Chapitre 11 · Pour devs et tech leads

Claude Code : bonnes pratiques 2026

Comment fonctionne Claude Code sous le capot, et les pratiques qui font la différence entre l'utiliser comme un gadget et l'utiliser comme un vrai levier de productivité technique. Chapitre orienté développeurs et tech leads.

Le bon modèle mental : "le collègue qui ne lâche jamais le terminal"

Avant de parler bonnes pratiques, il faut bien se représenter ce qu'est Claude Code. Ce n'est ni un autocomplete glorifié, ni un IDE avec une fonctionnalité IA. C'est un agent qui tourne dans votre terminal et qui sait utiliser des outils — exactement comme un développeur senior très à l'aise en CLI le ferait.

🛠️ Architecture en quelques mots

Claude Code = un modèle Claude + des outils puissants + une boucle d'exécution. Les outils principaux :

Lire et éditer des fichiers
Exécuter des commandes terminal (bash, git, docker, gh, npm...)
Rechercher dans le code (glob, grep, find)
Optionnellement, des serveurs MCP pour étendre les capacités

Et c'est tout. Pas d'indexation préalable du code, pas d'embeddings, pas de RAG. Claude explore le code comme un humain qui débarque dans une nouvelle base : il fait des grep, lit les fichiers, suit les imports.

Cette simplicité est volontaire. C'est ce qu'Anthropic appelle le principe du simple thing that works : un agent unique avec des bons outils, qu'on laisse tourner dans une boucle jusqu'à ce qu'il décide qu'il a fini.

Les conséquences pratiques de ce design

Pas de pré-traitement du repo — Vous ouvrez Claude Code dans n'importe quel dossier, ça marche immédiatement. Pas de "Claude est en train d'indexer votre projet, patience..."
Le contexte se construit au fur et à mesure — Plus la session avance, plus Claude a chargé de fichiers en mémoire. Cela impacte directement la gestion du contexte (cf. plus bas).
Plus le projet est bien structuré, mieux Claude s'en sort — Une convention de nommage cohérente, des dossiers logiques, des imports propres : Claude trouve les bons fichiers en moins de tool calls.
Le modèle compte autant que la commande — Sonnet pour la rapidité, Opus pour les tâches lourdes (cf. /model).

💡 La métaphore qui marche

Pensez Claude Code comme le mentor senior qui vit dans le terminal et qui peut faire tout ce que vous lui demandez en bash, git, docker, ou autre CLI. Vous lui parlez en langage naturel, il traduit en commandes. La différence avec un humain : il n'est jamais fatigué et il accepte les sessions à 23h.

Bonne pratique #1 : utilisez CLAUDE.md pour tout ce qui se répète

Claude Code est un agent stateless : entre deux sessions, il ne se souvient de rien. Le mécanisme officiel pour partager du contexte avec lui session après session, c'est le fichier CLAUDE.md placé à la racine du projet.

Au démarrage de Claude Code, ce fichier est automatiquement injecté dans le contexte avec une instruction du type "voici les notes importantes laissées par le développeur, lis-les attentivement". Tout ce que vous ne voulez pas répéter à chaque session va dedans.

Ce qu'on met dans CLAUDE.md

📂 Vue d'ensemble du projet

Architecture, dossiers principaux, où se trouvent les tests, le build, la config. Évite à Claude d'explorer 10 fichiers pour comprendre la structure.

Indispensable

🧪 Comment lancer les tests

La commande exacte (pnpm test, make test, pytest -xvs...). Claude lance les tests tout seul si vous lui dites.

Indispensable

📝 Conventions de code

Style guide, conventions de nommage, patterns à suivre, patterns à éviter. Claude suit la charte si vous lui donnez.

Recommandé

🚫 Choses à ne pas faire

"Ne touche jamais à vendor/", "ne committe jamais sans demander", "n'installe pas de nouvelle dépendance sans validation".

Recommandé

⚙️ Outils internes spécifiques

Si vous avez un CLI maison ou des scripts custom, expliquez-les. Claude saura les utiliser.

Selon contexte

🔗 Références à d'autres fichiers

Avec la syntaxe @autre-fichier.md, vous pouvez chaîner plusieurs fichiers de doc. Utile pour gros monorepos.

Avancé

Les 3 emplacements possibles pour CLAUDE.md

À la racine du projet — Versionné dans git, partagé avec toute l'équipe. C'est le cas standard.
Dans un sous-dossier — Lu par Claude quand il explore ce sous-dossier. Utile pour les monorepos avec des conventions différentes par package.
Dans ~/.claude/CLAUDE.md — Vos préférences personnelles, indépendantes du projet. Claude les charge toujours.

