MCP en entreprise en 2026 : architecture, autorisation, gouvernance et migration vers la spécification 2026-07-28

Le Model Context Protocol, ou MCP, fournit un langage commun pour connecter une application fondée sur un modèle à des outils et des sources de contexte. Un client peut découvrir des capacités, appeler un outil ou intégrer une interface sans développer un connecteur propre à chaque couple d’applications.

Cette standardisation accélère l’intégration. Elle ne transforme pas un serveur en composant digne de confiance. L’entreprise doit toujours décider qui peut l’utiliser, quelles données il voit, quelles actions il réalise et comment il est surveillé.

La spécification officielle 2026-07-28 a introduit un cœur stateless et plusieurs évolutions majeures ; les SDK et dépréciations doivent être vérifiés avant mise en œuvre.

Ce que MCP standardise

MCP décrit les échanges entre une application cliente et un serveur qui expose des capacités. Selon la version et les extensions, celles-ci peuvent inclure outils, ressources, interfaces ou tâches longues.

Le protocole apporte :

• découverte structurée ;
• schémas d’entrée et de sortie ;
• transport ;
• cycle de requête ;
• mécanismes d’autorisation ;
• conventions de compatibilité ;
• SDK dans plusieurs langages.

Il ne définit pas les règles métier, le niveau de confiance, la classification des données ou le droit réel de l’utilisateur dans le système cible.

Ce que change la révision 2026-07-28

La spécification publiée le 28 juillet 2026 adopte un cœur de protocole stateless. Le handshake et la session gérés au niveau du protocole sont retirés, afin de faciliter routage, mise à l’échelle et infrastructure HTTP classique. L’application peut conserver un état, mais elle ne doit plus dépendre d’une session MCP implicite.

La révision renforce également l’autorisation, formalise le cadre d’extensions, introduit ou stabilise des mécanismes tels que les requêtes multi-étapes, les MCP Apps et l’extension Tasks pour les travaux longs. Certaines capacités historiques sont dépréciées. L’équipe doit lire le changelog et tester ses clients et serveurs avec les SDK adaptés.

Distinguer protocole et architecture d’entreprise

Une architecture d’entreprise ajoute généralement :

• registre de serveurs approuvés ;
• passerelle ou proxy ;
• identité et délégation ;
• politique d’outils ;
• filtrage réseau ;
• secrets ;
• observabilité ;
• sandbox ;
• approbations ;
• processus de version et retrait.

Le client ne devrait pas pouvoir se connecter librement à n’importe quel serveur découvert sur Internet depuis un environnement sensible.

Concevoir l’identité et l’autorisation

L’accès doit refléter l’utilisateur et le contexte. Un serveur ne doit pas recevoir un jeton général donnant davantage de droits que la personne. Les scopes sont limités aux capacités et ressources nécessaires.

Les principes incluent :

• consentement explicite ;
• audience du jeton ;
• durée courte ;
• séparation client/serveur ;
• rotation ;
• protection contre redirections abusives ;
• révocation ;
• journal d’autorisation.

Les droits métier sont toujours revérifiés par le service cible. Un outil MCP n’est pas une voie de contournement des API habituelles.

Exposer des outils sûrs

Les outils sont petits, nommés selon le métier et validés par un schéma strict. Ils ne donnent pas accès à un shell ou à une requête arbitraire. Ils renvoient des résultats structurés et limitent les données.

Pour une action :

• identité ;
• portée ;
• validation ;
• idempotence ;
• prévisualisation ;
• approbation ;
• vérification ;
• audit ;
• compensation.

Le descriptif de l’outil aide le modèle, mais la politique indépendante détermine s’il peut être appelé.

Traiter ressources et interfaces comme des données non fiables

Un serveur peut exposer un contenu contenant des instructions malveillantes. Le client doit séparer données et instructions et appliquer les mêmes protections que pour le web ou l’email.

Les MCP Apps ou interfaces rendues par serveur sont isolées, soumises à une politique de contenu et privées d’accès implicite aux secrets. Leur origine et leurs capacités doivent être visibles pour l’utilisateur.

