Agentic Coding with Claude Code

1La fenêtre de contexte est le vrai budget

Première famille : choisir ce qui entre. Tout part d'une limite. Claude ne voit qu'une quantité limitée de texte à la fois. Sa fenêtre contient les consignes, la conversation et les fichiers lus. Le livre donne un ordre de grandeur : 10 000 tokens après le premier échange, 30 000 après le deuxième, près de 100 000 au cinquième (ch. 39). Or, quand la fenêtre se remplit de choses sans rapport avec la tâche, la qualité baisse. Le livre appelle cela la « pollution du contexte ». Il en distingue trois formes. L'empoisonnement, c'est une hallucination qui entre dans le contexte. La confusion, c'est du hors-sujet qui pèse sur la réponse. Le conflit, ce sont deux parties du contexte qui se contredisent.

Contre cette pollution, le livre décrit l'ingénierie du contexte. Claude Code l'applique avec quatre stratégies (ch. 0) :

• Écrire : garder une mémoire qui survit d'une session à l'autre (idée 2).
• Sélectionner : ne charger que ce qui sert à la tâche (idées 3 et 4).
• Compresser : /compact résume la conversation et garde les décisions clés. /clear repart d'une conversation vide.
• Isoler : confier une tâche à un sous-agent. Un sous-agent est une seconde instance de Claude, avec sa propre fenêtre (idées 5 et 6).

2Un CLAUDE.md vous évite de tout répéter

La première stratégie, écrire, passe par un fichier. Sans mémoire, chaque session repart de zéro. Il faut alors tout répéter, par exemple que le projet utilise Prisma, une bibliothèque d'accès à la base de données (ch. 0). Le CLAUDE.md règle ce problème. C'est un fichier texte que Claude Code charge au début de chaque session. Il existe à plusieurs étages (ch. 11) :

• ~/.claude/CLAUDE.md vaut pour tous vos projets.
• ./CLAUDE.md vaut pour le projet, et se partage par Git.
• CLAUDE.local.md est personnel, et Git l'ignore.

/Users/edenmarco/
├── .claude/CLAUDE.md             # mémoire utilisateur
└── Desktop/my-company/
    ├── CLAUDE.md                 # mémoire projet
    └── frontend/CLAUDE.md        # mémoire du dossier
# Lancé depuis frontend/, Claude Code charge les trois fichiers.
# (arborescence du livre, abrégée)

La démonstration du livre est drôle. L'auteur range « j'aime la pizza » dans la mémoire du projet. Il range « j'aime les hamburgers » dans la mémoire utilisateur. Il vide la conversation avec /clear, puis demande ce qu'il aime manger. Claude répond les deux (ch. 12). Les deux fichiers ont donc été relus après le /clear. Le livre conseille des fichiers courts et précis, parce qu'une mémoire surchargée gaspille des tokens (ch. 11).

Quoi mettre à quel étage, en pratique : le CLAUDE.md d'un projet PHP dit ce que toute l'équipe doit savoir. Par exemple : « l'accès à la base passe par PDO », ou « les tests se lancent avec vendor/bin/phpunit ». Le CLAUDE.local.md garde ce qui ne concerne que votre poste, comme le port de votre serveur local. Le fichier de votre dossier personnel garde vos habitudes valables partout, comme la langue de vos messages de commit.

3Une skill ne se charge que quand elle sert

Le CLAUDE.md a une limite : il se charge à chaque session, même quand il ne sert pas. Le livre part d'une demande banale : « donne à cette application le style d'Anthropic ». Sans aide, l'agent va chercher ce style à chaque fois. Le mettre dans le CLAUDE.md le chargerait même pour du code serveur (ch. 51).

La skill répond à ce cas, et c'est la deuxième stratégie : sélectionner. Une skill est un dossier avec un fichier SKILL.md, et parfois des scripts. Seul son en-tête reste en permanence dans le contexte : le nom et la description, soit 100 à 200 tokens par skill. Claude lit le reste seulement quand il juge la skill utile. Le livre appelle cela le chargement progressif (ch. 55).

