Chapitre 1.3 — Anatomie d’une session

⏱️ TL;DR — Une session, c’est une fenêtre de contexte que l’agent remplit au fur et à mesure : instructions du harness, ton CLAUDE.md, ta demande, les fichiers lus, les sorties de commandes, son raisonnement. Cette fenêtre est finie et périssable. Comprendre ce qui la remplit — et ce qui la pollue — est la compétence qui sépare une session nette d’une session qui « part en vrille ». On voit aussi le système de permissions (ce que l’agent a le droit de faire) et le plan mode (réfléchir avant d’agir).

🎯 Objectifs

• Lister ce qui compose le contexte d’une session et dans quel ordre de priorité.
• Identifier ce qui remplit et ce qui pollue le contexte.
• Comprendre les modes de permission et pourquoi ils existent.
• Savoir ce qu’est le plan mode et quand l’utiliser.

Ce qu’il y a dans le contexte

Quand l’agent « réfléchit », il ne voit pas ton disque dur : il voit une pile de texte, sa fenêtre de contexte. En gros, dans l’ordre :

Points clés :

1. Les instructions du harness et ton CLAUDE.md sont là dès le départ, en permanence. C’est pour ça que le CLAUDE.md est si puissant : il est toujours présent (à la différence d’une skill, chargée à la demande — voir 1.4).
2. Ta demande oriente la boucle.
3. Tout ce que l’agent lit et exécute s’accumule. Lire un fichier de 800 lignes, c’est 800 lignes dans le contexte. Lancer une commande verbeuse, c’est sa sortie entière dans le contexte.

⚠️ Piège — Le contexte se remplit silencieusement. Une commande npm run build qui crache 500 lignes de logs, un gros fichier lu « pour voir », un long copier-coller : tout ça s’entasse. Au bout d’un moment, l’agent « oublie » le début (le plus vieux se fait résumer/évincer) et sa qualité baisse. Un contexte propre = un agent net.

Contexte : le nourrir vs le polluer

La bonne nouvelle : quand une session se charge trop, Claude Code compacte automatiquement (il résume le passé pour continuer). Et tu peux reprendre la main avec /clear (repartir propre) ou en isolant une sous-tâche dans un subagent (qui a son propre contexte — Partie 8). On outillera tout ça en Partie 5.

💡 Réflexe d’architecte — Traite le contexte comme un budget d’attention. Avant de lancer une commande très verbeuse ou de faire lire un énorme fichier, demande-toi : ai-je besoin de tout ça, ou d’un extrait ? Un agent avec un contexte ciblé raisonne mieux qu’un agent noyé.

Les permissions : ce que l’agent a le droit de faire

L’agent peut exécuter des commandes et modifier des fichiers — donc la question « qu’est-ce qu’il a le droit de faire sans me demander ? » est centrale. Claude Code encadre ça par des modes de permission :

• Demander (par défaut) : l’agent demande confirmation avant les actions sensibles (exécuter une commande, écrire un fichier selon la config).
• Accepter les éditions : il applique ses modifications de fichiers sans confirmation à chaque fois, mais reste prudent sur le reste.
• Plan : il ne modifie rien, il conçoit un plan (voir plus bas).
• Autonomie élargie : moins d’interruptions, à réserver aux contextes où tu fais confiance et où le risque est faible.

Tu affines aussi via des règles de permission (autoriser tel type de commande, refuser tel autre) dans settings.json — on y reviendra (P7, P10, Annexes). L’idée à retenir maintenant : plus tu es en confiance et outillé (hooks, tests, git), plus tu peux élargir l’autonomie sans risque.

⚠️ Piège — Tout autoriser dès le premier jour « pour ne pas être dérangé ». Mauvais calcul : sans garde-fous (tests, hooks, commits fréquents), une autonomie large sur un projet fragile = des dégâts silencieux. L’autonomie se gagne en installant le filet de sécurité d’abord (Parties 7 et 11).

Le plan mode : réfléchir avant d’agir

Le plan mode est un mode où l’agent conçoit un plan sans rien modifier, te le présente, et n’exécute qu’après ta validation. C’est l’outil anti-« il a foncé dans la mauvaise direction ».

Tu l’utilises quand :

• la tâche est ambiguë ou a plusieurs approches possibles ;
• elle touche à beaucoup de fichiers ou à de l’architecture ;
• tu veux cadrer avant de laisser l’agent écrire (le cœur de la Partie 2).

🧭 Sur TaskFlow — On ouvrira TaskFlow en plan mode : avant d’écrire la moindre ligne, l’agent proposera une structure (routes, modèle de données, découpage des composants). On la corrigera à ce moment-là — c’est mille fois moins cher que de corriger 30 fichiers déjà écrits.

✏️ Exercices

Exercice 1 — Repère la pollution. Pendant une session réelle, après quelques échanges, demande à l’agent : « Résume ce que tu as en contexte actuellement et ce qui te semble superflu. » Observe ce qui s’est accumulé.

Exercice 2 — Plan d’abord. Prends une tâche moyenne (« ajoute l’export CSV des tâches ») et lance-la en plan mode. Lis le plan : y a-t-il une décision que tu n’aurais pas prise ? Corrige-la avant l’exécution.

🧠 Quiz de révision

Chapitre suivant : La carte des briques — CLAUDE.md, skills, subagents, hooks, MCP, plugins : qui fait quoi, et quand.