Identité et invitations

En-tête

Domaine	Identité & invitations — inscription, création d’établissement, invitation, acceptation, et les trois façons dont un lien meurt
Durée	~12 min
Niveau	complet
Étiquette	manuel — l’acceptation d’une invitation exige une seconde session et un aller-retour entre deux navigateurs

Préparation

Socle B, et c’est ce scénario qui le monte : jouez-le en premier de la recette complète, son résultat sert aux quinze suivants.

docker compose up -d postgres redis
cd packages/db && bun run db:migrate
cd ../.. && bun run dev

Deux navigateurs — un profil normal et une fenêtre privée. Aucun compte n’existe au départ, et aucune invitation Le lien envoyé à une personne pour qu'elle rejoigne votre établissement au lieu d'en fonder un nouveau. non plus.

1. Inscription et création d’établissement

Navigateur 1.

#	Action	Résultat attendu
1.1	Ouvrir http://localhost:3000	la carte « Connexion », sous-titrée « Accédez à l’espace de planification de votre établissement. »
1.2	« Créer un compte »	« Créer votre compte », sous-titré « Créez votre compte, puis créez ou rejoignez un établissement. »
1.3	Renseigner « Nom complet » = alice, un e-mail, un mot de passe, et « Nom de l’établissement » = « School A », valider	le compte est créé et l’accueil s’affiche : « Bienvenue, alice »
1.4	Regarder « Vos accès »	toutes les sections y sont, Administration comprise — la créatrice est administratrice
1.5	Se déconnecter, puis se reconnecter	l’accueil revient — la session s’ouvre normalement
1.6	Ouvrir /login en étant déjà connecté	le formulaire s’affiche : aucune redirection ne l’en empêche

2. Inviter

Toujours dans le navigateur 1, en alice.

#	Action	Résultat attendu
2.1	Administration → Utilisateurs	alice seule dans la liste
2.2	« Inviter »	« Inviter un membre », sous-titré « La personne rejoindra cet établissement grâce au lien d’invitation. »
2.3	Saisir l’e-mail de bob, « Envoyer l’invitation »	un lien copiable s’affiche, avec « Copier le lien »
2.4	Copier le lien	« Lien d’invitation copié. »
2.5	Fermer, regarder « Invitations en attente »	la ligne apparaît avec « Expire le … » — sept jours plus tard
2.6	Réinviter la même adresse	« Une invitation est déjà en attente pour cet e-mail. »
2.7	Inviter sa propre adresse	« Cette personne est déjà membre de l’établissement. »

3. Accepter

Navigateur 2, aucune session.

#	Action	Résultat attendu
3.1	Ouvrir le lien d’invitation	la page d’invitation s’affiche
3.2	« Créer un compte »	le formulaire d’inscription, sous-titré « Créez votre compte pour rejoindre votre établissement. » — sans champ d’établissement
3.3	Renseigner bob, valider	le compte est créé
3.4	Revenir sur le lien d’invitation	un bouton « Accepter l’invitation » — rien n’est automatique
3.5	Accepter	bob rejoint School A ; l’accueil s’affiche
3.6	Regarder « Vos accès »	seulement Mon planning et Mon espace — bob est membre sans aucun rôle applicatif
3.7	Navigateur 1 → Administration → Utilisateurs	bob apparaît, colonne « Rôles » = « Aucun rôle » ; l’invitation a quitté « Invitations en attente »

Le cas 3.6 est le résultat le plus important du scénario : accepter une invitation ne donne rien d’autre que l’appartenance. Les droits s’attribuent ensuite, et c’est l’objet du scénario RBAC et scoping.

4. Les trois façons dont un lien meurt

#	Action	Résultat attendu
4.1	Rouvrir le même lien avec bob, déjà membre	« Cette invitation est invalide, expirée ou a déjà été utilisée. »
4.2	Inviter dave, puis annuler l’invitation depuis « Invitations en attente », puis ouvrir le lien	même message
4.3	Une invitation vieille de plus de sept jours	même message — le produit ne distingue pas les trois cas

C’est délibéré : un message unique ne renseigne pas un tiers sur l’existence d’une adresse.

5. Le compte, une fois créé

Navigateur 2, en bob → Mon compte.

