Types de CAPTCHA : ce que révèle une case à cocher

Une case à cocher, une grille d’images ou un widget invisible ne suffisent pas à identifier de manière fiable un type de CAPTCHA. Ces éléments décrivent la présentation d’un contrôle ; ils ne révèlent ni tous ses mécanismes ni la règle d’acceptation du site. Classez séparément l’interaction, le contrôle documenté, son emplacement et la décision du serveur. BotBrowser fournit des contrôles du navigateur fondés sur des profils et une configuration de proxy, mais ne résout pas les défis, n’expose pas le score privé d’un fournisseur et ne garantit pas qu’un site acceptera une session.

Résumé

• Une case à cocher, une tâche avec images et l’absence de widget visible décrivent des interactions ; aucune ne constitue une description complète du système de vérification.
• La notation du risque, la preuve de travail et l’attestation décrivent des mécanismes ou des éléments probants différents. Ils peuvent coexister avec des interactions visibles ou invisibles.
• Un jeton de réponse produit dans le navigateur nécessite toujours la validation côté serveur exigée par le fournisseur. L’autorisation de l’application reste une décision distincte.
• Identifiez un produit déployé à partir de son intégration documentée et de la configuration du propriétaire, et non d’une capture ressemblant simplement au défi d’un autre fournisseur.
• Consignez comme inconnus les mécanismes inconnus. Pour un travail automatisé autorisé, suspendez les tâches dépendantes lorsqu’un défi remplace le résultat attendu de l’application.

Sommaire

• Classez les types de CAPTCHA selon quatre axes distincts
• Ce que les tâches visibles établissent
• Ce que les contrôles en arrière-plan peuvent mesurer
• Suivez un jeton jusqu’à la décision du serveur
• Rédigez une observation sans inventer de score
• Choisissez la prochaine action selon votre rôle
• Conclusion pratique

Classez les types de CAPTCHA selon quatre axes distincts

Une liste qui place « case à cocher », « invisible », « score de risque » et « preuve de travail » dans quatre lignes concurrentes mélange des questions différentes. Une case à cocher décrit une interface. Invisible décrit l’absence de widget visible. Un score décrit une évaluation renvoyée par un service particulier. La preuve de travail décrit une tâche de calcul. Choisir une étiquette n’exclut pas les autres.

Utilisez quatre champs plutôt que de chercher à identifier un type universel unique. Les valeurs ci-dessous sont des choix de classification, pas des mesures effectuées sur un fournisseur en activité. Ne renseignez le champ du mécanisme que lorsqu’une description officielle du produit ou le propriétaire du déploiement l’établit.

Axe	Question	Exemples de valeurs	Ce que le champ ne peut pas établir
Interaction	Que voit ou fait la personne ?	Case à cocher, tâche avec images, tâche textuelle, aucun widget visible	Quelles entrées privées ont été évaluées
Mécanisme	Quel élément probant ou contrôle est documenté ?	Évaluation du risque, preuve de calcul, mécanisme d’attestation	Ses pondérations non divulguées ou le résultat de cette requête
Emplacement	Où le contrôle est-il intégré ?	Widget intégré à l’application, page interstitielle de défi	Si le reste de l’application a autorisé l’opération
Décision	Quel composant accepte quoi ?	Le fournisseur vérifie un jeton ; le site applique sa propre politique	Si un succès dans le navigateur signifie un succès de l’opération métier

Ces axes expliquent aussi pourquoi l’apparence d’un défi peut changer au cours d’une même visite. Google indique qu’une case à cocher reCAPTCHA v2 peut être validée immédiatement ou présenter un défi. C’est une branche prévue dans une même intégration, pas la preuve que le site a changé de fournisseur de CAPTCHA. La chronologie d’un incident doit décrire la transition réelle, et non une nouvelle catégorie déduite de chaque écran.

L’article connexe sur le diagnostic d’un CAPTCHA en cours d’exécution traite de l’examen de la route, de la session du navigateur et de la charge de travail après l’apparition d’un défi. La classification répond à une question antérieure : quels faits l’écran établit-il, et lesquels nécessitent la documentation du fournisseur ou des éléments du propriétaire du site ? Elle ne remplace pas cette investigation par une étiquette de fournisseur.

