siop2/docs/01-cadrage/releases.md

Plan de releases — SIOP V2

Rôle de ce document (playbook) : découper le produit en releases fermées — chaque release a un périmètre figé, une définition de fini (DoD) et se termine par une recette formelle + un déploiement. On n'ouvre pas Rn+1 avant la clôture de Rn. C'est l'antidote à la dérive de périmètre constatée en v1.

Définition de fini (DoD) commune à toutes les releases

1. Toutes les stories de la release recettées (critères d'acceptation × preuves).
2. CI verte : lint, typecheck, tests (couverture API ≥ 70 % bloquante), contrat OpenAPI à jour.
3. Revue pixel : les écrans livrés sont conformes aux maquettes validées.
4. Déployé en production (Dokploy) et vérifié en ligne.
5. Chapitre(s) de playbook de la release relus par le référent.
6. Journal + tag git release/rX.

R0 — Fondations (aucun écran métier)

But : tout ce qui rend les releases suivantes rapides et propres.

• Playbook 00-vision, 01-cadrage, 02-design (charte + tokens + maquettes HD validées), 03-architecture (ADRs, C4, modèle de données).
• Monorepo pnpm/Turborepo, infra Docker locale (PostgreSQL + Redis + MinIO), CI (4 pipelines : node, contrat, python, e2e).
• apps/api : auth JWT, matrice de permissions (7 rôles × objets × droits, en base), seed réaliste (parc d'ascenseurs de démonstration).
• Sélecteur de compte démo (DEMO_MODE=true) : bascule de rôle en < 3 s, local et démo, jamais en prod réelle.
• apps/web : coquille applicative (login, layout, navigation, design system appliqué, page vitrine du design system).
• Déploiement Dokploy « hello SIOP » (l'app en ligne dès R0).

Hors R0 : tout écran métier.

R1 — Référentiel

Sites/emplacements (hiérarchie + carte), ascenseurs + organes (hiérarchie, statuts, QR imprimable), catégories, personnes & équipes (invitation, activation, profils). Recette type : créer un site → un ascenseur → ses organes → imprimer l'étiquette QR → inviter un technicien.

R2 — Exploitation

Ordres de travail (machine à états, priorités dont « personne bloquée », assignation, commentaires, pièces jointes), bilan codé (6 champs + référentiels administrables + garde de clôture), portail de demandes (public via QR + interne) convergeant vers l'OT, préventif (gabarits à périodicité, génération mensuelle idempotente, checklist, premier contrôle), compteurs. Recette type : demande gardien → approbation → OT → intervention → bilan codé → clôture → suivi demandeur ; génération du préventif de juillet.

R3 — Gestion

Stock (mouvements, seuils, alertes), consommation sur OT à prix figé, bons de commande, tiers, main-d'œuvre valorisée (taux figé) et coût total OT, analytics (KPI + graphiques), bibliothèque de fichiers (documents rattachables). Recette type : consommer sous seuil → BC → réception → réappro ; coût complet d'un OT ; tableau de bord direction.

R4 — Mobile technicien

App Expo offline-first : OT assignés, fiche, scan QR → fiche ascenseur, checklist du mois cochable hors-ligne, clôture terrain, synchro à verrou optimiste (patron validé en v1). Recette type : mode avion en sous-sol → cocher la grille → retour réseau → synchro.

R5 — IA

Assistant RAG (notices + historiques ingérés, réponses citant leurs sources), aide à la saisie du bilan (suggestion de codes à partir d'une description libre). Si budget temps : transcription vocale du bilan. Principe : l'IA propose, l'humain valide. Recette type : « quel couple de serrage pour les guides du Gen2 ? » → réponse sourcée.

Après v1 (backlog v2)

PV PDF signé hors-ligne, check-in/out géolocalisés, agent vocal, affectation géospatiale automatique, multi-langue, exports comptables.