Ingénierie du contexte pour les agents IA : ce qui entre vraiment dans la fenêtre de contexte

Table des matières

Publié en août 2026.

TL;DR: L’ingénierie du contexte est la discipline qui consiste à décider quels tokens méritent une place dans la fenêtre de contexte d’un agent à chaque étape — instructions système, définitions d’outils, données récupérées et historique de conversation se disputent tous le même espace limité. L’ingénierie de prompt demande comment formuler ceci ; l’ingénierie du contexte demande ce que le modèle a réellement besoin de savoir maintenant. Le mode d’échec habituel n’est pas trop peu de contexte — c’est trop : historique obsolète, schémas d’outils non pertinents et documents récupérés que personne n’a demandés, qui diluent tous le signal et font grimper le coût. J’applique un budget fixe par catégorie, je coupe l’historique avant l’identité, et je résume avant de tronquer.

Lecture de l’opérateur : Les agents les plus difficiles à déboguer n’échouaient pas parce que le modèle était faible. Ils échouaient parce que j’avais laissé la fenêtre de contexte devenir un tiroir fourre-tout : six schémas d’outils dont la tâche n’avait pas besoin, un historique de conversation qui avait dérivé de 40 tours par rapport à la demande initiale, un document récupéré techniquement pertinent et pratiquement inutile. Corriger le prompt n’aidait pas. Corriger ce qu’il y avait devant le prompt, si.

L’ingénierie de prompt vous a donné un agent qui fonctionne. L’ingénierie du contexte, c’est ce qui le maintient fonctionnel une fois qu’il gère du vrai volume, un vrai historique et de vrais cas limites — et c’est la compétence à laquelle je consacre désormais plus de temps qu’à la formulation du prompt.

L’ingénierie de prompt et l’ingénierie du contexte ne sont pas le même métier

Un prompt est une instruction. Le contexte, c’est tout ce que le modèle voit en agissant sur cette instruction : le prompt système, les outils qu’il peut appeler, ce que vous avez récupéré ou consulté, et la quantité de conversation ou d’historique d’exécution que vous avez décidé de conserver. L’ingénierie de prompt optimise la formulation de la première chose. L’ingénierie du contexte optimise la composition des quatre.

Cette distinction compte en pratique, pas seulement dans le vocabulaire. Si j’écris un prompt parfaitement calibré et que je donne à l’agent cinq schémas d’outils non pertinents et quarante tours d’historique obsolète, la formulation n’a plus d’importance — le modèle raisonne sur un contexte majoritairement composé de bruit. Chacun de mes agents qui est passé de « fonctionne en démo » à « fonctionne à 3h du matin sur une entrée bizarre » y est arrivé en corrigeant ce qu’il y avait dans la fenêtre, pas en reformulant les instructions à l’intérieur.

Les quatre éléments qui se disputent l’espace

À chaque tour, quatre catégories se battent pour le même espace limité :

1. Instructions système — identité, règles, format de sortie. Voir les cinq couches que j’utilise pour les prompts système — c’est la seule catégorie qui devrait rester quasiment fixe, parce que le prompt caching ne paie que si le préfixe ne bouge pas.
2. Définitions d’outils — les schémas de chaque outil que l’agent pourrait appeler ce tour-ci, qu’il en ait besoin ou non.
3. Données récupérées — tout ce qui est extrait d’une base de données, d’un vector store ou d’un appel API : mémoire, documents, fiches clients.
4. Historique de conversation ou d’exécution — ce qui s’est déjà passé dans cette session ou cette exécution.

Aucune de ces catégories n’est gratuite. Chaque token, quelle que soit sa catégorie, est un token que le modèle doit peser face à tous les autres pour décider quoi faire ensuite, et chaque token est un token que vous payez à chaque requête qui n’est pas un hit de cache.

L’erreur, c’est presque toujours trop, pas trop peu

Quand un agent se comporte mal, le réflexe est d’ajouter du contexte — plus d’instructions, plus de contexte de fond, plus d’historique « au cas où ». D’après mon expérience, c’est souvent l’inverse qu’il faut faire.

Trop de schémas d’outils. J’ai vu un agent appeler le mauvais outil non pas parce que le bon manquait, mais parce qu’il était enterré derrière six autres dont il n’avait pas besoin pour cette tâche. N’envoyez que les outils pertinents pour l’étape en cours, pas toute la boîte à outils à chaque appel. Une couche de routage qui décide quel sous-ensemble d’outils exposer est bon marché à construire et se rentabilise dès la première fois qu’elle évite un mauvais appel.

