Traceroute ou ping : ce que chacun révèle, avec exemples

Ping et traceroute envoient tous deux des paquets et chronomètrent les réponses, mais ils ne répondent pas à la même question. Ping vous dit si un hôte répond et combien de temps prend un aller-retour. Traceroute vous dit quels routeurs se trouvent entre vous et cet hôte, et à quel endroit du trajet le temps s'accumule. Ci-dessous, les deux outils visent le même hôte depuis le même serveur, à une minute d'intervalle, puis un tableau vous aide à choisir lequel lancer en premier.

La différence en un tableau

	Ping	Traceroute
Question à laquelle il répond	L'hôte répond-il, et en combien de temps ?	Quels routeurs sont sur le chemin, et où le retard s'accumule-t-il ?
Ce qu'il envoie	ICMP Echo Request	Des paquets au TTL croissant : UDP sous Linux et macOS, ICMP sous Windows (tracert)
Qui répond	La destination seulement	Chaque routeur du trajet (ICMP Time Exceeded), puis la destination
Sortie	Un temps par paquet, puis la perte et min/avg/max	Une ligne par saut, trois temps par ligne
Durée	Jusqu'à ce que vous l'arrêtiez sous Linux et macOS, 4 paquets sous Windows	De quelques secondes à une minute
Angle mort	Ne dit pas d'où vient un retard	Un seul instantané ; des sauts intermédiaires peuvent paraître lents ou sujets à des pertes alors qu'ils ne le sont pas

Ping : un seul chiffre, bien mesuré

Depuis notre serveur de Falkenstein, en Allemagne, vers un hôte de test Vultr dans le New Jersey, le 7 octobre 2026 à 12:27 UTC :

$ ping -c 10 nj-us-ping.vultr.com
PING nj-us-ping.vultr.com (108.61.149.182) 56(84) bytes of data.
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=1 ttl=50 time=86.1 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=2 ttl=50 time=86.1 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=3 ttl=50 time=86.4 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=4 ttl=50 time=86.2 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=5 ttl=50 time=86.3 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=6 ttl=50 time=86.1 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=7 ttl=50 time=86.3 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=8 ttl=50 time=86.2 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=9 ttl=50 time=86.1 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=10 ttl=50 time=86.2 ms

--- nj-us-ping.vultr.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9410ms
rtt min/avg/max/mdev = 86.113/86.212/86.360/0.081 ms

• time= est l'aller-retour de chaque paquet : environ 86 ms pour l'aller et le retour.
• 0 % de perte de paquets et un mdev de 0,081 ms (la dispersion des temps) : le chemin est stable. Sur un chemin sain à l'intérieur d'un continent, le mdev reste souvent sous 1 ms ; des valeurs de plusieurs dizaines de millisecondes trahissent de la congestion ou du Wi-Fi.
• ttl=50 est ce qui restait de la durée de vie (TTL) de la réponse à son arrivée. Si l'hôte est parti de 64, la valeur par défaut habituelle sous Linux, la réponse a traversé 14 routeurs au retour, trois de plus que les 11 sauts que traceroute compte à l'aller (voir plus bas). Le retour emprunte souvent une autre route, et aucun outil lancé de votre côté ne peut la montrer.

Ce que ping ne peut pas dire, c'est pourquoi il faut 86 ms. C'est le rôle de traceroute.

Traceroute : d'où viennent les 86 ms

Le même hôte, depuis le même serveur, une minute plus tard, avec les sondes UDP par défaut :

$ traceroute nj-us-ping.vultr.com
traceroute to nj-us-ping.vultr.com (108.61.149.182), 30 hops max, 60 byte packets
 1  * * *
 2  ex9k1.dc11.fsn1.hetzner.com (213.133.117.208)  0.517 ms  0.318 ms  0.291 ms
 3  core23.fsn1.hetzner.com (213.133.126.23)  3.999 ms  3.920 ms  3.834 ms
 4  juniper4.dc2.nbg1.hetzner.com (213.239.252.233)  2.806 ms juniper5.dc2.nbg1.hetzner.com (213.239.252.245)  2.854 ms juniper5.dc2.nbg1.hetzner.com (213.239.254.218)  2.959 ms
 5  ae12-498.nbg40.core-backbone.com (5.56.20.253)  2.763 ms  2.687 ms  2.666 ms
 6  ae7-2093.nyk10.core-backbone.com (81.95.9.195)  86.557 ms  86.413 ms  86.437 ms
 7  * * *
 8  * * *
 9  * * *
