Géolocalisation IP : comment fonctionnent les bases de données, et comment les corriger

Les bases de données de localisation devinent où une adresse IP est utilisée, à partir du routage, de mesures, des fiches des registres et de ce que leur disent les opérateurs de réseau, et les sites web, les services de streaming et les contrôles antifraude agissent sur ces estimations. Un bloc qui change de mains garde souvent son ancienne localisation pendant des semaines. Le remède est un geofeed, un petit fichier qui indique où chaque préfixe est utilisé, référencé depuis la fiche du bloc au registre, puis des demandes aux bases de données qui comptent, et de la patience : comptez six semaines ou plus.

Qui l'utilise, et pourquoi les erreurs coûtent cher

• Le streaming et les droits sur les contenus, où la localisation est liée aux licences : un mauvais pays ou une étiquette d'hébergement bloque purement et simplement un service.
• La recherche et la publicité, pour la langue, la devise et les résultats locaux.
• Les contrôles antifraude et de sécurité, qui signalent les connexions depuis des lieux inattendus.
• La fiscalité, les jeux d'argent et d'autres obligations de conformité, ainsi que les réseaux de diffusion de contenu qui choisissent un serveur.

L'atelier de l'IAB sur la géolocalisation IP de 2025 a estimé la précision des geofeeds au niveau du pays à plus de 95 %, a constaté une précision bien plus faible au niveau de la ville, et n'a trouvé aucun moyen standard pour les réseaux de corriger les données de tiers. Son rapport cite le marché de l'IPv4 d'occasion comme une cause : les blocs changent de place, et « the addresses may remain 'located' in Asia in some databases for weeks or months » (traduction : « les adresses peuvent rester “localisées” en Asie dans certaines bases pendant des semaines ou des mois ») après leur passage en Europe.

D'où les bases tirent leurs données

• Les fiches des registres, auxquelles la plupart accordent le moins de poids. La documentation de la base de données RIPE elle-même indique que son attribut country: « cannot be used in any reliable way to map IP addresses to countries » (traduction : « ne peut être utilisé de façon fiable pour associer des adresses IP à des pays ») : c'est en général le pays du titulaire, pas celui de l'utilisateur.
• Le routage : quels réseaux annoncent et transportent le préfixe.
• La mesure : latence et traceroutes depuis les sondes des fournisseurs eux-mêmes.
• Les noms de DNS inverse et les chemins réseau.
• Les geofeeds que publient les opérateurs, et les corrections qu'ils soumettent.
• Les signaux des appareils et des navigateurs, chez certains fournisseurs.

En dehors de la localisation, la plupart des fournisseurs classent les adresses : hébergement, VPN, proxy, Tor. Ces étiquettes pèsent souvent plus lourd que le pays (voir plus bas).

Le fichier geofeed : RFC 8805

Le RFC 8805 définit un fichier CSV, une ligne par préfixe :

# prefix,country,region,city,postal code
192.0.2.0/24,NL,NL-NH,Amsterdam,
198.51.100.0/24,DE,DE-HE,Frankfurt am Main,
203.0.113.0/24,,,,

• Le préfixe est obligatoire ; le pays est un code ISO 3166-1, la région un code ISO 3166-2 tel que NL-NH, et la ville du texte simple.
• Pas de codes postaux : le champ est obsolète, et « new feeds SHOULD NOT include » it (traduction : « les nouveaux flux NE DEVRAIENT PAS l'inclure »).
• Des champs vides signifient aucune localisation, pour de l'espace pas encore utilisé, plutôt qu'une estimation.
• L'ensemble complet à chaque fois, pas seulement les changements ; le même préfixe deux fois est une erreur.
• UTF-8, lignes terminées par CRLF, servi en HTTPS.
• Une indication, pas un ordre : les fournisseurs confrontent un flux à leurs propres données et peuvent préférer d'autres sources.

Pointer vers le fichier : RFC 9632

Le RFC 9632, qui a remplacé le RFC 9092 en août 2024, explique comment un fournisseur trouve un flux et quelles parties il peut utiliser :

• Depuis la fiche du registre : un attribut geofeed: avec une seule adresse HTTPS ou, là où un registre n'en a pas, une ligne exactement de la forme remarks: Geofeed https://....
• La fiche la plus spécifique l'emporte : une attribution /24 avec sa propre référence prime sur la référence du /22 qui la contient.
• Seules les lignes comprises dans la plage de la fiche comptent ; le reste du fichier est ignoré pour cette fiche.
• Les indications de localisation propres au registre sont ignorées dès qu'un flux existe pour une plage.
• Les collecteurs récupèrent les flux au plus une fois par semaine, à partir des données en masse des registres.
• La signature d'un flux est facultative, et inutilisée en pratique : le validateur RPKI rpki-client a abandonné en janvier 2026 la vérification des flux signés, personne ne prévoyant de s'en servir.

Dans chaque registre

Les bases de données et les plateformes

Vérifié le 16 octobre 2026. Corriger une base ne corrige pas les autres, et plusieurs grandes plateformes ont la leur.

Étiquettes hébergement, VPN et proxy

Un bloc peut être dans le bon pays et quand même être refusé, parce qu'il est étiqueté comme espace d'hébergement ou de VPN. L'Anonymous IP list d'AWS WAF, un groupe de règles géré qu'un site peut activer, bloque les « IP addresses from web hosting and cloud providers » (traduction : « adresses IP d'hébergeurs web et de fournisseurs cloud ») sauf si le site passe outre ; MaxMind, IP2Location et d'autres étiquettent les plages d'hébergement, de VPN, de proxy et de Tor. Ces étiquettes ont leurs propres voies de révision, comme le formulaire de l'équipe de correction de MaxMind et le formulaire de faux positifs d'IPQualityScore, distinctes des corrections de localisation.

