Traduction automatique

Cet article a été traduit automatiquement depuis la version originale en anglais.

Ingénierie du contexte pour les agents IA : fenêtres de contexte, mémoire, outils et garde-fous

TL;DR

L’ingénierie du contexte est le pipeline qui décide ce que le modèle voit au moment de prendre une décision : instructions, exemples, connaissances, mémoire, compétences, outils, garde-fous. La plupart des agents en production fonctionnent ou cassent à ce niveau. Voici le blueprint auquel je reviens sans cesse, avec les patterns que j’utilise réellement.

Le même agent qui brille dans une démo de 30 minutes peut s’effondrer au troisième jour en production. Presque toujours, l’échec n’a rien à voir avec le modèle et tout à voir avec ce qui se trouvait dans le contexte quand il a pris la mauvaise décision. Une mémoire obsolète. Une doc qui n’est plus pertinente. Une description d’outil qui a dérivé. Une instruction vague.

L’ingénierie du contexte, c’est ce que vous faites pour éviter cela : concevoir délibérément, avant chaque décision et avec un budget, ce que le modèle voit. Cet article passe en revue les patterns que j’utilise.

---

Pourquoi l’ingénierie du contexte est importante pour les agents IA

Un agent de support client tourne pendant trois semaines et traite 200 tickets. Puis il commence à halluciner des détails produit, à mélanger les clients et à appeler les mauvaises API. Le modèle n’est pas devenu moins bon. Le contexte, si.

Quatre choses ont changé en 2025 qui rendent cela plus douloureux qu’avant. Les agents ont cessé d’être de simples chatbots et ont commencé à agir, ce qui veut dire qu’une seule mauvaise décision de contexte peut se propager dans un plan en dix étapes au lieu de produire une seule mauvaise réponse. La mémoire centralisée et des standards comme MCP permettent de charger du contexte personnel en sécurité, mais seulement si vous concevez correctement cette couche — sans gouvernance, vous fuitez des PII ou vous explosez la fenêtre. Le hybrid retrieval, le reranking et le retrieval conscient des graphes ont tous mûri, ce qui réduit les hallucinations et les tokens, à condition de router les requêtes vers la bonne stratégie. Et la plupart des pilotes agentiques que je vois bloquer bloquent sur la conception du contexte et la gouvernance, pas sur la qualité du modèle. Une couche de contexte délibérée est ce qui les débloque.

---

Concepts clés pour débutants

Quelques termes qui reviennent tout au long de l’article :

• Fenêtre de contexte : la mémoire de travail du modèle. Quantité maximale de texte (en tokens) qu’il peut considérer dans une seule décision. Dépassez-la et le modèle plante ou oublie le début.
• Tokens : l’unité dans laquelle le texte est découpé. En gros, 1 000 tokens représentent 750 mots.
• Budget d’attention : les modèles de langage prêtent attention à chaque paire de tokens ; pour n tokens, cela fait n² relations. À mesure que le contexte grandit, ce budget s’étire, et les tokens du milieu perdent face au début et à la fin.
• Embeddings : représentations numériques du texte. Ils permettent la recherche sémantique ; ainsi, une requête sur "dog" peut retrouver "puppy".
• JSON Schema : une manière standard de décrire la forme de données JSON. On l’utilise pour forcer le modèle à produire des champs spécifiques, comme {"answer": "...", "citations": [...]}.
• MCP (Model Context Protocol) : un standard ouvert qui permet aux modèles d’IA de parler à des données et outils externes via une interface commune. Voyez-le comme un port USB pour connecter un agent à vos fichiers locaux, bases de données ou Slack.

---

Qu’est-ce que la couche de contexte ?

Un pipeline plus une politique qui sélectionnent et structurent les entrées à chaque étape, appliquent des contrôles (format, sécurité, politique) et alimentent le modèle avec un contexte juste suffisant, juste à temps.

Voyez-la comme la chaîne d’assemblage qui prépare exactement ce dont le modèle a besoin pour prendre une bonne décision.

Le contexte est une ressource finie. Les modèles, comme les humains avec une mémoire de travail limitée, ont un budget d’attention qui s’épuise à mesure que le contexte grandit. Chaque nouveau token en consomme une partie. Le problème d’ingénierie consiste à trouver le plus petit ensemble de tokens à fort signal qui permet d’obtenir la réponse voulue.

Il n’existe pas de décomposition canonique unique — différentes équipes livrent différentes stacks. Celle que j’utilise ressemble à ceci :

1) Instructions

Un contrat durable de comportement : rôle, ton, contraintes, schéma de sortie, objectifs d’évaluation. Les modèles modernes respectent des hiérarchies d’instructions (system > developer > user), donc utilisez explicitement cette hiérarchie au lieu d’entasser tout dans un seul bloc.

On utilise des instructions quand on a besoin d’une sortie cohérente (rapports, SQL, appels API, JSON) ou lorsqu’il faut faire respecter une politique — supprimer les PII, refuser les demandes sur des éléments non pris en charge, ne jamais inclure d’URL internes. Les patterns qui fonctionnent en pratique sont évidents : garder les blocs de politique séparés de la tâche utilisateur, piloter le code aval déterministe avec des JSON Schemas, et séparer les messages system, developer et user afin que le modèle sache de quelle voix provient chaque instruction.

Un exemple simple de bloc de politique :

SYSTEM RULES
- Role: support assistant for ACME.
- Always output valid JSON per AnswerSchema.
- If a request needs account data, ask for the account ID.
- Never include secrets or internal URLs.

---

Raisonnement guidé par schéma (SGR)

La mise à niveau la plus utile de « donner des instructions au modèle » consiste à rendre ces instructions structurelles. Pilotez l’agent avec des JSON Schemas pour le plan, les arguments d’outil, les résultats intermédiaires et la réponse finale. Le modèle produit et consomme du JSON à chaque étape, et votre code le valide avant toute autre chose. Cela réduit l’ambiguïté, rend les retries déterministes et améliore la sécurité parce que les types et champs requis sont appliqués dans toute la boucle.

Le flux est court. Définissez des schémas pour Plan, ToolArgs, StepResult et FinalAnswer. À chaque étape, le modèle produit un JSON conforme à l’un d’eux. Votre code valide. Si la validation échoue, tentez une réparation automatique (par exemple, remplir les champs requis manquants avec des valeurs par défaut raisonnables). Si la réparation échoue, refusez et logguez.

