J'ai Arrêté de Gérer Ma Fenêtre de Contexte. J'ai Commencé à Concevoir Avec.
L'épiphanie n'est pas venue en lisant un changelog. Elle m'a frappé en pleine session, trois agents dans un refactoring, thread principal à peine à 30%. Pas de /compact. Pas de redémarrage. Juste... propre.
Six semaines plus tôt, j'étais comme tout le monde. Dégradation du contexte à 60%, réponses floues, Claude qui oublie le fichier qu'il vient de lire. Le genre de situation où on a envie de frapper quelque chose (mais on ne peut pas frapper une IA, alors on fixe l'écran en respirant fort).
Puis /insights a posé le diagnostic que je n'avais jamais demandé : 219 événements de chevauchement en 28 jours. Je faisais du multi-clauding sans le savoir.
Mars 2026 fut un festival d'outils. Subagents matures, Agent Teams, context: fork. Cet article n'est pas un tour des fonctionnalités. C'est comment mon modèle mental a changé, et le framework de décision que j'utilise maintenant pour décider si je lance un agent, deux, ou cinq.
TLDR : La fenêtre de contexte est passée d'une ressource qu'on préserve à un matériau qu'on distribue. Les subagents, context: fork, et Agent Teams permettent d'isoler les contextes au lieu de lutter contre la dégradation dans une seule session. Le framework : agent unique si la portée est cohérente et le contexte sous 40%, subagent si l'exploration polluerait le principal, Agent Team si les sous-tâches sont indépendantes mais bénéficient de coordination. Testez-le sur votre prochain refactoring qui nécessite habituellement trois redémarrages.
Trois Agents, Un Refactoring, Zéro Compactage
Le refactoring était une synchronisation de produits WooCommerce qui accumulait la dette technique depuis six mois. Le genre de codebase où chaque fichier a un commentaire "correction temporaire" de janvier.
Trois agents, chacun dans son propre contexte. Un sur la couche API (douze endpoints, validation, chemins d'erreur). Un qui réécrit la logique de transformation devenue spaghetti à cause de six mois de "ajoute juste une condition". Un qui audite la suite de tests pour comprendre quels tests testent vraiment quelque chose versus ceux qui sont juste... là. Des tests à l'intuition.
Thread principal à 30%, qui coordonne, sans faire le gros du travail. Aucun moment où Claude commence à répondre aux questions sur des fichiers qu'il a lus il y a quarante minutes avec la confiance de quelqu'un qui n'a définitivement pas lu ce fichier. (Vous connaissez cette expression. L'expression confiante mais fausse.)
Le même refactoring, deux mois plus tôt : session unique, le contexte se remplit au deuxième endpoint, les réponses deviennent floues vers le fichier sept, je redémarre, ré-explique toute la mise en place, perds vingt minutes, redémarre encore. Au troisième redémarrage je ne refactorise plus. Je garde Claude en vie artificielle.
Cette fois, deux heures. Résumés propres de chaque agent. Merge, test, push.
Je ne gérais plus une fenêtre. Je concevais un système de contextes.
Le Diagnostic Que Je N'Avais Pas Demandé
J'ai lancé /insights sur mon usage de Claude Code. 374 sessions. 219 événements de chevauchement multi-Claude en 28 jours. Pas parce que j'étais malin. Parce que j'ouvrais de nouvelles sessions quand l'ancienne se dégradait, sans la fermer. Du multi-clauding accidentel, la raison derrière les mauvaises habitudes.
Le nombre de chevauchements était un symptôme. La maladie était en dessous : je traitais le contexte comme une ressource rare. Chaque /compact était un petit aveu que la session se dégradait. Chaque redémarrage était un plus gros aveu. Et chaque fois que j'ouvrais un deuxième terminal "juste pour vérifier un truc vite fait", mon workflow essayait de distribuer le contexte avant que j'aie les outils pour le faire exprès.
La dégradation du contexte était le symptôme. Traiter le contexte comme une contrainte était la maladie.
Faire du multi-clauding par accident n'est pas un signe d'incompétence. C'est un signal que le workflow a dépassé le modèle à session unique. Si vos /insights montrent des chevauchements, vous y êtes probablement aussi.
Le Contexte a Cessé d'Être une Contrainte. Il Est Devenu un Matériau de Construction.
Le résultat d'abord.
En mars 2026, quatre choses ont été livrées en même temps : la fenêtre de contexte de 1M tokens, les types de subagents matures (Explore, Plan, General purpose), context: fork comme fonctionnalité de première classe dans les skills personnalisés, et Agent Teams comme mode multi-agent expérimental. Chacun utile seul. Ensemble, ils ont changé ce qu'est une fenêtre de contexte.
Pas une boîte qui se remplit. Un matériau qu'on distribue.
Pensez au passage du monolithe aux microservices. Pas la version hype avec douze services et un bus de messages pour une app todo. La vraie version : vous avez arrêté d'essayer d'économiser la RAM dans un gros processus et avez commencé à concevoir des frontières d'isolation. Chaque service a sa propre mémoire. L'orchestrateur reste léger. La communication se fait par des interfaces définies, pas par un état partagé. Même changement, appliqué au contexte. Chaque subagent a une fenêtre fraîche de 200K. Le thread principal reste léger. Les résultats reviennent sous forme de résumés, pas de saignée brute.
La communauté de praticiens converge sur des chiffres similaires. "Diviser par contexte, pas par rôle" continue de ressortir comme pattern. Le contexte principal reste autour de 30-40% pour les gens qui ont fait le changement. Lydia Hallie de l'équipe Claude Code présente context: fork comme une fonctionnalité de conception, pas un contournement. Simon Willison a formalisé les patterns de subagents dans ses écrits sur l'ingénierie agentique.
Pourquoi maintenant ? Ces patterns ne sont pas nouveaux (Docker n'a pas inventé les conteneurs). Mais la convergence de mars les a rendus accessibles à n'importe quel dev solo sur un plan Max. Avant mars, distribuer le contexte signifiait lutter contre les outils. Après, les outils s'y attendent.
Attention : l'analogie microservices se casse vite si vous la poussez. Pas de découverte de services entre agents. Pas de "context mesh". Agent Teams est expérimental, pas un runtime distribué mature. Le modèle mental aide. L'analogie est un point de départ, pas une destination.
Même modèle, mêmes tokens. Relation complètement différente.
La théorie est propre. En pratique, la question de chaque session se résume à quelque chose de brutalement simple : est-ce que je lance un agent, deux, ou cinq ?
Le Framework de Décision Que J'Utilise Vraiment
Tâche arrive
├── Portée cohérente, fichiers liés, contexte < 40%
│ └── Agent unique. Préfixe scope-lock. Terminé.
├── Exploration lourde (> 3 fichiers non liés à lire), résultat = résumé
│ └── Subagent / context: fork. Il explore, vous restez propre.
└── Sous-tâches indépendantes + bénéfice de coordination
└── Agent Team. Mais : si les agents doivent constamment
lire la sortie des autres → retour à agent unique.
Trois régimes. Les frontières comptent plus que les catégories.
Agent unique reste le bon choix pour la plupart des tâches. Un ajout de fonctionnalité touchant trois fichiers liés. Une correction de bug où la portée est évidente. Si le contexte rentre confortablement et que les fichiers sont liés, spawner un subagent ajoute de la complexité pour zéro bénéfice. Un préfixe scope-lock dans votre prompt fait le travail : "Vous travaillez sur X. Ne touchez que les fichiers Y et Z. N'explorez pas au-delà de cette portée."
Subagents sont pour quand l'exploration empoisonnerait votre contexte principal. Le déclencheur sur lequel j'ai atterri : si je dois lire plus de trois fichiers non liés pour répondre à une question, c'est un spawn. La semaine dernière, un subagent explorant le flux d'auth d'une API partenaire a lu quatorze fichiers dans trois repos, retourné un résumé de six lignes. Mon contexte principal n'a pas bougé. La même exploration dans une session unique aurait mangé 35-40% de la fenêtre avec des contenus de fichiers que je ne regarderais plus jamais.
Agent Teams sont pour quand les sous-tâches sont indépendantes mais le résultat global bénéficie d'une exécution parallèle. Le refactoring de la section une. Une session de débogage avec trois hypothèses explorées simultanément. Le test critique : si les agents doivent constamment lire la sortie des autres pour procéder, vous n'avez pas de sous-tâches indépendantes. Vous avez une tâche unique qui porte un imperméable en prétendant être trois. Retournez à agent unique.
La structure de prompt que j'utilise pour lancer un Agent Team :
"Trois agents parallèles. Chaque agent a UNE portée :
- Agent 1 : [portée]. Livrer : [sortie spécifique].
- Agent 2 : [portée]. Livrer : [sortie spécifique].
- Agent 3 : [portée]. Livrer : [sortie spécifique].
Aucun agent ne lit les fichiers d'un autre agent. Le merge final est le mien."
Chaque agent reçoit une portée, des contraintes, et un livrable attendu. Si vous reconnaissez le pattern, c'est parce que les frontières de contexte fonctionnent comme les contrats de prompt appliqués à l'architecture multi-contexte. Même discipline. Portée, contraintes, livrable. Sauf que maintenant vous écrivez le contrat pour un contexte isolé, pas une session unique.
Ce framework est calibré sur un usage solo/indie. Dans une équipe de quatre devs, la dynamique change (conflits git, permissions, coordination humaine empilée sur la coordination d'agents). Je n'ai pas encore stress-testé Agent Teams en équipe. En solo, ça tient.
La règle : si vous ne pouvez pas écrire le contrat du subagent en deux phrases, il n'a pas besoin d'exister.
La Facture de Tokens Dont Personne Ne Veut Parler
Distribuer le contexte coûte plus de tokens. C'est la partie honnête, et prétendre le contraire serait malhonnête.
Agent Teams consomme 4-7x les tokens d'une session unique faisant le même travail. Les subagents en parallèle sur un plan Pro atteignent la limite de taux en environ vingt minutes. Le plan Max à $100-200/mois est le plancher réaliste pour ce workflow.
Maintenant la partie que personne ne calcule.
Le prompt caching change les maths. Sur les sessions lourdes, 90%+ des tokens sont des lectures de cache à $0.50 par million de tokens pour Opus. Le multiplicateur est réel, mais c'est un multiplicateur sur une base qui est dramatiquement moins chère que le prix affiché. Ma facture mensuelle a augmenté peut-être de 40% après être passé au multi-contexte. Pas 400%. La couche de prompt caching est ce qui fait que toute l'économie multi-contexte fonctionne vraiment.
Mais oubliez la facture de tokens une seconde. Karen de la Compta me tuerait de dire ça, mais la facture de tokens c'est le mauvais tableur.
Le vrai coût de la dégradation du contexte : les vingt minutes à ré-expliquer le contexte après un redémarrage. Le bug que vous livrez parce que la réponse de Claude était basée sur un fichier dont il se souvenait à moitié. Le troisième redémarrage où vous abandonnez le refactoring et le faites à la main. Ce coût n'apparaît sur aucune facture. Il apparaît sur votre vendredi après-midi, celui que vous étiez censé passer à la piscine avec les enfants, à déboguer une session qui a pourri à 65%.
Le multi-contexte élimine le coût invisible. La facture de tokens monte. Le coût total descend.
Ces chiffres sont pour le plan Max avec le prompt caching d'Opus. Sur Pro, le ratio change drastiquement. Sur API directe sans caching, le multi-contexte peut devenir prohibitif. Ne copiez pas mes chiffres sur votre tier.
Ce Qui Change Quand Tout le Monde Pense Comme Ça
Le signal le plus clair que ce changement est réel n'est pas dans les fonctionnalités. C'est que les praticiens qui ont fait le switch ne reviennent pas en arrière. "Diviser par contexte, pas par rôle" devient un réflexe, pas un conseil. Les gens qui font du multi-contexte quotidiennement ne l'évangélisent pas. Ils le font juste, comme personne ne parle plus d'utiliser git. On utilise git, c'est tout.
Les outils suivent. Agent Teams est expérimental aujourd'hui mais la direction est fixée. La persistance de contexte entre sessions livre déjà (auto-memory, /resume). Il y a 100+ configs de subagents communautaires sur GitHub qui construisent sur le pattern avant même qu'il ait un nom officiel.
La plupart des devs utilisent encore Claude Code comme un monolithe avec une grosse fenêtre. Et ça marche. Mais certaines tâches méritent plus. Et savoir lesquelles, c'est tout l'intérêt. 🤷
Il y a deux mois on luttait contre la dégradation du contexte. Redémarrage, compactage, clear, optimisation des MCP, élagage des skills... en priant que Claude se souvienne de la ligne 42.
Aujourd'hui mes fichiers CLAUDE.md sont une autre bête. Plus de listes "ne fais pas X". Des déclarations de portée pour chaque contexte. Mes skills ont context: fork par défaut. La structure de projet reflète la distribution de contexte, pas l'inverse.
Le changement n'était pas technique. Les outils existaient déjà en morceaux. Le modèle mental a bougé : arrêter de protéger une session unique, commencer à architecturer des contextes isolés. Tout le reste a suivi.
Un agent suffit pour la plupart des tâches. Mais savoir quand ce n'est pas suffisant, et forker au bon moment au lieu de s'accrocher à une session qui pourrit, c'est la différence entre utiliser Claude Code et le comprendre.
Sources
Simon Willison, "Agentic Engineering Patterns" (simonwillison.net). Lydia Hallie (Anthropic), documentation et présentations Claude Code context: fork. Akshay Pachaar, "split by context, not by role" (X/Twitter, mars 2026).
(*) La couverture est générée par IA. Les trois agents sur l'image ont une meilleure coordination que la plupart des standups auxquels j'ai assisté.