La disponibilité d'un solveur CAPTCHA ne se juge pas sur un chiffre d'uptime affiché en page marketing : elle se mesure sur votre propre trafic, avec vos types de CAPTCHA, aux heures où votre pipeline tourne vraiment. Un fournisseur peut annoncer une continuité de service élevée et rester lent le week-end ou pendant un pic de charge, exactement les moments où votre collecte de données en dépend le plus. Ce guide propose un cadre de comparaison fondé sur des métriques internes reproductibles, avec les scripts pour les relever vous-même.
Pourquoi mesurer la disponibilité vous-même
Deux solveurs peuvent afficher le même uptime annuel et se comporter très différemment à 3 h du matin. L'écart tient souvent à l'architecture. Un service à opérateurs humains (résolution par opérateurs humains) dépend de la disponibilité de ses opérateurs : les nuits, les week-ends et les jours fériés, la file d'attente s'allonge et la latence grimpe. Un service basé sur des modèles d'IA sur infrastructure redondante, comme CaptchaAI, ne connaît pas ce goulot d'étranglement humain et garde un profil de latence plus régulier autour de l'horloge.
Selon les données publiées, 2Captcha repose sur des opérateurs humains et une file d'attente, Anti-Captcha sur un modèle hybride, et CapSolver sur de l'IA. Ces différences d'architecture ne disent pas quel service sera le plus rapide sur votre volume, mais elles prédisent bien où chercher les creux de performance : aux heures creuses pour les services humains, lors des pics de charge pour tout le monde.
Les métriques de fiabilité à suivre
Une comparaison utile repose sur des indicateurs mesurés en interne, pas sur des slogans :
- Taux de réussite par type de CAPTCHA (reCAPTCHA v2, Turnstile, GeeTest v3…).
- Taux d'erreur API (réponses 4xx/5xx).
- Timeouts de soumission et de polling.
- Latence médiane, P90 et P99 — le P99 révèle les cas lents que la médiane masque.
- Nombre de retries nécessaires pour 1 000 tâches.
- Comportement de failover vers un fournisseur secondaire.
La médiane rassure, mais ce sont les percentiles hauts qui cassent un pipeline : une P99 à 90 s sur un job planifié toutes les minutes suffit à faire déborder la file. Suivez P90 et P99 par plage horaire, pas seulement une moyenne globale.
Une grille de comparaison à remplir avec vos chiffres
Les valeurs ci-dessous se complètent avec vos propres mesures ; les résultats varient selon l'environnement, le volume et le moment de la journée. Gardez la même fenêtre d'observation (par exemple 30 jours) et le même type de CAPTCHA pour chaque colonne, sinon la comparaison n'a pas de sens.
| Indicateur | CaptchaAI | Fournisseur B | Fournisseur C |
|---|---|---|---|
| Disponibilité mesurée sur 30 jours | à mesurer | à mesurer | à mesurer |
| Timeout de polling observé | à mesurer | à mesurer | à mesurer |
| Retries moyens pour 1 000 tâches | à mesurer | à mesurer | à mesurer |
| Durée maximale de dégradation | à mesurer | à mesurer | à mesurer |
| Procédure d'incident | documentée | documentée | documentée |
Une architecture pensée pour la résilience
Aucun service n'est disponible en permanence. La question n'est pas d'éviter tout incident, mais d'absorber les incidents sans arrêter le pipeline. Le schéma le plus simple enchaîne un solveur principal, un retry contrôlé, puis une bascule vers un solveur secondaire :
Client -> Solver principal -> resultat
| (erreur/timeout)
v
Retry controle -> Solver secondaire -> resultat
Bonnes pratiques :
- Limiter le nombre de retries par tâche.
- Distinguer les erreurs temporaires des erreurs définitives.
- Activer un circuit breaker en cas de pic d'échec.
- Journaliser chaque bascule vers le fallback.
Un retry aveugle transforme une panne courte en tempête de requêtes. Un backoff exponentiel et un plafond de tentatives évitent d'aggraver la charge quand le fournisseur est déjà en difficulté.
Exemple Python : un solveur résilient
La classe ci-dessous encapsule la logique de résilience : soumission, polling avec timeout, et nouvelle tentative avec backoff exponentiel plafonné. Elle vise l'endpoint in.php pour envoyer la tâche et res.php pour interroger le résultat.
import logging
import requests
import time
logger = logging.getLogger(__name__)
class ReliableCaptchaSolver:
def __init__(self, api_key: str, max_retries: int = 3, poll_timeout: int = 120):
self.api_key = api_key
self.max_retries = max_retries
self.poll_timeout = poll_timeout
self.base_url = "https://ocr.captchaai.com"
def solve(self, method: str, **params) -> str:
for attempt in range(1, self.max_retries + 1):
try:
return self._solve_once(method, **params)
except TimeoutError:
logger.warning("Timeout solve attempt=%s", attempt)
time.sleep(min(2 ** attempt, 8))
except requests.RequestException as exc:
logger.warning("API exception attempt=%s error=%s", attempt, exc)
time.sleep(min(2 ** attempt, 8))
raise RuntimeError("All solve attempts failed")
def _solve_once(self, method: str, **params) -> str:
submit = requests.post(
f"{self.base_url}/in.php",
data={"key": self.api_key, "method": method, "json": 1, **params},
timeout=30,
)
submit.raise_for_status()
task_id = submit.json()["request"]
start = time.time()
while time.time() - start < self.poll_timeout:
time.sleep(5)
poll = requests.get(
f"{self.base_url}/res.php",
params={"key": self.api_key, "action": "get", "id": task_id, "json": 1},
timeout=30,
)
poll.raise_for_status()
payload = poll.json()
if payload["request"] == "CAPCHA_NOT_READY":
continue
return payload["request"]
raise TimeoutError("Polling timeout")
Ajustez poll_timeout selon le type visé : Cloudflare Turnstile se résout typiquement en moins de 10 secondes et reCAPTCHA v3 en moins de 4 secondes, tandis qu'un reCAPTCHA v2 sous forte concurrence demande une marge plus large. Trop court, vous abandonnez des tâches qui allaient aboutir ; trop long, vous immobilisez un thread inutilement.
Un scénario concret côté francophone
Prenons un job de collecte nocturne hébergé sur un worker Scaleway ou OVHcloud en région eu-west-3 (Paris). En journée, deux solveurs paraissent équivalents. Mais en instrumentant P90 et P99 par heure, l'équipe constate qu'entre 2 h et 5 h, le fournisseur à opérateurs humains double sa latence, alors que le service basé sur l'IA reste stable. Le correctif n'est pas d'abandonner le premier, mais de le placer en secondaire et de router le trafic nocturne vers le solveur régulier.
Pour un pilote, un plan d'entrée comme BASIC ($15/mois, 5 threads) suffit à mesurer la disponibilité réelle sur votre propre trafic avant de dimensionner plus haut. La facturation reste en dollars US et se fait par thread concurrent, sans coût par résolution : la variable à surveiller est le nombre de threads occupés en pic, pas le volume brut. Si vous journalisez des échantillons de trafic, minimisez les données personnelles collectées et vérifiez vos obligations RGPD.
Valider la fiabilité en continu
- Exécuter des tests synthétiques réguliers : une résolution par type, chaque heure.
- Comparer les indicateurs par plage horaire et par région.
- Centraliser les incidents dans un tableau de bord unique.
- Rejouer des scénarios de failover en préproduction, pas seulement en incident réel.
Un test synthétique horaire par type de CAPTCHA vous donne une courbe de disponibilité indépendante du trafic métier : vous détectez une dégradation avant qu'elle ne touche la production.
Questions fréquentes
Sur quelles métriques comparer la fiabilité de deux solveurs CAPTCHA ?
Comparez sur une même fenêtre et un même type : taux de réussite, taux d'erreur API, P90/P99 de latence, retries pour 1 000 tâches et durée de dégradation. Un uptime global annoncé ne remplace pas ces mesures relevées sur votre trafic.
Comment distinguer une erreur temporaire d'une erreur définitive ?
Une erreur temporaire (timeout réseau, 5xx passager, CAPCHA_NOT_READY prolongé) se retente avec un backoff. Une erreur définitive (clé API invalide, méthode incorrecte, type non pris en charge) ne doit jamais être retentée : loggez-la et faites-la remonter immédiatement.
Quel délai de polling faut-il prévoir ?
Calez le timeout sur le type : quelques secondes suffisent pour Turnstile ou reCAPTCHA v3, davantage pour un reCAPTCHA v2 en forte concurrence. Prévoyez une marge au-dessus du temps de résolution habituel, puis abandonnez la tâche proprement plutôt que de bloquer un thread.
Faut-il configurer un fournisseur de secours ?
Pour un pipeline critique, oui. Un schéma principal/secondaire avec bascule automatique évite qu'une panne isolée chez votre fournisseur principal n'arrête toute la collecte. Journalisez chaque bascule pour mesurer la fréquence réelle des incidents.
La fiabilité se confirme dans la durée, par des mesures internes reproductibles plutôt que par un chiffre affiché.
