🧾 Code produit par des agents : comment en établir la provenance ? (7/10)

Lorsqu’un agent écrit une modification, qu’un autre la vérifie et qu’un troisième la déploie, le nom figurant dans l’historique du dépôt ne suffit plus à expliquer d’où vient le code. Pour répondre sérieusement à un audit, il faut pouvoir établir quel processus a produit la modification, à partir de quelles données, selon quelles règles, avec quelle autorisation et quelles preuves.

Ce texte est le septième volet de la série « AI Governance in an AI-Native Software Development Company ». Le sixième article, consacré au confinement, expliquait comment arrêter un agent, mesurer les effets de ses actions et remettre le système dans un état connu. Ici, il s’agit de pouvoir reconstituer les faits après l’événement. Une politique appliquée dont on ne peut retrouver la trace reste une affirmation ; une intervention de confinement impossible à documenter reste un récit.

Dans une chaîne de développement où interviennent des agents, identifier un compte n’équivaut pas à établir la paternité du travail. Il faut suivre toute la chaîne.

La signature d’un commit ne raconte plus toute l’histoire

Le fonctionnement classique se prêtait à une réponse simple : un développeur effectuait un commit, son identité était signée, puis on pouvait l’interroger sur sa décision. Avec des agents, la succession des acteurs se complique. Une personne exprime une intention ; un agent consulte plusieurs sources, appelle un modèle, produit du code, lance des vérifications et recommence éventuellement. Un autre agent confronte le résultat aux règles applicables ; un troisième le met en production ; un quatrième observe le déploiement et choisit de ne pas revenir en arrière.

L’audit doit donc retrouver l’intention initiale, les données consultées, le modèle et sa version, le prompt et la compétence active, les outils appelés et leurs arguments, l’ensemble de règles ayant rendu un verdict, les preuves générées à chaque étape, la portée de l’autorisation humaine et les conséquences observées en aval. Il ne s’agit pas de neuf journaux séparés, mais d’une même suite d’événements dont chaque maillon doit pouvoir être relié au précédent.

Une chaîne amputée d’une liaison n’est pas « presque complète ». Le maillon manquant risque justement de correspondre à l’action contestée lors d’un incident.

Construire une chaîne de conservation des preuves

Chaîne de conservation des preuves pour le travail des agents

Le parcours à reconstituer va de l’intention au contexte, puis au modèle, au prompt et à la compétence ; viennent ensuite l’action, le verdict des règles, le code ou document modifié, le déploiement, les effets en production et les preuves associées. Chaque transfert est un point de rupture possible.

Plusieurs pratiques issues des systèmes distribués permettent de consolider ce parcours :

• Identifiant de corrélation stable. Un identifiant est créé pour l’intention de départ et transmis à chaque système. S’il disparaît lors d’un transfert, les événements en aval deviennent difficiles à rattacher au travail initial.
• Versions précisément identifiées. Il faut conserver la version du modèle, l’empreinte du prompt, celle de l’ensemble des règles, la version de la compétence et celle de la description des outils. « La dernière version » n’est pas une référence vérifiable.
• Empreintes des données d’entrée. On ne peut pas toujours enregistrer l’intégralité des informations consultées. Une empreinte cryptographique accompagnée d’un pointeur vers la source permet néanmoins de vérifier ultérieurement une entrée donnée.
• Attestations signées à chaque contrôle. Chaque système chargé d’évaluer le travail produit un enregistrement indiquant son identité, ce qu’il a examiné, son verdict et la version des règles utilisée.
• Historique non réinscriptible. Une preuve doit pouvoir être complétée ou remplacée par une nouvelle version, jamais modifiée discrètement. Les deux versions restent conservées.

Ces mécanismes rendent possible la reproduction de l’analyse, limitent la contestation d’une action enregistrée et permettent de déceler les altérations. Un historique qu’on ne peut pas suivre ni rejouer n’est qu’une narration.

Décrire précisément la contribution humaine et celle des agents

Indiquer vaguement que « l’IA a participé » ne répond pas aux questions que peuvent poser des clients, les équipes juridiques ou les responsables de conformité. Les situations à distinguer sont concrètes : un résultat entièrement rédigé par l’agent puis approuvé par un humain ; un brouillon de l’agent révisé par une personne, avec conservation des différences ; un travail humain seulement assisté par des suggestions ; une implémentation produite par l’agent à partir d’une spécification humaine ; enfin, un travail intégralement humain.

Selon le contexte, ces différences peuvent intervenir dans les questions de propriété intellectuelle, de licences, de garanties ou d’obligations sectorielles. Elles ne déterminent pas à elles seules une conclusion juridique. Le système doit néanmoins être capable de les décrire. Un champ authorship structuré et signé doit être émis par le système qui a produit le travail, au moment où celui-ci a eu lieu ou lors de sa publication. Une case cochée par une personne plusieurs jours plus tard ne constitue pas une preuve équivalente.

