Scrapers IA hors de contrôle : comment protéger votre site en 2026

Le 10 juillet 2026, le rédacteur en chef de LWN.net, Jonathan Corbet, publie un bilan sans ambiguïté : un an après un premier article d'alerte sur le pillage des sites par les robots d'entraînement IA, « le problème continue de grandir ». LWN vient d'essuyer, selon ses propres mots, l'attaque de scraping la plus lourde jamais subie par le site. Ses défenses ont tenu, mais l'anecdote illustre une tendance de fond que tout site web français, PME comprise, doit désormais anticiper.

Pour qui découvre le sujet : depuis l'explosion des grands modèles de langage, des armées de robots parcourent le web pour aspirer du contenu servant à l'entraînement (ou au fine-tuning) de modèles IA. Le phénomène n'est pas nouveau, mais son échelle et sa sophistication ont changé de dimension en un an.

Le trafic ne vient plus d'un botnet, il vient de votre voisin

Le point le plus frappant du constat de LWN : les attaques ne proviennent plus d'un pool d'adresses IP identifiable. Il est courant d'observer des requêtes coordonnées venant de millions d'adresses IP uniques en quelques heures, chacune ne sollicitant le site que deux ou trois fois. Le user-agent est falsifié pour ressembler à un navigateur humain classique. Résultat : le temps qu'un site identifie un comportement suspect (pas de chargement d'images ni de CSS, par exemple), l'adresse en question a déjà disparu du trafic. Bloquer une IP a posteriori ne sert plus à rien.

Ce trafic provient majoritairement de réseaux résidentiels et mobiles, pilotés par des noeuds de commande centralisés. Un logiciel installé sur des appareils ordinaires (téléphones, box, objets connectés) reçoit des ordres, va chercher des pages web sur commande, et renvoie les données au contrôleur. Le tout, souvent, à l'insu total du propriétaire de l'appareil. C'est ce qu'on appelle les « proxies résidentiels ».

Deux familles d'opérateurs, un même effet

LWN distingue deux profils. D'un côté, des réseaux purement criminels, construits sur des appareils infectés par des malwares. Début 2026, Google a démantelé un réseau de ce type baptisé IPIDEA, ce qui a provoqué une baisse nette et mesurable du trafic scrapeur sur LWN pendant quelques mois, avant que l'accalmie ne cesse. Plus récemment, ce sont les box de streaming média qui sont identifiées comme un vecteur majeur, parfois compromises dès la fabrication, parfois simplement mal sécurisées.

De l'autre côté, des sociétés qui opèrent à visage plus ou moins découvert, en se présentant comme des fournisseurs d'IP « éthiquement sourcées ». Bright Data en est l'exemple le plus cité par LWN : l'entreprise propose notamment un service de VPN gratuit, où l'utilisateur accepte en échange de faire transiter du trafic tiers par son appareil, devenant ainsi un noeud du réseau de proxies résidentiels de la société. De nombreux autres acteurs proposent des SDK similaires à intégrer dans des applications mobiles, rémunérant les développeurs pour détourner la connexion de leurs utilisateurs.

Qui commandite ces attaques reste flou. LWN souligne qu'aucune preuve ne relie directement les grandes entreprises d'IA « frontières » à ces réseaux : leur propre trafic de scraping, lui, s'identifie clairement via le user-agent et respecte généralement le fichier robots.txt. L'hypothèse la plus probable est celle d'une multitude d'acteurs moins visibles : startups qui entraînent des modèles concurrents, agences gouvernementales, voire organisations criminelles, tous engagés dans une course aux données d'entraînement.

Le blocage par IP est mort, place aux nouvelles défenses

