Comment fonctionne le scoring reCAPTCHA v3 : guide technique 2026

Le scoring reCAPTCHA v3 est devenu le mécanisme anti-bot invisible dominant sur le web en 2026. Contrairement à reCAPTCHA v2 qui présente un défi visuel, la version 3 attribue un score de risque continu entre 0.0 et 1.0 pour chaque action, sans interaction utilisateur visible. Comprendre comment fonctionne le scoring reCAPTCHA v3 est essentiel pour les ingénieurs QA, les équipes d'automatisation et les chercheurs en sécurité qui doivent faire passer leurs requêtes légitimes tout en respectant les politiques des plateformes.

Comment fonctionne le scoring reCAPTCHA v3 : le modèle de score

reCAPTCHA v3 fonctionne sur un principe simple mais redoutable : chaque interaction utilisateur est notée individuellement. Lorsqu'un visiteur charge une page protégée, le script JavaScript grecaptcha.execute(siteKey, {action: 'login'}) déclenche une évaluation côté client. Google renvoie un token que le serveur backend soumet ensuite à l'endpoint siteverify pour obtenir le score final.

Le score est un nombre flottant compris entre 0.0 (bot probable) et 1.0 (humain probable). Google discrétise en interne ce score en onze paliers (0.0, 0.1, 0.2, …, 1.0), ce qui donne une granularité suffisante pour distinguer les comportements suspects sans produire de faux positifs excessifs. Les sites configurent ensuite des seuils d'action :

• Blocage : score < 0.3 — la requête est rejetée ou soumise à un défi v2 de secours.
• Défi : score entre 0.3 et 0.6 — une vérification supplémentaire (email, SMS, captcha visuel) est exigée.
• Autorisation : score > 0.6 — la requête passe sans friction.

Ces seuils ne sont pas des standards Google mais des décisions implémentées côté serveur par chaque site. Un site bancaire peut exiger > 0.8 pour une transaction, tandis qu'un formulaire de newsletter peut tolérer > 0.3. La documentation officielle de Google décrit le modèle de score comme une recommandation, laissant aux développeurs le soin d'ajuster les seuils selon leur tolérance au risque.

Les signaux fusionnés par le moteur de risque

Le score reCAPTCHA v3 n'est pas basé sur un seul signal. Google fusionne des dizaines de features issues de plusieurs domaines pour produire une évaluation probabiliste. Voici les principales catégories :

1. Télémétrie comportementale

Le script collecte les événements de souris (mouvement, clics, vitesse), de scroll (direction, rythme, saccades), et de clavier (délai entre touches, rythme de frappe). Un bot qui soumet un formulaire en 50 ms sans aucun mouvement de souris reçoit un score proche de 0.1. Un humain qui remplit un formulaire en 8 secondes avec des hésitations et des corrections obtient naturellement un score > 0.7.

2. Empreinte du navigateur et TLS

Google examine les caractéristiques du navigateur : User-Agent, ensemble de headers HTTP, ordre des headers, support WebGL, canvas fingerprint, et surtout l'empreinte TLS. L'ordre des cipher suites TLS, les extensions ClientHello, et la signature JA3/JA4 permettent d'identifier les clients automatisés. Une bibliothèque Python requests produit un JA3 radicalement différent de Chrome 120. Les outils comme Playwright avec un navigateur Chromium réel reproduisent une empreinte TLS authentique, ce qui est indispensable pour maintenir un score acceptable.

3. Graphe de cookies Google

Si l'utilisateur possède un cookie Google (NID, SID, __Secure-1PSID) issu d'une session de navigation antérieure, Google peut corréler l'activité avec un historique de navigation humain. Un cookie frais ou absent est un signal négatif, mais pas disqualifiant. Un visiteur sans cookie Google mais avec un comportement humain cohérent peut encore obtenir un score > 0.6.

4. Réputation IP

C'est ici que le proxy entre en jeu. Google maintient une base de réputation IP massive. Les adresses datacenter (AWS, DigitalOcean, Hetzner) sont systématiquement marquées comme à haut risque, ce qui fait chuter le score indépendamment du comportement. Une IP résidentielle avec un historique de navigation normal reçoit un bonus de réputation. C'est pourquoi les proxies résidentiels sont nécessaires pour l'automatisation légitime : ils fournissent une IP dont la réputation n'est pas compromise par défaut.

Pourquoi les IPs datacenter font chuter le score

Le score reCAPTCHA v3 est multiplicative, pas additive. Si votre IP a une réputation médiocre, le score global est plafonné même si tous les autres signaux sont parfaits. Une IP datacenter peut plafonner le score à 0.2-0.3, ce qui place automatiquement la requête dans la zone de blocage ou de défi, quelle que soit la qualité de l'émulation comportementale.

Google ne publie pas sa formule exacte, mais les tests empiriques montrent que :

