Files
siop2/docs/01-cadrage/user-story-map.md
pr-daaif 04e61056f6 docs(r0): kickoff SIOP V2 — vision, cadrage, charte graphique, maquettes HD
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>
2026-07-15 21:06:33 +01:00

54 lines
3.3 KiB
Markdown

# User-story map — SIOP V2
> **Rôle de ce document (playbook)** : la carte relie les activités des personas (colonnes)
> aux releases (lignes). Chaque cellule = stories. Les critères d'acceptation détaillés
> sont écrits au cadrage de chaque release (format *Étant donné / Quand / Alors*) dans les
> issues GitHub du jalon correspondant.
## Activités (le « squelette » horizontal)
| | A. Gérer le parc | B. Exploiter (pannes) | C. Prévenir (réglementaire) | D. Gérer les ressources | E. Piloter | F. Terrain (mobile) | G. Être assisté (IA) |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Personas | Salma, Nadia | Salma, Ahmed, Karim | Salma, Ahmed | Nadia | M. Bennis | Ahmed | Ahmed, Salma |
## Carte (stories clés par release)
### R0 — Fondations
- En tant qu'**équipe**, je me connecte avec mon rôle et ne vois que ce que ma matrice autorise.
- En tant que **développeur/démonstrateur**, je bascule de compte en 1 clic (`DEMO_MODE`).
- En tant que **visiteur**, je vois une app en ligne au design abouti (coquille + design system).
### R1 — Référentiel
- **A** Salma crée un site (adresse, position carte) puis un ascenseur (marque, n° série, mise en service) et ses organes.
- **A** Salma imprime l'étiquette **QR** à coller en cabine.
- **A** L'admin invite un technicien (lien d'activation) et compose des équipes.
### R2 — Exploitation
- **B** Karim scanne le QR en cabine → formulaire de signalement prérempli avec photo ; il suit ensuite l'avancement sans jargon.
- **B** Salma approuve la demande → un OT est créé (lien 1-1) et assigné en 1 clic.
- **B** Un OT « **personne bloquée** » saute en tête partout, visuellement impossible à manquer.
- **B** Ahmed clôt son OT par le **bilan codé** (6 champs) ; la clôture est bloquée si incomplet.
- **C** Le 1er du mois, les OT préventifs se génèrent avec la **checklist des tâches dues** (parachute en juillet, premier contrôle = tout) ; regénérer ne double rien.
- **C** La clôture d'un OT préventif exige la checklist complète (Fait / N-A).
### R3 — Gestion
- **D** Nadia consomme une pièce sur un OT (prix figé) ; sous le seuil, une alerte part et un BC se prépare ; la réception réapprovisionne.
- **D** Nadia range notices et certificats dans la **bibliothèque**, rattachés à l'ascenseur.
- **D** La main-d'œuvre saisie (taux figé par personne) donne le **coût total** de l'OT.
- **E** M. Bennis lit en 30 s : OT par statut, pannes par organe, taux de préventif, coûts, top équipements.
### R4 — Mobile
- **F** Ahmed voit ses OT triés priorité/échéance, **même sans réseau**.
- **F** Il scanne le QR → fiche de l'ascenseur et ses interventions.
- **F** Il coche la grille du mois hors-ligne et clôt du terrain ; tout se synchronise au retour du réseau **sans perdre une saisie** (verrou optimiste).
### R5 — IA
- **G** Ahmed demande « procédure de réglage des portes Gen2 » → réponse **avec source** (notice ingérée).
- **G** Ahmed décrit la panne en langage libre → l'assistant **suggère les codes** du bilan ; il valide ou corrige.
## Priorisation
Le chemin critique produit est **B + C** (c'est le carnet papier remplacé) — d'où R2 au
centre du programme. A (R1) est le prérequis de tout ; D/E (R3) rendent l'outil gestionnaire ;
F (R4) supprime la ressaisie ; G (R5) différencie.