Le retour du “Hacker”
On a passé quelques années à empiler des features dans des IDE “tout-en-un”. Et puis… le terminal revient au centre du jeu. Pas par nostalgie, mais parce que c’est là que vivent les logs, Git, les serveurs, et toute la plomberie qui fait tourner la prod.
La bonne nouvelle : il existe maintenant des outils vraiment pensés pour travailler depuis la CLI (sans juste coller un chat à côté d’un shell). La mauvaise : le marketing autour est un terrain miné pour les hallucinations. Donc ici, on reste sur du vérifiable.
1. Claude Code (Anthropic) : L’autonome
Claude Code est un agent “dans le repo” : vous lui donnez une tâche, il lit/édite les fichiers, et peut proposer/exécuter des commandes (avec confirmations et garde-fous). C’est un produit officiel d’Anthropic, documenté et maintenu.
- Forces :
- Boucle de travail complète : lire → modifier → lancer des tests/outils → itérer, tant que vous validez ce qui doit l’être.
- Contexte “repo-first” : il est conçu pour naviguer dans votre codebase (plutôt que répondre au coup-par-coup).
- Faiblesses :
- Vous devez le cadrer : sans règles (format, conventions, limites), il peut partir dans des refactors trop ambitieux.
- On n’est pas en pilote automatique : l’intérêt, c’est l’itération rapide — pas de “tout exécuter sans regarder”.
Quand ça brille : “refactorise ce module, mets à jour les tests, et explique-moi ce que tu as changé”.
2. GitHub Copilot CLI (gh copilot) : Le copilote
GitHub Copilot CLI s’intègre à gh (GitHub CLI). Son angle est plus “assistant de commandes” que “agent autonome” : générer une commande, l’expliquer, proposer des variantes, etc.
- Forces :
- Très bon sur le “shell glue” : une commande un peu tordue, un pipeline, une option rare… et hop.
- Explications utiles : l’approche “explain” existe officiellement et colle bien à l’apprentissage du terminal.
- Zéro surprise d’exécution : par design, vous gardez le contrôle (il propose, vous exécutez).
- Faiblesses :
- Pas un agent de codebase : il ne remplace pas un outil qui lit/édite votre projet et enchaîne des actions.
Quand ça brille : “écris-moi la commande pour X” + “explique-moi ce que ça fait avant que je la lance”.
3. Gemini CLI (gemini) : le “chat” en terminal, open source
Gemini CLI est un projet open source publié par Google (sur GitHub). Il apporte Gemini directement dans votre terminal et met l’accent sur l’intégration avec votre workflow (fichiers, commandes, etc.) — avec une doc d’installation claire.
- Forces :
- Projet public : on peut lire le README, voir les options, comprendre comment ça marche, suivre les releases.
- Pratique pour explorer : idées de commandes, explications, itérations rapides sans quitter la CLI.
- Faiblesses :
- Ça ne remplace pas un agent spécialisé “repo-first” par magie : selon vos besoins, vous préférerez un outil centré sur l’édition multi-fichiers et les tests.
Quand ça brille : “aide-moi à diagnostiquer ce log / cette stacktrace” et “propose une commande sûre pour vérifier X”.
Ce que ça change pour les devs
-
On gagne en débit sur les tâches répétitives (scripts, commandes, diagnostics) — mais seulement si on garde des garde-fous (validation, dry-run, diffs, tests).
-
Le “bon” outil dépend du type d’aide :
- Vous voulez un assistant de terminal (commandes + explications) → Copilot CLI est très cohérent.
- Vous voulez un agent de codebase (refactor + tests + itérations) → Claude Code est taillé pour ça.
- Vous voulez un outil CLI open source autour de Gemini → Gemini CLI est le point d’entrée le plus clair.
Conclusion : “guerre” ? plutôt triage
Il n’y a pas (encore) un CLI qui écrase tout le reste. En pratique, on finit souvent avec un duo :
- un agent repo-first pour les changements multi-fichiers,
- un assistant de shell pour les commandes et le debugging.
Bref : testez, mais n’achetez pas une promesse. Achetez un workflow où chaque action est vérifiable.
Sources:
