Détection des bots par IP : ce que l'IP peut et ne peut pas vous dire

Cette lacune compte, car les bots représentent désormais la majorité des requêtes. Le Bad Bot Report 2026 d'Imperva a constaté que le trafic automatisé représentait 53 % du trafic web observé en 2025, et que les bots malveillants à eux seuls en représentaient 40 %. La question utile sur votre formulaire de connexion est donc rarement « est-ce un bot ? ». C'est plutôt « quel type de bot, et passe-t-il ? ».

Ces types méritent d'être nommés : robots d'exploration vérifiés, bots déclarés non vérifiés, imposteurs, agents IA et récupérateurs déclenchés par l'utilisateur, scrapers de contenu et de prix, auteurs de credential stuffing et scanners. Nous montrons ci-dessous ce qu'une requête a renvoyé pour cinq IP, une par classe de bot, puis nous vous orientons vers le guide qui traite chaque besoin en détail : vérifier les robots d'exploration par IP, DNS inverse et plages publiées, protéger les inscriptions et le paiement, et limiter le débit sans bloquer les vrais utilisateurs.

Comment détecter les bots par adresse IP : six signaux

Pour détecter les bots par adresse IP, interrogez l'IP source et lisez six signaux : le type de réseau, le DNS inverse, les plages publiées des robots d'exploration, les indicateurs d'anonymat, les indicateurs de scanner et le nombre de requêtes que son préfixe vous envoie. L'IP est un meilleur point de départ que le User-Agent pour une raison simple. Un en-tête est un texte choisi par le client, alors qu'une requête HTTP nécessite une poignée de main TCP complète : l'IP source ne peut donc pas être simplement falsifiée. Le vrai contournement consiste à louer l'IP de quelqu'un d'autre ou à passer par elle via un proxy, ce que traitent les sections ci-dessous.

Nous avons effectué une requête anonyme à l'API GeoIPHub par classe de bot le 7 octobre 2026 :

Parcourez la colonne du score et la leçon principale apparaît. Dans les requêtes GeoIPHub du 7 octobre 2026, seul le nœud de sortie Tor a été bloqué (fraud_score de 100). Googlebot a obtenu 0, le scanner Censys 0, la sortie iCloud Private Relay 9 et le serveur DigitalOcean 15, tous allow. Le score répond à « à quel point cette IP est-elle risquée ? », pas à « est-ce un bot ? ». Un serveur de datacenter à 15 et un scanner à 0 relèvent tous deux de l'automatisation, et aucun n'est risqué en soi. Les correspondances avec des listes sont ici les signaux les plus fiables ; les indicateurs de type de réseau sont des inférences, c'est pourquoi ils ne font que légèrement bouger le score. Il s'agit de cinq requêtes isolées, pas d'un benchmark, et les valeurs évoluent à mesure que les plages changent.

Voici ce que vous dit chaque signal, et où trouver le détail :

• Type de réseau (asn.asn_type, asn.user_type, detection.is_hosting). L'ASN, le réseau qui annonce l'IP, vous indique à qui appartient le réseau. Une IP de datacenter (hébergement), le champ detection.is_hosting de l'API, est le premier filtre, car la plupart des bots tournent dans des datacenters et la plupart des gens non. C'est un verdict faible à lui seul, ce qui explique le score de 15 de DigitalOcean. Notre article sur ce qu'est une adresse IP de datacenter explique comment l'hébergement est détecté et quand il est légitime.
• DNS inverse (network.ptr_record, fcrdns_valid). Un nom d'hôte confirmé par une recherche directe peut nommer l'opérateur. Le PTR du nœud de sortie Tor se termine par tor-exit.artikel10.org, ce qui a déclenché rdns_tor. Une limite de notre côté : l'API ne stocke aucun PTR pour les IP de Googlebot et de DigitalOcean, alors que dig -x renvoie des noms en direct pour les deux ; no_ptr_datacenter se déclenche donc pour elles. Effectuez vous-même la vérification DNS quand le nom d'hôte compte.
• Plages publiées des robots d'exploration (threat.crawler). Faire correspondre une IP au fichier de plages de l'opérateur est la preuve la plus nette qu'un bot est bien celui qu'il prétend être. GeoIPHub charge 19 flux officiels de plages de Google, Microsoft (Bing), Apple, DuckDuckGo, OpenAI, Anthropic, Perplexity, Mistral, Common Crawl et Ahrefs, récupérés chaque jour.
• Indicateurs Tor, VPN, proxy et relais (detection.is_tor, is_vpn, is_proxy, is_relay). Ils indiquent que le vrai client se cache derrière le réseau de quelqu'un d'autre. Voir comment détecter le trafic Tor par IP et le fonctionnement de la détection des VPN et des proxys.
• Indicateurs de scanner (threat.is_scanner). Les scanners à l'échelle d'internet sondent toutes les adresses qu'ils peuvent atteindre.
• Débit par préfixe. Celui-ci vous revient, pas à nous : comptez les requêtes par /64 en IPv6, comme l'explique la section sur la limitation de débit ci-dessous.

