Pourquoi les comptes de service et les étapes d’approbation ne suffisent plus lorsque les agents écrivent, relisent et livrent du code.

Article 2 sur 10 — Gouvernance de l’IA dans une entreprise de développement logiciel AI-native

La phrase la plus coûteuse de l’ingénierie AI-native est généralement prononcée avec beaucoup d’assurance :

« Nous avons déjà une gouvernance. » 🫤

La plupart du temps, cela signifie trois choses :

• les agents s’authentifient via SSO ou un compte de service
• des permissions de dépôt existent
• un humain approuve encore les changements de production

Ce n’est pas de la gouvernance. C’est du contrôle à la porte d’entrée.

Cela répond aux premières questions et ignore les plus coûteuses :

• Pourquoi l’agent a-t-il pris cette décision ?
• Comment cette décision est-elle devenue un changement en production ?
• Qu’est-ce qui a changé autour de cette décision ?
• L’agent a-t-il réellement amélioré les résultats ?
• Faut-il donner davantage d’autonomie à cet agent au prochain trimestre, ou moins ?

C’est là que se situe l’écart.

Dans l’article précédent, « You Think You Have AI Governance. You Don’t. », j’expliquais que la gouvernance de l’IA dans une entreprise logicielle n’est pas la même conversation que la sécurité de l’IA. C’est un problème d’opérations d’ingénierie. Cet article transforme cette idée en diagnostic : un modèle en cinq couches permettant de distinguer une véritable gouvernance de quelques contrôles visibles accompagnés de beaucoup d’espoir.

La version courte est directe : la plupart des équipes ne disposent que des couches 1 et 2, et encore partiellement. Tout le reste constitue une dette de gouvernance.

🧩 Le modèle en une phrase

La gouvernance des agents comporte cinq couches :

  1. Identité : qui agit ?
    2. Action : que l’agent est-il autorisé à faire ?
    3. Sortie : qu’a-t-il décidé et quelles preuves soutiennent cette décision ?
    4. Changement : comment cette sortie est-elle devenue un changement en production ?
    5. Résultat : l’agent a-t-il aidé, nui ou dérivé ?

S’il en manque une seule, votre pile de gouvernance comporte un angle mort. Si les couches 3 à 5 manquent, comme c’est le cas dans beaucoup d’entreprises, vous n’avez pas de pile de gouvernance : vous avez du contrôle d’accès accompagné d’optimisme.

L’idée centrale, en termes simples :

Les couches 1 et 2 contrôlent l’accès. Les couches 3, 4 et 5 créent la confiance à l’échelle.

L’accès n’est pas la confiance. La confiance commence aux couches 3, 4 et 5. Les contrôles à l’entrée empêchent les problèmes évidents. Les trois dernières couches permettent d’enquêter, d’annuler et d’améliorer ce qui a malgré tout franchi ces contrôles.

🗂 Les cinq couches

1. Identité
Question centrale : Qui agit ?
Ce qui est attendu : chaque agent possède une identité unique et vérifiable, des identifiants limités et un propriétaire.
Ce qui casse en son absence : identifiants partagés, attribution faible, confinement impossible.

2. Action
Question centrale : Que peut faire l’agent ?
Ce qui est attendu : limites d’autonomie explicites, non-objectifs imposés par la machine et approbation humaine lorsque l’autorité s’arrête.
Ce qui casse en son absence : dérive de périmètre, utilisation dangereuse des outils, dépassement accidentel.

3. Sortie
Question centrale : Qu’a décidé l’agent, et pourquoi ?
Ce qui est attendu : traces de décision, liens vers les preuves, confiance, citations et justification structurée.
Ce qui casse en son absence : PR mystérieuses, échecs d’audit, post-mortems fondés sur des suppositions.

4. Changement
Question centrale : Comment cette sortie a-t-elle atteint la production ?
Ce qui est attendu : traçabilité de bout en bout, de la requête à la PR, CI, canary et déploiement, avec préparation au rollback.
Ce qui casse en son absence : trous dans la chronologie, dérive silencieuse des prompts ou modèles, réponse aux incidents lente.