#	Action	Résultat attendu
5.1	Ouvrir Mon compte depuis le bouton portant son nom, en bas de la barre latérale	six cartes : profil, adresse, langue, notifications, mot de passe, sessions
5.2	Changer le « Nom complet », enregistrer	« Profil mis à jour. »
5.3	Changer de mot de passe avec deux saisies différentes	« Les deux mots de passe ne correspondent pas. »
5.4	Changer de mot de passe correctement	« Mot de passe mis à jour. Vos autres sessions ont été déconnectées. »
5.5	Regarder « Sessions actives »	l’appareil courant porte « Cet appareil »

Pièges connus

• Le champ « Nom de l’établissement » n’apparaît que sur une inscription libre. Une inscription depuis un lien d’invitation ne le propose pas : la personne rejoint, elle ne crée pas.
• L’acceptation est explicite. Ouvrir le lien ne suffit pas ; il faut cliquer. Une personne qui « a cliqué sur le lien » sans voir le bouton n’est pas membre.
• Un compte créé mais qui n’accepte jamais reste sans établissement. Il pourra se connecter plus tard avec un nouveau lien — l’ancien ne se réactive pas.

Le message dit qu'aucun e-mail n'est envoyé — c'est souvent faux

Après création, l’écran affiche systématiquement : « Aucun e-mail n’est envoyé — copiez ce lien et transmettez-le vous-même à la personne. »

Vérifié dans le code : un e-mail est bien envoyé dès qu’un service d’envoi est configuré sur l’installation. Le message décrit le cas de repli, pas le cas courant.

Pour la recette : le cas 2.3 ne doit pas être considéré comme un échec si la personne reçoit aussi un e-mail. Le seul cas gênant est l’inverse : sur une installation sans service d’envoi, une invitation créée sans transmettre le lien ne parviendra jamais à son destinataire, et rien ne le signalera.

Le réflexe : copiez le lien de toute façon.

Ce scénario enchaîne assez de requêtes d’authentification pour déclencher le limiteur de débit — un refus muet qui n’a rien à voir avec vos identifiants. Il est décrit une fois pour toutes sur Les pièges connus.

Traçabilité

Ce qui est couvert	Story	Vue
Invitations, expiration à sept jours, acceptation explicite	(hors story — docs/invitations.md)	—
Inscription, création d’établissement, session	STORY-002	—
Rôle applicatif distinct de l’appartenance	STORY-004	V60
Écran de compte, mot de passe, sessions	STORY-020	—

Couvert par les tests automatisés : apps/api/src/auth/invitations.e2e.spec.ts, apps/api/src/auth/auth-tenant.e2e.spec.ts, apps/api/src/auth/account.e2e.spec.ts. Le cycle de vie d’une invitation et l’isolation à l’inscription y sont couverts ; le parcours à deux navigateurs et l’acceptation explicite ne le sont pas.

Checklist

• Inscription avec « Nom de l’établissement » → « Bienvenue, alice », Administration dans « Vos accès »
• « Inviter » → un lien copiable + « Lien d’invitation copié. »
• « Invitations en attente » → la ligne avec « Expire le … »
• Réinviter la même adresse → « Une invitation est déjà en attente pour cet e-mail. »
• S’inviter soi-même → « Cette personne est déjà membre de l’établissement. »
• Navigateur 2 : inscription depuis le lien → aucun champ d’établissement
• Retour sur le lien → « Accepter l’invitation », rien d’automatique
• Après acceptation → « Vos accès » ne contient que Mon planning et Mon espace
• Côté alice → bob apparaît avec « Aucun rôle »
• Lien déjà utilisé, ou annulé → « Cette invitation est invalide, expirée ou a déjà été utilisée. »
• Mon compte → changement de nom → « Profil mis à jour. »
• Mots de passe différents → « Les deux mots de passe ne correspondent pas. »
• Changement réussi → « Mot de passe mis à jour. Vos autres sessions ont été déconnectées. »

Écrans concernés

• Inscription, Connexion et Acceptation d'une invitation — les trois écrans publics traversés.
• Utilisateurs — l’invitation et son suivi.
• Mon compte — le bloc 5.
• Accueil — « Vos accès », qui rend les droits visibles.