Gestion de la fenêtre de contexte : ce que 50 sessions m'ont appris sur le développement IA

J’ai mesuré la consommation de tokens sur 50 sessions de développement avec Claude Code. Le constat était systématique : la qualité des résultats se dégrade aux alentours de 60 % d’utilisation du contexte, bien avant que la limite dure ne déclenche la compaction.¹

TL;DR

L’épuisement de la fenêtre de contexte dégrade silencieusement la qualité du code généré par l’IA. Après avoir suivi 50 sessions de construction de mon infrastructure Claude Code et de mon système de qualité pour le blog, j’ai identifié trois stratégies qui maintiennent la qualité des résultats sur des sessions de plusieurs heures : la compaction proactive après chaque sous-tâche, la mémoire basée sur le système de fichiers qui persiste au-delà des limites de contexte, et la délégation à des sous-agents qui maintient le contexte principal allégé. L’insight clé : traitez la fenêtre de contexte comme une ressource rare, pas comme un fil de conversation sans fond.

À quoi ressemble réellement la dégradation

Chaque lecture de fichier, chaque sortie d’outil et chaque tour de conversation consomme des tokens. Une seule lecture de fichier volumineux (2 000 lignes) peut consommer 15 000 à 20 000 tokens. Après avoir lu 10 fichiers et exécuté plusieurs commandes, la fenêtre de contexte contient davantage de sorties d’outils que d’instructions réelles.²

La dégradation est subtile. Claude n’annonce pas « mon contexte est rempli à 80 % ». Au lieu de cela, le modèle commence à : - Oublier des instructions établies 20 minutes plus tôt - Répéter des suggestions déjà rejetées trois tours auparavant - Manquer des patterns établis plus tôt dans la conversation - Produire des modifications multi-fichiers moins cohérentes

J’ai remarqué ce phénomène en construisant mon système de délibération. Une session qui avait commencé avec des modifications multi-fichiers précises sur 8 modules Python s’est dégradée en une vision tunnel sur un seul fichier au bout de 90 minutes. L’agent avait cessé de référencer l’architecture qu’il avait lue plus tôt, car ce contexte avait été compressé et éliminé.

Stratégie 1 : compaction proactive

La commande /compact de Claude Code résume la conversation et libère de l’espace contextuel. Le système préserve les décisions clés, le contenu des fichiers et l’état de la tâche tout en éliminant les sorties d’outils verbeuses.³

Quand compacter : - Après avoir terminé une sous-tâche distincte (fonctionnalité implémentée, bug corrigé) - Avant de commencer à travailler sur une nouvelle zone du codebase - Lorsque Claude commence à se répéter ou à oublier le contexte antérieur

Je compacte environ toutes les 25-30 minutes lors de sessions intensives. Pendant la construction de l’infrastructure de délibération (9 PRDs, 3 455 lignes de Python), j’ai compacté après chaque PRD terminé. Chaque compaction préservait les décisions architecturales tout en libérant du contexte pour la phase d’implémentation suivante.

Stratégie 2 : le système de fichiers comme mémoire

La mémoire la plus fiable au-delà des limites de contexte réside dans le système de fichiers. Claude Code lit CLAUDE.md et les fichiers mémoire au début de chaque session et après chaque compaction.⁴

Mon répertoire .claude/ sert de palais mental structuré :

~/.claude/
├── configs/           # 14 JSON configs (thresholds, rules, budgets)
│   ├── deliberation-config.json
│   ├── recursion-limits.json
│   └── consensus-profiles.json
├── hooks/             # 95 lifecycle event handlers
├── skills/            # 44 reusable knowledge modules
├── state/             # Runtime state (recursion depth, agent lineage)
├── handoffs/          # 49 multi-session context documents
├── docs/              # 40+ system documentation files
└── projects/          # Per-project memory directories
    └── {project}/memory/
        └── MEMORY.md  # Always loaded into context

Le fichier MEMORY.md capture les erreurs, les décisions et les patterns à travers les sessions. Il contient actuellement 54 échecs documentés avec des patterns d’apprentissage inter-domaines. Quand je découvre que ((VAR++)) échoue avec set -e en bash lorsque VAR vaut 0, je l’enregistre. Trois sessions plus tard, lorsque je rencontre un cas limite similaire avec les entiers en Python, l’entrée dans MEMORY.md fait remonter le pattern.⁵

L’effet composé inter-domaines : une erreur d’échappement bash provenant du développement de hooks a conduit à une amélioration des regex dans mon linter Python pour le blog. Un écart dans les tokens CSS (--spacing-2xs n’existe pas) a déclenché un audit systématique de toutes les références aux propriétés personnalisées. Chaque entrée connecte des domaines qui resteraient autrement cloisonnés dans les contextes de sessions individuelles.

