10 outils CLI que j'utilise au quotidien avec Claude Code

Trois moniteurs. Dix-sept onglets de terminal. Un cerveau complètement perdu.

C'était mon setup il y a six mois, quand je me suis plongé dans Claude Code pour la première fois. Je pensais que plus de fenêtres signifiait plus de productivité. iTerm2 étalé sur tout mon bureau. VS Code sur un écran. Un navigateur sur un autre. Et mon terminal — un bazar chaotique de commandes cat et de chemins de répertoires à moitié mémorisés — sur le troisième.

J'étais techniquement "productif." Mais honnêtement ? J'avais l'impression de construire un vaisseau spatial avec un couteau à beurre.

Le déclic n'est pas venu de l'apprentissage d'un nouveau langage de programmation ni de la découverte d'une fonctionnalité obscure de Claude Code. Il est venu de la mise en place d'un véritable environnement CLI — un ensemble d'outils de terminal qui ont transformé mon workflow, passant d'un changement frénétique de fenêtres à quelque chose de réellement fluide et intentionnel.

Voici ce que j'aurais aimé qu'on me dise plus tôt : Claude Code vit dans le terminal. Quand tu traites le terminal comme un environnement de premier plan et que tu t'équipes en conséquence, tout change. Les boucles de feedback se resserrent. Les changements de contexte disparaissent. Tu restes dans la zone plus longtemps.

Je teste et collecte ces outils depuis des mois. Certains, je les utilise tous les jours sans exception. Quelques-uns, je les ai essayés puis abandonnés — je te dirai lesquels et pourquoi, parce que c'est plus utile qu'une simple liste "best of" soigneusement sélectionnée. Et l'un d'entre eux, que je garde pour la section honnêteté, est devenu tellement essentiel que je ne peux plus imaginer une session agentique sans lui.

Pourquoi la plupart des utilisateurs de Claude Code naviguent à l'aveugle

Avant d'en venir aux outils, laisse-moi décrire le problème plus précisément — parce que je pense que beaucoup de développeurs essaient de résoudre entièrement le mauvais problème.

Quand tu exécutes Claude Code, tu gères une collaboration en direct entre ta réflexion et un agent IA qui écrit, modifie et réorganise activement des fichiers. Ça signifie que tu dois répondre à trois questions en temps réel, presque simultanément :

Que fait réellement Claude à ma base de code en ce moment ?
Où suis-je dans mon système de fichiers, et où dois-je aller ?
Comment mes ressources système tiennent-elles sous la charge ?

La plupart des développeurs répondent à ces questions en passant d'un onglet à l'autre, en lançant git status toutes les 30 secondes, et en croisant les doigts. C'est suffisant pour des sessions rapides. Mais quand tu exécutes des boucles agentiques plus longues — Claude qui refactorise un service, génère du contenu, échafaude des fonctionnalités entières — tu as besoin d'une meilleure instrumentation.

Les outils que je partage ici sont ceux qui répondent à ces trois questions sans casser ton flow. J'ai installé la plupart d'entre eux avec Homebrew sur mon Mac, et je te donnerai les commandes d'installation exactes tout au long de l'article. La plupart ont des équivalents Linux pour les configurations serveur headless.

Un aveu honnête d'emblée : je n'utilise pas les douze chaque jour dans chaque projet. Certains dépendent du contexte. Je préciserai lesquels sont mes outils quotidiens et lesquels sont situationnels — parce que je préfère te donner une boîte à outils sincère plutôt qu'une qui sonne impressionnante mais ne reflète pas comment le vrai travail se fait.

Mais avant d'en venir aux outils spécifiques, tu dois comprendre le modèle mental qui fait fonctionner cette stack. Sans lui, tu vas tout installer et ne rien utiliser.

La stack terminal à trois couches

Voici comment je conçois mon environnement CLI quand je travaille avec Claude Code. Chaque outil s'inscrit dans l'une de ces trois couches :

Couche 1 : Conscience — Savoir ce qui se passe avec ton code et ton système en temps réel. Couche 2 : Navigation — Aller là où tu dois être, vite, sans y réfléchir. Couche 3 : Intelligence — Comprendre tes outils IA, les options de modèles et les coûts de ressources.

La plupart des développeurs ne couvrent que la Couche 2 — ils connaissent cd et ls. Ceux qui gèrent des sessions Claude Code efficaces ont les trois couches câblées. Laisse-moi te détailler chaque couche et les outils qui la servent.

Couche 1 : Conscience — Savoir ce qui se passe réellement

