Blog de développement

Ce billet raconte la construction d'un pipeline de résolution automatique d'un CAPTCHA audio en français, à base de Whisper et de Playwright. Ce n'est pas un billet théorique : les chiffres présentés sont mesurés sur une soixantaine de cas réels. Le billet est aussi l'occasion de mettre en perspective les résultats avec une étude académique récente sur le même sujet — et de noter quelques différences qui méritent discussion.

1. Le problème posé

Certains portails administratifs français utilisent des CAPTCHA de type « saisie de caractères » — une image distorc distordue accompagnée d'une piste audio. L'audio est synthétique, en français, et énonce des lettres et des chiffres un à un. L'objectif est d'automatiser complètement la résolution : extraire l'audio depuis la page, le transcrire, soumettre le code, et détecter si l'authentification a réussi.

La contrainte principale est que l'audio est en français synthétique — pas en anglais. Ce point, anodin en apparence, a des conséquences importantes sur le choix du modèle et sur les confusions phonétiques observées.

2. Architecture du pipeline

Le pipeline est entièrement en Python 3.11 sous Windows, orchestré par un script principal et lancé depuis un fichier .bat. Les grandes étapes sont :

1. Chargement de la page via Playwright (Chromium headless=False), avec retry x5 sur domcontentloaded en cas d'absence du CAPTCHA dans le HTML.
2. Extraction de l'audio : l'image et le fichier WAV sont encodés en base64 directement dans le HTML — pas d'appel réseau séparé, pas de cache à intercepter.
3. Transcription Whisper : le WAV est décodé, écrit sur disque et passé à whisper.load_model("small") avec language='fr'.
4. Nettoyage : suppression des espaces, conversion en majuscules, détection des hallucinations (caractère répété quatre fois ou plus).
5. Soumission via press_sequentially() (le page.fill() standard étant incompatible avec ce formulaire).
6. Détection du résultat : le serveur renvoie un 302 vers une URL invalide en cas de succès — bug de redirect connu et contourné par navigation manuelle vers la page cible.

Tous les résultats sont enregistrés dans un CSV horodaté et dans un rapport texte par tentative, ce qui permet une analyse post-hoc. Le navigateur Playwright reste ouvert sur la page de travail après un succès, ce qui permet une confirmation visuelle avant de passer à la suite.

3. Résultats mesurés

Sur 66 tests (dont une trentaine en « phase corrigée » après résolution des bugs techniques), les chiffres stabilisés sont :

• Taux de transcription correcte (Whisper = code attendu) : 68 %
• Taux de succès par tentative de soumission : 58 %
• Taux cumulé sur 3 tentatives : 93 %
• Taux cumulé sur 5 tentatives : 99 %
• Durée moyenne de transcription Whisper small : 22 s
• Durée totale par tentative (chargement + transcription + soumission) : 35 s
• Hallucinations détectées : 1 sur 66 (caractère répété en boucle, bruit de fond)

L'écart entre 68 % de transcription correcte et 58 % de succès s'explique par les ambiguités phonétiques : Whisper transcrit fidèlement ce qu'il entend, mais ce qu'il entend est ambigu en français synthétique. Le code soumis est phonétiquement plausible mais pas lexicalement identique au code attendu.

4. Confusions phonétiques en français

C'est le point le plus instructif de l'expérience. En français, certaines lettres sont quasiment homophones lorsqu'elles sont énoncées isolément par une voix synthétique :

• B / P / V : « bé », « pé », « vé » — triplet confirmé sur plusieurs occurrences.
• D / V : « dé » / « vé » — confirmé.
• L / F : « elle » / « effe » — confirmé (2 occurrences).
• Z / 7 : « zède » / « sept » — confirmé (2 occurrences).
• L / M, D / T : observés une fois chacun, à confirmer.

Ces confusions sont spécifiques au français. Un modèle entraîné majoritairement sur de l'anglais — comme Whisper tiny.en ou base.en utilisés dans l'étude académique — ne rencontrera pas les mêmes ambiguïtés, car les phonèmes concernés n'ont pas les mêmes voisinages sonores en anglais.

5. Discussion : l'étude de Grenoble INP et ses limites

