Pourquoi une vidéo peut-elle devenir lente ou ne pas démarrer avec un VPN ? J’ai compris que le cercle de chargement ne mesurait pas seulement mon débit

La première fois, la vidéo n’a pas démarré. La deuxième fois, elle a démarré en quelques secondes, puis l’image est devenue floue. J’avais pourtant changé une seule chose: le serveur de mon VPN.

C’est précisément ce qui m’a dérouté.

Dans ma tête, ces deux échecs racontaient la même histoire: le VPN ralentissait Internet.

J’ai lancé un test de débit. Plus de 200 Mbit/s. J’ai recommencé. Toujours largement assez pour une vidéo.

Puis j’ai coupé le VPN.

Lecture. L’image est apparue presque immédiatement.

À ce moment-là, j’étais prêt à tirer la conclusion habituelle: le VPN chiffre le trafic, donc il ralentit la vidéo.

Mais cette explication collait mal à ce que je venais d’observer. Avec un serveur, la vidéo ne passait même pas le bouton Lecture. Avec un autre, elle passait le bouton Lecture mais peinait quelques minutes plus tard.

Ce n’étaient pas simplement deux versions du même problème.

Une vidéo qui ne démarre pas n’est pas toujours une vidéo qui manque de débit

C’est la première distinction que j’aurais aimé faire avant de commencer à changer les serveurs.

Une plateforme vidéo ne reçoit pas immédiatement un énorme flot d’images dès que j’appuie sur Lecture.

Avant cela, elle doit accepter la connexion, déterminer ce qu’elle peut me montrer, établir les échanges nécessaires avec le lecteur et commencer à récupérer les données vidéo.

Un VPN peut modifier plusieurs éléments de ce trajet, notamment l’adresse IP publique et le chemin utilisé jusqu’au service.

Netflix fournit un exemple très clair de ce premier type d’échec: la plateforme peut afficher une erreur lorsqu’elle identifie l’utilisation d’un VPN ou d’un proxy. Elle précise également que les VPN ne sont pas pris en charge pour les événements en direct ni avec son offre financée par la publicité.

Dans ce cas, ajouter 100 Mbit/s ne résout rien. La vidéo ne manque pas encore de vitesse. Elle est arrêtée avant même que le débit devienne le vrai sujet.

C’était exactement l’erreur que je faisais en regardant uniquement mon Speedtest.

Je mesurais la largeur de la route alors que le lecteur pouvait encore être arrêté au péage.

Une fois la vidéo lancée, le problème change

Lorsque les premières images apparaissent, le lecteur doit continuer à recevoir suffisamment de données pour rester en avance sur ce que je regarde.

YouTube parle d’ailleurs de débit soutenu, et pas simplement d’un pic obtenu pendant quelques secondes. Son aide indique environ 5 Mbit/s recommandés pour du 1080p et 20 Mbit/s pour de la 4K.

Le mot qui m’intéressait était « soutenu ». Mon test de débit pouvait monter très haut pendant un instant.

Cela ne signifiait pas que le trajet réellement utilisé par la vidéo allait fournir les données avec la même régularité pendant les vingt prochaines minutes.

C’est là que le chemin jusqu’au contenu devient important.

Les grandes plateformes distribuent leurs vidéos depuis des infrastructures réparties géographiquement afin de rapprocher le contenu des spectateurs. Cloudflare résume le principe ainsi: une bonne diffusion dépend notamment d’un point de livraison proche et d’un routage efficace jusqu’au contenu demandé.

En activant un VPN, je change une partie de ce trajet.

Le service vidéo ne me voit plus forcément arriver depuis le même réseau ni depuis le même emplacement logique.

La route jusqu’à la vidéo peut donc changer elle aussi.

Mon accès fibre pouvait afficher 500 Mbit/s et malgré tout emprunter, à travers un serveur VPN donné, un chemin moins favorable vers la plateforme vidéo.

Et soudain, mes deux échecs devenaient beaucoup plus faciles à lire. Premier serveur: la lecture bloque avant de réellement commencer.

Deuxième serveur: la lecture est acceptée, mais le trajet vidéo tient mal dans la durée.

Un cercle de chargement cache plusieurs pannes différentes

Une discussion publiée en juillet 2026 sur r/ProtonVPN illustrait exactement ce piège.

Un utilisateur expliquait que Prime Video fonctionnait normalement sans VPN. Avec le VPN activé, l’application et le reste de la connexion continuaient à fonctionner, mais les vidéos restaient bloquées au chargement malgré plusieurs essais de serveurs, de pays et de protocoles.

Ce témoignage ne permet pas de déterminer ce qui se passait à l’intérieur de Prime Video.

Mais côté utilisateur, la conséquence est très reconnaissable. Internet fonctionne. L’application s’ouvre. Le catalogue peut même apparaître.

Puis la vidéo ne part pas. Face à cela, « mon VPN est lent » paraît être une explication naturelle. Elle n’est simplement pas assez précise pour savoir quoi essayer ensuite.

Et j’étais en train de tomber dans la même mécanique. Changer de serveur. Changer de protocole. Revenir au premier.

Essayer un autre pays. Chaque tentative ajoutait une nouvelle combinaison. Aucune ne me disait quelle partie du trajet posait réellement problème.

J’ai arrêté de chercher le serveur le plus rapide

Mon fournisseur habituel avait un avantage évident: beaucoup de régions, beaucoup de serveurs et suffisamment de réglages pour essayer plusieurs chemins.

J’ai utilisé cet avantage.

France. Puis un autre serveur français. Puis un troisième. Une vidéo a refusé de démarrer.

Une autre tentative a démarré mais a baissé rapidement en qualité. Une troisième a mieux fonctionné pendant quelques minutes. À chaque fois, le VPN me donnait une nouvelle porte.

