La liste complète des champs de données IP à connaître

Posez la question « quelles données peut-on obtenir d'une adresse IP ? » et la plupart des réponses s'arrêtent à « une localisation approximative ». C'est la plus petite partie de ce que couvre l'intelligence IP. La même adresse vous dit aussi quel réseau la possède, s'il s'agit d'une ligne domestique ou d'un serveur loué, si c'est un VPN, une sortie Tor ou un relais de confidentialité, si elle figure sur une liste de blocage, et s'il s'agit d'un robot d'exploration vérifié. Pour savoir comment les champs de détection sont construits, consultez comment fonctionne la détection des VPN et des proxys.

Cette référence a beaucoup changé depuis notre version de juillet. L'API a gagné trois champs, nos tableaux en avaient oublié deux, le score d'une sortie Tor est passé de 79 à 100, et plusieurs champs renvoient des valeurs que les tableaux de juillet décrivaient mal. Chaque exemple ci-dessous provient de GET api.geoiphub.com/v1/lookup/{ip} le 22 octobre 2026, et vous pouvez reproduire n'importe lequel avec l'outil de recherche IP gratuit.

Nous avons compté 103 champs dans sept réponses en direct le 22 octobre 2026

Nous avons obtenu sept réponses le 22 octobre 2026 entre 04:56 et 04:57 UTC et compté 103 champs répartis en 10 groupes. Cinq champs sont nouveaux dans cette liste depuis juillet, et 11 sont fictifs. Les sept adresses étaient des infrastructures publiques, choisies pour activer des groupes différents :

Un petit script Node a parcouru chaque réponse et listé chaque champ terminal, en comptant geo.country_names comme un seul champ puisqu'il s'agit d'une table de traductions. Les sept réponses avaient exactement les mêmes 103 clés. Voici leur répartition :

Cinq champs sont nouveaux dans cette liste. Trois ont été ajoutés à l'API en octobre : detection.residential_proxy_status, residential_proxy_evidence et residential_proxy_last_seen. Ils figurent désormais dans la référence des champs de l'API, marqués comme réservés. Les deux autres, threat.crawler.unverified et threat.spammer_last_seen, étaient déjà dans la réponse en juillet, et nos anciens tableaux les avaient simplement oubliés. Aucun champ de la liste de juillet n'a été supprimé.

Onze champs sont fictifs. Nous avons vérifié le générateur de réponses de l'API : dix d'entre eux sont écrits comme une valeur vide constante ([], "none" ou 0) à chaque requête, et crawler.spoofed n'a pas encore de source de données. Huit autres champs contiennent des données mais sont réservés, et nous n'en publions pas les valeurs : blocklist_count, ptr_pattern dans les deux groupes, et les cinq champs de proxy résidentiel. Les tableaux ci-dessous signalent les deux catégories.

Comment les 10 groupes s'articulent dans une requête sur une sortie Tor

Les groupes se comprennent plus facilement en suivant une seule adresse. Voici la vraie réponse pour 185.220.101.1, une sortie Tor, réduite aux champs qui racontent son histoire :

Les groupes se corroborent mutuellement. L'ASN indique un hébergement, detection.is_tor provient de la liste des sorties du Tor Project, threat.dnsbl_sources montre une inscription sur Spamhaus ZEN, et le groupe scoring rassemble le tout en block avec les quatre méthodes qui se sont déclenchées.

La réponse révèle aussi une lacune. ptr_record vaut "none", donc no_ptr_datacenter s'est déclenché, et pourtant un dig -x 185.220.101.1 en direct le même matin a renvoyé un nom d'hôte tor-exit. Le DNS inverse stocké par l'API est en retard sur l'enregistrement en direct pour certaines adresses. C'est aussi pour cette raison que rdns_tor, visible dans la version de juillet de cet article, ne se déclenche plus. Ce recoupement entre groupes est la raison même de transporter autant de champs. Passons maintenant à chaque groupe.

1. L'IP elle-même (ip)

Le champ ip renvoie l'adresse exacte que l'API a résolue, sous forme de chaîne. Utilisez-le pour confirmer que vous avez interrogé ce que vous vouliez, surtout après l'analyse d'un en-tête X-Forwarded-For, où choisir le mauvais saut est un bug classique. C'est aussi la clé naturelle pour votre propre cache.

