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>

docs/00-vision/benchmark-atlas.md

@@ -0,0 +1,55 @@
+# Benchmark — Atlas CMMS et adaptation ascenseurs
+
+> **Rôle de ce document (playbook)** : avant de concevoir, on étudie l'état de l'art. Ici,
+> [Atlas CMMS](https://github.com/grashjs/cmms) (GMAO open source, Spring Boot + React) est
+> notre référence fonctionnelle : on liste ce qu'on **reprend**, ce qu'on **adapte** au
+> métier ascenseur, ce qu'on **écarte**, et nos **différenciateurs**.
+
+## 1. Ce qu'Atlas fait bien (repris tel quel, réimplémenté dans notre stack)
+
+| Module Atlas | Reprise SIOP | Release |
+| --- | --- | --- |
+| Work Orders (statuts, priorités, assignés, coûts) | Ordres de travail, machine à états stricte | R2 |
+| Requests (portail + approbation → WO) | Demandes convergeant vers l'OT (lien 1-1) | R2 |
+| Preventive Maintenance (triggers) | Génération périodique d'OT avec checklist | R2 |
+| Assets + hiérarchie | Ascenseurs + **organes** (hiérarchie 2 niveaux) | R1 |
+| Locations | Sites/emplacements + carte | R1 |
+| Parts & Inventory / Purchase Orders | Stock dérivé des mouvements, BC, seuils | R3 |
+| People & Teams, rôles/permissions | Matrice rôles × objets × droits, en base | R0 |
+| Vendors & Customers | Tiers unifiés | R3 |
+| Files | Bibliothèque de documents rattachables | R3 |
+| Analytics | Tableau de bord KPI + agrégations SQL | R3 |
+| Mobile app | App technicien Expo offline-first | R4 |
+
+## 2. Ce qu'on adapte au métier ascenseur (le cœur de la valeur)
+
+| Spécificité métier (source : carnet SPELEV) | Traduction produit |
+| --- | --- |
+| **Bilan d'intervention codé** (6 champs à valeurs codifiées : état portes, position cabine, anomalie, cause extérieure, action, élément) | Référentiels administrables + garde de clôture : pas d'OT terminé sans bilan valide |
+| **Périodicités réglementaires** calées calendrier (mensuel → annuel, ancrage au mois — ex. parachute en juillet) | Gabarits de tâches à périodicité + génération mensuelle idempotente + « premier contrôle = tout » |
+| **Grille du mois** cochée en cabine | Checklist embarquée sur l'OT préventif, cochable hors-ligne sur mobile |
+| **PV contradictoire signé** (technicien + client) | Signatures tactiles + PDF fidèle au carnet, générable hors connexion (post-v1 : R5+) |
+| **Urgence « personne bloquée »** | Priorité dédiée, circuit court (alerte immédiate, pas de validation préalable) |
+| **Étiquette QR en cabine** | QR = URL canonique de la fiche → signalement prérempli (public) et fiche technicien (mobile) |
+
+## 3. Ce qu'on écarte (v1)
+
+- Multi-tenant SaaS, facturation, abonnements (Atlas est un produit commercial hébergé).
+- Workflows configurables génériques — nos flux métier sont fixés par le métier.
+- Intégrations tierces (SAP, IoT…) — hors périmètre v1.
+
+## 4. Nos différenciateurs (au-delà d'Atlas)
+
+1. **IA** (R5) : assistant RAG citant ses sources (notices, historiques), aide à la saisie
+   du bilan ; principe « l'IA propose, l'humain valide ».
+2. **Design métier** : interface pensée pour les personas ascensoristes (gros statuts,
+   urgences visibles, terminologie du carnet) — pas une GMAO générique habillée.
+3. **DX/démo** : sélecteur de compte démo 1 clic (`DEMO_MODE`) — essentiel pour la
+   démonstration commerciale ET le développement.
+
+## 5. Choix de stack face à Atlas
+
+Atlas = Java Spring Boot + React (MUI). Nous **ne clonons pas la stack**, seulement le
+fonctionnel : notre stack TypeScript de bout en bout (NestJS/React/Expo) + FastAPI pour
+l'IA est plus cohérente pour une équipe unique et l'enseignement (un seul langage principal).
+Décision motivée en ADR-001.

docs/00-vision/charte-projet.md

@@ -0,0 +1,67 @@
+# 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.

docs/00-vision/personas.md

@@ -0,0 +1,64 @@
+# Personas — SIOP V2
+
+> **Rôle de ce document (playbook)** : un persona n'est pas une fiche décorative — chaque
+> écran conçu en phase design doit pouvoir répondre à « quel persona, quelle tâche, quel
+> contexte ? ». Les rôles applicatifs (matrice de permissions) dérivent de ces personas.
+
+## P1 — Salma, dispatchrice (bureau)
+
+- **Contexte** : au bureau SPELEV, 2 écrans, toute la journée dans l'application.
+- **Tâches** : recevoir les demandes, créer/assigner les OT, surveiller les urgences,
+  relancer les techniciens, préparer les bons de commande.
+- **Douleurs** : jongler entre téléphone et papier ; ne pas savoir qui est où ; urgences
+  « personne bloquée » à traiter en secondes.
+- **Attentes produit** : tableau de bord temps réel, création d'OT en < 30 s, assignation
+  en 1 clic, alertes visibles.
+- **Rôle applicatif** : *Dispatcher* (tout voir, tout créer/éditer, pas d'administration).
+
+## P2 — Ahmed, technicien itinérant (terrain)
+
+- **Contexte** : en déplacement, souvent en sous-sol **sans réseau**, gants, pressé.
+- **Tâches** : consulter ses OT du jour, scanner le QR en cabine, dérouler la checklist du
+  mois, saisir le bilan codé, faire signer le client, repartir.
+- **Douleurs** : réseau absent, ressaisie au bureau le soir, carnet papier perdu.
+- **Attentes produit** : mobile **offline-first**, gros boutons, checklist en 2 taps,
+  synchro automatique au retour du réseau.
+- **Rôle applicatif** : *Technicien* (ses OT, saisie terrain ; « voir autre » limité).
+
+## P3 — Karim, gardien d'immeuble (demandeur)
+
+- **Contexte** : occasionnel, smartphone, aucune formation à l'outil.
+- **Tâches** : signaler une panne (photo à l'appui), suivre l'avancement.
+- **Douleurs** : ne sait pas si sa demande a été vue ; rappelle 3 fois.
+- **Attentes produit** : portail ultra-simple (ou scan du QR en cabine → formulaire
+  prérempli), suivi du statut sans jargon interne.
+- **Rôle applicatif** : *Demandeur* (ses demandes uniquement, rien d'autre).
+
+## P4 — Nadia, gestionnaire (back-office)
+
+- **Contexte** : mi-temps sur l'outil ; responsable stock, achats, contrats.
+- **Tâches** : inventaire, seuils et réappro, bons de commande, tiers, documents
+  (certificats, notices), coûts par équipement.
+- **Attentes produit** : tables efficaces (tri/filtre/export), alertes de stock,
+  bibliothèque documentaire rangée.
+- **Rôle applicatif** : *Gestionnaire* (stock, achats, tiers, fichiers ; lecture OT).
+
+## P5 — M. Bennis, direction (lecture)
+
+- **Contexte** : consulte 1 fois par semaine, souvent sur mobile.
+- **Tâches** : indicateurs (pannes, coûts, taux de préventif, réactivité), décisions
+  contrat/renouvellement de parc.
+- **Attentes produit** : tableau de bord lisible en 30 s, tendances, export.
+- **Rôle applicatif** : *Vue seule* (analytics + lecture).
+
+## P0 — L'administrateur (transverse)
+
+Paramètre l'instance : utilisateurs, permissions, référentiels du bilan codé, gabarits de
+périodicité. Rôle *Administrateur* (tout). C'est aussi **le compte de démonstration** par
+défaut du sélecteur `DEMO_MODE`.
+
+---
+
+**Correspondance personas → rôles de la matrice** : Administrateur, Dispatcher, Technicien,
+Technicien limité (variante « voir autre » restreinte de P2), Gestionnaire, Demandeur,
+Vue seule — 7 rôles seedés dès R0, tous accessibles en 1 clic via le sélecteur démo.