Formulaire de contact
Un formulaire de contact est le bloc de champs publié sur une page du site, par lequel un visiteur envoie un message sans ouvrir sa propre messagerie.
Définition
Un formulaire de contact est le bloc de champs publié sur une page du site, par lequel un visiteur envoie un message sans ouvrir sa propre messagerie. C’est l’élément le plus simple à poser et le plus facile à laisser tomber en panne sans s’en apercevoir.
Ce qui se passe vraiment quand on clique sur Envoyer
Un formulaire n’est pas une brique, c’est une chaîne de trois éléments réglés séparément.
Le premier maillon est l’affichage. Une page publie des champs et un bouton, et le navigateur du visiteur vérifie au passage les règles les plus simples, une adresse électronique qui ressemble à une adresse, un champ obligatoire qui n’est pas vide. Cette vérification est un confort de saisie et rien d’autre : elle vit dans le navigateur, donc n’importe quel automate peut s’en passer en envoyant directement les données au serveur.
Le deuxième maillon est le traitement, du côté du serveur. C’est là que se décide l’essentiel : est-ce que la demande vient bien d’une page du site, est-ce que les champs obligatoires sont remplis, est-ce que le contenu n’est pas une soumission automatisée. WordPress fournit pour cela un jeton à usage unique, déposé dans la page au moment de l’affichage et revérifié à la réception. Sans lui, n’importe quelle page extérieure peut faire soumettre votre formulaire par un visiteur qui passe chez elle.
Le troisième maillon est la remise. Deux chemins coexistent et ils ne se valent pas. Le message peut partir par courrier électronique, auquel cas il dépend du serveur d’envoi et peut se perdre en route sans avertir personne. Il peut aussi être enregistré dans la base de données du site, ce qui garantit qu’il existe quelque part, mais impose alors de le consulter et de le purger. La plupart des installations font les deux.
Ce qu’il faut en retenir. Le message de confirmation affiché au visiteur est écrit par le deuxième maillon. Il dit que le formulaire a accepté la demande, jamais que vous l’avez reçue. Ces deux faits sont indépendants, et c’est exactement pour cela qu’un formulaire muet passe inaperçu des mois.
Faut-il une extension, ou un formulaire écrit dans le thème ?
Les deux fonctionnent. Ils ne créent simplement pas la même dépendance.
Une extension de formulaire apporte une interface de construction, un stockage des messages, des exports et des connexions vers d’autres outils. Elle apporte aussi sa propre surface : des scripts chargés sur les pages qui portent un formulaire, parfois sur toutes, une table supplémentaire dans la base, et un cycle de mises à jour de plus à suivre. C’est le bon choix quand plusieurs personnes doivent créer et modifier des formulaires sans toucher au code.
Un formulaire écrit dans le thème enfant fait l’inverse. Il n’ajoute ni script ni table, il ne se met à jour que quand vous le décidez, et il ne peut pas être cassé par la mise à jour d’un tiers. En échange, chaque modification passe par quelqu’un qui sait éditer un gabarit, et les protections qu’une extension fournit d’office, jeton de sécurité, champ piège, limitation du nombre d’envois, sont à poser à la main.
Un point de vigilance vaut pour les deux : un formulaire ne doit jamais être servi depuis une copie de page conservée en amont du site. Le jeton déposé dans la page a une durée de vie, et une page gardée en réserve trop longtemps présente au visiteur un jeton déjà périmé, ce qui se traduit par un refus incompréhensible à la soumission.
Relevé du 19 septembre 2026 sur ilti.fr, en lecture seule. Le thème enfant du site porte six formulaires écrits à la main, pour l’audit, la page d’audit, l’abonnement, la page introuvable, le diagnostic et le devis. Les six portent le même dispositif : un jeton de sécurité et un champ piège nommé comme s’il demandait l’adresse du site, que seul un automate remplit. Aucun contenu publié ne contient de formulaire dans la base : les six vivent dans les gabarits, pas dans les pages. Le relevé sort une seconde chose, moins attendue. Vingt-six extensions sont actives sur ce site et aucune n’est une extension de formulaire, pourtant la base conserve encore un formulaire déclaré par une extension de ce type et une table de tâches qui porte cinquante-quatre lignes. Désactiver une extension retire son écran d’administration, pas ses données. C’est le rappel le plus concret de ce que coûte un formulaire posé puis abandonné.
Le formulaire dit que c’est parti et rien n’arrive
C’est le symptôme le plus courant, et il se diagnostique dans un ordre précis.
Vérifier d’abord le stockage, pas la boîte aux lettres
Si les messages sont enregistrés dans le site, ouvrez la liste. Un message présent à cet endroit et absent de votre messagerie désigne le courrier électronique, pas le formulaire. Cela divise le problème en deux, et la moitié est déjà résolue.
Chercher dans les indésirables, puis chez l’hébergeur
Un message parti du serveur du site avec votre propre adresse en expéditeur ressemble à une usurpation aux yeux des filtres. C’est la cause la plus fréquente, et elle se corrige en faisant partir le message depuis une adresse du domaine, avec l’adresse du visiteur placée en champ de réponse.
Tester en visiteur anonyme, sur l’adresse nue
Connecté à l’administration, vous recevez des pages fraîches que le reste du monde ne reçoit pas. Un formulaire qui marche pour vous et pour personne d’autre est presque toujours un formulaire servi depuis une copie conservée en amont.
Regarder ce que le serveur a refusé
Jeton périmé, champ piège rempli, limite d’envois atteinte, filtre de sécurité déclenché par un mot du message : le refus est une décision, elle laisse une trace. Les journaux du serveur et ceux de l’extension de sécurité disent laquelle.
Quand le courrier électronique est bien la cause, la correction passe presque toujours par le même geste : faire partir les messages par un vrai service d’envoi authentifié, ce qu’on appelle une configuration SMTP, plutôt que par la fonction d’envoi par défaut du serveur. Le message est alors émis au nom du domaine, signé, et les filtres de destination cessent de le traiter comme une adresse usurpée.
Il reste un dernier cas, plus rare et plus coûteux : le formulaire fonctionne, le message arrive, et personne ne le lit parce qu’il atterrit dans une boîte partagée que plus personne n’ouvre. Cela ne se diagnostique pas techniquement. Cela se découvre en s’envoyant un message tous les trimestres, depuis l’extérieur, comme le ferait un client.
Ce qu’un formulaire vous engage à faire
Dès qu’il recueille un nom ou une adresse, il devient un traitement de données personnelles.
Trois principes valent quelle que soit la solution retenue, et ils se règlent au moment où le formulaire est posé plutôt qu’après. Le premier est la sobriété : ne demander que les champs dont vous vous servirez réellement, parce que chaque champ supplémentaire est une donnée à protéger, à justifier et à effacer un jour. Le deuxième est l’information : dire à qui le message est destiné, pourquoi il est collecté et combien de temps il est conservé, au moment de la saisie et pas dans une page perdue du site. Le troisième est la durée : les messages stockés dans la base ne se périment pas tout seuls et une base qui accumule des années de demandes est un risque qui grandit sans rien apporter.
Ces trois principes se matérialisent dans un document unique, la politique de confidentialité, vers laquelle le formulaire renvoie au moment de la saisie. C’est elle qui nomme le responsable du traitement, la finalité, la durée de conservation et la façon d’exercer ses droits, et c’est à elle que le visiteur se réfère plutôt qu’à une mention glissée sous un bouton.
L’autorité française de protection des données publie des recommandations à jour sur ces trois points et sur ce qui relève ou non du consentement. Les règles évoluent : c’est sa page qui fait foi, pas ce que vous avez lu il y a deux ans, ni cette fiche.
Questions fréquentes
Une image de vérification est-elle obligatoire pour arrêter les robots ?
Non, et elle est rarement le premier levier. Un champ piège invisible pour le visiteur et obligatoirement vide arrête déjà l’essentiel des envois automatisés, sans rien demander à personne. Les dispositifs de vérification visuelle se justifient quand le volume d’envois indésirables reste élevé malgré le champ piège, et ils se choisissent alors en regardant ce qu’ils envoient comme données à leur éditeur.
Faut-il stocker les messages dans le site ou se contenter du courrier électronique ?
Le courrier électronique seul fait perdre des messages sans le dire, puisque rien ne subsiste si l’envoi échoue. Le stockage seul oblige à ouvrir le site pour découvrir qu’on a reçu quelque chose. La combinaison des deux est ce qui se pratique le plus souvent : le message existe dans la base, et la notification prévient qu’il est arrivé.
Un formulaire ralentit-il le site ?
Pas le formulaire en lui-même, mais éventuellement ce qu’il charge. Une extension qui pose ses scripts sur toutes les pages, y compris celles qui ne portent aucun formulaire, se voit dans la mesure. Un formulaire écrit dans le gabarit de la page concernée n’ajoute rien ailleurs.
Pourquoi mon formulaire refuse les envois avec un message de sécurité ?
Le cas classique est le jeton déjà périmé, présenté par une page conservée en réserve depuis plus longtemps que la durée de vie du jeton. La vérification se fait sur l’adresse nue, en navigation privée : si la page fraîche accepte et que la page normale refuse, la couche de cache est en cause et la page doit être exclue de la mise en réserve.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.