Le context engineering fiabilise les agents IA en contrôlant ce que le LLM reçoit à chaque appel. Pas juste le prompt. Le vrai sujet, c’est l’assemblage du contexte, la mémoire, le RAG, les outils, et tout ce qui peut noyer les bonnes instructions.
Pourquoi les agents échouent en production ?
Les agents échouent souvent en production parce que le contexte envoyé au modèle devient trop lourd, trop bruyant ou contradictoire, pas forcément parce que le modèle est mauvais.
En démo, tout est propre. On donne une tâche claire, deux ou trois exemples, un outil bien défini, et l’agent répond correctement. Puis on le branche à de vrais flux business. Là, il reçoit l’historique client, des documents internes, des règles métier, des données CRM, des retours d’API, des messages précédents, parfois même des bouts de raisonnement intermédiaires. Et d’un coup, ce qui semblait intelligent devient instable.
Comment créer un assistant IA local pour coder ?
Le point que je vois souvent, c’est que la performance perçue du LLM dépend énormément de la qualité des données d’entrée. Un LLM, c’est le modèle de langage. Il prédit la meilleure suite possible à partir de ce qu’on lui donne. Si on lui donne un mélange flou, il va faire de son mieux avec un mélange flou.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
Le vrai piège, c’est que tout finit dans la même fenêtre de contexte. La fenêtre de contexte, c’est l’espace disponible dans lequel le modèle lit les informations avant de répondre. Même quand elle est grande, elle reste une ressource limitée et sensible.
Le problème ne vient pas seulement du nombre de tokens. Un token, pour faire simple, c’est un petit morceau de texte que le modèle traite. Le souci vient aussi de la qualité de ces tokens.
- La pertinence : Est-ce que cette information aide vraiment l’agent à décider ?
- L’ordre : Est-ce que les infos importantes arrivent au bon moment ?
- La fraîcheur : Est-ce que la donnée est encore valable ?
- La cohérence : Est-ce que deux sources ne disent pas l’inverse ?
Comment résumer des documents avec une IA souveraine ?
J’ai vu des agents qui semblaient très bons en test, puis perdaient complètement le fil dès qu’on leur réinjectait trop d’historique ou trop de documentation brute. Pas parce qu’ils étaient “nuls”. Parce qu’on leur demandait de trier, prioriser, vérifier et décider en même temps, sans hiérarchie claire.
Avant de parler de techniques pour corriger ça, il faut poser une distinction importante. Le prompt engineering et le context engineering ne règlent pas le même problème. Et c’est souvent là que les projets IA commencent à dérailler.
Prompt engineering ou context engineering ?
Le prompt engineering travaille la formulation de l’instruction. Le context engineering travaille tout ce qui est envoyé au modèle autour de cette instruction. C’est la différence la plus simple, et franchement la plus utile à garder en tête.
Agentforce Operations peut-il automatiser le back-office ?
Quand je fais du prompt engineering, je cherche à mieux guider le modèle à un instant donné. Je précise son rôle, la consigne, le format attendu, le ton, les contraintes, parfois les étapes de raisonnement. C’est très utile. Un prompt flou donne souvent une réponse floue, surtout quand on demande un livrable précis.
Mais ça ne suffit plus dès qu’on parle d’agent IA. Un agent ne fait pas juste une réponse dans une conversation propre. Il enchaîne plusieurs appels au modèle, utilise une mémoire, appelle des outils, va chercher des documents avec du RAG, c’est-à-dire de la recherche dans une base documentaire, et manipule des données qui changent selon l’utilisateur, le moment ou la tâche.
Le context engineering, c’est plus proche d’une discipline logicielle. Je ne rédige pas juste un meilleur prompt. Je construis automatiquement le bon contexte pour chaque appel. Je décide quoi charger, quoi filtrer, quoi résumer, quoi supprimer, quoi mettre en avant. Le contexte devient un tampon dynamique, pas un énorme bloc de texte qu’on recolle partout en espérant que le modèle s’y retrouve.
Comment créer un assistant IA local avec MCP et Qwen ?
J’ai vu ce problème chez un client qui avait un agent support connecté à toute sa documentation. Le prompt était correct. Le souci venait du contexte. Trop de documents remontaient, certains obsolètes, d’autres presque identiques. Le modèle répondait avec assurance, mais sur la mauvaise version de la procédure. Le vrai bug n’était pas dans la phrase d’instruction. Il était dans ce qu’on donnait au modèle pour réfléchir.
Les deux approches restent complémentaires. Un bon prompt dans un mauvais contexte peut échouer. Un bon contexte avec des instructions floues peut aussi produire un résultat faible. Mais en production, le gros levier est souvent la gestion du contexte, parce que c’est là que le bruit apparaît.
| Critère | Prompt engineering | Context engineering |
| Objectif | Formuler une meilleure instruction pour guider la réponse. | Construire le bon contexte pour chaque appel au modèle. |
| Périmètre | Rôle, consigne, ton, format, contraintes. | Mémoire, outils, RAG, données, historique, filtres, résumés. |
| Limite principale | Ne corrige pas un contexte bruité ou incomplet. | Ne compense pas toujours des instructions vagues ou contradictoires. |
Que contient vraiment la fenêtre de contexte ?
La fenêtre de contexte contient les instructions système, l’historique ou la mémoire, les connaissances récupérées et les définitions d’outils nécessaires à l’agent. Tout ça arrive dans le même espace limité, le fameux budget de tokens. Un token, pour simplifier, c’est un petit morceau de texte que le modèle lit et traite.
Le system prompt, c’est la base. Il définit la persona de l’agent, ses règles, ses contraintes d’exécution, ce qu’il a le droit de faire ou non, et parfois des éléments dynamiques comme le rôle de l’utilisateur, la langue, le contexte métier ou le niveau de priorité. C’est utile, mais il y a un piège. Un system prompt trop volumineux consomme des tokens à chaque appel. Et plus il est long, plus les consignes vraiment importantes peuvent se noyer dans le reste. J’ai déjà vu des agents avec trois pages de règles, mais incapables de respecter la règle principale. Pas parce que le modèle était mauvais. Parce que le contexte était mal hiérarchisé.
L’état de conversation et la mémoire, c’est tout ce que l’agent sait déjà de l’échange ou de l’utilisateur. Ça peut être les derniers messages, un résumé, des préférences, des décisions prises avant. Mais réinjecter tout l’historique sans tri, c’est créer du bruit. Les anciens messages peuvent être obsolètes, redondants, ou même contradictoires avec la situation actuelle. L’agent peut alors s’accrocher à une vieille information, juste parce qu’elle est présente dans le contexte.
Les connaissances récupérées via RAG ajoutent une autre couche. RAG veut dire Retrieval Augmented Generation, en gros on va chercher des documents externes pour aider le modèle à répondre. Mais récupérer un document ne suffit pas. Il faut nettoyer, réduire et sélectionner les extraits vraiment utiles. Sinon on donne au modèle trop de texte, parfois à moitié pertinent, et on augmente le risque d’hallucination ou de réponse approximative.
Les définitions d’outils et les sorties structurées prennent aussi de la place. Les schémas d’API, les endpoints, les paramètres obligatoires, les formats JSON attendus, les contraintes métier… Tout ça entre dans la fenêtre de contexte. Charger tout le catalogue d’outils à chaque appel est rarement une bonne idée. Mieux vaut charger seulement les outils utiles à la tâche en cours.
Tous ces blocs sont en concurrence dans le même budget. Ce n’est pas une liste technique, c’est un arbitrage permanent. Si je donne trop de place aux règles, je réduis la place pour les documents. Si je charge trop d’historique, je pollue la décision. La suite logique, c’est donc de filtrer, compresser et charger juste-à-temps.
Comment mieux gérer le contexte ?
On gère mieux le contexte en filtrant les données, en compressant la mémoire, en récupérant seulement les extraits pertinents et en chargeant les outils juste au bon moment.
Le context engineering, c’est simplement l’art de donner au modèle le bon contexte, ni trop, ni trop peu. Un agent LLM, donc un agent basé sur un grand modèle de langage, ne devient pas meilleur parce qu’on lui jette plus d’informations dans le prompt. Souvent, c’est même l’inverse. Trop de contexte crée du bruit, dilue les consignes et augmente les chances qu’il parte dans une mauvaise direction.
La base tient en quatre réflexes simples.
- Filtrer. Garder uniquement ce qui aide vraiment la tâche en cours. Une préférence client utile, oui. Trois pages d’historique sans impact, non.
- Compresser. Résumer l’historique ou la mémoire sans perdre les décisions importantes, les contraintes actives et les préférences fiables.
- Récupérer peu, mais mieux. Avec du RAG, c’est-à-dire de la recherche documentaire injectée au modèle, mieux vaut trois extraits précis que quinze passages moyens.
- Charger juste-à-temps. Ne pas injecter toutes les connaissances, toutes les règles et tous les outils par défaut.
Le point que je vois souvent sous-estimé, c’est l’indexation des définitions d’outils. Au lieu de mettre tout le catalogue d’outils dans le prompt, l’agent peut interroger une couche de recherche qui contient les descriptions, les paramètres attendus et les cas d’usage. Il ne charge ensuite que les schémas pertinents. Ça évite qu’il appelle un outil CRM alors qu’il devait juste chercher dans une base documentaire, ou qu’il invente des paramètres parce qu’il a trop de choix sous les yeux.
Dans les projets IA, j’essaie d’abord de réduire le contexte avant de changer de modèle. C’est souvent moins cher, plus stable et plus rapide à corriger. Et surtout, ça se teste. Je teste la qualité du contexte comme je testerais une API ou un pipeline de données. Est-ce que les bons extraits remontent. Est-ce que les instructions critiques restent visibles. Est-ce que les outils proposés sont vraiment ceux dont l’agent a besoin.
| Hallucinations | Contexte trop large ou sources peu fiables | Filtrer les sources et récupérer moins d’extraits, mais plus précis | Réponses plus factuelles et plus faciles à vérifier |
| Perte d’instruction | Consignes noyées dans trop d’historique | Compresser la mémoire et remonter les contraintes actives | Agent plus constant dans son comportement |
| Mauvais outil appelé | Catalogue d’outils injecté en bloc | Indexer les définitions et charger les schémas juste-à-temps | Moins d’erreurs d’appel et moins de paramètres inventés |
| Réponses incohérentes | Mémoire non résumée ou contradictions dans le contexte | Dédupliquer, résumer et prioriser les décisions récentes | Sorties plus stables et plus alignées avec la tâche |
Et si le vrai bug venait du contexte ?
Le context engineering remet le sujet au bon endroit. Quand un agent IA se trompe en production, je ne commence pas par accuser le modèle. Je regarde ce qu’on lui envoie. Un system prompt trop lourd, une mémoire brute, un RAG mal filtré ou trop d’outils disponibles peuvent suffire à dégrader les réponses. La bonne approche consiste à construire un contexte propre, utile et dynamique à chaque appel. Moins de bruit, plus de signal. C’est souvent là que les agents deviennent vraiment exploitables. Le bénéfice pour vous est simple : des agents LLM plus fiables, plus stables et plus faciles à maintenir.
FAQ
- Qu’est-ce que le context engineering pour les LLM ?
Le context engineering consiste à gérer automatiquement tout ce qui entre dans la fenêtre de contexte d’un LLM. Ça inclut les instructions système, l’historique, la mémoire, les documents récupérés, les définitions d’outils et les contraintes de sortie. L’objectif est simple : envoyer au modèle le bon contexte, au bon moment, sans le noyer. - Quelle est la différence avec le prompt engineering ?
Le prompt engineering travaille surtout la formulation de la consigne. Le context engineering va plus loin : il organise les données autour de cette consigne. En production, c’est souvent ce deuxième point qui fait la différence, parce que l’agent reçoit beaucoup plus qu’un simple prompt. - Pourquoi un agent IA marche en démo puis échoue en production ?
Parce qu’en production, on ajoute de la mémoire, des historiques, des documents, des outils et des règles métier. Si tout est injecté sans tri, le modèle reçoit trop de bruit. Les instructions importantes se diluent, les contradictions apparaissent et les réponses deviennent moins fiables. - Quel rôle joue le RAG dans le contexte ?
Le RAG apporte des connaissances externes au modèle, mais il doit être contrôlé. Récupérer trop de passages ou des extraits peu pertinents peut créer de la confusion. Le bon réflexe est de nettoyer, réduire et sélectionner les morceaux vraiment utiles avant de les envoyer au LLM. - Comment éviter de surcharger la fenêtre de contexte ?
Il faut filtrer les informations, résumer la mémoire, limiter l’historique réinjecté, récupérer seulement les extraits utiles et charger les définitions d’outils juste quand elles sont nécessaires. Le but n’est pas de tout donner au modèle, c’est de lui donner ce qui l’aide vraiment à décider.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, analytics engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent passer de la démo IA sympa à des systèmes fiables, mesurables et maintenables. J’ai travaillé avec des organisations comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer ou fiabiliser vos agents IA, contactez-moi, je peux vous aider.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.