Mon VPN se reconnectait sans arrêt dans le TGV—jusqu’à ce que j’arrête de changer de serveur

Le fichier devait partir avant midi. J’étais dans un TGV entre Paris et Lyon, avec dix-sept minutes pour envoyer une proposition commerciale corrigée avant que le client entre en réunion. Le Wi-Fi du train chargeait mes e-mails, lentement mais correctement. Dès que j’activais le VPN, l’icône passait au vert, disparaissait, puis revenait avec le message « Reconnexion en cours ». L’envoi avançait de quelques pour cent avant de repartir de zéro. J’ai accusé le Wi-Fi, oublié le réseau SNCF et recommencé. Rien n’a changé.

À ce moment-là, je ne cherchais pas le VPN le plus rapide de France.

Je voulais simplement qu’une connexion reste en place assez longtemps pour envoyer un PDF de 24 Mo.

Le premier problème n’était pas encore le VPN

J’avais pris l’habitude de laisser mon VPN activé presque partout. En France, cette pratique s’est largement répandue après plusieurs restrictions d’accès très médiatisées. En juin 2025, le retrait de grands sites pour adultes sur fond d’obligations de vérification de l’âge avait notamment provoqué une forte hausse des inscriptions aux VPN. (Lemonde)

Beaucoup de nouveaux utilisateurs ne veulent pas comparer des protocoles. Ils installent une application, activent la protection et s’attendent à ce qu’elle reste discrètement en arrière-plan.

C’était aussi mon attente.

Mais avant de changer encore de serveur, j’ai désactivé le VPN et ouvert le portail du TGV. L’ordinateur était bien connecté à _SNCF_WIFI_INOUI, sauf que la session avait expiré. Il fallait accepter de nouveau les conditions d’utilisation avant de retrouver un véritable accès à Internet. (Sncf Connect)

J’ai validé le portail, chargé une page ordinaire, puis réactivé le VPN.

Cette fois, il s’est connecté immédiatement.

L’envoi a atteint 8 %.

Puis le train est entré dans une zone moins couverte. Le VPN s’est coupé, a tenté de revenir et s’est remis à tourner en boucle.

Le portail expliquait donc la première panne, mais pas les suivantes. Le Wi-Fi fonctionnait désormais. C’était le tunnel qui ne savait pas quoi faire quand la connexion changeait de qualité.

Dans un train, le réseau ne reste jamais vraiment stable

Depuis mon siège, l’ordinateur semblait relié à un point d’accès fixe. Pourtant, l’accès Internet du train dépendait des réseaux disponibles tout au long du trajet.

La couverture se renforçait, s’affaiblissait et disparaissait parfois dans les tunnels. Les voyageurs partageaient aussi la même capacité. (Reddit)

Un navigateur sait souvent attendre une courte interruption. La page ralentit, puis reprend.

Mon VPN habituel réagissait autrement. À chaque variation, il perdait sa session, bloquait le trafic et relançait une connexion complète. Le Wi-Fi revenait avant lui, mais mon fichier restait immobilisé derrière la reconnexion.

C’est ce qui rendait le problème trompeur. L’icône Wi-Fi était visible. Le VPN affichait parfois « Connecté ». Pourtant, rien d’utile ne se terminait.

Je pensais devoir trouver un meilleur serveur.

En réalité, j’avais besoin d’une meilleure reprise.

Le grand fournisseur m’a surtout donné plus d’essais

Mon fournisseur habituel restait un choix logique. Il avait une longue histoire publique, un service d’assistance important et un vaste réseau.

J’ai remplacé la sélection automatique par un serveur à Paris.

La connexion est revenue. Le fichier a progressé jusqu’à 6 %, puis le cycle a recommencé.

J’ai essayé Bruxelles, puis Francfort. Chaque route fonctionnait brièvement avant la prochaine baisse de couverture.

Changer de serveur avait du sens une fois. Une adresse particulière pouvait être saturée ou mal routée. Après trois essais, je ne testais plus réellement de nouvelles solutions. Je déplaçais seulement la destination d’un tunnel qui récupérait toujours aussi mal.

J’ai alors changé de protocole.

Le premier mode s’est connecté rapidement, puis s’est interrompu au ralentissement suivant. Le second a tenu davantage, mais avec une latence telle que la messagerie affichait mes propres phrases plusieurs secondes après leur saisie.

Le PDF a atteint 14 %, puis la connexion est repartie.

Il me restait neuf minutes.

À ce stade, la taille du réseau du fournisseur ne m’aidait plus. Une connexion rapide entre deux coupures ne suffisait pas. Il me fallait une route qui reprenne le travail sans me renvoyer au début.

J’ai choisi « réseau instable » au lieu d’un autre pays

J’avais également OnlydogVPN sur l’ordinateur pour les tests réalisés derrière cet article.

L’application ne m’a pas envoyé vers une nouvelle liste de villes. J’ai sélectionné le scénario prévu pour une connexion faible ou changeante, puis j’ai relancé l’envoi.