La portée d’une affirmation compte autant que son étiquette. « Ce produit documente un contrôle de calcul en arrière-plan » concerne une famille de produits. « Cette requête a échoué à ce contrôle » concerne une exécution et nécessite les éléments correspondants. La première affirmation n’établit pas la seconde. Conservez les capacités du produit et les observations sur la requête dans des colonnes distinctes de tout dossier d’assistance.

Ce que les tâches visibles établissent

La case à cocher bien connue demande une interaction visible, mais sa position dans la page révèle peu de choses sur l’ensemble du processus de vérification. Dans le comparatif des versions de reCAPTCHA de Google, le parcours v2 avec case à cocher peut accepter l’interaction sans autre tâche ou exiger un défi supplémentaire. Cliquer sur la case ne mesure donc pas un score numérique public et n’établit pas qu’aucune évaluation en arrière-plan n’a eu lieu.

Une tâche avec images est également un format d’interaction. Son apparition établit qu’une tâche fondée sur des images a été présentée. Elle n’indique pas à un observateur côté client pourquoi cette tâche a été choisie, si le même visiteur verra ensuite un autre format, ni si sa réussite satisfera une restriction de compte distincte. Décrivez la tâche affichée sans inventer sa règle de sélection.

La saisie de texte et les autres tâches visibles relèvent de la même méthode de classification. Elles diffèrent par l’interaction exigée, les besoins d’accessibilité et les erreurs de saisie possibles. Ces différences pratiques comptent lorsqu’un propriétaire d’application teste le parcours utilisateur pris en charge. Elles ne permettent pas de classer la qualité de sécurité de produits entiers et ne révèlent pas les éléments de fond utilisés pour sélectionner une tâche.

« Invisible » exige aussi un sujet précis. Google décrit reCAPTCHA v2 invisible comme une intégration qui n’exige pas de cliquer sur une case ; elle peut être déclenchée par un bouton ou un appel d’API, et le trafic suspect peut toujours recevoir un défi. L’absence de case initiale ne promet donc pas qu’aucune tâche visible n’apparaîtra jamais.

Cloudflare documente les modes de widget Turnstile Managed, Non-Interactive et Invisible. Managed peut choisir un contrôle sans interaction ou demander de cocher une case. Non-Interactive affiche un widget sans exiger d’interaction ; Invisible s’exécute sans afficher le widget. Une boîte visible et un clic obligatoire sont deux faits distincts, même au sein d’un même produit.

Le guide des modes invisible et passif de hCaptcha introduit une autre distinction utile. Invisible supprime la case initiale, tandis que le comportement passif concerne la présentation éventuelle d’un défi interactif. La documentation décrit la combinaison des modes invisible et passif dans l’offre Enterprise concernée. Ne généralisez pas une option propre à une offre en promesse applicable à tous les comptes ou à toutes les intégrations.

Observation visible	Description étayée	Déduction non étayée
Une case à cocher est affichée	L’intégration propose une interaction avec une case à cocher	Un score de risque public doit être disponible
Une tâche avec images est affichée	Le parcours a présenté une tâche fondée sur des images	Un signal particulier du navigateur l’a déclenchée
Un widget est visible, mais aucun clic n’est demandé	L’interface est actuellement sans interaction	Aucun contrôle du navigateur n’est en cours
Aucun widget n’est visible	Aucun widget n’a été observé dans cet état	Il n’existe aucune intégration de défi ni vérification

Pour les tests d’accessibilité et de l’application, consignez l’interaction réellement requise, la configuration documentée et l’état pertinent de la page. Une capture peut étayer le premier fait. La configuration du propriétaire peut établir le deuxième. Ni l’une ni l’autre ne fournit le mécanisme caché ou un verdict du fournisseur auquel l’observateur n’a pas accès. Évitez de traiter une capture d’écran soignée comme un élément probant sur un modèle de notation non documenté.

Ce que les contrôles en arrière-plan peuvent mesurer

Une évaluation du risque n’est pas le même résultat qu’une réponse à une énigme. La documentation de reCAPTCHA v3 de Google décrit un score pour chaque requête, sans friction pour l’utilisateur, et laisse le site décider de l’action à suivre. Elle décrit aussi des actions qui fournissent un contexte pour interpréter les résultats. Ce modèle de réponse documenté ne rend pas un score numérique accessible à n’importe quel client de navigateur.