L'exemple du livre s'appelle git-pushing. Cette skill force l'agent à passer par un script, au lieu d'improviser des commandes Git (ch. 53) :

.claude/skills/git-pushing/
├── SKILL.md
└── scripts/smart_commit.sh

# SKILL.md (extrait)
---
name: git-pushing
description: Stage, commit, and push git changes with conventional commit messages. ...
---
Stage all changes, create a conventional commit, and push to the remote branch.
**ALWAYS use the script** - do NOT use manual git commands:
bash skills/git-pushing/scripts/smart_commit.sh

Le livre donne une règle simple (ch. 55). Une tâche lourde qui gonflerait le contexte va à un sous-agent. Une méthode à suivre à chaque fois va dans une skill.

Comment choisir chez soi, par exemple : une règle vraie pour chaque tâche va dans le CLAUDE.md, comme « on utilise PDO ». Une méthode utile pour certaines tâches seulement va dans une skill. Par exemple : écrire une migration SQL selon les conventions du projet, ou préparer une mise en production. La session ne porte alors que l'en-tête de la skill. Claude lit le reste le jour où vous écrivez une migration.

4MCP charge tous ses outils d'avance

Une skill se charge à la demande. MCP fait l'inverse. MCP (Model Context Protocol) est un standard qui branche Claude sur des outils externes. Ce peut être un navigateur, une base de données ou un moteur de recherche. MCP charge d'avance la description de tous ses outils. Ainsi, 58 outils consomment 55 000 tokens avant le début de la conversation (ch. 23).

Le livre mesure ce poids avec /context, une commande qui montre ce qui occupe la fenêtre. Le projet testé compte quatre serveurs MCP. Avant le moindre message, le prompt système prend 2 000 tokens. Le prompt système, ce sont les consignes de base de Claude. Les outils de base prennent 12 000 tokens, et MCP près de 20 % de la fenêtre. Presque la moitié est donc déjà prise (ch. 22).

La parade du livre : ne lancer qu'un seul fichier de configuration, ici celui de Tavily, un moteur de recherche web. L'option stricte évite de charger aussi les serveurs de la configuration utilisateur (ch. 22).

claude --mcp-config .mcp.json.tavily --strict-mcp-config

Résultat : MCP ne pèse plus qu'environ 2,4 %, et 3,2 % en désactivant deux serveurs à la main (ch. 22).

Exemple pratique : lancez /context au début d'une session et regardez la part de MCP. Un serveur MCP de base de données ne sert que dans le projet qui interroge cette base. Déclarez-le donc dans la configuration de ce projet. Dans votre configuration utilisateur, il se chargerait partout.

5Un sous-agent travaille dans sa propre fenêtre

Deuxième famille : faire le travail lourd hors de la fenêtre. Lire des dizaines de fichiers remplit la fenêtre de la conversation. Le sous-agent évite ce problème. Il a sa propre fenêtre, ses propres consignes et ses propres outils. Il revient avec une réponse condensée, par exemple 15 000 ou 20 000 tokens (ch. 39). Le livre oppose deux cas (ch. 1) :

• Un agent de revue de code : un contexte étroit.
• Un agent de recherche : un contexte large.

Un sous-agent s'écrit dans un fichier Markdown qui commence par un en-tête YAML. YAML est un format de configuration qui range les réglages par indentation. Seuls name et description sont obligatoires (ch. 37) :

---
name: code-reviewer
description: Senior code review agent. Automatically analyzes code changes for bugs,
  security flaws, and convention violations. Invoke after any code modification.
tools: Read, Grep, Glob, Bash
---
(consignes du sous-agent, en Markdown)

La ligne tools de cet en-tête applique un principe : le moindre privilège. On ne donne à un sous-agent que les outils dont sa tâche a besoin. Prenons Mermaid, un langage texte qui décrit un schéma. Un générateur de diagrammes Mermaid n'a besoin ni de la ligne de commande (Bash) ni de l'écriture de fichiers. Chaque outil en trop alourdit la fenêtre du sous-agent. Le livre parle de « pollution d'outils » (ch. 39).

