Mon formulaire WordPress n'envoie pas les messages : les 9 causes et leurs solutions

Si ton formulaire WordPress n’envoie pas les messages, dans la grande majorité des cas le formulaire lui-même fonctionne : c’est l’email qui n’arrive pas. WordPress l’expédie par défaut avec la fonction PHP mail(), sans aucune authentification, et le serveur du destinataire le rejette ou le classe en spam. La solution durable est un envoi SMTP authentifié depuis une adresse de ton domaine. Ce guide te donne d’abord un diagnostic en 5 minutes, puis les 9 causes réelles et leur correction pas à pas.

Je suis Ayoub Fattami, développeur web freelance à Marrakech, et le formulaire de contact qui n’envoie rien est probablement la panne que je répare le plus souvent. Elle est sournoise : le site s’affiche, le visiteur voit « Merci, votre message a été envoyé », et personne ne se rend compte que les demandes partent dans le vide. Commence par le diagnostic, il t’évitera de tester les neuf causes une par une.

Diagnostic en 5 minutes : le message est-il envoyé, en spam ou bloqué ?

Avant de modifier quoi que ce soit, tu dois savoir dans quelle famille de panne tu te trouves. Il n’y en a que trois : l’email part mais n’arrive pas (délivrabilité), l’email part et arrive au mauvais endroit (spam, mauvaise adresse), ou l’email ne part jamais (le formulaire ne déclenche pas l’envoi). Chaque famille a ses causes, et les mélanger fait perdre des heures.

Voici les quatre vérifications à faire dans l’ordre, sans rien installer de plus que ce qui est indiqué.

1. Envoie un test toi-même depuis le formulaire, avec une adresse qui n’est pas celle du destinataire habituel (une adresse Gmail personnelle par exemple). Note l’heure exacte.
2. Regarde le dossier spam de la boîte destinataire, et aussi les onglets « Promotions » ou « Notifications » de Gmail. Une partie non négligeable des « formulaires cassés » que je diagnostique sont des emails qui dorment dans le spam.
3. Vérifie le journal d’envoi. Si tu utilises Contact Form 7, installe Flamingo : il enregistre chaque soumission en base. Sur Elementor Pro, va dans Elementor → Soumissions. Sur WPForms et Gravity Forms, les entrées sont dans le menu du plugin. Si la soumission apparaît, le formulaire fonctionne et le problème est dans l’envoi de l’email.
4. Installe un journal d’emails si tu n’en as pas : FluentSMTP ou Post SMTP (gratuits) listent chaque email que WordPress a tenté d’envoyer, avec le statut et l’erreur éventuelle. C’est l’outil qui transforme une intuition en certitude.

Le résultat te donne la direction. La soumission est enregistrée et l’email apparaît dans le journal comme « envoyé » mais n’arrive pas : lis les causes 1 à 4. L’email arrive dans le spam ou sur une autre adresse : causes 2, 3 et 9. Aucune soumission, aucun email dans le journal, le bouton ne réagit pas ou affiche une erreur : causes 5 à 8.

Un détail que beaucoup ignorent : le message « Votre message a été envoyé » affiché par le plugin ne prouve rien. Il signifie que WordPress a remis l’email au serveur local, pas que Gmail l’a accepté. C’est précisément pour cela que la panne passe inaperçue pendant des semaines.

Cause 1 : WordPress envoie via PHP mail() sans authentification

C’est la cause numéro un, et de loin. Par défaut, la fonction wp_mail() de WordPress s’appuie sur la fonction PHP mail(), qui remet l’email au serveur de l’hébergement sans identifiant ni mot de passe. Pour Gmail, Outlook ou tout serveur de messagerie sérieux, un email qui arrive sans authentification depuis une adresse IP partagée par des centaines de sites est suspect par nature. Il est rejeté ou classé en spam, et WordPress n’en est jamais informé.

Symptôme : le formulaire affiche la confirmation, la soumission est bien enregistrée, mais l’email n’arrive pas ou arrive une fois sur trois. Les emails de WordPress lui-même (réinitialisation de mot de passe, nouveau commentaire) subissent le même sort.

