2025-10-05 · Mis à jour 2026-07-15

[!NOTE] Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.

Context Engineering pour les agents AI : fenêtres de contexte, mémoire, outils et contraintes de sécurité

Context engineering correspond au pipeline qui définit ce que le modèle perçoit avant chaque décision : instructions, exemples, connaissances, mémoire, définitions d’outils, observations ainsi que des contraintes. Un agent n’agit pas sur tout ce que le système sait ; il agit plutôt sur l’ensemble de données préparé pour la prochaine invocation du modèle.

C’est justement cette sélection qui est à l’origine de nombreuses défaillances. Une préférence obsolète apparaît comme étant à jour. Le texte récupéré contient une instruction. Un tool result trop long masque la condition préalable non remplie. Un résumé conserve la décision prise, mais oublie quel fichier a été modifié.

La tâche pratique consiste à assembler l’ensemble de travail minimal suffisant pour chaque décision, tout en préservant le périmètre, l’origine et les permissions associées. Cet article passe en revue les schémas que j’utilise ainsi que les contraintes qui les rendent fiables.

En résumé. Considérez le contexte comme un artefact runtime structuré et porteur d’informations sur sa provenance. Sélectionnez-le étape par étape, imposez des contraintes de tenant et de droits d’accès avant de le récupérer, séparez les instructions fiables des données non fiables, planifiez en fonction de l’utilité attendue, validez les actions en dehors du modèle, et évaluez les résultats de la tâche plutôt que uniquement la longueur du contexte.

Le contexte constitue une entrée de décision, et non une mémoire

La fenêtre de contexte correspond à l’entrée actuelle du modèle ainsi qu’aux tokens générés. Elle peut contenir les échanges de la conversation, mais ce n’est pas un système de mémoire persistante. La mémoire à long terme, les index de documents, les bases de données et les entrepôts d’artefacts se trouvent en dehors de cette fenêtre ; c’est le contexte pipeline qui décide de ce qui sera copié à l’intérieur.

La taille de la fenêtre représente une limite de capacité, et non une garantie de qualité. La recherche sur des contextes longs, telle que Perdu au milieu et Règle Cela montre que la récupération et le raisonnement réussis peuvent varier en fonction de la position, de la tâche, du modèle ainsi que de la longueur de la séquence. La leçon pratique à en tirer n’est pas que les tokens intermédiaires sont systématiquement ignorés ; il s’agit plutôt du fait qu’ajouter des tokens qui semblent pertinents peut néanmoins nuire aux performances de la tâche.

Utilisez un manifeste de contexte pour chaque appel au modèle :

from datetime import datetime
from typing import Literal

from pydantic import BaseModel


class ContextItem(BaseModel):
    item_id: str
    kind: Literal["instruction", "task_state", "evidence", "memory", "tool"]
    source: str
    trust: Literal["trusted", "untrusted"]
    retrieved_at: datetime | None = None
    version: str | None = None
    token_count: int


class ContextManifest(BaseModel):
    request_id: str
    tenant_id: str
    items: list[ContextItem]
    total_input_tokens: int

Le manifeste permet de rendre l’échec reproductible. L’affirmation « Le modèle a produit des hallucinations » se transforme en une question testable : quels éléments de preuve, quelle version, quel périmètre d’autorisation, et tool schema le modèle a-t-il réellement reçus ?

Le cycle de vie de l’assemblage

Un pipeline fiable effectue ces opérations dans l’ordre suivant :

1. Résoudre le contexte de la demande fiable. Authentifier l’acteur, le locataire, la région linguistique, l’heure ainsi que l’état actuel de la tâche en dehors du modèle.
2. Choisir la décision suivante. Une étape de planification, une recherche d’éléments de preuve, une sélection d’outils et la réponse finale nécessitent des contextes distincts.
3. Récupérer dans les limites définies. Appliquer les filtres d’autorisation et liés au locataire avant le classement sémantique, et non après que les documents aient été intégrés à l’ensemble des candidats.
4. Classer et allouer des ressources. Sélectionner les éléments en fonction de leur utilité, de leur fraîcheur, de leur fiabilité et de leur diversité, tout en respectant un budget d’entrée prédéfini.
5. Assembler avec des limites de confiance. Conserver les politiques dans les canaux d’instructions et citer le contenu récupéré comme données ; les instructions obtenues ne deviennent pas des politiques système.
6. Générer une proposition structurée. Une sortie contrainte peut imposer une syntaxe et une forme spécifiques, mais elle ne peut pas corriger les valeurs.
7. Valider et exécuter. Le code d’application vérifie l’autorisation, les règles métier, les arguments des outils ainsi que les conditions post-exécution.
8. Enregistrer l’origine et le résultat. Sauvegarder le manifeste, les identifiants des sources sélectionnées, les références tool result, le résultat de la validation ainsi que l’issue de la tâche.

