Un formulaire n’envoie pas les e-mails : où se situe le plus souvent le problème

Un formulaire de site peut sembler parfaitement fonctionnel : les champs se remplissent, le bouton réagit, un message « envoyé » apparaît. Mais l’e-mail n’arrive jamais chez le propriétaire. Pour une entreprise, c’est plus dangereux qu’une erreur visible. Quand le formulaire affiche un avertissement rouge, au moins le problème se voit. Quand tout semble réussir, des demandes peuvent se perdre pendant des semaines.

Le problème ne vient pas toujours du formulaire lui-même. C’est plus souvent la chaîne de livraison qui casse quelque part : le site a bien reçu les données, mais l’e-mail n’est pas passé par le serveur, le SMTP, le DNS, le filtre anti-spam ou la boîte de réception du destinataire. La bonne question n’est donc pas « pourquoi le formulaire ne marche pas », mais « à quelle étape la demande disparaît-elle ».

Pourquoi cela concerne n’importe quel site

Ce n’est pas un problème propre à un CMS particulier, à une extension ou à une plateforme. La même situation peut se produire sur un site avec un formulaire fait maison, sur un vieux CMS, sur un constructeur, sur une boutique en ligne, sur une landing page ou sur un formulaire de réservation.

La seule différence, c’est l’endroit où se trouve le contrôle. Sur certains sites, on peut consulter le journal d’envoi, les demandes enregistrées et les réglages SMTP. Sur d’autres, le propriétaire ne voit que l’éditeur visuel et l’e-mail dans sa boîte. C’est pourquoi le diagnostic commence toujours par comprendre la plateforme : ce que le site enregistre réellement, comment il envoie les e-mails, et s’il est possible de retrouver une trace technique de la demande.

Dans sa documentation Workspace, Google précise que le formulaire lui-même n’est généralement pas la cause principale. Le problème vient plus souvent de la manière dont le message est envoyé et validé par le système de messagerie : SPF, relais SMTP, DKIM et réglages de l’expéditeur. C’est un point important. Le bouton « Envoyer » peut fonctionner parfaitement, et la messagerie rejeter quand même l’e-mail comme suspect.

Où la chaîne casse le plus souvent

Une demande passe par plusieurs étapes.

1. Le client remplit le formulaire.
2. Le site vérifie les champs et la protection anti-spam.
3. Le site compose l’e-mail.
4. Le serveur ou le service SMTP tente de l’envoyer.
5. Les enregistrements DNS du domaine confirment que l’expéditeur a le droit d’envoyer ce message.
6. Gmail, Outlook ou un autre service de messagerie examine le message.
7. L’e-mail arrive en boîte de réception, en spam, ou est rejeté.
8. Si l’enregistrement des demandes est activé sur le site, une trace reste dans l’administration, la base de données ou le CRM.

Chaque étape peut avoir sa propre erreur.

Les causes les plus fréquentes :

• le formulaire envoie l’e-mail via la fonction PHP mail basique, sans authentification correcte
• le SMTP n’est pas configuré, ou le mot de passe SMTP a changé
• le champ From affiche l’e-mail du client au lieu de l’adresse du domaine du site
• le Reply-To n’est pas configuré, donc la réponse ne part pas vers le client
• le SPF n’inclut pas le serveur ou le service qui envoie réellement l’e-mail
• le DKIM n’est pas activé, ou a été cassé après un transfert de messagerie
• le DMARC est trop strict pour le schéma d’envoi actuel
• l’e-mail ressemble à du spoofing, c’est-à-dire une usurpation d’expéditeur
• la boîte mail est pleine, ou un filtre range les messages en spam
• le captcha ou l’anti-spam bloque de vrais clients
• le cache ou une optimisation gêne l’envoi du formulaire
• après une mise à jour, les champs, le modèle d’e-mail ou l’endpoint du formulaire ont changé
• le site n’enregistre pas les demandes, donc un e-mail perdu ne peut pas être récupéré

Pourquoi From et Reply-To comptent autant

L’une des erreurs les plus fréquentes consiste à envoyer l’e-mail comme s’il venait directement du client.

Par exemple, le client indique client@gmail.com, et le site tente d’envoyer l’e-mail depuis son propre serveur avec un en-tête From : client@gmail.com. Pour un service de messagerie, cela paraît suspect : l’e-mail ne provient pas des serveurs de Gmail, mais prétend venir de Gmail. C’est ainsi que naît un risque de spoofing, de classement en spam ou de rejet pur et simple.

Il vaut mieux procéder autrement :

• From : une adresse technique du domaine du site, par exemple no-reply@domaine.fr ou contact@domaine.fr
• Reply-To : l’e-mail du client indiqué dans le formulaire
• To : l’adresse professionnelle du propriétaire ou du service commercial

