Qu'est-ce que l'ingénierie du contexte ? Donnez à l'IA les bonnes informations, pas plus de mots
L'ingénierie du contexte consiste à décider de ce que voit un modèle d'IA avant de répondre. Ce qu'elle recouvre, en quoi elle diffère du prompt engineering, pourquoi plus de contexte n'est pas mieux et comment l'appliquer dans vos discussions et vos agents.
Pendant deux ou trois ans, le conseil type était simple : écrivez un meilleur prompt. Puis sont arrivés des assistants qui lisent des fichiers, cherchent sur le web et lancent des outils sur des dizaines d'étapes, et un autre problème est apparu. Le modèle n'échouait pas parce que la consigne était mal formulée. Il échouait parce qu'il regardait les mauvaises informations, ou trop d'informations. L'ingénierie du contexte (en anglais, context engineering) est le nom qui s'est imposé pour y remédier. Ce guide explique ce qu'est l'ingénierie du contexte, en quoi elle diffère du prompt engineering, ce qui entre dans le contexte d'un modèle, pourquoi plus n'est pas mieux et comment l'appliquer, dans ChatGPT comme dans un agent.
Ce que recouvre vraiment l'ingénierie du contexte
Un modèle de langage n'a aucune mémoire d'une requête à l'autre et ne voit ni votre écran, ni vos fichiers, ni votre entreprise. Chaque fois qu'il répond, il travaille uniquement à partir du texte (et des images) qu'il reçoit dans cette requête : sa fenêtre de contexte. L'ingénierie du contexte consiste à décider de ce qui entre dans cette fenêtre — quoi inclure, quoi laisser de côté, sous quelle forme et dans quel ordre — pour que le modèle ait ce qu'il lui faut pour l'étape suivante, et presque rien d'autre.
Le terme a décollé en juin 2025, quand le PDG de Shopify, Tobi Lütke, a dit le préférer à « prompt engineering » et qu'Andrej Karpathy l'a approuvé, en le décrivant comme « the delicate art and science of filling the context window with just the right information for the next step » (traduction : « l'art délicat et la science de remplir la fenêtre de contexte avec exactement les bonnes informations pour l'étape suivante »). L'équipe d'ingénierie d'Anthropic l'a ensuite défini comme l'ensemble des stratégies pour sélectionner et maintenir le meilleur ensemble possible de tokens pendant que le modèle travaille. Mots différents, même idée : le prompt que vous tapez n'est qu'une partie de ce que lit le modèle, souvent la plus petite.
Une image utile : le modèle est un prestataire très compétent qui arrive chaque matin totalement amnésique. Ce qui est sur le bureau quand il s'assoit, c'est tout ce qu'il sait du travail. L'ingénierie du contexte, c'est préparer ce bureau.
Ingénierie du contexte et prompt engineering
Ils ne sont pas rivaux. Le prompt engineering porte sur la façon de formuler une consigne : le rôle, la tâche, les contraintes et le format. Nos fondamentaux du prompt engineering couvrent ce savoir-faire. L'ingénierie du contexte se situe un cran au-dessus et traite tout ce qui entoure la consigne.
- La portée : le prompt engineering façonne un message. L'ingénierie du contexte façonne tout ce que reçoit le modèle : prompt système, historique de la conversation, documents, exemples et résultats des outils.
- Le moment : un prompt s'écrit généralement une fois. Le contexte est souvent dynamique : il change à chaque tour d'une conversation et à chaque étape d'un agent.
- L'échec qu'elle corrige : le prompt engineering corrige « il n'a pas compris ce que je demandais ». L'ingénierie du contexte corrige « il a compris, mais il n'avait pas les faits » et « il avait tellement de matière qu'il s'est dispersé ».
Un prompt superbement rédigé avec le mauvais contexte produit quand même une réponse fausse et sûre d'elle. Un prompt tout simple avec exactement le bon contexte fonctionne souvent du premier coup. Le terme a donc pris chez ceux qui construisent des produits d'IA, mais il concerne tout autant quiconque utilise un assistant conversationnel pour travailler.
Ce qui entre dans le contexte d'un modèle
Dans une fenêtre de discussion comme dans une application, le contexte est assemblé à partir des mêmes ingrédients :
- Les instructions : le prompt système ou les instructions personnalisées qui fixent le rôle, les règles et le ton. Notre guide des prompts système explique comment les rédiger.
- La tâche : votre demande actuelle, idéalement avec l'objectif et le public, pas seulement l'action.
- Les exemples : quelques échantillons de bons résultats. Deux ou trois exemples bien choisis valent souvent mieux qu'une page de règles, et notre article sur le prompting few-shot explique pourquoi.
- Les connaissances : les documents, données ou résultats de recherche dont la réponse doit découler, collés par vous ou récupérés automatiquement (on parle souvent de RAG, retrieval-augmented generation).
- L'historique et la mémoire : les échanges précédents et tout ce que l'outil a enregistré sur vous ou le projet.
- Les outils et leurs résultats : la description de ce que le modèle a le droit de faire (chercher, exécuter du code, lire un fichier) et ce qui revient à chaque utilisation.
- Le format de sortie : la structure attendue en retour, par exemple un tableau, du JSON ou une limite de mots.
Chaque élément prend de la place, et tous se disputent l'attention du modèle. L'ingénierie du contexte consiste surtout à les équilibrer : assez de chacun pour accomplir la tâche, et rien qui tire dans une autre direction.
Pourquoi plus de contexte n'est pas mieux
Les fenêtres de contexte atteignent désormais des centaines de milliers de tokens, et certains modèles en acceptent un million ou plus. On est tenté de tout coller et de laisser le modèle faire le tri. En pratique, cela se retourne souvent contre vous, pour quatre raisons :
- L'attention se dilue : l'étude bien connue « Lost in the Middle » a montré que les modèles exploitent bien mieux les informations du début et de la fin d'un long texte que celles enfouies au milieu. Anthropic décrit un effet voisin sous le nom de context rot (dégradation du contexte) : plus le contexte grossit, moins le modèle sait en retrouver et en utiliser chaque élément.
- La distraction : un contenu hors sujet n'est pas neutre. Un document à moitié pertinent invite à reprendre une phrase qui n'a rien à faire dans la réponse.
- Les contradictions : deux versions d'une politique interne, une ancienne consigne et une nouvelle, une note qui contredit les données. Le modèle peut suivre l'une ou l'autre, ou les mélanger, sans toujours vous dire qu'il a dû choisir.
- Le coût et la vitesse : chaque token est traité à chaque appel, et un contexte surchargé rend les applications plus lentes et plus coûteuses.
Quand un modèle compétent répond mal, la cause est généralement l'un de quatre problèmes de contexte : quelque chose manquait, quelque chose était périmé, deux éléments se contredisaient, ou la partie utile était noyée dans le bruit. Demandez-vous lequel avant de reformuler le prompt pour la cinquième fois. Le contexte manquant est aussi une grande cause des hallucinations de l'IA : faute de faits, le modèle comble le vide avec du plausible.
L'ingénierie du contexte dans vos discussions au quotidien
Nul besoin de construire quoi que ce soit pour en profiter. Si vous utilisez ChatGPT, Claude ou Gemini pour travailler, vous faites déjà de l'ingénierie du contexte chaque fois que vous choisissez quoi coller, bien ou mal. Quelques réflexes font une vraie différence :
- Commencez par un brief : avant la demande, donnez ce qu'il faudrait à un nouveau collègue : pour qui c'est, ce qui est déjà décidé et à quoi ressemble un bon résultat.
- Collez la source, pas votre résumé : si la réponse doit être fidèle à un document, incluez-en la partie pertinente.
- Faites le tri avant de coller : les trois paragraphes utiles d'un contrat valent mieux que le PDF complet de 40 pages.
- Entretenez ce qui persiste : instructions personnalisées, projets avec fichiers importés et mémoires enregistrées sont du contexte qui se charge automatiquement. Gardez-les courts et à jour : une mémoire périmée sur un poste que vous avez quitté l'an dernier reste du contexte.
- Repartez de zéro quand une discussion dérive : une longue discussion accumule idées abandonnées et erreurs corrigées. Quand les réponses mélangent d'anciens éléments, ouvrez une nouvelle discussion avec un résumé propre.
Un brief réutilisable ressemble à ceci :
Quand la réponse doit venir d'un ensemble précis de documents, un outil construit autour de vos propres sources fait une bonne partie de ce travail pour vous. Notre guide pour utiliser NotebookLM montre comment cela fonctionne en pratique.
L'ingénierie du contexte pour les agents et les applications d'IA
L'ingénierie du contexte compte surtout quand un modèle enchaîne de nombreuses étapes. Un agent IA qui cherche, lit des fichiers et appelle des outils génère du nouveau contexte à chaque action. Sans gestion, sa fenêtre se remplit de résultats d'outils périmés et il finit par perdre le fil. Les techniques employées pour l'éviter sont étonnamment terre à terre :
- Récupérer au bon moment : au lieu de tout charger d'emblée, gardez des références légères (chemins de fichiers, liens, requêtes enregistrées) et laissez l'agent chercher ce qu'il lui faut au moment voulu.
- Compacter : quand une longue session approche de la limite, résumez l'essentiel (décisions, problèmes en suspens, faits clés) et repartez de ce résumé. Effacer les anciens résultats d'outils en est la forme la plus simple.
- Prendre des notes hors de la fenêtre : l'agent tient un fichier d'avancement ou une liste de tâches qu'il peut relire, pour que l'essentiel survive même quand la conversation est raccourcie.
- Découper le travail : des sous-agents traitent une tâche ciblée dans un contexte propre et renvoient un court résumé, et l'agent principal n'a pas à porter chaque détail de chaque recherche.
- Garder des outils peu nombreux et clairs : des outils redondants ou mal décrits obligent le modèle à deviner lequel utiliser. Chaque description d'outil est aussi du contexte.
- Placer le prompt système à la bonne altitude : l'expression d'Anthropic pour le juste milieu entre des règles rigides du type « si ceci, alors cela » et des encouragements vagues : précis sur les objectifs et les limites, souple sur la méthode.
Vous pouvez essayer la compaction à la main dans n'importe quelle longue discussion avant d'en ouvrir une nouvelle :
Une check-list du contexte à réutiliser
Avant une demande importante, ou quand un assistant se trompe toujours sur le même point, parcourez cette liste :
- Objectif : le contexte dit-il à quoi sert le résultat, et pas seulement quoi faire ?
- Sources : chaque fait dont dépend la réponse est-il réellement sous les yeux du modèle ?
- Fraîcheur : y a-t-il quelque chose de périmé : un ancien brief, une version remplacée, une mémoire qui ne s'applique plus ?
- Contradictions : deux éléments se contredisent-ils ? Supprimez-en un, ou indiquez lequel l'emporte.
- Bruit : que pourriez-vous supprimer sans rien perdre d'utile à la tâche ?
- Titres : les documents et extraits sont-ils clairement nommés et séparés, pour que le modèle (et vous) puissiez les distinguer ?
- Ordre : la consigne clé est-elle au début ou à la fin, plutôt qu'enfouie au milieu d'un long collage ?
- Format : avez-vous montré ou décrit le résultat que vous attendez ?
Vous pouvez aussi demander au modèle d'auditer son contexte avant de répondre :
Ce que l'ingénierie du contexte ne peut pas régler
L'ingénierie du contexte est utile, mais ce n'est pas de la magie, et une partie de l'engouement qui l'entoure promet plus qu'elle ne tient. Les limites à connaître :
- Elle n'ajoute pas de capacités au modèle : un contexte parfait ne fera pas raisonner un petit modèle comme un grand, ni rendre un modèle fiable sur une tâche qu'il gère mal.
- Elle ne garantit pas la fidélité : même avec les bons documents, un modèle peut mal lire, exagérer ou mélanger les sources. Vérifiez les affirmations qui comptent.
- Vos sources fixent le plafond : si les documents sont faux, biaisés ou datés, les réponses le seront aussi, avec exactement la même assurance.
- La recherche peut ramener le mauvais passage : la recherche automatique dans vos documents renvoie parfois un passage presque juste, et le modèle raisonne alors soigneusement sur le mauvais extrait.
- Le contenu non fiable est un risque : les pages web, e-mails et fichiers que vous donnez à une IA peuvent contenir des instructions cachées, ce qu'on appelle l'injection de prompt (prompt injection). Traitez tout ce que lit le modèle comme des données, pas comme des ordres, et faites valider par un humain toute action irréversible.
- C'est un travail continu : le contexte se périme. Instructions, mémoires et fichiers de référence s'entretiennent comme toute documentation.
L'idée est simple : un modèle ne travaille qu'avec ce qu'il voit, alors choisissez délibérément ce qu'il voit. Donnez-lui l'objectif, les faits et un exemple de bon résultat, écartez le superflu et vérifiez. Cette habitude améliore les réponses plus sûrement que toute formulation astucieuse.