Le résultat du scanner nous a surpris ; le voici, extrait de la vraie réponse :

L'indicateur de scanner est activé, mais il n'ajoute rien au score, et le réseau de Censys n'est pas classé comme hébergement. Si vous décidez uniquement sur recommended_action, le trafic de scanner passe. Lisez directement threat.is_scanner si vous voulez l'exclure de vos statistiques ou le bloquer au pare-feu.

Vérifier l'adresse IP d'un bot : ce robot d'exploration est-il celui qu'il prétend être ?

La vérification de l'adresse IP d'un bot confirme un robot d'exploration déclaré en faisant correspondre son IP au fichier de plages publié par l'opérateur, ou à un nom DNS inverse confirmé par une recherche directe, jamais en faisant confiance au User-Agent. N'importe quel client peut envoyer Googlebot dans cet en-tête. Seul l'opérateur contrôle ses plages d'IP.

Notre API ne voit que l'IP, jamais vos en-têtes de requête : c'est donc votre code qui fait la comparaison entre l'opérateur du bot revendiqué et threat.crawler.verified et threat.crawler.operator. Ne vous fiez pas à threat.crawler.name : c'est l'étiquette du fichier, et un même fichier peut couvrir plusieurs bots. Dans nos requêtes, 66.249.66.1 a renvoyé verified: true, name: "Googlebot", verification_method: "ip_range_list". Le serveur DigitalOcean a renvoyé name: "none" : une prétention à être Googlebot depuis ce serveur n'est donc pas vérifiée. Cela signifie « non vérifié comme étant ce bot », pas la preuve d'une imposture.

ClaudeBot et PerplexityBot sont couverts par les fichiers de plages que publient Anthropic et Perplexity : le 8 octobre 2026, 216.73.216.10 a renvoyé verified: true, name: "ClaudeBot", operator: "Anthropic". Les bots qui ne publient aucun fichier de plages exigent toujours la méthode propre à l'opérateur, comme le DNS inverse. Les bots qui signent leurs requêtes avec Web Bot Auth peuvent être vérifiés par leur signature plutôt que par leur IP.

Le détail se trouve dans quatre articles. Le guide de vérification des robots d'exploration couvre le DNS inverse, les fichiers CIDR et les signatures Web Bot Auth. Comment vérifier Googlebot et repérer les faux Googlebots présente les trois groupes de robots d'exploration de Google et leurs fichiers de plages. GPTBot, OAI-SearchBot et ChatGPT-User comparés explique quel bot OpenAI bloquer et comment vérifier chacun d'eux. Notre liste d'IP de robots d'exploration vérifiés rassemble les 19 fichiers avec leurs dates et le code de liste d'autorisation.

Ce que la détection des bots par IP ne peut pas vous dire

La détection des bots par IP ne peut pas vous dire si une IP domestique est louée comme proxy résidentiel, et GeoIPHub ne détecte pas les proxys résidentiels. Un réseau de proxys résidentiels fait transiter la requête d'un bot par la connexion domestique de quelqu'un. Au niveau IP, cette requête ressemble au trafic du foyer lui-même : un FAI grand public, une vraie ville, aucun indicateur d'hébergement.

Notre champ is_residential_proxy est une inférence approximative fondée sur l'ASN, pas une détection : considérez qu'il ne fournit aucun signal. La rotation aggrave les choses. Un pool peut attribuer une IP domestique différente à chaque requête, si bien que les compteurs par IP ne montent jamais.

Les botnets partagent le même angle mort. Des appareils domestiques infectés envoient du trafic de bots depuis des IP résidentielles ordinaires, et les flux de botnets couvrent l'infrastructure connue, comme les serveurs de commande et de contrôle, pas chaque appareil infecté. Les bots contournent la détection par IP de quatre façons courantes : la rotation d'adresses, la location de proxys résidentiels, le passage d'une adresse à l'autre dans un /64 IPv6 et le routage via des proxys mobiles qui partagent les IP des opérateurs avec de vrais téléphones.

