Context engineering

Un agent IA ne travaille qu’avec les informations disponibles au moment où il répond ou agit. Si des règles importantes manquent, il doit les deviner. Si trop de documents sont chargés en même temps, les éléments utiles peuvent se perdre dans le bruit.

Le context engineering, ou ingénierie du contexte, organise ces informations. Il choisit les consignes, les outils, les documents, l’historique et l’état du travail utiles à chaque étape. Le prompt fait partie de cet ensemble, mais il n’en est qu’un élément. [S1]

Le principe de départ est simple : garder toujours présentes les règles indispensables, décrire clairement le travail en cours et récupérer les détails seulement lorsqu’ils deviennent utiles. Une mémoire durable, un RAG ou plusieurs agents ne sont ajoutés que lorsqu’un problème observé montre qu’ils sont nécessaires. [S1] [S2]

Le résultat à obtenir

Un bon système de contexte permet à l’agent de répondre correctement à cinq questions avant d’agir :

1. Quel résultat faut-il atteindre ? L’objectif, le livrable et la condition d’arrêt sont explicites.
2. Quelles limites s’appliquent ? L’autorité, les actions interdites, les validations humaines et les contraintes de sécurité sont connues.
3. Quelles informations font foi ? Le projet désigne ses fichiers, règles, documents et données canoniques.
4. Quel est l’état actuel ? L’agent connaît la tâche active, les décisions déjà prises, les changements effectués et les preuves encore attendues.
5. Comment vérifier ? Des critères observables et des cas représentatifs permettent de distinguer un résultat fiable d’un résultat seulement plausible.

Les instructions et garde-fous sont un composant fondamental d’un agent ; les évaluations doivent être spécifiques à la tâche, commencer tôt et être enrichies avec les échecs réels. [S2] [S5]

Un modèle simple en cinq couches

Le découpage suivant est une proposition pratique, pas une classification universelle.

1. Règles stables. Mission, autorité, limites, sécurité et définition de « terminé ». Elles restent toujours présentes, courtes et stables. [S1] [S2]
2. Contexte du projet. Architecture, conventions, commandes et sources de vérité propres au projet ou au dossier concerné. [S3]
3. État de la tâche. Demande active, décisions prises, travail restant, fichiers modifiés, résultats et blocages. Ces informations évoluent pendant le travail. [S1]
4. Informations à la demande. Fichiers, documentation officielle, résultats d’outils, données métier et exemples. L’agent les récupère juste avant la décision qui en dépend. [S1] [S4]
5. Mémoire durable. Préférences ou décisions qui doivent rester disponibles entre plusieurs sessions. Cette mémoire n’est créée que si le besoin est réel. [S1] [S4]

Les règles globales et locales ne doivent pas être recopiées partout. Des instructions liées à un chemin permettent de n’ajouter une règle que lorsqu’un sous-système diverge ; GitHub documente notamment des instructions globales, des instructions ciblées par chemin et des fichiers AGENTS.md où le plus proche prévaut. [S3]

La récupération à la demande évite de charger tout un corpus avant de savoir ce qui sera utile. Des chemins, des identifiants ou des liens peuvent guider l’agent vers le bon élément au bon moment. [S1]

Ce qu’il faut prévoir

Indispensable dès le départ

• Une consigne de départ claire : objectif, résultat attendu, contraintes, autorité et condition d’arrêt. Une consigne vague oblige l’agent à deviner. Une longue suite d’exceptions devient difficile à maintenir. [S1] [S2]
• Une hiérarchie des sources de vérité : indiquer quel document prévaut en cas de conflit et éviter de dupliquer une même décision dans plusieurs fichiers. [S3]
• Un état de tâche explicite : conserver les décisions déjà prises, les travaux restants et les preuves obtenues sans injecter toute la conversation. [S1]
• Un petit ensemble d’outils bien différenciés : chaque outil possède un rôle distinct, des entrées compréhensibles et une sortie utile. Des outils qui font presque la même chose multiplient les mauvais choix. [S1] [S2]
• Une récupération de preuves fraîches : charger le fichier, la donnée ou la source officielle dont dépend la décision au moment de l’utiliser, puis traiter son contenu comme une donnée et non comme une nouvelle autorité. [S1] [S4]
• Des évaluations représentatives : tester les cas normaux, limites et adverses, automatiser ce qui peut l’être et conserver une revue humaine pour vérifier que les bons critères sont mesurés. [S5]

Facultatif, avec un déclencheur précis

• Des exemples canoniques lorsque les mêmes erreurs d’interprétation réapparaissent. Quelques exemples diversifiés sont préférables à une liste exhaustive de cas particuliers. [S1]
• Des règles locales lorsqu’un dossier possède réellement d’autres commandes, contraintes ou conventions que le socle du projet. [S3]
• La compaction, c’est-à-dire le résumé d’un historique devenu trop long. Elle doit préserver les objectifs, les décisions, les faits critiques et les questions ouvertes. Un résumé trop agressif peut supprimer un détail qui deviendra important plus tard. [S1]
• Une mémoire durable lorsqu’une information doit survivre entre plusieurs sessions et ne peut pas être retrouvée de façon fiable dans une source canonique. Sa portée, son propriétaire, sa durée de vie et son mode de correction doivent alors être définis. [S1] [S4]
• Une information chargée à l’avance lorsqu’elle est nécessaire à chaque demande. Un outil convient mieux à une information volumineuse ou utile seulement dans certains cas. Tout contenu chargé d’avance occupe de l’espace et peut devenir périmé. [S4]
• Un RAG lorsque le corpus est trop vaste pour une navigation directe, que les requêtes sont récurrentes et qu’une évaluation démontre que la récupération améliore précision et rappel. [S4] [S5]

