Périmètre sûr : ce guide vise vos propres applications et vos environnements de test, ou des systèmes pour lesquels vous disposez d'une autorisation écrite. Il ne traite pas de l'automatisation de sites tiers.
Un token reCAPTCHA v2 valide à la résolution mais refusé à l'envoi du formulaire ? L'IP a changé entre les deux étapes : ce scénario impose une session persistante. Une collecte page par page, elle, se comporte mieux avec des IP qui tournent. Le mode de session découle du parcours que vous rejouez.
Ce que chaque mode change concrètement
Une session persistante (« sticky ») garde la même IP pendant une fenêtre définie chez votre fournisseur ; une session rotative en attribue une nouvelle par requête. Le reste — sitekey, résolution, injection du token — ne bouge pas.
| Critère | Session persistante | Session rotative |
|---|---|---|
| IP par requête | Identique pendant le TTL | Nouvelle à chaque appel |
| Continuité des cookies | Conservée | Perdue |
| Parcours multi-étapes | Adapté | Défis fréquents |
| Validité du token | Cohérente avec l'IP d'origine | Risque de non-correspondance |
| Latence | Connexion réutilisée | Nouvelle connexion à chaque appel |
Ces tendances reposent sur des mesures observées : les résultats varient selon l'environnement, le volume et le moment de la journée.
Session persistante : quand garder la même IP
Un token CAPTCHA est validé dans le contexte de la requête qui l'accompagne. Dès qu'un parcours enchaîne chargement de page, résolution puis soumission — connexion, checkout de recette, formulaire protégé —, changer d'IP revient à présenter le token depuis un autre contexte.
Pour la fenêtre, une règle suffit : environ deux fois la durée mesurée du parcours. Un login suivi de trois actions tient dans 5 minutes ; une navigation multi-pages demande plutôt 10 minutes.
Session rotative : quand faire tourner les IP
Les sessions rotatives servent quand chaque requête est autonome : disponibilité des pages, rendu multi-régions, résilience face à un changement d'IP. Dans les deux modes, l'appel de résolution reste identique :
import os
import requests
API_KEY = os.environ['CAPTCHAAI_KEY']
def submit_recaptcha_v2(sitekey: str, page_url: str) -> str:
payload = {
'clientKey': API_KEY,
'task': {
'type': 'NoCaptchaTaskProxyless',
'websiteURL': page_url,
'websiteKey': sitekey,
},
}
resp = requests.post('https://api.captchaai.com/createTask', json=payload, timeout=30)
resp.raise_for_status()
return resp.json()['taskId']
La clé vient d'une variable d'environnement : en intégration continue, elle reste un secret de pipeline, jamais une valeur du dépôt.
Exemple : une recette e-commerce chez un éditeur lyonnais
L'équipe QA déploie ses workers sur OVHcloud et lance deux campagnes nocturnes contre sa préproduction. La première rejoue « connexion, ajout au panier, paiement sandbox » : session persistante de 10 minutes, reCAPTCHA v2 sur la connexion et Cloudflare Turnstile sur le paiement. La seconde contrôle 400 fiches produits depuis plusieurs régions, en rotatif.
La capacité se calcule en threads : BASIC ($15/mois, 5 threads) suffit à une campagne séquentielle, STANDARD ($30/mois, 15 threads) à une exécution parallélisée. Côté RGPD, ces journaux contiennent des adresses IP : comptes fictifs, rétention limitée et documentée.
Dépannage
| Problème | Cause probable | Correctif |
|---|---|---|
| Token refusé après résolution réussie | IP changée entre résolution et envoi | Passer le parcours en session persistante |
| Défis plus nombreux sur des pages isolées | Trafic concentré sur une IP persistante | Basculer ces appels en rotatif |
| Échec impossible à rejouer | Mode de session absent des logs | Journaliser le mode à chaque appel |
Liste de contrôle avant exécution
- Chaque scénario déclare explicitement son mode de session.
- La fenêtre persistante vaut environ deux fois la durée du parcours.
- La clé CaptchaAI vit dans un coffre ou un secret CI.
- Durées d'appel, codes retour et mode de session sont journalisés.
- Un retry idempotent avec backoff exponentiel borné couvre les erreurs transitoires de l'API.
FAQ
Quelle durée de session persistante choisir pour un parcours de connexion ?
Environ deux fois la durée mesurée : si le parcours prend 2 minutes, une fenêtre de 5 minutes laisse de la marge sans concentrer inutilement le trafic sur une seule IP.
Pourquoi mon token est-il refusé alors que la résolution a réussi ?
L'IP qui soumet le formulaire n'est plus celle qui a chargé la page. Vérifiez que le client HTTP et l'étape de résolution partagent la même session proxy, puis rejouez en mode persistant : voir résoudre reCAPTCHA v2 via l'API.
Le mode de session influe-t-il sur le dimensionnement de mon plan ?
Indirectement : la facturation dépend du nombre de threads simultanés, pas du mode de proxy. Un mauvais choix multiplie les défis, donc la concurrence nécessaire.
Cloudflare Turnstile réagit-il comme reCAPTCHA v2 au changement d'IP ?
Oui : traitez ces parcours en session persistante. Les détails figurent dans le guide Cloudflare Turnstile via l'API.
Guides connexes
- Démarrer avec l'API CaptchaAI
- Tests CAPTCHA en environnement autorisé
- Valider l'endpoint API
- Résolution CAPTCHA en chaîne CI
- Résoudre reCAPTCHA v2 via l'API
- Résoudre Cloudflare Turnstile via l'API
Mesurez les défis produits par chaque mode avant de trancher. – Obtenez votre clé CaptchaAI.
