Quand faut-il changer de protocole plutôt que de serveur VPN ? Quand changer de destination ne change plus rien

Le troisième serveur venait d’échouer exactement comme les deux premiers. J’étais sur le Wi-Fi d’un salon d’aéroport, mon navigateur fonctionnait sans VPN, mais dès que j’activais le tunnel, les pages tournaient dans le vide. Paris : rien. Amsterdam : rien. Francfort : connecté, puis aucun trafic.

J’allais sélectionner un quatrième pays quand j’ai fait quelque chose de beaucoup plus utile : j’ai activé le partage 5G de mon téléphone et repris le tout premier serveur.

Il s’est connecté immédiatement.
C’est à ce moment-là que j’ai compris mon erreur.
Je changeais de serveur parce que le VPN ne fonctionnait pas.
Mais le serveur que j’accusais depuis dix minutes venait de fonctionner parfaitement.
Ce qui avait changé n’était pas la destination.
C’était le chemin utilisé pour l’atteindre.

Changer de serveur et changer de protocole ne réparent pas la même panne

Dans une application VPN, ces deux actions sont souvent placées à quelques centimètres l’une de l’autre.

Elles donnent donc l’impression d’être deux versions du même dépannage.

Elles ne le sont pas.

Changer de serveur revient surtout à modifier l’endroit où le tunnel aboutit. Un serveur peut être en maintenance, saturé, avoir une mauvaise route vers un service précis ou utiliser une adresse IP qui pose problème.

Dans ce cas, passer de « France 12 » à « France 18 » peut réellement suffire.

Les guides de dépannage de Proton font d’ailleurs cette distinction : lorsqu’un serveur individuel pose problème, choisir une autre sortie est une première étape logique ; changer de protocole correspond à un autre type de diagnostic.

Un protocole change quelque chose de plus fondamental.
Il change la manière dont le tunnel voyage entre mon appareil et le serveur.
Je le vois maintenant comme une différence entre changer d’adresse et changer de véhicule.
Si le restaurant où je vais est fermé, je change d’adresse.

Si le poste de contrôle refuse tous les camions, choisir un autre restaurant tout en gardant le même camion ne m’aide pas beaucoup.

Au troisième serveur identique, j’étais encore en train de changer de restaurant.

Le partage 5G m’a donné la réponse avant n’importe quel réglage avancé

Le test était presque trop simple.
Même ordinateur.
Même VPN.
Même serveur.
Wi-Fi de l’aéroport : échec.
Partage 5G : connexion immédiate.

J’ai refait l’essai.
Retour au Wi-Fi.
Le tunnel indiquait brièvement qu’il était connecté, mais presque rien ne circulait.
Retour au téléphone.
Connexion.
Pages ouvertes.

Messagerie synchronisée.
À partir de là, chercher un serveur « moins chargé » n’avait plus beaucoup de sens.
Le serveur savait répondre.
C’était le réseau devant moi qui n’aimait pas la façon dont j’essayais de lui parler.

Ce genre de situation revient dans les discussions de voyageurs. En mai 2026, un utilisateur racontait que son VPN fonctionnait normalement chez lui mais refusait de se connecter ou devenait très instable sur certains Wi-Fi d’hôtels. Dans la même discussion, un autre voyageur expliquait avoir rencontré ce problème dans des hôtels et des aéroports : WireGuard et OpenVPN échouaient sur certains réseaux alors qu’un mode furtif parvenait à établir la connexion.

Ce qui m’intéressait dans ces témoignages n’était pas de deviner les règles exactes de chaque hôtel.

C’était le schéma.

Plusieurs serveurs peuvent sembler « morts » alors qu’ils utilisent tous une méthode de transport que le réseau traite mal.

Le protocole détermine ce que le réseau voit avant même que le serveur compte

C’est ici qu’un peu de technique devient utile.

WireGuard transporte son trafic via UDP. OpenVPN peut utiliser UDP ou TCP.

Pour mon problème, c’est presque tout ce qu’il fallait retenir.

Imaginons qu’un Wi-Fi invité limite certains flux UDP, certains ports ou certaines formes reconnaissables de trafic VPN.

Je peux choisir Paris.
Puis Bruxelles.
Puis Zurich.

Mais si mes trois tentatives quittent l’ordinateur avec un tunnel que le réseau perturbe de la même façon, j’ai changé le point d’arrivée sans modifier ce qui bloque au départ.

Voilà le moment où changer de protocole devient plus logique que changer encore de serveur.
Chez moi : ça marche.
Sur la 5G : ça marche.
Sur ce Wi-Fi précis : plusieurs serveurs échouent de la même manière.

Ce motif m’en disait désormais beaucoup plus qu’un pourcentage de charge affiché à côté d’un nom de serveur.

Il existe aussi un troisième cas où changer les deux ne sert à rien

Un événement survenu quelques jours auparavant m’avait donné un contre-exemple utile.

Dans la nuit du 26 au 27 août 2026, Proton a subi une panne mondiale. L’entreprise a ensuite expliqué qu’une défaillance totale du système de refroidissement de son centre de données de Francfort avait provoqué une montée rapide des températures et perturbé plusieurs services, dont le VPN pour certains utilisateurs.

Dans ce cas-là, changer Paris pour Amsterdam n’aurait pas forcément réparé quoi que ce soit.
Basculer d’UDP vers TCP non plus.
Le fournisseur lui-même rencontrait un incident.

Cette panne m’a donné une règle de diagnostic beaucoup plus simple que « essayez tout jusqu’à ce que ça marche ».

Si un serveur échoue alors que les autres fonctionnent sur le même réseau avec le même protocole, je change de serveur.

Si plusieurs serveurs fonctionnent ailleurs mais échouent tous sur un réseau précis, je regarde le protocole.

