Quel VPN choisir quand le réseau détecte le VPN ? Celui qui change sa signature avant de me faire désactiver la sécurité du Wi-Fi

J’ai activé une fonction censée rendre mon Wi-Fi plus sûr. Trois minutes plus tard, mon VPN ne fonctionnait plus. C’était chez moi, à Montréal.

L’application Helix Fi de Vidéotron me proposait sa fonction Sécurité avancée : surveillance de l’activité des appareils, détection des comportements suspects et blocage automatique de certaines menaces. Elle était déjà incluse dans mon forfait, alors je l’ai activée.

Pourquoi pas ? Le lendemain matin, j’ai ouvert mon ordinateur pour préparer une présentation client. Internet fonctionnait. Le navigateur fonctionnait. Ma visioconférence aussi. Puis j’ai lancé le VPN que j’utilisais habituellement. Connexion… Connecté. J’ai ouvert mon espace de travail. La page a commencé à charger. Puis plus rien. J’ai changé de serveur. Même chose. J’ai essayé mon téléphone.

Sur le réseau mobile, le même VPN fonctionnait immédiatement. Retour sur Helix : blocage. J’ai fini par désactiver temporairement la Sécurité avancée. VPN reconnecté. La page s’est ouverte. Je venais de créer un problème assez ridicule. J’avais désormais deux outils censés améliorer ma sécurité, mais je devais apparemment en éteindre un pour utiliser l’autre.

Au début, j’ai cru qu’un changement de serveur suffirait

C’était mon vieux réflexe. Un serveur ne marche pas ? Prenez-en un autre. Mon fournisseur principal avait largement de quoi m’occuper. Beaucoup de régions. Plusieurs serveurs proches. Des protocoles différents. Une application mature. J’ai donc réactivé la Sécurité avancée et recommencé. Serveur numéro deux. Connexion. Quelques secondes d’Internet. Puis les applications se sont de nouveau mises à attendre.

Serveur numéro trois. Même résultat. À ce stade, changer encore d’adresse commençait à ressembler à une fausse solution.

Si le réseau reconnaissait surtout la manière dont mon tunnel communiquait, je pouvais parcourir toute la liste des serveurs sans changer ce qu’il observait réellement.

Une discussion publique de juillet 2026 m’a conforté dans cette idée.

Un administrateur système racontait que des milliers de salariés en télétravail rencontraient soudainement des difficultés avec leurs VPN Cisco et Fortinet sur plusieurs fournisseurs nord-américains, dont Vidéotron, lorsque certaines fonctions de sécurité avancée étaient actives. Chez les utilisateurs concernés, désactiver cette protection rétablissait la connexion.

Ce témoignage ne permettait pas d’expliquer à lui seul mon réseau domestique. Mais il correspondait assez précisément au comportement que j’avais sous les yeux pour changer mon diagnostic. Je ne cherchais plus un meilleur serveur. Je cherchais une connexion moins facile à reconnaître comme tunnel VPN.

Un VPN chiffre ce qu’il transporte, pas forcément le fait qu’il existe

C’est une distinction que j’avais longtemps mal comprise. J’imaginais vaguement qu’une fois le VPN activé, tout devenait invisible. Le contenu est chiffré. Mais le réseau continue à voir des paquets. Leur taille. Leur rythme. Leur destination. Et parfois certains motifs suffisamment caractéristiques pour reconnaître le type d’application qui les produit.

Les équipements de sécurité modernes ne se limitent plus forcément à vérifier un numéro de port. Fortinet documente par exemple des fonctions d’Application Control capables d’identifier des applications à partir du trafic lui-même, y compris lorsqu’elles passent par des ports non standards.

L’image qui m’aide le plus est celle d’une enveloppe opaque. Le réseau ne lit pas nécessairement la lettre. Mais il peut encore reconnaître la forme de l’enveloppe et la manière dont elle est envoyée.

Des travaux présentés à USENIX ont montré à quel point cette signature peut être exploitable : les chercheurs ont réussi à identifier une grande partie du trafic OpenVPN à partir de caractéristiques protocolaires, de tailles de paquets et du comportement des serveurs. Dans leur évaluation, plus de 85 % des flux OpenVPN ciblés étaient reconnus avec très peu de faux positifs.

C’est là que le conseil classique « passez simplement par le port 443 » montre ses limites.

Changer la porte ne suffit pas toujours si le paquet garde exactement la même silhouette.

J’ai changé de protocole avant de changer de VPN

Mon grand fournisseur proposait heureusement plusieurs choix. C’était ici un vrai avantage. J’ai commencé par son mode rapide habituel. Même problème. Puis je suis passé à une option TCP. Cette fois, la connexion s’est établie plus proprement. Mon espace client s’est ouvert. J’ai cru avoir terminé. Puis j’ai lancé le partage d’écran de la présentation. L’image s’est figée. Une seconde. Trois. Retour. Puis nouveau gel.

Je pouvais probablement faire la réunion comme ça. Caméra coupée. Partage d’écran seulement quand c’était indispensable. Ou désactiver Helix pendant une heure. Mais ce n’était plus vraiment ce que je cherchais. Au départ, je voulais seulement voir le mot Connecté. Maintenant, je voulais un VPN que je n’aie pas à négocier avec mon réseau domestique chaque matin.

