L’ingénierie du contexte, c’est gérer ce que le LLM reçoit à chaque appel. Pas juste écrire un meilleur prompt. Je vais montrer pourquoi les agents IA se dégradent en production, ce qui remplit vraiment la fenêtre de contexte, et comment garder un contexte utile, propre et actionnable.
Besoin d'aide ? Découvrez les solutions de notre agence d'agents IA.
Pourquoi le prompt ne suffit plus ?
Le prompt ne suffit plus parce qu’en production, le problème vient souvent moins de la consigne que de tout ce qu’on envoie autour au modèle. Une bonne instruction aide, oui. Mais si le contexte est sale, trop long, mal trié ou contradictoire, même un très bon modèle peut répondre à côté.
Je le vois souvent avec des équipes qui ont déjà testé un agent IA. Au début, tout marche bien. On écrit un bon prompt, on fait quelques tests, les réponses sont propres. Puis on ajoute de la mémoire, plusieurs étapes, du RAG, des outils, des sorties JSON, des automatisations dans Make, n8n ou un backend maison. Et là, la fiabilité baisse.
Le RAG, pour faire simple, c’est quand on récupère des documents dans une base de connaissance pour les donner au modèle au moment de répondre. Le LLM, c’est le grand modèle de langage, comme GPT, Claude ou Gemini. Sur le papier, c’est logique. En pratique, on finit parfois par lui envoyer trop de choses.
- Des anciens messages qui ne servent plus.
- Des documents récupérés mais pas vraiment pertinents.
- Des règles métier qui se contredisent.
- Des définitions d’outils trop longues.
- Des consignes importantes perdues au milieu du bruit.
Dans un prototype, on ajuste le prompt à la main. On relit, on corrige, on relance. En production, ce n’est plus juste un prompt. C’est un système logiciel qui doit décider à chaque appel quoi charger, quoi supprimer, quoi résumer et quoi prioriser. Et cette décision change tout.
Une instruction parfaite peut être noyée si elle arrive après dix pages d’historique, vingt extraits RAG moyens et une liste d’outils mal décrits. Le modèle n’est pas magique. Il fait avec ce qu’on lui donne. Si on lui donne un contexte confus, il produit souvent une réponse confuse.
J’ai déjà vu des équipes changer de modèle alors que le vrai sujet était beaucoup plus simple : nettoyer le contexte envoyé au modèle. Elles pensaient avoir un problème de performance IA. Elles avaient surtout un problème d’architecture autour de l’IA.
C’est exactement là qu’on quitte le simple prompt engineering. On ne cherche plus seulement la meilleure phrase à écrire. On conçoit tout ce que le modèle doit voir, oublier, utiliser et ignorer. C’est le passage vers le context engineering.
Quelle différence avec le prompt engineering ?
Le prompt engineering travaille la formulation des instructions. L’ingénierie du contexte travaille l’assemblage dynamique de toutes les données envoyées au modèle. C’est la différence la plus simple, et franchement la plus utile à garder en tête.
Le prompt engineering reste important. Je m’en sers encore tout le temps. On améliore une consigne, on précise un rôle, on impose un ton, on donne quelques exemples, on structure la réponse attendue. C’est nécessaire. Mais c’est assez statique par nature. On écrit une meilleure instruction, puis on espère qu’elle tienne dans tous les cas.
Le problème arrive dès que l’agent doit agir dans un environnement réel. Il doit lire un historique, récupérer des documents, appeler des outils, respecter un format JSON, tenir compte d’une règle métier, ignorer une vieille information, prioriser une donnée récente. Là, la qualité ne dépend plus seulement du prompt. Elle dépend de ce qu’on met autour.
L’ingénierie du contexte, je la vois plutôt comme une discipline logicielle. Elle consiste à sélectionner, filtrer, compresser et organiser automatiquement ce qui entre dans la fenêtre de contexte à chaque appel au modèle. Cette fenêtre contient le system prompt, l’historique de conversation, la mémoire, les résultats RAG, les schémas d’outils, les contraintes de sortie et les informations métier utiles. RAG veut dire Retrieval Augmented Generation, en gros on va chercher des documents pertinents avant de demander au modèle de répondre.
Point important : le system prompt n’est qu’une partie de la fenêtre de contexte. En production, il peut représenter une petite fraction des tokens. Les tokens, ce sont les morceaux de texte que le modèle lit et facture. Le reste vient souvent de l’historique, des documents récupérés, des descriptions d’API et des formats JSON attendus.
La fenêtre de contexte reste un espace limité, même quand les modèles acceptent beaucoup de tokens. Plus elle est grande, plus on peut charger d’informations. Mais ça ne veut pas dire que tout devient utile. Un grand contexte mal géré peut rendre le raisonnement plus fragile.
C’est là qu’apparaît le context rot. Les instructions importantes finissent ensevelies sous des contenus moins pertinents, anciens ou trop verbeux. Le modèle peut perdre le fil, privilégier une donnée secondaire, ou suivre une instruction moins importante juste parce qu’elle est plus visible dans le contexte. Je l’ai vu chez un client avec un agent support : le prompt était propre, mais l’historique noyait les règles de priorité.
| Approche | Objectif | Limite principale | Bon usage |
| Prompt engineering | Améliorer la consigne donnée au modèle | Reste souvent statique | Définir un rôle, un ton, un format, des exemples |
| Ingénierie du contexte | Composer dynamiquement les bonnes informations | Demande une vraie logique logicielle | Gérer mémoire, RAG, outils, historique et contraintes métier |
Maintenant, il faut regarder concrètement ce qui remplit cette fameuse fenêtre de contexte.
Qu’est-ce qui remplit le contexte ?
La fenêtre de contexte est remplie par des sources qui se concurrencent toutes pour le même budget de tokens. C’est ça le point clé. Le modèle ne voit pas “tout votre système”, il voit ce qu’on arrive à faire entrer dans cette fenêtre à un instant donné.
Les instructions système arrivent souvent en premier. Elles définissent la persona, les règles d’exécution, les limites, les priorités, parfois le ton, les formats attendus, les interdictions. C’est utile, évidemment. Mais un system prompt volumineux peut consommer 1 000 à 2 000 tokens à chaque appel. Et ces tokens-là ne sont plus disponibles pour les informations vraiment spécifiques à la tâche du moment.
L’état de conversation et la mémoire prennent vite beaucoup de place aussi. Réinjecter toute la conversation paraît rassurant. On se dit que l’agent aura “tout le contexte”. En réalité, ça devient vite dangereux. Les anciens messages peuvent être obsolètes, contradictoires ou juste inutiles. Le modèle peut alors traiter une ancienne contrainte comme encore valable, même si vous l’avez corrigée depuis. J’ai déjà vu ça chez un client avec un agent support : il continuait à appliquer une ancienne règle tarifaire, simplement parce qu’elle traînait dans l’historique.
Les connaissances récupérées via RAG ajoutent une autre couche. Le RAG, pour Retrieval Augmented Generation, consiste à récupérer des documents externes pour aider le modèle à répondre. Mais récupérer ne suffit pas. Si vous injectez des payloads JSON bruts, du markup, des métadonnées ou des fragments trop longs, vous ajoutez du bruit. Et le bruit favorise les hallucinations. Il vaut mieux donner des extraits nettoyés, courts, pertinents, et surtout au bon moment.
Les définitions d’outils et les sorties structurées remplissent aussi le contexte. Le modèle doit connaître les paramètres, contraintes, schémas JSON et descriptions d’API pour appeler correctement les bons outils. Mais charger tout le catalogue d’outils à chaque appel, c’est souvent une mauvaise idée. L’approche plus propre, c’est la recherche d’outils : on charge seulement les définitions pertinentes, comme le principe de Tool search documenté par Anthropic.
Dans un agent IA, chaque ajout semble logique isolément. Un peu de mémoire, trois documents RAG, dix outils, un gros system prompt. Pris séparément, tout se défend. Ensemble, on obtient vite un agent qui a trop de choses à regarder.
- Réponses qui changent sans raison.
- Oublis de consignes pourtant explicites.
- Mauvais choix d’outils.
- Hallucinations sur des documents fournis.
- Sorties JSON instables.
- Coûts tokens qui montent.
La vraie question n’est donc pas seulement quoi mettre dans le contexte. C’est quoi garder, quoi résumer, quoi retirer, quoi récupérer à la demande, et dans quel ordre le présenter au modèle.
Comment gérer le contexte en production ?
On gère le contexte en production en le traitant comme une ressource logicielle limitée, pas comme un simple champ texte à remplir. Un modèle IA a une fenêtre de contexte, c’est-à-dire une quantité maximale d’informations qu’il peut lire à un moment donné. Si on la remplit mal, l’agent devient lent, cher, confus, parfois franchement mauvais.
Le premier réflexe, c’est le filtrage. Je ne garde que les informations liées à la tâche en cours. Le but n’est pas d’avoir un contexte complet, c’est d’avoir un contexte utile. Un agent support n’a pas besoin de tout l’historique client pour répondre à “Comment changer mon adresse de facturation ?”. Il lui faut le statut du compte, la règle métier, peut-être le canal de réponse. Pas les 47 échanges précédents.
La compression aide aussi beaucoup. Je résume les échanges passés, je transforme les blocs verbeux en faits utiles, je supprime les répétitions. Mais attention, une bonne compression doit préserver ce qui compte encore : décisions prises, contraintes, préférences utilisateur, informations vérifiées et toujours valables. J’ai déjà vu des agents “oublier” une contrainte de sécurité parce qu’un résumé trop agressif l’avait supprimée. C’est le genre de bug discret qui coûte cher.
Le chargement juste-à-temps consiste à injecter les documents, outils ou règles seulement quand l’étape du workflow en a besoin. Si l’utilisateur parle d’un remboursement, là je charge les règles de remboursement. Avant, non. Même logique pour la sélection dynamique des outils : inutile de donner 25 outils à l’agent s’il n’en utilise que 2 dans cette étape.
Dans un workflow multi-étapes, je peux aussi faire du swap d’instructions système. Une étape de qualification, une étape de recherche et une étape d’action n’ont pas besoin du même cadre. Le “system prompt”, c’est l’instruction de fond donnée au modèle. S’il est trop lourd ou trop générique, il pollue tout.
La mémoire doit être utilisée avec retenue. Je ne confonds pas mémoire et historique complet. La mémoire contient des éléments persistants, vérifiés, utiles dans le temps. Pas tout ce qui a été dit.
Le RAG, c’est la récupération de documents pour enrichir la réponse. Là aussi, il faut nettoyer. Je retire les métadonnées inutiles, je limite la taille, j’évite les gros blocs JSON bruts, je préfère des passages courts et directement exploitables.
| Problème | Stratégie | Bénéfice |
| Context rot | Filtrage et compression régulière | Moins de bruit, meilleures décisions |
| Historique trop long | Résumé de mémoire | Conservation des faits utiles sans tout relire |
| RAG bruité | Nettoyage des extraits | Réponses plus précises et moins d’hallucinations |
| Trop d’outils | Sélection dynamique des outils | Moins d’erreurs d’action |
| System prompt trop lourd | Swap d’instructions selon l’état du workflow | Agent plus concentré sur l’étape en cours |
Au final, la qualité d’un agent IA dépend autant de l’orchestration du contexte que du choix du modèle. Un très bon modèle avec un contexte mal géré reste un agent moyen. Un modèle correct avec un contexte propre, lui, peut déjà faire un vrai boulot.
Comment l’appliquer à vos workflows IA ?
Pour l’appliquer à vos workflows IA, il faut auditer ce qui entre dans chaque appel au modèle et décider ce qui mérite vraiment d’y rester. C’est moins sexy qu’un nouveau modèle, mais souvent beaucoup plus rentable.
Je pars toujours d’un appel LLM réel. Un LLM, c’est le modèle de langage, celui qui reçoit votre prompt, votre historique, vos données, vos consignes, parfois vos outils. Je regarde ce qu’on lui envoie vraiment, pas ce qu’on pense lui envoyer. Puis je découpe le contexte par source : consigne système, demande utilisateur, mémoire, documents, résultats d’API, historique de conversation, exemples de sortie.
Après, je mesure ce qui prend de la place. Les tokens, ce sont les morceaux de texte que le modèle lit et facture. Plus vous en envoyez, plus ça coûte, plus ça ralentit, et plus vous augmentez le risque de confusion. Le vrai sujet, ce n’est pas “est-ce que cette info est intéressante ?”, c’est “est-ce qu’elle aide la réponse maintenant ?”.
Dans un workflow n8n, Make, LangChain, LlamaIndex ou une architecture interne, le problème reste le même. Chaque nœud, chaque étape, chaque agent doit recevoir un contexte adapté à son rôle. Il ne faut pas traîner tout le contexte d’une étape à l’autre juste parce que c’est plus simple techniquement. Je vois souvent ça chez des clients : on passe tout le JSON précédent au nœud suivant “au cas où”. Et trois semaines plus tard, personne ne comprend pourquoi les réponses dérivent.
Les bonnes questions sont simples :
- Cette information est-elle encore vraie ?
- Est-elle utile maintenant, pour cette étape précise ?
- Est-elle nécessaire au format de sortie attendu ?
- Est-elle indispensable pour choisir le bon outil ou appeler la bonne API ?
- Est-elle utile au modèle, ou seulement rassurante pour nous humains ?
Il y a un réflexe très humain derrière ça. Les équipes gardent trop de contexte parce qu’elles ont peur que le modèle manque d’information. En réalité, trop d’information peut produire l’effet inverse. Le modèle voit du bruit, mélange les priorités, ressort une vieille contrainte, ou rate une instruction importante.
L’ingénierie du contexte doit aussi être monitorée. Je suivrais au minimum les coûts tokens, le taux d’erreur, la qualité des appels d’outils, la stabilité des sorties JSON, le taux d’hallucination et la dérive des réponses dans les conversations longues. JSON, c’est juste un format structuré que les workflows aiment bien lire, mais les modèles peuvent le casser si le contexte est mal contrôlé.
Ce n’est pas un chantier réservé aux grands labos IA. Une PME avec quelques automatisations peut déjà gagner beaucoup en supprimant le bruit, en résumant la mémoire et en chargeant les bons outils au bon moment. Avant de chercher un modèle plus puissant, je regarderais d’abord ce qu’on lui donne à lire.
Et si le vrai levier était ce que vous donnez au modèle ?
L’ingénierie du contexte change la manière de concevoir les agents IA. Je ne regarde plus seulement le prompt, je regarde tout ce qui arrive dans la fenêtre de contexte : instructions, mémoire, RAG, outils, schémas, historique. C’est là que beaucoup de problèmes de production apparaissent. Trop de données, trop de bruit, des consignes enfouies, et l’agent devient moins fiable. En traitant le contexte comme une ressource à filtrer, compresser et charger au bon moment, vous améliorez la qualité des réponses, vous réduisez les coûts tokens et vous construisez des workflows IA plus stables.
FAQ
- Qu’est-ce que l’ingénierie du contexte en IA ?
L’ingénierie du contexte consiste à gérer automatiquement les informations envoyées à un LLM à chaque appel. Ça inclut le system prompt, l’historique, la mémoire, les documents récupérés par RAG, les définitions d’outils et les formats de sortie attendus. - Quelle est la différence entre prompt engineering et context engineering ?
Le prompt engineering améliore la formulation des consignes. Le context engineering décide quoi mettre dans la fenêtre de contexte, quoi retirer, quoi résumer et quoi charger au bon moment. En production, les deux sont utiles, mais le contexte devient souvent le vrai sujet. - Pourquoi un agent IA devient moins fiable avec le temps ?
Souvent parce que son contexte se dégrade. L’historique grossit, les anciennes informations restent présentes, les documents RAG ajoutent du bruit et les consignes importantes finissent noyées. C’est ce qu’on appelle le context rot. - Le RAG suffit-il à améliorer les réponses d’un LLM ?
Pas toujours. Le RAG aide si les extraits sont propres, courts et pertinents. Injecter de gros blocs de texte, du JSON brut ou des métadonnées inutiles peut au contraire augmenter les hallucinations et rendre la réponse moins stable. - Comment réduire le bruit dans la fenêtre de contexte ?
Je commence par filtrer les informations inutiles, résumer la mémoire, charger les documents juste-à-temps et limiter les définitions d’outils aux outils vraiment utiles pour l’étape en cours. Le but n’est pas de tout donner au modèle, mais de lui donner ce qui sert maintenant.
A propos de l’auteur
Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les entreprises sur le tracking server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA dans les process business et le SEO/GEO. J’ai travaillé avec des équipes chez Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer des agents IA fiables, des workflows automatisés propres ou une architecture data exploitable, contactez-moi.
⭐ Analytics engineer, Data Analyst et 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 avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, 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.