hcaptcha-challenger : résoudre hCaptcha sans service tiers, avec des modèles ONNX embarqués

Le problème concret : un défi visuel qui change de forme

hCaptcha ne se contente pas de demander une case à cocher. Selon la configuration du site, le défi peut prendre la forme d'un choix binaire sur une grille d'images, d'un clic sur un point précis, d'un rectangle à tracer, d'un choix multiple ou d'un glisser-déposer. Chaque variante a sa propre logique de vérification côté serveur, et un solveur qui ne gère qu'un seul type devient inutile dès que l'opérateur du site change de mode.

hcaptcha-challenger répond à ce problème en empilant plusieurs modèles spécialisés, chacun rattaché à un type de défi identifié dans le tableau des fonctionnalités du README. Le projet revendique explicitement deux absences : aucun script Tampermonkey, aucun service anti-captcha tiers. C'est le point de positionnement central. L'utilisateur cible est donc un développeur Python qui automatise des parcours navigateur avec Playwright et qui refuse de payer à la requête ou d'envoyer ses images à un intermédiaire.

Le revers de cette indépendance est assumé : il faut faire tourner l'inférence soi-même, ce qui suppose des dépendances ONNX et un temps de calcul local que la documentation ne quantifie nulle part.

Comment l'inférence est répartie entre les modèles

L'architecture visible dans le README est un routage par type de défi. Le type image_label_binary part sur un ResNet exporté en ONNX pour de la classification. Le type image_label_area_select en mode point utilise un YOLOv8 ONNX en détection. Le même type en mode bounding box utilise un YOLOv8 ONNX en segmentation, et la colonne Agent Capability indique un tiret pour cette ligne, ce qui suggère que le chemin agentique n'est pas câblé pour ce cas. Le type image_label_multiple_choice s'appuie sur un ViT ONNX en zero-shot, également sans coche côté agent. Le type image_drag_drop utilise une chaîne de raisonnement spatial, décrite comme Spatial Chain-of-Thought, et porte la coche agent.

Les ressources sont présentées comme pluggables. Le tableau Advanced Task mentionne un Rank.Strategy adossé à un nested-model-zoo, un mécanisme d'auto-supervision basé sur CLIP-ViT, et un Agentic Workflow confié à un modèle multimodal. Le README cite Gemini dans ses références, aux côtés de Playwright, MCP et A2A. Ces citations indiquent des inspirations ou des intégrations possibles, pas une liste de fournisseurs supportés, et le dépôt ne détaille pas la sélection du modèle à l'exécution.

C'est là que la documentation devient insuffisante pour un évaluateur sérieux. On sait quels modèles sont mobilisés par type de défi, on ne sait pas comment le routage est déclenché, ni comment un échec de classification est détecté avant de soumettre la réponse.

Installation et clés de configuration réellement documentées

Le README ne fournit aucune commande d'installation. Aucun pip install, aucun extrait de configuration, aucune variable d'environnement n'apparaît dans le matériel fourni. La seule trace d'un chemin d'exécution est le badge PyPI en tête de dépôt, qui implique une publication sous le nom hcaptcha-challenger, et la présence d'une release taguée model servant de dépôt de poids.

Autrement dit, quiconque veut essayer doit se référer à la documentation liée, déclinée en anglais, chinois simplifié, russe et vietnamien, et non au README principal. C'est un choix de structuration fréquent dans les projets de cette taille, mais il a une conséquence pratique : le fichier que GitHub affiche en premier ne permet pas de démarrer. Un lecteur qui découvre le projet via la page d'accueil ne peut pas distinguer les prérequis réels (version de Python, backend ONNX, navigateur Playwright installé) des dépendances optionnelles liées au workflow agentique.

Je considère cela comme une faiblesse de premier contact, pas comme un défaut du moteur. La documentation multilingue existe et le dépôt la référence explicitement, mais elle reste hors du périmètre de ce que je peux vérifier ici.

Le workflow agentique et ce qu'il implique en ressources

Le tableau Workflow du README décrit une chaîne d'outils qui dépasse le solveur lui-même. Deux workflows GitHub Actions sont nommés : ci: sentinel et ci: collector. Le premier évoque une surveillance de la disponibilité ou de l'évolution des défis, le second une collecte d'images. Les jeux de données sont annoncés comme hébergés sur Roboflow et sur un dépôt public d'archives, avec un lien vers un projet séparé nommé hcaptcha-whistleblower.

L'entraînement est externalisé dans des notebooks Colab, un pour ResNet, un pour YOLOv8, référencés depuis un dépôt distinct, hcaptcha-model-factory. Les modèles produits sont ensuite publiés via une release taguée model. Cette séparation entre le code du solveur et la fabrique de modèles est saine sur le plan de l'organisation : elle permet de reconstruire les poids sans toucher au code d'orchestration.