• Une IP datacenter avec un navigateur réel et un comportement humain obtient un score de 0.2-0.4.
• Une IP résidentielle avec le même navigateur et le même comportement obtient 0.7-0.9.
• Une IP résidentielle avec un client HTTP brut (curl, requests) obtient 0.1-0.3.

Ces observations sont cohérentes avec les analyses publiées par des chercheurs en sécurité, notamment les travaux sur l'empreinte TLS qui montrent comment les clients automatisés se distinguent par leur ClientHello.

Vérification côté serveur : siteverify, action et hostname

Le token renvoyé par grecaptcha.execute() n'est qu'un jeton à usage unique valable 2 minutes. Le serveur doit le soumettre à https://www.google.com/recaptcha/api/siteverify avec la clé secrète. La réponse JSON contient plusieurs champs critiques :

{
  "success": true,
  "score": 0.85,
  "action": "login",
  "challenge_ts": "2026-01-15T10:30:00Z",
  "hostname": "example.com",
  "error-codes": []
}

Le serveur doit vérifier trois choses :

1. Le score dépasse le seuil configuré pour cette action.
2. L'action renvoyée par Google correspond exactement à celle attendue (ex. login). Si un attaquant capture un token valide pour l'action newsletter et tente de l'utiliser pour login, la non-correspondance doit être détectée.
3. Le hostname correspond au domaine attendu. Un token généré sur phishing-site.com ne doit pas être accepté pour example.com.

Ne pas vérifier l'action et le hostname est une erreur d'implémentation courante qui rend reCAPTCHA v3 trivial à contourner par rejou de token.

Approche légitime avec ProxyHat : un exemple Python complet

Pour les cas d'usage légitimes — tests d'accessibilité automatisés, QA de formulaires, recherche autorisée en sécurité — il faut combiner trois éléments : un proxy résidentiel, un vrai navigateur, et un comportement humain simulé. Voici un exemple fonctionnel avec ProxyHat et Playwright.

from playwright.sync_api import sync_playwright
import time
import random

PROXY = "http://user-country-US:pass@gate.proxyhat.com:8080"

SITE_URL = "https://example.com/login"
RECAPTCHA_SITE_KEY = "6Le...votre_site_key..."

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=False,
        proxy={"server": "http://gate.proxyhat.com:8080",
               "username": "user-country-US",
               "password": "pass"}
    )
    context = browser.new_context(
        viewport={"width": 1920, "height": 1080},
        user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                   "AppleWebKit/537.36 (KHTML, like Gecko) "
                   "Chrome/120.0.0.0 Safari/537.36",
        locale="en-US"
    )
    page = context.new_page()

    # Navigation avec délai humain
    page.goto(SITE_URL, wait_until="networkidle")
    time.sleep(random.uniform(2.0, 4.0))

    # Simulation de mouvement de souris
    page.mouse.move(random.randint(100, 800), random.randint(100, 600))
    time.sleep(random.uniform(0.3, 0.8))
    page.mouse.move(random.randint(200, 900), random.randint(200, 500))
    time.sleep(random.uniform(0.5, 1.2))

    # Saisie progressive avec délais aléatoires
    page.fill("#username", "test_user")
    time.sleep(random.uniform(0.5, 1.0))
    page.fill("#password", "test_pass")
    time.sleep(random.uniform(0.8, 1.5))

    # Exécution de reCAPTCHA v3
    token = page.evaluate(f"""
        async () => {{
            await new Promise(r => grecaptcha.ready(r));
            return await grecaptcha.execute(
                '{RECAPTCHA_SITE_KEY}',
                {{action: 'login'}}
            );
        }}
    """)

    print(f"Token reCAPTCHA : {token[:40]}...")

    # Soumission au serveur pour siteverify
    # (à implémenter côté backend)

    browser.close()

Les points clés de cette approche :

• Proxy résidentiel US via gate.proxyhat.com:8080 avec le flag country-US pour une IP résidentielle américaine.
• Chrome réel via Playwright (pas headless de préférence, ou headless avec stealth) pour une empreinte TLS et canvas authentique.
• Délais aléatoires entre 300 ms et 2000 ms pour simuler un rythme humain.
• Mouvements de souris avant et pendant la saisie pour générer une télémétrie comportementale cohérente.

Avec cette configuration, le score reCAPTCHA v3 attendu se situe entre 0.7 et 0.9, ce qui franchit le seuil d'autorisation de la plupart des sites. Consultez notre page de tarification pour les plans de proxies résidentiels, et la documentation ProxyHat pour les paramètres avancés de géo-ciblage.

Erreurs courantes et cas limites

Erreur 1 : Utiliser un client HTTP brut

requests, httpx, curl ne peuvent pas exécuter JavaScript, donc ne peuvent pas appeler grecaptcha.execute(). Même avec un proxy résidentiel, le score sera nul car le script reCAPTCHA ne s'exécute pas. Il faut un navigateur réel (Playwright, Puppeteer, Selenium avec Chrome).