IPv4 et IPv6 sont tous deux acceptés. Si vous n'êtes pas sûr de votre propre adresse publique, l'outil quelle est mon IP l'affiche avec tout ce qu'un site web peut en déduire.

2. Données réseau et ASN (asn)

Le groupe asn vous indique quel réseau annonce l'adresse, et il fait partie des données IP les plus fiables que vous puissiez obtenir. Chaque IP routable appartient à un système autonome, et cette information provient de la table de routage mondiale plutôt que d'une estimation.

Les valeurs varient selon l'adresse. 1.1.1.1 est revenue avec asn_type: "cdn" et user_type: "content_delivery_network", et Googlebot avec user_type: "search_engine_spider". La sortie Private Relay a renvoyé asn_type: "unknown", connection_type: "unknown" et user_type: "consumer_privacy_network". Une chose a changé depuis juillet : 8.8.8.8 renvoie désormais rpki: "valid", alors que l'exemple de notre documentation affiche encore "invalid".

Le champ à surveiller est connection_type. Une adresse de datacenter sur une connexion grand public mérite un second regard. L'hébergement seul n'est pas de la fraude pour autant : 45.33.32.156 est un simple hébergement et a obtenu 10, allow. Vous pouvez vérifier n'importe quelle adresse avec le contrôle d'IP de datacenter gratuit, et la page API de géolocalisation IP décrit le modèle ASN.

3. Données de géolocalisation (geo)

Le groupe geo place l'adresse sur une carte, et c'est le groupe auquel on accorde le plus souvent trop de confiance. Les 15 champs contenaient des données à chaque requête que nous avons effectuée.

Le pays est fiable, la ville est approximative. Une étude évaluée par des pairs sur la géolocalisation par DNS inverse, fondée sur des données de 2018, a mesuré des erreurs médianes de 11,1 km et 16,7 km pour deux bases de données commerciales. Nous présentons d'autres éléments dans quelle est la précision de la géolocalisation IP. Considérez la ville comme un rayon, jamais comme un point précis, et n'utilisez jamais une IP pour localiser une personne.

Lisez geo_confidence à côté de detection.is_anycast. 1.1.1.1 a renvoyé 0,8 pour Sydney mais est aussi is_anycast: true, parce que la même adresse est annoncée depuis de nombreux endroits à la fois. Pour une adresse anycast, la ville n'est qu'un emplacement plausible parmi plusieurs.

Deux autres lacunes sont apparues. timezone est revenu "none" pour les trois adresses américaines que nous avons interrogées (8.8.8.8, 66.249.66.1 de Googlebot et 45.33.32.156) alors que la ville était renseignée, donc déduisez vous-même le fuseau quand vous en avez besoin. Et la sortie Private Relay 104.28.46.99 a été placée à Luanda, en Angola, alors que la propre liste des sorties d'Apple situe cette plage à Lusaka, en Zambie. Pour les relais, prenez la localisation dans la ligne d'Apple, comme nous l'expliquons dans comparer les IP de relais à la liste des sorties d'Apple.

4. Données WHOIS et d'enregistrement (whois)

Le groupe whois indique qui a enregistré le bloc et quand, à partir de données récupérées via RDAP auprès des cinq registres Internet régionaux. Il ajoute une couche de propriété que la géolocalisation ne voit pas.

La couverture varie selon le registre. 8.8.8.8 et 45.33.32.156 ont renvoyé "none" pour org, netname, status et last_changed, seuls country et registered étant renseignés. L'enregistrement du serveur Mullvad était riche : netname: "NET-31173-185-213-155-0-24", enregistré le 19 juillet 2017, modifié pour la dernière fois le 11 novembre 2025.

Les indicateurs de mots-clés sont des preuves d'appoint, jamais une raison suffisante de signaler une adresse. Les deux valaient false pour les sept adresses, y compris le serveur Mullvad, dont l'org au registre indique « 31173 Services AB infrastructure in Frankfurt, DE. » sans aucune mention de VPN. C'est pourquoi les listes de fournisseurs des sections suivantes comptent davantage.

5. Preuves réseau (network)

Le groupe network contient le DNS inverse et le contact abuse du registre. Trois de ses sept champs sont fictifs aujourd'hui.