Elle crée en revanche une dépendance à des ressources externes. Si les images d'entraînement ou les notebooks disparaissent, le code reste exécutable avec les poids existants, mais la capacité à réentraîner sur de nouveaux types de défis se perd. Le README ne décrit pas de procédure de repli.

Les limites que le projet ne masque pas, et celles qu'il tait

Le tableau des fonctionnalités est honnête sur un point : deux lignes sur cinq n'ont pas de coche dans la colonne Agent Capability. Le mode bounding box et le choix multiple ne bénéficient donc pas du chemin agentique, alors que le point, le binaire et le glisser-déposer en bénéficient. Un utilisateur qui rencontre un défi de type rectangle à tracer se retrouve sur un chemin moins outillé, sans que le README explique ce que cela change en taux de réussite.

La deuxième limite est structurelle. Le projet dépend de Playwright pour piloter un navigateur, et Playwright laisse des empreintes détectables. Le README renvoie d'ailleurs vers undetected-playwright, un projet séparé du même auteur, ce qui revient à reconnaître que le pilotage standard ne suffit pas toujours. Résoudre le défi visuel ne sert à rien si le navigateur est identifié comme automatisé en amont.

Troisième point, l'absence de toute mesure publiée. Ni latence, ni taux de succès par type de défi, ni consommation mémoire des modèles ONNX. Pour un composant qui s'insère dans un parcours d'automatisation, c'est une inconnue qui compte, et le README ne permet pas de la lever.

Ce qui distingue l'approche d'un service anti-captcha

La comparaison la plus directe est celle d'un service anti-captcha à l'API, du type 2Captcha ou CapMonster. Ces services reçoivent une image ou une URL de page, et renvoient un jeton. Le coût est proportionnel au volume, la latence dépend de la file d'attente côté fournisseur, et les images sortent de votre infrastructure.

hcaptcha-challenger prend le chemin inverse sur les trois axes. Rien ne sort : les images sont traitées par des modèles ONNX locaux, et le workflow agentique, quand il est activé, appelle un modèle multimodal dont le fournisseur n'est pas verrouillé dans le matériel fourni. Le coût marginal par résolution tombe à celui du calcul local, mais le coût d'entrée monte : il faut installer les dépendances, télécharger les poids depuis la release model, et accepter de maintenir cette pile.

La différence de nature est là. Un service externe vend une disponibilité et une mise à jour continue contre un paiement récurrent. hcaptcha-challenger vend un contrôle total contre une charge de maintenance, avec des modèles qu'il faut réentraîner quand hCaptcha fait évoluer ses défis. Le projet fournit les notebooks pour cela, ce qui est cohérent, mais cela reste un travail à votre charge.

Licence, maintenance et coût de mise à jour

Le dépôt est publié sous GPL-3.0, un choix qui n'est pas anodin. Si vous intégrez hcaptcha-challenger dans un produit distribué, la licence implique que le code dérivé soit distribué sous les mêmes termes. Pour un usage interne, une chaîne de test privée ou un script non distribué, la contrainte ne se déclenche pas de la même manière. Je ne donne pas d'avis juridique : faites relire votre cas d'usage si le code part chez un client.

Sur la maintenance, les faits disponibles sont les suivants : la dernière poussée sur main date du 15 août 2026, la dernière release publiée est v0.19.0 du 5 janvier 2026, précédée de v0.18.13 en octobre 2025 et v0.18.12 quelques jours plus tôt. Le rythme de publication est irrégulier, avec des correctifs rapprochés puis des mois sans version. Le dépôt n'est pas archivé.

Le coût de mise à jour ne se limite pas au code. Les poids sont distribués hors du paquet, dans une release dédiée, et les notebooks d'entraînement vivent dans un autre dépôt. Une mise à niveau implique donc de vérifier la compatibilité entre la version du paquet, celle des fichiers ONNX et celle des notebooks, sans qu'aucun mécanisme de versionnement croisé ne soit décrit dans le README. C'est le principal coût caché du projet.

Conclusion éditoriale

À adopter si vous automatisez des parcours de test sur des pages protégées par hCaptcha et que vous acceptez la contrainte GPL-3.0 sur du code Python. À éviter si votre cible est un site tiers sans mandat écrit, ou si vous avez besoin d'un support commercial et d'une API stable. Avant tout déploiement, vérifiez la version publiée sur PyPI, la présence des fichiers ONNX dans la release taguée model, et le contenu de la variable d'environnement qui alimente le workflow agentique, car la documentation publique reste mince sur ce dernier point.

Sources officielles

1. Issues
2. License: GPL-3.0
3. QIN2DIM/hcaptcha-challenger on GitHub
4. README
5. Releases