Comment le confirmer : ouvre le journal d’emails installé pendant le diagnostic. Si les emails sont marqués « envoyés » sans erreur et qu’ils n’arrivent pas, tu es dans ce cas. Autre indice : va dans les réglages de ton plugin de formulaire et regarde l’adresse « De ». Si elle est vide ou ressemble à wordpress@tondomaine.ma sans qu’aucune boîte de ce nom n’existe, l’email part d’une adresse fantôme.

La correction : remplacer la fonction mail() par un envoi SMTP authentifié. Le SMTP (Simple Mail Transfer Protocol) est le protocole standard d’envoi d’emails : ton site se connecte à un vrai serveur de messagerie avec un identifiant et un mot de passe, exactement comme le fait ton téléphone quand tu envoies un email. Le serveur destinataire voit alors un expéditeur identifié, sur un domaine vérifiable. La procédure complète est détaillée plus bas dans la section sur la solution durable, parce qu’elle règle aussi les causes 2, 3 et 4.

Cause 2 : l’adresse « De » n’appartient pas à ton domaine (SPF, DKIM, DMARC)

Si ton formulaire envoie l’email « de la part » du visiteur, en mettant son adresse dans le champ « De », l’email est rejeté. Ton serveur prétend envoyer un message au nom de client@gmail.com, et Gmail sait très bien que ton hébergeur n’est pas autorisé à parler au nom de Gmail. C’est une usurpation d’identité aux yeux des filtres, même si l’intention est innocente.

Trois mécanismes gèrent cette vérification, et il vaut la peine de les comprendre en une phrase chacun.

• SPF (Sender Policy Framework) est un enregistrement DNS de type TXT qui liste les serveurs autorisés à envoyer des emails pour ton domaine.
• DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque email, que le destinataire vérifie grâce à une clé publique publiée dans tes DNS.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) indique au destinataire quoi faire quand SPF ou DKIM échouent : ne rien faire, mettre en quarantaine, ou rejeter.

Depuis 2024, Google impose à tout expéditeur d’authentifier ses emails avec SPF ou DKIM, et exige DMARC pour les gros volumes. Les exigences pour les expéditeurs d’emails publiées par Google sont explicites : sans ces enregistrements, l’email est traité comme suspect. Ce n’est plus une bonne pratique optionnelle, c’est un prérequis.

Symptôme : les emails arrivent en spam ou sont rejetés avec un message du type « 550 SPF check failed » ou « This message was not sent by the domain it claims to be from » visible dans le journal.

Comment le confirmer : regarde le champ « De » du formulaire. Sur Contact Form 7, il affiche d’ailleurs un avertissement orange quand l’adresse n’appartient pas au domaine du site. Ensuite, vérifie tes DNS : un simple nslookup -type=TXT tondomaine.ma dans un terminal, ou l’outil de vérification DNS de ton registrar, te dit si un enregistrement SPF existe.

La correction : mets une adresse de ton domaine dans « De » (contact@tondomaine.ma), et l’adresse du visiteur dans l’en-tête Reply-To. Tu pourras toujours cliquer sur « Répondre » et écrire au visiteur, mais l’email sera envoyé par un expéditeur légitime. Puis publie les enregistrements SPF et DKIM fournis par ton hébergeur, et un DMARC minimal. Je détaille les valeurs exactes dans la section SMTP.

Cause 3 : expéditeur et destinataire identiques (Gmail vers Gmail)

Un cas qui piège énormément de sites vitrines au Maroc : le propriétaire a configuré le formulaire avec son adresse Gmail dans « De » et la même adresse Gmail dans « À ». Résultat, ton serveur d’hébergement envoie à Gmail un email qui prétend venir de Gmail, à destination de ce même compte Gmail. Google le rejette silencieusement ou le classe en spam, parce qu’il sait que cet email n’est pas parti de ses serveurs.

Symptôme : rien n’arrive, jamais, sans erreur visible. Le journal indique « envoyé ». Parfois, les tests envoyés vers une autre adresse (Outlook, adresse pro) arrivent, ce qui rend la panne encore plus déroutante.

Comment le confirmer : ouvre les réglages du formulaire et compare les champs « De » et « À ». Si l’adresse est identique et qu’elle est chez Gmail, Outlook, Yahoo ou n’importe quel fournisseur public, c’est la cause.

