Comment savoir si un serveur français est physique ou virtuel ? J’ai appris que l’adresse IP ne pouvait pas me le dire

Le serveur disait Paris. Le site de vérification d’IP disait Paris. Un deuxième site disait Paris aussi.

Et pourtant, assis à Lyon avec une fibre largement assez rapide, j’avais l’impression que ma connexion faisait un détour beaucoup plus long.

Je m’en étais aperçu pendant une session de bureau à distance.

Sans VPN, le poste parisien répondait presque immédiatement.

VPN activé, serveur « Paris », le curseur commençait à avoir ce petit retard qui ne casse rien mais finit par rendre chaque manipulation agaçante.

J’ai changé de serveur. Même chose. Mon premier diagnostic était évident : ce serveur français doit être virtuel et se trouver physiquement dans un autre pays.

J’ai donc fait ce qui me paraissait logique. J’ai copié mon adresse IP dans trois outils de géolocalisation. France. Île-de-France.

Paris. J’étais rassuré pendant environ trente secondes. Puis j’ai compris que je venais de poser trois fois la mauvaise question.

« IP française » et « machine physiquement en France » ne veulent pas dire la même chose

Dans le vocabulaire des VPN, un « emplacement virtuel » ne signifie généralement pas que le serveur n’existe pas.

Il existe bien une machine quelque part.

La différence est que l’adresse IP présentée à Internet correspond au pays choisi dans l’application, tandis que le matériel qui termine réellement le tunnel peut se trouver dans un autre pays.

ExpressVPN l’explique directement dans sa documentation : pour la majorité de ses emplacements, le serveur physique et l’adresse IP correspondent au même pays. Pour certaines destinations, l’adresse IP correspond au pays sélectionné alors que la machine se trouve ailleurs. Ces emplacements sont indiqués comme virtuels dans sa liste.

Le fournisseur annonçait encore en août 2026 un réseau de 214 emplacements sélectionnables dans 113 pays tout en maintenant cette distinction entre emplacements physiques et virtuels.

C’était mon premier indice réellement utile. Si un fournisseur publie lui-même cette information, c’est là que je commencerais. Pas sur un site « What is my IP ».

Mon vérificateur d’IP ne pouvait pas voir le rack

C’est le point que j’avais mal compris.

La géolocalisation IP n’est pas un GPS attaché au serveur.

MaxMind, qui fournit des données de géolocalisation utilisées par de nombreux services, explique qu’une adresse IP peut souvent être rattachée avec une bonne précision à un pays, mais que la précision diminue fortement lorsqu’on cherche une ville exacte. Les VPN, proxies et réseaux d’entreprise compliquent encore cette interprétation.

Autrement dit, voir : Paris, France ne signifie pas : machine physiquement installée dans un centre de données parisien.

Cela signifie surtout que la base consultée associe cette adresse IP à Paris ou à sa région.

Pour un service de streaming ou un site français, cette information peut suffire : c’est la localisation de l’IP qu’il voit.

Pour savoir où se trouve réellement la machine, elle ne suffit pas. J’ai donc arrêté d’ouvrir de nouveaux sites de géolocalisation. Ils pouvaient tous afficher Paris et simplement répéter la même information.

J’ai ensuite pensé que le ping allait trancher

Deuxième idée : si Paris est vraiment Paris, la latence doit être faible. J’ai donc comparé. Sans VPN.

Avec le serveur français. Puis avec une autre sortie. Les écarts étaient visibles. Pendant quelques minutes, cela a semblé confirmer mon intuition.

Sauf qu’une latence élevée ne prouve pas qu’une machine se trouve à Amsterdam, Francfort ou Londres. Internet ne suit pas une ligne droite entre deux points sur une carte.

Le trafic passe entre différents opérateurs, réseaux et points d’interconnexion. Une destination géographiquement proche peut être atteinte par une mauvaise route ; une destination un peu plus éloignée peut bénéficier d’un chemin beaucoup plus efficace.

Traceroute permet justement d’observer ces différents sauts et leur latence. Il montre comment le trafic voyage, pas l’étiquette collée sur le rack final.

J’ai lancé quelques mesures. Elles m’ont appris une chose utile : le chemin n’était pas aussi direct que je l’avais imaginé. Elles ne m’ont toujours pas donné l’adresse physique de la machine. Et cette distinction a fini par casser mon diagnostic initial.

Le plus embarrassant : le serveur que je soupçonnais pouvait parfaitement être physique

J’ai repris la documentation du fournisseur au lieu de continuer à interpréter les millisecondes. Sa liste distinguait explicitement les emplacements virtuels des autres. La France n’y était pas indiquée comme emplacement virtuel. Mon raisonnement :

« la latence est plus élevée que prévu, donc le serveur français doit être virtuel » ne tenait plus. Le détour que je ressentais pouvait simplement venir de la route réseau. L’erreur inverse existe pourtant réellement.

Dans une discussion publique de mai 2026, un utilisateur de Proton VPN racontait avoir choisi des serveurs présentés dans son pays avant de remarquer dans l’application que plusieurs étaient physiquement installés aux États-Unis. Pour des usages sensibles à la latence, notamment le jeu et Discord, la différence devenait immédiatement perceptible.

Dans son cas, le statut virtuel changeait réellement la décision.

Dans le mien, j’avais accusé la virtualisation d’un problème qu’elle n’était même pas nécessaire pour expliquer.

