# 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.