Périmètre sûr : ce guide s'applique exclusivement à vos propres applications, à vos environnements de QA, de préproduction ou de production, ou à des systèmes pour lesquels vous disposez d'une autorisation écrite. Il ne décrit ni l'automatisation de sites tiers, ni le contournement de protections, ni l'évasion d'anti-bot.
Un proxy d'entreprise et un service de résolution de CAPTCHA ne font pas le même travail, et c'est précisément pour cela qu'ils se complètent. Bright Data place vos requêtes de test dans la bonne région ; CaptchaAI résout, côté serveur, le défi CAPTCHA que votre propre application affiche. Aucun des deux ne recouvre l'autre, et aucune technique d'évasion n'entre en jeu.
Cette combinaison devient utile dès que vous validez votre application sous plusieurs origines géographiques et qu'un formulaire du parcours est protégé par un CAPTCHA : le proxy diversifie l'origine des requêtes, CaptchaAI renvoie le token attendu, et vos tests poursuivent leur exécution sans intervention manuelle.
Comment se répartissent proxy et résolution de CAPTCHA
CaptchaAI ne transite pas par votre proxy Bright Data. Le service résout le défi sur sa propre infrastructure, puis vous renvoie un token que votre script injecte dans la page. Deux flux coexistent donc : votre client HTTP (ou navigateur piloté) sort par Bright Data pour charger la page, tandis qu'un appel séparé part vers l'API CaptchaAI avec l'URL et le sitekey.
Ce découplage aide au débogage : une panne de proxy et une erreur de résolution se diagnostiquent indépendamment. Si un défi est lié à l'IP qui a chargé la page, l'API CaptchaAI accepte un paramètre proxy optionnel pour résoudre depuis la même origine — réservez-le aux cas où le token doit correspondre à l'IP d'origine.
Configuration de base : proxy Bright Data et appel CaptchaAI
Pointez votre client HTTP de QA sur l'endpoint Bright Data, puis appelez CaptchaAI pour obtenir le token correspondant à votre formulaire. L'authentification du proxy reste gérée par le client HTTP, ce qui garde les deux services indépendants. Stockez les identifiants Bright Data et la clé CaptchaAI dans des variables d'environnement ou un coffre de secrets, jamais en clair dans le dépôt.
Exemple de requête Python via un proxy authentifié, pour un simple contrôle de disponibilité :
import os
import requests
PROXY = {
'https': f"http://{os.environ['BD_USER']}:{os.environ['BD_PASS']}@brd.superproxy.io:22225",
}
resp = requests.get(os.environ['QA_BASE_URL'] + '/health', proxies=PROXY, timeout=30)
resp.raise_for_status()
print(resp.json())
La même mécanique s'applique à Selenium ou Playwright : configurez le proxy au lancement, récupérez le sitekey une fois la page chargée, puis injectez le token CaptchaAI avant de soumettre le formulaire.
Choisir le type de proxy selon la région testée
Le type de sortie influence la fréquence des défis CAPTCHA sur votre application. Les IP datacenter sont rapides et économiques, mais plus souvent signalées ; les IP résidentielles déclenchent moins de défis ; les IP ISP combinent vitesse datacenter et confiance résidentielle. Pour des tests de QA, le résidentiel offre le meilleur compromis entre réalisme et coût.
Pour valider le parcours d'inscription tel qu'il apparaît depuis Paris, Bruxelles ou Montréal, routez chaque exécution via un point de sortie de la région correspondante — par exemple une IP française pour un test proche d'eu-west-3 (Paris). Vous vérifiez ainsi que le contenu localisé, les redirections et le CAPTCHA se comportent comme prévu pour chaque marché francophone que vous servez.
Conservez une session collante (sticky) pendant toute la durée d'un scénario. Si l'IP change entre le chargement de la page et la soumission du formulaire, le token de résolution est refusé : la plupart des défis lient le token à l'IP qui a affiché la page.
Observabilité, journalisation et RGPD
Quel que soit le langage, instrumentez les appels CAPTCHA pour obtenir des métriques exploitables : durée totale d'obtention du token, code retour HTTP, identifiant de tâche et taille de la file d'attente interne. Ils alimentent vos tableaux de bord de QA et vos alertes.
Séparez les journaux par environnement (développement, préproduction, production) et corrélez les identifiants à votre traçage distribué, par exemple via OpenTelemetry : vous rejouez un scénario complet à partir d'un identifiant unique, ce qui réduit nettement le temps de diagnostic. Appliquez enfin la minimisation RGPD à ces traces : pas de données personnelles dans vos logs de test, et une rétention limitée au strict nécessaire au débogage.
Liste de contrôle avant exécution
-
Le périmètre reste strictement limité à vos propres applications ou à des sources explicitement autorisées.
-
La clé CaptchaAI et les identifiants Bright Data vivent dans un coffre ou un secret CI, jamais dans le code source.
-
Les durées d'appel et les codes retour sont tracés pour chaque exécution.
-
Une stratégie de retry idempotent couvre les erreurs transitoires.
-
Les sessions restent collantes pendant toute la durée d'un scénario.
-
Les tests sont rejouables et reproductibles depuis votre intégration continue.
Dépannage
| Problème | Cause probable | Correctif |
|---|---|---|
| Erreur 407 renvoyée par le proxy | Identifiants incorrects | Vérifiez l'identifiant client, la zone et le mot de passe Bright Data |
| Un CAPTCHA à chaque requête | Sortie datacenter détectée | Basculez sur une zone résidentielle |
| Token refusé après résolution | L'IP a changé entre le chargement et la soumission | Passez en session collante (sticky) |
| Réponse lente du proxy | Nœud de sortie saturé | Ciblez un pays ou une ville moins sollicités |
Questions fréquentes
Ce guide couvre-t-il l'automatisation de sites tiers ?
Non. Tous les exemples portent sur vos propres applications ou sur des environnements de test pour lesquels vous disposez d'une autorisation écrite. Aucune technique de contournement, d'évasion ou d'anti-détection sur des sites tiers n'est décrite ici. Si votre projet implique une source externe, validez d'abord les conditions d'utilisation et la base juridique.
CaptchaAI utilise-t-il mon proxy Bright Data pour résoudre le défi ?
Non par défaut. CaptchaAI résout le défi sur sa propre infrastructure : vous ne lui transmettez que l'URL de la page et le sitekey, et le proxy sert uniquement à charger la page. Si un défi est lié à l'IP d'origine, vous pouvez fournir le paramètre proxy optionnel pour que la résolution parte de la même adresse.
Comment router mes tests vers une région précise ?
Sélectionnez une zone Bright Data ciblée sur le pays voulu et gardez la session collante pendant l'exécution. Vous obtenez ainsi une origine cohérente pour un marché donné — France, Belgique, Suisse ou Québec — et observez le parcours CAPTCHA tel que le verrait un utilisateur local.
Que faire si l'API renvoie une erreur transitoire ?
Mettez en place un retry avec backoff exponentiel borné (par exemple 3 tentatives, doublement du délai, plafond à 30 secondes) et tracez chaque échec avec son identifiant de tâche. Si l'erreur persiste, vérifiez la configuration réseau (DNS, certificats) et les quotas associés à votre clé.
Guides connexes
- Le démarrage rapide de CaptchaAI
- La QA CAPTCHA en environnements autorisés
- Tester l'endpoint API sur vos formulaires
- Intégrer la résolution CAPTCHA à votre CI
- Résoudre reCAPTCHA v2 via l'API
- Résoudre Cloudflare Turnstile via l'API
- Les méthodes d'authentification proxy
Structurez vos tests CAPTCHA région par région, dans vos propres environnements, avec une approche méthodique et reproductible. – Obtenez votre clé CaptchaAI.