Périmètre sûr : ce guide couvre uniquement vos propres applications, vos environnements de QA, de préproduction ou de production, ainsi que les systèmes pour lesquels vous détenez une autorisation écrite. Il ne décrit ni l'automatisation de sites tiers, ni le contournement de protections, ni l'évasion d'anti-bot.
Charger l'extension CaptchaAI via le Chrome DevTools Protocol (CDP) revient à traiter l'extension comme un composant stable de votre navigateur automatisé, pas comme une case à cocher activée à la main. La stabilité repose sur quatre éléments : l'état du compte, le profil de navigateur, le handler CAPTCHA sélectionné et le comportement de la page après résolution. L'erreur classique ne vient pas du code, mais d'un chargement qui marche en local puis casse dès la première exécution sans surveillance.
Préparer un environnement isolé
Avant d'écrire la moindre ligne, sécurisez le terrain :
- Isolez la QA de la production (bases et identifiants distincts).
- Stockez la clé CaptchaAI dans un secret CI ou un coffre.
- Vérifiez que vos endpoints internes acceptent le trafic de test.
- Côté RGPD, limitez les données personnelles de vos scénarios de test.
Charger l'extension au lancement du navigateur
Le chargement via CDP suit toujours la même logique : démarrez Chrome avec un profil dédié (--user-data-dir) et injectez l'extension au lancement (--load-extension). C'est ce couple profil + extension qui doit rester stable d'une exécution à l'autre. Un profil recréé à chaque run repart d'un état vide : session perdue et défis instables. Avec Selenium, Playwright ou Puppeteer, le principe ne change pas : profil persistant, extension chargée par argument de lancement, un seul contexte pour tout le scénario.
Encapsuler l'appel à l'API CaptchaAI
Isolez l'appel à CaptchaAI dans une fonction réutilisable : elle prend la sitekey et l'URL de votre propre page, renvoie un token, et trace la durée et le code retour. Vous simplifiez ainsi la maintenance entre tests.
Voici un exemple Node.js qui crée une tâche via l'API :
import fetch from 'node-fetch';
const API_KEY = process.env.CAPTCHAAI_KEY;
export async function createTurnstileTask(siteKey, pageUrl) {
const res = await fetch('https://api.captchaai.com/createTask', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
clientKey: API_KEY,
task: {
type: 'TurnstileTaskProxyless',
websiteURL: pageUrl,
websiteKey: siteKey,
},
}),
});
const data = await res.json();
return data.taskId;
}
Appliquer le token dans la même session
Appliquez toujours le token dans le contexte qui a déclenché le défi : même contexte de navigateur, même client HTTP, même jar de cookies. Un token appliqué depuis une session différente est la cause la plus fréquente de rejet après résolution : si l'extension est chargée via CDP dans un contexte persistant, poursuivez le parcours dans ce même contexte.
Vérifier le token côté backend
Le token renvoyé doit être vérifié par votre propre backend avant toute opération métier : aucune requête ne doit être acceptée sur la base d'un token périmé ou contrefait. Suivez deux signaux distincts : la réussite de la résolution et celle du parcours complet.
Observabilité et journalisation
Quel que soit le langage, instrumentez les appels CAPTCHA pour obtenir des métriques exploitables : durée d'obtention du token, code retour HTTP, identifiant de tâche et taille de la file d'attente. Séparez les journaux par environnement et corrélez les identifiants à votre traçage distribué, par exemple via OpenTelemetry. Vous pourrez rejouer un scénario complet à partir d'un identifiant unique et diagnostiquer plus vite un incident.
Liste de contrôle avant mise en production
- Le périmètre reste limité à vos propres applications ou à des sources autorisées.
- La clé CaptchaAI est stockée dans un secret CI ou un coffre, jamais dans le code source.
- Le profil de navigateur et l'extension sont persistants et réutilisés entre les runs.
- Les durées d'appel et les codes retour sont tracés à chaque exécution.
- Un retry idempotent, avec backoff exponentiel borné, couvre les erreurs transitoires et reste rejouable depuis votre CI.
Dépannage
| Problème | Cause probable | Correctif |
|---|---|---|
| L'extension n'est pas chargée au démarrage | Chemin --load-extension incorrect ou profil recréé à chaque run |
Vérifiez le chemin absolu et réutilisez un --user-data-dir persistant |
| Token refusé après résolution | Token appliqué dans une session différente de celle du défi | Poursuivez le parcours dans le même contexte de navigateur |
| Résolutions instables en headless | Profil ou extension non persistants entre les lancements | Fixez un profil dédié et rechargez l'extension au lancement |
FAQ
Faut-il charger l'extension via CDP plutôt qu'avec un profil Chrome persistant ?
Les deux se combinent. Le CDP pilote le navigateur et injecte l'extension au lancement, tandis que le profil persistant (--user-data-dir) conserve l'état entre deux exécutions.
Pourquoi le token est-il refusé après la résolution ?
Presque toujours parce qu'il est appliqué dans une session différente de celle qui a déclenché le défi. Conservez la résolution et la soumission du formulaire dans le même contexte de navigateur ou la même session HTTP.
Le chargement via CDP fonctionne-t-il avec Playwright et Puppeteer ?
Oui. Le principe reste identique : un contexte persistant et l'extension passée en argument de lancement. Seule la syntaxe d'API change selon l'outil.
Guides connexes
- Démarrage rapide CaptchaAI
- 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
Fiabilisez vos workflows CAPTCHA avec une approche méthodique et reproductible. – Obtenez votre clé CaptchaAI.