Vous êtes à Shanghai, mais la recherche IP indique une autre ville ; deux sites web consultent la même adresse, l'un affiche les États-Unis, l'autre le Canada. Face à de tels résultats, l'intuition est de penser qu'« une base de données est forcément erronée ». Mais avant de comparer les bases, il convient de confirmer : comparez-vous la même adresse, le même type de localisation, ou des champs aux noms proches mais aux significations différentes ?
La géolocalisation IP est une estimation de la position d'une adresse réseau, pas une localisation de l'appareil. Les différentes plateformes utilisent des sources de données, des dates de mise à jour et des granularités de localisation différentes ; en cas d'incohérence, vérifiez d'abord l'adresse et les champs avant de décider s'il faut corriger.
Cet ordre est important. Sinon, vous pourriez prendre la position de la sortie réseau pour la vôtre, ou contredire une localisation au niveau de la ville en vous appuyant sur le lieu d'enregistrement, et finalement soumettre une demande de modification au mauvais endroit.
Le terme « localisation » peut recouvrir quatre types d'informations
De nombreuses pages de recherche n'indiquent que « pays », « région » ou « localisation », sans préciser la signification des données. En réalité, les informations suivantes ne sont pas interchangeables.
Information affichée | Objet décrit | Points de vigilance lors de la comparaison |
|---|---|---|
Géolocalisation IP | Position estimée par la base de données : lieu d'utilisation ou sortie réseau | Y a-t-il une plage de localisation, un degré de confiance et une date de mise à jour ? |
Informations d'enregistrement des ressources | Enregistrements d'enregistrement des ressources d'adresses IP et des organisations associées | L'enregistrement ne prouve pas la position de l'appareil terminal |
Localisation par navigateur ou appareil | Position de l'appareil obtenue avec les autorisations appropriées | Peut utiliser les capacités de l'appareil comme le GPS, pas seulement la recherche IP |
Contenu local fourni par le site web | Contenu régional choisi par le service selon sa propre logique | Peut aussi être influencé par les paramètres du compte, la langue ou l'historique des préférences |
La présentation de Whois/RDAP par l'ARIN explique l'utilisation des informations d'enregistrement pour la recherche. C'est une couche de données différente de l'estimation par les bases géographiques de « l'endroit où cette adresse est actuellement utilisée ».
La documentation de l'API Geolocation du MDN indique que les sites web, après avoir obtenu l'autorisation de l'utilisateur, peuvent obtenir la position grâce aux capacités de localisation disponibles sur l'appareil. Ainsi, le fait qu'une application cartographique sache dans quelle rue vous êtes ne signifie pas qu'un autre site de recherche IP devrait offrir la même précision.
Pourquoi une même adresse peut-elle correspondre à des localisations différentes ?
L'utilisation de l'adresse a changé, mais les bases de données ne se mettent pas toutes à jour en même temps
Les ressources d'adresses peuvent être réattribuées, sous-louées ou utilisées pour de nouvelles sorties réseau. Les services de géolocalisation ont besoin de processus distincts pour détecter les changements, les vérifier et publier les mises à jour ; les sites qui utilisent des bases de données hors ligne doivent également déployer effectivement les nouvelles versions dans leurs systèmes.
Par conséquent, « le fournisseur de données a corrigé » et « tous les sites utilisant ces données ont été mis à jour » sont deux choses différentes. Continuer à voir d'anciens résultats peut provenir du fournisseur de données, ou de la base de données locale ou du cache côté utilisateur.
Il n'existe pas de délai de mise à jour fixe applicable à toutes les plateformes. On ne peut pas conclure qu'une soumission est invalide simplement parce que rien n'a changé après une journée ; on ne peut pas non plus promettre qu'une correction à un endroit sera synchronisée au même moment sur les autres plateformes.
La sortie réseau n'est pas nécessairement proche de l'utilisateur
Les réseaux mobiles, les réseaux d'entreprise et les VPN peuvent séparer la position de l'appareil de la position de la sortie publique. Les bases de données géographiques parviennent parfois à bien estimer la position de la sortie, mais ne peuvent pas localiser la personne qui utilise cette sortie.
La documentation sur la précision de géolocalisation de MaxMind traite spécifiquement des scénarios comme les réseaux mobiles et les services de protection de la vie privée, comme les VPN et les proxys, et indique clairement que les données géographiques IP ne suffisent pas à identifier un foyer, un individu ou une adresse précise.
Ainsi, si une personne est dans la ville A alors que la sortie est localisée dans la ville B, cela n'indique pas nécessairement une anomalie de ligne. Il faut d'abord clarifier si vous souhaitez connaître la position de l'appareil, ou la position réseau vue par les services externes.
Les deux plateformes offrent des précisions différentes
Qu'une plateforme indique un pays et une autre une ville ne signifie pas que la seconde est forcément plus précise. Un champ plus détaillé peut n'être qu'un point représentatif dans une zone ; l'absence d'affichage du rayon de localisation ne veut pas dire que ce rayon n'existe pas.
Même si le marqueur sur la carte semble tomber sur un bâtiment précis, on ne peut pas en déduire que le serveur ou l'utilisateur se trouve dans ce bâtiment. Afficher plus de décimales pour la latitude et la longitude n'augmente que la précision d'affichage, pas automatiquement l'exactitude des données.
Si la source de données fournit une plage de localisation, il faut lire le point et la plage ensemble. Sinon, il faut éviter de considérer un nom de ville comme une position vérifiée sur le terrain.
Un réseau du même nom ne signifie pas que chaque adresse a le même usage et la même position
Une organisation peut opérer dans plusieurs régions. Un même ASN peut contenir des plages d'adresses de régions et d'usages différents.
Le nom de l'organisation et l'ASN aident à vérifier le contexte réseau, mais ne permettent pas à eux seuls de localiser toutes les adresses d'un réseau dans une seule ville. Une abréviation de ville dans le DNS inverse n'est qu'un indice ; le nom d'hôte peut provenir d'une ancienne convention de nommage et ne remplace pas les autres preuves.
Avant de diagnostiquer, assurez-vous d'abord de bien identifier « la même adresse IP »
L'erreur de comparaison la plus courante ne se trouve souvent pas dans la base de données, mais dans l'objet de la requête.
Copiez d'abord l'adresse publique complète, ne vous contentez pas de mémoriser le pays et l'opérateur. Vérifiez notamment si les deux pages affichent respectivement une adresse IPv4 et une adresse IPv6 : ce ne sont pas la même adresse, et on ne doit pas les utiliser directement pour mesurer la cohérence entre deux bases de données.
Notez également l'heure de la requête et vérifiez que les paramètres réseau n'ont pas changé en cours de route. La sélection automatique de ligne par le proxy, la reconnexion du réseau mobile, ou l'utilisation de règles de proxy différentes par le navigateur et d'autres applications peuvent modifier la sortie observée.
Vous pouvez d'abord enregistrer le résultat actuel via Recherche d’adresse IP, puis comparer en utilisant la même adresse comme objet de requête explicite. Si vous saisissez un nom de domaine, notez qu'il peut résoudre vers plusieurs adresses ; comparer différents serveurs renvoyés par un domaine n'équivaut pas à comparer la même adresse IP.
Comment transformer les écarts de localisation en un problème traitable ?
Empiler des captures d'écran en disant « vous êtes inexacts » est généralement moins utile que l'ensemble d'informations suivant.
L'adresse IP complète interrogée, ainsi que son type IPv4 ou IPv6.
L'heure et le fuseau horaire de la requête, pour éviter de considérer des résultats d'instants différents comme des observations simultanées.
Le nom du champ de chaque résultat : pays d'enregistrement, pays de localisation, ville, ou autre position.
La source des données, la version ou la date de mise à jour ; si ces informations sont impossibles à obtenir, indiquez honnêtement qu'elles ne sont pas fournies.
Ce que vous estimez erroné, ainsi que les éléments qui appuient ce jugement.
Par exemple, « les deux plateformes donnent des pays de localisation différents pour la même IPv4 » est plus précis que « les localisations des deux sites diffèrent » ; « la plage qui vient de nous être attribuée affiche encore l'ancienne ville » se rapproche davantage d'un problème vérifiable par le fournisseur de réseau et le responsable de la maintenance des données.
Les preuves ont aussi une force variable. La zone de livraison indiquée dans le contrat de service, les déclarations de l'opérateur réseau et les informations d'utilisation des ressources vérifiables sont généralement plus probantes que le fuseau horaire configuré dans le système d'exploitation du serveur. Le fuseau horaire peut être modifié et ne peut pas prouver la position physique.
À qui s'adresser pour la correction, au lieu de soumettre la demande à tous les sites
Vous êtes un utilisateur d'un réseau haut débit ou mobile ordinaire
Demandez d’abord à votre opérateur s’il existe une sortie centralisée, une passerelle interrégionale ou un ajustement récent de l’attribution des adresses. Si la sortie réseau se trouve déjà dans une autre région, modifier la base de données géographique ne peut pas transformer le chemin réel en une sortie locale.
Si seule la région de contenu d’une application ne correspond pas à vos attentes, alors que les résultats de plusieurs bases de données IP concordent, vérifiez aussi les autorisations de localisation et les paramètres régionaux du compte de cette application. Dans ce cas, le problème ne vient pas nécessairement de la base de données IP.
Vous avez loué un proxy, un VPS ou une adresse publique fixe
Demandez au fournisseur de préciser le mode de livraison réel et la région, et vérifiez si l’adresse vient d’être déplacée ou réattribuée. Ne considérez pas uniquement l’option de région affichée sur la page de vente comme preuve définitive de l’emplacement.
Si la correction concerne tout un préfixe, il est généralement plus approprié que l’opérateur réseau qui contrôle la ressource la traite de manière unifiée. Le Geofeed peut aider les opérateurs réseau à publier des informations géographiques sur un préfixe, mais la RFC 8805 réserve aussi explicitement un espace pour que les utilisateurs vérifient l’autorité et l’exactitude ; publier un fichier n’est pas une instruction de mise à jour obligatoire pour toutes les bases de données.
Vous savez déjà clairement quelle est la source de données erronée
Utilisez le canal officiel de cette source de données. Par exemple, MaxMind fournit dans sa documentation un portail de correction des données géographiques. Soumettez les faits vérifiables conformément aux exigences, au lieu de demander qu’elle modifie l’adresse pour qu’elle corresponde à la région que vous souhaitez afficher.
La correction vise à rapprocher les données de l’utilisation réelle, et non à créer une fausse attribution à un pays ou à une ville. Lors de la soumission, il n’est pas non plus nécessaire de divulguer l’adresse précise de votre domicile, vos identifiants ou des captures d’écran de l’interface d’administration ; ne fournissez que les informations nécessaires à un interlocuteur de confiance.
Après la correction, comment confirmer que le problème est vraiment résolu ?
Conservez les enregistrements antérieurs à la soumission, attendez que le responsable de la maintenance confirme le traitement, puis interrogez à nouveau la même adresse et le même champ, et vérifiez si le site Web précédemment concerné a également adopté le nouveau résultat. Les deux peuvent ne pas être synchronisés.
Si les données IP ont changé, mais qu’un service affiche encore l’ancienne région, orientez le problème vers l’utilisateur du service : utilise-t-il une autre source de données, conserve-t-il un cache, ou existe-t-il encore un paramètre régional au niveau du compte ? Continuer à modifier des données déjà correctes n’aide généralement pas.
Quant à savoir si le service est utilisable, il faut le vérifier séparément par une Tests d’accès aux services et un accès réel normal. Une localisation correcte ne signifie pas que le service est nécessairement ouvert ; un service accessible ne prouve pas non plus en retour que la localisation de la ville est correcte.
Les informations géographiques IP servent à vous aider à comprendre le contexte réseau, à détecter des écarts évidents et à lancer des corrections. Les considérer comme un jugement comportant une source et des limites de précision, plutôt que comme une preuve d’adresse précise jusqu’à la rue, correspond davantage à leur véritable usage.
Localisation de pays différents sur les réseaux transnationaux : pays d’enregistrement, Anycast et position de sortie
Prenons d’abord un scénario hypothétique : un fournisseur de services transnational enregistre ses ressources d’adresses au Canada, le service réel est déployé aux États-Unis, et les bases de localisation commerciales ainsi que les requêtes d’enregistrement affichent donc des pays différents. Ici, il n’est pas nécessaire de supposer l’Anycast, et une simple différence de pays ne permet pas non plus de déterminer l’Anycast. Il faut d’abord distinguer si l’on lit le pays d’enregistrement, une estimation de localisation commerciale, ou un nœud de service effectivement observé lors d’une requête particulière ; ces éléments décrivent des faits différents, et on ne peut pas déterminer qui a tort en se fondant uniquement sur une « incohérence entre deux pays ».
Le pays d’enregistrement provient des enregistrements de ressources dans la base de données RDAP ou Whois ; il décrit l’attribution administrative du bloc d’adresses, et non la région où se trouve l’équipement terminal. Par exemple, pour une plage d’adresses enregistrée au Canada mais utilisée depuis longtemps par un centre de données américain, la base de données géographique peut indiquer une ville américaine, tandis que le pays d’enregistrement reste le Canada. Ces deux éléments relèvent de champs différents et ne doivent pas être directement comparés. Lorsque vous consultez plusieurs résultats de requête, vérifiez d’abord si la page indique « pays » (country), « pays d’enregistrement » (registered country) ou « emplacement » (location).
L’Anycast est une autre possibilité qui exige des preuves indépendantes. La même adresse de service peut être fournie depuis plusieurs emplacements, et la politique de routage détermine l’instance atteinte par la requête actuelle, sans garantir la sélection du nœud physiquement le plus proche. Ce n’est que lorsque des preuves telles qu’une déclaration de l’opérateur, des mesures multi-sites ou une identification d’instance le confirment qu’il est approprié de discuter de l’influence de l’Anycast sur la localisation. Que deux bases commerciales affichent des pays différents ne prouve ni l’Anycast, ni n’exclut une base de données obsolète, un changement d’attribution ou un déploiement transnational ordinaire.
Lors de la vérification, consultez d’abord l’organisation, l’étendue et les événements du RDAP, puis utilisez les observations BGP comme contexte de routage. Un seul ASN peut couvrir plusieurs pays, et la présence de plusieurs ASN d’origine pour un même préfixe a aussi plusieurs explications ; aucun de ces éléments ne permet à lui seul de déterminer la ville où se trouve le service. Si vous pouvez obtenir une description régionale de l’opérateur, un Geofeed maintenu ou des mesures multi-points, indiquez pour chacun leur date et leur portée, et réduisez progressivement le jugement, au lieu de rejeter directement la localisation commerciale avec le pays d’enregistrement.
Lors du diagnostic, notez d’abord l’adresse IPv4/IPv6 complète, l’heure de la requête et le nom du champ indiqué par chaque plateforme. Si une adresse appartient à un réseau Anycast ou à un cloud transnational, ne soumettez pas précipitamment une correction ; consultez plutôt les annonces de routage de ce préfixe et la documentation publique de l’opérateur réseau. Tout jugement du type « c’est certainement faux ici » doit être formé en combinant les informations d’enregistrement, les observations BGP et les preuves de sortie réelle. Pour en savoir plus sur les relations entre RDAP, ASN, BGP et les preuves de localisation, consultez le RDAP, ASN, BGP et RPKI : comprendre les données d’une IP.
Demande de correction : hiérarchie des preuves, enregistrement temporel et limites de propagation
Les documents de correction doivent correspondre au champ spécifique. La description du déploiement par l’opérateur pour cette plage d’adresses, un Geofeed maintenu et la région de livraison du service peuvent fournir des indices sur l’emplacement d’utilisation ; la latence, le traceroute et le DNS inverse fournissent des observations auxiliaires. Les enregistrements du plan de contrôle BGP n’indiquent pas directement l’emplacement physique du serveur et ne doivent pas être cités comme preuve déterminante de la salle des machines. Tous les documents doivent être vérifiés quant à leur authenticité, leur date de mise à jour, leur domaine d’application et leur adéquation à l’adresse actuelle, plutôt que d’établir un classement d’autorité universel.
Des documents plus faibles mais consultables comprennent : les rapports d’utilisateurs, le réglage du fuseau horaire du système d’exploitation du serveur, la langue du contenu du site Web, etc. Le fuseau horaire du système d’exploitation peut être modifié librement et ne prouve pas l’emplacement physique de l’appareil ; la langue du site Web ou les paramètres régionaux du compte reflètent plus probablement des préférences de contenu que l’attribution de l’IP. Lors de la soumission d’une correction, ne téléversez pas l’adresse précise de votre domicile, vos identifiants ou des captures d’écran de l’interface d’administration ; fournissez des informations publiques ou opérationnelles suffisantes pour permettre au responsable de la maintenance des données de juger de l’emplacement d’utilisation de l’adresse.
Consignez la date, l’heure et le fuseau horaire de chaque requête. Prenons un exemple hypothétique : une adresse est réattribuée à une nouvelle région en mars 2024, mais la base de géolocalisation n’est toujours pas à jour en mai. Une capture de janvier risque donc de constituer une preuve obsolète pour la demande de correction. Comparer les résultats d’une même adresse à différentes dates aide à distinguer la mise à jour soudaine d’une source d’un changement qui se propage entre plusieurs sources. Présentez une chronologie des anciens et des nouveaux enregistrements, en indiquant la source de chaque résultat. Cela facilite l’examen des éléments fournis, sans garantir l’acceptation de la correction ni un délai de traitement.
Les fournisseurs de données et les sites qui les utilisent sont des maillons distincts de la chaîne de mise à jour. MaxMind, IP2Location et d'autres sources peuvent mettre à jour leurs bases de données en premier, mais les sites qui consomment ces données doivent encore les télécharger, les déployer et éventuellement configurer un cache. Par conséquent, si une source affiche un nouveau résultat alors qu'un site continue de montrer l'ancien, cela ne signifie pas forcément que la source n'a pas été corrigée. Dans ce cas, il faut vérifier séparément : si la source a bien été modifiée ; quelle version de la base le site utilise ; et si le site a mis en place son propre cache ou une logique de repli.
Aucun canal de correction ne doit promettre que « les autres plateformes se synchroniseront dans un délai fixe après la modification ». La publication d'un geofeed ou une correction officielle n'est que le point de départ de la chaîne de mise à jour. Certaines bases de données hors ligne ne publient des mises à jour que tous les quelques mois, et certains sites utilisent des données auto-hébergées ou tierces plutôt que de s'abonner directement à la source. Vous ne pouvez pas vous attendre à ce qu'une seule demande modifie simultanément tous les résultats de recherche. Après une soumission réussie, interrogez à nouveau la même adresse et le même champ après la publication de la nouvelle version, et confirmez à au moins deux moments distincts. Si une plateforme ne se met manifestement pas à jour sur le long terme, il convient de s'interroger sur la manière dont elle utilise les données, plutôt que de soumettre sans cesse des données déjà correctes.
Enfin, l'objectif d'une correction est de rapprocher les données de l'utilisation réelle du réseau, et non de modifier l'adresse pour qu'elle affiche le pays ou la ville que vous souhaitez. Si les preuves sont insuffisantes pour démontrer une erreur de localisation, ou si la source indique que l'adresse est liée à Anycast ou à une sortie dynamique, poursuivre les soumissions risque d'être sans effet. Vous pouvez consulter la page Sources de données et méthodologie pour mieux comprendre comment les bases de données géographiques sont mises à jour et validées.
