Claude Code en terminal : 7 améliorations de workflow pour utilisateurs avancés

Claude Code « vanilla » est déjà utile tel quel. Vous l’installez, vous le sollicitez, et il construit ce que vous voulez. C’est la configuration de vibe-coding de la plupart des gens, et ça fonctionne.

La version de Claude Code utilisée dans un terminal personnalisé est un autre outil. Les commandes bash de confiance sont pré-approuvées, donc Claude ne demande presque jamais d’autorisations. Un fichier CLAUDE.md est à la racine du projet, donc Claude connaît déjà les conventions dès l’ouverture d’une session. Et quand une session commence à se brouiller, la commande à utiliser n’est pas un redémarrage.

Cet article comble l’écart entre ces deux configurations de Claude Code, en sept améliorations. Chacune prend moins de dix minutes à mettre en place et se rentabilise en moins d’une semaine.

Si vous n’avez jamais ouvert Claude Code, notre guide principal sur Claude Code est un meilleur point de départ. Tout ce qui suit suppose que vous savez déjà créer des prompts et accepter des appels d’outils.

1. Arrêtez de ré-approuver les mêmes commandes

Par défaut, chaque nouvel appel d’outil demande votre approbation. Acceptable la première fois que vous lancez pytest. Agaçant à la troisième. À la dixième, vous matraquez Enter sans lire le message. C’est le pire des deux mondes : vous vous habituez à ignorer le contrôle de sécurité, tout en étant quand même ralenti.

Bien sûr, il existe le mode « dangerously bypass permissions » ou « auto mode ». Nous avons largement couverts leurs compromis dans mon tutoriel sur l’Auto Mode et les channels de Claude Code.

Définir des permissions dans le fichier settings.json

La solution est un fichier .claude/settings.json à la racine du projet, avec un bloc permissions qui pré-approuve les motifs de confiance et bloque ceux que vous refusez :

{
  "permissions": {
	"allow": [
  	"Bash(pytest *)",
  	"Bash(uv run *)",
  	"Bash(ruff check *)",
  	"Read(~/.zshrc)"
	],
	"deny": [
  	"Bash(curl *)",
  	"Read(./.env)",
  	"Read(./.env.*)",
  	"Read(./secrets/**)"
	]
  }
}

Les règles s’évaluent dans un ordre fixe : d’abord deny, puis ask, puis allow. La première correspondance l’emporte, donc une règle deny bat toujours un allow ultérieur.

Maîtriser la portée et les jokers

Trois pièges reviennent souvent lors de la première écriture.

1. Le premier est la portée. Un .claude/settings.json de projet outrepasse votre ~/.claude/settings.json global. Donc si vous avez autorisé Bash(rm *) globalement et que le projet le refuse, c’est le projet qui gagne. C’est le bon comportement par défaut, mais ça surprend quand on s’attend à ce que les autorisations globales priment.

