Au-delà du prompt : maîtriser le Context Engineering en 2026
Le prompt engineering est devenu un simple sous-ensemble d'une discipline plus large. Ce guide vous explique laquelle, et comment l'appliquer dès cette semaine.
TLDR;
Le prompt engineering seul ne suffit plus pour construire des agents IA fiables en production. Le vrai levier, c’est le context engineering : l’art de concevoir tout l’environnement informationnel autour du modèle.
Les modèles de langage souffrent de “context rot” : plus le contexte grossit, plus l’attention du modèle se dégrade. Le contexte est une ressource limitée, pas un espace de stockage illimité.
Anthropic a formalisé 6 principes de prompting qui restent la base de tout bon context engineering : donner du contexte, montrer des exemples, spécifier les contraintes, décomposer en étapes, faire réfléchir le modèle, définir son rôle.
L’approche “Just-in-Time” change la donne : les agents modernes ne chargent plus tout dans la fenêtre de contexte. Ils vont chercher l’information au moment où ils en ont besoin, comme un développeur qui navigue dans un système de fichiers.
Pour les tâches longues, trois techniques permettent de contourner les limites : la compaction (résumer pour repartir), la prise de notes structurée (mémoire externe), et les architectures multi-agents (diviser pour mieux régner).
Il y a un an, quoique c’est encore un peu le cas aujourd’hui, on parlait du “prompt engineering” comme la compétence du siècle. LinkedIn regorgeait de templates magiques, des formations à 500 euros vous promettaient de “hacker” ChatGPT avec la bonne phrase. Et puis la réalité a rattrapé tout le monde.
Parce que dès qu’on sort du cas simple (une question, une réponse), les prompts montrent leurs limites. Changez un mot et le système se comporte différemment. Essayez de construire un agent qui tourne en boucle pendant des heures sur une tâche complexe avec juste un bon prompt et vous allez comprendre le problème.
Le prompt engineering a un successeur. Et il porte un nom : le context engineering.
C’est le sujet dont parlent Anthropic, Gartner (entreprise de recherche et de conseil qui accompagne les dirigeants de l'informatique et des affaires) et la plupart des équipes qui construisent des agents IA en production aujourd’hui. Et pour une fois, ce n’est pas un buzzword de plus, mais un vrai changement de paradigme dans la façon de travailler avec les modèles de langage. Si vous développez des applications qui utilisent l’IA (ou si vous comptez le faire), vous avez besoin de comprendre ce qui se joue ici.
Voyons cela ensemble.
Ce qui a changé et pourquoi vos prompts ne suffisent plus
Revenons aux bases : un prompt, c’est une instruction que vous écrivez pour dire au modèle ce que vous attendez de lui. Le prompt engineering, c’est l’art de formuler cette instruction pour obtenir le meilleur résultat possible.
Et pendant longtemps, c’était suffisant. Vous aviez une tâche simple (résumer un texte, générer du code) et un prompt bien écrit faisait le travail.
Mais le monde de l’IA a bougé. On ne se contente plus de poser des questions à un chatbot. On construit des agents qui utilisent des outils, qui naviguent dans des systèmes de fichiers, qui écrivent du code, qui prennent des décisions sur plusieurs tours d’inférence. Et là, le prompt seul n’est plus suffisant.
Pourquoi ? Parce que le prompt engineering repose sur trois hypothèses qui ne tiennent pas à l’échelle :
Toute l’information pertinente tient dans un seul prompt
Chaque interaction est indépendante des précédentes
L’utilisateur fournit manuellement le bon contexte à chaque fois
Vous voyez le problème ? Dans un agent qui tourne en boucle pendant des heures, aucune de ces trois hypothèses ne se vérifie.
C’est là que le context engineering entre en scène.
Mais alors, qu’est-ce que le context engineering ?
Anthropic le définit comme la suite naturelle du prompt engineering. Si ce dernier se demande “comment formuler ma requête ?”, le context engineering se pose une question plus large : “quelle configuration de contexte va maximiser les chances d’obtenir le comportement souhaité de mon modèle ?”
Le contexte, c’est l’ensemble des tokens que le modèle voit au moment où il génère une réponse. Pas juste votre prompt, mais tout : les instructions système, les définitions d’outils, l’historique de conversation, les résultats de recherche, les données externes, la mémoire...
Et le engineering, c’est l’optimisation de ces tokens face aux contraintes des modèles de langage.
Gartner a d’ailleurs formalisé cette distinction : le context engineering, c’est la discipline qui consiste à concevoir et structurer les données, les workflows et l’environnement pour que les systèmes IA puissent comprendre l’intention, prendre de meilleures décisions et produire des résultats alignés avec les objectifs de l’entreprise ou du développeur.
Vous développez avec des LLM au quotidien ? Alors vous faites probablement déjà du context engineering sans le savoir. Chaque fois que vous branchez un outil via MCP, que vous injectez des résultats de recherche dans un prompt, que vous gérez un historique de conversation, vous construisez du contexte.
La différence, c’est qu’en 2026, on ne fait plus cela au hasard.
Pourquoi le contexte est une ressource limitée et précieuse
Voici un point que beaucoup de développeurs sous-estiment. On pourrait penser :
“Les fenêtres de contexte sont de plus en plus grandes, 200K tokens ici, 1M tokens là. Alors où est le problème ? Je balance tout dedans et le modèle se débrouille.”
Sauf que ça ne fonctionne pas comme ça.
Il existe un phénomène dont vous avez peut-être déjà entendu parler, appelé context rot : à mesure que le nombre de tokens dans la fenêtre de contexte augmente, la capacité du modèle à retrouver et utiliser correctement l’information diminue. Ce n’est pas un bug d’un modèle en particulier. C’est un trait qui apparaît sur tous les modèles. C’est comme si on vous gavait d’informations pendant 1h, vous ne retiendriez pas tout : c’est pareil pour les IA.
Les données montrent que les performances se dégradent nettement au-delà d’environ 1 million de tokens, quelle que soit la taille théorique de la fenêtre de contexte. Plus de tokens ne veut pas dire de meilleures réponses.
D’où vient ce phénomène ? De l’architecture elle-même. Chaque token doit “faire attention” à tous les autres tokens du contexte. Cela crée n² relations pour n tokens. L’attention du modèle est un budget limité : chaque token ajouté consomme une partie de ce budget.
Pensez-y comme à votre propre mémoire de travail. Vous pouvez garder 4 à 7 éléments en tête simultanément. Comme je vous le disais plus haut, si quelqu’un vous donne 50 instructions à la fois, vous allez en oublier la moitié. Les LLM fonctionnent de manière comparable.
Un bon context engineering, c’est trouver le plus petit ensemble de tokens à fort signal qui maximise la probabilité d’obtenir le résultat souhaité. Pas le plus gros ensemble, mais le plus pertinent.
Les 6 principes du prompting qui restent la base
Avant d’aller plus loin dans le context engineering, je tiens à préciser quelque chose : le prompt engineering n’est pas mort. Il est devenu un sous-ensemble du context engineering. Et ses bonnes pratiques restent la base de toute architecture de contexte efficace.
Anthropic a formalisé 6 principes que je vous résume ici avec des exemples concrets.
1. Donnez du contexte
Un prompt vague donne une réponse vague. “Parle-moi du changement climatique” est un prompt médiocre. “Explique 3 impacts du changement climatique sur l’agriculture tropicale avec des exemples de la dernière décennie. Je prépare un entretien dans un labo de recherche agricole en Indonésie” est un prompt qui fonctionnera mieux.
Le truc que beaucoup de développeurs oublient : dites aussi au modèle qui vous êtes et pourquoi vous posez la question. Vous le feriez naturellement avec un humain, faites-le avec votre IA.
2. Montrez des exemples
Parfois, montrer vaut mieux qu’expliquer. Si vous avez un format très précis en tête, donnez 2-3 exemples au modèle plutôt que de décrire le format en 15 lignes. C’est ce qu’on appelle le few-shot prompting. Pour un LLM, les exemples sont les images qui valent mille mots.
3. Spécifiez les contraintes de sortie
Format, longueur, langue, style, structure. Plus vous êtes précis sur ce que vous attendez, moins le modèle doit deviner.
4. Décomposez en étapes
Au lieu de dire “analyse ces données de vente”, dites : “identifie les produits les plus performants, compare avec le trimestre précédent, repère les tendances inhabituelles, puis propose des explications”. C’est le chain-of-thought prompting, et ça fonctionne parce que ça réduit l’ambiguïté sur le processus attendu.
5. Faites réfléchir le modèle d’abord
Demandez au modèle de réfléchir avant de répondre, pas après. Comme pour un humain, la réflexion en amont améliore la qualité de l’action. Les modèles récents comme Claude le font par défaut avec l’extended thinking, mais vous pouvez toujours guider ce processus.
6. Définissez le rôle et le ton
“Explique la formation des arcs-en-ciel du point de vue d’un professeur de sciences qui parle à un enfant de 10 ans curieux” donne un résultat radicalement différent de “explique la formation des arcs-en-ciel”. Le rôle influence à la fois le niveau de détail et le style de la réponse.
Ces 6 principes sont la couche de base. Le context engineering, c’est tout ce qui vient au-dessus.
L’anatomie d’un contexte efficace
Et là vous devez vous dire “D’accord, mais concrètement, quels sont les composants d’un bon contexte ?”.
Le system prompt : trouver la bonne altitude
Anthropic parle de “bonne altitude” pour décrire le niveau de détail idéal d’un prompt système. C’est une zone entre deux extrêmes : d’un côté, des instructions trop rigides qui codent en dur chaque comportement. De l’autre, des instructions trop vagues qui laissent le modèle deviner.
La bonne altitude, c’est assez précis pour guider le comportement, assez souple pour que le modèle puisse s’adapter.
L’entreprise américaine recommande d’organiser les prompts en sections distinctes avec des balises XML (<instructions>, <context>, <example>) ou des headers Markdown pour séparer les blocs. Même si le formatage exact devient moins critique à mesure que les modèles progressent.
Les outils : moins c’est mieux
Les outils (fonctions, API, MCP) sont ce qui permet à un agent d’interagir avec son environnement et de récupérer de nouvelles informations. Anthropic insiste sur un point : un des modes de défaillance les plus fréquents, c’est un jeu d’outils trop large avec trop de chevauchements.
La règle est simple : si un ingénieur humain ne peut pas dire de façon certaine quel outil utiliser dans une situation donnée, l’agent ne fera pas mieux.
Les exemples : qualité plutôt que quantité
Beaucoup d’équipes entassent des dizaines de cas limites dans leur prompt pour couvrir toutes les situations. Cette approche est déconseillée. Mieux vaut un petit nombre d’exemples diversifiés et représentatifs qui montrent clairement le comportement attendu.
L’approche “Just-in-Time” : charger le contexte au bon moment
C’est probablement le concept le plus important que vous devez retenir aujourd’hui et celui qui change le plus la façon de construire des agents.
Traditionnellement, on faisait du RAG classique : avant même que le modèle ne commence à travailler, on allait chercher des documents pertinents dans une base et on les injectait dans le contexte. C’est de la récupération “pré-inférence”.
L’approche Just-in-Time fait l’inverse : au lieu de tout charger d’avance, l’agent garde des références légères (chemins de fichiers, URLs, requêtes stockées) et va chercher les données dynamiquement au moment où il en a besoin.
Claude Code, pour ne citer que lui, fonctionne exactement comme ça. Le modèle écrit des requêtes ciblées, stocke les résultats, et utilise des commandes comme head et tail pour analyser de gros volumes de données sans jamais charger l’intégralité dans le contexte.
Vous trouvez cela familier ? C’est normal, c’est exactement ce que vous faites en tant que développeur. Vous ne mémorisez pas tout le code source d’un projet. Vous naviguez dans l’arborescence, vous ouvrez les fichiers dont vous avez besoin, vous utilisez grep (ou cmd + shift + F :D) pour trouver ce que vous cherchez.
L’avantage de cette approche, c’est ce qu’on appelle la progressive disclosure : l’agent découvre le contexte couche par couche. Chaque interaction lui donne des indices pour la suivante. La taille d’un fichier suggère sa complexité, les conventions de naming indiquent son objectif…
Le compromis ? C’est plus lent que de récupérer des données pré-calculées et ça demande un vrai travail d’ingénierie pour que l’agent navigue efficacement dans son paysage d’information.
La solution la plus efficace en pratique serait un modèle hybride. Certaines données critiques sont chargées d’entrée (comme les fichiers CLAUDE.md à la racine de votre projet), tandis que l’agent va chercher le reste à la demande (vos skills, etc.).
Quand le contexte dépasse la fenêtre : 3 techniques pour les tâches longues
Voici le dernier morceau du puzzle. Que faire quand une tâche dure des heures et que l’agent accumule plus d’information que sa fenêtre de contexte ne peut en contenir ?
La compaction
La compaction consiste à résumer le contenu d’une conversation qui approche de la limite de la fenêtre de contexte, puis à relancer avec ce résumé. Le modèle conserve alors les décisions architecturales, les bugs non résolus et les détails techniques, tout en éliminant les sorties d’outils redondantes.
Je ne suis pas trop fan de cette technique, qui perd tout de même des informations importantes au fur et à mesure de la discussion. Elle est également controversée au sein de la communauté des développeurs.
La prise de notes structurée
L’agent écrit régulièrement des notes dans un fichier persistant en dehors de la fenêtre de contexte. Ces notes sont réinjectées quand c’est nécessaire. Comme lorsque votre agent de code maintient un fichier to-do ou quand il écrit dans un NOTES.md.
Les architectures multi-agents
Au lieu d’un seul agent qui essaie de tout garder en tête, des sous-agents spécialisés gèrent des tâches ciblées avec des fenêtres de contexte propres. L’agent principal coordonne avec un plan de haut niveau. Chaque sous-agent peut explorer en profondeur (en utilisant des dizaines de milliers de tokens) mais ne renvoie qu’un résumé condensé de 1 000 à 2 000 tokens.
C’est la séparation des responsabilités appliquée à l’IA. C’est une technique que j’utilise souvent et que j’apprécie pour son efficacité.
Et maintenant, on fait quoi ?
Cette semaine, prenez un de vos projets qui utilise un LLM. Regardez ce qui entre dans la fenêtre de contexte. Tout est-il vraiment nécessaire (notamment tous vos MCP) ? Y a-t-il des informations que vous pourriez charger à la demande plutôt que d’emblée ? Avez-vous structuré vos instructions avec des balises XML ou des sections claires ?
Si cette édition vous a donné des idées, transférez-la à un collègue qui construit avec l’IA. Et si vous n’êtes pas encore abonné, c’est le moment.
Philippe