Concrètement : au lieu que le modèle dise « Je vais chercher les tickets du client », il produit

{
    "action": "call_tool",
    "tool": "search_tickets",
    "args": { "customer_id": "A-123", "limit": 10 },
    "expected_schema": "TicketList"
}

et votre code valide args par rapport au schéma de l’outil avant d’appeler l’API.

---

2) Exemples

Quelques paires entrée-sortie courtes qui montrent exactement le format, le ton et les étapes que le modèle doit suivre. Utilisez des exemples quand vous avez besoin d’un template précis (tableaux, JSON, SQL, appels API) ou quand vous voulez un phrasé spécifique au domaine et un ton cohérent.

Quelques règles que je réapprends sans cesse. Montrez la structure cible exacte dans votre démo canonique, pas une paraphrase. Associez de bons exemples à de mauvais — opposer une erreur typique au résultat souhaité enseigne plus que deux sorties correctes. Associez votre JSON Schema à deux ou trois démos courtes plutôt qu’à une seule longue. Et gardez-les courts : de nombreuses petites démos ciblées battent presque toujours un seul exemple tentaculaire.

---

3) Connaissances

Ancrer le modèle avec des faits externes : vector retrieval, keyword retrieval, reranking, requêtes graphe, web fetches, sources d’entreprise. Vous en avez besoin quand le modèle ne peut pas connaître la réponse via ses poids — faits frais, faits privés, ou tout ce qui exige une citation.

La stack de retrieval à utiliser par défaut vaut la peine d’être hybrid (BM25 plus dense) avec un reranker par-dessus pour réduire la facture en tokens. Utilisez un retrieval conscient des graphes (GraphRAG) quand la réponse nécessite de traverser plusieurs documents, et un RAG adaptatif lorsqu’un seul type de requête ne convient pas à tous les cas — parfois il ne faut aucun retrieval, parfois un seul passage, parfois une boucle itérative.

Les paramètres qui font réellement bouger la qualité sont plus modestes que la littérature ne le laisse entendre. Chunk par frontière sémantique (paragraphes, sections) plutôt que par taille fixe — le chunking est la décision qui fait ou défait la qualité du retrieval sur des documents réels. Démarrez top-k à 10 à 20 pour l’hybride, puis rerankez vers 3 à 5. Utilisez MMR avec λ autour de 0,7 par défaut pour la diversité. Et incluez toujours des références de source et des citations directes dans votre sortie, non pas parce que le modèle hallucinerait sans elles, mais parce que c’est ce qui rend la réponse auditable.

---

4) Mémoire

Contexte durable à travers les tours et les sessions. La mémoire court terme conserve l’état de la conversation. La mémoire long terme conserve les faits utilisateur et applicatifs. La mémoire épisodique conserve les événements. La mémoire sémantique conserve les entités. Utilisez la mémoire quand vous voulez de la personnalisation et de la continuité, ou lorsque plusieurs agents coordonnent leurs actions sur plusieurs jours ou semaines.

Les patterns qui survivent au contact de la production : des mémoires d’entités (noms, IDs, préférences) avec des politiques d’expiration explicites ; un retrieval scoped depuis un store long terme basé sur des vecteurs, des paires clé-valeur ou un graphe ; et un couplage entre mémoire et compression afin que, lorsque la mémoire court terme devient volumineuse, elle soit résumée plutôt que tronquée. La partie summarization est couverte dans Stratégies de compression du contexte [7].

La politique d’expiration que j’utilise par défaut :

• Préférences : 365 jours.
• Événements épisodiques : 90 jours.
• État court terme : effacé à la fin de la session.
• Entités : pas d’expiration, mais validation périodique requise.

---

5) Compétences

Une expertise métier composable que les agents découvrent et chargent à la demande. Le framework Agent Skills d’Anthropic est la conception de référence pour capturer la connaissance procédurale et la partager entre agents.

Construire une skill pour un agent, c’est comme préparer un guide d’onboarding pour une nouvelle recrue. — Anthropic Engineering Blog

Vous voulez des skills quand vous avez besoin d’expertise spécifique au domaine (manipulation de PDF, git, analyse de données), quand vous voulez des procédures réutilisables entre agents ou organisations, ou quand vous voulez spécialiser un agent sans coder en dur des comportements dans le system prompt.

Qu’est-ce qu’une skill ?

Une skill est un dossier organisé contenant des instructions, des scripts et des ressources que l’agent peut découvrir et charger quand c’est pertinent :

• Un fichier SKILL.md avec un nom, une description (en frontmatter YAML) et les instructions de la skill.
• Des fichiers supplémentaires — références, templates — que la skill peut importer.
• Du code : Python ou d’autres exécutables que l’agent peut lancer comme outils.

Pattern des skills : divulgation progressive

Le principe qui permet aux skills de passer à l’échelle est la divulgation progressive : charger l’information seulement lorsqu’elle est nécessaire. (Voir Le principe de divulgation progressive ci-dessous pour la version générale.) Au démarrage, seuls les noms et descriptions des skills figurent dans le contexte — juste assez pour que l’agent sache ce qui est disponible. Le SKILL.md complet n’est chargé que lorsque la skill est activée. Les fichiers référencés plus profonds ne sont chargés que lorsque la skill activée en a besoin.

Cela signifie que le contenu des skills est effectivement non borné. L’agent ne paie pas en contexte pour ce qu’il n’utilise pas.

┌─────────────────────────────────────────────────────────┐
│ Context Window                                          │
├─────────────────────────────────────────────────────────┤
│ System Prompt                                           │
│ ├── Core instructions                                   │
│ └── Skill metadata (name + description only)           │
│     • pdf: "Manipulate PDF documents"                   │
│     • git: "Advanced git operations"                    │
│     • context-compression: "Manage long sessions"       │
├─────────────────────────────────────────────────────────┤
│ [User triggers task requiring PDF skill]                │
│                                                         │
│ → Agent reads pdf/SKILL.md into context                 │
│ → Agent reads pdf/forms.md (only if filling forms)      │
│ → Agent executes pdf/extract_fields.py (without loading)│
└─────────────────────────────────────────────────────────┘

Bonnes pratiques pour les skills

