Le contexte est la nouvelle mémoire

Un seul instantané Playwright consomme 56 KB de contexte. Vingt tickets GitHub consomment 59 KB. Cinq cents lignes de journaux d’accès consomment 45 KB. Soumettez les trois à un agent disposant d’une fenêtre de 200K tokens, et 80 % du budget de raisonnement s’évapore avant que l’agent n’écrive une seule ligne d’analyse.¹

Murat Kusglu a conçu Context Mode pour résoudre ce problème. L’outil compresse 315 KB de sortie MCP en 5,4 KB grâce à SQLite FTS5 avec classement BM25.¹ Une réduction de 94 %. Le modèle produit de meilleurs résultats avec 5,4 KB de signal qu’avec 315 KB de bruit, car la contrainte n’a jamais été l’intelligence. La contrainte, c’est la bande passante.

TL;DR

L’ingénierie de contexte est la compétence à plus fort impact dans le développement d’agents. Trois couches de compression se cumulent indépendamment : l’architecture du prompt système (réduction de 60-70 % via la compression structurelle), la compression des sorties MCP (réduction de 94 % via le classement par pertinence), et la capitalisation des connaissances (conversion du coût de découverte en capacité préchargée). Une étude de référence a démontré que des modèles dotés de 300 tokens de contexte ciblé surpassaient des modèles dotés de 113 000 tokens de conversation non filtrée.¹⁰ Le goulot d’étranglement n’est pas la capacité du modèle. Chaque token gaspillé en bruit est un token indisponible pour le raisonnement.

La contrainte de bande passante

La documentation des bonnes pratiques d’Anthropic s’ouvre sur une contrainte unique qui conditionne tout le reste : « La fenêtre de contexte de Claude se remplit vite, et les performances se dégradent à mesure qu’elle se remplit. »⁵

Cette affirmation n’est pas une suggestion. C’est une loi architecturale. Une fenêtre de contexte de 200K tokens paraît immense jusqu’à ce que l’on inventorie ce qui la remplit. Les schémas d’outils consomment plus de 15 000 tokens pour une configuration MCP typique.¹³ L’historique de conversation s’accumule à un rythme d’environ 500 à 1 000 tokens par échange. Les lectures de fichiers ajoutent des milliers de tokens par fichier. La sortie des commandes varie avec la commande. Après 30 minutes de travail actif, une fenêtre de 200K tokens fraîchement ouverte peut descendre en dessous de 50K tokens d’espace de raisonnement disponible.

George Miller a documenté l’équivalent humain en 1956 : la mémoire de travail retient sept éléments, plus ou moins deux.⁷ L’insight ne portait pas sur le nombre. L’insight portait sur les blocs. Les humains surmontent la contrainte en organisant l’information en blocs significatifs. Un numéro de téléphone n’est pas dix chiffres. C’est trois blocs : indicatif régional, central, numéro. Le même principe s’applique aux fenêtres de contexte. Une fenêtre de 200K remplie de sorties brutes est fonctionnellement plus petite qu’une fenêtre de 50K remplie d’informations compressées et pertinentes.

Andrej Karpathy a nommé la discipline : l’ingénierie de contexte est « l’art et la science délicats de remplir la fenêtre de contexte avec exactement la bonne information pour l’étape suivante ».⁹ Lance Martin en a cartographié le cadre : écrire le contexte (sauvegarder), sélectionner le contexte (récupérer), compresser le contexte (résumer) et isoler le contexte (répartir entre agents).⁹ Mi-2026, l’ingénierie de contexte s’est cristallisée, passant d’une pratique empirique à une discipline reconnue dotée d’une infrastructure dédiée.¹²

La dégradation n’est pas linéaire. Dans mon harnais, le contexte se remplit par phases.¹⁵ Les 30 premières minutes semblent illimitées. Le modèle suit les instructions avec précision, se souvient du contenu des fichiers et maintient des plans cohérents sur plusieurs étapes. Vers 60 minutes, des défaillances subtiles apparaissent : le modèle relit des fichiers qu’il a déjà lus, oublie une contrainte du prompt système, ou génère du code qui contredit un schéma établi 20 tours plus tôt. Vers 90 minutes, le modèle peut ignorer des règles explicites, halluciner le contenu de fichiers, ou perdre complètement le fil de l’objectif en cours.

