The constraint behind everything

Si vous ne devez retenir qu'un concept de tout ce chapitre, que ce soit celui-ci. La context window est la ressource la plus importante de Claude, et celle que la plupart des gens ignorent jusqu'à ce qu'il soit trop tard.

Ce que la context window est réellement

La context window est la mémoire de travail de Claude. Tout ce que Claude sait sur votre session actuelle vit dans ce buffer : le system prompt, votre CLAUDE.md, chaque fichier qu'il a lu, chaque commande qu'il a lancée, chaque message que vous avez envoyé, chaque réponse qu'il a générée, et tout son raisonnement interne.

La context window par défaut est de 200 000 tokens. Vous pouvez opter pour 1 million de tokens en ajoutant le suffixe [1m] à votre modèle dans les réglages, par exemple "model": "claude-opus-4-6[1m]". Si vous avez suivi le setup de la Leçon 2, vous l'avez déjà. Quoi qu'il en soit, le budget part plus vite que vous ne le pensez.

Voyez la context window comme de la RAM, pas du stockage. Tout ce qui est dedans est actif, disponible, et consomme de l'espace. Il n'y a pas de « disque » sur lequel swapper, pas de moyen de pager les choses in et out. Quand la fenêtre se remplit, quelque chose doit partir.

Ce qui consomme du contexte

Ce qui remplit votre context window dans une session typique, à peu près dans l'ordre du coût :

Chargé au démarrage de la session (avant que vous ne tapiez quoi que ce soit) :

• System prompt et descriptions d'outils intégrés
• Votre fichier CLAUDE.md (et tous les fichiers CLAUDE.md au niveau projet)
• Descriptions de skills (chaque skill installée ajoute un résumé, même si elle n'est pas utilisée activement)
• Descriptions d'outils des MCP servers (chaque serveur connecté ajoute sa liste d'outils)
• Contexte initial de session

C'est pourquoi la mise en garde « n'installez pas tout » de la Leçon 2 compte ici. Chaque skill et chaque MCP server coûte des tokens juste en étant connecté, avant que vous ne tapiez un seul message. Lancez /context pour voir exactement ce qui est chargé et combien d'espace ça prend. Vous pourriez être surpris de combien de votre budget est déjà promis.

Accumulé pendant la session :

• Chaque fichier que Claude lit (contenu complet de chaque fichier)
• Chaque sortie de commande Bash (logs de build, résultats de tests, git diffs)
• Chaque message que vous envoyez
• Chaque réponse que Claude génère
• Extended thinking (tokens de raisonnement interne, ils comptent)
• Résultats de web search et fetch

CLAUDE.md (well-structured)     ~800-1500 tokens
Plugin tool descriptions        ~2000-4000 tokens
Reading a 200-line file         ~1000-1500 tokens
Reading a 500-line file         ~3000-4000 tokens
Build output (success)          ~200-500 tokens
Build output (failure + errors) ~1000-3000 tokens
A typical Claude response       ~500-2000 tokens
Extended thinking per turn      ~2000-10000 tokens

Additionnez tout ça. Dix lectures de fichiers, cinq commandes bash, quelques allers-retours de messages, et vous êtes à 50 000-80 000 tokens. C'est un quart de votre budget, et vous n'êtes peut-être même pas à la moitié de la tâche.

Ce qui se passe quand elle se remplit

Quand la context window approche de la capacité, Claude Code déclenche l'auto-compaction. C'est une étape de résumé, pas un crash ni une erreur. Claude prend les parties les plus anciennes de la conversation et les compresse en un résumé, libérant de l'espace pour le nouveau travail.

Le problème, c'est que les résumés perdent du détail. La signature de cette fonction que Claude a lue il y a 20 minutes ? Après compaction, il peut se souvenir « lu une fonction liée à l'authentification » mais pas les types de paramètres exacts. Cette erreur de build de tout à l'heure ? Résumée en « il y avait une erreur de type qui a été corrigée ».

Vous l'avez vu vous-même même si vous n'en connaissiez pas la cause. Claude fonctionne génial pendant les 15 premières minutes, puis commence à faire de petites erreurs : utiliser le mauvais nom de variable, oublier un pattern qu'il suivait plus tôt, suggérer une approche qu'il avait déjà essayée et rejetée. Dégradation du contexte.

C'est pourquoi le /compact des quick wins compte, et pourquoi le /clear entre les tâches compte encore plus. Vous n'êtes pas juste « en train de nettoyer ». Vous protégez la qualité du raisonnement de Claude.

