Compaction contextuelle — pourquoi les agents jettent 80% du contexte

En bref

Les systèmes agentiques déployés en production — Claude Code, GitHub Copilot, LangChain — compressent entre 75 et 95% du contexte conversationnel accumulé. Les benchmarks académiques de référence, eux, montrent que la qualité chute au-delà de 50-60% de compression. Sept sources indépendantes dessinent une distribution bimodale nette : industrie d’un côté, recherche de l’autre. L’explication tient en un mot : décomposition.

En clair : imaginez un cuisinier qui prépare un menu complet. S’il devait garder en tête chaque ingrédient, chaque geste, chaque casserole utilisée depuis l’entrée jusqu’au dessert, il s’effondrerait avant le plat principal. Mais s’il découpe son service en stations indépendantes — découpe / cuisson / dressage —, chaque station peut oublier les précédentes. La compaction agressive, c’est exactement ce mécanisme : oublier ce dont l’étape suivante n’a pas besoin.

Le chiffre qui surprend

Quand un outil comme Claude Code atteint la limite de sa fenêtre de contexte (la quantité de texte qu’il peut “voir” à un instant donné), il déclenche un mécanisme de compaction. La compaction résume les anciens échanges pour libérer de la place, tout en conservant les informations jugées essentielles. Le taux de compaction mesure la proportion de contexte éliminée : à 95%, il ne reste que 5% du texte original.

Voici ce que donnent sept mesures indépendantes :

La frontière est nette. Au-dessus de 75% : les outils de production. En dessous de 60% : les benchmarks de recherche. Aucun des systèmes mesurés ne tombe entre les deux.

Deux mondes, deux mesures

Pourquoi un tel écart ? La réponse commence par une différence de protocole.

Les benchmarks académiques testent la compression sur des tâches monolithiques : le modèle reçoit un long document, on compresse une partie, puis on pose des questions sur l’ensemble. C’est le protocole de Liu et al. (“Lost in the Middle”) et de Veseli et al. (COLM 2025). Dans ce scénario, chaque information peut être nécessaire à tout moment. Compresser au-delà de 50-60%, c’est perdre des détails que la tâche pourrait exiger.

Les systèmes industriels, eux, ne fonctionnent pas comme ça. Un agent Claude Code ne traite pas un seul long problème d’un bloc. Il décompose : lire un fichier, modifier une fonction, lancer un test, vérifier le résultat. Chaque sous-tâche est relativement autonome. L’historique complet de la conversation — les 40 échanges précédents — n’est pas nécessaire pour exécuter l’étape en cours.

C’est exactement ce que formalisent Roy et al. dans leur travail sur λ-RLM : pour des tâches décomposables, la précision reste constante indépendamment de la longueur de l’historique. Le modèle n’a besoin que du contexte local de la sous-tâche en cours, pas de tout ce qui précède.

Le mécanisme : la décomposition rend la compaction viable

Le raisonnement est circulaire au premier abord, mais il tient : les agents agentiques peuvent compresser agressivement parce que leur architecture décompose le travail en étapes atomiques.

Prenons un exemple concret. Un développeur demande à Claude Code de “refactorer le module d’authentification”. L’agent va :

1. Lire les fichiers concernés (contexte nécessaire : la demande + les fichiers)
2. Identifier les modifications (contexte nécessaire : les fichiers lus + les conventions du projet)
3. Appliquer chaque modification (contexte nécessaire : le plan + le fichier cible)
4. Lancer les tests (contexte nécessaire : la commande de test)

À l’étape 4, l’agent n’a plus besoin du contenu brut des fichiers lus à l’étape 1. La compaction peut éliminer ces détails sans affecter la qualité de l’étape en cours. Le contexte résiduel nécessaire — “quel fichier j’ai modifié, pourquoi, quel test lancer” — tient en quelques centaines de tokens.

Ce mécanisme converge avec une observation que nous avons faite dans nos propres expériences : le taux de récupération factuelle (la capacité à retrouver une information dans le contexte) reste à 100% sur des contextes de 1K à 44K tokens, tant que l’information est présente. Ce n’est pas le volume qui compte — c’est la présence ou l’absence de l’information pertinente pour la tâche en cours.

En clair : la compaction ne dégrade pas la qualité tant qu’on jette les ingrédients dont on n’a plus besoin. Elle devient destructrice dès que l’étape suivante a besoin d’un détail qu’on a oublié. Le seuil de viabilité de 75-95% n’est donc pas une propriété du LLM — c’est une propriété de la décomposition de la tâche.

Les limites de cette architecture

La compaction agressive n’est pas gratuite. Trois risques documentés méritent attention.

La perte d’information inter-étapes. Quand une décision prise à l’étape 2 dépend d’un détail observé à l’étape 1, et que ce détail a été compressé entre-temps, l’agent peut produire une incohérence. C’est le phénomène de “context rot” — la dégradation progressive de la cohérence contextuelle — formalisé mathématiquement par Roy et al. comme une décroissance exponentielle.

La dépendance au découpage. Si la décomposition est mal faite — si une sous-tâche nécessite en réalité le contexte de plusieurs étapes précédentes — le taux de compaction élevé devient destructeur. La qualité de la compaction dépend directement de la qualité de la décomposition.

Le biais de survie. Nous mesurons les seuils des systèmes qui fonctionnent. Les systèmes qui ont essayé 95% de compaction sans architecture de décomposition adéquate ont vraisemblablement échoué — et ne figurent pas dans nos données.

Ce qu’il faut retenir

• Les systèmes agentiques industriels compressent 75 à 95% du contexte ; les benchmarks académiques plafonnent à 50-60%.
• Cette distribution bimodale s’explique par la décomposition en tâches atomiques : chaque sous-tâche nécessite moins de contexte résiduel.
• La compaction agressive est viable en production parce que l’architecture découpe le travail — pas malgré elle.
• Les benchmarks académiques testent des tâches monolithiques, où toute l’information peut être nécessaire à tout moment — un scénario différent de l’usage agentique.
• Le risque principal reste la perte d’information inter-étapes, surtout quand la décomposition est imparfaite.