Le visiteur remplit votre formulaire de contact, clique sur le bouton, et voit apparaître un message de remerciement. De son point de vue, la demande est partie. De votre côté, rien n'arrive dans la boîte, ou le message tombe dans les indésirables et vous le découvrez trois semaines plus tard, ou il part vers une adresse que plus personne ne consulte depuis le départ d'une collaboratrice. Le site fonctionne parfaitement, le formulaire fonctionne parfaitement, et vous perdez pourtant des demandes de devis sans le moindre signal d'alerte.
C'est l'incident le plus discret et l'un des plus coûteux que nous traitons sur les sites que nous reprenons. Il ne provoque aucune erreur visible, et le seul symptôme perceptible est un silence commercial que le dirigeant attribue généralement à la conjoncture ou au référencement. Nous avons vu des entreprises conclure que leur site ne rapportait rien, alors qu'il rapportait sans que personne ne le sache.
Dans le cadre de la maintenance WordPress à 500 HT / an, nous contrôlons périodiquement les formulaires et la délivrabilité des messages qu'ils émettent. À la création d'un site, nous branchons dès le départ un envoi authentifié plutôt que la fonction d'envoi du serveur web, pour les raisons expliquées ci-dessous.
Pourquoi la fonction d'envoi du serveur web ne suffit pas
Un site WordPress installé sur un hébergement mutualisé envoie ses messages, par défaut, avec la fonction mail() de PHP. Cette fonction remet le message au serveur d'envoi local de la machine, qui le transmet ensuite sur Internet. Le mécanisme est ancien et il présente trois faiblesses structurelles.
La première tient à l'expéditeur. Le message part d'une machine mutualisée qui n'a jamais été déclarée comme autorisée à envoyer du courrier pour votre nom de domaine. Le serveur de réception constate qu'un message se présente au nom de votre entreprise depuis une infrastructure inattendue, et il applique la seule décision prudente à sa disposition : il classe le message en indésirables, ou il le rejette purement et simplement. Ce mécanisme repose sur trois enregistrements publics de votre domaine, que nous détaillons dans notre article sur les e-mails qui arrivent en indésirables.
La deuxième faiblesse tient à la mutualisation. Sur un hébergement partagé, la réputation de la machine dépend aussi du comportement des autres sites qu'elle héberge. Si l'un d'eux a émis du courrier indésirable, l'adresse de la machine se retrouve mal notée, et vos messages légitimes en subissent les conséquences.
La troisième faiblesse tient à l'absence de retour. La fonction mail() indique seulement qu'elle a remis le message au serveur local. Elle ne dit rien du sort ultérieur. Beaucoup d'hébergeurs restreignent ou bloquent silencieusement ces envois, précisément pour limiter les abus. Le formulaire affiche alors son message de remerciement, parce que du point de vue du site tout s'est bien passé, et le courrier n'existe nulle part.
La solution consiste à faire envoyer les messages par un serveur d'envoi authentifié, avec un compte identifié : celui de votre messagerie professionnelle, celui de votre hébergeur de messagerie, ou un service de remise dédié. Le message part alors depuis une source légitime pour votre domaine, et un échec d'envoi devient visible au lieu de rester muet. Que votre messagerie soit adossée à Microsoft 365 ou à une offre de messagerie chez Infomaniak, le principe reste identique.
Les causes que nous rencontrons le plus souvent
Six situations expliquent la quasi-totalité des cas que nous diagnostiquons.
- Le domaine n'autorise pas la source d'envoi. Les enregistrements publics de votre domaine ne mentionnent pas l'infrastructure depuis laquelle le site expédie, et les serveurs de réception les plus stricts écartent le message.
- L'envoi se fait sans compte authentifié, par la fonction du serveur web décrite plus haut, avec les conséquences que nous venons d'exposer.
- L'adresse de destination n'est plus valide. Elle appartenait à une personne partie de l'entreprise, ou au prestataire qui a construit le site, ou il s'agit d'une adresse générique que personne n'a jamais ouverte.
- Un filtre anti-spam classe les messages avant que vous ne les voyiez. Le message est bien arrivé, mais il se trouve dans un dossier de quarantaine que vous ne consultez pas, sujet que nous abordons dans notre article sur le traitement du spam et du phishing.
- L'extension de formulaire est mal configurée ou a cessé de fonctionner après une mise à jour. Le champ de destinataire est vide, une case de notification a été décochée, ou l'adresse d'expédition a été remplacée par une valeur par défaut inutilisable.
- La protection anti-robot est déréglée dans un sens ou dans l'autre. Trop stricte, elle bloque des visiteurs légitimes sans les avertir. Trop laxiste ou absente, elle laisse passer un volume de messages automatiques qui noie les vraies demandes et finit par dégrader la réputation de votre boîte.
Comment nous avons construit le formulaire de notre propre site
Nous appliquons chez nous ce que nous recommandons, et le mécanisme est facile à décrire. Le formulaire transmet les données au serveur par une requête en méthode POST au format JSON, vers un point d'entrée unique et identifié. Cette approche donne une réponse explicite au navigateur, ce qui nous permet d'afficher une confirmation seulement lorsque l'envoi a réellement abouti, et un message d'erreur dans le cas contraire.
Un champ masqué joue le rôle de piège : il est invisible pour un visiteur humain, qui ne le remplit donc jamais, alors que de nombreux robots le remplissent automatiquement. Un formulaire arrivant avec ce champ rempli est écarté sans consommer de ressource. Une limitation du nombre de soumissions par adresse réseau complète ce dispositif, ce qui empêche un même émetteur de saturer la boîte. La vérification anti-robot repose enfin sur Google reCAPTCHA v3, qui évalue la soumission sans imposer d'énigme visuelle au visiteur. L'envoi lui-même passe par un serveur d'envoi authentifié, jamais par la fonction du serveur web.
Ce niveau de soin ne demande pas un développement lourd. Il demande simplement d'avoir traité le sujet une fois, au lieu de faire confiance aux réglages par défaut d'une extension.
Notre méthode de diagnostic quand les messages ne partent plus
Nous procédons toujours dans le même ordre, du plus concret au plus subtil, parce que réinstaller l'extension en espérant que le problème disparaisse ne produit qu'une perte de temps.
- Nous envoyons une soumission de test depuis le site vers une adresse que nous contrôlons, afin d'établir si le message sort réellement du serveur ou s'il n'existe jamais.
- Nous lisons les en-têtes techniques du message reçu. Ils indiquent quelle machine a émis le courrier, quelle adresse d'expéditeur a été utilisée et si les contrôles d'authentification du domaine ont réussi ou échoué. C'est cette lecture qui distingue un problème d'émission d'un problème de réception, et elle prend quelques minutes.
- Nous vérifions la configuration de l'extension de formulaire : le destinataire réel, l'adresse d'expédition, les copies éventuelles, et le journal des soumissions si l'extension en conserve un. Ce journal révèle souvent des demandes reçues par le site mais jamais transmises par courrier.
- Nous contrôlons les enregistrements publics du domaine et nous les complétons pour autoriser la source d'envoi retenue, en veillant à ne pas perturber vos échanges habituels.
- Nous basculons l'envoi sur un compte authentifié, puis nous refaisons un test complet vers plusieurs fournisseurs de messagerie différents, parce que leurs filtres ne se comportent pas de la même manière.
- Nous mettons en place une vérification périodique dans le contrat de maintenance, avec un test réel effectué à intervalle régulier, et un contrôle systématique après toute migration d'hébergement ou changement de messagerie.
Ce dernier point mérite d'être souligné. Le dirigeant teste son formulaire une fois, le jour de la mise en ligne, puis plus jamais. Or une migration d'hébergement, un changement de fournisseur de messagerie ou une mise à jour d'extension peuvent rompre la chaîne à tout moment. Notre article sur la migration d'un site vers un autre hébergeur intègre d'ailleurs ce contrôle dans la procédure de bascule.
Si vous ne savez pas avec certitude que les demandes envoyées depuis votre site arrivent bien, remplissez votre propre formulaire et écrivez-nous en parallèle. Nous comparerons ce que le site prétend avoir envoyé et ce qui est réellement arrivé, puis nous corrigerons l'émetteur et le destinataire. Si votre boîte professionnelle est totalement à l'arrêt et que votre activité est bloquée, notre ligne d'urgence traite ce type d'incident en priorité.