Formulaire de contact silencieux : la panne que personne ne voit

Un client me contacte pour refondre son site. Douze mois d’existence, aucune demande reçue via le formulaire. Sa conclusion : le site ne convertit pas.

La vraie conclusion, après une heure de vérification : le formulaire fonctionnait parfaitement. C’est la messagerie qui ne partait pas. Douze mois de demandes potentielles perdues, sans qu’aucun signal ne l’alerte.

Ce n’est pas un cas isolé. C’est le problème le plus fréquent et le moins détecté que je rencontre.

Pourquoi la panne est invisible

Un formulaire web enchaîne deux opérations distinctes. Il collecte les données, puis il déclenche un envoi d’e-mail. Le message de confirmation affiché au visiteur — « Merci, votre message a bien été envoyé » — récompense la première opération. Il ne dit rien de la seconde.

Concrètement : le serveur remet le message à sa file d’envoi, la file répond « accepté », le visiteur voit sa confirmation. Ce qui arrive ensuite au message échappe complètement à cette chaîne. Il peut être rejeté par le serveur destinataire, classé en indésirable, ou silencieusement supprimé.

Personne ne le sait. Le visiteur pense avoir écrit. Le propriétaire pense n’avoir reçu aucune demande. Les deux ont tort.

Les trois causes que je rencontre

L’envoi par la fonction native du serveur. La plupart des hébergements mutualisés expédient les e-mails via la fonction d’envoi intégrée à PHP. Ces messages partent sans authentification, depuis une adresse IP partagée avec des centaines d’autres sites. Les grands fournisseurs de messagerie les rejettent ou les classent en indésirable presque systématiquement.

L’absence d’authentification du domaine. SPF déclare quels serveurs ont le droit d’expédier au nom de votre domaine. DKIM signe cryptographiquement chaque message. DMARC indique quoi faire quand l’un des deux échoue. Sans ces trois enregistrements correctement configurés, un message qui prétend venir de votre domaine mais part d’un serveur mutualisé est traité comme une usurpation. C’est exactement ce qu’il est, techniquement.

L’adresse d’expédition incohérente. Le formulaire expédie depuis l’adresse saisie par le visiteur, pour permettre au destinataire de répondre directement. Résultat : un message qui prétend venir d’une boîte grand public, mais expédié depuis votre hébergeur. Aucune vérification d’authenticité ne peut passer.

Comment vérifier en dix minutes

Ne partez pas du principe que ça marche. Testez.

Envoyez-vous un message via votre propre formulaire, depuis une adresse extérieure à votre domaine. Puis vérifiez trois endroits : la boîte de réception, le dossier indésirable, et si votre messagerie en propose un, le dossier de quarantaine.

Si le message arrive, ouvrez son en-tête complet. La plupart des messageries permettent d’afficher la source. Cherchez les lignes commençant par spf=, dkim= et dmarc=. Trois pass : la configuration est saine. Un seul fail ou none : vous avez une explication.

Recommencez vers une adresse d’un autre fournisseur. Un message peut passer chez l’un et être bloqué chez l’autre. Tester une seule destination ne prouve rien.

Ce qui règle le problème

Le principe est simple : cesser d’expédier depuis le serveur web.

Un service de messagerie transactionnelle prend le relais. Le formulaire lui remet le message, et ce service — dont c’est le métier — le fait partir depuis une infrastructure authentifiée, avec une réputation d’expéditeur suivie. Vous obtenez en prime un journal d’envoi consultable : vous savez si le message est parti, s’il a été reçu, s’il a été rejeté.

Complétez avec deux règles :

• L’expéditeur doit être votre domaine, jamais l’adresse du visiteur. Celle-ci va dans le champ de réponse, pas dans le champ d’expédition.
• Le formulaire doit écrire ailleurs qu’en e-mail. Une entrée dans votre outil de suivi client, une ligne dans un tableau, un ticket. L’e-mail devient une notification, pas le seul enregistrement de la demande. Si l’envoi échoue, la demande existe quand même.

Ce qu’il faut retenir

Avant de conclure qu’un site ne convertit pas, vérifiez qu’il transmet. Un formulaire silencieux n’est pas un problème de contenu, de design ou de référencement — c’est une panne technique, et elle se répare en une matinée.

Ce qu’elle a coûté entre-temps, en revanche, ne se rattrape pas.