MCP en entreprise : architecture, sécurité et gouvernance

Le Model Context Protocol (MCP), ou protocole de contexte pour modèles, standardise la manière dont une application d’intelligence artificielle (IA) découvre et utilise des capacités externes. Son intérêt en entreprise ne réside pas dans une promesse de connexion universelle sans effort, mais dans une séparation plus nette entre le client IA, le serveur MCP, les outils exposés, les ressources consultables et les systèmes métier sous-jacents.

Les entités à gouverner sont précises : un client initie la connexion ; un serveur décrit des capacités ; un outil représente une opération ; une ressource fournit un contenu ; une identité porte des droits ; une passerelle ou un service métier applique les règles réelles. MCP organise l’échange entre ces composants. Il ne remplace ni l’autorisation, ni la validation des entrées, ni les contrôles métier, ni l’observabilité.

MCP fournit un langage commun pour présenter au client des outils et des ressources avec leur nom, leur description et leurs paramètres. Une application peut ainsi découvrir des capacités sans intégrer directement chaque interface propriétaire. Le protocole améliore l’interopérabilité de la couche de contexte ; il ne garantit pas que deux outils de même nom aient la même sémantique ni qu’un appel soit sûr.

Il faut distinguer trois couches :

• Expérience IA : conversation, assistant de développement ou agent qui formule l’intention ;
• Couche MCP : découverte, description et invocation des capacités ;
• Système métier : service, interface de programmation d’application, base ou workflow qui détient les règles et les données.

Une architecture robuste évite de placer les secrets ou les règles critiques dans les instructions du modèle. Le serveur MCP appelle un service contrôlé, et ce service revalide l’identité, le périmètre et les paramètres avant toute opération.

Le placement dépend de la sensibilité des capacités et du mode d’exploitation. Un serveur local peut convenir à un outil individuel sans accès partagé. Un serveur interne mutualisé facilite la gouvernance d’un domaine métier. Une passerelle centrale peut gérer la découverte, les politiques, les versions et les journaux, mais elle devient aussi un composant critique qu’il faut rendre disponible et segmenter.

Le bon découpage suit généralement les frontières de responsabilité et de données. Un serveur qui mélange ressources humaines, finance et relation client rend les droits, les changements et les incidents plus difficiles à isoler.

Un outil MCP est un contrat. Son nom doit exprimer une action métier, sa description préciser les préconditions et son schéma limiter les paramètres. Les opérations larges comme « exécuter une requête » ou « mettre à jour un client » exposent trop de liberté. Préférez des capacités étroites telles que « rechercher une commande par référence » ou « préparer une demande de changement d’adresse ».

Pour chaque outil, documentez :

• le propriétaire métier et l’équipe d’exploitation ;
• les données lues, écrites et retournées ;
• les identités et périmètres autorisés ;
• les validations effectuées côté service ;
• les effets externes, leur réversibilité et la confirmation attendue ;
• les erreurs possibles, délais et limites d’appel ;
• la version, les dépendances et la procédure de retrait.

La description aide le modèle à choisir, mais elle n’est pas une politique de sécurité. Toute contrainte importante doit être appliquée par du code déterministe ou par le système de destination.

Le serveur doit savoir au nom de quelle entité il agit : utilisateur final, application ou agent technique. Cette identité doit rester traçable jusqu’au système métier. Une identité de service unique dotée de droits étendus simplifie le prototype, mais empêche souvent d’appliquer les restrictions propres à l’utilisateur et de déterminer qui a déclenché une action.

Les secrets ne doivent pas apparaître dans les descriptions, les messages ou les sorties d’outil. Ils sont stockés dans un mécanisme dédié, renouvelés et accessibles seulement au composant qui en a besoin. Lorsque le serveur relaie l’identité de l’utilisateur, le service appelé doit encore vérifier les droits. Lorsque l’agent agit avec une identité propre, son périmètre doit être plus étroit et les opérations sensibles doivent demander une approbation.

Une liste d’autorisation des serveurs et outils approuvés réduit aussi le risque qu’un client se connecte à une capacité non évaluée portant un nom trompeur. La confiance doit être fondée sur l’origine, la version et le propriétaire, pas seulement sur la description affichée.

Les tests doivent traverser toute la chaîne, du contenu présenté au modèle jusqu’à l’effet métier. Un document peut contenir une injection d’instructions ; un outil peut retourner des données inattendues ; un serveur peut devenir indisponible ; un schéma peut évoluer ; un appel peut être répété après un délai réseau.

Les opérations d’écriture gagnent à accepter une clé d’idempotence afin qu’une même intention ne produise pas plusieurs effets. Les délais, quotas et coupe-circuits empêchent qu’une défaillance se propage. Une réponse d’erreur structurée aide le client à s’arrêter ou à escalader plutôt qu’à improviser.

Le catalogue doit relier chaque serveur à un propriétaire, un dépôt, un environnement, une politique d’accès et une version. Chaque outil suit un état : proposé, en test, approuvé, restreint, déprécié ou retiré. Une nouvelle version est évaluée sur ses schémas, ses permissions et ses effets, pas seulement sur sa compatibilité technique.

L’observabilité minimale associe l’identité appelante, le client, le serveur, l’outil, la version, le statut, la durée et un identifiant de corrélation. Les paramètres sensibles peuvent être masqués ou remplacés par des attributs utiles au diagnostic. Les revues examinent les erreurs, refus, appels inutilisés, permissions excessives et changements de dépendance.

Commencez avec un domaine, quelques outils en lecture et un client approuvé. Validez la découverte, les droits, les journaux, la gestion d’erreur et le retrait. Ajoutez ensuite l’écriture et de nouveaux domaines seulement lorsque les contrôles communs sont reproductibles.