From 04e61056f67cc0962fd9b87969b7fd6f30602ef2 Mon Sep 17 00:00:00 2001 From: pr-daaif Date: Wed, 15 Jul 2026 21:06:33 +0100 Subject: [PATCH] =?UTF-8?q?docs(r0):=20kickoff=20SIOP=20V2=20=E2=80=94=20v?= =?UTF-8?q?ision,=20cadrage,=20charte=20graphique,=20maquettes=20HD?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- .gitignore | 4 + CLAUDE.md | 34 + README.md | 46 ++ docs/00-vision/benchmark-atlas.md | 55 ++ docs/00-vision/charte-projet.md | 67 ++ docs/00-vision/personas.md | 64 ++ docs/01-cadrage/exigences.md | 55 ++ docs/01-cadrage/releases.md | 71 ++ docs/01-cadrage/risques.md | 20 + docs/01-cadrage/user-story-map.md | 53 ++ docs/02-design/charte-graphique.md | 79 ++ docs/02-design/maquettes/maquette-web.html | 821 +++++++++++++++++++++ docs/02-design/tokens.css | 156 ++++ docs/journal/journal.md | 22 + 14 files changed, 1547 insertions(+) create mode 100644 .gitignore create mode 100644 CLAUDE.md create mode 100644 README.md create mode 100644 docs/00-vision/benchmark-atlas.md create mode 100644 docs/00-vision/charte-projet.md create mode 100644 docs/00-vision/personas.md create mode 100644 docs/01-cadrage/exigences.md create mode 100644 docs/01-cadrage/releases.md create mode 100644 docs/01-cadrage/risques.md create mode 100644 docs/01-cadrage/user-story-map.md create mode 100644 docs/02-design/charte-graphique.md create mode 100644 docs/02-design/maquettes/maquette-web.html create mode 100644 docs/02-design/tokens.css create mode 100644 docs/journal/journal.md diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..6a73c02 --- /dev/null +++ b/.gitignore @@ -0,0 +1,4 @@ +.DS_Store +node_modules/ +dist/ +.env diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 0000000..4d147c5 --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1,34 @@ +# SIOP V2 — GMAO ascenseurs (refondation design-first) + +## Contexte + +Projet **réel** (SPELEV, maintenance d'ascenseurs, Maroc) mené par le Pr. Daaif (ENSET) avec ses étudiants. **V2 = refondation** de `siop-spelev/siop` (v1, gelée, référence de lecture seulement) décidée le 15 juillet 2026 : 100 % nouveau code, design en premier, documentation en « playbook » pédagogique. Double objectif : **produit** complet déployé (web + mobile + IA, Dokploy) et **playbook** du cycle de vie logiciel (cours ENSET + méthode de la future entreprise du référent). + +**Langue de travail : français** (docs, échanges, commits descriptifs). Code et identifiants en anglais. + +## Principes non négociables (V2) + +1. **Design-first** : aucune ligne de code applicatif avant validation par le référent de la charte graphique, des tokens et des maquettes HD (`docs/02-design/`). Chaque release subit une revue « pixel » écrans ↔ maquettes. +2. **Playbook vivant** : chaque phase du cycle de vie a son dossier `docs/0X-*/` (template réutilisable + artefacts réels). Le journal quotidien vit dans `docs/journal/` — **jamais** dans le livre. +3. **Périmètre fermé par release** : R0 Fondations → R1 Référentiel → R2 Exploitation → R3 Gestion → R4 Mobile → R5 IA. On n'ouvre pas Rn+1 avant recette **et** déploiement de Rn. +4. **Déployer tôt** : chaque release part sur le serveur de production (Dokploy) dès sa recette. +5. **Le développeur est le premier utilisateur** : `DEMO_MODE=true` active un **sélecteur de compte démo** (connexion 1 clic sur les comptes seedés, endpoint `POST /auth/demo-login` strictement absent si l'env ne l'active pas). Critère : changer de rôle en < 3 s sans mot de passe. + +## Stack (ADR-001 — reconduite de v1 car éprouvée, code neuf) + +pnpm + Turborepo. `apps/api` : NestJS, Prisma, PostgreSQL (pgvector + PostGIS), Redis, MinIO derrière l'interface `FileStorage` (jamais d'import direct du SDK). `apps/web` : React 19, Vite, TanStack Query/Table, **shadcn/ui + Tailwind v4** thématisés par les tokens de `docs/02-design/tokens.css`, Lucide. `apps/mobile` : Expo (Expo Go). `apps/ai` : FastAPI (Python, uv). **Règle d'or du contrat** : schémas Zod dans `packages/shared` → OpenAPI committée → clients typés régénérés dans le même commit (CI bloquante). + +## Conventions + +- **Journal de bord** : toute session se clôt par une entrée en tête de `docs/journal/journal.md` (date — auteur — release/tâche ; Actions / Décisions / Prochaine étape). +- Mode solo temporaire : commits directs sur `main` tolérés ; à l'arrivée des étudiants → PR + CI obligatoires. +- Commits conventionnels ; branches courtes `feat/…`, `fix/…`. +- Tests écrits avec le code : Jest (api), Vitest (web), jest-expo (mobile), pytest (ai) ; couverture backend ≥ 70 % bloquante ; parcours Playwright par release. +- API fermée par défaut (guard JWT global, `@Public()` explicite) ; matrice de permissions en base. +- Conformité loi 09-08 : géolocalisation limitée au service, purge des audios, consentements. +- IA : l'IA propose, un humain valide (sauf urgence « personne bloquée ») ; toute réponse RAG cite sa source. + +## État d'avancement + +- 🔄 **R0 — Fondations** (en cours) : vision + cadrage + design (charte, tokens, maquettes HD) rédigés ; **en attente de validation des maquettes par le référent avant tout code applicatif**. Suivront : monorepo, CI, auth + permissions + démo-login, déploiement Dokploy « hello ». +- Dépôt GitHub : `siop-spelev/siop2` (privé). Jalons R0→R5 créés. diff --git a/README.md b/README.md new file mode 100644 index 0000000..09a6b57 --- /dev/null +++ b/README.md @@ -0,0 +1,46 @@ +# SIOP V2 — GMAO pour la maintenance d'ascenseurs + +**SIOP** (Système Intégré d'Opérations de maintenance Préventive) est une GMAO complète +dédiée à la maintenance d'ascenseurs, inspirée fonctionnellement d'[Atlas CMMS](https://github.com/grashjs/cmms) +et adaptée au métier (carnet d'intervention, périodicités réglementaires, PV signés, +urgence « personne bloquée »), avec une couche IA différenciante. + +Ce dépôt poursuit **deux objectifs jumeaux** : + +1. **Le produit** — une application web + mobile + IA complètement fonctionnelle, + déployée en production (Dokploy). +2. **Le playbook** — la documentation *pédagogique* de toutes les phases du cycle de + vie logiciel (cadrage → design → architecture → développement → tests → production + → formation), réutilisable comme support de cours et comme méthode d'entreprise. + +> V2 : refondation *design-first* du projet [siop](https://github.com/siop-spelev/siop) +> (v1, gelée — elle sert de référence de lecture). 100 % nouveau code. + +## Le playbook + +| Phase | Dossier | Contenu | +| --- | --- | --- | +| Vision | [docs/00-vision](docs/00-vision/) | Charte projet, personas, benchmark Atlas | +| Cadrage | [docs/01-cadrage](docs/01-cadrage/) | Releases, user-story map, exigences, risques | +| Design | [docs/02-design](docs/02-design/) | Charte graphique, design tokens, maquettes HD | +| Architecture | [docs/03-architecture](docs/03-architecture/) | ADRs, C4, modèle de données, contrat d'API | +| Développement | [docs/04-developpement](docs/04-developpement/) | Conventions, déroulé d'un sprint | +| Tests | [docs/05-tests](docs/05-tests/) | Stratégie, plans, recettes par release | +| Production | [docs/06-production](docs/06-production/) | Runbook Dokploy, sauvegardes, sécurité | +| Formation | [docs/07-formation](docs/07-formation/) | Manuels, supports, exercices étudiants | + +## Releases + +`R0` Fondations → `R1` Référentiel → `R2` Exploitation → `R3` Gestion → `R4` Mobile → `R5` IA. +Règle : **une release n'ouvre pas tant que la précédente n'est pas recettée et déployée.** + +## Démarrage (à partir de R0) + +```bash +nvm use && pnpm install +pnpm infra:up # PostgreSQL + Redis + MinIO (Docker) +pnpm dev +``` + +--- +Projet mené par le Pr. Daaif (ENSET Mohammedia) avec ses étudiants, en partenariat avec SPELEV. diff --git a/docs/00-vision/benchmark-atlas.md b/docs/00-vision/benchmark-atlas.md new file mode 100644 index 0000000..0192ef6 --- /dev/null +++ b/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. diff --git a/docs/00-vision/charte-projet.md b/docs/00-vision/charte-projet.md new file mode 100644 index 0000000..f7604fc --- /dev/null +++ b/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. diff --git a/docs/00-vision/personas.md b/docs/00-vision/personas.md new file mode 100644 index 0000000..a3d3c88 --- /dev/null +++ b/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. diff --git a/docs/01-cadrage/exigences.md b/docs/01-cadrage/exigences.md new file mode 100644 index 0000000..2ce46cd --- /dev/null +++ b/docs/01-cadrage/exigences.md @@ -0,0 +1,55 @@ +# Exigences non fonctionnelles — SIOP V2 + +> **Rôle de ce document (playbook)** : les exigences fonctionnelles vivent dans la +> user-story map et les issues ; ici on fige ce qui est **transversal** — qualité, sécurité, +> conformité, exploitation — avec des critères **mesurables** (sinon invérifiables). + +## Qualité & design + +| Exigence | Critère mesurable | +| --- | --- | +| Fidélité au design | Revue pixel par release : écrans conformes aux maquettes validées (`../02-design/`) | +| Réactivité | Interfaces utilisables de 360 px (mobile) à 1920 px ; tables scrollables sans casser la page | +| Thème | Clair **et** sombre, pilotés par les tokens ; aucun style codé en dur hors tokens | +| Accessibilité | Navigation clavier sur les parcours critiques ; libellés/aria sur tous les contrôles ; contraste AA | +| Langue | 100 % français (produit), zéro franglais dans l'UI | + +## Performance + +| Exigence | Critère | +| --- | --- | +| Chargement des listes | < 1 s pour 10 000 OT (pagination serveur, index SQL) | +| Tableau de bord | < 2 s (agrégations SQL, jamais de calcul en mémoire sur tout l'historique) | +| Mobile offline | Ouverture d'un OT déjà synchronisé : instantanée (< 200 ms, lecture locale) | + +## Sécurité + +| Exigence | Critère | +| --- | --- | +| API fermée par défaut | Guard JWT global ; routes publiques explicitement `@Public()` ; test de couverture des routes | +| Permissions | Matrice rôles × objets × droits **en base** (jamais dans le JWT), testée rôle par rôle | +| Démo-login | `POST /auth/demo-login` **inexistant** (404) si `DEMO_MODE` n'est pas `true` ; jamais activé en production réelle ; test e2e dédié | +| Fichiers | Accès aux objets MinIO uniquement par URL signée à durée courte ; clés opaques | +| Secrets | Jamais en git ; `.env.example` exhaustifs ; secrets Dokploy | + +## Conformité (loi 09-08) + +Consentement explicite pour toute géolocalisation ; géolocalisation limitée aux heures de +service ; purge des enregistrements audio après transcription (R5) ; droit d'accès/rectification +des données personnelles (procédure au runbook). + +## Fiabilité & exploitation + +| Exigence | Critère | +| --- | --- | +| Sauvegardes | PostgreSQL + MinIO sauvegardés quotidiennement ; restauration testée 1×/release (runbook) | +| Migrations | `prisma migrate deploy` rejouable ; seed idempotent (rejouer ne casse rien) | +| Offline mobile | Aucune saisie terrain perdue : file locale + verrou optimiste + rejeu (testé) | +| Supervision | Endpoint `/health` (base, Redis, MinIO) ; vérifié au déploiement | + +## Testabilité + +Pyramide : unitaires (logique pure), intégration contre infra réelle (Docker), parcours +navigateur Playwright (1+ par release), mobile testé en Node (`node:sqlite`), contrat +OpenAPI bloquant en CI. Couverture API ≥ 70 % **bloquante**. Chaque bug corrigé = un test +qui l'aurait attrapé. diff --git a/docs/01-cadrage/releases.md b/docs/01-cadrage/releases.md new file mode 100644 index 0000000..4d30f68 --- /dev/null +++ b/docs/01-cadrage/releases.md @@ -0,0 +1,71 @@ +# 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. diff --git a/docs/01-cadrage/risques.md b/docs/01-cadrage/risques.md new file mode 100644 index 0000000..d8dcbc4 --- /dev/null +++ b/docs/01-cadrage/risques.md @@ -0,0 +1,20 @@ +# Registre des risques — SIOP V2 + +> **Rôle de ce document (playbook)** : nommer les risques AVANT qu'ils ne frappent, avec +> une mitigation concrète et un signal d'alerte. Relu à chaque clôture de release ; +> les risques réalisés sont documentés (post-mortem court) — c'est de la matière de cours. + +| # | Risque | Prob. | Impact | Mitigation | Signal d'alerte | +| --- | --- | --- | --- | --- | --- | +| 1 | **Dérive de périmètre** (la cause n°1 de l'abandon de la v1) | Haute | Haut | Releases fermées (DoD stricte) ; toute idée hors release va au backlog v2, jamais dans la release courante | Une story « en plus » apparaît dans un jalon en cours | +| 2 | **Dette design** — l'esthétique se dégrade sous la pression du fonctionnel | Haute | Haut | Maquettes validées avant code ; revue pixel par release ; tokens obligatoires (pas de styles ad hoc) | Un écran livré « à peu près comme la maquette » | +| 3 | **Playbook en retard** sur le produit (docs bâclées en fin de release) | Moyenne | Haut (objectif B) | Le chapitre s'écrit PENDANT la release ; sa relecture fait partie de la DoD | Chapitre vide à mi-release | +| 4 | **Serveur partenaire indisponible** ou repris | Moyenne | Moyen | Tout est Docker/Dokploy → portable en heures ; sauvegardes exportées hors du serveur | Latence/pannes récurrentes | +| 5 | **Rupture d'outillage** (versions Expo/React/Prisma, pnpm) | Moyenne | Moyen | Versions épinglées ; leçons v1 documentées (jest-expo↔jest, peers Expo/pnpm, worklets) ; monter de version = tâche dédiée, jamais en passant | CI rouge après un simple `install` | +| 6 | **Équipe qui s'élargit** (étudiants) sans conventions intégrées | Moyenne | Moyen | CLAUDE.md + 04-developpement comme contrat d'équipe ; PR + CI obligatoires dès leur arrivée ; exercices d'onboarding (07-formation) | Styles/patterns divergents dans les PR | +| 7 | **IA (R5) survendue** — attentes RAG > réalité | Moyenne | Moyen | Jeu d'évaluation constitué AVANT le développement ; « l'IA propose, l'humain valide » ; périmètre R5 réduit et honnête | Réponses non sourcées jugées « suffisantes » | +| 8 | **Données de démo peu crédibles** → démos commerciales ternes | Basse | Moyen | Seed réaliste dès R0 (parc marocain nommé, historiques plausibles) maintenu à chaque release | Démo qui montre des « Test 123 » | + +## Post-mortems + +*(vide — se remplit quand un risque se réalise)* diff --git a/docs/01-cadrage/user-story-map.md b/docs/01-cadrage/user-story-map.md new file mode 100644 index 0000000..5dbf453 --- /dev/null +++ b/docs/01-cadrage/user-story-map.md @@ -0,0 +1,53 @@ +# 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. diff --git a/docs/02-design/charte-graphique.md b/docs/02-design/charte-graphique.md new file mode 100644 index 0000000..060b2ee --- /dev/null +++ b/docs/02-design/charte-graphique.md @@ -0,0 +1,79 @@ +# Charte graphique — SIOP V2 + +> **Rôle de ce document (playbook)** : fixer l'identité visuelle AVANT le code. Toute +> valeur visuelle vit dans [`tokens.css`](tokens.css) (source de vérité, importée telle +> quelle par l'application) ; ce document explique les **choix** et leurs raisons. +> Règle absolue : aucun style codé en dur hors tokens — c'est ce qui a rendu la v1 « flottante ». + +## 1. Positionnement + +SIOP est un **outil de travail professionnel** pour ascensoristes : sobre, dense sans être +étouffant, lisible en plein soleil sur un chantier comme au bureau. Le monde visuel est +celui du métier — acier, cabine, signalisation de sécurité — pas celui d'une app grand +public. Deux thèmes (clair/sombre) au même niveau de soin. + +## 2. Couleur + +| Token | Valeur (clair) | Rôle & justification | +| --- | --- | --- | +| `--encre` | `#1B2534` | Texte principal — un « noir acier » à biais bleu, jamais de noir pur | +| `--bleu-treuil` | `#1F4FB8` | **Primaire** (actions, liens, focus) — bleu de vêtement de travail, profond et désaturé, volontairement distinct du bleu néon par défaut des frameworks | +| `--safran` | `#DD8A0B` | **Accent de marque** — safran marocain / gilet haute visibilité. Parcimonieux : logo, rail actif de navigation, moments de marque. Jamais pour un statut | +| Fonds | `#F5F7FA` / surfaces `#FFFFFF` | Acier clair, biais froid assumé | +| Sombre | fond `#0F1622`, surface `#182234` | « Machinerie de nuit » — pas une simple inversion | + +**Statuts (réservés, jamais réutilisés ailleurs)** : Ouvert `bleu`, En cours `indigo`, +En attente `ambre`, Terminé `vert`, Annulé `gris`. Priorités : **Personne bloquée** +(rouge vif + pastille animée — la seule animation d'alerte de l'app), Haute `rouge`, +Moyenne `ambre`, Basse `verte`. Toujours pastille/pictogramme + libellé, jamais la couleur seule. + +**Palettes graphiques (analytics) — validées par script (CVD, contraste, bande de +luminosité)** : + +- Clair : `#3B69D6 · #DD8A0B · #1F9E8E · #8A63D2` (ordre fixe, jamais recyclé ; étiquettes + directes obligatoires — le safran passe sous 3:1 sur blanc). +- Sombre : `#5580E4 · #C7820A · #26A896 · #9673DE` (repas dédiés, pas d'inversion automatique). + +## 3. Typographie + +- **UI & titres : Manrope** (géométrique-humaniste, OFL, auto-hébergée — jamais de CDN). + Titres en 600/700, `text-wrap: balance`. Les maquettes HTML approximent avec Avenir Next + (présent sur macOS) en attendant l'app. +- **Données : chiffres tabulaires** (`font-variant-numeric: tabular-nums`) partout où des + nombres s'alignent (tables, KPI, coûts). +- Échelle : 12 / 13 / 14 (base) / 16 / 20 / 24 / 32. Libellés en capitales : 11 px, + `letter-spacing: 0.06em`. + +## 4. Forme & espace + +- Grille d'espacement **4 px** ; densité « bureau » (tables 40 px/ligne) mais cibles + tactiles ≥ 44 px sur mobile. +- Rayons : 10 px (cartes), 8 px (contrôles), 999 px (pastilles). +- Élévation discrète : bordures d'abord (`--bordure`), ombre légère seulement au survol/menus. +- **Motif signature « rail »** : l'élément actif de la navigation porte un rail vertical + safran de 3 px (la cage d'ascenseur) — c'est LE geste identitaire, utilisé nulle part ailleurs. + +## 5. Iconographie & logo + +- **Lucide**, trait 1,75 px, 16–20 px dans l'UI. +- Logotype : « SIOP » en Manrope 700 + marque **▲▼** (montée/descente cabine) safran sur + encre. Favicon = la marque seule. + +## 6. Mouvement + +Fonctionnel uniquement : transitions 120–160 ms (`ease-out`) sur survol/ouverture ; +`prefers-reduced-motion` respecté ; **une seule** animation continue autorisée — la +pastille « personne bloquée ». + +## 7. Ton rédactionnel + +Français métier, direct, sans jargon système : « Clôturer l'intervention », pas +« Soumettre le formulaire ». Les erreurs disent quoi faire (« La checklist est incomplète : +traitez chaque tâche »), jamais « Erreur 400 ». Vocabulaire du carnet : OT, bilan, organe, +grille du mois. + +## 8. Application + +`tokens.css` est copié tel quel dans `apps/web` (et mappé vers la config Tailwind/shadcn). +La page `/design` de l'app (R0) expose tous les tokens et composants — c'est la référence +vivante des revues pixel. diff --git a/docs/02-design/maquettes/maquette-web.html b/docs/02-design/maquettes/maquette-web.html new file mode 100644 index 0000000..50ef91d --- /dev/null +++ b/docs/02-design/maquettes/maquette-web.html @@ -0,0 +1,821 @@ + + + + + +SIOP V2 — Maquettes haute-fidélité + + + + + + +
+ SIOP V2 · Maquettes HD + +
+
+ + +