Les recommandations d’Anthropic se résument à quatre points. Commencez par l’évaluation : exécutez l’agent sur des tâches représentatives, trouvez les manques et écrivez des skills pour les combler. Structurez pour l’échelle : découpez un gros SKILL.md en fichiers séparés, et gardez des chemins distincts lorsque les contextes sont mutuellement exclusifs. Observez comment l’agent utilise vos skills et itérez sur les noms et descriptions jusqu’à obtenir une forte précision de déclenchement. Et laissez l’agent aider : demandez à Claude de capturer les approches réussies dans un contenu de skill réutilisable.

Considérations de sécurité

Les skills introduisent des vulnérabilités par définition — elles donnent à l’agent de nouvelles capacités via des instructions et du code. Installez-les uniquement à partir de sources de confiance. Auditez avant usage, y compris les fichiers embarqués, les dépendances de code et toute connexion réseau. Portez une attention particulière aux instructions qui connectent la skill à des services externes, car c’est généralement là que l’exfiltration commence.

---

6) Outils

Des appels de fonction qui récupèrent des données ou exécutent des actions : API, bases de données, recherche, opérations sur fichiers, computer use. Vous voulez des outils quand vous avez besoin d’effets de bord déterministes et d’une forte fidélité des données, ou lorsque vous orchestrez des boucles plan-call-verify-continue.

Les patterns que j’utilise par défaut sont une planification tool-first avec des validateurs post-call, des sorties structurées entre les étapes et des fallbacks explicites en cas d’échec des outils (retry, puis mode dégradé, puis human-in-loop).

Trois concepts méritent d’être définis précisément. Idempotent signifie qu’un retry est sans effet de bord (GET oui, POST ou DELETE non). Les postconditions sont les vérifications effectuées après chaque appel : résultat non vide, statut égal à "ok", JSON valide. La chaîne de fallback est l’ordre suivi quand quelque chose se passe mal : retry, puis dégradation gracieuse, puis escalade vers un humain.

Une note sur MCP

MCP devient le standard pour la manière dont les agents se connectent aux outils et aux données [6]. Au lieu d’écrire un wrapper API personnalisé pour chaque service, vous exécutez un serveur MCP pour chacun d’eux et l’agent découvre automatiquement les outils et ressources disponibles.

---

7) Garde-fous

Validation des entrées et des sorties, filtres de sécurité, défense contre les jailbreaks, application de schéma, politique de contenu. Vous voulez des garde-fous lorsque vous avez besoin de conformité ou d’intégrité de marque, et quand vous voulez des sorties typées, correctes, et un comportement sûr.

La forme qui tient en production : des rails programmables (règles de politique plus actions), des validateurs de schéma et sémantiques (types, regex, evals), et une politique centrale avec observabilité (dashboards, red-teaming).

La décision réparation versus refus est celle que les équipes ratent. Les violations de schéma ont droit à une tentative de réparation automatique ; si elle échoue, on refuse avec une erreur claire. Les violations de politique sautent complètement l’étape de réparation — refus immédiat, avec suggestion d’une alternative sûre.

Quatre types courants de garde-fous couvrent la plupart des besoins en production. Les garde-fous d’entrée détectent PII, prompt injection et toxicité avant que le modèle ne les voie. Les garde-fous de sortie appliquent schéma, politique de contenu et cohérence factuelle. Les garde-fous d’outil gèrent rate limiting, vérifications de permissions et seuils de coût. Les garde-fous mémoire suppriment les PII avant stockage et appliquent l’expiration.

---

Exemple concret : un bot de support répond à un ticket

Voici ce que la couche de contexte assemble lorsqu’un client demande « Pourquoi ma clé API ne fonctionne-t-elle pas ? » :

• Instructions : le rôle est celui d’un assistant support utile pour ACME, citer les sources, retourner un JSON {answer, sources, next_steps}.
• Exemples : deux courtes paires Q→R montrant le ton et la forme JSON, l’une sur les clés API, l’autre sur la facturation.
• Connaissances : rechercher dans le centre d’aide et les runbooks produit "API key troubleshooting" ; inclure les citations pertinentes.
• Mémoire : nom du client "Sam", ID de compte "A-123", plan "Pro", dernière interaction "API key created 3 days ago".
• Compétences : charger la skill ticket-handling avec les procédures de dépannage, les politiques d’escalade et les templates de résolution.
• Outils : search_tickets(customer_id), check_api_key_status(key), create_issue(description).
• Garde-fous : supprimer les valeurs de clé API dans la sortie ; si le schéma échoue, réparer une fois ; si la politique est violée (une demande de suppression de données de production, par exemple), refuser poliment.

Le modèle reçoit tout ce contexte structuré, génère une réponse, puis les garde-fous la valident avant qu’elle ne soit renvoyée au client.

---

Fondamentaux du contexte : plongée détaillée

Avant que les patterns aient du sens, il faut comprendre l’anatomie.

L’anatomie du contexte

Le contexte possède plusieurs composants distincts, chacun avec ses propres caractéristiques et contraintes.

Les system prompts établissent l’identité, les contraintes et les consignes comportementales de l’agent. Ils sont chargés une fois au début de la session et persistent pendant la conversation. L’astuce consiste à trouver la bonne altitude : suffisamment spécifiques pour orienter réellement le comportement, mais assez flexibles pour laisser une marge de jugement. Trop bas, et vous livrez des règles codées en dur et fragiles. Trop haut, et le modèle n’a aucun signal concret sur lequel agir.

Organisez les prompts en sections distinctes à l’aide de tags XML ou de titres Markdown :

<BACKGROUND_INFORMATION>
You are a Python expert helping a development team.
Current project: Data processing pipeline in Python 3.9+
</BACKGROUND_INFORMATION>

<INSTRUCTIONS>
- Write clean, idiomatic Python code
- Include type hints for function signatures
- Add docstrings for public functions
</INSTRUCTIONS>

<TOOL_GUIDANCE>
Use bash for shell operations, python for code tasks.
File operations should use pathlib for cross-platform compatibility.
</TOOL_GUIDANCE>

