MCP (Model Context Protocol) : le standard qui change l'orchestration d'agents IA

En 2024, déployer un agent IA capable d’interagir avec les outils d’une entreprise signifiait développer une intégration sur mesure pour chaque système : une connexion au CRM, une autre à la base documentaire, une autre encore au calendrier ou au système de tickets. Chaque intégration était couplée au modèle choisi, écrite dans le style du framework utilisé, remaniée à chaque changement de modèle. Le coût d’un vrai agent d’entreprise n’était pas le modèle lui-même, mais tout le travail d’assemblage autour.

Le Model Context Protocol (MCP) a mis fin à ce problème. En définissant un standard ouvert pour la communication entre un modèle de langage et ses outils externes, Anthropic a posé les fondations d’un écosystème dans lequel un serveur MCP développé une fois peut être utilisé par n’importe quel agent compatible, quel que soit le modèle ou le framework sous-jacent. En 2026, MCP est devenu la colonne vertébrale de facto des architectures agentiques sérieuses.

Cet article explique ce qu’est MCP, comment il fonctionne techniquement, pourquoi il a changé la donne pour les projets d’agents en entreprise, et comment VirtuoseWeb l’exploite dans ses trois voies de déploiement.

Ce que MCP résout : le problème de l’intégration à l’échelle

Avant d’expliquer comment MCP fonctionne, il est utile de comprendre le problème qu’il résout, car c’est ce problème qui justifie toute son architecture.

Un agent IA utile en entreprise doit pouvoir agir sur ses outils métiers. Lire des emails, interroger un CRM, créer une facture, envoyer un message Slack, chercher dans une base documentaire. Chacune de ces actions suppose une intégration technique entre le modèle de langage et le système cible.

Avant MCP, cette intégration se faisait de trois manières, toutes imparfaites. Première approche : définir des fonctions dans le code de l’application et les passer comme tools à l’API du modèle. Simple mais monolithique : si vous changez de modèle, vous devez réécrire l’intégration. Deuxième approche : utiliser un framework comme LangChain avec ses propres abstractions. Plus portable, mais dépendant du framework et souvent désynchronisé des évolutions des APIs modèles. Troisième approche : des connecteurs no-code via des plateformes comme Zapier ou Make. Fonctionnels pour des cas simples, mais incapables de gérer la logique complexe qu’un vrai agent autonome exige.

MCP propose une quatrième voie : un protocole standardisé qui découple complètement la définition des outils (le serveur MCP) de leur consommation (le modèle et son framework). Cette séparation est la source de tous les bénéfices qui suivent.

L’architecture MCP : hôte, client, serveur

MCP s’organise autour de trois rôles qui correspondent à trois couches distinctes dans votre architecture.

Le serveur MCP est le processus qui encapsule un outil ou un ensemble d’outils. Il expose un catalogue structuré de capabilities : tools (actions exécutables), resources (données accessibles en lecture) et prompts (templates de prompt réutilisables). Un serveur MCP pour Notion expose par exemple un outil create_page, un outil search_pages, et une resource database qui permet de lire le contenu d’une base. Le serveur tourne indépendamment, sur votre infrastructure ou celle de votre fournisseur SaaS.

Le client MCP est la composante de votre framework d’agent qui sait communiquer avec les serveurs MCP. Il découvre leurs capacités, les transmet au modèle sous forme de tool definitions, et route les appels de tools vers le bon serveur. Dans Claude Managed Agents, ce client est intégré directement dans l’infrastructure d’Anthropic.

L’hôte MCP est l’application principale : votre agent, votre IDE intelligent, votre assistant métier. Il pilote le client, orchestre la session, et décide quelle action déclencher selon le raisonnement du modèle.

Ce découplage en trois couches permet de mixer les serveurs MCP indépendamment des modèles. Vous pouvez connecter le même serveur MCP GitHub à un agent Claude, à un agent Gemma 4 tournant sur Scaleway, ou à un assistant basé sur Mistral sur votre on-prem, sans modifier une ligne du serveur.

Ce que MCP expose : tools, resources, prompts

MCP standardise trois types de capabilities que les serveurs peuvent exposer aux modèles.

Les tools

Les tools sont les actions exécutables. Chaque tool a un nom, une description lisible par le modèle, et un schéma JSON qui décrit ses paramètres. Quand le modèle décide d’appeler un tool, il produit un tool_use block avec les paramètres correspondants. Le client MCP route cet appel vers le serveur, exécute l’action, et renvoie le résultat.

Exemples concrets de tools dans un contexte métier :