La correction : l’expéditeur doit être une adresse de ton domaine. Si tu n’as pas encore d’adresse professionnelle, c’est le moment d’en créer une chez ton hébergeur, cela prend deux minutes et je te montre comment plus bas. Le destinataire, lui, peut rester ton Gmail sans problème. Et si tu tiens absolument à envoyer depuis Gmail, il faut alors configurer le SMTP de Gmail avec un mot de passe d’application, ce qui revient à faire du SMTP authentifié de toute façon.

Cause 4 : l’hébergeur bloque ou limite la fonction mail

Certains hébergeurs mutualisés désactivent purement et simplement la fonction mail() de PHP, ou plafonnent le nombre d’emails envoyés par heure, pour éviter que leurs serveurs soient utilisés pour du spam. D’autres l’autorisent mais routent les emails par une IP partagée régulièrement blacklistée. Dans les deux cas, ton site fait tout correctement et l’email n’existe plus une fois sorti du serveur.

Symptôme : le journal d’emails affiche une erreur explicite du type « Could not instantiate mail function » ou « mail(): Failed to connect », ou bien les emails partent normalement puis cessent d’arriver dès que le site dépasse un certain volume (boutique, inscriptions).

Comment le confirmer : le plus rapide est de lire la documentation ou d’écrire au support de ton hébergeur avec une question précise : « la fonction PHP mail() est-elle active sur mon plan, et quel est le quota d’envoi horaire ? ». Sur les plans mutualisés Hostinger, très répandus au Maroc parce que le paiement se fait facilement en dirhams, l’envoi via PHP est possible mais limité, et l’hébergeur recommande lui-même le SMTP.

La correction : ne cherche pas à débloquer mail(). Passe par le SMTP, qui n’utilise pas du tout cette fonction : ton site se connecte directement au serveur de messagerie de ton domaine, avec ses propres quotas, bien plus généreux pour un usage normal. Pour un site à fort volume (notifications de commandes, newsletters), un service d’envoi transactionnel dédié est plus adapté qu’une boîte email classique.

Cause 5 : le plugin de formulaire est mal configuré

Quand aucune soumission n’est enregistrée, ou quand l’email est envoyé vers nulle part, il faut ouvrir les réglages du plugin. Les erreurs sont toujours les mêmes : un destinataire vide, une balise de champ mal orthographiée, une adresse « De » qui reprend celle du visiteur, ou une notification désactivée après une mise à jour. Voici où regarder sur les quatre plugins que je rencontre le plus.

Contact Form 7

Dans l’onglet « E-mail » du formulaire, vérifie que le champ Pour contient bien ton adresse et non [your-email] (qui désigne l’adresse saisie par le visiteur). Le champ De doit contenir une adresse de ton domaine, par exemple [your-name] <contact@tondomaine.ma>. L’adresse du visiteur va dans En-têtes additionnels sous la forme Reply-To: [your-email]. Contact Form 7 affiche un avertissement de configuration en haut de page quand quelque chose cloche : lis-le, il désigne le champ fautif. Enfin, Contact Form 7 n’enregistre aucune soumission par lui-même. Installe Flamingo, développé par le même auteur, pour conserver chaque message en base.

Elementor Forms

Ouvre le widget Formulaire, section Actions après envoi. L’action « Email » doit être présente, sinon aucun email ne part. Dans l’onglet « Email », vérifie À (ton adresse), Email de l’expéditeur (une adresse de ton domaine, pas le champ email du visiteur) et Répondre à (le champ email du visiteur, sous forme de shortcode [field id="email"]). Ajoute aussi l’action « Collecter les soumissions » pour que chaque message soit enregistré dans Elementor → Soumissions. Si tu as des pages qui affichent une erreur 500 au moment de publier, c’est un autre problème que je traite dans le guide pour corriger l’erreur 500 sur Elementor.

WPForms

Dans le formulaire, va dans Réglages → Notifications. Vérifie que la notification est activée et que Envoyer à l’adresse email contient ton adresse, ou {admin_email} si l’adresse d’administration du site est correcte (Réglages → Général). L’Email de l’expéditeur doit être une adresse de ton domaine. Les entrées sont conservées en base dans la version payante ; en version gratuite, l’email est ta seule trace, ce qui rend le SMTP encore plus indispensable.

Gravity Forms

