Autonomie méritée : gouverner les agents de code IA tout au long du cycle de développement

Qu’est-ce que l’autonomie méritée pour un agent de code IA ?

L’idée tient en une phrase : un agent mérite son autonomie là où des contrôles automatisés peuvent prouver son travail, et la perd là où ils ne le peuvent pas. L’autonomie n’est pas un réglage choisi une fois pour toutes. C’est un statut que l’agent détient pour un type de travail donné, et ce sont les preuves qui décident s’il le garde.

Pourquoi un réglage unique est-il une mauvaise approche ?

La plupart des équipes choisissent une position unique. Soit un humain relit tout, ce qui ne résiste pas au volume qu’un agent peut produire, soit l’agent est cru partout, ce qui fonctionne jusqu’au premier changement que personne n’a compris et qui atteint la production.

Une retouche de documentation et un changement sur le stockage de données personnelles ne portent pas le même risque, et un module bien testé n’offre pas le même filet de sécurité qu’un domaine tout neuf. Le cadre agentic-sdlc, un cadre de travail que je maintiens, règle l’autonomie par étape et par niveau de risque, et relie chaque niveau aux preuves nécessaires pour l’accorder. Il repose sur trois engagements :

• La responsabilité reste humaine : une personne nommée porte l’intention, l’architecture et chaque décision de mise en production.
• L’autonomie est accordée sur preuves : plus d’autonomie demande plus de vérification automatisée, pas plus d’optimisme.
• Chaque étape laisse un artefact : ce qui n’est pas écrit, testé ou enregistré n’a pas eu lieu.

Quels sont les niveaux d’autonomie, et que garde l’humain ?

Le cadre définit quatre niveaux, de L0 à L3. Le tableau ci-dessous suit ses propres définitions. L’autonomie se règle par étape, ne dépasse jamais L1 sur des données ou des actions irréversibles, et baisse d’un niveau après tout incident.

Comment le cadre structure-t-il la responsabilité sur tout le cycle de vie ?

Les niveaux disent ce que l’agent peut faire. Les contrats d’étape disent ce qui doit exister avant d’avancer. Chacune des huit étapes a un critère de sortie et une preuve : la responsabilité est donc rattachée à un artefact plutôt qu’à une conversation.

• Intention : problème, utilisateurs, critères d’acceptation testables et non-objectifs, consignés dans un SPEC.md.
• Architecture : frontières, flux de données, risques et décisions, consignés dans des fiches de décision.
• Construction par l’agent : un petit changement conforme à la spécification, avec ses tests, livré sous forme de pull request.
• Revue humaine : le diff est compris, la sécurité et le traitement des données sont vérifiés avec une liste de contrôle.
• Vérification : tests, évaluations et contrôles de non-régression réussis, attestés par la CI et un rapport d’évaluation.
• Point de contrôle de mise en production : critères remplis, limites documentées et retour arrière connu, dans une fiche de release.
• Déploiement : une version versionnée et reproductible, attestée par le journal du pipeline.
• Mesure : usage, qualité, coût et incidents enregistrés, avec des retours d’expérience.

Comment la fonction Engineering de NOVA applique-t-elle ce cadre ?

NOVA est mon agent produit personnel, un dépôt public en bêta sans licence, utilisé par 800 collaborateurs chez Devoteam. Sa fonction Engineering prend une intention ou une issue GitHub et la transforme en spécification, conception, code, tests, pull request, revue, réparations de CI et fusion, derrière des points d’approbation.

Elle propose deux modes. En mode Guidé, un humain valide le plan et la fusion. En mode Autopilot, NOVA va seul jusqu’à la fusion. En termes d’autonomie méritée, c’est la différence entre garder l’humain à deux points de décision et le retirer. Ma lecture personnelle : l’Autopilot devrait être une promotion qu’un projet a méritée, pas un réglage par défaut, et la règle du cadre sur les données et actions irréversibles s’y applique pleinement.

Le README du cadre place NOVA aux étapes 1 à 4, pour orchestrer plans, approbations et livrables. Il s’appuie sur ORBIT pour un contexte gouverné, sur FORGE pour l’évaluation aux étapes 5 et 6, et sur TrustRail pour contrôler ce que les agents peuvent faire. NOVA, ORBIT, FORGE et TrustRail sont des bêtas publiques, et je ne revendique aucune validation en production.

Que faut-il mesurer avant d’augmenter l’autonomie ?

La preuve est la monnaie, donc décidez de ce qui compte avant de promouvoir quoi que ce soit. Le cadre suggère un cycle court : fixer un niveau de départ par étape, L1 par défaut, travailler deux semaines, mesurer, puis promouvoir ou rétrograder une étape. Ses métriques sont définies dans le dépôt et marquées non encore mesurées tant qu’elles ne le sont pas, et je garde cette mention.

Au-delà, les vérifications suivantes sont mes propres suggestions, pas des exigences du cadre. Je n’augmenterais pas un niveau sans réponse à ces questions :

• À quelle fréquence la revue a trouvé un problème que les contrôles automatisés avaient manqué, car cet écart est la vraie limite de l’autonomie.
• Si les tests vérifient un comportement ou seulement l’arithmétique du code, puisqu’un agent peut écrire des tests qui passent sans rien prouver.
• Si la pile réelle a été exécutée de bout en bout, pas seulement les tests unitaires.
• Quelle était la taille de chaque changement, et si les relecteurs pouvaient encore le comprendre.
• Ce qu’un incident a coûté et si le niveau a bien baissé quand il le fallait.

Quels modes d’échec faut-il anticiper ?

Le cadre recense des risques propres aux agents en plus des risques classiques : dérive du périmètre, tests écrits pour passer, dépendances inventées, secrets divulgués, coûts qui s’emballent, volume non relu et dégradation du contexte. Trois d’entre eux sont, selon mon expérience, ceux qui font échouer la gouvernance en silence.

• La fatigue de relecture : quand l’agent produit plus de diffs que les gens ne peuvent en lire, la revue devient un clic. Le remède est de réduire la taille des changements et le niveau, pas d’allonger la liste de contrôle.
• La production d’agent sans propriétaire : du code dont personne n’a accepté la responsabilité. Le premier engagement y répond, car une personne nommée porte chaque décision de mise en production.
• La dérive silencieuse du périmètre : l’agent fait un peu plus que la spécification, et personne ne le voit puisque les tests passent. Une spécification écrite avec des non-objectifs est le contrôle.

Est-ce open source, et le cadre a-t-il été validé ?

agentic-sdlc est un cadre de travail en version 0.1, sous licence MIT. C’est le seul de mes projets que je qualifie d’open source. Il est issu de la construction de NOVA, ORBIT, FORGE, TrustRail et de plusieurs prototypes, et son README précise qu’il n’a pas été validé par une étude indépendante.

Ses études de cas sont des brouillons reconstruits à partir d’historiques de commits publics. L’un des constats est que les défauts les plus coûteux ont été trouvés en exécutant le système réel, pas grâce à la suite de tests. C’est une raison de traiter les niveaux et seuils du cadre comme des jugements à adapter à votre propre risque.