Quand le formulaire de contact affiche « Merci » mais qu’aucun e-mail n’arrive

Imaginez un petit cabinet de kinésithérapie. Son site web dispose d’un formulaire de contact, et le formulaire fonctionne – ou du moins en a-t-il l’air. Les visiteurs le remplissent, cliquent sur « Envoyer » et voient un aimable « Merci, nous reviendrons vers vous rapidement ». Ce que personne ne voit : les messages ont cessé d’arriver dans la boîte de réception du cabinet depuis un certain temps. Aucune erreur, aucun message de retour (bounce) dans aucune boîte de réception, aucun voyant rouge nulle part. Le formulaire échoue en silence.

Pourquoi personne ne s’en aperçoit

La page « Merci » d’un formulaire ne signifie généralement qu’une chose : le site web a transmis le message. Qu’un serveur de messagerie l’accepte, le classe comme spam ou le rejette en cours de route se produit plus tard, hors de la vue du formulaire. La fonction mail() de PHP, par exemple, signale un succès dès que le système local accepte le message pour livraison – et non lorsqu’il atteint quelqu’un. Le visiteur reçoit donc une confirmation et passe à autre chose. Le propriétaire, de son côté, voit une boîte de réception vide et suppose qu’il s’agit simplement d’un mois calme. Une baisse des demandes est rarement alarmante en soi : les vacances, la météo, la conjoncture – il y a toujours une explication qui semble plus plausible que « le formulaire est cassé ».

Les causes habituelles

• Le mot de passe SMTP ou le fournisseur de messagerie a changé. Le formulaire continue de se connecter avec les anciens identifiants et le serveur de messagerie refuse – en silence, du point de vue du visiteur.
• PHP mail() sans authentification. Le serveur web envoie les e-mails directement, sans se connecter à un véritable serveur de messagerie. De nombreux serveurs destinataires considèrent ces e-mails comme suspects : ils finissent en spam ou sont purement et simplement rejetés.
• SPF, DKIM et DMARC ne concordent pas. De nombreux formulaires placent l’adresse du visiteur dans le champ From. Le message prétend alors provenir, par exemple, d’une adresse gmail.com, mais il est envoyé par votre serveur web – exactement ce que DMARC est conçu pour empêcher.
• Une mise à jour de plugin ou un changement de thème casse le formulaire ou son CAPTCHA. Un modèle modifié supprime un champ, un script ne se charge plus, ou le widget CAPTCHA apparaît sans son script – et chaque envoi échoue à la validation.
• La boîte aux lettres de réception est pleine. Le serveur de messagerie refuse les nouveaux messages, et le message de retour (bounce) part vers une adresse que personne ne lit.
• La bannière de cookies bloque le script du formulaire. Si l’outil de consentement classe le CAPTCHA ou le script du formulaire dans la catégorie « marketing », les visiteurs qui refusent les cookies peuvent se retrouver avec un formulaire impossible à envoyer, ou dont les envois sont rejetés faute de jeton.
• Un certificat TLS ou un domaine expiré. Les visiteurs voient un avertissement du navigateur et repartent, ou le serveur de messagerie n’est plus joignable de manière sécurisée. Si le domaine de la boîte aux lettres de réception expire, les e-mails qui lui sont destinés cessent tout simplement d’arriver.
• Une couche de cache sert des pages périmées. Un cache de pages complètes peut délivrer un formulaire avec un jeton de sécurité expiré (un nonce ou un jeton CSRF). Le serveur rejette l’envoi et, selon la configuration, le visiteur ne voit aucune erreur claire.

Le piège de l’adresse From

La troisième cause mérite qu’on s’y attarde, car de nombreuses configurations de formulaire l’intègrent par défaut. DMARC vérifie si le domaine de l’adresse From visible correspond à un domaine garanti par SPF ou DKIM. Si le formulaire envoie un message « de la part de » l’adresse du visiteur, votre serveur n’est pas autorisé à envoyer pour ce domaine ; la vérification échoue donc. Selon la politique DMARC du domaine du visiteur et selon votre propre fournisseur de messagerie, le message finit en spam ou est rejeté. La solution est simple : envoyez depuis une adresse de votre propre domaine et placez l’adresse du visiteur dans le champ Reply-To. Un clic sur « Répondre » atteint toujours le visiteur.

Que faire

1. 1Envoyez régulièrement un message de test via votre propre formulaire – au moins une fois par mois, et systématiquement après des mises à jour, des changements de thème ou des modifications des réglages de messagerie. Identifiez-le clairement comme un test afin que personne n’y réponde.
2. 2Connaissez votre rythme habituel. Si le formulaire apporte habituellement quelques messages par semaine, deux semaines de silence sont une raison de vérifier, pas un mois calme.
3. 3Envoyez via SMTP avec authentification – par l’intermédiaire de votre fournisseur de messagerie ou d’un service d’envoi dédié – au lieu de vous fier à PHP mail().
4. 4Utilisez votre propre domaine dans le champ From et l’adresse du visiteur dans Reply-To. Configurez ensuite SPF, DKIM et DMARC pour ce domaine afin que les messages passent les contrôles.
5. 5Conservez une copie de chaque envoi dans la base de données. De nombreux plugins de formulaire le proposent, parfois sous forme d’extension. Si l’envoi d’e-mails échoue, les demandes sont toujours là.
6. 6Vérifiez le formulaire après chaque mise à jour de plugin – y compris le CAPTCHA, et aussi avec les cookies refusés.

Ce genre de contrôles s’oublie facilement, c’est pourquoi il vaut la peine de les automatiser. Avec un compte et un domaine vérifié, formexposed peut envoyer une soumission de test clairement identifiée et vérifier si elle arrive réellement (le contrôle de livraison, uniquement sur activation). Il détecte également le silence – un formulaire qui reçoit normalement des messages et n’en reçoit soudain plus aucun – et vérifie SPF, DKIM et DMARC des e-mails de notification ainsi que l’expiration du certificat TLS et du domaine. Vous n’êtes alerté que lorsque quelque chose change.

Si vous souhaitez simplement un premier aperçu : une vérification gratuite sur formexposed.com ne nécessite aucun compte et ne soumet rien. Elle indique notamment si un CAPTCHA est présent mais défaillant – un widget sans son script, une clé de test publique, des erreurs dans le navigateur –, l’une des manières les plus discrètes dont un formulaire cesse de fonctionner. Seul un véritable message de test peut confirmer que les messages arrivent réellement ; envoyez-en donc un dès aujourd’hui.