Si tout tombe sur plusieurs réseaux et que le fournisseur signale une panne, j’arrête de bricoler mon ordinateur.

Trois symptômes.
Trois problèmes différents.
Et dans l’aéroport, j’étais clairement dans le deuxième cas.

J’avais déjà assez changé de serveur

J’avais encore une quarantaine de minutes avant l’embarquement et quelques tâches à terminer.

Je pouvais simplement rester sur le partage 5G.

Mais cela évitait le problème sans vraiment le résoudre.

Je voulais continuer à utiliser le Wi-Fi disponible sans passer les vingt minutes suivantes dans une liste de protocoles.

C’est à ce moment-là que j’ai essayé OnlydogVPN^↗.
Je n’ai pas commencé par sélectionner Paris, Londres ou Amsterdam.
J’ai utilisé le mode prévu pour les réseaux plus difficiles et lancé la connexion.
Quelques secondes plus tard, le tunnel était établi.
J’ai ouvert la page qui tournait jusque-là dans le vide.
Elle a chargé.

Ma messagerie s’est synchronisée.
Puis j’ai ouvert le document dont j’avais besoin avant le vol.
Il est apparu sans que je repasse sur la 5G.

Cette fois, changer d’application avait réellement changé la nature de la tentative — pas seulement le serveur situé au bout du tunnel.

Je n’avais pas réellement besoin d’apprendre quel protocole choisir

Le service utilise un transport basé sur HTTP/3 avec une couche supplémentaire d’obfuscation.

Dans mon cas, l’intérêt était assez simple.

Mes premières tentatives changeaient la destination tout en présentant au Wi-Fi un type de tunnel similaire.

Cette nouvelle connexion abordait le réseau autrement.

L’obfuscation ajoutait une deuxième pièce utile : lorsque le problème vient de la manière dont un réseau reconnaît ou traite le trafic VPN, modifier son apparence peut compter davantage que choisir un quatrième pays.

Je n’avais évidemment pas accès aux règles internes du routeur de l’aéroport. Je ne pouvais donc pas dire si le premier tunnel rencontrait une restriction de port, de transport ou une classification particulière.

Mais ce niveau de précision n’était plus nécessaire pour prendre une décision.
Plusieurs sorties de mon fournisseur habituel avaient échoué sur ce Wi-Fi.
Le même Wi-Fi transportait maintenant une connexion utilisable.
Et j’avais enfin arrêté de résoudre un problème de protocole avec une liste de pays.

C’est là que l’interface simple a commencé à avoir du sens

Avant cette expérience, j’aurais probablement considéré l’absence d’une grande liste de protocoles comme une limitation.

J’aime pouvoir régler mes outils.
Du moins, j’aime penser que j’aime cela.
Dans l’aéroport, mon comportement réel avait été moins glorieux.
Serveur.
Attente.
Serveur.

Attente.
Pays voisin.
Paramètres.
Retour.
Nouvelle tentative.
Je ne faisais pas un diagnostic réseau sophistiqué.

Je cliquais jusqu’à ce que quelque chose change.

Le mode orienté vers la situation supprimait précisément cette partie.

Je n’avais pas besoin de décider si mon problème exigeait OpenVPN TCP, WireGuard, un autre port ou un mode furtif avant même d’avoir compris ce qui bloquait.

Je lui indiquais le type de situation.
L’application se chargeait du choix technique.
Dans ce contexte, « moins de réglages » ne ressemblait plus à « moins de contrôle ».

Cela ressemblait surtout à moins de mauvaises hypothèses entre moi et la page que j’essayais d’ouvrir.

Le grand fournisseur garde un avantage réel

La petite application possède une histoire publique beaucoup plus courte.

Son historique visible sur l’App Store français commence à la fin de novembre 2025, et Apple n’affiche toujours pas de résumé des notes faute d’un nombre suffisant d’évaluations. Sa couverture géographique est également plus limitée que celle des plus grands fournisseurs.

Si mon problème était simplement un serveur français en maintenance, cette différence pourrait compter énormément.

Je préférerais avoir immédiatement dix autres sorties françaises disponibles.
Mais justement : ce n’était pas mon problème à l’aéroport.
J’en avais déjà essayé plusieurs.
Changer de serveur n’avait pas échoué parce que je n’en avais pas assez.
Cela avait échoué parce que je modifiais la mauvaise variable.

Alors, quand faut-il changer de protocole plutôt que de serveur VPN ?

Je n’ouvrirais plus la liste des protocoles au premier échec.
Je regarderais d’abord la forme de l’échec.
Un serveur ne fonctionne pas, mais les autres oui ?
Je change de serveur.

Plusieurs serveurs échouent uniquement sur un Wi-Fi précis, alors que les mêmes connexions fonctionnent sur ma 5G ?

Je cesse de faire défiler les pays.

À ce stade, changer la manière dont le tunnel traverse le réseau a beaucoup plus de sens que changer encore son point d’arrivée.

C’est exactement la distinction que le Wi-Fi de l’aéroport m’a obligé à apprendre.

Mon fournisseur habituel me donnait beaucoup de destinations et suffisamment de réglages pour chercher manuellement la combinaison qui fonctionnerait.

La petite application a raccourci tout ce diagnostic : elle a changé la façon d’aborder le réseau au moment où continuer à changer de serveur ne m’apportait plus rien.

J’avais commencé avec trois serveurs que je croyais défectueux.
J’ai fini par comprendre qu’aucun d’eux ne l’était.
Le vrai signal n’était pas que Paris, Amsterdam et Francfort échouaient.
C’était que Paris fonctionnait dès que je quittais le Wi-Fi de l’aéroport.

À partir de ce moment-là, choisir un quatrième serveur aurait été comme changer une quatrième fois d’adresse alors que le problème était toujours au péage.