Vérifier la destination avant de fixer un seuil
Dans un jeu rapide, un aller-retour faible et stable jusqu’au serveur du jeu est généralement préférable. Ces fourchettes sont des repères éditoriaux de comparaison, sans norme officielle ni garantie pour un jeu précis.
| Aller-retour affiché | Lecture indicative |
|---|---|
| Moins de 50 ms | Un objectif de faible délai pour les interactions rapides. |
| 50–100 ms | Peut être jouable ; vérifiez le jeu et la stabilité. |
| 100–150 ms | Le décalage peut devenir plus perceptible dans un jeu rapide. |
| Plus de 150 ms | Réactivité souvent moindre, sans prouver une panne. |
N’utilisez pas ce tableau comme exigence universelle pour les appels ou la vidéo. Les appels dépendent aussi des variations, pertes et tampons ; la vidéo préchargée dépend largement du débit et de la stabilité. Un test de navigateur ne certifie pas l’expérience.
Ping, latence et stabilité
La commande ping classique utilise l’écho ICMP. Le RTT inclut l’aller et le retour. Le diviser par deux ne détermine pas fiablement le délai à sens unique : chemins et files peuvent différer. Les Mbps mesurent une capacité, différente du délai en ms.
Les variations sont souvent appelées gigue ; la perte de paquets est une autre mesure. Notez destination et méthode : les outils peuvent calculer des statistiques différentes.
Ce que mesure IPdidi
Le test de ping effectue 2 requêtes de préparation puis 40 mesures HTTP vers /ping.txt sur le point Cloudflare qui dessert le site. Il n’envoie pas d’ICMP et ne mesure pas le serveur du jeu.
Il utilise normalement l’intervalle de requestStart à responseStart, qui peut inclure le traitement du serveur. À défaut, il chronomètre fetch, lecture de la réponse comprise. Ce n’est pas une garantie de RTT réseau pur.
La gigue affichée est la moyenne des écarts absolus entre échantillons voisins réussis. Un délai dépassé ou un échec HTTP est un échantillon raté, pas un taux de perte de paquets IP. Les notes d’usage sont des heuristiques du site. L’explication vient de l’examen du code, pas d’un essai de votre connexion ou appareil.
Comparer à conditions égales
- Notez cible, outil, heure, Wi-Fi ou câble, VPN, moyenne, variations et échecs.
- Répétez au repos puis pendant un transfert ordinaire, sans changer de cible ni de méthode.
- Comparez Ethernet et Wi-Fi si possible. Cela aide à isoler le sans-fil, sans garantir un meilleur chiffre.
- Consultez les diagnostics du jeu ou de l’application d’appel. Un bon résultat vers un point n’exclut pas un problème local, de route, de serveur ou d’application ailleurs.
Pour comparer l’ICMP, lancez ping example.com dans un terminal et arrêtez avec Ctrl+C si nécessaire. Une cible peut filtrer l’écho ; l’absence de réponse ne prouve pas l’arrêt du service.
Changer un seul élément puis mesurer
- Suspendez transferts et sauvegardes pour observer les files sous charge.
- En Wi-Fi, comparez emplacement et bandes ou canaux moins occupés ; le 5 GHz n’est pas toujours préférable à travers des murs ou à distance.
- Comparez une région adaptée du jeu et le VPN activé/désactivé sur la même activité. Ni VPN ni abonnement plus rapide ne garantissent une meilleure latence.
- Si le routeur gère les files, suivez sa documentation officielle. Cela peut réduire l’attente, sans supprimer la distance de propagation.
- Si le problème persiste, fournissez au support les cibles, horaires et résultats au repos et sous charge, pas seulement le minimum.
Gardez le même test avant et après. Ne concluez pas à partir de la seule différence entre deux destinations.
Questions courantes
100 ms est-il toujours mauvais ?
Cela dépend de l’activité, de la cible, du protocole et de la stabilité. C’est une mesure à examiner, pas une note universelle.
Un échec HTTP équivaut-il à une perte de paquets ?
Non. Les causes sont multiples et ce test ne détermine pas le taux de perte réseau.
Pourquoi le jeu indique-t-il autre chose ?
Cible, trafic et traitement diffèrent. Comparez ses propres diagnostics plutôt que de soustraire des valeurs sans rapport.
Sources et portée
Ce guide décrit les mesures et une méthode de comparaison. Il ne prétend pas localiser votre panne ni avoir testé un appareil particulier.
Sources vérifiées: 2026-11-05.