Le cycle de vie est défini au niveau de chaque décision. La réutilisation d’un contexte volumineux tout au long du fonctionnement d’un agent génère des données obsolètes et permet à chaque étape d’accéder à des informations dont elle n’a pas besoin.

Assigner une tâche à chaque source de contexte

Les instructions définissent un comportement durable

Les instructions définissent le rôle, la politique, le contrat de sortie ainsi que le comportement d’escalade. Il convient de maintenir stable le contenu afin d’améliorer le cache des préfixes, mais il ne faut pas figer les valeurs qui évoluent à runtime. Le seuil de remboursement doit être stocké au sein d’un service de politique ou dans un enregistrement de données versionné, et non copié indéfiniment dans un prompt.

La hiérarchie des instructions constitue une frontière de contrôle et non une mesure de sécurité sandbox. Un modèle peut néanmoins suivre des textes malveillants présents dans un document récupéré. Il convient donc de délimiter le contenu non fiable, de préciser qu’il s’agit de preuves plutôt que d’instructions, de restreindre les outils de manière indépendante, ainsi que de tester les cas d’@prompt injection.

Enregistrement de l’état de la tâche : définition des engagements

Le texte issu d’une conversation constitue une source de vérité peu fiable pour des tâches à plusieurs étapes. Il est impératif de conserver de manière explicite l’état actuel, la phase en cours, les actions déjà réalisées, les approbations en attente, les références aux artefacts ainsi que le statut des tests. Le modèle peut résumer cet état à des fins de narration, mais c’est le code de l’application qui détient la version officielle et authoritative.

Les exemples illustrent les décisions prises en situation de bordure

Les exemples de type few-shot sont utiles lorsqu’ils permettent de clarifier une frontière complexe, plutôt que de se contenter de reproduire le schéma. Il convient de choisir des exemples correspondant à la décision actuelle et d’y inclure des cas limites pertinents. L’évaluation de la récupération des exemples doit suivre les mêmes principes que celle de la récupération de documents : un exemple apparemment similaire mais incompatible avec la politique en vigueur peut s’avérer pire que l’absence totale d’exemple.

Les connaissances fournissent des preuves

La récupération d’informations est adaptée aux faits récents, privés ou citables. Il n’existe pas de solution optimale universelle. top_kla taille du chunk, le poids hybride, ou le seuil reranker. Il convient d’ajuster l’ensemble de ce mécanisme en fonction des questions pour lesquelles des preuves de soutien sont connues.

Un élément de preuve utile comprend :

• identifiant du document source et stable
• version ou date d’entrée en vigueur
• portée des permissions
• plage citée et emplacement
• scores de récupération et reranking aux fins de débogage

Ne demandez pas au modèle de citer une URL qu’il n’a jamais reçue. Ne consignez pas l’intégralité des documents privés uniquement dans le but de déboguer le processus de sélection.

Les ressources mémoire assurent la continuité ciblée

La mémoire représente des données récupérées présentant des risques supplémentaires liés à leur cycle de vie. Chaque enregistrement doit disposer d’un sujet, d’une provenance, d’une finalité, d’un accord ou d’une base juridique le cas échéant, d’une date de création, d’une politique de péremption ou de révision, ainsi que d’une procédure de suppression.

Les règles fixes telles que « les préférences restent valables 365 jours » ne constituent pas une politique de portabilité. La conservation des données dépend des besoins du produit, des attentes des utilisateurs et des exigences légales. Avant de charger une mémoire, vérifiez :

1. S’agit-il de ce sujet et de ce tenant authentifiés ?
2. Son objectif est-il pertinent pour cette décision ?
3. Est-il suffisamment à jour pour être utilisé ?
4. Sa source est-elle fiable ou ne s’agit-il que d’une inférence issue du modèle ?

Traitez les mémoires inférées comme des hypothèses. Ne transformez pas silencieusement une réponse du modèle en fait permanent pour l’utilisateur.

Les contrats d’outil exposent les capacités disponibles