Je devais encore découvrir moi-même laquelle menait correctement jusqu’au lecteur. C’est là que mon critère a changé. Je ne voulais plus savoir: quel serveur donne le plus gros chiffre?

Je voulais savoir: quel chemin franchit le bouton Lecture puis continue à alimenter la vidéo? Les deux moments sont différents, mais ils appartiennent au même trajet.

C’est seulement après avoir compris cela que j’ai ouvert OnlydogVPN.

J’ai choisi « streaming » au lieu de choisir une nouvelle ville

Le petit service ne me demandait pas de résoudre le problème à partir d’une carte géographique.

Son interface est organisée autour de l’usage recherché, avec notamment un mode consacré au streaming qui laisse davantage de décisions de route à l’application au lieu de demander à l’utilisateur de tester manuellement une succession de serveurs.

J’ai sélectionné ce mode.

Connexion.

Puis j’ai complètement fermé le lecteur avant de le rouvrir, pour repartir proprement sur la nouvelle route.

J’ai appuyé sur Lecture. L’écran noir a duré un instant. Puis le générique est apparu. Je n’ai pas arrêté le test là.

Le serveur précédent était lui aussi parvenu jusque-là. J’ai donc laissé tourner. Cinq minutes. La résolution est montée.

Dix minutes. Je suis revenu quelques secondes en arrière. La vidéo est repartie immédiatement. J’ai avancé jusqu’à un autre passage.

Toujours pas de cercle de chargement. Cette fois, j’avais les deux résultats que je cherchais. Le lecteur avait accepté la connexion. Et la route continuait à lui fournir la vidéo après les premières images.

HTTP/3 m’a surtout aidé à comprendre pourquoi la deuxième moitié du test tenait mieux

Une fois la vidéo stabilisée, j’ai regardé ce qui différenciait cette connexion.

Le service utilise notamment un transport basé sur HTTP/3 pour son tunnel.

Cela n’explique pas à lui seul pourquoi une plateforme accepte une adresse IP donnée.

En revanche, c’est directement pertinent lorsque la vidéo a déjà commencé et que le réseau devient irrégulier.

HTTP/3 s’appuie sur QUIC. Cloudflare explique notamment que ce transport évite certains ralentissements en chaîne propres à TCP lorsqu’une partie des données se perd, ce qui peut améliorer le comportement sur des réseaux imparfaits.

Je l’ai compris avec une image simple.

Dans une file classique, un colis manquant peut retenir inutilement ceux qui attendent derrière.

QUIC est conçu pour éviter qu’un seul incident bloque toute la file. Cela ne crée pas de bande passante.

Mais une fois qu’une bonne route de streaming a été trouvée, c’est exactement le genre de comportement que je veux dans le tunnel qui transporte la vidéo.

Et dans ce test, la différence était visible sans ouvrir une page de statistiques: la vidéo continuait simplement à avancer.

Mon Speedtest n’était pas faux, il répondait seulement à une autre question

C’est finalement ce qui m’a le plus surpris. Le résultat initial de plus de 200 Mbit/s n’était pas inutile.

Il me disait que ma connexion pouvait transporter beaucoup de données vers le serveur de test choisi.

Il ne me disait pas: si la plateforme vidéo accepterait mon adresse VPN; quel chemin serait utilisé jusqu’à son infrastructure vidéo; ni si ce chemin resterait suffisamment régulier une fois la lecture lancée.

Netflix recommande d’ailleurs Fast.com dans certaines procédures de diagnostic, ce qui permet de vérifier la connexion depuis un environnement directement lié à son propre réseau plutôt que de supposer qu’un test général décrit automatiquement l’expérience Netflix.

À partir de là, je n’ai plus considéré le cercle de chargement comme un diagnostic. C’était seulement un symptôme. La vraie question devenait: à quel moment la vidéo casse-t-elle?

Avant la première image?

Je regarde d’abord la route choisie, l’adresse de sortie et la manière dont le service accepte la connexion.

Après quelques minutes?

Je regarde davantage la régularité du trajet et la façon dont le tunnel absorbe les petits défauts du réseau.

Cette distinction m’a fait gagner plus de temps que les changements de serveurs en série.

Le plus petit service garde aussi ses limites

Le fournisseur que j’utilisais au départ conserve des avantages évidents.

Il possède davantage de régions, davantage d’historique public et davantage de contrôle manuel.

Le service plus petit propose moins de zones et dispose de moins d’années de retours publics et d’évaluations indépendantes.

Pour quelqu’un qui doit impérativement choisir une ville précise ou construire une configuration très spécifique, cette différence compte.

Mais ce soir-là, la quantité de choix ne m’avait pas rapproché du résultat. Elle m’avait surtout permis de refaire le même problème de nombreuses façons.

Le mode orienté streaming avait simplifié la décision à la tâche que je savais réellement décrire.

Je voulais lancer une vidéo. Puis je voulais qu’elle continue. C’est exactement ce que j’ai pu vérifier à l’écran.

Je pensais au départ qu’une vidéo lente et une vidéo qui refuse de commencer prouvaient toutes les deux que mon VPN manquait de vitesse.

Je sais maintenant qu’un lecteur peut échouer avant même que le débit devienne le problème, ou accepter la connexion puis souffrir d’un trajet médiocre pendant la diffusion.

Le fournisseur mature m’avait donné beaucoup de chemins à essayer. Le mode orienté streaming m’en a donné un qui a franchi les deux parties du test.

Je ne juge donc plus mon VPN au meilleur chiffre affiché avant la lecture: je regarde s’il fait passer la vidéo par le bouton Lecture, puis s’il la conduit encore proprement dix minutes plus tard.