Intention : première impression sobre ; le mode démonstration (demande DX du référent) permet d'entrer dans n'importe quel rôle en 1 clic — visible uniquement quand DEMO_MODE=true.

+
+
+
+ +
+
+ +
Mode démonstration
+
+ + + + + +
+
DEMO_MODE=true — absent en production
+
+
+
+ + + +
+
+ +
+
+
Rechercher un OT, un ascenseur, un site… ⌘K
+ 1 personne bloquée +
DÉMOSI +
Salma Idrissi
Dispatchrice ▾
+
+
+
+ +
Personne bloquée — Tour Atlas, ascenseur B2 (Casablanca)
+ Signalé il y a 4 min par le gardien · aucune intervention en cours
+
+
+
+
OT ouverts
12
dont 5 en cours
+
En retard
3
+2 cette semaine
+
Préventif · juillet
+
+ + + + +
78 %
32 / 41 grilles
+
+
Demandes à traiter
4
la + ancienne : 2 h
+
Coût · juillet
18 450 MAD
−12 % vs juin
+
+
+
+

OT par statut

+
+
Ouvert
7
+
En cours
5
+
En attente
2
+
Terminé (30 j)
34
+
+
+
+

Pannes par organe · 12 mois

+
+
Portes
34
+
Armoire cde
18
+
Boutons
12
+
Treuil
7
+
Parachute
5
+
+
+
+
+

