reCAPTCHA v3 vs v2 : responsabilités du site

Le choix utile entre reCAPTCHA v3 vs v2 porte sur les interactions et les responsabilités du serveur qu’un site peut prendre en charge. V2 avec case propose une interaction délibérée ; v2 invisible peut toujours présenter un défi ; v3 renvoie un score que le site doit transformer en décision applicative. BotBrowser fournit des contrôles du navigateur fondés sur des profils pour un environnement client reproductible, mais ne peut pas choisir cette politique, vérifier un jeton du fournisseur au nom du site ou révéler un score privé à un visiteur. Une intégration existante nécessite un responsable identifié pour le parcours du navigateur comme pour le résultat du backend.

Ces noms désignent des intégrations web classiques existantes, y compris les intégrations prises en charge conservées après une migration de compte. La documentation actuelle des clés Google Cloud associe CHECKBOX à l’ancien v2 Checkbox, INVISIBLE à l’ancien v2 Invisible et SCORE à l’ancien v3. Le guide de migration de Google confirme que l’instrumentation et les appels du backend existants peuvent continuer. L’avis de dépréciation des guides classiques ne signifie pas que ces contrats déployés ont cessé de fonctionner ; les nouvelles fonctionnalités Cloud et les procédures de migration nécessitent leur propre documentation à jour.

Résumé

• Comparez les trois intégrations web réelles : v2 avec case, v2 invisible et v3. V2 invisible n’est pas un autre nom de v3.
• Chaque intégration nécessite une vérification du jeton dans le backend. Un rappel réussi dans le navigateur n’autorise pas l’envoi d’un formulaire.
• V3 exige que le site vérifie l’action attendue et décide ce que le score renvoyé signifie pour cette opération. Supprimer une énigme ne supprime pas ce travail.
• Choisissez une interaction que l’application peut expliquer et dont elle peut gérer les incidents, puis attribuez les contrôles du serveur et le résultat applicatif à des responsables précis.
• Les guides classiques de Google affichent désormais un avis de dépréciation. La documentation Cloud actuelle fait correspondre leurs anciens noms et prend en charge les intégrations existantes ; confirmez la clé et l’API déployées plutôt que d’appliquer cette comparaison à tous les produits actuels.

Sommaire

• La matrice de décision pour une intégration web existante
• Le parcours du navigateur modifie l’expérience utilisateur
• La vérification du backend reste obligatoire
• V3 ajoute une politique d’action et de score
• La liste des responsabilités d’implémentation
• Trois choix hypothétiques et leurs chemins d’échec
• Conclusion pratique

La matrice de décision pour une intégration web existante

Le comparatif des versions de Google distingue les formes avec case et invisible de v2 de v3. La comparaison porte sur leurs contrats documentés d’intégration web, pas sur un classement mesuré de l’efficacité de leur sécurité. Un site qui utilise déjà l’un de ces contrats peut évaluer un changement en se demandant ce que son interface et son backend devront ensuite prendre en charge. Un visiteur qui cherche à expliquer un refus a une autre tâche et ne dispose généralement pas des enregistrements serveur nécessaires à cette décision.

La terminologie a une limite actuelle. La documentation des clés de Google associe SCORE à l’ancien v3, CHECKBOX à l’ancien v2 Checkbox et INVISIBLE à l’ancien v2 Invisible. Elle décrit aussi d’autres types d’intégration. Les anciens noms restent donc utiles pour identifier des implémentations existantes, mais ne décrivent pas toute la gamme actuelle de produits. La matrice suivante s’applique aux parcours web classiques nommés et à leur modèle documenté de vérification ; elle ne recommande pas de démarrer par défaut un nouveau déploiement Cloud avec une ancienne API.

