Les équipes qui se défendent contre les bots et celles qui les conçoivent sont engagées dans une course aux armements au ralenti depuis une quinzaine d’années. La frontière s’est déplacée tous les quelques années, et chaque évolution a contraint les équipes data à investir différemment. Il vaut la peine de connaître la chronologie approximative, car l’état actuel des choses n’est pas évident de l’extérieur, et beaucoup de conseils que l’on trouve sur internet ont deux générations anti-bot de retard.
Génération 1 : listes de blocage d’IP et limites de débit
Les premières défenses étaient procédurales. Une requête arrivait, le serveur notait l’IP, et si cette IP faisait quelque chose d’ostensiblement mécanique - trop de requêtes par minute, une séquence trop prévisible, un User-Agent trop restreint - elle se retrouvait limitée en débit ou bannie purement et simplement. Des listes de plages d’IP de datacenters connus circulaient. Tout ce qui provenait d’AWS ou de DigitalOcean était traité avec méfiance.
C’était l’époque où la réponse à “comment scraper X” était presque toujours “utilise un proxy”. Plus précisément, un proxy de datacenter. Acheter un /24, le faire tourner, problème résolu.
Ça fonctionnait parce que les défenseurs n’avaient pas grand-chose d’autre.
Génération 2 : les CAPTCHAs et la taxe de friction utilisateur
Quand les défenses au niveau IP ont commencé à échouer, les défenseurs ont imposé des frictions à l’utilisateur. Les CAPTCHAs sont devenus universels - d’abord ceux avec correspondance d’images, puis reCAPTCHA, puis reCAPTCHA invisible, puis hCaptcha, Turnstile et Arkose.
Les CAPTCHAs fonctionnent, dans le sens où ils bloquent les scrapers naïfs. Ils fonctionnent aussi dans le sens où ils agacent suffisamment les vrais utilisateurs pour réduire les conversions de manière mesurable. La plupart des sites qui utilisaient des couches CAPTCHA agressives entre 2017 et 2020 ont depuis fait marche arrière, car le coût de la friction dépassait celui des bots.
Du côté des scrapers, les CAPTCHAs ont engendré toute une industrie de services de résolution avec intervention humaine. Payer quelques centimes par résolution, envoyer ses CAPTCHAs à un panel de travailleurs dans des zones géographiques à faible coût, récupérer le token, continuer à scraper. Pas élégant, mais ça fonctionnait.
Génération 3 : fingerprinting du navigateur et comportemental
La troisième génération est montée dans la pile. Les sites ont commencé à prendre l’empreinte du client lui-même - non plus seulement l’IP, mais le navigateur. Fingerprinting via Canvas, signatures WebGL, listes de polices, contexte audio, fuseau horaire, préférences de langue, dimensions d’écran, plugins disponibles, l’ordre dans lequel les chiffrements TLS étaient proposés lors du handshake (empreintes JA3 / JA4), le timing des mouvements de souris, la cadence des frappes au clavier.
Headless Chromium sans durcissement spécifique laisse fuir des dizaines de ces signaux. Les défenseurs ont construit des bibliothèques (Fingerprint.js, et divers équivalents commerciaux) qui évaluaient les requêtes sur cette surface et rejetaient tout ce qui semblait trop propre, trop mécanique, ou trop différent du navigateur d’un vrai utilisateur.
C’est à ce moment que le scraping est devenu difficile. Une IP résidentielle ne suffisait plus à elle seule. Il fallait piloter un vrai navigateur, ou un headless suffisamment bon avec des empreintes corrigées, et faire en sorte que son comportement paraisse naturel. Le proxy restait indispensable, mais il était devenu un composant parmi d’autres dans une pile, plutôt que la solution complète.
Génération 4 : réputation au niveau réseau
La frontière actuelle est la plus coûteuse pour tout le monde. Les défenseurs achètent désormais des données de réputation auprès de fournisseurs réseau comme Cloudflare, Akamai, et une douzaine de spécialistes plus petits. Chaque IP reçoit un score de réputation qui agrège des signaux provenant de millions de sites : cette IP a-t-elle été vue en train de se connecter à des comptes bancaires, de réaliser des processus de paiement, d’ouvrir Gmail normalement ? Ou a-t-elle été vue en train de frapper des endpoints de connexion selon des schémas qui suggèrent du credential stuffing, de poster des commentaires à des cadences mécaniques, de scraper des pages de tarification concurrentes à 3h du matin un mardi ?
Une IP de datacenter a, presque par définition, un historique réseau mince ou négatif. Elle n’a pas effectué d’actions humaines normales. Une IP résidentielle, en revanche, dispose de plusieurs années de trafic banal derrière elle - le foyer qu’elle dessert l’utilise pour Netflix, Steam, Zoom, la navigation ordinaire. C’est cette réputation qui protège les scrapers aujourd’hui.
Les proxies ISP occupent un milieu intéressant : ils sont émis par de vrais FAI résidentiels (donc le fournisseur en amont correspond à un bloc d’IP domestique), mais ils sont alloués à des datacenters et détenus de manière statique. Ils sont plus difficiles à détecter que les IP pures de datacenter, mais plus faciles que les résidentielles rotatives, et leur prix reflète cette position.
Ce que cela signifie pour les équipes data en 2026
Quelques constantes ont traversé les quatre générations et continueront de s’appliquer :
Le bon proxy est nécessaire mais pas suffisant. Une vraie IP résidentielle vous fait passer la barrière au niveau réseau. Ensuite, votre client, vos headers, votre empreinte TLS et vos schémas comportementaux doivent rester plausibles.
Le taux de blocage est la seule métrique qui compte. Pas la taille du pool, pas le nombre de pays, pas les fonctionnalités annoncées. Si vos scrapes renvoient du HTML propre à un coût acceptable, l’infrastructure fonctionne. Si ce n’est pas le cas, aucune promesse marketing ne vous aidera.
Le bon proxy dépend du workflow. La rotation par requête sur un grand pool résidentiel est adaptée aux jobs de surveillance de prix en éventail. Les sessions persistantes sur une seule IP résidentielle pendant dix minutes sont adaptées aux flux multi-pages. Les IP ISP fixes sont adaptées à la gestion de comptes et à tout workflow nécessitant la même identité sur des semaines ou des mois. N’utilisez pas un seul outil pour tous les cas.
Les systèmes anti-bot continueront de monter dans la pile. La prochaine couche sera probablement une analyse comportementale plus agressive à la périphérie - des classifieurs appris par machine qui examinent la forme des sessions sur plusieurs minutes, et non les caractéristiques d’une seule requête. C’est déjà en production sur les plus grands sites. La course aux armements des défenseurs s’intensifie, et le coût pour y rester aussi.
La conclusion honnête : quiconque vous dit que le scraping est “résolu” a tort. C’est un problème opérationnel, et c’est pour les opérations que vous payez. Les proxies résidentiels restent le fondement parce qu’ils sont encore le seul endroit où l’IP en amont porte le bon type d’historique. Tout le reste repose sur cette base.