Comment fonctionne le score reCAPTCHA v3 : guide technique pour automatisation légitime

Si vous avez déjà automatisé un flux de connexion, un test d'accessibilité ou un audit de prix, vous connaissez le mur invisible : reCAPTCHA v3. Contrairement à v2 avec ses images de feux de signalisation, v3 ne présente aucun défi visible. Il renvoie silencieusement un score de risque continu entre 0.0 et 1.0, et votre demande passe ou échoue selon un seuil défini côté serveur. Comprendre comment fonctionne le score reCAPTCHA v3 est donc essentiel pour toute équipe d'automatisation ou de QA qui interagit avec des sites protégés.

Cet article détaille le moteur de scoring, les signaux fusionnés par Google, l'impact de la réputation IP, la vérification côté serveur, et une approche légitime utilisant les proxies résidentiels ProxyHat pour maintenir un score acceptable.

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

reCAPTCHA v3 introduit un changement fondamental par rapport à v2 : il n'y a aucun challenge utilisateur. Au lieu de cela, le script grecaptcha.execute() génère un token associé à une action nommée (par exemple login, signup, checkout). Ce token est envoyé au serveur du site, qui appelle l'API siteverify de Google pour obtenir un verdict.

La réponse de siteverify contient un champ score compris entre 0.0 et 1.0, où 0.0 signifie « très probablement un bot » et 1.0 signifie « très probablement humain ». Google documente officiellement ce score comme une évaluation continue du risque basée sur l'interaction de l'utilisateur avec le site.

En pratique, les administrateurs de sites configurent des seuils dans leur logique métier. Voici les seuils typiques observés dans la nature :

Plage de score	Décision côté site	Exemple de comportement
< 0.3	Blocage	Requête rejetée, compte marqué, ou challenge v2 injecté
0.3 – 0.6	Challenge ou révision	Challenge additionnel, MFA forcé, ou file d'attente manuelle
> 0.6	Autorisation	Requête traitée normalement

Google ne publie pas la liste exacte des seuils, mais des analyses indépendantes et la documentation publique confirment que les sites appliquent généralement leurs propres politiques. Le score est aussi par action : un utilisateur peut obtenir 0.9 sur login et 0.4 sur checkout lors de la même session, car le contexte diffère.

Google regroupe les scores en onze buckets discrets (0.0, 0.1, 0.2, … 1.0) dans ses rapports d'analyse, même si l'API renvoie une valeur continue. Cela signifie qu'un score de 0.31 et un score de 0.39 tombent dans le même bucket 0.3 pour les statistiques agrégées du tableau de bord admin.

Les signaux que Google fusionne pour calculer le score

Le score n'est pas basé sur une seule métrique. Google combine des dizaines de signaux en un modèle de machine learning. Voici les principales catégories, avec leur poids approximatif observé :

Télémétrie d'interaction comportementale

Le script grecaptcha injecté dans la page collecte en continu :

• Timing de la souris : vitesse, accélération, trajectoires, micro-pauses entre mouvements. Un mouvement parfaitement linéaire ou instantané est suspect.
• Scroll : vitesse de défilement, direction, pauses. Un scroll instantané en bas de page sans lecture est un signal négatif.
• Keystroke timing : intervalles entre frappes, durée d'appui. Un remplissage de formulaire en 50 ms avec intervalles constants signale une automatisation.
• Événements de focus/blur : si l'utilisateur clique dans le champ email puis en sort, ou si le formulaire est soumis sans jamais avoir reçu le focus.

Ces signaux comportementaux pèsent lourd dans le score, mais ils ne suffisent pas à eux seuls. Un mouvement de souris parfait avec une mauvaise réputation IP ne produira pas un score élevé.

Le graphe de cookies Google

C'est le signal le plus puissant et le moins documenté. Si l'utilisateur possède un cookie Google valide (SID, HSID, SSID, APISID) issu d'une session précédente sur un appareil ayant un historique d'activité Google authentique — Gmail, YouTube, Search — le score grimpe significativement. Ce cookie lie la session courante à un historique de comportement humain connu.

