MCP : le protocole qui va changer votre façon de travailler avec l'IA

Tu as 5 onglets ouverts. Cursor d'un côté pour coder. Claude de l'autre pour chercher. GitHub pour vérifier une PR. Slack pour comprendre le contexte d'un ticket. Et ton terminal pour déployer.

Chaque outil vit dans son monde. Tu passes ton temps à copier-coller du contexte d'un onglet à l'autre. L'IA dans Cursor ne sait pas ce que tu as dit dans Slack. L'agent dans Claude ne connaît pas ton dernier commit.

Le MCP résout exactement ça.

C'est quoi, le MCP ?

Le Model Context Protocol est un standard ouvert créé par Anthropic en 2024, maintenant gouverné par la Linux Foundation. L'idée est simple : un protocole universel qui connecte les agents IA à des outils externes.

Avant le MCP, chaque outil IA avait sa propre façon de se connecter aux APIs. ChatGPT avait ses plugins. Claude avait ses tools. Cursor avait ses integrations. Chaque combinaison = un code d'intégration différent.

Le MCP unifie ça. Un serveur MCP écrit une fois est utilisable par n'importe quel client compatible : Claude Desktop, Claude Code, Cursor, VS Code Copilot, ChatGPT, ou ton propre agent.

Avant MCP	Avec MCP
ChatGPT → plugin propriétaire	Tout client → serveur MCP standard
Claude → tool use custom	Cursor → même serveur MCP
Cursor → integration dédiée	Copilot → même serveur MCP
1 outil = 1 intégration	1 serveur = N clients

C'est exactement l'analogie utilisée dans la presse technique : USB-C pour les agents IA. Un standard. Un connecteur. Partout.

L'architecture en 3 couches

Le MCP définit 3 rôles :

Couche	Rôle	Exemple
Host	L'application qui initie la connexion	Claude Desktop, Cursor, VS Code Copilot
Client	Vit à l'intérieur du host, gère le protocole	Le client MCP intégré à Claude Code
Server	Expose des capacités (tools, resources, prompts)	Serveur GitHub, serveur PostgreSQL, le tien

Le serveur est "bête" : il écoute les requêtes et renvoie des résultats. C'est le client (l'agent IA) qui décide quand appeler quel outil, en se basant sur les descriptions et le contexte de la conversation.

Les 3 primitives

Le MCP définit 3 types de capacités qu'un serveur peut exposer :

Tools — Des fonctions que l'agent peut appeler. Lire un fichier, interroger une base, envoyer un Slack, créer une PR. C'est la primitive principale. 80% de la valeur vient des tools.

Resources — Des données en lecture seule que l'agent peut récupérer. Des fichiers, des lignes de base, des réponses d'API. Accessibles par URI (file:///, postgres://, etc.).

Prompts — Des templates de prompts réutilisables. Le client peut les injecter dans la conversation. Nice-to-have, pas essential.

En pratique, tu t'arrêtes aux tools. C'est eux qui font le travail.

Le concret : un serveur en 30 lignes

Un serveur MCP minimal, c'est 3 choses : un objet serveur, des définitions de tools, et des handlers.

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  ListToolsRequestSchema,
  CallToolRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";
import { readFile } from "node:fs/promises";

const server = new Server(
  { name: "mon-serveur", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: "lire_fichier",
      description: "Lit le contenu d'un fichier du projet",
      inputSchema: {
        type: "object",
        properties: {
          chemin: { type: "string", description: "Chemin du fichier" },
        },
        required: ["chemin"],
      },
    },
  ],
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;
  if (name === "lire_fichier") {
    const contenu = await readFile(args.chemin, "utf-8");
    return { content: [{ type: "text", text: contenu }] };
  }
  return { content: [{ type: "text", text: "Tool inconnu" }] };
});

const transport = new StdioServerTransport();
await server.connect(transport);

C'est tout. Tu l'ajoutes à ton .mcp.json :

{
  "mcpServers": {
    "mon-serveur": {
      "command": "node",
      "args": ["./dist/server.js"]
    }
  }
}

