Lorsqu'un agent de code annonce qu'une tâche est terminée, qu'est-ce que l'organisation sait réellement ?

L'agent peut affirmer que les tests ont réussi, que ses modifications sont restées dans le périmètre autorisé et que la branche est prête à être intégrée. Son résumé peut être précis, cohérent, rassurant. Il n'en reste pas moins le récit produit par le système qui vient d'effectuer le travail.

C'est là que commence le sujet de gouvernance. La question n'est pas de savoir si un agent sait produire du code utile. Il le sait. La question est de distinguer une proposition utile d'un changement autorisé sans dépendre de la confiance que l'agent affiche, de sa mémoire de la session ou de son interprétation de ses propres actes.

J'applique une séparation simple : l'agent propose et agit ; des mécanismes déterministes établissent les faits ; un humain juge si le résultat peut être intégré et reste responsable de cette décision.

Je pratique ce modèle sur mes propres projets avec un dispositif d'orchestration construit pour laisser des agents travailler sans surveillance. Il a tourné ainsi pendant deux mois, avec un seul opérateur : moi. Ce n'est ni un déploiement en équipe ni un résultat client, mais une pratique individuelle qui révèle où la confiance ne suffit plus.

La confiance n'est pas le bon contrôle

Entre personnes, la confiance s'accompagne d'une responsabilité et de conséquences. Un agent ne répond pas d'une exception de risque et ne peut pas engager l'entreprise sur une mise en production. Un résumé convaincant ne le rend pas responsable.

Refuser cette confiance ne revient pas à considérer sa production comme inutile. Ce serait perdre la valeur de l'outil. La position utile est plus précise : laisser l'agent produire, mais lui retirer le pouvoir de certifier lui-même ce qu'il a produit.

Pour un agent observé par un ingénieur dans un seul dépôt, la boucle habituelle peut suffire : lire, contrôler, faire la revue de code, décider. Lorsque plusieurs agents avancent sans surveillance, l'assurance conversationnelle ne tient plus. Un message de fin reste un message, pas un garde-fou.

Chaque affirmation importante demande alors une réponse indépendante : une preuve liée au commit pour les tests, une comptabilité complète pour les commits, une clôture capable de refuser et, avant la mise en production, une décision humaine éclairée par le changement et ses preuves.

Donner une adresse à chaque preuve de validation

Un résultat de test sans adresse apporte peu. Quel état du dépôt a-t-il couvert ? L'arbre de travail était-il propre, ou des corrections non commitées ont-elles aidé les tests à réussir ? Le commit a-t-il été modifié après le contrôle ? Les commandes attendues ont-elles été exécutées avec la bonne chaîne d'outils ?

Dans mon dispositif, chaque validation produit un reçu. Il désigne le dépôt, la branche, le commit, le commit de départ et la phase. Il enregistre la propreté de l'arbre avant et après, les commandes, leurs codes de sortie et les journaux avec leur empreinte. Il dépend aussi d'un catalogue de commandes versionné et de la configuration réellement utilisée.

Un état initial vert ne prouve pas la branche après intégration. Le cycle distingue donc la référence saine avant le travail, le contrôle isolé de l'agent, le contrôle après chaque commit importé et le contrôle final de la branche complète.

L'agent ne peut pas transformer « j'ai lancé les tests » en « les tests sont valides ». Un garde exécute le plan et écrit le reçu ; un vérificateur le compare à la phase et au commit attendus. Le mauvais état est refusé, même si le fichier est bien formé. Quand le catalogue change, les anciens reçus expirent.

Les échecs restent dans le dossier. Si une intégration échoue puis qu'une correction réussit, les deux états demeurent visibles. Une histoire nettoyée, où rien ne semble avoir cassé, aide peu à comprendre l'exécution.

Ces reçus rendent les altérations visibles ; ils ne les rendent pas impossibles. Le superviseur et les agents utilisent le même compte dans le même conteneur. Le mécanisme couvre les erreurs, la dérive et les raccourcis accidentels, pas un processus malveillant doté du même accès. Ce risque demande une séparation de privilèges, des branches protégées, des commits signés et une revue humaine.