Un bloc déplacé ou loué, étape par étape

1. Vérifiez-le avant de le prendre : les principales bases, leurs étiquettes hébergement et proxy, et chaque fiche de registre couvrant le bloc, à la recherche d'anciennes références de geofeed ou d'indications de localisation laissées par des titulaires précédents (contrôler un bloc d'abord).
2. Fixez la localisation réelle par préfixe : toujours le pays, la région et la ville quand vous en êtes sûr, pas de code postal, et des champs vides pour l'espace pas encore utilisé.
3. Publiez le fichier en HTTPS, et vérifiez-le avec un validateur tel que geofeed-finder ou le mm-geofeed-verifier de MaxMind.
4. Référencez-le depuis la fiche de registre la plus spécifique. Pour une location, c'est le titulaire qui s'en charge : il inscrit votre préfixe dans son propre flux, ou donne à votre attribution sa propre référence vers votre fichier. Les deux fonctionnent ; demandez à votre bailleur ce qu'il fait, et prévenez-le avant de déplacer l'espace vers un autre pays.
5. Supprimez les indications contradictoires, comme les références de geofeed périmées et les lignes geoloc: erronées.
6. Mettez le routage en accord : annoncez le préfixe exact là où se trouvent ses utilisateurs, avec un ROA et un objet route valides. L'espace qui passe par un tunnel est situé au point de présence du tunnel.
7. Soumettez aux fournisseurs qui comptent, avec l'adresse du flux, et demandez séparément la révision des étiquettes hébergement ou VPN erronées.
8. Vérifiez de nouveau après une, deux et six semaines. À la fin d'une location, supprimez ou videz les lignes du bloc, pour que l'utilisateur suivant n'en hérite pas.

Vérifier où apparaît un bloc

RIPEstat répond avec les données gratuites GeoLite de MaxMind pour n'importe quel préfixe :

curl -s "https://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=203.0.113.0/24"

Remplacez 203.0.113.0/24, une plage réservée à la documentation, par votre bloc. MaxMind qualifie ses données gratuites GeoLite City de « considerably less accurate » (traduction : « nettement moins précises ») que ses données payantes, et les plateformes qui ont leur propre base, comme Google, n'y figurent pas. Vérifiez aussi quelques adresses sur les services dont dépendent vos utilisateurs.

Combien de temps cela prend

La modification au registre est immédiate. Les collecteurs récupèrent les flux chaque semaine, les fournisseurs examinent et publient selon leur propre calendrier, et beaucoup de sites utilisent une copie téléchargée qu'ils mettent à jour quand ils le décident. Pour les nouvelles adresses, Cloudflare indique que « IP geolocation will take at least six weeks to update across databases » (traduction : « la géolocalisation IP mettra au moins six semaines à se mettre à jour dans les bases de données »). Aucun fournisseur ne garantit l'acceptation ni le délai.

La place de RTM Networks

Avec chaque location chez nous, les corrections de géolocalisation se font sur demande : dites-nous où les adresses sont utilisées, et nous référençons un geofeed pour le bloc depuis sa fiche au registre, la nôtre ou la vôtre, et demandons aux principales bases de localisation de corriger les leurs. La vitesse à laquelle chacune suit dépend d'elle.