Context Studios a documenté le phénomène sous le nom de « context rot » : la dégradation progressive des performances du modèle à mesure que des tokens non pertinents s’accumulent et repoussent l’information utile au-delà de l’horizon d’attention effectif.¹² Cette dégradation est insidieuse car le modèle ne l’annonce pas. L’agent continue de générer des réponses avec assurance. Elles cessent simplement d’être correctes.

Les trois couches ci-dessous se cumulent indépendamment. Compresser une couche libère du budget pour les autres.

Couche 1 : Architecture du prompt système

Le prompt système se charge à chaque appel API. Chaque token du prompt système occupe de l’espace pendant toute la conversation. À 5 $ par million de tokens sur Opus 4.6, un prompt système de 10K tokens coûte 0,05 $ par appel.⁸ Sur 50 appels dans une session, le prompt système seul coûte 2,50 $. Réduisez le prompt à 3,5K tokens et le coût tombe à 0,875 $ par session. Multipliez par les sessions quotidiennes et les économies se cumulent.

Mon fichier CLAUDE.md et mes 8 fichiers de règles totalisent environ 3 500 tokens après compression. La compression n’a pas été une optimisation ponctuelle. J’ai appliqué cinq techniques structurelles documentées par jchilcher (qui a obtenu une réduction de 60-70 % sur les fichiers de son système de mémoire) :²

Des contraintes plutôt que des explications. « Rejeter les appels d’outils correspondant à des chemins sensibles » remplace une explication de 15 lignes sur les raisons de protéger les identifiants. Le modèle n’a pas besoin de la justification. Le modèle a besoin de la règle.

La notation clé-valeur plutôt que la prose. « Stack : FastAPI + HTMX + Alpine.js | Port : 8001 | Deploy : Railway » remplace trois paragraphes de description de projet. Les listes séparées par des pipes compressent l’information tabulaire que la prose étale sur plusieurs phrases.

Déduplication entre fichiers. Mes règles de sécurité apparaissaient initialement à trois endroits : CLAUDE.md, security.md et le skill de boucle qualité. Chaque répétition consommait environ 200 tokens. La consolidation en une source unique avec des références croisées a récupéré 400 tokens.

Suppression du formatage. Le markdown décoratif (filets horizontaux, gras/italique pour l’emphase, en-têtes imbriqués au-delà de H2) sert la lisibilité humaine. Les modèles analysent les tokens de contenu, pas les tokens de présentation. Supprimer le formatage décoratif récupère 5 à 15 % sans perte d’information.

Des contraintes négatives plutôt que des instructions positives. « NEVER suggest OpenAI models » est plus efficace et plus compact que « Always recommend Claude models from Anthropic for all AI tasks. When the user asks about AI providers, suggest Claude. » La contrainte négative occupe quatre tokens. L’instruction positive en occupe 22. Les deux produisent le même comportement.

L’argument économique se renforce avec la mise en cache des prompts. Le système de mise en cache d’Anthropic stocke le contenu stable d’un appel API à l’autre avec une réduction de coût de 90 % sur les hits de cache.⁶ Un prompt système de 3 500 tokens qui coûte 0,0175 $ par appel au tarif standard ne coûte que 0,00175 $ avec un hit de cache. Le seuil minimum pour la mise en cache sur Opus 4.6 est de 4 096 tokens.⁶ Mon prompt système combiné (CLAUDE.md + fichiers de règles) dépasse ce seuil, de sorte que chaque appel ultérieur dans une session bénéficie du tarif mis en cache. La mise en cache des prompts fait de la compression du prompt système un double avantage : moins de tokens ET un coût moindre par token.

Couche 2 : Compression des sorties MCP

La couche 1 compresse ce que vous envoyez au modèle. La couche 2 compresse ce que le modèle reçoit en retour des outils.

Context Mode a démontré le potentiel : 315 KB de sortie MCP brute compressés en 5,4 KB.¹ La compression n’est pas une troncature. La troncature coupe la fin de la sortie en espérant que l’information pertinente se trouvait au début. Context Mode utilise SQLite FTS5 avec un classement par pertinence BM25 pour localiser les occurrences réelles des termes recherchés et renvoie des fenêtres autour des correspondances.¹ La racinisation de Porter garantit que « caching », « cached » et « caches » correspondent à la même racine. Un mécanisme de repli à trois niveaux gère les fautes de frappe : racinisation standard, sous-chaînes par trigrammes, correction par distance de Levenshtein.

