Périmètre sûr : ce guide s'applique uniquement à vos propres applications et à vos environnements de QA, de préproduction ou de production, ou à des systèmes pour lesquels vous disposez d'une autorisation écrite. Il ne traite pas de l'automatisation de sites tiers.
Un fichier de configuration partagé permet à plusieurs postes d'exécuter l'extension CaptchaAI avec les mêmes réglages, sans configuration manuelle machine par machine. Vous versionnez un seul fichier — clé API référencée par secret, profil de navigateur, type de CAPTCHA ciblé, comportement après résolution — et chaque poste le lit au démarrage.
Pourquoi centraliser la configuration de l'extension
Dès que plusieurs développeurs, un runner d'intégration continue et un poste de préproduction partagent le même comportement, chaque réglage manuel devient une source de dérive. Un token qui passe chez vous mais échoue chez un collègue vient presque toujours d'un écart de configuration, pas de l'API. La source de vérité unique supprime cette catégorie entière d'incidents.
Ce que le fichier de configuration doit décrire
| Élément | Ce qui reste stable entre les postes |
|---|---|
| État du compte | La clé API n'est pas écrite en clair, mais référencée via un secret d'intégration continue. |
| Profil de navigateur | Le répertoire user-data-dir et le chemin de l'extension, pour que chaque poste charge le même profil. |
| Gestionnaire de CAPTCHA | Le type ciblé (reCAPTCHA v2, reCAPTCHA v3, Cloudflare Turnstile, GeeTest v3, image/OCR) et ses paramètres. |
| Comportement après résolution | Où le token est injecté et comment la session poursuit le parcours. |
Encapsuler la résolution dans une fonction partagée
Isolez d'abord l'environnement de QA de la production et récupérez la clé CaptchaAI depuis un coffre ou un secret d'intégration continue. Le cœur de la configuration partagée est une fonction unique que tous les postes appellent : elle prend le sitekey et l'URL de votre page, envoie la tâche à CaptchaAI, retourne un identifiant de tâche et trace la durée et le code retour. Un seul endroit à maintenir.
Exemple : une fonction de résolution réutilisable
Voici la fonction que les postes partagent, en Node.js :
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;
}
La même logique se transpose vers Python ou Go.
Vérifier le token côté backend
Le token retourné doit être validé par votre propre backend avant toute opération métier, et dans la même session que celle qui a déclenché le défi CAPTCHA. Cette validation évite qu'une requête soit acceptée sur la base d'un token périmé ou appliqué dans une autre session — la cause la plus fréquente de rejet après résolution.
Observabilité et journalisation
Instrumentez chaque appel CAPTCHA pour obtenir des signaux exploitables : durée d'obtention du token, code retour HTTP, identifiant de tâche et taille de la file d'attente. Ils distinguent la réussite de résolution de la réussite du parcours complet. Séparez les journaux par environnement et corrélez les identifiants à votre traçage distribué (OpenTelemetry, par exemple). Côté conformité, minimisez les données personnelles journalisées : gardez les identifiants techniques, pas le contenu des formulaires, conformément au RGPD.
Liste de contrôle avant déploiement
| Contrôle | Pourquoi il compte |
|---|---|
| Fichier de configuration versionné | Il reste la seule source de vérité partagée entre les postes. |
| Périmètre limité à vos applications ou à des sources autorisées | Le guide ne couvre pas l'automatisation de sites tiers. |
| Clé CaptchaAI référencée depuis un secret ou un coffre | Jamais écrite dans le fichier ; vous pouvez la faire tourner sans y toucher. |
| Durées d'appel et codes retour tracés | Un retry idempotent à backoff exponentiel borné absorbe les erreurs transitoires. |
| Tests rejouables à l'identique depuis chaque poste | La configuration partagée n'a de valeur que si elle est reproductible. |
FAQ
Comment s'assurer que tous les postes utilisent la même configuration ?
Versionnez un fichier unique, lu par l'extension au démarrage. Chaque poste y charge le profil, le type de CAPTCHA et la référence de clé ; rien n'est saisi à la main.
Où stocker la clé API dans une configuration partagée ?
Jamais dans le fichier. Celui-ci référence une variable d'environnement ou un secret d'intégration continue ; la valeur réelle reste dans un coffre. Vous la partagez sans l'exposer et pouvez la faire tourner sans toucher au fichier.
Que se passe-t-il si un poste utilise une version différente de l'extension ?
Le comportement peut diverger, et c'est précisément ce que la source de vérité unique évite. Épinglez la version de l'extension dans le fichier partagé et validez-la au démarrage : un poste dont la version ne correspond pas doit échouer bruyamment plutôt que produire des résultats différents en silence.
Peut-on gérer plusieurs environnements avec un seul fichier ?
Oui. Gardez une base commune et surchargez uniquement ce qui diffère entre développement, préproduction et production : endpoints internes, niveau de journalisation, quotas. La logique de résolution, elle, reste partagée.
Guides connexes
- Démarrage rapide CaptchaAI
- QA CAPTCHA en environnements autorisés
- Tester l'endpoint API sur vos formulaires
- Intégration CAPTCHA en continu
- Résoudre reCAPTCHA v2 via l'API
Déployez la même configuration d'extension sur tous vos postes et mesurez vos temps de résolution depuis votre propre environnement. – Obtenez votre clé CaptchaAI.