Cas concret : vous reprenez un vieux projet PHP. Vous cherchez tous les appels à mysql_query, une fonction retirée de PHP 7. La recherche renvoie des centaines de lignes. Confiez-la à un sous-agent qui n'a que Read et Grep. Les centaines de lignes restent dans sa fenêtre, et il ne vous donne que la liste des fichiers à migrer.

6La description d'un sous-agent écrit sa consigne

Le sous-agent a un angle mort : il ne voit pas votre conversation. L'agent principal est le Claude avec lequel vous discutez. Il choisit un sous-agent d'après sa description, ajoutée à ses propres consignes. Le sous-agent, lui, ne reçoit que le message rédigé par l'agent principal. Le livre l'écrit : « la seule information qu'il reçoit est le prompt généré par l'agent principal » (ch. 39). Écrire la description, c'est donc écrire une partie de ce message.

Le livre en donne un exemple : le diagramme d'un système RAG. RAG est le sigle de « Retrieval-Augmented Generation », soit génération augmentée par la recherche. Avant de répondre, le modèle cherche dans une base de documents les passages utiles, puis s'appuie dessus. Le premier diagramme obtenu est touffu : on ne voit pas d'un coup d'œil comment les composants s'articulent. La correction se résume à une phrase ajoutée à la description (ch. 39).

# AVANT : description générée par Claude Code (début)
description: Use this agent when you need to convert textual descriptions,
  requirements, processes, or concepts into visual Mermaid diagrams. ...

# APRÈS : une phrase ajoutée (traduite du livre)
... L'agent principal doit toujours, toujours simplifier le concept à l'essentiel.
Il écrit aussi un petit dessin en caractères ASCII (du texte de clavier, sans image) représentant le concept pour le sous-agent.

Avec cette phrase, le message au sous-agent contient le concept simplifié. Le diagramme a moins d'étapes. C'est l'idée qui m'a le plus appris : une phrase de description change ce que le sous-agent reçoit.

Ce pouvoir de la description a un revers. Le livre met en garde : un sous-agent copié d'une source inconnue peut cacher des instructions malveillantes. Je relis donc un sous-agent avant de l'installer, comme un script.

Le livre relève un second défaut : le sous-agent ne renvoie qu'un résumé. Le code du diagramme n'apparaît qu'en dépliant sa sortie, et il faut le copier à la main. Le livre ajoute donc une étape aux consignes du sous-agent : renvoyer le diagramme lui-même, sans fioritures. Le résumé revient quand même. Le livre l'attribue à une limite actuelle de l'outil.

Chez soi : dans la description d'un sous-agent de revue de code, dites ce que l'agent principal doit lui transmettre. Par exemple : « passe toujours le diff complet et le nom des tables SQL touchées ». Le diff est la liste des lignes modifiées. Sans cette phrase, le relecteur peut ne recevoir qu'un résumé vague du changement.

7CodeMode remplace les allers-retours par un script

Retour à MCP, qui a un second coût, cette fois pendant le travail. Le livre l'appelle le « ping-pong » : chaque action fait un aller-retour complet (ch. 23).

1. Le modèle demande un outil.
2. L'outil s'exécute.
3. Le résultat s'ajoute à l'historique.
4. Tout l'historique repart vers le modèle, qui décide de la suite.

Un exemple tout simple : « cherche, résume, enregistre ». En ping-pong, cela fait trois allers-retours. Chacun renvoie tout l'historique, résultats intermédiaires compris.

CodeMode, une approche de Cloudflare, change ce mécanisme (ch. 24). Les outils deviennent des fonctions TypeScript, un langage de programmation. Le modèle les appelle depuis un script. Dans l'exemple, il écrit un script de trois lignes qui appelle les trois outils à la suite. Ce script s'exécute une seule fois.

Le script tourne dans un bac à sable. Un bac à sable est un environnement fermé, coupé d'Internet. Il n'atteint que les outils fournis. Il ne renvoie que ce que le script affiche avec console.log (ch. 25).

