Context engineering pour agents IA

Introduction

Le context engineering agents ia devient utile quand un agent déjà en production coûte trop cher, oublie les bons signaux ou mélange historique, retrieval et instructions métier. Si vous avez déjà appris à créer un agent IA, l’étape suivante consiste à gouverner ce qu’il voit réellement. L’enjeu n’est pas de “mettre plus de contexte”, mais de décider quoi transmettre, quand, et sous quelle forme. Cette discipline aide surtout pour un agent RAG, un copilote interne ou un workflow multi-agent. Si votre cas reste simple, avec peu d’outils et peu d’état, restez sur une approche plus simple : un bon prompt et un flux déterministe suffisent souvent.

Résumé rapide

Point clé	À faire	À éviter
Rôle du context engineering	Traiter le contexte comme une couche d’architecture	Le réduire à un prompt plus long
Ce qui entre dans le run	Injecter seulement ce qui aide la décision courante	Coller tout l’historique “au cas où”
Mémoire	Séparer session courte, mémoire durable et retrieval	Mélanger préférences, logs et documents dans le même bloc
Signal de maturité	Contrat explicite entre état, mémoire, outils et récupération	Empilement ad hoc de chunks et d’instructions
Quand l’utiliser	Agent RAG, support, copilote métier, multi-agent	Prototype simple sans forte variabilité de contexte

Explication

Le context engineering répond à un problème plus profond que la taille du prompt. Un agent n’échoue pas seulement parce qu’il manque de place dans sa fenêtre de contexte. Il échoue surtout parce qu’on lui donne des informations mal hiérarchisées, arrivant au mauvais moment, sans distinction entre ce qui doit guider la décision, ce qui doit rester consultable, et ce qui relève du simple historique technique.

Le bon modèle mental est le suivant : un agent opère avec un contexte actif très limité, alimenté par plusieurs couches qui n’ont pas le même statut. L’état courant décrit où en est le run. La mémoire de session rappelle ce qui vient d’être dit ou décidé. La mémoire durable stocke préférences, faits stabilisés et traces utiles sur le long terme. Le retrieval va chercher à la demande des documents externes. Les outils, eux, n’entrent pas comme du texte brut : ils servent à produire ou vérifier une information quand le contexte actif ne suffit pas.

Autrement dit, le context engineering llm consiste à gouverner les flux d’information, pas seulement leur volume. Vous définissez quels signaux doivent être présents avant une décision, lesquels peuvent rester hors bande, et lesquels ne doivent être récupérés qu’en cas de besoin. Cette approche réduit les contradictions, limite le coût et rend le comportement de l’agent plus explicable. C’est une discipline d’architecture parce qu’elle touche au découpage du système, à la mémoire, à l’observabilité et à la maintenance, bien au-delà du prompt initial.

Développement principal

Le piège classique consiste à croire qu’un agent devient meilleur quand on lui donne “plus de contexte”. En pratique, un contexte plus gros contient souvent plus de bruit, plus d’instructions concurrentes et plus de coûts cachés. Le sujet n’est donc pas la quantité, mais la sélection et l’ordre de priorité.

Une manière simple de cadrer le problème est de séparer trois zones : ce qui entre immédiatement dans le run, ce qui reste en base, et ce qui se récupère à la demande.

Contexte actif du run
- objectif courant
- état de la tâche
- contraintes de sortie
- 1 à 3 faits récents utiles

Reste en base
- historique complet
- préférences durables
- documents métier
- traces d'exécution

Récupéré à la demande
- passages RAG pertinents
- mémoire longue ciblée
- résultats d'outils
- données externes fraîches

Ce découpage évite un antipattern fréquent : transformer le prompt en conteneur universel. Quand tout est injecté en même temps, l’agent ne sait plus clairement ce qui est prioritaire. Une préférence ancienne d’utilisateur peut se retrouver au même niveau qu’une contrainte de sécurité. Un document RAG peu fiable peut contredire l’état réel du dossier. Un ancien message de session peut réapparaître alors que le run a déjà changé de phase.

