Plan B VPN à l’hôtel : le bon test se fait dix minutes avant la réunion, pas après la panne

Plan B VPN à l’hôtel : le bon test se fait dix minutes avant la réunion, pas après la panne

À 8 h 51, le Wi-Fi de l’hôtel affichait toutes ses barres.
À 8 h 52, Teams ne chargeait plus.
Ma réunion commençait à 9 heures.
J’ai d’abord accusé le VPN.
Déconnexion.

Reconnexion.
Autre serveur.
Toujours rien.
J’ai coupé le VPN complètement et ouvert une page web.

Au lieu du site demandé, l’hôtel m’a renvoyé vers son portail Wi-Fi.

« Accepter les conditions pour continuer. »
Ma session avait simplement expiré.
J’ai validé.
Internet est revenu.
Puis j’ai relancé le VPN.

8 h 57.

La réunion n’avait même pas commencé et j’avais déjà passé six minutes à réparer une connexion qui affichait pourtant quatre barres.

C’est là que mon « plan B VPN pour l’hôtel » a changé de sens.

Je pensais qu’un plan B consistait à connaître un deuxième serveur ou un deuxième protocole.

En réalité, avant une réunion, j’avais besoin de quelque chose de beaucoup plus simple :

si le Wi-Fi de l’hôtel devient inutilisable, combien de temps faut-il pour reprendre la réunion sur une connexion de secours ?

Le Wi-Fi de l’hôtel n’a pas besoin d’être mauvais pour devenir un problème

Les déplacements professionnels restent massifs : les dépenses européennes liées aux voyages d’affaires devaient approcher 390 milliards d’euros en 2026.

Cela représente beaucoup de réunions prises depuis des réseaux que personne ne maîtrise vraiment.

Chambre d’hôtel.
Salon d’aéroport.
Appartement temporaire.
Coworking.

Le problème n’est d’ailleurs pas toujours un débit catastrophique.

Un Wi-Fi peut fonctionner suffisamment bien pour les mails et le navigateur, puis devenir irrégulier précisément au moment où commence une visioconférence. Des travailleurs à distance décrivent encore cette difficulté très simple : choisir un hôtel qui semble adapté au travail et découvrir ensuite que son Wi-Fi ne tient pas correctement une journée d’appels.

C’était exactement mon cas.

Et c’est ce qui rend ce type de panne trompeur : si le réseau était complètement mort, je chercherais immédiatement une alternative.

Quand il fonctionne « presque », je suis tenté de le réparer.

À huit minutes d’une réunion, c’est souvent la mauvaise priorité.

Mon Speedtest ne m’avait presque rien appris sur ma réunion

J’avais une habitude rassurante en arrivant dans un hôtel.
Speedtest.
Résultat correct.
Très bien, je peux travailler.

Sauf qu’une visioconférence ne dépend pas uniquement du nombre de mégabits disponibles. Teams surveille aussi des éléments comme la latence, la perte de paquets et la gigue.

Cela explique pourquoi une connexion rapide mais irrégulière peut produire une mauvaise réunion, alors qu’un hotspot mobile moins spectaculaire tient parfaitement la conversation.

Cette distinction a changé ma préparation.

Je ne cherchais plus à démontrer que le Wi-Fi de l’hôtel était rapide.

Je voulais savoir si je pouvais le quitter immédiatement lorsqu’il cessait d’être fiable.

Et avant de tester la bascule, il fallait comprendre pourquoi mon premier essai m’avait fait perdre autant de temps.

Le portail de l’hôtel voulait passer avant la VPN

Mon premier service était NordVPN.
Le choix était raisonnable.
Infrastructure mature.
Nombreux serveurs.
Applications établies.

Auto-connexion pratique sur les réseaux publics.

Mais les hôtels ajoutent souvent une étape avant l’accès normal à internet : le portail captif.

NordVPN explique lui-même que l’auto-connexion peut gêner l’affichage de ce portail et recommande de terminer d’abord l’authentification du Wi-Fi, puis de réactiver la VPN.

C’était pratiquement ce qui venait de m’arriver.
Le Wi-Fi voulait :
portail ;
validation ;
internet.

La VPN voulait déjà créer son tunnel.

À 8 h 52, je n’avais aucune envie de déterminer lequel des deux devait gagner.

J’en ai tiré une règle plus utile :

le portail se règle une fois ; la réunion, elle, doit avoir une sortie de secours.

J’ai donc préparé une sortie, pas un dépannage

Pour la réunion suivante, j’ai changé de méthode.

La veille au soir, j’ai activé le hotspot de mon téléphone.

J’ai connecté le notebook.
J’ai vérifié que Teams s’ouvrait.
J’ai lancé quelques secondes d’appel.
Puis je suis revenu au Wi-Fi de l’hôtel.

Deux minutes plus tard, j’avais deux chemins dont je savais déjà qu’ils fonctionnaient :

Wi-Fi de l’hôtel.

Hotspot mobile.

C’était beaucoup plus rassurant qu’une liste de procédures à tenter en urgence.

L’idée n’a rien d’exotique : chez les travailleurs nomades, garder une connexion mobile de secours revient régulièrement dès que les appels professionnels dépendent du Wi-Fi d’un logement.

Mais il restait une faiblesse dans mon plan.

Si je quittais le Wi-Fi pour le hotspot et devais ensuite attendre que la VPN reconstruise sa connexion, j’avais simplement déplacé le point de panne.

