Résolution de CAPTCHAs depuis Fastly Compute@Edge

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 couvre ni l'automatisation de sites tiers, ni la neutralisation de protections anti-bot.

Une fonction Fastly Compute@Edge ne résout pas un CAPTCHA elle-même : elle délègue l'appel à CaptchaAI, récupère un token, puis le réinjecte dans la requête qui poursuit le parcours. Tout l'enjeu tient à la fiabilité de cet aller-retour lorsqu'il tourne sans surveillance — en CI, dans un cron ou derrière une file interne. Ce guide décrit une intégration « All types » pensée pour rester stable en production, pas seulement le temps d'une démo.

Architecture : résoudre un CAPTCHA depuis une fonction edge

Le schéma est simple : votre fonction edge appelle CaptchaAI en HTTPS pour obtenir un token, puis l'injecte dans le formulaire ou la route d'API qui continue le flux. Instrumentez chaque étape pour rendre les régressions visibles dès la première montée de version. À la périphérie, deux contraintes pèsent plus qu'ailleurs : le temps d'exécution limité et l'absence d'état entre deux invocations. Traitez donc chaque résolution comme une opération autonome et idempotente, hors du chemin critique de rendu quand c'est possible.

Le contrat submit / polling pour Fastly Compute@Edge

La logique est la même quel que soit le type de CAPTCHA, ce qui rend l'intégration portable :

1. Ne capturez que les paramètres utiles au type (sitekey, URL de la page, action éventuelle, proxy optionnel). Stocker plus crée de fausses pistes de débogage.
2. Envoyez la tâche et traitez tout statut différent d'un succès comme une erreur : journalisez la réponse complète et remontez-la vers votre supervision.
3. Interrogez le résultat en respectant la cadence : 15 s avant la première interrogation, puis toutes les 5 s, avec un plafond strict de 120 s par tâche.
4. Appliquez le token dans la même session qui a déclenché le défi — même contexte, même client HTTP, même jarre de cookies. Une session dépareillée est la première cause de refus.
5. Mesurez la latence, les retries et l'acceptation en aval. Réussite de la résolution et réussite du workflow sont deux métriques distinctes.

Gérer les secrets à la périphérie

• Stockez la clé CaptchaAI dans un coffre (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) ou un secret de CI, jamais dans le code source.
• Montez-la en variable d'environnement au déploiement ; la fonction edge la lit au runtime.
• Faites-la tourner régulièrement et prévoyez une clé de secours pour absorber une rotation sans coupure.

Exemple de code

Exemple d'appel HTTP côté serveur dans votre propre service :

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;
}

Observabilité et journalisation

Instrumentez les appels CAPTCHA pour obtenir des signaux exploitables (durée d'obtention du token, code retour HTTP, identifiant de tâche, taille de la file interne), séparez les journaux par environnement et corrélez chaque identifiant à votre traçage distribué, par exemple OpenTelemetry. Les chiffres ci-dessous reposent sur des mesures observées et des retours d'utilisateurs ; ils varient selon l'environnement, le volume et le moment de la journée.

Dépannage

Liste de contrôle avant la mise en production

• Le périmètre est strictement limité à vos propres applications ou à des sources autorisées.
• La clé CaptchaAI est stockée dans un secret de CI ou un coffre, 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 avec backoff exponentiel borné est en place pour les erreurs transitoires.
• Les tests sont rejouables et reproductibles depuis votre intégration continue.

Un scénario concret : worker planifié chez OVHcloud

Prenez un worker qui, chaque nuit, traverse une étape protégée par un CAPTCHA sur votre propre application, déployé chez OVHcloud, Scaleway ou dans une région AWS proche comme eu-west-3 (Paris). CaptchaAI facture au thread simultané, résolutions illimitées par thread : le plan BASIC ($15/mois, 5 threads) suffit à faible cadence, et vous ajoutez des threads quand la concurrence augmente. Si la fonction manipule des données de formulaire, appliquez la minimisation RGPD : journalisez l'identifiant de tâche et les métriques, jamais les données personnelles saisies.

FAQ

Comment stocker la clé API dans un environnement serverless ?

Placez-la dans un coffre ou un secret de CI, puis montez-la en variable d'environnement au déploiement. La fonction la lit au runtime et ne la matérialise jamais dans le code ou les logs.

Combien de threads faut-il pour un worker à la périphérie ?

Cela dépend de votre concurrence réelle, pas du volume total : un thread traite un CAPTCHA à la fois et se libère aussitôt. Le plan BASIC ($15/mois, 5 threads) couvre un worker à faible cadence ; ajoutez des threads pour des résolutions en parallèle.

Que faire si le token est refusé après résolution ?

Vérifiez la cohérence de session : le token doit être appliqué dans le contexte, le client HTTP et la jarre de cookies qui ont déclenché le défi. Corrélez ensuite l'échec à son identifiant de tâche pour rejouer le scénario.

Guides connexes

• Le guide de démarrage rapide CaptchaAI
• La QA CAPTCHA en environnements autorisés
• Tester l'endpoint API sur vos formulaires
• Intégrer la résolution CAPTCHA dans votre CI
• Résoudre reCAPTCHA v2 via l'API

Fiabilisez vos workflows CAPTCHA avec une approche méthodique et reproductible. — Obtenez votre clé CaptchaAI.