Demandez à un agent IA de faire du vrai travail et un phénomène prévisible se produit. Le premier brouillon revient faux, non pas parce que le modèle est faible, mais parce qu'il n'a jamais vu le paragraphe de politique, la grille tarifaire actuelle ou l'exemple de ton qui auraient rendu la réponse évidente. La solution est rarement un prompt plus malin. La solution, c'est un meilleur context engineering.
Le context engineering est la discipline qui a remplacé le culte du prompt dans les équipes agents sérieuses. L'idée, popularisée en 2025 et devenue vocabulaire standard en 2026, est simple : la qualité des modèles est à peu près la même pour tout le monde, donc l'avantage va à qui assemble la meilleure information autour du modèle. Anthropic le décrit comme la curation de l'ensemble optimal de tokens pendant l'inférence, y compris tout ce qui atterrit dans la fenêtre hors du prompt lui-même.
Ce guide explique ce qu'est le context engineering, pourquoi c'est devenu le sujet agent le plus bruyant de l'année, comment il fonctionne en pratique, en quoi il diffère du prompt engineering et de la mémoire d'agent, et comment une équipe d'agents de rôle le met en œuvre sans laboratoire de recherche. Si les agents qui agissent sur des outils sont nouveaux pour vous, lisez Qu'est-ce que MCP pour les agents IA ? en parallèle.
Le context engineering en langage simple
Le context engineering est la pratique qui consiste à concevoir délibérément ce qu'un modèle IA voit à chaque appel qu'il effectue en travaillant pour vous.
À chaque exécution, le modèle voit un paquet : les instructions système, la demande de l'utilisateur, les documents récupérés, les définitions d'outils, l'historique récent de conversation et les résultats des appels d'outils précédents. Ce paquet est le contexte. L'ingénierie de ce contexte signifie décider, volontairement :
- Quelles instructions et règles sont toujours présentes, et lesquelles n'apparaissent que pour certaines tâches
- Quels faits sont récupérés depuis votre base de connaissances, dans quel ordre, avec quels contrôles de fraîcheur
- Quels outils l'agent peut voir à cette étape, et comment leurs descriptions sont rédigées
- Ce qu'il advient des longs historiques : ce qui est résumé, ce qui est conservé tel quel, ce qui est abandonné
- À quoi doit ressembler la sortie pour que l'étape suivante, ou l'agent suivant, puisse l'utiliser
Le changement mental consiste à passer de l'écriture d'une requête à la construction d'un pipeline. Un prompt est une phrase. Le contexte est toute l'usine qui produit cette phrase et tout ce qui l'entoure, pour chaque appel, dans une boucle qui peut tourner cinquante étapes avant qu'un humain ne voie quoi que ce soit.
Un agent support à qui l'on pose une question de facturation illustre la différence. Une configuration naïve donne au modèle la question plus un énorme tas de documents. Une configuration bien conçue lui donne la question, le dossier d'abonnement actuel du client, les deux sections de politique de remboursement applicables, un court guide de style, trois tickets passés pertinents, et exactement quatre outils : consulter, rédiger, escalader et journaliser. Le second agent n'est pas plus intelligent. Il est mieux nourri.
Pourquoi le context engineering fait tant de bruit en 2026
Plusieurs forces ont convergé pour faire du contexte le sujet sur lequel tout le monde, de Salesforce à Sourcegraph en passant par Neo4j, publie des guides cette année.
1. Les modèles ont banalisé la partie difficile. Les modèles frontière sont tous suffisamment bons pour que les astuces de formulation ne distinguent plus les équipes. Ce qui les distingue, c'est l'architecture d'information autour du modèle : quelles sources sont à jour, ce qui est récupéré et quand, combien tient dans un tour. Les rapports de tendances 2026 placent le context engineering en successeur direct du prompt engineering, et le titre de « context engineer » apparaît dans les équipes plateforme.
2. Les agents exécutent de longues boucles. Un chatbot répond en un tour. Un agent travaille en boucle, appelle des outils, accumule de l'état, et prend sa décision à l'étape 47 avec le résidu des étapes 1 à 46 encore dans la fenêtre. Le budget de tokens est fini, et l'attention se dégrade quand la fenêtre est saturée. La plupart des échecs en production remontent à la façon dont ce budget a été dépensé, pas à un mauvais prompt initial.
3. Des fenêtres plus grandes n'ont pas réglé le problème. Les fenêtres d'un million de tokens ont changé l'architecture mais pas la physique. Tout y verser dilue toujours le signal, augmente le coût par appel et ralentit chaque étape. Les équipes ont appris que la qualité de la récupération bat la taille de la fenêtre, la même leçon que les moteurs de recherche ont enseignée une génération plus tôt.
4. Les systèmes multi-agents l'ont rendu structurel. Quand un orchestrateur confie du travail à des sous-agents spécialisés, chaque transfert est une décision de conception de contexte : ce que le sous-agent doit savoir, et ce qui ne ferait que polluer sa concentration. Les systèmes multi-agents, c'est du context engineering avec un organigramme.
Rien de tout cela n'est abstrait. Les symptômes sont quotidiens : des agents qui citent les tarifs du trimestre dernier, des brouillons dans la mauvaise voix de marque, des bots support qui rouvrent des tickets résolus, des agents de code qui lisent quatre mille résultats de recherche et ratent le vrai bug.
Comment le context engineering fonctionne en pratique
Une configuration efficace a cinq pièces mobiles. Vous pouvez les implémenter dans n'importe quelle stack.
1. Des instructions en couches
Les règles stables vivent en haut : rôle, audience, ton, contraintes strictes. Les règles propres à une tâche ne se chargent que lorsqu'elles sont pertinentes. Un agent rédacteur de contenu garde des règles permanentes de voix et de format, mais ne charge la checklist SEO que pour les articles de blog. La couche permanente reste ainsi petite et nette au lieu d'un mur de texte que le modèle survole.
2. Une récupération intentionnelle
La récupération n'est pas « attacher le wiki ». C'est une requête conçue par étape : le dossier actuel du client, les deux sections de politique applicables, la liste de prix la plus fraîche. Les bons pipelines filtrent par date, dédupliquent et classent par pertinence pour la question réelle. L'objectif est le plus petit ensemble de faits à fort signal, pas l'archive la plus complète.
3. Curation et description des outils
Chaque définition d'outil consomme de la fenêtre et de l'attention. Exposez cinq outils pertinents, pas cinquante. Rédigez les descriptions d'outils comme des modes d'emploi : quand appeler, ce que cela coûte, ce que cela renvoie, ce qu'il ne faut jamais faire. Cela rejoint la réflexion MCP : le protocole standardise la connexion, mais le context engineering décide ce que chaque agent voit réellement.
4. Gestion de l'historique
Les longues sessions ont besoin de compaction : les étapes anciennes résumées, les étapes récentes conservées telles quelles, les décisions extraites en notes structurées. Quand une conversation franchit une frontière de phase, disons de la recherche à la rédaction, le contexte doit être reconditionné, pas simplement allongé. C'est là que la mémoire d'agent se branche : la mémoire stocke, le contexte sélectionne.
5. Contrats de sortie
La sortie de chaque étape doit être façonnée pour son consommateur : champs structurés pour l'outil suivant, brief propre pour l'agent suivant, dossier vérifiable pour l'humain. Les contrats de sortie sont du context engineering pour le futur, car chaque sortie devient l'entrée de quelqu'un d'autre.
Context engineering vs prompt engineering vs mémoire d'agent
Ces trois notions sont constamment confondues. Ce sont des couches différentes du même système.
| Dimension | Prompt engineering | Context engineering | Mémoire d'agent |
|---|---|---|---|
| Question centrale | Comment formuler cette demande ? | Que doit voir le modèle à chaque étape ? | Que faut-il conserver entre les sessions ? |
| Portée | Un appel | Toute la boucle, chaque appel | À travers appels et sessions |
| Travail typique | Formulation, exemples, formats | Récupération, curation d'outils, compaction, ordre | Stockage, rappel, oubli, savoir d'équipe |
| Mode d'échec | Formulation vague ou contradictoire | Bruit, faits manquants, fenêtres saturées | Faits périmés, fuites de confidentialité |
| Responsable | Celui qui écrit la demande | Le constructeur d'agents ou l'équipe plateforme | Plateforme et gouvernance |
Le signe le plus clair : si vos progrès viennent de la reformulation, vous faites du prompt engineering. S'ils viennent de la rewiring des données qui entrent, dans quel ordre, et de ce qui est éjecté, vous faites du context engineering. S'ils viennent de décider ce qui survit demain, vous travaillez la mémoire. Les équipes de production font les trois, mais le context engineering concentre l'essentiel du levier aujourd'hui.
Quand le context engineering aide, et quand il est superflu
Cela vaut l'effort :
- Les agents en boucles multi-étapes avec appels d'outils, où le bruit se cumule
- Les équipes qui partagent des agents, où le contexte réglé par l'un profite à tous
- Les sorties réglementées ou sensibles pour la marque, où le bon paragraphe de politique doit être présent
- Les charges sensibles au coût, où réduire le gonflement de fenêtre diminue la facture à chaque appel (voir comment payer moins cher les agents IA)
- Tout agent dont les échecs ressemblent à « il ne savait pas » plutôt qu'à « il ne pouvait pas raisonner »
Probablement superflu :
- Les questions ponctuelles à un chatbot, où une phrase claire suffit
- Les prototypes rapides pour tester si un workflow mérite d'être automatisé
- Les tâches aux entrées petites et stables, comme reformater un type de document fixe
Une heuristique utile : plus la boucle est longue et plus le résultat compte pour les autres, plus le context engineering paie. Plus la tâche est courte et jetable, plus c'est de la cérémonie.
Approbation humaine et rayon d'impact
La conception du contexte est aussi une surface de sécurité. Ce que l'agent voit façonne ce qu'il fait, et ce qu'il fait va du brouillon inoffensif au paiement irréversible.
Concevez le contexte par niveau de risque, pas par commodité. Les étapes à faible risque comme rédiger et résumer peuvent tourner sur un contexte riche et large. Les étapes à fort impact comme les remboursements, suppressions et envois externes méritent un contexte minimal et vérifié, plus un point de contrôle humain. Le dossier que l'humain examine est lui-même un artefact de context engineering : petit, actuel, et assez complet pour décider.
C'est le cœur pratique des agents IA avec humain dans la boucle : l'humain ne relit pas le monde entier, parce que le pipeline a déjà sélectionné les trois faits qui comptent. Associez un contexte gradué par risque à des permissions d'outils limitées, et la sécurité des agents cesse d'être un audit séparé pour faire partie du même passage de conception.
Schémas d'équipe : qui possède le contexte
Dans les équipes saines, le contexte est possédé comme du code, pas comme du folklore. Quatre schémas reviennent.
Des agents de rôle au contexte cadré. Chaque rôle a sa couche d'instructions et son jeu d'outils. Un agent responsable support voit macros, politiques et historique de tickets. Un agent responsable commercial voit tarifs actuels, arguments concurrentiels et dossiers CRM. Personne ne maintient un méga-prompt qui essaie d'être les deux, ce qui rejoint la raison pour laquelle les agents IA verticaux battent les généralistes : des rôles étroits rendent possible un contexte étroit et à fort signal.
Une couche de connaissances partagée. Faits produit, politiques et guides de voix vivent dans un seul endroit maintenu, versionné et daté, pour que chaque agent récupère la même vérité actuelle. Quand la page de tarifs change, une mise à jour se propage à tous les rôles.
Des revues de contexte dans le cycle de release. Quand un agent déraille, la première question est « qu'a-t-il vu ? » et non « quel modèle était-ce ? ». Les équipes examinent les traces comme des diffs de code, une habitude qui s'accorde naturellement avec l'observabilité des agents.
Des modèles pour les nouvelles recrues, humaines et IA. Un nouvel agent développeur senior hérite de la carte du dépôt, des standards de code et de la checklist de revue comme contexte, de la même façon qu'une recrue humaine hérite de documents d'accueil. Embarquer un agent, c'est du context engineering avec une date limite.
Un plan d'action pour cette semaine
Pas besoin d'une équipe plateforme pour commencer. Cinq gestes, dans l'ordre :
- Choisissez un workflow agaçant. Celui où l'agent « marche presque » : un rapport hebdomadaire, un tri de tickets, un premier brief. Faible rayon d'impact, forte répétition.
- Écrivez ce que le modèle devrait voir. Pour un run réel, listez les cinq à dix faits ou documents qui auraient rendu la sortie correcte. Cette liste est votre spécification de contexte, et elle est généralement plus courte que vous ne le craignez.
- Réduisez la liste d'outils. Retirez chaque outil que l'agent n'a pas utilisé lors des dix derniers runs. Réécrivez les descriptions des survivants comme des modes d'emploi, pas comme des étiquettes d'API.
- Ajoutez une règle de fraîcheur. Des dates sur les documents récupérés, ou un champ « à jour au » dans le dossier. Le contexte périmé cause plus de dégâts que le contexte manquant, car il a l'air sûr de lui.
- Ajoutez un point de contrôle. Pour l'étape la plus irréversible, exigez une approbation humaine avec un dossier de revue sélectionné. Ne mesurez rien de compliqué : comptez combien de fois le contrôle a attrapé un vrai problème.
Faites tourner le workflow une semaine, puis revisitez la spécification de contexte. C'est la deuxième itération qui compose les gains, car vous savez maintenant quels faits récupérés ont réellement servi.
Où Upchat se situe
Le context engineering récompense exactement ce pour quoi Upchat est construit : des rôles spécialisés, des outils cadrés et une propriété partagée en équipe.
Sur Upchat, vous créez des agents de rôle avec leurs propres instructions et connaissances, vous ne connectez que les outils dont chaque rôle a besoin, et vous gardez l'approbation humaine sur les étapes où une erreur ferait mal. Comme les agents vivent dans le cloud en actifs partagés d'équipe, la conception de contexte que vous réglez le lundi profite à chaque coéquipier le mardi, au lieu de rester enfermée dans l'historique de chat privé d'une seule personne. Et comme les rôles restent étroits, le contexte de chaque agent reste petit, actuel et à fort signal, ce qui est tout l'enjeu.
Si vous voulez essayer le plan ci-dessus sans assembler d'infrastructure d'abord, créez un compte Upchat et construisez votre premier agent de rôle autour d'un seul workflow : instructions cadrées, une poignée d'outils, un point d'approbation. C'est du context engineering que vous pouvez livrer cette semaine.
En résumé
Le context engineering est la reconnaissance que les agents échouent à cause des entrées, pas de l'intelligence. Le modèle est une infrastructure partagée ; le contexte est votre avantage privé. Les équipes qui traitent instructions, récupération, outils, historique et sorties comme un seul système conçu obtiennent des agents qui citent des faits actuels, restent dans la voix et gagnent la confiance des relecteurs. Celles qui continuent à écrire des prompts plus longs récoltent des déceptions plus longues.
Commencez petit : un workflow, une spécification de contexte, un point de contrôle. Puis grandissez d'un agent réglé vers un banc coordonné d'agents de rôle, en vous appuyant sur ce qu'apporte un système multi-agents, avec la mémoire d'agent qui porte la connaissance entre les sessions et l'approbation humaine dans la boucle qui garde les étapes qui comptent. L'ère du prompt demandait « comment formuler cela ? ». L'ère du contexte pose une meilleure question : « que doit voir le modèle ? »