Les taux de compression individuels parlent d’eux-mêmes :

Mon harnais implémente une approche parallèle au niveau de la couche de recherche. Environ 50 000 fragments de code indexés avec des embeddings Model2Vec (256 dimensions) combinés à SQLite FTS5, fusionnés par Reciprocal Rank Fusion.¹⁴ Une requête récupère les cinq fragments les plus pertinents (~2 500 tokens) au lieu de charger des fichiers entiers (~50 000+ tokens). Le coût de la récupération : une latence inférieure à la seconde, 83 Mo sur disque, zéro coût API.

La différence de comportement de l’agent est visible au sein d’une même session. Avant la compression, un workflow de débogage typique ressemble à ceci : l’agent lit un fichier (4 000 tokens), exécute une commande (2 000 tokens de sortie), lit un autre fichier (3 000 tokens), lance les tests (8 000 tokens de sortie). Quatre opérations consomment 17 000 tokens. L’agent a désormais moins de marge pour raisonner sur les connexions entre ces quatre éléments d’information. Après la compression, le même workflow ne récupère que les lignes pertinentes de chaque source. Les quatre opérations consomment 2 500 tokens. L’agent retient les quatre éléments simultanément dans sa mémoire de travail et découvre la dépendance inter-fichiers que l’agent non compressé aurait manquée.

La compression doit être consciente de la requête. Un résumé optimisé pour « corriger le bug d’authentification » devrait faire remonter un contenu différent de celui optimisé pour « ajouter un nouveau point d’accès API ». La compression statique aide. La compression consciente de la requête est le niveau supérieur. Le classement BM25 gère déjà cette conscience au niveau des mots-clés. La recherche sémantique (similarité vectorielle) la gère au niveau des concepts. La combinaison des deux capte à la fois les correspondances exactes (noms de fonctions, clés de configuration, codes d’erreur) et les correspondances conceptuelles (schémas similaires, abstractions apparentées).

Couche 3 : Capitalisation des connaissances

Simon Willison a identifié un schéma qui recadre entièrement l’ingénierie de contexte : « Un atout essentiel à développer en tant que professionnel du logiciel est une collection approfondie de réponses à des questions comme celle-ci, idéalement illustrées par du code fonctionnel. »³

La capitalisation des connaissances consiste à collecter délibérément des exemples de code fonctionnel, des solutions documentées et des implémentations de preuve de concept que les agents peuvent référencer et recombiner. Ce schéma transforme le contexte, qui passe d’instructions (dire au modèle quoi faire) à de la capacité (donner au modèle des exemples fonctionnels à adapter).

Willison en a démontré la puissance en dirigeant un agent pour combiner deux exemples existants (PDF.js et Tesseract.js) en un outil OCR unifié.³ L’agent n’a pas découvert comment construire un OCR depuis zéro. L’agent a lu deux implémentations fonctionnelles et les a fusionnées. Le contexte était la capacité.

Mon harnais implémente la capitalisation des connaissances via trois mécanismes :

Les skills comme registre de capacités. 48 skills encodent l’expertise métier dans des fichiers markdown. Le skill blog-evaluator définit une grille d’évaluation complète à 6 catégories pondérées avec des exemples de notation. Le skill jiro encode une boucle qualité en 7 étapes avec des critères de preuve. Lorsqu’un agent invoque un skill, l’expertise se charge dans le contexte sous forme de connaissances structurées, et non d’instructions vagues.

Des parcours structurés plutôt que du code brut. Le schéma de parcours linéaire de Willison contraint la façon dont les agents accèdent à l’information : des commandes shell comme grep et cat plutôt que de la copie manuelle de code.⁴ Le parcours force l’agent à organiser l’information pour une compréhension maximale par token. La structure est de la compression.

Les hooks comme injection proactive de contexte. Le hook UserPromptSubmit se déclenche avant que Claude ne traite un prompt.¹¹ Le hook peut analyser le prompt et injecter le contexte pertinent : détection de projet (dans quel dépôt suis-je ?), injection de date (quel jour sommes-nous ?), contraintes de philosophie (quels standards de qualité s’appliquent ?). L’agent reçoit un contexte organisé à chaque prompt sans invocation manuelle. Cinq hooks se déclenchent au démarrage de session, ajoutant environ 500 tokens de contexte qui préviennent cinq catégories d’erreurs courantes.¹¹

