Résoudre les CAPTCHA dans Azure Durable Functions

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, ni l'évasion de systèmes anti-bot.

Dans Azure Durable Functions, l'appel à CaptchaAI doit vivre dans une fonction d'activité, jamais dans l'orchestrateur. Ce dernier rejoue son code à chaque reprise (checkpoint/replay) et doit rester déterministe : un appel réseau mal placé se déclenche plusieurs fois et corrompt l'état de votre workflow. Cette règle posée, le reste de l'intégration devient prévisible et se tient en production, pas seulement dans une démo.

Pourquoi l'orchestrateur n'appelle jamais CaptchaAI

Une fonction orchestratrice est rejouée depuis le début à chaque point de reprise. Tout ce qui n'est pas déterministe — appel HTTP, horloge système, aléatoire — doit passer par une fonction d'activité, dont le résultat est enregistré dans l'historique et réutilisé lors du replay. L'orchestrateur décide, l'activité appelle CaptchaAI et renvoie le token. La résolution reste ainsi rejouable après un redémarrage de l'hôte, sans relancer une résolution déjà payée.

Architecture : activité de résolution et orchestrateur

Le découpage qui tient dans la durée sépare trois responsabilités :

• Activité « soumission » : elle envoie la tâche à CaptchaAI via HTTPS et renvoie l'identifiant de tâche. C'est le seul endroit qui connaît votre clé API.
• Orchestrateur : il enchaîne les étapes, gère l'attente, applique la politique de retry et injecte le token dans la suite du parcours.
• Activité « application » : elle rejoue le token dans la même session que celle ayant déclenché le défi.

Ce découpage se prête au fan-out/fan-in : chaque résolution parallèle devient une activité indépendante, et votre plafond de parallélisme correspond au nombre de threads de votre plan CaptchaAI.

Attendre le résultat avec un timer durable

La résolution d'un CAPTCHA à token n'est pas instantanée : vous soumettez une tâche, puis vous interrogez le résultat. N'utilisez jamais sleep ni Task.Delay dans un orchestrateur — cela casse le déterminisme. Utilisez un timer durable (context.CreateTimer / create_timer), qui suspend l'orchestration sans consommer de ressources.

La cadence éprouvée reste la même quel que soit le type de CAPTCHA : attendez 15 s avant la première interrogation, puis interrogez toutes les 5 s, avec un plafond strict de 120 s par tâche. Traitez tout statut différent de « prêt » comme une indisponibilité temporaire, et toute erreur explicite comme un échec à journaliser.

Rejouer le token dans la même session

La cause la plus fréquente de rejet après résolution est un token appliqué dans une session différente de celle qui a déclenché le défi. Conservez le même contexte de navigateur, le même client HTTP et le même cookie jar. L'activité « application » doit donc recevoir tout le contexte nécessaire (URL de page, sitekey, cookies) en entrée plutôt que de le reconstruire.

Retry idempotent et secrets

Les Durable Functions offrent des politiques de retry natives (RetryOptions), mais bornez-les : trois tentatives, backoff exponentiel, plafond à 30 s. Rendez chaque activité idempotente pour qu'un replay ne relance pas une résolution déjà obtenue, et distinguez une erreur transitoire (réseau, quota) d'une erreur définitive (paramètre invalide, clé absente). La clé CaptchaAI vit dans Azure Key Vault ou un secret CI, jamais dans le code ; le déploiement la monte en variable d'environnement au runtime.

Exemple de code

Appel HTTP côté serveur, à isoler dans une fonction d'activité :

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

L'activité renvoie l'identifiant de tâche ; l'orchestrateur enchaîne les interrogations via un timer durable jusqu'au token ou au plafond de 120 s.

Observabilité et journalisation

Instrumentez chaque appel 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. Séparez les logs par environnement et corrélez-les à votre traçage distribué (Application Insights ou OpenTelemetry). Grâce à l'instanceId de l'orchestration, vous rejouez un scénario complet à partir d'un identifiant unique, ce qui divise par deux le temps de diagnostic en cas d'incident.

Mesurer la réussite

Les chiffres ci-dessous reposent sur des mesures observées et des retours d'utilisateurs ; les résultats varient selon l'environnement, le volume et le moment de la journée. Câblez ces indicateurs dans le tableau de bord de votre application pour repérer une régression avant vos utilisateurs.

Liste de contrôle

• Le périmètre est limité à vos propres applications ou à des sources autorisées.
• La clé CaptchaAI est dans Azure Key Vault ou un secret CI, jamais dans le code.
• L'appel réseau vit dans une activité, pas dans l'orchestrateur.
• L'attente passe par un timer durable, jamais par sleep.
• Le retry est idempotent et borné pour les erreurs transitoires.
• Les durées d'appel et les codes retour sont tracés à chaque exécution.

FAQ

Où placer l'appel à CaptchaAI dans une Durable Function ?

Dans une fonction d'activité, jamais dans l'orchestrateur. Celui-ci est rejoué à chaque point de reprise ; un appel réseau y serait répété. L'activité effectue l'appel HTTPS, dont le résultat est enregistré puis réutilisé lors du replay.

Comment attendre le résultat sans bloquer l'orchestrateur ?

Utilisez un timer durable (context.CreateTimer) plutôt qu'une pause bloquante : l'orchestration se suspend sans consommer de ressources, puis reprend pour interroger le résultat. Gardez 15 s d'attente initiale, puis une interrogation toutes les 5 s, plafonnée à 120 s.

Quel plan CaptchaAI pour un orchestrateur qui résout plusieurs CAPTCHA en parallèle ?

Le nombre de threads borne votre parallélisme réel : chaque résolution en vol occupe un thread. Le plan BASIC ($15/mois, 5 threads) convient à un orchestrateur modeste ; montez vers STANDARD ($30/mois, 15 threads) ou ADVANCE ($90/mois, 50 threads) selon votre fan-out. La facturation est basée sur les threads, avec résolutions illimitées.

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. Si votre projet implique une source externe, validez d'abord les conditions d'utilisation et la base juridique avant toute automatisation.

Guides connexes

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

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