Il ne faut pas attribuer l’existence d’un score à tous les widgets. Un produit peut émettre un jeton de vérification sans exposer de score numérique de risque via son intégration standard. Inversement, un produit fondé sur un score peut alimenter une politique du site qui demande une autre forme de vérification. Le résultat du fournisseur, la réponse choisie par le site et l’interaction montrée au visiteur sont des enregistrements distincts.

La preuve de travail décrit un contrôle de calcul, pas une présentation visible. La présentation de Turnstile cite parmi ses contrôles la preuve de travail, la preuve d’espace et le sondage d’API web. Plusieurs mécanismes peuvent participer au même système. Il serait inexact de transformer cette liste en produits CAPTCHA mutuellement exclusifs ou de conclure qu’un widget invisible n’utilise qu’un seul de ces mécanismes.

Un mécanisme d’attestation concerne des éléments émis ou vérifiés dans un cadre de confiance particulier. Son affirmation exacte, son émetteur, ses prérequis et son vérificateur dépendent du schéma documenté. Ce n’est pas un synonyme d’invisible. Si la documentation publique d’un fournisseur n’établit pas quel mécanisme d’attestation s’applique au parcours déployé, laissez ce mécanisme non précisé plutôt que de remplir le champ d’après l’apparence visuelle.

Le mot « mesurer » demande ici de la retenue. Une page officielle peut nommer une catégorie de contrôles sans révéler leurs pondérations, seuils, composition ou utilisation pour une requête précise. Un client peut observer l’exécution d’un script ou le changement d’état d’un widget. Ces observations ne permettent pas de reconstituer la procédure complète de décision côté serveur. Aucune expression saisie dans la console du navigateur ne transforme une évaluation non divulguée du fournisseur en valeur locale de diagnostic fiable.

Les caractéristiques du navigateur sont des entrées potentielles, pas des explications universelles. Un contrôle du navigateur fondé sur un profil peut modifier une valeur documentée au niveau du navigateur ; un proxy modifie une route réseau. Aucun de ces changements ne prouve ce qu’un fournisseur a évalué ni n’établit que ces entrées ont causé l’échec d’une requête de l’application. Conservez un relevé de configuration du navigateur pour la reproductibilité, mais ne rebaptisez pas des différences de configuration en causes mesurées de CAPTCHA.

C’est aussi pourquoi une étiquette générique « humain ou bot » est trop grossière pour un incident d’assistance. Un résultat peut concerner la vérification du jeton, une évaluation contextuelle ou une règle distincte de l’application. La question utile est de savoir quel composant a renvoyé quel champ documenté. Une étiquette générale perd cette distinction et peut orienter l’opérateur comme l’équipe applicative vers un correctif que les éléments disponibles n’étayent pas.

Suivez un jeton jusqu’à la décision du serveur

Un rappel de fin d’exécution dans le navigateur est un événement dans un parcours plus long. Pour les intégrations traitées ici, le site doit effectuer la vérification côté serveur exigée par le fournisseur avant de se fier au jeton de réponse. L’application décide ensuite d’autoriser ou non l’opération demandée selon ses propres règles. Un jeton n’est pas un justificatif d’autorisation général pour toutes les routes du site.

Utilisez ce modèle ordonné pour examiner une intégration : le navigateur exécute le parcours client configuré ; un jeton de réponse est remis à l’application ; le backend le valide auprès du fournisseur ; le backend vérifie les champs renvoyés pertinents pour son intégration ; l’application applique sa politique. Ce sont des responsabilités logiques, pas une trace de paquets capturée dans le déploiement d’un véritable client.

La documentation de vérification côté serveur de Google exige une requête du backend contenant le secret et le jeton de réponse. Elle indique que chaque jeton de réponse est valable deux minutes et peut être vérifié une fois. Le secret doit rester sur le serveur. Un journal du navigateur contenant un jeton ne prouve pas qu’une requête de vérification ultérieure a réussi, et le jeton lui-même ne doit pas être copié dans un rapport public d’incident.

Pour v3, le guide officiel demande au site de vérifier l’action et d’évaluer le score dans son contexte. C’est une responsabilité d’intégration du propriétaire. Un visiteur qui voit échouer l’envoi d’un formulaire ne peut pas déduire le score renvoyé, la politique configurée ou le résultat de ces contrôles simplement en examinant le texte d’erreur du formulaire. Demandez une corrélation à l’opérateur plutôt que de traiter un score deviné localement comme un élément probant.