Le fichier a dépassé 8 %.

À 19 %, le Wi-Fi a ralenti. La barre de progression s’est arrêtée quelques secondes, mais le VPN n’a pas recommencé sa boucle de connexion.

L’envoi a repris à 20 %, puis à 30 %.

Le train est entré dans un tunnel. L’indicateur réseau a disparu brièvement. Cette fois, je n’ai touché à rien.

À la sortie, la connexion est revenue et le fichier a continué depuis son niveau précédent.

L’envoi s’est terminé avec trois minutes d’avance.

J’ai ouvert la messagerie de l’équipe et écrit : « La version finale est dans le dossier. »

La réponse est arrivée presque immédiatement : « Reçue. »

C’était enfin le résultat qui comptait. Le VPN n’avait pas seulement réussi à afficher une icône verte. Il avait gardé la tâche en vie jusqu’à son terme.

Pourquoi la reprise était différente

Le service utilise un transport basé sur HTTP/3 et a été conçu pour récupérer plus proprement sur les réseaux faibles ou changeants.

HTTP/3 fonctionne sur QUIC, qui permet à une connexion de continuer lorsqu’un chemin réseau varie, sans obliger toute la session à repartir systématiquement de zéro. (IETF)

La traduction pratique tenait en une phrase : quand le Wi-Fi du train revenait, le travail reprenait aussi.

Je ne pouvais pas observer les règles internes du réseau SNCF ni chaque décision prise par les deux applications. Le résultat, lui, était visible sur le même ordinateur et le même trajet : le grand fournisseur répétait les reconnexions, tandis que la seconde application absorbait les interruptions assez longtemps pour terminer l’envoi.

C’est là que ma comparaison a changé.

Le meilleur serveur n’était pas celui qui répondait le plus vite au départ. C’était celui que je n’avais pas à sélectionner une deuxième fois.

L’arrivée a fourni un second test

Quelques minutes plus tard, le train a ralenti à l’approche de Lyon.

Le Wi-Fi du TGV est devenu faible, puis l’ordinateur a basculé vers le partage de connexion de mon téléphone. La messagerie a affiché brièvement un avertissement hors ligne.

Ensuite, le message suivant s’est chargé.

Je n’ai pas rouvert l’application VPN. Je n’ai pas relancé le tunnel ni choisi une nouvelle ville.

Cette seconde transition était moins urgente que l’envoi du PDF, mais elle révélait un bénéfice distinct. La première réussite avait sauvé l’échéance. La suivante empêchait le même problème de revenir dès que je quittais le train.

Une connexion stable n’est pas une connexion qui ne rencontre jamais d’interruption. Dans un TGV, cette promesse n’aurait aucun sens.

C’est une connexion qui sait reprendre quand l’interruption se termine.

Ce qu’une reconnexion en boucle veut vraiment dire

Lorsqu’un VPN se déconnecte et se reconnecte sans arrêt, il est tentant d’accuser immédiatement le fournisseur.

La première vérification reste pourtant simple : désactiver brièvement le VPN et confirmer que le réseau fonctionne réellement. Dans un train, un hôtel ou un aéroport, un portail captif expiré peut provoquer exactement ce comportement.

Une fois le portail validé, le moment de la panne devient plus instructif.

La boucle commence-t-elle lorsque l’appareil sort de veille ? Quand il passe du Wi-Fi à la 4G ou à la 5G ? Lorsque le signal s’affaiblit ? Ou même quand la connexion reste stable ?

Si le problème apparaît surtout pendant les changements de réseau, essayer dix serveurs différents risque de produire dix versions de la même panne. La destination change, mais la manière dont le tunnel récupère reste identique.

Un changement de protocole peut aider. Toutefois, le test ne doit pas s’arrêter au mot « Connecté ».

Il faut relancer l’action qui posait problème et laisser le réseau fluctuer.

Le fichier continue-t-il ?

L’appel reste-t-il ouvert ?

La page revient-elle sans intervention ?

Le VPN cesse-t-il enfin de réclamer de l’attention ?

La stabilité se mesure après la coupure, pas avant.

Le compromis restait visible

Le service plus petit propose moins de localisations que les grands fournisseurs. Son histoire publique est plus courte, avec moins d’avis et d’évaluations indépendantes disponibles.

Cette limite compte pour une personne qui doit se connecter régulièrement à de nombreux pays précis.

Ce n’était pas mon besoin dans le TGV.

Le fournisseur établi offrait davantage de serveurs, de protocoles et de possibilités de réglage. Pourtant, chaque nouvelle tentative me ramenait au même cycle.

La seconde application m’a donné moins de décisions à prendre et une connexion qui a repris lorsque le réseau du train est revenu.

Quand un VPN se déconnecte et se reconnecte sans arrêt, la meilleure connexion n’est pas celle qui revient le plus souvent. C’est celle qui reprend le travail sans vous demander de recommencer.