5. Résultat
Question centrale : L’agent a-t-il été efficace ?
Ce qui est attendu : métriques au niveau de la version sur le taux d’acceptation, le retravail, le rollback, le coût, l’escalade et la dérive.
Ce qui casse en son absence : autonomie étendue à l’intuition, agents faibles maintenus, confiance érodée.

Répétons-le, car c’est précisément là que les équipes se trompent elles-mêmes : Les couches 1 et 2 contrôlent l’accès. Les couches 3, 4 et 5 créent la confiance à l’échelle. Si vous n’avez construit que les deux premières, la pile n’est pas terminée. Vous avez construit le hall et laissé le reste du bâtiment dans l’obscurité.

Couche 1 : Identité 🔐

Tout système de gouvernance commence ici, car sans identité tout le reste se transforme en ambiguïté. Un agent sans identité unique n’est pas gouverné. C’est simplement un processus dont la responsabilité reste floue.

Au minimum, la couche 1 signifie :

• chaque instance d’agent possède un enregistrement d’identité distinct
• les identifiants sont propres à cet agent et ne sont pas partagés entre plusieurs agents
• les permissions sont limitées à l’objectif enregistré de l’agent
• l’émission, la rotation et la révocation des identifiants sont auditables
• un responsable humain nommé existe

Cela semble évident. En pratique, beaucoup d’équipes font encore fonctionner plusieurs agents avec le même jeton ou laissent des agents d’IDE hériter d’un accès développeur très large simplement parce que c’est pratique. Cette facilité devient rapidement une dette opérationnelle. Trois agents partageant un même identifiant ne peuvent pas être isolés proprement lors d’un incident. Si un agent emprunte l’accès d’un humain, la frontière entre action humaine et action de l’agent disparaît. Et si un agent de production conserve un secret statique de longue durée, une fuite de logs suffit à créer une violation difficile à attribuer.

L’identité n’est pas seulement une question de sécurité. C’est le premier prérequis de la lisibilité. Si vous ne pouvez pas répondre en une requête à « quel agent a fait cela ? », inutile de passer aux modèles de maturité et aux tableaux de KPI. Vous êtes encore à la couche 1.

🛑 Couche 2 : Action

L’identité indique qui est l’agent. L’action indique ce qu’il est autorisé à faire. C’est ici que vivent les limites d’autonomie, les non-objectifs, les périmètres d’outils, les seuils d’approbation et les règles fail-closed.

Une couche 2 solide rend l’autorité de l’agent explicite dans cinq directions :

• fonctionnelle : quelles actions il peut ou ne peut pas effectuer
• données : quels systèmes et domaines de données il peut consulter
• temporelle : quand il peut agir et quand il ne le doit pas
• autorité : quelles décisions nécessitent une approbation humaine
• escalade : quand l’ambiguïté ou le risque doit interrompre le workflow

Le choix de conception essentiel est simple et pourtant rare : le refus doit être considéré comme une sortie correcte.

Si un agent ne peut pas déterminer si une demande est dans son périmètre, il doit refuser et escalader. Trop d’équipes récompensent encore les agents parce qu’ils sont « utiles », alors que le comportement gouverné devrait être « stop ».

C’est la différence entre un agent impressionnant en démonstration et un agent que vous pouvez exploiter en production en toute sécurité. La plupart des entreprises disposent d’une forme de couche 2, mais elle est généralement faible : une politique interne, un prompt disant « ne touche pas à la production », ou une étape d’approbation manuelle pour certaines actions risquées.

Ce n’est pas suffisant. Une véritable couche 2 est imposée au runtime. Elle est lisible par la machine et bloque avant que l’action ne s’exécute. Sinon, vos limites ne sont pas des limites : ce sont des suggestions.

🧾 Couche 3 : Sortie

C’est la couche que la plupart des équipes sautent entièrement, et c’est là que la gouvernance commence à devenir réelle. La couche 3 demande : lorsqu’un agent prend une décision importante, quelles preuves survivent à cette décision ? Pas une description de PR bien rédigée. Pas un message marketing disant que l’agent est « transparent ». Les véritables preuves opérationnelles.

