Optimiser le contexte d'une IA : faire plus avec moins

En bref

• La fenêtre de contexte n'est pas un disque dur. Plus on la remplit, plus le modèle a du mal à retrouver l'information utile : c'est documenté par la recherche, pas une impression.
• Le plus gros gain est gratuit : des consignes courtes et structurées, un fichier d'instructions de projet, et des tâches découpées.
• La mise en cache des prompts réduit fortement le coût et la latence des parties qui se répètent, à condition de mettre le contenu stable en premier.
• Chercher plutôt que tout coller : un agent qui va lire le bon fichier au bon moment bat presque toujours un prompt de 200 pages.
• Un résumé peut avoir l'air parfait et avoir perdu l'essentiel. La seule façon de le savoir, c'est de le tester avec des questions.
• J'en parle d'expérience, y compris de mes erreurs, et de HCS, le projet open source que je développe sur ce problème, encore expérimental.

Ce qu'est vraiment la fenêtre de contexte

Un modèle de langage ne « se souvient » de rien entre deux requêtes. À chaque appel, on lui envoie un bloc de texte, découpé en tokens, et il répond à partir de ce bloc uniquement. Ce bloc, c'est le contexte. Sa taille maximale, c'est la fenêtre de contexte.

Quand on discute avec un assistant, on a l'impression d'une conversation continue. En réalité, à chaque message, l'application renvoie tout ou partie de l'historique. Avec un agent de code, c'est encore plus net : le contexte se remplit à une vitesse surprenante.

Ce qui remplit le contexte, concrètement

Sur une session de travail réelle avec un agent, voici ce qui occupe la fenêtre, dans l'ordre où je le vois grossir :

1. Les instructions système de l'outil lui-même, que l'on ne voit pas.
2. Les définitions d'outils : chaque outil disponible (lire un fichier, lancer une commande, chercher sur le web) est décrit au modèle, avec ses paramètres.
3. Les fichiers d'instructions de projet (AGENTS.md, CLAUDE.md) et la mémoire persistante.
4. L'historique de la conversation : vos messages et ses réponses.
5. Les résultats d'outils : le contenu des fichiers lus, la sortie des commandes, les pages web consultées. C'est presque toujours le poste le plus lourd.
6. Les documents collés par l'utilisateur.

Un seul fichier de 2 000 lignes lu en entier, une commande qui affiche un long journal d'erreurs ou une page web complète peuvent peser plus lourd que tout le reste de la conversation.

Ce que coûte un contexte trop plein

Le prix. Les API facturent chaque token d'entrée, à chaque appel. Un contexte de 100 000 tokens renvoyé dix fois, ce sont un million de tokens d'entrée facturés. Pour estimer l'impact selon le modèle, utilisez le calculateur de coût d'API.

La latence. Le modèle doit lire tout le contexte avant de produire le premier mot. Plus il est long, plus l'attente est longue.

La qualité. C'est le point le plus contre-intuitif, et il est bien documenté :

• L'étude Lost in the Middle (Liu et al., publiée dans Transactions of the Association for Computational Linguistics) a montré que les modèles retrouvent mieux une information placée au début ou à la fin d'un long contexte qu'au milieu, y compris des modèles conçus pour les longs contextes (arXiv 2307.03172).
• En juillet 2025, l'équipe de recherche de Chroma a testé 18 modèles et conclu que leurs performances deviennent de moins en moins fiables à mesure que l'entrée s'allonge, même sur des tâches simples, et de manière irrégulière (Context Rot).
• Anthropic résume le principe dans son article sur l'ingénierie du contexte : le contexte doit être traité comme une ressource limitée, aux rendements décroissants (Effective context engineering for AI agents).

Une grande fenêtre de contexte est une capacité, pas un objectif. Le bon contexte est le plus petit ensemble d'informations qui permet au modèle de bien faire la tâche.

Les leviers, du plus simple au plus avancé

1. Des consignes courtes, structurées et précises

