mirror of
https://github.com/siop-spelev/siop2.git
synced 2026-08-08 12:41:54 +00:00
04e61056f6
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>
3.6 KiB
3.6 KiB
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 (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)
- IA (R5) : assistant RAG citant ses sources (notices, historiques), aide à la saisie du bilan ; principe « l'IA propose, l'humain valide ».
- 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.
- 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.