Le formulaire de l’événement confirme l’envoi, mais l’équipe ne reçoit pas l’alerte

Cerner le formulaire et préserver le contact

Télécharger la fiche d’incident des alertes de formulaire (Markdown, en anglais)

Notez l’URL publiée, la langue et l’objet du formulaire : contact, intervenants, exposants, bénévoles ou questions d’accès. Indiquez quand le défaut a été remarqué, la boîte prévue et le message vu après l’envoi. Un écran de réussite ne prouve pas qu’une alerte est parvenue à l’équipe. Le W3C recommande un retour clair sur les succès et les erreurs ; le texte public doit rester fidèle à ce que le site sait confirmer.[1]

Si les demandes peuvent être urgentes, affichez un autre courriel ou téléphone approuvé et surveillé. Ne promettez pas de retrouver des messages encore introuvables et ne révélez aucun détail personnel dans une annonce d’incident. Désignez la personne qui suit cette voie de secours.

Vérifier que la demande a été conservée

Si votre équipe l’autorise, envoyez une seule demande synthétique clairement étiquetée depuis le formulaire en ligne, avec une adresse de test gérée et un texte anodin. Consignez heure, fuseau, URL, message de réussite ou d’erreur et identifiant éventuel. Cherchez cet enregistrement dans le bon formulaire, événement et intervalle du tableau de bord.

Sans enregistrement, faites examiner validation, destination et intégration par le responsable du site avant de modifier la messagerie. S’il existe, suivez la chaîne de notification. Confiez la recherche d’anciennes demandes non traitées à des personnes habilitées, sans diffuser les données dans un large fil de courriels.

Examiner la règle et le destinataire

Dans les réglages de ce formulaire ou événement, vérifiez que l’alerte interne est active, que le déclencheur correspond au dépôt et que l’adresse est exacte et encore surveillée. Distinguez un avis immédiat d’un récapitulatif différé. Si la règle dépend d’une réponse, d’un statut ou de la langue, suivez la branche du test et contrôlez la configuration publiée plutôt qu’un brouillon.

L’accusé au visiteur et l’alerte interne sont deux circuits. Wix Forms, par exemple, utilise une automatisation pour choisir les destinataires des notifications de formulaire ; par défaut, l’avis va à l’adresse du propriétaire du site. Ces réglages sont propres au fournisseur. Notez la règle d’origine, puis ne corrigez que la cause prouvée avec les options prises en charge.[4]

Suivre les états du service d’envoi

Demandez au responsable du site ou du service l’événement correspondant à l’heure ou à l’identifiant de test. Séparez tentative, mise en attente, acceptation, remise, rejet, rebond et suppression selon les libellés réels du fournisseur. « Accepté » ne veut pas dire « lu ». La référence WordPress `wp_mail()` précise qu’un résultat positif ne prouve pas la réception ; cela n’implique pas que tous les sites utilisent WordPress.[2]

Examinez séparément From et Reply-To. Si l’authentification échoue, faites comparer les en-têtes d’un exemple aux consignes actuelles du fournisseur par le responsable du domaine ou du courrier. Les règles de Gmail exigent SPF ou DKIM pour les messages envoyés aux comptes Gmail personnels (@gmail.com ou @googlemail.com) et ajoutent des conditions pour certains expéditeurs à fort volume. Ne modifiez ni SPF ni DMARC à l’aveugle : un test DNS ne garantit pas la présence en boîte de réception.[3]

Contrôler la boîte et la relève de l’équipe

Confirmez la boîte ciblée et la personne qui la consulte. Cherchez le sujet, l’expéditeur et l’heure du test dans tous les dossiers et la quarantaine gérée. Avec l’administration du courrier, examinez filtres, transferts, appartenance aux groupes et boîte désactivée ou pleine. L’état de remise du fournisseur ne prouve pas qu’un membre a vu le message. Essayez un second destinataire approuvé seulement si le système le permet sans risque, puis rétablissez la route normale.

L’aide de Wix Forms conseille de vérifier les dossiers indésirables et les destinataires de l’automatisation lorsqu’une notification manque. Appliquez ces contrôles à votre fournisseur sans supposer les mêmes menus, expéditeur ou modalités de remise. Si la boîte reçoit les autres messages mais pas cette alerte, revenez aux preuves de la règle et du service d’envoi.[4]

Recontrôler et clore l’incident

Après une correction ciblée, envoyez une nouvelle demande synthétique depuis l’URL publiée. Consignez la réponse du formulaire, l’enregistrement, la règle, l’événement du fournisseur et l’arrivée dans la bonne boîte. Sur téléphone et au clavier, vérifiez que le message d’état et le contact de secours restent utilisables. Gérez les données de test selon le processus interne.

Examinez la période sans alertes. Si les demandes sont conservées, assignez les réponses à des personnes habilitées ; ne présumez pas d’un renvoi automatique. Sinon, maintenez une voie de contact exacte et laissez le responsable décider d’une communication plus large. Notez l’heure de réparation, les formulaires touchés, les preuves, la surveillance et le prochain essai contrôlé.