Les définitions d’outils spécifient les actions que l’agent peut entreprendre. Chaque outil a un nom, une description, des paramètres et un format de retour. Ce sont les descriptions qui orientent réellement le comportement. De mauvaises descriptions obligent l’agent à deviner ; de bonnes descriptions incluent le contexte d’usage, des exemples et des valeurs par défaut raisonnables. Le principe de consolidation : si un ingénieur humain ne peut pas dire de manière certaine quel outil utiliser, un agent ne fera pas mieux. C’est le signal qu’il faut les fusionner ou les renommer.

Les documents récupérés amènent du contenu pertinent dans le contexte à l’exécution au lieu de tout précharger. L’approche just-in-time conserve autour d’elle des identifiants légers — chemins de fichiers, requêtes stockées, liens web — et ne charge les données réelles qu’en cas de besoin.

L’historique des messages est la conversation entre l’utilisateur et l’agent, y compris les requêtes précédentes, les réponses et le raisonnement. Pour les tâches de longue durée, il peut finir par dominer la fenêtre. Il agit aussi comme mémoire de brouillon, là où les agents suivent la progression et l’état de la tâche.

Les sorties d’outils sont les résultats des actions de l’agent : contenus de fichier, résultats de recherche, sortie de commande, réponses API. Dans des trajectoires d’agent typiques, les observations finissent par consommer plus de 80 % du contexte total [4]. C’est cette pression qui motive des techniques comme l’observation masking et la compaction.

Fenêtres de contexte et mécanique de l’attention

Les modèles de langage calculent l’attention comme des relations pair à pair entre chaque paire de tokens. Pour n tokens, cela représente n² relations. À mesure que le contexte grandit, la capacité du modèle à capturer ces relations s’étire.

Les modèles apprennent aussi leurs schémas d’attention à partir des données d’entraînement, et ces données sont dominées par des séquences plus courtes. Le modèle a donc comparativement peu d’expérience avec des dépendances à l’échelle de tout le contexte. Le résultat final est un budget d’attention qui s’épuise à mesure que le contexte grandit.

Le principe de divulgation progressive

La divulgation progressive gère efficacement le contexte en chargeant l’information uniquement quand elle est nécessaire. Au démarrage, les agents ne chargent que les noms et descriptions des skills — juste assez pour savoir quand une skill pourrait être pertinente. Le contenu complet n’est chargé que lorsqu’il est activé pour des tâches spécifiques.

# Instead of loading all documentation at once:

# Step 1: Load summary

docs/api_summary.md # Lightweight overview

# Step 2: Load specific section as needed

docs/api/endpoints.md # Only when API calls needed
docs/api/authentication.md # Only when auth context needed

Qualité du contexte versus quantité

L’hypothèse selon laquelle de plus grandes fenêtres de contexte résolvent les problèmes de mémoire a été réfutée empiriquement. L’ingénierie du contexte consiste à trouver le plus petit ensemble possible de tokens à fort signal.

Plusieurs forces vous poussent vers l’efficacité. Le coût de traitement croît de manière disproportionnée avec la longueur du contexte — pas simplement doublé pour deux fois plus de tokens, mais exponentiellement plus en temps et en calcul. Les performances du modèle se dégradent au-delà de certaines longueurs de contexte, même quand la fenêtre en supporte techniquement davantage. Et les longues entrées restent coûteuses même avec le prefix caching.

Le principe directeur est l’informativité plutôt que l’exhaustivité. Incluez ce qui compte pour la décision en cours, excluez ce qui ne compte pas.

---

Patterns de dégradation du contexte

Les modèles de langage présentent des patterns de dégradation prévisibles à mesure que le contexte grandit. Les connaître est ce qui vous permet de diagnostiquer les échecs et de concevoir des systèmes robustes.

Le phénomène lost-in-middle

Le pattern de dégradation le mieux documenté est le « lost-in-middle », où les modèles montrent des courbes d’attention en U [1]. Les informations au début et à la fin du contexte reçoivent une attention fiable ; celles du milieu subissent une baisse de rappel de 10 à 40 %.

Le mécanisme est concret. Les modèles allouent une attention massive au premier token (souvent le token BOS) pour stabiliser les états internes, créant un « attention sink » qui consomme le budget d’attention [2]. À mesure que le contexte grandit, les tokens du milieu n’obtiennent pas assez de poids d’attention.

Le correctif pratique consiste à placer l’information critique au début ou à la fin du contexte. Utilisez des structures de résumé qui mettent l’information clé à des positions favorisées par l’attention.

# Organize context with critical info at edges

[CURRENT TASK] # At start

- Goal: Generate quarterly report
- Deadline: End of week

[DETAILED CONTEXT] # Middle (less attention)

- 50 pages of data
- Multiple analysis sections
- Supporting evidence

[KEY FINDINGS] # At end

- Revenue up 15%
- Costs down 8%
- Growth in Region A

Pour les instructions qu’on ne peut absolument pas se permettre de perdre, dupliquez-les au début comme à la fin. Comme les modèles prêtent une forte attention aux deux bords, la même instruction aux deux positions reçoit de l’attention quelle que soit la longueur du contexte. C’est la bonne approche pour les contraintes système à toujours respecter, les exigences de format de sortie et les politiques de sécurité.

# Example: Duplicating critical instructions

[SYSTEM - START]
CRITICAL: Always respond in JSON format. Never include PII.

[... long context with documents, history, tools ...]

[SYSTEM - REMINDER]
CRITICAL: Always respond in JSON format. Never include PII.

Empoisonnement du contexte

L’empoisonnement du contexte survient lorsque des hallucinations, erreurs ou informations incorrectes entrent dans le contexte et se renforcent au fil des références répétées. Une fois empoisonné, le contexte crée des boucles de rétroaction qui renforcent une croyance erronée.

Il arrive généralement par l’une de trois portes : des sorties d’outils contenant des erreurs ou des formats inattendus, des documents récupérés contenant des informations incorrectes ou obsolètes, et des résumés générés par le modèle qui introduisent des hallucinations puis persistent.

On le reconnaît à ses symptômes : baisse de qualité sur des tâches qui réussissaient auparavant, agents appelant les mauvais outils ou de mauvais paramètres, et hallucinations persistantes qui survivent aux tentatives de correction.

La récupération est mécanique. Tronquez le contexte avant le point d’empoisonnement, signalez explicitement l’empoisonnement et demandez une réévaluation, ou redémarrez avec un contexte propre en ne conservant que les informations vérifiées.

