Le terminal de Claude Code est-il plus puissant que l'app ?

Le moteur est le même, mais le terminal expose des fonctions que l'app cache ou n'a pas : sessions en parallèle avec les git worktrees, flags pour automatiser (--print, --output-format), mode headless pour l'intégrer à des scripts, et un contrôle bien plus fin des permissions et du contexte. L'app est parfaite pour réviser chaque changement ; le terminal, c'est pour quand tu travailles à grand volume ou que tu veux enchaîner Claude avec d'autres outils.

Faut-il bien connaître le terminal pour faire le saut ?

Le strict nécessaire. Il faut être à l'aise avec cd, ls, lancer des commandes et comprendre ce qu'est une branche git. Pas besoin d'être un expert en bash : 90 % du temps, tu écris en langage naturel exactement comme dans l'app. Ce qu'il y a de nouveau à apprendre, ce sont quatre commandes de Claude (les slash commands) et le concept de worktree.

Qu'est-ce que les sessions en parallèle et pourquoi comptent-elles autant ?

Ce sont plusieurs instances de Claude Code qui tournent en même temps, chacune dans sa propre copie du projet (un git worktree) et sur sa propre branche. Pendant que l'une refactorise, une autre écrit des tests et une autre documente, sans se gêner. C'est le flux qui transforme Claude Code d'assistant en équipe, et c'est quasi impossible à reproduire avec une seule fenêtre de l'app.

Est-ce dangereux d'utiliser le terminal ? Est-ce que je perds le filet de sécurité du visualiseur de changements ?

Tu ne le perds pas : dans le terminal aussi, Claude te demande ton approbation avant de toucher un fichier ou de lancer une commande. La différence, c'est que tu peux régler les permissions (auto-approuver ce qui est sûr, exiger une confirmation pour ce qui est destructeur) et, si tu veux, lui donner plus d'autonomie. Plus de pouvoir et plus de responsabilité : configure les permissions avant de lui confier de grosses tâches.

Quand le terminal ne vaut-il PAS le coup ?

Si tes demandes sont ponctuelles, que tu les révises tranquillement une par une et que tu n'as besoin ni de parallélisme ni d'automatisation, l'app te suffit largement. Le saut devient rentable quand tu remarques trois choses : que tu répètes les mêmes consignes, que tu voudrais lancer deux tâches à la fois, ou que tu aimerais glisser Claude à l'intérieur d'un script. Si tu ne ressens rien de tout ça, reste sur l'app sans complexe.

Claude Code dans le terminal : le saut avancé qui décuple ta puissance

Ça fait des semaines que tu utilises l'app de Claude Code et tu as pris le pli : des demandes claires, réviser le visualiseur, approuver. Ça marche. Mais tu commences à sentir le plafond : tu voudrais lancer deux choses en même temps, tu répètes les mêmes consignes à chaque session, et il te vient des idées de tâches qui feraient un beau script si seulement tu pouvais appeler Claude depuis la ligne de commande.

Ce plafond a un nom : c'est le moment de descendre dans le terminal. Pas parce que c'est «plus pro», mais parce que ça débloque une poignée de choses que l'app, par conception, ne te donne pas. Ce guide, c'est le saut : ce que tu gagnes vraiment, comment l'installer, les commandes qui comptent et les flux qui changent ta façon de travailler.

Note

Le moteur est le même dans l'app et dans le terminal. Tu ne vas pas «apprendre un autre Claude Code». Tu vas dévoiler les fonctions avancées que l'interface visuelle garde hors de vue : parallélisme, automatisation et contrôle fin des permissions.

Ce que tu gagnes en descendant dans le terminal (et ce que tu ne gagnes pas)

Soyons honnêtes pour ne pas te faire perdre de temps. Le terminal ne te rend pas meilleur, et il ne rend pas les résultats plus intelligents. Ce qui change, c'est la façon de travailler. Tu gagnes quatre choses concrètes :

