MCP, le standard qui change la donne pour connecter vos documents à Claude

Imaginez la scène. Un CTO d'une PME industrielle veut brancher Claude sur cinq systèmes internes : le SharePoint contractuel, l'ERP, le CRM, un dossier de procédures qualité et un connecteur Slack. Il y a dix-huit mois, ça voulait dire cinq intégrations one-off, chacune avec son SDK, son auth, son format de retour, son lot de maintenance. Et le jour où on voulait essayer Mistral à la place de Claude pour comparer, on refaisait la moitié du travail.

Aujourd'hui, on écrit cinq MCP servers. Et on les rebranche à n'importe quel client compatible — Claude Desktop, Cursor, Continue, l'Agents SDK d'OpenAI — sans toucher au code des intégrations elles-mêmes. C'est la promesse du Model Context Protocol, et c'est la première fois depuis l'arrivée des LLMs en production qu'on a un standard qui tient la route.

Le problème : N×M intégrations

Avant MCP, la connexion entre un LLM et le monde extérieur ressemblait à un jeu de matrice. N modèles d'un côté (Claude, GPT-4, Mistral, Gemini, Llama…). M outils de l'autre (votre CRM, votre base documentaire, votre data warehouse, etc.). Et entre les deux, N×M connecteurs spécifiques à écrire, tester, maintenir.

Dans la pratique, ça donnait trois pathologies récurrentes chez les PME qu'on accompagne :

• Dépendance verrouillée à un fournisseur. Une fois qu'on a écrit 15 fonctions OpenAI tool-calling avec leur format JSON spécifique, on ne change pas de modèle pour le plaisir. Le coût de migration devient prohibitif.
• Maintenance dispersée. Chaque intégration a sa propre logique d'erreur, ses propres timeouts, son propre format de retour. Multipliez par cinq systèmes et trois projets : la dette technique s'accumule vite.
• Fragmentation des équipes. Un dev écrit le connecteur SharePoint pour le projet A, un autre le réécrit pour le projet B parce que le premier n'était pas générique. On a vu ça plus souvent qu'on ne voudrait.

MCP attaque ce problème par le seul angle qui marche : un protocole, pas N×M intégrations.

MCP en une phrase

MCP est un protocole standard open-source publié par Anthropic en novembre 2024, qui définit comment un LLM accède à des outils et à des sources de données externes. Un seul protocole, n'importe quel modèle compatible.

Pensez-y comme à LSP (Language Server Protocol) pour les éditeurs de code. Avant LSP, chaque IDE avait son intégration spécifique pour chaque langage : N×M. Après LSP, on écrit un language server une fois et il fonctionne dans VS Code, Neovim, Sublime, et autres. MCP fait la même chose pour les LLMs.

L'anatomie d'un MCP server

Un MCP server expose deux choses au client :

• Des tools — des fonctions appelables par le LLM, avec un schéma JSON Schema pour les arguments. Exemples : search_docs(query), create_invoice(client_id, amount), get_order_status(order_id).
• Des resources — des données accessibles par URI. Exemples : un fichier, une ligne de base, une page wiki. Le LLM peut les lire, le client peut les afficher.

La communication se fait via JSON-RPC 2.0, soit sur stdio (le client lance le server comme un sous-process — pratique en local), soit sur HTTP/SSE (pour un server distant partagé).

Voici un MCP server minimal en TypeScript qui expose un tool search_docs :

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { CallToolRequestSchema, ListToolsRequestSchema } from "@modelcontextprotocol/sdk/types.js";
 
const server = new Server(
  { name: "docs-search", version: "0.1.0" },
  { capabilities: { tools: {} } }
);
 
server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [{
    name: "search_docs",
    description: "Recherche dans la base documentaire interne.",
    inputSchema: {
      type: "object",
      properties: { query: { type: "string" } },
      required: ["query"],
    },
  }],
}));
 
server.setRequestHandler(CallToolRequestSchema, async (req) => {
  const { query } = req.params.arguments as { query: string };
  const results = await searchVectorIndex(query); // votre code métier
  return { content: [{ type: "text", text: JSON.stringify(results) }] };
});
 
