Qu’est-ce que le context engineering ? Cette compétence qui sépare les démos IA des systèmes qui fonctionnent réellement devient plus simple à utiliser lorsqu’on la relie à une décision concrète, au lieu de la traiter comme un nouveau mot à la mode. Ce guide d’AI Tools Radar examine l’idée en pratique, les compromis qui comptent et les questions à poser avant d’adopter un outil ou un processus.
En juin 2025, Andrej Karpathy a publié une définition devenue depuis le cadre standard d’une discipline émergente : le context engineering est « l’art et la science délicats de remplir la fenêtre de contexte avec exactement la bonne information pour l’étape suivante ».
Cette formulation comptait parce qu’elle donnait un nom à une pratique que les spécialistes appliquaient sans étiquette. Toute application d’IA sérieuse, tout agent de production, tout flux de travail qui produit réellement des résultats cohérents implique des décisions délibérées sur les informations que le modèle voit lorsqu’il s’exécute. L’ensemble de ces décisions constitue le context engineering.
Le prompt engineering, à l’inverse, correspond à ce que la plupart des personnes imaginent lorsqu’elles pensent à « travailler avec l’IA ». Vous écrivez de meilleures instructions, formulez les choses clairement et ajoutez des exemples. Le prompt engineering est réel et utile. Mais il ne traite qu’une seule couche du problème, souvent la moins importante dans les systèmes de production.
Le context engineering est la discipline plus large. Il couvre non seulement ce que vous demandez au modèle, mais tout ce que le modèle sait lorsqu’il répond : les instructions sous lesquelles il opère, les outils qu’il peut appeler, l’historique de la conversation, les documents récupérés pour appuyer la tâche et la mémoire de qui vous êtes et de ce sur quoi vous travaillez. Réunir correctement ces éléments, dans la bonne combinaison et au bon moment, détermine le succès ou l’échec d’une application d’IA.
Context engineering ou prompt engineering : quelle différence réelle ?
La distinction n’est pas académique. Elle a des conséquences pratiques pour toute personne qui construit avec l’IA ou essaie de l’utiliser de façon fiable.
Le prompt engineering se concentre sur la requête. Comment formuler la question ? Quels exemples inclure ? Comment structurer l’instruction pour obtenir le format de sortie voulu ? Il suppose une configuration relativement statique : un modèle, un utilisateur, une demande.
Le context engineering se concentre sur l’environnement. Que sait le modèle avant que l’utilisateur ne tape quoi que ce soit ? Quelles informations sont récupérées et injectées ? Comment gère-t-on l’historique de conversation ? Quels outils sont disponibles ? Quelles contraintes sont intégrées au système ? Le context engineering considère la fenêtre de contexte du modèle comme une surface de conception active, et non comme une page blanche.
L’analyse de LangChain formule ainsi la différence : le prompt engineering consiste à poser la bonne question ; le context engineering consiste à créer l’environnement optimal pour que le modèle identifie et exécute la bonne solution, souvent sans que l’utilisateur ait même besoin de la demander.
Dans un usage informel de l’IA, le prompt engineering suffit généralement. Vous ouvrez ChatGPT, demandez quelque chose et affinez la formulation si la réponse ne convient pas. Très bien.
Dans les systèmes d’IA de production, le prompt engineering n’est que le minimum requis. L’application moyenne déployée en 2026 combine récupération, appels d’outils, gestion de l’historique conversationnel, état structuré, routage conditionnel et parfois coordination entre plusieurs modèles. Chacun de ces éléments est une décision de contexte. La qualité de ces décisions détermine celle de chaque sortie du système.
Une fenêtre de contexte ne se réduit pas au texte que vous saisissez. Dans toute application d’IA bien conçue, le contexte assemblé pour un appel de modèle donné contient généralement plusieurs couches distinctes :
Prompt système Ce sont les instructions persistantes qui définissent le rôle, les contraintes et le comportement du modèle. Qui est le modèle ? Que peut-il faire ? Que ne doit-il jamais faire ? Un prompt système bien conçu n’est pas un paragraphe de conseils vagues. C’est un ensemble de règles et de rôles soigneusement maintenu qui façonne chaque réponse.
Historique de conversation C’est la trace de ce qui a été dit jusqu’ici. La quantité d’historique à conserver, la façon de le compresser lorsqu’il devient long et le choix de résumer certains éléments plutôt que de les préserver textuellement sont des décisions d’ingénierie actives. Trop d’historique gaspille l’espace de contexte ; trop peu fait perdre le fil de tâches complexes en plusieurs étapes.
Documents récupérés Il s’agit d’informations extraites d’une source de connaissances externe et injectées dans le contexte au moment de l’inférence. C’est la génération augmentée par récupération (RAG), l’une des primitives les plus importantes du context engineering. La qualité de la récupération, la taille des fragments, le classement de pertinence et l’ordre du contenu récupéré influencent tous la qualité de la sortie.
Définitions d’outils Ce sont les interfaces qui permettent au modèle d’agir : appeler une API, exécuter du code, chercher sur le web ou écrire dans une base de données. La manière de décrire les outils, les paramètres qu’ils exposent et les outils disponibles dans un contexte donné sont des décisions de context engineering.
Mémoire Ce sont les informations persistantes sur l’utilisateur, le projet ou les interactions passées. La mémoire à court terme peut être constituée des derniers échanges. La mémoire à long terme peut inclure des préférences utilisateur, des décisions antérieures et des connaissances accumulées sur un travail en cours. L’analyse de Weaviate décrit la mémoire comme la couche qui permet aux systèmes IA de devenir réellement personnalisés avec le temps, au lieu de repartir de zéro à chaque session.
État et données structurées Pour les flux de travail d’agents couvrant plusieurs étapes, l’état actuel de la tâche, les sorties des étapes précédentes et toute donnée structurée dont le modèle a besoin pour raisonner font partie du contexte qui doit être géré avec soin.
L’art du context engineering consiste à assembler correctement ces couches pour chaque appel précis : choisir ce qu’il faut inclure, compresser, récupérer et laisser de côté afin que le modèle dispose exactement de ce dont il a besoin, sans rien qui dilue le signal.
Pourquoi le context engineering est devenu la compétence critique.
Trois évolutions ont rendu le context engineering plus important que le prompt engineering pour la plupart des travaux d’IA sérieux.
L’essor de l’IA agentique. Lorsqu’un modèle s’exécute une seule fois en réponse à une question unique, le prompt engineering compte le plus. Lorsqu’un modèle fonctionne en boucle, agit, reçoit des résultats et décide de la suite, le contexte évolue à chaque étape. La qualité de l’agent dépend presque entièrement du fait que le contexte de chaque étape contient les bonnes informations pour prendre la bonne décision. L’analyse de Deepset identifie cela comme le moteur central : à mesure que les systèmes IA deviennent plus autonomes, la conception du contexte devient le défi d’ingénierie dominant.
Des fenêtres de contexte plus longues, le même problème de rareté. Les modèles prennent désormais en charge des fenêtres de contexte d’un million de jetons. Cela semble résoudre le problème, mais ce n’est pas le cas. Une fenêtre d’un million de jetons remplie d’informations non pertinentes produit de moins bons résultats qu’une fenêtre de 100 000 jetons contenant exactement la bonne information. Plus de capacité n’élimine pas le besoin de sélection ; elle augmente l’enjeu. Un context engineering négligent à grande échelle produit plus de bruit, pas moins.
L’écart entre les démos et la production. Il est facile de créer une démo IA impressionnante : vous composez manuellement le contexte, sélectionnez des entrées favorables et l’exécutez une fois. Il est difficile de bâtir un système IA qui fonctionne de façon cohérente pour des milliers d’utilisateurs face à des milliers d’entrées et d’états différents. La différence remonte presque toujours au context engineering. La démo a fonctionné parce que quelqu’un a manuellement fait de bons choix de contexte. Le système de production échoue parce que ces choix n’ont jamais été systématisés.
Il existe une couche de context engineering que la plupart des outils et cadres ignorent presque entièrement : votre contexte personnel.
Prompts système, définitions d’outils et documents récupérés sont tous des problèmes d’ingénierie que les équipes peuvent résoudre au niveau de l’application. Mais une catégorie de contexte vous est propre : les recherches effectuées au cours des six derniers mois, les réunions avec vos clients, les décisions prises par votre équipe au dernier trimestre, les connaissances accumulées dans votre situation professionnelle particulière. Aucune application IA n’est livrée avec ce contexte. Elle ne peut pas l’être. Il est à vous.
C’est ce qui rend la plupart des outils IA frustrants pour un travail intellectuel sérieux. Le modèle est capable. L’infrastructure est solide. Mais chaque session part de zéro, et la distance entre « ce que le modèle sait du monde » et « ce que le modèle sait de votre travail » est l’écart qui limite chaque sortie que vous recevez.
Pour la plupart des personnes, le passage du prompt engineering au context engineering se déroule en trois étapes.
Étape 1 : conception délibérée du système. Cessez de traiter le prompt système comme une réflexion après coup. Définissez clairement ce qu’est le modèle, ce qu’il n’est pas, ce qu’il doit toujours faire et ce qu’il ne doit jamais faire. Traitez le prompt système comme du code : versionnez-le, testez les changements et entretenez-le.
Étape 3 : gestion de l’état pour les tâches en plusieurs étapes. Lorsqu’une tâche couvre plusieurs étapes ou plusieurs appels de modèle, suivez explicitement l’état. Qu’a-t-on décidé ? Qu’a-t-on produit ? Que doit-il encore se passer ? Transmettez cet état délibérément, au lieu d’espérer que le modèle le reconstruise à partir du seul historique de conversation.
Le principe sous-jacent aux trois étapes est identique : la qualité de sortie du modèle est fonction de la qualité de son contexte d’entrée. Concevoir ce contexte est le travail.
Le context engineering est-il réservé aux développeurs ? Non. Le terme vient de l’ingénierie logicielle, mais la pratique s’applique à toute personne qui utilise régulièrement des outils IA. Décider quelles informations inclure avant de poser une question à un assistant IA, constituer un dossier de documents pertinents à coller dans une session ou utiliser une base de connaissances pour accumuler des notes de travail sont toutes des formes de context engineering, même sans écrire une ligne de code.
Quelle différence entre RAG et context engineering ? Le RAG, ou génération augmentée par récupération, est une composante du context engineering : la partie qui récupère des documents pertinents et les injecte dans le contexte. Le context engineering est la discipline plus large qui couvre aussi la conception du prompt système, la gestion de la mémoire, la définition des outils, le traitement de l’historique conversationnel et le suivi de l’état dans les flux de travail en plusieurs étapes.
Une fenêtre de contexte plus grande rend-elle le context engineering moins important ? Non. Les fenêtres plus grandes offrent plus de capacité, mais ne réduisent pas l’importance de ce que vous y mettez. Un contexte dispersé d’un million de jetons produit de moins bons résultats qu’un contexte ciblé de 100 000 jetons. La discipline qui consiste à sélectionner, ordonner et compresser l’information devient plus importante, et non moins, à mesure que la capacité augmente.
Quelle relation entre context engineering et agents IA ? Le context engineering est fondamental dans la conception des agents. Un agent n’est fiable qu’à hauteur du contexte qu’il reçoit à chaque étape. La qualité du prompt système, les définitions d’outils, l’état récupéré et la gestion de la mémoire déterminent si un agent prend de bonnes décisions ou dérive, hallucine ou boucle. Les applications agentiques sont l’endroit où les conséquences d’un mauvais context engineering sont les plus visibles.
Le context engineering n’est pas une tendance. C’est la discipline qui permet aux applications IA de fonctionner au niveau de qualité dont les utilisateurs ont réellement besoin. Le passage de « poser de meilleures questions » à « concevoir de meilleurs environnements informationnels » est le passage de l’usage de l’IA à la construction avec elle, et de la tolérance de résultats incohérents à l’exigence de résultats fiables.
Le test pratique consiste à déterminer si cette approche améliore une partie répétable du travail sans masquer ses sources, ses coûts ou ses modes de défaillance. Commencez par une tâche représentative, conservez un contrôle humain là où les erreurs ont de l’importance, puis réévaluez le résultat à mesure que les modèles et les produits évoluent.
Nous croisons sources primaires, documentation produit et cas d’usage réels pour vous aider à déterminer si un outil convient à votre manière de travailler.