Context as code : transformer les consignes d’un agent en actif logiciel maintenable

Un agent de code peut produire une sortie plausible tout en travaillant avec une information incomplète, dépassée ou difficile à vérifier. Le problème ne vient alors pas uniquement du modèle. Il vient du contexte qui lui est fourni : règles du dépôt, contraintes de sécurité, connaissances d’équipe, outils disponibles et critères d’évaluation.

Dans la présentation Context Is the New Code, publiée par InfoQ le 30 septembre 2026, Patrick Debois défend une idée opérationnelle : gérer le contexte avec des pratiques empruntées au génie logiciel. Tester, versionner, distribuer, observer et analyser les risques deviennent des activités aussi importantes que la rédaction initiale des instructions.

Il ne s’agit pas d’affirmer qu’un agent devient fiable par la seule présence d’un fichier de consignes. L’enjeu est plus précis : rendre le contexte relisible et maintenable lorsque plusieurs développeurs, dépôts et agents doivent l’utiliser.

Le problème : une connaissance utile mais sans cycle de vie

Une règle donnée à un agent peut commencer dans un prompt individuel, être copiée dans un fichier du dépôt, puis être modifiée au fil des urgences. Après quelques itérations, personne ne sait forcément quelle version fait autorité, quelle équipe l’a validée ni dans quelles tâches elle doit s’appliquer.

Cette situation crée trois risques. Une instruction peut contredire une convention plus récente. Une connaissance interne peut être distribuée trop largement. Une sortie non déterministe peut sembler acceptable dans une tâche et devenir problématique dans une autre. Le contexte devient alors une dépendance implicite, sans propriétaire ni preuve de qualité.

Le rapprochement avec le code ne signifie pas que le contexte serait parfaitement déterministe. Il fournit plutôt un cadre de travail : chaque élément doit avoir un périmètre, une version, une règle de validation et une manière d’être retiré.

Ce que signifie traiter le contexte comme du code

Un contexte exploitable peut être décomposé en artefacts différents : instructions stables, règles propres à une tâche, documentation récupérée à la demande, définitions d’outils et critères de contrôle. Les regrouper dans un seul prompt rend leur maintenance difficile. Les séparer permet de savoir ce qui change, pourquoi cela change et qui doit relire la modification.

Une chaîne de traitement en cinq étapes

La première étape consiste à inventorier le contexte réellement utilisé. Il faut relever les fichiers d’instructions, les modèles de tickets, les documents consultés, les outils appelables et les règles ajoutées directement dans les interfaces. Cet inventaire ne mesure pas encore la qualité ; il rend visible la surface de dépendance.

Ensuite, chaque élément doit recevoir un propriétaire et un périmètre. Une règle de style de code n’a pas nécessairement sa place dans un workflow de migration. Une consigne de sécurité qui concerne un dépôt sensible ne doit pas être distribuée comme une préférence générale. Cette séparation réduit le risque de transmettre trop d’informations ou d’autoriser une action hors contexte.

La troisième étape est la version. Un changement de contexte mérite un diff, une justification et une possibilité de retour arrière. Dans cette logique, une modification de prompt ou de document de référence ne devrait pas être traitée comme une retouche invisible si elle peut modifier le comportement d’un agent.

Vient ensuite l’évaluation. Il faut construire quelques cas représentatifs et vérifier des propriétés observables : respect d’une contrainte, format attendu, présence d’un contrôle, refus d’une action interdite ou capacité à demander une précision. Ces vérifications ne prouvent pas qu’un agent sera fiable dans toutes les situations ; elles rendent certaines dérives détectables.

Enfin, le contexte doit être distribué et observé. Les équipes doivent savoir quelle version est utilisée, par quel workflow et avec quels outils. La présentation de Patrick Debois relie cette étape aux pratiques de distribution, de gestion de paquets et d’observabilité : l’objectif est de pouvoir faire évoluer le contexte sans perdre la maîtrise de sa provenance.

Ce que les tests peuvent réellement vérifier

Tester un contexte ne revient pas à chercher une réponse unique. Une sortie peut être formulée différemment tout en respectant le contrat. Les assertions doivent donc porter sur des propriétés utiles au workflow : une action est-elle autorisée, une information obligatoire est-elle présente, le résultat reste-t-il dans le périmètre demandé, l’agent signale-t-il une ambiguïté ?

Un jeu de tests minimal peut associer une tâche normale, une tâche incomplète, une instruction contradictoire et une demande dépassant les permissions prévues. Les résultats doivent être relus avec prudence. Un test qui passe ne transforme pas une sortie non déterministe en garantie absolue ; il fournit un signal comparable avant et après une modification.

Cette démarche complète les ressources déjà disponibles sur le choix des canaux de contexte pour un agent de code : elle s’intéresse moins à l’emplacement idéal d’une information qu’à son cycle de vie après intégration.

Distribuer sans perdre le contrôle

La distribution est le point où une bonne pratique d’équipe peut devenir une dépendance difficile à gouverner. Avant de partager un paquet de contexte, il faut distinguer les règles générales, les informations internes, les secrets et les capacités d’action. Un document utile à la navigation dans un dépôt n’a pas besoin de contenir des identifiants, des chemins sensibles ou des instructions d’exploitation.

Le contrôle de sécurité doit aussi porter sur les outils décrits par le contexte. Une consigne qui demande à l’agent de consulter un système externe ne définit pas, à elle seule, une permission légitime. L’autorisation doit rester appliquée par l’environnement d’exécution, avec des droits limités et une validation humaine pour les effets irréversibles.

La présentation source évoque également l’analyse de sécurité du contexte. Dans la pratique, cela peut conduire à rechercher des secrets, des permissions excessives, des instructions ambiguës ou des références devenues obsolètes avant de distribuer une nouvelle version.

Le contexte devient une mémoire organisationnelle

Le bénéfice le plus durable n’est pas seulement d’obtenir de meilleures réponses à court terme. Un contexte versionné conserve des décisions d’équipe : conventions, limites connues, critères de revue et raisons d’un refus. Il devient une forme de connaissance organisationnelle qui peut être relue et corrigée, au lieu de rester attachée à la mémoire d’un développeur.

Cette mémoire doit toutefois rester sélective. Tout document ne mérite pas d’être injecté dans un workflow agentique. Une règle utile doit être compréhensible, attribuée, testable lorsque c’est possible et supprimable lorsqu’elle ne correspond plus au système.

Checklist avant de déclarer un contexte prêt

• Le périmètre du contexte est-il explicite ?
• Chaque règle importante a-t-elle un propriétaire ?
• La version utilisée peut-elle être identifiée ?
• Des cas normaux, ambigus et interdits ont-ils été prévus ?
• Les critères portent-ils sur le comportement attendu plutôt que sur le style de réponse ?
• Les outils et permissions sont-ils contrôlés séparément des instructions ?
• Les informations sensibles sont-elles exclues ou minimisées ?
• Existe-t-il une procédure pour corriger, retirer ou désactiver ce contexte ?

Le principe « context as code » ne promet donc pas de supprimer l’incertitude des agents. Il propose de déplacer le contexte dans un cycle de travail où les changements sont visibles, discutables et réversibles. Pour une équipe de développement, c’est une manière concrète de transformer une consigne isolée en composant maintenu du système.

Cette approche peut être rapprochée d’une suite de tests de régression pour les prompts IA : dans les deux cas, le but n’est pas de figer les réponses, mais de détecter les propriétés qui cessent d’être respectées.