Régler les threads pour saturer le débit sans erreurs

Périmètre sûr : ce guide s'applique à 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 décrit ni l'automatisation de sites tiers, ni la levée de protections.

Saturer vos threads, c'est garder occupées toutes les résolutions simultanées que votre plan autorise, sans dépasser ce seuil au point de générer des erreurs. Un thread correspond à une résolution CAPTCHA en cours : dès qu'elle se termine, il se libère pour la suivante. Ce guide vous donne une référence citable en revue de code, qui tient en production.

Qu'est-ce que la saturation des threads ?

La facturation CaptchaAI se fait par thread simultané, avec un nombre de résolutions illimité par thread sur le mois. Le débit maximal est donc borné par deux facteurs : le nombre de threads du plan et la vitesse de résolution par type de CAPTCHA. Avec un plan STANDARD ($30/mois, 15 threads), la saturation consiste à maintenir ces 15 threads actifs le plus souvent possible. Lancer 40 tâches d'un coup ne va pas plus vite : le surplus attend et votre code interprète parfois l'attente comme un échec. Le bon réglage n'est pas « le plus de threads possible » mais « autant de tâches en vol que de threads disponibles ».

Architecture cible : de l'appel API au token

Votre composant interne appelle CaptchaAI en HTTPS pour récupérer un token, puis l'injecte dans votre formulaire ou votre route d'API. Un semaphore borné à la taille du plan évite d'inonder l'API et garde le débit stable quand la charge fluctue.

Le cycle envoi / interrogation du résultat

La boucle reste identique quel que soit le type de CAPTCHA ; seuls les paramètres d'entrée changent.

1. Capturez uniquement les paramètres utiles (sitekey, URL, action, proxy éventuel). En stocker plus crée de fausses pistes de débogage.
2. Envoyez la tâche à in.php avec json=1. Tout statut différent de 1 est une erreur à journaliser et à remonter.
3. Interrogez le résultat sur res.php. Attendez 15 s, puis interrogez toutes les 5 s avec un plafond strict de 120 s par tâche.
4. Appliquez le token dans la même session que celle qui a déclenché le défi : même contexte de navigateur, même cookie jar. Une session dépareillée est la première cause de rejet.
5. Mesurez latence, retries et acceptation en aval. Réussite de la résolution et réussite du workflow sont distinctes.

Sécuriser la clé et dimensionner les threads

La clé CaptchaAI vit dans un coffre (HashiCorp Vault, AWS Secrets Manager) ou un secret de CI, jamais dans le code source. Exposez la limite de concurrence comme variable de configuration : vous ajustez la saturation sans redéployer quand vous changez de plan.

Observabilité : mesurer le débit et les erreurs

Instrumentez les appels CAPTCHA pour obtenir des signaux exploitables : durée d'obtention du token, code retour HTTP, identifiant de tâche et profondeur de la file interne. Corrélez les identifiants à votre traçage distribué (par exemple OpenTelemetry) pour rejouer un scénario depuis un seul identifiant. Si vos journaux capturent des données personnelles, minimisez leur collecte et vérifiez vos obligations RGPD.

Exemple de code : vérifier le solde avant de saturer

Avant de lancer un pool à pleine capacité, un contrôle du solde évite de saturer des threads qui échoueront sur un compte vide :

import os
import requests

API_KEY = os.environ['CAPTCHAAI_KEY']

def get_balance() -> float:
    resp = requests.post(
        'https://api.captchaai.com/getBalance',
        json={'clientKey': API_KEY},
        timeout=15,
    )
    resp.raise_for_status()
    return float(resp.json().get('balance', 0))

Objectifs à suivre dans vos tableaux de bord

Câblez ces indicateurs sur le tableau de bord de votre application. Les valeurs 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.

Dépannage

Liste de contrôle avant la mise en production

• Le périmètre est limité à vos propres applications ou à des sources autorisées.
• La clé est stockée dans un coffre ou un secret de CI, jamais dans le code source.
• La concurrence est plafonnée au nombre de threads du plan, jamais au-delà.
• Durées d'appel et codes retour sont tracés à chaque exécution.
• Un retry idempotent, avec backoff exponentiel borné, couvre les erreurs transitoires.

FAQ

Combien de threads dois-je prévoir pour mon volume ?

Partez de votre débit réel mesuré. Comptez les résolutions simultanées lancées en pointe, puis choisissez le plan qui couvre ce chiffre avec une marge : BASIC ($15/mois, 5 threads) pour un job léger, ADVANCE ($90/mois, 50 threads) pour un pool plus large. Les résolutions étant illimitées par thread, vous payez la concurrence.

Comment éviter les erreurs quand les threads sont saturés ?

Bornez la concurrence à la taille de votre plan avec un semaphore : jamais plus de tâches en vol que de threads disponibles. Le surplus attend côté client plutôt que d'être rejeté par l'API.

Ce guide couvre-t-il l'automatisation de sites tiers ?

Non. Tous les exemples portent sur vos propres applications ou sur des environnements autorisés par écrit. Aucune technique de levée de protection sur un site public n'est décrite. Si une source externe est concernée, validez d'abord ses conditions d'utilisation et votre base juridique.

Que faire en cas d'erreur transitoire de l'API ?

Mettez en place un retry avec backoff exponentiel borné : trois tentatives, doublement du délai à chaque essai, plafond à 30 s. Tracez chaque échec avec son identifiant de tâche. Si l'erreur persiste, vérifiez le réseau et les quotas de votre clé.

Guides connexes

• Le démarrage rapide CaptchaAI
• La 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

Réglez vos threads sur des mesures réelles et gardez un débit stable et reproductible. – Obtenez votre clé CaptchaAI.