Et Claude Code, Cursor, ou Claude Desktop peut appeler lire_fichier directement dans la conversation. Pas de copier-coller. Pas d'onglet séparé.

Pourquoi un lead dev doit comprendre le MCP

1. Tu arrêtes de réinventer l'intégration

Sans MCP, chaque outil IA a sa propre façon de se connecter aux APIs. Tu écris 5 intégrations différentes pour 5 clients différents. Avec MCP, tu écris 1 serveur et il marche partout.

2. Tu construis un tissu d'outils pour ton équipe

Dans une boîte de 15 devs, tu peux avoir un serveur MCP par outil interne (Jira, Confluence, Datadog, GitHub, le CRM). Chaque dev peut utiliser n'importe lequel de ces outils depuis n'importe quel assistant IA. Nouvel outil ajouté au catalogue ? Tout le monde y a accès automatiquement.

3. Tu sépares le cycle de vie

Le MCP brille quand l'outil et l'agent ont des cycles de vie indépendants. Tu mets à jour ton serveur MCP sans toucher à l'agent. Tu changes d'agent (de Cursor à Claude Code) sans toucher au serveur. C'est du découplage propre.

Les 2 transports à connaître

Transport	Usage	Comment ça marche
stdio	Local, même machine	Le serveur tourne en sous-processus. Zéro réseau, zéro auth. Parfait pour le dev local.
Streamable HTTP	Remote, cloud	Un endpoint HTTP. Serveless friendly. Le default pour toute production en 2026.

Pour le dev local, stdio suffit. Pour partager un serveur avec ton équipe ou le déployer en prod, tu passes en HTTP.

Le piège à connaître : le coût contextuel

Les définitions de tools MCP consomment du contexte. Anthropic cite l'exemple d'une config multi-serveurs typique (GitHub, Slack, Sentry, Grafana, Splunk) : ~55 000 tokens de définitions avant même le premier prompt. C'est 27% d'une fenêtre de 200k tokens qui disparaît avant que tu poses ta question.

❝

La règle : commence avec 2-3 tools, pas 15. Chaque tool que tu ajoutes réduit l'espace disponible pour le travail réel. Les meilleurs serveurs MCP ont 5-10 tools ciblés, pas 30 tools "au cas où".

MCP v2 : ce qui change en juillet 2026

La spec release candidate 2026-07-28 est la plus grosse révision depuis le lancement. Le changement principal : le protocole devient stateless.

Plus de handshake initialize/initialized
Plus de Mcp-Session-Id
Les serveurs tournent derrière un load balancer round-robin classique
Chaque requête est autonome

Si tu construis des serveurs MCP aujourd'hui, c'est le bon moment pour migrer vers le stateless. Le déploiement devient identique à n'importe quel microservice HTTP.

Liens sélectionnés de la semaine

1. Effective Context Engineering for AI Agents (Anthropic). L'article de référence sur le context engineering. Complémentaire au numéro 2. Incontournable.

2. MCP Server Development: Complete 2026 Guide (AY Automate). Le guide le plus complet pour construire un serveur MCP de production. Sécurité, déploiement, auth. Très pratique.

3. How to Build Your First MCP Server (Alejandro Rioja). Le tutoriel pas-à-pas le plus accessible. 30 lignes de code, un serveur qui marche.

4. MCP in Production: A 2026 Field Guide (Coder Legion). Quand utiliser MCP vs quand ne pas l'utiliser. Le guide honnête qui manquait.

Outil de la semaine

MCP Inspector. L'outil officiel pour tester un serveur MCP. Tu lances npx @modelcontextprotocol/inspector node ./dist/server.js, tu as une UI web qui te permet d'appeler chaque tool, lire chaque resource, sans passer par un agent. Indispensable pour debugger avant de brancher Claude.

Une question pour toi

❝

Tu utilises déjà des MCP dans ton workflow ? Si oui, lesquels ? Si non, quel outil tu aimerais connecter en premier à ton agent IA ?

Une ligne. Ça m'aide à calibrer les prochains numéros sur votre stack réelle.