Qu'est-ce que l'IP intelligence ? Au-delà de la simple géolocalisation
L'IP intelligence regroupe tout ce qu'une IP révèle : géolocalisation, ASN, infrastructure, anonymisation, historique de menaces et un score de risque explicable.

La plupart des outils de recherche d'IP renvoient une position. L'IP intelligence moderne renvoie un dossier complet. Cet article détaille l'ensemble des données disponibles : ce que contient chaque couche, d'où elle provient et quelles décisions elle permet de prendre. Pour chaque champ individuel et son type, consultez la référence complète des champs de données IP.

Couche 1 : géolocalisation
La couche fondamentale. Chaque adresse IP appartient à un réseau enregistré dans un pays, annoncé depuis une région donnée et généralement utilisé dans une ville donnée. Les données de géolocalisation associent des plages d'IP à des positions physiques en combinant les enregistrements des registres (RIPE, ARIN, APNIC, LACNIC, AFRINIC), l'analyse de la topologie réseau et la mesure active.
Voici ce que renvoie une requête de géolocalisation, d'après le groupe geo d'une réponse GeoIPHub réelle pour l'IP 91.108.56.1 de Telegram (abrégée, requête effectuée le 2 octobre 2026) :
{
"ip": "91.108.56.1",
"geo": {
"country_code": "SG",
"country_name": "Singapore",
"region": "Singapore",
"city": "Singapore (Novena)",
"latitude": 1.3208600000000001,
"longitude": 103.842,
"timezone": "Asia/Singapore",
"geo_confidence": 0.8
}
}
La précision varie considérablement selon le type d'IP. Les IP des FAI résidentiels sont généralement précises au niveau de la ville. Les nœuds périphériques de CDN et les IP anycast (comme le 1.1.1.1 de Cloudflare) sont géolocalisés à l'emplacement de l'infrastructure réseau, pas à celui des utilisateurs. Les IP mobiles sont géolocalisées avec précision au niveau du pays et de la région, de façon moins fiable au niveau de la ville. Les IP de VPN sont géolocalisées à l'emplacement du serveur VPN, et non à la position réelle de l'utilisateur, ce qui est la première raison pour laquelle la géolocalisation seule ne suffit pas.
Couche 2 : ASN et propriété du réseau
Chaque IP est annoncée par un système autonome (AS), un réseau doté d'un ASN unique qui contrôle un ensemble de plages d'IP. L'ASN vous indique qui exploite le réseau auquel appartient l'IP, ce qui en fait l'une des données isolées les plus informatives qui soient. Voici le groupe asn pour le 1.1.1.1 de Cloudflare (réponse réelle abrégée) :
{
"asn": {
"asn": 13335,
"org": "CLOUDFLARENET - Cloudflare, Inc.",
"asn_type": "cdn",
"user_type": "content_delivery_network",
"connection_type": "datacenter"
}
}
Types d'ASN :
- FAI / résidentiel (Comcast, Deutsche Telekom, Jio) : trafic de personnes réelles
- Opérateur mobile (AT&T Mobility, Vodafone) : téléphones derrière du CGNAT
- Datacenter / cloud (AWS, Google Cloud, Azure, OVH) : infrastructure de serveurs
- CDN (Cloudflare, Akamai, Fastly) : nœuds périphériques de diffusion de contenu
- Hébergement / colocation : généralement des serveurs loués, pas à l'échelle du cloud
- ASN de VPN : systèmes autonomes ayant un historique documenté de serveurs VPN
Le type d'ASN constitue une probabilité a priori, avant même la prise en compte de tout indice comportemental. Une requête provenant de l'AS7922 (Comcast) vient presque certainement d'une personne réelle. Une requête provenant de l'AS16509 (Amazon) vient presque certainement d'un serveur ou d'un processus automatisé. Cette seule donnée change ce que vous devez attendre et accepter de la connexion.
Couche 3 : classification de l'infrastructure
Plus fine que l'ASN, la classification de l'infrastructure identifie le type précis de contexte réseau dans lequel l'IP opère :
- Résidentielle : attribuée à une connexion haut débit domestique par un FAI grand public
- Mobile : attribuée via CGNAT à un téléphone sur un réseau cellulaire
- Datacenter : exploitée chez un fournisseur cloud, sur un serveur dédié ou dans un centre de colocation
- Professionnelle : attribuée à l'infrastructure de bureau d'une entreprise
- Périphérie de CDN : le trafic sort par un nœud périphérique d'un réseau de diffusion de contenu
- Satellite : attribuée par des FAI satellitaires (Starlink, Viasat)
Pour un droplet DigitalOcean (104.248.50.21), les champs de classification sont les suivants (réponse réelle abrégée) :
{
"asn": { "asn_type": "hosting", "user_type": "hosting", "connection_type": "datacenter" },
"detection": {
"is_hosting": true,
"is_mobile": false,
"is_satellite": false,
"is_anycast": false
}
}
Cette couche compte pour la fraude et le contrôle d'accès, car la plupart des vrais utilisateurs de la plupart des produits grand public se connectent depuis des IP résidentielles ou mobiles. Une IP de datacenter qui accède à votre produit grand public est structurellement inhabituelle. Ce n'est pas toujours malveillant (développeurs, pipelines automatisés et utilisateurs professionnels se connectent légitimement depuis des datacenters), mais c'est suffisamment inhabituel pour peser dans un calcul de risque.
Couche 4 : détection d'anonymisation
La détection d'anonymisation détermine si l'IP apparente est la véritable IP de l'utilisateur ou un relais par lequel il fait transiter son trafic. Trois grands types :
VPN (réseau privé virtuel) : le trafic de l'utilisateur sort par un serveur VPN. La géolocalisation indique l'emplacement du serveur VPN, et non la position réelle de l'utilisateur. La détection s'appuie sur les listes publiques de serveurs des fournisseurs, le sondage actif de protocoles (handshakes OpenVPN, IKEv2, PPTP et L2TP) et l'historique des ASN. Les fournisseurs de VPN commerciaux comme NordVPN, ExpressVPN et Mullvad exploitent une infrastructure publiée, détectable de façon fiable.
Proxy (HTTP/SOCKS) : trafic relayé au niveau de la couche application plutôt que de la couche réseau. Détectable par sondage de ports, car les proxies SOCKS5 et HTTP répondent à leurs séquences d'accueil respectives sur des ports caractéristiques.
Proxy résidentiel : l'anonymiseur le plus sophistiqué. Le trafic sort par une véritable IP résidentielle, généralement récupérée sur un appareil infecté par un logiciel malveillant ou via un réseau de proxies pair-à-pair payant. L'IP elle-même appartient à un FAI domestique, si bien que la détection fondée sur l'ASN échoue. La détection exige des signaux comportementaux : la même IP qui apparaît dans les annonces de réseaux de proxies, des schémas de rotation anormaux ou une diversité de User-Agent incompatible avec une connexion d'un seul foyer.
Tor : le réseau d'anonymisation Tor fait transiter le trafic par une série de relais chiffrés avant qu'il ne sorte par un nœud de sortie Tor. Les IP des nœuds de sortie sont publiées dans l'annuaire de consensus Tor, ce qui rend la détection fiable et exhaustive.
Voici le groupe detection pour 185.213.155.73, un serveur WireGuard figurant dans la liste publique des relais de Mullvad (réponse réelle abrégée) :
{
"detection": {
"is_vpn": true,
"is_proxy": false,
"is_tor": false,
"is_hosting": true,
"is_anonymous": true,
"anonymity_level": "medium",
"vpn_confidence": 95
}
}
Couche 5 : threat intelligence
La threat intelligence agrège des preuves externes de comportements malveillants : signalements des services abuse des réseaux, captures de honeypots, données de sinkholes de botnets, journaux d'activité de scan et déclenchements de pièges à spam.
Signaux clés (la matière première du score de réputation IP) :
- Présence sur des listes de blocage : combien de listes de blocage indépendantes incluent cette IP, et dans quelles catégories
- Signalements d'abus : volume et ancienneté des plaintes adressées aux FAI et aux services abuse
- Historique de botnet : association avec une infrastructure connue de commande et contrôle de logiciels malveillants
- Empreintes de scanner : preuves de scan de ports, de sondage de vulnérabilités ou de credential stuffing
Ces signaux figurent dans le groupe threat. Pour le même serveur Mullvad, la seule catégorie de menace est l'anonymiseur lui-même (réponse réelle abrégée) :
{
"threat": {
"is_abusive": false,
"is_spammer": false,
"is_scanner": false,
"is_botnet": false,
"is_cgnat": false,
"threat_types": ["vpn"]
}
}
La threat intelligence est par nature sensible au temps. Les entrées des listes de blocage expirent à mesure que les IP changent de mains ; des signalements d'abus vieux de trois mois sont des preuves faibles ; l'activité de scan d'hier est une preuve forte. Une threat intelligence efficace se met à jour en continu plutôt que selon un cycle mensuel par lots. Combinés aux données de localisation et d'infrastructure, ces flux sont ce sur quoi s'appuient les blocages en périphérie, les contrôles de voyage impossible et les restrictions géographiques.
Couche 6 : score de risque
Tout ce qui précède se condense en un seul score de 0 à 100, scoring.fraud_score : le nombre sur lequel vous fondez vos décisions. Pour le même serveur Mullvad (réponse réelle abrégée) :
{
"scoring": {
"fraud_score": 100,
"confidence": 0.7075,
"recommended_action": "block",
"detection_methods": [
"known_vpn_server",
"wireguard_open",
"datacenter_with_vpn_proxy",
"no_ptr_datacenter"
]
}
}
Le score ne vaut que par son explicabilité. Un nombre opaque qui monte et descend sans explication ne peut être ni ajusté, ni défendu dans un litige de rétrofacturation, ni audité pour détecter des biais. Le tableau detection_methods nomme les éléments de preuve contributifs (ici : l'IP figure sur la liste de serveurs d'un fournisseur, cette liste l'identifie comme serveur WireGuard, et elle se trouve sur une infrastructure d'hébergement), et recommended_action fait correspondre le score à une tranche : allow jusqu'à 25, review jusqu'à 50, step_up jusqu'à 75, block au-delà de 75. Ainsi, lorsqu'un score bloque un client légitime, vous pouvez identifier le signal responsable et ajuster le seuil ou la pondération.
À quoi ressemble une réponse d'IP intelligence complète
En réunissant toutes les couches dans une seule requête :
curl "https://api.geoiphub.com/v1/lookup/103.21.244.0" \
-H "x-api-key: YOUR_API_KEY"
Réponse réelle abrégée (requête effectuée le 2 octobre 2026 ; la réponse complète comporte 10 groupes : ip, asn, geo, whois, network, detection, threat, dns, scoring, meta) :
{
"ip": "103.21.244.0",
"asn": {
"asn": 13335,
"org": "CLOUDFLARENET - Cloudflare, Inc.",
"asn_type": "hosting",
"connection_type": "datacenter"
},
"geo": {
"country_code": "CA",
"region": "Ontario",
"city": "Toronto",
"latitude": 43.6532,
"longitude": -79.3832,
"timezone": "America/Toronto"
},
"whois": {
"org": "Cloudflare, inc.",
"netname": "CLOUDFLARE_103_21_244_0"
},
"detection": {
"is_hosting": true,
"is_mobile": false,
"is_vpn": false,
"is_proxy": false,
"is_tor": false
},
"threat": {
"is_abusive": false,
"threat_types": []
},
"scoring": {
"fraud_score": 15,
"confidence": 0.25,
"recommended_action": "allow",
"detection_methods": ["datacenter_ip", "no_ptr_datacenter"]
}
}
Cette IP fait partie de l'infrastructure de Cloudflare et est géolocalisée à Toronto : ce n'est pas une personne, elle n'est pas malveillante et ne cache rien. Le score de fraude de 15 reflète le contexte datacenter (et l'absence de DNS inverse typique de l'espace datacenter) sans aucune preuve d'anonymiseur ou d'abus ; il se situe donc dans la tranche allow. L'action appropriée dépend du cas d'usage : pour un parcours de paiement grand public, cela justifie une note dans le journal de session ; pour un client API B2B, c'est exactement ce à quoi vous vous attendriez. Pour intégrer une requête de ce type à votre propre parcours d'inscription ou de paiement, suivez le guide pas à pas pour ajouter la détection de fraude IP avec l'API gratuite.
Quelles couches pour quels cas d'usage
| Cas d'usage | Couches principales | Remarques |
|---|---|---|
| Prévention de la fraude au paiement | Anonymisation, score de risque, threat intelligence | Bloquer ou challenger en cas d'anonymiseur + historique d'abus |
| Score de risque à la connexion | Anonymisation, infrastructure, score de risque | Datacenter + VPN à la connexion = risque élevé |
| Restriction géographique / conformité | Géolocalisation, anonymisation | La détection VPN empêche le contournement géographique |
| Fraude publicitaire / filtrage IVT | Infrastructure, empreintes de bots | Datacenter + bot = trafic invalide |
| Localisation du contenu | Géolocalisation, ASN | Pays + FAI orientent les décisions de langue et de CDN |
| Prévention des abus d'API | Infrastructure, threat intelligence, signaux de débit | Les IP de datacenter présentes sur des listes de blocage justifient une limitation de débit |
| Tri du trafic de sécurité | Toutes les couches | Vision complète pour l'investigation d'incidents |
L'IP intelligence selon les équipes et les secteurs
Chaque équipe s'appuie sur des couches différentes, et un même signal n'a pas la même signification selon l'activité. C'est pourquoi l'« IP intelligence » apparaît aussi bien dans les recherches sur les plateformes anti-fraude que sur les outils de sécurité ou d'analytics. Il s'agit d'un seul jeu de données au service de plusieurs missions :
- Les équipes fraude et risque s'appuient sur l'anonymisation, l'historique de menaces et le score de risque pour décider en temps réel de l'issue d'un paiement, d'une connexion ou d'une inscription.
- Les équipes de sécurité utilisent les couches infrastructure et menaces pour trier le trafic entrant, repérer les scans et enrichir les alertes SIEM avec le contexte ASN et d'hébergement. Nous expliquons séparément comment ces signaux contrent des schémas précis de cybercriminalité.
- Les équipes trust and safety combinent les indicateurs d'anonymiseur et le comportement pour détecter le contournement de bannissement, les faux comptes et les abus coordonnés.
- Les équipes growth et marketing utilisent la géolocalisation et l'ASN pour la localisation, le filtrage du trafic invalide et des analytics plus propres.
- La conformité utilise les données de pays et d'anonymisation pour les restrictions géographiques, le filtrage des sanctions et la détermination de la juridiction.
Le secteur modifie davantage les enjeux que les données. La fintech et la banque accordent le plus de poids à l'anonymisation et au risque, car les tentatives de prise de contrôle de compte se cachent derrière un VPN ou un proxy. Le jeu vidéo se préoccupe du contournement de bannissement et des régions de licence. L'e-commerce et les marketplaces luttent contre la fraude au paiement et les faux vendeurs. Le SaaS évalue le risque à la connexion et les abus d'API. Le streaming fait respecter les licences géographiques face au contournement par VPN. Six couches, pondérées différemment. C'est pourquoi une plateforme d'IP intelligence est plus utile que n'importe quel champ isolé, et pourquoi il vaut la peine de vérifier quelles couches un fournisseur de données IP couvre réellement avant d'en choisir un. Consultez les motifs nommés derrière chaque score de risque.
Le manque que laisse la géolocalisation
Pour rendre la différence concrète : si un utilisateur à Moscou se connecte via le serveur Mullvad 185.213.155.73, une requête de géolocalisation renvoie Allemagne, Frankfurt am Main. La requête GeoIPHub complète renvoie le même geo.country_code: DE, plus detection.is_vpn: true, scoring.fraud_score: 100 et des detection_methods known_vpn_server et wireguard_open. Les données de localisation sont identiques. Le renseignement, lui, ne l'est pas.
Dans un contexte de restriction géographique (par exemple, un service de streaming détenant des droits pour l'Allemagne), la géolocalisation seule approuve la requête. L'IP intelligence signale que la position n'est pas fiable. Bloquer ou autoriser relève d'une décision produit ; mais sans la couche de renseignement, vous ne pouvez même pas prendre cette décision en connaissance de cause.
Telle est la frontière pratique entre la géolocalisation IP et l'IP intelligence : la géolocalisation vous dit ce que l'adresse prétend. Le renseignement vous dit à quel point vous pouvez la croire.
Questions fréquentes
Qu'est-ce que l'IP intelligence ?
L'IP intelligence est l'ensemble complet des données que l'on peut tirer d'une adresse IP. Cela ne se limite pas au pays et à la ville : il s'agit aussi du système autonome qui la possède, de la nature de l'infrastructure (résidentielle ou datacenter), de la présence éventuelle d'un VPN, d'un proxy ou d'un relais Tor, de son historique d'abus, de sa classification de menace et d'un score de risque qui synthétise le tout. Le terme distingue l'analyse IP complète de la géolocalisation de base, qui ne renvoie généralement que des champs de localisation.
Quelle est la différence entre la géolocalisation IP et l'IP intelligence ?
La géolocalisation IP répond à la question : où se trouve cette IP ? Pays, région, ville, coordonnées, fuseau horaire, nom du FAI. L'IP intelligence répond à la question : qu'est-ce que cette IP et quel degré de confiance mérite-t-elle ? Elle ajoute le type d'infrastructure (datacenter, résidentielle, mobile), la détection d'anonymisation (VPN, proxy, Tor), les classifications de menace (scanner, botnet, source de spam), l'historique d'abus et un score de risque synthétique. La géolocalisation n'est qu'une couche de l'IP intelligence.
Que peut vous apprendre l'IP intelligence que la géolocalisation ne peut pas ?
Si l'IP est un VPN ou un proxy qui masque la position réelle (ce qui rend les champs de géolocalisation dénués de sens), s'il s'agit d'une IP de datacenter sans utilisateur réel derrière, si elle a figuré récemment sur des listes de blocage pour abus, si elle fait activement tourner un service de proxy ou de scan, et une estimation probabiliste du risque d'une requête provenant de cette IP. La géolocalisation de base renvoie des coordonnées ; l'IP intelligence vous dit si vous pouvez vous y fier.
Comment l'IP intelligence est-elle utilisée en pratique ?
Les équipes anti-fraude l'utilisent pour évaluer le risque au paiement, à la connexion et à l'inscription. Les équipes de sécurité l'utilisent pour trier le trafic entrant et repérer les scans ou les abus automatisés. Les plateformes publicitaires l'utilisent pour filtrer le trafic invalide avant qu'il ne soit facturé à une campagne. Les équipes conformité l'utilisent pour appliquer les restrictions géographiques et déterminer la juridiction. Les plateformes de contenu l'utilisent pour les licences géographiques et les décisions de paywall. Le cas d'usage détermine quelles couches de renseignement comptent le plus.
L'IP intelligence est-elle précise pour les utilisateurs mobiles ?
En partie. Les utilisateurs mobiles partagent des IP via le CGNAT (NAT de niveau opérateur), si bien que la géolocalisation est généralement correcte au niveau du pays et de la région mais imprécise au niveau de la ville. La classification de l'infrastructure (opérateur mobile ou datacenter) est fiable. La détection d'anonymisation est fiable : un utilisateur mobile sur un VPN se présente très différemment d'une connexion mobile native. Le score de risque pour le mobile doit être calibré différemment de celui des IP résidentielles, car le CGNAT dilue la responsabilité attribuable à chaque IP.
L'équipe derrière l'API GeoIPHub
Rédigé par l'équipe GeoIPHub, les personnes qui développent l'API de renseignement IP GeoIPHub et son scanner. Les brouillons sont préparés avec l'aide de l'IA et relus par l'équipe ; les exemples d'API sont de vraies requêtes sur l'API en production, sauf mention « illustratif ».