Les sessions en parallèle. Plusieurs instances qui travaillent à la fois sur des branches différentes. C'est la raison numéro un de faire le saut.
L'automatisation. Des flags comme --print et --output-format transforment Claude en une commande de plus, enchaînable avec |, grep ou un cron.
Le mode headless. Glisser Claude dans un script ou un pipeline de CI sans que personne ne regarde l'écran.
Le contrôle des permissions. Tu décides ce qu'il auto-approuve (lire, lister) et ce qui exige ton feu vert (supprimer, exécuter, push).

Ce qui ne change pas : le filet de sécurité est toujours là. Claude te demande ton approbation avant de toucher à quoi que ce soit, comme dans l'app. Sauf que désormais, c'est toi qui décides où placer la barre.

Installation : cinq minutes

Si tu as déjà l'app, tu remplis déjà les prérequis (Node et, quasi certainement, Git). Le terminal s'installe comme un paquet global :

Installer Claude Code (terminal)

# Avec npm (le plus courant)
npm install -g @anthropic-ai/claude-code

# Vérifie qu'il est là et regarde la version
claude --version

# Connecte-toi la première fois (avec ton compte de l'app)
claude

La première fois que tu lances claude dans un dossier, il te demande de te connecter et démarre une session interactive dans ce répertoire. À partir de là, tu lui parles en langage naturel, exactement comme dans l'app. La différence est dans ce que tu peux faire autour de cette conversation.

Astuce

Lance toujours Claude à l'intérieur du dossier du projet (cd mon-projet && claude). Le répertoire d'où tu le lances est sa zone de travail et l'endroit où il cherche le CLAUDE.md. Le lancer depuis le home par erreur, c'est le premier faux pas classique.

Les commandes qui comptent vraiment

Oublie la mémorisation de cent raccourcis. En pratique, le quotidien se joue sur six. Les commandes qui commencent par / s'écrivent à l'intérieur de la session de Claude :

/clear — vide le contexte et repart à zéro. Ton meilleur ami : une session, un objectif. Quand tu changes de tâche, nettoie-la.
/init — analyse le projet et te génère un premier CLAUDE.md. Le point de départ du contexte permanent.
/agents — gère les sous-agents (on les explore plus bas).
/permissions — ajuste ce qu'il auto-approuve et ce qu'il n'auto-approuve pas.
/resume — reprend une session précédente avec tout son contexte. Tu fermes le portable et demain tu continues là où tu t'étais arrêté.
# en début de phrase — enregistre cette consigne dans le CLAUDE.md sans ouvrir le fichier. Un raccourci en or.

Et deux flags qui s'utilisent au lancement de claude depuis l'extérieur, pas de l'intérieur :

claude -p "ta demande" (ou --print) — exécute une tâche et renvoie le résultat sur la sortie standard, sans session interactive. La porte d'entrée de l'automatisation.
--output-format json — renvoie la réponse structurée pour qu'un autre programme la traite.

Le vrai saut : les sessions en parallèle avec les git worktrees

Voilà la vraie raison de descendre dans le terminal. Dans l'app, tu travailles avec une conversation à la fois. Dans le terminal, tu peux avoir trois Claude qui travaillent en parallèle, chacun sur sa branche, sans se marcher dessus.

L'astuce, c'est git worktree : il crée des copies du dépôt qui partagent le même historique mais vivent dans des dossiers et sur des branches distincts. Tu ouvres un terminal par worktree, tu lances un claude dans chacun, et ils se répartissent le travail.

Trois sessions en parallèle

# Depuis la racine du projet, crée trois worktrees sur de nouvelles branches
git worktree add ../projet-feature -b feature-paiements
git worktree add ../projet-tests   -b add-tests
git worktree add ../projet-docs    -b update-docs

# Dans trois onglets/fenêtres de terminal distincts :
cd ../projet-feature && claude   # «implémente le flux de paiement»
cd ../projet-tests   && claude   # «écris des tests pour le module d'auth»
cd ../projet-docs    && claude   # «mets à jour le README avec les nouveaux endpoints»

# Quand une branche est prête, tu la merges et tu nettoies son worktree
git worktree remove ../projet-docs

