aziz/siop2

mirror of https://github.com/siop-spelev/siop2.git synced 2026-08-08 12:41:54 +00:00

Files

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

3.3 KiB

Raw Blame History

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.

3.3 KiB Raw Blame History