À éviter sans besoin démontré

• recopier des documents entiers dans les instructions « au cas où » ;
• conserver sans limite l’historique et tous les résultats d’outils ;
• créer un fichier de mémoire générique sans information intersession identifiée ;
• ajouter SQL, une base vectorielle ou un pipeline RAG avant d’avoir mesuré un échec de récupération ;
• répartir le travail entre plusieurs agents avant qu’un agent unique, correctement outillé et évalué, ait montré une limite ;
• accumuler des règles pour des cas jamais observés ou plusieurs outils qui réalisent la même action.

Ces choix évitent d’ajouter de la complexité avant d’avoir observé le problème qu’elle doit résoudre. Ils doivent être réévalués si les usages ou les mesures changent. [S1] [S2]

Méthode de conception

1. Partir d’une décision réelle. Décrire le résultat utile, les erreurs coûteuses et la personne autorisée à trancher. [S2] [S5]
2. Écrire les cas de vérification avant l’architecture. Conserver quelques demandes normales, limites et adverses avec leurs critères de réussite ; éviter une validation fondée sur l’impression générale. [S5]
3. Inventorier les informations disponibles. Pour chacune, noter sa source, son propriétaire, sa fraîcheur, sa sensibilité et la décision qu’elle influence. [S4]
4. Choisir où l’information doit vivre et combien de temps. Toujours présente, liée à un dossier, temporaire, récupérée à la demande ou durable : une information ne doit être copiée à plusieurs endroits que si cette duplication est contrôlée. [S1] [S3] [S4]
5. Choisir le mécanisme le plus simple. Une règle courte avant une règle locale ; un chemin avant une copie ; une lecture ciblée avant un index ; une recherche déterministe avant un RAG ; un agent unique avant plusieurs agents. [S1] [S2] [S4]
6. Clarifier le rôle des outils. Supprimer les chevauchements, limiter les résultats trop volumineux et rendre visible la source des données. [S1] [S2]
7. Tester l’ensemble composé. Les instructions, fournisseurs de contexte et outils peuvent être corrects séparément mais se contredire une fois réunis. [S4]
8. Mesurer puis élaguer. Journaliser les échecs utiles à l’évaluation, corriger la couche responsable et retirer les règles ou exemples qui ne changent aucun résultat. [S5]

Échecs fréquents et contre-mesures

• Contexte exhaustif. Signe : réponses moins précises, lenteur ou éléments importants noyés. Contre-mesure : garder les règles stables et récupérer le détail juste à temps. [S1]
• Règle trop vague. Signe : l’agent invente des conventions ou suppose une autorité. Contre-mesure : ajouter un critère de décision et un résultat vérifiable, sans écrire un programme en prose. [S1]
• Règle trop rigide. Signe : toute exception impose une nouvelle branche. Contre-mesure : revenir au résultat attendu, aux limites et à quelques exemples canoniques. [S1]
• Instructions contradictoires. Signe : deux fichiers donnent des commandes ou priorités différentes. Contre-mesure : désigner une source canonique et une règle de portée explicite. [S3]
• Outils qui se recouvrent. Signe : choix aléatoire, appels inutiles ou résultats incompatibles. Contre-mesure : conserver le plus petit ensemble différencié et clarifier chaque contrat. [S1] [S2]
• Contexte périmé. Signe : une ancienne décision continue d’orienter l’action. Contre-mesure : associer propriétaire, date de revue et stratégie de rafraîchissement. [S4]
• Mémoire ou RAG sans signal. Signe : une infrastructure doit être maintenue sans gain mesuré. Contre-mesure : revenir aux cas d’évaluation et exiger une amélioration observable. [S5]
• Validation au ressenti. Signe : une démonstration réussit mais les cas réels régressent. Contre-mesure : utiliser des évaluations ciblées et les calibrer avec le jugement humain. [S5]

Par où commencer ?

Commencez avec :

1. un fichier racine court qui définit mission, autorité, contraintes, sources de vérité, commandes et validations [S1] [S2] ;
2. des règles locales uniquement pour les dossiers qui divergent réellement [S3] ;
3. un état de tâche distinct qui conserve décisions, progression et preuves actuelles [S1] ;
4. des outils capables de lire les fichiers du projet et les sources officielles au moment du besoin [S1] [S4] ;
5. un petit jeu de tests construit à partir des décisions que le système doit soutenir [S5].

Ne créer une mémoire persistante que si une information utile se perd entre sessions malgré des sources canoniques accessibles. Ne créer un RAG ou une base vectorielle que si le volume du corpus et les tests de recherche montrent une limite répétée. Ne passer au multi-agent que si la séparation des responsabilités apporte un gain mesurable face à un agent unique. Jusqu’à l’apparition de ces signaux, ces composants ajoutent du contexte, des conflits et de la maintenance sans améliorer la décision. [S1] [S2] [S4] [S5]