L'effet cascade

La gestion du contexte compte parce que chaque décision compose.

Un setup bloaté (trop de plugins chargés, un CLAUDE.md trop long) signifie moins de place pour les lectures de fichiers. Moins de lectures de fichiers signifie que Claude rassemble moins de contexte sur votre codebase. Moins de contexte signifie de pires décisions. De pires décisions signifient plus d'échecs de vérification. Plus d'échecs signifient plus d'itérations de boucle. Plus d'itérations consomment plus de contexte. La fenêtre se remplit plus vite. La compaction arrive plus tôt. L'information est perdue. La qualité chute encore plus.

Pourquoi les quick wins ne suffisent pas

Dans la leçon précédente, vous avez appris huit choses que vous pouvez faire aujourd'hui pour améliorer vos résultats. Chacune aide. Mais il y a une différence entre connaître les astuces et comprendre le système.

Savoir utiliser /compact est un quick win. Savoir quand compacter (après la recherche mais avant l'implémentation, après une approche qui a échoué, aux points de rupture naturels du workflow) c'est de la méthodologie. Compacter au mauvais moment peut perdre du contexte dont vous avez encore besoin.

Savoir utiliser le Plan Mode est un quick win. Savoir comment écrire des specs qui rendent le Plan Mode fiable (avec des critères d'acceptation, des contraintes, et le bon niveau de détail) c'est de la méthodologie. Le Plan Mode avec un prompt vague produit un plan vague.

Savoir donner des critères de vérification est un quick win. Bâtir un pipeline de vérification qui tourne automatiquement après chaque changement (build, types, lint, tests, security checks) c'est de la méthodologie. Vous arrêtez de vous souvenir de vérifier et commencez à bâtir des systèmes qui vérifient pour vous.

Les Chapitres 2 à 7 vous donnent chacun un levier différent pour gérer cette ressource. Ensemble ils forment un système.

La carte du cours

Chaque chapitre qui suit enseigne des techniques qui sont, à leur cœur, des stratégies de gestion de contexte :

• Chapitre 2, CLAUDE.md : Pré-charger la bonne information pour que Claude n'ait pas à la chercher. Les règles, les limites, et les patterns de votre projet chargés une fois, utilisés à chaque session.
• Chapitre 3, L'humain dans la boucle : Donner à Claude une intention structurée pour qu'il rassemble le bon contexte et agisse avec précision. Specs, Plan Mode, corrections de tir.
• Chapitre 4, Gestion du budget de contexte : Charger la connaissance spécialisée seulement quand il le faut. Isoler les tâches de recherche coûteuses. Router vers le bon modèle pour le travail.
• Chapitre 5, La boucle de feedback : Capturer la friction au moment où elle arrive, router les corrections au bon endroit, et bâtir des hooks qui appliquent les règles à coût de contexte zéro. Votre setup devient plus intelligent à chaque session.
• Chapitre 6, Passer à l'échelle : Faire tourner plusieurs sessions Claude en parallèle avec des worktrees, scripter Claude pour des pipelines automatisés, utiliser le pattern writer/reviewer pour une qualité non biaisée, et configurer les permissions pour une autonomie sûre.
• Chapitre 7, Bâtissez votre blueprint : Câblez tout ça ensemble dans votre propre système. Pas celui de quelqu'un d'autre. Le vôtre.

Toutes répondent à la même question : comment tirer le plus de valeur de notre budget de contexte ?

Le système commence ici

Le Chapitre 1 vous a donné la carte. Vous comprenez la machine (Leçon 1), vous avez les quick wins (Leçon 2), vous avez vu ce que la context window de 1M change et ne change pas (Leçon 3), et vous comprenez la ressource que chaque technique de ce cours est conçue pour protéger (cette leçon).

Ce que vous n'avez pas encore, c'est le système.

Les développeurs qui finissent ce cours n'écrivent pas de meilleurs prompts. Ils bâtissent de meilleurs systèmes. Ils ont des fichiers CLAUDE.md qui pré-chargent le bon contexte. Des skills qui chargent la connaissance de domaine à la demande. Des hooks qui appliquent les règles sans consommer un seul token. Des subagents qui font de la recherche en isolation. Des pipelines de vérification qui attrapent les erreurs automatiquement.

Et le système commence avec un fichier : CLAUDE.md.

Le Chapitre 2 commence là où chaque session commence : avec votre codebase.