Essor des outils de développement agentiques : l'auditabilité des workflows se transforme en goulot d'étranglement
L'essor des outils de développement agentiques exige des workflows auditables pour garantir transparence, contrôle et confiance.
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é la question suivante : pour une merge request spécifique ouverte par un agent et destinée à mettre à jour une dépendance d'un service de paiement, est-il possible d'indiquer qui a approuvé la modification, quelles données d'entrée et quels prompts l'agent a utilisés, quels contrôles de politique ont été évalués au moment de la création de la merge request, et comment reproduire ou annuler cette tâche précise ?
Face à cette question, l'équipe n'avait pas de réponse. L'agent produisait bien des résultats, mais le système de livraison n'avait aucune notion du travail effectué par l'agent en tant que transaction délimitée et auditable. Un diff validé par la CI et qui obtient une approbation prouve qu'une modification a eu lieu. Cependant, il ne prouve pas quel contexte l'agent a utilisé, quelles décisions de politique ont été évaluées avant la création de la merge request, ni s'il serait possible de reproduire le résultat lors d'une exécution ultérieure du pipeline. Dans les environnements réglementés, le "comment" et le "pourquoi" sont justement essentiels.
La même tendance est observée sur l'ensemble des plateformes et au sein des organisations DevSecOps. Le budget consacré aux outils de développement alimentés par l'IA agentique est validé en quelques semaines, tandis que celui consacré aux enregistrements d'exécution des agents, à la liaison d'identité et aux outils de rejeu soit n'apparaît jamais, soit est traité comme un simple coût de conformité.
Quatre exceptions récurrentes
Dès que des agents commencent à ouvrir des merge requests dans un environnement CI/CD réglementé, une catégorie prévisible d'exceptions de conformité apparaît :
- Provenance manquante. Personne ne peut indiquer quelles données d'entrée l'agent a utilisées : les spécifications de la tâche, les références du contexte récupérées, les appels d'outils et l'état du dépôt au moment de l'invocation.
- Attribution d'identité incertaine. Personne ne peut distinguer les modifications initiées par un agent de celles initiées par un humain, car l'agent a agi sous un token de service partagé, sans responsable humain désigné et associé à l'action.
- Chaîne de décision non reconstituable. Personne ne peut indiquer quels contrôles de politique ont été évalués avant la création de la merge request, ni pourquoi l'agent a privilégié une option plutôt qu'une autre, car le raisonnement n'a été capturé que de façon éphémère.
- Retour en arrière non délimité. Toute annulation se transforme en véritable travail manuel à travers les commits et les dépôts, car les modifications de l'agent étaient couplées, et il n'existe aucune frontière de transaction nette à défaire.
La résolution passe par la reconstruction : passer en revue les logs de conversation, les données de sortie partielles de la CI et les éventuelles traces d'agent encore disponibles. Dans la plupart des organisations, personne ne comptabilise le nombre d'heures consacrées chaque semaine à cette tâche, et c'est précisément pour cette raison que son coût demeure invisible.
Voici un test concret. Prenez la dernière merge request ouverte par un agent ayant touché à une dépendance ou à l'Infrastructure as Code. Votre équipe est-elle capable de produire, en moins d'une heure, un dossier de preuves unique réunissant les spécifications exactes de la tâche, la référence de l'état du dépôt, les contrôles de politique évalués au moment de la merge request et l'identité du responsable humain à l'origine de l'action ?
Mettre à l'échelle les actions des agents
Une merge request rédigée par un humain s'accompagne d'un ensemble de preuves relativement délimité : le diff, les approbations et les résultats du pipeline. Une merge request rédigée par un agent exige les mêmes éléments, auxquels s'ajoutent les spécifications de la tâche, les références du contexte récupéré, les invocations d'outils, la version du modèle, les évaluations de politique et un état suffisant pour rejouer la tâche avec des données d'entrée figées. Les logs de CI ne couvrent pas ces éléments : ils montrent les étapes et les données de sortie du pipeline, mais pas le contexte de l'agent, ses appels d'outils, ni les décisions de politique évaluées avant la création de la merge request.
À mesure que l'adoption des agents se généralise, le nombre de micro-décisions par merge request augmente, tandis que la capacité à documenter manuellement ces décisions stagne. C'est là que l'équation ne fonctionne plus.
Dès lors qu'un système non humain commence à apporter des modifications, le système de livraison a besoin d'un enregistrement durable de ce qu'il a vu, décidé et fait, directement intégré à son workflow, et non ajouté après coup. Les agents compliquent cette tâche, car leurs données d'entrée ne sont pas reproductibles : le contexte récupéré, la version du modèle et le raisonnement ne produiront pas le même résultat lors d'une nouvelle exécution. Le chaînon manquant consiste à rattacher le contexte et les actions de l'agent à la merge request sous la forme d'un artefact persistant, et non d'un canal annexe.
"Livrer d'abord" : conditions de succès et limites
La stratégie "Livrer d'abord, gouverner ensuite" peut fonctionner dans le bon environnement. Une équipe produit performante utilise des agents pour des périmètres restreints : génération de tests, petites refactorisations, mises à jour de documentation. Elle s'appuie pour cela sur une solide revue humaine, un rayon d'impact limité et des ingénieurs expérimentés qui détectent les problèmes avant le merge. Lorsque les agents sont cantonnés à des périmètres à faible risque et que chaque modification passe par des revues rigoureuses et des contrôles Policy as Code, le dépôt et le pipeline restent souvent le système de référence.
La situation inverse est tout aussi fréquente. Une grande entreprise a tenté de construire un socle de workflow stable pour l'ensemble de ses processus d'automatisation avant d'en généraliser l'utilisation. L'initiative s'est transformée en un projet de plateforme étalé sur plusieurs trimestres, entre débats sur les schémas, promesses de rejeu intenables et nouveau problème de rétention des données dès lors que les prompts ont commencé à être stockés. Les équipes produit ont contourné la plateforme pour tenir leurs délais et ont privilégié des agents légers dotés de garde-fous stricts. L'audit était satisfaisant, mais le projet de plateforme a surtout retardé l'adoption tout en élargissant la surface de gouvernance.
Le schéma habituel finit par se fracturer lorsque les équipes adoptent l'état d'esprit "livrer d'abord" sans la même rigueur de revue, lorsque les bibliothèques de prompts se multiplient avec une journalisation incohérente et lorsque des tokens de service partagés rendent l'attribution d'identité impossible à l'échelle du portefeuille. Un contournement local acceptable se transforme en risque pour toute l'entreprise dès le premier audit qui exige une cohérence des preuves sur l'ensemble du portefeuille.
La pression concurrentielle récompense la vitesse, tandis que les régulateurs récompensent la capacité de reconstitution. La direction doit tenir compte de ces deux éléments. Le coût de la vitesse de développement sans couche d'exécution enregistrée ne se mesure pas à un build en échec : il prend la forme de preuves manquantes découvertes lors d'un contrôle réglementaire, d'une remédiation de plusieurs semaines avec une visibilité au niveau de la direction, et d'un rayon d'impact qui s'aggrave à chaque action initiée par un agent qui n'a jamais été correctement enregistrée.
C'est la raison pour laquelle des leaders technologiques évoluant dans des secteurs réglementés, tels que Crédit Agricole CIB, pilotent une livraison dans le monde entier réunissant des milliers de développeurs répartis dans des dizaines de pays sur une seule et même plateforme DevSecOps : il s'agit là de la condition requise qui permet d'auditer le travail agentique.
Nommer, équiper en ressources et mesurer le travail
La démarche concrète consiste à nommer explicitement ce travail, "Exécution enregistrée pour le CI/CD agentique", et à l'équiper en ressources comme un produit, en réunissant l’ingénierie de plateforme, la sécurité, la liaison avec l'audit et l’expérience développeur. Les livrables attendus correspondent directement aux quatre échecs de reconstitution évoqués plus haut : un schéma d'enregistrement d'exécution qui capture les données d'entrée, de sortie, les appels d'outils, la version du modèle et les résultats des politiques ; une liaison d'identité qui rattache chaque action d'agent à un responsable humain ; des logs de décisions de politique générés au moment de la merge request et du pipeline ; ainsi que des primitives de rejeu et de retour en arrière qui rendent l'unité de travail réexécutable avec des données d'entrée figées.
Pilotez cette démarche à l'aide d'indicateurs opérationnels : la profondeur de la file d'attente des exceptions de conformité pour les merge requests initiées par des agents, le délai médian d'obtention des preuves, le taux de réussite des rejeux et le taux de réouverture des exceptions après les suivis d'audit. Si vous ne deviez franchir qu'une seule étape, commencez par développer l'enregistrement d'exécution et le chemin de rejeu pour les cas d'utilisation les plus à risque, comme les changements de dépendances, les modifications de l'Infrastructure as Code et la configuration de sécurité, avant d'étendre progressivement cette démarche.
Un dernier test : demandez à une équipe de sélectionner une modification fusionnée rédigée par un agent et d'effectuer un retour en arrière propre, en tant qu'unité délimitée unique, en s'appuyant uniquement sur des artefacts enregistrés. Si ce retour en arrière exige une recherche dans Slack, des clones locaux ou la recréation du prompt en espérant que tout fonctionne, vous tenez votre plan d'action.