Contexte composé : pourquoi les projets IA s'améliorent avec le temps

Il y a six mois, une tâche de développement dans mon projet resumegeni nécessitait une session entière d’explications. L’agent devait comprendre le schéma de base de données, les conventions de routage, l’héritage des templates, la couche de cache, le pipeline de déploiement et les patterns de test avant de pouvoir toucher une seule ligne de code. Chaque session repartait de zéro.

La semaine dernière, j’ai dit « corrige les performances de la page market » et l’agent a lu un document de passation d’une session précédente, identifié le goulot d’étranglement dans market_hub(), implémenté une requête paginée avec un RPC d’agrégation, écrit les tests et déployé. Austin est passé de 14 secondes à 108 millisecondes. L’agent n’est pas devenu plus intelligent. Le projet est devenu plus riche.

La différence ne vient pas du modèle. Elle vient du contexte accumulé autour du projet : le CLAUDE.md qui décrit les conventions, les fichiers mémoire qui capturent les décisions, les documents de passation qui préservent les diagnostics entre les sessions, les hooks qui imposent des contraintes, les skills qui encodent les workflows, les suites de tests qui vérifient la correction, les journaux de bord qui consignent ce qui a été livré et pourquoi. Chaque artefact a été créé pour résoudre un problème spécifique. Ensemble, ils rendent chaque problème ultérieur moins coûteux à résoudre.

C’est le contexte composé.

En bref

• Le contexte composé est le phénomène par lequel les projets assistés par IA s’améliorent plus rapidement au fil du temps, car les problèmes résolus déposent du contexte réutilisable qui réduit le coût de résolution du problème suivant.
• Le modèle ne s’améliore pas entre les sessions. C’est l’infrastructure du projet qui progresse : fichiers CLAUDE.md, systèmes de mémoire, hooks, skills, documents de passation, couverture de tests, conventions de nommage et journaux opérationnels.
• Le contexte composé explique pourquoi démarrer un nouveau projet avec un agent IA semble lent, alors que la 500e session sur le même projet semble rapide. La première session construit le contexte. La 500e le dépense.
• L’effet n’est pas automatique. Il exige un investissement intentionnel dans les artefacts de contexte : des documents qui capturent les décisions, des hooks qui encodent les contraintes, des tests qui vérifient les hypothèses et des journaux qui préservent l’historique opérationnel.
• Les organisations qui comprennent le contexte composé cesseront de faire tourner les ingénieurs entre les projets chaque trimestre et commenceront à traiter le contexte accumulé comme un actif en capital.

Ce qui se compose

Le contexte composé opère à travers six catégories de connaissances accumulées sur le projet. Chacune génère un type de rendement différent.

Documents de conventions (CLAUDE.md). Un fichier CLAUDE.md indique à chaque session d’agent comment le projet fonctionne : structure des fichiers, conventions de nommage, patterns d’import, approche de test, processus de déploiement. La première session sans CLAUDE.md consacre une grande partie de son effort à découvrir les conventions. La centième session avec un CLAUDE.md mature n’y consacre rien. Le document se compose parce que chaque convention capturée une fois n’est jamais ré-expliquée.

Mémoire décisionnelle. Les fichiers mémoire capturent pourquoi les décisions ont été prises, pas seulement ce qui a été décidé. Quand une session future rencontre le même arbitrage, elle lit la mémoire au lieu de re-dériver la réponse. Mon système de mémoire stocke les décisions de projet, les préférences utilisateur, les corrections de feedback et les pointeurs de référence. Chaque mémoire est petite. La collection forme un cache décisionnel qui empêche le projet de rouvrir des questions réglées.

Documents de passation. Un document de passation préserve un diagnostic au-delà des limites de session. La passation concernant les performances de la page market a survécu à trois corrections de revue de code, deux réordonnancements de priorités, et a finalement guidé l’implémentation quatre jours plus tard. Sans cette passation, la session suivante aurait relancé l’investigation depuis le début, ciblant probablement le mauvais chemin de code (comme la première ébauche l’avait fait). La passation s’est composée en convertissant le temps de diagnostic en artefact réutilisable.