Critère de décision	V2 avec case	V2 invisible	V3
Interaction initiale de l’utilisateur	Cliquer sur la case affichée	Déclencher depuis un bouton ou une API JavaScript ; aucun clic initial sur une case	Déclencher pour une action du site sans qu’une tâche CAPTCHA interrompe ce parcours
Défi possible dans le parcours documenté	Peut valider immédiatement ou présenter un défi	Peut présenter un défi malgré le point d’entrée invisible	Renvoie un score ; le site choisit sa réponse ultérieure
Responsabilité d’intégration dans le navigateur	Afficher le bon widget et gérer la fin du parcours, l’expiration et les erreurs	Relier l’exécution à l’opération prévue et gérer la fin du parcours, l’expiration et les erreurs	Exécuter pour l’action prévue et transmettre rapidement le jeton au backend
Responsabilité de vérification du backend	Valider le jeton de réponse via le point de terminaison serveur documenté	Valider le jeton de réponse via le point de terminaison serveur documenté	Valider le jeton de réponse et vérifier l’action attendue
Responsabilité de politique applicative	Décider si l’opération vérifiée est permise par les règles de l’application	Décider si l’opération vérifiée est permise par les règles de l’application	Interpréter le score dans le contexte de l’opération et appliquer la politique du site
Une raison d’envisager ce contrat	Une étape délibérée avec case convient au parcours utilisateur existant	Le formulaire existant doit déclencher la vérification depuis son propre bouton tout en conservant un chemin de défi	Le site peut gérer le score dans son contexte et le parcours utilisateur ou de modération qui en découle
Une raison de reporter le changement	L’interface ne peut pas prendre en charge l’interaction ou ses états de récupération	L’équipe n’a pas conçu les états possibles du défi et des rappels	Personne n’est responsable de la validation de l’action, du traitement du score ou de la réponse applicative

Les deux dernières lignes sont des règles de choix d’ingénierie, pas des affirmations de performance de Google. Par exemple, une équipe qui n’a pas attribué le traitement des scores ne peut pas faire disparaître cette obligation en choisissant un parcours client moins visible. À l’inverse, une équipe qui conserve v2 a toujours besoin d’un véritable vérificateur dans le backend. Le modèle de classification des CAPTCHA sépare présentation et mécanisme ; la décision supplémentaire est ici le contrat documenté que l’application va implémenter et maintenir.

Les clés existantes nécessitent également un inventaire administratif. Le guide actuel de migration de Classic de Google indique que les intégrations existantes prises en charge peuvent conserver leur instrumentation web et leurs appels du backend, et continuer à utiliser siteverify après migration. Cette affirmation ne fait pas d’une migration de compte la même opération qu’un passage de v2 à v3. Consignez séparément la propriété de la clé, l’intégration cliente déployée et le point de terminaison du backend avant de décider quelle responsabilité change réellement.

Le parcours du navigateur modifie l’expérience utilisateur

Avec v2 à case, le site affiche un widget qui demande au visiteur de cliquer. Le guide d’affichage de v2 de Google permet un affichage automatique ou un affichage explicite après le chargement de la bibliothèque. Le choix influence la manière dont l’application initialise le contrôle, notamment lorsqu’un formulaire est monté dynamiquement. Une boîte affichée seule n’établit pas que le gestionnaire d’envoi de l’application joindra le bon jeton de réponse à la bonne opération.

Le parcours avec case peut accepter l’interaction immédiatement ou demander un défi supplémentaire, selon le comparatif des versions. L’application doit prendre en charge cette branche plutôt que promettre le même nombre de clics à chaque visiteur. L’équipe d’assistance doit aussi distinguer un widget qui ne s’est jamais initialisé d’un visiteur ayant atteint un défi. Ce sont des états utilisateur différents qui nécessitent des explications différentes ; aucun ne prouve l’existence d’un score numérique visible par le visiteur.

V2 invisible change le point d’entrée. Le guide invisible de Google permet une liaison automatique à un bouton, une liaison par programmation ou un déclenchement par programmation. Un bouton Envoyer ordinaire peut donc commencer le contrôle sans case préalable. Cependant, cette intégration peut toujours demander un défi. La qualifier d’invisible n’engage pas l’ensemble du parcours applicatif à rester sans vérification visible et ne fournit pas au site le contrat documenté de réponse avec score de v3.