Ce n'est pas une faiblesse à masquer. C'est la limite du modèle de menace. Un bon dispositif de gouvernance dit précisément ce qu'un contrôle prouve et où cette preuve s'arrête.

La validation ne dit pas d'où vient le changement

Un reçu vert prouve qu'un état donné du dépôt a passé un plan défini. Il ne prouve ni l'origine de cet état ni la présence de tout le travail attendu.

Il faut pour cela une seconde trace : la comptabilité de provenance.

Au début, mon dispositif fige un commit de référence. À la clôture, chaque commit jusqu'à celui attesté par le reçu final doit avoir une explication, et une seule. Dans le cas nominal, le registre relie chaque commit d'agent à son import sur la branche d'intégration et au reçu incrémental correspondant.

« Exactement une fois » agit dans les deux sens. Un commit sans explication n'a pas d'origine identifiée ; deux explications peuvent en masquer un autre. Chaque commit de l'agent doit aussi être intégré ou remplacé par une correction équivalente. Une branche propre ne suffit pas si du travail a disparu pendant la reprise.

Les commits signés apportent une preuve d'identité et d'intégrité selon la politique de clés de l'organisation. Ils ne prouvent pas la justesse du code. La provenance établit l'origine et l'exhaustivité, pas la pertinence du changement. Les reçus établissent le résultat de contrôles reproductibles, pas la suffisance de ces contrôles. Ces mécanismes se renforcent justement parce qu'ils ne prétendent pas répondre à la même question.

Les exceptions restent possibles. L'opérateur peut enregistrer avec une justification une correction directe qu'il a relue, par une action réservée à un terminal. Une série en échec peut être remplacée, mais son équivalence doit être établie à partir des différences. L'exception existe sans devenir invisible.

Un résultat vert n'est pas une autorisation

Le contresens le plus dangereux serait de transformer de meilleures preuves en approbation automatique.

Dans ma pratique sans surveillance, la revue de code a trouvé quatre défauts après la réussite du formatage, de l'analyse statique, des tests unitaires, de la construction et des tests visuels : un contrôle exécuté deux fois, une analyse lancée dans le mauvais répertoire, un lien qui polluait un titre et une marque visuelle incomplète.

Les reçus étaient honnêtes. Les contrôles prévus avaient bien réussi sur les commits enregistrés. Ils ne vérifiaient simplement pas ces détails sémantiques.

La preuve produite par la machine et le jugement humain sont complémentaires. Les mécanismes déterministes disent quelles commandes ont tourné, sur quel état, avec quel résultat et d'où vient chaque commit. La revue humaine juge le comportement, la cohérence de la conception, le risque et l'opportunité d'intégrer.

La décision humaine vient donc après la chaîne de preuves ; elle ne se cache pas à l'intérieur. L'opérateur lit les changements, les reçus, la provenance et les éventuelles exceptions. La protection des branches et le pipeline appliquent ensuite les règles d'intégration et de mise en production de l'organisation. L'agent peut recommander une décision. Il ne peut ni la prendre au nom de l'organisation ni en porter la responsabilité.

Concevoir le refus comme un résultat normal

Un système de gouvernance se révèle moins dans le cas nominal que dans ce qu'il sait refuser.

Mon dispositif ne se ferme pas parce qu'un agent coordinateur annonce « terminé ». Du code déterministe relit le dépôt, vérifie le reçu final, la propreté de l'arbre et la provenance. Un commit inexpliqué, une intégration sans reçu valide, un commit abandonné ou une ressource encore active empêche la clôture.

Les corrections sont bornées. À l'épuisement du budget, l'exécution demande une intervention humaine. L'état survit aux interruptions : relancer l'agent n'efface ni les échecs, ni les commits intégrés, ni les tentatives déjà consommées.