Historique de conversation obsolète. Un agent de support qui traîne 60 tours d’historique venant de trois incidents sans rapport n’est pas en train de « se souvenir du client » — il dilue la requête actuelle avec du bruit non pertinent, et agit parfois sur quelque chose qui n’est plus vrai. C’est exactement le mode d’échec qu’une mémoire épisodique avec une fenêtre bornée est censée empêcher, et il vaut la peine de vérifier si votre fenêtre est vraiment bornée ou si elle a grossi sans limite en silence.

Documents récupérés que personne n’a demandés. Une récupération sémantique qui renvoie les 10 fragments « les plus similaires » au lieu des 2 pertinents enterre la réponse sous une distraction d’apparence plausible. Plus de contexte récupéré n’est pas plus de signal — passé un certain seuil, c’est activement pire, car le modèle doit travailler davantage pour trouver la partie qui compte.

Instructions répétées par prudence défensive. Je vois cela dans des prompts qui répètent la même règle de quatre façons différentes parce qu’une version antérieure de l’agent l’a ignorée une fois. C’est un signal que la règle devait être déplacée plus tôt dans le prompt ou imposée structurellement (une contrainte dans le schéma d’un outil, une étape de validation) — pas un signal pour remplir le contexte de répétitions.

Le budget que j’applique réellement

Sur plus de 30 agents en production, je fixe un budget de tokens explicite par catégorie avant de construire l’agent, pas après qu’il commence à mal se comporter :

L’ordre de cette dernière colonne est le véritable cadre de décision : d’abord l’historique, puis la largeur de récupération, puis le périmètre des outils, et les instructions système en dernier. L’historique est le moins coûteux à compresser sans perdre en exactitude — un résumé de deux phrases de « ce qui s’est passé dans les tours 1 à 30 » apporte généralement la même valeur opérationnelle que la transcription complète. Couper les instructions système est le plus dangereux, car c’est là que réside le comportement réel de l’agent.

Résumez avant de tronquer

La troncature — supprimer simplement les tours les plus anciens — en est la version brute. Ça marche jusqu’à ce que le tour supprimé contienne le seul fait dont l’agent avait besoin. Le meilleur schéma est la compaction : avant de supprimer l’historique brut, le condenser en un résumé structuré court qui capture les décisions et les faits, et conserver ce résumé de façon permanente même après la disparition des tours bruts.

// workers/compact-history.ts

interface HistoryDigest {
  summary: string; // 2-3 phrases : ce qui a été décidé, résolu, ou reste ouvert
  keyFacts: Record<string, string>; // faits stables qui valent la peine d'être conservés tels quels
  turnCount: number; // combien de tours bruts ce résumé remplace
}

async function compactIfNeeded(
  history: ConversationTurn[],
  env: Env
): Promise<{ digest: HistoryDigest | null; recent: ConversationTurn[] }> {
  const RECENT_WINDOW = 10;
  if (history.length <= RECENT_WINDOW) {
    return { digest: null, recent: history };
  }

  const toCompact = history.slice(0, -RECENT_WINDOW);
  const recent = history.slice(-RECENT_WINDOW);

  // Un modèle bon marché qui résume suffit presque toujours pour cette étape
  const digest = await summarizeTurns(toCompact, env);
  return { digest, recent };
}

C’est le même principe qu’un eval harness transformant chaque échec de production en cas de test permanent (voir le eval harness que j’utilise pour livrer des agents IA) : ne jetez pas l’information, compressez-la sous une forme bon marché à conserver et toujours utile. Les tours bruts sont jetables. Les faits qu’ils contiennent, généralement, ne le sont pas.

Récupération : moins de résultats, mais plus pertinents, valent mieux que plus de résultats

La même discipline s’applique à tout ce qui est extrait d’un vector store ou d’une base de données. La tentation est de récupérer généreusement — top-10, top-20 — sur la théorie que plus de contexte ne peut pas faire de mal. Si, ça peut. Chaque fragment non pertinent est un fragment que le modèle doit lire, peser et écarter, et un tas suffisamment grand de quasi-correspondances peut peser plus lourd que le seul fragment qui répond vraiment à la question.

Par défaut, je commence avec un k petit (2-4) et je ne l’élargis que si je peux démontrer, avec des cas réels, que la réponse manque véritablement à cette largeur — pas parce qu’un filet plus large paraît plus sûr. Si la qualité de la récupération est incohérente, la solution est généralement une meilleure requête ou une étape de re-ranking, pas un k plus grand.

