Plugin formulaire de contact WordPress : gardez vos messages
Un formulaire de contact WordPress qui écrit chaque message en base avant de tenter l'email : si l'email se perd, le message reste. Gratuit, sans CAPTCHA.
Un visiteur remplit votre formulaire de contact, clique sur Envoyer, lit « Merci, votre message a bien été envoyé »… et vous ne le recevez jamais. L’email est parti en spam, ou n’est jamais parti du tout. Pour lui, vous n’avez pas répondu ; pour vous, il n’a jamais existé. Ce scénario est courant, et il a une cause précise : le message n’a été confié qu’à un email. Le module Forms de Blaminhor Essentials prend le chemin inverse — il écrit d’abord, il envoie ensuite.
L’essentiel
- Contact Form 7 n’enregistre rien par défaut : le message part par email, et si l’email échoue, il est perdu. Il faut lui ajouter Flamingo (son compagnon officiel) ou un plugin de base de données.
- WPForms Lite envoie par email ; la consultation des entrées dans WordPress est réservée à la version payante — c’est ce que Google AI Overview répond lui-même, le 8 septembre 2026, à qui cherche le meilleur formulaire gratuit.
- Dans le module Forms, l’enregistrement en base est une case cochée par défaut (Keep each submission in the database), et il précède toute tentative d’email.
- Anti-spam sans CAPTCHA : champ piège invisible, jeton horodaté signé, limite de débit par adresse IP hachée. reCAPTCHA et Cloudflare Turnstile restent possibles, en option.
- RGPD : adresse IP jamais stockée sauf demande explicite (et alors hachée), durée de conservation réglable par formulaire avec purge quotidienne, case de consentement jamais pré-cochée.
Où vont les messages envoyés par Contact Form 7 ?
Par défaut, les messages envoyés par Contact Form 7 ne vont nulle part d’autre que dans un email : le plugin transmet le contenu à la fonction d’envoi de WordPress, puis l’oublie. Il ne conserve aucune copie en base de données. Si l’email tombe en spam ou n’est jamais expédié, le message est définitivement perdu.
Ce comportement est voulu. Contact Form 7 est gratuit, sans version payante ni upsell, et son auteur a volontairement gardé le plugin minimal : un formulaire, un email. Pour la conservation, il a écrit un second plugin gratuit, Flamingo, qui intercepte chaque soumission et la stocke dans WordPress sous forme de contenu personnalisé (un « custom post type », c’est-à-dire un type de contenu comme les articles ou les pages, mais réservé aux messages). Des plugins tiers comme CFDB7 ou Form Vibes font la même chose. Tant que l’un d’eux n’est pas installé, chaque message repose sur un seul fil : l’email.
Le point aveugle, c’est que rien ne vous prévient : l’absence de message ressemble exactement à l’absence de visiteurs. On découvre le problème des semaines plus tard, quand quelqu’un vous écrit par un autre canal : « je vous ai contacté deux fois via votre site ».
Pourquoi l’email d’un formulaire se perd-il si souvent ?
L’email d’un formulaire se perd parce que WordPress l’envoie, par défaut, avec la fonction mail() de PHP : un envoi non authentifié, depuis un serveur mutualisé partagé avec des centaines de sites, sans les signatures que Gmail et Outlook exigent aujourd’hui. Résultat : boîte spam, ou rejet silencieux.
Trois causes reviennent dans la quasi-totalité des cas :
- L’hébergeur bloque ou bride
mail()— certains mutualisés le désactivent, d’autres limitent les envois par heure. Le formulaire, lui, affiche « envoyé » quoi qu’il arrive. - Le domaine n’est pas authentifié : sans SPF, DKIM et DMARC — les trois signatures détaillées dans le guide de délivrabilité email WordPress —, les grandes messageries classent l’email comme suspect.
- L’expéditeur est usurpé par le formulaire lui-même : envoyer « de la part de » l’adresse du visiteur, depuis votre serveur, déclenche exactement les protections anti-usurpation des messageries.
La solution côté email est connue : passer par un vrai serveur SMTP — le protocole d’envoi authentifié qu’utilise votre messagerie — avec un relais qui signe vos emails. Mais elle ne suffit pas seule. Un SMTP bien réglé réduit les pertes ; il ne les annule pas — un quota dépassé, un relais en panne une heure, une règle de filtrage trop zélée, et le message disparaît à nouveau. La seule garantie, c’est une copie qui ne dépend pas de l’email.
Comment le module Forms de Blaminhor Essentials garde-t-il chaque message ?
Le module Forms de Blaminhor Essentials enregistre la soumission dans une table dédiée de votre base de données, puis tente l’email de notification, l’auto-répondeur et le webhook — dans cet ordre. L’enregistrement est activé par défaut (case « Keep each submission in the database ») et chaque message apparaît dans un écran Entrées, avec un statut non lu, lu ou spam.
J’ai écrit ce module en partant de cette faille : dans le code, l’écriture en base précède l’appel à la notification, et l’email passe ensuite par la fonction standard de WordPress — donc par le module SMTP du même plugin s’il est actif. Concrètement, quand un visiteur envoie le formulaire :
- Le jeton de sécurité (le « nonce », qui prouve que l’envoi vient bien de votre site) est vérifié, puis les champs sont validés côté serveur.
- Le contrôle anti-spam s’exécute ; une soumission suspecte est conservée avec le statut Spam mais n’envoie aucun email.
- L’entrée est écrite en base, avec la date, le statut Non lu, et les valeurs de chaque champ.
- L’email de notification part vers l’adresse de votre choix, avec l’adresse du visiteur en Répondre à — vous répondez d’un clic.
- L’auto-répondeur (s’il est activé) confirme la réception au visiteur ; le webhook (s’il est configuré) transmet l’entrée à vos outils — un envoi automatique vers une adresse web de votre choix, pour Zapier, Make ou n8n.
Si l’étape 4 échoue, le module l’écrit dans son journal — et l’étape 3 a déjà eu lieu.

