Quel VPN garde de bonnes performances pour obtenir une IP française depuis un pays lointain ? J’ai arrêté de mesurer le Wi-Fi japonais

Le Wi-Fi affichait plus de 300 Mb/s.

J’étais à Kyoto, dans un appartement loué pour quelques semaines, et je devais déposer un fichier vidéo dans le back-office d’un client français avant le début de sa journée à Paris.

Sans VPN, tout était rapide. Le problème était que l’espace de préproduction du client refusait les connexions provenant de l’étranger. J’ai donc lancé mon VPN habituel. France.

Paris. Connexion. Le tableau de bord s’est ouvert. Très bien.

J’ai commencé l’envoi du fichier. La barre a avancé. Puis ralenti. Puis presque arrêté.

Elle repartait quelques secondes, hésitait à nouveau et me donnait cette impression particulièrement agaçante d’une connexion techniquement active mais incapable de décider à quelle vitesse elle voulait fonctionner.

J’ai ouvert un Speedtest. Le résultat restait largement suffisant pour envoyer un fichier. J’ai changé de serveur français. Puis encore une fois.

Le troisième semblait meilleur pendant une minute. Ensuite, la barre s’est remise à avancer par à-coups.

C’est à ce moment-là que j’ai compris pourquoi mon test de débit ne répondait pas à ma question.

Je n’avais pas besoin de savoir si le Wi-Fi japonais était rapide.

Je voulais savoir si le trajet Japon → VPN français → service français pouvait rester efficace assez longtemps pour que mon fichier arrive réellement au bout.

Depuis un pays lointain, une connexion rapide ne raccourcit pas le trajet jusqu’à la France

Le Japon est justement un bon endroit pour rencontrer ce problème en 2026.

L’Office national du tourisme japonais a enregistré au printemps une forte progression des visiteurs venus de France, avec un record mensuel en avril et encore 48 500 arrivées françaises en mai.

À cela s’ajoute une communauté française installée sur place : France Diplomatie recensait plus de 17 000 ressortissants français vivant au Japon à la mi-2025.

Beaucoup continuent naturellement à utiliser des services français. Parfois pour regarder un contenu. Parfois pour accéder à un outil de travail. Parfois simplement parce qu’un service exige une adresse IP française.

Et lorsqu’on est à Bruxelles ou Barcelone, le détour peut rester assez discret. Depuis Kyoto, on le sent beaucoup plus vite. C’était précisément mon erreur de départ. Je voyais :

Wi-Fi : 300 Mb/s. VPN : connecté. Serveur : France. Et j’en déduisais que la vitesse disponible réglerait le reste.

Mais la bande passante et la distance ne racontent pas la même chose.

La latence augmente notamment avec la distance physique parcourue par les paquets. À cela s’ajoutent les routeurs intermédiaires, les détours du routage et les éventuelles congestions.

Depuis Kyoto, obtenir une IP française impose donc une contrainte impossible à supprimer complètement : mon trafic doit réellement aller jusqu’en France avant de ressortir sur Internet. Je peux choisir un meilleur chemin. Je peux limiter les détours.

Je peux utiliser un tunnel qui récupère mieux lorsque la route devient imparfaite. Mais aucun bouton ne rapproche Paris du Japon. L’image la plus simple est celle d’une autoroute très longue. Ajouter des voies augmente sa capacité.

Cela ne raccourcit pas la distance.

Et lorsqu’un colis se perd au milieu du trajet, devoir revenir le chercher coûte bien plus cher que sur une route de quelques kilomètres.

Sur Internet, les pertes de paquets et leur récupération finissent par produire exactement ce genre d’effet.

C’est pourquoi une petite perte pouvait me coûter beaucoup plus que prévu

Sur un trajet aussi long, la régularité compte presque autant que le débit brut.

QUIC, le protocole qui sert de base à HTTP/3, possède justement des mécanismes destinés à détecter les pertes et à ajuster l’envoi lorsque le réseau devient moins fiable. La RFC 9002 décrit cette logique de récupération et de contrôle de congestion.

Je n’avais pas besoin d’aller beaucoup plus loin dans les algorithmes pour comprendre ce qui arrivait à mon fichier.

Plus le trajet aller-retour est long, plus attendre de détecter une perte puis renvoyer ce qui manque coûte du temps.

Et si le chemin perd régulièrement des paquets, un débit théorique excellent peut produire une expérience très moyenne.

Une discussion publique de mars 2026 décrivait un cas particulièrement parlant entre le Japon et la France.

Un utilisateur disposait d’environ 200 Mb/s sans VPN au Japon, mais tombait sous 1 Mb/s sur son PC Windows lorsqu’il utilisait un tunnel WireGuard vers un serveur français. Ses tests UDP montraient environ 15 % de pertes, alors que le même environnement se comportait beaucoup mieux sur son iPhone.

La conclusion intéressante n’était pas « WireGuard est lent ».

Le même serveur fonctionnait mieux sur un autre appareil.

Ce témoignage montrait plutôt à quel point, sur un long trajet Japon–France, le chemin réseau, les pertes et la manière dont le tunnel les gère peuvent faire exploser la différence entre connexion établie et connexion réellement utilisable.

C’était exactement la distinction que ma barre d’envoi venait de m’apprendre.