Le rappel appartient au flux de contrôle du formulaire. Dans une intégration invisible, l’application peut d’abord effectuer sa validation habituelle des champs, déclencher la vérification et envoyer le formulaire après le rappel de fin du parcours. L’exemple officiel invisible illustre cette séquence. Une véritable application doit toujours empêcher qu’un rappel sans rapport, une activation répétée du bouton ou un état périmé du formulaire soit pris pour la fin de l’opération actuelle. C’est une exigence d’association de l’application, pas une affirmation selon laquelle la bibliothèque cliente de Google fournirait un gestionnaire de transactions applicatives.

V3 associe au contraire l’exécution à une action et renvoie un jeton pour évaluation dans le backend. Le guide de v3 décrit la liaison à un bouton et le déclenchement par programmation, et conseille d’exécuter le contrôle lorsque l’utilisateur réalise l’action plutôt qu’au chargement de la page, car les jetons expirent. Une page de paiement longtemps ouverte ne peut pas considérer son chargement initial comme un événement de vérification permanent. Le responsable du client doit identifier l’opération réellement protégée et le moment où son jeton doit être obtenu.

L’accessibilité reste une composante du parcours applicatif, quel que soit le contrat conservé. La configuration d’affichage documente les contrôles de langue et de tabindex, tandis que le guide invisible décrit aussi la position du badge et le traitement des rappels. Ces options ne certifient pas l’accessibilité du formulaire qui entoure le widget. Testez l’ordre de focus, les messages d’état et le chemin de récupération prévu par le site avec le widget réellement configuré. L’absence de tâche CAPTCHA dans v3 n’établit pas non plus qu’une étape supplémentaire choisie par l’application soit utilisable ; le site est responsable du comportement qu’il ajoute.

La vérification du backend reste obligatoire

L’obligation commune du serveur est plus précise et plus limitée que « le navigateur a réussi ». Le guide de vérification de Google exige que le backend envoie un POST à https://www.google.com/recaptcha/api/siteverify avec le secret et le jeton de réponse. remoteip est documenté comme facultatif. Garder le secret dans le backend fait partie de cette intégration ; recevoir un jeton dans un rappel n’est que la transmission du client à l’application, pas un remplacement de la requête au fournisseur.

Le même guide limite chaque jeton de réponse à deux minutes et une vérification. Un backend qui place un jeton dans une file de travail retardée indéfiniment n’a pas conservé une vérification valide simplement parce que le rappel initial s’est terminé. Une requête déjà vérifiée ne peut pas utiliser ce jeton de vérification comme justificatif de session réutilisable pour des opérations sans rapport. L’application nécessite un nouveau parcours documenté lorsqu’une nouvelle réponse est requise, tandis que ses propres contrôles de session et de transaction conservent leurs objectifs distincts.

La référence des erreurs serveur distingue les secrets absents ou invalides, les réponses absentes ou invalides, une requête mal formée et timeout-or-duplicate. La dernière erreur combine deux possibilités : une réponse peut être trop ancienne ou avoir déjà été utilisée. Elle n’identifie pas à elle seule laquelle s’est produite. Un responsable peut corréler les horaires et ses propres appels de vérification pour enquêter, mais ne doit pas transformer cette erreur combinée documentée en défaillance précise du navigateur sans éléments correspondants.

La vérification possède aussi un contrat de réponse. La réponse web classique documente success, challenge_ts, hostname et les error-codes facultatifs ; la réponse de v3 documente en plus score et action. challenge_ts décrit l’heure de chargement du défi, pas l’horodatage d’une transaction métier terminée. hostname fournit le contexte documenté du site, pas la preuve que la règle de compte ou de paiement de l’application ait autorisé quoi que ce soit. Conservez ces significations des champs pour concevoir les contrôles serveur et les messages d’incident.

Le responsable du backend doit définir un résultat lorsque la vérification ne peut pas être achevée. Un délai réseau dépassé vers le point de terminaison de vérification, une réponse avec success: false et un jeton vérifié suivi d’un refus applicatif sont trois états différents. Le protocole de vérification définit l’échange avec le fournisseur ; le site doit décider comment son propre point de terminaison signale et traite chaque état. Une exception non gérée ou un message ambigu « réessayez » ne doit pas être silencieusement compté comme un accès vérifié.

