Le CAPTCHA est là – mais ne protège rien

De nombreux propriétaires de sites web ajoutent un CAPTCHA à leur formulaire de contact, voient apparaître le petit badge ou la case à cocher et considèrent le problème du spam comme réglé. Puis les messages indésirables continuent d’arriver. Souvent, le CAPTCHA lui-même fonctionne – il n’est simplement relié à rien qui puisse arrêter un robot. Cet article passe en revue les façons typiques dont reCAPTCHA, hCaptcha et Cloudflare Turnstile finissent par n’être qu’une décoration, et explique comment vérifier vos propres formulaires.

Où la protection a réellement lieu

Les trois services fonctionnent selon le même principe. Un script dans le navigateur effectue ses contrôles et remet au formulaire un jeton – une courte chaîne de caractères qui signifie « ce visiteur a réussi ». Le jeton accompagne l’envoi du formulaire jusqu’à votre serveur. C’est seulement là que la vraie décision est prise : votre serveur envoie le jeton avec une clé secrète au fournisseur et reçoit une réponse – succès ou échec, et pour reCAPTCHA v3 également un score. Si un maillon de cette chaîne manque, le widget a toujours l’air parfaitement normal, mais un robot qui envoie directement ses requêtes au gestionnaire de votre formulaire passe sans obstacle.

La clé de test qui laisse tout passer

Google, hCaptcha et Cloudflare publient des clés de test spéciales pour que les développeurs puissent exécuter des tests automatisés sans résoudre d’énigmes. Avec la clé secrète de test correspondante, la vérification réussit toujours – c’est tout leur intérêt. Elles sont destinées aux environnements locaux et de préproduction, mais survivent régulièrement au passage en production : un développeur les colle pendant la construction du site, le site est mis en ligne et personne ne les remplace. reCAPTCHA affiche au moins dans le widget une mention indiquant qu’il est réservé aux tests, mais avec une configuration invisible, presque personne ne regarde. Si la clé de site de test et la clé secrète de test sont toutes deux actives, chaque envoi passe, qu’il provienne d’un humain ou d’un robot ; si seule la clé de site est une clé de test, la vérification échoue au contraire et de vrais messages peuvent être rejetés.

Un jeton que personne ne vérifie

Le deuxième classique est un serveur qui n’interroge jamais le fournisseur. Le widget fonctionne, un jeton est créé et transmis, puis le gestionnaire du formulaire l’ignore tout simplement. Les sources typiques sont les formulaires écrits à la main, les extraits de code copiés qui ne couvrent que le côté navigateur et les réglages de plugin à moitié terminés. Un cas voisin : le serveur appelle bien le service de vérification, mais vérifie seulement que la requête a abouti, et non ce que dit la réponse. Ou bien le seuil de score de reCAPTCHA v3 est fixé à 0, ce qui accepte tous les scores que le service peut renvoyer. Certains gestionnaires sont aussi « permissifs en cas d’échec » (fail open) : si le jeton manque ou si la vérification échoue, ils acceptent quand même le message – et un robot se contente d’omettre le jeton.

Quand le widget ne se charge jamais vraiment

D’autres erreurs de configuration cassent plutôt le côté navigateur. Si la clé de site n’est pas enregistrée pour le domaine – typiquement après un passage de la préproduction à la production, un changement de domaine ou un nouveau sous-domaine –, le fournisseur refuse d’émettre des jetons et affiche une erreur dans le widget ou dans la console du navigateur. Après un changement de thème ou une mise à jour de plugin, le balisage du widget peut toujours figurer dans la page alors que le script qui lui donne vie a disparu. Un outil de gestion du consentement aux cookies peut avoir le même effet s’il bloque le script du CAPTCHA jusqu’à ce que le visiteur donne son accord. La suite dépend du serveur : s’il exige un jeton valide, les vrais visiteurs ne peuvent plus envoyer de messages et personne ne remarque les demandes perdues ; s’il ne l’exige pas, les robots passent librement.

Deux autres cas passent facilement inaperçus. Avec reCAPTCHA v3, le badge dans le coin indique seulement que le script est chargé quelque part sur la page – peut-être par le thème ou un autre plugin – alors que l’intégration dans le plugin de formulaire lui-même est désactivée. Et les plugins de mise en cache peuvent stocker une page avec un jeton intégré dans le HTML. Les jetons CAPTCHA ne sont valables que quelques minutes et ne peuvent être vérifiés qu’une seule fois ; un jeton mis en cache échoue donc pour les vrais visiteurs, et la « solution » tentante consistant à désactiver la vérification supprime discrètement la protection.

Un court autocontrôle

1. 1Ouvrez la page du formulaire dans une fenêtre de navigation privée, ouvrez les outils de développement du navigateur et recherchez dans la console des erreurs provenant du script du CAPTCHA.
2. 2Vérifiez que le widget apparaît réellement – une fois avant et une fois après l’acceptation de la bannière de cookies – et que le formulaire ne peut pas être envoyé tant qu’il est absent.
3. 3Dans la console d’administration du fournisseur, vérifiez que la clé de site mentionne votre domaine de production (y compris les variantes comme www) et que les clés de votre plugin de formulaire ou de votre code y correspondent – et non des clés issues de la documentation ou d’une configuration de préproduction.
4. 4Dans les réglages du plugin de formulaire, assurez-vous que l’intégration du CAPTCHA est activée pour ce formulaire précis ; pour reCAPTCHA v3, vérifiez que le seuil de score est supérieur à 0.
5. 5Si vous avez accès au code, trouvez la vérification côté serveur et vérifiez qu’elle rejette l’envoi lorsque la réponse est négative ou que le jeton est absent.
6. 6Excluez la page du formulaire de la mise en cache de pages complètes, ou assurez-vous que le jeton est généré à neuf dans le navigateur.
7. 7Envoyez un vrai message de test et vérifiez qu’il arrive ; répétez le contrôle après toute modification du thème, des plugins ou de l’outil de consentement.

Un CAPTCHA est une couche, pas toute la protection. Combiné à un champ honeypot, un contrôle de durée et un filtrage côté serveur, une erreur de configuration à un endroit ne laisse pas le formulaire grand ouvert. Si vous souhaitez avoir rapidement une idée de l’état de vos formulaires, saisissez votre domaine sur formexposed.com – le rapport indique si les éléments de votre configuration CAPTCHA visibles de l’extérieur sont en ordre.