Un agent de développement peut disposer d'un excellent modèle et produire malgré tout une modification médiocre. La cause n'est pas toujours le prompt. Elle se trouve souvent dans le contexte : conventions absentes, fichiers inutiles, objectifs ambigus, historique trop long ou outils mal décrits.
Le context engineering consiste à sélectionner, structurer et maintenir les informations utiles à chaque étape d'une tâche. Anthropic le décrit comme la recherche du plus petit ensemble de tokens à fort signal susceptible de produire le comportement attendu. Cette définition change la question : au lieu de demander « quel prompt magique écrire ? », on demande « quelles informations l'agent doit-il voir maintenant ? ».
Les cinq couches du contexte d'un agent de code
1. Les règles stables du dépôt
Les conventions qui s'appliquent à presque toutes les tâches doivent vivre dans le dépôt : architecture, commandes de test, limites de sécurité, style et définition du travail terminé. Un fichier AGENTS.md ou des instructions propres à un chemin évitent de répéter ces règles.
Une bonne instruction est courte et vérifiable :
- Exécuter les tests unitaires du module modifié.
- Ne pas modifier l'API publique sans test de compatibilité.
- Ne jamais écrire de secret dans le dépôt ou les journaux.
GitHub recommande également de séparer les instructions générales des règles propres à un langage ou un répertoire. Cette hiérarchie limite les consignes contradictoires.
2. Le contexte propre à la tâche
Une demande efficace indique le résultat attendu, les contraintes et les critères d'acceptation. Elle ne dicte pas nécessairement chaque ligne de code.
Avant de déléguer, renseignez :
- le comportement actuel et le comportement attendu ;
- les fichiers ou composants probablement concernés ;
- les cas limites connus ;
- les tests qui prouvent la réussite ;
- les éléments explicitement hors périmètre.
3. Le contexte récupéré à la demande
Charger tout un dépôt dans le contexte est rarement optimal. L'agent peut commencer avec des chemins, des symboles et des commandes de recherche, puis ouvrir les fichiers au moment où ils deviennent utiles. Cette récupération « juste à temps » conserve davantage d'attention pour le raisonnement.
4. L'état de travail
Pour les tâches longues, l'agent doit conserver une trace compacte : hypothèses confirmées, décisions, tests exécutés et problèmes restants. Une note structurée est plus utile qu'un historique complet de centaines de messages.
5. Les retours de l'environnement
Les résultats de tests, erreurs du compilateur et diffs sont du contexte. Ils doivent être bornés et lisibles. Préférez la sortie ciblée du test en échec à un journal de plusieurs milliers de lignes.
Une méthode en six étapes
- Définir un résultat observable.
- Fournir les règles stables du dépôt.
- Indiquer des points d'entrée, pas une copie du projet.
- Autoriser l'agent à rechercher le contexte manquant.
- Exiger une validation par tests, lint ou scénario reproductible.
- Résumer les décisions avant de poursuivre une tâche longue.
Les symptômes d'un mauvais contexte
Un agent qui modifie trop de fichiers, invente une API ou réexplique sans agir manque souvent de contraintes ou de points d'entrée. À l'inverse, un agent qui applique aveuglément une solution imposée reçoit peut-être trop de procédure et pas assez d'objectif.
Mesurez la qualité du contexte avec des signaux simples : nombre de fichiers inutilement ouverts, retours en arrière, tests échoués, corrections humaines et taille du diff final.
Context engineering et MCP
Le Model Context Protocol facilite l'accès aux outils et aux données, mais il ne décide pas ce qui est pertinent. Un catalogue de cinquante outils mal décrits augmente la confusion. Chaque outil doit avoir un nom explicite, une description courte, des paramètres bornés et des permissions minimales.
Le context engineering complète donc le prompt engineering pour développeurs : le prompt formule la mission, tandis que le contexte fournit les règles, les preuves et les moyens d'agir.
Checklist avant de lancer un agent
- L'objectif tient-il en une phrase testable ?
- Les commandes de validation sont-elles connues ?
- Les règles de sécurité figurent-elles dans le dépôt ?
- L'agent peut-il retrouver les fichiers sans tout charger ?
- Les outils ont-ils des permissions limitées ?
- Une personne sait-elle ce qui exige une validation humaine ?
quel element de contexte reduit le plus les erreurs de vos agents : conventions du depot, exemples, tests ou limites explicites ?
Publié dans la discussion