Le Model Context Protocol (MCP) expliqué aux décideurs

Un modèle d'IA seul ne connaît ni vos clients, ni vos stocks, ni vos contrats. Pour agir sur ces informations, une application doit se connecter à vos ERP, CRM, bases documentaires ou messageries. Ces connexions utilisent souvent des contrats différents selon le système et l'assistant. Le Model Context Protocol propose une interface commune entre ces deux côtés ; il ne supprime ni l'adaptateur vers le logiciel métier, ni les contrôles de sécurité, ni la maintenance liée aux versions.

Qu'est-ce que le Model Context Protocol ?

Le Model Context Protocol (MCP) est un protocole ouvert présenté par Anthropic en novembre 2024. Il définit comment une application d'IA découvre et appelle les ressources ou outils exposés par un serveur MCP. Un serveur peut être réutilisé par plusieurs clients compatibles, à condition de valider la version du protocole, les fonctions prises en charge, l'authentification et les politiques propres à chaque client.

L'analogie la plus parlante est celle du port USB-C : avant, chaque périphérique avait son câble propriétaire ; après, un connecteur unique sert à tout. MCP joue ce rôle entre les modèles d'IA et le système d'information de l'entreprise.

Quel problème MCP résout-il ?

Avant MCP, connecter l'IA à l'entreprise posait un problème de multiplication. Si vous vouliez que trois assistants — disons ChatGPT, Claude et un copilote interne — accèdent à cinq systèmes — ERP, CRM, base documentaire, messagerie, outil de tickets —, il fallait potentiellement construire et maintenir quinze intégrations différentes, chacune avec sa logique propre, sa sécurité propre et ses bugs propres.

Cette matrice augmente le nombre de contrats techniques, de contrôles de sécurité et de chemins à maintenir. Une intégration étroitement liée à un fournisseur peut aussi rendre un changement de modèle plus coûteux.

Avec MCP, chaque système peut exposer un contrat commun via un serveur et plusieurs clients compatibles peuvent l'utiliser. Cette architecture peut réduire la matrice d'intégrations, mais elle ne garantit pas cinq connecteurs au lieu de quinze : les capacités, identités, autorisations et extensions réellement prises en charge doivent être testées. Un changement de modèle devient plus simple seulement si les deux clients supportent les mêmes outils et si l'application n'est pas couplée à des fonctions propriétaires.

Comment fonctionne MCP, sans plonger dans la technique ?

Trois notions suffisent pour suivre une conversation d'architecture :

• Le serveur MCP : un petit service qui se place devant l'un de vos systèmes (Odoo, SharePoint, une base SQL...) et expose au modèle un catalogue d'actions permises — « rechercher un client », « lire une facture », « créer un brouillon de devis ». C'est lui qui parle à votre système ; le modèle ne touche jamais directement vos données.
• Le client MCP : l'application d'IA que vos équipes utilisent. Elle découvre les serveurs disponibles et leurs capacités, puis demande l'exécution des actions. Claude prend en charge MCP, et la plateforme OpenAI documente les serveurs MCP distants parmi ses outils ; les fonctions disponibles restent à vérifier produit par produit.
• Les permissions : chaque serveur décide de ce qu'il expose, à qui, et dans quelles limites. Un serveur bien conçu n'ouvre que le strict nécessaire — lecture seule sur les stocks, création limitée aux brouillons, jamais de suppression.

Le point clé pour un décideur : une partie essentielle de la frontière de sécurité se trouve dans le serveur MCP, son hébergement et son système d'autorisation. L'entreprise doit définir ce que chaque identité peut voir et faire, action par action, tout en tenant compte des politiques du client IA et des services tiers traversés.

Pourquoi les décideurs doivent-ils s'y intéresser maintenant ?

Parce que l'adoption s'est élargie au-delà d'Anthropic : plusieurs produits d'IA et fournisseurs d'infrastructure annoncent une prise en charge de MCP. Cette adoption rend le protocole pertinent à évaluer, sans supprimer le risque d'évolution. La spécification 2026-07-28 a encore modifié le cœur du protocole, renforcé l'autorisation et formalisé des dépréciations ; la compatibilité doit donc être versionnée et testée.

Pour l'entreprise, trois conséquences concrètes :

• La réutilisation peut augmenter. Un serveur MCP bien découpé peut servir plusieurs clients compatibles. Sa durabilité dépend toutefois des versions, des tests de contrat et de l'interface du logiciel métier sous-jacent.
• La réversibilité peut s'améliorer. Le changement de modèle demande moins de travail si les outils, schémas, autorisations et comportements attendus restent compatibles. Un test de sortie doit le démontrer avant d'en faire un engagement.
• Le champ des cas d'usage s'élargit. Ce sont les connexions MCP qui transforment un chatbot qui « répond » en un assistant qui agit : préparer un devis dans l'ERP, qualifier un ticket, croiser un contrat avec la base clients.

Quels risques faut-il encadrer ?

Un connecteur universel ouvre des portes ; il faut donc décider lesquelles, et le décider explicitement. Trois chantiers de gouvernance accompagnent tout déploiement MCP sérieux :

• Les droits d'accès. L'IA ne doit jamais voir plus que l'utilisateur qu'elle assiste. Les serveurs MCP doivent hériter des habilitations existantes, pas les contourner. Un assistant connecté à l'ERP avec un compte administrateur est une faille, pas un gain de productivité.
• L'injection de prompt. Quand un modèle lit des contenus externes — un e-mail, une page web, un document —, des instructions malveillantes peuvent s'y cacher et tenter de détourner ses actions. La parade est architecturale : limiter les actions sensibles, exiger une validation humaine pour tout ce qui écrit ou envoie, et cloisonner les serveurs.
• La traçabilité. Chaque action déclenchée via MCP doit être journalisée : qui, quoi, quand, sur quel système. C'est la condition pour auditer les usages, répondre à un régulateur et diagnostiquer un incident.

Rien de tout cela n'est spécifique à MCP — ce sont les règles de toute intégration au système d'information. Un serveur commun peut centraliser une partie de ces contrôles, à condition que les identités, journaux et politiques ne soient pas dispersés dans les clients et services situés autour de lui.

Comment démarrer ?

La bonne première étape n'est pas technologique : c'est un inventaire. Quels systèmes contiennent les données que vos équipes ressaisissent ou recherchent à longueur de journée ? C'est là que la connexion IA-système d'information paie le plus vite. Choisissez ensuite un périmètre borné — un système, un cas d'usage, des accès en lecture seule — et mesurez : temps gagné, qualité des réponses, incidents.

Le délai d'un pilote dépend de l'interface du logiciel, des droits, du niveau d'autorisation, des environnements de test et des critères d'acceptation. Le premier lot doit produire un cas d'usage évalué et une base réutilisable seulement après des tests de compatibilité, de sécurité et de réversibilité. Notre offre de développement MCP pour logiciels métier détaille cette mise en œuvre, complétée par notre métier d'ingénierie IA et notre offre d'intégration IA. Pour explorer ce que MCP changerait à votre système d'information, parlons-en.