Comment exécuter un Traceroute sur Windows, Mac et Linux

Un traceroute est un utilitaire de diagnostic réseau qui cartographie le chemin exact emprunté par les paquets IP depuis votre machine vers un hôte cible, en enregistrant chaque routeur intermédiaire (saut) et en mesurant le temps d’aller-retour (RTT) vers chacun d’eux. C’est l’outil le plus efficace pour déterminer si une augmentation de latence, une perte de paquets ou une anomalie de routage provient de votre réseau local, de l’infrastructure de votre FAI, d’un backbone de transit ou du serveur de destination lui-même.

Lorsque vous exécutez un traceroute, votre système envoie une série de paquets de sonde avec des valeurs TTL (Time To Live) croissantes. Chaque routeur qui décrémente le TTL à zéro renvoie un message ICMP « Time Exceeded », révélant son identité et son temps de réponse. Ce mécanisme est ce qui différencie fondamentalement le traceroute d’un simple `ping` — il expose la topologie de routage complète, pas seulement l’accessibilité de bout en bout.

Comment fonctionne le traceroute en coulisses

Comprendre les mécanismes sous-jacents évite les erreurs d’interprétation des résultats — une erreur que commettent même les administrateurs expérimentés.

• Windows (`tracert`) envoie des paquets ICMP Echo Request par défaut.
• Linux et macOS (`traceroute`) envoient des datagrammes UDP vers des ports à numéros élevés (33434+) par défaut, bien que cela soit configurable.
• Chaque sonde est envoyée trois fois par saut, produisant trois mesures RTT par ligne.
• Un routeur qui limite le débit ou supprime les paquets ICMP/UDP affichera des astérisques (`* * *`), mais cela ne signifie pas nécessairement que le chemin au-delà est interrompu.

Cette différence de comportement entre les systèmes d’exploitation est cruciale : un saut qui semble ne pas répondre sous Linux peut répondre normalement sous Windows, simplement parce que l’ACL du routeur bloque UDP mais autorise ICMP.

Comment exécuter un traceroute sous Windows

Étape 1 : Ouvrir l’invite de commandes

Appuyez sur `Win + R`, tapez `cmd` et appuyez sur Entrée. Vous pouvez également rechercher Invite de commandes dans le menu Démarrer. Pour les environnements où ICMP est restreint, envisagez d’exécuter en tant qu’administrateur.

Étape 2 : Exécuter la commande

“`

tracert example.com

“`

Remplacez `example.com` par le nom de domaine ou l’adresse IP cible. Windows résout le nom d’hôte en adresse IP avant d’envoyer la première sonde.

Étape 3 : Lire la sortie

“`

Tracing route to example.com [93.184.216.34] over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.0.1

2 10 ms 11 ms 10 ms 10.0.0.1

3 15 ms 16 ms 15 ms isp.gateway.net [203.0.113.1]

4 * * * Request timed out.

5 22 ms 21 ms 23 ms core1.backbone.net [198.51.100.5]

“`

Options `tracert` clés sous Windows

Exemple avec options :

“`

tracert -d -h 20 -w 2000 example.com

“`

Conseil pro : Sous Windows, `tracert -d` est le moyen le plus rapide d’obtenir des résultats lorsque vous ne vous intéressez qu’au routage au niveau IP et non aux noms d’hôtes. Les résolutions DNS inverses peuvent ajouter plusieurs secondes par saut sur les réseaux encombrés.

Comment exécuter un traceroute sous macOS

Étape 1 : Ouvrir le Terminal

Appuyez sur `Command + Space`, tapez Terminal et appuyez sur Entrée. Ou naviguez vers Applications > Utilitaires > Terminal.

Étape 2 : Exécuter la commande

“`

traceroute example.com

“`

macOS est livré avec `traceroute` préinstallé dans le cadre de sa boîte à outils réseau BSD. Aucune installation supplémentaire n’est requise.

Étape 3 : Lire la sortie

“`

traceroute to example.com (93.184.216.34), 64 hops max, 52 byte packets

1 192.168.0.1 (192.168.0.1) 1.206 ms 0.930 ms 0.799 ms

2 10.0.0.1 (10.0.0.1) 10.123 ms 10.456 ms 10.678 ms

3 isp.gateway.net (203.0.113.1) 15.789 ms 15.012 ms 15.234 ms

“`