Si les artefacts disposent déjà de métadonnées relatives au responsable, à la version et à l’origine, cette information supplémentaire s’inscrit dans une discipline existante.

Signer également ce qui détermine le comportement

Pour un logiciel traditionnel, les équipes savent construire un artefact, calculer son empreinte, le signer et vérifier ensuite que le produit livré correspond à celui qui a été fabriqué. Les systèmes à agents exigent la même rigueur pour les éléments qui orientent leurs décisions.

Doivent être identifiés et signés : les compétences, avec leurs métadonnées, contrats et tests ; les ensembles de règles, avec leur version et leur périmètre ; les prompts, par leur empreinte ; les déclarations des outils et leurs droits d’accès ; les ensembles de politiques chargés par les évaluateurs ; et les versions exactes des modèles. Les mises à niveau doivent relever du processus de gestion des changements, non d’une modification implicite décidée par le fournisseur.

Le cas fréquent est celui d’un prompt édité sur place. Le système l’utilise immédiatement, sans enregistrer le changement, et l’audit pointe désormais vers un texte qui n’existe plus sous sa forme initiale. Pour l’éviter, il faut enregistrer l’empreinte du prompt, le signer lors de sa publication et refuser de charger les éléments non validés.

Des versions de logiciel signées à des comportements traçables

Comme la nomenclature des composants logiciels recense ce qui entre dans un produit, les agents ont besoin d’une nomenclature des modèles, prompts, compétences, outils et règles ayant contribué à chaque résultat. Elle doit être capturée au moment de la production, et non reconstituée à la fin. Sans signature des éléments qui conditionnent le comportement, la piste d’audit s’arrête là où ils ont pu changer.

Le transfert entre deux systèmes doit lui aussi laisser des preuves

Le quatrième article de la série soulignait l’importance des preuves à chaque contrôle. Mais celles-ci se perdent souvent au passage d’un service à l’autre : contexte supprimé, nouvel identifiant émis, version des règles oubliée, signature retirée parce que le destinataire ne sait pas la vérifier.

À chaque frontière, il faut poser cinq questions : le service émetteur fournit-il les éléments nécessaires ? Le destinataire les vérifie-t-il ? L’identifiant commun est-il préservé ? La version des règles appliquées reste-t-elle identifiable ? Si le travail sort de l’organisation vers un outil, un fournisseur de modèle ou une API, la politique et les preuves sont-elles consignées dans une forme que l’on peut contrôler ?

Entre systèmes internes, des contrats de service plus stricts peuvent suffire. Avec un prestataire externe, il faut anticiper l’absence de conservation des preuves, les identifiants réémis, les nouvelles tentatives invisibles et les réponses impossibles à rattacher à une requête particulière. L’organisation responsable de la gouvernance doit alors rétablir elle-même la preuve au passage de frontière, au lieu de supposer sa transmission automatique.

Reconstituer les décisions sans surveiller les ingénieurs

Une piste de provenance n’a pas vocation à enregistrer les frappes au clavier d’un ingénieur ou à suivre son activité minute par minute. Pour expliquer une action d’agent, on a besoin de l’intention qui l’a déclenchée, des artefacts et des règles qui l’ont influencée, des verdicts, des changements appliqués et de leurs effets. L’acteur pertinent est souvent « agent X agissant selon la politique Y pour l’intention Z ». Quand une personne intervient, c’est l’autorisation donnée, et sa portée, qu’il faut conserver.

Deux principes doivent encadrer cette conception. Premièrement, ne conserver que les preuves nécessaires pour expliquer les décisions : accumuler toutes les données disponibles facilite aussi les usages abusifs. Deuxièmement, définir une durée de conservation limitée, comme pour toute information sensible. Une rétention indéfinie n’est pas une qualité en soi. Un audit excessivement intrusif risque de pousser les équipes à contourner le dispositif, ce qui nuit autant à la confiance qu’à la qualité des preuves.

La provenance sert à reconstituer les faits, pas à observer les personnes.

Les signes d’une traçabilité qui fonctionne

On doit pouvoir partir de n’importe quelle modification en production et remonter jusqu’à l’intention initiale ; retrouver la version du modèle, l’empreinte du prompt, la version des compétences et l’ensemble des politiques ; consulter une attribution signée ; traverser les frontières internes et constater explicitement comment la preuve a été rétablie chez les tiers. Les enregistrements restent signés, non réinscriptibles et vérifiables par empreinte. L’équipe doit aussi pouvoir expliquer précisément comment le comportement d’un agent a changé au cours des trente derniers jours.

