Cookies reCAPTCHA : lesquels sont déposés et pourquoi ils comptent

Même formulaire, même adresse IP, deux navigateurs : le premier valide la case à cocher en une seconde, le second enchaîne trois grilles d'images. Dans la majorité des cas, l'écart vient des cookies. reCAPTCHA lit les cookies du domaine Google présents dans le navigateur, y ajoute ses propres entrées, et s'en sert comme signal d'historique : un profil vierge n'a rien à montrer, il est donc traité comme un profil à risque. Savoir lesquels survivent à un redémarrage change directement le temps de résolution de vos scripts.

Pourquoi les cookies pèsent sur la difficulté du défi

Le moteur de risque combine des dizaines de signaux (adresse IP, empreinte du navigateur, rythme des interactions), mais l'état des cookies pèse lourd : c'est le plus difficile à fabriquer artificiellement.

Trois profils types

1. Cas favorable : le navigateur porte SID, HSID et NID issus d'une session Google connectée → la case à cocher suffit le plus souvent.
2. Cas courant : NID et 1P_JAR accumulés par une navigation normale → case à cocher, ou grille d'images simple.
3. Cas défavorable : aucun cookie Google, session créée à l'instant → grilles d'images à plusieurs tours.

La conséquence est contre-intuitive : un environnement « propre », réinitialisé à chaque exécution, produit les défis les plus coûteux.

Quels cookies sont déposés et lus

Cookies du domaine Google

Posés sur .google.com et lus par l'iframe reCAPTCHA :

Cookies propres à reCAPTCHA

Le widget ne pose qu'un seul cookie en propre : _GRECAPTCHA, déposé sur .google.com ou sur .recaptcha.net selon le domaine qui sert le script, et limité à la session. Tout le reste de l'état reCAPTCHA — les entrées rc::a, rc::b, rc::c et rc::d-<id> — n'est pas stocké dans des cookies mais dans le localStorage du navigateur, détaillé plus bas. Confondre les deux mène à une erreur classique : sauvegarder les cookies, croire le profil complet, et perdre malgré tout l'état du widget.

Cookies du site cible

Le site qui héberge le widget ajoute ses propres cookies, et ceux-là conditionnent l'acceptation du formulaire :

• Identifiant de session (PHPSESSID, session_id) : rattache la résolution à la session de l'utilisateur.
• Token CSRF (csrf_token, _token) : sans lui, le formulaire est rejeté avant même la vérification du token reCAPTCHA.
• Suivi maison, propre à chaque site : peut déclencher le défi plus tôt que prévu.

Un token reCAPTCHA parfaitement valide sera refusé si le PHPSESSID a changé entre l'affichage du formulaire et son envoi. C'est l'erreur la plus fréquente en automatisation : on conserve les cookies Google et on oublie ceux du site.

Gérer les cookies dans vos scripts d'automatisation

Avec Playwright ou Puppeteer

Le navigateur gère les cookies tout seul ; votre travail consiste à les faire survivre d'une exécution à l'autre.

# Save cookies after session
cookies = page.context.cookies()
import json
with open("cookies.json", "w") as f:
    json.dump(cookies, f)

# Restore cookies in next session
with open("cookies.json") as f:
    cookies = json.load(f)
page.context.add_cookies(cookies)

Sur des workers déployés chez OVHcloud ou Scaleway, montez ce fichier — ou tout le répertoire de profil — sur un volume persistant : un conteneur recréé à chaque tâche repart vierge et retombe dans le cas défavorable décrit plus haut.

Avec l'API CaptchaAI

Sans navigateur, les cookies n'entrent pas dans la résolution : CaptchaAI travaille dans son propre environnement. Le paramètre cookies existe seulement pour transmettre le contexte du site cible quand celui-ci en dépend :

POST https://ocr.captchaai.com/in.php

key=YOUR_API_KEY
&method=userrecaptcha
&googlekey=SITE_KEY
&pageurl=https://example.com/login
&cookies=NID=12345;1P_JAR=2026-04-04-12

