Comment détecter le web scraping : journaux, recherches IP et angles morts

Une requête isolée d'un scraper n'est qu'un GET. Elle a un code de statut, un chemin et un User-Agent, comme toutes les autres lignes de votre journal. Le scraping n'apparaît qu'à travers des centaines de lignes et à l'échelle d'un réseau : un script Python sur un serveur cloud, un navigateur headless piloté par Puppeteer ou Playwright, un robot d'exploration d'entraînement d'IA, un robot SEO comme AhrefsBot, ou une API de scraping qui vend des proxys rotatifs au gigaoctet.

Nous avons soumis sept IP de type scraper à l'API GeoIPHub le 8 octobre 2026. Quatre robots d'exploration vérifiés (Googlebot, CCBot, ClaudeBot, AhrefsBot) provenaient tous de réseaux d'hébergement et ont obtenu allow. Un simple serveur cloud Linode a obtenu 10, également allow, tandis qu'un nœud de sortie Tor et un serveur VPN Mullvad ont tous deux obtenu 100, block. L'IP vous donne le réseau. Le verdict de scraping vient de vos journaux.

Ci-dessous, nous montrons comment détecter les bots de scraping dans un journal d'accès, nous retraçons une ligne de journal qui prétend être Googlebot, nous montrons où les données IP deviennent aveugles, et nous relions ce que vous trouvez aux actions autoriser, limiter le débit, vérifier ou bloquer. Si vous voulez d'abord les signaux IP un par un, notre article de référence couvre la détection des bots par IP, signal par signal ; cet article les applique au scraping.

Comment détecter le web scraping : débit, chemin, client et réseau

Pour détecter le web scraping, vérifiez quatre groupes de signaux : la vitesse à laquelle un client fait ses demandes (débit), ce qu'il demande et dans quel ordre (chemin), ce qu'il dit de lui-même (client), et d'où il se connecte (réseau). L'OWASP classe le scraping comme une menace automatisée à part entière, OAT-011, définie comme la collecte de « application content and/or other data for use elsewhere » (contenu applicatif et/ou autres données destinés à être utilisés ailleurs) (OWASP Automated Threats). Cette définition porte sur l'intention, que vous ne pouvez pas voir. Les quatre groupes sont ce que vous pouvez voir.

• Débit. Requêtes par minute par IP, et par réseau. Par réseau, nous entendons l'ASN ou, pour un regroupement plus fin, le /24 en IPv4 et le /64 en IPv6. Les scrapers tournent souvent à un débit constant jour et nuit ; les personnes arrivent par vagues et dorment.
• Chemin. Des URL de listes et de pagination parcourues dans l'ordre, un sitemap lu de haut en bas, uniquement des pages produits ou de prix, et aucune requête CSS, JavaScript ou image.
• Client. La revendication du User-Agent, un en-tête Accept-Language absent, aucun cookie conservé entre les requêtes, et des marqueurs d'automatisation. Dans le navigateur, navigator.webdriver vaut true lorsque Chrome tourne avec --headless ou --enable-automation (MDN), même si un scraper déterminé le neutralise. En périphérie, une empreinte TLS (JA3 ou JA4) révèle souvent une bibliothèque HTTP derrière un User-Agent qui prétend être Chrome.
• Réseau. Ce que renvoie une recherche IP : une IP de datacenter (hébergement), que l'API signale par detection.is_hosting, un robot d'exploration vérifié, Tor, un VPN ou un scanner.

La difficulté de la détection du web scraping, c'est que chaque signal a un jumeau innocent. Un CDN qui interroge votre origine, un outil de surveillance de disponibilité, un bureau derrière une seule adresse NAT et un lecteur RSS paraissent tous étranges sur un axe. Le scraping se démontre par des signaux qui concordent.

Comment savoir si votre site est scrapé : lisez d'abord vos journaux d'accès

Pour savoir si votre site est scrapé, regroupez vos journaux d'accès par réseau et cherchez les clients qui récupèrent de nombreuses pages, les récupèrent dans l'ordre et ne chargent jamais les ressources qu'un navigateur chargerait. Les signes extérieurs arrivent souvent en premier : vos descriptions de produits ou vos prix apparaissent sur un autre site, ou la bande passante et le coût des serveurs augmentent sur les pages de listes alors que les conversions stagnent. Pour vérifier depuis l'extérieur, recherchez entre guillemets une phrase caractéristique de votre page, et surveillez si vos prix réapparaissent sur des sites agrégateurs quelques heures après un changement. Les journaux vous disent qui l'a fait.

