Un client SaaS B2B nous appelle en novembre 2025. Leur équipe a passé six semaines à intégrer Claude dans leur outil — appels de fonction custom, sérialisation maison, gestion d'erreur fragile. Ils veulent maintenant que la même intégration tourne avec GPT-4o et Gemini en fallback. Devis estimé : huit semaines supplémentaires. Plus la maintenance des trois implémentations en parallèle quand les SDK changent. Nous proposons MCP : trois jours de réécriture, une seule implémentation, tous les LLM compatibles. Six mois plus tard, ils ajoutent un quatrième LLM en deux heures. Voici pourquoi MCP transforme l'économie des intégrations LLM, et le pattern d'adoption qui évite la dette technique.
Pourquoi MCP existe : le problème combinatoire des intégrations LLM
Avant MCP, brancher un LLM sur un outil métier signifiait écrire une intégration spécifique au LLM. Le format des appels de fonction de Claude n'était pas celui d'OpenAI, ni celui de Gemini. Chaque mise à jour majeure cassait quelque chose. Chaque nouveau LLM imposait une nouvelle intégration complète.
Le problème est combinatoire : avec N LLM et M outils métier à connecter, vous écriviez N × M intégrations. À 3 LLM et 5 outils, ça reste gérable (15 intégrations). À 10 LLM et 50 outils, ça devient ingérable (500 intégrations).
MCP — Model Context Protocol — résout ce problème comme ODBC l'a résolu pour les bases de données dans les années 90 : un protocole pivot. N + M au lieu de N × M.
| Métrique | Avant MCP | Avec MCP |
|---|---|---|
| Intégrations à maintenir (3 LLM × 5 outils) | 15 | 8 |
| Intégrations à maintenir (10 LLM × 50 outils) | 500 | 60 |
| Temps pour ajouter un LLM | 1 sem./outil | 0 (gratuit) |
| Temps pour ajouter un outil | 1 sem./LLM | 1 sem. total |
| Standardisation des erreurs | Non | Oui |
Anthropic a publié la spec MCP en novembre 2024. En janvier 2026, elle est supportée nativement par Claude, ChatGPT, Cursor, Zed, Continue, et a des SDK officiels en TypeScript, Python, Rust, Go, Kotlin. C'est devenu le standard de fait — adopter autre chose maintenant, c'est créer de la dette technique.
Le pattern d'adoption en 5 jours
Voici le plan que nous appliquons chez les clients ayant déjà des intégrations LLM custom à migrer.
// Un MCP server typique en TypeScript — 60 lignes minimum viable
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
const server = new Server(
{ name: "crm-server", version: "1.0.0" },
{ capabilities: { tools: {} } }
);
server.setRequestHandler(ListToolsRequestSchema, async () => ({
tools: [
{
name: "search_customer",
description: "Recherche un client par nom ou email",
inputSchema: {
type: "object",
properties: { query: { type: "string" } },
required: ["query"],
},
},
],
}));
server.setRequestHandler(CallToolRequestSchema, async (req) => {
if (req.params.name === "search_customer") {
const customers = await db.searchCustomers(req.params.arguments.query);
return { content: [{ type: "text", text: JSON.stringify(customers) }] };
}
});
await server.connect(new StdioServerTransport());Trois primitives au cœur de MCP : tools (actions à effets de bord), resources (données lisibles), prompts (templates réutilisables). Pour 90 % des cas d'usage B2B, vous n'utiliserez que les tools.
| Primitive | Quand l'utiliser | Exemple |
|---|---|---|
tools | Action qui modifie quelque chose | create_ticket, send_email |
resources | Données accessibles en lecture | customer://42, file:///docs/... |
prompts | Templates partagés entre clients | « rédiger un email de relance » |
Pourquoi MCP fonctionne : l'architecture qui rend les LLM agnostiques
MCP repose sur JSON-RPC 2.0 comme transport, ce qui le rend trivial à implémenter dans n'importe quel langage. Les implémentations officielles couvrent TypeScript, Python, Rust, Go, Kotlin, C# et Java. Pour les langages exotiques, écrire un serveur MCP minimal demande 200 lignes.
Le séparation client-server qui fait la magie
Un setup MCP comporte trois rôles :
- Le LLM (Claude, GPT, Gemini) — le cerveau qui décide
- Le client MCP (Cursor, Claude Desktop, votre application) — qui orchestre
- Le serveur MCP (votre intégration métier) — qui expose les tools
Le LLM n'a aucune connaissance du serveur MCP. Il voit juste une liste d'outils, leurs descriptions, leurs schémas. Le client MCP fait la traduction. Cette séparation est ce qui permet de changer de LLM sans toucher aux serveurs MCP — et inversement.
Transport stdio vs HTTP+SSE
MCP supporte deux transports principaux :
| Transport | Cas d'usage | Avantages |
|---|---|---|
stdio | Server local, intégration desktop | Simple, sécurisé, par défaut |
HTTP + SSE | Server distant, multi-tenant | Cloud-friendly, scalable |
Pour un POC ou un outil interne, stdio est suffisant et plus simple. Pour un service mutualisé ou une intégration cloud, HTTP + SSE (Server-Sent Events) permet d'héberger un serveur MCP unique consommé par plusieurs clients distants.
L'authentification qui manquait au début
Le talon d'Achille de MCP en 2024-2025 était l'authentification : comment exposer un serveur MCP cloud avec OAuth ou API keys ? La spec a été étendue mi-2025 avec des authorization flows standards (OAuth 2.1 + PKCE). Aujourd'hui, un MCP server peut exiger un JWT valide, valider des scopes, et tracer chaque appel par identité.
C'est ce qui rend MCP enfin viable pour les déploiements B2B : on peut exposer un MCP server à plusieurs clients tout en isolant les données par utilisateur authentifié.
Edge cases et pièges en production
Cas 1 : descriptions de tools trop longues qui saturent le contexte
Chaque tool exposé occupe des tokens dans la fenêtre de contexte du LLM client. Une description verbeuse de 300 tokens × 30 tools = 9 000 tokens dépensés avant même que la conversation commence. Sur Claude, c'est 27 €/1M requêtes en pure overhead.
Règle : descriptions de tool < 80 tokens. Si la description est complexe, mettez le détail dans la doc du server, pas dans le description. Le LLM lit le nom + 1-2 phrases, pas un manuel.
Cas 2 : serveur MCP qui plante silencieusement
MCP utilise stdio par défaut — le serveur communique via stdin/stdout. Si le serveur crash ou stall, le client MCP attend. Sans timeout, l'agent freeze. Mitigation :
- Configurer des timeouts agressifs côté client (10 s par appel max)
- Le serveur doit logger sur stderr (pas stdout, qui est le canal de protocole)
- Health check toutes les 60 secondes
- Auto-restart côté client si le server ne répond pas
Cas 3 : multi-tenant avec partage de tools
Vous voulez exposer le même tool à plusieurs clients tout en isolant leurs données. Pattern à imposer : le tool reçoit le user_id ou tenant_id depuis le contexte d'auth, jamais depuis les paramètres LLM-fournis. Sinon, n'importe quel utilisateur peut « demander » les données d'un autre tenant en inventant un ID.
async function search_customer(args: { query: string }, ctx: AuthContext) {
// ✅ tenant depuis ctx.user, isolé du LLM
return db.searchCustomers({ tenant: ctx.user.tenantId, query: args.query });
}| Anti-pattern | Risque | Mitigation |
|---|---|---|
tenant_id dans les paramètres LLM | Cross-tenant data leak | Auth context côté server |
| Pas de rate limit par tenant | DoS via LLM en boucle | Quota par identité |
Logs sans tenant_id | Audit impossible | Tracing structuré |
Cas 5 : MCP server qui expose trop de capacités d'un coup
Un client juridique nous a demandé d'auditer leur MCP server interne. Il exposait 47 tools, des resources sur tous les fichiers du tenant, et 12 prompts métier. Résultat : la fenêtre de contexte de Claude était occupée à 60 % par les descriptions MCP avant même la première question utilisateur. Coût en tokens : 18 € / 1 000 conversations en pure overhead.
Solution appliquée : segmentation en 4 serveurs MCP spécialisés (recherche documentaire, gestion clients, génération de courriers, assistance jurisprudence). Le client MCP charge dynamiquement le serveur pertinent selon le contexte de la conversation. Overhead tokens divisé par 6, qualité de raisonnement améliorée parce que le LLM voit 12 tools au lieu de 47.
Règle : un MCP server = un domaine. Plusieurs domaines = plusieurs serveurs. Pas un mégaserveur unique « parce que c'est plus simple ».
Cas 6 : performance et caching côté MCP server
Un MCP server qui appelle une base de données métier sans cache devient un goulot d'étranglement. À chaque conversation, le LLM peut faire 5 à 15 appels d'outils — multipliez par les utilisateurs simultanés et votre base se met à genoux. Pattern à imposer dès le départ :
- Cache de résultats côté MCP server (Redis ou in-memory) avec TTL adapté à la fraîcheur exigée
- Pagination explicite sur les tools qui peuvent renvoyer beaucoup de données
- Limite de payload : refus des arguments > 4 KB pour éviter qu'un LLM ne mette tout son contexte en paramètre
Sur un projet client juridique, l'ajout d'un cache Redis de 5 minutes sur le tool search_jurisprudence a divisé la charge DB par 40 sans changer la qualité des réponses.
Cas 4 : versionning des tools sans casser les clients
Vous renommez un paramètre de search_customer : query devient q. Les clients existants cassent. Pattern de transition :
- Ajouter le nouveau paramètre
qen gardant l'ancienquerypendant 3 mois - Logger les utilisations de
querypour identifier qui doit migrer - Marquer
querycomme deprecated dans la description - Retirer après une période de grâce
C'est exactement le même pattern que pour une API REST publique. MCP n'a pas inventé le problème, mais il faut le gérer.
Ce qu'il faut retenir
Trois règles, dans cet ordre :
- Adoptez MCP par défaut sur les nouvelles intégrations. Toute intégration LLM custom écrite après 2026 sans MCP est de la dette technique anticipée.
- Trois à cinq tools par serveur, pas trente. La parcimonie battle l'exhaustivité. Vous pouvez avoir plusieurs serveurs spécialisés.
- Authentifiez côté serveur, pas côté LLM. Le LLM n'est pas une source d'identité. Imposez OAuth ou JWT au transport, pas dans les paramètres.
Pour aller plus loin :
- Spec MCP officielle : modelcontextprotocol.io (mise à jour mensuelle)
- Anthropic SDK Python/TS pour MCP — implémentation de référence
- Liste des serveurs MCP communautaires : 200+ implémentations open-source en 2026 (GitHub, Slack, Postgres, Linear…)
- Vercel MCP server : permet aux agents de piloter directement vos déploiements
- Tutoriel officiel pour exposer un service interne en MCP en moins d'une heure
Conclusion
MCP n'est pas un sujet d'architecture — c'est un sujet de levier. Le client SaaS de l'intro a multiplié par 4 le nombre de LLM supportés sans coût additionnel d'intégration. La même équipe maintient une seule pile au lieu de trois. C'est le genre de standard qui ne fait pas la une mais qui transforme silencieusement la productivité d'une équipe IA. Adoptez-le aujourd'hui, vous remercierez votre vous d'il y a six mois.
