Frugalité Unix : do more with less

Il y a un test que je fais mentalement quand je lis du code ou qu’une personne se présente : est-ce que j’y trouve un cat file.txt | grep pattern là où un grep pattern file.txt suffisait ?

Ce n’est pas une question d’optimisation. Le surcoût d’un process forké est dérisoire. C’est une question de culture : cat | grep trahit quelqu’un qui a appris les commandes comme des incantations, pas comme des briques composables. Et le principe derrière la version courte, c’est le fondement même d’Unix : do more with less, small is beautiful. Chaque brique fait une chose, la fait bien, prend du texte en entrée et produit du texte en sortie.

Cet article assemble ce que j’ai défendu en vingt-cinq ans de terminal : les deux commandes qui précèdent toutes les autres, une leçon de design venue des années 2000, un toolkit minimal mais auditable et l’endroit précis où la frugalité doit céder devant un outil plus gros.

apropos et man, avant tout le reste

Deux commandes à connaître avant tout : apropos et man.

Pas apt, pas systemctl, pas le framework de l’année. Quand on me demande la liste des commandes essentielles pour un opérateur Linux/BSD, je commence par là et les listes qu’on m’oppose qui commencent par ln tr sed locate env sont déjà très loin de couvrir le métier. La mémoire musculaire d’un admin système, ce n’est pas trois cents raccourcis d’IDE, c’est savoir retrouver la documentation de ce qu’on ne connaît pas encore.

Détail qui résume l’esprit : shutdown et reboot sont des liens symboliques vers systemctl. Ceux qui ont lu le man le savent, ceux qui n’ont pas lu croient connaître deux commandes. Même chose pour apt : c’est très “debian-like specific”, il existe d’autres distributions et dans le cas Debian lui-même, apt-get, apt-cache et dpkg font partie de la partie.

Et le corollaire direct : absolument personne ayant lu les manpages et compris les permissions Unix ne fait un chmod 777 “pour que ça marche”. J’ai vu ça faire par des débutants et par des “devs” qui s’en fichaient royalement et ne comprenaient pas vraiment ce qu’ils faisaient. Le 777 n’est pas une erreur de syntaxe, c’est un symptôme de documentation non lue.

La leçon dsniff : des petits outils chaînables

Ma référence en design d’outillage vient des années 2000 : la suite dsniff. Des petits outils simples, scriptables, qui font chacun une chose mais bien, prennent du texte en entrée et produisent du texte en sortie. C’était très pratique pour chaîner les commandes et scripter des attaques ou des démonstrations.

À l’opposé, Ettercap : un outil monolithique, lourd, parfois instable, avec une interface GTK qui fait plus de mal que de bien et des soucis de distribution entre 2010 et 2013 avec des paquets compromis. Aujourd’hui je pointe Bettercap pour le MitM moderne (Ethernet, WiFi, BLE, interception HTTP/HTTPS, injection de paquets, modules), mais la leçon reste celle de dsniff.

Le reste de la panoplie suit la même logique : tu n’es pas obligé de quitter ton terminal pour analyser ton trafic. Capture avec tcpdump ou tshark, analyse offline avec NetworkMiner ou Zeek, sonde IDS/NDR avec Suricata et Arkime et pour l’infra du NetFlow. Chaque brique est exploitable seule, scriptable, chaînable. Le contraire de la frugalité n’est pas la richesse, c’est la monolithie.

Un toolkit minimal et sa limite honnête

Le toolkit frugal du quotidien, je le détaille dans l’ancêtre d’Ansible : un .env clé/valeur, un ~/.ssh/config bien tenu, SSH/SCP, du bash structuré et un moteur de template comme envsubst ou mo. Je ne le réénumère pas ici, ce qui compte c’est pourquoi ce choix tient.

Chaque composant est auditable, aucun magique et ça tourne partout où il y a un bash, un ksh ou un zsh. Les sessions vivent dans un fichier texte qu’on relit, qu’on templatise, qu’on distribue par dépôt. Pas de daemon, pas de base de données d’état, pas de licence.

Mais je dois la limite : c’est aussi exactement ce que fait Ansible, en ajoutant l’idempotence, la gestion d’erreurs, le parallélisme et des centaines de modules maintenus par la communauté. Réinventer tout ça en shell est éducatif, mais devient vite chronophage en production. Mieux vaut passer à Ansible (ou Salt, Puppet) et concentrer son énergie sur l’infrastructure plutôt que sur l’outillage.

La règle frugale n’est pas “tout faire à la main”, c’est “savoir exactement où s’arrête le fait-main” : sur une machine, pour un besoin simple, le shell bat tout. Sur cent machines avec de l’état et de la concurrence, le fait-main devient sa propre dette technique.

L’éditeur : déclaratif et reproductible

Pour tous ces langages : vim ou neovim , c’est suffisant.

Mon setup est déclaratif et reproductible : la config vit dans un dépôt (.vim ou .config/nvim par projet), les greffons sont gérés par vim-plug ou par un petit gestionnaire maison basé sur les git submodules et un poste neuf est opérationnel en moins de trois minutes. Pas de marketplace, pas d’extensions qui phonent à la maison, pas de .vscode qui squatte chaque dépôt avec des recommandations divergentes.

Précision nécessaire : ne pas embaucher quelqu’un parce qu’il utilise VS Code ou VSCodium, c’est de la pure stupidité. Le test de la frugalité n’est pas l’outil qu’on brandit, c’est ce qu’on sait faire sans lui.

Kali : apprendre la sécurité, pas l’administration

Dernier point et il tient en une phrase : Kali is good for learning security, not Linux administration.

Kali est un excellent point d’entrée pour l’apprentissage, les CTF et les certifications type OSCP, zéro débat. Mais présenter Kali comme “essentiel pour les professionnels IT” confond deux métiers : l’exploitation et l’exploitation… pardon, la sécurité offensive et l’administration système. L’opérateur qui a appris Linux sur Kali connaît une distribution dont le noyau est patché, les services tournent en root par défaut et l’éthique du pen-test prime sur l’hygiène d’exploitation. Pour apprendre à administrer, prenez une distribution standard et lisez les man.

Résumé

cat | grep n’est pas une erreur de performance, c’est un marqueur culturel. La version courte est la leçon : composabilité, une brique, une tâche.
apropos et man avant toutes les autres commandes. Le chmod 777 trahit les manpages non lues, pas un manque de talent.
La suite dsniff reste la référence de design : petits outils, texte en entrée et sortie, chaînables. Le contraire de la frugalité, c’est la monolithie (Ettercap), pas la richesse.
Le toolkit .env + .ssh/config + bash + envsubst est auditable et partout ; la limite honnête est Ansible : ne réinventez pas l’idempotence en shell en production.
L’éditeur doit être déclaratif et reproductible, pas universel. Et ne jugez personne sur son éditeur.
Kali apprend la sécurité offensive, pas l’administration. Pour administrer : distribution standard et man.