Quand faire évoluer votre forfait CaptchaAI : les signaux de saturation

Périmètre sûr : ce guide vise vos propres applications et vos environnements de QA, de préproduction ou de production — ou tout système pour lequel vous disposez d'une autorisation écrite. Il ne couvre pas l'automatisation de sites tiers que vous ne contrôlez pas.

Le signal le plus fiable qu'il faut faire évoluer votre forfait CaptchaAI tient en un code d'erreur : ERROR_NO_SLOT_AVAILABLE. Il apparaît dès que votre automatisation tente de résoudre plus de CAPTCHA en parallèle que votre plan ne l'autorise. Mais ce n'est pas le seul indice, et augmenter le forfait n'est pas toujours la bonne réponse. Voici comment lire les signaux de saturation, les distinguer d'un pic passager, et choisir entre faire évoluer, optimiser ou empiler vos plans.

La facturation par threads, en bref

CaptchaAI facture des threads simultanés, pas des résolutions à l'unité. Un thread correspond à un CAPTCHA en cours de traitement : dès qu'une résolution se termine, le thread se libère pour la suivante. Chaque plan inclut un nombre de résolutions illimité par thread, sans plafond journalier ni surcoût selon le type de CAPTCHA.

Le plafond, c'est donc le nombre de threads. Le forfait BASIC ($15/mois, 5 threads) suffit à un cron nocturne modeste ; STANDARD ($30/mois, 15 threads) et ADVANCE ($90/mois, 50 threads) couvrent la plupart des pipelines de production. Au-delà, PREMIUM ($170/mois, 100 threads) et ENTERPRISE ($300/mois, 200 threads) visent les charges massives. Quand votre débit dépasse les threads disponibles, les requêtes excédentaires reçoivent ERROR_NO_SLOT_AVAILABLE.

Les trois signaux d'un forfait saturé

Trois symptômes, souvent combinés, trahissent un plan devenu trop petit.

D'abord, le taux de ERROR_NO_SLOT_AVAILABLE. Un pic isolé pendant une rafale ponctuelle est normal ; au-delà de 5 à 10 % des soumissions sur une fenêtre représentative, votre plafond de threads est le goulot d'étranglement.

Ensuite, la latence de bout en bout qui grimpe alors que le temps de résolution unitaire ne bouge pas. Vos tâches attendent un thread libre avant même d'être soumises : la file d'attente interne gonfle, et le temps perçu inclut cette attente.

Enfin, un débit qui plafonne. Vous ajoutez des workers, mais le nombre de CAPTCHA résolus par minute ne progresse plus : le mur n'est pas votre code, c'est l'allocation de threads.

Exemple concret : une équipe déploie ses workers sur Scaleway pour des tests de checkout e-commerce nocturnes. En journée, 5 threads (BASIC) suffisent ; pendant la fenêtre de tests, le débit triple et ERROR_NO_SLOT_AVAILABLE apparaît. Le bon réflexe n'est pas de payer un gros forfait en permanence, mais de dimensionner sur le pic réel — ou d'empiler un plan le temps de la campagne.

Surveiller la saturation avant qu'elle ne bloque

Instrumentez vos appels pour distinguer une saturation réelle d'un incident réseau. Une sonde simple vérifie le solde et sert de base à un tableau de bord qui suit, en parallèle, le taux de créneaux indisponibles :

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))

Étendez ensuite ce principe : comptez les réponses ERROR_NO_SLOT_AVAILABLE, rapportez-les au total des soumissions, et faites remonter le ratio dans vos métriques par environnement. Tracez pour chaque appel la durée totale d'obtention du token, le code retour HTTP, l'identifiant de tâche et la taille de la file d'attente interne : ces signaux alimentent vos tableaux de bord de QA et vos alertes.

Séparez les journaux par environnement (développement, préproduction, production) et corrélez les identifiants à votre traçage distribué (OpenTelemetry, par exemple). Vous pourrez ainsi rejouer un scénario complet à partir d'un identifiant unique, et distinguer d'un coup d'œil une attente de thread d'une véritable panne.

Faire évoluer, optimiser ou empiler : comment choisir

Un forfait saturé n'impose pas mécaniquement de passer au palier supérieur. Trois leviers existent, dans cet ordre de préférence.

Optimisez d'abord. Des boucles de retry mal bornées, des paramètres erronés qui relancent des tâches ou un polling trop agressif consomment des threads pour rien. Corrigez ces gaspillages avant de payer plus : ils font souvent passer une saturation apparente pour un vrai plafond.

Faites évoluer ensuite. Si votre débit utile dépasse durablement vos threads, passez au palier au-dessus. C'est le geste le plus simple, et le plus prévisible côté facturation : le coût mensuel reste fixe, quel que soit le nombre de résolutions.

Empilez enfin. Pour des charges très variables ou plusieurs équipes, cumuler plusieurs plans répartit les threads sans vous enfermer dans un seul palier, et vous laisse retirer la capacité temporaire une fois la campagne terminée.

Liste de contrôle avant de changer de forfait

• Mesurez le taux de ERROR_NO_SLOT_AVAILABLE sur une fenêtre représentative, pas sur un pic isolé.
• Vérifiez que vos boucles de retry sont bornées : trois tentatives, backoff exponentiel plafonné à 30 s.
• Confirmez que le goulot vient bien des threads, et non du réseau, des certificats ou d'un paramètre erroné.
• Distinguez, dans vos métriques, le temps d'attente d'un thread du temps de résolution unitaire.
• Estimez votre débit cible en threads au pic avant de choisir le palier, pour éviter le sur-dimensionnement.
• La clé CaptchaAI reste stockée dans un secret CI ou un coffre, jamais dans le code source.

FAQ

Que signifie l'erreur ERROR_NO_SLOT_AVAILABLE ?

Elle indique que tous vos threads sont occupés : votre automatisation demande plus de résolutions simultanées que votre plan n'en autorise. Ce n'est pas une panne de CaptchaAI. Mettez la tâche en file d'attente et réessayez après un court délai ; si le taux dépasse durablement 5 à 10 %, votre forfait est trop petit.

Combien de threads faut-il pour mon volume ?

Comptez le nombre de CAPTCHA que vous devez résoudre en parallèle au pic, pas en moyenne. Le débit dépend aussi du temps de résolution par type : un thread enchaîne d'autant plus de tâches que chaque résolution est rapide. Partez du palier qui couvre votre pic — BASIC (5 threads), STANDARD (15) ou ADVANCE (50) — puis ajustez d'après vos mesures.

Vaut-il mieux changer de forfait ou empiler plusieurs plans ?

Pour une charge stable qui dépasse durablement vos threads, passez au palier supérieur : c'est plus simple à suivre. Pour des pics irréguliers ou plusieurs équipes, empiler des plans répartit les threads avec plus de souplesse. Dans les deux cas, corrigez d'abord les gaspillages de threads (retry non bornés, paramètres erronés).

Un forfait plus cher résout-il les CAPTCHA plus vite ?

Non. Le palier détermine le nombre de threads simultanés, pas la vitesse de résolution d'un CAPTCHA donné. Un plan plus grand supprime l'attente d'un thread libre lorsque vous êtes saturé, mais il ne réduit pas le temps de résolution unitaire, qui dépend du type de CAPTCHA.

Guides connexes

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

Dimensionnez votre forfait sur votre charge réelle plutôt qu'au jugé. – Créez votre compte CaptchaAI.