await server.connect(new StdioServerTransport());

Vingt-cinq lignes pour exposer un outil à Claude — et au passage à tout autre client MCP-compatible. Pour le brancher dans Claude Desktop, on ajoute une entrée dans le fichier de config :

{
  "mcpServers": {
    "docs-search": {
      "command": "node",
      "args": ["/chemin/vers/server.js"]
    }
  }
}

Redémarrez Claude Desktop, et le tool est disponible. C'est aussi simple que ça pour démarrer.

MCP vs API : la distinction qui compte

Question qu'on nous pose souvent : "Mais pourquoi pas juste une API REST classique ?" Réponse courte : parce que MCP est une API pour les LLMs, pas pour les développeurs.

La différence est dans le contrat. Une API REST traditionnelle est conçue pour qu'un développeur lise la doc, choisisse les bons endpoints, construise les bonnes requêtes. Un MCP server est conçu pour qu'un LLM découvre dynamiquement les tools disponibles, lise leurs descriptions, et décide lui-même quel appel faire selon le contexte de la conversation.

Concrètement, MCP apporte trois choses qu'une API REST ne donne pas gratuitement :

• La découverte au runtime. Le client appelle tools/list et reçoit la liste complète des tools avec leurs schémas. Pas besoin de coder en dur quels endpoints existent. Vous ajoutez un tool à votre server, il est immédiatement disponible pour tous les clients connectés.
• Les descriptions pensées pour un LLM. Chaque tool a une description en langage naturel. C'est ça que le modèle lit pour décider quand appeler le tool. Pas une doc Swagger pour humains, mais une instruction pour un raisonneur statistique. C'est un métier en soi.
• Un contrat unifié pour les ressources. Les resources (URIs lisibles par le client) permettent d'attacher du contexte sans passer par un tool call. Un fichier épinglé, une page de doc, une slide d'un deck — accessibles en URI.

Vous pouvez bien sûr wrapper votre API REST existante dans un MCP server (et on le fait souvent). Mais c'est le wrapper qui apporte la valeur, pas l'API sous-jacente.

Adoption début 2026

L'argument N×M ne tient que si M est grand — c'est-à-dire si beaucoup de clients supportent le protocole. Petit état des lieux des supports confirmés au moment où on écrit :

• Anthropic — Claude Desktop, Claude Code, l'API Claude. Support natif depuis l'origine.
• Cursor — l'éditeur IA, support MCP pour les tools custom.
• Continue — l'assistant open-source pour VS Code et JetBrains.
• Cline — agent autonome dans VS Code.
• Zed — l'éditeur de Nathan Sobo, intégration MCP native.
• OpenAI — annonce en mars 2025 du support MCP dans l'Agents SDK et d'autres produits. C'est le signal qui a fait basculer la perception du standard.
• Microsoft — support MCP annoncé dans Copilot Studio, ce qui ouvre la porte à des déploiements Microsoft 365.

Côté serveurs, l'écosystème officiel couvre déjà les cas courants : filesystem, GitHub, Postgres, Brave Search, Slack, Google Drive (via tiers). Plus quelques centaines de servers communautaires sur GitHub, de qualité variable.

On n'est pas encore au niveau de maturité de LSP, mais on est au-delà du point de bascule. Quand OpenAI adopte un standard initialement publié par un concurrent, c'est généralement que le standard a gagné.

Ce qu'on déploie chez nos clients

Le pattern qu'on retrouve le plus souvent chez nos clients PME, c'est l'index vectoriel exposé via MCP, avec citations vers la source. Concrètement :

• Un MCP server qui wrap un index Pinecone, Qdrant ou pgvector.
• Un tool search_documents(query, filters) qui renvoie les top-K passages avec métadonnées (titre, URL source, date).
• Le LLM frontal — Claude Sonnet la plupart du temps, parfois Mistral Large pour les contraintes de souveraineté — appelle le tool, reçoit les passages, génère une réponse avec citations.