Le guide de validation côté serveur de Turnstile de Cloudflare exige également Siteverify ; le widget client seul ne suffit pas. Il documente une durée de validité du jeton de 300 secondes après sa génération et un usage prévu unique. Toutefois, la détection de réutilisation repose sur une cohérence éventuelle : des validations très rapprochées peuvent réussir avant la propagation de l’état d’utilisation. Cela ne constitue pas un contrat de jetons réutilisables. N’implémentez pas de cache de jetons réutilisables et ne considérez pas l’événement de fin d’exécution du widget comme l’équivalent d’une validation réussie du backend. Le comportement documenté par le fournisseur reste la référence pour la gestion du rejeu.

Étape	Éléments accessibles au composant responsable	Ce que le succès ne prouve toujours pas
Interaction client	État du widget, rappel ou erreur client documentée	La validation du jeton par le backend a réussi
Vérification du fournisseur	La véritable réponse de Siteverify	L’application autorise l’opération métier
Politique de l’application	Contrôles configurés par le propriétaire et journaux des requêtes	Toutes les opérations futures seront acceptées
Résultat de l’application	Le résultat authentifié ou transactionnel attendu	Une autre session obtient la même évaluation

Un widget intégré et une page de défi en périphérie occupent aussi des positions différentes dans le parcours d’une requête. Turnstile peut être intégré sans exiger que le trafic du site passe par le CDN de Cloudflare. Les Challenge Pages de Cloudflare peuvent, elles, remplacer par du HTML la réponse attendue d’une ressource. Le diagnostic d’un scraper bloqué couche par couche distingue les observations de requête, de transport et d’application ; utilisez cette investigation lorsque le corps même de la réponse change, plutôt que de supposer que tous les contrôles liés à Cloudflare correspondent à la même intégration.

Rédigez une observation sans inventer de score

Une observation utile indique comment chaque champ a été établi. Séparez les éléments visibles d’une capacité officielle du produit et des faits connus du seul propriétaire. Le texte suivant est un modèle vierge à copier, pas le résultat d’un test de fournisseur. Remplacez chaque élément entre crochets par une valeur vérifiée ou laissez-le inconnu.

interaction_observed: [checkbox / image task / no visible widget / unknown]
product_identification: [documented integration or owner confirmation / unknown]
mechanism_documented: [official source and applicable mode / unknown]
placement_observed: [embedded / interstitial / unknown]
client_completion_observed: [yes / no / unknown]
backend_verification: [owner-confirmed result / unknown]
application_result: [expected result / refused / unknown]
correlation_reference: [redacted request reference / unavailable]

Pour un exemple concret de raisonnement, supposons qu’un testeur autorisé voit une case à cocher intégrée à un formulaire de connexion, puis une erreur générique du formulaire. C’est un scénario hypothétique. Le champ d’interaction peut indiquer une case à cocher ; l’emplacement peut indiquer une intégration dans la page. Sans détails d’intégration, le produit et le mécanisme restent inconnus. Sans éléments du backend, la vérification reste inconnue. L’erreur du formulaire établit un échec du résultat applicatif, pas un score précis ni un échec de preuve.

Supposons maintenant que le propriétaire du site confirme le produit et fournisse une réponse de vérification en échec, expurgée de données sensibles, pour cette requête exacte. Le champ du backend peut alors être renseigné à partir de cet élément. Cela n’établit toujours pas pourquoi le fournisseur a produit ce résultat au-delà des champs de réponse documentés, ni qu’un changement de navigateur le corrigerait. Chaque affirmation supplémentaire nécessite sa propre source.

Consignez la portée d’une observation autant que son contenu. Une requête de production, une clé officielle de test et un rappel simulé localement répondent à des objectifs différents. Une simulation peut tester la manière dont l’application traite un rappel, mais ne peut pas établir le comportement du fournisseur. Un dispositif de test du fournisseur peut exercer le parcours d’intégration documenté dans les conditions indiquées, mais ne constitue pas une mesure de l’évaluation ordinaire du risque en production. Identifiez explicitement ces environnements.

Excluez les secrets, les jetons de réponse complets, les cookies et les données personnelles d’un dossier partagé. Une référence minimale de corrélation et une erreur documentée expurgée sont généralement plus utiles qu’un export complet du navigateur. Le propriétaire peut conserver les détails nécessaires selon les règles d’accès et de conservation de l’application. Collecter davantage de données ne produit pas automatiquement une explication plus exacte.

Choisissez la prochaine action selon votre rôle

