Compression de contexte pour agents IA

Introduction

La compression de contexte agents ia devient utile quand un agent commence à relire trop d’historique, trop de documents ou trop de sorties d’outils pour prendre une décision simple. Le sujet est pertinent pour les builders qui voient monter coût, latence ou contradictions dans des runs longs. Vous allez voir quand compresser, quoi compresser et comment éviter de casser la qualité. En revanche, si votre workflow reste court, déterministe et avec peu d’état, ce n'est probablement pas le bon choix : restez sur une approche plus simple tant que le vrai problème n’est pas encore le bruit informationnel.

Résumé rapide

Situation	Bon réflexe	Mauvais réflexe
Historique conversationnel trop long	Résumer les décisions encore utiles	Réinjecter tout le transcript
Trop de documents RAG	Sélectionner seulement les passages qui changent la décision	Multiplier les chunks “au cas où”
Sorties d’outils trop verbeuses	Projeter un sous-ensemble structuré	Coller la réponse brute d’API dans le prompt
État, mémoire et retrieval confondus	Séparer chaque couche avant compression	Utiliser la compression pour masquer un design flou
Agent simple et court	Garder une architecture légère	Ajouter résumés, stores et filtres sans besoin réel

Pourquoi compresser le contexte au lieu de l’allonger

Augmenter la fenêtre de contexte ne résout pas automatiquement les problèmes d’un agent. Dans beaucoup de stacks, cela déplace seulement le problème : plus de texte à traiter, plus de coût par run, plus de latence, et surtout plus de bruit. Un agent ne décide pas mieux parce qu’il voit tout. Il décide mieux quand les signaux utiles sont présents, hiérarchisés et frais.

La compression de contexte sert précisément à cela. Son but n’est pas de “faire tenir plus de texte” dans un prompt, mais de réduire la distance entre la question courante et les informations qui changent réellement la décision. Dès qu’un agent combine historique de session, état courant, mémoire durable, retrieval documentaire et résultats d’outils, la vraie difficulté n’est plus la quantité absolue de tokens. C’est la gouvernance de ce qui entre dans le run.

Le bon modèle mental consiste à distinguer quatre couches. D’abord, l’état courant : où en est le workflow, quelle action a déjà été tentée, quelle validation manque encore. Ensuite, la mémoire utile de session : décisions récentes, contraintes actives, ambiguïtés ouvertes. Puis la mémoire durable : préférences stables, faits consolidés, données qui dépassent un run. Enfin, le retrieval : documents ou références à relire à la demande. Si ces couches sont bien séparées, la compression devient sélective. Sinon, elle n’est qu’un bricolage pour faire rentrer un système déjà confus dans une fenêtre plus petite.

C’est pour cela que la compression est proche du context engineering pour agents IA. Le contexte actif doit rester une couche intentionnelle, pas un dépôt de texte accumulé au fil des intégrations. La compression devient aussi complémentaire de la question d’état : si vous ne savez pas ce qui relève de l’état courant, vous ne savez pas non plus ce qui peut être résumé ou retiré. Le guide sur gérer l’état d’un agent IA aide justement à fixer cette frontière.

En pratique, compresser le contexte apporte trois bénéfices quand le problème est réel. Le premier est économique : moins de tokens et moins de retries coûteux. Le deuxième est qualitatif : moins de conflits entre sources et moins de dilution des priorités métier. Le troisième est opérationnel : un run plus explicable, parce qu’on peut lister les blocs inclus, exclus ou condensés. En revanche, si l’agent n’a qu’un prompt stable, peu de sources et presque pas d’historique, la compression devient vite une couche de complexité supplémentaire. Dans ce cas, le bon choix reste souvent un prompt mieux cadré et une orchestration plus simple.

Stratégies utiles, erreurs fréquentes et lien avec mémoire, état et RAG

La première stratégie utile est le résumé tournant. Au lieu de réinjecter tout l’historique, on conserve les quelques messages les plus récents en brut, puis un résumé vivant des décisions, contraintes et points encore ouverts. Ce pattern fonctionne bien sur des conversations longues ou des workflows où plusieurs étapes s’enchaînent. Le piège consiste à résumer trop tôt ou trop agressivement. Si le résumé perd les raisons d’une décision, l’agent garde une conclusion sans son contexte, ce qui dégrade la suite du run.

La deuxième stratégie est la sélection par rôle. Toutes les sources n’ont pas la même autorité. Une consigne système, un état validé, une sortie d’outil fraîche et un chunk RAG n’ont pas vocation à se retrouver au même niveau. La compression consiste alors moins à raccourcir qu’à filtrer selon la priorité : règles système, état courant, contraintes métier, mémoire récente, puis documents récupérés. Cette hiérarchie évite qu’un document secondaire ou un ancien message contredise une vérité opérationnelle plus importante.