À l'inverse, un navigateur vierge sans cookie Google, ou un cookie d'un compte fraîchement créé, reçoit un score de base bas. C'est pourquoi les environnements d'automatisation headless purs, sans historique Google, partent avec un handicap structurel.

Caractéristiques du navigateur et empreintes TLS

Google collecte des caractéristiques du navigateur via JavaScript :

• User-Agent, langue, plate-forme, navigator.webdriver (qui est true dans Selenium/Puppeteer non patché).
• Résolution d'écran, profondeur de couleur, fuseau horaire.
• Empreinte canvas et WebGL — bien que Google ne l'utilise pas exactement comme les librairies fingerprinting classiques, des signaux graphiques sont collectés.
• JA3/JA4 TLS fingerprint : l'ordre des cipher suites et les extensions TLS du ClientHello. Un navigateur headless Chrome peut avoir un JA3 légèrement différent d'un Chrome réel, surtout si les flags TLS sont modifiés par des librairies d'automatisation.

Le RFC 8446 (TLS 1.3) définit les cipher suites standard, mais chaque navigateur les ordonne différemment. Une incohérence entre l'User-Agent déclaré et l'empreinte TLS réelle est un signal négatif fort.

Réputation IP

C'est le signal qui nous intéresse le plus dans cet article. Google maintient une base de réputation IP massive, alimentée par :

• Le type d'IP : datacenter (AWS, GCP, OVH, Hetzner), résidentielle (FAI grand public), mobile (opérateurs cellulaires).
• L'historique d'activité malveillante associée : spam, scraping agressif, fraude publicitaire.
• La densité de requêtes : si une IP a généré 10 000 tokens reCAPTCHA en une heure, son score de réputation chute.
• La cohérence géographique : si l'IP est à Francfort mais le fuseau horaire du navigateur est America/New_York, c'est un signal d'incohérence.

Une IP datacenter connue, ou une IP résidentielle sur-utilisée, peut faire chuter le score en dessous de 0.3 indépendamment du comportement. C'est le point critique pour les équipes d'automatisation.

Pourquoi les IPs datacenter et les IPs signalées font chuter le score

De nombreuses équipes d'automatisation découvrent reCAPTCHA v3 quand elles migrent de tests locaux vers un environnement cloud. Le même script qui obtenait un score de 0.7 en local tombe à 0.1 sur une instance AWS. Pourquoi ?

Google classe les plages d'IP datacenter comme non grand public. Les serveurs cloud ne sont pas utilisés par des humains pour naviguer sur le web au quotidien. Toute requête provenant d'une IP datacenter est donc intrinsèquement suspecte pour un système qui modélise le comportement humain moyen. Le score de base pour une IP datacenter non flaguée commence souvent autour de 0.2 à 0.4, avant même d'analyser le comportement.

Les IPs résidentielles sur-utilisées subissent le même sort. Si un pool de proxies résidentiels est massivement utilisé pour du scraping sur des sites protégés, Google finit par flagger ces IPs. Le score de réputation chute, et les tokens générés depuis ces IPs reçoivent des scores bas.

C'est pourquoi les proxies résidentiels frais et de qualité sont indispensables pour quiconque doit interagir avec des sites protégés par reCAPTCHA v3 dans un cadre légitime. Un proxy résidentiel attribue à votre trafic une IP appartenant à un FAI grand public, ce qui place le score de base IP dans la zone « humain plausible ».

Le comportement parfait ne compense pas une mauvaise réputation IP. Le score est un produit de signaux, et un seul signal très négatif peut faire chuter le score global en dessous du seuil.

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

Une fois que grecaptcha.execute() renvoie un token côté client, ce token doit être vérifié côté serveur via l'endpoint siteverify :

