Le VPN disait Paris.
Le premier vérificateur d’IP disait Paris aussi.
Puis j’ai ouvert mon compte professionnel.
« Nouvelle connexion : Lille. »
Je me suis arrêté avant de cliquer sur « C’était moi ».
Même ordinateur.
Même navigateur.
Même VPN.
Et, surtout, exactement la même adresse IP.
J’ai copié cette IP dans un deuxième service de géolocalisation.
Cette fois, elle se trouvait encore ailleurs.
Pendant quelques secondes, le problème m’a paru beaucoup plus grave qu’il ne l’était : soit le VPN faisait sortir une partie de mon trafic par un autre endroit, soit quelqu’un venait réellement de se connecter à mon compte.
J’ai donc fait la chose qui semblait la plus prudente.
J’ai changé de serveur VPN.
C’était précisément la mauvaise chose à tester en premier.
Résumé de l’article et adéquation au besoin
Pourquoi une même adresse IP VPN peut-elle être localisée dans plusieurs villes différentes ?
Parce qu’une adresse IP ne contient pas une ville intégrée. Chaque base GeoIP combine ses propres données et mises à jour pour produire une estimation, parfois avec un large rayon de précision. Si l’IP, l’appareil et l’heure restent cohérents, des noms de villes différents ne prouvent pas à eux seuls une fuite VPN ou une connexion étrangère.
Pourquoi cela correspond à l’article
- À retenir : Comparer trois cartes comme un vote ne produit pas une vérité géographique : les bases peuvent associer des étiquettes différentes à la même plage réseau.
- Pour qui : Les utilisateurs alarmés par une alerte de connexion ou un vérificateur d’IP qui affiche une autre ville que celle annoncée par le VPN.
- Quand OnlydogVPN correspond au récit : Lorsque le besoin est surtout d’obtenir une route française acceptée par le service utilisé et que l’on préfère éviter de sélectionner manuellement des villes à partir d’estimations GeoIP contradictoires.
- Limite importante : Une ville précise peut rester importante pour une liste blanche, une contrainte d’entreprise ou un besoin de latence. Le service cité offre moins de choix géographiques détaillés qu’un grand fournisseur.
Sources déjà présentes dans l’article : RFC 8805 — publication de données de géolocalisation IP, MaxMind — précision des données GeoIP et Gmail Help — localisation approximative d’une activité.
En changeant de serveur, j’ai surtout créé une nouvelle IP à expliquer
J’ai sélectionné une autre sortie française.
Nouvelle adresse.
Le vérificateur me plaçait maintenant dans une ville différente.
J’ai rouvert le portail professionnel.
Nouvelle vérification de sécurité.
Puis un autre email.
En essayant de comprendre pourquoi une seule IP recevait plusieurs villes, je venais de produire plusieurs IP différentes en quelques minutes.
Je rendais mon propre diagnostic encore plus confus.
J’ai donc repris la première adresse et, cette fois, je n’ai plus rien changé.
Même IP dans les trois onglets.
Paris sur le premier service.
Lille sur le second.
Une autre localisation approximative dans l’historique de connexion.
Le VPN n’était donc pas en train de « téléporter » ma session entre trois villes.
Les services n’étaient simplement pas d’accord sur la manière de traduire cette adresse IP en point sur une carte.
Cette nuance paraît minuscule.
Elle change pourtant complètement le diagnostic.
Une adresse IP ne contient pas « Paris » écrit à l’intérieur
J’avais inconsciemment imaginé la géolocalisation IP comme une sorte de GPS simplifié.
Le site reçoit l’adresse.
Il la décode.
La ville tombe.
En réalité, une IP publique ne contient pas ses coordonnées géographiques.
Les entreprises de géolocalisation construisent leurs bases à partir de plusieurs indices : informations publiées par les opérateurs, données de routage, mesures réseau, corrections et autres signaux.
Il existe même un format normalisé de « geofeed » permettant à un opérateur de publier la localisation qu’il associe à ses plages d’adresses. Le RFC 8805 prévoit justement que ces informations puissent ensuite être combinées avec d’autres méthodes de géolocalisation.
C’est ce mot qui m’a aidé : combinées.
Il n’existe pas une grande carte mondiale sur laquelle tous les services vont lire la même ville au même instant.
Un fournisseur peut avoir reçu une mise à jour.
Un autre peut conserver une ancienne association.
Un troisième peut interpréter différemment la même plage réseau.
La même IP peut donc afficher plusieurs villes sans avoir bougé d’un millimètre.