Voici à quoi cela ressemble dans un journal d'accès au format combiné. Ce sont des valeurs illustratives, pas du trafic réel. 45.33.32.156 est l'hôte de test public de Nmap chez Linode, et il n'a pas envoyé ces requêtes ; il représente « un serveur cloud », car nous ne pouvons pas publier l'IP d'un vrai visiteur.

Trois choses sautent aux yeux. Les pages se suivent une à une, à 1 ou 2 secondes d'intervalle, à 3 heures du matin. Il n'y a aucun référent et pas une seule requête .css ou .js entre elles. Et le client se présente comme Googlebot, ce que les sections suivantes vérifient.

Vous n'avez pas besoin d'une plateforme de journaux pour trouver des clients de ce genre. Ces commandes d'une ligne fonctionnent sur un journal combiné standard ; lancez-les d'abord sur une heure chargée :

Analysez le résultat à l'aide de cette liste :

• Pages visitées. Les clients les plus actifs se concentrent-ils sur les listes, les prix, les résultats de recherche ou le sitemap ?
• Débit par IP, puis par réseau. Après avoir enrichi les IP, additionnez les requêtes par ASN ; 50 adresses d'hébergement d'un même ASN qui parcourent les mêmes pages relèvent probablement d'un seul acteur.
• Profondeur de session. Des centaines de pages par session, sans utilisation du panier, de la connexion ni du champ de recherche.
• Ordre. Des URL de pagination ou de sitemap récupérées en séquence.
• Ressources. HTML uniquement, sans CSS, JavaScript, polices ni images.
• Revendications de robot d'exploration. Chaque User-Agent Googlebot, Bingbot, GPTBot ou ClaudeBot va sur une liste à vérifier par IP.
• Marqueurs d'automatisation. Des User-Agents de bibliothèques (python-requests, curl, Go-http-client) et des indices de navigateur headless.

Adresses IP de scrapers : ce que renvoient de vraies recherches GeoIPHub

Les adresses IP de scrapers se répartissent en quelques classes de réseau, et une recherche vous indique quelle classe vous observez, pas si la requête provenait d'un scraper. Dans nos recherches GeoIPHub, les robots d'exploration vérifiés ont obtenu de 0 à 23 (allow) ; les sorties Tor et VPN ont obtenu 100 (block). Nous avons effectué une recherche anonyme par classe le 8 octobre 2026, à quatre secondes d'intervalle :

Ce sont des recherches ponctuelles effectuées un seul jour, pas un banc d'essai, et les valeurs évoluent à mesure que les plages changent. Une lacune connue : no_ptr_datacenter sur les lignes Googlebot et AhrefsBot vient de nos données, pas des leurs. L'API ne stocke pas d'enregistrement PTR pour certaines plages de robots d'exploration alors que le DNS inverse se résout (192.178.4.40 se résout en crawl-192-178-4-40.googlebot.com). Pour l'IP de ClaudeBot, le signal est exact : elle n'a pas de DNS inverse.

Voici la réponse pour CCBot, abrégée mais avec les valeurs réelles et l'imbrication d'origine :

Le robot d'exploration de Common Crawl tourne sur AWS, et obtient pourtant 0. L'IP se trouve dans 18.97.14.80/29, une plage que Common Crawl publie dans son fichier ccbot.json, et l'ajustement pour robot d'exploration vérifié de notre scoring (−28,5) annule le signal de datacenter. GeoIPHub consulte ainsi 19 flux officiels de plages de robots d'exploration, dont ceux de Google, Bing, OpenAI, Anthropic, Common Crawl et Ahrefs. Accepter qu'un robot d'exploration dont les données alimentent des modèles d'IA, comme CCBot ou GPTBot, lise vos pages est une question de politique. La recherche ne fait qu'établir de qui il s'agit.