Outil métier	Tool MCP exposé	Ce que le modèle peut faire
CRM Salesforce	create_lead, update_deal, fetch_contact	Créer des leads, mettre à jour le pipeline
Facturation	create_invoice, send_invoice, check_payment	Émettre et suivre les factures
Email	send_email, search_inbox, read_thread	Traiter la boîte mail
Base documentaire	search_docs, read_document, create_note	Chercher et synthétiser
Calendrier	create_event, find_free_slots, invite_attendees	Planifier des réunions

Les resources

Les resources sont des données exposées en lecture par le serveur, sans que le modèle n’ait besoin d’appeler une action. Elles permettent d’injecter du contexte persistant : la base de connaissances produit, le catalogue clients, les SLA en vigueur, les règles métier. Ce mécanisme est important pour l’efficience : plutôt que de passer des milliers de lignes de contexte dans chaque prompt (coûteux en tokens), vous exposez les données via une resource et le modèle les lit à la demande.

Les prompts

Les prompts MCP sont des templates réutilisables que les hôtes peuvent injecter dans leurs interactions. Utiles pour standardiser des workflows récurrents : un template de rédaction de devis, un template de rapport d’audit, un template de synthèse de réunion. L’avantage est que ces templates vivent dans le serveur MCP, donc en dehors du code de l’application, et peuvent être mis à jour sans redéploiement.

Pourquoi MCP a été adopté si rapidement

MCP a été publié par Anthropic fin 2024 comme standard ouvert. En dix-huit mois, l’adoption a dépassé les attentes des équipes d’Anthropic elles-mêmes. Plusieurs raisons expliquent cette vitesse.

Premièrement, le timing. MCP est arrivé au moment où les équipes techniques commençaient à construire leurs premiers agents sérieux et se heurtaient exactement au problème d’intégration décrit plus haut. La solution était prête au bon moment.

Deuxièmement, la simplicité du protocole. MCP utilise JSON-RPC 2.0 sur stdio ou SSE. N’importe quel développeur qui a déjà fait une API REST peut écrire un serveur MCP en quelques heures. Les SDK officiels en Python et TypeScript réduisent encore cette barrière.

Troisièmement, l’écosystème. Dès les premiers mois, des centaines de serveurs MCP open source ont émergé pour les outils les plus courants. GitHub, Notion, Slack, PostgreSQL, Stripe, Salesforce, Google Drive, Jira : la plupart ont un serveur MCP maintenu par la communauté ou par l’éditeur lui-même. Ce catalogue réduit le travail d’intégration à zéro pour beaucoup de cas d’usage standard.

Quatrièmement, l’intégration native dans Claude Managed Agents. Quand Anthropic a lancé son offre Managed Agents en avril 2026, MCP y était intégré nativement. Connecter un serveur MCP à un agent Claude Managed se fait en quelques lignes de configuration. Cette intégration a légitimé MCP comme le standard de référence de l’écosystème Claude.

MCP dans les trois voies de déploiement VirtuoseWeb

Chez VirtuoseWeb, MCP est au cœur de tous nos déploiements, mais son implémentation varie selon la voie choisie.

Voie 1 — Agent Express Claude

Sur Claude Managed Agents, les serveurs MCP se connectent via la configuration de l’agent. Vous spécifiez l’URL du serveur (ou son chemin local dans l’environnement du conteneur), ses paramètres d’authentification, et Claude l’interroge directement pendant la session. La latence d’un appel MCP est typiquement inférieure à 100 millisecondes pour un serveur hébergé en Europe de l’Ouest, ce qui est imperceptible dans une session d’agent.

Pour un cabinet de conseil qui déploie un agent de qualification de leads, nous connectons par exemple un serveur MCP Salesforce, un serveur MCP Gmail et un serveur MCP Notion. L’agent peut lire le profil d’un prospect dans Salesforce, rechercher les échanges email précédents, et créer une fiche de qualification dans Notion, le tout en une session autonome.

Voie 2 — Agent Souverain Europe

Sur Scaleway ou OVHcloud, les serveurs MCP tournent dans le même VPC que le modèle Gemma 4 ou Mistral. Aucun appel ne sort du réseau européen. C’est la voie que nous recommandons dès que les données qui transitent par les tools sont sensibles : données patients, données comptables, informations juridiques confidentielles.

La configuration est identique côté agent. La différence est que les serveurs MCP sont déployés dans votre infrastructure cloud européenne plutôt que d’être exposés sur l’internet public. La sécurité est renforcée, et la latence intra-VPC est souvent meilleure que via une connexion externe.

Voie 3 — Agent Souverain Intégral

Sur votre infrastructure on-prem, les serveurs MCP tournent sur le même réseau privé que le LLM. Aucune donnée ne quitte votre périmètre réseau. C’est la configuration que nous déployons pour les industriels, les acteurs de la défense et les directions juridiques soumises au secret professionnel le plus strict.