Va dans Paramètres du formulaire → Notifications. Vérifie que la notification « Admin Notification » est active, que Envoyer à contient une adresse valide et que Email de l’expéditeur n’est pas le champ du visiteur. Gravity Forms enregistre nativement toutes les entrées dans le menu « Entrées » du formulaire, ce qui facilite le diagnostic : si les entrées existent, le formulaire fonctionne et le problème est dans l’envoi.

Sur tous ces plugins, une mise à jour majeure peut réinitialiser ou modifier une notification. Après chaque grosse mise à jour du plugin de formulaire, renvoie un message test. Cela prend trente secondes et évite des semaines de silence.

Cause 6 : un conflit d’extension ou de cache — le bouton ne fait rien

Quand tu cliques sur « Envoyer » et que rien ne se passe, ni confirmation ni erreur, ou que le bouton tourne indéfiniment, l’email n’est pas en cause : le JavaScript du formulaire ne s’exécute pas. Les coupables habituels sont les plugins d’optimisation qui reportent, combinent ou minifient le JavaScript (WP Rocket, LiteSpeed Cache, Autoptimize, Perfmatters), un thème qui charge une version incompatible de jQuery, ou une autre extension qui provoque une erreur JavaScript en amont et bloque tout le reste.

Symptôme : clic sans effet, bouton qui tourne, ou rechargement de la page sans confirmation. Aucune soumission enregistrée, aucun email dans le journal.

Comment le confirmer : ouvre la page du formulaire, appuie sur F12 pour ouvrir les outils du navigateur, onglet « Console », puis clique sur « Envoyer ». Une ligne rouge apparaît : elle nomme le fichier JavaScript en erreur, et donc l’extension concernée. Ensuite, désactive le cache et l’optimisation JavaScript pour cette page uniquement (tous les plugins de cache permettent d’exclure une URL) et refais le test.

La correction : exclus les scripts du plugin de formulaire de l’optimisation (report, combinaison, minification), vide le cache, teste. Si ça ne suffit pas, désactive les extensions une par une jusqu’à trouver la coupable, comme pour n’importe quel conflit WordPress. Si tu débutes avec cette méthode, mon article sur les 15 solutions quand un site WordPress bug explique la procédure d’isolation d’un plugin fautif pas à pas.

Un cas que je vois régulièrement : un cache serveur qui sert une version figée de la page avec un jeton de sécurité (nonce) expiré. Le formulaire est alors rejeté par WordPress avec une erreur de validation, même si tout le reste est correct. La solution est d’exclure la page du cache ou de réduire la durée de vie du cache sur les pages contenant un formulaire.

Cause 7 : reCAPTCHA ou anti-spam trop strict qui rejette les humains

L’anti-spam qui bloque de vrais clients est une panne silencieuse redoutable : le visiteur voit un message d’erreur vague (« Échec de la vérification anti-spam ») ou, pire, une confirmation alors que le message a été jeté. reCAPTCHA v3 attribue un score de confiance à chaque visiteur ; un seuil réglé trop haut rejette les personnes qui naviguent en navigation privée, avec un bloqueur de publicités, ou depuis un réseau mobile partagé, ce qui est extrêmement courant au Maroc.

Symptôme : une partie des visiteurs se plaint de ne pas pouvoir envoyer le formulaire, alors que tes tests fonctionnent depuis ton ordinateur. Ou les soumissions ont chuté brutalement après l’activation d’un anti-spam.

Comment le confirmer : teste le formulaire depuis un téléphone en 4G, en navigation privée, sans être connecté à un compte Google. Puis regarde les clés reCAPTCHA dans les réglages : une clé de site enregistrée pour un autre domaine, ou une clé v2 utilisée sur une intégration v3, fait échouer la vérification systématiquement.

La correction : sur Contact Form 7 (Contact → Intégration), sur Elementor (Elementor → Réglages → Intégrations) ou sur WPForms (Réglages → CAPTCHA), vérifie que les clés correspondent bien à ton domaine et à la bonne version. Si tu utilises reCAPTCHA v3, baisse le seuil de score. Mieux : remplace-le par un honeypot (un champ invisible que seuls les robots remplissent) ou par le pot de miel intégré au plugin. Pour un site vitrine avec quelques demandes par semaine, un honeypot élimine l’essentiel du spam sans jamais gêner un humain.

Cause 8 : requête AJAX bloquée (admin-ajax, CSP, pare-feu)

