Notifications

En-tête

Domaine	Notifications — la cloche, les producteurs réels, les préférences, l’e-mail et le rappel
Durée	~12 min
Niveau	complet
Étiquette	manuel — le fan-out en direct exige deux navigateurs, et le rappel différé demande d’attendre une minute réelle

Préparation

Socle B. Le montage est sur la préparation commune.

Comptes : alice (l’acteur, qui déclenche) et bob (le destinataire, qui reçoit). Les deux connectés, dans deux navigateurs.

Redis doit tourner. Les envois d’e-mail et les rappels passent par une file ; sans Redis, les notifications Le message qui prévient une personne de ce qui la concerne — une demande à traiter, un emploi du temps qui a changé. in-app apparaissent mais rien d’autre n’est traité.

docker compose ps          # postgres et redis doivent être « running »

Aucune configuration d’e-mail n’est nécessaire : sans clé d’envoi, les messages sont journalisés côté API au lieu d’être expédiés. Gardez un œil sur les journaux de l’API pendant le scénario — c’est là que se vérifie le bloc 4.

1. La cloche

#	Action	Résultat attendu
1.1	bob se connecte	une cloche apparaît dans l’en-tête
1.2	Cliquer dessus, sans notification	« Aucune notification »
1.3	Après réception d’un événement (bloc 3)	un badge affiche le nombre de non-lues
1.4	Ouvrir le panneau	la liste, la plus récente en haut, chaque ligne portant le libellé de son type
1.5	Cliquer une notification	elle passe lue et le badge décrémente
1.6	« Tout marquer lu »	le badge disparaît
1.7	Déclencher assez d’événements pour dépasser une page, puis dérouler	« Voir plus » charge la suite sans doublon

2. Le fan-out en direct, isolé par utilisateur

#	Action	Résultat attendu
2.1	alice déclenche un événement destiné à bob (bloc 3)	sans rafraîchir, la cloche de bob s’incrémente
2.2	Regarder la cloche d’alice	elle ne bouge pas — la notification n’était pas pour elle

3. Les producteurs réels

C’est le bloc à jouer avec le plus d’attention, parce que la liste a changé depuis le plan d’origine.

#	Ce qu’on déclenche	Qui reçoit	Type attendu
3.1	alice réserve une salle en confirmation immédiate	alice	« Réservation confirmée »
3.2	alice annule une réservation confirmée	alice	« Réservation annulée »
3.3	bob soumet une demande, alice valide	bob	« Demande approuvée »
3.4	bob soumet une demande, alice refuse avec motif	bob	« Demande refusée »
3.5	bob soumet une demande, alice propose une alternative	bob	« Alternative proposée »
3.6	alice publie un périmètre de planning	les enseignants des cours touchés, et les étudiants liés	« Planning publié »
3.7	bob soumet une demande — et rien d’autre	personne	aucune notification : une demande créée ne notifie pas, c’est la décision qui notifie

Ce qui n’a pas de producteur : « Réservation modifiée », « Séance déplacée » et « Séance annulée » figurent au catalogue interne mais ne sont émis par personne. Ne les attendez pas, et ne les cherchez pas dans la matrice de préférences — ils n’y sont pas.

Le plan de test d'origine dit que « Planning publié » n'est pas produit — c'est devenu faux

docs/notifications-test-plan.md §4 annonce que planning.published est « au catalogue mais non produit en V1 ». Cette phrase n’est plus vraie.

Vérifié dans apps/api/src/occupancy/planning-workflow.service.ts : une publication appelle bien l’envoi de notification avec ce type, et l’écran des préférences le liste parmi les sept types réglables.

Conséquence pour la recette : le cas 3.6 doit passer. S’il ne passe pas, c’est un vrai défaut, pas une fonctionnalité à venir — c’est exactement l’inverse de ce que le plan d’origine laisse croire.

Le fichier de docs/ n’a pas été modifié : il reste la documentation de conception, et l’écart a été signalé à ses mainteneurs.

4. Les préférences

Compte bob → Mon compte → carte « Notifications ».

#	Action	Résultat attendu
4.1	Ouvrir la carte	une matrice type × canal — « In-app », « E-mail », « Push » — avec sept types listés
4.2	Sans avoir rien réglé	tous les interrupteurs sont actifs : l’absence de réglage vaut activé
4.3	Basculer une case	l’enregistrement est immédiat — il n’y a aucun bouton « Enregistrer »
4.4	Couper « In-app » pour « Réservation annulée », puis annuler une réservation	aucune ligne n’apparaît dans la cloche pour ce type
4.5	Réactiver, refaire l’annulation	la ligne réapparaît
4.6	Couper « E-mail » pour un type, déclencher l’événement	aucun envoi journalisé côté API pour ce type
4.7	Recharger la page	l’état des cases est conservé