Hooks et contraintes. Chaque hook encode une leçon tirée d’un échec passé. Mon garde-fou contre les API destructifs existe parce qu’un agent a purgé l’intégralité du cache Cloudflare. Mon hook de sandbox existe parce qu’un agent a tenté d’écrire dans ~/.ssh/. Mon détecteur de dérive existe parce que des agents ont perdu le fil de leur tâche douze fois en soixante jours. Chaque hook empêche la même classe d’échec de se reproduire dans toutes les sessions futures. Les hooks se composent parce qu’ils convertissent la réponse aux incidents en prévention permanente.

Skills et workflows. Un skill est un workflow codifié qu’un agent peut exécuter sans réinventer le processus. Mon skill /nightcheck effectue plus de 50 vérifications de pages avec des benchmarks TTFB, une vérification du cache et des crawls complets du sitemap. Mon skill /scan-intel interroge six sources académiques sur huit sujets de recherche avec déduplication et scoring. Mon skill /blog-translator traduit les articles en neuf langues avec préservation du format. Chaque skill a été coûteux à construire une fois et gratuit à exécuter indéfiniment. Les skills se composent parce qu’ils convertissent la connaissance des processus en automatisation exécutable.

Suites de tests. Les tests vérifient que le projet fonctionne toujours après des modifications. Une suite de tests mature permet à un agent d’effectuer des changements agressifs en toute confiance, car les échecs sont détectés immédiatement. Un projet sans tests impose des changements conservateurs et incrémentaux parce que l’agent ne peut pas vérifier son travail. La couverture de tests se compose parce que chaque test rend les changements futurs moins coûteux et plus sûrs.

La courbe de composition

Le contexte composé suit une courbe caractéristique.

Sessions 1 à 10 : phase d’investissement. L’essentiel de l’effort va à la construction du contexte plutôt qu’à la livraison de fonctionnalités. Vous rédigez le CLAUDE.md, établissez les conventions, créez les premiers hooks, mettez en place le framework de test. La production semble lente parce que vous construisez de l’infrastructure, pas du produit.

Sessions 10 à 50 : phase d’accélération. Le contexte commence à produire de la valeur. L’agent cesse de poser des questions sur les conventions et commence à les suivre. Les hooks interceptent les erreurs avant le déploiement. Les skills automatisent les workflows répétitifs. Chaque session produit davantage que la précédente parce que la base de contexte s’enrichit.

Sessions 50 à 200 : phase de composition. Le projet a accumulé suffisamment de contexte pour que les problèmes difficiles deviennent faciles. Un agent qui lit un CLAUDE.md mature, un ensemble de fichiers mémoire et un document de passation peut exécuter des implémentations complexes en plusieurs étapes sans guidance supplémentaire. La correction de la page market s’est produite dans cette phase. Une seule phrase (« corrige les performances de la page market ») a déclenché un processus de quatre jours qui s’est conclu par une amélioration de 132x parce que l’infrastructure de contexte portait le diagnostic, les contraintes et les critères de vérification.

Sessions 200+ : phase de maintenance. Le rythme de création de nouveau contexte ralentit car la plupart des conventions, contraintes et workflows sont déjà capturés. L’accent se déplace vers la mise à jour du contexte existant (correction des mémoires obsolètes, extension des skills, ajout de tests pour de nouveaux cas limites) plutôt que vers sa création ex nihilo. L’effet de composition plafonne mais reste élevé.

Pourquoi ce n’est pas évident

Trois facteurs masquent l’effet de composition.

Les améliorations du modèle masquent les améliorations du contexte. Quand vos sessions IA s’améliorent au fil du temps, vous attribuez le progrès à de meilleurs modèles. Claude Opus 4.6 est meilleur que Claude 3.5 Sonnet. Mais l’amélioration que vous constatez sur un projet de longue date dépasse l’amélioration du modèle, car le contexte composé se cumule par-dessus l’amélioration du modèle. Passer à un nouveau projet sur le même modèle révèle la différence : le nouveau projet semble lent parce qu’il n’a pas de contexte composé.

Le contexte est invisible. Un fichier CLAUDE.md est un document texte. Les fichiers mémoire sont des notes en markdown. Les hooks sont des scripts shell. Aucun de ces artefacts n’est impressionnant individuellement. L’effet de composition n’est visible dans aucun artefact isolé. Il n’est visible que dans le comportement agrégé des sessions qui opèrent sur la pile de contexte complète. Vous ne pouvez pas pointer un seul fichier en disant « voilà pourquoi le projet est rapide ». Vous ne pouvez que comparer la 500e session à la 1re et constater la différence.

