Partage mobile Vidéotron : le débit était bon, mais le tunnel VPN du bureau ne démarrait pas

Le test de débit m’avait rassuré beaucoup trop vite. Ma connexion résidentielle venait de tomber, j’avais un document à récupérer sur le réseau interne avant une réunion, et le partage de connexion Vidéotron de mon téléphone donnait immédiatement Internet au portable.

Outlook Web chargeait, Teams recevait les messages, les pages s’ouvraient sans hésiter. J’ai donc lancé le VPN du bureau en pensant que la partie difficile était terminée. La fenêtre est restée sur « établissement du tunnel », puis a affiché un échec. Deuxième essai, même résultat.

J’ai commencé par soupçonner le mot de passe, puis le client VPN. En réalité, j’avais vérifié que la connexion mobile était rapide ; je n’avais pas vérifié qu’elle laissait mon tunnel professionnel s’établir de la même manière que ma connexion habituelle.

Mon téléphone faisait exactement ce que je lui demandais

Le premier piège était presque trop simple.

Puisque le navigateur fonctionnait sur le portable, j’avais mentalement classé le partage mobile dans la catégorie « Internet OK ».

Et il l’était.

Vidéotron décrit le point d’accès mobile comme un moyen de transformer un téléphone LTE, 4G ou 5G en petit routeur Wi-Fi. L’opérateur cite même les pannes de courant ou de réseau parmi les situations où cette connexion de secours peut être utile.

C’était exactement mon cas.
Téléphone connecté au réseau mobile.
Hotspot actif.
Portable connecté.

Internet disponible.
Le problème commençait seulement quand j’ajoutais la dernière étape :
portable → VPN de l’entreprise → réseau interne.
J’ai relancé le client.

Échec.
J’ai redémarré le portable.
Échec.
J’ai désactivé puis réactivé le hotspot.

Toujours pareil.

À ce stade, recommencer les mêmes manipulations ne m’apprenait plus rien. Il fallait arrêter de réparer au hasard et comparer ce qui fonctionnait avec ce qui échouait.

Sur un autre Wi-Fi, le même VPN démarrait immédiatement

Un peu plus tard, j’ai pu rejoindre un autre accès Wi-Fi.
Même portable.
Même compte.
Même authentification multifacteur.

Même client du bureau.
Cette fois, le tunnel s’est établi.
Le lecteur réseau est apparu.
Je suis revenu au hotspot Vidéotron.

Internet fonctionnait toujours.
VPN : échec.
Ce va-et-vient a changé la question.
Je ne cherchais plus :

« Qu’est-ce qui est cassé dans mon VPN ? »
Je cherchais :

« Qu’est-ce que ce tunnel essaie de faire que ma connexion mobile ne transporte pas de la même façon ? »

Une discussion publique de la communauté Vidéotron décrit la même frustration : un utilisateur connecte son ordinateur au hotspot, dispose bien d’Internet, puis obtient une erreur au moment d’établir le tunnel VPN du bureau.

C’était exactement le genre de symptôme qui m’avait trompé : tout semble fonctionner jusqu’au moment où le VPN professionnel doit construire son propre chemin.

« Vidéotron bloque les VPN » était une conclusion trop facile

J’ai failli m’arrêter là.
Le VPN marche ailleurs.
Il échoue sur le partage mobile.
Donc Vidéotron bloque mon VPN.

C’était séduisant.
Et trop rapide.

Dans sa politique de gestion du trafic Internet Mobile applicable au forfait illimité concerné, Vidéotron précise que ses mesures ne ciblent pas un type de trafic, une application ou un protocole particulier ; le partage de connexion est explicitement cité parmi les usages qui ne sont pas visés spécifiquement.

Je n’avais donc aucune raison solide de transformer mon échec en « l’opérateur interdit les VPN ».

En revanche, le partage mobile n’est pas simplement mon Wi-Fi domestique avec une antenne différente. Le téléphone devient un intermédiaire : le portable lui remet son trafic, puis celui-ci traverse encore le réseau mobile avant d’atteindre Internet.