Notez que macOS utilise par défaut 64 sauts maximum contre 30 pour Windows — ce qui est pertinent lors du traçage de chemins vers des destinations réseau géographiquement distantes ou complexes.

Options `traceroute` clés sous macOS

Exemple — mode ICMP pour contourner le filtrage UDP :

“`

sudo traceroute -I example.com

“`

Exemple — mode TCP SYN sur le port 80 (le plus compatible avec les pare-feux) :

“`

sudo traceroute -T -p 80 example.com

“`

Comment exécuter un traceroute sous Linux

Étape 1 : Ouvrir le Terminal

Appuyez sur `Ctrl + Alt + T` ou localisez le terminal dans votre lanceur d’applications.

Étape 2 : Installer `traceroute` si nécessaire

Sur de nombreuses distributions Linux minimales ou orientées serveur, `traceroute` n’est pas installé par défaut.

Debian / Ubuntu :

“`

sudo apt-get install traceroute

“`

CentOS / RHEL / AlmaLinux / Rocky Linux :

“`

sudo yum install traceroute

“`

Fedora :

“`

sudo dnf install traceroute

“`

Arch Linux :

“`

sudo pacman -S traceroute

“`

Étape 3 : Exécuter la commande

“`

traceroute example.com

“`

Étape 4 : Lire la sortie

“`

traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets

1 192.168.0.1 (192.168.0.1) 0.728 ms 0.457 ms 0.373 ms

2 10.0.0.1 (10.0.0.1) 9.862 ms 9.946 ms 10.123 ms

3 isp.gateway.net (203.0.113.1) 14.987 ms 14.123 ms 15.456 ms

“`

Options `traceroute` clés sous Linux

L’option `-A` est particulièrement puissante pour diagnostiquer les problèmes de routage inter-AS — elle indique quel FAI ou opérateur réseau possède chaque saut, vous permettant d’identifier précisément où un transfert entre opérateurs provoque de la latence.

“`

traceroute -A example.com

“`

`mtr` — L’alternative supérieure sous Linux

Pour les diagnostics continus ou interactifs, `mtr` (Matt’s Traceroute) combine `ping` et `traceroute` dans un affichage en actualisation continue. C’est l’outil privilégié par les ingénieurs réseau pour l’analyse de perte de paquets en temps réel.

“`

sudo apt-get install mtr

mtr example.com

“`

`mtr` accumule des statistiques au fil du temps, rendant visible la perte de paquets intermittente — quelque chose qu’un `traceroute` en passe unique manquera entièrement.

Comparaison multiplateforme : tracert vs. traceroute

Comprendre la sortie du traceroute : analyse technique

Numéro de saut

Chaque ligne représente un routeur dans le chemin. Le saut 1 est presque toujours votre passerelle par défaut (routeur domestique ou commutateur LAN). Le saut 2 est généralement le premier point d’agrégation de votre FAI.

Temps de réponse (RTT)

Trois valeurs RTT sont affichées par saut. Des valeurs saines suivent généralement un schéma d’augmentation progressive à mesure que les sauts accumulent une distance géographique. Une augmentation soudaine de 50+ ms à un saut spécifique qui persiste sur tous les sauts suivants indique un véritable goulot d’étranglement à ce nœud.

Interprétation de `* * *` (astérisques)

Les astérisques signifient que la sonde a expiré — le routeur n’a pas renvoyé de réponse ICMP dans la fenêtre d’attente. Ce n’est pas automatiquement un problème. De nombreux routeurs d’entreprise et nœuds de backbone déprioritisent ou suppriment silencieusement les paquets de sonde ICMP/UDP pour des raisons de sécurité tout en continuant à transférer le trafic normalement. Si les sauts après les astérisques affichent des RTT normaux, le chemin est intact.

Latence élevée sur un seul saut

Si le saut 7 affiche 200 ms mais que le saut 8 affiche 25 ms, la valeur de 200 ms est presque certainement due à une limitation de débit ICMP sur le routeur du saut 7 — et non à un véritable goulot d’étranglement. Le routeur traite la sonde en basse priorité tout en transférant le trafic réel à pleine vitesse. Évaluez toujours les tendances de latence sur l’ensemble du chemin, et non les sauts individuels de manière isolée.

