siop2/docs/03-architecture/adr/ADR-002-demo-login.md

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