C'est le levier le plus rentable, et il ne coûte rien.

Quand l'utiliser : toujours.

Ce qui marche :

• Dire l'objectif en une phrase, puis le contexte utile (pas toute l'histoire), puis les contraintes, puis le format de sortie attendu.
• Remplacer les longues explications par des listes et des exemples courts.
• Retirer ce qui ne change pas la réponse : politesses répétées, historique du projet, détails « au cas où ».
• Demander explicitement une réponse courte quand c'est possible : la sortie se paie aussi, et elle revient dans le contexte au tour suivant.

Exemple : au lieu de coller tout un fichier et d'écrire « regarde ce qui ne va pas », je colle la fonction concernée, le message d'erreur exact et une phrase : « Ce test échoue depuis l'ajout du cache ; trouve la cause et propose le correctif minimal. » La bibliothèque de prompts applique cette structure à 30 cas courants.

2. Un fichier d'instructions de projet

Au lieu de réexpliquer le projet à chaque session, on l'écrit une fois dans un fichier que l'agent charge automatiquement : AGENTS.md (format ouvert, voir agents.md), CLAUDE.md pour Claude Code (documentation de la mémoire de Claude Code), ou leurs équivalents.

Quand l'utiliser : dès qu'un projet dure plus d'une session.

Ce qu'il doit contenir : les commandes (installer, compiler, tester), la structure des dossiers, les conventions, les zones à ne jamais toucher, et les règles de vérification. Pas la documentation complète du projet.

Le piège : un fichier d'instructions trop long se dilue lui-même, et il est relu à chaque session. Une ou deux pages suffisent. Le générateur de fichier d'instructions produit une base propre, avec un score de qualité.

3. Découper les tâches, et utiliser des sous-agents

Une seule session qui fait « tout le refactoring du site » finit saturée de résultats d'outils qui ne servent plus. Plusieurs sessions courtes, chacune avec un objectif clair, gardent un contexte propre.

Quand l'utiliser : pour toute tâche qui touche plus de quelques fichiers, ou qui mélange recherche et modification.

Les sous-agents poussent l'idée plus loin : un agent principal confie une sous-tâche (explorer un dossier, vérifier des faits, écrire un fichier) à un sous-agent qui travaille dans son propre contexte, puis ne renvoie qu'un résumé. Le contexte principal ne reçoit que la conclusion, pas les centaines de lignes lues pour y arriver. C'est l'une des architectures décrites par Anthropic dans l'article cité plus haut.

Exemple vécu : pour écrire les guides de ce Lab, j'ai confié chaque guide à un agent séparé, avec un cahier des charges précis. L'agent principal n'a reçu que le compte rendu de chacun : nombre de mots, sources vérifiées, limites. Sans ce découpage, la session principale aurait été noyée sous les recherches web.

4. La mise en cache des prompts

Quand une grande partie du contexte se répète d'un appel à l'autre (instructions système, définitions d'outils, document de référence), les grands éditeurs proposent de la garder en cache. Les appels suivants qui commencent par le même début sont alors traités plus vite et facturés moins cher.

Comment ça marche, selon la documentation officielle :

Sources : OpenAI, Anthropic, Google. Les tarifs exacts changent souvent : le calculateur de coût d'API applique les remises publiées, avec leur date de vérification.

La règle d'or, commune aux trois : mettre le contenu stable en premier (instructions, outils, documents de référence) et le contenu variable à la fin (la question du jour, la date, les données de l'utilisateur). Un seul caractère modifié au début, et tout le cache qui suit est perdu.

Les pièges :

• Une date ou un identifiant de session placé tout en haut du prompt casse le cache à chaque appel.
• Modifier la liste ou l'ordre des outils invalide le cache chez Anthropic, et dégrade la réutilisation chez OpenAI.
• Chaque éditeur a une taille minimale en dessous de laquelle rien n'est mis en cache, sans message d'erreur. Vérifiez dans les champs d'usage de la réponse que le cache est réellement utilisé.