La plupart des formulaires WordPress envoient les données sans recharger la page, via une requête vers wp-admin/admin-ajax.php ou vers l’API REST (/wp-json/). Contact Form 7 utilise l’API REST, Elementor Forms et WPForms passent par admin-ajax.php. Si cette requête est bloquée, le formulaire ne peut pas aboutir, et selon le plugin, tu verras une erreur ou rien du tout.

Symptôme : erreur « Une erreur s’est produite lors de l’envoi », bouton qui tourne, ou message « 403 Forbidden » dans la console du navigateur.

Comment le confirmer : ouvre les outils du navigateur (F12), onglet « Réseau », clique sur « Envoyer » et regarde la requête vers admin-ajax.php ou wp-json. Un code 403 signale un blocage par un pare-feu ou une règle de sécurité. Un code 0 ou une erreur « blocked by Content Security Policy » désigne un en-tête CSP trop restrictif. Un code 500 renvoie à une erreur PHP côté serveur. Va aussi dans Outils → Santé du site : WordPress y signale explicitement si l’API REST est bloquée.

La correction : selon l’origine du blocage. Si tu utilises Wordfence, iThemes Security ou un pare-feu Cloudflare, cherche l’adresse admin-ajax.php ou /wp-json/contact-form-7/ dans le journal du pare-feu et ajoute une règle d’autorisation. Si tu as ajouté un en-tête Content-Security-Policy dans .htaccess ou via un plugin de sécurité, il doit autoriser les scripts et connexions vers ton propre domaine. Certains hébergeurs appliquent aussi un pare-feu applicatif (ModSecurity) qui bloque les requêtes contenant certains mots ou des liens dans le message : le support peut désactiver la règle concernée.

Si tu es arrivé à ce point sans résultat et que le site est en production, ne cherche pas trois jours de plus. Chaque jour de formulaire cassé, ce sont des demandes réelles qui partent chez un concurrent. Mon service de dépannage WordPress commence par un diagnostic gratuit, et une panne de formulaire se règle généralement en une seule intervention.

Cause 9 : boîte pleine, filtre Gmail, adresse mal orthographiée

C’est la cause la plus bête, et je la mets en dernier parce qu’elle est vite éliminée, pas parce qu’elle est rare. Une boîte email saturée refuse tout nouveau message. Un filtre Gmail créé par erreur archive ou supprime tout ce qui vient du site. Une adresse destinataire avec une faute de frappe (contact@tondomaine.com au lieu de .ma, ou un gmial.com) envoie tout vers un compte qui n’existe pas.

Symptôme : l’email part correctement, le journal indique « envoyé », parfois avec un message de retour (« bounce ») du type « Mailbox full » ou « User unknown » dans la boîte expéditrice.

Comment le confirmer : ouvre la boîte de l’adresse expéditrice (celle de ton domaine) et cherche les messages de retour automatiques. Puis relis l’adresse destinataire caractère par caractère. Enfin, dans Gmail, ouvre Paramètres → Filtres et adresses bloquées et vérifie qu’aucune règle ne touche les emails de ton domaine.

La correction : corrige l’adresse, vide la boîte ou augmente son quota chez l’hébergeur, supprime le filtre fautif. Puis ajoute l’adresse expéditrice du site dans les contacts de la boîte destinataire : Gmail traite beaucoup mieux les emails d’un expéditeur connu.

La solution durable : configurer le SMTP avec l’email de ton domaine

Tout ce qui précède mène ici. Le SMTP authentifié règle définitivement les causes 1 à 4, et c’est la seule configuration que j’accepte de laisser sur un site client en production. La procédure prend une vingtaine de minutes la première fois, et tu n’auras plus jamais à y revenir. Je la décris avec WP Mail SMTP, le plugin le plus utilisé, mais FluentSMTP ou Post SMTP suivent exactement la même logique.

Étape 1 : créer une adresse email sur ton domaine

Si ton site est chez Hostinger, connecte-toi à hPanel, ouvre la section Emails, choisis ton domaine, puis Créer un compte email. Nomme-le contact@tondomaine.ma (ou site@, noreply@), choisis un mot de passe fort et note-le. Sur cPanel (Nindohost, Genious, la plupart des hébergeurs marocains), la démarche est identique dans Comptes de messagerie. Une fois l’adresse créée, l’hébergeur affiche les paramètres de connexion : serveur SMTP sortant, port et type de chiffrement. Sur Hostinger, c’est smtp.hostinger.com, port 465 en SSL.

