Ingénierie de contexte
Pourquoi c’est important
En profondeur
L'ingénierie du contexte traite la fenêtre de contexte comme une ressource gérée avec un budget, un cycle de vie et des modes d'échec connus. Un appel type à un modèle de langage assemble son contexte à partir de nombreuses sources : un prompt système qui définit le comportement, des exemples few-shot, des documents tirés par la récupération, des définitions d'outils et leurs résultats, de la mémoire à long terme et l'historique courant de la conversation. La discipline consiste à décider ce qui mérite une place dans cette fenêtre, dans quel format et quel ordre, quand la rafraîchir ou la comprimer, et comment en tenir à l'écart l'information non pertinente ou erronée. Là où l'ingénierie de prompts demande comment formuler l'instruction, l'ingénierie du contexte demande ce que le modèle devrait savoir au moment où l'instruction arrive.
Le budget de contexte
Les fenêtres de contexte sont passées de quelques milliers de tokens à des centaines de milliers et plus, mais l'espace n'est jamais gratuit. Chaque token supplémentaire ajoute de la latence et du coût à chaque appel, et l'attention ne s'échelonne pas gracieusement : la recherche sur les modèles à long contexte montre que l'information enfouie au milieu d'un long prompt est utilisée de façon moins fiable que celle près du début ou de la fin, un motif connu sous le nom de « perdu au milieu ». L'ingénierie du contexte pratique veut donc dire budgéter. Les équipes comprimment les vieux tours de conversation en résumés courants, taillent les sorties d'outils verbeuses pour ne garder que les champs qui comptent, dédoublonnent le passe-partout répété, et sortent le matériel de référence du prompt pour le mettre dans la récupération, afin qu'il ne soit tiré que lorsqu'il est pertinent. Le but, c'est le plus petit contexte qui contient encore tout ce dont le modèle a besoin pour l'étape courante.
Assembler le contexte à l'exécution
Les applications modernes bâtissent le contexte dynamiquement plutôt que de l'écrire à la main. Une chaîne de RAG récupère les documents pertinents à la question de l'utilisateur et les injecte au moment de l'appel; un système de mémoire transporte des faits durables sur l'utilisateur d'une séance à l'autre; l'utilisation d'outils et des protocoles comme MCP permettent au modèle de tirer des données en direct en pleine conversation, chaque résultat étant ajouté au contexte pour l'étape suivante. Les boucles d'agents poussent ça le plus loin : chaque observation, action et résultat intermédiaire atterrit dans le contexte, si bien que le contexte devient de fait l'état de travail de l'agent, sa mémoire à court terme et son plan réunis. C'est pourquoi l'ingénierie du contexte ressort si fortement dans la conception d'agents — décider quoi conserver, quoi résumer et quoi laisser tomber au fil d'une exécution de cinquante étapes fait souvent la différence entre un agent qui reste sur la tâche et un qui dérive.
Une plus grande fenêtre n'est pas la solution
Une idée fausse répandue veut que les fenêtres de contexte d'un million de tokens rendent l'ingénierie du contexte inutile — il suffirait de tout déverser et de laisser le modèle démêler. En pratique, le long contexte introduit ses propres modes d'échec. La pourriture de contexte décrit la dégradation graduelle de la performance à mesure que la fenêtre se remplit : la justesse sur les questions de type récupération chute à mesure que la longueur d'entrée grandit, même sur les modèles annoncés pour de très longs contextes. L'empoisonnement de contexte est plus vicieux : dès qu'une affirmation hallucinée, un fait périmé ou une instruction injectée entre dans le contexte, le modèle tend à la traiter comme vérité terrain et à bâtir dessus, et les agents qui réécrivent leurs propres sorties dans le contexte peuvent amplifier une seule erreur précoce à travers toutes les étapes suivantes. Les modes d'échec apparentés incluent la distraction de contexte, où du matériel non pertinent écarte le modèle de sa tâche, et le conflit de contexte, où de l'information contradictoire dans la fenêtre produit des réponses évasives ou des choix arbitraires. Sélectionner les entrées, valider ce qui est réécrit, se défendre contre l'injection de prompt et réinitialiser périodiquement le contexte sont les contre-mesures standards.
De l'ingénierie de prompts à l'ingénierie du contexte
L'ingénierie de prompts, la discipline plus ancienne, se concentrait sur la formulation : libellé de l'instruction, choix des exemples few-shot, prompts de rôle. Elle présumait un humain écrivant un seul prompt devant une fenêtre presque vierge. À mesure que les applications sont devenues des chaînes et des agents, le goulot d'étranglement s'est déplacé — la partie difficile est devenue la gestion du flux d'information vers une fenêtre partagée entre instructions, données, outils et historique, la majeure partie étant assemblée par du logiciel plutôt que tapée par un utilisateur. Le terme d'ingénierie du contexte a pris chez les praticiens en 2025 pour nommer exactement ce déplacement, et il est resté parce qu'il décrivait ce que les équipes faisaient déjà. L'art du prompt compte toujours, et l'apprentissage en contexte demeure le mécanisme sur lequel tout repose, mais la formulation n'est plus qu'une composante d'une surface d'ingénierie plus large qui couvre aussi la qualité de récupération, la conception de la mémoire, le formatage des sorties d'outils et la gestion du cycle de vie du contexte.