Formulaire de contact WordPress ne fonctionne pas : un symptôme qui trompe
Un formulaire de contact WordPress qui ne fonctionne pas ne se comporte presque jamais comme une panne classique. Le visiteur clique sur « Envoyer », voit un message de confirmation, ferme la page — et le message n’arrive jamais dans la boîte mail du destinataire. Aucune erreur affichée, aucun code HTTP anormal, rien dans les journaux du plugin de formulaire : le symptôme le plus fréquent n’est pas un blocage visible, c’est un silence.
Cette particularité change la méthode de diagnostic. Sur une erreur 500 ou une page blanche, le site indique lui-même qu’il y a un problème. Sur un formulaire muet, WordPress affiche une réussite alors que l’envoi a échoué plus loin dans la chaîne — entre le serveur qui traite la soumission et la boîte mail qui devrait la recevoir. Le diagnostic doit donc suivre cette chaîne étape par étape, pas se contenter de relire la configuration du formulaire.
Les quatre causes qui expliquent 90 % des cas
Le serveur mail n’est pas configuré correctement (cause la plus fréquente). La fonction mail() de PHP, utilisée par défaut par WordPress et par de nombreux plugins de formulaire, envoie le message directement depuis le serveur d’hébergement sans authentification. Les fournisseurs de messagerie (Gmail, Outlook, et la plupart des filtres anti-spam d’entreprise) rejettent silencieusement ces envois non authentifiés, ou les classent en spam sans notification à l’expéditeur. Le formulaire « fonctionne » du point de vue de WordPress — l’appel à mail() ne renvoie pas d’erreur — mais le message n’est jamais délivré.
Un conflit de plugin bloque la soumission côté JavaScript. Un plugin de cache agressif, un plugin de sécurité, ou un simple conflit entre deux extensions peut interrompre le script qui envoie la requête AJAX du formulaire avant qu’elle n’atteigne le serveur. Symptôme typique : le bouton d’envoi tourne indéfiniment ou le message de confirmation apparaît sans qu’aucune requête réseau ne soit visible dans la console du navigateur.
Le cache de page sert une version obsolète du formulaire. Un plugin de cache qui met en cache le nonce de sécurité WordPress (le jeton anti-CSRF généré à chaque chargement de page) fait échouer la validation côté serveur dès que ce nonce a expiré — en général après quelques heures. Le visiteur voit un message d’erreur générique ou, pire, aucune erreur du tout si le plugin de formulaire ne relaie pas la réponse serveur correctement.
Le service tiers de protection anti-spam bloque l’envoi. reCAPTCHA, hCaptcha ou un plugin anti-spam mal configuré (mauvaise clé API, domaine non autorisé côté Google) peut faire échouer silencieusement la validation du formulaire — le visiteur ne voit jamais l’échec, il pense simplement avoir envoyé son message.
Étape 1 : confirmer que le problème est bien la livraison, pas la saisie
Avant de chercher plus loin, il faut isoler où la chaîne se rompt. Ouvrir la console développeur du navigateur (F12 → onglet Réseau) et soumettre le formulaire soi-même : si aucune requête n’apparaît, le blocage est côté JavaScript (cause 2). Si une requête part et reçoit une réponse HTTP 200, le blocage se situe après — côté serveur mail (cause 1) ou côté anti-spam (cause 4).
Ce test simple élimine d’emblée la moitié des hypothèses et évite de passer du temps à reconfigurer un service SMTP alors que le problème est en réalité un plugin de cache qui bloque la requête avant qu’elle n’atteigne le serveur.
Étape 2 : remplacer mail() par un envoi SMTP authentifié
C’est la correction qui résout la cause la plus fréquente. Un plugin comme WP Mail SMTP (ou l’équivalent fourni nativement par certains plugins de formulaire) permet de faire transiter les envois par un vrai compte SMTP authentifié — celui de l’hébergement email du site, ou un service dédié à l’envoi transactionnel. Contrairement à mail(), un envoi SMTP authentifié passe les vérifications SPF et DKIM des fournisseurs de messagerie, ce qui élimine l’essentiel des rejets silencieux.
Le choix de la solution email dépend directement de l’offre d’hébergement en place : certains hébergeurs mutualisés limitent le nombre d’envois sortants par heure ou bloquent purement mail() pour lutter contre le spam sortant, ce qui explique pourquoi le même formulaire fonctionne parfaitement sur un hébergement et pas sur un autre. Le comparatif des solutions d’hébergement email professionnel détaille les critères à vérifier avant de choisir une offre compatible avec un envoi SMTP fiable.
Après configuration, la plupart des plugins de formulaire proposent un test d’envoi intégré : l’utiliser systématiquement avant de considérer le problème résolu, plutôt que d’attendre le prochain message d’un visiteur réel.
Étape 3 : exclure le formulaire du cache
Si le test de l’étape 1 montre une requête réseau qui échoue par intermittence (fonctionne parfois, pas d’autres fois), le cache de page est la cause la plus probable. La plupart des plugins de cache (WP Rocket, W3 Total Cache, LiteSpeed Cache) proposent une option d’exclusion par page ou par identifiant de formulaire — à activer sur la page de contact spécifiquement, plutôt que de désactiver le cache pour tout le site. Vider ensuite le cache existant pour forcer la régénération d’un nonce à jour.
Étape 4 : vérifier la configuration anti-spam
Si le formulaire utilise reCAPTCHA ou hCaptcha, contrôler dans la console d’administration du service (Google reCAPTCHA admin ou dashboard hCaptcha) que le domaine exact du site — avec et sans www selon la configuration — figure bien dans la liste des domaines autorisés. Un changement de domaine, de sous-domaine, ou une migration vers HTTPS après l’enregistrement initial des clés est une cause fréquente et facile à manquer : les clés restent valides mais rejettent silencieusement les requêtes venant d’un domaine non déclaré.
Distinguer d’un plugin de formulaire cassé après une mise à jour
Un cas distinct mérite d’être écarté avant de suivre les quatre étapes précédentes : si le formulaire a cessé de fonctionner immédiatement après une mise à jour de plugin ou de thème, le problème est plus probablement un conflit direct de code (fonction dépréciée, hook modifié) qu’un problème de livraison mail. Dans ce cas, désactiver temporairement les autres plugins un par un pour isoler le conflit est plus rapide que de suivre la chaîne de diagnostic mail — la méthode de désactivation ciblée déjà détaillée pour d’autres blocages WordPress, comme dans l’article sur l’erreur 500 WordPress, s’applique de la même façon ici.
Un formulaire qui se met soudainement à envoyer des volumes anormaux de soumissions, ou qui redirige vers un domaine inconnu après l’envoi, n’est en revanche pas un problème de configuration mais un signe de compromission : la marche à suivre est alors celle décrite dans l’article site WordPress piraté, que faire dans l’urgence, pas les correctifs de cet article.
Vérifier après coup, pas seulement au moment du test
Un formulaire réparé aujourd’hui peut recommencer à échouer silencieusement après une mise à jour de plugin, un changement d’hébergeur ou l’expiration d’une clé API — sans qu’aucune alerte ne prévienne. Programmer un test d’envoi mensuel (calendrier, ou fonctionnalité de test automatique si le plugin de formulaire la propose) reste la seule façon fiable de détecter une régression avant qu’un client ou un prospect ne l’apprenne à sa place. Avant toute intervention plus lourde sur la configuration du site, s’assurer qu’une sauvegarde récente existe reste la précaution de base, comme pour toute modification touchant plugins ou configuration serveur.