8Un hook s'exécute à chaque fois

Troisième famille : ce que Claude fait sur vos fichiers, hors de la fenêtre. Une consigne du CLAUDE.md entre dans la fenêtre, et Claude la lit. Un hook, lui, s'exécute. Un hook est un petit programme que Claude Code lance tout seul à un moment précis. Il peut formater le code, lancer les tests ou bloquer une édition risquée (ch. 10). Le moment se choisit parmi cinq événements :

• PreToolUse : avant qu'un outil s'exécute.
• PostToolUse : juste après.
• UserPromptSubmit : quand vous envoyez un message.
• Notification : quand Claude Code vous notifie.
• Stop : juste avant la fin de sa réponse.

L'exemple de départ est modeste : jouer un son quand Claude a fini (ch. 10, chemin du script simplifié). Le réglage s'écrit en JSON, un format de données à accolades. Il va dans un fichier de réglages du dossier .claude du projet.

{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          { "type": "command", "command": "uv run play_sound.py" }
        ]
      }
    ]
  }
}

Dans ce réglage, uv run lance simplement le script Python play_sound.py. Le matcher vide veut dire « pour tous les événements de ce type ». Or un hook tourne souvent. Le livre conseille donc une commande système légère plutôt qu'un script Python (ch. 10). Par exemple, afplay sous macOS et aplay sous Linux jouent un son.

Sur un projet PHP : un hook PostToolUse peut lancer php -l après chaque modification d'un fichier PHP. Cette commande contrôle la syntaxe. Une erreur remonte aussitôt à Claude, sans attendre que quelqu'un ouvre la page. Côté JavaScript, le même hook peut lancer votre formateur sur le fichier modifié.

9Le retour en arrière ne défait pas les commandes

Un hook agit au moment de l'action. Le retour en arrière, lui, défait une action après coup, mais pas toutes. Avant chaque prompt qui change des fichiers, Claude Code crée un point de contrôle. Il le garde jusqu'à 30 jours (ch. 13). On y revient avec /rewind ou en appuyant deux fois sur Échap. La chronologie des prompts s'ouvre alors, avec trois choix :

• Restaurer le code et la conversation.
• Restaurer la conversation seule, fichiers intacts.
• Restaurer le code seul, conversation conservée.

Dans la démonstration, l'auteur restaure le code seul. Puis il demande « fais-en un minimaliste » (ch. 13). Le livre pose ensuite les limites. Les commandes de terminal lancées par Claude Code ne sont pas suivies. Les modifications faites à la main non plus. Le retour en arrière ne remplace pas Git : c'est un « annuler » local et de courte durée.

10Paralléliser seulement ce qui est indépendant

Dernière question sur ce que Claude fait : peut-on en lancer plusieurs à la fois ? Oui. Le livre lance plusieurs Claude Code sur le même projet, comme des développeurs sur la même branche (ch. 34). Chacun prend sa tâche. Cela marche quand les tâches sont indépendantes, par exemple deux bugs sans rapport.

Le contre-exemple du livre : une route backend et la page qui l'appelle, confiées à deux Claude en même temps. L'agent frontend appelle une API qui n'existe pas encore. Il invente alors des données factices (ch. 34).

Le livre juge ce montage fragile, et cite la parade des équipes : donner à chaque agent son propre espace de travail. Avec Git, c'est une branche par agent, ou un worktree. Un worktree est un second dossier de travail du même dépôt, sur sa propre branche. Les agents ne touchent plus aux mêmes fichiers, et on fusionne ensuite.

Le livre décrit aussi une variante qui coûte cher en tokens (ch. 40). Plusieurs sous-agents implémentent la même fonctionnalité, et on garde la meilleure version.

Comment choisir : demandez-vous si une tâche attend le résultat de l'autre. Corriger le formulaire de contact et l'export CSV des commandes ? Rien ne les relie, deux Claude peuvent avancer en même temps. Une route PHP qui renvoie du JSON, et la page JavaScript qui la lit avec fetch ? La page dépend de la route. Faites d'abord la route, puis la page.