Context engineering

Le context engineering ne consiste pas à remplir la fenêtre de contexte. Il consiste à choisir, pour chaque étape, les informations qui augmentent réellement la probabilité d’obtenir le comportement attendu, puis à retirer ou résumer ce qui n’est plus utile. Le prompt n’est qu’une partie de cet ensemble : instructions système, outils, données externes, historique et état de travail consomment tous le même budget d’attention. [S1]

Pour un système comme OSIA, la décision de départ est simple : garder toujours présent un socle court de règles et de sources de vérité, préciser l’état du travail en cours, puis récupérer les preuves détaillées à la demande. Une mémoire persistante, un RAG ou une orchestration multi-agent ne deviennent nécessaires qu’après l’observation d’un échec reproductible que cette capacité peut corriger. [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]

Cinq couches de contexte pour OSIA

Le découpage suivant est une synthèse opérationnelle pour OSIA, pas une taxonomie universelle.

1. Invariants. Mission, autorité, limites, exigences de sécurité et définition de « terminé ». Cette couche reste toujours présente, courte et stable. [S1] [S2]
2. Portée projet. Architecture, conventions, commandes, sources de vérité et règles propres à un dossier. Cette couche est chargée selon le dépôt et le chemin concerné. [S3]
3. État de la tâche. Demande active, décisions acceptées, plan, fichiers touchés, résultats et blocages. Cette couche est mise à jour pendant le travail, puis archivée ou supprimée. [S1]
4. Preuves à la demande. Fichiers, documentation officielle, résultats d’outils, données métier et exemples pertinents. Ces éléments sont récupérés juste avant la décision qui en dépend. [S1] [S4]
5. État durable. Préférences stables, décisions transverses ou continuité entre sessions. Cette couche n’est persistée que si un besoin intersession est démontré. [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 précharger un corpus complet. Des chemins, identifiants ou liens légers peuvent guider l’agent vers le bon élément au moment utile ; cette divulgation progressive conserve davantage de signal dans la fenêtre active. [S1]

Ce qui est indispensable, facultatif ou inutile

Indispensable dès le départ

• Un contrat d’exécution court : objectif, sortie attendue, contraintes, autorité et condition d’arrêt. Des instructions vagues supposent un contexte partagé qui n’existe pas ; des instructions transformées en longue logique conditionnelle deviennent fragiles. [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 aux contrats non ambigus : chaque outil doit avoir un rôle distinct, des entrées compréhensibles et une sortie utile. Les catalogues qui se recouvrent 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 lorsqu’une tâche longue dépasse régulièrement la fenêtre utile ; elle doit préserver objectifs, décisions, faits critiques et questions ouvertes. Une compaction trop agressive peut perdre un détail qui ne deviendra important que 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]
• Un contexte proactif pour une information nécessaire à chaque invocation ; un outil convient mieux à une information coûteuse ou utile seulement dans certains cas. Le contexte proactif consomme des tokens à chaque passage et peut ajouter latence, obsolescence ou interactions inattendues. [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]

Inutile au démarrage d’OSIA

• 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 exclusions sont des décisions de simplicité pour OSIA. Elles suivent le principe d’un contexte à fort signal et d’une complexité ajoutée progressivement, mais elles devront être réévaluées si les mesures d’usage 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. Attribuer une couche et une durée de vie. Toujours présent, lié au chemin, état temporaire, récupéré à la demande ou durable : une information ne doit vivre dans plusieurs couches que si la duplication est explicitement 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. Définir le contrat des outils. Supprimer les chevauchements, borner les résultats volumineux et rendre visible la provenance 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 invariants 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 une heuristique et une sortie 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]

Décision applicable à OSIA

Commencer 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 corpus d’évaluation construit à partir des décisions qu’OSIA 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]