Pourquoi trois tests de débit donnent trois chiffres différents

Trois réponses, et toutes sont défendables

Lancez un test sur trois sites différents en l’espace d’une minute et vous obtiendrez peut-être 300 Mbps, 180 Mbps et 90 Mbps. La tentation est grande d’en conclure que deux d’entre eux sont défaillants. En pratique, chacun répond à une question légèrement différente, et l’écart entre eux porte plus d’information que n’importe quel chiffre isolé.

L’un mesure la capacité que la ligne peut transporter lorsqu’elle est délibérément saturée. Un autre mesure la vitesse à laquelle voyagera un téléchargement réel unique. Un troisième mesure peut-être un chemin qui ne sort jamais du réseau de votre propre fournisseur. Ce sont trois grandeurs légitimes, avec trois usages légitimes.

Les connexions parallèles modifient le plafond

Une connexion TCP unique a besoin de temps pour monter en charge jusqu’à la capacité maximale de la ligne. Ouvrez-en huit ou seize simultanément et chacune monte en charge en parallèle : l’agrégat atteint donc le plafond bien plus vite, et sur un test court, cette différence est considérable. Les tests multithreads rapportent par conséquent des chiffres plus élevés, et ils sont l’outil approprié lorsque la question est : « ai-je obtenu la capacité que j’ai payée ? »

Les tests à un seul thread rapportent des chiffres plus bas et sont l’outil approprié lorsque la question est : « à quelle vitesse ce téléchargement va-t-il réellement aller ? » Un flux vidéo, un téléchargement de jeu, un fichier issu d’un CDN et un appel vidéo sont tous, en pratique, des flux uniques. L’écart entre les deux méthodes n’est pas une erreur de mesure : c’est la différence entre un chiffre de capacité et un chiffre de livraison.

La latence amplifie cet effet. Plus le temps d’aller-retour est élevé, plus une connexion unique passe de temps à monter en charge ; les liaisons à forte latence — satellite, certains réseaux sans fil fixes, longs trajets internationaux — présentent donc l’écart le plus large entre résultats single-thread et multi-thread.

L’emplacement du serveur détermine la route mesurée

Différents outils s’appuient sur différents réseaux de serveurs. Certains choisissent le point de terminaison disponible le plus proche, d’autres utilisent un réseau de diffusion de contenu lié à un service précis, d’autres encore des serveurs hébergés au sein même du réseau d’un fournisseur d’accès. Chaque choix mesure un chemin différent.

Un test vers un serveur situé à l’intérieur du réseau de votre fournisseur ne franchit jamais d’interconnexion : il peut légitimement annoncer le meilleur chiffre que vous verrez jamais, et il ne dit rien de la façon dont le trafic atteint les services extérieurs à ce réseau. Un test mené contre le CDN d’un fournisseur de contenu vous indique comment ce fournisseur se comportera, pas comment l’Internet dans son ensemble se comportera. Comparer deux outils qui utilisent des points de terminaison différents, c’est comparer des routes autant que des connexions.

La plus grande source d’erreur est généralement locale

Les différences de méthodologie retiennent l’attention, mais au quotidien les erreurs les plus importantes viennent de l’environnement :

• Le Wi-Fi au lieu de l’Ethernet. Le sans-fil ajoute de la latence, de la gigue et de la variabilité qui augmentent avec la distance, les murs et le nombre d’appareils partageant la bande. Sur un forfait rapide, un test filaire et un test sans fil dans la même pièce peuvent différer largement.
• Le trafic en arrière-plan. Une synchronisation cloud, une mise à jour système, un correctif de jeu ou le flux 4K de quelqu’un d’autre consomment de la capacité pendant la fenêtre de test.
• Les extensions de navigateur et les VPN. Les deux se trouvent sur le chemin et peuvent limiter ou rediriger le trafic du test.
• L’heure de la journée. Sur les connexions à média partagé, le même test exécuté à 10:00 et à 21:00 mesure deux réseaux différents.

Lire un chiffre avec son contexte

Un test de débit mesure un chemin, vers un serveur, à un instant donné, avec une méthode de transfert donnée. Il ne prouve pas que chaque site se chargera rapidement, qu’un serveur de jeu paraîtra réactif, que le réseau domestique est bien configuré, ni que la capacité tiendra aux heures de pointe. Considérez un résultat comme un instantané de diagnostic et la méthode comme une partie du résultat : un chiffre sans ses conditions n’est pas une mesure.

Autre distinction utile : le débit et la réactivité sont indépendants. Une ligne à très forte capacité avec 200 ms de latence vers le CDN le plus proche donne une sensation pire pour un usage interactif qu’une ligne modeste affichant 10 ms. Si la plainte est « ça paraît lent », le chiffre en Mbps est souvent le moins utile de l’écran.

Une routine de test reproductible

Normaliser les conditions compte davantage que le choix de l’outil.

1. Connectez-vous par Ethernet lorsque c’est possible. Si vous devez utiliser le Wi-Fi, restez dans la même pièce que le point d’accès et utilisez la bande 5 GHz ou 6 GHz.
2. Fermez tout ce qui déplace des données — sauvegardes, clients de synchronisation, mises à jour, flux — sur l’appareil de test comme sur tout ce qui partage la connexion.
3. Testez avec un profil de navigateur propre, sans extension et sans VPN.
4. Effectuez trois tests et retenez le résultat médian plutôt que le meilleur.
5. Notez l’heure de la journée et répétez à l’heure la plus chargée à laquelle vous utilisez normalement le réseau. La différence entre les deux est le chiffre qui prédit votre expérience réelle.
6. Si deux services ne sont pas d’accord, testez les deux vers le même serveur proche avant de conclure que la ligne est en cause.

Procédez ainsi une fois en milieu de matinée et une fois en soirée, et vous disposerez d’une image plus fidèle de votre connexion que n’importe quel chiffre isolé.