2. Le second concerne les jokers sur les commandes réseau. Bash(curl http://github.com/ *) paraît restrictif mais ne couvre pas https://, les options avant l’URL, les redirections, ni l’expansion de variables shell. Le motif recommandé dans la doc est d’interdire Bash(curl *) purement et simplement. Puis utilisez l’outil WebFetch avec WebFetch(domain:github.com) pour les domaines que vous souhaitez vraiment autoriser.

3. Le troisième est l’espace. Bash(ls *) correspond à ls -la mais pas à lsof. Bash(ls*) correspond aux deux. L’espace avant l’astérisque compte vraiment : faites attention à celui que vous tapez.

Quelques raccourcis clavier complètent les permissions dans la même logique « arrêter de lutter contre le terminal » à maîtriser dès le premier jour :

• Shift+Tab fait défiler les modes d’autorisation (défaut, acceptation auto, plan)

• Esc+Esc ouvre le sélecteur de rembobinage (voir point 3)

• Ctrl+R recherche à rebours dans l’historique des prompts, comme dans bash et zsh

• Ctrl+U supprime du curseur au début de la ligne

• Shift+Enter ajoute une nouvelle ligne dans le prompt

La plupart de ces raccourcis fonctionnent d’emblée dans les terminaux. Si ce n’est pas le cas, exécutez une fois la commande /terminal-setup pour tout installer.

2. Faites retenir votre projet à Claude Code

Chaque session démarre avec une fenêtre de contexte vierge.

Par défaut, Claude n’a pas mémoiré que vous utilisez uv au lieu de pip. Il n’a pas mémoiré que vos tests sont dans tests/ et non dans test/. Et les conventions d’API que vous avez expliquées hier sur dix échanges ont aussi disparu. La solution est un fichier CLAUDE.md à la racine du projet. Lancez Claude Code depuis ce répertoire (ou l’un de ses sous-répertoires), et le fichier est chargé automatiquement dans le contexte avant votre premier prompt.

Le moyen le plus rapide de commencer est /init. Exécutez-le dans le projet. Claude lit la base de code et écrit un CLAUDE.md de départ avec les commandes de build, les instructions de test et les conventions qu’il peut déduire. Vous l’éditerez ensuite, car /init fournit une base opérationnelle, pas un fichier finalisé.

Claude cherche le contexte à trois endroits, superposés :

CLAUDE.md de projet à ./CLAUDE.md est livré avec le dépôt. Il est identique pour tous les contributeurs : mettez-y les spécificités du projet :

• Le gestionnaire de paquets et la version du langage
• La commande de test et l’emplacement des tests
• La structure des répertoires et les conventions non évidentes
• Toute info utile à un nouveau venu dès le premier jour

CLAUDE.md utilisateur à ~/.claude/CLAUDE.md vous suit sur tous les projets de votre machine. Renseignez-y vos préférences : style de code, façon d’écrire les docstrings, langages favoris. N’y mettez pas de faits propres à un projet, sinon ils déborderont sur tous les autres dépôts.

Mémoire automatique est la troisième couche, écrite par Claude lui-même. Quand vous le corrigez pendant une session (« ici, on utilise snake_case et pas camelCase »), il consigne la correction dans ~/.claude/projects/<project>/memory/MEMORY.md. Les 200 premières lignes ou 25 Ko de ce fichier sont chargés au début de chaque conversation sur le même projet. Vous pouvez voir ce qui est chargé avec /memory, qui permet aussi d’activer ou d’inactiver la mémoire automatique.

Une règle de taille : gardez chaque CLAUDE.md sous 200 lignes. Au-delà, le fichier consomme trop de contexte à chaque échange, et Claude suit moins bien un long fichier qu’un court. Si le vôtre grossit, découpez-le dans .claude/rules/ avec des portées par chemin. Pour aller plus loin sur le contenu idéal d’un CLAUDE.md, voir mon guide pour écrire un excellent CLAUDE.md.

3. Arrêtez de redémarrer les sessions quand ça déraille

Le réflexe, quand une session part de travers, c’est de taper /clear et de repartir de zéro. La plupart du temps, c’est une erreur. Vous jetez les chemins de fichiers que Claude éditait, le test en échec qu’il suivait, ou les contraintes définies au début. Une nouvelle session doit tout réapprendre, et vous payez ce réapprentissage en jetons et en temps.

Commencez par reconnaître les symptômes. Ce « pourrissement » de contexte a des signaux clairs :

• Claude redemande un chemin de fichier qu’il éditait il y a cinq échanges
• Il répète une suggestion déjà rejetée
• Il perd la trace de la branche active
• Vous avez corrigé deux fois ou plus le même point dans une session

Une fois ces signaux repérés, vous avez quatre options, non échangeables :

Compacter votre session

 /compact n’est pas aussi mauvais que certains le disent.

Votre CLAUDE.md de projet survit. Claude relit le fichier depuis le disque après compaction et le ré-injecte, vos conventions ne se perdent donc pas. Vous pouvez aussi guider le résumé, par exemple /compact keep the auth refactor decisions, drop the failed test runs. C’est la différence entre un résumé utile et un générique.

Utiliser l’option « annuler » de Claude Code

Le sélecteur de rembobinage via Esc+Esc est méconnu. Il liste tous les points de contrôle de la session. Une fois l’un choisi, trois options : restaurer uniquement la conversation, uniquement le code, ou les deux.

La plupart du temps, « Restore code and conversation » est ce qu’il faut. Une demi-heure de mauvais échanges s’efface sans toucher à git. C’est l’équivalent d’un « annuler » pour toute une session.

Une fois que vous arrêtez de redémarrer, le prochain défi est de retrouver vos sessions.

Nommer et rouvrir des sessions

claude -n <name> (ou --name) démarre une session nommée, et le nom apparaît dans /resume et dans le titre du terminal. Quand vous menez trois chantiers dans le même repo (branche d’expérimentation, refactor, debug), les noms permettent de les distinguer. /rename change le nom en cours de session si le périmètre évolue.

Astuce : utilisez /color pour différencier encore mieux des sessions dans la même fenêtre de terminal.

La réouverture d’une session passe par deux options. claude --continue (ou -c) recharge la conversation la plus récente dans le répertoire courant. Idéal pour reprendre là où vous en étiez.

claude --resume ouvre un sélecteur interactif, et claude --resume <name-or-id> saute directement à une session précise. Traitez vos sessions comme des branches git : des flux de travail distincts méritent les leurs.

4. Planifiez le difficile, économisez sur le facile

Le principal coût d’une config personnalisée n’est ni l’éditeur ni les raccourcis. C’est d’adapter la puissance de calcul à la difficulté de la tâche. Trois outils travaillent de concert pour ça : le mode plan, /effort et /model.

Utiliser le mode plan de Claude Code

Le mode plan demande à Claude de réfléchir à une approche avant de toucher aux fichiers. Il écrit le plan, vous le relisez, vous l’approuvez ou le corrigez, et seulement ensuite il exécute.

Une astuce pour bétonner les plans : un prompt très simple que j’utilise souvent :

Red-team this plan from multiple angles using as many Opus 4.7 agents as you need.

Cela lance plusieurs sous-agents pour passer le plan à la loupe sous différents angles et proposer des correctifs. Bonne pratique au-delà de 500 lignes de plan.

Le coût : planification + red-teaming ajoutent deux tours avant la moindre ligne de code, donc pour une petite fonctionnalité ou un bug mineur, c’est excessif.

Cinq façons d’entrer en mode plan :

La forme en ligne (/plan refactor the auth module to use JWT) est souvent méconnue. Elle règle le mode et la tâche en un seul geste. Pour un pas-à-pas détaillé d’un workflow revue-d’abord, mon tutoriel sur le mode plan de Claude Code vous guide étape par étape.

Régler un niveau d’effort adéquat

L’effort contrôle la quantité de réflexion étendue effectuée par Claude à chaque tour. Plus d’effort signifie un raisonnement plus profond, plus de jetons et une réponse plus lente.

/effort <level> et le drapeau CLI --effort <level> acceptent les cinq valeurs. Low, medium, high et xhigh persistent entre sessions. Max est limité à la session car il supprime la contrainte de dépense, à définir volontairement à chaque fois. Le bon défaut pour le quotidien : low ou medium. Réservez high ou xhigh aux vrais sujets ardus, et max aux moments où vous préférez brûler des jetons que vous tromper.

Un contrepoint : un modèle en low avec un excellent contexte bat souvent le même modèle en max avec un contexte pauvre. Améliorer votre prompt rapporte généralement plus que d’augmenter l’effort.

Choisir le bon modèle

La sélection du modèle est là où se jouent les vraies économies. /model change en cours de session, et Option+P (macOS) / Alt+P (Win/Linux) bascule sans effacer ce que vous avez déjà tapé. Les alias à connaître :

• sonnet est le quotidien par défaut

• opus pour les problèmes les plus ardus (l’alias best pointe aussi sur opus)

• haiku pour la vitesse

• sonnet[1m] et opus[1m] sont les variantes contexte 1M

• opusplan exécute Opus pour la planification et Sonnet pour l’exécution

• default supprime tout override et revient au modèle recommandé

Si vous utilisez Opus par défaut pour tout, passer à Sonnet pour l’essentiel de votre journée est la réduction de dépenses la plus importante à votre portée.

Opus est le bon choix quand vous êtes bloqué sur un point difficile et que vous voulez le modèle le plus performant. Sonnet gère presque tout le reste. L’écart de coûts entre les deux est tel que « je vais juste prendre Opus pour être sûr » devient l’habitude la plus onéreuse à laisser en pilote automatique.

5. Automatisez ce que vous faites encore à la main

Une fois les frictions éliminées, la couche suivante est le travail que vous faites encore manuellement.

Tâches planifiées

C’est plus simple que d’essayer de vous en passer. Deux fonctionnalités couvrent l’essentiel : /loop pour des vérifications récurrentes et des hooks pour des garanties qu’un CLAUDE.md ne peut pas imposer.

/loop relance un prompt ou une commande slash à intervalle régulier. Deux syntaxes :

• /loop 5m <prompt> exécute le prompt toutes les 5 minutes

• /loop <prompt> seul laisse le modèle décider de la cadence

Unités d’intervalle : s, m, h et d, avec une minute minimum. Nécessite Claude Code v2.1.72 ou ultérieure.

Par exemple, mettez en place un watcher de tests : /loop 2m run the test suite and report failures. Au lieu de penser à lancer les tests après chaque changement (et oublier une fois sur deux), Claude signale un test cassé à la prochaine échéance de 2 minutes.

Même logique pour sonder un déploiement de staging (/loop 10m check if the staging deploy is green) ou suivre des logs pendant un incident instable (/loop 1m tail the last 50 lines of app.log and flag errors).

Les boucles vivent 7 jours.

La tâche s’exécute une dernière fois au septième jour puis s’efface. Elles sont liées à la session, donc --continue ou --resume les réactive si vous fermez puis rouvrez. Pour arrêter une boucle plus tôt, appuyez sur Esc. Si vous avez besoin d’une planification qui survit à la fermeture (vérification nocturne, récap hebdo), utilisez Routines via /schedule.

Hooks

Les hooks complètent le tableau. Ils exécutent des commandes shell à des moments précis du workflow de Claude, configurés dans .claude/settings.json. 

Pourquoi préférer un hook à une instruction CLAUDE.md ? Parce que CLAUDE.md est indicatif, et les hooks s’exécutent quoi qu’il arrive. Le cas classique : « toujours lancer le linter après édition » que Claude oublie une fois sur deux. Un hook comble cette lacune.

Six événements couvrent la plupart des cas d’usage :

Un hook minimal PostToolUse qui lance un linter après chaque édition de fichier :

{
  "hooks": {
	"PostToolUse": [
  	{
    	"matcher": "Edit|Write",
    	"hooks": [
      	{ "type": "command", "command": "/path/to/lint-check.sh" }
    	]
  	}
	]
  }
}

Un piège à connaître : seul le code de sortie 2 bloque réellement Claude. Le code 1 est traité comme une erreur non bloquante, et Claude poursuit quand même, même si 1 est le code d’échec Unix habituel. Si votre hook doit faire respecter une règle, retournez 2.

Vous n’êtes pas obligé d’écrire les hooks à la main.

Demandez à Claude : « write a hook that runs ruff after every file edit », il générera le JSON. /hooks liste toutes les configurations de hooks actives, inutile de grepper les fichiers de config quand quelque chose se déclenche de façon inattendue. Pour le catalogue complet des événements et les schémas JSON stdin/stdout, voir mon tutoriel sur les hooks Claude Code.

6. Gardez un œil sur les coûts

Les boucles, les longues sessions et Opus par défaut consomment des jetons. Trois commandes rendent la dépense assez visible pour être pilotée. L’habitude à prendre : y jeter un coup d’œil, pas les surconfigurer.

/usage affiche votre offre, les totaux de session, la répartition par modèle, et des barres de progression pour les fenêtres de limitation à 5 heures et à la semaine.

/context visualise la fenêtre de contexte actuelle sous forme de grille colorée, avec des alertes de capacité et des suggestions sur les outils/fichiers gourmands. Utilisez-la quand une session paraît lourde, pour arbitrer entre /compact et /clear.

/statusline configure une barre persistante en bas du terminal. Elle peut afficher le modèle, le pourcentage de contexte, les fenêtres de rate-limit, et tout ce que vous pouvez lire depuis le JSON de session. C’est celle qui change le plus les comportements, car les chiffres utiles sont dans votre vision périphérique pendant que vous travaillez.

Vous pouvez exécuter /statusline et décrire en langage naturel ce que vous voulez y voir, et Claude génère le script puis met à jour les paramètres. Autre option : écrire vous-même un script shell et le référencer depuis ~/.claude/settings.json :

{
  "statusLine": {
	"type": "command",
	"command": "~/.claude/statusline.sh"
  }
}

Pour un suivi plus long terme, npx ccusage est un outil communautaire qui agrège la consommation de jetons dans le temps. C’est tiers, pas conçu par Anthropic, mais il comble l’écart entre /usage (lié à la session) et votre facture mensuelle.

7. Trois autres fonctions à connaître

Les six upgrades ci-dessus sont celles que j’utilise au quotidien. Les trois suivantes sont réelles et utiles, même si plus occasionnelles : sachez qu’elles existent pour les sortir le jour où vous en aurez besoin.

Activer le push-to-talk avec /voice

/voice active la dictée push-to-talk. Maintenez Space, parlez, relâchez, et le texte transcrit arrive dans votre prompt. Nécessite la v2.1.69 ou ultérieure, vingt langues prises en charge.

La voix surpasse le clavier quand vous marchez et pensez à voix haute, ou pour dicter l’intention au début d’une tâche avant de figer la formulation. Moins bon pour des édits à la ligne, où « changer la ligne 47 en... » est plus simple à taper.

Rapatrier des sessions cloud avec /teleport

/teleport (alias /tp) rapatrie une session cloud dans votre terminal local. Vous avez lancé une longue tâche sur le web ou l’app iOS et vous êtes de retour sur votre laptop ? Exécutez claude --teleport pour ouvrir un sélecteur et retrouver la session dans votre terminal avec la bonne branche déjà checkout.

Quelques prérequis doivent concorder :

• Un état git propre
• Le bon repo
• Le même compte claude.ai que celui de la session cloud
• La branche a été poussée sur le remote

Ne confondez pas --teleport avec --resume. Ce dernier ne rouvre que des sessions locales depuis l’historique de cette machine. Pour un guide complet, notre tutoriel de contrôle à distance de Claude Code couvre le reste.

Poser des questions annexes avec /btw

/btw sert aux questions rapides sans casser le flux.

Imaginez Claude en plein travail : vous avez lancé une longue édition ou un appel d’outil et vous devez soudain connaître la regex pour les IPs ou quel flag fait X. 

Tapez simplement /btw <question>, et la réponse apparaît dans une superposition que vous pouvez fermer. La tâche en cours continue, la réponse n’entre pas dans l’historique, vous évitez donc d’ouvrir une nouvelle session pour un simple lookup et ne polluez pas l’actuelle.

Conclusion

La meilleure façon de rechuter sur tout ce qui précède est de tout essayer en une journée. Choisissez-en deux ou trois, ancrez les réflexes, et ajoutez le reste quand le premier lot est devenu automatique.

Trois pour démarrer, chacun pour un moment différent de la journée, pour éviter qu’ils se parasitent :

• Un CLAUDE.md de projet concis plus deux ou trois règles de permissions avec jokers dans .claude/settings.json pour les commandes bash que vous ré-approuvez à chaque session. Habitude du matin : vous la sentez quand les interruptions cessent.

• Le choix /compact vs /clear et le rembobinage Esc+Esc. Habitude en milieu de session : le signal, c’est quand Claude redemande un chemin de fichier qu’il connaissait il y a une heure.

• Un /loop pour une vérification récurrente qui vous prend déjà du temps. Habitude de fond : une fois lancée, elle s’amortit toute seule.

Si la différence entre Sonnet, Opus et Haiku reste floue, notre cours Introduction to Claude Models explique quand utiliser chaque modèle. Les commandes /effort et /model deviennent alors bien plus simples.