Si ton domaine utilise Google Workspace pour ses emails, tu peux utiliser le SMTP de Google avec un mot de passe d’application. Le principe reste le même : une adresse réelle, sur ton domaine, avec un mot de passe.

Étape 2 : installer et configurer WP Mail SMTP

Dans WordPress, va dans Extensions → Ajouter, cherche « WP Mail SMTP », installe et active. Ouvre ensuite le menu WP Mail SMTP → Réglages et remplis les champs suivants.

1. Adresse email d’expédition : l’adresse que tu viens de créer (contact@tondomaine.ma). Coche Forcer l’adresse email d’expédition pour que tous les plugins l’utilisent, même ceux qui sont mal configurés.
2. Nom de l’expéditeur : le nom de ton entreprise, en cochant également l’option pour le forcer.
3. Mailer : choisis Autre SMTP.
4. Hôte SMTP : le serveur fourni par ton hébergeur (smtp.hostinger.com par exemple).
5. Chiffrement : SSL avec le port 465, ou TLS avec le port 587, selon ce qu’indique ton hébergeur.
6. Authentification : activée. Identifiant : l’adresse email complète. Mot de passe : celui du compte email.
7. Enregistre, puis ouvre l’onglet Test d’email et envoie un test vers une adresse Gmail que tu contrôles.

Si le test échoue, le plugin affiche l’erreur exacte renvoyée par le serveur : mot de passe incorrect, port bloqué, certificat invalide. Ces messages sont explicites et suffisent généralement à corriger. Un port 465 bloqué par l’hébergeur se contourne souvent en passant au 587 en TLS.

Un mot sur le stockage du mot de passe : par défaut, il est enregistré dans la base de données. Pour un site sensible, WP Mail SMTP permet de le définir dans wp-config.php via une constante, ce qui est plus propre. Pour un site vitrine, la base suffit.

Étape 3 : publier SPF, DKIM et DMARC

Le SMTP authentifie ton envoi ; SPF, DKIM et DMARC prouvent au destinataire que le serveur qui envoie est bien autorisé par ton domaine. Sans eux, un email SMTP correct peut encore finir en spam. Les enregistrements se créent dans la zone DNS de ton domaine, chez ton registrar ou dans hPanel si les DNS sont chez Hostinger.

• SPF : un enregistrement TXT sur le domaine racine. Ton hébergeur fournit la valeur exacte ; elle ressemble à v=spf1 include:_spf.mail.hostinger.com ~all. Un seul enregistrement SPF par domaine : si tu envoies aussi via Google Workspace, les deux include vont dans la même ligne. La documentation Google sur SPF explique la syntaxe clairement.
• DKIM : l’hébergeur génère une clé et te donne un enregistrement TXT (ou CNAME) à publier sur un sous-domaine du type sélecteur._domainkey.tondomaine.ma. Sur Hostinger, il est proposé directement dans la section Emails.
• DMARC : un enregistrement TXT sur _dmarc.tondomaine.ma avec la valeur v=DMARC1; p=none; rua=mailto:contact@tondomaine.ma. La politique p=none ne bloque rien, elle te fait seulement recevoir des rapports. C’est le bon point de départ ; tu pourras passer à quarantine une fois sûr que tout est authentifié.

Compte quelques minutes à quelques heures de propagation DNS. Ensuite, envoie un email depuis le formulaire vers une adresse Gmail, ouvre-le, clique sur « Afficher l’original » : tu dois voir SPF, DKIM et DMARC marqués « PASS ». C’est le contrôle final. Si l’un des trois échoue, l’enregistrement correspondant est mal saisi ou pas encore propagé.

Étape 4 : tester depuis le vrai formulaire

Le test du plugin valide la connexion SMTP, pas le formulaire. Envoie donc un message réel depuis chaque formulaire du site (contact, devis, rappel), vérifie qu’il arrive dans la boîte principale et non en spam, que le bouton « Répondre » vise bien l’adresse du visiteur, et que la soumission est enregistrée en base. Note la date : c’est le premier point de ta routine de test mensuelle.

