Un formulaire se perd de deux façons : noyé sous le pourriel, ou barré par un casse-tête qui fait fuir vos prospects. Comment protéger sans rien demander.

Il y a deux façons de perdre un formulaire de contact, et elles ne se ressemblent pas. La première est bruyante : le formulaire n'est pas protégé, les soumissions automatisées s'accumulent, et au bout de quelques semaines plus personne n'ouvre les notifications. Les vraies demandes continuent d'arriver, elles meurent dans le tas.
La deuxième est silencieuse. Le formulaire est si verrouillé qu'un prospect renonce devant une grille d'images à cliquer, ferme l'onglet et appelle un concurrent. Dans nos services web, c'est celle-là qui nous inquiète le plus, parce qu'elle ne laisse aucune trace : personne ne vous écrit pour vous dire qu'il a abandonné votre formulaire.
La question utile n'est donc pas « combien de protection », c'est « qui la paie ». Un bon dispositif fait porter le coût au robot. Un mauvais le refile au visiteur.
Un formulaire web se perd de deux façons opposées. Sans protection, il se remplit de soumissions automatisées jusqu'à ce que plus personne ne le lise, et les vraies demandes disparaissent dans le bruit. Trop protégé, il oppose un casse-tête visuel qui coûte en moyenne 32 secondes au visiteur, selon les mesures publiées par Cloudflare, et qui exclut carrément certaines personnes handicapées : le W3C parle d'un déni de service à leur endroit. La bonne approche fait porter le coût au robot plutôt qu'au visiteur, en superposant des défenses invisibles : un champ piège que seul un programme remplit, un horodatage du formulaire, une limitation du débit par adresse IP, une validation côté serveur, et un score de risque calculé en arrière-plan. C'est le rôle de reCAPTCHA (édition Essentials gratuite jusqu'à 10 000 évaluations par mois) ou de Cloudflare Turnstile, gratuit et conçu pour respecter les WCAG 2.2. Aucun de ces mécanismes ne demande quoi que ce soit à la personne qui vous écrit.
Un formulaire non protégé finit toujours par être trouvé. Pas parce qu'on vous a choisi, mais parce que des programmes balaient le web en continu à la recherche de champs à remplir, comme ils cherchent des extensions périmées : c'est le trafic décrit dans notre article sur la sécurité de site web pour PME.
Le volume se supporte. C'est l'habitude qui coûte. Quand la moitié des notifications sont du pourriel, la personne qui les reçoit survole. Quand c'est les trois quarts, elle crée une règle de tri, puis cesse de vérifier le dossier. Le formulaire fonctionne toujours du point de vue technique, et l'entreprise a arrêté de recevoir ses demandes.
Il y a pire : un formulaire qui envoie à une adresse tirée de ses propres champs devient un relais à pourriel, et c'est votre domaine qui se retrouve sur les listes de blocage.
L'autre réflexe consiste à empiler la protection visible : grille d'images, texte déformé, petit calcul. Ce test est devenu mauvais des deux côtés.
Du côté des robots, il ne tient plus. Le W3C, dans sa note « Inaccessibility of CAPTCHA » mise à jour le 16 décembre 2021, rappelle qu'une étude de l'Université du Maryland a atteint 90 % de réussite en cassant le CAPTCHA audio de Google avec le service de reconnaissance vocale de Google lui-même. Les tests à caractères déformés sont pris dans une course perdue : pour résister à la reconnaissance optique, il faut déformer davantage, ce qui les rend impraticables pour les humains bien avant de les rendre difficiles pour les machines.
Du côté des visiteurs, le coût est mesurable. Cloudflare a publié la donnée en 2021 : en moyenne, 32 secondes pour résoudre un défi. Sur une page de contact, c'est énorme, sans compter le test raté qu'il faut reprendre.
Et pour une partie de vos visiteurs, ce n'est pas une friction, c'est un mur. Le W3C est direct : la nature même de la tâche interactive exclut beaucoup de personnes handicapées, ce qui aboutit à un déni de service. Demander à une personne aveugle ou dyslexique d'identifier des caractères dans une image déformée, c'est exactement la tâche qu'elle est le moins en mesure d'accomplir. La note ajoute qu'on peut soutenir qu'un modèle de conception qui présuppose plusieurs tentatives est inaccessible par nature pour les personnes vivant avec un trouble anxieux.
Les WCAG tolèrent le CAPTCHA, mais l'exemption est étroite. Le critère 1.1.1 exige des alternatives textuelles qui identifient le test et en décrivent l'objet, et des formes de rechange faisant appel à d'autres types de perception sensorielle. Si vous mettez une grille d'images, vous devez donc fournir une solution de rechange auditive, et celle-là est cassée à 90 %. Vous héritez d'une obligation d'accessibilité sans gagner de sécurité.
La couche qui fonctionne est celle que personne ne voit. Quatre mécanismes empilés font la plus grande partie du travail.
Le champ piège : un champ caché en CSS, laissé vide par un humain qui ne le voit pas, rempli par le programme qui lit le code et remplit tout. S'il contient quelque chose, la soumission part à la poubelle sans message d'erreur.
L'horodatage : on inscrit dans le formulaire le moment où la page a été rendue et on rejette les soumissions arrivées en moins de deux ou trois secondes. Personne ne lit un formulaire et n'écrit un message en deux secondes. Un script, oui.
La limitation du débit : un plafond de soumissions par adresse IP et par tranche de temps, appliqué sur le serveur. Ça ne coûte rien et ça neutralise le remplissage en boucle.
La validation côté serveur : ne jamais faire confiance à ce qui a été validé dans le navigateur. Un robot n'exécute pas votre JavaScript, il frappe directement votre point de terminaison. Sur les sites que nous construisons, chaque champ est revalidé côté serveur, et le courriel de notification part vers une adresse fixe définie dans la configuration, jamais tirée du formulaire.
Aucun de ces quatre mécanismes n'est visible ni ne pose de problème d'accessibilité. Ils demandent une heure de développement une fois pour toutes et tombent en panne moins souvent qu'un service tiers, ce qui compte quand on parle de maintenance de site web.
Au-dessus vient la notation du risque : un service tiers observe le comportement du navigateur et renvoie un score, à partir duquel votre serveur décide. Rien n'est affiché au visiteur. C'est ce que nous déployons sur les formulaires de nos clients avec reCAPTCHA Enterprise, en mode score, invisible, doublé de la validation côté serveur.
Deux choses méritent d'être connues avant de choisir. D'abord le prix. Chez Google, l'édition Essentials est gratuite jusqu'à 10 000 évaluations par mois civil, et ce plafond est calculé par organisation, cumulé sur tous les comptes, tous les sites et tous les projets. Au-delà, un projet sans facturation reçoit une erreur de quota ; un projet avec facturation passe à l'édition Premium, facturée 8 $ US forfaitaires de 10 001 à 100 000 évaluations, puis 1 $ US par tranche de 1 000. Depuis le 22 avril 2026, reCAPTCHA fait partie de la plateforme Google Cloud Fraud Defense.
Ensuite, un comportement qui mérite votre attention. Pour les anciennes clés hors Enterprise, la documentation de Google indique qu'une clé v3 qui dépasse son quota mensuel peut échouer « en mode ouvert » : la vérification renvoie un score fixe de 0,9 et le message « Over free quota », sans aucune indication visible pour les utilisateurs, pour le reste du mois. Traduction : votre filtre cesse de filtrer et déclare tout le monde humain, en silence. C'est la raison pour laquelle le score doit rester une couche parmi d'autres, jamais l'unique verrou.
L'alternative sérieuse est Cloudflare Turnstile. Le forfait gratuit couvre jusqu'à 20 widgets, avec un nombre illimité de défis et de requêtes de vérification, et 10 noms d'hôte par widget. Le widget existe en trois formes : géré (il décide s'il montre une case à cocher selon le risque), non interactif, et invisible.
Trois arguments comptent pour une PME. Turnstile s'intègre à n'importe quel site sans faire passer le trafic par le réseau de Cloudflare. Sa documentation précise qu'il ne traite que les données strictement nécessaires à sa fonction de sécurité et qu'il n'accède pas aux saisies de formulaire ni aux autres entrées de la page, qu'il ne les stocke pas et ne les transmet pas, ce qui simplifie la conversation sur la vie privée. Et Cloudflare affiche une conformité aux WCAG 2.2 sur les deux forfaits, rare dans cette catégorie.
Dernier angle, souvent oublié : au Québec, un formulaire de contact est une collecte de renseignements personnels au sens de la loi. L'article 5 de la Loi sur la protection des renseignements personnels dans le secteur privé est court et sans ambiguïté : la personne qui recueille des renseignements personnels sur autrui ne doit recueillir que les renseignements nécessaires aux fins déterminées avant la collecte. L'article 4 précise que ces fins se déterminent avant, pas après.
Concrètement, chaque champ doit survivre à une question : à quoi sert-il, exactement, pour répondre à cette demande ? Le téléphone obligatoire quand vous répondez par courriel, la taille de l'équipe, le budget : si vous ne pouvez pas nommer l'usage, retirez le champ. Vous réduisez du même coup la friction et le risque, ce qui est le rare cas où la conformité et la conversion tirent dans la même direction.
Deux réflexes complètent le tableau. Les services de notation déposent un témoin : reCAPTCHA installe _GRECAPTCHA, que Google qualifie de nécessaire à son analyse de risque, et ça se documente dans votre politique. Et si vous utilisez un service tiers, dites-le près du bouton d'envoi, ce que la licence de reCAPTCHA exige d'ailleurs quand on masque son badge. Notre article sur la Loi 25 et votre site web détaille le volet témoins et formulaires.
Un formulaire bien protégé, en 2026, ressemble à un formulaire non protégé. Trois champs, pas de grille d'images, pas de case à cocher, et derrière : un champ piège, un horodatage, une limite de débit, une validation serveur et un score. Le visiteur écrit et envoie. Le robot ne passe pas.
→ Demandez un audit de votre site
Une précision pour finir : ce texte vulgarise les règles de collecte de renseignements personnels pour aider une PME à réviser ses propres formulaires, ce n'est pas un avis juridique. Pour un formulaire qui recueille des renseignements sensibles, validez avec un conseiller juridique. La Commission d'accès à l'information et les textes de loi sur LégisQuébec sont la référence qui prime.
Écrit par