Routage asymétrique

Le traceroute ne cartographie que le chemin aller. Les paquets de retour peuvent emprunter un itinéraire complètement différent. Cela signifie qu’une augmentation de latence que vous observez pourrait provenir du chemin retour, et non du chemin aller affiché. Des outils comme `traceroute` dans les deux sens (depuis la source et depuis la destination) sont nécessaires pour une visibilité complète.

Boucles de routage

Si la même adresse IP apparaît à plusieurs sauts consécutifs, une boucle de routage existe. Les paquets sont transférés indéfiniment entre deux routeurs jusqu’à l’expiration du TTL. Il s’agit d’une mauvaise configuration qui entraînera une panne de connectivité complète vers cette destination.

Scénarios courants de traceroute et leur signification

Scénario 1 : Latence élevée à partir du saut 2

Le premier point d’agrégation de votre FAI est congestionné. Cela échappe à votre contrôle. Documentez la sortie avec des horodatages et contactez votre FAI avec les preuves.

Scénario 2 : Tous les sauts après le saut 5 affichent `* * *` mais la destination répond au ping

Les routeurs en amont de la destination bloquent les sondes ICMP. Passez en mode TCP SYN (`-T -p 443`) pour tracer à travers les pare-feux.

Scénario 3 : Pics de latence à un saut situé dans un pays inattendu

Votre trafic est acheminé à l’international avant d’atteindre une destination locale — une anomalie de routage BGP. Cela est courant avec un anycast mal configuré ou des FAI mal interconnectés.

Scénario 4 : Le traceroute se termine mais le site web est toujours lent

Le goulot d’étranglement peut être côté serveur : CPU surchargé, réponse applicative lente ou latence de base de données. Le traceroute ne mesure que les performances au niveau réseau. Si vous hébergez sur un VPS et rencontrez ce problème, examinez l’utilisation des ressources serveur avec `top`, `htop` ou `vmstat`.

Scénario 5 : Le traceroute ne se termine jamais (s’arrête indéfiniment à un saut spécifique)

Un pare-feu supprime vos sondes et la destination est inaccessible. Confirmez avec `ping` vers la destination. Si le ping échoue également, l’hôte est hors ligne ou bloque tout ICMP. Si le ping réussit, seul le protocole de sonde est bloqué — changez de protocole.

Traceroute pour les diagnostics serveur et d’hébergement

Le traceroute est indispensable pour diagnostiquer les problèmes de connectivité entre votre infrastructure et les utilisateurs finaux ou entre les services. Si vous exécutez des applications sur un Serveur Dédié, un traceroute depuis plusieurs points d’observation géographiquement distribués révèle si la latence est localisée à une région ou un FAI spécifique.

Pour les environnements d’hébergement web gérés via un panneau de contrôle, tracer les routes vers l’IP de votre serveur depuis le côté client aide à distinguer un problème au niveau de l’hébergement d’un problème de transit réseau. Les administrateurs utilisant un VPS avec cPanel peuvent croiser les données de traceroute avec les journaux d’accès côté serveur pour obtenir une image complète d’une plainte de connectivité.

Lors du diagnostic d’échecs de livraison d’e-mails ou de délais d’expiration SMTP, exécuter un traceroute vers l’IP de votre serveur de messagerie est une première étape logique avant d’examiner les enregistrements SPF/DKIM. Si vous utilisez un service d’Hébergement Email dédié, cela permet de confirmer si le problème est au niveau réseau ou au niveau de la configuration.

Pour les charges de travail sensibles à la latence telles que l’inférence d’apprentissage automatique ou les pipelines de rendu s’exécutant sur un Hébergement GPU, le traceroute aide à vérifier que le chemin réseau entre votre client et le nœud GPU est optimalement routé sans sauts de transit inattendus.

Techniques avancées : traceroute en ligne et distribué

Les traceroutes depuis un seul point ne montrent que le chemin depuis votre machine. Pour une analyse réseau complète :

