MCP (Model Context Protocol) : la pièce IA manquante

Pendant deux ans, connecter un LLM à un outil réel — un dépôt GitHub, une base Postgres, un bucket S3, un Slack — demandait un travail artisanal. Chaque modèle avait son format d'appel de fonction, chaque client (Claude Desktop, Cursor, un notebook interne) son pipeline d'intégration, et chaque outil son wrapper maison. Pour M modèles et N outils, on reconstruisait M×N ponts. C'était tenable avec trois modèles et cinq outils ; c'est devenu ingérable quand les équipes ont commencé à déployer des dizaines d'agents sur des dizaines de systèmes.

Le coût caché n'était pas seulement le code. C'était la duplication des politiques de sécurité (chaque intégration réinventait ses permissions), la dette de maintenance (quand l'API d'un outil changeait, il fallait patcher N wrappers), et l'impossibilité de réutiliser un outil entre clients. Un développeur qui écrivait une intégration Slack pour Claude Desktop ne pouvait pas la brancher dans Cursor sans tout réécrire.

MCP (Model Context Protocol), annoncé par Anthropic fin 2024, attaque ce problème à la racine. Il ne définit pas un nouveau modèle, ni un nouveau framework d'agents. Il standardise l'interface entre un hôte LLM et un fournisseur d'outils. Une seule intégration par outil, utilisable par n'importe quel client compatible. La métaphore retenue par Anthropic — le « USB-C de l'IA » — est précise : un connecteur universel, un contrat propre, et l'extensibilité pour les cas futurs.

MCP décrit trois rôles clairement séparés. L'**hôte** (host) est l'application dans laquelle l'utilisateur interagit avec le LLM : Claude Desktop, Cursor, Zed, Claude Code, ou votre agent interne. Le **client** MCP est un composant à l'intérieur de l'hôte, responsable de la gestion des connexions aux serveurs MCP. Le **serveur** MCP est un programme indépendant qui expose des capacités — outils, ressources, prompts — selon le protocole. Un hôte peut connecter plusieurs serveurs en parallèle ; un serveur peut être utilisé par plusieurs hôtes.

Le transport repose sur **JSON-RPC 2.0**, un format léger et déterministe. Deux modes sont supportés. Le mode **stdio** lance le serveur comme sous-processus de l'hôte : simple à déployer, idéal pour un poste développeur ou un agent local. Le mode **SSE/HTTP** (Server-Sent Events) expose le serveur sur le réseau : indispensable pour partager un serveur entre plusieurs utilisateurs, plusieurs machines, ou plusieurs agents cloud. Le choix du transport ne change pas la logique métier du serveur — seulement son point d'entrée.

Cette séparation des rôles est ce qui distingue MCP d'un simple « plugin LLM ». Le serveur ne connaît ni le modèle, ni le client, ni l'utilisateur final. Il expose un contrat stable, documenté, versionné. L'hôte orchestre. Le modèle décide. C'est une architecture pensée pour durer, pas pour faire une démo.

MCP ne se contente pas d'exposer des « fonctions ». Il définit trois primitives distinctes, chacune avec sa sémantique. Les **tools** (outils) sont des actions que le modèle peut décider d'invoquer — envoyer un message, créer un ticket, exécuter une requête. Ils suivent le pattern classique du function calling : nom, description, schéma JSON des paramètres, résultat retourné au modèle. C'est la primitive la plus utilisée aujourd'hui.

Les **resources** (ressources) sont des données adressables que le client peut exposer au modèle, à la demande ou en contexte. Un fichier de configuration, une ligne de documentation, une entrée de base de connaissances. La différence clé avec un outil : une ressource est lue, pas exécutée. Elle ne déclenche pas d'effet de bord. Cela permet à un client de proposer au modèle des sources contextuelles sans risquer d'action involontaire.

Les **prompts** (modèles de prompts) sont des templates réutilisables que le serveur met à disposition. Un serveur Sentry peut exposer un prompt « analyser cette erreur », pré-rempli avec le contexte adéquat. Cela transforme le serveur MCP en bibliothèque de savoir-faire métier, pas seulement en boîte d'outils. Ensemble, ces trois primitives couvrent la quasi-totalité des patterns d'intégration qu'on rencontre en production.

Un an après l'annonce, l'adoption dépasse les prévisions les plus optimistes. Anthropic maintient une vingtaine de **serveurs de référence** : filesystem, git, GitHub, Slack, PostgreSQL, Google Drive, Puppeteer, Memory, fetch, Sequential Thinking. Ces serveurs sont open source, auditables, et servent à la fois de production-ready et de patterns de référence pour la communauté.

