MCP n'est pas un connecteur, mais votre interface de gouvernance pour l'ère des agents

Le problème du cadrage : le terme « connecteur » minimise la décision que vous prenez réellement

Lorsqu'Anthropic a présenté le protocole de contexte de modèle (MCP) en novembre 2024 comme norme ouverte pour connecter les systèmes d'IA aux sources de données et aux outils métier, l'industrie a réagi comme à son habitude face à une nouvelle spécification d'intégration : elle l'a classée MCP dans la catégorie « infrastructure ». Adaptateurs, protocoles de transport, une solution simple pour éviter de développer des interfaces spécifiques pour chaque modèle et chaque outil. Tout cela true, et sans intérêt pour les DSI, les DTO et les RSSI.

Voici le changement de perspective essentiel pour une entreprise. Dès qu'un agent peut accéder à un outil qui consulte vos données clients ou écrit dans vos systèmes d'information, vous créez un nouveau point de contrôle, que vous l'ayez nommé ou non. MCP est l'endroit où ce point de contrôle peut être explicité. Il ne s'agit pas simplement de la manière dont l'agent accède à vos outils ; il s'agit de décider qui appelle, sous quelle identité, quels outils sont visibles, comment chaque appel est enregistré et quel est le coût autorisé pour chaque appel. Ce sont des questions de gouvernance, et non de connectivité.

Si vous considérez MCP comme une simple fonctionnalité de connectivité, vous optimiserez le mauvais aspect : la couverture, le nombre d'intégrations, le délai avant le premier appel. Considérez-le comme une plateforme de gouvernance et vous optimiserez ce qui détermine réellement la sécurité du déploiement à grande échelle des agents : une interface unique, standardisée et auditable où la politique est appliquée une seule fois et respectée partout.

Pourquoi les « nombreuses intégrations personnalisées » recréent-elles discrètement la gouvernance N fois ?

La plupart des entreprises n'abordent pas l'ère des agents sans avoir de solution miracle. Ils arrivent avec un ensemble d'intégrations ponctuelles : un connecteur sur mesure ici, un compte de service là, un wrapper API développé par une équipe il y a deux trimestres et dont personne ne se souvient vraiment. Chacune de ces intégrations était une décision locale raisonnable. Collectivement, elles posent un problème de gouvernance, car chacune réimplémente l'identité, l'autorisation, la journalisation et le contrôle des débits/coûts selon ses propres spécificités, voire en omet certaines.

Trois modes de défaillance suivent de manière prévisible. Premièrement, les dérives d'identité : une intégration fonctionne comme un compte de service partagé, une autre usurpe l'identité de l'utilisateur final, une troisième utilise une clé de longue durée créée par quelqu'un qui a depuis changé d'équipe - alors "qui a fait ça ?" a N réponses différentes, aucune n’est complète. Deuxièmement, l’autorisation se fragmente, car les règles régissant ce qu’un outil peut faire résident dans N bases de code avec N cadences de révision ; un contrôle que vous avez serré à un endroit reste silencieusement desserré à un autre. Troisièmement – ​​la finance et l’audit ressentent en premier – les chiffres dérivent, car la même question répondue via deux voies d’intégration renvoie deux réponses. Une fois que les parties prenantes cessent de faire confiance aux chiffres, le programme d’agents cesse d’avoir de l’importance.

L'alternative standardisée n'est ni magique ni gratuite, mais elle transforme radicalement le travail. Au lieu de gérer N intégrations N fois, vous gérez une seule interface et exposez les outils via celle-ci de manière ciblée. L'identité est centralisée. L'autorisation est une propriété de l'interface, et non une habitude de chaque connecteur. La journalisation est uniforme, garantissant ainsi une traçabilité fiable. Enfin, les chiffres cessent de dériver car leur calcul est unifié.

Identité et contexte du locataire : décision prise à l'entrée, et non dans l'outil

La première question à laquelle une interface de gouvernance doit répondre est celle de l'autorité à l'origine d'un appel. Dans un contexte SaaS mutualisé, la situation est complexe, car deux éléments distincts entrent en jeu : l'identité de l'appelant (quel agent, pour quel utilisateur ou service) et le contexte du locataire dans lequel l'appel s'effectue (quelles données et quels droits client s'appliquent). Leur confusion engendre le problème classique de l'agent incompétent, où un agent légitimement authentifié pour un usage précis se voit attribuer des privilèges qu'il n'aurait jamais dû posséder.

La bonne pratique consiste à extraire le contexte du locataire de la liaison côté serveur, et non des informations fournies par la session de l’appelant. Dans notre implémentation, le niveau client qui contrôle l’accès aux fonctionnalités est déterminé à partir du contexte du locataire, jamais lu à partir de la session de l’appelant. Ceci afin d’empêcher un appelant d’étendre son influence en présentant une session plus riche. L’identité indique qui est à l’origine de la requête ; le contexte du locataire définit l’univers de données et les droits nécessaires au calcul de la réponse. Ces deux éléments sont définis dès le départ, avant même l’exécution de tout outil.

