L’essor des outils de développement agentiques, qui confient à des agents d’IA la préparation de modifications de code, pose la question de l’auditabilité des workflows. Dans les secteurs réglementés, savoir qui a approuvé une modification ne suffit plus : il faut pouvoir reconstituer le contexte, les contrôles et les décisions qui l’ont produite.
Au sein d’une grande institution financière qui utilise un agent dans son workflow de développement, l’équipe d’audit interne et de conformité s’est posé une question précise. Pour une merge request (une demande de fusion de code) ouverte par un agent afin de mettre à jour une dépendance d’un service de paiement, pouvait-on indiquer qui l’avait approuvée, quelles données d’entrée et quels prompts l’agent avait utilisés, quels contrôles de politique avaient été évalués et comment reproduire ou annuler cette tâche ? L’équipe n’avait pas de réponse. Le système de livraison ne considérait pas le travail de l’agent comme une transaction délimitée et auditable.
Un diff validé par la CI (l’intégration continue, qui teste automatiquement le code) et approuvé prouve qu’une modification a eu lieu. Il ne prouve pas, en revanche, le contexte utilisé par l’agent, les décisions de politique évaluées avant la création de la merge request, ni la possibilité de reproduire le résultat lors d’une exécution ultérieure. Or, dans les environnements réglementés, le « comment » et le « pourquoi » sont essentiels. Cette situation se retrouve sur l’ensemble des plateformes et dans les organisations DevSecOps : le budget des outils agentiques est validé en quelques semaines, alors que celui des enregistrements d’exécution, de la liaison d’identité et des outils de rejeu n’apparaît jamais ou est traité comme un simple coût de conformité.
Quatre exceptions récurrentes
Dès que des agents ouvrent des merge requests dans un environnement CI/CD réglementé, quatre types d’exceptions de conformité apparaissent. La première est la provenance manquante : personne ne peut dire quelles données l’agent a utilisées, qu’il s’agisse des spécifications, du contexte récupéré, des appels d’outils ou de l’état du dépôt. La deuxième est l’attribution d’identité incertaine, puisque l’agent a agi sous un token de service partagé, sans responsable humain désigné. La troisième est une chaîne de décision non reconstituable, le raisonnement n’ayant été capturé que de façon éphémère. La quatrième est le retour en arrière non délimité : les modifications de l’agent étant couplées, toute annulation devient un travail manuel à travers les commits et les dépôts.
La reconstruction a posteriori consiste à examiner les logs de conversation, les sorties partielles de la CI et les traces de l’agent encore disponibles. Dans la plupart des organisations, personne ne comptabilise les heures consacrées chaque semaine à cette tâche, ce qui explique que son coût reste invisible. La source propose un test simple : une équipe est-elle capable de produire en moins d’une heure un dossier de preuves réunissant les spécifications de la tâche, l’état du dépôt, les contrôles évalués et le responsable humain à l’origine de l’action ?
« Livrer d’abord » et ses limites
La stratégie « Livrer d’abord, gouverner ensuite » peut fonctionner lorsque les agents sont cantonnés à des périmètres restreints, comme la génération de tests, de petites refactorisations ou la mise à jour de documentation, avec une revue humaine solide. Elle se fracture en revanche lorsque les équipes s’en affranchissent, que les bibliothèques de prompts se multiplient avec une journalisation incohérente et que des tokens partagés rendent l’attribution impossible à l’échelle du portefeuille. L’article cite aussi le cas d’une grande entreprise qui a voulu bâtir un socle de workflow avant de généraliser les agents : le projet de plateforme s’est étalé sur plusieurs trimestres, et les équipes ont fini par le contourner.
L’article souligne que « la pression concurrentielle récompense la vitesse, tandis que les régulateurs récompensent la capacité de reconstitution ». Il décrit le coût de cet écart : preuves manquantes découvertes lors d’un contrôle, remédiation de plusieurs semaines et rayon d’impact qui s’élargit à chaque action d’agent mal enregistrée. Il cite à ce titre Crédit Agricole CIB, qui pilote, selon le texte, une livraison réunissant des milliers de développeurs répartis dans des dizaines de pays sur une seule plateforme DevSecOps, condition requise pour auditer le travail agentique.
Nommer et mesurer le travail
La source recommande de traiter ce chantier comme un produit à part entière, baptisé « Exécution enregistrée pour le CI/CD agentique », avec des moyens réunissant ingénierie de plateforme, sécurité, audit et expérience développeur. Ses livrables couvrent un schéma d’enregistrement capturant données d’entrée, sorties, appels d’outils et version du modèle, une liaison d’identité rattachant chaque action à un responsable humain, des logs de décisions de politique, ainsi que des mécanismes de rejeu et de retour en arrière. Le suivi peut s’appuyer sur la profondeur de la file des exceptions, le délai médian d’obtention des preuves, le taux de réussite des rejeux et le taux de réouverture des exceptions.
Si une seule étape doit être franchie, le texte conseille de commencer par les cas les plus à risque, comme les changements de dépendances, les modifications d’Infrastructure as Code et la configuration de sécurité. Le dernier test proposé consiste à demander à une équipe d’annuler proprement une modification fusionnée rédigée par un agent, en s’appuyant uniquement sur des artefacts enregistrés.
