Socle Composable

Accès, rôles & invitations

Deux niveaux de maturité documentés : porte simple (mot de passe partagé + cookie HMAC) pour démo/v1, et modèle NOMINATIF sur invitation (le seul valable en production avec données réelles).

Construit à partir de :

tourisme-backofficeStudio BellezaRDC backoffice

Dans le back office

Équipe (page BO) : comptes nominatifs, rôles lecture < moniteur < gérant, habilitations sensibles SÉPARÉES du rôle (acces_sante), désactivation jamais suppression (actions au journal).

Pages & écrans

Page / zone	Rôle
`/acces`	Connexion v1 : mot de passe partagé → cookie HMAC signé, expiration, compteur de blocage affiché
`/equipe`	Comptes nominatifs + invitations obligatoires : trigger = inscription sans invitation ne voit JAMAIS rien ([])
`matrice droits`	lecture < moniteur (assigner, valider/envoyer, interrupteur IA) < gérant (règles, équipe, journal, canaux, RGPD)

Patterns UI/UX

Rate-limit fenêtre glissante en mémoire process (assumé pm2-restart)
Session et mutation : chaque Server Action re-vérifie le cookie dans son corps, tenant résolu côté serveur JAMAIS en paramètre

Composants clés

lib/admin-auth.ts
gestes juridictionnels (refus silencieux mesuré en test)

Intelligence artificielle

Rôle IA: Un compte lecture-seule peut consulter l'agent mais PAS proposer (droits, pas consigne).
Modèles: —
Garde-fous: —

Données

equipe/comptes (role, acces_sante)
invitations
sessions/cookies HMAC

Invariants & pièges

CRITIQUE : Le mot de passe partagé est un défaut CONNU des v1 : le contrat type RDC exige désormais 1 compte par personne + droits distincts + journal horodaté
Une clé d'API n'est PAS un accord client : deux verrous distincts (voir module Agent IA)