AhrefsBot a été la surprise. Il est revenu vérifié (5.39.1.230 se trouve dans 5.39.1.224/27 dans les plages de robots d'exploration publiées par Ahrefs), mais aussi avec is_abusive: true et abusive_listed dans les méthodes, pour un score de 23, toujours allow. Nous n'avons pas retrouvé quelle liste l'a signalé. La leçon reste valable dans tous les cas : « vérifié » vous dit qui est un robot d'exploration, pas si vous en voulez. Un robot SEO qui cartographie votre site pour le rapport de backlinks d'un concurrent fait toujours du scraping, simplement déclaré.

L'usurpation de robots d'exploration dans les journaux de scraping : une ligne retracée

Une requête qui indique Googlebot dans son User-Agent mais provient d'un serveur cloud est une revendication non vérifiée. GeoIPHub peut vous dire que l'IP ne fait pas partie d'une plage de Google, mais la comparaison avec le User-Agent se fait dans votre code, car la recherche ne voit jamais vos en-têtes. Prenez la quatrième ligne du journal illustratif : 45.33.32.156, GET /products?page=37, User-Agent Googlebot/2.1.

1. Recherchez l'IP. La vraie recherche a renvoyé l'ASN 63949, Akamai Connected Cloud (Linode), detection.is_hosting: true, threat.crawler.name: "none", verified: false, fraud_score 10, allow, avec les méthodes ["datacenter_ip"].
2. Comparez la revendication. Votre code compare l'identifiant du User-Agent à threat.crawler.verified et threat.crawler.name.
3. Décidez. Le UA dit Googlebot ; l'IP n'appartient à aucune plage de Google. Elle est donc « non vérifiée comme Googlebot ». Limitez son débit ou soumettez-la à une vérification. Une vérification (un CAPTCHA ou un contrôle JavaScript) est la manière d'appliquer l'action step_up de l'API. Ne la qualifiez pas de fausse : une nouvelle plage de Google peut mettre jusqu'à environ deux jours à être vérifiée dans nos données, car les fichiers de plages sont récupérés chaque jour et la base de recherche est reconstruite chaque jour.
4. Comparez avec le cas réel. Le vrai Googlebot à 192.178.4.40 a renvoyé verified: true, name: "Googlebot", verification_method: "ip_range_list", score 0.

Google documente deux façons d'effectuer vous-même la même vérification : un DNS inverse sur l'IP suivi d'une recherche directe du nom d'hôte, ou une comparaison avec ses fichiers de plages publiés comme common-crawlers.json (Google Search Central). La comparaison dans le code ressemble à ceci :

C'est le cas où le score dit allow et le schéma dit scraper. Sur la seule base de l'IP, cette requête obtient 10 et allow, car un serveur cloud est un signal faible en soi. Le verdict de scraping vient de trois éléments que le score ne voit pas : l'incohérence du UA, le débit régulier et le parcours page par page. Pour la procédure complète de Google, voyez comment vérifier Googlebot par DNS inverse et avec les fichiers de plages de Google ; pour GPTBot, ClaudeBot et les agents signés, voyez comment vérifier les robots d'exploration d'IA par IP, DNS inverse et Web Bot Auth.

Ce que les données IP ne voient pas : proxys résidentiels et vrais navigateurs

Les données IP ne voient pas les scrapers qui passent par des proxys résidentiels ou mobiles, et GeoIPHub ne détecte pas les proxys résidentiels ; le champ is_residential_proxy est une déduction grossière fondée sur l'ASN, à considérer comme une absence de signal. Un réseau de proxys résidentiels fait passer chaque requête par la connexion domestique de quelqu'un. Au niveau IP, la requête ressemble à ce foyer : un FAI grand public, une vraie ville, aucun indicateur d'hébergement, un score propre.

La rotation aggrave la situation. Un pool peut attribuer une nouvelle IP domestique à chaque requête, si bien que les compteurs par IP n'augmentent jamais. Les proxys mobiles partagent les IP des opérateurs avec de vrais téléphones, et un scraper IPv6 peut parcourir tout un /64 sans toucher à un nouveau réseau.

Les vrais navigateurs constituent le second angle mort. Un script Playwright qui pilote Chrome depuis une connexion de bureau ou domestique envoie la même IP, la même poignée de main TLS et les mêmes ressources que la personne au bureau d'à côté. Certaines configurations headless se trahissent ; celles qui sont bien réglées, non.

Ce qui trahit encore ces scrapers, c'est le schéma commun à plusieurs requêtes :

Si vous placez un lien caché, interdisez son chemin dans robots.txt, afin que les robots d'exploration qui respectent ce fichier n'y touchent jamais. Deux articles approfondissent les couches qui se situent à côté de l'IP. Lisez pourquoi l'empreinte d'appareil et le renseignement IP fonctionnent mieux ensemble, et ce qu'une recherche peut et ne peut pas montrer dans la détection de la fraude par proxy résidentiel.

Scraping, crawling et abus d'API

Le crawling est déclaré et vérifiable, le scraping prend votre contenu ou vos données et n'est souvent pas déclaré, et l'abus d'API consiste en des appels scriptés à vos points de terminaison au-delà de vos conditions ou de vos limites. La frontière entre eux tient au comportement et à l'identité, pas à la technologie : Googlebot et un scraper de prix peuvent utiliser la même bibliothèque HTTP sur le même cloud.

Un robot d'exploration vérifié peut tout de même scraper, comme le montre AhrefsBot, et un scraper peut tout de même ressembler à un robot d'exploration. C'est pourquoi la section suivante commence par n'autoriser que les robots vérifiés.

Comment empêcher le web scraping sans bloquer les robots d'exploration des moteurs de recherche

Pour empêcher le web scraping sans bloquer les robots d'exploration des moteurs de recherche, autorisez d'abord les robots vérifiés, puis limitez le débit par réseau et soumettez à une vérification les clients qui ne se comportent pas comme des navigateurs, et ne bloquez que ce que vous avez confirmé. Les plages de score de GeoIPHub fournissent le volet IP : allow jusqu'à 25, review jusqu'à 50, step_up jusqu'à 75 et block au-delà de 75. L'ordre compte. Un blocage généralisé des datacenters appliqué en premier aurait touché Googlebot, CCBot, ClaudeBot et AhrefsBot dans notre tableau, puisque tous les quatre provenaient de réseaux d'hébergement.

1. Autorisez les robots d'exploration vérifiés lorsque threat.crawler.verified vaut true et que crawler.name correspond à l'identifiant du User-Agent. Appliquez ensuite votre propre politique robot par robot. Pour les robots d'exploration d'IA, notre comparaison de GPTBot, OAI-SearchBot et ChatGPT-User montre comment bloquer l'entraînement sans quitter la recherche par IA.
2. Réutilisez les règles IP. Les plages de score, le traitement de Tor et les limites de débit par préfixe fonctionnent de la même manière pour les scrapers que pour n'importe quel bot ; l'article de référence les couvre. Traitez une IP de datacenter comme une donnée pondérée, pas comme un blocage, car l'hébergement couvre aussi les agents d'IA, les proxys d'entreprise et vos propres outils (voir ce qu'est une adresse IP de datacenter).
3. Limitez le débit par ASN sur les pages que les scrapers convoitent. Un pool qui tourne sur un seul hébergeur reste sous n'importe quelle limite par IP, mais un compteur par ASN sur les pages de listes, de recherche et de prix en fait la somme. Accordez un plafond plus élevé aux grands clouds, car de nombreux clients sans lien entre eux partagent un même ASN.
4. Plafonnez la pagination et placez les listes complètes derrière une connexion. Servez un nombre fixe de pages de listes aux visiteurs anonymes. Un mur de compte transforme chaque scraper en comptes que vous pouvez compter et fermer.
5. Fixez des quotas par clé sur les points de terminaison JSON qu'appellent vos pages. Les scrapers sautent souvent le HTML et appellent l'API qui se trouve derrière : émettez des clés ou des jetons de session et plafonnez les appels par clé.
6. Ajoutez une couche de gestion des bots ou un WAF pour les signaux client que vos journaux ne contiennent pas, comme les empreintes TLS et les contrôles JavaScript en périphérie.
7. Utilisez des règles comportementales pour le trafic résidentiel, où l'IP ne vous apporte rien.