La première brique à discipliner est l’état. L’état n’est pas la mémoire. C’est la représentation opérationnelle du run : étape courante, objectif actif, action déjà tentée, validation obtenue ou non, sortie attendue. Si cet état est implicite, le modèle doit le reconstruire à partir du texte, ce qui produit des erreurs de coordination. Dans une bonne gestion contexte agent, l’état est structuré, souvent compact, et injecté avant le reste parce qu’il définit la situation présente.

La deuxième brique est la mémoire de session. Elle sert à éviter que l’agent oublie ce qui vient d’être dit, mais elle ne doit pas devenir un transcript intégral recopié à chaque tour. Il faut résumer, compacter et conserver seulement les décisions, contraintes et ambiguïtés encore actives. Si vous gardez tout, vous payez une taxe permanente sur chaque requête. Si vous résumez trop tôt, vous perdez des détails encore utiles. Le bon compromis consiste souvent à conserver un court historique brut récent, plus un résumé évolutif de la session.

La troisième brique est la mémoire durable. Elle contient ce qui vaut au-delà d’une session : préférences stables, données utilisateur non volatiles, faits métier consolidés, et parfois enseignements extraits de runs précédents. C’est ici que la distinction entre mémoire et contexte agent devient importante : tout ce qui est mémorisé ne doit pas être injecté. La mémoire durable doit rester interrogeable, filtrable et priorisable, sinon elle redevient juste un gros prompt externalisé. Si votre principal problème vient de la mémoire et non du prompt, poursuivez avec les stratégies de mémoire pour agents.

La quatrième brique est le retrieval. Dans un agent RAG, il ne sert pas à “nourrir” aveuglément le modèle, mais à satisfaire un besoin d’information précis. Le retrieval doit donc être déclenché par une question ou une lacune identifiable : manque de contexte métier, besoin de vérifier une procédure, nécessité de retrouver un précédent pertinent. Quand tout part systématiquement en RAG, le système masque ses propres défauts de conception. Vous augmentez le coût, la latence et le risque de contradictions entre documents. Le guide RAG pour agents IA complète bien cette logique côté récupération documentaire.

La cinquième brique concerne les outils et les résultats d’outils. Beaucoup d’équipes injectent des réponses d’API complètes dans le contexte actif alors qu’un sous-ensemble structuré suffit. Or un résultat outil mal normalisé pollue vite le run : clés inutiles, bruit textuel, statuts techniques, détails de transport. Le context engineering implique donc aussi une couche d’adaptation : transformer la sortie brute d’un système externe en signal exploitable par l’agent.

En pratique, choisir ce qui entre dans le contexte actif repose sur quatre questions simples.

1. Cette information change-t-elle la décision en cours ?
2. Est-elle plus fiable qu’une autre source déjà présente ?
3. Doit-elle être lue maintenant, ou seulement disponible à la demande ?
4. Peut-elle être résumée ou structurée sans perdre le sens utile ?

Si la réponse est non à l’une des deux premières questions, il y a de bonnes chances que l’information doive rester hors bande. Si la réponse est oui à la troisième, elle relève probablement du retrieval ou d’un appel outil. Et si la quatrième réponse est oui, il faut souvent préférer une forme structurée à un bloc de texte libre.

Quand utiliser cette discipline ? D’abord, dès que votre agent combine plusieurs sources : historique conversationnel, base documentaire, état de workflow, préférences utilisateur et outils. Ensuite, quand vous observez des symptômes typiques : réponses longues mais peu utiles, oublis de priorités métier, coûts qui dérivent avec la croissance de l’historique, ou comportements différents d’un run à l’autre malgré des cas proches. Enfin, quand plusieurs équipes touchent au même agent. Sans contrat de contexte, chacun ajoute sa couche, et l’ensemble devient vite impossible à raisonner.