abuse_contact est le champ vers lequel vous vous tournez quand vous devez signaler une activité, et il était renseigné pour cinq de nos sept adresses. fcrdns_valid n'est pas un simple booléen : il a renvoyé la chaîne "none" pour la sortie Tor, le serveur Mullvad et le relais, qui n'ont pas de PTR stocké. Un code qui teste === false manquera ce cas.

Ne vous fiez pas à un PTR stocké sans le vérifier. Pour Googlebot 66.249.66.1, le ptr_record stocké appartient à une adresse voisine, alors qu'un dig -x en direct renvoie crawl-66-249-66-1.googlebot.com. Nous avons confirmé la valeur de 8.8.8.8 (dns.google) et celle de 1.1.1.1 (one.one.one.one) avec dig -x le même matin.

open_ports est vide même lorsqu'une sonde a répondu. Il est écrit [] à chaque requête. Notez que le wireguard_open du serveur Mullvad n'est pas un résultat de sonde : il signifie que la liste de serveurs de Mullvad marque ce serveur comme WireGuard. Lisez les résultats de sonde comme openvpn_open dans scoring.detection_methods jusqu'à ce que le champ soit branché.

6. Détection des VPN, proxys, Tor et relais (detection)

Le groupe detection indique si l'adresse anonymise son utilisateur, et comment. Avec 23 champs, c'est le groupe le plus important, et trois d'entre eux sont nouveaux depuis juillet.

vpn_provider est le champ à entourer. La plupart des API savent dire qu'une IP est « un VPN » ; nommer l'opérateur exige une liste de fournisseurs. Nous nommons un VPN à partir des propres listes de serveurs de neuf fournisseurs, d'une liste publique tierce ou d'une courte table de réseaux VPN connus, et vpn_confidence indique quel chemin s'est déclenché : 95 ici signifie la propre liste de Mullvad. Lorsqu'une adresse ne figure sur aucune liste, vpn_provider renvoie "none" même si un handshake prouve qu'il s'agit d'un VPN. Nous retraçons ces chemins dans comment un VPN est nommé grâce à sa propre liste de serveurs, et vous pouvez tester n'importe quelle adresse avec le test de détection VPN.

is_relay et relay_provider fonctionnent en paire. 104.28.46.99 a renvoyé is_relay: true, relay_provider: "iCloud Private Relay", un score de 9 et allow. L'API renvoie aussi "Cloudflare WARP" pour les plages de connexion WARP publiées par Cloudflare, les adresses auxquelles se connecte l'application WARP, et une valeur non documentée "Cloudflare" pour les autres sorties de confidentialité de Cloudflare que la liste d'Apple ne couvre pas.

is_anonymous ne couvre pas les relais. /docs le décrit comme vrai pour tout anonymiseur, relais compris, mais la sortie de relais a renvoyé is_anonymous: false avec anonymity_level: "medium". L'indicateur ne suit que les VPN, proxys et Tor, donc lisez is_relay séparément.

Les trois nouveaux champs de proxy résidentiel sont réservés. Ils sont arrivés lors d'une modification du backend en octobre et ne sont pas encore documentés. La détection des proxys résidentiels n'est pas une fonctionnalité que nous proposons aujourd'hui, donc considérez les cinq champs de proxy résidentiel comme réservés et ne bâtissez pas de règles dessus. Si ce trafic vous inquiète, c'est ici que nous expliquons ce qu'une requête IP peut et ne peut pas voir.

7. Renseignement sur les menaces et les bots (threat)

Le groupe threat indique si l'adresse est connue pour être malveillante ou connue pour être un bot bienveillant. Il compte 25 champs, dont sept sont fictifs.

La sortie Tor remplit l'autre moitié de ce tableau : is_spammer: true, threat_types: ["spammer", "tor"] et dnsbl_sources: ["zen.spamhaus.org"]. Le serveur Mullvad a renvoyé threat_types: ["vpn"], donc le tableau reprend aussi les indicateurs d'anonymiseur.

C'est dans l'objet crawler que se prennent les décisions sur les bots. Pour 66.249.66.1, l'API a renvoyé verified: true, name: "Googlebot", operator: "Google" et verification_method: "ip_range_list", avec une correspondance sur 19 flux officiels de plages de robots provenant de 10 opérateurs. Les catégories que nous avons vues dans les requêtes d'octobre sont search_engine, ai et fetcher. Les noms perdent leurs traits d'union, donc le récupérateur déclenché par l'utilisateur de Google revient sous le nom GoogleUserTriggeredFetcher.