Le système de messagerie voit alors une situation cohérente : le site envoie un e-mail de service depuis son propre domaine, et le propriétaire peut cliquer sur Répondre pour écrire directement au client. Cela ne résout pas tout automatiquement, mais cela élimine l’une des causes de blocage les plus fréquentes.

Pourquoi le SMTP vaut généralement mieux qu’un envoi depuis l’hébergement

Un site classique n’a pas vocation à être un système de messagerie complet. L’hébergement sert bien les pages, mais n’envoie pas toujours bien les e-mails. Sur un serveur mutualisé, on trouve parfois des limitations, une mauvaise réputation d’IP, des ports bloqués ou des plafonds d’envoi.

Le SMTP règle une partie de ce problème. Le site se connecte à un service de messagerie avec un identifiant et un mot de passe, ou via une API, et l’e-mail part par un système conçu pour la livraison. Cela peut être la messagerie du domaine, Google Workspace, Microsoft 365, SendGrid, Mailgun, Brevo, Postmark ou un autre service.

Mais le SMTP doit lui aussi être correctement configuré :

• choisir le bon port et le bon type de chiffrement
• vérifier l’identifiant et le mot de passe
• configurer l’adresse d’expéditeur
• ajouter le SPF, le DKIM et, si besoin, le DMARC
• envoyer un e-mail de test
• vérifier la livraison sur Gmail, Outlook et la messagerie du domaine
• regarder si l’e-mail atterrit en spam

Se contenter d’installer une extension SMTP sans vérifier le résultat peut laisser le problème intact. Le propriétaire verra « envoyé avec succès », pendant que la messagerie continue de filtrer les messages.

C’est un vrai plus quand les demandes sont enregistrées sur le site

La situation idéale : la demande n’est pas seulement envoyée par e-mail, elle est aussi enregistrée sur le site, dans une base de données, un CRM ou un journal dédié. Si l’e-mail finit en spam ou est rejeté, il suffit alors d’ouvrir l’administration pour voir que le client a bien écrit.

C’est particulièrement important pour une entreprise qui fait de la publicité, prend des réservations ou reçoit des demandes coûteuses. Si le clic a déjà été payé, un formulaire perdu n’est pas un détail technique : c’est de l’argent perdu directement.

Mais il faut le dire honnêtement : ce n’est pas le cas sur tous les sites, et ce n’est pas partout facile à activer.

Les limites varient :

• un constructeur fermé n’offre pas d’accès correct à la base de données
• le formulaire est fourni par un service externe et garde les données uniquement chez lui
• un vieux site envoie les e-mails directement et n’enregistre rien
• le forfait de la plateforme n’inclut pas d’historique des demandes
• le site n’a ni CRM, ni webhook, ni module de journalisation
• il existe des obligations légales sur les données personnelles et leur durée de conservation
• après un piratage ou un incident, la base a pu être vidée

C’est pourquoi un audit de formulaire doit vérifier non seulement la livraison de l’e-mail, mais aussi une question précise : où reste la trace de la demande. Sans réponse claire, l’entreprise dépend uniquement de la boîte mail.

Un cas concret : des demandes existaient, mais le propriétaire ne les voyait pas

Un scénario classique pour un site de service local. Le propriétaire avait lancé une campagne publicitaire, les gens arrivaient sur la page, le formulaire affichait un message de succès. La boîte mail restait silencieuse. La première conclusion, simple, était que la publicité ne fonctionnait pas et qu’il n’y avait pas de demande.

La vérification a montré autre chose. Après un changement de messagerie sur le domaine, l’ancien schéma d’envoi était resté en place. Le site tentait d’envoyer les notifications depuis l’adresse du client indiquée dans le formulaire, pas depuis l’adresse du domaine du site. Pour Gmail et Outlook, cela ressemblait à une usurpation suspecte d’expéditeur : l’e-mail arrivait techniquement depuis le serveur du site, mais l’en-tête affirmait venir d’une adresse externe appartenant au client.

Une partie des e-mails partait en spam, une autre était rejetée sans notification visible pour le propriétaire. Sur l’écran, le formulaire avait l’air de fonctionner, puisque l’utilisateur voyait « envoyé ». Le problème n’était pas dans le design du formulaire, mais dans la livraison.

Dans ce cas précis, la chance a joué : les demandes étaient enregistrées dans l’administration du site. Le journal a permis de retrouver plusieurs contacts des derniers jours, de vérifier l’heure d’envoi, la page, le téléphone et l’e-mail du client. Une partie des clients a pu être rappelée par téléphone ou par e-mail. Sans cet enregistrement, il aurait été presque impossible de les retrouver. Il ne serait resté que des traces indirectes : des clics publicitaires, des visites de pages, des événements d’analyse, mais pas les coordonnées des clients eux-mêmes.