Tableau récapitulatif : symptôme, cause probable, correction

Ce tableau condense tout le guide. Si tu n’as que deux minutes, pars de ton symptôme.

Symptôme observé	Cause probable	Correction
Confirmation affichée, soumission enregistrée, aucun email reçu	Envoi via PHP mail() sans authentification (cause 1)	Installer WP Mail SMTP, envoyer depuis une adresse du domaine
Emails reçus en spam ou une fois sur trois	Adresse « De » hors domaine, SPF/DKIM absents (cause 2)	Adresse « De » sur le domaine, visiteur en Reply-To, publier SPF, DKIM, DMARC
Rien n’arrive, expéditeur et destinataire sont la même adresse Gmail	Envoi Gmail vers Gmail depuis un serveur tiers (cause 3)	Créer une adresse sur le domaine comme expéditeur
Erreur « mail function » dans le journal, ou arrêt après un certain volume	Hébergeur qui bloque ou limite mail() (cause 4)	SMTP authentifié ; service transactionnel si fort volume
Aucune soumission, aucune notification	Destinataire vide, notification désactivée, champ mal orthographié (cause 5)	Vérifier « Pour », « De », Reply-To et l’action email du plugin
Le bouton ne fait rien ou tourne sans fin	Conflit JavaScript, cache, optimisation (cause 6)	Exclure les scripts du formulaire de l’optimisation, isoler l’extension fautive
Certains visiteurs ne peuvent pas envoyer, toi si	reCAPTCHA ou anti-spam trop strict (cause 7)	Vérifier les clés, baisser le seuil, préférer un honeypot
Erreur 403 ou « blocked » dans la console	Requête AJAX ou REST bloquée par pare-feu, CSP, ModSecurity (cause 8)	Autoriser admin-ajax.php et /wp-json/ dans le pare-feu
Journal « envoyé », message de retour « Mailbox full » ou « User unknown »	Boîte pleine, filtre, faute de frappe (cause 9)	Corriger l’adresse, vider la boîte, supprimer le filtre

Comment ne plus jamais perdre une demande de client

Réparer le formulaire est nécessaire, mais insuffisant. L’email est un canal fragile par construction : un changement de politique chez Google, une IP blacklistée, un mot de passe expiré, et le silence recommence. La bonne approche consiste à ne plus dépendre d’un seul canal, et à savoir immédiatement quand l’un d’eux tombe.

Voici ce que je mets en place sur les sites que je livre ou que je reprends en maintenance.

• Enregistrer chaque soumission en base. Flamingo pour Contact Form 7, l’action « Collecter les soumissions » sur Elementor Pro, les entrées natives de Gravity Forms ou WPForms Pro. Tant que le message existe dans WordPress, aucune demande n’est perdue, même si l’email échoue.
• Envoyer vers deux adresses. Une adresse principale et une adresse de secours sur un autre fournisseur (par exemple l’adresse du domaine et un Gmail). Dans le champ « Pour », les deux adresses sont séparées par une virgule. Si l’une tombe, l’autre reçoit.
• Ajouter une notification WhatsApp pour les activités où la réactivité fait la vente : restaurants, riads, salons, artisans, transporteurs. Un plugin ou une automatisation relaie chaque soumission vers ton numéro. Au Maroc, WhatsApp est souvent lu avant l’email, et une demande de réservation répondue en dix minutes se convertit bien mieux qu’une réponse le lendemain.
• Tester le formulaire une fois par mois. Un message réel, depuis un téléphone, avec vérification de réception. Mets un rappel dans ton agenda. C’est le test le plus rentable de toute ta maintenance.
• Surveiller les rapports DMARC. Les rapports envoyés à l’adresse rua te signalent quand un email de ton domaine échoue à l’authentification. Tu n’as pas besoin de les lire chaque semaine, mais un pic d’échecs est un signal d’alarme.

Le cas qui m’a le plus marqué est celui d’un salon de coiffure à Marrakech qui prenait ses réservations par un formulaire Elementor. Après une mise à jour de plugin, l’action email avait disparu du formulaire. Pendant environ trois semaines, les clientes recevaient « Merci, votre demande a bien été envoyée » et personne au salon ne voyait rien. C’est une cliente fidèle qui a fini par appeler pour se plaindre de ne pas avoir de réponse. Les soumissions étaient toujours là, dans Elementor → Soumissions, parce que la collecte était activée : le salon a pu rappeler chaque personne. Sans cet enregistrement, ces demandes auraient disparu sans laisser de trace. Depuis, je considère la collecte en base comme obligatoire, pas comme une option.