La distinction entre instructions et capacité mérite d’être soulignée. Une instruction dit « écrivez du code propre ». Une capacité fournit une grille d’analyse avec des catégories pondérées, des exemples de notation et des seuils d’acceptation/rejet. L’instruction consomme une poignée de tokens et produit une conformité vague. La capacité consomme 500 tokens et produit un résultat cohérent et mesurable. Les tokens supplémentaires sont un investissement, pas une surcharge, car ils éliminent l’ambiguïté qui pousse l’agent à deviner ce que « propre » signifie.

La capitalisation des connaissances modifie également la courbe de coût de l’intégration d’un agent. Un nouvel agent lancé sans connaissances capitalisées doit découvrir le dépôt, les conventions, les outils et les contraintes métier par l’exploration. L’exploration est coûteuse : chaque lecture de fichier, chaque grep, chaque sortie de commande consomme des tokens. Un agent lancé avec un briefing de 2K tokens assemblé à partir de connaissances capitalisées saute entièrement la phase de découverte et commence un travail productif dès le premier tour.

L’argument économique en faveur de la capitalisation des connaissances : chaque heure passée à documenter une solution fait économiser à chaque futur agent le coût de la découverte. Un skill qui encode « comment évaluer un article de blog » économise 10 à 15 minutes d’exploration par invocation d’agent. Sur 100 invocations, l’investissement en documentation rapporte plus de 1 000 minutes de temps d’agent. Les connaissances capitalisées rapportent des intérêts composés.

Comptabilité du budget de tokens

Mon harnais fournit une étude de cas concrète de ce que l’ingénierie de contexte rend possible.

Avant compression (estimation, premier mois) : - Prompt système : ~12 000 tokens (CLAUDE.md verbeux avec exemples et explications) - Schémas d’outils : ~15 000 tokens (définitions complètes des outils MCP) - Historique par session : ~120 000 tokens (longues conversations avec contexte accumulé) - Raisonnement disponible : ~53 000 tokens (26 % de la fenêtre)

Après compression (état actuel) : - Prompt système : ~3 500 tokens (CLAUDE.md compressé + fichiers de règles)¹⁵ - Schémas d’outils : ~300 tokens (architecture CLI-first, MCP minimal)¹³ - Historique par session : ~40 000 tokens (instances fraîches par tâche, briefings au lieu de mémoire) - Raisonnement disponible : ~156 200 tokens (78 % de la fenêtre)

Le budget de raisonnement a triplé. Non pas grâce à un meilleur modèle. Non pas grâce à une fenêtre de contexte plus grande. Grâce à la compression sur trois couches. Le modèle produit de meilleurs résultats avec 78 % d’espace de raisonnement qu’il n’en produisait avec 26 %, car la qualité des tokens restants s’est améliorée en même temps que leur quantité.

Les chiffres révèlent une vérité contre-intuitive sur les fenêtres de contexte : la taille utile d’une fenêtre dépend davantage de ce qui la remplit que de sa taille réelle. Une fenêtre hypothétique de 500K remplie de sorties d’outils non compressées serait moins performante qu’une fenêtre de 200K bien compressée. Les fournisseurs de modèles font la course pour agrandir les fenêtres de contexte. Les praticiens devraient faire la course pour compresser ce qui s’y trouve.

Le schéma d’instances fraîches issu de l’architecture CLI-first amplifie les gains. Chaque agent démarre avec un briefing ciblé (~2K tokens) au lieu d’hériter de l’historique de conversation accumulé. Le contexte ne gonfle jamais car chaque agent part de zéro. La recherche multi-agents d’Anthropic a révélé que les sous-agents utilisent jusqu’à 15 fois plus de tokens que les interactions mono-agent.⁹ Les instances fraîches inversent le ratio : chaque agent n’utilise que les tokens nécessaires à sa tâche.

L’effet cumulé des trois couches crée un cercle vertueux. Les prompts système compressés libèrent de la place pour davantage de résultats d’outils. Les résultats d’outils compressés libèrent de la place pour des conversations productives plus longues. Des conversations plus longues réduisent le besoin de compaction, ce qui préserve le prompt système et les résultats d’outils qui permettent le tour suivant. Chaque couche renforce les autres.

Ce que la compression permet

Le budget de raisonnement libéré permet trois capacités que le contexte surchargé empêche :