Interventions récentes

+
+ + + + + + + +
N°ObjetÉquipementPrioritéStatutAssignés
OT-2026-0341Bruit anormal en gaineAsc. A1Résidence Al ManarHauteEn cours
AB
OT-2026-0339Grille du mois — juilletAsc. C1Anfa PlaceBasseOuvert
FA
OT-2026-0336Remplacement contact porteAsc. B2Tour AtlasMoyenneEn attente
ABFA
OT-2026-0332Réglage nivellement cabineAsc. A1Résidence Al ManarBasseTerminé
FA
+
+
+
+
+
+ + + +
+
+
+
+
Rechercher…
+ 1 personne bloquée +
DÉMOSI +
Salma Idrissi
Dispatchrice ▾
+
+
+
+

Ordres de travail

+
+
+
+ Statut : Actifs ▾ + Type : Tous ▾ + Priorité : Toutes ▾ + Assigné : Tous ▾ + 14 résultats +
+
+ + + + + + + + + + +
N°ObjetÉquipement · SiteTypePrioritéStatutAssignésÉchéance
OT-2026-0342Personne bloquée en cabineAsc. B2Tour Atlas, CasablancaDépannagePersonne bloquéeOuvert—immédiat
OT-2026-0341Bruit anormal en gaineAsc. A1Résidence Al Manar, MohammediaDépannageHauteEn cours
AB
15 juil.
OT-2026-0339Grille du mois — juilletAsc. C1Anfa Place, CasablancaMaintenanceBasseOuvert
FA
31 juil.
OT-2026-0338Grille du mois — juilletAsc. A1Résidence Al Manar, MohammediaMaintenanceBasseEn cours
AB
31 juil.
OT-2026-0336Remplacement contact de porteAsc. B2Tour Atlas, CasablancaDépannageMoyenneEn attente
ABFA
18 juil.
OT-2026-0335Ampoule cabine grilléeAsc. D3Clinique Andalous, MohammediaTravauxBasseOuvert—22 juil.
OT-2026-0332Réglage nivellement cabineAsc. A1Résidence Al Manar, MohammediaDépannageBasseTerminé
FA
12 juil.
+
+
+
+
+ + + +
+
+
+
+
Rechercher…
+
DÉMOSI +
Salma Idrissi
Dispatchrice ▾
+
+
+
Ordres de travail / OT-2026-0341
+
+