Un propriétaire de site peut examiner la configuration et les enregistrements de vérification du backend. Un opérateur d’automatisation autorisé ne le peut généralement pas. Choisissez la prochaine étape à partir de cette limite d’accès, plutôt que d’une promesse selon laquelle un « type » particulier de CAPTCHA aurait un remède universel. La classification est utile lorsqu’elle dirige la demande vers le bon responsable de composant et évite des expérimentations locales non étayées.

Votre rôle et la situation observée	Prochaine action délimitée	Évitez de conclure
Propriétaire du site ; le parcours client se termine, mais l’application refuse	Corréler les enregistrements exacts de validation du backend et de politique applicative	Un widget terminé garantit une autorisation
Testeur d’intégration ; aucun widget n’est visible	Confirmer le produit et le mode configurés à l’aide du guide officiel d’intégration	Le contrôle est absent ou repose exclusivement sur l’attestation
Opérateur autorisé ; les données attendues deviennent un défi	Suspendre l’extraction dépendante et conserver un relevé minimal de la transition	Le fournisseur a identifié une valeur particulière du navigateur
Relecteur d’assistance ; seule une capture est disponible	Classer l’interaction et demander les éléments manquants au propriétaire	Le score caché ou le mécanisme exact de preuve est connu

La référence sur la cohérence de l’automatisation de BotBrowser documente des contrôles au niveau du navigateur fondés sur des profils, notamment les surfaces spécifiées liées à l’automatisation. Sa référence de configuration de proxy couvre la configuration de routage prise en charge. Ces contrôles aident à décrire un environnement reproductible ; ils ne valident pas les jetons des fournisseurs, ne modifient pas la politique d’autorisation d’une application et n’établissent pas un résultat sans défi. Aucune de ces références ne documente une solution CAPTCHA universelle.

Pour une intégration existante, terminez par une question à laquelle il est possible de répondre : quel composant est responsable de la première étape non vérifiée ? Si le résultat du backend n’est pas disponible, une interprétation supplémentaire de la case à cocher ne le fournira pas. Si la validation du jeton a réussi mais que l’application a refusé l’action, examinez la décision de l’application auprès de son responsable habilité. Si un site tiers exige un défi, utilisez sa procédure prise en charge de récupération humaine ou par un opérateur, plutôt que de considérer le tableau de classification comme une permission de poursuivre l’extraction.

Questions fréquentes

Un CAPTCHA invisible est-il identique à reCAPTCHA v3 ?

Non. reCAPTCHA v2 invisible, reCAPTCHA v3, Turnstile Invisible et les modes invisibles de hCaptcha ont des modèles d’intégration documentés différents. « Invisible » décrit la présentation, pas une interface de notation commune. Identifiez le produit et le mode réels avant d’appliquer leur documentation de vérification.

Une case à cocher signifie-t-elle que le service a mesuré un score de risque ?

Une case à cocher seule n’établit pas l’existence d’un score numérique exposé au site. Lisez le contrat de réponse du produit déployé. Même lorsqu’un service renvoie un score, l’interaction visible ne révèle pas la valeur de la requête concernée.

Un même système peut-il utiliser une preuve de travail et un widget visible ?

Oui, les mécanismes et les modes d’interaction ne sont pas nécessairement exclusifs. Turnstile documente des contrôles de calcul aux côtés de plusieurs modes de widget. Cette affirmation au niveau du produit ne prouve pas qu’une requête précise a utilisé tous les mécanismes documentés ; l’exécution exacte reste inconnue, sauf si des éléments applicables l’établissent.

Sources

• Google : versions de reCAPTCHA
• Google : reCAPTCHA v3
• Google : vérification de la réponse de l’utilisateur
• Cloudflare : Turnstile
• Cloudflare : modes du widget
• Cloudflare : validation côté serveur
• hCaptcha : modes invisible et passif
• BotBrowser : cohérence de l’automatisation
• BotBrowser : configuration de proxy

Conclusion pratique

Décrivez l’interaction réellement observée, ajoutez uniquement les mécanismes documentés, situez l’intégration et laissez la décision du backend inconnue jusqu’à confirmation par son responsable. Une case à cocher n’est pas un score, invisible n’est pas une attestation et un jeton n’est pas une autorisation applicative. Commencez par la classification à quatre champs, puis demandez au responsable de la première étape non vérifiée les éléments nécessaires pour poursuivre.