POST https://www.google.com/recaptcha/api/siteverify
  secret=VOTRE_SECRET_KEY
  response=TOKEN_DU_CLIENT
  remoteip=IP_DU_VISITEUR (optionnel)

La réponse JSON contient plusieurs champs critiques :

• success : boolean, indique si le token est valide.
• score : float entre 0.0 et 1.0.
• action : l'action associée au token (ex. login).
• hostname : le domaine depuis lequel le token a été généré.
• error-codes : liste d'erreurs si applicable.

Deux vérifications côté serveur sont obligatoires mais souvent oubliées par les développeurs :

1. Vérification de l'action : le champ action dans la réponse doit correspondre exactement à l'action attendue. Si le site attend login et reçoit checkout, le token doit être rejeté. Un attaquant pourrait générer un token valide pour une action peu protégée et le réutiliser pour une action sensible.
2. Vérification du hostname : le champ hostname doit correspondre au domaine du site. Un token généré depuis exemple.com ne doit pas être accepté sur autre-site.com.

Voici un exemple de vérification côté serveur en Python :

import requests

def verify_recaptcha(token, expected_action, expected_hostname, remote_ip=None):
    resp = requests.post(
        "https://www.google.com/recaptcha/api/siteverify",
        data={
            "secret": "VOTRE_SECRET_KEY",
            "response": token,
            "remoteip": remote_ip or "",
        },
        timeout=5,
    )
    result = resp.json()

    if not result.get("success"):
        return False, "Token invalide"

    if result.get("action") != expected_action:
        return False, f"Action mismatch: {result.get('action')} != {expected_action}"

    if result.get("hostname") != expected_hostname:
        return False, f"Hostname mismatch: {result.get('hostname')} != {expected_hostname}"

    score = float(result.get("score", 0))
    return True, score

# Utilisation
ok, score = verify_recaptcha(token, "login", "monsite.com")
if not ok or score < 0.5:
    raise Exception("Accès refusé")

Cette double vérification empêche les attaques par rejeu de token entre actions et entre domaines. C'est une erreur courante de ne vérifier que success et score, ce qui laisse une faille exploitable.

Approche légitime avec ProxyHat : maintenir un score au-dessus du seuil

Pour les cas d'usage légitimes — tests d'accessibilité automatisés, QA d'intégration, recherche autorisée, audit de prix sur des sites partenaires — il est possible de maintenir un score reCAPTCHA v3 acceptable en combinant trois éléments :

1. Un proxy résidentiel de qualité via ProxyHat pour obtenir une IP grand public.
2. Un navigateur réel (non headless) avec une empreinte cohérente.
3. Des interactions humaines simulées réalistes : mouvements de souris, scroll progressif, délais entre frappes.

Configuration du proxy ProxyHat

ProxyHat fournit des proxies résidentiels accessibles via gate.proxyhat.com. Pour cibler une IP résidentielle aux États-Unis :

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

Vous pouvez aussi cibler une ville spécifique pour une cohérence géographique maximale :

http://user-country-US-city-newyork:pass@gate.proxyhat.com:8080

Et maintenir une session persistante pour conserver la même IP pendant une session de navigation :

http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080

Pour du SOCKS5, utilisez le port 1080 :

socks5://user-country-US:pass@gate.proxyhat.com:1080

Consultez la documentation ProxyHat pour la liste complète des paramètres de géo-ciblage.

Exemple Python complet avec Playwright

Voici un exemple fonctionnel combinant ProxyHat et Playwright pour exécuter une action login légitime avec un score attendu supérieur à 0.6 :

from playwright.sync_api import sync_playwright
import time, random

PROXY = "gate.proxyhat.com:8080"
PROXY_USER = "user-country-US"
PROXY_PASS = "pass"

def human_delay(min_s=0.5, max_s=2.0):
    time.sleep(random.uniform(min_s, max_s))

def human_mouse_move(page, x, y):
    # Mouvement progressif avec petites étapes
    steps = random.randint(10, 25)
    page.mouse.move(x, y, steps=steps)
    human_delay(0.1, 0.4)