Bruit anormal en gaine

+ En cours +
+ + + +
+
+
+
+

Intervention

+
+
N°
OT-2026-0341 · Dépannage
+
Équipement
Ascenseur A1 — Otis Gen2
+
Site
Résidence Al Manar, Mohammedia
+
Priorité
Haute
+
Échéance
15 juillet 2026
+
Assignés
+ AB Ahmed Benali +
+
Demande liée
DEM-2026-0107 — Karim Doukkali (gardien)
+
+
+
+

Activité

+
    +
  • Ahmed Benali a démarré l'intervention
    aujourd'hui · 09 h 41
    • +
  • Commentaire d'Ahmed : « Frottement guide côté gaine, contrôle des coulisseaux en cours. »
    aujourd'hui · 10 h 05
    • +
  • Salma Idrissi a assigné Ahmed Benali
    hier · 16 h 22
    • +
  • OT créé depuis la demande DEM-2026-0107
    hier · 16 h 20
    • +
+
+
+
+
+

Bilan d'intervention — requis pour clôturer

+
+
Fonctionnement normal ▾
+
Entre deux niveaux ▾
+
Frottement mécanique ▾
+
Sélectionner… ▾
+
Réglage ▾
+
Sélectionner… ▾
+
+

⚠ « Élément concerné » manquant — la clôture restera bloquée.

