Aller au contenu principal
IAAgents IAArchitecturePerformance

Le contexte : pourquoi c'est la ressource la plus critique d'un agent IA

La différence entre un agent IA qui tient trois tours et un agent qui tient trois heures se joue presque entièrement sur la gestion du contexte. Six techniques pour éviter l'explosion des coûts et la perte de qualité.

Par Jean-Christophe Bork
Schéma de la gestion de contexte dans un agent IA

Si l’on ne devait retenir qu’un sujet technique sur les agents IA, ce serait celui-ci. La plupart des échecs en production — agent qui oublie l’objectif, qui se répète, qui se contredit, qui coûte dix fois plus cher que prévu — sont des problèmes de gestion du contexte.

Qu’est-ce que le contexte ?

Le contexte, c’est tout ce qui est envoyé au modèle à chaque tour : le prompt système, les descriptions d’outils, les documents de référence, l’historique de la conversation, et le message en cours.

C’est la mémoire de travail de l’agent — et c’est une ressource rare et coûteuse.

Pourquoi ça pose problème

Trois raisons cumulatives qui apparaissent systématiquement.

Le coût est quadratique

À chaque tour, tout l’historique est renvoyé. Une conversation de 40 tours où chaque tour ajoute 2 000 tokens ne coûte pas 80 000 tokens en entrée mais environ 1,6 million — la somme des préfixes. Sans optimisation, c’est ce qui fait exploser les factures.

La qualité se dégrade avant la limite technique

Une fenêtre de 200 000 tokens ne signifie pas que le modèle raisonne aussi bien à 190 000 qu’à 20 000. L’information pertinente se dilue — un phénomène appelé “context rot”. Un contexte plus court et mieux trié bat presque toujours un contexte long et brut.

La latence croît

Le temps de réponse dépend de la taille du contexte à traiter. Un contexte de 100 000 tokens est sensiblement plus lent qu’un contexte de 20 000.

Six techniques pour maîtriser le contexte

1. La mise en cache des préfixes

Le levier le plus rentable et le plus simple. La partie stable du prompt — système, outils, documents de référence — est mise en cache côté fournisseur. Les requêtes suivantes ne paient qu’une fraction du tarif.

Trois règles pour que ça fonctionne :

  • Ordonner du plus stable au plus volatil : système, puis outils, puis documents, puis historique, puis message courant. Toute modification invalide le cache à partir du point modifié.
  • Ne pas mettre d’horodatage en début de prompt — c’est l’erreur classique qui invalide le cache à chaque appel.
  • Vérifier le seuil minimal de tokens requis pour qu’un préfixe soit cachable.

2. La compaction structurée

Quand le contexte approche de la limite, le résumer. Plutôt qu’un résumé libre (qui oublie des choses), maintenir un état structuré mis à jour à chaque palier :

Objectif : (inchangé)
Faits établis : (avec sources)
Décisions prises : (avec justification)
Écarté : (pistes explorées sans succès — et pourquoi)
Prochaine étape : (une seule ligne)

La section “Écarté” est celle qu’on oublie et qui coûte le plus cher. Sans elle, l’agent refait en boucle les mêmes tentatives infructueuses.

3. L’externalisation vers le système de fichiers

Plutôt que de garder 50 000 tokens de résultats dans le contexte, l’agent les écrit dans des fichiers et ne garde en contexte que les chemins et une description d’une ligne. Il relit ce dont il a besoin, quand il en a besoin.

C’est le modèle mental du développeur : on ne garde pas tout le code en tête, on garde l’arborescence et on ouvre les fichiers utiles.

4. La récupération agentique plutôt que le RAG statique

Le RAG classique récupère des documents une fois avant l’appel, une fois pour toutes. La récupération agentique donne à l’agent un outil de recherche et le laisse chercher, reformuler, affiner, autant de fois que nécessaire.

En pratique, l’hybride gagne : une première récupération statique pour amorcer, plus un outil de recherche pour approfondir.

Point pratique : sur des corpus de taille modeste (quelques centaines de pages), la recherche plein texte donne souvent d’aussi bons résultats que la recherche vectorielle, pour une fraction de la complexité. Ne montez une base vectorielle que quand vous avez démontré qu’elle est nécessaire.

5. Les compétences chargées à la demande

Au lieu d’un prompt système massif qui couvre tous les cas, maintenir un prompt court (2 000 tokens) et vingt “compétences” — des procédures détaillées — dont une seule sera chargée selon la tâche.

C’est le mécanisme de divulgation progressive : seule la compétence pertinente occupe le contexte, les autres restent sur disque.

6. L’isolation par sous-agent

Déléguer la lecture de volumes importants à un sous-agent qui ne renvoie qu’un résumé de 300 mots. Le contexte principal ne voit jamais les 40 000 tokens bruts.

On paie un peu plus de tokens au total, mais on garde le contexte principal propre. Sur des tâches longues, c’est souvent gagnant sur les deux tableaux — qualité et coût.

Budget de contexte : une méthode

Pour un agent de production, fixer explicitement un budget par poste et s’y tenir :

PosteBudget cible (tokens)
Prompt système + politique1 000 - 3 000
Définitions d’outils500 - 2 000
Compétences chargées0 - 5 000
Mémoire / état500 - 2 000
Historique de travail10 000 - 60 000
Marge de sécurité20 % de la fenêtre

Si un poste déborde systématiquement, c’est un signal de conception : trop d’outils, prompt trop bavard, ou tâche mal découpée.

L’impact sur les anti-patterns

Beaucoup de problèmes d’agents en production sont en réalité des problèmes de contexte déguisés :

  • L’agent oublie l’objectif au vingtième tour → pas de compaction
  • L’agent boucle sur la même action → pas de section “Écarté” dans le résumé
  • L’agent se contredit → dilution par excès de contexte non pertinent
  • La facture explose → pas de mise en cache des préfixes

Résoudre le contexte, c’est résoudre la moitié des problèmes.


La gestion du contexte est le savoir-faire le plus sous-estimé du domaine. Pour une analyse de vos cas d’usage et de l’architecture adaptée, demandez un diagnostic.