Gouvernance des agents IA : politiques, validation humaine et reçus signés

Pourquoi les agents IA exigent-ils une gouvernance que les chatbots n’exigent pas ?

Un chatbot répond. Un agent agit : il rembourse, change un forfait, active une fonctionnalité, invite un utilisateur. La sortie n’est plus un texte qu’une personne lit avant de décider, c’est une modification dans un système réel.

La question change : on ne demande plus « la réponse est-elle bonne ? » mais « cet agent avait-il le droit de le faire, de la part de qui, et peut-on le prouver ensuite ? ».

À quelles questions une couche de gouvernance doit-elle répondre pour chaque action ?

J’aime la façon dont TrustRail cadre le sujet. Pour chaque opération protégée, la couche doit répondre à cinq questions : quel agent l’a demandée, qui a autorisé cet agent, quelles limites s’appliquent, si l’action a été autorisée, bloquée ou mise en attente d’approbation, et quelles preuves appuient le résultat.

Remarquez ce qui manque dans cette liste : le modèle. La gouvernance ne dépend pas de l’intelligence de l’agent ni de la qualité de son prompt. Elle se place entre l’agent et le système qu’il veut modifier, et traite l’agent comme un demandeur non fiable, quel que soit le modèle derrière.

TrustRail est une étude de conception publique. Son README décrit une V1 qui fonctionne sur des bacs à sable synthétiques (un commerçant fictif et un produit SaaS fictif) et précise qu’aucun argent réel ne circule. Ce n’est pas un système de production et je ne le présente pas comme tel : c’est un moyen de rendre les idées concrètes et testables.

Que résout une couche de politiques ?

Une couche de politiques remplace « le prompt dit de ne pas le faire » par une règle évaluée avant chaque action, qu’on ne peut pas discuter. Un prompt est une demande faite au modèle. Une politique est une décision prise en dehors du modèle.

Trois choix de conception comptent plus que les règles elles-mêmes. D’abord, le moteur de politiques doit être pur : à partir d’une demande, d’une délégation et de règles, il renvoie un verdict, sans base de données ni effet de bord, ce qui permet de le tester de façon exhaustive. TrustRail décrit son moteur en ces termes, avec une validation de la chaîne de délégations à côté.

Ensuite, l’autorité doit être déléguée explicitement. Un agent agit au nom d’une personne ou d’une entreprise, et la délégation qui le dit doit être vérifiée à chaque appel, pas supposée. Enfin, le verdict doit avoir trois issues, pas deux. Autorisé et bloqué sont évidents. La troisième, la mise en attente d’approbation, rend la gouvernance utilisable au lieu d’être un frein.

Quand un humain doit-il valider une action d’agent ?

Pas toujours. Si chaque action attend une personne, l’agent devient un formulaire lent et les gens finissent par valider sans lire. Si rien n’attend, vous avez donné un accès en écriture à un acteur que vous ne savez pas expliquer. La réponse consiste à lier le contrôle à la conséquence de l’action.

Le tableau ci-dessous est mon propre cadrage, pas une spécification de TrustRail. Les exemples d’actions sont du type que mentionne le README (remboursements, crédits, changements de forfait, invitations) ; les niveaux et les contrôles sont mon point de départ.

• Placer la limite dans la politique, pas dans les instructions de l’agent.
• Montrer à la personne qui valide la demande, la délégation et la raison de la mise en attente : valider doit être une décision, pas un clic.
• Traiter une tentative bloquée comme une information : elle révèle où le comportement de l’agent et son mandat divergent.

Qu’est-ce qu’un reçu signé, et en quoi est-ce plus qu’un journal ?

Un journal est écrit par le système qui a fait l’action, et celui qui contrôle ce système peut le modifier. Un reçu signé est un enregistrement qu’un tiers peut vérifier sans faire confiance au système qui l’a produit.

Le README de TrustRail décrit des reçus signés en Ed25519 (au format JWS) et un paquet de vérification distinct, et indique qu’un parcours a été vérifié de façon indépendante. Cette séparation est le point essentiel. Si la vérification exige la base qui contient les données, elle prouve peu. Si toute personne disposant de la clé publique peut contrôler un reçu, celui-ci peut être remis à un auditeur, un client ou un collègue comme preuve.

Le reçu est aussi l’endroit où se retrouvent les cinq questions de gouvernance : l’agent demandeur, l’autorité, les limites, le verdict et le résultat, dans un seul enregistrement vérifiable. Il transforme « nous pensons que l’agent a fait ceci » en « voici la preuve ».

Comment un agent doit-il gagner son autonomie ?

L’autonomie doit être un réglage que les preuves font bouger, pas une décision prise une fois au lancement. J’applique la même logique dans NOVA, dont la couche de sécurité et de gouvernance comprend une politique d’autonomie, et dont les actions externes suivent toujours la politique de l’entreprise. NOVA est utilisé par 800 collaborateurs chez Devoteam : à cette échelle, « l’agent peut tout ce que l’outil permet » n’est pas une valeur par défaut acceptable.

Ma séquence de travail, qui est ma méthode et non un standard :

• Commencer en lecture seule, avec toute action à conséquence mise en attente de validation.
• Observer ce que font les validateurs. Les actions qu’ils approuvent sans changement, à chaque fois, sont candidates à une règle fondée sur des limites.
• Élargir la délégation par petits pas, avec des limites explicites, en gardant la possibilité de la retirer.
• La restreindre immédiatement quand les reçus, les erreurs ou les incidents montrent quelque chose d’inattendu.

Que faut-il journaliser pour chaque action d’agent ?

Journalisez assez pour reconstituer la décision, pas seulement le résultat. Une ligne « remboursement réussi » n’est pas une piste d’audit. Voici les éléments que j’exigerais sur chaque action protégée :

• Qui : l’identité de l’agent et la personne ou l’entreprise qui l’a autorisé.
• Quoi : l’opération demandée et ses paramètres.
• Selon quelle règle : la délégation et la version de politique évaluées.
• Le verdict : autorisé, bloqué ou mis en attente, et la raison.
• Qui a validé, quand, et ce que cette personne a vu, si un humain est intervenu.
• Le résultat dans le système cible, avec une clé d’idempotence pour qu’un nouvel essai ne répète pas l’action.
• La signature, pour pouvoir vérifier l’enregistrement plus tard.

Quelle confiance accorder à une étude de conception comme TrustRail ?

Moins qu’à un produit, et c’est la réponse honnête. Le README de TrustRail renvoie à un état d’avancement et à un modèle de menaces qui décrit ce que le projet protège ou non, et précise que son rapport de tests consigne des commandes réellement exécutées, pas des affirmations. Je trouve ce ton plus utile qu’une liste de fonctionnalités, et c’est celui que j’essaie de tenir ici.

Ce que le projet offre aujourd’hui est concret : des SDK TypeScript et Python, un adaptateur MCP exposant get_order, request_refund et get_action_status, des agents d’exemple exécutables et deux cas d’usage synthétiques. Il n’offre pas de preuves issues de clients réels, d’argent réel ou d’un environnement réglementé. Conserver des pistes d’audit est aussi une bonne raison de construire ainsi, car des textes comme le règlement européen sur l’IA poussent les organisations vers la traçabilité, mais une étude de conception n’est pas une réponse de conformité.