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