Ton formulaire de contact affiche « envoyé », mais rien n’arrive

À qui s’adresse ce guide

Tu as un site avec un formulaire de contact ou de demande. Un visiteur le remplit et voit un message de remerciement, mais l’e-mail n’arrive jamais dans ta boîte. Ou tu soupçonnes que cela arrive à certains visiteurs, parce que quelqu’un t’a dit « Je t’ai écrit la semaine dernière » et que tu n’as rien vu.

Ce guide vaut pour WordPress, les créateurs de sites, et les sites codés à la main ou statiques. Les premiers contrôles ne demandent aucune connaissance technique. Les étapes suivantes touchent aux réglages DNS et au compte de messagerie ou d’hébergement : il te faudra peut-être la personne qui s’occupe de ton domaine.

Le trajet d’un message, et où il se perd

Un envoi de formulaire passe par plusieurs étapes, et le message de remerciement apparaît le plus souvent après la première :

• Le navigateur envoie le formulaire à un gestionnaire : une extension, un script sur ton serveur, une fonction serverless ou un service de formulaires externe.
• Le gestionnaire passe le message à un expéditeur d’e-mails : la messagerie intégrée de ton serveur, un compte SMTP ou un service d’envoi d’e-mails.
• L’expéditeur le transmet au serveur de messagerie du destinataire, qui l’accepte, le retarde, le refuse ou le met en quarantaine.
• Le message finit dans une boîte : la boîte de réception, le dossier spam ou, avec des règles de transfert, ailleurs.

La page de remerciement prouve seulement que la première étape a fonctionné. Tout ce qui suit peut échouer sans que ni toi ni le visiteur ne voyiez quoi que ce soit. C’est pourquoi la solution consiste à vérifier chaque étape tour à tour, plutôt qu’à deviner.

Comment savoir quelle cause s’applique

Fais d’abord le test de l’étape 1, puis compare avec ce que tu vois :

• Le test arrive dans les spams ou les indésirables. Le serveur destinataire ne fait pas confiance à l’expéditeur. Cause probable : l’adresse d’expédition ou une authentification e-mail manquante. Va aux étapes 3 et 4.
• Le test n’arrive jamais, et ton service d’envoi n’affiche rien à son sujet. Le gestionnaire ne l’a jamais envoyé. Cause probable : une erreur que le gestionnaire masque, ou un envoi désactivé. Va à l’étape 2.
• Le service d’envoi indique « bounced », « rejected » ou « deferred ». Lis le motif indiqué, il nomme le plus souvent le problème. Va aux étapes 3, 4 et 7.
• Le service indique « delivered », mais tu ne trouves pas le message. Le serveur destinataire l’a accepté. Regarde les spams, la quarantaine, les règles de transfert et l’adresse du destinataire. Va à l’étape 5.
• Chez toi, ça marche, mais les messages de certains visiteurs manquent. Une règle anti-spam de ton formulaire bloque de vraies personnes, ou une limite est atteinte. Va aux étapes 6 et 7.
• Ça a fonctionné pendant des mois, puis plus rien. Quelque chose a changé : une clé expirée, un quota épuisé, de nouveaux réglages DNS ou une mise à jour d’extension. Va à l’étape 7.

Les étapes pour corriger

1. Fais un vrai test et note l’heure. Envoie toi-même le formulaire en ligne. Saisis comme adresse du visiteur une autre adresse e-mail que celle qui reçoit les messages, idéalement chez un autre fournisseur, et mets un mot unique dans le message, par exemple « test-1017 ». Note l’heure et ton fuseau horaire, puis attends dix minutes : certains serveurs retardent volontairement les expéditeurs inconnus. Cherche ton mot unique dans la boîte de réception, dossier spam compris.