Quand l'utiliser : chatbots avec de longues instructions, assistants qui interrogent toujours le même document, agents qui enchaînent beaucoup d'appels.

5. Chercher plutôt que tout coller (RAG et lecture à la demande)

Coller toute la documentation dans le prompt « pour être sûr » est l'erreur la plus fréquente. Deux alternatives :

• La récupération de documents (RAG). Les documents sont découpés et indexés à l'avance. À chaque question, on ne fournit au modèle que les quelques passages les plus pertinents. L'approche a été formalisée par Lewis et al. (arXiv 2005.11401).
• La lecture à la demande. C'est ce que font les agents de code : au lieu de tout charger, ils gardent des références (chemins de fichiers, requêtes) et vont lire le contenu au moment où ils en ont besoin, avec leurs outils de recherche. Anthropic décrit les deux approches et leurs compromis : la lecture à la demande est plus lente, d'où des approches hybrides.

Quand l'utiliser : dès que la base de connaissances dépasse ce qu'on relirait soi-même pour répondre à une question. Une FAQ de deux pages peut être collée ; un catalogue de 3 000 produits ou un dépôt de code complet, non.

Le piège du RAG : si la recherche ramène les mauvais passages, le modèle répond avec assurance à partir de mauvaises informations. Un bon RAG se teste, avec des questions dont on connaît la réponse, comme on le verra plus bas.

Pour connecter une IA à vos documents, à vos outils et à vos machines (API, MCP, agents), voir le guide frère Connecter une IA à vos outils et à vos machines.

6. Résumer et compacter les longues sessions

Quand une conversation approche de la limite de la fenêtre, les outils récents la compactent : ils remplacent l'historique par un résumé et repartent de là. Une forme plus légère consiste à effacer les vieux résultats d'outils, qui ne servent plus.

C'est indispensable pour les longues sessions. C'est aussi là que se cachent les pertes les plus sournoises.

Mon vécu, sans enjoliver. Sur une très longue session de travail sur ce site, la conversation a été compactée automatiquement. Le résumé était bon dans l'ensemble. Mais un détail avait disparu : il existait deux formulaires différents, un pour prévenir les visiteurs de la sortie d'une application, et un Google Form pour inscrire les testeurs. Après la compaction, l'agent les a confondus, puis m'a demandé une adresse qu'il aurait pu trouver lui-même dans les fichiers du serveur. Rien de grave, mais exactement le type d'erreur qu'un résumé produit : il garde le sujet, il perd la distinction.

Ce qui limite les dégâts :

• Avant une compaction, demander à l'agent d'écrire l'état du travail dans un fichier : décisions prises, fichiers modifiés, prochaines étapes, pièges connus.
• Après une compaction, exiger que l'agent vérifie dans les fichiers plutôt que de se fier à sa mémoire. C'est d'ailleurs une règle que j'ai ajoutée à mes fichiers d'instructions : « vérifier dans le dépôt plutôt que supposer ».
• Préférer plusieurs sessions courtes, chacune démarrée avec un état écrit, à une session interminable.

7. La mémoire persistante et les notes de projet

Les notes écrites hors de la fenêtre de contexte, puis relues au besoin, sont la forme la plus robuste de mémoire. Anthropic décrit cette technique comme une prise de notes structurée : l'agent écrit régulièrement des notes conservées hors du contexte, et les recharge plus tard.

Ce que je garde en notes, pour chaque projet :

• les chemins, services et commandes du serveur ;
• les décisions prises et leur raison (« pourquoi on ne fait pas X ») ;
• les pièges déjà rencontrés et leur solution ;
• les préférences de la personne avec qui je travaille.

Ce que je n'y mets jamais : les secrets (mots de passe, jetons, clés d'API). Une note de projet est lue par l'agent à chaque session : un secret qui s'y trouve finit tôt ou tard dans une conversation. Avant de coller un texte sensible dans une IA, l'anonymiseur remplace les données personnelles et les clés par des repères.