La troisième stratégie est la projection structurée. Beaucoup d’agents consomment des sorties d’API, des résultats SQL ou des réponses d’outils qui sont trop verbeuses. Il vaut mieux transformer cette matière brute en petit objet stable : statut, champs utiles, anomalies, prochaine action. Un agent n’a pas besoin de la réponse complète du backend si seules trois variables déterminent l’étape suivante. Cette logique réduit fortement le bruit dans le prompt tout en améliorant l’explicabilité du système.

La quatrième stratégie est la mémoire structurée, qui ne doit pas être confondue avec la compression elle-même. La compression gère ce qui entre maintenant dans le prompt. La mémoire durable gère ce qui mérite d’être conservé au-delà du tour courant. Si vous gardez tout dans une mémoire sémantique ou une base vectorielle, vous ne compressez pas le contexte ; vous déplacez seulement le problème. Les stratégies de mémoire pour agents IA montrent pourquoi une préférence durable, un fait métier stable et une trace d’exécution n’ont pas la même destination.

La cinquième stratégie est la compression conditionnelle liée au retrieval. Dans un setup RAG, le bon réflexe n’est pas d’injecter plus de chunks pour “ne rien oublier”. Il faut plutôt récupérer peu, mais bien. Ensuite, si certains passages sont encore trop longs, on peut les condenser en gardant faits, exceptions et sources réellement utiles. C’est aussi là qu’il faut distinguer compression et RAG : le retrieval décide quoi relire ; la compression décide quelle forme injecter. Le guide RAG pour agents IA complète bien ce point côté récupération documentaire, tandis que mémoire agent vs RAG aide à choisir la bonne couche selon la nature de l’information.

Plusieurs erreurs reviennent souvent.

Erreur 1 : compresser pour masquer un mauvais design. Si l’état est flou, si le retrieval ramène des documents contradictoires, ou si l’agent ne sait pas quelles sources priment, un résumé ne corrigera pas le problème. Il rendra seulement l’erreur plus compacte.

Erreur 2 : tout compresser au même endroit. Certaines informations doivent être conservées exactement, pas résumées : identifiants, statuts métier, validations, données sensibles ou résultats d’outils critiques. La compression doit viser la matière redondante, pas les points de vérité.

Erreur 3 : compresser sans instrumenter. En production, il faut savoir ce qui a été supprimé, résumé ou gardé. Sans observabilité, un mauvais résultat devient difficile à attribuer : était-ce un résumé trop agressif, un chunk mal filtré, ou un état déjà faux avant la compression ?

Erreur 4 : croire qu’une compression agressive est toujours meilleure. Réduire au maximum le nombre de tokens n’est pas un objectif autonome. Un contexte plus petit mais moins fiable coûte parfois plus cher si les retries, vérifications humaines ou escalades augmentent ensuite.

La réalité production oblige donc à poser quelques règles simples. D’abord, compresser à partir d’un contrat de contexte écrit : quelles couches existent, qui les alimente, quelle fraîcheur elles ont, quel niveau d’autorité elles portent. Ensuite, logguer les versions de résumés, les blocs injectés et les décisions prises après compression. Enfin, garder des chemins de repli : si le résumé semble insuffisant, l’agent doit pouvoir relire une source plus détaillée ou déclencher un outil, au lieu d’halluciner à partir d’une condensation trop pauvre.

Un bon test consiste à se poser trois questions avant d’ajouter une compression. Est-ce que cette information doit vraiment être lue maintenant ? Peut-elle être représentée de façon plus compacte sans perdre la logique de décision ? Et si on l’enlève, quelle erreur métier risque d’apparaître ? Si vous ne savez pas répondre, le problème n’est probablement pas la compression, mais le design du contexte lui-même.

Exemple concret

Prenons un agent support interne branché à une base documentaire, à un outil de ticketing et à un petit store d’état. L’agent doit répondre à des questions récurrentes, vérifier parfois un statut de ticket, puis décider s’il peut répondre directement ou s’il doit escalader.

Dans une version naïve, chaque run injecte tout : historique complet de la conversation, fiche ticket brute, plusieurs chunks RAG, consignes système, messages internes précédents et sortie complète de l’API de ticketing. Au début, le système “semble riche”. Mais les symptômes arrivent vite : coût en hausse, latence irrégulière, réponses qui citent des détails inutiles, et surtout difficulté à comprendre pourquoi l’agent a privilégié un ancien échange plutôt qu’une règle actuelle.

Une version plus propre applique trois niveaux de compression.

1. Historique récent + résumé tournant : on garde les deux ou trois derniers messages en brut, plus un résumé des décisions encore actives.
2. Projection d’état : au lieu d’envoyer toute la fiche ticket, on injecte seulement l’étape courante, le niveau de priorité, la validation déjà reçue et la prochaine action possible.
3. Retrieval ciblé puis condensation légère : on récupère deux ou trois passages documentaires, puis on réduit chaque passage à ses règles, exceptions et liens de vérification utiles.