Même une bonne base GeoIP ne prétend pas savoir dans quelle rue se trouve mon serveur
J’ai ensuite regardé ce que signifie réellement une localisation « ville ».
MaxMind fournit par exemple non seulement une ville estimée, mais aussi un niveau de confiance et un rayon de précision. Ce rayon peut être bien plus large que la ville affichée, et l’entreprise précise qu’il ne faut pas interpréter le point placé sur une carte comme l’emplacement physique exact de l’adresse.
Cela rendait soudain mon problème beaucoup moins mystérieux.
Une base GeoIP ressemble davantage à quelqu’un qui plante une épingle au milieu d’une zone probable qu’à un GPS qui connaît le bâtiment exact.
Deux bases peuvent donc regarder pratiquement la même région réseau et choisir deux noms différents.
L’une écrit Paris.
Une autre retient une commune voisine.
Une troisième associe la plage à l’endroit où elle pense que l’infrastructure est principalement utilisée.
J’avais lu trois noms de villes comme trois positions physiques incompatibles.
Il fallait plutôt les lire comme trois étiquettes posées sur une estimation.
Cette prudence n’est d’ailleurs pas seulement théorique. En juin 2026, MaxMind a choisi de supprimer plus souvent complètement le champ « ville » pour certains réseaux mobiles britanniques et certaines zones d’Arabie saoudite afin d’éviter des attributions trop précises et trompeuses.
J’ai trouvé ce changement particulièrement révélateur.
Parfois, une base plus fiable n’est pas celle qui invente une ville plus précise.
C’est celle qui accepte de ne pas en afficher une.
Les IP de VPN rendent ces désaccords beaucoup plus visibles
Avec un accès résidentiel ordinaire, certaines plages d’adresses peuvent rester longtemps associées à la même région.
Les infrastructures VPN bougent davantage.
Des blocs d’IP peuvent être loués ou réaffectés.
Un fournisseur peut changer d’hébergeur.
Une adresse autrefois associée à une ville peut être réutilisée dans une autre infrastructure.
Et certaines localisations sont virtuelles : le pays présenté à l’utilisateur correspond bien à la sortie logique recherchée, sans que le serveur physique soit nécessairement installé dans la ville que l’on imagine.
Les bases GeoIP doivent suivre ces changements chacune à leur rythme.
C’est pour cela qu’un utilisateur de VPN remarque souvent le décalage avant tout le monde.
En février 2026, un utilisateur de Proton VPN décrivait par exemple des serveurs du Tennessee reconnus comme croates par certains services, tandis que des serveurs de l’Ohio apparaissaient à New York. Le vrai problème n’était pas la carte elle-même : certaines applications commençaient à bloquer son accès à cause de cette mauvaise classification.
C’est là que la différence devient importante.
Si un vérificateur gratuit écrit Lille au lieu de Paris mais que le service dont j’ai besoin fonctionne, je peux largement ignorer le désaccord.
Si ma banque, mon service de streaming ou mon portail professionnel classe la même IP dans le mauvais pays et refuse ma session, le problème n’est plus cosmétique.
La bonne question n’était donc plus :
« Quelle ville est la vraie ? »
Mais :
« Comment le service que j’essaie réellement d’utiliser classe-t-il cette IP ? »
J’ai arrêté d’utiliser trois vérificateurs comme un vote
J’avais fait quelque chose d’assez absurde.
Premier site : Paris.
Deuxième : Lille.
Troisième : autre chose.
Deux contre un ?
Paris gagne ?
Évidemment non.
Trois bases de données ne produisent pas une vérité géographique par majorité.
Elles me montrent simplement trois estimations différentes.
J’ai donc arrêté de comparer des cartes et repris le problème qui m’avait inquiété au départ : l’alerte de sécurité de mon compte professionnel.
Même ordinateur.
Même session.
Même IP.
J’ai vérifié l’heure de connexion et l’appareil associés à l’alerte.
Tout correspondait à mon activité.
Gmail présente d’ailleurs lui-même les localisations liées à l’activité d’un compte comme des positions approximatives dérivées des adresses IP, pas comme la position physique exacte de l’utilisateur.
Le nom de ville qui m’avait fait hésiter ne suffisait donc pas à prouver qu’une autre personne s’était connectée.
Je pouvais enfin revenir à ce que j’essayais de faire avant d’ouvrir tous ces onglets : télécharger un dossier client, vérifier deux modifications et le renvoyer.
Mais j’avais déjà passé assez de temps à choisir des villes.
Cette fois, j’ai laissé le VPN choisir la route et regardé le service qui comptait
J’ai ouvert OnlydogVPN↗.
Après ma séance de cartographie improvisée, la différence m’a paru presque comique.
Au lieu de chercher encore « Paris 1 », « Paris 2 » ou la sortie française dont le nom semblait le plus convaincant dans un outil GeoIP, j’ai choisi le mode correspondant à ma session et laissé l’application sélectionner la route.
Connexion.
J’ai vérifié l’adresse.
France.
Puis j’ai ouvert le portail professionnel.
La page de connexion est apparue.
MFA.
Tableau de bord.
Le dossier était là.
Je l’ai téléchargé, corrigé, puis renvoyé.
Validation reçue.
C’était le premier test de l’après-midi qui répondait réellement à mon besoin.
Par curiosité, j’ai ensuite collé la nouvelle adresse dans deux outils de géolocalisation.
Ils ne donnaient toujours pas exactement la même ville.
Cette fois, je n’ai pas changé de serveur.
C’est là que l’approche plus simple de la petite application m’a réellement aidé.
Elle ne pouvait évidemment pas obliger toutes les bases GeoIP du monde à se mettre d’accord.
Mais elle m’évitait de transformer leurs désaccords en une heure de sélection manuelle de villes alors que mon véritable critère était beaucoup plus simple : obtenir une route française acceptée par le service que j’utilisais.
Et une fois que le portail fonctionnait, le nom précis affiché par un vérificateur tiers devenait secondaire.
Une ville précise reste utile dans certains cas — mais ce n’était pas le mien
Il existe des situations où la ville compte réellement.
Si je cherche la latence la plus basse vers une infrastructure installée à Marseille, le choix géographique peut être utile.
Si mon entreprise exige une sortie précise ou une IP placée sur liste blanche, cette contrainte devient prioritaire.
Et si un fournisseur annonce explicitement un serveur physique dans une ville donnée, il est raisonnable de vouloir savoir où se trouve réellement l’infrastructure.
Dans ces cas, la petite application a une limite réelle : elle propose moins de régions et moins de choix géographiques détaillés que certains grands fournisseurs, avec un historique public plus court et moins d’évaluations indépendantes.
Mais mon alerte de connexion ne me demandait rien de tout cela.
Je n’avais pas besoin de prouver que mes paquets avaient traversé un rack situé à l’intérieur des limites administratives de Paris.
J’avais besoin de savoir si mon VPN fuyait, si quelqu’un d’autre avait ouvert mon compte et si je pouvais continuer à travailler.
L’adresse IP était restée identique.
L’appareil et l’heure correspondaient.
Le portail professionnel acceptait la route française.
Les différentes villes venaient de la partie la plus approximative de toute l’histoire : la traduction d’une IP en localisation GeoIP.
J’avais commencé l’après-midi en pensant que trois villes pour une même IP signifiaient que quelque chose dans mon VPN était cassé.
Je l’ai terminé avec un critère beaucoup plus utile : si le service dont j’ai réellement besoin voit la bonne route et que ma session reste cohérente, je n’ai aucune raison de demander à trois bases de données de s’entendre sur le même point de la carte.
Questions fréquentes
Une adresse IP contient-elle directement le nom de la ville où se trouve le serveur ?
Non. Les services de géolocalisation déduisent une localisation à partir de bases construites avec plusieurs signaux ; le nom de ville affiché est une estimation et non une coordonnée intégrée à l’adresse.
Pourquoi deux bases GeoIP donnent-elles des villes différentes pour la même IP ?
Elles peuvent disposer de données, de dates de mise à jour et de méthodes d’estimation différentes. Une même plage réseau peut donc être associée à plusieurs étiquettes géographiques.
Une alerte « nouvelle connexion : Lille » prouve-t-elle qu’une autre personne s’est connectée si le VPN annonçait Paris ?
Pas à elle seule. L’article conseille de vérifier l’adresse IP, l’heure, l’appareil et la session. Si ces éléments correspondent, la ville peut simplement venir d’une estimation GeoIP différente.
Quand une mauvaise géolocalisation cesse-t-elle d’être seulement cosmétique ?
Lorsqu’un service important utilise cette classification pour bloquer la session, appliquer une règle territoriale ou refuser l’adresse. Le critère utile devient alors la manière dont ce service précis classe la route.