Quand l’éviter ? Si votre agent se résume à une tâche courte, avec une seule source de vérité, peu de tours et pas de mémoire durable, formaliser une architecture complète de contexte peut être prématuré. Une approche légère décrite dans Prompt engineering pour agents peut suffire tant que vous n’avez ni dérive de coût, ni confusion entre état et mémoire, ni besoin fort d’observabilité.

Un autre point important concerne la priorité des sources. Toutes les informations n’ont pas le même poids. Dans un agent métier, les règles système et l’état validé du dossier doivent généralement primer sur une hypothèse issue d’un document récupéré. Sans ordre explicite, le modèle arbitrera lui-même entre sources concurrentes. C’est là que naissent beaucoup de réponses “plausibles mais fausses”. Une bonne architecture de contexte agent ia définit donc une hiérarchie : instruction système, état courant, contraintes métier, mémoire session, mémoire durable, retrieval opportuniste, puis seulement texte de fond complémentaire.

Il faut aussi penser à la fraîcheur. Certaines données doivent être lues en temps réel, d’autres peuvent être servies depuis une mémoire stabilisée. Une préférence utilisateur peut vivre longtemps. Un stock, un statut de ticket ou une politique de remboursement peuvent exiger une vérification fraîche. Si vous injectez un souvenir ancien comme s’il s’agissait d’un fait actuel, l’agent gagne en fluidité mais perd en fiabilité. C’est pourquoi le context engineering ne se résume pas à stocker plus ; il impose de décider quelles données doivent être relues au moment du run.

La réalité production ramène enfin ce sujet à des arbitrages très concrets. Plus le contexte actif grossit, plus les coûts de run augmentent, plus les retries deviennent chers, et plus il est difficile d’expliquer pourquoi l’agent a choisi une source plutôt qu’une autre. Sans traces sur les éléments injectés, vous ne savez pas si un échec vient du modèle, du retrieval, d’un résumé de session trop agressif, ou d’une mémoire durable mal filtrée. Le context engineering devient alors un levier d’observabilité : vous pouvez comparer quels blocs ont été inclus, quels blocs ont été récupérés, et lesquels ont réellement changé la décision.

Enfin, cette discipline joue un rôle clé dans les architectures multi-agent. Si chaque sous-agent reçoit tout le contexte global, vous dupliquez le bruit et les coûts. Mieux vaut transmettre à chacun un contexte spécialisé : objectif local, état nécessaire, et références minimales. Ce découpage rend la coordination plus stable et évite que la mémoire d’un agent devienne un fourre-tout utilisé par tous sans gouvernance.

Exemple concret

Prenons un agent RAG métier destiné à un support interne RH. Les employés posent des questions sur les congés, les justificatifs et les règles locales. L’agent doit répondre à partir d’une base documentaire, tenir compte du profil employé, et ouvrir un ticket si la demande sort du cadre standard.

Une implémentation immature injecte souvent tout ce qu’elle a : historique complet du chat, fiche employé entière, résultats de recherche multiples, anciennes interactions, consignes produit, et parfois même la sortie brute des outils. Le système semble “riche”, mais il produit vite trois problèmes : réponses plus lentes, contradictions entre documents, et difficulté à expliquer pourquoi un mauvais paragraphe a dominé.

Une version disciplinée commence par définir le contexte actif minimal : la question courante, le pays ou l’entité RH concernée, le statut du run, et la forme de sortie attendue. Ensuite, le profil employé n’entre pas en entier ; seuls les attributs nécessaires à la décision sont projetés dans le run. Les politiques RH restent en base documentaire et sont récupérées à la demande selon le type de question. Les anciennes conversations ne sont pas recopiées intégralement : un court résumé de session suffit tant qu’aucun litige n’est ouvert.

Le flux peut ressembler à ceci : classification de la demande, retrieval ciblé de deux ou trois passages, réponse initiale, puis vérification d’un besoin d’escalade. Si le sujet touche un cas individuel sensible, l’agent interroge un outil interne pour vérifier un statut à jour, au lieu de se fier à une mémoire ancienne. S’il doit garder des préférences, une couche comme Agent vector memory peut servir de support technique, mais seulement avec un filtrage clair sur ce qui mérite vraiment d’être réinjecté.

