← Retour aux articles
Défis

Gouvernance Vérifiable pour l'IA Agentique : Des Principes Consultatifs aux Watchdogs en Runtime

Par Marc Molas·23 mars 2026·11 min de lecture

L'écart de gouvernance dans l'IA agentique est structurel, pas philosophique. La plupart de la gouvernance d'IA — principes, codes d'éthique, model cards, frameworks consultatifs — décrit comment l'IA devrait se comporter. Rien de cela n'empêche l'IA de faire autre chose quand personne ne regarde. Pour les modèles prédictifs sans effets secondaires dans le monde réel, cet écart est tolérable. Pour les agents qui agissent via des tool calls — envoi d'emails, exécution de trades, modification de données de production, dépense d'argent — il ne l'est pas.

Le récent article Verifiable Governance Architecture (VGA) for Organisations and Teams with Human and AI Employees (Fradelos, janvier 2026) nomme directement cet écart : « beaucoup de principes de gouvernance sont consultatifs, alors que les agents modernes agissent via des tool calls avec des conséquences réelles. » Il propose ensuite un pattern d'ingénierie pour le fermer : un Watchdog runtime qui médie les tool calls avec sémantique fail-close (default-deny), gouvernance encodée en policy-as-code (OPA/Rego), et un magasin d'evidence immuable qui empêche l'IA d'halluciner sa propre conformité.

C'est le pattern de design dont le domaine a besoin depuis un moment. Ça vaut la peine de le comprendre en détail parce que les choix sont non évidents et les modes de défaillance des alternatives plus faibles sont réels.

L'Idée Centrale : Frontières d'Action, Pas Comportement Moyen

Trois approches de gouvernance dominent la pratique actuelle :

  1. Garde-fous de prompt : ajouter des instructions de sécurité au system prompt.
  2. Supervision de modèle de récompense : entraîner les modèles à refuser certaines actions.
  3. Supervision de processus : insérer des relecteurs humains aux points de décision.

Les trois améliorent le comportement moyen. Aucun d'eux, par lui-même, ne fournit des garanties de frontière d'action pour des outils irréversibles.

C'est l'idée qui fait que le reste du pattern suit. Un agent qui a été entraîné à « ne pas exfiltrer les données client » n'exfiltrera pas les données client en moyenne. Il peut exfiltrer les données client dans des conditions adversariales, dans des distributions de prompt inhabituelles, dans des séquences de tool call que personne n'a anticipées, ou simplement parce que la distribution d'entraînement ne couvrait pas le scénario spécifique. Les améliorations moyennes ne sont pas des garanties de sécurité pour des actions irréversibles.

Le pattern VGA part de la posture inverse : n'essayez pas de rendre l'agent fiablement bon. Faites que les actions que l'agent peut prendre soient contraintes par quelque chose que l'agent ne peut pas contourner.

Le Watchdog

Le Watchdog est la couche runtime qui médie chaque tool call avant qu'il atteigne l'outil. Chaque action que l'agent veut prendre passe par lui. Le Watchdog a trois propriétés qui le distinguent des alternatives plus laxistes :

Fail-close (default-deny)

Si le Watchdog ne peut pas vérifier positivement qu'une action est permise, l'action est refusée. C'est l'opposé de la plupart des patterns de garde-fous en production, qui sont fail-open par défaut — si la règle ne match pas, l'action procède.

Fail-close n'est pas négociable pour l'IA agentique spécifiquement parce que le mode de défaillance de fail-open est « l'agent a fait quelque chose que personne n'a autorisé quand la politique n'anticipait pas le cas ». Fail-close signifie que le mode de défaillance est « l'agent s'est arrêté et a demandé », ce qui est récupérable.

Médie la surface d'outils, pas la surface du modèle

Le Watchdog ne s'assoit pas entre l'utilisateur et le modèle. Il s'assoit entre le modèle et les outils. Cela importe parce que le raisonnement du modèle, le contenu du prompt et les sorties intermédiaires sont tous dans la portée pour la modération de contenu, mais ils ne sont pas la frontière d'action. La frontière d'action est le tool call. Mettre le Watchdog à la surface d'outils signifie que la politique appliquée est la politique qui compte vraiment.