Distraction contextuelle

La distraction contextuelle apparaît quand le contexte devient si long que le modèle se focalise excessivement sur ce que vous avez fourni au détriment de ce qu’il a appris à l’entraînement. La recherche montre qu’un seul document non pertinent suffit à réduire les performances sur des tâches impliquant des documents pertinents [8]. L’effet suit une fonction en escalier — la présence de n’importe quel distracteur déclenche une dégradation.

L’intuition clé : les modèles ne peuvent pas ignorer un contexte non pertinent. Ils doivent prêter attention à tout ce qui est fourni, et cette attention est en elle-même la distraction, même lorsque l’information non pertinente n’est manifestement pas utile.

L’atténuation passe par un filtrage de pertinence avant chargement des documents, un namespacing pour rendre les sections non pertinentes faciles à ignorer, et une question simple : l’information doit-elle être dans le contexte, ou peut-elle être accessible via un appel d’outil ?

Confusion contextuelle

La confusion contextuelle survient lorsque des informations non pertinentes influencent les réponses de manière à dégrader la qualité. Si vous mettez quelque chose dans le contexte, le modèle doit y prêter attention ; il peut alors incorporer des informations non pertinentes, utiliser des définitions d’outils destinées à une autre tâche, ou appliquer des contraintes issues d’un autre contexte.

Les signes à surveiller : des réponses qui traitent le mauvais aspect de la requête, des appels d’outils qui semblent corrects pour une autre tâche, des sorties qui mélangent des exigences provenant de plusieurs sources.

Le correctif est une segmentation explicite des tâches (tâches différentes, fenêtres de contexte différentes), des transitions claires entre contextes et une gestion d’état qui isole le contexte.

Collision de contexte

La collision de contexte se développe lorsque des informations accumulées entrent directement en conflit, créant des consignes contradictoires. C’est différent de l’empoisonnement, où un élément est faux — dans une collision, plusieurs éléments corrects se contredisent.

Les sources courantes incluent le retrieval multi-source avec des informations contradictoires, des conflits de version (informations obsolètes et actuelles présentes ensemble dans le contexte) et des conflits de perspective (points de vue valides mais incompatibles).

Résolvez cela avec un marquage explicite des conflits, des règles de priorité établissant quelle source prévaut, et un filtrage de version excluant l’information obsolète.

Seuils de dégradation spécifiques aux modèles

La recherche fournit des données concrètes sur le moment où la dégradation commence. La longueur de contexte effective — celle où les modèles conservent des performances optimales — est souvent bien plus petite que le maximum annoncé [3] :

Modèle	Contexte max	Contexte effectif	Notes sur la dégradation
GPT-4 Turbo	128K tokens	~32K tokens	Le retrieval se dégrade après 32K, la précision baisse au-delà de 64K
GPT-4o	128K tokens	~8K tokens	La précision NIAH complexe chute de 99 % à 70 % à 32K
Claude 3.5 Sonnet	200K tokens	~4K tokens	La précision NIAH complexe chute de 88 % à 30 % à 32K
Gemini 1.5 Pro	1M tokens	~128K tokens	99 % de rappel NIAH à 1M, meilleure performance en long contexte
Gemini 2.0 Flash	1M tokens	~32K tokens	La précision NIAH complexe chute de 94 % à 48 % à 32K

Sources : benchmark RULER [3], benchmark NoLiMa [9], rapports techniques Google.

La conclusion clé de RULER [3] : seuls 50 % des modèles revendiquant 32K+ de contexte maintiennent des performances satisfaisantes à 32K tokens. Des scores quasi parfaits sur de simples tests needle-in-a-haystack ne se traduisent pas en vraie compréhension long contexte — les tâches de raisonnement complexe se dégradent bien plus fortement.

---

Stratégies de compression du contexte

Note de terminologie : la compression du contexte est un terme parapluie qui inclut la summarization (pour l’historique de conversation et la mémoire), l’observation masking (pour les sorties d’outils) et le selective trimming [5]. La summarization de mémoire mentionnée dans la section Mémoire est une application de ces stratégies de compression plus larges.

Lorsque les sessions d’agents génèrent des millions de tokens d’historique de conversation, la compression cesse d’être optionnelle. L’approche naïve consiste à compresser agressivement pour minimiser les tokens par requête. La bonne cible d’optimisation est les tokens par tâche [4] : le total de tokens consommés pour accomplir la tâche, y compris les coûts de re-fetch quand la compression fait perdre quelque chose de critique.

Quand la compression est nécessaire

Activez la compression lorsque les sessions d’agent dépassent les limites de la fenêtre de contexte, lorsque les agents commencent à « oublier » quels fichiers ils ont modifiés, lorsque vous déboguez une longue session de développement qui s’étale sur des heures, ou lorsque les performances se dégradent visiblement dans des conversations prolongées.

Trois approches prêtes pour la production

Anchored iterative summarization maintient un résumé persistant structuré avec des sections explicites pour l’intention de session, les modifications de fichiers, les décisions et les prochaines étapes. Quand la compression se déclenche, elle ne résume que la portion nouvellement tronquée et la fusionne dans le résumé existant. La raison pour laquelle cela fonctionne est que la structure force la préservation : des sections dédiées agissent comme une checklist que le summarizer doit remplir, ce qui empêche une dérive silencieuse.

## Session Intent

Debug 401 Unauthorized error on /api/auth/login despite valid credentials.

## Root Cause

Stale Redis connection in session store. JWT generated correctly but session could not be persisted.

## Files Modified

- auth.controller.ts: No changes (read only)
- config/redis.ts: Fixed connection pooling configuration
- services/session.service.ts: Added retry logic for transient failures
- tests/auth.test.ts: Updated mock setup

## Test Status

14 passing, 2 failing (mock setup issues)

## Next Steps

1. Fix remaining test failures (mock session service)
2. Run full test suite
3. Deploy to staging

Opaque compression produit des représentations compressées optimisées pour la fidélité de reconstruction. Elle atteint les meilleurs taux de compression (99 %+) mais sacrifie l’interprétabilité. Utilisez-la lorsque l’économie maximale de tokens compte et que le re-fetch est peu coûteux.

Regenerative full summary génère un résumé structuré détaillé à chaque compression. La sortie est lisible, mais les détails peuvent se dégrader au fil des cycles de compression répétés.

