Rappels d'événement

Les événements du calendrier ne restent utiles que lorsque les gens y assistent. Les rappels transforment le calendrier en une poussée — un message WhatsApp la veille de la retraite des jeunes, un e-mail le matin de la réunion des leaders, un SMS une heure avant le début de l'appel de prière.

Les rappels ne sont pas configurés par événement. Ils sont configurés une fois par organisation, et chaque événement avec une date future et un canal correspondant passe par le même pipeline.

Comment fonctionne la configuration

Il y a exactement une ligne event_reminder_config par org. Ouvrez Paramètres → Rappels pour la modifier.

event_reminder_config(
  id, organization_id, is_enabled,
  reminder_offsets_hours integer[],
  channel_slugs text[],
  title_template text,
  body_template text,
  created_at, updated_at
)

Deux tableaux font le travail :

• reminder_offsets_hours — quand envoyer. {24} est un seul rappel 24 heures avant l'événement. {24, 1} est deux rappels : la veille et une heure avant. {168, 24, 1} est trois rappels : une semaine avant, la veille et une heure avant.
• channel_slugs — comment envoyer. Choisissez parmi email, sms, whatsapp, push, in_app. La valeur par défaut est {push, in_app} qui ne vous coûte jamais de crédits de message.

Les deux tableaux se multiplient. Si reminder_offsets_hours = {24, 1} et channel_slugs = {email, whatsapp}, chaque événement déclenche quatre notifications : un e-mail et un message WhatsApp 24 heures avant, puis à nouveau une heure avant.

Sémantique d'envoi X heures avant

Les décalages sont des heures absolues, pas « le matin de » ou « la veille ». Un décalage de 24 heures pour un événement à 19h le dimanche envoie à 19h le samedi — pas à 9h le dimanche matin. Si vous voulez des rappels le matin même, réglez le décalage sur à peu près l'écart entre le matin et l'heure de l'événement (10–12 heures pour un événement du dimanche soir).

Quelques motifs courants :

Cas d'usage	Décalages
Rappel de veille uniquement	{24}
Veille + heure avant	{24, 1}
Semaine avant + veille pour grands événements	{168, 24}
Appel de prière juste à temps	{0.25} (15 min — mais entier uniquement, alors utilisez 1)

WARNING

La colonne est integer[]. Les décalages inférieurs à l'heure ne sont pas pris en charge. Arrondissez à la hausse — un décalage de 0 heure entrerait en concurrence avec l'événement lui-même.

Canaux

Chaque slug de canal correspond au canal configuré dans vos paramètres Messaging. Pour envoyer des rappels WhatsApp, il vous faut un canal WhatsApp actif configuré sous Messaging → Canaux ; pour envoyer des SMS, un canal SMS ; pour envoyer des e-mails, un canal e-mail.

Si un slug de canal est dans la configuration mais qu'aucun canal fonctionnel n'existe pour lui, le rappel pour ce slug échoue silencieusement. Les autres canaux partent quand même. Surveillez l'écran Notifications → Journaux si les rappels deviennent silencieux — les canaux échoués y apparaissent avec la raison de l'échec.

Les deux canaux gratuits méritent d'être soulignés :

• push — notifications push navigateur et PWA. Les membres qui ont installé l'app ou se sont abonnés dans leur navigateur les reçoivent sans dépenser de crédits de message.
• in_app — notifications de l'icône cloche. Visibles à toute personne qui se connecte.

La plupart des orgs utilisent {push, in_app, whatsapp} — push pour la portée à bas coût, WhatsApp pour les gens qui n'ont pas installé l'app.

Modèles de titre et de corps

Deux champs texte portent le texte du rappel :

• title_template — par défaut Upcoming: .
• body_template — par défaut on at .

Variables disponibles dans les deux modèles :

• — le titre de l'événement (ou le titre de remplacement d'une exception).
• — formatée dans le fuseau horaire de l'org.
• — l'heure de début, ou vide si l'événement n'en a pas.
• — préfixé par « at » lorsqu'il est présent, sinon vide.

Gardez les titres courts — les SMS et les push limitent les caractères visibles. Le corps peut être plus long pour l'e-mail et WhatsApp.

Déduplication

Les événements récurrents se répètent. Sans déduplication, vous enverriez le même rappel une fois par occurrence par décalage par canal — rapidement des milliers de messages. La table event_reminders_sent empêche cela :

event_reminders_sent(
  id, event_id, occurrence_date,
  organization_id, channel_slug, offset_hours,
  sent_at
)

Le cron qui dispatche les rappels vérifie (event_id, occurrence_date, channel_slug, offset_hours) contre cette table avant d'envoyer. Si la ligne existe, le rappel est sauté. Si elle n'existe pas, le rappel part et la ligne est insérée dans la même transaction.

L'implication : modifier un événement récurrent ne renvoie pas les rappels déjà envoyés, et relancer le cron après un échec ne double-enverra pas ceux qu'il a déjà réussis.

Désactiver les rappels

Mettez is_enabled = false sur la ligne de configuration et le cron saute votre org entièrement. Utile quand vous amorcez une org de test, migrez depuis une autre plateforme ou testez la création d'événements sans spammer vos membres.

Vous pouvez aussi désactiver les rappels par canal en retirant le slug de channel_slugs. Retirer whatsapp en milieu de semaine signifie que la prochaine passe de rappels saute WhatsApp pour tout le monde, même pour les événements déjà planifiés.

Ce qui reçoit un rappel

Chaque événement non supprimé avec une occurrence future à l'intérieur du prochain décalage planifié reçoit un rappel. Cela inclut :

• Les événements ponctuels dont la event_date est dans le futur.
• Chaque occurrence future d'un événement récurrent, étendue à partir de la RRULE.
• Les événements qui tombent sur une date avec un remplacement — le rappel utilise le titre, l'heure et le lieu du remplacement.
• Les événements que l'exception n'a pas annulés. Les occurrences annulées sont sautées.

Les anniversaires ne passent pas actuellement par event_reminder_config — ils ont un déclencheur de workflow séparé dans le module messaging.