Pourquoi les agents de codage comme Claude Code ont besoin d’une couche de gouvernance, et non de meilleures instructions.

Des instructions plus précises permettent d’obtenir de meilleures réponses. Elles réduisent les malentendus, précisent les directives et donnent une direction claire à une session donnée, ce qui donne l’impression, pendant un temps, d’améliorer toute votre façon de travailler avec l’IA. Ce sentiment disparaît une fois que les agents font partie du travail quotidien. On cesse de demander une seule réponse convaincante à une requête isolée. On s’attend alors à ce que l’agent connaisse le projet, respecte les décisions déjà prises, choisisse la procédure appropriée, reste dans ses limites de compétence, utilise les outils adéquats et laisse des preuves vérifiables.

Une instruction façonne l’échange qui a lieu devant vous. Elle ne peut pas régir tout ce qui entoure cet échange.

Codex et Claude Code fournissent déjà de nombreuses fonctionnalités utiles. Ce qui manque, c’est un système complet et portable capable de déterminer quelles règles s’appliquent, quel contexte est pertinent, ce qu’un agent de codage peut faire, comment le travail est acheminé et ce qui constitue une preuve. Quelqu’un doit créer cette couche autour de l’environnement d’exécution. On l’appelle parfois un noyau : une couche de gouvernance que l’on contrôle, qui transmet le travail de l’intention humaine jusqu’à la preuve. Il ne contient aucun modèle et ne s’exécute pas de lui-même.

Concrètement, un tel noyau peut commencer par être un ensemble de fichiers Markdown structurés et portables : règles, protocoles, index, décisions acceptées, état du projet et politiques de mémoire. Lorsque les instructions écrites ne suffisent pas, des compétences, des scripts, des raccourcis et des points d’ancrage comblient les lacunes.

Le contexte n’était qu’un symptôme

Le premier problème visible est la perte de contexte. Une nouvelle session ne dispose souvent d’aucune information sur l’architecture, les changements récents ou les raisons sous-jacentes à une tâche, ce qui oblige à effectuer une nouvelle vérification avant de pouvoir reprendre un travail utile. Cette répétition fait perdre du temps, des ressources et de la patience.

Un plus grand contexte aide, mais il ne résout pas les problèmes plus profonds. Un agent peut toujours suivre la mauvaise procédure, agir avec plus d’autorité qu’il ne le devrait, intégrer des éléments irrelevants ou annoncer un succès sans preuve.

La solution évidente consiste à placer les règles manquantes ainsi que les informations de base dans AGENTS.md, CLAUDE.md ou un fichier de démarrage similaire. Cela est sensé, mais insuffisant. Ces fichiers améliorent réellement le processus d’intégration, mais attendre d’eux qu’ils gèrent l’ensemble du flux de travail est une erreur. Un fichier de démarrage peut définir des règles stables et indiquer des sources fiables. Il ne peut cependant pas, de lui-même, maintenir l’état du projet à jour, choisir le contexte approprié pour chaque tâche, décider de ce que l’agent est autorisé à faire ou vérifier le résultat.

Un principe reste au cœur de tout : définir ce que signifie « terminé » avant l’exécution, puis exiger des preuves à la fin.

Éliminer les répétitions n’a jamais été l’objectif principal. L’IA était passée d’une expérience occasionnelle à une dépendance quotidienne, et la question intéressante était de savoir quelle valeur un environnement conçu avec soin selon les principes classiques de la conception logicielle pouvait en tirer. L’IA était arrivée en même temps par plusieurs voies : dans les éditeurs, dans Xcode et VS Code, ainsi que dans des outils tels que Codex et Claude Code. Chacun d’eux facilitait l’appel à un modèle performant, mais une accessibilité accrue ne contribuait en rien à organiser ce qui se passait autour de cet appel.

Par un bon jour, un agent peut examiner du code, expliquer un framework inconnu, proposer une architecture ou aider à déployer une fonctionnalité, ce qui ressemble beaucoup à travailler en binôme avec un autre développeur. Plus on s’appuie sur cela, plus les questions environnantes deviennent importantes. Lorsque deux sources sont en désaccord, laquelle l’emporte ? Quelles règles s’appliquent à cette tâche ? L’agent peut-il décider ou seulement recommander ? S’il affirme que le travail est terminé, à quoi devrait-on s’attendre ?