C’est là que j’ai cherché un mode obfusqué plutôt qu’un quatrième serveur

J’ai ouvert OnlydogVPN. Je n’ai pas commencé par choisir Montréal, Toronto ou New York. J’ai utilisé le mode destiné aux réseaux restrictifs. Et surtout, j’ai laissé la Sécurité avancée Helix activée. Connexion. Quelques secondes. Connecté. OpenVPN TCP avait lui aussi réussi cette étape, alors je n’en ai rien conclu. J’ai rouvert les mêmes outils. Espace client. Chargé. Présentation.

Chargée. Visioconférence. Connectée. Puis j’ai lancé le partage d’écran. Première slide. Deuxième. Troisième. Cinq minutes plus tard, nous parlions toujours de la présentation. Je n’avais plus le VPN ouvert devant moi. C’était exactement le résultat que je voulais. Je n’avais désactivé ni la borne, ni sa fonction de sécurité pour tout le foyer.

Et je n’étais plus en train de transformer une réunion client en banc d’essai de protocoles.

Cette fois, l’obfuscation répondait exactement au problème

Le service combine un transport basé sur HTTP/3 avec une couche supplémentaire d’obfuscation. Pour cette panne, c’est surtout cette deuxième partie qui comptait. Changer de serveur modifie la destination. Changer de port modifie une partie du chemin. L’obfuscation s’attaque davantage à l’apparence du trafic lui-même.

Elle ne rend pas un VPN magiquement invisible — les travaux sur le fingerprinting montrent justement que des systèmes suffisamment avancés peuvent encore identifier certains trafics obfusqués.

Mais elle change enfin la bonne variable. Dans mon test : VPN habituel avec Sécurité avancée active → connexion inutilisable ; autre protocole standard → connexion possible mais partage d’écran instable ; mode obfusqué → réunion et partage d’écran utilisables sans désactiver la protection réseau. Je n’avais plus besoin d’un quatrième serveur. J’avais enfin changé ce que le réseau semblait remarquer.

Garder Helix activé ne signifie pas empiler deux protections identiques

Une chose méritait tout de même d’être clarifiée.

Vidéotron explique qu’un VPN peut réduire l’efficacité de certaines fonctions Helix Fi, puisque les requêtes de l’appareil sont chiffrées dès qu’elles passent dans le tunnel. La borne ne peut alors plus analyser cette navigation de la même manière.

Donc mon résultat ne signifiait pas : Helix inspecte tout et le VPN chiffre tout, donc je bénéficie de deux protections complètes superposées. Ce que j’obtenais était plus concret.

Je pouvais laisser la Sécurité avancée active pour le reste du foyer — téléviseur, objets connectés, autres appareils — sans couper globalement cette fonction chaque fois que mon ordinateur professionnel lançait son VPN.

C’était déjà beaucoup mieux que mon premier réflexe :

« désactiver la sécurité pendant la réunion et penser à la remettre ensuite ».

J’ai compris pourquoi le mot « obfusqué » ne m’avait jamais intéressé avant

Sur mon ancienne connexion, presque tous mes VPN fonctionnaient. Dans ce contexte, l’obfuscation ressemblait à une fonction spécialisée, destinée à des réseaux beaucoup plus restrictifs que le mien. Puis ma propre connexion domestique a commencé à mieux reconnaître certains tunnels. Et soudain, cette fonction répondait à un problème parfaitement banal :

Internet fonctionne, le VPN fonctionne ailleurs, mais les deux refusent de fonctionner correctement ensemble sur ce réseau.

Depuis, je ne cherche pas automatiquement un mode obfusqué au premier échec. Je commence par un test beaucoup plus utile. Même ordinateur. Même VPN. Un autre réseau, comme le partage mobile. S’il fonctionne immédiatement ailleurs, le réseau local devient le suspect. À partir de là, je ne passe plus ma matinée à essayer dix serveurs qui utilisent la même méthode. Je cherche une autre manière de transporter le tunnel.

Le grand fournisseur reste plus complet, mais ce n’était plus mon critère

Mon fournisseur habituel dispose de davantage de régions. Il a une histoire publique plus longue. Beaucoup plus d’avis et d’analyses indépendantes existent à son sujet. Pour quelqu’un qui veut régler manuellement chaque protocole et chaque destination, cette maturité reste un avantage réel. Le service plus petit a moins de localisations et moins de recul public.

Mais le matin où mon réseau a commencé à reconnaître ou perturber le VPN, je ne manquais justement pas de destinations.

Je manquais d’une connexion qui se présente autrement. C’est désormais comme cela que je répondrais à la question « quel VPN choisir quand le réseau détecte le VPN ? ». Je ne commencerais pas par compter les serveurs. Je ne commencerais même pas par chercher le port le plus discret.

Je regarderais si le service possède un véritable mode obfusqué, puis je testerais la seule chose qui compte vraiment : est-ce que mon application recommence à fonctionner sur ce réseau précis ?

Ce matin-là, mon premier VPN me proposait encore toute une carte du monde.

Le mode que j’ai gardé est celui qui m’a permis de laisser Helix tranquille, fermer les réglages et recommencer à parler de ma présentation au lieu de parler de mon VPN.