Emails automatiques
TimePick envoie des emails transactionnels à des moments précis du cycle de vie d'un compte, d'un événement ou d'une réservation — jamais de newsletter ni d'envoi périodique. Chaque email correspond à un modèle (template_key en base de données) : neuf au total, déclenchés automatiquement par une action précise (un administrateur qui invite, un membre qui réserve, un créneau qui change…), sans aucune intervention manuelle au moment de l'envoi lui-même.
Cette fiche liste les neuf modèles, leur déclencheur exact et leur destinataire. Elle ne couvre pas :
- la personnalisation du contenu d'un modèle (en-tête, corps, pied, variables) — voir Guide administrateur — Éditeur d'emails ;
- la configuration du serveur d'envoi (SMTP) — voir Configuration SMTP par fournisseur et Paramètres in-app.
Vue d'ensemble
| Modèle (nom dans l'éditeur) | template_key | Destinataire | Éditable |
|---|---|---|---|
| Invitation | invitation | Membre invité à un événement | Oui — coque + contenu, par modèle et par événement |
| Connexion | magic_link_login | Personne qui demande une connexion | Oui — système |
| Confirmation | reservation_confirmation | Membre qui vient de réserver | Oui — système |
| Création de compte | account_created | Compte nouvellement créé | Oui — système |
| Annulation | cancellation_confirmation | Inscrits d'un créneau annulé par un admin | Oui — système |
| Désinscription | unregistration_confirmation | Membre qui s'est désinscrit lui-même | Oui — système |
| Promotion admin | role_promoted | Membre promu administrateur | Oui — système |
| Retour membre | role_demoted | Ex-administrateur rétrogradé membre | Oui — système |
| (sans nom — non éditable) | slot_modification | Inscrits d'un créneau modifié | Non, dynamique |
Huit modèles éditables, un modèle dynamique
Les huit premiers modèles se personnalisent depuis Paramètres → Modèle d'email (coque commune + contenu, avec héritage marque → modèle → événement pour l'invitation) : voir Guide administrateur — Éditeur d'emails. Le neuvième, « Modification de créneau », n'apparaît pas dans ce sélecteur.
Déclencheurs détaillés
Invitation et connexion
Invitation (invitation) part quand un administrateur envoie ou renvoie une invitation à un événement, depuis l'onglet Invitations de l'événement :
- envoi initial à un ou plusieurs membres sélectionnés ;
- renvoi individuel à un membre déjà invité ;
- renvoi groupé à tous les invités qui n'ont pas encore répondu depuis plus de 3 jours.
Les trois actions passent par le même mécanisme d'envoi et intègrent un lien de connexion valable pour la durée fixée pour cet événement — voir Invitations pour le détail du parcours et des statuts.
Connexion (magic_link_login) part à chaque demande de lien de connexion aboutie : formulaire de connexion public (email seul, sans mot de passe), renvoi d'un lien de connexion expiré en dehors du contexte d'un événement précis, ou création du tout premier administrateur pendant l'assistant d'installation. Le contenu varie légèrement selon que le destinataire est administrateur ou membre, mais reste le même modèle.
Réservation, désinscription et annulation
Confirmation (reservation_confirmation) part quand un membre réserve un créneau, depuis le calendrier public ou la vue d'un événement — récapitulatif de la date et de l'horaire réservés.
Désinscription (unregistration_confirmation) part quand un membre annule lui-même sa propre réservation.
Annulation (cancellation_confirmation) part quand un administrateur annule un créneau qui compte au moins un inscrit. Dans ce cas, le créneau n'est pas supprimé mais horodaté « annulé » (il reste visible, marqué comme tel, dans le planning des inscrits) ; chacun d'entre eux reçoit cet email. Un créneau sans aucun inscrit est en revanche supprimé silencieusement, sans email.
Désinscription vs Annulation : qui a pris l'initiative
Les deux modèles couvrent le même résultat visible pour le membre (le créneau disparaît de son planning), mais la distinction tient à qui a agi : le membre lui-même reçoit « Désinscription », les inscrits d'un créneau annulé par un administrateur reçoivent « Annulation ».
Compte et rôle
Création de compte (account_created) part quand un compte est créé avec l'envoi explicitement demandé :
- création manuelle d'un utilisateur, case Envoyer un email d'invitation cochée (cochée par défaut) ;
- import d'une liste CSV, case Envoyer une invitation par e-mail aux nouveaux membres cochée (décochée par défaut).
Ce modèle contient un lien vers la page de connexion classique, sans jeton de connexion directe — le nouveau compte se connecte ensuite normalement via l'email « Connexion ».
Promotion admin (role_promoted) et Retour membre (role_demoted) partent quand un administrateur change le rôle d'un utilisateur, avec la case Notifier le membre du changement de rôle par email cochée (cochée par défaut). Le modèle de promotion peut inclure un lien de connexion directe si sa génération a réussi ; le modèle de rétrogradation renvoie vers la page de connexion classique, sans jeton (l'ancien administrateur redevient un membre comme un autre).
Modification de créneau — le seul modèle dynamique
Modification de créneau (slot_modification) diffère structurellement des huit autres : son corps n'est pas un texte enregistré en base que l'éditeur permettrait de modifier, mais un contenu calculé à chaque envoi à partir de la différence entre l'ancien et le nouveau créneau (horaire de début, horaire de fin, description). Un administrateur qui avance un créneau d'une heure et modifie sa description voit les deux changements listés dans l'email sous la forme « avant → après » ; s'il ne touche qu'à l'horaire, seul ce champ apparaît.
Conditions d'envoi, depuis le formulaire de modification d'un créneau :
- au moins un des trois champs suivis (horaire de début, horaire de fin, description) doit changer — un renommage d'événement ou un changement de capacité n'en fait pas partie ;
- le créneau doit compter au moins un inscrit ;
- le switch Notifier les N inscrits, activé par défaut, ne doit pas avoir été désactivé pour cette modification.
Pas de page dédiée dans l'éditeur
Ce modèle n'ayant pas d'écran dans Paramètres → Modèle d'email, il ne peut ni être prévisualisé ni faire l'objet d'un envoi de test avant qu'une vraie modification de créneau ne le déclenche. Sa coque visuelle (en-tête, pied, identité visuelle) suit malgré tout la même cascade marque → modèle que les autres modèles système.
Ce que reçoit un membre au fil d'un parcours type
Pour situer ces neuf modèles les uns par rapport aux autres, voici la séquence d'emails reçus par un membre qui suit le parcours le plus courant — invitation, réservation, puis désinscription :
- Invitation. Un administrateur ajoute le membre aux destinataires d'un événement et envoie les invitations : le membre reçoit l'email « Invitation ».
- Connexion (selon le parcours). Si le lien d'invitation a expiré ou si le membre passe par le formulaire de connexion classique, il reçoit un email « Connexion » distinct, à durée de vie généralement plus courte.
- Confirmation. Une fois connecté, le membre réserve un créneau : il reçoit l'email « Confirmation ».
- Modification de créneau (éventuel). Si un administrateur modifie ensuite l'horaire ou la description de ce créneau sans désactiver la notification, le membre reçoit l'email dynamique « Modification de créneau ».
- Désinscription ou Annulation. Si le membre se désinscrit lui-même, il reçoit « Désinscription » ; si c'est l'administrateur qui annule le créneau, il reçoit « Annulation » à la place.
Les trois modèles restants (Création de compte, Promotion admin, Retour membre) ne s'inscrivent pas dans ce parcours de réservation : ils accompagnent des actions administratives sur le compte du membre, indépendantes de tout événement précis.
Duplication d'un événement
Dupliquer un événement ne recopie ni ses créneaux ni la liste de ses invités — la copie créée est un brouillon vide, sans date d'ouverture. Aucun email n'est donc envoyé au moment de la duplication elle-même ; les invitations repartent normalement une fois la copie complétée et publiée.
Tous les envois passent par le SMTP configuré
Quel que soit le déclencheur, le rendu de l'email (HTML et texte brut, coque et contenu) suit le même moteur interne ; seule la remise diffère selon la configuration active. Un modèle correctement rendu mais dont l'envoi échoue (SMTP mal configuré, fournisseur indisponible) ne bloque jamais l'action métier qui l'a déclenché : la réservation, l'annulation ou la création de compte reste effective, et l'échec d'envoi est seulement journalisé côté serveur. Voir Configuration SMTP par fournisseur pour le choix et la configuration du serveur d'envoi, et Délivrabilité email pour les réglages qui améliorent les chances d'arriver en boîte de réception plutôt qu'en spam.
Vérifier l'état du serveur d'email sans déclencher de parcours réel
L'endpoint GET /health renvoie un statut services.smtp (ok ou en échec), utilisable pour un contrôle de supervision indépendant de tout envoi réel — voir Dépannage.
Tester un modèle sans déclencher le parcours réel
Chacun des huit modèles éditables dispose d'un bouton d'envoi de test dans l'éditeur, qui envoie l'email à une adresse choisie sans passer par le parcours métier réel (pas de réservation créée, pas de compte modifié, pas de rôle changé) — pratique pour vérifier le rendu ou la configuration SMTP sans action à annuler ensuite. Voir Guide administrateur — Éditeur d'emails. Le modèle slot_modification, sans page dans l'éditeur, n'est pas concerné par ce bouton de test.
Repères techniques (code source)
Pour qui souhaite vérifier ou faire évoluer un déclencheur, chaque modèle correspond à une fonction d'envoi unique dans le code serveur :
template_key | Fonction d'envoi | Appelée depuis |
|---|---|---|
invitation | sendEventInvitation | invitations.service.ts |
magic_link_login | sendAdminMagicLinkEmail / sendUserMagicLinkEmail | auth.controller.ts |
reservation_confirmation | sendReservationEmail | reservation.service.ts |
account_created | sendWelcomeInvitation | admin.controller.ts |
cancellation_confirmation | sendSlotCancellationEmail | slot.service.ts |
unregistration_confirmation | sendUnregistrationEmail | reservation.service.ts |
role_promoted / role_demoted | sendRoleChangedEmail | admin.controller.ts |
slot_modification | sendSlotModificationEmail | slot.service.ts |
Toutes ces fonctions passent ensuite par un point d'entrée unique, renderEmail(), qui résout la coque (marque/modèle/événement) et compile le HTML — voir render-email.service.ts. La liste des neuf template_key autorisés provient de la migration 006_email_refactoring.sql et de son évolution 025_add_slot_modification_email_template.sql, qui a ajouté slot_modification en dernier.
Voir aussi
- Guide administrateur — Éditeur d'emails — personnalisation du contenu des huit modèles éditables.
- Identité visuelle des emails — logo, couleurs et police, communs à tous les envois.
- Invitations — détail du parcours d'invitation à un événement.
- Utilisateurs — création de compte, promotion et rétrogradation de rôle.
- Configuration SMTP par fournisseur — configuration du serveur d'envoi.
- Délivrabilité email — SPF, DKIM, DMARC, réputation d'envoi.
- Dépannage — diagnostiquer un email non reçu.