Gérer les tâches longues

Les tâches agentiques peuvent durer au-delà d’une requête. L’extension de tâches apporte un modèle, mais l’application doit encore gérer :

• identité et autorisation pendant la durée ;
• état ;
• annulation ;
• reprise ;
• échéance ;
• budget ;
• notification ;
• résultat ;
• idempotence.

Une tâche ne doit pas conserver un pouvoir indéfini. Les autorisations peuvent expirer ou nécessiter une nouvelle validation avant une étape sensible.

Stateless ne signifie pas sans état

Le cœur stateless simplifie l’infrastructure, mais les applications conservent des conversations, tâches, approbations et résultats. Cet état doit être explicite, stocké dans un système gouverné et associé à une identité.

Le routage par en-têtes et les listes mises en cache nécessitent une politique de confidentialité et d’invalidation. Les métadonnées ne doivent pas révéler des capacités interdites.

Gouverner un catalogue de serveurs

Chaque serveur est un fournisseur de logiciel, de données et d’actions. Le registre doit inclure :

• propriétaire ;
• provenance ;
• version ;
• capacités ;
• données ;
• droits ;
• environnements ;
• dépendances ;
• support ;
• risques ;
• statut d’approbation ;
• date de revue.

Qualifier un serveur tiers

L’équipe examine code ou provenance, politique de mise à jour, vulnérabilités, collecte de données et destinations. Un serveur peut changer ses outils ; le client doit détecter la différence et demander une nouvelle approbation lorsque le risque évolue.

Le pilote s’exécute dans un environnement isolé, avec données synthétiques et jetons limités. Les comportements en erreur et en retrait sont testés.

Passerelle et proxy

Une passerelle d’entreprise peut centraliser authentification, liste autorisée, limites, journaux et routage. Elle réduit la dispersion, mais devient un composant critique. Elle doit préserver l’identité de l’utilisateur et éviter de devenir un super-compte.

Elle peut bloquer certains outils, transformer les scopes, appliquer une politique de destinations et fournir des métriques. Les logs minimisent les paramètres sensibles.

Observabilité

Chaque appel est corrélé à l’application, l’utilisateur, le serveur, l’outil, la version et le résultat. Les métriques suivent latence, erreurs, volume, coûts, refus, approbations et destinations.

Une hausse d’appels, un outil nouveau ou une destination inhabituelle déclenche une alerte. La capacité de coupure permet de suspendre un serveur sans déployer tous les clients.

Migration vers 2026-07-28

La migration doit commencer par un inventaire des clients, serveurs, SDK et fonctionnalités utilisées. Le changelog identifie les éléments dépréciés et les changements de transport ou d’autorisation.

La démarche comprend :

1. tests de compatibilité dans un environnement séparé ;
2. mise à jour des SDK ;
3. suppression des dépendances à la session protocolaire ;
4. adaptation de l’autorisation ;
5. validation des schémas ;
6. tests des extensions ;
7. déploiement progressif ;
8. observation ;
9. retrait de l’ancien chemin.

Les clients et serveurs peuvent nécessiter une période de coexistence versionnée.

Tests de sécurité

Tester :

• serveur non approuvé ;
• changement d’outil ;
• scope trop large ;
• jeton destiné à un autre serveur ;
• contenu injecté ;
• outil générique ;
• réponse malformée ;
• tâche sans fin ;
• annulation ;
• destination externe ;
• perte de connexion ;
• révocation.

Les scénarios deviennent une suite de régression.

MCP comme contrat d’intégration

MCP réduit le coût des connecteurs et favorise un écosystème ouvert. Son adoption en entreprise exige la même discipline que les API : catalogue, version, sécurité, observabilité et responsabilité.

Partitech peut développer des serveurs et clients MCP, concevoir la passerelle, qualifier les outils et accompagner la migration vers la spécification 2026-07-28. Le protocole devient alors une brique maîtrisée de la plateforme agentique, pas une porte ouverte vers tous les outils.

Parlons de votre projet

Concevoir un catalogue MCP sécurisé et gouverné avec Partitech. Contactez Partitech.