Il reste facultatif. Côté facturation, rien ne change : les formules se comptent en threads simultanés — BASIC ($15/mois, 5 threads) au premier palier — et non au cookie ni à la requête. Le champ googlekey reçoit le sitekey de la page, pageurl l'URL exacte où le widget s'affiche ; ces deux valeurs suffisent dans l'immense majorité des intégrations.

Ce que reCAPTCHA conserve dans localStorage

Les entrées préfixées rc:: servent d'état côté client, indépendant des cookies tiers :

Les effacer revient à repartir de zéro à chaque chargement de page. Conservez-les au même titre que les cookies :

# Save localStorage
storage = page.evaluate("() => JSON.stringify(localStorage)")
with open("localstorage.json", "w") as f:
    f.write(storage)

# Restore localStorage
with open("localstorage.json") as f:
    storage = f.read()
page.evaluate(f"Object.entries(JSON.parse('{storage}')).forEach(([k,v]) => localStorage.setItem(k,v))")

Cookies tiers, RGPD et navigateurs modernes

Le widget se charge dans une iframe servie par google.com : ses cookies sont donc des cookies tiers, avec toutes les restrictions que cela implique.

En Europe s'ajoutent les bandeaux de consentement imposés par le RGPD : tant que le visiteur n'a pas arbitré le bandeau, le cookie CONSENT et les cookies publicitaires comme 1P_JAR peuvent ne jamais être posés. Si votre scénario de test clique « tout refuser », il reproduit le profil le plus pauvre en signaux et hérite de défis plus durs qu'en production. Gardez par ailleurs la collecte de données personnelles au minimum dans vos journaux, conformément aux recommandations de la CNIL.

Les parades de Google

• recaptcha.net comme domaine de repli lorsque google.com est filtré ;
• localStorage (entrées rc::*) pour l'état côté client ;
• chargement du script en propriétaire pour les clients reCAPTCHA Enterprise.

Bonnes pratiques

• Conservez les profils de navigateur d'une exécution à l'autre : l'historique accumulé fait baisser la difficulté.
• Ne videz pas les cookies entre deux tâches, sous peine de repartir de zéro à chaque fois.
• Basculez sur recaptcha.net quand google.com est filtré : même service, autre domaine.
• Sauvegardez les entrées rc:: du localStorage en même temps que les cookies.
• Faites visiter des propriétés Google de temps en temps pour rafraîchir la validité des cookies.
• Restaurez aussi les cookies du site cible, sinon le token part dans une session que le serveur ne reconnaît plus.

Dépannage

FAQ

Le bandeau de consentement RGPD rend-il les défis plus difficiles ?

Indirectement, oui. Un refus global empêche le dépôt de plusieurs cookies Google et prive le moteur de risque d'historique. C'est normal, pas un défaut d'intégration : calibrez vos tests en conséquence.

Faut-il transmettre le paramètre cookies à l'API ?

Seulement si le site cible lie son formulaire à une session existante. Pour un widget reCAPTCHA v2 classique, envoyez googlekey et pageurl, et laissez ce paramètre de côté.

Pourquoi utiliser recaptcha.net plutôt que google.com ?

Parce que certains réseaux d'entreprise et certaines régions filtrent google.com. recaptcha.net sert le même widget et évite l'échec de chargement du script.

Combien de profils de navigateur prévoir pour du scraping en parallèle ?

Un profil persistant par worker, réutilisé d'une exécution à l'autre. Alignez ce nombre sur vos threads CaptchaAI : avec STANDARD ($30/mois, 15 threads), quinze résolutions peuvent être en vol simultanément, donc quinze profils entretenus restent cohérents.

Articles connexes

• Résoudre le callback reCAPTCHA v2 via l'API
• Gérer reCAPTCHA v2 et Turnstile sur le même site
• Le mécanisme de callback de reCAPTCHA v2

Prochaines étapes

Des profils durables et une clé API suffisent à faire baisser la difficulté de vos défis : récupérez votre clé API CaptchaAI et branchez la persistance des cookies sur vos workers.