La contrainte de la Voie 3 est le dimensionnement : un cluster GPU qui fait tourner un Gemma 4 31B ou un Mistral Large 2 occupe déjà une fraction importante des ressources d’un serveur H100. Les serveurs MCP doivent donc être légers et bien optimisés. Nous les conteneurisons systématiquement avec Docker pour faciliter la gestion des ressources.

Construire un serveur MCP : ce que ça implique concrètement

Pour donner une idée concrète de la charge de développement, voici ce qu’implique la création d’un serveur MCP simple en Python avec le SDK officiel.

Un serveur MCP fonctionnel tient en moins de cinquante lignes de code. Vous instanciez un objet Server, vous décorez vos fonctions Python avec @server.call_tool(), et vous décrivez leurs paramètres avec un schéma JSON. Le SDK se charge du transport, de la sérialisation et de la gestion des erreurs.

La complexité vient de la logique métier encapsulée, pas du protocole lui-même. Un serveur MCP pour votre ERP maison peut nécessiter quelques semaines de développement si l’ERP n’expose pas d’API moderne. Un serveur MCP pour PostgreSQL ou Notion prend quelques heures à partir d’un template open source.

Dans notre pratique chez VirtuoseWeb, nous distinguons trois niveaux de serveurs MCP :

Niveau 1 — Assemblage de serveurs existants. Disponibles en open source, testés, maintenus. Couvre 80 % des besoins standard. Durée : heures.

Niveau 2 — Adaptation d’un serveur existant. Votre outil a une API REST, vous l’enveloppez dans un serveur MCP en ajoutant votre logique d’authentification et vos règles métier spécifiques. Durée : jours.

Niveau 3 — Serveur MCP sur mesure. Votre système legacy n’expose pas d’API, vous devez créer l’intégration de zéro. Durée : semaines. Ce niveau est exceptionnel dans les projets récents, la plupart des systèmes en 2026 exposant au moins une API basique.

L’avantage de portabilité sur la durée

Un argument souvent sous-estimé en faveur de MCP est la portabilité sur le long terme. Vous ne savez pas aujourd’hui quel modèle sera le plus compétitif dans douze mois. Peut-être continuerez-vous avec Claude Opus 4.6. Peut-être basculerez-vous vers une nouvelle version de Gemma ou de Mistral. Peut-être migrerez-vous d’un cloud souverain à un autre.

Si vos intégrations sont construites en MCP, cette migration ne coûte que le recâblage de la configuration de l’agent, pas le redéveloppement de toutes vos intégrations métiers. C’est une assurance technique dont le ROI se mesure au premier changement de modèle que vous n’aurez pas à absorber en dette technique.

Chez VirtuoseWeb, nous intégrons cette logique dans notre méthode SOP → Code dès l’étape de design de l’agent. Chaque outil métier identifié dans le SOP est évalué selon trois critères : existe-t-il un serveur MCP open source ? Faut-il l’adapter ? Faut-il le créer ? Ce travail en amont garantit que l’architecture est portable dès le premier jour.

Checklist MCP pour un projet d’agent en entreprise

Avant de lancer un projet d’agent, voici les questions à se poser sur MCP :

Question	Réponse attendue
Quels outils métiers l’agent doit-il utiliser ?	Liste exhaustive des systèmes cibles
Existe-t-il un serveur MCP open source pour chacun ?	Vérifier le catalogue Anthropic et GitHub
Les données transitant par les tools sont-elles sensibles ?	Si oui, déployer les serveurs MCP en réseau privé (V2/V3)
La latence des appels MCP est-elle acceptable ?	Tester avec le volume de données réel
Qui maintient les serveurs MCP dans la durée ?	Définir la responsabilité en amont
La version du protocole est-elle compatible ?	Vérifier la version MCP supportée par votre runtime

Conclusion : MCP est l’infrastructure invisible de l’agentique

MCP n’est pas un sujet glamour. C’est un protocole de transport, une couche intermédiaire, un standard qui passe inaperçu quand il fonctionne. Mais c’est précisément pour ça qu’il est stratégique.

Les équipes qui déploient des agents en 2026 sans MCP créent une dette technique qui sera douloureuse à rembourser. Les équipes qui l’adoptent dès le départ bénéficient d’une architecture portable, maintenable et évolutive, quelle que soit la direction que prend l’écosystème des modèles de langage.

Si vous envisagez de déployer votre premier agent autonome, ou si vous avez déjà commencé et souhaitez auditer vos choix d’architecture, notre audit SOP gratuit de 30 minutes permet d’évaluer rapidement si votre approche d’intégration est pérenne. Et si vous partez de zéro, notre guide du diagnostic SOP explique comment identifier les outils métiers que votre agent devra connecter avant même d’ouvrir un éditeur de code.