La solution n’a pas consisté à « installer un autre formulaire ». Le schéma a d’abord été corrigé :

• le From a été remplacé par une adresse du domaine du site
• le Reply-To a été lié à l’e-mail du client
• l’envoi est passé par le SMTP
• le SPF et le DKIM ont été vérifiés
• un DMARC de base a été ajouté en mode souple
• le journal d’envoi a été activé
• des tests ont été envoyés vers plusieurs boîtes mail
• le scénario mobile a été vérifié

Il est ensuite devenu clair que le site recevait bien les demandes, que les e-mails arrivaient, et que le propriétaire pouvait vérifier l’historique en cas de doute.

Ce que vous pouvez vérifier vous-même

Une vérification de base est possible sans accès au code.

1. Ouvrez le formulaire comme un client, pas depuis l’administration.
2. Envoyez un test depuis un ordinateur.
3. Envoyez un test depuis un téléphone.
4. Utilisez un autre e-mail que celui qui reçoit habituellement les demandes.
5. Vérifiez la boîte de réception, les spams, les promotions, les mises à jour et « Tous les messages ».
6. Cliquez sur Répondre dans l’e-mail reçu et regardez à qui la réponse partira.
7. Vérifiez si une réponse automatique arrive chez le client, quand elle doit arriver.
8. Regardez si la demande est enregistrée dans l’administration, le CRM ou un tableau.
9. Notez l’heure exacte du test, la page et l’e-mail de l’expéditeur.
10. Ne changez pas cinq réglages à la fois, sinon vous ne saurez plus ensuite ce qui a aidé ou cassé quelque chose.

Il est particulièrement important de tester le formulaire avant une campagne publicitaire. Si la publicité amène déjà des visiteurs sur la page, et que le formulaire perd les e-mails en silence, le budget part dans le vide. Le propriétaire peut conclure à tort que l’offre ne plaît pas, alors que le problème se situe dans la livraison des demandes.

Quand le problème ne vient pas des e-mails

Parfois, l’e-mail n’est même pas créé. Le SMTP et le DNS ne peuvent alors rien y faire.

C’est le cas si :

• le bouton ne réagit pas sur téléphone
• un champ obligatoire est cassé
• le captcha bloque tout le monde sans distinction
• une erreur JavaScript survient après l’envoi
• le formulaire se trouve dans une popup, et le script de la popup entre en conflit avec le cache
• un fichier du thème ou du modèle ne transmet pas les données du formulaire
• l’endpoint du formulaire est bloqué par une protection ou un pare-feu
• la version multilingue envoie la demande vers un formulaire qui n’existe pas

C’est pourquoi le diagnostic ne doit jamais commencer uniquement par la messagerie. Il faut parcourir tout le trajet du client : ouvrir la page, remplir le formulaire, l’envoyer, voir le résultat, vérifier l’e-mail, vérifier le journal, et vérifier l’enregistrement de la demande.

Quand passer par Zen Webmaster

Si le formulaire compte pour les demandes, les réservations, les devis ou les ventes, il ne peut pas fonctionner sur le principe « installé une fois, oublié ensuite ». Il faut un contrôle.

Zen Webmaster peut vérifier :

• si le formulaire fonctionne sur ordinateur et sur mobile
• si une popup, le cache, le captcha ou des scripts ne gênent pas
• si le From et le Reply-To sont correctement configurés
• si le SMTP est en place avec les bons accès
• si le SPF, le DKIM et le DMARC passent
• si les e-mails finissent en spam
• si les demandes sont enregistrées dans l’administration, le CRM ou les journaux
• s’il est possible de retrouver les contacts manqués
• quels formulaires existent sur le site et s’ils fonctionnent tous
• ce qu’il vaut la peine de tester régulièrement après chaque mise à jour

Après la vérification, on peut mettre en place un contrôle simple : une demande test une fois par mois, une vérification après chaque mise à jour, un contrôle avant une campagne publicitaire, un journal d’envoi et l’enregistrement des demandes partout où c’est possible. C’est une routine technique peu passionnante, mais c’est exactement elle qui protège l’entreprise d’une situation du type « les clients ont écrit, et nous n’avons rien reçu ».

L’idée à retenir

Le formulaire d’un site n’est pas un simple ensemble de champs. C’est la porte d’entrée de l’activité. S’il tombe en panne, le propriétaire ne perd pas seulement un e-mail, mais aussi un client, un budget publicitaire et la confiance dans son propre site.

Une bonne configuration ne promet pas de miracle. Elle rend le système vérifiable : on voit que le client a envoyé une demande, on voit si l’e-mail est parti, on sait où répondre, et il existe une chance de retrouver les contacts manqués. Sans cela, un site peut sembler fonctionner parfaitement tout en perdant de l’argent en silence.