Les descriptions des outils doivent préciser les prérequis, les effets, la portée d’autorisation, le schéma d’entrée, le schéma de sortie, l’idempotence ainsi que les cas d’échec significatifs. Une requête valide selon le schéma peut néanmoins être non autorisée ou dangereuse.

Après exécution, remplacer la sortie brute détaillée par une observation tapée qui conserve le résultat pertinent pour la décision ainsi qu’une référence à l’artefact complet :

{
    "tool": "check_api_key_status",
    "status": "revoked",
    "checked_at": "2026-07-15T09:30:00Z",
    "account_id": "A-123",
    "artifact_ref": "toolrun://req-42/step-3"
}

MCP standardise la manière dont les clients découvrent des outils, des ressources ainsi que des prompts ; il ne autorise pas leur utilisation ni ne garantit l’exactitude du contenu retourné. Il convient de placer les vérifications relatives aux passerelles, aux identifiants et aux politiques en dehors de la description du modèle et du protocole.

Comment le contexte se dégrade

Un contexte insuffisant ne provoque pas d’échecs de manière unique. La version initiale de ce guide séparait plusieurs schémas qui restent utiles lors du débogage :

• Perte de position : les preuves nécessaires sont présentes, mais le modèle les utilise de manière incohérente en raison de leur position dans la séquence ainsi que du contexte environnant. Les évaluations sur des contextes longs montrent que ce phénomène varie selon le modèle et la tâche ; il n’existe pas de plage universellement considérée comme « mauvaise ».
• Empoisonnement : une mémoire erronée, un document obsolète, une instruction malveillante ou une observation d’outil défectueuse pénètrent dans l’ensemble de travail et influencent les décisions ultérieures.
• Distraction : des preuves pertinentes entrent en concurrence avec des éléments récents ou sémantiquement similaires, mais inutiles pour l’étape actuelle.
• Confusion : des instructions, des exemples ou des descriptions d’outils qui se chevauchent amènent le modèle à avoir plusieurs interprétations plausibles de la tâche.
• Conflit : deux éléments présentés comme autoritaires diffèrent sur une valeur, une politique ou l’action suivante, et l’assemblateur ne met pas en évidence leurs versions respectives ni leur hiérarchie.

Ces pannes nécessitent des solutions distinctes. Une meilleure hiérarchisation des résultats peut atténuer la distraction, mais elle ne permet pas de corriger une source obsolète. Les délimiteurs peuvent aider à séparer les données des instructions, cependant ils ne confèrent pas d’autorisation à un outil. Une fenêtre de contexte plus large permet de conserver davantage de matériel contradictoire sans pour autant résoudre ce conflit.

Lorsqu’un exécution échoue, examinez le manifeste afin de déterminer quel schéma s’est produit, avant de modifier le prompt ou d’ajouter une nouvelle étape de récupération.

Budget par service, et non par quota de composant

Un budget de contexte alloue une marge pour les sorties avant d’attribuer les entrées à la décision en cours. Il suffit de partir de la fenêtre de taille supportée par le modèle, de soustraire la longueur maximale des sorties ainsi que les surcoûts liés au protocole, puis d’empaqueter les candidats dans l’espace restant.

Évaluez les candidats en utilisant des caractéristiques que vos processus d’évaluation peuvent remettre en question :

utility = relevance × authority × freshness × scope_match
          − redundancy_penalty − injection_risk

Cette formule constitue un prompt de conception, et non une théorie mathématique universelle. Lorsqu’il s’agit d’une réponse générée selon une politique prédéfinie, l’autorité associée peut primer sur la similarité sémantique. Pendant le débogage, un journal d’erreurs récent peut avoir plus d’importance que la documentation générale.

L’ordre joue également un rôle crucial. Privilégiez d’abord les instructions stables et fiables lorsque la sémantique du cache du fournisseur bénéficie d’un préfixe partagé. Placez la tâche et la décision en cours à proximité des données qu’elles citent. Évitez d’inclure des horodatages ou des identifiants de demande dans les préfixes stables lorsqu’ils ne sont pas nécessaires.

Comprimer sans perdre l’état

La compression est dégradante à moins que l’original reste accessible. Il convient d’optimiser le nombre de tokens par tâche réussie, et non le nombre de tokens par requête : un résumé trop agressif qui oblige à une nouvelle récupération ou entraîne un tool call incorrect n’est pas moins coûteux.

Utiliser des mécanismes distincts pour chaque type de matériau :