+
+
+
+

Pièces & main-d'œuvre

+
Coulisseau de guide × 2240 MAD
+
Graisse guide (cartouche)85 MAD
+
Ahmed Benali · 1 h 30 × 120 MAD/h180 MAD
+
Coût total505 MAD
+
+
+

Documents

+
photo-guide-frottement.jpg2,1 Mo · ↓
+
+
+
+
+
+
+
+ + + +
+
+
+
+
Rechercher…
+
DÉMOSI +
Salma Idrissi
Dispatchrice ▾
+
+
+
Ascenseurs / Ascenseur A1
+
+

Ascenseur A1 — Otis Gen2 Premier

+ En service +
+ + +
+
+
+
+

Identité

+
+
N° de série
OT-2020-4521
+
Marque · modèle
Otis — Gen2 Premier
+
Mise en service
15 mars 2020
+
Site
Résidence Al Manar — Bd Hassan II, Mohammedia
+
Contrat préventif
Actif · premier contrôle effectué
+
Charge · niveaux
630 kg · 8 niveaux
+
+
+
+

Étiquette cabine

+
+ + + + + + + + + + + + + + +
Collée en cabine.
Scan gardien → signalement prérempli.
Scan technicien → cette fiche.
+
+
+
+
+
+

Organes

+
Portes cabine — Fermator 40/10Surveillance
+
Treuil — Gen2 gearlessBon état
+
Parachute — essai juillet ✓Conforme
+
Armoire de commande — MCS 220Bon état
+
+
+
+