Lazygit : L'outil sans lequel je ne peux pas ouvrir Claude Code

Ouvre Lazygit avant de démarrer n'importe quelle session Claude Code. Lance simplement lazygit dans le répertoire de ton projet et tu obtiens une interface terminal complète montrant l'état de ton dépôt, les modifications staged, l'historique des commits, les branches et les stashes — tout en une seule vue, tout se mettant à jour en temps réel.

Pourquoi c'est important spécifiquement pour Claude Code : quand tu exécutes une session agentique et que Claude fait des modifications, Lazygit devient ta fenêtre en direct sur ce qui se passe réellement. Tu peux voir les modifications de fichiers au moment où elles se produisent. Examiner les diffs sans quitter le terminal. Si Claude fait quelque chose d'inattendu — et ça arrivera, tôt ou tard — tu vois exactement ce qui a changé avant de décider si tu gardes ou si tu reviens en arrière.

brew install lazygit

La navigation est ultra simple : j/k pour monter et descendre, enter pour approfondir, space pour stager, c pour commiter. La courbe d'apprentissage, c'est vingt minutes, pas vingt jours.

Un truc que je n'avais pas anticipé : Lazygit m'a fait commiter plus fréquemment pendant les sessions Claude. Observer les changements s'accumuler en temps réel crée un rythme naturel. Je fais des points de sauvegarde plus souvent maintenant, ce qui rend le rollback moins effrayant — ce qui signifie que je laisse Claude être plus agressif avec les refactorisations. C'est un bénéfice composé qu'il m'a fallu du temps à remarquer.

Btop : Le monitoring système qui te dit vraiment ce qui ne va pas

Quand j'ai commencé à faire des sessions Claude Code plus longues, mon MacBook se mettait à ramer au bout d'environ 45 minutes. Je n'avais aucune idée pourquoi. C'étaient les appels API au LLM ? Des fuites mémoire de Node.js ? Trop de processus en arrière-plan se disputant la RAM ?

Btop a répondu à ça en environ 10 secondes.

brew install btop

Lance btop et tu obtiens un tableau de bord interactif dans le terminal montrant l'utilisation CPU par cœur, la consommation mémoire par processus, les I/O disque, et le trafic réseau — le tout en une seule vue. Appuie sur t pour basculer entre les différents panneaux d'affichage. Appuie sur e pour développer les détails des processus.

Pour les utilisateurs de Claude Code : garde Btop en marche dans un split de terminal pendant tes sessions d'agent. Tu apprendras vite à quoi ressemble une utilisation "normale" des ressources pour ta configuration, et tu attraperas les processus emballés avant qu'ils ne plantent ta session.

Astuce pro : c'est grâce à la vue mémoire de Btop que j'ai découvert qu'un package npm que j'utilisais fuyait de la mémoire de manière agressive pendant les tests lancés par Claude. Corrigé en 20 minutes une fois que je pouvais réellement voir ce qui se passait. Sans cette visibilité, j'aurais continué à accuser Claude.

Voici un workflow qui m'a fait honte pendant des années : cd ~/projects/clients/acme/backend/src/controllers. À chaque fois. En entier. Même après avoir visité ce répertoire 200 fois.

Zoxide corrige ça définitivement.

brew install zoxide

Ajoute ceci à ton ~/.zshrc :

eval "$(zoxide init zsh)"

Après l'installation, une fois que tu as visité un répertoire, tu peux y retourner avec juste un fragment : z controllers et Zoxide devine où tu veux aller en se basant sur ton historique de navigation. La commande zi te donne une recherche floue interactive de tout ton historique de déplacements.

Pour Claude Code : quand tu alternes entre plusieurs répertoires de projets pendant une session — vérifier la sortie d'un projet pendant que Claude génère des fichiers pour un autre — Zoxide réduit le temps de navigation de "plusieurs secondes de frappe" à une touche et un mot.

J'ai sous-estimé celui-ci quand je l'ai installé la première fois. Maintenant c'est de la pure mémoire musculaire. Le genre d'outil dont tu remarques immédiatement l'absence quand tu travailles sur une machine neuve.

Ranger : Un explorateur de fichiers qui vit dans ton terminal

Ranger te donne un explorateur de fichiers à trois panneaux dans ton terminal. Le panneau de gauche montre le répertoire parent, celui du centre montre le répertoire courant, et celui de droite montre un aperçu du fichier sélectionné. Navigue avec h/j/k/l (style Vim), ouvre les fichiers avec enter, prévisualise les fichiers texte sans lancer de commande séparée.