À l’inverse, il y a un problème lorsque le nom d’une personne masque le véritable enchaînement du travail, qu’un prompt change sans empreinte enregistrée, qu’un modèle est mis à niveau sans nouvelle référence de version, ou que les journaux existent sans liaison. Autre signe révélateur : les mêmes questions des juristes obtiennent des réponses différentes d’un trimestre à l’autre. Si la réponse dépend de la personne interrogée, les preuves ne forment pas encore une chaîne fiable.

Comment la chaîne se rompt en pratique

Plusieurs défaillances reviennent constamment. Identifiant perdu : le second service abandonne la référence commune et rend les événements suivants impossibles à rapprocher. Versions manquantes : l’action est enregistrée, mais pas le modèle, le prompt ou la règle qui l’a produite. Prompt modifiable : l’artefact final est signé, pas son entrée. Paternité attribuée automatiquement : le responsable qui approuve apparaît comme l’auteur de tout, même si l’agent a rédigé le changement. Silence externe : la trace s’arrête au premier outil tiers. Audit par captures d’écran : l’équipe assemble après coup souvenirs, historiques de conversation et images partielles.

Chaîne complète et chaîne interrompue

Ces défauts procèdent d’une même hypothèse : croire que les journaux épars finiront par se relier d’eux-mêmes. Ce n’est pas le cas.

Une responsabilité de conception, pas seulement de conformité

Dans l’audit traditionnel, l’ingénierie exportait souvent les journaux après la demande d’une autre équipe. Avec des agents, cette méthode ne peut produire un identifiant, une version de modèle ou une empreinte de prompt jamais enregistrés au moment de l’action. Le fait manquant n’existe nulle part.

La provenance devient donc un problème d’architecture et de développement. Ses composants sont familiers : l’identifiant commun relève du traçage distribué, l’attestation de la signature logicielle, l’historique non réinscriptible du journal d’événements, et l’empreinte de l’adressage par contenu. Il faut intégrer ces mécanismes à la chaîne de fabrication plutôt que fabriquer un rapport a posteriori.

Une mise en œuvre par étapes

1. Définir la chaîne utile. Partir des vraies questions des clients, des juristes, des responsables de conformité ou des autorités, puis remonter vers les données nécessaires. L’exhaustivité maximale n’est pas l’objectif.
2. Instrumenter un parcours important de bout en bout. Le circuit d’une demande de modification rédigée par un agent puis déployée constitue souvent un bon point de départ : suivre l’intention jusqu’aux effets en production.
3. Faire de l’identifiant commun une obligation contractuelle. Le créer à la réception de l’intention, le propager partout et vérifier sa présence à chaque frontière. Sa perte est un défaut.
4. Figer et signer les éléments comportementaux. Prompt par empreinte, compétence par version, modèle par référence précise, ensemble des règles par empreinte signée.
5. Inscrire la paternité dans les artefacts. Le champ authorship doit décrire les contributions possibles, être signé, produit automatiquement et exigé au moment de la publication.
6. Traiter explicitement les frontières. Contrats pour les services internes ; preuves rétablies et dépendances aux tiers clairement identifiées pour les services externes.
7. Tester avec de vraies questions. Choisir une modification récente et rechercher ce qui l’a produite, sous quelle autorité et selon quelles règles. Si plusieurs longues recherches sont nécessaires, le dispositif n’est pas encore suffisamment solide.

Conclusion

Dans une organisation qui utilise des agents pour développer et livrer du logiciel, l’audit n’est plus seulement un dossier à constituer en urgence. C’est une capacité à construire dans la plateforme avant les premières mises en production. La chaîne relie une intention à ses effets en traversant agents, modèles, prompts, compétences, politiques, contrôles et systèmes d’exécution ; elle dépend de chacune de ses frontières.

Il faut toutefois en reconnaître la limite : un événement jamais observé ne peut être reconstitué. Si un modèle change derrière un nom stable, si un prompt est modifié sans trace ou si une compétence gagne un outil sans déclaration, la chaîne ne le saura pas. Les changements de capacité doivent eux-mêmes être soumis à la gouvernance. Multiplier les politiques sans pouvoir expliquer ce qui s’est réellement passé n’apporte pas la preuve attendue.

La suite de la série portera sur la gestion des changements concernant les agents : une fois les origines vérifiables, leurs évolutions pourront être administrées comme de véritables déploiements, avec versions, essais progressifs, communication et retour arrière.

Article publié initialement par Reza Arani sur Medium le 4 juin 2026, puis adapté pour Aipolix comme septième volet de la série.

Sources

• Article original de Reza Arani sur Medium