Les réponses forment une échelle : autoriser, limiter le débit, vérifier, bloquer. Certains sites ajoutent un tarpit, qui ralentit les réponses à un scraper présumé, ou servent un contenu leurre, comme des prix modifiés, au trafic qu'ils ont déjà classé. Les deux vous coûtent quelque chose si la classification est erronée : ne les utilisez donc que sur du trafic que vous bloqueriez de toute façon.

Pour les lignes qui ne concernent que l'IP (Tor, relais, scanners, préfixes IPv6), utilisez la correspondance des actions de notre guide de détection des bots par IP.

Et robots.txt ? Il demande ; il n'impose rien. La RFC 9309, la norme d'exclusion des robots, précise que ses règles « are not a form of access authorization » (ne constituent pas une forme d'autorisation d'accès) (RFC 9309). Gardez-le pour les robots d'exploration qui le respectent, et appliquez tout le reste sur votre serveur. Notre guide pour bloquer les robots d'exploration d'IA montre cette couche de contrôle avec du code nginx et Express.

Commencez par les journaux d'hier. Exportez les 50 clients les plus actifs qui n'ont chargé aucune ressource, collez chacun d'eux dans la recherche IP gratuite (30 recherches par minute sans clé, 1 500 par jour avec une clé gratuite), et classez-les selon les classes du tableau de recherche ci-dessus. Ceux qui restent, très actifs et sur des réseaux grand public, sont la prochaine cible de vos règles comportementales.

