Un agent qui peut écrire dans des systèmes métier a besoin de plus qu’un modèle et une liste d’outils. Il lui faut une couche d’actions dotée de règles : un endroit unique où les outils sont définis et versionnés, des contrôles exécutés avant tout changement, un humain qui valide chaque écriture, une protection contre la double exécution, une trace qui permet de rejouer toute décision, et une identité qui ne dépasse jamais les droits de l’utilisateur à l’origine de la demande. Ce guide décrit cette couche avec le Model Context Protocol (MCP).

Pourquoi les agents ont besoin d’une couche d’actions

Lire présente peu de risques ; écrire, si. Si un agent appelle directement les API métier, chaque intégration décide seule de ce que l’agent peut faire, de la manière dont il est autorisé et de ce qui est journalisé. Le résultat est un comportement impossible à relire en un seul endroit et des erreurs impossibles à rejouer. Une couche d’actions rassemble tout cela dans un service unique : l’agent propose, la couche décide.

Un serveur d’actions MCP unique

MCP est un protocole ouvert pour exposer des outils aux modèles d’IA. Servir toutes les actions des agents via un serveur d’actions MCP unique donne aux agents une interface uniforme et à l’organisation un endroit unique où ajouter des contrôles. C’est le serveur, et non l’agent, qui détient les identifiants des systèmes en aval et décide si un appel peut se poursuivre.

Des manifestes d’outils versionnés

Chaque outil est décrit par un manifeste : son nom et son rôle, ses schémas d’entrée et de sortie, s’il lit ou écrit, et quels contrôles s’appliquent. Versionnez les manifestes. Quand un outil change, les agents et les évaluations se calent sur une version : un changement de comportement devient une livraison délibérée plutôt qu’un effet de bord, et les anciennes décisions s’interprètent au regard du manifeste en vigueur au moment où elles ont été prises.

Validation humaine à chaque écriture

Tout outil qui modifie un état exige qu’une personne approuve l’action concrète, c’est-à-dire les paramètres exacts et non un résumé, avant son exécution. Les lectures s’exécutent sans approbation.

C’est plus lent qu’une autonomie totale, par conception. Cela garde une personne responsable de chaque changement et offre à l’agent une manière sûre de se tromper : une proposition rejetée coûte un clic, pas un incident.

Idempotence et préconditions

Les réseaux réessaient et les utilisateurs cliquent deux fois. Donnez à chaque écriture une clé d’idempotence pour que l’exécuter deux fois ait l’effet de l’exécuter une fois. Attachez des préconditions, l’état que l’action suppose (par exemple « la fiche est toujours en brouillon »), et faites-les vérifier par le serveur au moment de l’exécution. Un échec de précondition signifie que le monde a changé entre la proposition et l’approbation, et la bonne réponse est de reproposer, pas de forcer l’écriture.

Un journal de décisions rejouable

Enregistrez chaque proposition, approbation, refus et exécution dans un journal en append-only : qui ou quoi l’a proposée, la version du manifeste d’outil, les entrées, les contrôles exécutés et le résultat. Append-only signifie que les entrées ne sont jamais modifiées ; les corrections sont de nouvelles entrées.

Pour les exigences d’audit et de conservation, exportez le journal vers un stockage en écriture unique (WORM) comme S3 Object Lock en mode compliance, afin que même les administrateurs ne puissent pas altérer l’historique pendant la durée de conservation. Avec ce journal, toute décision peut être rejouée et expliquée a posteriori.

Identité : hériter des droits de l’utilisateur

L’agent ne doit détenir aucun privilège propre au-delà de ceux de la personne pour qui il agit. Avec OAuth2 Token Exchange, la plateforme échange le jeton de l’utilisateur contre un jeton restreint pour l’appel en aval, de sorte que le système en aval voit, et applique, les droits de l’utilisateur. Les workloads eux-mêmes utilisent des identités cloud de courte durée, propres à chaque service, plutôt que des secrets partagés. La règle est simple : l’IA peut faire ce que l’utilisateur peut faire, jamais plus.

En pratique

Sur la plateforme d’ENSO, j’ai spécifié des actions d’agents via un serveur d’actions MCP unique avec des manifestes d’outils versionnés, une validation humaine de chaque écriture, des contrôles d’idempotence et de préconditions, et un journal de décisions en append-only qui rend chaque décision de l’IA rejouable, avec un export WORM vers S3 Object Lock. L’IA hérite des droits de l’utilisateur via OAuth2 Token Exchange (Keycloak, OIDC) et des identités de workload IRSA. L’architecture complète est décrite dans l’étude de cas ENSO.

Compromis et limites

La validation humaine de chaque écriture limite le débit et convient mal à l’automatisation à fort volume et à faible risque. On peut la relâcher plus tard pour certains outils dont le risque est faible et que le manifeste désigne.

Une couche d’actions est un service de plus à construire et à garder disponible. Et le journal n’est utile que par la discipline qui l’entoure : définissez la conservation, l’accès et l’export avant d’en avoir besoin.