Netwatch : diagnostiquer un réseau en temps réel depuis le terminal

https://terminaltrove.com/netwatch/

https://github.com/matthart1983/netwatch

📌 Netwatch regroupe dans une seule interface terminal tout ce qui sert à comprendre pourquoi “ça rame” ou “ça drop” : interfaces actives, top connexions, DNS, bande passante et paquets, avec une lecture en temps réel pensée pour aller vite.

Quand un service devient lent, qu’un VPN se comporte bizarrement ou qu’un poste “parle” trop sur le réseau, la difficulté vient rarement d’un manque d’outils : c’est plutôt l’empilement. Un coup ping, puis traceroute, puis des commandes type lsof/netstat, ensuite un captureur de paquets, et au final des onglets et des commandes partout. Netwatch vise l’inverse : un tableau de bord unique, lisible en quelques secondes, pour identifier la piste la plus probable avant de plonger dans le détail.

L’écran d’ensemble met en avant les métriques qui comptent immédiatement : RX/TX live, interface, IP locale, état, et une liste des connexions “les plus parlantes” à l’instant T. L’idée n’est pas de remplacer les outils experts, mais d’éviter la phase d’échauffement où l’on passe dix minutes à reconstruire le contexte. En pratique, ça fonctionne bien pour les incidents intermittents : un pic de latence, une résolution DNS lente, une rafale de connexions sortantes, ou une saturation qui n’apparaît que sur une interface spécifique.

Au quotidien, l’onglet connexions sert à repérer les top talkers et à suivre l’état TCP sans effort. On peut trier, inspecter, puis basculer directement vers la vue paquets filtrée sur une connexion pour comprendre ce qui se passe réellement (handshake, retransmissions, flux applicatif). Ce couplage “connexion → paquets” est précieux pour passer du symptôme (latence) à une hypothèse exploitable (délais DNS, serveur qui répond en dents de scie, paquet perdu, port mal configuré) sans changer de contexte.

À mi-chemin entre le monitoring et l’analyse réseau, Netwatch propose aussi une vue topologie en ASCII : une carte simplifiée de la machine, de la passerelle, des serveurs DNS et des hôtes distants les plus présents, avec des indicateurs de santé et des compteurs de connexions. C’est une façon très directe de visualiser où se concentre l’activité, et de lancer un traceroute depuis n’importe quel hôte si un chemin paraît suspect. Pour les environnements domestiques, lab ou petites infra, cette représentation rapide aide à détecter un équipement qui devient central “sans raison” ou une dépendance réseau inattendue.

points clés

• 🧭 Tableau de bord temps réel : interfaces, IP, RX/TX et connexions dominantes
• 🔎 Diagnostic bout-en-bout : connexions, DNS, bande passante, paquets et décodage
• 🧱 Topologie ASCII : vue réseau lisible + traceroute intégré
• 🧊 Gestion d’incident : gel d’une fenêtre, export de contexte et PCAP
• 🎛️ Filtres et réglages : filtres type Wireshark, thèmes, seuils, capture
• 🤖 Analyse assistée (optionnelle) : insights périodiques via LLM (local ou distant)

La partie paquets est celle qui fait gagner le plus de temps quand il faut prouver quelque chose : capture intégrée, export PCAP, décodage dans l’interface, et des filtres d’affichage proches des habitudes Wireshark (protocoles, IP source/destination, ports, combinaisons et négations). Le fait de pouvoir armer un “flight recorder”, geler une fenêtre d’incident et exporter un bundle contextualisé permet de documenter un problème sans devoir rerun la capture au bon moment. Dans la vraie vie, c’est souvent ce qui manque : un incident survient, on n’a pas les données, et tout redevient “normal” quand on lance les commandes.

Les statistiques complètent bien l’enquête : hiérarchie de protocoles, compteurs, volumes, distribution, et des indicateurs orientés TCP (jusqu’aux histogrammes de handshake). Ces éléments ne remplacent pas une analyse complète, mais ils aident à décider rapidement si l’on regarde un problème réseau (perte, retransmissions), un problème applicatif (temps de réponse), ou un problème de résolution/chemin. La timeline façon Gantt, qui montre quand chaque connexion a été active et dans quel état, donne une lecture très simple des “rafales” et des connexions qui restent pendantes trop longtemps.

Côté prise en main, l’expérience est conçue pour être pilotée au clavier : navigation par onglets, pause/reprise, rafraîchissement, recherche/filtrage, et un panneau de réglages intégré. Les réglages permettent d’adapter la capture (interface, mode de suivi, filtre BPF), l’affichage (thème, refresh), et des paramètres plus avancés comme GeoIP ou les seuils d’alerte. Le but est d’éviter le fichier de config à écrire avant de comprendre l’intérêt de l’outil.

Un point à connaître : Netwatch propose des “AI insights” facultatifs. Quand c’est activé, l’outil envoie périodiquement un snapshot synthétique (mix de protocoles, top talkers, requêtes DNS, états de connexion, probes de santé, alertes) à un modèle de langage et affiche une analyse en bullets dans l’interface. C’est opt-in et désactivé par défaut. L’intégration vise surtout à faire remonter des anomalies faciles à manquer quand on scrolle : beaconing, DNS inhabituel, dégradation progressive, régression de latence. La configuration s’oriente autour d’Ollama (local par défaut), avec la possibilité de pointer vers un hôte distant ou un endpoint cloud compatible, sans gestion de clés API dans l’outil.

Sur la confidentialité, la règle simple est la suivante : tout ce qui reste dans le TUI (captures, stats, exports PCAP) vit sur la machine tant qu’on n’exporte pas. En revanche, si les insights IA sont activés et dirigés vers un endpoint distant, un résumé du trafic observé peut sortir de la machine. Dans un contexte sensible, l’usage le plus cohérent est soit de laisser l’IA off, soit de la pointer vers un modèle local, et de réserver l’export d’incident à des cas où le partage est justifié.

Netwatch est particulièrement utile sur une machine locale (poste, serveur, VM) mais il se prête aussi aux diagnostics à distance via un shell : là où une interface graphique est impossible ou trop lourde, un TUI clair permet de conserver une lecture “tableau de bord” même en SSH. Concrètement, c’est un outil qui accélère le passage de “j’ai un ressenti” à “j’ai un signal” : quelle interface est en cause, quel hôte domine, quel état TCP est majoritaire, et à quel moment l’incident s’est produit.

À retenir : quand l’objectif est d’avoir un diagnostic réseau rapide et actionnable sans quitter le terminal, Netwatch apporte une vue unifiée et des chemins courts vers le détail, avec assez d’options pour aller loin quand l’incident l’exige.