Ingénierie du contexte pour les agents IA : un guide pratique (2026)
Ce qu'est l'ingénierie du contexte, en quoi elle diffère du prompt engineering, les quatre techniques fondamentales, comment se positionnent les principaux frameworks, comment la mesurer et comment l'appliquer dans des systèmes multi-agents.
Un agent IA ne vaut que ce que vaut l'information présente dans sa fenêtre de contexte au moment où il décide de sa prochaine action — et organiser cette information est tout l'enjeu. Si l'ingénierie de prompt consiste à rédiger une bonne instruction, l'ingénierie de contexte consiste à gérer l'ensemble de l'environnement d'information dans lequel le modèle évolue : instructions système, outils, documents récupérés, mémoire et historique en cours de la tâche. À mesure que les agents prennent en charge des travaux plus longs et multi-étapes, c'est devenu le levier le plus important pour déterminer si un agent réussit ou s'effondre silencieusement. Ce guide couvre ce qu'est l'ingénierie de contexte, en quoi elle diffère de l'ingénierie de prompt, les techniques fondamentales, et comment l'appliquer dans de vrais systèmes d'agents.
Pourquoi l'ingénierie de contexte est importante
L'ingénierie de contexte est importante parce que les grands modèles de langage ont une fenêtre de contexte finie, et la manière dont vous remplissez cette fenêtre détermine la qualité de chaque décision prise par l'agent. Un modèle ne vaut que ce que vaut l'information qu'on lui présente — lui en donner trop peu et il hallucine ; lui en donner trop, ou du mauvais type, et sa précision se dégrade.
Ce n'est pas une préoccupation théorique. Des chercheurs ont documenté un effet « perdu au milieu », où les modèles utilisent de manière fiable l'information située au début et à la fin d'un long contexte, mais négligent les faits enfouis au milieu. Les praticiens décrivent un problème connexe qu'ils appellent la « pourriture du contexte » (context rot) : à mesure qu'une conversation ou l'exécution d'un agent s'allonge, les tokens non pertinents s'accumulent, le rapport signal/bruit diminue, et le modèle commence à faire de moins bons choix. La fenêtre ne s'est pas rétrécie — elle s'est encombrée.
Ce changement de terminologie reflète un véritable changement de pratique. En 2025, des voix influentes de l'IA — dont Andrej Karpathy et Tobi Lütke de Shopify — ont soutenu que « l'ingénierie de contexte » décrit bien mieux ce que font réellement les personnes qui construisent des applications LLM sérieuses que ne le fait « l'ingénierie de prompt ». Anthropic a publié des conseils sur une ingénierie de contexte efficace pour les agents ; les équipes derrière des produits d'agents comme Manus ont longuement écrit sur les leçons tirées de la gestion du contexte en production. Le consensus : pour les systèmes agentiques, le contexte est le produit.
Qu'est-ce que l'ingénierie de contexte ?
L'ingénierie de contexte est la discipline consistant à assembler le bon ensemble de tokens pour un modèle au moment de l'inférence, afin que le modèle dispose exactement de ce dont il a besoin pour entreprendre la prochaine action correcte — ni plus, ni moins. Le « contexte » comprend tout ce qui se trouve à l'intérieur de la fenêtre :
- Instructions système — le rôle de l'agent, ses contraintes et ses règles de comportement
- Outils et leurs définitions — les actions que l'agent peut entreprendre, et comment elles sont décrites
- Connaissances récupérées — documents, résultats de recherche ou lignes de base de données extraits pour cette tâche
- Mémoire — faits reportés depuis plus tôt dans la session ou depuis des sessions précédentes
- Historique de la conversation et des actions — le registre courant de ce qui a été dit et fait
- La demande actuelle de l'utilisateur — l'objectif immédiat
L'ingénierie de contexte est l'ensemble des décisions concernant ce qui entre dans chacun de ces emplacements, sous quelle forme, et à quel moment. Elle traite la fenêtre de contexte comme une ressource rare et gérée, plutôt que comme un seau dans lequel on continue de déverser du texte.
La fenêtre de contexte est un budget d'attention fini — l'ingénierie de contexte décide de ce qui remplit chaque emplacement.
Ingénierie de contexte vs ingénierie de prompt
La différence entre l'ingénierie de contexte et l'ingénierie de prompt est une différence de portée : l'ingénierie de prompt optimise une seule instruction, tandis que l'ingénierie de contexte gère l'ensemble de l'environnement d'information, dynamique, tout au long d'une tâche multi-étapes. L'ingénierie de prompt est un sous-ensemble de l'ingénierie de contexte.
| Ingénierie de prompt | Ingénierie de contexte | |
|---|---|---|
| Portée | Un seul prompt / une seule instruction | L'ensemble de la fenêtre de contexte dans le temps |
| État | Principalement sans état, en une seule fois | Avec état, évolue au fil de nombreuses étapes |
| Préoccupation | Formulation, exemples, mise en forme | Quoi inclure, récupérer, mémoriser et écarter |
| Usage typique | Une seule complétion ou un seul tour de discussion | Agents autonomes, tâches de longue durée |
| Échec évité | Une instruction vague ou mal comprise | Pourriture du contexte, distraction, état contradictoire |
L'ingénierie de prompt reste importante — un prompt système bien formulé fait partie d'une bonne ingénierie de contexte. Mais dès qu'un agent s'exécute pendant des dizaines d'étapes, appelle des outils et accumule de l'historique, la formulation d'un prompt unique n'est plus le goulot d'étranglement. Ce qui compte, c'est la discipline qui gère tout ce qui l'entoure.
Les quatre techniques fondamentales
L'essentiel du travail d'ingénierie de contexte se ramène à quatre opérations sur la fenêtre de contexte. Un bon moyen de les retenir : écrire, sélectionner, compresser et isoler.
Écrire, sélectionner, compresser et isoler — les quatre opérations derrière chaque décision d'ingénierie de contexte.
1. Écrire — persister le contexte hors de la fenêtre
Tout ce dont l'agent a besoin ne devrait pas vivre dans le prompt. Écrire le contexte signifie stocker l'information à l'extérieur — brouillons, fichiers, un espace de mémoire, une liste de tâches — afin qu'elle survive au-delà d'une seule fenêtre et puisse être rappelée délibérément. Un agent de longue durée qui écrit son plan dans un fichier et le relit reste bien mieux sur la bonne voie que celui qui s'appuie uniquement sur l'historique de conversation.
2. Sélectionner — n'apporter que ce qui est pertinent maintenant
Sélectionner le contexte est l'art de récupérer la bonne information au bon moment : le document spécifique, la décision passée pertinente, la seule définition d'outil dont cette étape a besoin. C'est là que vivent la génération augmentée par récupération (RAG), la recherche sémantique et la sélection intelligente d'outils. L'objectif est la précision — extraire les trois faits pertinents, pas les trois cents adjacents.
3. Compresser — réduire les tokens tout en conservant le signal
Compresser le contexte signifie résumer ou élaguer afin que la fenêtre contienne du sens, pas du volume. Les tactiques courantes incluent le résumé des sous-tâches terminées, la troncature des sorties d'outils verbeuses, et le remplacement des longs historiques par un récapitulatif condensé. La compression est ce qui permet à un agent de travailler sur une tâche plus longtemps que ne le permettrait autrement sa fenêtre de contexte brute.
4. Isoler — répartir le contexte entre agents ou frontières
Isoler le contexte signifie donner à différentes parties d'un problème leurs propres fenêtres propres — par exemple, faire naître un sous-agent avec uniquement le contexte dont il a besoin pour une sous-tâche, puis ne retourner que le résultat. L'isolation empêche qu'une partie d'un travail ne pollue une autre, et constitue le fondement des systèmes multi-agents fiables.
Comment se comparent les principaux frameworks
Une source de confusion est que chaque équipe majeure utilise son propre vocabulaire pour désigner les mêmes opérations sous-jacentes. Anthropic, LangChain et des fournisseurs de bases de données de graphes comme Neo4j décrivent tous l'ingénierie de contexte différemment — mais ils correspondent clairement aux quatre opérations ci-dessus. Ce tableau les met en correspondance :
| Opération (ce guide) | Vision d'Anthropic | Vision de LangChain | Vision graphe de connaissances / GraphRAG |
|---|---|---|---|
| Écrire (persister hors de la fenêtre) | Prise de notes structurée, mémoire d'agent (NOTES.md, listes de tâches) | Store et State ; outils qui écrivent via Command | Mémoire à long terme ; le graphe lui-même comme stockage persistant |
| Sélectionner (récupérer ce qui est pertinent maintenant) | Contexte juste-à-temps, recherche agentique, récupération hybride | Sélection dynamique d'outils/messages ; outils qui lisent | RAG hybride, GraphRAG, « contexte minimal viable » |
| Compresser (réduire les tokens, conserver le signal) | Compaction ; dépenser le « budget d'attention » judicieusement | Résumé du cycle de vie via des middlewares | Budgétisation en tokens/coût ; la « pyramide de contexte » |
| Isoler (séparer des fenêtres propres) | Architectures de sous-agents renvoyant des résumés distillés | Frontières de cycle de vie et sous-agents | Transferts et protocoles (par ex., MCP) |
Si vous avez lu ces sources et avez eu l'impression qu'elles se contredisaient, voici pourquoi : elles décrivent les quatre mêmes mouvements sous des angles différents. Choisissez le vocabulaire qui convient à votre stack — ce sont les opérations qui comptent.
L'ingénierie de contexte pour les systèmes multi-agents
Dans les systèmes multi-agents, l'ingénierie de contexte devient un problème de coordination : chaque agent a besoin d'assez de contexte pour accomplir son travail, mais en partager trop crée du bruit, des coûts et un état contradictoire. Le modèle dominant est un orchestrateur qui détient le plan de haut niveau et délègue des sous-tâches étroitement définies à des sous-agents spécialisés, chacun opérant dans une fenêtre isolée.
Chaque sous-agent obtient une fenêtre propre et isolée, et ne renvoie qu'un résultat distillé — empêchant toute contamination croisée.
Cela fonctionne grâce au principe d'« isolation » évoqué plus haut. Un sous-agent de recherche qui ne voit jamais que la question de recherche et ses propres résultats surpassera celui qui doit également se frayer un chemin à travers l'historique non lié de la tâche de codage d'un agent voisin. L'orchestrateur compresse ensuite la sortie de chaque sous-agent jusqu'au résultat essentiel avant de la réintégrer dans le contexte principal. Bien fait, c'est ainsi que les équipes font fonctionner des agents sur des tâches qui déborderaient de nombreuses fois n'importe quelle fenêtre de contexte unique.
Modes d'échec courants de l'ingénierie de contexte
La plupart des échecs d'agents remontent à une poignée de problèmes de contexte récurrents. Les nommer permet de mieux s'en prémunir dans la conception :
| Mode d'échec | À quoi cela ressemble | Correction principale |
|---|---|---|
| Empoisonnement du contexte | Une hallucination ou une erreur entre dans le contexte et est référencée encore et encore, aggravant l'erreur | Isoler + écrire uniquement des faits vérifiés |
| Distraction du contexte | La fenêtre grossit tant que le modèle se focalise excessivement sur l'historique accumulé et cesse de raisonner sur l'objectif réel | Compresser |
| Confusion du contexte | Des informations non pertinentes encombrent la fenêtre et induisent le modèle vers un mauvais choix | Sélectionner plus étroitement |
| Conflit de contexte | Une information nouvellement récupérée contredit ce qui se trouve déjà dans la fenêtre, et le modèle ne parvient pas à concilier les deux | Sélectionner + écrire vers une source unique de vérité |
Les quatre techniques fondamentales sont les antidotes : écrire pour délester, sélectionner pour rester pertinent, compresser pour réduire l'encombrement, et isoler pour empêcher la contamination croisée.
Un mode d'échec que les guides populaires couvrent rarement est un problème de sécurité : l'injection de prompt via le contexte récupéré. Lorsqu'un agent récupère une page web, un document ou un résultat d'outil, ce contenu peut contenir des instructions conçues pour détourner l'agent. Traitez tout ce que vous sélectionnez dans la fenêtre comme une entrée non fiable — gardez les données récupérées séparées des instructions système, et exécutez les outils dans un bac à sable plutôt que directement sur une machine de confiance.
Comment mesurer si l'ingénierie de contexte fonctionne
Vous mesurez l'ingénierie de contexte en suivant le taux de réussite des tâches par rapport aux tokens et au temps nécessaires pour y parvenir — une bonne ingénierie de contexte augmente le taux de réussite tout en maintenant ou en réduisant le coût. La plupart des guides décrivent des techniques mais ne disent jamais comment savoir si elles fonctionnent ; voici les métriques qui comblent cet écart.
- Taux de réussite des tâches — la part des exécutions qui atteignent un résultat correct et complet. C'est la métrique de résultat ; tout le reste n'est qu'un moyen d'y parvenir. Suivez-la sur un ensemble d'évaluation fixe de tâches représentatives afin de pouvoir comparer avant et après chaque changement.
- Efficacité du contexte (tokens par tâche réussie) — total des tokens consommés divisé par le nombre de réussites. Une baisse des tokens par réussite est le signal le plus clair que la compression et la sélection portent leurs fruits.
- Utilisation de la fenêtre — à quel point la fenêtre de contexte est remplie pendant une tâche. Une proximité constante avec la limite prédit une pourriture du contexte ; c'est un indicateur avancé qu'il faut compresser ou isoler.
- Précision et rappel de la récupération — parmi les éléments que vous avez sélectionnés dans la fenêtre, combien étaient réellement pertinents (précision), et parmi les éléments pertinents disponibles, combien avez-vous récupérés (rappel). Une précision médiocre signifie que vous ajoutez du bruit ; un rappel médiocre signifie que vous privez le modèle d'information.
- Latence et coût par tâche — le plafond pratique. Une exploration « juste-à-temps » agressive peut améliorer la précision mais ralentir l'agent ; cette métrique maintient ce compromis honnête.
La discipline qui relie tout cela est le test de régression : conservez une suite de tâches fixes, exécutez-la après chaque changement apporté aux prompts, à la récupération ou à la mémoire, et observez l'évolution des chiffres. L'ingénierie de contexte sans boucle d'évaluation n'est que de la conjecture.
Comment Happycapy applique l'ingénierie de contexte
Happycapy est un ordinateur natif d'agents qui exécute des agents IA — y compris Claude Code — directement dans votre navigateur, et l'ingénierie de contexte est intégrée au fonctionnement de ces agents plutôt que laissée à l'utilisateur. Trois choix de conception font l'essentiel du travail :
- Les skills comme contexte ciblé. Plutôt que de déverser toutes les capacités dans un seul prompt, Happycapy permet à un agent de faire appel à une skill spécifique — concevoir une présentation, analyser une feuille de calcul, faire de la recherche web — afin que seules les instructions et les outils pertinents entrent dans la fenêtre pour cette tâche. Ce sont les principes « sélectionner » et « isoler » appliqués par défaut.
- Un bac à sable persistant avec mémoire et fichiers. Chaque agent travaille dans un espace de travail isolé où il peut écrire des plans, des résultats intermédiaires et des notes sur disque, et les rappeler plus tard — le principe « écrire », afin que la progression survive au-delà d'une seule fenêtre de contexte.
- Accès à plus de 150 modèles. Différentes étapes ont des besoins de contexte différents ; router le travail vers un modèle approprié est en soi une décision d'ingénierie de contexte.
Le résultat pratique est que vous pouvez confier une tâche longue et multi-étapes et laisser l'agent gérer son propre contexte en arrière-plan, puis recevoir le résultat final — sans avoir à ajuster manuellement les prompts ni à surveiller la fenêtre vous-même.
Se lancer dans l'ingénierie de contexte
Vous n'avez pas besoin de reconstruire toute votre stack pour commencer. Commencez par les habitudes à plus fort effet de levier :
- Traitez la fenêtre de contexte comme un budget. Avant d'ajouter quoi que ce soit, demandez-vous si cela mérite ses tokens.
- Sortez l'état du prompt. Utilisez des fichiers, des brouillons ou un espace de mémoire pour tout ce que l'agent doit conserver.
- Récupérez étroitement. Extrayez les faits spécifiques dont une étape a besoin, pas des documents entiers.
- Résumez au fur et à mesure. Remplacez les longs historiques et les sorties d'outils verbeuses par des récapitulatifs serrés.
- Isolez les sous-tâches. Donnez à chaque tâche distincte son propre contexte propre, en particulier dans les configurations multi-agents.
Si vous préférez ne rien ajuster manuellement, Happycapy exécute vos tâches avec ces schémas déjà intégrés à l'agent : il gère sa propre fenêtre de contexte en arrière-plan — en sélectionnant, en compactant et en isolant au fur et à mesure — afin que vous décriviez simplement le résultat souhaité sans jamais toucher au budget de tokens vous-même.
Questions fréquentes
Q : L'ingénierie de contexte est-elle la même chose que l'ingénierie de prompt ?
Non. L'ingénierie de prompt optimise une seule instruction ; l'ingénierie de contexte gère l'ensemble de l'environnement d'information qu'un agent perçoit tout au long d'une tâche multi-étapes — instructions, outils, données récupérées, mémoire et historique. L'ingénierie de prompt fait partie de l'ingénierie de contexte.
Q : Pourquoi l'ingénierie de contexte est-elle importante spécifiquement pour les agents IA ?
Parce que les agents s'exécutent pendant de nombreuses étapes, appellent des outils et accumulent de l'historique, leur fenêtre de contexte se remplit rapidement. Sans gestion active, les tokens non pertinents évincent le signal et les décisions de l'agent se dégradent — un problème connu sous le nom de pourriture du contexte. L'ingénierie de contexte maintient la fenêtre focalisée sur ce qui compte.
Q : Quelles sont les principales techniques d'ingénierie de contexte ?
Les quatre techniques fondamentales sont écrire (persister le contexte hors de la fenêtre), sélectionner (ne récupérer que ce qui est pertinent maintenant), compresser (résumer pour économiser des tokens) et isoler (donner aux sous-tâches leur propre contexte propre). L'essentiel du travail pratique est une combinaison de ces éléments.
Q : L'ingénierie de contexte est-elle une compétence qui vaut la peine d'être apprise en 2026 ?
Oui. À mesure que davantage de logiciels sont construits sur des LLM et des agents autonomes, la capacité à bien gérer le contexte devient une compétence centrale pour les développeurs, les concepteurs de prompts et les équipes produit IA — et c'est de plus en plus ce qui distingue un agent qui fonctionne d'un agent qui ne fonctionne pas.
Q : Comment mesure-t-on si l'ingénierie de contexte fonctionne ?
Suivez le taux de réussite des tâches par rapport à un ensemble d'évaluation, ainsi que des métriques d'efficacité : tokens par tâche réussie, utilisation de la fenêtre de contexte, précision et rappel de la récupération, et latence/coût par tâche. Une bonne ingénierie de contexte augmente le taux de réussite tout en maintenant ou en réduisant le coût. Exécutez la suite après chaque changement afin de voir si un ajustement a aidé ou nui.
Q : Dois-je faire moi-même de l'ingénierie de contexte pour utiliser des agents IA ?
Pas nécessairement. Des plateformes d'agents comme Happycapy intègrent la gestion du contexte dans le système — en délimitant le contexte avec des skills, en persistant l'état dans un bac à sable, et en isolant les sous-tâches — afin que vous puissiez exécuter des travaux multi-étapes sans ajuster manuellement la fenêtre de contexte.