• Serveurs Looking Glass : De nombreux FAI et IXP exploitent des serveurs looking glass publics qui vous permettent d’exécuter des traceroutes depuis leur périphérie réseau, révélant le chemin du point de vue d’un opérateur.
• BGP.tools / RIPE Atlas : Plateformes de mesure distribuées qui exécutent des traceroutes depuis des centaines de points d’observation mondiaux simultanément, exposant les anomalies de routage régionales invisibles depuis un seul emplacement.
• PathPing (Windows) : Un outil Windows intégré qui combine `ping` et `tracert`, exécutant des sondes continues vers chaque saut et calculant des statistiques de perte de paquets. Exécutez avec : `pathping example.com`
• WinMTR : Un équivalent Windows graphique de `mtr`, fournissant des statistiques de perte de paquets et de latence par saut en temps réel.

Matrice de décision pratique : quel outil utiliser

Points techniques clés à retenir

• Utilisez toujours `-n` ou `-d` en premier pour éliminer les délais de résolution DNS et obtenir des résultats bruts plus rapidement.
• Un saut affichant `* * *` n’indique pas un chemin interrompu — évaluez les sauts qui le suivent.
• La latence sur un seul saut intermédiaire est fréquemment due à une limitation de débit ICMP, et non à un véritable goulot d’étranglement.
• Changez de protocole de sonde (ICMP, UDP, TCP SYN) lorsque vous rencontrez des délais d’expiration persistants — les pare-feux sont sélectifs selon le protocole.
• Utilisez `mtr` plutôt que `traceroute` pour toute session de diagnostic dépassant une vérification unique.
• Le traceroute ne révèle que le chemin aller. Le routage asymétrique nécessite une analyse bidirectionnelle.
• L’option `-A` du traceroute Linux ajoute l’annotation des numéros AS, essentielle pour l’analyse du routage multi-FAI.
• Documentez les sorties de traceroute avec des horodatages lors du dépôt de tickets de support FAI — les opérateurs exigent ces données pour enquêter sur les problèmes au niveau BGP.

Foire aux questions

Pourquoi le traceroute affiche-t-il `* * *` pour certains sauts alors que la destination est toujours accessible ?

Les routeurs sur le chemin sont configurés pour supprimer ou limiter le débit des messages ICMP TTL-exceeded tout en continuant à transférer le trafic normalement. Il s’agit d’une politique délibérée de sécurité et de performance sur la plupart des routeurs d’entreprise et de niveau opérateur. Cela n’indique pas de perte de paquets sur le chemin de données.

Quelle est la différence entre `tracert` sous Windows et `traceroute` sous Linux ?

La différence principale réside dans le protocole de sonde par défaut : `tracert` utilise des ICMP Echo Requests, tandis que `traceroute` sous Linux/macOS utilise des datagrammes UDP. Cela signifie qu’ils interagissent différemment avec les pare-feux et les ACL. Le `traceroute` sous Linux prend également en charge les sondes TCP SYN et les recherches de numéros AS, ce que `tracert` ne fait pas.

Comment exécuter un traceroute à travers un pare-feu qui bloque UDP et ICMP ?

Utilisez le mode TCP SYN avec un port presque certainement ouvert sur la cible, tel que le port 80 ou 443 : `sudo traceroute -T -p 443 example.com`. Les sondes TCP SYN passent à travers la plupart des pare-feux à état car elles ressemblent au début d’une connexion légitime.

Que signifie une augmentation soudaine de la latence du traceroute qui reste élevée pour tous les sauts restants ?

Une augmentation persistante de la latence à partir d’un saut spécifique indique un véritable goulot d’étranglement ou un lien congestionné à ce point du chemin. Cela se distingue d’un pic sur un seul saut (qui est généralement une limitation de débit). L’augmentation soutenue signifie que tout le trafic est retardé à ce nœud ou sur le lien immédiatement après.

Le traceroute peut-il diagnostiquer des performances lentes d’un site web ?

Le traceroute ne diagnostique que la latence au niveau réseau et les problèmes de routage. Si le chemin réseau semble correct mais que le site web est toujours lent, le problème est côté serveur — temps de traitement applicatif, latence des requêtes de base de données ou épuisement des ressources. Utilisez des outils de surveillance serveur en complément du traceroute pour un diagnostic complet.