La détection d'usurpation se fait dans votre code. L'API ne voit que l'IP, jamais le User-Agent. Une requête qui se présente comme Googlebot mais renvoie crawler.verified: false n'est pas vérifiée, et c'est à vous de faire cette comparaison. Nous la montrons dans la détection des bots par IP et vérifier les robots d'exploration IA par IP, rDNS et CIDR.

is_cgnat doit adoucir une décision, pas la durcir. Une adresse CGNAT est partagée par de nombreux abonnés, donc le score y est plafonné, et un seul acteur malveillant ne devrait pas bloquer tout un opérateur. Consultez la présentation du renseignement sur les menaces pour les flux qui alimentent ce groupe.

8. DNS inverse (dns)

Le groupe dns reprend trois champs de DNS inverse de network, afin que le code qui n'a besoin que du rDNS puisse lire un seul petit objet. Les valeurs sont identiques aux copies de network dans chaque réponse que nous avons obtenue.

fcrdns_valid est celui auquel se fier. Un PTR qui se résout en retour vers la même IP est une preuve bien plus solide qu'une simple chaîne PTR, que quiconque contrôle la zone inverse peut définir. La même prudence s'applique qu'à la section 5 : comparez un PTR stocké à un dig -x en direct avant de le citer.

9. Scoring de risque (scoring)

Le groupe scoring transforme les preuves en décision. Il compte quatre champs, et detection_methods est celui qui rend le score auditable.

Le fraud_score combine 36 raisons pondérées, et certaines raisons soustraient. Googlebot l'illustre : datacenter_ip et verified_crawler se sont tous deux déclenchés, et le score s'est établi à 0. Un relais ne peut jamais atteindre block, car les scores des relais sont plafonnés à 60. Le recommended_action fait correspondre le score à des tranches :

Affichez confidence comme un nombre, pas comme une chaîne : il arrive avec tout le bruit de la virgule flottante. Nous expliquons le modèle dans le guide du score de fraude IP et dans comment chaque raison fixe le score et sa confiance, et où fixer les seuils dans choisir un seuil de score de fraude IP pour la connexion, l'inscription et le checkout. Vous pouvez évaluer n'importe quelle adresse avec le contrôle du score de fraude IP.

10. Métadonnées (meta)

Le groupe meta date la réponse et identifie la requête. Deux de ses cinq champs signifient autre chose que ce que suggère leur nom.

last_classified_at est l'heure de la réponse, pas celle de la classification. Dans les sept requêtes, il tombait à environ une seconde du moment où nous avions envoyé la requête. Utilisez plutôt last_scanned pour juger de la fraîcheur. Il avait la même valeur que detection.last_seen dans chaque réponse, et les sept étaient datés du 20 octobre.

Des données IP périmées sont des données IP fausses, car les plages changent de mains. Le request_id est ce que vous citez si vous pensez qu'une classification est erronée. La latence côté serveur allait de 0 à 3 ms sur les sept requêtes.

Comment les autres fournisseurs nomment les mêmes champs

D'autres fournisseurs de données IP couvrent un terrain qui se recoupe avec des noms de champs différents, et certains réservent les champs les plus riches aux offres supérieures. Nous avons lu la documentation publique de trois fournisseurs le 22 octobre 2026 et n'avons retenu que ce que ces pages indiquent.

Sources : réponses des services web GeoIP de MaxMind, données de détection de confidentialité d'IPinfo, données ASN d'IPinfo et paramètres de réponse de détection de proxy d'IPQualityScore.

Deux conséquences pratiques en découlent. L'échelle d'un score n'a de sens qu'à côté de ses seuils documentés : le 75 d'IPQualityScore est « suspect », alors que notre 76 est déjà block. Et un champ portant le même nom peut signifier des choses différentes, donc faites correspondre les champs selon leur signification documentée, pas selon leur nom. Notre checklist d'achat pour choisir un fournisseur de données IP en fait un test rapide que vous pouvez mener sur n'importe quelle API.

Quels champs de données IP comptent pour chaque décision

Vous avez rarement besoin des 103 champs à la fois. Associez les champs à la décision, et ignorez les champs fictifs :

Pour une investigation, l'ordre dans lequel vous lisez les groupes compte autant que les champs. Notre guide étape par étape pour enquêter sur une adresse IP fait passer trois vraies IP par douze contrôles passifs qui utilisent ces groupes tour à tour.