Démarrer de nouveaux projets est excitant. Un nouveau projet apporte une énergie fraîche et aucune dette accumulée. Mais il n’a pas non plus de contexte accumulé. La première session sur un nouveau projet semble productive parce qu’elle prend des décisions de haut niveau qui paraissent impactantes. La 20e session sur un projet existant semble routinière parce qu’elle s’exécute dans des conventions établies. La sensation de routine, c’est l’effet de composition en action. La sensation d’excitation, c’est son absence.

Ce qui empêche la composition

Quatre modes de défaillance brisent la courbe de composition.

La dégradation du contexte. Des mémoires obsolètes, des sections CLAUDE.md périmées et des hooks dépréciés créent de la confusion plutôt que de la clarté. Un agent qui suit des conventions obsolètes produit un résultat pire qu’un agent sans aucune convention. Le contexte nécessite de la maintenance. Mon système de mémoire inclut des horodatages de dernière mise à jour et des vérifications explicites d’obsolescence. Un contexte mort est pire que l’absence de contexte.

La prolifération du contexte. Trop de fichiers, trop de hooks, trop de skills créent un problème de découvrabilité. Si l’agent ne trouve pas le contexte pertinent, le contexte ne se compose pas. L’organisation compte : mes fichiers mémoire utilisent un frontmatter avec des descriptions pour que les sessions futures puissent évaluer la pertinence sans lire l’intégralité du contenu. Mes hooks sont enregistrés dans un répartiteur qui les charge par type d’événement. Un contexte découvrable se compose. Un contexte enfoui se dégrade.

L’isolement des sessions. Si les sessions ne lisent ni n’écrivent de contexte persistant, chaque session repart de zéro. L’effet de composition exige des ponts intentionnels : des documents de passation qui transportent le diagnostic entre les sessions, des écritures mémoire qui capturent les décisions, des journaux de bord qui consignent l’historique opérationnel. Sans ces ponts, un projet avec 500 sessions a le même contexte effectif qu’un projet avec une seule.

L’instabilité de plateforme. Changer d’outil IA réinitialise la pile de contexte. Un CLAUDE.md écrit pour une plateforme n’aide pas automatiquement une autre. Des hooks écrits pour le modèle événementiel d’une plateforme ne se déclenchent pas dans une autre. Le contexte composé est spécifique à la plateforme, ce qui crée un verrouillage qui est aussi un avantage concurrentiel. Plus votre pile de contexte est profonde sur une plateforme, plus le coût de migration est élevé, et plus votre projet s’améliore par rapport aux concurrents qui changent sans cesse.

Le contexte composé comme capital

En finance, les intérêts composés transforment de petits dépôts en sommes importantes avec suffisamment de temps. L’intuition clé est que les rendements eux-mêmes génèrent des rendements supplémentaires. Le contexte composé fonctionne de la même manière.

Une convention capturée dans CLAUDE.md élimine la ré-explication dans chaque session future. Ce temps économisé est consacré à résoudre de nouveaux problèmes, ce qui génère de nouvelles conventions, qui réduisent encore la ré-explication future. Un hook qui prévient une classe d’échec élimine la ré-investigation de cet échec dans chaque session future. Ce temps économisé est consacré à construire de nouveaux hooks pour de nouvelles classes d’échec. Chaque investissement génère des rendements qui permettent de nouveaux investissements.

L’implication pour les organisations : le contexte de projet est un actif en capital. Faire tourner les ingénieurs entre les projets chaque trimestre détruit le contexte accumulé de la même manière que clôturer un compte d’épargne détruit les intérêts accumulés. Une équipe qui reste sur le même projet pendant deux ans avec l’assistance de l’IA surpassera une équipe qui tourne chaque trimestre, non parce que les individus sont meilleurs, mais parce que le contexte s’est composé.