Côté clients, tout l'écosystème développeur s'est aligné. **Claude Desktop** supporte MCP nativement depuis fin 2024. **Cursor** a intégré MCP comme mécanisme principal d'extension d'outils. **Zed** l'a ajouté pour l'assistance code. **Claude Code** (le CLI agentif d'Anthropic) en fait un usage intensif pour brancher filesystem, git et bash. Cline, Continue, et d'autres éditeurs ont suivi. Cette convergence côté clients est ce qui transforme un protocole prometteur en standard effectif.

Le moment charnière de 2025 a été l'**endorsement d'OpenAI** : en mars, OpenAI a annoncé le support de MCP dans l'Agents SDK et dans ChatGPT. Quand le concurrent direct adopte votre protocole, ce n'est plus une option — c'est l'infrastructure. Aujourd'hui, écrire un serveur MCP, c'est écrire une intégration qui fonctionne pour Claude, GPT, Cursor, et tout agent compatible. Le coût marginal d'un nouveau client tend vers zéro.

Les deux SDK officiels — **TypeScript** (`@modelcontextprotocol/sdk`) et **Python** (`mcp`) — rendent la création d'un serveur MCP trivialement simple. En TypeScript, on déclare ses outils avec un schéma Zod, on implémente le handler, et on monte le transport stdio en quatre lignes. En Python, le décorateur `@mcp.tool()` fait office de déclaration. Aucun glue code, aucune plomberie réseau à écrire soi-même.

Le choix du transport se résume à une question : votre serveur est-il local à un poste, ou partagé ? Pour un outil de développeur (introspection de repo local, requêtes sur une base de test), **stdio** est la bonne réponse — zéro configuration réseau, lancement automatique par le client. Pour un outil d'entreprise (API métier, base de production, CRM), **SSE/HTTP** s'impose : déploiement centralisé, authentification, monitoring, et capacité à servir plusieurs sessions simultanément.

Le point de sécurité à ne jamais transgresser : **le serveur est le gardien des permissions**. Il ne doit jamais exposer une clé API brute au modèle. Le modèle demande une action ; le serveur vérifie l'identité de l'utilisateur (transmise par l'hôte via le contexte), vérifie l'autorisation, exécute, et renvoie le résultat. Une clé Stripe ou AWS n'a aucune raison de transiter par le contexte du LLM. C'est le serveur qui parle à l'API externe, jamais le modèle directement. Cette discipline est ce qui permet de déployer MCP en production sans transformer son LLM en canal d'exfiltration.

Ces trois mécanismes ne sont pas concurrents — ils opèrent à des couches différentes. Le **function calling natif** (OpenAI, Anthropic, Google) est le plus léger : idéal pour une intégration ponctuelle, un chatbot avec deux ou trois actions, un prototype. Aucune abstraction, aucun protocole, mais aucun partage possible entre clients. **LangChain tools** (ou LlamaIndex, ou Vercel AI SDK) ajoutent une couche d'orchestration : exécution parallèle, retries, gestion d'état, intégration avec des chains et des agents. Très utile pour un pipeline complexe dans une seule application.

**MCP** brille quand la valeur est dans la **réutilisation multi-client**. Vous écrivez un serveur MCP pour votre API interne de facturation une fois. Il fonctionne dans Claude Desktop pour les équipes support, dans Cursor pour les développeurs qui debuggent, dans votre agent Slack pour le compta, et dans Claude Code pour les ops. Un seul contrat, plusieurs contextes. C'est aussi le seul des trois qui standardise la négociation capacités et le cycle de vie serveur (initialisation, listage, exécution, teardown).

En pratique, nous recommandons : function calling pour les démos et les scripts jetables ; LangChain pour les pipelines applicatifs complets ; MCP dès que l'intégration a vocation à servir plus d'un client, plus d'une équipe, ou plus d'un agent. Pour un studio comme VALRY LABS, où chaque client a son propre paysage d'outils, MCP divise par cinq le coût d'intégration d'un nouvel agent dans l'existant.

Le pattern de production le plus puissant que nous déployons en 2025 est le **« toolhub » MCP**. Un serveur unique, interne à l'entreprise, qui expose toutes les API métier (CRM, ERP, datalake, tickets, monitoring) derrière un contrat MCP unifié. N'importe quel agent — Claude Desktop pour le marketing, Cursor pour le dev, un agent custom pour le support — se branche au toolhub et obtient immédiatement accès à l'ensemble des outils autorisés pour son contexte.

L'efficacité opérationnelle est immédiate. Avant MCP, ajouter un nouvel outil à un agent signifiait : développer l'intégration, la déployer, la maintenir. Avec un toolhub, on déclare l'outil une fois côté serveur, et tous les agents compatibles en bénéficient. Le coût marginal d'un nouvel agent tend vers zéro. Le coût marginal d'un nouvel outil aussi. C'est l'équation gagnante : M×N devient M+N.

L'angle qui fait basculer les DSI, c'est la **gouvernance**. Parce que tout passe par le serveur MCP, on obtient gratuitement un journal d'audit complet : quel utilisateur, via quel agent, a appelé quel outil, avec quels paramètres, à quel instant. Côté sécurité, le serveur applique une politique RBAC centralisée — impossible de contourner depuis le client. Côté conformité, on a une trace unique pour SOC 2, ISO 27001, ou le RGPD. MCP n'est plus seulement un protocole de développeurs : c'est devenu un levier d'architecture pour la DSI.