Reliez cela au coût et à la justesse

L’ingénierie du contexte n’est pas seulement un problème de qualité — c’est le levier individuel le plus important sur ce que coûte l’exécution d’un agent, car la plupart des charges de travail d’agents facturent bien plus les tokens en entrée que ceux en sortie. Une fenêtre de contexte surchargée est une facture surchargée avant d’être un bug de comportement. Si vous n’avez pas consulté le calcul de coût pour choisir entre niveaux de modèle, le budget de contexte que vous appliquez change directement ce calcul : un contexte plus petit et bien délimité rend un modèle moins cher viable pour davantage de vos tâches, parce qu’on ne demande pas au modèle de chercher une aiguille dans une botte de foin inutilement grande.

Chaque agent que j’exploite tourne sur Claude, et la décision de niveau de modèle n’a de sens qu’une fois le budget de contexte fixé — comparer des coûts sur un contexte surchargé et mal délimité ne vous dit rien sur ce dont la tâche a réellement besoin.

Et parce que modifier ce qu’il y a dans la fenêtre de contexte change le comportement tout autant qu’un changement de prompt, chaque changement de contexte passe par le même sas qu’un changement de prompt : le faire tourner contre le jeu d’évaluations construit à partir de vrais échecs de production avant de le déployer. Réduire l’historique ou resserrer la largeur d’une récupération est exactement le genre de changement « évidemment sûr » qui fait régresser silencieusement un cas limite si vous ne vérifiez pas.

Le bilan de l’opérateur

L’ingénierie du contexte, c’est décider, à chaque tour, ce qui mérite une place dans une fenêtre limitée — et l’échec par défaut est d’en inclure trop, pas trop peu. Gardez les instructions système stables et en dernier recours à couper. Limitez les définitions d’outils à l’étape en cours. Récupérez étroitement et n’élargissez qu’avec des preuves. Compactez l’historique en résumés avant de le jeter, et coupez d’abord les tours bruts les plus anciens. Puis vérifiez chaque changement contre vos évaluations, car les changements de contexte modifient le comportement exactement comme les changements de prompt — c’est juste plus facile de faire semblant que non.

FAQ

Qu’est-ce que l’ingénierie du contexte pour les agents IA ?

C’est la discipline qui consiste à décider quels tokens — instructions système, définitions d’outils, données récupérées et historique de conversation — entrent dans la fenêtre de contexte d’un agent à chaque étape, contrairement à l’ingénierie de prompt, qui concerne la formulation d’une seule instruction. Cela compte surtout en production, où les quatre catégories se disputent le même espace limité à chaque requête.

L’ingénierie du contexte est-elle différente de l’ingénierie de prompt ?

Oui. L’ingénierie de prompt optimise la formulation d’une instruction. L’ingénierie du contexte optimise tout ce que le modèle voit à côté de cette instruction — quels outils sont exposés, ce qui a été récupéré, et combien d’historique est reporté. Un prompt bien formulé échoue quand même s’il est entouré de schémas d’outils non pertinents ou d’historique obsolète.

Combien d’historique de conversation un agent IA devrait-il conserver ?

Moins que vous ne le pensez. Une fenêtre glissante bornée (10 à 20 tours récents est typique) plus un résumé condensé de tout ce qui est plus ancien surpasse généralement une transcription brute complète, parce que cela élimine le bruit sans perdre les faits qui comptent. Compactez avant de supprimer l’historique, ne vous contentez pas de le tronquer.

Une fenêtre de contexte plus grande signifie-t-elle qu’il me faut moins d’ingénierie du contexte ?

Non — cela retire le plafond technique dur mais pas le problème de coût ni de bruit. Une fenêtre plus grande rend le laxisme moins cher, mais chaque token non pertinent continue de diluer le signal que le modèle doit traiter et continue de coûter de l’argent à chaque requête qui n’est pas un hit de cache. La discipline compte tout autant à 200K tokens qu’à 8K.

En lien : Comment écrire des prompts système d’agents IA qui ne cassent pas en production · Comment ajouter de la mémoire à un agent IA · Prompt caching : réduisez vos coûts Claude sans changer de modèle · Le eval harness que j’utilise pour livrer des agents IA

Besoin d’aide pour concevoir le contexte et la mémoire d’un agent ? Contactez-moi — je conçois des systèmes d’agents en production pour des équipes opératrices.