Traceroute PowerShell est né le jour où je me suis demandé pourquoi tracert.exe passait autant de temps… à attendre.
Une seconde entre les requêtes ICMP.
Encore. Et encore. Et encore.
Alors j’ai recréé le fonctionnement de ping.exe et tracert.exe directement en PowerShell et en .NET.
Et le résultat était assez inattendu :
le traceroute devenait brutalement plus rapide… simplement en supprimant cette attente artificielle.
Comme quoi, certaines habitudes techniques survivent parfois beaucoup plus longtemps que les contraintes qui les ont fait naître.
Pourquoi recréer Ping et Tracert en PowerShell ?
Le but du projet n’était pas de remplacer les outils Microsoft officiels.
L’idée était surtout de comprendre ce qu’ils font réellement derrière le rideau :
- comment les requêtes ICMP sont envoyées,
- comment le TTL est manipulé,
- comment les réponses sont interprétées,
- et surtout quelles parties du comportement historique sont encore réellement utiles aujourd’hui.
Le projet repose entièrement sur PowerShell et les classes .NET natives.
Autrement dit :
- aucun appel à
ping.exe, - aucun parsing de texte fragile,
- aucun exécutable externe,
- uniquement des objets PowerShell exploitables proprement.
Et honnêtement, c’est aussi un excellent exercice pour rappeler que PowerShell est capable de bien plus que lancer trois cmdlets d’administration dans une console grise.
Traceroute PowerShell et Test-Ping : la base du projet
Avant même de reconstruire tracert.exe, il fallait d’abord recréer ping.exe.
C’est là qu’intervient Test-Ping.
Le script gère :
- les requêtes ICMP,
- les temps de réponse,
- les statistiques,
- les timeouts,
- les interruptions propres,
- et l’affichage des résultats.
L’objectif était simple :
obtenir un comportement proche de ping.exe, mais avec une sortie PowerShell native et structurée.
Pas du texte bricolé à parser derrière avec une regex douteuse écrite à 2h du matin.
Gérer CTRL+C proprement
Un des petits détails intéressants du projet concerne l’interruption du processus.
Par défaut, beaucoup de scripts PowerShell interrompus au CTRL+C perdent leur état ou retournent une sortie incomplète.
Le projet intercepte proprement l’événement afin de conserver les données déjà récupérées :
If ([console]::KeyAvailable) {
$key = [system.console]::readkey($true)
If (($key.modifiers -band [consolemodifiers]"control") -and ($key.key -eq "C")) {
Write-Verbose -Message "Control-C"
break
}
}Petit détail amusant :
cela ne fonctionne pas correctement dans PowerShell ISE.
Mais en 2026, utiliser ISE pour faire du troubleshooting réseau commence doucement à relever de l’archéologie numérique.
Trace-Route : manipuler directement le TTL
Une fois Test-Ping terminé, la suite logique était évidente :
recréer tracert.exe.
Le principe d’un traceroute reste relativement simple :
- envoyer un paquet ICMP,
- augmenter progressivement le TTL,
- récupérer les réponses des équipements intermédiaires,
- reconstruire le chemin réseau hop par hop.
Le projet Trace-Route repose exactement sur cette logique.
Et c’est là qu’un comportement intéressant est apparu pendant les tests.
Pourquoi ce Traceroute PowerShell est plus rapide que tracert.exe ?
En comparant les résultats avec tracert.exe, un détail sautait immédiatement aux yeux :
la version PowerShell terminait souvent plus rapidement.
Au début, je pensais avoir raté quelque chose.
Puis j’ai réalisé que le problème venait surtout d’une vieille habitude historique :
l’attente artificielle entre les requêtes ICMP.
Dans mon implémentation, rien n’imposait cette pause
Les paquets partaient immédiatement les uns après les autres.
Et surprise :
- le réseau ne s’effondrait pas,
- les équipements répondaient normalement,
- les résultats restaient cohérents,
- et le traceroute devenait nettement plus réactif.
Comme quoi, certaines limitations historiques ressemblent parfois davantage à des reliques d’époque modem 56k qu’à de véritables contraintes techniques modernes.
Réduire aussi les ralentissements DNS
Un autre point améliore les performances :
la résolution DNS.
tracert.exe tente régulièrement de résoudre les noms des équipements intermédiaires.
Selon l’infrastructure réseau, cela peut ralentir énormément l’exécution.
Le projet PowerShell reste beaucoup plus direct et évite une partie de ces résolutions inutiles.
Résultat :
le chemin réseau apparaît souvent beaucoup plus rapidement.
Le formatage PowerShell personnalisé
Le projet contient également un fichier format.ps1xml.
C’est une fonctionnalité PowerShell souvent oubliée, alors qu’elle est extrêmement puissante.
Elle permet de contrôler précisément :
- l’affichage des objets,
- l’alignement des propriétés,
- le rendu des collections,
- et la lisibilité globale des cmdlets.
Ce mécanisme permet d’obtenir une sortie propre directement dans la console sans multiplier les Format-Table dans tous les sens.
PowerShell est bien plus qu’un shell
Ce projet rappelle surtout une chose importante :
PowerShell n’est pas simplement un interpréteur de commandes destiné à automatiser quelques tâches système.
C’est une véritable plateforme capable de :
- manipuler le réseau,
- interagir directement avec .NET,
- exploiter les APIs système,
- produire des objets structurés,
- et construire de vrais outils d’ingénierie.
Quand on commence à utiliser PowerShell de cette manière, la frontière entre scripting et développement devient beaucoup plus floue.
Et honnêtement, c’est probablement là qu’il devient le plus intéressant.
Code source GitHub
Le projet complet est disponible ici :
J’ai mis tout ça sur mon repo Git… C’est cadeau !
Test-PingTrace-Route- le formatage PowerShell personnalisé,
- les démonstrations,
- et quelques expérimentations réseau réalisées principalement par curiosité technique… et probablement avec un peu trop de café.