Le contexte répond à la première partie de cette question, car il fournit à l’agent les connaissances pertinentes. Le reste concerne la manière dont ces connaissances sont utilisées. Le terme « gouvernance » convient bien à l’ensemble : il désigne le lien pratique entre l’intention, les connaissances fiables, les règles, l’autorité, l’exécution et la preuve. Il reste pratique lorsque les éléments importants d’un flux de travail sont suffisamment explicites pour être examinés, corrigés et réutilisés.

Pour un ingénieur qui aime concevoir des systèmes dont les composants coopèrent efficacement, laisser le flux de travail autour des agents se développer de manière improvisée semble gaspiller des ressources. Il s’agit alors d’un élément à concevoir, et non d’une série de conversations à superviser. Le faire correctement nécessite d’observer ses propres habitudes sur le long terme : ce que l’on vérifie avant de s’attaquer à un projet, quels schémas on réutilise, quand on ralentit et quels contrôles permettent réellement de s’assurer qu’une tâche est terminée. L’objectif est de transformer ces habitudes tacites en comportements que les agents peuvent suivre et que les personnes peuvent auditer.

Ce qu’un bootstrap peut et ne peut pas faire

Un développeur qui rejoint un projet déjà en place a besoin de plus que de talent. Il doit apprendre comment le code est organisé, quelles décisions ont été prises, ce qui a changé récemment et où se situent les limites. Sans cela, même un excellent recrutement passe des jours à redécouvrir l’environnement.

Les sessions des agents sont confrontées à une version compressée du même problème. Vous expliquez l’architecture, les objectifs, l’état actuel et les contraintes ; l’agent produit un bon travail, mais la session suivante nécessite que la majeure partie de cette information soit reconstruite.

Placer ce matériel dans un fichier AGENTS.md ou CLAUDE.md rend l’intégration bien moins coûteuse. Le terme « bootstrap » marque une limite et n’est pas une critique : un bon document définit le contrat opérationnel minimal et indique à l’agent où se trouvent les informations fiables. Codex gère des fichiers AGENTS.md en couches dont la taille totale est limitée, tandis que Claude Code propose des instructions de projet succinctes, les procédures peu fréquemment nécessaires étant regroupées dans des compétences. Tout cela est expliqué dans les documents des fournisseurs : le guide Claude Code memory et le guide Codex AGENTS.md. Une compétence regroupe une procédure reproductible afin qu’elle puisse être utilisée entre différents projets, et des hooks permettent d’imposer un comportement spécifique à chaque fois. Néanmoins, un autre élément doit décider quand chacun de ces mécanismes s’applique et comment leurs résultats sont vérifiés.

Les problèmes commencent lorsque l’on s’attend à ce qu’un seul fichier représente l’ensemble de l’espace de travail. Il ne peut être court tout en contenant à la fois chaque décision architecturale, le plan actuel, les rapports antérieurs, les protocoles et les détails des tâches. De plus, même si la fenêtre de contexte pouvait tout accueillir, y entasser tout au cours de chaque session entraînerait ses propres échecs : les instructions importantes se retrouveraient en concurrence avec du texte obsolète ou sans rapport. Corriger une erreur nécessite un contexte différent de celui requis pour examiner une architecture. Le déploiement suit une démarche différente d’une première réunion sur le produit, et une question rapide ne devrait pas entraîner les coûts de coordination liés à une fonctionnalité importante.

Ainsi, un outil de démarrage devrait offrir un accès au système sans chercher à en être lui-même l’ensemble.

De l’outil de démarrage à la carte

Dans cette conception, le bootstrap contient un petit contrat opérationnel et fait ensuite référence à des sources distinctes au fur et à mesure qu’elles deviennent pertinentes. Les décisions acceptées restent associées au projet. Les protocoles décrivent des types de tâches récurrentes, les compétences comportent des procédures reproductibles, les raccourcis compressent les demandes fréquentes et les plans actuels conservent l’état dont une autre session pourrait avoir besoin.

Rien d’intelligent ne se cache à l’intérieur du noyau. Sa valeur provient de la manière dont les fichiers sont séparés, liés, sélectionnés et maintenus au cours des différentes sessions et exécutions.