L’autorisation applicative suit cet échange. Un jeton valide n’établit pas qu’un mot de passe était correct, qu’un compte était éligible ou qu’une commande respectait les règles du site. Si une intégration existante change de version, conservez ces contrôles plutôt que de considérer un nouveau rappel client comme leur remplacement. Le guide d’intégration de v3 place explicitement l’action contextuelle après l’évaluation renvoyée. Le choix pertinent porte sur le résultat vérifié reçu par le backend et sur ce que l’application en fera.

V3 ajoute une politique d’action et de score

Le champ action de v3 est un accord d’intégration entre le déclenchement client et l’attente du backend. Google demande de vérifier que le nom de l’action est celui attendu lors du contrôle d’une réponse. Son guide des actions limite aussi les noms d’action aux caractères alphanumériques, aux barres obliques et aux traits de soulignement, et précise qu’ils ne doivent pas être propres à un utilisateur. Le site doit définir des noms d’opérations plutôt que d’encoder une adresse e-mail, un identifiant de compte ou une autre identité utilisateur dans ce champ.

La valeur attendue doit provenir de la compréhension de l’opération par le serveur. Copier simplement un nom d’action fourni par l’appelant dans un champ « attendu » n’établirait pas qu’il correspond au point de terminaison prévu. Pour une opération de connexion existante, le responsable du backend doit connaître l’action documentée qui appartient à cette opération avant de vérifier la valeur renvoyée. C’est une conséquence de l’exigence d’action attendue de Google, pas une nouvelle API du fournisseur ni une affirmation selon laquelle un site tiers particulier l’appliquerait correctement.

Le score est un autre champ renvoyé, pas un verdict applicatif. La documentation de v3 décrit une plage de 0.0 à 1.0 et des réponses contextuelles telles qu’une authentification supplémentaire ou une modération. Choisir v3 crée donc une responsabilité de politique du site : un responsable doit décider de la réponse appropriée pour chaque action protégée et de la personne chargée d’examiner les résultats inattendus. Aucun seuil universel ni recette de configuration du navigateur ne peut remplacer cette décision pour toutes les applications.

Google indique aussi que le service apprend du trafic réel : les scores dans un environnement de préproduction ou peu après l’implémentation peuvent donc différer de ceux de production. Cette réserve liée à l’environnement compte pour accepter un changement de version. Un formulaire de préproduction qui atteint sa page de succès prouve uniquement le résultat déclaré de l’intégration de préproduction ; il n’établit ni la distribution des scores de production ni la pertinence d’une politique applicative. Séparez la validité de la vérification de toute évaluation ultérieure des décisions opérationnelles du site.

La description publique classique indique que les scores reposent sur les interactions avec le site et qu’un contexte plus large inclut des comportements légitimes et abusifs. Elle ne publie pas de modèle complet de pondération permettant à un client de navigateur de calculer son propre score. Le guide de placement de v3 décrit une intégration ; il ne prouve pas que modifier une propriété du navigateur changera un résultat particulier. Maintenez cette distinction lorsqu’une comparaison de versions est utilisée à la fois par les ingénieurs applicatifs et par les opérateurs d’automatisation autorisés.

Le résultat visible appartient à un champ différent du résultat du fournisseur. Par exemple, l’application peut exiger une autre étape d’authentification après l’évaluation ; l’absence d’énigme ne signifie pas que l’opération demandée a été immédiatement autorisée. Les exemples d’interprétation du score de Google montrent ce type de séparation. Une décision de version doit nommer la réponse applicative prévue et son responsable avant le déploiement, plutôt que de laisser le comportement du produit à une interprétation non documentée de n’importe quel nombre reçu.

La liste des responsabilités d’implémentation

