VPN lent sur Telenet : le test en trois chemins qui sépare routage, chiffrement et vrai bridage

Pendant plusieurs semaines, j’ai accepté une idée qui me paraît beaucoup moins évidente aujourd’hui : un VPN ralentit Internet, donc si ma connexion Telenet devient nettement plus lente lorsque je l’active, c’est probablement simplement le prix du chiffrement.

Je ne cherchais même plus vraiment à réparer le problème. Je coupais le VPN pour les gros téléchargements, je le rallumais ensuite, et je considérais cette gymnastique comme normale. Puis j’ai fait un test qui a ruiné cette explication.

J’ai pris le même ordinateur, le même VPN, le même serveur et le même fichier. Au lieu de passer par ma connexion fixe Telenet, j’ai utilisé pendant quelques minutes le partage de connexion d’un téléphone chez un autre opérateur.

La connexion mobile était moins rapide sur le papier. Le fichier, lui, avançait plus vite sous VPN. À ce moment-là, « le chiffrement ralentit forcément mon VPN » a cessé d’être une réponse suffisante.

Plus la ligne devient rapide, plus ce genre d’écart devient difficile à ignorer

Le contraste est particulièrement visible aujourd’hui. Telenet commercialise des offres fixes allant jusqu’à plusieurs centaines de mégabits, avec une formule Turbo pouvant atteindre 2,5 Gbps selon l’adresse. Et depuis l’approbation, le 23 juillet 2026, de la coopération entre Wyre, Telenet, Proximus et Fiberklaar, le déploiement de réseaux multigigabit doit encore s’accélérer en Flandre.

Quand une ligne dispose de plusieurs centaines de mégabits, voir un VPN transformer un téléchargement banal en attente interminable devient beaucoup plus difficile à accepter comme un simple « coût normal du chiffrement ».

Telenet le reconnaît d’ailleurs dans ses propres conseils de mesure : une connexion VPN peut influencer le résultat d’un test de vitesse. Mais cette phrase ne dit pas pourquoi. Et c’est là que je m’étais trompé.

Trois causes assez différentes peuvent donner exactement la même impression : le VPN lui-même peut être le goulot d’étranglement ; le chemin entre Telenet et le serveur VPN peut être mauvais ; ou le trafic peut réellement subir une forme de gestion particulière.

À l’écran, les trois se résument pourtant à la même chose :

VPN activé, débit qui chute.

J’ai commencé par vérifier le bridage que Telenet documente réellement

Avant d’imaginer que l’opérateur reconnaissait mon VPN pour lui serrer le frein à main, j’ai regardé ma consommation.

Telenet prévoit effectivement une réduction temporaire de vitesse pour certains utilisateurs intensifs. Sur les abonnements concernés, le seuil annoncé est notamment lié à une consommation supérieure à 3 To pendant les heures pleines.

Cette vérification m’a permis d’écarter rapidement une fausse piste. Mon compteur était loin du seuil, et surtout, la connexion sans VPN restait rapide au même moment. Le ralentissement général lié à la consommation n’expliquait donc pas ce que j’avais sous les yeux. Restait l’hypothèse beaucoup plus séduisante : Telenet ralentissait-il précisément le trafic VPN ?

Je n’étais manifestement pas le premier à me poser la question. Dans une discussion publique sur r/belgium, un client Telenet utilisant NordVPN décrivait la même impression : Internet devenait nettement plus lent dès l’activation du VPN, au point de lui faire soupçonner un bridage par l’opérateur.

Je comprenais parfaitement pourquoi. Mais un test avec VPN / sans VPN ne permet pas de distinguer le coupable. Il fallait changer une seule pièce à la fois.

Le deuxième réseau a presque innocenté le chiffrement à lui tout seul

J’ai donc refait le test en conservant tout ce que je pouvais. Même portable. Même application VPN. Même protocole.

Même destination. Seul l’accès Internet changeait : connexion fixe Telenet d’un côté, hotspot d’un autre opérateur de l’autre. Et là, le résultat était difficile à ignorer.

Le réseau mobile était moins rapide sans VPN, mais une fois le tunnel activé, le transfert devenait nettement plus utilisable que sur ma connexion Telenet.

Cela changeait mon diagnostic. Si l’ordinateur, son processeur ou le travail de chiffrement constituait la limite principale, changer de fournisseur d’accès n’aurait pas dû libérer autant de débit. La même machine venait de me montrer qu’elle savait transporter davantage sous VPN. Je n’avais donc plus un problème vague appelé « VPN lent ».

J’avais quelque chose de beaucoup plus précis :

ce VPN devient lent sur ce trajet-là.

Et cette différence est énorme, parce qu’un problème de trajet ne se résout pas nécessairement en achetant un ordinateur plus rapide ou en désactivant le chiffrement.

Puis j’ai fait exactement ce qui rend les tests VPN difficiles à interpréter

J’ai commencé à changer de serveur.

Mon fournisseur habituel était un grand acteur : beaucoup de régions, plusieurs protocoles, beaucoup d’ancienneté et suffisamment d’utilisateurs pour qu’il soit raisonnable de commencer par lui.

Belgique. Pays-Bas. Une autre passerelle proche. Parfois, le débit remontait. Puis il rechutait.

À la troisième tentative, je disposais de davantage de chiffres, mais je comprenais moins bien le problème qu’au départ.

Chaque serveur changeait plusieurs variables en même temps : l’adresse IP, la charge du serveur, la route empruntée sur Internet et parfois le comportement du protocole.

