1 
2Le mot du moment, dans le petit monde des agents IA, est l’ingénierie contextuelle.
3 
4Cela ressemble à un énième label inventé pour vendre quelque chose que nous faisions déjà. C’est en partie le cas. Cependant, comme cela arrive souvent, l’étiquette fait son chemin car elle donne un nom à une vraie douleur.
5 
6Le problème est le suivant : les modèles n’échouent pas simplement parce qu’ils « ne pensent pas ». Ils échouent souvent parce que nous les envoyons travailler dans la mauvaise pièce.
7 
8Nous leur donnons d'anciennes instructions. Nous lui cachons des fichiers importants. Nous leur transmettons des documents trop longs et ne disons pas ce qui compte. Nous leur montrons les logs sans priorité. Nous leur donnons dix outils sans leur expliquer quand les utiliser. On s'étonne alors si l'agent se déplace comme une personne réveillée dans un appartement inconnu.
9 
10L'invite est la phrase que vous lui dites. Le contexte est le monde que vous préparez autour de lui.
11 
12## De l'ingénierie rapide à l'ingénierie contextuelle
13 
14L’ingénierie rapide était souvent considérée comme de l’écriture. Choisissez les bons mots, demandez de la bonne manière, ajoutez des exemples, précisez le format.
15 
16L’ingénierie du contexte est plus proche de l’architecture.
17 
18Vous ne vous contentez pas de demander « comment formuler la demande ? ». Il demande :
19 
20- quelles informations sont réellement nécessaires ?
21- qu'est-ce que le bruit ?
22- que faut-il récupérer à la volée ?
23- que faut-il retenir ?
24- quels outils doivent être exposés ?
25- quelles instructions sont stables et lesquelles dépendent de la tâche ?
26- comment faire comprendre à l'agent ce qui fait autorité ?
27 
28C'est un changement subtil mais énorme. Car lorsque vous travaillez avec des agents, le contexte n’est pas un bloc statique. Cela change à chaque étape.
29 
30L'agent ouvre un fichier, apprend quelque chose, exécute un test, reçoit une erreur, met à jour le plan, appelle un outil, découvre une dépendance. À chaque tour, il doit décider quoi emporter avec lui et quoi laisser de côté.
31 
32C'est de l'ingénierie.
33 
34## Le contexte n'est pas une décharge
35 
36Les modèles avec de grandes fenêtres contextuelles nous ont donné la tentation : ajoutons tout.
37 
38C'est compréhensible. Si j'ai un million de jetons, pourquoi devrais-je choisir ?
39 
40Parce que même quand on peut tout mettre dedans, cela ne veut pas dire que tout est utile. En effet, le bruit a un coût. Cela coûte des jetons, cela coûte de l’attention, cela coûte de la latence, cela coûte de la qualité. Un modèle peut se perdre dans des détails non pertinents, tout comme nous lorsque nous ouvrons vingt onglets sans nous rappeler pourquoi.
41 
42Un bon contexte a une hiérarchie :
43 
441. instructions et politiques du système ;
452. objectif spécifique ;
463. situation actuelle ;
474. données pertinentes ;
485. contraintes ;
496. outils disponibles ;
507. suivre les décisions déjà prises.
51 
52Il n’est pas nécessaire de tout traiter au même niveau. Une commande utilisateur vaut plus qu’une vieille note. Un test échoué vaut désormais plus qu’une préférence esthétique d’il y a trois mois. Une politique de sécurité vaut plus qu’un raccourci de production.
53 
54L’ingénierie du contexte signifie également donner des pondérations, pas seulement des données.
55 
56## Mémoire : souvenez-vous moins, souvenez-vous mieux
57 
58La mémoire des agents est l’un des sujets les plus glissants.
59 
60En tant qu'utilisateur, vous souhaitez que l'agent vous connaisse. Vous voulez qu’il se souvienne du ton, du plan, des conventions, des choses déjà décidées. En tant qu'ingénieur, vous savez que toute mémoire persistante est aussi un risque : elle peut être fausse, ancienne, trop personnelle, trop générique, invérifiable.
61 
62Un souvenir utile doit avoir au moins trois qualités :
63 
64- provenance : d'où proviennent ces informations ?
65- date : quand était-ce vrai ?
66- finalité : à quel type de tâche doit-il être utilisé ?
67 
68Sans ces trois choses, la mémoire devient superstition.
69 
70J'aime considérer la mémoire agentique comme un manuel et non comme un esprit magique. Il y a des notes temporaires, des décisions confirmées, des préférences de style, des contraintes techniques, des liens vers des sources. Certaines choses expirent. Certains doivent être réécrits. Certains doivent être éliminés parce que l’agent les a mal interprétés.
71 
72Un bon système doit rendre cet entretien normal. Pas héroïque.
73 
74## La récupération et les outils ne sont pas la même chose
75 
76Quand on parle de contexte, on aboutit souvent immédiatement sur RAG. Incorporation, base de données vectorielles, chunking, reclassement.
77 
78Tout cela est utile. Mais la récupération n'est qu'un moyen parmi d'autres d'apporter des informations au modèle. Il n'est pas le seul.
79 
80Un agent peut obtenir du contexte en lisant des fichiers, en interrogeant une API, en appelant un serveur MCP, en ouvrant un navigateur, en exécutant des tests, en recherchant dans Slack, en consultant un tableau de bord, en interrogeant l'humain.
81 
82La partie intéressante est de décider quel itinéraire utiliser et quand.
83 
84Si l’agent a besoin de répondre à une question historique, une simple récupération suffit peut-être. S'il doit corriger un bug, il doit lire le vrai code. S'il a besoin de comprendre pourquoi un déploiement échoue, il doit consulter de nouveaux journaux. Si vous devez écrire à un client, vous devez récupérer la tonalité, l'historique et le statut du ticket. S'il doit agir sur la production, il doit demander la permission.
85 
86Le contexte n'est pas une base de données. C'est un flux de travail.
87 
88## Le bon agent sait aussi ignorer
89 
90Un signe de maturité chez les agents sera la capacité de dire : je n'ai pas besoin de cette information.
91 
92Cela semble trivial, mais c'est très difficile. De nombreux systèmes agents s'accumulent. Chaque appel d'outil ajoute du texte. Chaque erreur reste dans le tampon. Chaque fichier lu s'ajoute à la pile. Au final le modèle a une très longue histoire et pas de carte.
93 
94Une compression est nécessaire. Une synthèse intermédiaire est nécessaire. Il faut qu’il soit structuré.
95 
96Non pas « c'est tout ce qui s'est passé », mais :
97 
98- objectif toujours valable ;
99- hypothèse actuelle ;
100- les fichiers déjà vérifiés ;
101- les décisions prises ;
102- risques ouverts ;
103- prochaine action.
104 
105Cela rend l’agent moins théâtral et plus utile. Non pas parce qu’il semble plus intelligent, mais parce qu’il travaille avec un bureau bien rangé.
106 
107## Ingénierie du contexte pour les équipes, pas pour les artistes prompts
108 
109La raison pour laquelle ce sujet m’intéresse est qu’il déplace la responsabilité de l’individu vers le système.
110 
111En ingénierie rapide, celui qui parle le mieux au modèle gagne souvent. En ingénierie de contexte, l'équipe qui organise le mieux son travail gagne : documentation, conventions, problèmes, journaux, tests, propriété, dénomination, sources.
112 
113Un référentiel propre devient un meilleur contexte. Un numéro bien écrit devient un meilleur carburant. Un runbook mis à jour évite les jetons et l'anxiété. Un journal des modifications clair réduit les hallucinations.
114 
115C’est une bonne nouvelle, mais quelque peu inconfortable. Beau car il récompense les bonnes pratiques. Inconvénient car vous ne pouvez pas tout résoudre avec une invite intelligente.
116 
117Les agents amplifient l’hygiène du système qu’ils trouvent.
118 
119## Comment je l'appliquerais demain
120 
121Si je devais introduire l’ingénierie de contexte dans un projet réel, je partirais de petites choses :
122 
123- un dossier d'instructions de projet court et tenu à jour ;
124- de bons exemples de résultats attendus ;
125- une liste des outils disponibles et des cas dans lesquels les utiliser ;
126- les décisions architecturales rédigées de manière citable ;
127- problème avec un contexte minimum obligatoire ;
128- facile à récupérer les journaux et les tests ;
129- mémoire persistante modifiable par les humains.
130 
131Ensuite, je mesurerais une chose simple : combien de fois l'agent doit-il demander des éclaircissements ou partir dans la mauvaise direction ?
132 
133Si cela arrive souvent, je n'ajouterais pas tout de suite un modèle plus grand. Je regarderais le contexte.
134 
135## Ma lecture
136 
137L’ingénierie de contexte est un mot un peu gonflé, oui. Mais le concept est solide.
138 
139Cela nous rappelle que l’intelligence d’un agent ne réside pas seulement dans le modèle. Cela réside dans l'environnement que nous lui préparons : ce qu'il voit, ce dont il se souvient, ce qu'il peut faire, ce qu'il lui est interdit de faire, quelles sources il reconnaît comme vraies.
140 
141La partie humaine est la suivante : bien préparer le contexte est une forme de soin. C'est dire à l'agent, mais aussi à l'équipe : "Je ne veux pas que vous deviniez, je veux que vous ayez ce dont vous avez besoin."
142 
143Moins de magie. Chambre plus propre. Les agents en ont autant besoin que nous.
144 
145##Sources
146 
147- [Blog LangChain : L'essor de l'ingénierie de contexte](https://blog.langchain.com/the-rise-of-context-engineering/)
148- [Simon Willison : Ingénierie du contexte](https://simonwillison.net/2025/Jun/27/context-engineering/)
149- [Protocole de contexte de modèle : Introduction](https://modelcontextprotocol.io/introduction)
150- [Anthropic : Créer des agents efficaces](https://www.anthropic.com/engineering/building-effective-agents)
151- [OpenAI : Nouveaux outils pour les agents de construction](https://openai.com/index/new-tools-for-building-agents/)
152