Pourquoi MCP existe

Quand on construit des pipelines de données depuis un certain temps, on connaît les douleurs de l’intégration. Chaque nouvelle source exige du code sur mesure. Chaque API a son propre système d’authentification. Chaque connecteur de base de données a ses particularités. Multipliez cette complexité par le nombre d’applications IA qui ont besoin d’accéder à votre infrastructure de données.

C’est le problème N fois M que le Model Context Protocol (MCP) a été conçu pour résoudre.

Avant MCP, chaque source de données nécessitait sa propre implémentation. N applications IA avaient chacune besoin de M connecteurs personnalisés. Les modèles IA se retrouvaient bloqués derrière des systèmes legacy, sans accès au contexte dont ils avaient besoin. Chaque base de données, API ou système de fichiers exigeait du code dédié. Maintenir des connecteurs séparés devenait insoutenable à mesure que N et M grandissaient.

Anthropic a lancé MCP en novembre 2024 comme standard ouvert. Le protocole permet aux développeurs de créer des connexions sécurisées et bidirectionnelles entre les applications IA et les sources de données, outils et systèmes externes.

L’analogie qui a marqué les esprits : « USB-C pour l’IA ». Tout comme USB-C a remplacé un enchevêtrement de câbles propriétaires par un connecteur universel, MCP remplace les intégrations fragmentées par un protocole unique. On construit un connecteur une fois, et n’importe quelle application compatible MCP peut l’utiliser.

Pour les data engineers, vos bases de données, data warehouses et pipelines sont exactement le type de systèmes backend auxquels les assistants IA ont besoin d’accéder. Au lieu de construire des intégrations personnalisées pour Claude Desktop, puis Cursor, puis VS Code Copilot, puis tout ce qui viendra ensuite, vous construisez un seul serveur MCP qui fonctionne avec tous.

Contexte d’adoption (janvier 2026)

MCP a dépassé le stade expérimental. En janvier 2026 : plus de 97 millions de téléchargements mensuels du SDK, plus de 10 000 serveurs MCP actifs en production, et 75 300 étoiles GitHub sur le dépôt officiel des serveurs.

L’adoption s’est accélérée en 2025 avec l’arrivée des acteurs majeurs. OpenAI a adopté MCP en mars 2025, l’intégrant à son Agents SDK et à l’application desktop ChatGPT. Google DeepMind a suivi, et Microsoft a annoncé l’intégration MCP dans Windows 11 lors de Build 2025.

En décembre 2025, Anthropic a fait don de MCP à l’Agentic AI Foundation sous l’égide de la Linux Foundation, confirmant son statut de standard industriel neutre plutôt que de technologie propriétaire Anthropic.

Si vous vous demandez si cela vaut la peine d’investir du temps dans l’apprentissage de MCP, ces chiffres répondent à la question « est-ce que ça va durer ? ». Le protocole a franchi le seuil entre l’expérimentation intéressante et l’infrastructure sur laquelle on peut construire.

Architecture : trois participants

MCP utilise une architecture client-serveur avec trois participants : les hosts, les clients et les serveurs.

┌──────────────────────────────────────────────┐
│           Application Host                    │
│  (Claude Desktop, VS Code, Cursor, etc.)     │
│                                              │
│  ┌──────────────┐  ┌──────────────┐          │
│  │ MCP Client A │  │ MCP Client B │          │
│  │ (Database)   │  │ (File System)│          │
│  └──────┬───────┘  └──────┬───────┘          │
└─────────┼─────────────────┼──────────────────┘
          │                 │
          ▼                 ▼
   ┌──────────────┐  ┌──────────────┐
   │ MCP Server A │  │ MCP Server B │
   │ (Postgres)   │  │ (Filesystem) │
   └──────────────┘  └──────────────┘

Le host est l’application IA avec laquelle vous interagissez directement : Claude Desktop, VS Code avec Copilot, Cursor, ou un agent personnalisé que vous avez construit. Le host crée et gère les clients MCP.

Chaque client maintient une connexion vers exactement un serveur MCP. Si votre host doit communiquer à la fois avec une base Postgres et un système de fichiers, il crée deux clients, un pour chaque.

