Comment tester un VPN au-delà du Speedtest : ping, jitter, perte, MTU, upload et surtout reconnexion

J’avais déjà choisi le gagnant.

Sur ma fibre, le premier VPN dépassait largement les 500 Mb/s. Le second restait un peu en dessous. J’avais noté les résultats dans un tableau et la comparaison me paraissait terminée.

Puis j’ai lancé un envoi de plusieurs gigaoctets vers mon espace cloud tout en gardant un appel Teams ouvert.

La voix est devenue métallique. Le partage d’écran a hésité. L’envoi avançait vite, ralentissait brutalement, puis repartait.

Le VPN qui avait gagné mon Speedtest venait de perdre le test que j’allais réellement lui demander de réussir.

Je n’avais pas besoin d’un benchmark plus long. J’avais besoin d’un benchmark plus méchant.

Avec la fibre, un gros chiffre devient facilement rassurant

Ce piège est devenu particulièrement facile à rencontrer en France. Fin mars 2026, l’Arcep comptait 27,7 millions d’abonnements fibre, soit 84 % des abonnements internet fixes, et 35,4 millions de cartes SIM actives sur les réseaux 5G.

Voir plusieurs centaines de mégabits n’a donc plus rien d’exceptionnel pour beaucoup d’utilisateurs.

Mon travail, lui, contenait les moments moins propres : un appel pendant qu’un fichier monte, une sauvegarde qui remplit le débit montant, un Wi-Fi qui disparaît quelques secondes, un ordinateur qui change de réseau.

Je voulais savoir non pas lequel de mes deux VPN pouvait courir le plus vite sur une piste vide, mais lequel restait utilisable quand la piste se dégradait.

Et pour le savoir, il fallait commencer à regarder ce que le gros chiffre du Speedtest cachait.

Le premier chiffre que j’ai cessé de regarder seul était le ping

J’ai relancé le test avec un outil qui affiche autre chose que le débit descendant.

Cloudflare, par exemple, sépare le download, l’upload, la latence, le jitter et la perte de paquets. Son test permet aussi d’observer la latence lorsque la connexion travaille réellement.

Avec mon premier VPN, le ping au repos était très bon.

Puis j’ai recommencé pendant que l’upload cloud tournait.

La moyenne montait et, surtout, elle devenait irrégulière.

Le ping dit combien de temps prend l’aller-retour. Le jitter montre à quel point ce délai varie. La perte compte ce qui n’arrive pas du tout.

Pour une page web, quelques irrégularités peuvent passer inaperçues. Dans une conversation, elles deviennent des syllabes avalées, une voix robotique ou une image qui se fige.

Microsoft traite justement la latence, le jitter et la perte de paquets comme des métriques distinctes pour la qualité des appels Teams. Sa documentation montre aussi qu’une vidéo HD n’a pas besoin des centaines de mégabits qu’une fibre moderne peut afficher sur un test de débit.

C’était le premier changement dans ma façon de comparer les VPN : une fois le débit largement suffisant, sa stabilité commençait à m’intéresser davantage que son maximum.

L’upload a révélé ce que le download cachait

J’ai donc pris un gros fichier et je l’ai envoyé vers un service cloud que j’utilise réellement.

Quelque chose qui devait durer.

Une connexion peut afficher un énorme débit descendant tout en ayant beaucoup moins de marge en montant. Quand l’upload se remplit, l’audio, le navigateur et les autres échanges doivent quand même se frayer un passage.

Avec le premier VPN, le transfert était rapide par moments, mais tout le reste devenait moins agréable.

J’ai arrêté l’envoi.

Le ping s’est calmé.

Je l’ai repris.

Les pointes sont revenues.

Ce simple aller-retour m’a appris davantage que trois Speedtests successifs. Mon usage exigeait moins un record de débit qu’une connexion qui reste régulière pendant l’effort.

Il restait cependant une autre panne que je voulais distinguer d’un simple problème de charge : celle où la connexion paraît fonctionner, mais où certains transferts refusent mystérieusement de passer.

C’est là que la MTU devient intéressante.

Je n’ai regardé la MTU qu’après avoir vu un symptôme qui lui ressemblait

La MTU est la taille maximale qu’un paquet peut avoir sur un chemin. Un tunnel VPN ajoute son propre emballage.

Je la vois comme une valise qui passait juste sous la limite avant qu’on lui ajoute une housse : le contenu n’a pas changé, mais l’ensemble peut désormais être trop gros pour un passage du trajet.

La Path MTU correspond à la limite imposée par le maillon le plus étroit du chemin. Lorsque la découverte de cette limite se passe mal, on peut rencontrer un comportement particulièrement trompeur : la connexion s’établit, les petites données circulent, puis certains transferts plus importants se bloquent.

