# 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.