Autorisation multi-parties pour actions sensibles

Certaines actions exigent plus d'un approbateur. Le Watchdog peut l'exprimer naturellement : un tool call pour « transférer >10k$ » exige un evidence packet signé à la fois par l'agent et par un approbateur humain avant que l'appel procède. Un tool call pour « modifier le schéma de la base de données de production » exige un pipeline CI/CD qui a exécuté les vérifications de sécurité de migration. L'architecture est la même ; la politique varie selon la sensibilité.

La Matrice MVV : Lier les Lois aux Artefacts Vérifiables

La deuxième idée centrale est la matrice de Vérification Minimale Viable (MVV). Elle lie chaque règle de gouvernance à un artefact spécifique vérifiable et à une cadence spécifique à laquelle cet artefact doit être produit.

Sans MVV, les règles de gouvernance deviennent aspirationnelles. « Le système doit être auditable » sonne bien et ne vérifie rien. Avec MVV, « le système doit être auditable » se traduit en artefacts spécifiques :

  • Un log immuable de chaque tool call avec la décision de politique attachée.
  • Un evidence packet signé liant intention → tool call → résultat.
  • Un rapport d'attestation hebdomadaire d'un auditeur désigné.
  • Une revue externe trimestrielle avec scénarios red-team.

Chaque artefact a un producteur, format et cadence définis. La vérification de la conformité se réduit à « l'artefact a-t-il été produit à temps, dans le bon format, avec des signatures valides ? » — ce qu'un pipeline CI/CD peut vérifier.

C'est ce que « gouvernance-comme-code » signifie réellement en pratique. Ce ne sont pas seulement des politiques en Rego. C'est l'evidence vérifiable de l'application des politiques, produite par le runtime, sur un calendrier, dans des formats qu'un régulateur pourrait auditer.

Pourquoi le Magasin d'Evidence Doit Être Immuable

Le choix de design le plus subtil est le magasin d'evidence immuable. Le Watchdog produit un enregistrement de chaque décision ; cet enregistrement va dans un magasin que l'agent lui-même ne peut pas modifier ou antidater.

La raison est ce que l'article appelle des hallucinations de gouvernance : le mode de défaillance où l'agent produit un rapport de conformité d'apparence plausible qui ne correspond pas à ce qui s'est réellement passé. Si le magasin d'evidence est modifiable par quoi que ce soit à la portée de l'agent, l'agent (délibérément ou comme comportement émergent) peut produire des preuves de conformité qui ne reflètent pas les actions prises.

La correction est structurelle : la conformité dépend du magasin d'evidence, le magasin d'evidence est modifiable seulement par le Watchdog, le Watchdog est en dehors de la surface d'outils de l'agent. Même si l'agent produit un résumé de conformité parfait, l'audit peut le comparer au magasin immuable et détecter la divergence.

C'est le même principe que séparer l'autorité d'écriture de base de données du code d'application dans tout système sérieux de production. La nouveauté est de l'appliquer aux preuves de gouvernance d'IA.

Droits de Décision Dépendants de l'Ancienneté

La quatrième idée est opérationnellement importante : les agents ont une ancienneté. Un agent « junior » a un accès aux outils étroit et exige une autorisation multi-parties pour la plupart des actions non triviales. Un agent « professionnel » a un accès plus large. Un agent « senior » peut autoriser des actions de portée plus étroite au nom d'autres.

Cela ressemble au contrôle d'accès d'entreprise parce que c'est ça. Le but est de l'appliquer spécifiquement aux agents IA, avec la même rigueur et la même auditabilité que le contrôle d'accès basé sur les rôles humains. En pratique cela signifie :

  • Les nouveaux agents commencent en junior avec un accès aux outils contraint. Ils gagnent (ou sont configurés en) une portée plus large seulement après avoir passé une vérification spécifique.
  • L'accès aux outils est la frontière, pas « l'entraînement du modèle » ou « le system prompt ». Deux agents utilisant le même modèle peuvent avoir des droits de décision très différents selon leurs politiques d'accès.
  • Les promotions sont explicites et auditées. Quand un agent passe de portée professionnelle à senior, le changement est enregistré, l'evidence est conservée, le rollback est direct.