La liste suivante transforme la matrice en transmission entre les équipes applicatives. Son résultat attendu est un responsable nommé et une réponse documentée pour chaque responsabilité exigée par le contrat choisi. C’est une liste de conception, pas une réponse capturée du fournisseur ni une preuve du comportement d’un site déployé. Les exigences de vérification et le contrat d’action de v3 de Google fournissent les obligations du fournisseur ; l’association et les choix de récupération de l’application appartiennent au site.

Responsabilité à attribuer	Éléments que le responsable doit fournir	Choix concerné
Inventaire des clés et de l’intégration	Le produit configuré, la propriété de la clé et les noms d’API du client et du backend, sans partager de secrets	Confirme le contrat existant maintenu
Initialisation du navigateur	Le chemin d’affichage ou d’exécution du widget, l’opération protégée prévue et la gestion de la fin du parcours, de l’expiration et des erreurs	Distingue case à cocher, déclenchement invisible et exécution d’action v3
Vérification du jeton	La gestion par le backend de la requête de vérification documentée et des états d’échec renvoyés	Obligatoire pour chaque intégration comparée
Action attendue	L’action définie par le serveur pour chaque point de terminaison protégé et son contrôle face au champ renvoyé par v3	Exigée par le contrat de v3
Réponse au score	Le responsable de la politique applicative et le résultat prévu pour chaque opération pertinente	Rend l’évaluation v3 exploitable sans la confondre avec une autorisation
Résultat applicatif	Les contrôles ordinaires d’authentification ou de transaction et un résultat utilisateur non ambigu	Reste la responsabilité du site après la vérification du fournisseur
Récupération et assistance	Un moyen de distinguer initialisation client, réponse expirée, vérification du backend et refus applicatif	Empêche tous les échecs de devenir une erreur CAPTCHA inexpliquée

L’initialisation cliente mérite un cas d’acceptation précis. Le guide d’affichage de v2 exige qu’un rappel onload d’affichage explicite existe avant le chargement de l’API. Cela crée une véritable contrainte d’ordre pour les applications qui chargent des composants et des scripts de façon asynchrone. Le responsable du client doit vérifier le chemin d’affichage choisi plutôt que de supposer que voir api.js dans un panneau réseau prouve que le contrôle était prêt lors de l’envoi. Un événement de chargement de bibliothèque et un état utilisable du formulaire sont des conditions d’acceptation distinctes.

Les rappels d’expiration et d’erreur nécessitent aussi un traitement visible. La configuration invisible de Google décrit ces rappels et rend l’application responsable d’informer l’utilisateur qu’il doit réessayer lorsqu’elle fournit un rappel d’erreur. Une décision de maintenance doit inclure le message et l’action de récupération autorisée, pas seulement le nom du rappel. Le backend doit traiter indépendamment une réponse expirée ou invalide, même si le client a présenté un message informatif.

La référence sur la cohérence de l’automatisation de BotBrowser peut soutenir une configuration reproductible du navigateur lorsqu’une équipe exerce son application autorisée. Cette capacité aide à comparer le même comportement de formulaire dans un environnement déclaré. Elle n’implémente pas les responsabilités serveur de la liste, n’émet pas les identifiants du site et n’établit pas un score du fournisseur à partir d’observations locales du navigateur. Un test de formulaire doit rapporter la condition applicative effectivement vérifiée, en consignant séparément la version d’intégration choisie et toute conclusion sur l’accès.

Trois choix hypothétiques et leurs chemins d’échec

Considérons un formulaire d’assistance existant hypothétique utilisant v2 avec case. Son responsable souhaite supprimer la case initiale tout en conservant un parcours capable de présenter un défi. La comparaison des variantes documentées de v2 fait de v2 invisible un contrat pertinent à évaluer. Le travail concret porte sur le déclenchement depuis le bouton, l’association du rappel et la récupération utilisateur, tandis que la vérification du backend reste requise. Qualifier ce changement de « passage à v3 » identifierait mal à la fois le parcours client choisi et l’absence d’une nouvelle obligation de politique de score v3.