Le contexte actif peut alors ressembler à ceci :

{
  "state": {
    "ticket_status": "open",
    "current_step": "draft_answer",
    "needs_human_review": false
  },
  "session_summary": [
    "L'utilisateur veut savoir si la procédure VPN a changé",
    "Le ticket n'est pas bloqué",
    "Aucune dérogation validée"
  ],
  "retrieved_rules": [
    "La procédure MFA est obligatoire depuis la version actuelle",
    "Les exceptions doivent être approuvées par l'équipe sécurité"
  ]
}

Ce n’est pas seulement plus petit. C’est surtout mieux aligné sur la décision courante. L’agent voit l’état utile, les signaux de session encore actifs, puis les deux règles documentaires qui font autorité. S’il a besoin de détails supplémentaires, il peut relire le passage complet ou refaire une requête documentaire. Cette architecture garde donc une porte de sortie : la compression n’est pas une perte définitive, mais une couche de sélection avant la décision.

Le bénéfice production est concret. Les runs sont plus stables, les logs plus interprétables, et les retries moins coûteux. Surtout, l’équipe peut auditer ce qui a été condensé. Si une réponse est fausse, on peut vérifier si le problème vient du résumé, du retrieval ou de l’état. Sans cette séparation, toute erreur ressemble à une “hallucination”, alors qu’elle vient souvent d’un contexte mal gouverné.

Bonnes pratiques

Commencez par compresser tard, pas tôt. Tant que vous n’avez pas identifié quelles sources polluent réellement le run, vous risquez de résumer au hasard. La bonne séquence est souvent : rendre l’état explicite, clarifier les sources, mesurer le bruit, puis seulement ajouter des couches de condensation.

Définissez ensuite ce qui ne doit jamais être compressé : identifiants, statuts métier, validations, champs de sécurité, résultats d’outils critiques. La compression doit porter sur l’historique redondant, les documents trop larges ou les sorties verbeuses, pas sur les points de vérité opérationnels.

Instrumentez chaque run. En production, loggez la version du résumé, le nombre de blocs exclus, les sources relues et la raison d’un fallback éventuel. Cette observabilité évite de confondre un problème de modèle avec un problème de contexte condensé. Elle réduit aussi le coût de maintenance quand plusieurs personnes modifient les règles d’injection.

Enfin, gardez un mini-checklist simple : la compression change-t-elle la décision, réduit-elle vraiment le bruit, et reste-t-elle réversible via une source plus détaillée ? Si la réponse est non, n’ajoutez pas cette couche. Sur un agent court ou très déterministe, la compression est souvent de l’overkill. Là encore, restez sur une approche plus simple tant que l’architecture n’a pas atteint le niveau de complexité qui la justifie.

Questions fréquentes

La compression de contexte remplace-t-elle la mémoire d’un agent ?

Non. La compression de contexte décide ce qui entre dans le prompt courant et sous quelle forme. La mémoire sert à conserver des faits utiles sur plusieurs tours ou plusieurs sessions. Les deux peuvent se compléter, mais elles ne répondent pas au même problème d’architecture.

Faut-il compresser tous les résultats d’outils ?

Non plus. Certains résultats doivent rester exacts, notamment les statuts, identifiants, validations ou données sensibles. Il faut surtout compresser les réponses brutes trop verbeuses quand seules quelques variables influencent la décision suivante.

Comment savoir si mon agent a un vrai problème de contexte ?

Regardez les symptômes : historique qui gonfle, coûts qui dérivent, réponses incohérentes malgré des cas proches, difficulté à expliquer pourquoi une source a été privilégiée, ou latence qui augmente à mesure que l’agent voit plus d’informations. Si ces signaux apparaissent, la compression peut devenir utile.

Compression de contexte ou RAG : que faut-il traiter en premier ?

Traitez d’abord la couche qui pose réellement problème. Si le retrieval ramène trop de documents ou de mauvais passages, améliorez le RAG avant d’ajouter une compression agressive. Si le problème vient surtout du transcript, des sorties d’outils ou de l’accumulation d’état, la compression du contexte sera souvent le levier le plus immédiat.

Articles liés

La compression de contexte n’est pas une astuce pour “faire rentrer plus” dans le prompt. C’est une discipline de sélection qui devient utile quand l’agent voit trop d’informations pour trop peu de décision réelle. Utilisez-la pour réduire bruit, coût et latence sans perdre les signaux qui font autorité. Si vous voulez d’abord mieux cadrer la couche qui entre dans le prompt, poursuivez avec Context engineering pour agents IA.

• Context engineering pour agents IA
• Gérer l’état d’un agent IA
• Stratégies de mémoire pour agents IA
• RAG pour agents IA
• Mémoire agent vs RAG : quelle couche choisir ?