2. Découvre ce que fait le gestionnaire après l’envoi. Ouvre la page, ouvre les outils de développement de ton navigateur (F12), va dans l’onglet Réseau (Network) et envoie le formulaire. Clique sur la requête envoyée et lis la réponse. Un « 200 OK » dit seulement que le gestionnaire a répondu. Cherche ensuite une trace de l’autre côté :

   • WordPress : installe une extension SMTP avec une fonction d’e-mail de test (par exemple WP Mail SMTP) et utilise une extension de formulaire qui conserve chaque entrée, comme Contact Form 7 avec le module Flamingo, ou Gravity Forms. Si l’entrée est enregistrée mais qu’aucun e-mail n’est parti, c’est l’envoi qui est en panne.
   • Sites statiques ou codés à la main : lis le journal de la fonction ou du script qui traite le formulaire. Un bug fréquent : le code appelle le service d’e-mail, ignore sa réponse et renvoie « succès » quand même. Le gestionnaire ne devrait annoncer le succès que si le service d’e-mail a accepté le message, et une erreur sinon.
   • Service de formulaires externe : connecte-toi, regarde la liste des envois et ses notes de remise, et vérifie quelle adresse de notification y est réglée.

3. Envoie depuis ton propre domaine et mets le visiteur dans Reply-To. Beaucoup de formulaires utilisent l’adresse du visiteur comme adresse d’expédition (From). Un message qui prétend venir d’une adresse gmail.com mais qui part de ton serveur échoue aux contrôles des fournisseurs de messagerie (SPF, DKIM et alignement DMARC, expliqués dans la FAQ de dmarc.org) : il est refusé ou classé en spam. Change le formulaire pour que le message parte d’une adresse de ton propre domaine, par exemple formulaire@tondomaine.com, et que l’adresse du visiteur figure dans l’en-tête Reply-To. Tu peux toujours cliquer sur « répondre » et écrire au visiteur.

4. Envoie via un service authentifié et mets en place SPF, DKIM et DMARC. La fonction mail() de PHP, ou la messagerie par défaut d’un hébergeur, envoie des messages mal authentifiés, et beaucoup de fournisseurs s’en méfient. Utilise les paramètres SMTP de ton fournisseur de messagerie ou d’un service d’envoi d’e-mails, et ajoute les enregistrements DNS qu’il demande. Les consignes de Google pour les expéditeurs exigent SPF ou DKIM de tout expéditeur, et SPF, DKIM et DMARC, avec un domaine From aligné, de ceux qui envoient de gros volumes. Un formulaire de contact envoie peu de courrier, mais ce sont les mêmes contrôles qui décident de son sort. Les enregistrements ressemblent à ceci (ton service te donne les valeurs exactes) :

   • SPF : un enregistrement TXT sur tondomaine.com avec une valeur du type v=spf1 include:spf.service-mail.example ~all
   • DKIM : un enregistrement TXT ou CNAME nommé selector1._domainkey.tondomaine.com, dont la valeur est copiée depuis ton service d’e-mail
   • DMARC : un enregistrement TXT nommé _dmarc.tondomaine.com avec la valeur v=DMARC1; p=none; rua=mailto:dmarc@tondomaine.com

   Un domaine ne doit avoir qu’un seul enregistrement SPF : fusionne donc les entrées include: en un seul. Utilise le bouton « vérifier le domaine » du service, puis refais le test de l’étape 1. Ouvre le message reçu, choisis « Afficher l’original » (Gmail) ou les en-têtes, et cherche spf=pass, dkim=pass et dmarc=pass.

5. Vérifie où le message s’est arrêté. Deux endroits gardent une trace :

   • Côté envoi : le journal de ton service d’envoi d’e-mails ou de ton fournisseur SMTP. Retrouve ton test grâce à l’heure et au destinataire, et lis son statut : accepted, delivered, deferred, bounced ou complained. Un rebond s’accompagne d’un motif. La plupart des services affichent ces statuts dans un tableau de bord, par exemple dans la liste des types d’événements de Resend.
   • Côté réception : les dossiers spam, indésirables et quarantaine, les règles de la boîte et les transferts, et une faute de frappe dans l’adresse du destinataire. Si ta messagerie tourne sur Microsoft 365 ou Google Workspace, un administrateur peut lancer un suivi de message (Microsoft) ou une recherche dans les journaux d’e-mail (Google) pour voir si le message est arrivé et ce qu’il est devenu. Si l’adresse transfère vers une autre boîte, vérifie aussi cette dernière.