C'est également ici que vous indiquez que les agents ne sont pas des utilisateurs. Un humain dans une console a des yeux, des hésitations et un manager. Un agent a une boucle. L'identité et le contexte que vous lui accordez doivent refléter le fait qu'il peut agir plus rapidement et plus littéralement que n'importe quelle personne que vous avez provisionnée.

Autorisation par outil : l’exposition est un choix, pas un comportement par défaut

Le défaut le plus courant et le plus dangereux dans les premiers déploiements d’agents est l’exposition tout ou rien : connectez l’agent à la plateforme et laissez-le atteindre tout ce que les informations d’identification sous-jacentes peuvent atteindre. Pratique en démo, indéfendable en production. Une surface de gouvernance traite la visibilité et l'autorisation de chaque outil comme une décision délibérée et révisable.

Concrètement, l'autorisation doit être multiaxiale plutôt qu'un simple interrupteur marche/arrêt. Nous utilisons un modèle à trois axes : la portée et le niveau, ce dernier étant déterminé par le contexte du locataire comme décrit précédemment. Ainsi, un outil donné n'est accessible que si la portée de l'appelant le permet et si le niveau du locataire l'inclut. Le deuxième axe souligne que la capacité ne dépend pas seulement de l'entité qui la demande, mais aussi des droits d'accès du client en vigueur. Cela garantit l'intégrité de la visibilité : l'ajout d'un nouvel outil au catalogue ne le rend pas automatiquement accessible à tous les agents de chaque entreprise.

Le modèle mental à donner à vos architectes est un catalogue, pas un standard téléphonique. Chaque outil du catalogue a été sélectionné en fonction des personnes autorisées à l'utiliser et des conditions d'utilisation. Les outils dont aucun agent n'a actuellement besoin ne figurent tout simplement pas dans le catalogue. Le modèle « tout ou rien » relève d'une économie false ; seule une approche « délibérée par outil » résiste à un audit réel.

Écritures en cas d'échec : l'asymétrie entre la lecture et l'action

Les lectures et les écritures ne sont pas équivalentes, et votre interface de gouvernance ne doit pas les assimiler. Une lecture erronée renvoie des données obsolètes ou vides ; ces données sont récupérables, souvent de manière invisible. Une écriture erronée modifie un système d'information, envoie un message à un client réel ou effectue un transfert d'argent. Le coût d'une erreur étant asymétrique, le comportement par défaut doit l'être également.

La règle à laquelle nous tenons est que les outils d'écriture échouent à la fermeture. Si l'autorisation est ambiguë, si le contexte du locataire ne peut pas être résolu proprement, si une garde ne peut pas être évaluée, l'écriture n'a pas lieu. C'est l'opposé de la valeur par défaut motivée par la commodité dont de nombreuses intégrations héritent, où une vérification non évaluée se résout à "autoriser" afin que le chemin heureux reste fluide. Grâce à l'ouverture en cas d'échec, vous découvrez, des semaines plus tard, qu'un agent écrivait dans des conditions que personne n'avait jamais approuvées. Pour tout ce qui mute ou touche un client, la valeur par défaut est le refus, et la charge de la preuve incombe à l'appel pour démontrer que cela est autorisé.

Il existe une dimension culturelle. Les ingénieurs optimisent le bon fonctionnement ; la sécurité optimise le bon fonctionnement. Une interface de gouvernance permet d’affirmer que le pire scénario – une écriture non autorisée exécutée silencieusement – ​​est inacceptable, même au prix du refus occasionnel d’une écriture qui aurait été légitime.

Journaux budgétaires et mécanisme d'arrêt d'urgence : la maîtrise des coûts est un levier de contrôle essentiel.

Les agents introduisent une catégorie de risque que les intégrations traditionnelles n'entraient généralement pas en jeu : les dépenses autonomes. Une boucle d'appel d'outils peut, par le biais d'un bug ou d'une invite malveillante, les appeler bien plus souvent que prévu, épuisant ainsi le budget API, déclenchant des frais supplémentaires ou inondant les clients de requêtes. Le contrôle des coûts doit donc être intégré à la gouvernance, et non ajouté a posteriori sous forme d'alerte de facturation déclenchée une fois le mal fait.

Notre système repose sur un budget prévisionnel évalué avant chaque dépense, avec des limites par exécution, par jour et sur un cycle glissant de 30 jours, ainsi qu'un mécanisme d'arrêt automatique vérifié avant l'exécution. Notez l'ordre : le budget et le mécanisme d'arrêt d'urgence sont évalués avant les dépenses, et non rapprochés après. Une alerte signalant un dépassement budgétaire est une analyse a posteriori ; un registre refusant l'appel pour dépassement budgétaire est un contrôle. Les trois horizons temporels sont importants car les modes de défaillance se manifestent différemment : une boucle incontrôlée dépasse la limite par exécution, une planification mal configurée dépasse la limite journalière, et une dérive progressive n'apparaît que sur une période de 30 jours.