Comparaison des méthodes de compression

Une recherche de Factory.ai [4] a comparé des stratégies de compression sur de vraies sessions d’agents en production :

Méthode	Taux de compression	Score qualité	Meilleur cas d’usage
Anchored Iterative	98.6%	3.70/5	Sessions longues, suivi de fichiers
Regenerative	98.7%	3.44/5	Frontières de phase claires
Opaque	99.3%	3.35/5	Économies maximales, sessions courtes

Lecture des métriques :

• Taux de compression (98.6%) : pourcentage de tokens supprimés. Un taux de 98,6 % signifie que sur 100 000 tokens d’historique, seuls 1 400 restent.
• Score qualité (3.70/5) : mesuré via une évaluation par probes — après compression, on pose à l’agent des questions qui exigent de rappeler des détails précis de l’historique tronqué (quels fichiers avons-nous modifiés, quel était le message d’erreur). 3,70/5 signifie que l’agent a répondu correctement à environ 74 % des probes.
• 0,7 % de tokens supplémentaires : en comparant anchored iterative (98,6 %) à opaque (99,3 %), l’écart est de 0,7 %. Pour une session de 100K tokens, cela fait 1 400 tokens contre 700. Les 700 tokens supplémentaires (0,7 % de l’original) achètent 0,35 point de qualité (3,70 contre 3,35) — un rappel significativement meilleur des détails critiques pour la tâche.

Le problème de la trace des artefacts

L’intégrité de la trace des artefacts est la dimension la plus faible pour toutes les méthodes de compression, avec des scores de 2,2 à 2,5 sur 5,0. Les agents de code doivent savoir quels fichiers ils ont créés, modifiés ou lus, et la compression perd souvent cette information.

Recommandation : implémenter un index d’artefacts séparé ou un suivi explicite de l’état des fichiers dans le scaffolding de l’agent, en plus de la summarization générale.

Stratégies de déclenchement de compression

Stratégie	Point de déclenchement	Compromis
Seuil fixe	70-80% d’utilisation	Simple mais peut compresser trop tôt
Fenêtre glissante	Conserver les N derniers tours + résumé	Taille de contexte prévisible
Basée sur l’importance	Compresser d’abord le moins pertinent	Complexe mais préserve le signal
Frontière de tâche	Compresser à la fin des tâches	Résumés propres, timing imprévisible

Évaluation par probes

Les métriques traditionnelles comme ROUGE ne capturent pas la qualité fonctionnelle de la compression. Un résumé peut avoir un fort recouvrement lexical tout en manquant le seul chemin de fichier dont l’agent a réellement besoin.

L’évaluation par probes mesure directement la qualité en posant des questions après compression :

Type de probe	Ce qu’il teste	Exemple de question
Recall	Rétention factuelle	"Quel était le message d’erreur d’origine ?"
Artifact	Suivi de fichiers	"Quels fichiers avons-nous modifiés ?"
Continuation	Planification de tâche	"Que devons-nous faire ensuite ?"
Decision	Chaîne de raisonnement	"Qu’a-t-on décidé concernant le problème Redis ?"

Si la compression a préservé la bonne information, l’agent répond correctement. Sinon, il devine ou hallucine.

---

Techniques d’optimisation du contexte

L’optimisation du contexte étend la capacité effective par compression, masking, caching et partitioning. Ces techniques s’appuient sur les Stratégies de compression du contexte ci-dessus, en les appliquant systématiquement pour la production. Bien menée, l’optimisation peut doubler ou tripler la capacité effective de contexte sans nécessiter un modèle plus grand.

Stratégies de compaction

La compaction résume le contenu du contexte à l’approche des limites, puis réinitialise avec ce résumé. Le but est de distiller le contenu avec une haute fidélité, afin que l’agent puisse continuer à fonctionner avec une dégradation minimale.

L’ordre de priorité que je suis : compresser d’abord les sorties d’outils (les remplacer par des résumés), puis les anciens tours (résumer le début de conversation), puis les documents récupérés (les résumer si des versions récentes existent). Ne compressez jamais le system prompt.

Ce qu’il faut préserver dépend du type. Sorties d’outils : garder les constats, métriques et conclusions ; jeter la sortie brute verbeuse. Tours conversationnels : garder les décisions, engagements et changements de contexte ; jeter le remplissage. Documents récupérés : garder les faits et affirmations clés ; jeter les développements de support.

Observation masking

Les sorties d’outils peuvent représenter plus de 80 % de l’usage en tokens [4]. Une fois qu’un agent a utilisé une sortie d’outil pour prendre une décision, conserver la sortie complète apporte une valeur décroissante.

Une matrice de décision pour le masking :

Catégorie	Action	Raisonnement
Observations de la tâche courante	Ne jamais masquer	Critiques pour le travail en cours
Tour le plus récent	Ne jamais masquer	Immédiatement pertinent
Raisonnement actif	Ne jamais masquer	Pensée en cours
3+ tours plus tôt	Envisager le masking	Le besoin est probablement passé
Sorties répétées	Toujours masquer	Redondant
Boilerplate	Toujours masquer	Faible signal

Optimisation du KV-cache

Le KV-cache stocke les tenseurs Key et Value calculés pendant l’inférence. Le caching entre requêtes avec des préfixes identiques évite des recomputations, ce qui réduit fortement coût et latence.

Optimisez pour le caching en plaçant d’abord le contenu stable :

# Stable content first (cacheable)
context = [system_prompt, tool_definitions]
# Frequently reused elements
context += [reused_templates]
# Unique elements last
context += [unique_content]

Concevez pour la stabilité du cache : évitez le contenu dynamique comme les timestamps dans les prompts, utilisez un formatage cohérent et gardez une structure stable entre les sessions.

Partitionnement du contexte

L’optimisation la plus agressive consiste à répartir le travail entre des sous-agents avec des contextes isolés. Chaque sous-agent opère dans un contexte propre centré sur sa sous-tâche, sans porter le contexte accumulé des autres sous-tâches.

Pour l’agrégation : validez que toutes les partitions sont terminées, fusionnez les résultats compatibles et résumez si la sortie combinée reste trop volumineuse.

Cadre de décision pour l’optimisation