L’écran Entrées de chaque formulaire affiche le compte de messages non lus, permet de filtrer par statut, de marquer lu ou spam, et d’exporter l’ensemble en CSV (un fichier tableur, ouvrable dans Excel ou Numbers). Avec WP-CLI, l’outil en ligne de commande de WordPress, wp blaminhor forms resend-notification <id> renvoie l’email d’un message stocké — typiquement après avoir réparé un SMTP défaillant.
Que voit-on réellement quand on coupe l’email ?
Faites le test sur un site de démonstration : réglez volontairement un SMTP avec un mot de passe faux, envoyez un message via le formulaire, puis ouvrez l’écran des entrées. Le message y est, statut Non lu, alors qu’aucun email n’est parti — le journal du plugin note simplement l’échec de la notification.
L’expérience tient en cinq minutes :
- Activez le module Forms et créez un formulaire depuis le modèle Contact.
- Dans le module SMTP Mailer, saisissez un mot de passe erroné — l’envoi échouera à coup sûr.
- Remplissez le formulaire en prenant votre temps (le contrôle anti-spam attend au moins deux secondes) et envoyez.
- La confirmation s’affiche ; votre boîte reste vide ; l’écran Entrées affiche 1 non lu.
- Corrigez le mot de passe, relancez l’email avec la commande de renvoi : cette fois, il arrive.

Chaque ligne se déplie sur place pour montrer les valeurs soumises, champ par champ, consentement compris — pas de page intermédiaire à ouvrir.
Refaites les étapes 2 à 4 avec Contact Form 7 sans Flamingo : même confirmation, même boîte vide, et aucun écran où regarder. Avec Contact Form 7 seul, ce message n’existe plus nulle part ; avec le module Forms, il attend dans l’écran des entrées.
Que se passe-t-il quand l’email échoue, selon le plugin ?
| Plugin (version gratuite) | Le message est-il stocké dans WordPress ? | Si l’email échoue… | Pour stocker, il faut… |
|---|---|---|---|
| Contact Form 7 | Non | Le message est perdu | Flamingo (officiel, gratuit) ou un plugin tiers de base de données |
| WPForms Lite | Non (entrées réservées à la version payante) | Le message est perdu | Passer à WPForms Pro |
| Ninja Forms, Formidable Forms, Fluent Forms | Oui | Le message reste consultable | Rien : inclus |
| Module Forms de Blaminhor Essentials | Oui, avant même la tentative d’email | Le message est en base, statut Non lu, journal de l’échec, renvoi possible en WP-CLI | Rien : coché par défaut |
Les lignes Contact Form 7 et WPForms Lite reprennent ce que répondent les moteurs à assistant IA le 8 septembre 2026 : Google AI Overview précise, à propos de WPForms Lite, que la sauvegarde des entrées « directement dans votre tableau de bord WordPress nécessite une mise à niveau payante ou un module complémentaire » ; Brave résume Contact Form 7 de la même façon. Ce sont deux produits honnêtes qui ont fait deux choix d’architecture différents — l’un minimal, l’autre freemium.
Faut-il un CAPTCHA pour protéger un formulaire de contact du spam ?
Non : le module Forms protège chaque formulaire par trois contrôles invisibles — un champ piège que seuls les robots remplissent (« honeypot »), un jeton horodaté signé qui rejette toute soumission envoyée en moins de deux secondes, et une limite de dix envois par heure par adresse IP hachée (transformée en empreinte irréversible). Aucune grille d’images, aucune case « je ne suis pas un robot ».
C’est la même approche que le module Anti-Spam du plugin, intégrée directement au formulaire : le module Anti-Spam peut être désactivé, le formulaire reste protégé. Le champ piège est masqué aux lecteurs d’écran comme aux yeux, pour qu’un utilisateur aveugle ne tombe pas dessus — un défaut que d’autres plugins anti-spam ont dû corriger après coup.
Le délai minimal vaut deux secondes par défaut et se règle formulaire par formulaire, et le compteur de débit ne garde qu’une empreinte hachée dans une valeur temporaire de WordPress (un « transient ») qui expire seule. Si votre site subit un spam humain, payé à la tâche, ajoutez un champ reCAPTCHA (v2 ou v3) ou Cloudflare Turnstile : il se place comme n’importe quel champ, les clés se saisissent une fois dans les réglages du module, et la vérification a toujours lieu côté serveur. Une seconde couche visible, jamais une obligation.
Comment rester conforme au RGPD avec des messages stockés en base ?
Stocker les messages crée un traitement de données personnelles, et le module Forms le traite comme tel : adresse IP jamais enregistrée par défaut (et seulement hachée si vous l’activez), durée de conservation réglable par formulaire avec purge automatique quotidienne, case de consentement jamais pré-cochée, export et suppression à portée de clic.