brew install ranger

Je l'utilise dans deux scénarios précis : quand j'explore une structure de projet que je ne connais pas bien (Ranger me donne une compréhension spatiale de la base de code qu'un simple ls ne fournit jamais), et quand Claude a généré un lot de nouveaux fichiers et que je veux rapidement passer en revue la structure et repérer tout ce qui semble déplacé.

Pour les environnements Linux ou headless spécifiquement, Ranger est pratiquement indispensable. Il remplace le gestionnaire de fichiers graphique vers lequel tu te tournerais normalement.

EZA : Ce que `ls` aurait dû être depuis le début

eza est un remplacement moderne de ls avec des icônes, des permissions colorées, un regroupement par répertoires, et une intégration du statut git intégrée nativement.

brew install eza

Puis ajoute ces alias à ton ~/.zshrc :

alias ls='eza --icons --group-directories-first'
alias ll='eza -l --icons --group-directories-first'
alias la='eza -la --icons --group-directories-first'
alias lt='eza --tree --icons --level=2'

La différence est immédiatement visible : des icônes par type de fichier, les répertoires regroupés en haut, et — c'est la partie que j'adore — si tu es dans un dépôt git, eza montre quels fichiers sont modifiés, staged ou non suivis directement dans la liste des fichiers. Plus besoin d'un git status séparé pour un coup d'œil rapide.

Une petite amélioration de qualité de vie. Mais tu te demanderas comment tu faisais sans au bout d'une semaine.

Couche 3 : Intelligence — Comprendre tes outils IA et tes ressources

C'est la couche que la plupart des développeurs sautent complètement, et c'est là que le vrai levier se trouve quand tu gères des workflows lourds en IA.

LLMFit : Savoir ce que ton matériel peut vraiment supporter

LLMFit est un outil CLI qui scanne ton matériel et te dit quels modèles IA locaux tu peux réalistement faire tourner — avec des scores de performance, des estimations de mémoire requise, et des comptages de paramètres. Plus besoin de deviner.

pip install llmfit

Lance llmfit scan et tu obtiens un tableau : nom du modèle, nombre de paramètres, mémoire requise, score de performance estimé sur ton matériel spécifique, et statut de compatibilité en fonction de ta RAM disponible actuelle.

Pourquoi c'est important : j'ai perdu deux heures une fois en essayant de faire tourner un modèle de 13 milliards de paramètres sur une machine qui avait techniquement assez de RAM totale mais pas assez de RAM libre après l'overhead système. Le modèle plantait sans arrêt pendant l'inférence. LLMFit l'aurait signalé immédiatement et suggéré une alternative à 7 milliards.

Pour les utilisateurs de Claude Code qui travaillent avec des modèles locaux via Ollama ou LM Studio en parallèle de l'API de Claude : lance LLMFit une fois quand tu configures une nouvelle machine ou que tu expérimentes avec des tailles de modèles. Ça t'évite des sessions de débogage inutiles.

Models CLI : Comparaison de fournisseurs IA sans onglet navigateur

Le CLI models te donne une comparaison en terminal des fournisseurs de modèles IA — tarification par token, tailles de fenêtre de contexte, benchmarks et changelogs — sans ouvrir de navigateur.

npm install -g models-cli

Le cas d'usage est spécifique mais précieux : quand tu décides quel modèle utiliser pour une tâche d'agent particulière, pouvoir afficher une comparaison rapide sans changer de contexte vers un onglet navigateur te garde dans le flow. Je l'utilise surtout pour l'analyse des coûts. Quand un workflow de génération de contenu à haut volume devient cher avec Claude Opus, je peux rapidement vérifier si un modèle plus petit est viable pour une sous-tâche particulière — directement depuis le terminal, en pleine session.

Taproom : Tes packages Homebrew installés, organisés

Taproom montre tous les packages et casks Homebrew installés sur ton Mac, organisés clairement et avec recherche.

brew install taproom

Lance taproom pour une liste propre de tes formulae et casks installés. Lance taproom | grep ranger pour vérifier si quelque chose est déjà installé. Je l'utilise plus que prévu — principalement quand je configure de nouvelles machines et quand je ne me souviens plus si j'ai déjà installé quelque chose. Ça m'a évité de faire des installations en double et m'a aidé à répliquer mon environnement rapidement en passant d'une machine à l'autre.

À ce stade, tu as le modèle mental complet et les neuf outils principaux. Mais c'est maintenant que ça devient vraiment utile — les trois derniers outils sont ceux auxquels la plupart des gens ne pensent pas à installer, et deux d'entre eux ont changé des parties spécifiques de mon workflow plus que tout le reste.

Le trio sous-estimé : Markdown, images et données

Glow : Lire la sortie Markdown de Claude comme elle était censée apparaître

Quand Claude génère de la documentation, des articles de blog ou des READMEs, je les lis avec Glow au lieu de cat. La différence est significative.

brew install glow

Lance glow tonfichier.md et Glow affiche un vrai rendu markdown — les titres ressemblent à des titres, les blocs de code ont un contexte syntaxique, le texte en gras est réellement en gras. Plus besoin de plisser les yeux sur des astérisques et des backticks bruts.

Pour les workflows de contenu spécifiquement, c'est indispensable. Quand je relis des articles de 3 000 mots avant publication, les lire dans Glow versus en markdown brut, c'est la différence entre repérer les problèmes de formatage et les louper complètement.

Neovim est l'option avancée, et je ne vais pas prétendre que la courbe d'apprentissage est douce — elle ne l'est pas. Mais si tu es à l'aise avec les raccourcis Vim, Neovim te donne des superpouvoirs de navigation pour les longs fichiers markdown : sauter entre les titres avec ]] et [[, replier les sections avec za, chercher dans le fichier avec /. Pour les documents longs que Claude génère, c'est plus rapide que n'importe quel éditeur graphique pour des modifications structurelles rapides.

brew install neovim

Avis honnête : si tu n'as jamais utilisé Vim avant, installe d'abord Glow, utilise-le quotidiennement pendant deux semaines, puis envisage Neovim. Ne laisse pas le côté cool te pousser vers un outil pour lequel tu n'es pas prêt. Glow suffira à la plupart des gens — et un simple nvim sans plugins gère très bien les modifications rapides.

Shua et CSV Lens : Outils visuels et de données pour le terminal

Shua affiche des images directement dans ton terminal. Plus niche, mais si tu travailles avec Claude sur des tâches liées aux images — examiner des captures d'écran, prévisualiser des ressources générées, vérifier une sortie visuelle — pouvoir prévisualiser des images sans quitter le CLI est un vrai confort. La compatibilité dépend de ton émulateur de terminal (fonctionne parfaitement dans iTerm2).

CSV Lens te donne une TUI interactive pour les fichiers CSV :

cargo install csvlens
# If you don't have Rust installed: brew install rust first

Navigue avec les touches fléchées, cherche avec /, quitte avec q. Si tu travailles avec des données dans tes sessions Claude Code — logs exportés, données structurées, fixtures de test — CSV Lens te permet de parcourir et filtrer sans ouvrir Excel ou Numbers. Étonnamment rapide même sur des CSV volumineux.

La section honnêteté : Ce que j'ai fait de travers

Voici ce que j'aurais aimé qu'on me dise avant de me lancer dans une frénésie d'outils.

Erreur n°1 : Tout installer d'un coup. Ma première tentative de construction d'une boîte à outils CLI a été un désastre. J'ai installé environ 20 outils en un après-midi, aliasé la moitié d'entre eux, puis j'ai continué à utiliser les trois mêmes outils que j'avais toujours utilisés. Les nouveaux outils étaient juste là, théoriquement disponibles, jamais réellement déclenchés par l'habitude.

Ce qui a corrigé ça : installer un nouvel outil par semaine. Spécifiquement, supprimer mon alias existant pour quelque chose et me forcer à utiliser le remplacement. ls est devenu eza pendant deux semaines avant que j'installe Zoxide. Immersion forcée. Ça marche.

Erreur n°2 : Suroptimiser Neovim. Neovim est réellement puissant. Je l'utilise. Mais j'ai cramé environ six heures à essayer de configurer le Neovim "parfait" avec des serveurs LSP, des plugins et un thème entièrement personnalisé — pour de l'édition de markdown. C'était excessif. Glow gère la lecture. Un simple nvim gère les modifications rapides. Tu n'as pas besoin de la configuration IDE complète sauf si tu utilises Neovim comme éditeur principal pour tout.

Idée reçue sur LLMFit : Quelques personnes que je connais ont supposé qu'il donne une garantie définitive de ce qu'un modèle fera sur leur matériel. C'est plutôt une estimation bien informée. L'utilisation mémoire varie selon la quantization, la longueur du contexte, et ce qui tourne en parallèle. Considère-le comme un point de départ, pas un contrat.

L'opinion impopulaire : tous les utilisateurs de Claude Code n'ont pas besoin de cette boîte à outils complète. Si tu fais des sessions légères — questions rapides, petites modifications — un terminal VS Code bien configuré suffit probablement. Cette stack est pour ceux qui font des sessions agentiques prolongées, gèrent des systèmes de contenu ou font de la manipulation intensive de fichiers à travers plusieurs projets. Connais ton workflow réel avant d'optimiser pour un que tu n'as pas.

Et l'outil que j'ai abandonné, celui que j'ai mentionné au début ? Mac Top. Un moniteur système spécifique à macOS qui, après deux semaines de test, s'est avéré moins complet et moins personnalisable que Btop pour mes besoins. Pas un mauvais outil — juste pas le bon choix pour ce dont j'avais besoin en matière de monitoring système pendant des sessions IA.

Ce qui a vraiment changé après 90 jours

Quatre-vingt-dix jours plus tard, voici ce que je peux honnêtement rapporter :

Les changements de contexte ont nettement diminué. Avant : basculer sur GitHub Desktop pour vérifier l'état du dépôt, passer sur Finder pour naviguer dans les fichiers, ouvrir un navigateur pour comparer les prix des modèles. Après : Lazygit, Ranger et Models CLI gèrent les trois sans quitter le terminal. Moins de changements de contexte signifie des fenêtres de concentration ininterrompue plus longues.

Je repère les erreurs de Claude plus vite. Lazygit dans un split de terminal me montre les diffs en temps réel. Quand Claude fait une modification non voulue — et ça arrive, surtout pendant les sessions longues — je le vois en quelques secondes, pas après la fin de toute la session. Détection précoce signifie rollbacks plus petits et moins de retravail.

La réplication d'environnement est passée de plusieurs heures à quelques minutes. Quand j'ai monté une nouvelle machine de dev le mois dernier, j'avais mon environnement CLI complet opérationnel en environ 25 minutes : bundle Homebrew, lignes de config shell, quelques installations manuelles. Sans cette boîte à outils délibérée et documentée, ça m'aurait pris une demi-journée de "attends, qu'est-ce que j'avais installé déjà ?"

Le workflow de contenu spécifiquement : pour le système de blog que je fais tourner sur mejba.me, Claude génère des fichiers markdown que je relis avec Glow, que je commite dans git via Lazygit, et que j'organise avec Ranger. Ce cycle — générer, relire, commiter, organiser — me prenait environ quatre minutes par article. Maintenant c'est moins de 90 secondes. Sur des dizaines d'articles par mois, ça se compose en heures économisées.

Les gains rapides apparaissent immédiatement après l'installation (Zoxide seul fait gagner de vraies minutes par jour). Les gains plus profonds — meilleure conscience situationnelle, débogage plus rapide, moins de charge cognitive — émergent au fil des semaines à mesure que ces outils deviennent automatiques.

Ta prochaine action

Choisis trois outils dans cette liste. Juste trois — pas les douze. Ce soir.

Spécifiquement : Lazygit, Zoxide et Glow. Installe ces trois-là et ils changeront la texture de ta prochaine session Claude Code de manière immédiatement perceptible. Utilise-les pendant deux semaines avant d'ajouter quoi que ce soit d'autre. Résiste à l'envie d'installer la stack complète. La profondeur d'adoption bat la largeur d'installation à chaque fois.

Les développeurs que je vois utiliser Claude Code le plus efficacement ne sont pas ceux qui ont le plus d'outils. Ce sont ceux qui ont rendu un petit ensemble d'outils complètement automatique — où Lazygit est de la mémoire musculaire, où Zoxide est simplement la façon dont la navigation fonctionne, où relire la sortie de Claude dans Glow est la chose évidente à faire.

Il y a six mois : chaos sur trois moniteurs, changement de fenêtres permanent, navigation à l'aveugle dans les modifications de fichiers. Maintenant : un split de terminal focalisé avec des outils qui correspondent réellement à ma façon de penser.

Quelle partie de ton workflow terminal actuel te fait un peu grimacer à chaque fois que tu la fais ? Commence par là.

Travaillons ensemble

Tu cherches à construire des systèmes IA, automatiser des workflows ou faire monter en charge ton infrastructure tech ? Ce serait un plaisir de t'aider.

Fiverr (builds personnalisés & intégrations) : fiverr.com/s/EgxYmWD
Portfolio : mejba.me
Ramlit Limited (solutions entreprise) : ramlit.com
ColorPark (design & branding) : colorpark.io
xCyberSecurity (services de sécurité) : xcybersecurity.io