Cette séparation protège également le sens des informations. Une décision acceptée guide l’évolution d’un projet, un rapport d’état décrit un instant donné et un résultat de test enregistre des preuves. Si l’on mélange ces trois éléments dans une mémoire non différenciée, une ancienne observation commence à ressembler à une instruction actuelle.

Au fur et à mesure que la configuration se développe, elle couvre la politique de mémoire, la complexité des tâches, l’effort de réflexion nécessaire ainsi que le modèle à utiliser, les raccourcis, la continuité entre les sessions, ainsi que la validation et la coordination entre plusieurs agents. Une liste exhaustive cacherait l’architecture réelle. Ce qui importe, c’est que l’agent puisse les découvrir progressivement, en fonction des exigences du travail. Derrière cette structure se trouvent quatre responsabilités qui ne décrivent pas tous les mécanismes, mais expliquent pourquoi ils sont regroupés.

Certaines connaissances doivent survivre au chat

Chat fonctionne tant que la tâche est en cours, mais il ne doit pas constituer le registre officiel des décisions d’un projet. L’architecture acceptée, les contraintes et les choix de codage doivent figurer dans des sources gérées que toute session ultérieure peut consulter, et les plans en cours nécessitent leur propre état reprendable. Conserver une vérité fiable n’est pas identique à archiver chaque conversation, car la plupart d’entre elles ne sont que des éléments temporaires. Demandez plutôt ce qui doit encore être considéré comme officiel une fois la session terminée.

Chargement des éléments nécessaires à la tâche

Un agent a besoin de suffisamment d’informations pour comprendre sa tâche, et non de tout ce que le système a jamais stocké. Un petit changement de code peut nécessiter les règles du projet et quelques fichiers. Une fonctionnalité complexe peut également exiger la vision du produit, des décisions architecturales, des contributions de spécialistes et un plan de validation. L’objectif est un contexte suffisant au minimum, et non un contexte maximal disponible. La continuité signifie être capable de trouver le matériel adéquat au bon moment, et non de traîner toute l’histoire avec soi dans chaque tâche.

Trouver quelque chose n’est pas une autorisation

Localiser un fichier, un message ou une recommandation ne signifie pas pour autant qu’il est possible d’y agir. Le système doit séparer les informations des autorisations, surtout en ce qui concerne les actions destructrices, la validation finale, la publication et tout ce qui concerne le monde extérieur à l’espace de travail. Cette couche est moins visible que l’intelligence du modèle, mais elle est cruciale chaque fois qu’une erreur fatale coûte plus cher qu’un temps d’arrêt pour prendre une décision.

La finalisation nécessite une preuve

Être fluide ne signifie pas être correct, et être plausible ne signifie pas que le travail est terminé. Le noyau demande donc ce qui doit être vérifié, quelles preuves doivent être conservées et où l’état confirmé doit être consigné. Si un agent modifie du code et indique « terminé », vous n’avez reçu qu’une affirmation et rien de plus. La vérification peut consister en des tests réussis, une compilation réussie, le comportement observé dans l’application en cours d’exécution ainsi que l’état enregistré. D’autres domaines nécessitent des preuves différentes, mais la règle reste la même : la fin de la conversation ne signifie pas que le travail est achevé.

Une organisation en tant qu’analogie

Imaginez une entreprise disposant d’un bâtiment, d’ordinateurs et d’équipements de qualité, mais sans méthode de travail partagée. Elle a des capacités, mais n’est pas cohérente. Les gens ont encore besoin de connaissances communes, de procédures, de droits de décision, de responsabilités claires et de contrôles de qualité. La comparaison est approximative, car un agent n’est pas un employé et un environnement de exécution fait plus que simplement placer les personnes derrière des bureaux. Elle montre néanmoins comment les éléments sont liés : les agents occupent des rôles définis, les outils constituent l’équipement et l’environnement de exécution est le lieu où les actions sont mises en œuvre. Le noyau représente la couche partagée de règles, de connaissances, de méthodes et de contrôles qui permettent leur coopération. De meilleurs modèles ne garantissent pas automatiquement un meilleur système.

Où se situe cette couche