Le serveur, c’est là que vous intervenez. Un serveur MCP est un programme qui expose des capacités via le protocole MCP. Il peut exposer le schéma de votre data warehouse, exécuter des requêtes ou donner accès aux métadonnées de vos pipelines.

Sous le capot, MCP comporte deux couches : une couche données (JSON-RPC 2.0 gérant le cycle de vie, la négociation des capacités et les primitives) et une couche transport (gérant les canaux de communication, l’établissement de connexion et le cadrage des messages).

Mécanismes de transport

MCP supporte deux mécanismes de transport.

stdio pour les serveurs locaux

Quand le serveur MCP tourne sur la même machine que le host, stdio est l’option la plus simple. Le host lance le serveur en sous-processus et communique via les flux d’entrée/sortie standard. Pas de configuration réseau, pas de ports à ouvrir, pas de TLS à configurer.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/directory"]
    }
  }
}

Cette configuration indique au host de lancer un serveur MCP via npx, exécutant le package serveur filesystem avec accès à un répertoire spécifique. Le host et le serveur communiquent via stdin/stdout.

Streamable HTTP pour les serveurs distants

Pour les serveurs tournant sur d’autres machines, Streamable HTTP fournit la couche transport. Cela permet des scénarios de production où votre serveur MCP s’exécute dans un environnement cloud, derrière une authentification.

{
  "mcpServers": {
    "remote-server": {
      "url": "http://example.com/mcp",
      "env": {
        "API_KEY": "your-api-key"
      }
    }
  }
}

Streamable HTTP utilise le standard HTTP POST pour les messages client vers serveur, avec optionnellement des Server-Sent Events (SSE) pour les réponses en streaming. Il s’intègre avec OAuth 2.1 pour l’authentification.

Note : vous pourriez rencontrer des références à SSE comme mécanisme de transport. Celui-ci est en cours de dépréciation au profit de Streamable HTTP.

Format des messages

Toute communication MCP utilise JSON-RPC 2.0. Comprendre ces messages aide au debugging.

Quand un client se connecte à un serveur, ils négocient d’abord leurs capacités via un handshake d’initialisation.

Requête d’initialisation :

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "elicitation": {}
    },
    "clientInfo": {
      "name": "example-client",
      "version": "1.0.0"
    }
  }
}

Réponse d’initialisation :

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": {"listChanged": true},
      "resources": {}
    },
    "serverInfo": {
      "name": "example-server",
      "version": "1.0.0"
    }
  }
}

Une fois connecté, le client peut découvrir les outils proposés par le serveur :

Requête de découverte des outils :

{"jsonrpc": "2.0", "id": 2, "method": "tools/list"}

Et invoquer ces outils :

Requête d’appel d’outil :

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": {
      "query": "SELECT * FROM customers LIMIT 10",
      "database": "production"
    }
  }
}

Le format JSON-RPC est simple : chaque message a une version de protocole, un ID pour associer requêtes et réponses, un nom de méthode et des paramètres. Les réponses incluent le même ID plus soit un résultat, soit une erreur.

Primitives essentielles

MCP définit trois primitives serveur (ce que les serveurs exposent) et trois primitives client (ce que les clients exposent aux serveurs).

Primitives serveur

Les Tools sont la primitive la plus utilisée. Ils représentent des fonctions exécutables que le modèle IA peut invoquer : un outil de requête base de données, un outil de déclenchement de pipeline, un outil de validation de données. Les tools peuvent avoir des effets de bord, c’est pourquoi ils nécessitent une invocation explicite.

Les Resources fournissent des données contextuelles sans effets de bord. On peut les voir comme des endpoints en lecture seule. Une resource peut exposer la documentation des modèles de votre projet dbt ou les schémas des tables de votre data warehouse. L’IA peut récupérer des resources pour comprendre le contexte sans risque de modifier quoi que ce soit.

Les Prompts sont des templates réutilisables qui guident les interactions LLM. Un template de prompt « analyse de qualité des données » pourrait aider les utilisateurs à demander de manière cohérente des vérifications de qualité sur différentes tables.