C'est la partie que la plupart des systèmes agentiques en production en 2026 se trompent encore. Ils ont un seul rôle d'agent avec tous les outils, et la frontière est un system prompt. Le pattern d'ancienneté est une représentation plus honnête de ce qui est réellement nécessaire.

Mapping aux Régimes de Conformité Réels

Le pattern est explicitement conçu pour mapper sur les obligations de conservation des registres et de robustesse du EU AI Act. Le magasin d'evidence satisfait la conservation des registres. Le Watchdog fail-close satisfait la robustesse. La matrice MVV satisfait les exigences d'auditabilité. L'autorisation multi-parties satisfait les exigences de supervision humaine pour les systèmes à haut risque.

Ce n'est pas accidentel. L'architecture est conçue pour que la conformité devienne une propriété des artefacts produits, pas une question de « l'agent s'est-il bien comporté ». C'est la seule manière durable de se conformer à des règlements qui exigent des preuves plutôt que de la confiance.

Ce Que Ça Signifie Si Vous Construisez des Systèmes Agentiques Maintenant

Actions pratiques pour toute équipe livrant de l'IA agentique en 2026 :

  1. Déplacez l'application des politiques à la surface d'outils. Si vos garde-fous vivent dans le system prompt, vous avez de la gouvernance consultative. Mettez un médiateur fail-close entre le modèle et les outils.

  2. Adoptez policy-as-code. OPA/Rego est le choix le plus mature ; l'outil spécifique compte moins que la discipline. Les politiques en code peuvent être revues, versionnées, testées en CI et auditées. Les politiques en prompts ne le peuvent pas.

  3. Construisez le magasin d'evidence avant de mettre à l'échelle. Un log immuable et signé d'actions d'agent est beaucoup plus difficile à rétroadapter qu'à concevoir dès le début. Même si vous n'avez pas encore besoin de l'audit, la valeur de débogage opérationnel à elle seule justifie le coût.

  4. Appliquez l'ancienneté aux agents. Les nouveaux agents obtiennent une portée étroite. L'expansion de portée est explicite, auditée et réversible. N'exécutez pas tous vos agents au même niveau d'autorisation.

  5. Exécutez l'autorisation multi-parties sur les actions irréversibles. Tout ce qui est financier, tout ce qui touche aux données client, tout ce qui modifie la production. Le coût de performance de l'autorisation multi-parties est bien plus petit que le coût d'une mauvaise action.

Ce Que VGA Ne Fait Pas

Deux limites honnêtes valent la peine d'être nommées.

Cela ne rend pas le modèle meilleur. VGA borne ce que l'agent peut faire ; cela ne change pas comment l'agent raisonne dans ces bornes. Améliorer le comportement du modèle reste important — mais c'est maintenant un problème d'optimisation dans des bornes de sécurité connues, pas le mécanisme de sécurité lui-même.

Cela coûte de la latence. Chaque tool call passe par l'évaluation de politique. Avec des bundles OPA bien réglés, c'est des millisecondes, mais ce n'est pas zéro. Pour les chemins sensibles à la latence, vous devrez concevoir avec soin — typiquement avec des décisions mises en cache pour les chemins chauds et une évaluation par requête pour les sensibles.

Le coût est réel. Le coût de ne pas l'avoir est beaucoup plus élevé, et il apparaît en tant que gros titres.

Le passage de la gouvernance consultative à vérifiable pour l'IA agentique se produit ; la seule question est de savoir si votre organisation est en avance ou en retard sur la courbe. Le pattern d'architecture est ici. L'adopter n'est plus un projet de recherche.


Source : Fradelos, G. Verifiable Governance Architecture (VGA) for Organisations and Teams with Human and AI Employees (Genève, 9 janvier 2026). SSRN 6306840.

Vous construisez des systèmes agentiques et avez besoin de capacité d'ingénierie qui construit déjà avec policy-as-code, watchdogs fail-close et magasins d'evidence immuables ? Parlez à un CTO sur le déploiement d'un squad nearshore avec la bonne discipline pour la gouvernance d'IA vérifiable.

Prêt à construire votre équipe d'ingénierie ?

Parlez à un partenaire technique et déployez des développeurs validés par des CTOs en 72 heures.