⚠️ Piège classique du monorepo

Dans un gros monorepo, ne mettez pas tout dans le CLAUDE.md racine. Vous allez exploser le contexte de Claude dès le démarrage. Utilisez plutôt un CLAUDE.md léger à la racine + des CLAUDE.md spécifiques par sous-dossier que Claude découvrira naturellement.

✅ Itération du CLAUDE.md

Le CLAUDE.md évolue avec le projet. À chaque fois que vous corrigez une erreur récurrente de Claude (style, choix d'outil, oubli), ajoutez la règle correspondante dans CLAUDE.md. En quelques semaines vous avez un fichier qui élimine 80% des frictions.

Bonne pratique #2 : maîtrisez la gestion des permissions

Claude Code par défaut applique une politique conservatrice : lecture libre, mais validation humaine pour toute action qui modifie l'état du système (écriture de fichiers, commandes bash, push git, install de packages). À chaque action sensible, une UI vous demande "yes / yes always / no".

Cette politique est un bon réglage de départ, mais elle ralentit beaucoup les sessions. Voici comment l'optimiser sans sacrifier la sécurité.

Trois leviers à connaître

1. Le mode auto-accept (Shift+Tab)

Pendant une session, vous pouvez activer le mode auto-accept en pressant Shift+Tab. Claude exécute alors toutes les actions sans demander. Utile quand vous lancez Claude sur une grosse refacto bien définie et que vous allez prendre un café. À utiliser sur projets isolés ou en sandbox, pas sur prod.

2. La whitelist de commandes

Dans les settings, vous pouvez whitelist des commandes spécifiques pour qu'elles ne demandent plus de confirmation. Exemples typiques : npm test, pytest, cargo check, gh pr list. Tout ce qui est read-only ou idempotent peut y aller sans risque.

3. Le "yes always"

Pendant une session, choisir "yes always" sur une action ajoute la commande à votre whitelist personnelle pour les sessions futures. Manière progressive de construire une whitelist sur mesure.

⚠️ Ne whitelist jamais ces commandes

git push, npm publish, terraform apply, kubectl apply, rm -rf, ou tout ce qui touche à de la prod. Un Claude qui hallucine peut détruire un environnement en quelques tool calls. Le coût d'une confirmation manuelle est négligeable face à ce risque.

Bonne pratique #3 : adoptez les workflows qui marchent

Le workflow "plan d'abord, code ensuite"

Le réflexe naturel quand on commence avec Claude Code, c'est de lui dire "implémente cette feature". Ça marche, mais c'est sous-optimal. Le workflow qui donne de bien meilleurs résultats :

Demandez un plan, pas du code. "J'aimerais ajouter telle feature. Explore le code et propose-moi 2-3 approches possibles. Ne touche à rien pour l'instant."
Discutez le plan. Lisez ce que Claude propose. Validez ou amendez.
Lancez l'implémentation. Une fois le plan stabilisé, "OK, implémente l'option 2".

Bénéfice : vous corrigez les mauvaises orientations avant qu'elles soient transformées en code, donc vous économisez les tokens et le temps de revert.

La todo list visible

Sur les tâches longues, Claude Code génère et affiche une todo list interne. C'est précieux : c'est votre fenêtre sur ce que Claude prévoit de faire. Si vous voyez un item bizarre dans la liste ("Migrer la base de données" alors que vous n'avez pas demandé), c'est le moment de presser Esc pour intervenir et corriger la trajectoire.

Le vibe coding intelligent

Le "vibe coding" — laisser Claude tourner sans valider à chaque étape — est très puissant mais piège classique : on découvre 200 fichiers modifiés et 30% qui n'ont rien à faire là. Pour le rendre safe :

TDD systématique — Demandez à Claude d'écrire d'abord les tests, puis le code, puis de vérifier que les tests passent. Le test sert de garde-fou.
Petits commits fréquents — Demandez explicitement "commit après chaque étape qui passe les tests". Si ça part en vrille, vous revenez en arrière facilement.
Vérifications continues — TypeScript, lint, build : à chaque étape. Bloque les régressions silencieuses.

Screenshots pour le visuel

Les modèles Claude sont multimodaux. Un screenshot collé directement dans le terminal vaut mieux que mille mots de description. "Voici la maquette qu'on doit reproduire" + image, ou "voici l'erreur que je vois dans le navigateur" + screenshot, fonctionne très bien pour les sujets UI.

💡 Le réflexe de l'extended thinking

Sur les tâches complexes (debug profond, archi, refacto difficile), ajoutez "think hard" dans votre message. Claude active alors une phase de réflexion étendue avant et entre les tool calls. C'est plus lent mais beaucoup plus efficace sur les problèmes qui demandent de raisonner avant d'agir.

Bonne pratique #4 : faites tourner plusieurs Claude en parallèle

Quand vous avez bien intégré le workflow solo, l'étape suivante est la parallélisation : faire tourner 2, 3, voire 4 instances de Claude Code simultanément, chacune sur une tâche différente. Pratique courante chez les power users d'Anthropic.

Comment orchestrer plusieurs Claude

Tmux ou plusieurs terminaux — La méthode simple. Une instance par feature ou par bug. Vous oscillez entre elles à mesure qu'elles progressent.
Worktrees git — Chaque Claude bosse dans un worktree git différent. Pas de conflit de branches, parallélisation propre.
Communication par fichier — Claude n°1 écrit ses notes dans ticket.md. Claude n°2 lit ticket.md et continue. C'est rudimentaire mais ça marche.

Patterns de parallélisation utiles

🐛 Pattern bug-rush

3 bugs P1, 3 instances de Claude qui les attaquent en parallèle. Chacun sur un worktree différent. PR séparées, review en série.

Setup : 5 min

🔍 Pattern explore + implement

Claude n°1 explore le code et écrit un plan détaillé dans plan.md. Claude n°2 lit plan.md et implémente. Découplage analyse/exécution.

Setup : 2 min

⚡ Pattern producer/consumer

Claude n°1 génère des cas de tests dans cases.md. Claude n°2 implémente le code qui les fait passer. Mini-TDD distribué.

Setup : 3 min

🏗️ Pattern monorepo

1 Claude par package du monorepo. Chacun a son CLAUDE.md spécifique. Très efficace sur les refactos transverses.

Setup : 10 min

⚠️ Le pic cognitif

Au-delà de 3-4 Claude en parallèle, vous passez plus de temps à orchestrer qu'à valider. Le sweet spot pour la plupart des devs est 2-3 instances. Au-delà, c'est l'IA qui vous gère, pas l'inverse.

Bonne pratique #5 : maîtrisez les raccourcis et slash commands

Les raccourcis et slash commands de Claude Code sont sous-utilisés. Voici ceux qui changent vraiment le quotidien.

Raccourci / Commande	Effet	Quand l'utiliser
`Esc`	Interrompre Claude	Quand Claude part dans la mauvaise direction
`Esc Esc`	Revenir en arrière dans la conversation	Pour rejouer un tour différent
`Shift+Tab`	Toggle auto-accept mode	Quand vous lancez un gros chantier autonome
`/clear`	Vider le contexte (garde CLAUDE.md)	Changement complet de tâche
`/compact`	Résumer la session pour libérer du contexte	Quand le warning de contexte apparaît
`/model`	Switcher entre Sonnet et Opus	Opus pour les tâches lourdes, Sonnet pour la vitesse
`/config`	Réglages globaux	Whitelist de commandes, modèle par défaut
`think hard` dans le prompt	Active le raisonnement étendu	Debug complexe, archi, refacto difficile

Gestion du contexte : /clear vs /compact

Le contexte de Claude se remplit vite : 200k tokens semblent énormes mais quelques gros fichiers, quelques résultats de tests verbeux, et c'est saturé. Deux stratégies selon ce que vous faites :

/clear — quand vous changez de tâche. Vous étiez en debug d'un bug, vous passez à une nouvelle feature : reset complet, on repart propre.
/compact — quand vous continuez la même tâche. Claude génère un résumé de ce qui a été fait, l'injecte comme nouveau point de départ. Vous gardez le fil sans saturer.

💡 La règle des 70%

Quand le compteur de contexte atteint 70%, anticipez. Soit vous finissez la tâche en cours rapidement et vous faites /clear, soit vous faites /compact immédiatement. Au-delà de 90%, Claude commence à perdre en qualité parce qu'il oublie ce qui est en début de session.

Bonne pratique #6 : étendez avec MCP, mais préférez les CLI

Claude Code est puissant out-of-the-box, mais pour aller plus loin il y a deux voies : les serveurs MCP (Model Context Protocol) et les CLI installés sur la machine. La plupart du temps, le bon choix est le CLI.

La règle simple

Si un CLI bien documenté existe, utilisez le CLI

GitHub : utilisez gh. Cloud (AWS, GCP) : utilisez le CLI officiel. Docker, kubectl, terraform, gcloud : tous excellents en CLI. Claude Code sait les utiliser nativement, sans configuration.

Réservez MCP aux cas où il n'y a pas de CLI

Outils internes maison sans CLI, plateformes propriétaires (Notion, Linear avec API custom), bases de données spécifiques. Là, MCP est la bonne option.

Pourquoi cette préférence ? Parce que les CLI sont stables, documentés, ont des messages d'erreur clairs, et Claude a vu des milliers d'exemples dans son entraînement. Les MCP servers sont plus jeunes, parfois instables, et ajoutent une couche d'abstraction supplémentaire qui peut se mettre en travers.

Les MCP qui valent vraiment le coup

MCP de bases de données — Postgres, Sqlite, Redis : quand le CLI est trop verbeux pour de l'exploration interactive.
MCP d'outils internes — Si votre boîte a un outil maison sans CLI, écrire un MCP léger vaut le coup.
MCP de plateformes SaaS — Slack, Notion, Linear si vous voulez une intégration plus fluide qu'avec leurs API HTTP brutes.

Bonne pratique #7 : exploitez le mode headless

Au-delà de l'usage interactif, Claude Code expose un mode programmatique via le SDK et l'option claude -p. C'est ce qui permet d'utiliser Claude Code comme une brique dans des pipelines plus larges. Trois cas où ça change la donne.

1. CI/CD : Claude comme reviewer automatique

L'action GitHub officielle de Claude Code permet d'avoir un @claude qui répond aux issues et aux PR. Cas d'usage : un dev pose une question dans une issue, Claude propose une implémentation et ouvre une PR automatiquement. Configuré en 5 minutes, économise des heures de triage par semaine.

2. Pipelines Unix : Claude dans un pipe

L'option claude -p permet d'utiliser Claude comme n'importe quel utilitaire CLI. Quelques exemples qui valent leur pesant d'or :

cat error.log | claude -p "trouve la cause de l'erreur"
ifconfig | claude -p "explique-moi cette config réseau"
git diff | claude -p "fais-moi une review de ces changements"
cat suspect-file.ts | claude -p "review ce code et identifie les risques de sécu"

L'option --output-format json renvoie une réponse structurée que vous pouvez parser et utiliser dans d'autres scripts. C'est ce qui rend Claude Code combinable à l'infini avec les outils Unix existants.

3. Linters custom à la volée

Plutôt que d'écrire un linter custom pour vérifier une convention spécifique à votre équipe, vous pouvez demander à Claude de jouer le rôle de linter. Exemple :

find src -name "*.ts" | xargs cat | \
  claude -p "vérifie que chaque fonction publique a une docstring respectant notre format" \
  --output-format json

Bricolé en 2 minutes, ça fait le job pour des règles complexes qu'aucun linter standard ne vérifie.

✅ Le mindset à adopter

Chaque fois qu'une tâche dans votre stack pourrait bénéficier d'un peu de raisonnement contextuel (review, classification, transformation, génération de notes), demandez-vous : "et si je sprinklais un claude -p ici ?". Beaucoup de problèmes deviennent triviaux avec ce réflexe.

Le résumé des résumés

Si vous ne deviez retenir que 7 choses sur Claude Code après avoir lu ce chapitre :

C'est un agent simple, pas un produit complexe. Modèle + outils + boucle. Comprenez ça et tout devient logique.
CLAUDE.md est votre meilleur investissement temps. Itérez-le constamment.
Les permissions ne sont pas un frein, c'est un garde-fou. Whitelistez intelligemment.
Demandez un plan avant le code. Toujours plus rapide au global.
Plusieurs Claude en parallèle, c'est le multiplicateur. 2-3 instances, pas plus.
Esc est votre meilleur ami. Interrompez tôt, économisez des reverts.
Le mode headless est sous-exploité. Sprinklez du claude -p partout.

Ce chapitre est volontairement orienté dev. Pour la vue business côté PME (cas d'usage, ROI), voir le chapitre 9.

← Limites et tarifs Retour au sommaire →

Vous voulez intégrer Claude Code dans la stack technique de votre PME ?

30 minutes pour évaluer le contexte, identifier les premiers cas d'usage et cadrer un déploiement qui apporte un ROI dès le premier mois.

Réserver mon appel offert →

Voir aussi : service Agents Claude · service MCP pour PME