Le piège : une note fausse est pire que pas de note, car l'agent la croit. Une mémoire se relit et se corrige, comme un fichier d'instructions.

8. Les budgets de tokens

Dernier levier, plus technique : fixer une limite et choisir ce qui entre dedans.

• Plafonner la longueur des réponses quand on n'a pas besoin d'un roman.
• Tronquer les sorties d'outils : les 50 dernières lignes d'un journal suffisent souvent.
• Adapter le contexte au modèle : un petit modèle local a une fenêtre plus courte et souffre plus vite d'un contexte chargé. Le calculateur de matériel pour IA locale montre aussi combien de mémoire le contexte lui-même consomme (le cache KV).

Mesurer ce qu'on perd

Pourquoi un résumé « a l'air bon »

Un résumé est rédigé pour être lisible. Il garde la structure générale et les mots clés. Ce qu'il perd, ce sont les exceptions, les chiffres précis et les distinctions (deux formulaires qui se ressemblent, deux versions d'une règle, une option désactivée « pour l'instant »). Or ce sont souvent elles qui provoquent les erreurs.

Relire le résumé ne suffit pas, car on le compare à ce dont on se souvient, pas à la source.

La méthode des questions-tests

La seule méthode fiable que je connaisse : poser des questions dont la réponse se trouve dans la source, et vérifier si le modèle, avec le seul résumé, y répond correctement.

1. Écrire 10 à 30 questions précises : « Quel en-tête porte la clé d'idempotence ? », « Quelle est la branche par défaut ? », « Quelle permission manque au jeton ? ».
2. Noter la réponse exacte, avec l'endroit de la source où elle se trouve.
3. Poser les questions au modèle avec le résumé, puis sans aucun contexte : la différence montre ce que le résumé apporte vraiment.
4. Compter les réponses justes, fausses, et les « je ne sais pas ». Une réponse fausse donnée avec assurance est le pire cas.

C'est la même idée que les plans de test du concepteur d'assistant IA, appliquée au contexte. Plusieurs outils existent déjà pour mesurer une compression ou un résumé avec des questions, par exemple la méthode d'évaluation par sondes publiée par Factory, la métrique de résumé de DeepEval ou la fidélité de Ragas : ce sont des méthodes et des métriques, pas des formats de fichier.

HCS : mon projet open source sur ce problème

C'est en butant sur ces limites que j'ai lancé HCS (Holographic Context Standard), un projet open source sous licence MIT (github.com/Oufrid/HCS, présenté dans les projets du Lab).

L'idée : un fichier de contexte où chaque affirmation cite sa source, et qui sait dire quand il devient faux.

• Traçable : chaque affirmation pointe vers un passage précis (une fonction, une classe, un titre, une plage de lignes).
• Vérifiable : chaque citation porte une empreinte (hash) du texte cité. La commande hcs check détecte, sans IA, les affirmations dont la source a changé ; elle ignore le simple reformatage et suit le code qui a seulement été déplacé. Elle peut bloquer l'intégration continue.
• Mesuré : le fichier embarque des questions-tests dont la réponse est vérifiée mot pour mot dans la source, et hcs score calcule un score de fidélité pour un modèle donné, avec un intervalle de confiance et une comparaison sans contexte.
• Servi par MCP : un serveur intégré permet au modèle de lire d'abord les affirmations compactes, puis d'ouvrir la source exacte quand il en a besoin.

Ce qu'il faut savoir honnêtement :

• HCS est expérimental (version 0.2). Le format, la vérification sans IA et le serveur MCP sont terminés et testés.
• Les fonctions qui font appel à une IA (compiler un fichier, mesurer la fidélité) sont implémentées et testées contre des serveurs simulés, mais n'ont pas encore été mesurées sur de vrais modèles. Les résultats seront publiés avec leurs données brutes, pas comme des promesses.
• Aucune des idées n'est nouvelle prise isolément. HCS les combine dans un format portable. Il complète les formats existants (AGENTS.md, CLAUDE.md, llms.txt), les empaqueteurs de dépôt comme Repomix, la carte de dépôt d'Aider ou les détecteurs de dérive de documentation, plutôt qu'il ne les remplace.

