Gouvernance des agents IA sur plusieurs plateformes

La plupart des entreprises n'ont pas décidé d'adopter des agents IA sur cinq plateformes. Cela leur est arrivé. Microsoft Copilot est arrivé avec la suite de productivité. ServiceNow a intégré Now Assist dans la file d'attente des tickets. Salesforce a activé Agentforce au sein du CRM. D'autres plateformes de données et SaaS ont commencé à exécuter des agents à côté des systèmes d'enregistrement. Chaque plateforme a apporté son propre environnement d'exécution IA — et, discrètement, sa propre approche de gouvernance qui s'arrête aux limites de la plateforme.

Il en résulte un fossé de gouvernance qu'il est difficile pour un seul fournisseur de plateforme applicative de combler seul. Lorsqu'un agent au sein d'une plateforme appelle une API, qui l'a autorisé ? Lorsqu'un agent dans une autre plateforme résume un document sensible, quelle politique a régi la réponse ? Et lorsqu'un agent se comporte mal en production, qui peut le contenir rapidement — sans avoir à coordonner les actions sur plusieurs consoles de fournisseurs ou files d'attente de support ?

Il ne s'agit pas d'un risque d'avenir. C'est la réalité opérationnelle pour toute organisation ayant adopté plus d'une plateforme IA de manière indépendante — ce qui est de plus en plus courant dans les grandes entreprises.

La nature du problème

Avant de parler de solution, il est utile d'être précis sur les raisons pour lesquelles c'est réellement difficile. La difficulté est structurelle, et elle se manifeste simultanément à quatre niveaux.

Et il y a un cinquième problème qui ne devient visible qu'au moment où un utilisateur essaie réellement de faire quelque chose avec un agent tiers : la taxe sur les identifiants.

La taxe cachée sur les identifiants

Considérons une invite de routine envoyée à un agent tiers officiel installé au sein d'un assistant de type Copilot. La première fois qu'un utilisateur l'utilise, l'agent ne peut pas répondre tant que l'utilisateur ne s'est pas connecté directement à ce service tiers.

Ce n'est pas un bug. C'est la seule architecture sûre lorsque chaque agent est un produit vendu séparément. Mais cumulé sur l'ensemble de l'inventaire d'outils d'une entreprise, cela a de réelles conséquences opérationnelles :

• Friction par utilisateur et par outil. Chaque employé réautorise chaque agent la première fois qu'il l'utilise. Multipliez par l'effectif, puis par l'inventaire des outils.
• Prolifération des jetons. Les jetons OAuth pour chaque service connecté finissent par être dispersés dans les magasins d'identité des utilisateurs. La conformité devient une question par fournisseur au lieu d'une piste d'audit unique.
• Absence de révocation centrale. Lorsqu'un contrat est modifié ou qu'un incident exige de couper l'accès, l'organisation s'en occupe via chaque relation fournisseur plutôt qu'à un point d'étranglement unique.

‍