Exemple de sortie

{
  "intent": "question_regle_conges",
  "needs_fresh_check": false,
  "retrieved_sources": ["politique_conges_fr", "faq_rtt"],
  "answer_mode": "direct",
  "escalation": false
}

Ce cas est reproductible parce qu’il impose des frontières nettes : état RH courant dans le run, politique documentaire en retrieval, préférences hors bande, vérification fraîche via outil seulement quand le cas l’exige. Le gain n’est pas seulement qualitatif. L’agent devient aussi plus explicable, plus testable et plus facile à maintenir quand les politiques changent.

Bonnes pratiques

Le meilleur réflexe consiste à écrire un contrat de contexte avant d’optimiser le prompt. Listez les blocs possibles, leur source, leur priorité, leur durée de vie et la condition d’injection. Cette simple discipline révèle souvent que la moitié du contexte envoyé n’aide aucune décision réelle.

Deuxième règle : séparez clairement état, mémoire, retrieval et résultats d’outils. Quand ces couches sont confondues, les incidents deviennent difficiles à diagnostiquer. En production, ce flou se paie en temps d’investigation, en retries inutiles et en maintenance défensive.

Troisième règle : instrumentez ce qui a été injecté à chaque run. Sans observabilité, vous ne pouvez pas relier un mauvais résultat à une version de résumé, à un retrieval trop large ou à une mémoire trop bavarde. La réalité terrain n’est pas théorique : coûts de contexte, coordination entre équipes, et régressions discrètes apparaissent vite quand personne ne sait quelles données ont piloté la décision.

Enfin, supposez que le contexte doit rester petit par défaut et justifié par exception. Cette posture évite de transformer chaque nouveau besoin métier en bloc de texte supplémentaire collé au système.

Questions fréquentes

Le context engineering est-il juste un autre nom pour le prompt engineering ?

Non. Le prompt engineering travaille surtout la formulation des instructions. Le context engineering organise les sources d’information, leur priorité, leur durée de vie et leur injection dans le run. Les deux se complètent, mais le second relève davantage de l’architecture que de la rédaction du prompt.

Faut-il tout stocker dans une mémoire longue pour améliorer un agent ?

Non plus. Tout stocker augmente le bruit et complique la sélection. Une mémoire durable utile conserve des faits stables, des préférences ou des signaux réellement réutilisables. Le reste doit souvent rester en logs, en base documentaire, ou être recalculé à la demande.

Comment savoir si mon agent souffre d’un problème de contexte plutôt que de modèle ?

Si l’agent répond différemment à des cas proches, oublie des priorités métier, ou se dégrade à mesure que l’historique grandit, le problème vient souvent du contexte. Un meilleur modèle peut masquer temporairement le symptôme, mais rarement corriger une architecture contextuelle confuse.

Le sujet concerne-t-il seulement les agents RAG ?

Non. Le RAG est un cas évident, mais le problème existe aussi dans les copilotes internes, les agents outillés et les workflows multi-agent. Dès qu’il faut arbitrer entre état, mémoire, outils et sources externes, la question du contexte devient structurante.

Articles liés

Le point central à retenir est simple : un agent utile n’est pas celui qui voit tout, mais celui qui reçoit le bon contexte au bon moment. Le context engineering sert à gouverner cette sélection pour améliorer qualité, coût et explicabilité sans transformer le prompt en dépôt de données.

Si votre principal problème vient de la mémoire et non du prompt, poursuivez avec notre guide sur les stratégies de mémoire pour agents IA.

• Créer son premier agent IA en Python
• RAG pour agents IA : guide du Retrieval Augmented Generation
• Stratégies de mémoire pour agents IA
• Prompt engineering pour agents IA
• Mémoire vectorielle pour agents IA