Les agents IA passent de la réponse aux questions à l'exécution d'actions.
Ce seul changement modifie complètement le modèle de risque.
Les chatbots produisent du texte. Les agents pilotent des systèmes.
Ils peuvent lire des e-mails, appeler des API, mettre à jour des fiches clients, déployer du code, créer des tickets, approuver des étapes de workflow, coordonner avec d'autres agents, et stocker de nouvelles connaissances en mémoire à long terme.
La question centrale n'est donc plus :
Cette réponse est-elle correcte ?
Mais plutôt :
Cet agent devrait-il être autorisé à agir maintenant ?
C'est à cette question qu'une couche de gouvernance doit répondre.
1. La mémoire est utile. Ce n'est pas de la gouvernance.
La mémoire aide les agents à conserver le contexte entre les sessions.
Elle leur permet de se souvenir des préférences des utilisateurs, des travaux passés, des résultats d'outils et des décisions antérieures. C'est important. Mais la mémoire ne décide pas :
- quels faits sont autorisés à entrer en mémoire
- quels souvenirs sont périmés ou empoisonnés
- quelles actions nécessitent une approbation
- quelle étape de workflow doit venir ensuite
- quelle preuve est requise avant exécution
- quel agent est autorisé à utiliser quelle information
Dans les systèmes d'agents en production, le problème le plus difficile n'est souvent pas la récupération. C'est l'autorité.
La mémoire aide un agent à se souvenir.
La gouvernance l'aide à choisir ce qu'il est autorisé à faire.
C'est là que se situe Marrow.
Marrow n'est pas simplement une couche de mémoire. C'est une couche de jugement pour les flottes d'agents IA.
2. L'observabilité explique le passé. Les agents ont besoin de contrôle avant le futur.
L'observabilité est nécessaire. Les équipes ont besoin de traces, de journaux, d'évaluations, d'annotations, d'alertes et de tableaux de bord.
Mais la visibilité a posteriori n'empêche pas une mauvaise action avant qu'elle ne se produise.
Si un agent déploie du code dangereux, envoie un e-mail sensible, approuve le mauvais paiement ou saute une étape de workflow obligatoire, le tableau de bord pourra peut-être expliquer l'incident plus tard. Il ne l'empêche pas forcément.
Pour les workflows à fort impact, le signal doit atteindre l'agent avant l'action :
- niveau de risque
- preuve requise
- contraintes de politique
- approbation du propriétaire
- plan de rollback
- étape suivante exacte
- autoriser, avertir, réviser ou bloquer
C'est l'écart entre observabilité et gouvernance.
Les tableaux de bord informent les humains.
La gouvernance informe les agents avant qu'ils n'agissent.
3. L'évaluation est un instantané. La production est un flux.
L'évaluation pré-déploiement détecte de nombreux échecs. Mais les agents en production vivent dans des environnements changeants.
Les prompts changent. Les outils changent. Les API changent. Les données changent. Les politiques changent. Les autres agents de la flotte changent.
Un benchmark peut indiquer qu'un agent performe bien dans un ensemble de conditions. La production pose une question différente :
Cet agent continuera-t-il à prendre la bonne décision lorsque l'environnement change ?
Les recherches sur les agents utilisant des outils vont dans le même sens.
ToolEmu étudie les agents de modèle de langage utilisant des outils à haut risque et montre que les défaillances des agents peuvent avoir de graves conséquences dans le monde réel. AgentHarm et CUAHarm se concentrent sur les comportements nuisibles une fois que les agents peuvent utiliser des outils ou opérer des ordinateurs. D'autres recherches montrent que les agents peuvent comprendre le risque de manière abstraite mais échouent néanmoins à éviter les actions risquées dans des trajectoires concrètes.
La leçon est pratique :
La sécurité ne peut pas résider uniquement dans le modèle ou uniquement dans un benchmark.
Les agents en production ont besoin d'un contrôle à l'exécution.
4. La gouvernance devient une infrastructure IA.
Les grands cadres de gouvernance IA convergent vers la même idée : une IA responsable doit devenir opérationnelle.
Pas seulement des principes.
Pas seulement des PDF de politiques.
Pas seulement des tableaux de bord.
Une gouvernance opérationnelle nécessite :
- une gestion documentée des risques
- une journalisation automatique
- une supervision humaine pour les décisions à fort impact
- une gestion de la qualité tout au long du cycle de vie
- la traçabilité du comportement du système
- une surveillance post-marché
- une responsabilité pour les résultats indésirables
Cela se voit dans le NIST AI RMF, le profil d'IA générative du NIST, l'ISO/IEC 42001, les principes d'IA de l'OCDE, la loi européenne sur l'IA, la taxonomie des risques d'IA agentique de l'OWASP, et les directives 2026 du Five Eyes sur les services d'IA agentique.
La direction est claire.
Les systèmes d'IA d'entreprise ont besoin de preuves, de contrôle, de traçabilité et de responsabilité tout au long de leur vie opérationnelle.
Pour les agents IA, cela signifie que la gouvernance doit entrer dans l'environnement d'exécution.
5. Ce qu'une couche de gouvernance d'agent devrait faire
Une couche de gouvernance est un plan de contrôle entre l'environnement d'exécution de l'agent et les systèmes que l'agent peut affecter.
Elle reçoit l'action prévue de l'agent, l'évalue par rapport à la politique, aux permissions, au risque, à la preuve et aux résultats antérieurs, puis renvoie une décision exécutoire :
allow
warn
review required
block
Une couche de gouvernance sérieuse nécessite neuf fonctions.
- Identité et autorité limitée
Chaque agent a besoin d'une identité claire, de permissions limitées et de justificatifs d'identité restreints.
Une flotte ne peut pas être gouvernée si chaque agent partage la même clé API.
- Politique à l'exécution
Les politiques doivent devenir des conditions exécutables à l'exécution.
Quelle étape vient en premier ?
Quelle preuve est requise ?
Quelle action nécessite toujours une révision ?
Quelle action ne devrait jamais être exécutée automatiquement ?
- Barrières de risque
Le système doit classer les actions en fonction de leur impact, de leur réversibilité, de leur sensibilité et du contexte métier.
Les travaux à faible risque peuvent être exécutés automatiquement. Les travaux à haut risque peuvent nécessiter une preuve, une approbation ou un blocage.
- Packs de preuves
Avant l'action, l'agent doit joindre des preuves.
Exemples :
- couverture de tests
- plan de rollback
- clause politique
- vérification d'identité
- approbation clinique
- révision de facture
- validation du superviseur
- Routage d'approbation
La révision humaine ne devrait pas être une file d'attente manuelle pour tout.
Elle devrait être un point de contrôle conditionnel pour les actions où le coût de l'erreur est élevé.
- Audit et provenance
Chaque décision doit être traçable.
Qui l'a initiée ?
Pourquoi a-t-elle été autorisée ou bloquée ?
Quelle politique a été appliquée ?
Quelle preuve a été jointe ?
Qui l'a approuvée ?
Que s'est-il passé ensuite ?
- Clôture des résultats
La gouvernance ne s'arrête pas à autoriser ou bloquer.
Le système doit boucler la boucle :
- l'action a-t-elle réussi ?
- a-t-elle échoué ?
- un rollback a-t-il été nécessaire ?
- qui l'a approuvée ?
- quelle leçon doit être stockée ?
- Gouvernance de l'écriture en mémoire
Tous les journaux ne sont pas des connaissances.
Toutes les connaissances ne devraient pas influencer tous les agents.
Les résultats réels ne devraient devenir de la mémoire que par une écriture contrôlée.
- Apprentissage au niveau de la flotte
La couche de gouvernance doit suivre le comportement de la flotte :
- dérive par rapport aux workflows de base
- boucles de reprise
- échecs répétés
- schémas qui devraient alerter les futurs agents
C'est là que la gouvernance devient plus qu'une restriction. Elle devient un apprentissage.
6. Marrow comme étude de cas de gouvernance
Marrow est conçu autour d'une boucle opérationnelle simple :
orienter -> penser -> agir -> vérifier -> valider
Chaque étape a une fonction de gouvernance.
Orient fait remonter l'historique pertinent, les avertissements et les contraintes.
Think évalue l'action prévue avant qu'elle ne se produise.
Act exécute avec le contexte et les garde-fous attachés.
Check inspecte si une preuve ou une clôture manque.
Commit enregistre le résultat pour que la prochaine décision s'améliore.
C'est la différence fondamentale entre mémoire et jugement.
La mémoire demande :
Que sait l'agent ?
Marrow demande :
L'agent doit-il agir, et à quelles conditions ?
Ses surfaces produit correspondent directement à la gouvernance à l'exécution :
- decisionBrief() donne à l'agent le contexte pré-action.
- workflowGate() renvoie allow, warn, review required ou block.
- runGuarded() encadre les travaux risqués avec des conseils pré-action et une clôture des résultats.
- agentRuntime() injecte les leçons et les exigences de preuve dans le contexte de l'agent.
- agentStatus() indique si Marrow est actif et recueille des signaux utiles.
- valueReport() transforme la gouvernance en preuve visible par le propriétaire.
En d'autres termes :
Marrow transforme les résultats passés en jugement avant l'action.
7. Un exemple concret : le mauvais déploiement
Imaginez un agent CI/CD sur le point de déployer une modification de webhook de paiement.
La build passe.
La branche est prête.
L'agent s'apprête à pousser en production.
Mais la pull request manque de trois choses :
- couverture de tests
- plan de rollback
- test de non-régression
Sans gouvernance, le déploiement peut passer.
Les échecs de paiement apparaissent des heures plus tard. Les clients sont impactés. L'ingénieur d'astreinte effectue un rollback manuel. L'incident devient un autre post-mortem.
Avec gouvernance, la barrière de workflow s'exécute avant le déploiement.
Elle renvoie :
risk level: high
proof pack missing
deployment blocked
L'agent ne fait pas que journaliser davantage. Il est contraint de s'arrêter au bon moment.
C'est la valeur de la gouvernance pré-action.
8. Les bonnes métriques pour la gouvernance des agents
Une couche de gouvernance ne devrait pas seulement compter les journaux.
Elle devrait mesurer si la flotte devient plus sûre, plus cohérente et plus facile à auditer.
Les métriques utiles incluent :
- Couverture des actions : combien d'actions à fort impact passent par une barrière
- Taux de complétion des preuves : combien d'actions incluent la preuve requise avant exécution
- Taux de clôture des résultats : combien de décisions sont closes avec un résultat réel
- Prévention des échecs répétés : à quelle fréquence les schémas d'échec connus sont évités
- Gravité de la dérive : à quel point les agents s'éloignent des workflows approuvés
- Taux de faux positifs : à quelle fréquence la barrière bloque trop
- Taux de faux négatifs : à quelle fréquence les actions dangereuses passent à travers
- Temps de reconstruction d'audit : combien de temps il faut pour expliquer une décision
- Précision de la révision humaine : si l'approbation humaine est utilisée pour les bonnes actions
La gouvernance est utile lorsqu'elle réduit les rollbacks, prévient les incidents répétés, réduit les révisions inutiles et facilite la preuve du comportement des agents.
Sinon, elle devient du théâtre de conformité.
9. La couche de gouvernance comporte aussi des risques
Une couche de gouvernance peut aussi échouer.
Elle peut être mal configurée. Les politiques peuvent devenir obsolètes. Les preuves peuvent être incomplètes. Les barrières peuvent trop bloquer. Les attaquants peuvent cibler le plan de contrôle. Si elle stocke trop de données sensibles, elle devient un point de concentration des risques.
La couche de gouvernance elle-même a donc besoin de discipline :
- Privilège minimal par défaut Les agents ne doivent recevoir que les permissions dont ils ont besoin, pour la durée dont ils ont besoin.
- Échec fermé pour les actions à fort impact Si l'action peut causer un préjudice grave, une preuve manquante doit arrêter l'exécution.
- Échec progressif pour l'automatisation à faible risque Toutes les actions ne méritent pas le même niveau de friction.
- Preuves lisibles par l'humain, politique lisible par la machine Les opérateurs doivent comprendre la décision. Les systèmes doivent l'appliquer.
- Apprentissage à partir des résultats réels Sans clôture des résultats, le système accumule des journaux, pas du jugement.
10. Conclusion
Les agents IA poussent les logiciels vers un nouveau modèle opérationnel.
Ils peuvent choisir des outils, coordonner avec d'autres agents, modifier des systèmes et créer des conséquences.
Dans ce modèle, la gouvernance n'est pas une couche ajoutée après le déploiement. Elle appartient à l'environnement d'exécution.
La mémoire, l'observabilité, l'évaluation et la révision humaine sont toutes importantes. Mais chacune ne résout qu'une partie du problème.
Une couche de gouvernance les relie en une boucle d'action responsable :
politique avant action, preuve avant exécution, autorité pendant l'action, résultat après l'action, apprentissage dans toute la flotte
C'est la thèse derrière Marrow.
Les flottes d'agents IA n'ont pas simplement besoin de se souvenir davantage.
Elles ont besoin d'un meilleur jugement avant d'agir.
Références
- NIST. Cadre de gestion des risques de l'IA
- NIST. Profil d'IA générative, NIST AI 600-1
- OCDE. Principes d'IA de l'OCDE
- Service d'assistance de la loi européenne sur l'IA. Article 9 : Système de gestion des risques
- Service d'assistance de la loi européenne sur l'IA. Article 12 : Tenue de registres
- Service d'assistance de la loi européenne sur l'IA. Article 14 : Supervision humaine
- Service d'assistance de la loi européenne sur l'IA. Article 17 : Système de gestion de la qualité