Vérifiez vous-même les champs avant de construire

La liste des champs évolue, donc l'habitude la plus sûre est de la compter vous-même. Effectuez une requête et listez les clés terminales :

Le filtre compte chaque tableau comme un seul champ, ignore les éléments de tableau et rajoute country_names comme un champ. Il a affiché 103 pour chacune de nos sept réponses enregistrées. Si votre nombre diffère, comparez les clés avec la référence de l'API et cet article. Si vous testez sans clé, espacez vos appels : la 30e requête sans clé en une minute renvoie déjà 429 et bloque votre IP pendant deux heures.

Questions fréquentes

Quelles données peut-on obtenir d'une adresse IP ?

Bien plus qu'une localisation. Une requête GeoIPHub en direct le 22 octobre 2026 a renvoyé 103 champs en 10 groupes : l'IP elle-même, le réseau (ASN, FAI, type de connexion, RPKI), une géolocalisation approximative, les données de registre WHOIS, les preuves réseau et le DNS inverse, la détection des VPN, proxys, Tor et relais avec le fournisseur nommé lorsqu'il figure sur une liste, les signaux de menace et de robots d'exploration vérifiés, un score de risque explicable de 0 à 100, et des métadonnées de requête. Onze de ces champs sont fictifs et renvoient aujourd'hui une valeur vide fixe.

Une adresse IP peut-elle révéler mon adresse personnelle exacte ?

Non. La géolocalisation IP estime une zone approximative (au mieux une ville ou une région), jamais une adresse postale ni une personne précise. Les résultats au niveau de la ville sont imprécis, et les connexions mobiles, CGNAT et VPN les affaiblissent encore. Quiconque prétend à une précision à l'adresse près à partir d'une seule IP exagère.

Qu'est-ce qu'un ASN dans les données IP ?

Un Autonomous System Number (numéro de système autonome) identifie le réseau qui annonce une adresse IP sur Internet. Par exemple, 8.8.8.8 renvoie AS15169, GOOGLE - Google LLC. L'ASN et son organisation proviennent de la table de routage mondiale, ce qui en fait l'un des champs de données IP les plus fiables, contrairement à une estimation de l'emplacement physique.

Qu'est-ce qu'un score de fraude IP et comment est-il calculé ?

Un score de fraude IP est un nombre unique de 0 à 100 qui résume le niveau de risque d'une adresse. GeoIPHub combine 36 raisons pondérées, soustrait les raisons disculpantes comme un robot d'exploration vérifié, et renvoie les méthodes exactes qui se sont déclenchées ainsi qu'une action recommandée : allow jusqu'à 25, review jusqu'à 50, step_up jusqu'à 75, block au-delà de 75. Une sortie Tor que nous avons interrogée le 22 octobre 2026 a obtenu 100 avec quatre méthodes listées.

Quelle est la différence entre une IP résidentielle et une IP de datacenter ?

Une IP résidentielle est attribuée par un FAI grand public à une connexion domestique ; une IP de datacenter (hébergement) appartient à un fournisseur de cloud ou de serveurs. La distinction se trouve dans les champs asn.connection_type et asn.asn_type. Dans nos sept requêtes d'octobre, le serveur VPN Mullvad, la sortie Tor et Googlebot sont tous revenus avec connection_type datacenter.

Tous les fournisseurs d'API IP renvoient-ils les mêmes champs sur chaque offre ?

Non. La documentation d'IPinfo indique que son offre Core n'inclut que les indicateurs de confidentialité is_anonymous et is_hosting, les champs de confidentialité plus complets étant réservés aux offres Plus, Max et aux API personnalisées. GeoIPHub renvoie tous les champs sur chaque offre, y compris l'offre gratuite de 1 500 requêtes par jour.

Que signifie un rayon de précision en géolocalisation IP ?

Un rayon de précision est la distance, en kilomètres, autour des coordonnées renvoyées à l'intérieur de laquelle se trouve probablement l'emplacement réel. MaxMind le documente sous le nom location.accuracy_radius. GeoIPHub ne renvoie pas de rayon ; il renvoie geo.geo_confidence, une valeur de 0 à 1 qui vaut 0 lorsqu'il n'y a pas assez de preuves pour une ville.