Stratégie 3 : passation de relais entre sessions

Pour les tâches s’étalant sur plusieurs sessions, je crée des documents de passation qui capturent l’état complet :

## Handoff: Deliberation Infrastructure PRD-7
**Status:** Hook wiring complete, 81 Python unit tests passing
**Files changed:** hooks/post-deliberation.sh, hooks/deliberation-pride-check.sh
**Decision:** Placed post-deliberation in PostToolUse:Task, pride-check in Stop
**Blocked:** Spawn budget model needs inheritance instead of depth increment
**Next:** PRD-8 integration tests in tests/test_deliberation_lib.py

Mon répertoire ~/.claude/handoffs/ contient 49 documents de passation issus de tâches multi-sessions. Démarrer une nouvelle session avec claude -c (continuer) ou lire le document de passation fournit à la session suivante un contexte complet pour un coût minimal en tokens.⁶

Ce pattern de passation m’a sauvé pendant la construction du système de délibération. Le PRD-4 (extensions du garde-fou de récursion) nécessitait de comprendre les décisions des PRDs 1 à 3. Sans la passation, la nouvelle session aurait dû relire tous les fichiers modifiés. Avec la passation, la session a démarré avec le contexte architectural et est passée directement à l’implémentation.

Stratégie 4 : délégation aux sous-agents

Les sous-agents s’exécutent dans des fenêtres de contexte indépendantes. Déléguer les tâches de recherche ou de revue à des sous-agents préserve le contexte de la session principale pour le travail d’implémentation.⁷

Mon système de garde-fou de récursion gère cela automatiquement :

# From recursion-guard.sh - spawn budget enforcement
MAX_DEPTH=2
MAX_CHILDREN=5
DELIB_SPAWN_BUDGET=2
DELIB_MAX_AGENTS=12

Chaque sous-agent renvoie un résumé plutôt que la sortie brute, ce qui maintient le contexte principal allégé. Pendant les réécritures d’articles de blog, je délègue les tâches d’exploration (collecte de données CSS, lecture de code de hooks, inventaire des structures de répertoires) aux sous-agents. Le contexte principal reste concentré sur l’écriture tandis que les sous-agents gèrent la recherche.

Le budget de spawn a été appris à la dure : une session sans limites a engendré des sous-agents récursifs qui ont chacun engendré d’autres sous-agents. Le hook recursion-guard impose désormais des limites de profondeur avec une validation sécurisée des entiers et des budgets pilotés par la configuration.⁸

Les anti-patterns que j’ai appris à mes dépens

Lire des fichiers entiers quand vous n’avez besoin que de 10 lignes. Au début de mon utilisation de Claude Code, je lisais des fichiers entiers de 2 000 lignes pour une seule fonction. Utilisez les décalages de lignes : Read file.py offset=100 limit=20 économise plus de 15 000 tokens par lecture.

Conserver les sorties d’erreurs verbeuses dans le contexte. Après avoir débogué le problème de budget de spawn, mon contexte contenait plus de 40 stack traces des itérations échouées. Un seul /compact après la correction du bug a libéré ce poids mort.

Commencer chaque session en lisant tous les fichiers. Mes premières sessions pré-chargeaient 8 à 10 fichiers « pour le contexte ». Maintenant, je laisse les outils glob et grep de Claude Code trouver les fichiers pertinents à la demande, économisant plus de 100 000 tokens de pré-chargement inutile.

Points clés à retenir

Pour les développeurs individuels : - Compactez après chaque sous-tâche terminée, pas lorsque Claude force la compaction ; une compaction proactive toutes les 25-30 minutes maintient la qualité des résultats - Écrivez les décisions clés dans des fichiers mémoire du système de fichiers au fil de la session ; mon MEMORY.md contient 54 entrées qui persistent à travers des centaines de sessions - Utilisez des sous-agents pour les tâches de recherche qui pollueraient le contexte principal ; une requête de recherche sur 5 fichiers coûte plus de 75 000 tokens dans le contexte principal, mais seulement un résumé de 500 tokens via un sous-agent

Pour les équipes : - Standardisez le format des documents de passation pour les tâches multi-sessions ; chacune de mes 49 passations suit la même structure Statut/Fichiers/Décision/Bloqué/Suivant - Configurez des fichiers CLAUDE.md au niveau du projet avec le contexte architectural qui se charge automatiquement dans chaque session

Références