• Conversation : résumer les décisions prises, les questions en suspens ainsi que les engagements pris.
• Observations sur les outils : conserver les résultats obtenus sous forme de texte et les références aux artefacts ; supprimer le texte générique et les données redondantes.
• Preuves récupérées : garder les identifiants des sources, les segments pertinents ainsi que les dates d’effet afin que le système puisse les récupérer à nouveau.
• État de la tâche : stocker ces informations de manière normalisée en dehors du résumé.
• Traçabilité des fichiers ou artefacts : maintenir un index explicite des lectures, écritures, hachages et résultats des tests.

Déclencher la compactation en fonction de la dégradation mesurée ou d’un seuil budgétaire défini pour le modèle et la tâche. Il ne faut pas établir une règle générale du type « compresser à 70 % », comme si tous les modèles atteignaient leur limite au même moment.

Évaluer la compression à l’aide de sondes nécessitant une continuation, et non une superposition lexicale :

• Quel est l’objectif actuel et quelle est la prochaine action à entreprendre ?
• Quels fichiers ou enregistrements ont été modifiés ?
• Quelle décision a été rejetée et pourquoi ?
• Quelle source étaye la prétention actuelle ?
• Quelle approbation est encore en attente ?

Exécutez la même tâche avec et sans compression. Comparez le taux de réussite, les actions incorrectes, les requêtes de récupération supplémentaires, la latence et le nombre total de tokens.

Optimiser le chemin de contexte

L’optimisation doit préserver le contrat de décision. Quatre techniques issues du guide initial restent utiles lorsqu’elles sont appliquées à un goulot d’étranglement identifié :

Historique complet compacté

Remplacez les anciennes séquences de conversation par un transfert structuré qui enregistre les décisions prises, les questions non résolues, les artefacts modifiés ainsi que l’état des tests. Assurez-vous que le transcript original ou les artefacts restent accessibles lorsque leur révision ou leur récupération s’avère nécessaire.

Masquer les observations détaillées

Un outil peut retourner des pages de journaux lorsque l’étape suivante a besoin d’un statut, d’un code d’erreur et d’une référence à l’artefact correspondant. Il convient de transformer le résultat brut en une observation structurée après en avoir vérifié la validité, tout en conservant l’intégralité du chargement externe au prompt. Il ne faut pas permettre au modèle de résumer et d’éliminer ainsi le seul indice disponible concernant l’échec.

Préserver les préfixes pouvant être mis en cache

Les fournisseurs et les environnements d’exécution peuvent réutiliser du travail lorsque le début d’une requête reste stable. Il convient de conserver les instructions durables ainsi que tool schemas dans un ordre cohérent, et de placer les horodatages, les identifiants de requête, les preuves récupérées et l’état actuel dans la partie suffixe dynamique. Vérifiez d’abord les sémantiques de mise en cache du fournisseur avant de concevoir vos solutions en fonction d’elles.

Partitionnement par décision

Une étape de planification, une étape de récupération, une étape d’appel d’outils et une étape de réponse finale n’ont pas besoin des mêmes données. Il convient de fournir à chaque étape les instructions, l’état, les preuves et les outils dont elle a besoin, en respectant un niveau minimal de fiabilité. Cela permet de réduire à la fois l’utilisation de tokens et la vulnérabilité des capacités du système, mais seules les évaluations au niveau de la tâche peuvent déterminer si cette segmentation a supprimé des informations essentielles.

Sécuriser la chaîne d’approvisionnement des contextes

Le poisonage de contexte peut survenir via des documents, des mémoires, tool results, des compétences, ou des messages antérieurs de l’assistant. Marquer un texte comme « non fiable » aide le modèle, mais sa mise en œuvre doit reposer sur une architecture adaptée.

Utilisez ces limites :

1. Autoriser l’accès et l’exécution des outils avant toute récupération de données.
2. Séparer les canaux de données des instructions et délimiter le texte externe.
3. Définir une liste blanche d’outils par étape et par acteur ; privilégier l’absence de capacités à produire des effets secondaires par défaut.
4. Valider les identifiants de ressources plutôt que de laisser le modèle générer des clés d’utilisateur ou des chemins de fichiers.
5. Exiger une confirmation pour les opérations à fort impact, en se basant sur les politiques définies et non sur la confiance du modèle.
6. Scanner et examiner les compétences ou connecteurs exécutables avant leur installation.
7. Empêcher que des secrets ou des données sensibles brutes ne soient intégrés aux journaux ou à la mémoire à long terme.