Pour une décision significative, vous devriez pouvoir récupérer :

• l’identifiant de trace de décision
• les entrées utilisées par l’agent
• les sources de connaissance ou références sur lesquelles il s’est appuyé
• le signal de confiance ou de certitude, lorsqu’il est pertinent
• les alternatives envisagées lorsque la décision est importante
• le résultat structuré produit

Sans cela, vous obtenez ce que beaucoup d’équipes ont déjà : du code dans main sans explication fiable de la raison de sa présence. Lors d’un incident ou d’un audit, l’absence de couche 3 signifie que votre post-mortem commence par une recherche Slack et votre réponse à la conformité par « nous pensons que ».

Les journaux de conversation ne sont pas de la traçabilité. Ce sont des débris.

L’archéologie Slack n’est pas de l’auditabilité. C’est de la reconstruction. L’objection fréquente est la vitesse : « nous ne pouvons pas capturer tout cela et rester rapides ». C’est généralement faux. Il ne faut pas un roman pour chaque sortie ; il faut des traces structurées et interrogeables. Une bonne gouvernance des sorties n’est pas riche en narration, elle est riche en schémas.

Cette couche transforme le post-mortem d’un roman policier en travail d’ingénierie. C’est aussi une grande source de douleur lors des audits. Quand la conformité demande qui ou quoi a approuvé un changement, quelle version de politique était active ou quel niveau de preuve soutenait la décision, les équipes sans couche 3 fouillent les chats et captures d’écran. Ce n’est pas de la gouvernance ; c’est de la reconstruction. La couche 3 rend le travail lisible.

🔄 Couche 4 : Changement

La couche 3 vous dit ce que l’agent a décidé. La couche 4 explique comment cette décision est devenue un changement réel. Les incidents de production se produisent rarement au moment de la décision ; ils surviennent plus tard, lorsqu’une chaîne de systèmes transforme la sortie de l’agent en impact client.

La couche 4 relie toute la chronologie : demande → plan → PR → CI → canary → déploiement → signaux runtime → incident → rollback.

Une bonne gouvernance de couche 4 signifie :

• un identifiant de corrélation survit sur tout le parcours
• les liens vers les artefacts sont conservés plutôt que recopiés vaguement dans des notes
• chaque étape importante de la chronologie est signée ou auditable
• les liens manquants échouent bruyamment
• la préparation au rollback est vérifiée avant la promotion
• les changements affectant le comportement, tels que prompts, versions de modèles et schémas d’outils, sont versionnés et promus comme le code

C’est ce dernier point qui piège beaucoup d’organisations pourtant disciplinées. Elles considèrent encore le « changement » comme du code source uniquement.

Dans un modèle opérationnel AI-native, les modifications de prompts, règles de routage, schémas d’outils, index de recherche et versions de modèles changent toutes le comportement de production. Un prompt qui modifie le comportement actif est un changement de production. Un changement de modèle qui modifie l’approbation est un changement de production. Une évolution de schéma d’outil qui élargit ce qu’un agent peut invoquer est un changement de production.

Si ces modifications contournent la même discipline de promotion que le code, vous n’avez pas de contrôle du changement. Vous avez un modèle de déploiement à deux cerveaux : Git est gouverné, le comportement ne l’est pas. Si le comportement du système peut changer en dehors de la chaîne de déploiement, le système n’est pas réellement gouverné.

C’est ainsi qu’une équipe se retrouve à diagnostiquer vendredi un incident provoqué par une modification de prompt mardi, jamais revue, jamais canarisée et sans plan de rollback. La couche 4 rend la réversibilité réelle plutôt que rhétorique.

📈 Couche 5 : Résultat

La dernière couche pose finalement la question que les dirigeants poseront de toute façon : cet agent aide-t-il réellement ? Pas « les développeurs l’aiment-ils ? », pas « combien de prompts avons-nous déployés ce mois-ci ? », pas « combien de tokens avons-nous achetés ? ».

