Fenêtre de contexte d'un agent LLM : ce qu'elle contient et pourquoi l'agent oublie les règles

Qu'est-ce que la fenêtre de contexte d'un LLM

La fenêtre de contexte d'un LLM est l'ensemble du texte que le modèle reçoit en entrée pour générer sa réponse suivante. Le modèle n'a pas de mémoire au sens humain : tout ce qu'il « sait » de votre tâche à un instant donné se trouve dans cette fenêtre. Ce qui n'est pas dans la fenêtre n'existe pas pour lui.

La taille de la fenêtre se mesure en tokens, c'est-à-dire en fragments de mots. Pour le français comme pour le russe, un token couvre en moyenne moins de texte qu'en anglais, si bien qu'une même instruction coûte souvent davantage de tokens. Les modèles actuels ont des fenêtres de plusieurs centaines de milliers de tokens, et l'on pense que la place suffira pour tout. En pratique, la place d'un agent s'épuise plus vite qu'on ne l'imagine, et il commence à moins bien travailler encore plus tôt.

Ce qui entre dans la fenêtre de contexte d'un agent

Un agent de programmation dispose de trois sources d'information : le prompt système qui décrit la tâche, le contenu des fichiers qu'il a lus, et les sorties des outils qu'il a appelés. Toutes trois vivent dans la même fenêtre et se disputent la place.

Point essentiel : rien de tout cela ne disparaît de lui-même. Le journal des tests qui ont échoué, utile il y a vingt étapes, reste dans la fenêtre et détourne l'attention de l'étape en cours. Une longue session est une meule qui ne cesse de grossir, où il est de plus en plus difficile de retrouver l'aiguille.

Pourquoi l'agent oublie les règles dans une longue session

Plainte fréquente : au début de la session, l'agent respecte soigneusement les règles du CLAUDE.md, puis au bout d'une heure il commence à les enfreindre. Il ne les a pas « oubliées » au sens strict : le texte des règles est toujours dans la fenêtre. Le problème tient à la façon dont le modèle répartit son attention sur un long texte.

Lost in the middle

Une étude de Liu et coauteurs, publiée en 2023, a montré que les modèles de langage exploitent nettement mieux les informations placées au début et à la fin d'un long contexte que celles du milieu. Le fichier d'instructions est chargé au début de la session, mais à mesure que la conversation avance, du texte s'accumule au-dessus et en dessous. La règle qui était bien visible se retrouve peu à peu dans la zone où le modèle « voit » le moins bien.

La part des règles dans la fenêtre diminue

Dans une session neuve, les instructions représentent une part notable du contexte. Après une centaine d'appels d'outils, elles deviennent un petit fragment au milieu des journaux, des diffs et du code lu. Le signal est le même, mais le bruit autour est des dizaines de fois plus important.

Les exemples récents l'emportent sur les anciennes règles

Le modèle s'appuie fortement sur ce qui s'est passé récemment dans la conversation. Si l'agent a plusieurs fois contourné une règle et que cela lui a été pardonné, ce schéma pèse dans l'historique davantage qu'une ligne d'instruction quelque part au début.

Context rot : la dégradation avant la limite de la fenêtre

Context rot (« pourrissement du contexte ») désigne l'effet par lequel la qualité des réponses baisse à mesure que la fenêtre se remplit, alors même que la limite technique est encore loin. Le modèle accepte formellement 200 000 tokens, mais avec 150 000 il travaille moins bien qu'avec 20 000 : il confond davantage de détails, reprend des solutions déjà écartées, perd des instructions.

Signes qu'une session « a pourri » :

• l'agent propose une approche que vous avez ensemble rejetée il y a une demi-heure ;
• il confond les noms de fichiers et de fonctions déjà discutés ;
• il cesse de lancer les contrôles qu'il lançait lui-même au début ;
• les réponses deviennent plus longues et plus floues, des « j'ai aussi corrigé… » apparaissent.

Ajouter une règle de plus ne sert à rien : la nouvelle règle se perdra dans le même bruit. Il faut réduire le bruit.

La compaction du contexte

La compaction consiste à compresser l'historique de la session : le modèle rédige un résumé de ce qui s'est passé, et la conversation continue à partir de ce résumé au lieu de l'historique complet. La fenêtre se libère, et l'essentiel du travail semble préservé.

Dans Claude Code, la commande /compact permet de lancer cette compaction, avec une indication sur ce qu'il faut privilégier. Lorsque la fenêtre approche de la limite, Claude Code effectue aussi la compaction automatiquement. La commande /clear efface entièrement l'historique et repart de zéro, et /context montre ce qui occupe la fenêtre.

/context
/compact conserve : objectif de la tâche, décisions prises avec leurs raisons, liste des fichiers modifiés, ce qui reste à vérifier
/clear

Ce qui est dangereux dans la compaction