C’est là que la question « physique ou virtuel ? » s’est divisée en deux

Je me suis finalement demandé pourquoi je tenais autant à connaître l’emplacement physique. Si mon exigence était : « pour un contrat ou une politique interne, le matériel doit être physiquement hébergé en France », alors ni une adresse IP, ni un ping, ni un traceroute ne suffiraient.

Je chercherais une déclaration explicite du fournisseur.

Et si cette localisation physique constituait une vraie exigence contractuelle, je voudrais qu’elle soit documentée plutôt que déduite depuis mon ordinateur.

Mais ce n’était pas mon problème. Je ne préparais pas un audit de centre de données. Je voulais que mon bureau distant cesse de réagir avec retard. J’avais transformé « serveur physique en France » en raccourci mental pour dire :

je veux une route française rapide. Ce n’est pas la même demande. Et c’est seulement à ce moment-là que mon choix de VPN a changé.

J’ai arrêté de chercher où était la machine et demandé la route la plus rapide

J’ai ouvert OnlydogVPN^↗. Le service possède moins de régions qu’un grand fournisseur historique et moins de recul public. Mais pour ce que j’essayais réellement de faire, cette limite avait soudain beaucoup moins d’importance.

Je n’avais pas besoin de choisir entre six villes françaises en espérant deviner laquelle me donnerait le meilleur chemin.

J’avais besoin que ma session de bureau distant réponde correctement.

Au lieu de choisir moi-même Paris, Marseille ou une autre localisation, j’ai utilisé le mode qui sélectionne automatiquement une connexion rapide.

Connexion. Puis j’ai rouvert le bureau distant. J’ai déplacé une fenêtre. Puis une deuxième.

J’ai parcouru la timeline sur laquelle je travaillais. Le petit retard qui m’avait lancé dans toute cette recherche avait cessé d’attirer mon attention.

Les tests publiés du service sur la latence en France arrivent au même constat pratique : choisir la ville géographiquement la plus proche ne produit pas nécessairement la meilleure route, tandis que la sélection automatique peut éviter plusieurs essais manuels pour atteindre une connexion plus efficace.

C’était beaucoup plus proche de mon vrai problème que la question du rack.

Un serveur virtuel n’est donc pas automatiquement un mauvais serveur

C’est l’autre conclusion que je n’aurais pas acceptée au début.

Une localisation virtuelle peut devenir gênante si elle place physiquement le trafic beaucoup plus loin que prévu.

Si je suis à Lyon, que je sélectionne une destination censée être proche et que le matériel se trouve réellement à plusieurs pays de distance, la latence peut devenir une conséquence très concrète.

Mais « virtuel » ne veut pas dire automatiquement lent ou inutilisable.

Un fournisseur peut utiliser une machine dans un pays voisin doté d’une meilleure infrastructure tout en fournissant l’adresse IP du pays demandé. C’est précisément l’une des raisons avancées publiquement pour utiliser ce type d’emplacement.

Et « physique » ne veut pas dire automatiquement rapide. Mon test venait de me le rappeler. Le rack peut être en France. Les paquets peuvent tout de même faire du tourisme.

C’est à ce moment-là que j’ai cessé de considérer « physique » comme une caractéristique de performance.

Maintenant, je fais trois vérifications — mais chacune répond à une question différente

Je ne commence plus par la carte d’un site de géolocalisation. Je commence par la documentation du VPN. Le fournisseur dit-il explicitement quels emplacements sont virtuels ? S’il le fait, c’est l’information la plus directe disponible sans accès à son infrastructure.

Ensuite, je vérifie l’adresse IP. Pas pour localiser physiquement la machine, mais pour savoir quelle localisation verront les services auxquels je me connecte. Enfin, si mon problème concerne réellement les performances, je regarde ce qui compte pour mon usage : latence ;

stabilité ; réactivité de l’application ; et, si quelque chose paraît étrange, traceroute ou MTR pour observer le chemin. Ces vérifications répondent en réalité à trois questions différentes :

où le fournisseur dit que son matériel se trouve ; où Internet classe son adresse IP ; et comment mes paquets y arrivent réellement. J’avais mélangé les trois.

C’est pour cela que mes premiers tests semblaient se contredire.

La réponse la plus utile est aussi la plus courte

Peut-on savoir avec certitude qu’un serveur français est physique uniquement depuis son ordinateur ? Non. Une IP française ne le prouve pas. Un ping très bas peut renforcer une intuition, mais ne le prouve pas non plus.

Un traceroute peut révéler un détour ou rendre une localisation suspecte sans vous montrer l’emplacement exact de la machine.

Pour savoir si le matériel est réellement en France, la meilleure source reste donc le fournisseur lui-même et sa documentation sur les emplacements physiques et virtuels.

Mais ma recherche avait commencé pour une autre raison. Je pensais qu’un serveur virtuel expliquait la lenteur de ma connexion. En vérifiant correctement, j’ai découvert que j’avais utilisé « physique » comme synonyme de « rapide ».

Pour mon bureau distant, ce n’était pas le statut du serveur qui avait finalement amélioré l’expérience. C’était une meilleure route.

Depuis, lorsqu’un serveur affiche France mais se comporte bizarrement, je ne demande plus à trois bases d’IP de deviner dans quel bâtiment se trouve la machine : je vérifie ce que le fournisseur déclare, puis je laisse la qualité réelle du trajet décider si cette connexion mérite de rester active.