Les outils CLI que j’utilise tous les jours en dev web

Je passe l’essentiel de ma journée dans un terminal. Pas par posture geek : parce que la ligne de commande reste l’endroit le plus rapide pour chercher, filtrer et manipuler du code et des données. Mais les outils Unix historiques (grep, find, cat) datent d’une époque où on n’avait ni .gitignore, ni node_modules à 400 Mo, ni sortie couleur. Voici la sélection que j’ai réellement dans mon $PATH sur toutes mes machines, avec pourquoi je les garde et comment je m’en sers.

Avant de commencer : tous ces outils sont des binaires uniques, sans dépendance runtime. Un brew install ou un paquet apt suffit. Aucun ne demande de config obligatoire — ils sont utiles dès la première commande, et se configurent ensuite si l’envie vient.

Le socle : chercher et filtrer

ripgrep (rg) — la recherche que grep aurait dû être

C’est le premier outil que j’installe sur une machine neuve, avant même mon éditeur. rg recherche récursivement une regex en respectant automatiquement le .gitignore, saute les fichiers binaires, et sort en couleur. Il est écrit en Rust par Andrew Gallant, et c’est le backend de recherche par défaut de VS Code — autant dire qu’il est éprouvé.

# Chercher un appel de fonction dans tout le projet, sans polluer avec node_modules
rg "wp_enqueue_script" --type php

# Lister les fichiers qui matchent, avec le numéro de ligne
rg -l "TODO" src/

# Regex avec capture et remplacement à l'écran (dry-run)
rg "version: (d+.d+)" --replace 'v$1'

La vraie bascule, c’est la vitesse combinée au respect du gitignore. Sur un monorepo, grep -r passe des secondes à scanner vendor/ et node_modules/ ; rg les ignore par défaut et répond avant que j’aie lâché la touche Entrée. Le dépôt officiel de ripgrep détaille tous les filtres de types.

Si je ne devais garder qu’un seul de ces outils, ce serait ripgrep. Les autres améliorent le confort ; celui-là change ma vitesse de compréhension d’un codebase inconnu.

fd — trouver un fichier sans réciter la syntaxe de find

find est puissant mais sa syntaxe est punitive. fd, écrit par David Peter (sharkdp), fait le cas courant simplement : nom convivial, sortie couleur, respect du gitignore, et une vitesse qui rend l’attente négligeable.

# Trouver tous les fichiers SCSS
fd -e scss

# Trouver et supprimer les .DS_Store baladeurs
fd -H '^.DS_Store$' -X rm

# Chercher un dossier précis et l'ouvrir
fd -t d migrations

fzf — le fuzzy finder qui se branche partout

fzf, de Junegunn Choi, est un filtre flou interactif. Seul il est déjà utile, mais sa vraie force est de se composer avec les autres via des pipes. Je l’utilise pour naviguer dans l’historique, choisir une branche git, ouvrir un fichier.

# Ouvrir dans $EDITOR un fichier choisi au fuzzy
vim "$(fzf)"

# Changer de branche git de façon interactive
git checkout "$(git branch | fzf | tr -d ' *')"

# Combiné avec fd et bat en prévisualisation
fd -t f | fzf --preview 'bat --color=always {}'

Lire et comprendre

bat — cat avec coloration et numéros de ligne

bat (encore sharkdp) remplace cat pour la lecture humaine : coloration syntaxique, numéros de ligne, intégration git dans la marge. Pour du scripting je garde cat, mais pour lire un fichier de config, bat gagne à tous les coups.

bat wp-config.php
bat -r 40:80 functions.php   # seulement les lignes 40 à 80

eza — un ls qui respecte 2026

L’ancien exa n’est plus maintenu ; la communauté a repris le flambeau avec eza, activement développé. Icônes, couleurs par type, arborescence, colonne git : c’est mon ls par défaut, aliasé sans hésiter.

eza -la --git --icons
eza --tree --level=2 src/

jq — le couteau suisse du JSON

Dès qu’une API entre en jeu, jq devient indispensable. Le projet a changé de gouvernance il y a quelques années et vit désormais sous l’organisation jqlang, ce qui a relancé les releases. Je m’en sers pour inspecter des réponses REST WordPress, extraire un champ, reformater.

# Extraire les titres d'articles depuis l'API REST WP
curl -s https://exemple.com/wp-json/wp/v2/posts | jq '.[].title.rendered'

# Filtrer et reformater
cat data.json | jq '.items[] | {id, name}'

Automatiser

gh — GitHub sans quitter le terminal

La CLI officielle gh (dépôt cli/cli) me fait gagner un temps fou sur les tâches GitHub répétitives : ouvrir une PR, checker un run CI, cloner. Plus besoin d’aller-retour navigateur.

gh pr create --fill
gh run watch
gh repo clone monorg/monprojet
  1. Je crée la branche et je commit normalement.
  2. gh pr create --fill ouvre la PR avec titre et corps depuis les commits.
  3. gh run watch me montre le CI en direct, sans changer de fenêtre.

Le tableau de correspondance

Pour visualiser d’un coup ce que chaque outil remplace :

Outil moderneRemplaceGain principal
ripgrep (rg)grep -rRespect du gitignore + vitesse
fdfindSyntaxe humaine
fzf(rien d’équivalent)Filtre flou composable
batcatColoration + numéros de ligne
ezalsCouleurs, git, arborescence
jq(traitement JSON manuel)Requêtes JSON déclaratives
ghnavigateur GitHubWorkflow PR/CI en local
Ce socle prend tout son sens sur un serveur que je gère moi-même. Quand j’administre une VM en SSH — par exemple une stack sous CloudPanel en auto-hébergementrg et fd me font gagner un temps précieux pour fouiller des logs ou repérer un fichier suspect lors d’un durcissement de sécurité WordPress.

Comment je les installe d’un coup

  • macOS : brew install ripgrep fd fzf bat eza jq gh
  • Debian/Ubuntu : les paquets existent (attention, fd s’appelle fd-find et bat parfois batcat — un alias règle ça).
  • Le réflexe : je scripte cette ligne dans mon dotfiles pour qu’une machine neuve soit opérationnelle en une commande.

Ce que j’en retiens

Aucun de ces outils n’est révolutionnaire pris isolément. Ce qui l’est, c’est l’effet cumulé : chercher devient instantané, lire devient confortable, et la friction disparaît là où elle grignotait mon attention plusieurs fois par heure. Mon conseil si vous partez de zéro : commencez par ripgrep et fzf. Ce sont les deux qui changent le plus vite votre rapport au terminal. Les autres suivront naturellement, un alias à la fois. Et surtout, gardez les outils Unix classiques sous le coude pour vos scripts : le but n’est pas de tout remplacer dogmatiquement, mais d’avoir le bon outil au bon moment.