L'étude d'Aubry et al. (EuroS&PW 2025) compare six modèles ASR sur le CAPTCHA audio de Google reCAPTCHA v2 en anglais. Les résultats sont impressionnants : les modèles cloud (Google Speech-to-Text, Azure, Deepgram) atteignent 99 % de précision, et Whisper tiny.en atteint 97 %. La résolution se fait en moins de 2 secondes pour les modèles cloud.

Ces chiffres sont corrects, mais leur contexte est très spécifique : le CAPTCHA de Google en anglais, où l'audio énonce des chiffres seulement (0–9), avec un vocabulaire de 10 tokens. Dans ce cas, même un modèle ASR médiocre obtient de bons résultats par élimination. La conclusion « les CAPTCHA audio sont trivialement cassables » est justifiée pour ce cas précis, mais elle ne se généralise pas sans précaution.

Le cas traité ici est différent sur plusieurs points :

• L'audio est en français, pas en anglais.
• Le code contient des lettres et des chiffres mélangés (6 à 9 caractères), contre des chiffres seuls chez Google.
• Le vocabulaire effectif est de 36 tokens, ce qui rend le décodage statistiquement plus difficile.
• Les modèles cloud ne sont pas utilisables ici : pas d'API publique, pas de coût variable acceptable, et contrainte de traitement local pour des raisons de confidentialité.

L'étude évalue Whisper uniquement dans ses versions tiny.en et base.en, c'est-à-dire les variantes monolingues anglais. En français, le modèle adapté est Whisper small (variante multilingue, 244 M paramètres). C'est ce qui est utilisé ici, avec language='fr' et fp16=False (CPU uniquement, sans GPU).

6. Ce que l'étude ne dit pas

L'étude est rigoureuse dans son périmètre, mais elle laisse de côté plusieurs aspects qui comptent en pratique.

Les bugs côté serveur. Dans le cas étudié ici, le principal obstacle n'était pas la précision ASR : c'était un bug de redirection HTTP côté serveur qui faisait interpréter tous les succès comme des échecs. L'étude suppose que la chaîne POST → valider → page suivante est correcte, ce qui n'est pas toujours le cas. L'analyse du HAR Playwright a été déterminante pour diagnostiquer ce problème.

La robustesse en boucle. L'étude mesure la précision par tentative individuelle. En pratique, le métrique pertinent est le taux de succès sur N tentatives. Avec 58 % par tentative, cinq essais donnent 99 % de réussite cumulée — largement suffisant pour un usage en production, sans qu'il soit nécessaire d'atteindre 97 %.

La performance CPU sans GPU. Les temps rapportés dans l'étude (1–2 s pour Whisper) supposent des ressources de type laptop récent. Sur un serveur domestique sans GPU dédié, Whisper small prend 20–25 s par transcription. C'est acceptable pour un usage occasionnel, mais il faut le mentionner.

7. Ce que l'étude confirme

Malgré ces nuances, les conclusions générales de l'étude sont confirmées par l'expérience pratique :

• Whisper est le meilleur choix local, sans abonnement ni API externe.
• Les CAPTCHA audio sont vulnérables aux ASR modernes, même sans GPU et même en français.
• La combinaison Playwright + Whisper est déployable par un développeur seul, sur du matériel standard, en quelques jours de travail.
• L'étude mentionne que Whisper tiny.en atteint 97 % sur reCAPTCHA anglais ; Whisper small atteint 68 % sur un CAPTCHA français alphanumériques — l'écart s'explique entièrement par le changement de langue et la complexité du vocabulaire cible.

Bilan

Ce projet illustre que la résolution automatique d'un CAPTCHA audio n'est pas un problème de modèle ASR : c'est un problème d'intégration. Le choix de Playwright pour la navigation, la gestion des bugs de redirection HTTP, l'analyse HAR, la détection fine des statuts (succès, échec de code, erreur technique), et le pilotage en boucle ont été aussi déterminants que la qualité de la transcription elle-même.

La prochaine étape est d'utiliser la session authentifiée obtenue pour automatiser des recherches dans l'interface — ce qui était l'objectif initial. Le CAPTCHA était l'obstacle, pas la destination.