Le réglage Delete entries after accepte un nombre de jours ; à zéro, les entrées sont gardées indéfiniment, sinon une tâche planifiée passe chaque jour et efface, formulaire par formulaire, les entrées plus anciennes que la fenêtre choisie : trente jours pour un formulaire de contact, indéfiniment pour un formulaire de commande, sans que l’un efface les données de l’autre.
Une confusion mérite d’être levée au passage, parce qu’elle porte sur deux réglages qui se ressemblent. Côté formulaire, il n’y a rien à activer : l’enregistrement des soumissions est coché d’origine. Le réglage volontairement éteint par défaut se trouve ailleurs, dans le module SMTP : Store email content conserve le corps complet de chaque email journalisé, pour le relire et le renvoyer depuis le tableau de bord. Il reste éteint parce qu’un corps d’email contient couramment les données personnelles de tiers : l’activer, c’est accepter d’en devenir responsable — informer les personnes concernées, honorer les demandes d’effacement. Le journal de livraison seul suffit à diagnostiquer un envoi qui échoue, et le renvoi d’une notification de formulaire ne dépend pas de ce réglage : il reconstruit l’email à partir de l’entrée stockée.
Le champ Consentement est un type de champ à part entière, stocké en oui/non et impossible à pré-cocher — une case déjà cochée ne vaut pas consentement au sens du RGPD. Les modèles Contact, Newsletter et Demande de devis l’incluent d’office. Pour les traceurs, c’est le rôle du bandeau cookies RGPD du même plugin.
Que sait faire le constructeur au-delà d’un simple formulaire de contact ?
Le constructeur propose vingt-quatre types de champs — dont signature manuscrite, note par étoiles, choix d’image, répéteur, fichier et champ de calcul —, une logique conditionnelle évaluée côté serveur et côté navigateur, des formulaires multi-étapes ou conversationnels, un auto-répondeur, un webhook JSON, un bloc Gutenberg et un shortcode.