5. L’e-mail

Sans clé d’envoi configurée, rien ne part sur le réseau : les messages sont journalisés.

#	Action	Résultat attendu
5.1	Déclencher un événement dont le canal e-mail est actif	un envoi apparaît dans les journaux de l’API : destinataire, sujet, lien
5.2	Rejouer le même traitement	un seul envoi est journalisé — la livraison est idempotente

6. Le rappel de réservation

Le rappel est un traitement différé, planifié à la confirmation. Pour l’éprouver sans attendre vingt-quatre heures :

#	Action	Résultat attendu
6.1	Dans Mon compte, régler « Rappel avant réservation » sur « 1 heure avant »	le réglage est enregistré immédiatement
6.2	Créer une réservation confirmée commençant dans ~61 minutes	« Réservation confirmée. »
6.3	Attendre environ une minute	une notification « Rappel de réservation » arrive
6.4	Recommencer, puis annuler la réservation avant l’échéance	aucun rappel n’arrive : le traitement différé est retiré
6.5	Créer une réservation récurrente de trois occurrences	une notification de confirmation, et trois rappels planifiés

Le délai est figé à la planification : changer la préférence après coup ne s’applique pas aux rappels déjà programmés.

7. Le canal Push

La colonne « Push » existe et ses interrupteurs fonctionnent, mais aucun écran ne propose d’autoriser les notifications sur un appareil.

#	Action	Résultat attendu
7.1	Activer « Push » sur un type, déclencher l’événement	rien de visible — aucun appareil n’est enregistré, aucun envoi n’est tenté
7.2	Chercher un bouton d’activation dans l’application	il n’y en a pas

Ce n’est pas un réglage cassé : c’est un réglage en avance sur sa fonctionnalité. Le détail est sur Mon compte.

8. La résilience

#	Action	Résultat attendu
8.1	Arrêter Redis (docker compose stop redis), puis créer une réservation confirmée	« Réservation confirmée. » — l’action métier réussit, un incident de notification ne la casse jamais
8.2	Redémarrer Redis	le service repart ; les envois suivants reprennent

Pièges connus

• Sans Redis, la cloche fonctionne mais rien d’autre. Les lignes in-app peuvent apparaître, les e-mails et les rappels ne partent pas. C’est le premier point à vérifier quand « les notifications ne marchent pas ».
• Une demande de réservation ne notifie pas à sa création. C’est la décision qui notifie. Le cas 3.7 vérifie une absence, et c’est le résultat attendu.
• La matrice ne liste que les types productibles. Un type absent de l’écran n’est pas un oubli d’affichage : il n’a pas de producteur.

Les pièges transverses — environnement, authentification, fraîcheur des données — sont rassemblés sur Les pièges connus.

Traçabilité

Ce qui est couvert	Story	Vue
Socle de notification, trois canaux, préférences	STORY-020	V04
Fan-out en direct par utilisateur	STORY-014	—
Producteurs de réservation et d’approbation	STORY-016, STORY-017	—
Producteur de publication	STORY-030, STORY-038	—
Socle push, sans interface	STORY-040	—

Couvert par les tests automatisés : apps/api/src/notifications/notifications.e2e.spec.ts. Le socle, les préférences et l’idempotence de livraison y sont couverts ; le fan-out en direct, le rappel différé et la résilience Redis coupé ne le sont pas.

Checklist

• Redis tourne — docker compose ps
• La cloche apparaît, « Aucune notification » au départ
• alice déclenche → sans rafraîchir, la cloche de bob s’incrémente ; celle d’alice ne bouge pas
• Réservation confirmée → « Réservation confirmée » chez le titulaire
• Décision d’approbation → « Demande approuvée » / « Demande refusée » / « Alternative proposée » chez le demandeur
• Publication d’un planning → « Planning publié » chez les enseignants et les étudiants liés
• Une demande créée → aucune notification
• Matrice de préférences : sept types, tous actifs par défaut, enregistrement immédiat
• Canal in-app coupé → aucune ligne pour ce type ; réactivé → elle revient
• Canal e-mail actif → un envoi journalisé côté API, une seule fois
• Rappel réglé sur 1 h, réservation dans ~61 min → « Rappel de réservation » une minute plus tard
• Réservation annulée avant l’échéance → aucun rappel
• Redis arrêté → la réservation est quand même confirmée

Écrans concernés

• Mon compte — la matrice de préférences et le délai de rappel.
• Réservations et Approbations — les producteurs d’événements.
• Publication du planning — le producteur du cas 3.6.
• Mon planning — ce que la notification de publication annonce.