La vraie question est de savoir si une version précise d’une capacité a amélioré les résultats sans déplacer des coûts cachés ailleurs. Cela signifie mesurer, au niveau de la version de capacité :

• taux d’acceptation
• taux de retravail
• taux d’escalade
• taux de rollback
• variation du temps de réalisation
• coût par tâche
• respect des limites d’autonomie
• implication dans les incidents

C’est là que la plupart des entreprises fonctionnent encore à l’intuition. Elles savent que les agents sont « partout », que l’usage augmente et que le CFO veut une histoire de ROI. Mais elles ne savent pas dire quelle version d’agent a aidé l’équipe checkout, laquelle a augmenté la charge de revue, laquelle a régressé après un changement de modèle, ni laquelle mérite plus d’autonomie au prochain trimestre.

L’évaluation à l’intuition promeut les agents médiocres, défend les agents coûteux et transforme les agents faibles en « stratégie ». C’est aussi ainsi que des erreurs coûteuses deviennent normales.

Sans couche 5, l’expansion de l’autonomie devient politique : le partisan le plus bruyant, la démonstration la plus brillante ou la feuille de route du fournisseur gagne. Avec la couche 5, la gouvernance devient améliorable : vous pouvez réduire le périmètre, promouvoir des versions plus sûres, retirer les capacités faibles et prendre des décisions de ressources sur des preuves plutôt que sur l’enthousiasme.

🏦 Un incident vu à travers les cinq couches

Un agent de codage dans une fintech reçoit pour objectif de réduire la latence du checkout. Il réécrit un chemin de requête critique, remplace une recherche bornée par une jointure plus large, ouvre une PR et passe la suite de tests. Les tests valident la correction sur des données de fixture, pas la latence avec la cardinalité de production sous charge concurrente. Un humain approuve rapidement. Un agent de déploiement promeut le changement après le canary, car il ne voit ni hausse d’erreur ni dépassement du seuil p95 par défaut. En fin d’après-midi, la latence est pire. L’équipe rollback.

Avec seulement les couches 1 et 2, vous pouvez probablement dire quel compte d’agent a ouvert la PR et que l’agent disposait techniquement de la permission de modifier ce service. C’est utile, mais très loin d’être suffisant.

Couche 1, Identité
Vous connaissez l’instance exacte de l’agent, son propriétaire, son ensemble d’identifiants et la version de capacité impliquée.

Couche 2, Action
Vous savez si la modification de la logique de performance du checkout entrait réellement dans son périmètre, si elle a franchi une limite de données ou d’autorité, et si le seuil de revue était adapté à la criticité du service.

Couche 3, Sortie
Vous pouvez examiner la trace de décision : fichiers lus, preuves utilisées, benchmarks obsolètes éventuellement cités, faible confiance ou signaux contradictoires ignorés.

Couche 4, Changement
Vous reconstruisez la chronologie signée de la demande à la PR, CI, canary, déploiement et rollback, et vous pouvez voir si un prompt ou un schéma d’outil a changé dans la même fenêtre.

Couche 5, Résultat
Vous comparez l’incident au dossier de performance plus large de l’agent : erreur isolée ? Régression récente ? Motif sur les services critiques ? Signal qu’il faut réduire son autonomie ?

C’est la différence entre « nous avons eu un incident IA » et « nous comprenons notre système d’exploitation ». La première posture est réactive et coûteuse. La seconde est la manière de gagner de la confiance à grande vitesse.

🚧 Pourquoi la plupart des équipes s’arrêtent à la couche 2 ?

Trois raisons. Premièrement, les couches 1 et 2 ressemblent à la gouvernance traditionnelle. La sécurité possède l’identité, la plateforme les permissions, et la direction voit des contrôles visibles donc perçoit du progrès.

Deuxièmement, les couches 3 et 4 imposent une discipline inconfortable : traces structurées, chronologies signées, prompts épinglés à une version, détection des trous dans les gates de déploiement, sondes de rollback. C’est du vrai travail d’ingénierie et cela révèle la part des processus qui repose encore sur des comportements informels.