Quand optimiser : l’utilisation du contexte dépasse 70 %, la qualité des réponses se dégrade dans les conversations longues, les coûts augmentent à cause de contextes trop longs, ou la latence grimpe avec la longueur des conversations.

Ce qu’il faut appliquer dépend de ce qui domine. Si les sorties d’outils dominent, utilisez observation masking. Si les documents récupérés dominent, utilisez summarization ou partitioning. Si l’historique des messages domine, utilisez compaction avec summarization. Si plusieurs composants dominent, combinez les stratégies.

Des métriques cibles raisonnables : compaction à 50-70 % de réduction de tokens avec moins de 5 % de dégradation qualité ; masking à 60-80 % de réduction des observations masquées ; optimisation de cache à 70 % ou plus de hit rate pour des workloads stables.

---

Comment le cuisiner (étape par étape)

Une recette pratique pour la couche de contexte. Commencez simplement et ajoutez de la complexité uniquement quand quelque chose casse.

Étape 1 : écrire le contrat

Définissez ce que votre agent doit faire et comment il doit se comporter. Écrivez les politiques de niveau system (rôle, contraintes, règles de sécurité) et les consignes de niveau developer (format de sortie, ton, exigences de citation). Définissez des JSON Schemas pour chaque forme de sortie : AnswerSchema, PlanSchema, StepResultSchema.

Étape 2 : choisir une stratégie de retrieval

Commencez par un retrieval hybride (BM25 plus vector) et un reranker. Ensuite, routez selon le type de requête. Les connaissances générales n’exigent pas de retrieval. Les faits frais ou privés exigent un RAG single-shot (hybride plus rerank). Les requêtes complexes à plusieurs parties exigent un RAG itératif (les découper en sous-requêtes).

Étape 3 : concevoir la mémoire

Séparez le court terme (état de la conversation) du long terme (faits utilisateur, historique). Le court terme contient l’état de la conversation et les quelques derniers tours, puis est vidé à la fin de la session. Le long terme contient les entités utilisateur, les préférences et les événements épisodiques. Définissez des règles d’expiration : préférences 365 jours, épisodique 90 jours, court terme limité à la session. Ajoutez la suppression des PII avant tout stockage.

Étape 4 : spécifier les outils

Définissez des signatures d’outils claires avec validation et stratégies de fallback. Pour chaque outil, écrivez une docstring claire, un schéma d’entrée et un schéma de sortie. Indiquez s’il est idempotent. Définissez les postconditions et la chaîne de fallback. Validez les arguments d’outil contre le schéma avant l’appel.

Étape 5 : installer des garde-fous

Ajoutez validation des entrées et sorties, filtres de sécurité et application des politiques. La checklist minimale :

• [ ] Supprimer les PII (emails, SSN, cartes de crédit) avant traitement.
• [ ] Valider toutes les sorties contre le JSON Schema.
• [ ] Bloquer les tentatives de prompt injection.
• [ ] Appliquer du rate limiting sur les appels d’outils.
• [ ] Logger toutes les violations de politique à des fins d’audit.

Étape 6 : ajouter observabilité et evals

Instrumentez la couche de contexte pour pouvoir la déboguer. Tracez quelles sources de contexte ont été chargées ; les comptes de tokens (entrée, sortie, coût) ; les métriques de retrieval (requête, top-k, sources citées) ; les appels d’outils (quels outils, arguments, résultats, échecs) ; et les déclenchements de garde-fous (blocages d’entrée, réparations de sortie, refus de politique).

Les métriques qui comptent le plus sont l’exactitude (validité du schéma, cible 99 %+), l’ancrage factuel (taux de citation, cible 90 %+ pour les requêtes de connaissance), la latence (cible sous 2 s p95) et le coût (cible sous 0,05 $ par requête).

Étape 7 : itérer

N’ajoutez des patterns avancés que lorsque vous atteignez des limites claires. Ajoutez des réflexions quand le taux d’erreur dépasse 5 %. Ajoutez des planners quand les tâches exigent régulièrement plus de trois étapes séquentielles. Ajoutez des sous-agents quand vous avez des domaines distincts nécessitant des contextes isolés.

---

Anti-patterns

Les erreurs courantes qui tuent les systèmes agentiques. Évitez-les.

1. Stuff-the-window

Déverser tous les documents, souvenirs et exemples possibles dans le contexte à chaque requête. Le résultat est une pourriture du contexte — le ratio signal/bruit s’effondre, et vous déclenchez tous les patterns de dégradation d’un coup. Voir Patterns de dégradation du contexte pour les détails sur distraction et confusion. Le correctif est un routage adaptatif avec compression et masking. Voir Techniques d’optimisation du contexte.

2. Résultats d’outils non validés

L’agent appelle un outil, reçoit des données, puis les transmet immédiatement au modèle sans contrôle. Des données mal formées font planter la logique aval. Des résultats nuls causent des hallucinations. C’est l’un des principaux vecteurs de l’empoisonnement du contexte. Validez toujours les résultats d’outil contre le schéma et les postconditions.

3. Tout en one-shot

Politique system, consignes developer, exemples, requête utilisateur, mémoire et connaissances entassés dans un unique prompt monolithique. Aucune séparation des responsabilités. La fenêtre de contexte se remplit de boilerplate dupliqué. Séparez les instructions durables du contexte spécifique à l’étape, et utilisez les patterns d’optimisation du KV-cache ci-dessus.

4. Mémoire non bornée

Stocker chaque interaction utilisateur pour toujours et tout recharger à chaque requête. Le contexte se remplit de souvenirs obsolètes et non pertinents, et vous absorbez gratuitement un risque de confidentialité. Voir le phénomène lost-in-middle pour comprendre pourquoi le contenu du milieu est de toute façon ignoré. Définissez des politiques de rétention, implémentez un retrieval scoped et supprimez les PII.

5. RAG partout

Récupérer des documents pour chaque requête, même « What is 2+2? » ou « Hello. » Cela gaspille latence et coût, et le retrieval injecte du bruit qui déclenche la distraction contextuelle. Implémentez un routage RAG adaptatif à l’aide d’un classifieur ou d’un petit ensemble d’heuristiques.

6. Ignorer les déclenchements de garde-fous