Historique récent

+
    +
  • OT-2026-0341 · Bruit en gaine — En cours
    ouvert hier
    • +
  • OT-2026-0338 · Grille du mois juillet — En cours
    généré le 1ᵉʳ juillet
    • +
  • OT-2026-0332 · Nivellement cabine — Terminé
    12 juillet · bilan : Réglage / Guides
    • +
+
+
+

Documents

+
Notice Otis Gen2 Premier.pdf1,2 Mo · ↓
+
Certificat parachute 2026.pdf340 Ko · ↓
+
+
+
+
+
+
+
+ + + +
+
+
+ +
+
+ + Ascenseur A1 — hall principal (détecté par le QR) +
+
Une personne est-elle bloquée dans la cabine ?
+
+
+
📷 Ajouter une photo (facultatif)
+ +
+
+

Mes signalements

+
+ Porte bloquée au 3ᵉ étageDEM-2026-0107 · hier +
+ ✓ Reçu + Intervention en cours + Résolu +
+
+
+ Voyant cabine éteintDEM-2026-0093 · 2 juil. +
+ ✓ Reçu + ✓ Intervention + ✓ Résolu +
+
+
+
+
+
+ + + +
+
+
+
+

Mes interventions ⟳ à jour

+
+
Dépannage Haute
+ Bruit anormal en gaine +
Asc. A1 · Résidence Al Manar
+
+
+
Maintenance Basse
+ Grille du mois — juillet +
Asc. A1 · Résidence Al Manar
+
+
+
Dépannage Moyenne
+ Contact de porte +
Asc. B2 · Tour Atlas
+
+
+
+
+
+
+

Grille du mois ⟳ hors-ligne · 2 en attente

+
OT-2026-0338 · Asc. A1 · 2/4 traitées
+
+
✓Jeu et fixation des portes
+
–Éclairage de secours N-A
+
Niveau d'huile du treuil
+
Essai parachute (juillet)
+
+
FaitNon applicable
+
+ +
Vos coches partiront à la prochaine synchro
+
+
+
+
+
+

Scanner

+

Visez le QR collé en cabine