• Proxys résidentiels. Non détectés. Repérez-les par le comportement : vélocité par compte, incohérences d'appareil et de session.
• Le User-Agent et les autres en-têtes. L'API ne les voit jamais. Comparez la revendication dans votre propre code.
• Qui tape au clavier. Un navigateur headless et une personne sur la même IP de bureau sont identiques à ce niveau.
• Plages publiées depuis moins de deux jours. Nous récupérons les fichiers de plages des robots d'exploration chaque jour et reconstruisons la base de requêtes chaque jour : une plage toute nouvelle peut donc rester non vérifiée pendant environ deux jours au maximum.
• Robots d'exploration hors de nos 19 flux. Aucune identité vérifiée, quoi qu'ils prétendent.
• Risque des scanners. is_scanner est activé mais, dans notre requête, n'augmente pas fraud_score.

Les couches qui comblent ces lacunes se situent à côté de l'IP : comportement et vélocité, empreinte d'appareil, empreintes TLS comme JA3 et JA4, challenges, et Web Bot Auth pour les bots qui se déclarent. Côté résidentiel, lisez la détection de la fraude par proxy résidentiel pour savoir ce qu'une requête peut et ne peut pas montrer, et pourquoi autant de proxys résidentiels apparaissent dans votre trafic pour comprendre pourquoi ils sont si nombreux.

Comment détecter le trafic de bots lors des inscriptions, des connexions et du paiement

Pour détecter le trafic de bots lors des inscriptions, des connexions et du paiement, effectuez la requête IP au moment de l'action, puis combinez-la avec ce que votre application sait déjà : tentatives par compte, par préfixe et par appareil. L'IP réduit le champ. Ce sont vos propres compteurs qui tranchent.

Chaque point de terminaison pondère les signaux différemment :

• Connexions. Le credential stuffing répartit les tentatives sur de nombreuses IP, souvent résidentielles, que la couche IP ne peut pas signaler. Les indicateurs Tor et d'hébergement attrapent tout de même la part la moins soigneuse. Notre guide sur la prise de contrôle de compte et le credential stuffing présente la stratégie en couches.
• Paiement. Une IP de datacenter au moment du paiement peut être un agent d'achat IA légitime : l'hébergement est donc un signal pondéré plutôt qu'un blocage. Le serveur DigitalOcean a obtenu 15, allow. Voir comment stopper la fraude des agents d'achat IA au paiement.
• Clics publicitaires. Les indicateurs d'hébergement et Tor signalent les clics à exclure de vos données de conversion. Notre guide pour détecter la fraude au clic par adresse IP montre le scoring.
• Inscriptions. Les mêmes tranches s'appliquent, avec en plus un contrôle des comptes multiples depuis un même préfixe.

Utilisez les tranches de score comme action par défaut : allow jusqu'à 25, review jusqu'à 50, step_up jusqu'à 75, block au-delà de 75. Ajoutez vos propres règles pour les indicateurs que le score laisse de côté, comme is_scanner.

Comment limiter le débit des IP de bots sans bloquer les vrais utilisateurs

Limitez le débit des IP de bots selon l'unité qui correspond à un seul acteur : le /64 en IPv6 et l'adresse unique en IPv4, en tenant compte des sorties partagées comme le CGNAT et iCloud Private Relay. Si vous comptez la mauvaise unité, soit vous manquez le bot, soit vous pénalisez une foule. Pour les robots d'exploration IA en particulier, le choix entre autoriser, vérifier ou limiter le débit est détaillé dans faut-il bloquer les robots d'exploration IA.

En IPv6, un abonné reçoit un /64 entier et peut passer gratuitement d'une adresse à l'autre : un compteur par adresse ne se déclenche donc jamais. Notre guide pour limiter le débit et bloquer l'IPv6 par préfixe /64 présente la fonction de clé et indique quand élargir à /56 ou /48.

En IPv4, c'est le problème inverse : de nombreuses personnes partagent une même adresse. Le CGNAT des opérateurs place tout un quartier derrière une seule IP. L'API le signale par threat.is_cgnat, et le scoring plafonne le risque pour les adresses CGNAT. iCloud Private Relay fait de même pour les utilisateurs Apple : notre IP de relais a obtenu 9, allow, avec la méthode relay_ip.

