mirror of
https://github.com/siop-spelev/siop2.git
synced 2026-08-08 20:51:53 +00:00
04e61056f6
Refondation design-first du projet SIOP (v1 gelée) : - Playbook 00-vision (charte projet, personas, benchmark Atlas) - Playbook 01-cadrage (releases R0→R5 + DoD, user-story map, exigences, risques) - Playbook 02-design : charte graphique, tokens.css bi-thème (palettes analytics validées CVD/contraste par script), maquettes HD navigables (7 écrans dont démo-login DEMO_MODE, bilan codé, portail QR, mobile) Prochaine étape : validation des maquettes par le référent avant tout code. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
68 lines
3.8 KiB
Markdown
68 lines
3.8 KiB
Markdown
# Charte projet — SIOP V2
|
|
|
|
> **Rôle de ce document (playbook)** : la charte projet est le contrat fondateur. Une page
|
|
> suffit pour dire *pourquoi* le projet existe, *ce qu'est* le succès et *qui* décide.
|
|
> Tout ce qui suit dans le playbook en découle. À rédiger AVANT toute conception.
|
|
|
|
## 1. Vision
|
|
|
|
Remplacer le carnet d'intervention papier des ascensoristes par une **GMAO complète et
|
|
belle**, pensée pour le métier de la maintenance d'ascenseurs — du signalement d'une panne
|
|
par un gardien d'immeuble jusqu'au PV signé par le client, en passant par le préventif
|
|
réglementaire et l'assistance IA au technicien.
|
|
|
|
## 2. Problème
|
|
|
|
- Le suivi des interventions se fait sur **carnet papier** (perte, illisibilité, aucune analyse).
|
|
- Les **périodicités réglementaires** (contrôles mensuels → annuels) sont suivies à la main.
|
|
- Le bureau ne sait pas **où en sont les techniciens** ni quels équipements coûtent cher.
|
|
- Les GMAO génériques du marché ignorent les spécificités ascenseur (organes, carnet codé,
|
|
PV contradictoire, urgence « personne bloquée »).
|
|
|
|
## 3. Objectifs jumeaux
|
|
|
|
| # | Objectif | Mesure de succès |
|
|
| --- | --- | --- |
|
|
| A | **Produit** : GMAO ascenseurs complète (web + mobile + IA), clone adapté d'Atlas CMMS | Déployée en production (Dokploy), utilisée sur un parc réel de démonstration, releases R0→R5 recettées |
|
|
| B | **Playbook** : documentation pédagogique de toutes les phases du cycle de vie | Un étudiant peut refaire chaque phase avec le seul playbook ; le référent l'utilise comme base de sa future entreprise de digitalisation |
|
|
|
|
## 4. Parties prenantes
|
|
|
|
| Rôle | Qui | Responsabilité |
|
|
| --- | --- | --- |
|
|
| Commanditaire & référent métier | Pr. Daaif (ENSET) | Décisions produit, validation des recettes et des maquettes |
|
|
| Entreprise partenaire | SPELEV (maintenance d'ascenseurs) | Réalité métier : carnet, périodicités, organisation |
|
|
| Équipe de réalisation | Pr. Daaif + assistant IA (puis étudiants ENSET) | Conception, développement, tests, docs |
|
|
| Hébergeur | Serveur d'un partenaire (PaaS Dokploy) | Production |
|
|
| Bénéficiaires pédagogiques | Étudiants ENSET | Apprennent sur le playbook et contribuent |
|
|
|
|
## 5. Périmètre (v1 du produit = releases R0 → R5)
|
|
|
|
**Inclus** : référentiel (sites, ascenseurs, organes, QR), personnes & permissions, ordres
|
|
de travail avec bilan codé, portail de demandes, maintenance préventive à périodicité,
|
|
compteurs, stock & achats, tiers, coûts (pièces + main-d'œuvre), analytics, bibliothèque de
|
|
fichiers, app mobile technicien offline (scan QR, checklist, synchro), IA (assistant RAG,
|
|
bilan assisté). Détail par release : `../01-cadrage/releases.md`.
|
|
|
|
**Exclus (v1)** : facturation client, multi-tenant SaaS, agent vocal temps réel et
|
|
affectation géospatiale automatique (étudiés en fin de R5 si le budget temps le permet).
|
|
|
|
## 6. Contraintes
|
|
|
|
- **Design-first** : maquettes validées avant le code (leçon de la v1).
|
|
- **Langue** : produit et docs en français ; code en anglais.
|
|
- **Réglementaire** : loi marocaine 09-08 (données personnelles, géolocalisation, audio).
|
|
- **Hébergement** : PaaS auto-hébergé (Dokploy) sur le serveur du partenaire.
|
|
- **Équipe réduite** : 1 encadrant + IA, étudiants à intégrer → conventions strictes, CI bloquante.
|
|
|
|
## 7. Risques majeurs (détail : `../01-cadrage/risques.md`)
|
|
|
|
Dérive de périmètre (mitigation : releases fermées) ; dette design (mitigation : revue pixel
|
|
par release) ; dépendance au serveur partenaire (mitigation : tout est Docker, portable).
|
|
|
|
## 8. Gouvernance
|
|
|
|
Le référent tranche toute décision produit (sollicité explicitement à chaque bifurcation).
|
|
Les décisions techniques sont consignées en ADR (`../03-architecture/adr/`). Une release se
|
|
clôt par : recette formelle signée + déploiement + chapitre de playbook relu.
|