Un résumé perd toujours des détails. Le résumé peut omettre la solution écartée et la raison du rejet, la formulation exacte d'une exigence ou une précision convenue en passant. Après la compaction, l'agent travaille avec le résumé de sa propre session, écrit par quelqu'un d'autre. C'est pourquoi les éléments importants se conservent mieux dans des fichiers qui survivront à n'importe quelle compaction, et non dans l'historique de la conversation.

Compaction ou nouvelle session

Comment économiser la fenêtre de contexte

Économiser le contexte ne concerne pas le prix des tokens, mais la qualité du travail. Moins il y a de bruit dans la fenêtre, plus l'attention va à la tâche et aux règles.

1. Un fichier d'instructions court, qui sert de routeur

Le CLAUDE.md ou l'AGENTS.md d'entrée est lu en entier à chaque session. Un fichier de 600 lignes représente environ 10 000 à 20 000 tokens de coût permanent. Gardez-y les commandes de vérification, les contraintes strictes et la carte du projet, et placez les détails par thème dans des documents séparés, que l'agent n'ouvre qu'en cas de besoin.

2. Des connaissances chargées à la demande

Dans les skills de Claude Code, seule leur brève description entre au départ dans le contexte ; le texte complet de l'instruction ne se charge que lorsque le skill est nécessaire à la tâche. C'est une bonne manière de garder à portée de main les procédures rares — déploiement, migrations, publication — sans les payer à chaque session.

3. Des subagents pour le travail bruyant

Un subagent travaille dans sa propre fenêtre de contexte et ne renvoie à la session principale que le résultat. La recherche dans un grand code, l'analyse d'un long journal, l'étude d'un module inconnu : tout cela peut être confié à un subagent, qui renvoie quelques paragraphes de conclusions au lieu de milliers de lignes de sortie brute.

4. Des sorties d'outils silencieuses

Les sorties de commandes sont le principal consommateur de la fenêtre. Configurez les commandes de vérification pour qu'elles n'impriment qu'une ligne en cas de succès, et seulement l'essentiel en cas d'erreur : le test qui a échoué et son message, et non le journal complet du build.

# bruyant : des milliers de lignes dans la fenêtre à chaque exécution
pytest -v

# silencieux : en cas de succès une ligne, en cas d'échec seulement les tests en erreur
pytest -q --tb=short

# journal : non pas en entier, mais seulement la fin et les erreurs
tail -n 50 app.log | grep -i error

5. Une tâche, une session

Ne faites pas passer une seule session par trois tâches sans rapport. L'historique de la première tâche ne sert à rien pour la troisième, mais il occupe de la place et brouille l'agent. Une fois la tâche finie et le résultat fixé, ouvrez une nouvelle session.

6. L'état dans des fichiers, et non dans l'historique

Tout ce qui doit survivre à la compaction et à une nouvelle session doit être écrit dans le dépôt : objectif, décisions prises avec leurs raisons, solutions écartées, ce qui a été fait et comment on l'a vérifié, prochaine étape. Par exemple, dans PLAN.md et PROGRESS.md. La nouvelle session commence alors non pas par un récit, mais par un document précis, et vous pouvez sans crainte effacer l'historique.

# PROGRESS.md
## Objectif
Passer le calcul des remises aux centimes entiers

## Fait (vérifié)
- app/payments/discount.py : float → int, make test vert
- Migration 041 ajoutée, appliquée en local

## Décisions
- Arrondi bancaire, comme chez le prestataire de paiement

## Écarté
- Decimal dans le modèle : casse la sérialisation des webhooks

## Prochaine étape
Mettre à jour le scénario e2e de la commande et lancer make e2e

Les règles critiques ne doivent pas reposer seulement sur la fenêtre

Même un contexte parfaitement organisé ne garantit pas le respect des règles : le texte dans la fenêtre influence le modèle, mais ce n'est pas une interdiction exécutable. Si une violation est inacceptable, la règle doit être vérifiée mécaniquement. Dans Claude Code, cela passe par les hooks — commandes lancées lors des événements de l'agent, capables de bloquer une action — et par les réglages de droits qui interdisent certains outils ou certaines commandes. Les linters, les tests et la CI fonctionnent indépendamment de ce qui se passe dans la fenêtre de l'agent.

Bonne règle de harnais : tout ce qui peut être vérifié automatiquement l'est, et la fenêtre de contexte ne conserve que ce qui demande du jugement.

En résumé

La fenêtre de contexte d'un LLM est le seul endroit où l'agent voit votre tâche, et elle se remplit plus vite qu'il n'y paraît : les instructions, l'historique, les fichiers lus et les sorties de commandes s'accumulent jusqu'à la fin de la session. La qualité baisse bien avant la limite technique, les règles situées au milieu d'un long contexte se perdent, et la compaction sauve de la place au prix des détails. Gardez des instructions courtes, chargez les connaissances rares à la demande, confiez le travail bruyant aux subagents, conservez l'état dans des fichiers, et appuyez les règles critiques par des hooks et des contrôles. Le travail avec le contexte de l'agent est présenté en pratique dans le cours sur l'ingénierie des harnais.