J’ai arrêté de choisir le gagnant sur trente secondes de Speedtest

Mon grand fournisseur avait pourtant des avantages évidents. Plusieurs sorties françaises. Une infrastructure installée depuis longtemps. Davantage d’avis publics.

Si je voulais comparer des serveurs, j’avais largement de quoi le faire. Et je l’ai fait. Paris. Une autre sortie.

Retour à la première. Les chiffres changeaient.

Le problème est que je choisissais le gagnant sur un test très court, puis je lui demandais ensuite de réussir une tâche beaucoup plus longue.

Mon fichier, lui, se moquait du meilleur pic de vitesse. Il devait tenir jusqu’à 100 %. C’est là que mon critère a basculé. Je ne cherchais plus le VPN capable d’afficher le plus gros nombre juste après la connexion.

Je cherchais celui qui conservait des performances suffisamment régulières pendant toute la durée d’un trajet réseau que je savais déjà long.

J’ai donc essayé le tunnel plutôt que le benchmark

C’est à ce moment-là que j’ai lancé OnlydogVPN^↗ avec une sortie française. Puis j’ai recommencé exactement le même envoi. Cette fois, je n’ai pas immédiatement ouvert un outil de mesure. J’ai regardé la barre.

Elle a commencé à avancer. Je suis retourné corriger les notes qui devaient accompagner le fichier. Quelques minutes plus tard, je suis revenu. L’envoi continuait.

Pas de bond spectaculaire. Pas de chiffre qui donnait l’impression que la France se trouvait soudain dans la pièce voisine. Simplement une progression beaucoup plus régulière. Puis :

100 %. Le fichier apparaissait dans le back-office. J’ai ouvert sa prévisualisation. Lecture.

Le client pouvait le récupérer. La tâche était terminée.

Le service utilise un transport basé sur HTTP/3. Sur ce trajet, c’est surtout sa capacité à garder le tunnel exploitable malgré un chemin long et imparfait qui m’a intéressé.

La distance Japon–France était toujours là. Mais je n’avais plus besoin de refaire la roulette des serveurs au milieu de l’envoi. C’était exactement le compromis que je cherchais.

Le meilleur résultat n’était pas d’obtenir une vitesse « locale »

À ce stade, il aurait été facile de raconter l’histoire comme si le nouveau VPN avait transformé ma connexion japonaise en fibre parisienne.

Ce n’est pas ce qui s’est passé. Et je n’aurais de toute façon pas cru un service qui me le promettrait. Le temps aller-retour reste plus élevé entre Kyoto et Paris qu’entre Lyon et Paris. Une route Internet peut toujours rencontrer congestion, pertes ou mauvais peering.

Ce qui avait changé, c’était la façon dont cette contrainte se manifestait dans mon travail. Avec mon premier essai, je surveillais le débit. Je changeais de serveur. Je revenais voir la barre.

Je me demandais si le tunnel était encore le bon. Avec le second, la distance était encore perceptible, mais elle ne transformait plus chaque fluctuation en intervention. Le fichier était parti. C’est beaucoup moins spectaculaire qu’un énorme chiffre de benchmark.

Pour quelqu’un qui a réellement besoin d’utiliser une IP française à près de 10 000 kilomètres de la France, c’est aussi beaucoup plus utile.

« Choisir le serveur le plus proche » ne répondait pas à mon problème

Depuis un pays lointain, les conseils habituels deviennent vite contradictoires. On recommande souvent : choisissez le serveur le plus proche. C’est parfaitement logique lorsque le but est simplement de protéger la connexion.

Mais si mon besoin précis est une IP française, le serveur doit justement être en France. Je ne peux pas sélectionner Osaka parce qu’Osaka se trouve à côté de moi. La destination est imposée. Je dois donc optimiser ce qui reste réellement sous contrôle :

la qualité du chemin ; la façon dont le tunnel supporte les pertes ; sa capacité à rester utilisable malgré une forte latence. Cette distinction a changé toute ma comparaison.

La question n’était plus : « quel fournisseur possède le plus de serveurs autour de moi ? » Elle devenait : « lequel transporte le mieux ma connexion jusqu’au pays que je suis obligé de choisir ? »

C’est aussi pourquoi un réseau plus petit me gênait moins ici

Le petit service propose moins de régions que les grands fournisseurs et possède moins d’années d’historique public et d’évaluations indépendantes.

Si j’avais besoin d’alterner constamment entre vingt destinations, ce serait une vraie limite. Mais mon problème à Kyoto ne nécessitait pas vingt pays. Il nécessitait la France. À partir du moment où cette sortie existait, le nombre de petits drapeaux autour devenait secondaire.

Ce qui comptait était tout ce qui se passait entre le clic sur « France » et le moment où mon fichier arrivait réellement de l’autre côté.

J’étais parti avec l’idée qu’un bon VPN pour obtenir une IP française depuis le Japon devait surtout préserver le plus grand nombre possible de mégabits.

J’en suis arrivé à une mesure beaucoup plus sévère : sur un trajet aussi long, je préfère le tunnel qui fait arriver mon fichier à 100 % sans intervention à celui qui gagne le Speedtest puis me renvoie choisir un autre Paris à mi-chemin.