En Python avec le framework FastMCP, ces primitives ressemblent à ceci :

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("DataServer")

@mcp.tool()
def query_database(query: str, database: str = "production") -> str:
    """Execute a SQL query against the specified database."""
    return f"Query executed on {database}: {query}"

@mcp.resource("schema://{table_name}")
def get_table_schema(table_name: str) -> str:
    """Get the schema for a specific table."""
    return f"Schema for {table_name}: id INT, name VARCHAR(255)..."

@mcp.prompt(title="Code Review")
def review_code(code: str) -> str:
    return f"Please review this code:\n\n{code}"

Primitives client

Les serveurs peuvent aussi demander des capacités aux clients :

Le Sampling mérite attention pour les cas d’usage en data engineering. Il permet à votre serveur MCP de demander au LLM du host d’analyser ou de résumer des données, permettant des workflows multi-étapes où le serveur récupère les données et le LLM les traite.

Les Roots définissent quels chemins du système de fichiers un serveur peut accéder. C’est une frontière de sécurité qui empêche les serveurs d’accéder à des fichiers en dehors de leur périmètre désigné.

Modèle de sécurité

La sécurité dans MCP suit un modèle de périmètres de confiance en couches :

User → AI Host → MCP Client → MCP Server(s) → Backend APIs/Databases
         │                          │
    Security Broker           Resource Server
    (Access Control)          (Token Validation)

Authentification avec OAuth 2.1

Pour les serveurs MCP distants, le protocole impose OAuth 2.1 pour l’authentification. PKCE (Proof Key for Code Exchange) est requis pour tous les flux, protégeant contre l’interception des codes d’autorisation. Les tokens sont scopés à des serveurs MCP spécifiques via les Resource Indicators (RFC 8707), et le Dynamic Client Registration (RFC 7591) est recommandé pour l’acquisition de credentials à l’exécution.

Principes de sécurité

L’application host agit comme intermédiaire de sécurité entre le LLM et les ressources externes.

Chaque serveur MCP s’exécute dans son propre processus avec ses propres credentials, de sorte qu’un serveur compromis ne peut pas accéder aux credentials d’autres serveurs. Les serveurs doivent valider que les tokens leur sont spécifiquement destinés. Ne jamais transmettre les tokens aux API en amont : cela prévient les attaques « confused deputy » où une requête malveillante trompe un serveur pour qu’il utilise son autorité au nom d’un attaquant.

Les opérations sensibles avec effets de bord nécessitent le consentement explicite de l’utilisateur. Le host présente les invocations d’outils à l’utilisateur avant de les exécuter. Et grâce à la primitive Roots, les serveurs n’accèdent qu’aux chemins du système de fichiers qui leur ont été explicitement accordés.

Pour les data engineers, cela signifie que vous pouvez construire des serveurs MCP qui accèdent aux bases de données de production sans exposer ces credentials au modèle IA lui-même. Les credentials restent dans le processus serveur, isolés à la fois du host et des autres serveurs.

MCP vs APIs traditionnelles

Vous vous demandez peut-être pourquoi MCP existe alors que les APIs REST connectent déjà les systèmes. La distinction clé tient au consommateur visé.

Les APIs traditionnelles sont conçues pour des développeurs humains qui lisent la documentation, comprennent les schémas et écrivent le code d’intégration. Elles fonctionnent bien pour la communication machine-to-machine quand le système appelant sait exactement ce dont il a besoin.

MCP est conçu pour des modèles IA qui découvrent les capacités à l’exécution, ont besoin d’un contexte riche sur ce que les outils peuvent faire, et bénéficient d’une communication bidirectionnelle. Un assistant IA ne lit pas votre documentation API. Il interroge les outils disponibles, lit leurs descriptions, et décide comment les utiliser en fonction de la demande de l’utilisateur.

Les APIs traditionnelles sont strictement initiées par le client : le client envoie une requête, le serveur répond. MCP supporte la communication initiée par le serveur via le sampling (demander au LLM de traiter des données) et l’elicitation (demander plus d’informations à l’utilisateur). Cela permet des workflows qui étaient difficiles ou impossibles avec REST.