Contact Form 7 n'envoie pas d'e-mail : l'écart entre formulaire envoyé et message reçu

Le message vert « votre message a bien été envoyé » de Contact Form 7 indique que le formulaire a atteint le serveur, pas que l'e-mail est arrivé dans votre boîte de réception. Les deux étapes reposent sur des systèmes différents : WordPress gère la première, la fonction d'envoi d'e-mails du serveur ou un service SMTP gère la seconde.

C'est ainsi qu'une entreprise qui fait de la publicité peut croire pendant des semaines que le formulaire « fonctionne » sans recevoir une seule demande de devis. Google Ads affiche zéro conversion, le budget est réduit, alors que le vrai problème se situe dans la couche e-mail.

La cause la plus fréquente : la fonction d'envoi par défaut de WordPress expédie sans authentification, et le serveur destinataire la traite comme du spam ou la refuse purement et simplement. La deuxième : une adresse d'expéditeur (« From ») qui ne correspond pas à votre domaine ; SPF et DKIM échouent et l'e-mail est rejeté.

La troisième : l'hébergeur bloque le port d'envoi des e-mails ; la quatrième : des balises de champ cassées dans le modèle d'e-mail après une mise à jour d'extension. Chacune présente un symptôme différent et doit être écartée dans l'ordre.

D'abord, remplissez et envoyez vous-même le formulaire, puis attendez cinq minutes ; vérifiez aussi le dossier spam. Si l'e-mail est arrivé dans les spams, le problème vient de l'authentification : installez une extension SMTP, définissez un compte expéditeur qui correspond à votre domaine et ajoutez les enregistrements SPF et DKIM.

Si aucun e-mail n'arrive, consultez le journal des e-mails dans votre panneau d'hébergement ; une entrée du type « mail_failed » signifie que le serveur refuse d'envoyer, et un service SMTP est alors la seule solution durable. Si le journal est propre, vérifiez le modèle du formulaire : adresse du destinataire, ligne d'objet et balises de champ dans le corps du message.

Toucher au suivi des conversions avant d'avoir réparé l'e-mail inverse l'ordre ; assurez-vous d'abord que la demande vous parvient. Passez ensuite à la mesure : Contact Form 7 déclenche un événement navigateur lors d'un envoi réussi, et il vous faut dans Tag Manager un déclencheur qui l'écoute ainsi qu'une balise qui envoie un événement à GA4.

Avec le connecteur Tecrube, cette étape se termine dans le chat : « crée dans GTM un déclencheur et une balise d'événement GA4 pour l'envoi de Contact Form 7, marque l'événement comme conversion dans GA4 et associe GA4 à mon compte Google Ads ». Chaque partie arrive sous forme d'aperçu et s'applique après votre validation ; la publication de la version GTM est une étape distincte avec son propre aperçu et sa validation, et vous finalisez l'importation de la conversion côté Google Ads.

Dans ce cas, le formulaire et la mesure fonctionnent, mais le pont manque. Pour qu'une conversion GA4 atteigne le compte Google Ads, les deux comptes doivent être associés et la conversion doit être importée côté Google Ads. Demander dans le chat « liste les conversions importées de GA4 dans Google Ads » révèle l'écart en un coup d'œil.

Si la stratégie d'enchères de la campagne dépend de cette conversion, prévoyez deux semaines d'apprentissage une fois que les conversions commencent à remonter ; modifier le budget pendant cette période réinitialise l'apprentissage.

Remplissez vous-même le formulaire une fois par mois et vérifiez en trois étapes que l'e-mail arrive, que l'événement apparaît dans GA4 et que la conversion apparaît dans Google Ads. Dans Tecrube, les deux dernières étapes tiennent en une seule question et, comme il s'agit de lectures, ne consomment aucun crédit.

Refaites le test après chaque mise à jour d'extension ou de thème ; la plupart des pannes de formulaire commencent dans la semaine qui suit une mise à jour et passent inaperçues pendant un mois.

Associer le test à un créneau du calendrier, comme le premier lundi de chaque mois, évite de l'oublier ; une vérification de dix minutes est l'assurance la moins chère contre un mois de demandes perdues.

Si votre envoi de test revient marqué comme « spam », le formulaire n'est pas cassé ; c'est la protection antispam qui fonctionne. reCAPTCHA, Akismet ou un champ pot de miel ont peut-être pris votre test pour un robot. La solution n'est pas de désactiver la protection, mais de vérifier son seuil et de refaire le test depuis un vrai navigateur, en remplissant le formulaire à un rythme normal.

Pour savoir si de vrais clients sont eux aussi signalés, consultez les enregistrements de spam de l'extension. Si des dizaines de demandes de devis rédigées sous de vrais noms se sont accumulées dans les spams en une semaine, la protection est trop stricte et vous coûte des conversions. Assouplissez le seuil et observez pendant quelques jours.

Après avoir modifié le réglage antispam, vérifiez aussi le volet mesure. Les envois marqués comme spam ne produisent aucun événement GA4 ; tant que la protection est trop stricte, le nombre de conversions dans GA4 et Google Ads est donc inférieur à la réalité. Si les conversions bondissent la semaine qui suit l'assouplissement du réglage, c'est la mesure qui se corrige, pas un succès de campagne ; gardez-le en tête en lisant la stratégie d'enchères.