Voilà le symptôme qui me ferait enquêter.

Pas simplement : « mon VPN est un peu plus lent ».

Une discussion publique sur r/WireGuard m’a évité de transformer la MTU en explication universelle. Un utilisateur avait essayé plusieurs valeurs pour expliquer un débit bloqué autour de 50 Mb/s. Cela ne résolvait rien ; des tests directs avec iPerf ont finalement montré que la limite venait de la bande passante publique de son instance cloud.

Autrement dit, toucher à la MTU sans symptôme correspondant revient un peu à régler la hauteur d’une porte avant d’avoir vérifié si c’est réellement la valise qui coince.

Je l’ai donc laissée tranquille.

Et je suis passé au test qui allait réellement départager mes deux VPN.

Le test décisif a duré dix secondes

Il me restait une chose que le Speedtest mesure mal : ce qui se passe quand le réseau disparaît sous le VPN.

J’ai laissé l’upload actif, coupé le Wi-Fi de l’ordinateur et activé le partage de connexion de mon téléphone.

Avec le grand fournisseur que j’utilisais déjà, Internet est revenu assez vite. Le tunnel aussi.

Mais l’upload s’était interrompu et une application attendait encore. Quelques secondes plus tard, tout fonctionnait de nouveau.

Sur une fiche technique, j’aurais appelé cela une reconnexion réussie.

Devant mon fichier, j’ai commencé à faire une distinction plus sévère :

se reconnecter n’est pas forcément récupérer.

Ce que je voulais, c’était que le changement de réseau ne transforme pas le VPN lui-même en nouvelle tâche.

C’est à ce moment-là que j’ai ouvert la petite application que je gardais comme second essai.

J’ai refait exactement le même mauvais test

Je ne lui ai pas donné un Speedtest facile.

Pour cet essai, j’ai choisi le mode prévu pour un réseau faible ou changeant, puis repris exactement le même scénario.

Upload en cours. Appel actif. Wi-Fi connecté.

Puis Wi-Fi coupé.

Le hotspot a pris le relais.

L’audio s’est brièvement dégradé. L’upload a ralenti.

Mais je n’ai pas eu à rouvrir le VPN ni à relancer le transfert. Quelques instants plus tard, la progression continuait.

C’était moins spectaculaire qu’un résultat à 600 Mb/s et beaucoup plus convaincant.

Le service utilise un transport basé sur HTTP/3. HTTP/3 s’appuie sur QUIC, et QUIC a notamment été conçu pour permettre à une connexion de continuer à travers certains changements d’adresse ou de chemin réseau au lieu de devoir nécessairement repartir de zéro.

La technique expliquait le comportement que je venais d’observer, mais le résultat important était beaucoup plus simple.

Mon fichier avançait encore.

Mon appel était revenu.

Et je n’avais rien eu à réparer.

Mon protocole de test est devenu beaucoup plus court que mon tableau

Je garde désormais le Speedtest, mais comme point de départ.

Ensuite, je laisse tourner un ping pendant un vrai upload et je regarde si la latence explose, si elle devient irrégulière ou si des paquets disparaissent. Si de petites requêtes fonctionnent mais que certains transferts se bloquent, je commence seulement alors à regarder la MTU.

Enfin, je provoque une coupure.

Wi-Fi désactivé.

Hotspot activé.

Et j’observe ce qui survit.

Ce dernier test est celui que j’avais complètement oublié.

Un VPN peut être excellent tant que le réseau sous ses pieds ne bouge jamais. Ce n’est pas celui que je veux nécessairement laisser actif pendant une journée de travail où je passe du Wi-Fi au mobile, où un point d’accès décroche ou où l’upload se remplit.

La petite application a une limite évidente : elle offre moins de régions de sortie et possède moins d’historique public et d’avis indépendants que les grands fournisseurs établis. Si je cherchais une localisation très précise ou le maximum de recul public, cette différence pèserait dans la décision.

Mais mon besoin était ailleurs.

Je voulais que mon appel, mon transfert et mon tunnel restent utilisables lorsque la connexion cessait d’être propre.

Le grand fournisseur avait remporté mon premier test. Le second a mieux traversé celui que j’avais volontairement rendu désagréable.

Depuis, quand deux VPN dépassent déjà largement le débit dont j’ai besoin, je ne cherche plus lequel peut ajouter quelques dizaines de mégabits à une capture d’écran. Je lance un upload, je regarde le ping et le jitter, je surveille les pertes, je ne touche à la MTU que si les symptômes le justifient, puis je coupe le réseau sous leurs pieds.

Le VPN que je garde n’est pas celui qui reste le plus beau sur le Speedtest.

C’est celui qui me rend mon fichier, mon appel et ma connexion après que j’ai essayé de les lui enlever.