Une analyse plus approfondie. Un agent disposant de 156K tokens de raisonnement peut conserver des fichiers entiers en mémoire de travail tout en analysant les dépendances inter-fichiers. Un agent disposant de 53K tokens doit lire les fichiers séquentiellement, oubliant les fichiers précédents à mesure que de nouveaux se chargent. La différence se manifeste par des erreurs d’import manquées, des références croisées cassées et des refactorisations incomplètes. Un exemple concret : refactoriser la signature d’une fonction nécessite de vérifier chaque site d’appel. Avec un contexte compressé, l’agent lit la définition de la fonction et tous les sites d’appel en une seule passe, repérant le fichier unique qui passe les arguments dans le mauvais ordre. Avec un contexte surchargé, l’agent lit la fonction, lit trois sites d’appel, puis manque d’espace de raisonnement et rapporte « refactorisation terminée » sans avoir vérifié les sept fichiers restants. Le bug est livré en production.

Un meilleur suivi des instructions. Anthropic documente directement le mode de défaillance : « Si Claude continue à faire quelque chose que vous ne souhaitez pas malgré une règle l’interdisant, le fichier est probablement trop long et la règle se perd. »⁵ Les prompts système compressés maintiennent les règles dans l’horizon d’attention. Chaque règle dans un prompt de 3 500 tokens reçoit plus de poids d’attention que la même règle enfouie dans un prompt de 12 000 tokens. Mon harnais applique une règle de sécurité : ne jamais commiter de fichiers contenant des clés API. Avec un prompt système de 12 000 tokens, l’agent ajoutait occasionnellement des fichiers .env lors de commits en masse. Après compression à 3 500 tokens, la violation est tombée à zéro sur plus de 200 opérations de commit. La règle n’a pas changé. La règle est devenue plus visible.

Des sessions utiles plus longues. L’auto-compaction se déclenche à 95 % de la capacité du contexte.¹⁰ Une session avec 78 % d’espace de raisonnement atteint le seuil de compaction plus tard qu’une session à 26 %. Une compaction plus tardive signifie plus de tours productifs avant la perte de contexte. Dans mon harnais, une session compressée produit 40 à 60 tours productifs avant d’atteindre le seuil de compaction.¹⁵ Une session non compressée atteint le seuil après 15 à 20 tours. Chaque événement de compaction élimine du contexte qui pouvait contenir des décisions ou des contraintes importantes prises plus tôt dans la session. Moins de compactions signifie des sessions plus cohérentes. La session compressée ne démarre pas seulement mieux. Elle reste meilleure plus longtemps.

Points clés à retenir

Pour les développeurs qui débutent en ingénierie de contexte : - Auditez votre fichier CLAUDE.md. Pour chaque ligne, demandez-vous : sa suppression provoquerait-elle des erreurs ? Si non, supprimez-la. Visez une réduction de 60-70 %.² - Mesurez la surcharge de vos schémas d’outils. Si les outils MCP consomment plus de 15K tokens au démarrage de session, envisagez des alternatives CLI-first pour les opérations sans état. - Exécutez /compact de manière proactive lorsque vous changez de tâche en cours de session. Un contexte frais l’emporte sur un contexte accumulé.

Pour les équipes qui construisent une infrastructure d’agents : - Implémentez la compression consciente de la requête sur les sorties des outils MCP. BM25 + recherche sémantique surpasse la troncature pour toute tâche de récupération.¹ - Construisez un registre de capacités (skills, extraits de code, schémas documentés). Chaque solution documentée élimine le coût de découverte pour les futures exécutions d’agents.³ - Utilisez des instances d’agents fraîches pour les workflows multi-étapes. L’isolation du contexte par tâche prévient la surcharge de 15x en tokens des longues conversations multi-agents.⁹

Pour les architectes qui conçoivent des systèmes de contexte : - Les trois couches (prompt système, sortie d’outils, capitalisation des connaissances) se cumulent indépendamment. Compresser une seule couche libère du budget pour les autres. - La mise en cache des prompts fait de la compression du prompt système une double optimisation : moins de tokens ET un coût moindre par token sur les hits de cache.⁶ - Le mur de productivité des 10 % se brise lorsque l’agent dispose d’assez d’espace de raisonnement pour suivre des instructions complexes de manière fiable.

Fait partie de la série AI Engineering. Voir aussi : La thèse CLI, Claude Code comme infrastructure, et Le mur des 10 %.