+ +
+
+
+
+ + + + diff --git a/docs/02-design/tokens.css b/docs/02-design/tokens.css new file mode 100644 index 0000000..f8ad247 --- /dev/null +++ b/docs/02-design/tokens.css @@ -0,0 +1,156 @@ +/* + * SIOP V2 — Design tokens (source de vérité visuelle) + * Importé tel quel par apps/web ; les maquettes HD l'utilisent aussi. + * Règle : AUCUNE valeur visuelle codée en dur hors de ce fichier. + * Thèmes : clair par défaut, sombre via @media + surcharge [data-theme]. + */ + +:root { + /* ——— Marque ——— */ + --primaire: #1f4fb8; /* bleu-treuil : actions, liens, focus */ + --primaire-actif: #1a439c; + --primaire-doux: #eaf0fb; /* fonds de sélection/hover primaires */ + --safran: #dd8a0b; /* accent de marque — parcimonieux */ + --safran-doux: #fdf3e3; + + /* ——— Neutres (acier, biais froid) ——— */ + --fond: #f5f7fa; + --surface: #ffffff; + --surface-2: #eef2f7; /* en-têtes de table, zones repliées */ + --bordure: #dce3ec; + --bordure-forte: #b9c4d4; + --encre: #1b2534; /* texte principal */ + --encre-2: #55647a; /* texte secondaire */ + --encre-3: #8494ab; /* placeholder, désactivé */ + + /* ——— Statuts OT (réservés) ——— */ + --st-ouvert: #3d6fe0; --st-ouvert-fond: #e9effc; + --st-encours: #6d5bd8; --st-encours-fond: #efecfa; + --st-attente: #b96f07; --st-attente-fond: #fbf1df; + --st-termine: #178a50; --st-termine-fond: #e6f5ec; + --st-annule: #68788f; --st-annule-fond: #edf0f4; + + /* ——— Priorités (réservées) ——— */ + --prio-bloque: #d92626; --prio-bloque-fond: #fdeaea; /* personne bloquée */ + --prio-haute: #d92626; + --prio-moyenne: #b96f07; + --prio-basse: #178a50; + --prio-aucune: #8494ab; + + /* ——— Sémantique générale ——— */ + --succes: #178a50; + --alerte: #b96f07; + --danger: #d92626; + --info: #3d6fe0; + + /* ——— Palette graphique (analytics, ordre FIXE, validée CVD) ——— */ + --graf-1: #3b69d6; + --graf-2: #dd8a0b; + --graf-3: #1f9e8e; + --graf-4: #8a63d2; + --graf-grille: #e6ebf2; + + /* ——— Typographie ——— */ + --police-ui: "Manrope", "Avenir Next", "Segoe UI Variable", system-ui, sans-serif; + --police-mono: "SF Mono", ui-monospace, "Cascadia Mono", monospace; + --t-11: 11px; --t-12: 12px; --t-13: 13px; --t-14: 14px; + --t-16: 16px; --t-20: 20px; --t-24: 24px; --t-32: 32px; + + /* ——— Forme & espace (grille 4 px) ——— */ + --e-1: 4px; --e-2: 8px; --e-3: 12px; --e-4: 16px; --e-5: 20px; --e-6: 24px; --e-8: 32px; + --rayon: 10px; /* cartes */ + --rayon-controle: 8px; /* inputs, boutons */ + --rayon-pastille: 999px; + --ombre-menu: 0 8px 24px rgb(16 30 54 / 0.14); + --rail: 3px; /* motif signature : rail actif safran */ + + /* ——— Mouvement ——— */ + --transition: 140ms ease-out; +} + +/* ——— Thème sombre (« machinerie de nuit », pas une inversion) ——— */ +@media (prefers-color-scheme: dark) { + :root { + --primaire: #6e92e8; + --primaire-actif: #8facf0; + --primaire-doux: #1d2c4c; + --safran: #e89a1f; + --safran-doux: #33270f; + + --fond: #0f1622; + --surface: #182234; + --surface-2: #1e2a40; + --bordure: #2b3850; + --bordure-forte: #3d4d6b; + --encre: #e8edf5; + --encre-2: #a7b4c8; + --encre-3: #6d7d96; + + --st-ouvert: #7da2ee; --st-ouvert-fond: #1c2a47; + --st-encours: #a394ec; --st-encours-fond: #262040; + --st-attente: #e0a33c; --st-attente-fond: #322510; + --st-termine: #4bc084; --st-termine-fond: #12301f; + --st-annule: #93a3ba; --st-annule-fond: #222d3f; + + --prio-bloque: #f26d6d; --prio-bloque-fond: #3a1414; + --prio-haute: #f26d6d; + --prio-moyenne: #e0a33c; + --prio-basse: #4bc084; + --prio-aucune: #6d7d96; + + --succes: #4bc084; + --alerte: #e0a33c; + --danger: #f26d6d; + --info: #7da2ee; + + --graf-1: #5580e4; + --graf-2: #c7820a; + --graf-3: #26a896; + --graf-4: #9673de; + --graf-grille: #24304a; + + --ombre-menu: 0 8px 24px rgb(0 0 0 / 0.45); + } +} + +/* Le sélecteur de thème de l'app doit GAGNER dans les deux sens. */ +:root[data-theme="light"] { + --primaire: #1f4fb8; --primaire-actif: #1a439c; --primaire-doux: #eaf0fb; + --safran: #dd8a0b; --safran-doux: #fdf3e3; + --fond: #f5f7fa; --surface: #ffffff; --surface-2: #eef2f7; + --bordure: #dce3ec; --bordure-forte: #b9c4d4; + --encre: #1b2534; --encre-2: #55647a; --encre-3: #8494ab; + --st-ouvert: #3d6fe0; --st-ouvert-fond: #e9effc; + --st-encours: #6d5bd8; --st-encours-fond: #efecfa; + --st-attente: #b96f07; --st-attente-fond: #fbf1df; + --st-termine: #178a50; --st-termine-fond: #e6f5ec; + --st-annule: #68788f; --st-annule-fond: #edf0f4; + --prio-bloque: #d92626; --prio-bloque-fond: #fdeaea; + --prio-haute: #d92626; --prio-moyenne: #b96f07; --prio-basse: #178a50; --prio-aucune: #8494ab; + --succes: #178a50; --alerte: #b96f07; --danger: #d92626; --info: #3d6fe0; + --graf-1: #3b69d6; --graf-2: #dd8a0b; --graf-3: #1f9e8e; --graf-4: #8a63d2; + --graf-grille: #e6ebf2; + --ombre-menu: 0 8px 24px rgb(16 30 54 / 0.14); +} +:root[data-theme="dark"] { + --primaire: #6e92e8; --primaire-actif: #8facf0; --primaire-doux: #1d2c4c; + --safran: #e89a1f; --safran-doux: #33270f; + --fond: #0f1622; --surface: #182234; --surface-2: #1e2a40; + --bordure: #2b3850; --bordure-forte: #3d4d6b; + --encre: #e8edf5; --encre-2: #a7b4c8; --encre-3: #6d7d96; + --st-ouvert: #7da2ee; --st-ouvert-fond: #1c2a47; + --st-encours: #a394ec; --st-encours-fond: #262040; + --st-attente: #e0a33c; --st-attente-fond: #322510; + --st-termine: #4bc084; --st-termine-fond: #12301f; + --st-annule: #93a3ba; --st-annule-fond: #222d3f; + --prio-bloque: #f26d6d; --prio-bloque-fond: #3a1414; + --prio-haute: #f26d6d; --prio-moyenne: #e0a33c; --prio-basse: #4bc084; --prio-aucune: #6d7d96; + --succes: #4bc084; --alerte: #e0a33c; --danger: #f26d6d; --info: #7da2ee; + --graf-1: #5580e4; --graf-2: #c7820a; --graf-3: #26a896; --graf-4: #9673de; + --graf-grille: #24304a; + --ombre-menu: 0 8px 24px rgb(0 0 0 / 0.45); +} + +@media (prefers-reduced-motion: reduce) { + :root { --transition: 0ms; } +} diff --git a/docs/journal/journal.md b/docs/journal/journal.md new file mode 100644 index 0000000..930c6ba --- /dev/null +++ b/docs/journal/journal.md @@ -0,0 +1,22 @@ +# Journal de bord — SIOP V2 + +Trace chronologique des sessions (la plus récente en premier). Le **playbook** (`docs/0X-*`) est le livre ; ici, c'est le quotidien. + +--- + +## 2026-07-15 — Pr. Daaif (+ Claude) — R0 : kickoff, vision, cadrage, design + +**Actions** + +- **Refondation décidée** : nouveau dépôt `siop-spelev/siop2`, 100 % nouveau code ; la v1 (`siop`) est gelée comme référence. Jalons R0→R5 créés. +- Playbook initialisé : **00-vision** (charte projet, personas, benchmark Atlas), **01-cadrage** (plan de releases avec DoD, user-story map, exigences non fonctionnelles mesurables, registre des risques). +- **02-design** : charte graphique (bleu-treuil / safran / acier, Manrope, motif « rail »), `tokens.css` (source de vérité, bi-thème), palettes analytics **validées par script** (CVD + contraste, modes clair et sombre), **maquettes HD** navigables (7 écrans : connexion + démo-login, tableau de bord, liste OT, fiche OT avec bilan codé, fiche ascenseur + QR, portail demandeur, mobile technicien) — publiées pour revue. + +**Décisions (référent, via questions)** + +- Diagnostic v1 : esthétique absente, docs éparpillées, périmètre dérivant, bascule de comptes pénible → V2 **design-first**, playbook en livre, releases fermées, **sélecteur de compte démo** (`DEMO_MODE`) dès R0. +- 100 % nouveau code ; périmètre v1 = web + mobile + IA par paliers ; déploiement Dokploy ; nom conservé : **SIOP**. + +**Prochaine étape** : validation de la charte + maquettes par le référent (**bloquant** — aucun code applicatif avant), puis 03-architecture + squelette monorepo. + +---