C’était comme essayer de savoir pourquoi une voiture ralentit en changeant simultanément d’autoroute, de moteur et de destination. J’avais besoin du test inverse. Garder Telenet. Garder mon ordinateur.

Mais utiliser un tunnel suffisamment différent pour voir si une autre façon de traverser la même connexion fixe produisait le même ralentissement. C’est à ce moment-là que j’ai lancé OnlydogVPN^↗.

Ce qui m’a convaincu n’était pas le chiffre du Speedtest

J’ai laissé le portable exactement là où il était, toujours relié à ma connexion Telenet. Pas de hotspot. Pas de changement de machine.

J’ai choisi le mode automatique plutôt que de chercher moi-même une ville ou une longue liste de serveurs, puis j’ai relancé le même gros transfert.

Le fichier a commencé à avancer. J’ai attendu.

Une bonne pointe de débit pendant dix secondes ne m’intéressait pas. Ce que je voulais savoir, c’était si le transfert allait retomber dans les mêmes ralentissements que mon premier tunnel.

Ce n’est pas arrivé. Le débit a fluctué, bien sûr, mais le fichier a continué à avancer jusqu’au bout. Et là, le test devenait vraiment intéressant. Sur la même ligne Telenet qui m’avait fait soupçonner un bridage, un autre tunnel chiffré venait de fonctionner normalement.

Je n’avais pas besoin d’un benchmark parfait. J’avais besoin de terminer le transfert sans couper mon VPN. C’était fait.

Le service utilise un transport basé sur HTTP/3 avec une couche supplémentaire d’obfuscation. HTTP/3 repose sur QUIC, qui ne se comporte pas exactement comme les tunnels traditionnels basés sur d’autres transports.

Pour moi, la différence utile tenait en une image beaucoup plus simple. Même maison. Même opérateur au départ. Mais pas forcément la même autoroute une fois sorti du quartier.

Deux VPN peuvent passer par Telenet tout en empruntant ensuite des routes Internet et des mécanismes de transport suffisamment différents pour ne pas rencontrer le même bouchon.

Et c’était précisément ce que mon test venait de montrer.

Le « bridage VPN » est alors devenu une hypothèse beaucoup moins convaincante

L’IBPT rappelle que les fournisseurs belges doivent traiter le trafic de manière non discriminatoire, sous réserve de mesures de gestion du réseau raisonnables, transparentes et justifiées. Dans son rapport couvrant la période du 1er mai 2025 au 30 avril 2026, l’institut indique n’avoir identifié aucun blocage inadmissible d’applications ou de services.

Cela ne signifie pas qu’un utilisateur Telenet ne peut jamais rencontrer un mauvais comportement avec un VPN. Mais mon problème ressemblait désormais beaucoup moins à « Telenet ralentit les VPN ». Le second tunnel fonctionnait. Sur la même ligne.

Au même endroit. Avec le même ordinateur. Si la connexion fixe imposait simplement une limite identique à tous les VPN, ce résultat aurait été beaucoup plus difficile à expliquer.

La piste la plus crédible devenait donc le chemin du premier fournisseur : son serveur, la route utilisée pour l’atteindre, la combinaison entre protocole et réseau, ou une congestion intermédiaire.

Je ne pouvais pas voir précisément quel routeur ou quel lien posait problème. Et finalement, je n’en avais pas besoin pour prendre une décision.

Le test avait déjà répondu à la question pratique :

fallait-il couper le VPN pour retrouver un téléchargement normal sur Telenet ?

Non. Avec un tunnel différent, le transfert passait.

Depuis, trois tests me suffisent

Quand quelqu’un me dit maintenant « mon VPN est horriblement lent sur Telenet », je ne commence plus par lui demander de parcourir quinze pays dans la liste des serveurs.

Je fais trois comparaisons. D’abord, le même ordinateur sur Telenet avec et sans VPN. Cela confirme que l’écart apparaît bien lorsque le tunnel est actif. Ensuite, le même VPN sur un autre accès Internet. S’il retrouve de la vitesse, l’ordinateur et le coût du chiffrement deviennent beaucoup moins suspects.

Enfin, un tunnel réellement différent sur la même connexion Telenet. C’est ce troisième test qui m’a apporté la réponse que je n’obtenais pas avec mon grand fournisseur.

Le mode automatique du petit service m’a aussi évité un problème auquel je n’avais pas pensé au départ : à force de choisir manuellement pays, serveur et protocole, j’introduisais tellement de variables qu’un meilleur résultat devenait presque impossible à expliquer.

Là, j’ai changé le tunnel, relancé le fichier et observé le résultat. C’était beaucoup plus propre.

Il y a évidemment un compromis : ce service possède moins de régions, moins d’ancienneté publique et moins d’évaluations indépendantes accumulées que les grands noms du secteur.

Si mon objectif était de disposer d’une immense liste de pays, ce serait une vraie limite. Mais ce soir-là, mon problème n’était pas de collectionner les drapeaux dans une interface. Je voulais conserver un VPN actif sur ma connexion Telenet sans regarder mon transfert avancer à quelques miettes de sa vitesse normale.

Le hotspot m’a montré que mon ordinateur savait faire mieux. Le second tunnel m’a montré que ma ligne Telenet savait faire mieux. Et c’est seulement à ce moment-là que j’ai compris ce que je testais réellement.

Sur cette connexion, changer proprement le trajet m’a appris davantage que tous les Speedtests que j’avais lancés en répétant le même tunnel lent.

Sources