6. Écarte ta propre protection anti-spam. Les champs pièges (honeypot), les CAPTCHA, les limites de débit, les durées minimales de saisie et les filtres de mots rejettent aussi de vraies personnes. Essaie le formulaire depuis un téléphone en données mobiles, avec la saisie automatique du navigateur activée. La saisie automatique peut remplir un champ piège caché, et un réseau mobile ou un bureau partage souvent une seule adresse IP, qui atteint plus vite une limite de débit. Un envoi bloqué devrait être enregistré avec son motif, et le visiteur devrait voir un message clair, jamais un faux « envoyé ».

7. Contrôle les limites, les clés et les changements récents. Les offres gratuites des services d’e-mail et de formulaires ont des plafonds quotidiens ou mensuels, au-delà desquels les messages sont refusés ou perdus. Regarde la page d’utilisation de ton offre (les quotas de Resend en sont un exemple). Demande-toi ensuite ce qui a changé à l’époque où les messages ont cessé : une clé d’API expirée ou remplacée, un déménagement du site ou des DNS modifiés (le passage à un nouvel hébergeur fait souvent perdre les enregistrements de messagerie), une mise à jour d’extension ou de PHP, une adresse de destinataire modifiée. Note dans ton agenda les dates d’expiration des clés et des domaines.

8. Rends les pannes visibles la prochaine fois. Corriger une fois ne suffit pas, car la même chose peut se casser à nouveau sans qu’on le voie. Quatre habitudes l’évitent :

   • Garde une copie. Enregistre chaque envoi (base de données, tableur ou entrées de l’extension de formulaire) avant d’essayer d’envoyer l’e-mail, avec un statut comme reçu, envoyé ou échoué. Aucune demande ne se perd alors, même quand l’e-mail tombe en panne. Limite l’accès à ces copies et supprime-les après un délai fixé.
   • Réponds honnêtement. N’affiche le message de remerciement qu’une fois l’e-mail accepté par l’expéditeur. Sinon, affiche une erreur avec une autre façon de te joindre, comme ton adresse e-mail.
   • Déclenche une alerte en cas d’échec. Fais-toi prévenir par le gestionnaire quand l’envoi échoue ou qu’une limite approche, par un autre canal que la boîte du formulaire elle-même, par exemple un message de chat ou une seconde adresse. Si ton service d’e-mail propose des webhooks pour les rebonds et les plaintes, utilise-les.
   • Lance un test planifié. Une fois par jour ou par semaine, envoie un test clairement marqué via le formulaire en ligne et vérifie qu’il a été enregistré, accepté et remis. S’il n’arrive pas dans le délai prévu, déclenche l’alerte. Une tâche planifiée dans ton système d’intégration continue ou un service de surveillance capable de tester un formulaire suffit.

   Dans les journaux, consigne l’heure UTC, un identifiant d’envoi, l’identifiant de message du service d’e-mail, le statut et un éventuel code d’erreur. Le texte du message, les mots de passe et les clés n’y ont pas leur place, comme le conseille aussi l’aide-mémoire OWASP sur la journalisation.

Quand demander de l’aide

Fais appel à quelqu’un d’expérimenté si :

• le test continue de manquer après les étapes 1 à 5, alors que le service indique « delivered »
• tu n’as pas accès aux réglages DNS, au compte d’hébergement ou à l’administration de la messagerie, ou tu ne sais pas qui l’a
• le formulaire repose sur du code sur mesure que personne ne maintient
• des rapports de rebond ou DMARC montrent des expéditeurs inconnus qui utilisent ton domaine
• des messages perdus te coûteraient des clients ou des échéances, comme des demandes de devis, des réservations ou des avis juridiques, et tu veux une installation surveillée plutôt que d’espérer