Vous logguez les violations de garde-fous sans jamais les revoir. De vraies attaques vous échappent. De vrais problèmes UX passent inaperçus. Les réparations de schéma ne devraient pas être fréquentes — si elles le sont, vos instructions ne sont pas claires. Passez en revue les déclenchements de garde-fous chaque semaine.

7. Pas d’evals

Livrer des changements de couche de contexte sans test. Régressions silencieuses, aucun moyen de comparer objectivement les variantes. Définissez cinq à dix scénarios d’évaluation avant de livrer, exécutez-les à chaque changement, et utilisez l’évaluation par probes pour détecter les problèmes de qualité de compression.

---

Quick wins : déployez cela aujourd’hui

Si vous avez déjà un agent en production et voulez des améliorations immédiates, commencez ici. Chacune prend moins d’une journée.

1. Ajouter la validation du schéma de sortie

Cela intercepte la majorité des erreurs avant qu’elles n’atteignent les utilisateurs.

from jsonschema import validate, ValidationError

def validate_output(output: dict) -> dict:
    try:
        validate(instance=output, schema=ANSWER_SCHEMA)
        return output
    except ValidationError as e:
        repaired = auto_repair(output, e)
        validate(instance=repaired, schema=ANSWER_SCHEMA)
        return repaired

2. Instrumenter un tracing de base

Le débogage devient nettement plus rapide quand quelque chose casse.

logger.info(json.dumps({
    "request_id": request_id,
    "query": query,
    "context_loaded": {"instructions": True, "memory": True, "knowledge": True},
    "tokens": {"input": 1200, "output": 150},
    "latency_ms": 1120,
    "result": "success"
}))

3. Séparer les messages system et user

Réduit significativement le gaspillage de tokens en activant l’optimisation du KV-cache.

messages = [
    {"role": "system", "content": SYSTEM_POLICY + DEVELOPER_GUIDELINES},
    {"role": "user", "content": f"Query: {query}\nMemory: {memory}\nKnowledge: {knowledge}"}
]

4. Ajouter des exigences de citation

Renforce la confiance, permet l’audit et réduit les hallucinations.

5. Définir une expiration de mémoire

Évite la pollution du contexte et les risques de confidentialité.

def load_memory(customer_id: str) -> dict:
    entries = db.get_memory(customer_id)
    now = datetime.now()
    return {
        k: v for k, v in entries.items()
        if v.get("expires_at", now) > now
    }

---

Conclusion

L’ingénierie du contexte est la discipline qui sépare les agents de démo des agents de production. Le modèle n’est pas devenu moins bon — le contexte, si. Les quatre leviers à connaître : les fondamentaux (le contexte est fini, l’attention est limitée, la divulgation progressive est le déblocage), les patterns de dégradation (lost-in-middle, empoisonnement, distraction, confusion, collision), la compression (tokens-par-tâche plutôt que tokens-par-requête, résumés structurés) et l’optimisation (compaction, masking, caching, partitioning).

Commencez par les quick wins. Ajoutez de la complexité uniquement quand vous atteignez une vraie limite. Et mesurez tout — on ne peut pas améliorer ce qu’on ne trace pas.

---

Cet article intègre du contenu de la collection Agent Skills for Context Engineering, un ensemble de modules de connaissance réutilisables pour construire de meilleurs agents IA.

---

References

1. Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2023). "Lost in the Middle: How Language Models Use Long Contexts." arXiv preprint arXiv:2307.03172. https://arxiv.org/abs/2307.03172

   • Résultat clé : une précision de rappel de 10 à 40 % plus faible pour les informations au milieu du contexte qu’au début/à la fin.

2. Xiao, G., Tian, Y., Chen, B., Han, S., & Lewis, M. (2023). "Efficient Streaming Language Models with Attention Sinks." ICLR 2024. https://arxiv.org/abs/2309.17453

   • Introduit le phénomène d’« attention sink » où les LLM allouent une attention disproportionnée aux tokens initiaux.

3. Hsieh, C. Y., et al. (2024). "RULER: What's the Real Context Size of Your Long-Context Language Models?" COLM 2024. https://arxiv.org/abs/2404.06654

   • Résultat clé : seuls 50 % des modèles revendiquant un contexte 32K+ maintiennent des performances satisfaisantes à 32K tokens.

4. Factory.ai Research. (2025). "Evaluating Context Compression for AI Agents." https://www.factory.ai/blog/evaluating-context-compression

   • Source pour les comparaisons de stratégies de compression, l’optimisation tokens-par-tâche et la méthodologie d’évaluation par probes.

5. Li, Y., et al. (2023). "Compressing Context to Enhance Inference Efficiency of Large Language Models." EMNLP 2023.

   • Recherche sur l’élagage sélectif du contexte via des métriques de self-information.

6. Anthropic. (2024). "Model Context Protocol (MCP) Specification." https://modelcontextprotocol.io/

   • Spécification officielle du standard MCP pour l’intégration IA-outils.

7. LangChain/LangGraph. (2024). "How to add memory to the prebuilt ReAct agent." https://langchain-ai.github.io/langgraph/how-tos/create-react-agent-memory/ — Montre que la summarization est une technique parmi d’autres pour gérer la mémoire dans les limites du contexte.

8. Yoran, O., Wolfson, T., Bogin, B., Katz, U., Deutch, D., & Berant, J. (2024). "Making Retrieval-Augmented Language Models Robust to Irrelevant Context." ICLR 2024. https://arxiv.org/abs/2310.01558

   • Résultat clé : même un seul document non pertinent peut dégrader significativement les performances RAG, créant un « effet de distraction ».

9. Maekawa, S., et al. (2025). "NoLiMa: Long-Context Evaluation Beyond Literal Matching." ICML 2025. https://arxiv.org/abs/2502.05167

   • Résultat clé : contexte effectif de GPT-4o ~8K tokens, Claude 3.5 Sonnet ~4K tokens lorsqu’un raisonnement latent est requis (vs. simple correspondance littérale). À 32K tokens, GPT-4o chute de 99,3 % à 69,7 % de précision.

Ressources supplémentaires

• Documentation Anthropic Claude : bonnes pratiques pour l’usage du long contexte
• OpenAI Cookbook : stratégies de gestion des fenêtres de contexte
• Documentation LangChain : patterns de mémoire et de retrieval
• Documentation LlamaIndex : stratégies de RAG et de chunking