Mes agents IA utilisaient grep et cat — des outils de 1994 — alors que leurs remplaçants avaient 50 000 étoiles sur GitHub. Ce constat, découvert lors d'un audit systématique de ma pile CLI, m'a conduit à repenser intégralement l'équipement de mes 43 agents.
L'article précédent de cette série portait sur l'apprentissage des agents : comment encoder les bonnes pratiques dans une mémoire vectorielle accessible à tout moment. Mais les meilleurs comportements ne servent à rien si les agents travaillent avec de mauvais outils. Un chirurgien expert avec un couteau de cuisine reste limité.
Voici donc la méthode complète : comment j'ai audité 23 outils CLI modernes, croisé les résultats avec mes agents existants, et découvert 48 synergies qui économisent jusqu'à 98 % de tokens sur certaines opérations. Et comment j'ai rendu ce savoir permanent via 26 skills RAG.
Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.
L'audit multi-sources — trouver ce qui manque
La situation de départ
En février 2026, ma pile d'outils CLI se résumait à l'essentiel fonctionnel : bun, gh, git, docker, node, python3, curl. Suffisant pour faire tourner les agents. Insuffisant pour qu'ils travaillent efficacement.
Le problème ne sautait pas aux yeux immédiatement. Les agents fonctionnaient. Les résultats étaient corrects. Mais à l'analyse des logs de tokens, un signal répété apparaissait : trop d'appels Read sur des fichiers JSON et YAML pour en extraire une seule valeur. Un agent qui lit package.json en entier (800 tokens) pour récupérer la liste des scripts commet une inefficacité structurelle — pas un bug, mais un gaspillage systémique.
La méthodologie
Point de départ : le dépôt ibraheemdev/modern-unix sur GitHub, qui recense les alternatives modernes à chaque commande UNIX classique. Croisement avec quatre sources supplémentaires publiées en 2025-2026 : HARIL, Qodo, HostZealot et Medium.
Au total : 173 entrées de benchmarks pour 23 outils, 87 features documentées, et un cross-référencement systématique avec les 43 agents et ~80 skills existants.
Le résultat en chiffres :
| Métrique | Avant l'audit | Après adoption | Delta |
|---|---|---|---|
| Outils CLI installés | 6 | 17 | +11 |
| Synergies documentées | 18 | 48 | +30 |
| Agents avec CLI tips | 0 | 27 | +27 |
| Commandes legacy dans RAG | 5 | 0 | -5 |
Ce n'est pas une simple liste d'outils. C'est une démarche systématique : auditer ce qui manque, mesurer l'impact réel sur les tokens, identifier les combinaisons qui démultiplient les gains.
Tier 1 — les 6 outils indispensables
Ces six outils ont un impact immédiat sur le quotidien des agents. Leur adoption se mesure en heures, pas en jours.
| Outil | Remplace | Gain principal | Stars GitHub |
|---|---|---|---|
| jq | Lecture JSON manuelle | Parser JSON en CLI, piping structuré | 31k+ |
| ripgrep (rg) | grep | 5 à 10x plus rapide, respecte .gitignore | 50k+ |
| fd | find | 50 % plus rapide, syntaxe intuitive | 35k+ |
| bat | cat | Coloration syntaxique, numéros de ligne, diff Git | 51k+ |
| fzf | Recherche manuelle | Fuzzy finder universel, composable avec tout | 68k+ |
| lazygit | Commandes git | TUI interactive : staging partiel, rebase visuel | 55k+ |
Installation en une commande sous Windows :
winget install jqlang.jq BurntSushi.ripgrep sharkdp.fd sharkdp.bat junegunn.fzf JesseDuffield.lazygit
jq — le couteau suisse du JSON
L'impact est immédiat et chiffrable. Lire package.json via l'outil Read de Claude Code consomme environ 800 tokens — le fichier entier est chargé en contexte. Avec jq, extraire uniquement les scripts en demande 40 :
# Avant : Read package.json → ~800 tokens, tout le fichier en contexte jq '.scripts' package.json # ~40 tokens, résultat identique
Une économie de 95 % sur chaque lecture JSON. Multipliée par le nombre d'agents qui lisent des fichiers de configuration, c'est une réduction massive de la consommation cumulée.
ripgrep (rg) — grep multiplié par dix
À 50 000 étoiles GitHub, ripgrep est devenu le standard de facto pour la recherche dans les codebases. Il est 5 à 10 fois plus rapide que grep sur les projets réels, respecte automatiquement .gitignore (ce qui évite de crawler node_modules), et sa syntaxe reste quasi identique à grep — adoption immédiate.
Pour les agents qui effectuent des audits de code, la différence est sensible : moins de temps d'exécution, moins de résultats parasites, et une intégration naturelle dans les pipelines de traitement.
fzf — le compositeur universel
Fzf n'est pas un outil de recherche comme les autres : c'est un interface interactive qui se greffe sur n'importe quel flux de données. Son principe : tout ce qui sort en stdout peut devenir sélectionnable de manière fuzzy.
git branch | fzf # Choisir une branche interactivement
fd -e ts | fzf --preview "bat {}" # Explorer les fichiers TypeScript avec aperçu
À 68 000 étoiles GitHub, c'est l'outil le plus étoilé du Tier 1 — et celui dont l'usage s'étend bien au-delà de ce qu'on anticipe initialement.
Note importante : lazygit est une TUI (Terminal User Interface) interactive. Elle est conçue pour l'humain, pas pour l'agent en mode automatisé. Ne pas confondre les outils "humains" (lazygit, zoxide, bat en alias) avec les outils "agents" (jq, rg, fd) qui s'intègrent dans des scripts.
Tier 2 — les 6 outils de productivité
Ces six outils complètent la pile avec des gains plus ciblés selon les contextes.
| Outil | Remplace | Gain principal | Stars GitHub |
|---|---|---|---|
| zoxide | cd | Navigation intelligente par fréquence | 24k+ |
| eza | ls | ls moderne avec couleurs, icônes, arborescence | 14k+ |
| delta | git diff | Diff avec coloration syntaxique, side-by-side | 25k+ |
| tldr | man | Pages man simplifiées avec exemples pratiques | 53k+ |
| yq | Parsing YAML manuel | jq pour YAML/TOML/XML : docker-compose, CI | 13k+ |
| httpie | curl | Client HTTP lisible, coloration JSON auto | 34k+ |
yq — le jq du monde YAML
Si jq traite le JSON, yq traite le YAML, le TOML et le XML. C'est-à-dire : tous les fichiers de configuration qui ne sont pas JSON. Docker Compose, workflows GitHub Actions, frontmatter des fichiers Markdown d'agents — tout passe par yq.
L'exemple le plus frappant : l'audit batch de mes 43 agents. Avant, extraire le modèle utilisé par chaque agent nécessitait 43 appels Read, soit environ 12 000 tokens. Après :
# 43 appels Read → ~12 000 tokens
fd -e md agents/ -x yq -f extract '.model' {} # ~200 tokens (-98%)
98 % d'économie sur une seule opération. Sur une session d'audit complète, la différence est considérable.
La distinction fondamentale à retenir :
- Outils pour l'humain : zoxide (navigation), lazygit (TUI git), tldr (documentation), bat (visualisation) — ils améliorent le confort de travail mais ne s'intègrent pas dans des pipelines automatisés.
- Outils pour les agents : jq, rg, fd, yq — scriptables, composables, intégrables dans des workflows Claude Code.
La vraie révélation — les synergies
Chaque outil seul est bon. Ensemble, ils sont exponentiels.
La métrique la plus significative de cet audit n'est pas le nombre d'outils adoptés — c'est le nombre de synergies découvertes : 18 avant l'audit, 48 après, dont 7 classées "very-high impact". Ce sont ces combinaisons qui transforment réellement le comportement des agents.
Tableau des économies de tokens
| Pattern | Avant | Après | Saving |
|---|---|---|---|
| Read package.json | ~800 tokens | ~40 tokens (jq) | -95 % |
| Read agent.md × 43 | ~12 000 tokens | ~200 tokens (yq batch) | -98 % |
| Read settings.json | ~2 000 tokens | ~100 tokens (jq filter) | -95 % |
| Read docker-compose.yml | ~500 tokens | ~50 tokens (yq) | -90 % |
| grep -r dans agents | ~300/appel | ~100 (rg) | -67 % |
Les trois synergies les plus puissantes
S1 — jq remplace Read pour JSON
La synergie la plus simple et la plus immédiatement rentable. Au lieu de charger un fichier JSON entier en contexte, on extrait chirurgicalement la clé nécessaire :
# Avant : Read package.json → ~800 tokens, tout le fichier chargé jq '.scripts' package.json # ~40 tokens, résultat identique
Applicable à tous les fichiers de configuration JSON : package.json, settings.json, tsconfig.json, launch.json. Le retour sur investissement est immédiat.
S2 — yq + fd pour l'audit batch d'agents
La synergie la plus impactante en volume. Un audit de 43 agents nécessite de lire le frontmatter YAML de chaque fichier. Avec des appels Read individuels, c'est une opération de 12 000 tokens. Avec fd pour lister les fichiers et yq pour extraire le frontmatter :
# 43 appels Read → ~12 000 tokens
fd -e md agents/ -x yq -f extract '.model' {} # ~200 tokens
C'est 98 % de réduction. Non pas sur un exemple théorique — sur une opération que j'effectue régulièrement pour maintenir les agents.
S3 — Triple search (fd + rg + grepai)
La synergie la plus puissante conceptuellement. Trois dimensions de recherche complémentaires :
- fd pour la recherche structurelle : noms de fichiers, extensions, arborescences
- rg pour la recherche textuelle : contenu exact, expressions régulières dans les fichiers
- grepai pour la recherche sémantique : sens et intention, sans connaître les termes exacts
rg -l "authenticate" src/ # Recherche exacte : fichiers contenant "authenticate" grepai search "login flow" # Recherche sémantique : même résultat sans connaître le terme
Combinés, ces trois outils couvrent 100 % des cas de recherche dans une base de code. Un agent qui maîtrise les trois ne rate aucune information.
La synergie de configuration universelle
# Passer de YAML vers JSON pour utiliser jq sur docker-compose yq -o json docker-compose.yml | jq '.services | keys'
Cette combinaison jq + yq couvre l'intégralité des formats de configuration courants. JSON d'un côté, YAML/TOML/XML de l'autre — deux outils suffisent pour tout lire, tout filtrer, tout modifier chirurgicalement.
De la synergie au skill RAG — rendre le savoir permanent
Découvrir une synergie lors d'un audit est une chose. S'assurer que les agents s'en souviennent à la session suivante en est une autre.
C'est le problème fondamental de l'apprentissage agent : sans mémoire persistante, chaque découverte se perd. La solution mise en place : encoder chaque synergie comme un "skill" dans la mémoire vectorielle pgvector, accessible via le protocole d'apprentissage Phase 2 (pre-action skill lookup).
Les 26 skills créés
7 synergies "very-high impact" :
- synergy-jq_claude_read_replacement — -90 % de tokens sur les lectures JSON
- synergy-yq_claude_read_replacement — -90 % de tokens sur les lectures YAML
- synergy-jq_yq_universal_config — Configuration universelle JSON + YAML
- synergy-yq_fd_rg_agent_batch_audit — Audit batch sans Read
- synergy-fd_rg_grepai_triple_search — Triple search structurel + textuel + sémantique
- synergy-rg_grepai_text_plus_semantic — Recherche hybride
- synergy-fd_rg_jq_pgvector_audit_pipeline — Pipeline d'audit complet vers pgvector
13 synergies "high impact" et 6 synergies "medium impact" couvrent des combinaisons plus ciblées : fd + fzf + bat, rg + delta, jq + pgvector, etc.
Le résultat : 78 associations agent↔skill
Chaque agent sait maintenant quel outil utiliser dans quel contexte — sans qu'on ait besoin de le lui rappeler explicitement. Lors de l'étape de pré-action skill lookup, l'agent interroge la base vectorielle et retrouve la synergie pertinente pour son opération en cours.
C'est le complément naturel de l'apprentissage des agents décrit dans l'article précédent de cette série. Les agents apprennent de leurs propres expériences via le protocole de capture de skills. Mais ils disposent maintenant également d'une base de connaissances pré-remplie sur les outils — un capital collectif plutôt qu'un apprentissage individuel.
Les enseignements de cette démarche
Auditer systématiquement, pas ponctuellement
La liste modern-unix croisée avec les agents existants est reproductible en deux à trois heures. Ce n'est pas un travail de fond réservé aux grosses infrastructures : c'est une revue trimestrielle qu'on peut planifier.
Le bénéfice ne vient pas de l'outil installé — il vient du croisement. Identifier quel agent bénéficierait de quel outil, et surtout quelles combinaisons génèrent des synergies : voilà la valeur réelle de l'audit.
Distinguer les outils humains des outils agents
C'est une confusion fréquente. lazygit est une TUI interactive : elle ne peut pas être pilotée par un agent en mode non-interactif. zoxide améliore la navigation manuelle mais n'a pas d'équivalent utile dans un pipeline automatisé. bat en alias cat est pratique pour l'humain, pas pour l'agent.
À l'inverse, jq, rg, fd, yq sont scriptables, composables, intégrables dans n'importe quel pipeline. Ce sont eux qu'il faut prioriser pour l'adoption agent.
Encapsuler immédiatement, ne pas faire confiance à la mémoire
Une synergie découverte en cours de session et non encapsulée en skill RAG est perdue à la prochaine session. C'est une perte réelle : le temps passé à la découvrir, et le token cost de la redécouverte future.
La règle que j'ai mise en place : toute synergie qui économise plus de 50 % de tokens doit devenir un skill dans les 10 minutes suivant sa découverte.
L'anomalie Bun
Un résultat contre-intuitif mérite d'être documenté : dans les benchmarks, Bun est plus lent que Node sur les scripts simples (273 ms vs 103 ms).
Ce n'est pas un défaut de Bun — c'est une question de contexte d'usage. Son avantage réel s'exprime sur les suites de tests (7,5× plus rapide que Jest) et l'installation de packages (15× plus rapide que npm). Sur les scripts CLI courts, Node reste plus rapide.
La leçon : toujours benchmarker avant d'adopter un outil sur la base de sa réputation générale. Les gains annoncés sont réels, mais contextuels.
Conclusion
Douze outils CLI adoptés. 48 synergies documentées. 26 skills RAG créés. 27 agents enrichis avec des recommandations d'outils contextuelles. C'est le bilan de cet audit — mais surtout d'une méthode.
La méthode : audit multi-sources → cross-référencement avec les agents existants → identification des synergies → encapsulation en mémoire permanente. Reproductible en quelques heures, applicable trimestriellement au fil de l'évolution de l'écosystème.
Ce n'est pas un travail ponctuel. L'écosystème CLI évolue : de nouveaux outils émergent, les agents gagnent en capacités, les patterns de travail changent. La bonne approche est un processus continu, pas une migration unique.
Questions pour aller plus loin : Quelle est votre pile d'outils CLI actuelle ? Avez-vous déjà croisé cette liste avec les outils que vos agents utilisent réellement ? Quelles synergies avez-vous découvertes ?
Si vous n'avez pas encore lu l'article sur l'apprentissage des agents — comment encoder les bonnes pratiques en mémoire vectorielle accessible — c'est le complément naturel de cette démarche.
Qui suis je ?
Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.
J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.
Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.
L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.
La technologie, les méthodes, le management sont le cœur de mes compétences.
Vous pouvez me faire confiance sur ces points là.
Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr
Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100% IA.
Les outils CLI qui ont transformé mes agents IA : audit, adoption et synergies