Comment fonctionnent les systèmes anti-bot

Quand un scraper renvoie une erreur 403 ou une page « Just a moment… » à la place du contenu attendu, ce n'est jamais le fruit du hasard. Un système anti-bot a observé la requête, l'a comparée à ce qu'il attend d'un vrai navigateur, et a repéré une incohérence. Ces systèmes ne posent pas une seule question, ils en empilent plusieurs. Voici les couches qu'ils traversent, dans l'ordre où elles interviennent.

Couche 1 : le réseau, avant même la requête

Tout commence par l'adresse IP. Avant de regarder ce que vous demandez, un serveur regarde d'où vous venez. Toutes les IP ne se valent pas, et une hiérarchie de confiance implicite s'est installée.

Mobile, puis résidentiel, puis datacenter : voilà l'ordre de confiance dans lequel une IP est jugée.

Une IP mobile (réseau d'un opérateur cellulaire) inspire le plus confiance, car des milliers d'abonnés partagent la même adresse, ce qui rend le blocage risqué. Une IP résidentielle (box internet d'un particulier) est jugée crédible, parce qu'un humain réel s'en sert. Une IP de datacenter (serveur loué chez un hébergeur) est immédiatement suspecte : très peu de vrais visiteurs naviguent depuis un centre de données. Le serveur identifie l'origine via le numéro de réseau (ASN) et le reverse DNS. À cela s'ajoute la limitation de débit : trop de requêtes depuis la même adresse, à une cadence trop régulière, et l'accès se ferme.

Couche 2 : la poignée de main TLS

C'est la couche la plus méconnue, et souvent la plus décisive. Avant tout échange de données en HTTPS, le client et le serveur négocient le chiffrement. Le tout premier message du client, appelé ClientHello, part en clair et décrit ses capacités : versions supportées, algorithmes de chiffrement, extensions, dans un ordre précis. Or cet ordre et ce contenu varient selon la bibliothèque logicielle utilisée.

On peut donc calculer une empreinte de cette poignée de main, connue sous les noms de JA3 puis de JA4. Le problème pour un scraper naïf est simple à énoncer :

Un client qui affirme être Chrome dans ses en-têtes, mais qui serre la main comme un script Python, se contredit lui-même.

Aucune modification d'en-tête ne masque cette contradiction, car elle se joue à un niveau plus bas que le HTTP. Nous détaillons ce mécanisme dans un article dédié à l'empreinte TLS.

Couche 3 : l'empreinte du navigateur

Une fois la connexion établie et une page chargée, un script JavaScript se met au travail. Il interroge des dizaines de propriétés du navigateur pour construire un identifiant stable, sans avoir besoin de cookie.

• Canvas et WebGL : le script demande de dessiner une image invisible, puis lit le résultat. Selon le processeur graphique, le pilote et les polices installées, le rendu varie très légèrement, mais de façon reproductible.
• Polices, résolution, fuseau horaire, langue : autant de petits signaux qui, combinés, deviennent presque uniques.
• Indices d'automatisation : la présence d'un drapeau comme navigator.webdriver, posé par les outils de pilotage, ou un rendu graphique purement logiciel, trahissent un navigateur piloté par un programme.

La force du système ne tient pas à un signal isolé, mais à leur cohérence. Un navigateur qui dit être Chrome sur Windows mais dont le rendu graphique ressemble à celui d'un serveur Linux sans écran, voilà une histoire qui ne tient pas debout.

Couche 4 : le comportement

Les moteurs les plus avancés ne se contentent pas de photographier le client, ils le regardent agir. Mouvements de souris, vitesse de défilement, rythme des clics, cadence des requêtes : tout est analysé en temps réel.

Un humain est irrégulier par nature. Sa souris suit des courbes, marque des hésitations, accélère puis ralentit. Un bot, lui, tend vers la perfection mécanique : trajectoires en ligne droite, intervalles parfaits à la milliseconde, ou tout simplement aucun mouvement du tout. Cette régularité est précisément ce qui le désigne.

Couche 5 : le challenge

Quand le doute subsiste, le système impose une épreuve. Elles ne se ressemblent pas toutes :

• Le score invisible : certains dispositifs, comme reCAPTCHA v3, ne montrent rien à l'utilisateur. Ils attribuent une note de confiance en arrière-plan et laissent le site décider du seuil.
• Le défi calculatoire : la page « Just a moment… » de Cloudflare, par exemple, fait résoudre au navigateur une série de petits problèmes en JavaScript, dont un calcul volontairement coûteux. Négligeable pour un vrai navigateur, ce coût devient prohibitif quand il faut le payer des millions de fois avec un parc de bots.
• Le puzzle visuel : la sélection d'images n'apparaît qu'en dernier recours, quand le score est vraiment bas.

Les grands éditeurs, et leurs signatures

Quelques acteurs dominent ce marché, chacun avec une approche propre. Ils laissent des traces reconnaissables, souvent sous forme de cookies.

• Cloudflare agit au plus près du visiteur, sur son réseau de diffusion mondial. Il pose un cookie __cf_bm pour son score de bot, et cf_clearance comme preuve qu'un challenge a été réussi. Ce dernier est lié à la fois à la session, au navigateur annoncé et à l'IP : changez l'un des trois, il devient invalide.
• DataDome, éditeur français, décide en quelques millisecondes à partir d'un modèle d'apprentissage combinant empreinte, comportement et réseau. Signature : le cookie datadome.
• Akamai s'appuie sur une télémétrie lourde collectée côté client. Son cookie _abck devient invalide à la moindre incohérence avec l'empreinte observée.
• HUMAN (anciennement PerimeterX) mise sur la biométrie comportementale et une intelligence partagée entre ses clients.
• Kasada sert un script fortement obscurci qui embarque sa propre machine virtuelle, et impose un coût de calcul par requête.
• Imperva, racheté par Thales en 2023, combine pare-feu applicatif et réseau de diffusion.

Pourquoi un simple proxy ne suffit jamais

C'est l'erreur la plus commune. Un proxy ne change qu'une seule chose : l'adresse IP. Il corrige la couche 1, et laisse intactes toutes les autres. Un scraper qui passe par une belle IP résidentielle mais qui serre la main en Python, sans exécuter le JavaScript et sans le moindre comportement crédible, se fait repérer dès la deuxième couche.

Pour accéder proprement à une donnée publique, il faut que toutes les couches racontent la même histoire : un vrai moteur de navigateur capable d'exécuter le JavaScript et les challenges, une IP cohérente avec le profil, et une parfaite concordance entre la poignée de main TLS, les en-têtes, les propriétés du navigateur et le comportement. C'est exactement ce travail d'orchestration que WyndPath prend en charge, dans le respect des règles publiées par les sites et de la limitation de débit.