Le context engineering (ingénierie du contexte) consiste à décider de tout ce qu'un modèle de langage voit quand il répond : pas seulement la question que vous tapez, mais les consignes qui l'entourent, les documents et résultats d'outils insérés, la mémoire enregistrée sur l'utilisateur et la conversation jusque-là. Tout cela partage une seule fenêtre de contexte, et le modèle répond à partir de ce texte et de rien d'autre. Le terme s'est répandu en 2025, quand de plus en plus de produits d'IA sont devenus des agents qui assemblent automatiquement l'essentiel de leur contexte.
Le prompt engineering porte surtout sur la façon de formuler une demande. Le context engineering porte sur ce que le modèle doit avoir sous les yeux à chaque appel, et dans quel ordre.
Du prompt au contexte
Dans une application de chat, vous écrivez vous-même l'essentiel du contexte : l'application ajoute un prompt système et l'historique, vous ajoutez le reste. Dans une application métier, l'équilibre s'inverse. Un utilisateur tape une phrase, et le code autour du modèle ajoute des consignes, un profil utilisateur, trois articles d'aide trouvés par recherche, la liste des outils disponibles et la sortie du dernier appel d'outil. La phrase de l'utilisateur peut ne représenter qu'une petite fraction de ce que lit le modèle.
Quand un tel système répond mal, la solution se trouve rarement dans la formulation. La cause habituelle est que le modèle avait le mauvais contenu : un fait manquant, un résultat d'outil périmé, un document hors sujet qui semblait pertinent pour la recherche.
Ce qui entre dans la fenêtre de contexte
Un appel typique dans une application d'IA contient tout ou partie de ces éléments, à peu près dans cet ordre :
- Les consignes système : le rôle, les règles et le format de sortie, en général fixes pour toute l'application. Voir prompts système.
- Les définitions d'outils : noms, descriptions et paramètres des outils que le modèle peut appeler.
- Les exemples : quelques entrées et sorties types qui montrent le comportement attendu.
- La mémoire : des faits enregistrés lors de sessions précédentes, comme la formule de l'utilisateur, sa langue ou ses préférences.
- Les documents récupérés : des passages trouvés en cherchant dans une base de connaissances pour cette question (génération augmentée par récupération, ou RAG).
- L'historique de conversation : les tours précédents, mot pour mot ou résumés.
- Les résultats d'outils : la sortie des recherches, exécutions de code ou appels d'API faits pendant cette tâche, comme dans une boucle ReAct.
- Le message actuel : ce que l'utilisateur vient de demander.
Le bloc ci-dessous est un contexte assemblé pour un assistant support. Désactivez les parties une par une. Sans la partie contexte, le modèle ne peut pas connaître la formule du client ; sans la partie entrée, il n'a aucun fait sur le produit, et ses contraintes lui disent de le signaler plutôt que de deviner.
Bonjour Dana, le mode hors ligne fait partie de la formule Pro, et votre compte est actuellement en formule Free : il n'est donc pas disponible pour vous pour le moment. Avec Pro, les notes que vous créez pendant le vol se synchronisent automatiquement quand votre téléphone se reconnecte. Une limite à connaître : les pièces jointes de plus de 20 Mo ne sont pas disponibles hors ligne.
Remarquez que la bonne réponse dépend de la réunion de deux sources : la mémoire (formule Free) et un document (le mode hors ligne est réservé à Pro). Aucune ne suffit seule, ce qui est typique. Une grande partie du context engineering consiste à s'assurer que les éléments qui ont besoin les uns des autres arrivent ensemble.
Quatre façons dont un contexte déraille
- Une information manquante. Le modèle comble les trous par des suppositions plausibles, et c'est de là que viennent beaucoup d'hallucinations. Ajoutez le fait, ou dites au modèle quoi faire quand un fait manque.
- Trop de contenu. Chaque paragraphe hors sujet coûte des tokens et dispute l'attention. Liu et al. 2023, "Lost in the Middle: How Language Models Use Long Contexts", ont constaté que les modèles testés exploitaient plus fiablement les informations placées au début ou à la fin d'une longue entrée que celles du milieu. Les modèles récents gèrent mieux les longues entrées, mais envoyer les quelques passages qui répondent à la question reste moins cher, et plus facile à exploiter pour le modèle, que coller tout le manuel.
- Une information périmée. Un résultat d'outil d'il y a dix étapes peut décrire un fichier ou un solde qui a changé depuis. Si le modèle voit les deux versions, il peut utiliser l'ancienne.
- Les conflits. Deux documents se contredisent, ou la mémoire dit une chose et l'utilisateur une autre. Dites au modèle quelle source l'emporte, par exemple "le dernier message de l'utilisateur prime sur la mémoire enregistrée".
Ordonner le contexte
L'ordre change à la fois les résultats et le coût.
- Les parties stables d'abord. Les consignes système, les définitions d'outils et les documents de référence fixes changent rarement d'un appel à l'autre. Plusieurs fournisseurs d'API proposent la mise en cache du prompt (prompt caching), qui réutilise le traitement d'un début d'entrée identique : un préfixe inchangé rend donc les appels répétés moins chers et plus rapides.
- Le long contenu avant la question. Pour un long document ou un grand ensemble de passages, placez le contenu d'abord et la question et les consignes finales après. Le guide de prompting d'Anthropic, par exemple, recommande cet ordre pour les longues entrées, avec la question juste avant que le modèle commence à écrire.
- Étiquetez chaque élément. Entourez chaque source de balises comme
<document>,<memory>ou<tool_result>, avec un nom de source. Les étiquettes permettent au modèle de distinguer les données des consignes et vous permettent de lui demander d'où vient une réponse. Délimiteurs et balises XML présente les formats.
Alléger un long contexte
Chaque tour d'une conversation renvoie tout l'historique, donc les longues sessions grossissent jusqu'à ce qu'il faille sacrifier quelque chose. Selon l'application, elle peut résumer ou supprimer les messages anciens, ou vous demander d'ouvrir une nouvelle conversation. Vous obtenez de meilleurs résultats en allégeant délibérément.
- Gardez les derniers tours mot pour mot et remplacez les plus anciens par un résumé.
- Une fois qu'un résultat d'outil a servi, remplacez-le par une note d'une ligne sur ce qu'il a montré.
- Gardez les identifiants exacts dans chaque résumé : noms de fichiers, noms de fonctions, identifiants, messages d'erreur et nombres. Un résumé qui dit "le fichier de configuration" là où l'historique disait
settings.prod.yamlperd justement le détail qui comptait. - Dans une application de chat, quand la conversation dérive, ouvrez-en une nouvelle avec une note de passation. Le prompt ci-dessous en rédige une.
Objectif : remplacer les vérifications écrites à la main du formulaire d'inscription par un seul schéma de validation partagé entre le navigateur et le serveur.
Décisions
- Un seul fichier de schéma,
signupSchema.ts, importé parSignupForm.tsxetapi/signup.ts, pour que les deux jeux de règles ne puissent pas diverger. - Les messages d'erreur restent mot pour mot, car le centre d'aide les cite.
État actuel
- La validation côté navigateur utilise le schéma et
SignupForm.test.tsxpasse. - Le serveur appelle encore l'ancien
validateSignup()dansapi/signup.ts.
Détails exacts : les mots de passe doivent faire au moins 8 caractères et contenir un chiffre. Texte de l'erreur e-mail : "Veuillez saisir une adresse e-mail valide."
Prochaine étape : remplacer validateSignup() par le schéma et lancer les tests de l'API.
Question ouverte : un e-mail déjà inscrit doit-il renvoyer 409 ou 400 ?
La mémoire d'une session à l'autre
La mémoire est un contexte qui survit à une conversation : des faits écrits dans un stockage à la fin d'une session et chargés dans la suivante. Les applications de chat en proposent des versions, comme les souvenirs enregistrés ou les instructions de projet ajoutées à chaque conversation d'un projet. Dans votre propre application, la mémoire est une table ou un fichier de notes que votre code lit et insère. Deux règles la gardent utile : stockez des faits qui restent vrais (formule, langue, stack préférée), pas des transcriptions ; et ne chargez que ce qui concerne la tâche en cours, car la mémoire occupe le même espace que tout le reste.
Assembler le contexte dans le code
Dans une application, le context engineering est du code ordinaire. Ce croquis avec le SDK Python d'Anthropic place les règles fixes et la mémoire dans le prompt système, ne garde que l'historique récent et met les documents étiquetés avant la question.
import anthropic
client = anthropic.Anthropic()
MODEL = "your-model-id" # e.g. from your provider's model list
def build_context(question, docs, history, memory, max_messages=6):
documents = "\n".join(
f'<document source="{d["source"]}">\n{d["text"]}\n</document>' for d in docs
)
system = (
"You are the support assistant for Acme Notes. Answer only from the documents. "
"If they do not cover the question, say so.\n"
f"<memory>\n{memory}\n</memory>"
)
# history holds complete user/assistant pairs, so an even slice starts with a user turn
recent = history[-max_messages:]
user = f"<documents>\n{documents}\n</documents>\n\n{question}"
return system, recent + [{"role": "user", "content": user}]
# question, docs, history and memory come from your application
system, messages = build_context(question, docs, history, memory)
response = client.messages.create(model=MODEL, max_tokens=1024, system=system, messages=messages)
print(response.content[0].text)
Chaque décision dans cette fonction (quels documents, combien de messages, où placer la mémoire) est un choix de context engineering, et chacune mérite d'être testée sur de vraies questions, comme vous testeriez un changement de formulation.
Questions fréquentes
Qu'est-ce que le context engineering ?
Le context engineering (ingénierie du contexte) consiste à choisir, ordonner et alléger tout ce qu'un modèle de langage reçoit à chaque appel : les consignes système, les exemples, les documents récupérés, les définitions et résultats d'outils, la mémoire enregistrée, l'historique de conversation et le message de l'utilisateur. Le modèle ne répond qu'à partir de ce texte, donc ce qui s'y trouve, et ce qui en est absent, détermine la qualité de la réponse.
Quelle est la différence entre context engineering et prompt engineering ?
Le prompt engineering porte surtout sur la formulation des consignes. Le context engineering couvre toute l'entrée, dont une grande partie est assemblée par du code plutôt que tapée par une personne : quels documents récupérer, quels résultats d'outils garder, combien d'historique inclure et dans quel ordre. Dans un chat, vous écrivez vous-même l'essentiel du contexte ; dans une application ou un agent, l'essentiel est choisi par le système qui entoure le modèle.
Plus de contexte, est-ce toujours mieux ?
Non. Un contenu hors sujet ou périmé entre en concurrence avec ce qui compte, coûte des tokens et peut contredire l'état actuel. Les recherches sur les longues entrées ont montré que les modèles peuvent rater des informations placées au milieu d'un long contexte. Incluez ce dont la tâche a besoin, étiquetez-le, et retirez ce dont elle n'a plus besoin.
Pourquoi une longue conversation se dégrade-t-elle avec le temps ?
Toute la conversation est renvoyée à chaque tour, donc les anciennes erreurs, les idées abandonnées et le code remplacé restent dans le contexte et continuent d'influencer les réponses. Quand la conversation dépasse la fenêtre de contexte, l'application doit supprimer ou résumer les messages anciens. Ouvrir une nouvelle conversation avec un court résumé des décisions et de l'état actuel marche souvent mieux que de continuer.
Qu'est-ce que le RAG en context engineering ?
Le RAG (retrieval-augmented generation, génération augmentée par récupération) consiste à chercher dans vos propres documents les passages pertinents pour la question et à les insérer dans le contexte avant que le modèle réponde. C'est l'un des principaux outils du context engineering : le modèle obtient des faits actuels et précis qu'il ne pouvait pas connaître par son entraînement, et vous pouvez lui demander de répondre uniquement à partir de ces passages.
