thongor77/nmlinuxBoîte à outils réseau unifiée pour Linux — Python 3 + PySide6
Une boîte à outils réseau unifiée pour Linux et macOS — inspecter, connecter, diagnostiquer.
NMLinux est une interface graphique unique et unifiée qui rassemble 29 modules réseau dans une seule fenêtre : surveillance des interfaces, Wi-Fi, DNS, terminal SSH, visualiseur de pare-feu, carte de topologie, traceroute, et plus encore. Développé de zéro en Python et PySide6 (Qt 6), avec 8 langues d'interface et aucune dépendance externe au-delà des outils système standards.
[!NOTE] NMLinux n'a aucun lien avec le démon système Linux
/usr/bin/NetworkManager(NetworkManager de Red Hat/GNOME). NMLinux est un projet autonome développé de zéro en Python et PySide6.
Développé avec Claude Code (Anthropic) et la contribution de son auteur.
NMLinux est développé avec l'assistance de l'IA — Claude Code, précisément — et cela n'est caché nulle part dans ce dépôt. Quasiment tous les projets logiciels sérieux aujourd'hui utilisent l'IA quelque part dans leur chaîne de production, qu'ils le disent ou non. Donc « l'IA a-t-elle été impliquée » n'est pas la question intéressante. La question intéressante est : y a-t-il quelque chose qui détecte quand l'IA se trompe ?
Voici ce qui le fait, si vous préférez vérifier plutôt que me croire sur parole :
pytest tests/ -v. De la logique pure plus une poignée de vrais tests de widgets Qt (menus, tableaux), sans masquer les parties intéressantes par du mocking.docs/Decisions-Techniques.md — chaque décision technique non évidente, les alternatives rejetées, et les bugs (y compris ceux introduits par l'IA) qui ont été trouvés et corrigés, avec le raisonnement consigné.docs/Architecture.md et docs/Carte-des-Modules.md — la structure réelle du code, maintenue en phase avec ce qui est livré.Rien de tout cela n'existe parce que l'IA ne peut pas être digne de confiance. Cela existe parce que rien ne devrait être livré sans un processus qui le vérifie — le code écrit à la main inclus. Jugez le résultat et la façon dont il est vérifié, pas l'outil qui a aidé à l'écrire.
Vous avez quand même trouvé un bug ? C'est utile, pas embarrassant — ouvrez une issue.
Les GitHub Discussions sont ouvertes — partagez vos retours, proposez des idées, posez des questions, ou dites simplement bonjour. L'auteur a plus de 30 ans d'expérience en infrastructure et en opérations, et a créé cet outil parce qu'un logiciel bon, gratuit et simple devrait aussi exister pour Linux.
Captures d'écran Linux de la v1.2.7 — captures d'écran macOS de la v1.3.5. L'application compte désormais 29 modules et 8 langues d'interface (FR/EN/ES/DE/IT/PT/JA/ZH).
Linux (KDE)
| Tableau de bord | Topologie |
|---|---|
 |  |
| Traceroute | Wi-Fi |
|---|---|
 |  |
macOS
| Tableau de bord | Traceroute |
|---|---|
 |  |
libpython3.14.so.1.0, compilé contre la glibc 2.44 de la machine de développement Arch Linux) exigeait encore des symboles glibc plus récents que ceux disponibles sur la machine de test du catalogue AppImageHub (Ubuntu 22.04, glibc 2.35), si bien que l'AppImage continuait de planter dès le lancement. build-appimage.sh construit désormais le bundle PyInstaller à l'intérieur d'un conteneur ubuntu:22.04 (via podman) plutôt que sur l'hôte, afin que chaque binaire embarqué soit lié exactement à la version de glibc que l'AppImage doit prendre en charge.build-appimage.sh embarquait des bibliothèques partagées (libz.so.1, libstdc++.so.6, libX11.so.6, libfontconfig.so.1, et d'autres) directement depuis la glibc très récente de la machine de compilation Arch Linux. Sur les distributions plus anciennes, l'AppImage plantait immédiatement au lancement (GLIBC_ABI_DT_RELR' not found), détecté par le test automatisé du catalogue AppImageHub. Ces bibliothèques sont désormais retirées du bundle afin que l'AppImage se rabatte sur les copies du système hôte, ce qui est l'approche standard pour les AppImages.