Rendez-vous VFS Global : gérer le CAPTCHA en périmètre autorisé

Périmètre sûr : ce guide s'applique exclusivement à vos propres applications, à vos environnements de QA ou de préproduction, et aux systèmes pour lesquels vous disposez d'une autorisation écrite. Il ne décrit ni l'automatisation de portails tiers, ni l'évasion de protections anti-fraude.

Sur un parcours de prise de rendez-vous, le défi CAPTCHA est rarement le vrai point de rupture : c'est la session qui l'entoure. Un token réinjecté depuis un autre contexte navigateur sera refusé côté serveur, et votre suite de tests remontera un « échec de résolution » alors que la résolution s'est bien déroulée. La règle tient en une phrase : résolvez et soumettez dans la même session, puis mesurez séparément la résolution et l'acceptation en aval.

Ce guide couvre le branchement de CaptchaAI sur un parcours de rendez-vous VFS Global que vous exploitez vous-même : préproduction, application interne ou tests bout en bout.

Vérifier le périmètre avant d'écrire une ligne de code

Trois configurations sont couvertes ici : vous êtes propriétaire de l'application qui affiche le défi, vous l'exploitez pour un client qui a autorisé l'intégration par écrit, ou vous opérez sous accord de collecte documenté. Si aucune ne correspond à votre projet, la question n'est plus technique.

C'est aussi une étape de conformité. Consignez qui a donné l'autorisation, sur quel périmètre et pour quelle durée, au même endroit que vos registres de traitement RGPD : un ticket daté et une pièce jointe signée suffisent.

Le défi en grille d'images, côté BLS

Ces parcours affichent une grille de vignettes accompagnée d'une consigne numérique : l'utilisateur sélectionne les images correspondantes. CaptchaAI prend en charge ce type via la méthode bls. Vous envoyez la consigne et les images encodées en base64, vous récupérez la sélection attendue, puis vous la rejouez dans la page.

Deux conséquences pratiques : la qualité de capture des vignettes compte autant que l'appel API, et la consigne se transmet telle quelle, sans reformulation ni traduction — c'est un identifiant, pas du texte destiné à un lecteur.

Architecture de l'orchestration

L'orchestrateur pilote le parcours et n'appelle CaptchaAI que sur les écrans où un défi apparaît ; les autres étapes restent des appels HTTP classiques. Quatre briques suffisent :

1. Un contexte de session unique — même client HTTP, même cookie jar, du chargement initial à la soumission.
2. Un appel de résolution isolé, avec son timeout et son budget de retry propres, pour ne pas contaminer le timeout global.
3. Un point de contrôle après injection : vérifiez le code retour de la soumission, pas seulement celui de la résolution.
4. Une file d'attente interne calée sur le nombre de threads de votre plan.

Cette séparation évite le piège le plus fréquent : un retry global qui relance tout le parcours depuis le début et redemande un défi déjà résolu.

Exemple de code

Exemple côté client de votre propre suite de tests :

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

Le contrat ne change pas d'un langage à l'autre : envoyer la tâche, interroger le résultat, appliquer la réponse. Un client HTTP suffit à le transposer.

Retries, timeouts et robustesse

Bornez tout : trois tentatives au maximum, un backoff exponentiel qui double le délai à chaque essai, un plafond à 30 s par tentative. Au-delà, l'échec devient terminal, journalisé avec son identifiant de tâche et remonté à votre canal d'alerte.

Rendez ces retries idempotents : si une nouvelle tentative peut créer un second dossier, ce n'est plus un retry mais un doublon. Une clé d'idempotence transmise par l'orchestrateur règle le problème.

Distinguez enfin deux taux : la réussite de la résolution et l'acceptation en aval. L'écart entre les deux est le signal le plus utile, et il tient presque toujours à la session ou aux paramètres d'entrée.

Observabilité et journalisation

Instrumentez chaque appel CAPTCHA : durée totale d'obtention de la réponse, code retour HTTP, identifiant de tâche et profondeur de la file d'attente interne. Ces quatre signaux alimentent vos tableaux de bord QA et vos alertes.

Séparez les journaux par environnement et corrélez-les à votre traçage distribué, via OpenTelemetry par exemple : un identifiant unique suffit à rejouer un scénario complet.

Attention côté RGPD : les captures et les images de défis issues d'un dossier réel contiennent des données personnelles. Journalisez des identifiants, des durées et des codes retour, et gardez les images en test uniquement, avec une rétention courte.

Dimensionner les threads et le budget

La facturation CaptchaAI repose sur le nombre de threads simultanés, pas sur le nombre de résolutions : chaque plan inclut des résolutions illimitées par thread, sans surcoût selon le type de CAPTCHA. Un thread correspond à une résolution en cours ; dès qu'elle se termine, le thread prend la suivante.

Un cas concret : une équipe QA basée à Casablanca rejoue chaque nuit une trentaine de scénarios sur un clone de préproduction hébergé chez OVHcloud, avec au plus quatre parcours en parallèle — BASIC ($15/mois, 5 threads) suffit. Dès que la suite se déclenche à chaque merge request, la concurrence monte à une douzaine et STANDARD ($30/mois, 15 threads) devient le palier cohérent. La facturation reste en dollars US.

Liste de contrôle avant mise en production

• Périmètre limité à vos applications ou à des sources autorisées, autorisation archivée.
• Clé CaptchaAI dans un secret CI ou un coffre, jamais dans un fichier .env versionné.
• Résolution et soumission dans la même session et le même cookie jar.
• Durées, codes retour et identifiants de tâche tracés à chaque exécution.
• Retries bornés, idempotents et journalisés jusqu'à l'échec terminal.
• Jeux de données de test factices, rétention des captures limitée.
• Threads du plan alignés sur la concurrence réelle du pipeline.

FAQ

Puis-je appliquer ce guide au portail public de prise de rendez-vous ?

Non. Le périmètre couvert est celui de vos applications, de vos environnements de test et des systèmes pour lesquels vous détenez une autorisation écrite. Un portail public que vous ne contrôlez pas sort du cadre de cet article.

Quelle méthode CaptchaAI correspond à un défi en grille d'images ?

La méthode bls, en version stable : vous transmettez la consigne et les vignettes en base64, vous recevez la sélection à rejouer. Si l'écran affiche un défi reCAPTCHA v2, seules la méthode et la nature de la réponse changent.

Combien de threads prévoir pour une équipe de support ?

Comptez les parcours simultanés, pas le volume quotidien. Quatre workers en parallèle tiennent dans BASIC ($15/mois, 5 threads) ; une intégration continue dépasse vite ce palier. Les résolutions étant illimitées par thread, seul le parallélisme compte.

Que journaliser sans créer de risque RGPD ?

Journalisez l'identifiant de tâche, l'horodatage, la durée, le code retour et l'environnement. Évitez tout stockage durable des images de défis et des données personnelles issues d'un cas réel.

Guides connexes

• Démarrage rapide CaptchaAI
• Tester les CAPTCHA en environnement autorisé
• Valider l'endpoint API sur vos formulaires
• Intégrer la résolution CAPTCHA à votre CI
• Résoudre reCAPTCHA v2 via l'API

Gardez votre architecture en place : CaptchaAI renvoie une réponse que votre pipeline injecte à l'endroit prévu. – Obtenez votre clé CaptchaAI.