Un autre cas récurrent : une petite agence immobilière dont les emails de formulaire arrivaient chez le gérant mais jamais chez l’assistante. Le formulaire envoyait vers les deux adresses depuis une adresse Gmail dans « De ». Le gérant utilisait Outlook, qui laissait passer ; l’assistante utilisait Gmail, qui rejetait le Gmail-vers-Gmail. Personne n’avait fait le lien, et l’assistante pensait simplement que le site ne générait pas de demandes. Vingt minutes de SMTP et un SPF ont réglé ce qui durait depuis des mois.

Cas particuliers : multilingue, WooCommerce, hébergement au Maroc ou à l’étranger

Les neuf causes s’appliquent partout, mais trois situations ajoutent leurs propres pièges.

Formulaire sur un site multilingue

Sur un site en français, arabe et anglais géré avec WPML ou Polylang, chaque langue possède souvent sa propre copie du formulaire. C’est la copie arabe ou anglaise qui est la plus souvent cassée, parce qu’elle a été dupliquée une fois puis oubliée : destinataire d’origine, action email absente, clés reCAPTCHA non reportées. Teste chaque version linguistique séparément, et si le plugin le permet, utilise un seul formulaire avec des libellés traduits plutôt que trois formulaires distincts. Vérifie aussi que l’encodage du sujet de l’email gère l’arabe : un sujet en caractères illisibles est un symptôme d’en-tête mal encodé, pas d’un email non envoyé.

WooCommerce et les emails de commande

Les emails de WooCommerce (nouvelle commande, confirmation, facture) passent par la même fonction wp_mail() que ton formulaire. Si le formulaire n’envoie pas, tes clients ne reçoivent probablement pas non plus leurs confirmations de commande, ce qui génère des appels, des litiges et des avis négatifs. La configuration SMTP corrige les deux d’un coup. Vérifie ensuite dans WooCommerce → Réglages → Emails que chaque notification est activée et que l’adresse « De » est bien celle du domaine. Pour une boutique qui envoie plusieurs dizaines d’emails par jour, le SMTP d’une boîte classique peut atteindre le quota de l’hébergeur : un service d’envoi transactionnel devient alors le bon choix. Si tu lances une boutique, mon guide pour créer un site e-commerce au Maroc aborde cette question dès la phase de conception.

Site hébergé au Maroc ou à l’étranger

L’emplacement du serveur ne change rien aux règles d’authentification : Gmail applique les mêmes exigences à un email venant de Casablanca ou de Francfort. Ce qui change, c’est la réputation de l’IP partagée et la réactivité du support. Certains petits hébergeurs, au Maroc comme ailleurs, ont des IP régulièrement blacklistées parce qu’un site voisin envoie du spam ; le SMTP avec ton propre domaine te protège en partie, mais si l’IP du serveur SMTP lui-même est listée, seul un changement d’hébergeur ou un service transactionnel règle le problème. Si tu es en train de choisir, mon comparatif des hébergeurs web au Maroc tient compte de la qualité de l’envoi d’emails. Et si tu pars d’une page blanche, autant intégrer le SMTP dès le premier jour : c’est une des règles que j’applique sur chaque création de site WordPress, au même titre que les sauvegardes.

Ce que tu dois faire maintenant

Fais le diagnostic en 5 minutes, sans exception : un test réel, le dossier spam, le journal de soumissions, le journal d’emails. Tu sauras si l’email part ou non, et le tableau récapitulatif te donnera la cause en une ligne. Ensuite, quelle que soit la cause trouvée, configure le SMTP avec une adresse de ton domaine et publie SPF, DKIM et DMARC : c’est ce qui empêche la panne de revenir. Termine par la collecte des soumissions en base et une seconde adresse de réception.

Si tu préfères que quelqu’un s’en charge, ou si ton site perd des demandes en ce moment même, envoie-moi les accès et une description du symptôme via la page de contact de ton développeur WordPress freelance. Le diagnostic est gratuit, et la plupart des formulaires sont de nouveau opérationnels le jour même.