Erreur 2 : Vitesse d'exécution trop rapide

Un formulaire rempli en 200 ms avec des page.fill() consécutifs sans délai produit un score < 0.3 même avec un proxy résidentiel. Le moteur comportemental détecte l'absence d'hésitation humaine. Introduisez des time.sleep(random.uniform(...)) entre chaque action.

Erreur 3 : Ignorer la cohérence géographique

Si votre proxy est en Allemagne (country-DE) mais que le navigateur déclare locale="en-US" et un fuseau horaire America/New_York, Google peut détecter l'incohérence et pénaliser le score. Alignez le pays du proxy, le locale du navigateur, et le fuseau horaire. Consultez nos localisations disponibles pour choisir le bon pays.

Erreur 4 : Réutiliser un token

Un token reCAPTCHA v3 est valable 120 secondes et pour une seule vérification. Le mettre en cache ou le réutiliser pour plusieurs requêtes échouera systématiquement.

Erreur 5 : Ne pas vérifier l'action côté serveur

Côté serveur, si vous ne vérifiez pas que response["action"] correspond à l'action attendue, un attaquant peut capturer un token d'une action à faible seuil (ex. page_view) et l'utiliser pour une action sensible (ex. transfer). C'est une faille de logique applicative, pas de reCAPTCHA lui-même.

Cas d'usage appropriés et cadre légal

Les techniques décrites ici sont destinées à des usages légitimes :

• QA automatisé de vos propres sites : tester que les formulaires protégés fonctionnent correctement pour les utilisateurs légitimes.
• Tests d'accessibilité : vérifier que les utilisateurs de lecteurs d'écran ne sont pas bloqués par un défi v2 de secours injustifié.
• Recherche en sécurité autorisée : évaluer la robustesse de votre propre implémentation reCAPTCHA dans le cadre d'un pentest convenu.
• Collecte de données publiques conforme : pour des cas comme le suivi SERP ou le web scraping éthique, où la cible n'utilise pas reCAPTCHA sur les pages publiques mais où un proxy résidentiel reste nécessaire pour la fiabilité.

Ce qui n'est pas acceptable : création de comptes frauduleux, contournement de reCAPTCHA pour spam, scalping de billets, ou toute activité violant les conditions d'utilisation d'un site. Aux États-Unis, le Computer Fraud and Abuse Act (CFAA) criminalise l'accès non autorisé à des systèmes informatiques. Dans l'UE, le RGPD impose des limites strictes sur le traitement de données personnelles, y compris les adresses IP. Google elle-même interdit dans ses conditions d'utilisation le contournement de reCAPTCHA à des fins malveillantes.

Règle d'or : si vous devez automatiser l'interaction avec un site tiers protégé par reCAPTCHA v3, assurez-vous d'avoir une autorisation explicite ou que l'activité relève d'un usage légitime et conforme. Le fait qu'une technique fonctionne techniquement ne la rend pas légale.

Pourquoi la rotation d'IP n'est pas toujours nécessaire

Contrairement au scraping classique où la rotation d'IP par requête est essentielle, reCAPTCHA v3 se prête mieux aux sessions persistantes. Si vous maintenez la même IP résidentielle pendant toute une session de navigation (10-30 minutes), le cookie Google et la télémétrie accumulée renforcent le score. La rotation d'IP à chaque action casse cette continuité et peut paraître suspecte.

Avec ProxyHat, utilisez le flag de session pour maintenir la même IP :

# Session persistante avec la même IP résidentielle
PROXY = "http://user-country-US-session-qa123:pass@gate.proxyhat.com:8080"

Réservez la rotation d'IP pour les scénarios de scraping à grande échelle où vous avez besoin de répartir la charge, pas pour l'automatisation de formulaires reCAPTCHA.

Points clés à retenir

• reCAPTCHA v3 attribue un score continu 0.0-1.0 par action, avec des seuils typiques : blocage < 0.3, défi 0.3-0.6, autorisation > 0.6.
• Le score fusionne télémétrie comportementale, empreinte TLS/JA3, graphe de cookies Google, et réputation IP.
• Les IPs datacenter plafonnent le score à 0.2-0.4 indépendamment du comportement — les proxies résidentiels sont indispensables.
• Un navigateur réel (Playwright + Chrome) avec mouvements de souris et délais aléatoires est nécessaire pour générer une télémétrie humaine.
• Vérifiez systématiquement l'action et le hostname côté serveur dans siteverify.
• Utilisez des sessions persistantes plutôt que la rotation d'IP par requête pour préserver la continuité comportementale.
• Ces techniques sont réservées aux usages légitimes : QA, accessibilité, recherche autorisée. Le contournement frauduleux est illégal.

Pour configurer vos proxies résidentiels ProxyHat, rendez-vous sur le tableau de bord ou consultez la documentation technique pour les options de géo-ciblage avancées.