def run_login_test():
    with sync_playwright() as p:
        browser = p.chromium.launch(
            headless=False,  # Un vrai navigateur, pas headless
            proxy={
                "server": f"http://{PROXY}",
                "username": PROXY_USER,
                "password": PROXY_PASS,
            },
            args=[
                "--disable-blink-features=AutomationControlled",
            ],
        )
        context = browser.new_context(
            viewport={"width": 1920, "height": 1080},
            locale="en-US",
            timezone_id="America/New_York",
        )
        page = context.new_page()

        # 1. Naviguer vers la page avec un délai réaliste
        page.goto("https://exemple.com/login", wait_until="networkidle")
        human_delay(2.0, 4.0)

        # 2. Scroll progressif
        page.evaluate("window.scrollBy(0, 200)")
        human_delay(0.5, 1.5)
        page.evaluate("window.scrollBy(0, -100)")
        human_delay(0.3, 0.8)

        # 3. Déplacer la souris vers le champ email
        human_mouse_move(page, 960, 400)
        human_delay(0.3, 0.7)

        # 4. Remplir le formulaire avec des délais entre frappes
        email_field = page.locator("#email")
        email_field.click()
        for char in "test@example.com":
            page.keyboard.type(char)
            human_delay(0.05, 0.15)

        human_delay(0.5, 1.0)

        password_field = page.locator("#password")
        human_mouse_move(page, 960, 460)
        password_field.click()
        for char in "SecurePass123!":
            page.keyboard.type(char)
            human_delay(0.05, 0.15)

        human_delay(1.0, 2.5)

        # 5. Exécuter reCAPTCHA v3 pour l'action login
        token = page.evaluate("""
            async () => {
                await new Promise(r => grecaptcha.ready(r));
                return await grecaptcha.execute(
                    'VOTRE_SITE_KEY',
                    {action: 'login'}
                );
            }
        """)
        print(f"Token reCAPTCHA: {token[:40]}...")

        # 6. Soumettre le formulaire
        page.locator("#submit").click()
        human_delay(2.0, 4.0)

        browser.close()

run_login_test()

Les éléments clés de cet exemple :

• headless=False : un navigateur visible a une empreinte plus naturelle. Si l'environnement serveur l'exige, utilisez headless="new" ( Chromium headless moderne) avec des patches anti-détection.
• --disable-blink-features=AutomationControlled : supprime le flag navigator.webdriver=true.
• Le proxy résidentiel US assure une cohérence entre l'IP, le fuseau horaire America/New_York et la locale en-US.
• Les délais aléatoires entre frappes (50-150 ms) imitent un rythme de saisie humain.
• Les mouvements de souris progressifs (10-25 étapes) évitent les sauts instantanés.

Avec cette combinaison, un score entre 0.7 et 0.9 est typiquement atteint pour une action login sur un site de test. Un score de 0.3 ou moins indique généralement un problème de réputation IP ou une incohérence d'empreinte.

Erreurs courantes et cas limites

Oublier la vérification de l'action et du hostname

C'est l'erreur la plus fréquente côté serveur. Ne vérifier que success et score laisse une faille où un token généré pour une action page_view (souvent moins protégée) peut être réutilisé pour checkout. Toujours comparer result["action"] avec l'action attendue.

Utiliser un proxy datacenter « rapide »

La latence d'un proxy datacenter (souvent 20-50 ms) est séduisante, mais le score reCAPTCHA sera catastrophique. Un proxy résidentiel peut ajouter 100-300 ms de latence, mais le score passera de 0.1 à 0.7+. Le compromis vaut toujours la peine quand le score compte.

Incohérence géographique

Si votre proxy est en Allemagne (user-country-DE) mais que le fuseau horaire du navigateur est America/Los_Angeles, Google détecte l'incohérence et pénalise le score. Assurez-vous que le pays du proxy, le fuseau horaire, la locale et l'adresse IP géolocalisée sont cohérents. ProxyHat permet le ciblage par pays et par ville via la page locations.