Considérons maintenant une application hypothétique qui souhaite v3 pour une action de connexion. Le client peut déclencher v3, mais l’équipe n’a attribué ni la validation de l’action attendue ni la réponse à une évaluation nécessitant une étape supplémentaire. Le guide des actions et de l’interprétation de v3 de Google identifie les responsabilités manquantes. La décision de la matrice est de reporter le déploiement jusqu’à ce que ces responsables et résultats applicatifs existent, plutôt que de déduire que tout est prêt d’un jeton apparu dans un rappel du navigateur. Cet exemple ne représente aucune véritable exécution du fournisseur ni aucun score mesuré.

Enfin, supposons qu’une intégration v3 maintenue hypothétique reçoive une réponse du fournisseur avec success: true, mais que l’application refuse l’envoi. Le backend doit distinguer la vérification du jeton, le contrôle de l’action renvoyée et son propre résultat de politique. La définition de réponse de v3 sépare ces champs et responsabilités ; success ne promet pas une connexion réussie. Sans l’enregistrement serveur pertinent, un observateur extérieur ne peut pas décider si le refus concernait l’action, l’état du compte ou une autre règle applicative.

Ces scénarios aboutissent à des responsables différents, même lorsque l’utilisateur voit la même erreur générique. Un chemin d’initialisation défectueux relève de l’intégration cliente ; une requête de vérification invalide relève du backend ; une évaluation valide suivie d’une restriction prévue relève du responsable de politique applicative. Si un défi interrompt plutôt une collecte autorisée sur un autre site, le diagnostic d’un CAPTCHA en cours d’exécution traite la transition des requêtes et la récupération approuvée. La matrice des versions n’autorise ni à sonder la politique cachée du site ni à poursuivre l’extraction au-delà de sa décision d’accès.

Questions fréquentes

reCAPTCHA v3 est-il toujours meilleur que v2 ?

Les contrats documentés attribuent des travaux différents au site. V3 retire l’interaction CAPTCHA de son propre parcours, mais nécessite un traitement contextuel du score et la validation de l’action attendue. V2 avec case et invisible conservent leurs possibilités documentées de défi. Les descriptions des versions n’établissent pas de classement universel d’efficacité pour chaque application, déploiement et cas d’abus.

reCAPTCHA v2 invisible est-il la même intégration que v3 ?

Non. Le guide invisible décrit un parcours de déclenchement v2 qui peut toujours présenter un défi. V3 possède son propre contrat d’action et de score. Un bouton qui déclenche la vérification n’identifie pas l’intégration configurée par son responsable.

Une réponse Siteverify réussie autorise-t-elle l’opération ?

Elle établit le résultat documenté de vérification. L’application reste responsable de ses contrôles d’action, de sa politique de score applicable et de ses règles ordinaires d’autorisation. Les champs de réponse de v3 de Google doivent rester distincts du résultat final de l’application.

Les intégrations classiques existantes peuvent-elles encore utiliser ces noms ?

La documentation actuelle des clés fait correspondre les anciens noms, et le guide de migration de Google décrit la poursuite de l’instrumentation et des appels backend existants. Vérifiez la clé et le contrat d’intégration réels ; ces affirmations n’étendent pas cette comparaison à toutes les fonctionnalités Cloud et ne constituent pas une procédure de migration.

Sources

• Google : choisir le type de reCAPTCHA
• Google : affichage et configuration de reCAPTCHA v2
• Google : reCAPTCHA invisible
• Google : reCAPTCHA v3
• Google : vérifier la réponse de l’utilisateur
• Google Cloud : clés reCAPTCHA et anciens noms d’intégration
• Google Cloud : migrer depuis reCAPTCHA Classic
• BotBrowser : cohérence de l’automatisation

Conclusion pratique

Choisissez le contrat v2 ou v3 à maintenir selon l’interaction que l’application peut prendre en charge et les responsabilités du backend que ses responsables peuvent implémenter. Utilisez la matrice pour identifier le parcours client, conserver la vérification obligatoire et attribuer explicitement les décisions d’action et de score v3. Complétez la liste des responsabilités avant un changement de version, puis validez le résultat réel de l’application. Une étiquette de version seule ne fournit ni une politique d’autorisation ni la preuve qu’un refus existant disparaîtra.