Le noyau ne concurrence pas Codex, Claude Code, Gemini ou tout autre environnement d’exécution qui pourrait apparaître par la suite. Ceux-ci fournissent l’environnement en temps réel : des modèles, des outils, des sessions, des paramètres de raisonnement ainsi qu’un ensemble croissant de leurs propres sous-agents, de connecteurs et de compétences. La couche de gouvernance fonctionne autour de cet environnement et règle trois points essentiels, à savoir ce qui doit être conservé, ce que l’agent est autorisé à faire et quels éléments constituent une preuve de l’action accomplie.

La valeur de cette séparation augmente à chaque fois qu’un environnement de exécution intègre une fonctionnalité similaire à celles déjà développées manuellement. Réécrire chaque capacité de l’environnement de exécution reviendrait à gaspiller du temps qui pourrait être utilisé pour les projets que gèrent les agents. Permettre aux environnements de exécution de gérer l’exécution tandis que la couche de gouvernance reste portable est la solution la plus durable. Les fournisseurs diffèrent en termes de modèles, d’outils, d’interfaces et de style de sortie, et la portabilité permet à vos règles de rester indépendantes de l’un d’eux sans prétendre que ces différences ont disparu.

La gouvernance ne garantit pas la certitude

Rédiger une règle ne garantit pas qu’un agent la lira, la comprendra ou l’appliquera au bon moment. Un mécanisme de démarrage peut indiquer le bon protocole sans pour autant être pris en compte. Une décision canonique peut être parfaitement conservée tandis que son contenu devient progressivement obsolète. Un mécanisme de liaison peut faire respecter une règle fidèlement longtemps après que celle-ci a cessé d’être utile.

L’expérience montre que cela se produit rapidement. Les règles ajoutées pour les arbres de travail et les crochets commencent à se chevaucher, à entrer en conflit et à bloquer les tâches qu’elles étaient censées protéger, ce qui oblige à les simplifier et à les corriger. La gouvernance nécessite des maintenances, et les coûts ne s’arrêtent pas là : les interfaces et les index consomment du temps et des ressources, et peuvent encore ne pas refléter l’état le plus récent ; les agents ignorent parfois les instructions à mesure que le système se développe, et il est difficile de reconstruire la confiance lorsque un flux de travail affirme un succès sans la preuve attendue.

Un système de ce type n’est jamais achevé ni universel. Il s’agit d’une configuration personnelle qui est testée, défectueuse, puis corrigée au fil des mois. Elle améliore votre capacité à surveiller et à ajuster le comportement des agents, mais aucune règle, protocole, raccourci ou mécanisme de mémorisation n’est suivi à la perfection. La gouvernance peut faciliter l’inspection et la correction du comportement, mais elle ne peut pas rendre un agent probabiliste déterministe.

Trois questions à se poser en premier

La perte de contexte est ce qui pousse les gens sur cette voie. Ce qui les y retient est une question d’ingénierie plus importante : comment concevoir le parcours autour d’un modèle performant, en accordant autant d’attention à cette architecture qu’à toute autre architecture importante ?

Alors, pouvez-vous prouver que le travail est terminé ? Seulement lorsque le critère de « finition » a été défini avant l’exécution et que le résultat présente des éléments concrets correspondant à la tâche. Sans cela, ce que vous avez n’est qu’une affirmation, et une affirmation n’est pas une preuve.

Vous n’avez pas besoin d’un système comme celui-ci pour commencer à penser de cette manière. Avant d’ajouter un autre prompt ou un fichier, demandez-vous :

1. Quelles sources sont autorisées à définir ce qui est vrai ?
2. Quelles décisions et actions nécessitent une autorité humaine ?
3. Quelles preuves montreront que le travail est terminé ?

Ces questions transforment les fonctionnalités distinctes de l’IA en éléments d’un flux de travail fiable, plutôt que en capacités qui coexistent simplement. Chaque petite demande ne devrait pas entraîner l’ensemble du système. Les contrôles doivent être adaptés en fonction des conséquences : plus souples lorsque le risque est faible, plus stricts lorsque une erreur pourrait avoir de lourdes répercussions. Les modèles fournissent les capacités nécessaires, tandis que le parcours structuré allant de l’intention à la preuve est ce que l’on construit autour d’eux.