On le combine souvent avec un deuxième MCP server pour l'auth métier : un tool get_user_permissions(user_id) qui renvoie les ACLs, ce qui permet au LLM de filtrer ce qu'il a le droit de retourner. Et un troisième pour les actions transactionnelles (créer un ticket, envoyer un mail), avec confirmation utilisateur côté client.

Ça donne une architecture où chaque domaine métier a son MCP server, déployé séparément, versionné séparément, testé séparément. C'est l'équivalent du microservice pour la couche tooling LLM — avec tous les avantages et certains des coûts opérationnels qui vont avec.

Pour le pourquoi du choix entre cette approche et un fine-tuning ou un RAG classique, on en a parlé ailleurs : RAG vs fine-tuning vs MCP.

Les limites qu'on n'avoue pas assez

MCP est un bon standard. Ce n'est pas une magic bullet. Voici ce qu'il ne résout pas, et qu'on doit concevoir au-dessus :

• L'authn et l'authz. Le protocole définit le transport et le format des messages, pas qui a le droit d'appeler quoi. Si votre MCP server expose delete_invoice, c'est à vous de vérifier que l'utilisateur sous-jacent a le droit. Le LLM ne le fera pas pour vous.
• La gouvernance des secrets. Un MCP server local lancé en stdio hérite des variables d'environnement du client. Un MCP server distant doit gérer ses credentials. Aucune des deux options n'est triviale dans un contexte entreprise.
• La latence des appels chainés. Si le LLM enchaîne quatre tool calls pour répondre à une question, vous payez quatre allers-retours réseau et quatre fenêtres de génération. La perception utilisateur en prend un coup. Streaming et parallélisation aident, mais ne résolvent pas tout.
• La dépendance au modèle pour orchestrer. MCP suppose que le LLM choisit le bon tool, au bon moment, avec les bons arguments. Sur des workflows complexes, ça reste imparfait, même avec Claude Sonnet ou GPT-5. Pour des process critiques, on garde un workflow déterministe (n8n, ou code custom) et on appelle le LLM uniquement aux endroits où l'ambiguïté est OK.
• L'audit et la traçabilité. Logger les tool calls, les arguments, les résultats — et garder ça lisible pour un audit RGPD ou FINMA — c'est entièrement à votre charge.

Quand ne pas utiliser MCP

MCP est génial pour donner au LLM un accès souple à des outils et à des données. Il l'est moins quand :

• Le process exige un déterminisme strict. Calcul de prime d'assurance, génération de bordereau réglementaire, fermeture comptable. Ne mettez pas un LLM dans la boucle de décision. MCP ou pas.
• L'audit légal est très contraint. Certaines réglementations exigent de pouvoir rejouer exactement le raisonnement qui a mené à une décision. Avec un LLM, c'est techniquement possible mais opérationnellement douloureux.
• L'intégration est ultra-spécifique et isolée. Si vous avez un seul système à brancher, et que vous savez que vous resterez sur un seul modèle pour les deux prochaines années, un connecteur natif (function calling OpenAI ou tools Claude) marche très bien et vous économisera la surcouche MCP.
• La performance est critique. Pour des cas où chaque milliseconde compte (recherche temps réel, autocomplétion), le surcoût du protocole peut être significatif. Mesurez avant de décider.

Pour le reste — c'est-à-dire la grande majorité des cas d'usage qu'on voit dans les PME — MCP est le bon choix par défaut en 2026. C'est notamment pourquoi on pousse vers ce type d'architecture plutôt que vers des solutions verrouillées : voir ChatGPT Enterprise ne suffit pas.

Essayez en local, ce soir

Le meilleur moyen de comprendre MCP, c'est de l'utiliser. Installez Claude Desktop, ajoutez le MCP server filesystem officiel (deux lignes de config), pointez-le sur un dossier de votre disque, et demandez à Claude de chercher quelque chose dedans.

Cinq minutes plus tard, vous aurez compris pourquoi on parle d'un changement de standard. Et vous aurez l'image mentale pour évaluer la prochaine démo "agent" qu'on viendra vous vendre.