Quelqu’un remplit votre formulaire de contact. La page le confirme : « Merci, nous vous recontacterons. » La personne ferme l’onglet et attend de vos nouvelles.
Vous ne rappelez jamais, parce que vous n’avez jamais reçu le message. Aucun e-mail n’est arrivé, ni ce jour-là, ni plus tard. Le prospect attend en silence, puis part chercher la prochaine entreprise dont le formulaire fonctionne vraiment. Rien à l’écran n’a signalé à l’un ou à l’autre que l’envoi avait échoué.
Comment WordPress envoie réellement ce message
Voici la tuyauterie, en termes simples. Quand quelqu’un soumet un formulaire WordPress, le site appelle une fonction nommée wp_mail, qui transmet par défaut le message à la fonction intégrée mail() de PHP plutôt qu’à un service d’e-mail dédié. PHP mail ne se connecte nulle part, ne prouve pas que c’est vraiment vous qui envoyez, et ne passe pas par le type d’infrastructure vérifiée que Gmail ou Outlook attendent d’un expéditeur légitime. Il demande simplement à votre serveur web de pousser un e-mail vers l’extérieur et espère que tout se passe bien. Autrefois, cela suffisait. Aujourd’hui, presque plus, car les fournisseurs de messagerie ont renforcé leurs défenses précisément contre ce type d’envoi non authentifié et peu soigné, et un simple appel à mail() passe rarement le filtre.
L’e-mail prétend venir de vous, et personne n’y croit
Votre formulaire de contact est généralement configuré pour envoyer « depuis » une adresse comme you@yoursite.com, ou depuis une adresse qui n’existe même pas, comme wordpress@yoursite.com. Le champ De affirme que c’est vous, mais le serveur qui envoie réellement le message n’a jamais été autorisé à envoyer du courrier au nom de votre domaine. Tous les grands fournisseurs de messagerie vérifient désormais cette autorisation. Quand elle manque, ils ne renvoient pas le message avec une erreur claire que vous remarqueriez. Ils le suppriment discrètement, ou le rangent quelque part que vous n’ouvrirez jamais. Votre site n’est pas cassé d’une manière visible à l’œil nu. Il affirme quelque chose qu’il ne peut pas prouver, et les fournisseurs ont cessé de le croire sur parole.
Votre hébergeur n’envoie pas le courrier, ou très peu
Toutes les offres d’hébergement ne laissent pas un site envoyer des e-mails librement. L’hébergement mutualisé en particulier limite souvent le nombre de messages qu’un domaine peut envoyer par heure, ou bloque carrément la fonction mail de PHP, parce qu’un autre client du même serveur s’en est servi un jour pour envoyer du spam et que l’hébergeur a verrouillé toute la fonctionnalité. Si votre hébergeur fait partie des plus stricts, votre formulaire peut sembler parfaitement normal (la page confirme, le code s’exécute sans erreur) alors que l’envoi réel est avalé avant même de quitter le bâtiment. Vous ne verrez aucun message d’échec, parce que l’échec se produit sur une infrastructure dans laquelle vous n’avez aucune visibilité.
Votre domaine ne peut pas prouver que le courrier est légitime
Même quand le courrier est bien envoyé, les fournisseurs qui le reçoivent vérifient des enregistrements DNS appelés SPF et DMARC pour décider s’ils doivent lui faire confiance. Ensemble, ils permettent à votre domaine d’indiquer quels serveurs ont le droit d’envoyer du courrier en son nom, et ce qu’un serveur destinataire doit faire d’un message qui échoue à cette vérification. Sur un site WordPress où personne ne les a configurés volontairement, ils sont souvent absents ou mal configurés, et le courrier de votre domaine finit par ressembler exactement au type de message que ces systèmes existent pour filtrer.
Tout marchait, jusqu’à ce qu’une mise à jour change quelque chose
Le cœur de WordPress, votre thème et chaque extension du site se mettent à jour selon leur propre calendrier, et n’importe lequel d’entre eux peut modifier discrètement la façon dont le courrier est envoyé. Une mise à jour de l’extension de formulaire remplace sa bibliothèque d’envoi. Une extension de sécurité se met à bloquer une connexion sortante qu’elle autorisait auparavant. Une extension de cache continue d’afficher l’ancienne page de confirmation alors que l’envoi côté serveur a commencé à échouer. Rien de tout cela n’apparaît comme une erreur dans votre tableau de bord, parce que du point de vue de WordPress, le formulaire a bien été soumis. C’est la couche en dessous qui a discrètement cessé de fonctionner, et une mise à jour est la raison la plus courante pour laquelle cette couche bouge sans que personne n’y touche volontairement.
Le test de 10 minutes
Avant de réparer quoi que ce soit, vérifiez ce qui se passe réellement. Cela prend environ dix minutes et vous indique à quel type d’échec décrit plus haut vous avez affaire.
- Faites un vrai test d’envoi, avec une adresse e-mail qui n’est pas une adresse Gmail : une adresse professionnelle, un compte Outlook, peu importe. Le filtre antispam de Gmail est à lui seul assez agressif pour qu’un test limité à Gmail masque un problème qu’un autre fournisseur aurait détecté.
- Vérifiez le dossier spam ou courrier indésirable, pas seulement la boîte de réception, de l’adresse utilisée pour le test. Un message tombé dans les spams est un problème différent d’un message qui n’est jamais arrivé, et il vous oriente vers la partie SPF et DMARC ci-dessus plutôt que vers un blocage de l’hébergeur.
- Consultez le vrai journal des e-mails, pas le message de confirmation. La plupart des hébergeurs proposent un journal des e-mails dans cPanel ou dans leur panneau de contrôle, ou vous pouvez installer une extension gratuite comme WP Mail Logging, qui enregistre chaque e-mail que WordPress tente d’envoyer et indique s’il a réussi. Cette seule étape vous dit si WordPress a même essayé.
- Envoyez un second test vers un autre fournisseur. Si le message arrive chez Outlook mais pas chez Gmail, c’est un signal fort que vous avez affaire à un problème d’authentification lié à la façon dont un fournisseur évalue votre domaine, et non à un blocage général de l’hébergeur.
- Passez votre domaine au Bilan de santé du site. Il vérifie vos enregistrements SPF et DMARC (pas DKIM, qui nécessite un autre type de requête) et vous indique en moins d’une minute si votre domaine est configuré pour prouver que son courrier est légitime. Une alerte à ce niveau explique généralement tout le reste.
Les solutions honnêtes
Une fois que vous savez à quel type d’échec vous avez affaire, la solution tient généralement en quelques options. Aucune n’est une astuce ; chacune est une vraie façon de régler le problème.
Installez une extension SMTP. C’est la réponse classique des développeurs, et elle est justifiée. Une extension SMTP fait passer vos e-mails sortants par un véritable service d’e-mail au lieu de la fonction mail() de PHP, ce qui règle le problème d’authentification à la racine, puisque le courrier provient désormais d’une infrastructure à laquelle les fournisseurs font déjà confiance. Comptez une vingtaine de minutes si vous êtes à l’aise pour créer une clé d’API et la coller dans un écran de réglages. Sinon, c’est une heure de travail raisonnable à confier à un développeur.
Passez à un service de formulaires. Les outils conçus spécifiquement pour gérer les soumissions de formulaires, plutôt qu’une extension greffée sur wp_mail, envoient souvent les notifications via leur propre infrastructure d’envoi vérifiée, ce qui contourne tout le problème. Vous perdez un peu de contrôle sur l’apparence et le comportement exacts du formulaire. Vous gagnez un service dont le seul travail est de s’assurer que le message arrive.
Confiez la gestion du site à quelqu’un. Si vous préférez ne pas apprendre ce que signifie SPF, c’est une position tout à fait légitime, pas un échec de votre part. C’est exactement le genre d’entretien qui passe entre les mailles du filet sur un site WordPress géré soi-même : personne ne s’en aperçoit jusqu’à ce qu’un prospect appelle un concurrent. Si vous préférez ne plus être celui ou celle qui consulte un journal des e-mails chaque fois qu’une mise à jour casse quelque chose, passez directement à l’option pour ne plus jamais y penser.
Pourquoi cela ne cesse de casser
Un site WordPress n’est pas quelque chose qu’on termine. C’est un empilement d’éléments qui se mettent à jour indépendamment (le cœur, le thème, une douzaine d’extensions, l’hébergeur en dessous), et chacun peut déplacer le terrain sur lequel reposent les autres. Une mise à jour d’extension dans six mois peut casser à nouveau ce même formulaire d’une tout autre manière, et ce ne sera pas plus votre faute qu’aujourd’hui. C’est le prix à payer quand un logiciel n’est surveillé par personne. La version la plus extrême que nous ayons vue ne concernait même pas un formulaire : 32 liens de spam cachés avaient été injectés dans le code WordPress d’une entreprise de déménagement fondée par des vétérans, invisibles sur la page, faisant discrètement chuter son référencement jusqu’à ce qu’un audit les détecte. Un formulaire de contact cassé est l’échec que l’on remarque, parce que les prospects cessent d’appeler. Beaucoup de défaillances WordPress ne sont jamais remarquées.
Si vous ne voulez plus jamais déboguer cela
Si vous préférez ne pas être celui ou celle qui épluche les journaux d’e-mails et lit les enregistrements DNS chaque fois que cela casse, c’est ce que Surmado Sites prend en charge dans le cadre de la gestion du site : l’hébergement et l’acheminement des e-mails, ainsi que l’entretien qui empêche une correction de se défaire à la prochaine mise à jour. Vous le demandez une fois, en langage courant, et le problème reste réglé.
Questions fréquentes
Pourquoi le formulaire indique-t-il « envoyé » alors que rien n’arrive ?
La confirmation « message envoyé » est générée par WordPress au moment où le formulaire est soumis et où wp_mail est appelée. Elle n’attend pas qu’un serveur de messagerie confirme que le message a réellement été délivré, parce que la plupart des configurations de formulaires de contact ne sont pas conçues pour vérifier cela. La confirmation signifie que WordPress a tenté l’envoi. Elle ne signifie pas que quelqu’un l’a reçu.
Les messages finissent-ils dans les spams ?
Parfois, mais pas toujours. Si vos enregistrements SPF ou DMARC sont mal configurés, le courrier qui est bien envoyé atterrit souvent dans les spams, parce que les fournisseurs qui le reçoivent ne peuvent pas vérifier qu’il provient vraiment de votre domaine. Si votre hébergeur bloque purement et simplement l’envoi, ou si un conflit entre extensions l’arrête avant qu’il ne quitte votre serveur, le courrier n’est jamais envoyé, et il ne se trouve donc pas non plus dans les spams. Consulter un journal des e-mails, ou le résultat de votre Bilan de santé du site, vous indique dans quelle situation vous vous trouvez.
Pourquoi cela a-t-il cessé de fonctionner après une mise à jour ?
Parce qu’un élément de cette chaîne de mises à jour a modifié la façon dont le courrier est envoyé, ou le fait même qu’il le soit, et qu’aucun de ces changements n’apparaît comme une erreur visible dans WordPress. Il s’agit rarement de l’extension que l’on soupçonne en premier. C’est pourquoi consulter le journal des e-mails juste après chaque mise à jour vaut les deux minutes que cela prend, avant de commencer à chercher à l’aveugle.
Ai-je besoin d’une extension SMTP ?
Pas toujours, mais souvent, oui. Si les enregistrements SPF et DMARC de votre domaine sont corrects et que le vrai problème est un hébergeur qui bloque ou limite l’envoi via PHP, une extension SMTP qui fait passer le courrier par un véritable service d’e-mail est la solution la plus directe. Si ce sont les enregistrements DNS qui posent problème, corrigez-les d’abord ; une nouvelle méthode d’envoi n’aidera pas si le domaine lui-même ne peut toujours pas prouver sa légitimité. Dans tous les cas, une extension SMTP est une vraie solution, courante, pas un contournement, mais c’est aussi un élément de plus à configurer et à maintenir en état de marche, et c’est précisément cette partie qu’un service de formulaires ou un site géré vous retire.