Tutoriel Claude Code 3 : Pourquoi seulement le terminal ?

1.3 Pourquoi coder dans le terminal ?

Imaginons : vous êtes en train d'écrire une nouvelle fonctionnalité quand vous découvrez que vous devez modifier une fonction utilitaire de base éparpillée dans trois fichiers, avec des appels qui traversent des modules. Vous ouvrez votre éditeur, faites une recherche globale, parcourez un fichier après l'autre, modifiez prudemment, puis exécutez les tests — échec. Vous lisez l'erreur, examinez la pile, corrigez, et recommencez.

Dans ce processus, le temps réellement passé à « penser à comment modifier » représente moins de la moitié. Le reste est un travail mécanique : trouver les fichiers, modifier les références, attendre la compilation, cliquer.

Mettre l'IA dans le terminal a pour objectif principal de compresser ce travail mécanique.

Le terminal est l'endroit le plus proche du code

Vous utilisez peut-être VS Code, JetBrains ou Vim. Quel que soit votre choix, dans le processus de codage, vous ne pouvez pas éviter le terminal. Exécuter npm test, git log, grep, make build — ces opérations se font naturellement en ligne de commande.

Alors, si votre partenaire IA se trouve aussi dans le même terminal, les choses deviennent plus simples. Vous n'avez pas besoin de copier-coller le contenu des fichiers dans une fenêtre de chat, ni de décrire vous-même « il y a une classe appelée UserService dans mon projet, à la ligne 42 de src/services/user.ts... ». Claude Code se trouve à la racine du projet et peut voir par lui-même.

C'est une réduction dimensionnelle du contexte. Lorsque vous dites à Claude Code « aide-moi à refactoriser la gestion des erreurs du module de connexion », il va effectivement lire votre auth/login.ts, lire errors.ts, trouver tous les endroits qui l'appellent, puis les modifier directement. Vous n'avez pas besoin de servir de transporteur intermédiaire.

Vous libérer du rôle d'« opérateur »

Quand vous utilisez une IA de chat dans un navigateur, vous jouez souvent involontairement le rôle d'« intermédiaire » : l'IA produit du code, vous lisez, vérifiez, copiez, puis collez dans l'éditeur. Si le code fonctionne, tant mieux ; sinon, copiez l'erreur, demandez à nouveau, copiez encore. Ce processus interrompt fréquemment le flux de travail.

La conception de Claude Code vous permet de revenir à une position de « penseur ». Vous dites l'idée, il agit. Après les modifications, vous voyez directement le diff dans le terminal et décidez d'accepter ou non. Il peut également exécuter des tests et lint à votre place. Vous êtes là, la plupart du temps à lire du code et à prendre des décisions, plutôt qu'à basculer constamment entre les fenêtres.

Pourquoi pas un plugin d'éditeur ?

Vous pourriez demander : pourquoi ne pas simplement créer un plugin IA dans l'éditeur ?

Les plugins d'éditeur sont bien sûr utiles, et de nombreuses équipes les utilisent déjà. Mais Claude Code dans le terminal a plusieurs avantages difficiles à remplacer par un plugin :

1. Aucune dépendance à un éditeur. Vous utilisez VS Code aujourd'hui, Neovim demain, ou même un serveur distant sans interface graphique, Claude Code fonctionne partout. Il est indépendant de l'outil que vous choisissez.
2. Peut faire des choses « hors normes ». Dans le terminal, il peut exécuter n'importe quelle commande Shell. Cela signifie qu'il a un champ d'action beaucoup plus large — il peut lancer un conteneur Docker pour vérifier une migration de base de données, récupérer une branche distante et vérifier les conflits, ou exécuter automatiquement des tests e2e après une modification. Ces tâches, un plugin d'éditeur hésite généralement à les faire, ou ne peut tout simplement pas les faire.
3. Traitement par lots et automatisation. Vous pouvez intégrer Claude Code dans un script pour qu'il traite des dizaines de dépôts, génère de la documentation en masse, ou traite automatiquement des Issues. À ce stade, il n'est plus un « assistant », mais un maillon d'une chaîne de production.

Un petit exemple personnel

J'avais besoin de migrer un projet JavaScript vers TypeScript, environ 20 000 lignes de code. Mon approche n'a pas été d'ajouter manuellement des types fichier par fichier, ni de compter sur un plugin d'éditeur pour tout faire à ma place.

J'ai simplement lancé Claude Code dans le répertoire du projet et lui ai dit : « Migre progressivement ce projet vers le mode strict de TypeScript, modifie quelques fichiers à la fois, exécute tsc --noEmit après chaque lot, et si des erreurs apparaissent, corrige-les toi-même jusqu'à ce que tout passe. »

Pendant la demi-heure suivante, je n'ai pratiquement fait qu'une chose : regarder les diffs qu'il produisait, approuver ou refuser. Parfois je lui disais « ici, n'utilise pas any, définis une interface », et il continuait. Finalement, le projet compilait, et le temps nécessaire a été plusieurs fois inférieur à mon estimation initiale.

Cela ne signifie pas que Claude Code est plus intelligent qu'un plugin. Mais il peut accomplir la boucle « modification-vérification-correction » par lui-même, ce qui constitue la différence fondamentale avec une IA conversationnelle.

En fin de compte, le terminal donne des mains à l'IA

Loger l'IA dans le terminal revient à lui donner la capacité d'agir, et non seulement de conseiller.

Cela transforme votre dépôt de code, qui n'était qu'un ensemble de textes à lire, en un environnement réel que l'IA peut « toucher », modifier et vérifier. C'est un pas de géant.

Vous gardez toujours le contrôle de la direction du projet et de toutes les décisions clés, mais le travail fastidieux, peu créatif et nécessitant des allers-retours a désormais un meilleur exécutant.