Le coupe-circuit mérite une place à part entière dans la conception. C'est la commande à utiliser lorsque vous ne comprenez pas encore ce qui se passe et que vous devez interrompre l'activité immédiatement. Évalué avant exécution, il s'agit d'un disjoncteur, et non d'un outil de nettoyage. Chaque programme agent doit pouvoir répondre instantanément à une question : comment l'arrêter ? Si la solution implique de contacter trois équipes et de révoquer les clés manuellement, vous n'avez pas de solution miracle, mais un espoir.

Audit et rédaction : périmètre, durée et observabilité définis

Une gouvernance non observable n'est pas de la gouvernance ; c'est une intention. La dernière couche de la surface est celle qui permet de prouver a posteriori tout ce qui se trouve au-dessus. Les clés d'accès des agents doivent être limitées aux outils dont ils ont réellement besoin et avoir une durée de validité limitée afin que leur impact diminue progressivement et disparaisse plutôt que de persister indéfiniment. Une clé permettant tout faire indéfiniment est l'élément le plus fréquemment retrouvé lors d'une analyse d'incident.

De même, la piste d'audit doit respecter les données qu'elle enregistre. Nous appliquons une procédure de rédaction par appel afin que le journal conserve la trace des événements (outil utilisé, identité et contexte client, et résultat obtenu) sans devenir une copie secondaire des données sensibles que les contrôles sont censés protéger. Un journal d'audit qui accumule discrètement les enregistrements clients en clair n'est pas un contrôle ; c'est une nouvelle source de risques, même si elle est présentée comme anodine.

Ensemble, ces propriétés (clés de portée, limites temporelles, rédaction par appel, audit uniforme) permettent à un RSSI de répondre aux questions fréquemment posées après un incident : quelles étaient les possibilités de cette identification ? Pendant combien de temps ? Quelles actions a-t-elle réellement effectuées ? Et pouvons-nous le prouver sans divulguer davantage d'informations lors de la preuve ?

Lier cela à une gestion continue des risques et à une transparence totale sur les points restants

Rien de tout cela n'est une configuration ponctuelle. Le cadre de gestion des risques liés à l'IA du NIST (AI RMF 1.0) stipule clairement que la gestion des risques liés à l'IA est un processus continu, et non une simple liste de contrôle à remplir une fois pour toutes. Une plateforme de gouvernance est précieuse précisément parce qu'elle centralise les actions nécessaires à ce processus continu : lorsqu'un nouveau risque apparaît, vous ajustez les autorisations, les budgets, l'exposition ou l'audit via une interface unique, au lieu de devoir gérer les modifications à travers de multiples intégrations. La standardisation rend la gouvernance continue concrète et non plus un simple objectif. C'est également pourquoi une décision réfléchie en matière d'exposition est doublement rentable : une première fois lors de sa prise, et une seconde fois à chaque réévaluation.

Soyez honnête quant au risque résiduel, car votre conseil d'administration le sera également. Une gouvernance efficace réduit la surface d'attaque et rend l'activité auditable ; elle ne rend pas les agents infaillibles. Une injection rapide peut toujours tenter d'orienter un agent légitimement autorisé vers un usage abusif d'apparence légitime. Un outil délibérément exposé peut toujours être utilisé à mauvais escient dans le cadre de ses permissions. Les budgets limitent les coûts, mais pas le jugement. L'étude Deloitte « État de l'IA en entreprise » a démontré à maintes reprises le décalage entre les ambitions en matière d'IA et la maturité opérationnelle nécessaire pour la gouverner — et c'est précisément dans ce décalage que résident ces risques résiduels. La bonne réponse n'est pas de prétendre que le décalage est comblé, mais de le réduire, de le rendre observable et de le gérer en continu.

Nous avons bâti notre plateforme sur cette conviction. SocialHub.AI expose des outils de la couche sémantique sur MCP via un transport HTTP en flux continu, accessible depuis des agents tels que Claude, GitHub Copilot et Microsoft 365 Copilot. Les contrôles décrits ici sont appliqués à l'interface plutôt que dispersés entre les connecteurs : autorisation à trois axes avec hiérarchisation selon le contexte du locataire, écritures fermées en cas d'échec, un registre budgétaire par exécution/par jour/sur 30 jours avec un coupe-circuit avant exécution, et des clés d'agent limitées dans le temps et à portée, avec rédaction et audit par appel. C'est cette même discipline de gouvernance qui sous-tend notre travail de fidélisation, grâce auquel nous avons contribué à faire passer la contribution au GMV des membres de McDonald's China d'environ 5 % à 85 %. Des résultats de cette ampleur ne sont possibles que si l'interface d'accès aux données est fiable dès sa conception.

Si vous devez déterminer comment les agents interagiront avec vos systèmes d'information, la question à poser à votre équipe n'est pas « quel connecteur », mais plutôt « où sont gérées l'identité, l'autorisation, la journalisation et les coûts, et est-ce à un seul endroit ou à plusieurs endroits ? » Si vous souhaitez voir à quoi ressemble concrètement une interface MCP axée sur la gouvernance, réservez une démonstration ou consultez notre présentation sur /platform/ai-frontier.