Troisièmement, la couche 5 oblige à être honnête. Quand l’efficacité des agents est mesurée au niveau de la version, certains outils favoris cessent d’impressionner, certaines extensions d’autonomie apparaissent prématurées et certains goulots d’étranglement ne sont pas le codage mais la revue, la gestion d’incident ou une mauvaise retrieval.

Autrement dit, les couches profondes ne gouvernent pas seulement les agents. Elles gouvernent aussi les récits de management. C’est pourquoi elles sont repoussées. Et c’est aussi pourquoi elles comptent.

✅ Une auto-évaluation rapide

Pour savoir où vous en êtes, posez ces cinq questions :

  1. Identité : pouvons-nous nommer aujourd’hui chaque agent pertinent pour la production, son propriétaire, ses identifiants et son périmètre ?
    2. Action : pouvons-nous montrer ce que chaque agent ne doit pas faire et prouver que ces limites sont imposées au runtime ?
    3. Sortie : pouvons-nous reconstruire une décision matérielle d’un agent à partir de preuves traçables plutôt que de chats ?
    4. Changement : pouvons-nous suivre un identifiant de corrélation de la demande au déploiement puis au rollback, y compris les changements de prompts et de modèles ?
    5. Résultat : pouvons-nous montrer quelles versions de capacités aident, nuisent ou dérivent ?

Si vous avez répondu « non » à l’une de ces questions, cette couche est faible. Si vous avez répondu « non » aux questions 3 à 5, vous êtes dans l’état le plus courant : quelques contrôles de base devant, du brouillard au milieu et aucune boucle d’apprentissage fiable à la fin.

C’est un point de départ acceptable. Ce n’est pas un endroit sûr où rester. Plus directement : si vous ne pouvez pas répondre aux questions 3 à 5, vous n’avez pas de confiance à l’échelle. Vous avez une exposition à l’échelle.

🏗️ Où construire ensuite ?

N’essayez pas d’implémenter les cinq couches en même temps. Si vous débutez, sortez les couches 1 et 2 des documents de politique et transformez-les en enforcement réel. Si vous les avez déjà, ne sautez pas directement aux tableaux de ROI destinés aux dirigeants. Construisez d’abord les couches 3 et 4. Sans elles, vos métriques de résultat seront bruyantes, contestables et faciles à manipuler.

L’ordre de construction pratique pour la plupart des équipes :

  1. identité unique de l’agent et identifiants limités
    2. limites d’autonomie au runtime et non-objectifs explicites
    3. traces de décision pour les actions importantes
    4. chronologies de changement de bout en bout avec préparation au rollback
    5. métriques d’efficacité au niveau de la version de capacité

Cet ordre compte parce que chaque couche rend la suivante crédible.

🎯 Le sens du modèle

Le modèle en cinq couches n’est pas un exercice de taxonomie. C’est une façon d’arrêter d’utiliser le mot « gouvernance » si librement qu’il perd tout sens opérationnel.

La gouvernance n’est pas un prompt disant à l’agent d’être prudent. La gouvernance n’est pas SSO plus un modèle de pull request. La gouvernance n’est pas un comité Responsible AI qui ne regarde jamais votre chronologie de déploiement.

La gouvernance est la discipline opérationnelle qui rend une main-d’œuvre non humaine lisible, contenue, réversible et améliorable. C’est ce qui permet aux organisations d’ingénierie d’étendre l’usage des agents sans étendre la confusion à la même vitesse. Et c’est ce qui rend possible la confiance à grande vitesse.

Si l’article 1 était le changement de cadre, celui-ci est le diagnostic : la plupart des équipes n’ont pas un problème de gouvernance parce qu’elles manquent de principes. Elles ont un problème parce que leur pile n’a que deux couches alors qu’elles misent déjà la production sur les cinq.

Ce pari devient plus coûteux chaque trimestre.

Terminons donc par la phrase qui compte : Les couches 1 et 2 contrôlent l’accès. Les couches 3, 4 et 5 créent la confiance à l’échelle.

Si vous ne pouvez pas voir le travail, tracer le changement et mesurer le résultat, vous ne gouvernez pas les agents. Vous opérez sur la confiance aveugle.