Si le sujet vous intéresse, les retours et les corrections sont les bienvenus sur le dépôt.

Tableau récapitulatif

Les erreurs fréquentes

• Tout coller « pour être sûr ». Le modèle se perd au milieu, et la facture monte.
• Une date en haut du prompt. Le cache est perdu à chaque appel.
• Un fichier d'instructions de dix pages. Il se dilue et coûte à chaque session.
• Faire confiance à un résumé parce qu'il est bien écrit. La lisibilité n'est pas la fidélité.
• Laisser une session courir pendant des heures sans jamais écrire l'état du travail.
• Mettre des secrets dans les notes de projet, qui sont relues à chaque session.
• Choisir le modèle à plus grande fenêtre pour compenser un contexte mal organisé.

La checklist

1. Ma consigne tient-elle en objectif, contexte utile, contraintes, format ?
2. Mon projet a-t-il un fichier d'instructions court et à jour ?
3. Cette tâche peut-elle être découpée, ou confiée à un sous-agent ?
4. Le contenu stable est-il au début du prompt, et le variable à la fin ?
5. Ai-je vérifié dans les champs d'usage que le cache fonctionne ?
6. Est-ce que je colle un document entier alors qu'une recherche suffirait ?
7. Avant une longue session, ai-je prévu un fichier d'état ?
8. Après une compaction, l'agent vérifie-t-il dans les fichiers ?
9. Mes notes de projet sont-elles exactes, et sans secret ?
10. Ai-je testé mon résumé ou mon RAG avec des questions dont je connais la réponse ?

FAQ

Une plus grande fenêtre de contexte règle-t-elle le problème ?

Non. Elle repousse la limite, mais la recherche montre que les modèles exploitent moins bien les informations noyées dans un long contexte, en particulier au milieu. Une grande fenêtre est utile pour les cas qui l'exigent, pas comme dispense d'organiser le contexte.

La mise en cache change-t-elle la réponse du modèle ?

Non. Elle évite seulement de retraiter un début de prompt identique. Le modèle reçoit le même contenu ; seuls le coût et le délai changent.

Faut-il un RAG pour un petit site ou une petite FAQ ?

Pas forcément. Si tout le contenu utile tient en quelques pages, le coller dans les instructions, avec la mise en cache, est souvent plus simple et plus fiable. Le RAG devient intéressant quand la base dépasse ce que le modèle peut lire efficacement à chaque question.

Comment savoir si mon agent a perdu des informations après une compaction ?

Posez-lui des questions précises sur les décisions et les distinctions importantes du projet, et comparez avec vos notes. Mieux : avant la compaction, faites écrire l'état du travail dans un fichier, et demandez à l'agent de s'y référer.

HCS est-il prêt pour un usage en production ?

Pas encore. La vérification sans IA et le serveur MCP sont testés, mais les fonctions de compilation et de mesure n'ont pas encore été validées sur de vrais modèles. C'est un projet expérimental, à essayer en connaissance de cause.

Les petits modèles locaux souffrent-ils plus d'un long contexte ?

En général, leur fenêtre est plus courte, et le contexte consomme de la mémoire sur votre machine. Un contexte serré est donc encore plus important en local. Le calculateur de matériel montre la mémoire prise par le contexte selon le modèle.

Optimiser le contexte, est-ce seulement une question de coût ?

Non. Le coût est le plus visible, mais le gain principal est souvent la qualité : un contexte propre réduit les confusions, les oublis et les réponses inventées.

---

Vous voulez un assistant ou une automatisation qui reste fiable et maîtrisée en coût, avec un contexte bien conçu dès le départ ? C'est exactement ce que je mets en place dans mon service IA et automatisation. Parlons de votre projet.