Faut-il un CAPTCHA sur le formulaire de votre landing page ?

Il suffit de quelques semaines d'exposition pour que le formulaire d'une landing page attire son lot de soumissions automatiques : fausses adresses, messages publicitaires, tentatives d'injection. Le réflexe est d'ajouter un CAPTCHA — et c'est souvent une erreur de calcul : le CAPTCHA fait payer aux visiteurs légitimes, en friction et en abandons, ce que les robots vous coûtent en nettoyage de CRM. Cet article chiffre ce compromis à partir des études disponibles, puis détaille la hiérarchie des défenses invisibles qui règlent le problème dans la plupart des cas sans faire souffrir personne. Il complète notre guide complet du formulaire de landing page.

Ce qu'un CAPTCHA coûte réellement aux humains

Le coût du CAPTCHA pour les vrais visiteurs a été mesuré à grande échelle. Une étude d'Elie Bursztein et ses co-auteurs de Stanford publiée en 2010 (IEEE Symposium on Security and Privacy), portant sur plus d'un million de CAPTCHA évalués par des humains, a mesuré qu'un CAPTCHA textuel demande en moyenne autour de 10 secondes d'effort, que les CAPTCHA audio en demandent près de trois fois plus avec un taux d'échec bien supérieur, et que les humains sont loin de réussir à tous les coups — les personnes non anglophones ou plus âgées échouant davantage. Avant elle, une étude de Jeff Yan et Ahmad Salah El Ahmad publiée en 2008 (Symposium on Usable Privacy and Security) avait documenté les problèmes d'utilisabilité systématiques des CAPTCHA : caractères ambigus, épreuves illisibles, accessibilité quasi nulle pour les visiteurs malvoyants. Dix secondes de friction et un risque d'échec placés juste avant le bouton d'envoi, sur une page où chaque champ superflu se paie déjà en abandons — notre analyse sur le nombre de champs d'un formulaire le montre —, c'est exactement l'inverse de ce qu'on optimise.

La vraie question : quel est le coût du spam pour vous ?

Le raisonnement honnête part de l'autre côté : que vous coûte réellement le spam ? Pour une landing page qui capture des emails vers un outil d'emailing, quelques fausses adresses par semaine coûtent quasiment zéro — un filtre à la main ou un double opt-in les élimine. Pour un formulaire qui déclenche un rappel téléphonique par un commercial, chaque faux lead coûte un appel perdu : la protection se justifie plus vite. Et pour un formulaire branché sur un outil facturé au contact, le spam devient un coût direct. La décision se prend donc en comparant deux pertes : les abandons de visiteurs légitimes causés par la friction (souvent invisibles, donc sous-estimés) contre le coût de traitement du spam (visible, donc surestimé). Dans la grande majorité des cas de landing page, la friction coûte plus cher que le spam qu'elle évite.

La hiérarchie des défenses : de l'invisible au visible

• 1. Le honeypot : un champ caché en CSS que les humains ne voient pas mais que les robots remplissent — toute soumission avec ce champ rempli est rejetée. Zéro friction, efficace contre les robots génériques qui constituent l'essentiel du spam de formulaire.
• 2. Le contrôle du temps de remplissage : un formulaire soumis 800 millisecondes après le chargement de la page n'a pas été rempli par un humain. Rejeter les soumissions trop rapides coûte zéro friction.
• 3. La validation serveur stricte : format d'email vérifié, longueur des champs bornée, contenus avec liens rejetés sur un formulaire de contact — indispensable de toute façon, y compris avec un CAPTCHA.
• 4. Le rate limiting : limiter les soumissions par adresse IP et par fenêtre de temps bloque les rafales sans affecter un visiteur normal.
• 5. Le double opt-in pour la capture d'emails : l'adresse n'entre en base qu'après clic sur le lien de confirmation — les fausses adresses s'éliminent d'elles-mêmes, avec en prime une liste plus saine pour la délivrabilité (voir notre article sur la landing page de newsletter).
• 6. En dernier recours, un défi invisible ou discret : les solutions modernes type Cloudflare Turnstile ou reCAPTCHA v3 évaluent la session sans épreuve visuelle dans la plupart des cas, et ne montrent un défi qu'aux sessions suspectes.

Cette hiérarchie a une logique simple : on n'inflige une épreuve visible à 100 % des visiteurs que si les défenses qui ne coûtent rien ont échoué. Sur les templates LanderKit, le honeypot et la validation stricte se mettent en place en quelques lignes, le code du formulaire étant livré en source — c'est un des avantages concrets d'une page dont on contrôle le code plutôt qu'un widget fermé.

Si vous devez vraiment afficher un CAPTCHA

Certains contextes l'imposent : formulaire massivement attaqué de façon ciblée, obligation d'un service tiers, campagne à très fort trafic qui attire les fermes de bots. Dans ce cas, trois règles limitent les dégâts. D'abord, choisir une solution qui ne montre un défi qu'aux sessions suspectes plutôt qu'une grille d'images systématique. Ensuite, placer le défi après le clic d'envoi, pas au milieu du formulaire : le visiteur qui a déjà tout rempli va plus probablement au bout que celui qu'on arrête avant d'avoir commencé. Enfin, soigner le message d'erreur en cas d'échec — un visiteur légitime qui rate l'épreuve doit pouvoir réessayer sans perdre ce qu'il a saisi, sujet que notre article sur la microcopie de formulaire traite en détail.

Reste la question de la conformité : les CAPTCHA des grands fournisseurs reposent sur l'analyse de la session du visiteur, parfois via des cookies et des transferts de données hors UE — en France, la CNIL s'est penchée à plusieurs reprises sur ces mécanismes, notamment sur la question du consentement. Sans entrer dans une analyse juridique qui dépend de la solution choisie et de sa configuration, le point pratique est simple : le choix d'un CAPTCHA n'est pas neutre au regard du RGPD, et mérite d'être examiné avec les mêmes réflexes que le reste du formulaire — notre guide du formulaire conforme au RGPD donne le cadre. Une raison de plus de préférer les défenses invisibles côté serveur, qui n'analysent pas le visiteur.

Mesurer avant et après : la seule preuve qui compte

Si vous ajoutez ou retirez une protection, mesurez : taux de complétion du formulaire avant/après, volume de spam reçu avant/après, et si possible taux d'échec du défi pour les visiteurs (les solutions sérieuses l'exposent dans leur tableau de bord). Un A/B test tranche définitivement quand le trafic le permet. Le résultat typique — beaucoup de spam en moins avec un honeypot et une validation stricte, sans CAPTCHA visible et sans perte de conversion — est atteignable sur la plupart des landing pages : le CAPTCHA visible doit rester l'exception qu'on s'autorise en dernier recours, pas le réflexe par défaut.