Selenium Wire + CaptchaAI : interception de requêtes en QA

Périmètre sûr : ce guide s'applique exclusivement à 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 neutralisation de protections, ni l'évasion d'anti-bot.

Quand un test de préproduction échoue « à cause du CAPTCHA », le DOM ne vous dira jamais pourquoi : il vous montre un widget, pas la séquence d'appels qui l'a produit. Selenium Wire répond à cette question en gardant en mémoire chaque requête HTTP émise par le navigateur piloté, ce qui vous permet d'identifier le type de défi réellement chargé, de mesurer le temps d'obtention du token CaptchaAI et de comparer une exécution qui passe avec une exécution qui casse.

La boucle est courte : capturer le trafic, en extraire les signaux utiles, instrumenter les appels à l'API, puis figer le tout dans une liste de contrôle avant de brancher la suite sur votre intégration continue.

Pourquoi diagnostiquer par le réseau plutôt que par le DOM

Un défi CAPTCHA se matérialise dans une iframe, souvent injectée après plusieurs allers-retours AJAX : deux exécutions apparemment identiques peuvent charger deux widgets différents. En lisant le trafic, vous travaillez sur des faits datés et ordonnés plutôt que sur un instantané du DOM.

Trois signaux valent le détour :

• L'ordre des requêtes. Le formulaire est-il soumis avant que le token ne soit disponible ? C'est la cause la plus fréquente d'un échec intermittent en CI.
• Les codes retour. Un 403 sur une ressource du widget et un 200 sur la soumission ne racontent pas la même histoire qu'un 200 partout suivi d'un rejet applicatif.
• Les en-têtes. Accept-Language, cookies de session et en-têtes d'environnement expliquent souvent les écarts entre votre poste et le runner CI.

Lire le trafic capturé avec driver.requests

Selenium Wire s'utilise comme Selenium : vous remplacez l'import, le reste de votre suite ne bouge pas. Après navigation, driver.requests expose une liste ordonnée d'objets Python que vous pouvez filtrer, compter et comparer d'une exécution à l'autre.

Exemple Python :

from seleniumwire import webdriver
driver = webdriver.Chrome()
driver.get(QA_BASE_URL + '/protected')
for req in driver.requests:
    print(req.method, req.url, req.response.status_code if req.response else 'pending')

En pratique, filtrez sur les hôtes qui vous intéressent avant d'imprimer quoi que ce soit : une page moderne génère plusieurs centaines de requêtes et le bruit noie le signal. Videz aussi la liste entre deux scénarios (del driver.requests) pour éviter que la mémoire du runner ne gonfle sur une suite longue.

Ce que Selenium Wire ne change pas

Selenium Wire observe ; il ne rend pas votre environnement plus permissif et ne modifie pas le comportement réel des protections. C'est précisément l'intérêt en QA : le diagnostic reste fidèle à ce que verra la production. L'interception sert à comprendre la requête finale, jamais à la maquiller.

Instrumenter les appels CaptchaAI

Quel que soit le langage de votre suite, les appels de résolution méritent la même instrumentation que n'importe quelle dépendance externe. Quatre métriques suffisent à rendre un incident lisible : la durée totale d'obtention du token, le code retour HTTP, l'identifiant de tâche renvoyé par in.php et le nombre de tâches en attente côté suite.

Séparez les journaux par environnement (développement, préproduction, production) et propagez un identifiant de corrélation dans votre traçage distribué, par exemple avec OpenTelemetry. Vous rejouez alors un scénario complet à partir d'un seul identifiant, sans reconstituer le contexte à la main. Ajoutez un retry avec backoff exponentiel borné — trois tentatives, doublement du délai, plafond à 30 s — pour absorber les erreurs transitoires sans masquer une panne réelle.

Côté capacité, raisonnez en threads et non en volume : un thread correspond à une résolution en cours. Une suite de tests nocturne qui lance quelques scénarios en parallèle tient dans le plan BASIC ($15/mois, 5 threads) ; une matrice de navigateurs qui déclenche des dizaines de scénarios simultanés justifie STANDARD ($30/mois, 15 threads). La facturation est en dollars US.

Exemple : une préproduction hébergée en Europe

Prenons une équipe QA d'un éditeur SaaS français dont la préproduction tourne chez OVHcloud et dont les runners GitLab sont dans la région AWS eu-west-3 (Paris). Le scénario d'inscription passe en local et échoue une fois sur cinq en CI. La capture Selenium Wire montre la soumission du formulaire environ deux secondes avant la réponse de res.php : le test n'attendait pas le token, et le poste de développement, plus lent à enchaîner les clics, masquait le problème.

Deux corrections suivent : une attente explicite sur la présence du token, et un seuil d'alerte sur le temps de résolution mesuré par type de défi — Cloudflare Turnstile est annoncé sous 10 s, GeeTest v3 sous 12 s, ce qui donne des bornes réalistes pour vos alertes. Dernier point, non technique : les traces réseau contiennent des adresses e-mail et des identifiants de session de jeux de test, donc appliquez la même rétention et la même minimisation que sur vos autres journaux, conformément à vos obligations RGPD.

Liste de contrôle avant intégration en CI

• Le périmètre est strictement limité à vos propres applications ou à des sources autorisées.

• La clé CaptchaAI vit dans un secret CI ou un coffre, jamais dans le dépôt.

• Le temps de résolution et le code retour sont tracés à chaque exécution, avec l'identifiant de tâche.

• Un retry idempotent avec backoff borné couvre les erreurs transitoires.

• Les captures réseau sont purgées entre les scénarios et leur rétention est définie.

• Les tests sont rejouables à l'identique depuis l'intégration continue.

FAQ

Selenium Wire ralentit-il mes tests ?

Un peu, oui : tout le trafic transite par un proxy local et chaque réponse est conservée en mémoire. L'impact reste modéré si vous excluez les hôtes inutiles et videz driver.requests entre les scénarios. Sur une suite longue, c'est la mémoire du runner qui pose problème avant la durée d'exécution.

Comment savoir quel type de défi est réellement chargé ?

Filtrez les URL capturées sur les hôtes des fournisseurs et lisez les paramètres de l'iframe : la clé du site y figure généralement. Cette lecture est plus fiable qu'un sélecteur DOM, qui dépend du moment où vous l'interrogez.

Quels types de CAPTCHA puis-je couvrir dans ces tests ?

reCAPTCHA v2 et v3, Cloudflare Turnstile, Cloudflare Challenge, GeeTest v3, ainsi que les CAPTCHA image, texte et grilles d'images. hCaptcha et FunCaptcha ne sont pas pris en charge, GeeTest v4 est à venir, et CaptchaFox, Friendly Captcha et Lemin sont en bêta.

Quelle capacité prévoir pour une suite de tests nocturne ?

Comptez un thread par scénario exécuté en parallèle, pas par test. Le plan BASIC ($15/mois, 5 threads) suffit à la plupart des suites de préproduction ; passez à un palier supérieur seulement si vos scénarios s'exécutent réellement en simultané.

Guides connexes

• Le démarrage rapide de l'API
• Tester les défis CAPTCHA en environnement autorisé
• Vérifier l'endpoint API depuis vos formulaires
• Brancher la résolution sur votre intégration continue
• Résoudre reCAPTCHA v2 via l'API
• Résoudre Cloudflare Turnstile via l'API

Instrumentez vos scénarios une fois, et chaque échec devient un journal lisible plutôt qu'une capture d'écran. – Obtenez votre clé CaptchaAI.