Trois choix qui se voient à l’usage, et une réserve :
- Logique conditionnelle sans faille de validation : une règle par champ (afficher si tel autre champ vaut telle valeur), évaluée dans le navigateur et à nouveau sur le serveur — un champ masqué n’est ni validé ni stocké.
- Champ de calcul sans
eval(): la formule (quatre opérations, parenthèses) passe par un évaluateur maison ; une expression inattendue échoue, elle ne s’exécute pas. - Multi-étapes et mode conversationnel : un champ Saut de page découpe le formulaire en étapes avec barre de progression ; le mode conversationnel affiche un champ à la fois. Sans JavaScript, tout s’affiche d’un bloc et l’envoi fonctionne.
- Paiement Stripe : le formulaire peut exiger un paiement via Stripe Checkout, la page de paiement hébergée par Stripe ; l’entrée n’est créée qu’une fois le paiement confirmé côté serveur. Vérifiez tout le parcours en mode test avant de le mettre en production.
Quelles limites faut-il connaître avant de choisir ?
Trois, à connaître avant d’installer : il n’existe pas d’importateur depuis Contact Form 7 ou WPForms, le renvoi d’une notification se fait en ligne de commande plutôt que depuis un bouton du tableau de bord, et la logique conditionnelle se limite à une règle par champ.
Sur l’importation, les modèles ramènent un formulaire de contact classique en une minute ; vos anciens messages, eux, restent dans Flamingo ou dans WPForms. La logique conditionnelle accepte une seule règle par champ : suffisant pour l’immense majorité des formulaires, pas pour un questionnaire à arborescence. Si l’un de ces points vous bloque, Fluent Forms ou Formidable Forms stockent aussi les entrées gratuitement et sont plus anciens.
Ce qu’il reste de vos messages quand l’email lâche
Un formulaire de contact sert à faire arriver un message jusqu’à vous ; l’email n’en est que le véhicule, pratique et faillible. En écrivant chaque soumission en base avant de tenter l’envoi, le module Forms sépare les deux : la livraison peut échouer sans emporter la conservation.
Le module Forms fait partie de Blaminhor Essentials, le plugin modulaire gratuit que je construis pour remplacer la pile de plugins mono-fonction. Activez-le, gardez le SMTP à côté, et faites le test du mot de passe faux.
– blaminhor
FAQ
Comment retrouver un message Contact Form 7 qui n'est jamais arrivé ?
Sans plugin de stockage installé avant l'envoi, il n'existe plus nulle part : Contact Form 7 ne conserve aucune copie, il transmet le message à la fonction d'envoi d'email de WordPress et l'oublie. Installez Flamingo, le compagnon officiel, ou un module qui écrit en base, et vérifiez vos envois SMTP — vous protégez les prochains messages, pas ceux déjà perdus.
WPForms Lite enregistre-t-il les entrées gratuitement ?
Non. WPForms Lite envoie les soumissions par email ; la consultation des entrées dans le tableau de bord WordPress fait partie de la version payante. C'est un choix freemium assumé et clairement affiché. Ninja Forms, Formidable Forms, Fluent Forms et le module Forms de Blaminhor Essentials stockent, eux, les entrées en base sans payer.
Peut-on importer ses formulaires Contact Form 7 ou WPForms dans Blaminhor Essentials ?
Pas en un clic : le module Forms n'a pas d'importateur pour ces plugins. Quatre modèles prêts à l'emploi (contact, newsletter, sondage, demande de devis) permettent de recréer un formulaire de contact classique en une minute, avec la case de consentement déjà en place. Les anciens messages restent dans leur plugin d'origine.
Le formulaire fonctionne-t-il si JavaScript est désactivé ?
Oui. La soumission est un envoi de formulaire HTML classique traité côté serveur ; le JavaScript n'ajoute que le confort (affichage conditionnel en direct, étapes masquées, calculs instantanés). Sans lui, toutes les étapes s'affichent d'un coup, le bouton d'envoi reste présent et les erreurs sont affichées sous chaque champ après rechargement de la page.
Peut-on exporter les messages reçus ?
Oui, de deux façons : un bouton Export CSV sur l'écran des entrées de chaque formulaire, qui produit un fichier tableur avec la date, le statut et une colonne par champ ; et en ligne de commande avec WP-CLI (wp blaminhor forms export), pratique pour un export automatisé ou une migration vers un autre outil.
Les messages sont-ils envoyés à un serveur tiers ?
Non. Les entrées sont écrites dans une table dédiée de votre propre base de données WordPress, sur votre hébergement ; rien ne transite par un service externe. Les seules connexions sortantes possibles sont celles que vous configurez explicitement : un webhook vers un outil d'automatisation, un CAPTCHA tiers ou le paiement Stripe.
Un formulaire ralentit-il le reste du site ?
Non : la feuille de style et le script du module ne sont chargés que sur les pages qui contiennent réellement un formulaire, via le bloc ou le shortcode. Une page sans formulaire ne charge aucun fichier du module. Et comme tout Blaminhor Essentials, un module désactivé ne charge aucun code PHP.
Peut-on envoyer les soumissions vers Zapier, Make ou n8n ?
Oui, avec le webhook du formulaire : chaque soumission acceptée est envoyée en JSON à l'URL de votre choix, sans ralentir le visiteur. Si l'envoi échoue, une relance unique est programmée cinq minutes plus tard ; les adresses de réseau privé sont refusées pour qu'un formulaire public ne serve pas de sonde vers votre serveur.
Commentaires