En février 2026, Vidéotron a d’ailleurs annoncé la modernisation de son cœur de réseau 5G NSA et 4G LTE avec une nouvelle infrastructure Core Gateway. Ce changement ne prouvait pas la cause de mon échec ; il me rappelait surtout une chose plus simple : deux connexions capables d’ouvrir la même page Web ne constituent pas forcément le même chemin réseau.

Pour le navigateur, cette différence pouvait rester invisible.
Pour un tunnel, elle pouvait devenir décisive.

Le détail qui comptait n’était plus le débit, mais le transport

C’est là que la documentation des VPN d’entreprise m’a été plus utile que mon test de vitesse.

Cisco documente un cas très concret : lorsqu’un client VPN utilise IPsec/IKEv2 comme protocole principal et se trouve sur un réseau où le trafic IPsec en UDP 500/4500 ne passe pas, la connexion échoue. Dans la configuration décrite, le client ne bascule pas automatiquement vers TLS/DTLS ; l’autre méthode doit être sélectionnée.

Je ne savais pas encore si c’était exactement ce qui arrivait à mon VPN professionnel.

Mais je n’avais plus besoin d’une explication beaucoup plus compliquée pour comprendre le principe.

Internet peut fonctionner tandis que le chemin précis dont dépend un tunnel ne passe pas.

C’est comme trouver une route ouverte, puis découvrir que le seul pont devant soi n’accepte pas le véhicule qu’on conduit. Les voitures passent ; cela ne signifie pas que mon camion passera aussi.

Mon hotspot faisait passer le Web.
La vraie question était devenue : que faisait-il de mon tunnel ?

J’avais besoin d’un deuxième tunnel, pas d’un deuxième test de vitesse

Je pouvais déjà envoyer au service informatique :
« Le VPN ne marche pas sur mon hotspot. »
Mais il me manquait encore une information.

Le partage Vidéotron posait-il problème à tous les tunnels, ou seulement à la manière dont celui du bureau essayait de s’établir ?

C’est à ce moment-là que j’ai ouvert le petit service utilisé pour les tests de cet article.

Même portable.
Même hotspot.
VPN professionnel fermé.
J’ai laissé l’application choisir automatiquement sa connexion et activé le tunnel.

Connecté.
J’ai ouvert ma messagerie personnelle.
Puis un espace de stockage.
Puis plusieurs pages.

Tout répondait normalement.
J’ai coupé ce tunnel et relancé celui du bureau.
Échec.
Cette comparaison m’a donné la pièce qui me manquait :

le hotspot pouvait transporter un tunnel VPN. C’était le tunnel professionnel, avec sa stratégie de connexion, qui échouait sur ce chemin mobile.

Le petit service ne pouvait évidemment pas me donner accès au réseau privé de mon employeur. Il n’avait ni ses certificats ni ses autorisations, et ce n’était pas son rôle.

Mais comme tunnel témoin, il venait de faire quelque chose de très utile : fonctionner exactement là où l’autre refusait de démarrer.

HTTP/3 m’intéressait soudain pour une raison très concrète

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

Habituellement, ce genre de phrase technique me fait surtout chercher le bouton « fermer ».

Cette fois, je pouvais la rattacher à quelque chose que je venais de voir.

Les deux applications n’essayaient pas de traverser la connexion mobile exactement de la même manière.

Le VPN professionnel suivait la stratégie définie par mon entreprise.

L’autre utilisait un transport différent et s’était connecté sur le même hotspot sans me demander de choisir un protocole, un port ou cinq serveurs différents.

Je n’avais pas besoin de connaître le paquet précis qui coinçait pour que ce résultat soit utile.

Sur le même portable et la même connexion mobile :
VPN du bureau : échec.
Autre tunnel : connecté.
Je pouvais arrêter d’accuser le hotspot en bloc.

Et surtout, je pouvais enfin envoyer au support autre chose qu’un message vague.

