E-mail et téléphone deviennent obligatoires, et les silences parlent

[flocom]

Les trois promesses non tenues

L'un des deux contacts suffisait, et cela produisait trois défaillances silencieuses :

Promesse	Réalité
Le réglage « prévenir les inscrits »	Le cron filtrait sur isNotNull(email) — un inscrit sans adresse n'était jamais rappelé, sans trace
« Écrire aux bénévoles »	Ne joignait que les porteurs d'adresse, sans jamais compter les autres
« Vous désinscrire via le lien reçu par e-mail » (page Confidentialité)	Faux pour qui n'avait donné qu'un numéro : aucun moyen de se retirer

La règle

Les deux coordonnées sont désormais exigées, chacune pour une raison propre : l'e-mail porte la confirmation, le rappel et le lien de retrait ; le téléphone sert le jour même, quand personne ne lit ses courriels. Les formulaires l'expliquent au lieu d'exiger sèchement.

Elle s'applique partout où une inscription naît — formulaire bénévole public, réponse publique à une réunion, et l'outil MCP qui inscrit de vive voix. Sans ce dernier, un organisateur rouvrait le trou d'un appel.

Le téléphone est validé en comptant ses chiffres, pas en imposant un format : 06 12 34 56 78, 0612345678 et +33 6 98 76 54 32 sont le même numéro, et refuser l'un des trois ferait abandonner le formulaire. La fourchette 9–15 couvre le plan français comme la norme E.164.

Les inscriptions héritées

Celles d'avant la règle n'ont pas toujours d'adresse, et aucune migration ne peut leur en inventer une. On cesse donc de les traiter en silence :

• sous le créneau : « Sans e-mail : ne recevra ni rappel, ni lien de désinscription. Prévenez-la par téléphone. » — le numéro est juste au-dessus, la panne devient un coup de fil ;
• la diffusion répond « Message envoyé à 5 destinataire(s). 2 inscrit(s) sans adresse e-mail n'ont pas pu être joints : appelez-les. » ;
• le cron rend volunteersSansEmail et l'écrit au journal ;
• la page Confidentialité dit quoi faire quand on n'a reçu aucun message.

Vérifications sur instance réelle

API inscription — refus champ par champ, rien n'entre en base :

Saisie	Réponse
ni e-mail ni téléphone	{"email":["Required"],"phone":["Required"]}
e-mail seul	{"phone":["Required"]}
téléphone seul	{"email":["Required"]}
0612	{"phone":["Numéro de téléphone incomplet"]}
06 12 34 56 78 / +33 6 98 76 54 32 / 0612345678	{"ok":true} — les trois en base

Formulaire public — les cinq champs sont requis (slotId, name, email, phone, consent), la validation native bloque avant tout envoi, et une soumission complète arrive en base avec ses deux coordonnées.

Présences publiques — mêmes règles, mêmes refus, {"ok":true} seulement avec les deux.

Diffusion — {"sent":5,"sansEmail":2}, et le message le dit à l'expéditeur.

Cron — {"volunteerReminders":5,"volunteersSansEmail":2} + avertissement au journal.

Rendu — bandeaux d'alerte à 8,04:1, aucun débordement de 320 à 1280 px. tsc, eslint --max-warnings=0, build : verts.

Ce que ça change pour l'existant

Aucune migration : la colonne phone reste nullable, parce que les lignes héritées en dépendent. La contrainte est posée à la validation, là où naissent les nouvelles inscriptions. Rien n'est supprimé, rien n'est réécrit rétroactivement.

Un effet de bord à connaître : un parent qui refusait de donner son téléphone ne pourra plus s'inscrire seul. C'est le prix assumé de pouvoir tenir les trois promesses ci-dessus — et l'organisateur garde l'outil MCP pour l'inscrire à la main s'il a ses deux coordonnées par ailleurs.

🤖 Generated with Claude Code

https://claude.ai/code/session_014SfQYBU4xXTeSEHKhHQXdD

---

Generated by Claude Code