C'est ce que l'app ne te donne pas et ce que, une fois essayé, tu ne lâches plus. Pendant qu'une session refactorise, une autre documente et une autre teste. Ton travail passe de «attendre que Claude finisse» à «superviser trois fronts». C'est le passage d'assistant à équipe.

Attention

Le parallélisme, ce n'est pas open bar. Chaque session suit son objectif et rien d'autre : un worktree, une tâche. Si tu mélanges les sujets dans une même session, tu lui enlèves de la précision, exactement comme dans l'app. Et révise chaque branche avant de merger ; trois agents produisent trois fois plus de changements à approuver.

CLAUDE.md et slash commands : ton système d'exploitation personnel

Si dans l'app le CLAUDE.md était déjà utile, dans le terminal il devient indispensable. C'est le contexte permanent que Claude lit au démarrage de chaque session : ce qu'est le projet, comment tu travailles, quelles règles respecter. Avec plusieurs sessions en parallèle, c'est lui qui les maintient toutes alignées sans que tu le répètes à chacune.

Le deuxième niveau, ce sont les slash commands personnalisés : des fichiers Markdown dans .claude/commands/ qui deviennent des raccourcis. Tu écris un long prompt une seule fois et tu l'invoques avec /nom pour toujours.

Slash command maison (.claude/commands/revise.md)

Révise le code que je viens de changer en cherchant :

- Les bugs de logique et les cas limites non couverts.
- Les problèmes de sécurité (entrées non validées, secrets en clair).
- Les incohérences avec les conventions de ce projet.

Ne réécris rien pour l'instant. Liste les trouvailles par gravité
et attends mon feu vert avant de toucher aux fichiers.

À partir de ce fichier, tu écris /revise dans n'importe quelle session et Claude exécute cette révision complète. Multiplie ça par tes tâches récurrentes (commits, changelog, audit) et tu arrêtes de taper la même chose chaque jour.

Mode headless : Claude à l'intérieur de tes scripts

Le dernier flux avancé est celui que presque personne n'utilise et qui rend le plus. Avec claude -p, tu glisses Claude dans n'importe quel script, cron ou pipeline de CI. Il cesse d'être une fenêtre de chat pour devenir une pièce de ton automatisation.

Claude dans un script

# Génère le message de commit à partir du diff staged
git commit -m "$(git diff --cached | claude -p 'Résume ces changements en un message de commit concis, à l'''impératif')"

# Triage automatique : classe un nouvel issue sur la sortie standard
echo "$ISSUE_BODY" | claude -p 'Classe cet issue : bug / feature / question. Réponds seulement par l'''étiquette.' --output-format json

C'est là que Claude Code cesse d'être un outil que tu ouvres pour devenir une infrastructure qui tourne toute seule. Commence par des demandes cadrées et déterministes (résumés, classification, formatage), pas par des tâches destructrices sans supervision.

Quand faire le saut (et quand ne pas le faire)

Ne descends pas dans le terminal pour le statut. Fais-le quand tu ressens au moins un de ces trois signaux :

Tu répètes des consignes. Si tu copies le même prompt à chaque session, il te faut des slash commands et un CLAUDE.md bien réglé.
Tu voudrais lancer deux tâches à la fois. Ça, ce sont les worktrees. La raison numéro un.
Il te vient des idées de scripts. Si tu penses «ça devrait tourner tout seul», tu veux le mode headless.

Si tu ne ressens rien de tout ça —tes demandes sont ponctuelles et tu les révises tranquillement— reste sur l'app sans complexe. Elle est tout aussi puissante pour cet usage et n'a aucune friction.

La règle pour monter en puissance est toujours la même : petit à petit. Installe le terminal, habitue-toi aux six commandes, et seulement ensuite essaie un worktree. Le parallélisme et les scripts arrivent quand le reste te vient déjà naturellement. Le saut n'est pas technique, il est de volume : dès que tu auras trois sessions qui produisent en même temps et deux ou trois slash commands en poche, tu ne voudras plus revenir en arrière.