Mon message au support a changé d’une phrase

Le premier message que j’avais commencé à écrire disait :
« Mon VPN ne fonctionne plus. »
Je l’ai effacé.
À la place, j’ai envoyé quelque chose de beaucoup plus précis.

Le client du bureau fonctionne sur un autre Wi-Fi.
Internet fonctionne normalement via mon hotspot Vidéotron.
Le tunnel professionnel ne s’établit pas sur ce hotspot.
Un autre tunnel utilisant un transport différent s’établit sur la même connexion mobile.

Est-ce que notre profil utilise IPsec, et existe-t-il un mode TLS autorisé lorsque cette connexion ne passe pas ?

Cette fois, la réponse n’a pas commencé par « redémarrez votre ordinateur ».
L’équipe informatique a vérifié le profil.

Le client utilisait bien sa méthode IPsec habituelle. Une autre méthode de transport était déjà prévue par leur configuration, mais le poste ne l’avait pas sélectionnée automatiquement.

Je n’ai touché à aucune politique de sécurité moi-même.
Le support m’a indiqué le profil autorisé.
J’ai relancé.
Authentification.

Quelques secondes d’attente.
Puis le statut a changé.
Connecté.
J’ai ouvert le lecteur réseau.

Le dossier du projet était là.
Le document aussi.

C’était la première fois depuis le début que le résultat répondait réellement à mon problème.

Pas « Internet fonctionne ».
Pas « le hotspot est rapide ».
Pas même « un autre VPN se connecte ».
Le fichier interne dont j’avais besoin était enfin accessible.

Le petit service avait quand même gagné une place sur mon ordinateur

Une fois le document récupéré, j’ai refermé le VPN professionnel.
Je n’avais aucune raison d’utiliser deux tunnels pour la même tâche.
Mais j’ai gardé le petit service installé.
La raison n’était justement pas qu’il pouvait remplacer celui de l’entreprise.

C’était presque l’inverse.

Le VPN professionnel était lié aux choix techniques et aux règles de mon employeur. Quand son transport habituel ne passait pas, je dépendais du profil que l’équipe informatique avait prévu.

Pour mes usages personnels, le petit service avait fait quelque chose de beaucoup plus simple : il avait vu le réseau devant lui, choisi sa connexion et établi le tunnel sans me transformer en technicien IPsec.

Sur une connexion de secours, cette différence me paraissait soudain beaucoup plus importante qu’une longue liste de serveurs.

Je pouvais ouvrir mon portable, activer le hotspot, connecter le service et reprendre mes usages personnels sans recommencer l’enquête de ce matin-là.

Et son succès m’avait aussi fourni un test que je pouvais comprendre :
le réseau mobile fonctionnait ;
un tunnel fonctionnait ;

c’était la combinaison entre ce chemin mobile et le tunnel professionnel qu’il fallait examiner.

J’avais mesuré la mauvaise chose au début

Au départ, j’avais regardé le débit du hotspot comme s’il répondait à toute la question.
C’était logique.

Quand une connexion fixe tombe, on veut d’abord savoir si le téléphone peut prendre le relais. Vidéotron présente d’ailleurs le point d’accès mobile comme une solution utile lorsqu’un autre accès Internet disparaît.

Ce matin-là, il avait parfaitement rempli cette première mission.

L’erreur était d’avoir confondu avoir Internet avec avoir le chemin dont mon VPN professionnel avait besoin.

Le deuxième tunnel a rendu cette différence visible.
Le support informatique a ensuite pu agir sur la bonne variable.
Et le lecteur réseau s’est enfin ouvert.

Depuis, lorsque je passe mon ordinateur professionnel sur le partage mobile, je ne commence plus par regarder combien de mégabits le téléphone affiche.

Je regarde d’abord si le tunnel démarre — parce que pour récupérer un fichier du bureau, 200 Mbit/s devant une porte fermée valent moins qu’une connexion qui sait réellement l’ouvrir.