Il fallait donc tester la bascule complète.

Cette fois, j’ai provoqué la panne avant l’heure du rendez-vous

J’ai ouvert OnlydogVPN^↗.

Au lieu de choisir une ville ou de parcourir plusieurs serveurs, j’ai sélectionné la situation correspondant au travail sur une connexion de voyage.

Connexion.
J’ai lancé un appel de test.
Puis un envoi de fichier.
Tout fonctionnait sur le Wi-Fi de l’hôtel.
Ensuite, j’ai volontairement coupé le Wi-Fi.

Le notebook est passé au hotspot.
L’image de l’appel a hésité brièvement.
La barre d’envoi s’est arrêtée.
Puis les deux ont repris.
Je n’ai pas rouvert l’application.

Je n’ai pas choisi un autre serveur.
Je n’ai pas attendu devant « Reconnecting ».
Je suis simplement resté dans l’appel.
À cet instant, mon plan B était enfin réel.

Ce n’était plus une liste de choses que je saurais essayer si le Wi-Fi tombait.

C’était une transition que j’avais déjà testée.

La raison technique tient en trois phrases

Le service utilise un transport basé sur HTTP/3, donc sur QUIC. QUIC a été conçu pour mieux supporter les changements de chemin réseau, notamment lorsqu’un appareil passe d’une connexion à une autre.

Cela correspondait exactement à mon test : Wi-Fi, hotspot, puis reprise de la session.

Je ne peux pas observer de l’extérieur toutes les règles internes de routage ou de récupération appliquées pendant cette transition.

Mais je peux voir si je dois recommencer ma réunion.

Dans mon test, non.

Mon vrai plan B n’était donc pas « un autre serveur »

C’est là que ma préparation précédente s’est mise à paraître inutilement compliquée.

J’avais mémorisé :
quelques serveurs favoris ;
deux protocoles à essayer ;
plusieurs réglages de dépannage.

Tout cela peut être utile lorsque j’ai vingt minutes et que je veux comprendre pourquoi une connexion fonctionne mal.

À neuf heures moins trois, je veux autre chose.
Mon plan B tient désormais en deux couches.
D’abord :
une deuxième connexion internet déjà testée.
Ensuite :

une VPN qui ne me demande pas de reconstruire manuellement mon travail au moment de la bascule.

La distinction est importante.

Si l’hôtel n’a plus internet, aucun serveur VPN ne peut fabriquer cette connexion.

Le hotspot peut.

Une fois le hotspot actif, la VPN doit simplement me laisser continuer.

C’est beaucoup plus simple que de traiter chaque panne comme une énigme réseau.

J’ai aussi arrêté de réparer le Wi-Fi cinq minutes avant un appel

C’est probablement le changement le plus rentable.

Avant, une connexion instable déclenchait immédiatement une enquête.

DNS ?
Serveur VPN ?
Portail ?
5 GHz ?
Réception ?
Redémarrage ?
Autre protocole ?
Toutes ces questions peuvent attendre.
Une réunion, non.

Maintenant, si le Wi-Fi devient douteux juste avant un appel, je lui accorde très peu de temps.

Je bascule sur le hotspot que j’ai déjà testé.

Après la réunion, je peux comprendre pourquoi le réseau de l’hôtel s’est comporté ainsi.

Avant la réunion, mon seul objectif est d’entendre :
« Bonjour, vous m’entendez ? »
et de pouvoir répondre sans regarder l’icône VPN.

C’est précisément là que la petite application m’a été plus utile qu’une longue boîte à outils de dépannage.

Le grand fournisseur garde des avantages évidents

OnlydogVPN a moins de localisations, moins d’avis indépendants et un historique public plus court que les grands fournisseurs.

Si je veux choisir précisément de nombreux pays ou disposer d’une documentation de support très étendue, un service établi conserve une vraie avance.

NordVPN documente notamment très bien les problèmes de portails captifs.

Cette documentation m’a aidé à comprendre pourquoi ma première connexion s’était bloquée.

Mais pour une réunion imminente, je préfère une solution qui réduit le nombre de fois où j’ai besoin de la consulter.

Le grand fournisseur me donnait davantage d’outils pour réparer le Wi-Fi.

La petite application s’est montrée plus convaincante dans le test que j’avais fini par considérer comme essentiel :

couper ce Wi-Fi et continuer malgré tout.

Mon plan B tient maintenant sur un test de cinq minutes

La veille d’une réunion importante, je ne prépare plus une liste de serveurs de secours.

Je fais quelque chose de plus concret.
Je termine le portail de l’hôtel.
Je vérifie que Teams s’ouvre.
J’active le hotspot.
Je vérifie qu’il fonctionne aussi.

Puis je démarre un appel avec la VPN active et je coupe volontairement le Wi-Fi.

Je regarde une seule chose :

combien de temps s’écoule entre le moment où la connexion de l’hôtel disparaît et celui où je peux continuer à parler ?

Le fournisseur établi me donne davantage de moyens de réparer le réseau lorsque j’ai le temps de le faire.

La petite application m’a davantage convaincu pour le scénario où je ne veux surtout pas le réparer.

Mon plan B VPN à l’hôtel n’est donc plus « quel autre serveur essayer ? » : c’est « si je coupe ce Wi-Fi maintenant, est-ce que ma phrase suivante arrivera quand même jusqu’à la réunion ? »