Face à ce constat, les opérateurs de sites ont dû changer de stratégie. Des outils comme Anubis imposent une preuve de travail (proof of work) au navigateur avant de servir la page, ce qui ralentit un scraper automatisé sans bloquer un humain. D'autres s'appuient sur des services commerciaux avec bouton « prouvez que vous êtes humain », des CAPTCHA de plus en plus créatifs (repérer des lampadaires à LED, assembler un puzzle, fredonner un air), ou placent une partie de leurs contenus derrière un mur de connexion ou un paywall. Certains vont plus loin avec des outils de « empoisonnement » de données comme iocaine, qui servent délibérément du contenu généré pour polluer les jeux de données des scrapeurs.

LWN elle-même a choisi de ne pas déployer Anubis, jugeant que le délai imposé aux lecteurs légitimes n'en vaut pas la peine, et que les scrapeurs finiront de toute façon par le contourner : le site rapporte déjà des indices en ce sens. La rédaction a plutôt misé sur l'optimisation agressive des pages les plus coûteuses en ressources et sur des mesures qui ne s'appliquent qu'aux visiteurs anonymes, laissant les utilisateurs connectés totalement épargnés.

Check-list : protéger un site français du déluge de bots IA

Pour un site vitrine, un e-commerce ou un blog édité depuis la France, quelques mesures concrètes, du plus simple au plus poussé :

• Un robots.txt à jour, mais sans illusion. Il freine les acteurs qui jouent le jeu (grands modèles frontières), pas les réseaux de proxies résidentiels qui l'ignorent superbement. Utile quand même, gratuit, à faire en premier.
• Rate limiting au niveau du reverse proxy. Nginx, Cloudflare, ou votre CDN : limitez le nombre de requêtes par fenêtre de temps sur les routes coûteuses (recherche, pagination profonde, export), pas seulement par IP puisque l'adresse change à chaque requête.
• Mise en cache agressive des pages publiques. Une bonne partie du coût d'une attaque de scraping vient de requêtes qui régénèrent des pages dynamiques inutilement. Un cache HTTP correctement configuré absorbe l'essentiel du choc.
• Surveillance des schémas de trafic, pas seulement du volume. Des pics de requêtes qui ne chargent ni images ni CSS, ou qui parcourent méthodiquement chaque URL d'un sitemap, sont un signal bien plus fiable qu'un seuil de requêtes par seconde.
• Une preuve de travail en dernier recours. Des outils comme Anubis existent pour les sites déjà submergés, avec le compromis assumé d'un léger délai pour les visiteurs légitimes.
• Éviter la dépendance à un seul allowlist. Autoriser explicitement un moteur de recherche dominant pour « sauver » votre trafic revient à renforcer sa position, au détriment d'alternatives. LWN le souligne : ce choix mérite réflexion.

Notre lecture chez CZSyn

Ce que décrit LWN, nous le voyons directement dans les logs de plusieurs sites clients hébergés depuis Marseille : des pics de trafic soudains, aucune conversion, un serveur qui rame pour des visiteurs qui n'existent pas vraiment. Pour une PME française, l'enjeu n'est pas philosophique, il est budgétaire : chaque requête absorbée par un scraper est une requête de bande passante, de CPU, parfois de facturation cloud à l'usage, qui ne rapporte rien.

Notre recommandation concrète : ne pas attendre d'être submergé pour agir. La mise en cache et le rate limiting côté reverse proxy coûtent une demi-journée de configuration et absorbent déjà la majorité des attaques peu sophistiquées. Les mesures plus lourdes (preuve de travail, pièges à données) se justifient surtout pour les sites à fort trafic ou à contenu à forte valeur, là où le calcul coût-bénéfice change. Dans tous les cas, la vigilance doit devenir une routine d'exploitation, au même titre que la sauvegarde ou la surveillance de la disponibilité.

Sources primaires

• Jonathan Corbet, LWN.net, « An update on the scraper situation », 10 juillet 2026.
• Projet Anubis (Techaro), anubis.techaro.lol, documentation officielle de l'outil de preuve de travail anti-scraper.
• Google Search Central, « Introduction à robots.txt », documentation officielle.