10  66.55.138.149.vultrusercontent.com (66.55.138.149)  85.763 ms  85.862 ms  85.692 ms
11  * * *
12  * * *
[les mêmes * * * sur chaque ligne jusqu'à 30]
30  * * *

• Les 86 ms apparaissent d'un coup, au saut 6. Le saut 5 est nbg40, à Nuremberg, à 2,7 ms ; le saut 6 est nyk10, à New York, à 86,4 ms. Avant, c'est la traversée de l'Allemagne ; après, tout reste au même niveau : ce temps, c'est l'Atlantique. Ping n'aurait pas pu vous le dire.
• Les temps ne s'additionnent pas d'un saut à l'autre. Le saut 3 répond en 3,9 ms et le saut 4, plus loin, en 2,8 ms. Chaque ligne est un aller-retour distinct, traité par un routeur différent, qui prend son propre temps pour répondre.
• Une ligne muette n'est pas une coupure. Le saut 1 et les sauts 7 à 9 ne répondent jamais, mais le saut 10, si : ces routeurs ignorent simplement les sondes.
• La dernière ligne n'arrive jamais. Après le saut 10, rien que des astérisques jusqu'au saut 30, alors que ping montrait un hôte qui répondait parfaitement. Cet hôte ne répond pas aux sondes UDP. En ICMP, comme ping, le même tracé l'atteint :

$ traceroute -I -n -q 1 nj-us-ping.vultr.com
traceroute to nj-us-ping.vultr.com (108.61.149.182), 30 hops max, 60 byte packets
 1  *
 2  213.133.117.208  0.372 ms
 3  213.133.126.22  0.357 ms
 4  213.239.254.238  2.813 ms
 5  81.95.15.5  2.710 ms
 6  81.95.9.195  86.418 ms
 7  *
 8  *
 9  *
10  66.55.138.149  85.749 ms
11  108.61.149.182  85.975 ms

C'est l'erreur de lecture la plus courante d'un traceroute : un tracé qui se termine par des astérisques ne signifie pas que l'hôte est hors service. Vérifiez avec ping, puis relancez le tracé avec un autre protocole (-I pour ICMP, ou -T -p 443 pour TCP sous Linux, en root).

Lequel lancer en premier

Symptôme	Commencer par	Ensuite
« Le site est inaccessible »	Un ping de l'hôte, et d'un hôte qui fonctionne à coup sûr (1.1.1.1)	Si le ping échoue, un traceroute pour voir où ça s'arrête. Beaucoup d'hôtes bloquent le ping : testez le service lui-même (une vérification HTTP ou de port) avant de conclure
« C'est lent »	Un ping de 30 à 60 secondes : la moyenne et la dispersion	Traceroute ou mtr pour trouver le saut où le temps fait un bond et ne redescend plus
« Ça coupe de temps en temps »	Un long ping (ping -c 300) pour le taux de perte	mtr -c 100 pour voir à partir de quel saut la perte commence
« C'est mon réseau ou le leur ? »	Un traceroute depuis votre machine	Le même tracé depuis un autre endroit, puis comparer
Les gros transferts ou le VPN se bloquent, les petits échanges passent	Un ping avec un paquet de taille maximale, qui ne doit pas être fragmenté	Réduire la taille jusqu'à ce qu'il passe : c'est la MTU du chemin

Le test en taille maximale envoie 1 472 octets de données, qui, avec 28 octets d'en-têtes, font un paquet de 1 500 octets : ping -M do -s 1472 host sous Linux, ping -D -s 1472 host sous macOS, ping -f -l 1472 host sous Windows.

Les options qui changent la réponse

• ping -c 20 : s'arrête après 20 paquets (Windows : -n 20). -i 0.2 envoie un paquet toutes les 0,2 seconde au lieu d'un par seconde.
• ping -W : le délai d'attente de chaque réponse s'exprime en secondes sous Linux et en millisecondes sous macOS, un piège classique quand un script passe de l'un à l'autre.
• -4 ou -6 sous Linux et Windows : force IPv4 ou IPv6 (macOS a des commandes distinctes, ping6 et traceroute6). Un hôte peut être rapide sur l'un et lent sur l'autre.
• traceroute -n : pas de résolution DNS inverse, c'est bien plus rapide, mais vous perdez les noms des routeurs, souvent le meilleur indice pour situer un saut.

Les limites des deux outils

• Un seul sens. Les deux montrent le chemin depuis l'endroit où vous les lancez. Le chemin retour, dont l'indice du TTL plus haut montre qu'il est différent, reste invisible.
• Pour un routeur, répondre aux sondes passe en dernier. Un saut qui semble lent ou sujet à des pertes ne compte que si tous les sauts suivants, jusqu'à la destination, montrent la même chose. C'est expliqué avec des exemples réels dans comment repérer les goulots d'étranglement réseau.
• Un seul instant. Une mesure unique peut passer à côté d'un problème intermittent. mtr combine les deux outils et répète la mesure sur chaque saut.

Pour faire la même comparaison sans terminal, le ping de TraceMapper et son traceroute tournent depuis nos serveurs et depuis plus de 30 points de mesure, avec chaque saut placé sur une carte. Pour les commandes de chaque système, voir la commande traceroute sous Windows, Mac et Linux.