Claude Code : quatre disciplines plutôt que trente-deux hacks

Les listes de “32 hacks Claude Code” prolifèrent et se ressemblent : enchaîner trente commandes slash, mémoriser sept raccourcis, installer quatre serveurs MCP. La vérité opérationnelle est plus brève. Claude Code tient en quatre disciplines, le contexte, le plan, le modèle adapté à la tâche, les permissions et hooks, et tout le reste, des skills bundlées aux dynamic workflows, n’est que la mise en œuvre d’une de ces quatre. Une fois les principes en place, la longue liste devient évidente. Avant, elle est juste fatigante.

Voici les quatre, dans l’ordre où elles se chargent en mémoire.

Le contexte est la matière première

Le premier réflexe quand on ouvre un repo n’est pas de poser une question, c’est de charger le contexte. Sur Claude Code, ça veut dire trois choses : un fichier CLAUDE.md qui décrit l’architecture, les conventions, les fichiers importants ; un nettoyage régulier de la fenêtre ; et un diagnostic quand quelque chose semble lent ou cher.

Les commandes officielles sont documentées dans la référence. Les trois que je rejouerais sur n’importe quel projet :

/init génère un CLAUDE.md initial qui scanne le codebase. C’est rarement parfait, mais c’est une base qu’on raffine ensuite.
/context montre où vont les tokens. Souvent un seul serveur MCP mange 30 % de la fenêtre ; on ne le voit que quand on regarde.
/compact (avec optionnellement une consigne de ce qu’il faut préserver) et /clear (entre tâches sans rapport) sont les deux outils de gestion du chargement utile.

Le # en début de ligne épingle une note dans CLAUDE.md sans casser le flux. C’est le détail le plus sous-utilisé : la convention qu’on découvre à 15h s’écrit en une ligne et survit aux sessions suivantes.

Le réflexe à entretenir : plus le contexte est petit et intentionnel, meilleur est le résultat. Un dump complet du codebase est presque toujours pire qu’une sélection de cinq fichiers pertinents.

Le plan avant le code

La seconde discipline est plus humaine que technique. Avant d’écrire la modification, on décrit ce qu’on va faire, et on laisse Claude objecter.

/plan (ou Shift+Tab pour basculer en mode plan dans une session interactive) met Claude en posture de recherche : il peut lire, chercher, demander, mais pas modifier. Il propose l’approche, liste les fichiers concernés, signale les ambiguïtés. C’est dix minutes qui économisent une heure de revisions sur un diff de quarante fichiers parti dans la mauvaise direction.

La pratique qui rend ça vraiment efficace, c’est de demander explicitement “continue à me poser des questions tant que tu n’es pas à 95 % de confiance”. Trois tours de clarification battent trois tours de correction, à chaque fois.

Le /code-review et /security-review bundlés appartiennent à la même discipline : forcer un second passage en posture critique sur un code qu’on vient de produire en posture constructive. Le contexte mental n’est pas le même, et Claude le sait, c’est pour ça que ces skills existent comme commandes séparées plutôt que comme prompts ad-hoc.

Un modèle, un effort, par tâche

La troisième discipline est ce que Claude Code rend possible et que la plupart des utilisateurs ignorent : on ne reste pas sur un seul modèle.

/model change de modèle dans la session courante. Opus pour les décisions d’architecture et le debug compliqué ; Sonnet pour le travail quotidien ; Haiku pour les passes massives bon marché, “trouve tous les fichiers qui importent X”, “liste les fonctions sans tests”. Le coût et la qualité bougent ensemble, et il n’y a aucune raison de payer Opus pour une tâche que Haiku résout aussi bien.

/effort ajuste l’intensité de raisonnement (high, xhigh, max). Sur Opus 4.8 le défaut est high, sur 4.7 c’était xhigh, le réglage par défaut a bougé, et il vaut la peine d’essayer le défaut avant de pousser. Les régressions à pousser trop fort sont mesurables : tokens en plus, qualité parfois en baisse à cause de l’overthinking.

Les dynamic workflows arrivés avec Opus 4.8 étendent ce principe à l’échelle de la session : Claude décide lui-même quand fan-out massivement, dans des dizaines à des centaines de subagents parallèles, pour un travail à l’échelle du codebase. C’est l’évolution logique du “un modèle par tâche”, appliquée non plus par la main de l’utilisateur, mais par l’orchestration.

Conséquence directe : la qualité du brief initial compte encore plus, parce qu’une consigne floue se propage à toute la flotte de subagents.

Permissions et hooks tiennent la sécurité

La quatrième discipline est celle qui rend l’autonomie tenable. Plus Claude Code fait de choses tout seul, plus la posture de défense doit être explicite.

/permissions (ou ~/.claude/settings.json) sert à autoriser nommément les commandes sûres et à interdire nommément les commandes destructrices. Les règles d’interdiction l’emportent sur les règles d’autorisation, ce qui veut dire que les patterns dangereux restent bloqués même si une autorisation générique les couvrirait. C’est le compromis correct entre fluidité et sécurité.

Les hooks (Stop, PreToolUse, PostToolUse, SessionEnd, etc.) sont l’autre moitié de cette défense. Ils s’exécutent en dehors du raisonnement du modèle, Claude ne peut pas les sauter. C’est pour ça qu’ils sont l’endroit où mettre les choses qui doivent arriver : un formatage automatique sur édition, un bloqueur de rm -rf / non sandboxé, un lint avant commit, une notification de fin de tâche sur Telegram.

Le réflexe à ne jamais prendre, même par paresse : --dangerously-skip-permissions. La rapidité gagnée se paie d’une seule mauvaise session, et la perte est rarement réversible.

Le reste découle

Les autres “hacks” qu’on lit partout sont des variantes d’une de ces quatre disciplines. La voice mode rend le contexte plus dense (discipline 1). /cost et /statusline rendent visible la consommation pour mieux la gérer (discipline 1). Les git worktrees parallélisent ce que les subagents font conceptuellement (discipline 3). Les Routines déplacent l’orchestration en arrière-plan (discipline 3). Le marketplace de skills industrialise les workflows répétables, c’est la mise en réutilisation des trois premières disciplines.

Le piège qui guette la lecture de ces listes est de croire qu’il faut tout adopter pour être bon. C’est faux. Quatre disciplines bien tenues battent trente-deux commandes mémorisées sans cadre. Le /init, le mode plan, un /model adapté, et un /permissions discipliné sont déjà 80 % du chemin.

Si cela vous a parlé, vous aimerez Claude Opus 4.8 : un modèle qui rattrape ses propres bugs et Écrire des skills que votre agent de code utilisera vraiment. Abonnez-vous ci-dessous pour recevoir le billet de vendredi prochain.