La « réparation » automatique n’est appropriée que pour les modifications qui préservent le sens, comme par exemple l’analyse d’un format de date connu. Remplir les arguments manquants d’outils par des « valeurs par défaut raisonnables » peut altérer le fonctionnement. Demandez des précisions ou refusez la modification lorsque le sens est incertain.

Exemple concret : une demande de support pour une clé API

Pour la question « Pourquoi ma clé API ne fonctionne-t-elle pas ? », la prochaine étape consiste à collecter des preuves diagnostiques, et non à générer une réponse définitive. L’assembleur peut inclure :

• politique de support fiable et contrat de réponse préétabli
• identifiant de compte authentifié ainsi que le forfait correspondant, issus de l’état de l’application
• objectif actuel du ticket et actions déjà tentées
• deux plages actuelles du runbook sélectionnées dans le périmètre du produit/version
• une mémoire ciblée indiquant que la clé a été créée il y a trois jours, avec information sur son origine check_api_key_status et search_incidents, mais pas les outils de suppression ou de rotation de clés

Le modèle propose une vérification de statut en lecture seule. Le code d’application autorise le compte, appelle l’outil et enregistre une observation tapée. Une deuxième appel au modèle reçoit les sections pertinentes du guide opérationnel ainsi que cette observation. La réponse finale cite la version du guide opérationnel, ne affiche jamais la clé, et ne propose la rotation que comme une action autorisée séparément.

Notez ce qui est exclu : l’historique des tickets non pertinents, tous les exemples de support, les exports bruts des comptes, les outils de mutation, ainsi que les mémoires relatives à d’autres locataires.

Antipatterns à tester explicitement

• Remplir la fenêtre : charger tous les documents récupérés, l’historique, les mémoires ainsi que les outils, tant que la capacité le permet.
• RAG partout : utiliser la récupération sémantique pour les valeurs qui doivent figurer dans une base de données, un service de politique ou l’état d’une application authentifiée.
• Mémoire illimitée : conserver des faits inférés sans aucune notion de péremption, de correction ni de suppression.
• Une seule appelée par étape : solliciter un prompt unique pour effectuer des tâches de récupération, de raisonnement, d’autorisation, de modification et d’explication, sans frontières visibles.
• Le schéma équivaut à la validité : considérer des JSON valides comme une preuve que les valeurs, les permissions ou les décisions métier sont correctes.
• Aucune évaluation des composants : ne pas évaluer autre chose que le texte final, en ignorant les échecs liés à la récupération, au choix du contexte ou aux outils utilisés.

Transformez chaque anti-modèle en contre-exemple dans l’ensemble d’évaluation. Une directive qui n’est jamais appliquée par une tâche ou un suivi est facile à enfreindre sans que l’on s’en aperçoive.

Évaluer l’assembleur, et non seulement la réponse

Créez un ensemble de tâches fixes comprenant des étiquettes d’empreintes, des limites de permissions, les tool calls requis, ainsi que des actions interdites. Pour chaque modification de la politique de contexte, mesurez :

Utilisez des ablations pour déterminer la valeur causale : retirez progressivement la mémoire, reranking, les exemples ou la compression, un élément à la fois. Un composant qui ajoute des tokens sans améliorer la tranche pertinente ne devrait pas être chargé par défaut.

Conclusion

Un bon context engineering est sélectif et responsable. Il n’occupe pas une fenêtre de traitement trop vaste, car de la capacité reste disponible. Il construit un ensemble de travail spécifique à chaque étape à partir d’instructions fiables, d’un état de tâche canonique, de preuves ciblées, de mémoires revues, ainsi que d’outils autorisés.

Le cycle durable est simple : assembler, manifester, proposer, valider, exécuter et évaluer. Lorsqu’une décision échoue, ce cycle indique si l’élément manquant était une preuve, une fraîcheur, une autorité, un état ou une politique – et fournit un test pour la prochaine modification.

Références

• Perdu au milieu — utilisation dépendante de la position dans un contexte long Règle — évaluation multi-tâche de la longueur de contexte efficace
• Spécification du protocole de contexte du modèle — Concepts de protocole et spécifications actuelles Évaluation de la compression de contexte pour les agents AI — encadrement par tokens par tâche et évaluation basée sur des sondages Prompt injection attaques et défenses dans LLMapplications intégrées — taxonomie des menaces et mécanismes de défense