L’implication pour les ingénieurs individuels : votre infrastructure IA est un portefeuille d’investissement. Chaque section de CLAUDE.md, chaque fichier mémoire, chaque hook, chaque skill, chaque document de passation est un dépôt. Le portefeuille croît lentement au début. Après des centaines de sessions, il génère des rendements qui font paraître les problèmes difficiles faciles aux observateurs qui ne voient pas la pile de contexte en dessous.

La page market est passée de 14 secondes à 108 millisecondes. Un observateur voit une correction de performance. Moi, je vois un document de passation qui a survécu à trois révisions, un système de nightcheck qui a mesuré la régression, un garde-fou destructif qui a empêché une répétition de la purge du cache, un skill de revue de code qui a détecté la mauvaise cible initiale, et cinq cents sessions de contexte accumulé qui ont rendu tout cela possible.

C’est le contexte composé.

FAQ

Qu’est-ce que le contexte composé ?

Le contexte composé est le phénomène par lequel les projets assistés par IA s’améliorent plus rapidement au fil du temps, car les problèmes résolus déposent du contexte réutilisable (documents, hooks, skills, tests, mémoires) qui réduit le coût de résolution des problèmes suivants. Le terme est analogue aux intérêts composés : les rendements eux-mêmes génèrent des rendements supplémentaires.

Cela fonctionne-t-il avec n’importe quel outil IA ?

Le principe s’applique largement, mais l’implémentation dépend du support de l’outil pour le contexte persistant. Claude Code prend en charge les fichiers CLAUDE.md, les hooks, les skills et les systèmes de mémoire nativement. D’autres outils peuvent nécessiter un échafaudage externe pour obtenir le même effet. La courbe de composition est plus prononcée sur les plateformes qui offrent davantage de mécanismes de persistance du contexte.

Comment commencer à construire du contexte composé ?

Commencez par un CLAUDE.md qui décrit les conventions de votre projet. Ajoutez des fichiers mémoire pour les décisions clés. Écrivez des hooks pour les patterns d’échec que vous avez rencontrés. Créez des skills pour les workflows que vous répétez entre les sessions. L’investissement semble lent au début. Les rendements apparaissent après 10 à 20 sessions.

Est-ce simplement de la documentation ?

Non. La documentation en est une composante, mais le contexte composé inclut également des artefacts exécutables : des hooks qui imposent des contraintes à l’exécution, des skills qui automatisent les workflows, des suites de tests qui vérifient la correction, et des systèmes de mémoire qui éclairent la prise de décision. La documentation statique explique. Le contexte composé agit.

Qu’en est-il des limites de la fenêtre de contexte ?

Le contexte composé n’exige pas de charger tout le contexte dans chaque session. Il exige que le bon contexte soit disponible au bon moment. Un CLAUDE.md est chargé automatiquement. Les fichiers mémoire sont interrogés par pertinence. Les documents de passation sont lus lors de la reprise d’une tâche spécifique. La pile de contexte dépasse toute fenêtre de contexte individuelle. L’agent accède à la tranche pertinente par session.

Comment savoir si mon projet bénéficie du contexte composé ?

Comparez l’effort nécessaire pour des tâches similaires au début et plus tard dans l’histoire du projet. Si une tâche qui prenait une session entière au premier mois ne prend qu’un seul prompt au sixième mois, le contexte composé fonctionne. Si l’effort reste identique, le contexte ne s’accumule pas ou n’est pas persisté entre les sessions.

Sources

Cet article s’appuie sur l’expérience en production de plus de 500 sessions de développement autonome réparties sur six projets depuis mai 2025. Exemples spécifiques référencés :

• Performance de la page market : document de passation, vérification nightcheck et déploiement décrits dans les journaux de bord du 21 au 25 mars 2026
• Gardes-fous contre les API destructifs : construits après qu’un agent a purgé l’intégralité du cache Cloudflare, décrits dans l’article deploy-and-defend
• Infrastructure de hooks et skills : 84 hooks interceptant 15 types d’événements, décrits dans le commentaire NIST
• Détection de dérive : suivi par similarité cosinus sur plus de 60 sessions, décrit dans The Invisible Agent
• Boucles d’auto-recherche : expériences à budget fixe sur Apple Silicon, validées par l’article Claudini
• Documentation Anthropic sur la mémoire et les instructions de projet de Claude Code : Manage Claude’s memory
• Dépôt autoresearch d’Andrej Karpathy : autoresearch