Le but est d'empêcher qu'une ambiguïté dangereuse soit présentée comme une réussite. « Bloqué » et « aucun travail éligible » sont des issues valides. Préserver les éléments nécessaires à une décision humaine vaut mieux que fabriquer de la progression.

Mon dispositif ne pousse rien vers le dépôt distant. Il prépare un travail intégré et prouvé ; sa publication reste une décision distincte. Produire un changement et lui donner un effet dans l'organisation sont deux pouvoirs différents.

Les affirmations à ne jamais accepter sur parole

Pour un CTO ou une DSI, l'exercice applicable est direct : recenser les affirmations que le processus accepte aujourd'hui de l'agent qui a effectué le travail, puis remplacer chacune par une preuve indépendante ou par une décision humaine explicite.

  • « J'ai terminé la tâche. » Exigez un état propre enregistré dans des commits, une condition d'arrêt explicite, une clôture déterministe et une trace de ce qui reste bloqué ou non intégré.
  • « Les tests ont réussi. » Exigez un reçu lié au dépôt, à la branche, au commit, au commit de départ, à la phase, au catalogue de commandes versionné, à un arbre propre, aux codes de sortie et aux journaux conservés.
  • « Je suis resté dans mon périmètre. » Comparez mécaniquement les chemins modifiés avec la frontière d'écriture autorisée, puis faites examiner toute exception sémantique par un humain. Une consigne dans un prompt n'est pas une frontière.
  • « Voici tous les commits concernés. » Exigez une comptabilité de provenance où chaque commit de la plage d'intégration possède exactement une origine et où chaque commit d'agent est relié ou remplacé par un équivalent prouvé.
  • « Ma correction remplace le travail en échec. » Conservez la preuve de l'échec, établissez l'équivalence du remplacement, puis relancez la validation. La reprise ne doit pas réécrire l'histoire.
  • « La branche est prête à être intégrée. » Exigez une preuve incrémentale après chaque import, un reçu final pour la branche complète, le respect de la politique des commits et un dépôt propre. La recommandation de l'agent reste un commentaire.
  • « Le changement peut partir en production. » Exigez une revue de code, une décision d'intégration prise par un humain responsable, des branches protégées et le pipeline normal de mise en production. Aucun reçu ne transfère la responsabilité au modèle.
  • « Cette exception est sans risque. » Exigez l'approbation d'un humain nommé, au moyen d'un pouvoir que l'agent ne possède pas, avec une justification conservée dans le dossier.

Cette liste est plus utile qu'une politique générale d'« humain dans la boucle ». Elle précise où intervient l'humain, où intervient le code déterministe et quelles phrases ne restent que des affirmations de l'agent.

Adopter la propriété, pas mon dispositif

Je ne prescrirais pas cette mécanique à chaque dépôt. Pour un agent supervisé, la CI existante, un arbre propre, de petits commits et une revue attentive peuvent suffire.

Les contrôles supplémentaires deviennent utiles quand la surveillance disparaît : auteurs parallèles, exécution nocturne, intégration avant reconstitution de la session ou volume supérieur à ce que la revue informelle absorbe. Le seuil n'est pas l'usage de l'IA, mais l'impossibilité d'établir les faits en regardant.

Ces propriétés peuvent être obtenues autrement : reçus produits par la CI, exécutants séparés, file de fusion ou moteur de politiques. Le mécanisme dépend du contexte ; la règle de gouvernance reste portable.

Commencez par repérer les affirmations qui franchissent aujourd'hui votre frontière d'intégration sans preuve indépendante. Renforcez ces points avant d'ajouter davantage d'agents. Accélérer la génération sur une livraison invérifiable ne fait qu'augmenter la dette de revue.

L'idée à garder

Un agent IA peut proposer un changement et effectuer le travail. Il ne doit jamais devenir l'autorité qui certifie son propre résultat ou qui donne à ce résultat un effet dans l'organisation.

Utilisez des mécanismes déterministes pour établir les faits. Utilisez le jugement humain pour décider ce que ces faits autorisent. Gardez la responsabilité auprès de la personne qui intègre le changement.