Files
siop2/docs/03-architecture/adr/ADR-002-demo-login.md
2026-07-15 21:26:27 +01:00

35 lines
1.9 KiB
Markdown

# ADR-002 — Sélecteur de compte de démonstration (`DEMO_MODE`)
- **Statut** : acceptée (R0, 15 juillet 2026)
- **Contexte** : demande explicite du référent après la v1 — tester avec plusieurs rôles
obligeait à se déconnecter/reconnecter sans cesse, en local comme sur l'instance en ligne.
C'est aussi un besoin de **démonstration commerciale** (montrer chaque persona en 1 clic).
## Décision
1. Une variable d'environnement **`DEMO_MODE`** (`true`/absent) contrôle le mode démo,
côté API **et** côté web (`VITE_DEMO_MODE` injectée au build ou servie par `/auth/demo-accounts`).
2. Quand `DEMO_MODE=true` :
- `GET /auth/demo-accounts` (**publique**) liste les comptes de démonstration seedés
(id, nom, rôle, initiales — jamais de secret) ;
- `POST /auth/demo-login { userId }` (**publique**) émet un JWT pour ce compte **sans
mot de passe** — uniquement pour les comptes marqués `isDemo=true` en base ;
- le web affiche la liste sur l'écran de connexion **et** un sélecteur dans la topbar
(bascule instantanée, marquage visuel « DÉMO » safran permanent).
3. Quand `DEMO_MODE` est absent/faux : **les deux routes n'existent pas** (404 — le module
n'est pas enregistré), le web n'affiche rien. Test e2e dédié qui vérifie le 404.
## Sécurité
- Le danger réel est un `DEMO_MODE=true` oublié en production. Parades : (a) le module
refuse de démarrer si `DEMO_MODE=true` **et** `NODE_ENV=production` sauf si
`DEMO_MODE_I_KNOW=true` (double verrou explicite pour l'instance de démo publique) ;
(b) `isDemo` en base — un compte réel ne peut jamais être emprunté ; (c) bannière
« DÉMO » permanente dans l'UI.
- Critère d'acceptation (exigences) : passer d'Administrateur à Technicien en **< 3 s**.
## Conséquences
Le seed crée 7 comptes `isDemo` (un par rôle). Les environnements : dev local
(`DEMO_MODE=true`), démo en ligne (`true` + double verrou), production client (absent).