Questions fréquentes

Comment bloquer les scrapers d'IA comme GPTBot ou CCBot ?

Commencez par robots.txt : GPTBot et CCBot le respectent tous deux, donc une règle Disallow pour leurs identifiants arrête les robots d'exploration déclarés. robots.txt est une demande, pas un contrôle d'accès (la RFC 9309 précise que ses règles ne constituent pas une forme d'autorisation d'accès) : appliquez donc aussi le contrôle sur votre serveur, en vérifiant chaque robot d'exploration à l'aide de ses plages IP publiées et en considérant comme non vérifié tout client qui utilise ce nom depuis l'extérieur de ces plages. OpenAI exploite plusieurs bots aux rôles différents ; notre article GPTBot vs OAI-SearchBot vs ChatGPT-User explique lequel bloquer si vous voulez rester présent dans la recherche ChatGPT.

Combien de requêtes par minute signalent du scraping ?

Il n'existe pas de chiffre universel. Mesurez votre propre référence humaine sur une journée normale, par /24 en IPv4 et par /64 en IPv6, puis examinez les réseaux qui la dépassent largement. Le débit seul signale aussi le NAT de bureau, le CGNAT et les services de surveillance : ne considérez donc un débit élevé comme du scraping que s'il s'accompagne de pages récupérées dans l'ordre et d'aucune requête de ressources.

Peut-on arrêter complètement le web scraping ?

Non. Tout ce qu'un navigateur peut afficher, un scraper déterminé peut le copier, y compris via des proxys résidentiels et de vrais navigateurs. L'objectif est de rendre le scraping lent, coûteux et visible : vérifiez les robots d'exploration, limitez le débit par réseau, soumettez à une vérification les clients qui ne se comportent pas comme des navigateurs, et placez les données à forte valeur derrière une connexion ou des clés API.

Bloquer les IP de datacenter arrête-t-il le scraping ?

En partie. Cela arrête les scrapers qui tournent sur des serveurs cloud bon marché, mais bloque aussi les robots d'exploration vérifiés, sauf si vous les autorisez d'abord : dans nos requêtes du 8 octobre 2026, CCBot sur AWS a obtenu 0 (allow) et le vrai Googlebot 0 (allow), tous deux sur des réseaux d'hébergement. Un simple serveur Linode a obtenu 10, également allow : le score seul ne le bloquera donc pas. Les scrapers qui louent des proxys résidentiels passent entièrement à travers un blocage des datacenters.

Une recherche IP peut-elle me dire qu'une IP est un scraper ?

Non. Une recherche vous indique la classe de réseau et le risque : un robot d'exploration vérifié, un serveur de datacenter, un nœud de sortie Tor ou un VPN. Savoir si cette IP vous scrape relève de vos journaux : son débit de requêtes, l'ordre des pages qu'elle récupère, le chargement ou non des ressources, et la correspondance entre son User-Agent et le robot d'exploration que la recherche vérifie.

Comment savoir si un scraper utilise des proxys résidentiels ?

Vous ne pouvez pas le voir à partir de l'IP, et GeoIPHub ne détecte pas les proxys résidentiels. Cherchez de nombreuses IP grand public qui partagent un même schéma de session : le même ordre de pages, le même intervalle entre les requêtes, les mêmes ressources manquantes et des empreintes TLS ou d'appareil similaires. C'est le schéma commun à plusieurs adresses qui trahit le scraper, pas une adresse isolée.