La géolocalisation des relais demande aussi de la prudence. Notre requête a situé 104.28.46.99 à Luanda, en Angola. C'est la sortie du relais, pas la preuve de l'emplacement de l'utilisateur : ne faites donc pas de blocage géographique sur cette base. Notre guide pour détecter le trafic anonymisé sans bloquer les vrais clients explique la liste de sorties publiée par Apple et la manière de traiter les relais.

Par où commencer avec la détection des bots par IP

Pour agir sur la détection des bots par IP, associez chaque signal à une action par défaut (pour une seule adresse suspecte, suivez plutôt la méthode complète d'investigation d'une IP) : autorisez les robots d'exploration vérifiés, limitez le débit des prétentions de robot d'exploration non vérifiées, bloquez ou renforcez la vérification pour Tor, et utilisez les signaux de comportement lorsque l'IP paraît résidentielle. Chaque ligne ci-dessous correspond à un signal, ce qu'il prouve, une action par défaut et l'article qui le traite.

Le moyen le plus rapide de voir où se situe votre propre trafic : prenez les 20 IP les plus actives des journaux d'hier et collez chacune d'elles dans l'outil gratuit de recherche IP, ou exécutez curl -s https://api.geoiphub.com/v1/lookup/<ip> sans clé (30 requêtes par minute), ou jusqu'à 1 500 par jour avec une clé gratuite. Classez-les selon les classes de bots du premier tableau, et vous saurez quelle section de cette carte lire en premier.

Questions fréquentes

Peut-on détecter les bots uniquement par l'adresse IP ?

En partie. Une requête IP vous indique de quel type de réseau provient une requête : une plage publiée de robot d'exploration, un serveur de datacenter, un nœud de sortie Tor, un VPN, un relais de confidentialité ou un scanner connu. Elle ne peut pas vous dire si c'est une personne ou un script qui a envoyé la requête, ni repérer une IP domestique louée via un réseau de proxys résidentiels. Utilisez l'IP comme un signal parmi d'autres, à côté du débit de requêtes, de l'historique du compte et des signaux d'appareil.

Comment vérifier qu'une adresse IP de bot est un vrai robot d'exploration ?

Comparez l'IP au fichier de plages publié par l'opérateur, ou effectuez une recherche DNS inverse et confirmez-la par une recherche directe. Le User-Agent ne prouve rien, car n'importe quel client peut envoyer n'importe quelle chaîne. Lors de notre requête du 7 octobre 2026, 66.249.66.1 a renvoyé threat.crawler.verified à true avec le nom Googlebot, tandis qu'un serveur DigitalOcean n'a renvoyé aucune identité de robot d'exploration. Notre guide de vérification des robots d'exploration détaille pas à pas le DNS inverse, les fichiers de plages et Web Bot Auth.

Quelle est la précision de la détection des bots par IP ?

Cela dépend du signal. Une correspondance avec une liste publiée est une preuve solide : GeoIPHub vérifie 19 flux officiels de plages de robots d'exploration de 10 opérateurs, récupérés chaque jour, ainsi que la liste des nœuds de sortie du Tor Project, actualisée toutes les 6 heures. Les indicateurs d'hébergement, de VPN et de proxy sont des inférences ; la détection de l'hébergement s'appuie sur 853 ASN d'hébergeurs sélectionnés et sur les plages officielles de 10 fournisseurs cloud. Les proxys résidentiels ne sont pas détectés. Nous ne publions pas de pourcentage de précision, et les cinq requêtes de cet article sont des exemples, pas un benchmark.

Un score de fraude élevé signifie-t-il qu'une IP est un bot ?

Non. Le score mesure le risque, pas l'automatisation. Dans nos cinq requêtes, un scanner Censys a obtenu 0 et un serveur DigitalOcean 15, tous deux allow, alors que les deux sont clairement automatisés. Un nœud de sortie Tor a obtenu 100, block. Lisez les indicateurs pour savoir ce qu'est le trafic, et le score pour savoir à quel point il est risqué.

GeoIPHub détecte-t-il les proxys résidentiels ?

Non. Le champ is_residential_proxy est une inférence approximative fondée sur l'ASN, pas une détection. Une IP domestique louée via un réseau de proxys ressemble à une connexion domestique ordinaire au niveau IP ; pour la repérer, il faut des signaux de comportement et de session.