Comment lire les résultats d’un test de débit
Un résultat de test de débit est un instantané de quatre mesures — vitesse de téléchargement, vitesse d’envoi, latence et gigue — prises entre votre appareil et un serveur de test proche, à un instant donné, sur une connexion qui était peut-être occupée à autre chose à ce moment-là. C’est un instantané utile, mais ce n’est pas un verdict sur votre fournisseur d’accès, et ce n’est pas un seul chiffre : une connexion peut être rapide et pourtant désagréable, ou modeste sur le papier et parfaitement fluide à l’usage, selon lequel des quatre chiffres est le plus faible. Cet article explique ce que mesure chaque chiffre, ce qui est considéré comme bon pour naviguer, les appels vidéo, les jeux et le streaming 4K, pourquoi la même ligne donne un résultat différent à chaque mesure, et comment transformer un résultat en preuve sur laquelle votre fournisseur peut réellement agir. Vous pouvez lancer un test vous-même dans le test de vitesse internet, qui mesure votre connexion jusqu’au centre de données Cloudflare le plus proche, directement dans votre navigateur.
Les quatre chiffres, et ce que chacun mesure vraiment
La vitesse de téléchargement est le débit dans un sens : le nombre de mégabits par seconde (Mbps) que le test a réussi à tirer du serveur vers votre appareil, en utilisant des téléchargements de plus en plus gros et en rapportant un percentile élevé des échantillons plutôt qu’un pic isolé. La vitesse d’envoi est la même mesure en sens inverse — la rapidité avec laquelle votre appareil peut pousser des données vers l’extérieur — et c’est le chiffre qui décide de la qualité de votre image pour les autres participants d’un appel, du temps que prend une sauvegarde et de la durée d’envoi d’un gros fichier. Les deux sont souvent très asymétriques dans les offres domestiques, et un envoi lent avec un téléchargement rapide est la forme de l’offre, pas une panne.
La latence, souvent appelée ping, est le temps aller-retour d’une minuscule requête jusqu’au serveur et retour, mesuré en millisecondes : c’est l’attente avant que quoi que ce soit commence à bouger, et c’est ce qui fait qu’une connexion paraît réactive ou paresseuse. La gigue est la variation entre des mesures de latence consécutives — la stabilité de ce délai. Une connexion avec 25 ms de latence et 3 ms de gigue paraît nette ; la même moyenne de 25 ms avec 40 ms de gigue paraît saccadée, parce que les images vidéo et les paquets vocaux arrivent de façon irrégulière. À titre indicatif : naviguer sur le web est confortable à partir d’environ 10 Mbps en téléchargement avec une latence inférieure à 100 ms ; un appel vidéo de groupe demande environ 3–8 Mbps dans chaque sens, avec une latence inférieure à 150 ms et une gigue inférieure à 30 ms ; les jeux en ligne se soucient peu du débit brut — 5–10 Mbps suffisent largement — mais veulent une latence inférieure à 50 ms et une gigue inférieure à 20 ms ; et un seul flux 4K nécessite généralement environ 25 Mbps de téléchargement soutenu. Divisez les Mbps par 8 pour obtenir des mégaoctets par seconde, l’unité qu’utilise l’indicateur de téléchargement de votre navigateur.
Pourquoi la même ligne donne un chiffre différent à chaque fois
Un test de débit dans le navigateur mesure tout le chemin, pas seulement la ligne de votre fournisseur : votre appareil, votre wifi, votre routeur, la ligne jusqu’au central, le réseau de votre fournisseur et la route jusqu’au serveur de test. N’importe lequel de ces maillons peut être le goulot d’étranglement lors d’une mesure donnée. Le wifi est le suspect habituel sur les connexions rapides — il délivre rarement la totalité du débit de la ligne, et se dégrade avec la distance, les murs et les réseaux voisins —, suivi des autres appareils sur la même connexion, des mises à jour en arrière-plan et des synchronisations cloud, du navigateur lui-même sur une machine occupée, et de l’heure de la journée : les soirées, quand le quartier regarde des vidéos, sont l’heure de pointe du réseau partagé. La distance au serveur compte aussi, c’est pourquoi ce test mesure contre le centre de données Cloudflare le plus proche plutôt que contre un serveur sur un autre continent.
La méthodologie ajoute une seconde couche de différences. Les tests divergent sur la taille des fichiers, sur l’ouverture d’un seul flux ou de plusieurs, sur le percentile rapporté, et sur la question de savoir si le serveur de test se trouve dans le réseau de votre fournisseur (on-net, chemin plus court, chiffres flatteurs) ou en dehors (off-net, plus proche de la navigation réelle). Il n’existe pas de définition standard unique de la vitesse internet, donc les chiffres de différents outils ne sont pas directement comparables — 400 Mbps de l’un et 300 Mbps de l’autre peuvent être deux mesures honnêtes de choses différentes. Une seule mesure lente ne prouve ni la congestion ni le bridage : seul un motif récurrent, mesuré de la même façon pendant plusieurs jours, peut étayer l’une ou l’autre affirmation.
Pourquoi le test peut sembler bon pendant que l’application saccade — ou l’inverse
Un test de débit mesure le chemin vers un serveur de test. Votre appel vidéo, votre jeu ou votre plateforme de streaming se connectent à des serveurs différents, souvent dans des villes différentes, par des routes différentes — et ces routes peuvent être congestionnées alors que le chemin du test est libre, ou l’inverse. Le débit n’est aussi qu’une partie de l’histoire pour les applications réelles : presque tout ce que vous faites en ligne consiste en petits transferts, et les petits transferts sont limités par la latence, pas par la bande passante, parce que chaque aller-retour attend des accusés de réception avant d’envoyer plus de données. C’est pourquoi une connexion à 500 Mbps peut charger les pages lentement si la latence est élevée, et pourquoi une modeste connexion à 50 Mbps avec 15 ms de latence peut paraître instantanée. La latence au repos ne raconte pas non plus toute l’histoire : la latence en charge — de combien le délai augmente pendant que la connexion est occupée — est ce qui décide si un appel saccade quand un téléchargement démarre.
Traitez donc un écart comme une information, pas comme une contradiction. Si le test est sain mais qu’une application ne l’est pas, le problème se situe probablement au-delà de votre ligne : les serveurs de cette application, la route vers eux, ou quelque chose sur l’appareil. Vérifier la même destination depuis de nombreux endroits dans le monde, comme dans Est-ce en panne ou est-ce juste moi ?, sépare un problème local d’un problème global. Si toutes les applications saccadent alors que le test semble bon, regardez ce que le test ne mesure pas : la latence en charge, la perte de paquets, et ce qui utilisait la connexion au moment de la saccade. Et si le test est lent mais que les applications semblent bonnes, l’anomalie est peut-être le chemin du test ou le moment choisi, pas votre expérience quotidienne.
Comment lancer un test auquel vous pouvez vraiment faire confiance
Décidez ce que vous testez avant de commencer. Pour tester la ligne elle-même, utilisez une connexion Ethernet filaire, un seul appareil, et rien d’autre en cours : fermez le streaming, mettez en pause la synchronisation cloud et les mises à jour, et fermez les autres onglets du navigateur. Pour tester le wifi d’une pièce, testez depuis cette pièce, avec l’appareil que vous y utilisez réellement — mais le résultat décrit alors la pièce, pas la ligne, et ne devrait pas être cité à votre fournisseur comme vitesse de ligne. Lancez le test au moins trois fois et prenez la médiane, pas le meilleur résultat ; testez à différentes heures de la journée, y compris le pic du soir ; et gardez les mêmes conditions entre les mesures que vous comptez comparer. Un seul résultat est un instantané ; un ensemble de résultats comparables est une preuve.
Notez les conditions à côté des chiffres — filaire ou wifi, heure de la journée, ce qui tournait en parallèle — et tenez un petit journal pendant plusieurs jours si vous constituez un dossier. Un test complet peut déplacer une quantité de données considérable, jusqu’à environ 200 Mo, évitez donc les tests répétés sur une connexion facturée au volume ou plafonnée. Exportez ou capturez chaque résultat avec son horodatage ; le test de vitesse internet de ce site propose un export CSV exactement pour cela, de sorte qu’une semaine de chiffres comparables puisse être montrée à un fournisseur dans un seul fichier au lieu d’être discutée de mémoire.
Ce qu’un test de débit ne peut pas vous dire
Un test de débit rapporte des symptômes, pas des causes. Il ne peut pas dire pourquoi des paquets se perdent — si la cause est une interférence wifi, un câble défectueux, un lien congestionné ou un modem en panne — et il ne peut pas mesurer le bufferbloat, le gonflement de la latence en charge, à moins de sonder spécifiquement la latence pendant que la connexion est saturée. Il ne peut pas non plus diviser le chemin entre réseau domestique et réseau du fournisseur en une seule mesure : un résultat lent en wifi et un résultat lent sur la ligne ont exactement la même apparence dans les quatre chiffres, et seule une comparaison filaire les sépare. Il ne peut pas voir du tout dans votre réseau domestique — quel appareil monopolise la bande passante, si le routeur surchauffe, ou si le réseau d’un voisin piétine votre canal wifi.
Il ne peut pas non plus diagnostiquer des problèmes qui ne concernent pas la connexion. Un site qui vous bloque ou vous bride parce que votre adresse IP a une mauvaise réputation semblera cassé, quelle que soit la vitesse mesurée ; c’est un problème de réputation, expliqué dans Pourquoi votre adresse IP est signalée, et aucune bande passante ne le corrige. Un test ne peut pas non plus distinguer un bridage délibéré d’une congestion ordinaire — les deux ressemblent à un chiffre plus bas — ni vous dire si un site lent est lent pour tout le monde. Pour ces questions, combinez les outils : comparez le filaire et le wifi, testez la même destination depuis de nombreux endroits avec l’outil Global Ping, et cherchez un motif récurrent dans le temps avant de conclure.
Quand appeler votre fournisseur — et quels chiffres citer
Appelez quand un motif récurrent persiste, pas quand un seul résultat déçoit. Le seuil d’une vraie réclamation ressemble à ceci : des tests filaires, sur plus d’un jour, à différentes heures y compris en heures creuses, constamment très en dessous de la vitesse de votre offre — moins de la moitié est un signal fort — ou une latence et une gigue qui restent élevées en filaire quand rien d’autre n’utilise la connexion. Redémarrez le routeur une fois et retestez avant d’appeler, pour que cette étape soit déjà faite. Ne commencez pas par un résultat wifi depuis la chambre la plus éloignée : la première chose que le support vous demandera est un test filaire, et une réclamation construite sur des chiffres wifi sera classée comme problème de réseau domestique.
Citez les chiffres qui permettent au support d’agir : la vitesse de votre offre, la médiane d’au moins trois tests filaires avec dates et heures, la latence et la gigue de ces mêmes tests, et ce que vous avez écarté — un seul appareil, pas de trafic en arrière-plan, routeur redémarré. Dites si le problème est constant ou dépend de l’heure de la journée, car une lenteur uniquement nocturne pointe vers la congestion du réseau partagé, tandis qu’une lenteur toute la journée pointe vers la ligne ou l’équipement. Demandez un contrôle de ligne et un numéro de ticket, et conservez vos résultats exportés : une liste calme de chiffres comparables, recueillis de la même façon pendant plusieurs jours, est bien plus difficile à écarter qu’une capture d’écran furieuse.