Réutilisation excessive d'une même IP résidentielle

Si vous exécutez des centaines de sessions reCAPTCHA sur la même IP résidentielle (même avec sticky sessions), Google finit par flagger cette IP. Pour des volumes élevés, alternez les sessions avec de nouveaux identifiants de session ProxyHat pour obtenir de nouvelles IPs :

# Session 1
http://user-country-US-session-sess001:pass@gate.proxyhat.com:8080

# Session 2 (nouvelle IP)
http://user-country-US-session-sess002:pass@gate.proxyhat.com:8080

Timeout du token

Les tokens reCAPTCHA v3 expirent après environ 2 minutes. Si votre script prend trop de temps entre grecaptcha.execute() et l'envoi au serveur, le token sera invalide. Optimisez le flux pour soumettre le token rapidement après génération.

Score 0.3 persistant malgré tout

Si vous obtenez systématiquement un score de 0.3 ou moins malgré un proxy résidentiel et un navigateur réel, vérifiez :

• Le JA3/JA4 du navigateur : utilisez un outil comme ja3-rust ou les DevTools pour comparer l'empreinte TLS avec un navigateur réel.
• La présence de cookies Google : un navigateur vierge sans historique Google part avec un score de base bas. Pour les tests, connectez d'abord à un compte Google dans une session préalable.
• La densité de requêtes depuis l'IP du proxy : si le pool ProxyHat est partagé et très sollicité, demandez une IP dédiée ou réduisez la fréquence.

Cadre légal et éthique

Il est crucial de rappeler que les techniques décrites ici sont destinées à des usages légitimes :

• Tests d'accessibilité automatisés : vérifier que les utilisateurs handicapés peuvent compléter un flux protégé par reCAPTCHA.
• QA d'intégration : tester votre propre site ou un site dont vous êtes autorisé à tester.
• Recherche en sécurité : évaluer la robustesse de la configuration reCAPTCHA d'un site que vous protégez.
• Automatisation autorisée : interagir avec des API ou sites où vous avez une autorisation explicite.

Le Computer Fraud and Abuse Act (CFAA) aux États-Unis et le RGPD en Europe encadrent strictement l'accès non autorisé aux systèmes et le traitement des données personnelles. Contourner reCAPTCHA pour créer des comptes en masse, scraper des données protégées par des conditions d'utilisation, ou commettre une fraude est illégal et peut entraîner des poursuites pénales. Les proxies ne sont pas un bouclier juridique : ils masquent l'IP, mais ne légitiment pas l'action.

Toujours consulter les conditions d'utilisation du site cible et obtenir une autorisation écrite avant tout test automatisé sur un système que vous ne possédez pas.

Points clés à retenir

• Score continu 0.0-1.0 : reCAPTCHA v3 renvoie un score par action, pas un défi visible. Les sites appliquent leurs propres seuils (blocage < 0.3, challenge 0.3-0.6, autorisation > 0.6).
• Signaux multiples : Google fusionne télémétrie comportementale, graphe de cookies, empreinte navigateur/TLS et réputation IP. Un seul signal très négatif fait chuter le score global.
• IP datacenter = score bas : les IPs datacenter reçoivent un score de base structurellement bas. Les proxies résidentiels sont indispensables.
• Vérification serveur obligatoire : toujours vérifier action et hostname en plus de success et score.
• Cohérence géographique : pays du proxy, fuseau horaire, locale et géolocalisation IP doivent être alignés.
• Cadre légal : ces techniques sont pour l'automatisation autorisée, les tests d'accessibilité et la recherche en sécurité, jamais pour la fraude.

Pour explorer comment ProxyHat peut soutenir vos besoins d'automatisation légitime, consultez notre page de tarification, nos cas d'usage de web scraping, et notre guide de suivi SERP. La documentation technique détaille tous les paramètres de géo-ciblage et de session.