Le problème que MCP résout
Avant le Model Context Protocol, connecter des assistants IA à une infrastructure de données nécessitait de résoudre le problème N×M : chaque application d’IA avait besoin d’intégrations personnalisées vers chaque source de données. Chaque connecteur exigeait une authentification sur mesure, une gestion des erreurs spécifique et une maintenance continue.
MCP remplace ces intégrations personnalisées fragmentées par un protocole unique qui fonctionne à travers toutes les applications d’IA — une analogie parfois utilisée est « l’USB-C pour l’IA ».
MCP est un standard ouvert développé par Anthropic et désormais maintenu par l’Agentic AI Foundation sous la Linux Foundation. Début 2026 : plus de 97 millions de téléchargements de SDK, plus de 10 000 serveurs en production, et adoption par OpenAI, Google DeepMind, Microsoft et des leaders technologiques d’entreprise.
L’architecture à trois couches
MCP définit trois participants dans toute conversation entre une IA et vos systèmes de données.
Le Host est l’application d’IA avec laquelle vous interagissez directement : Claude Desktop, VS Code avec Copilot, Cursor, ou un agent personnalisé. Le host est la limite de sécurité, l’orchestrateur qui sait qui vous êtes et à quoi vous êtes autorisé à accéder.
Le Client est un pont. Chaque client MCP maintient exactement une connexion à un serveur MCP. Si votre host doit interroger à la fois une base de données Postgres et votre système de fichiers, le host crée deux clients, chacun gérant sa propre connexion.
Le Serveur est l’endroit où résident vos données — ou plus précisément, où vous exposez vos données via MCP. Un serveur MCP est un programme qui implémente le protocole et expose des capacités : requêtes de base de données, exploration de métadonnées, supervision de pipelines, contrôles de qualité des données. Construire un serveur, c’est écrire une logique métier dans votre langage préféré (Python, TypeScript, Go, Rust, etc.) et décorer des fonctions pour les marquer comme outils, ressources ou prompts.
Host (Claude, Cursor, VS Code) ├── MCP Client → MCP Server (Postgres) ├── MCP Client → MCP Server (Filesystem) └── MCP Client → MCP Server (Votre Data Warehouse)Communication : JSON-RPC et format de message
Toute communication MCP s’effectue via JSON-RPC 2.0, un protocole léger et sans état qui fonctionne partout. Lorsqu’un client se connecte à un serveur, ils commencent par une négociation d’initialisation — le client annonce ses capacités, le serveur répond avec ce qu’il peut faire. Ensuite, le client peut découvrir les outils disponibles, les invoquer et recevoir les réponses en streaming.
Pour les ingénieurs de données, comprendre le format de message facilite le débogage. Chaque message MCP comporte une version de protocole, un identifiant pour la correspondance requête-réponse, un nom de méthode et des paramètres. Lorsque vous appelez un outil, le client envoie un message tools/call avec le nom de l’outil et les arguments. Le serveur répond avec les résultats ou une erreur. C’est simple et facile à inspecter.
Le vrai pouvoir réside dans la façon dont MCP abstrait la complexité. Au lieu de construire des clients REST, d’analyser des specs OpenAPI et de gérer l’authentification par API, vous définissez des fonctions Python avec des décorateurs, et le SDK gère la sérialisation, la gestion du cycle de vie et la négociation de protocole.
Transport : comment les bits circulent
MCP prend en charge deux mécanismes de transport, et votre choix dépend de la topologie de déploiement.
Le transport stdio est destiné aux serveurs locaux — le host lance le serveur en tant que sous-processus et communique via les flux d’entrée/sortie standard. Aucune configuration réseau, aucun port à ouvrir, aucun TLS à gérer. Les identifiants de votre serveur restent dans des variables d’environnement sur cette machine, isolés du réseau. C’est idéal pour Claude Desktop et le développement.
Le transport HTTP Streamable est destiné aux serveurs distants — des serveurs fonctionnant dans des environnements cloud, partagés entre équipes ou derrière une authentification. Il utilise des requêtes HTTP POST standard pour les messages client-vers-serveur et des Server-Sent Events (SSE) optionnels pour les réponses en streaming. HTTP prend en charge l’authentification OAuth 2.1 avec PKCE (Proof Key for Code Exchange), qui empêche l’interception des codes d’autorisation. Les tokens sont délimités à des serveurs MCP spécifiques via les RFC 8707 Resource Indicators, de sorte qu’un serveur compromis ne peut pas utiliser des tokens destinés à un autre.
La plupart des équipes commencent avec stdio pendant le développement, puis passent à HTTP lorsqu’elles souhaitent un déploiement centralisé ou un accès inter-équipes. Le même code Python ou TypeScript fonctionne avec les deux transports ; il suffit de changer la façon dont le serveur démarre.
Les trois primitives du serveur
Tout ce qu’un serveur MCP expose appartient à trois catégories. Ces primitives définissent les capacités que le serveur met à disposition.
Les outils sont des fonctions exécutables que le modèle d’IA peut invoquer. Pensez aux requêtes de base de données, aux déclenchements de pipelines, aux contrôles de validation des données. Les outils peuvent avoir des effets de bord — ils peuvent modifier des données ou déclencher des jobs — donc ils nécessitent une invocation explicite. L’IA décide quand et comment les appeler en fonction de la demande de l’utilisateur. Les outils sont la primitive la plus utilisée car ils permettent à l’IA d’effectuer du travail.
Les ressources sont des sources de données en lecture seule. Elles ressemblent à des endpoints GET — le serveur fournit des informations, et l’IA peut les récupérer pour du contexte sans rien modifier. Une ressource peut exposer les schémas de tables de votre entrepôt, la documentation de votre projet dbt, ou des métadonnées sur vos pipelines. Les ressources donnent à l’IA les informations dont elle a besoin pour raisonner sur la prochaine action à prendre.
Les prompts sont des modèles réutilisables qui guident les interactions avec l’IA. Plutôt que les utilisateurs écrivent à chaque fois la même requête (« Analyse cette table pour des problèmes de qualité »), vous définissez un modèle de prompt « Analyse de la qualité des données ». L’IA l’invoque, le serveur retourne un prompt de requête structuré, et l’utilisateur bénéficie d’une cohérence. Les prompts sont initiés par l’utilisateur — celui-ci les choisit dans un menu.
Pour l’ingénierie de données spécifiquement : les outils rendent l’IA productive (elle peut interroger des tables, exécuter des contrôles, superviser des pipelines), les ressources la rendent informée (elle comprend votre schéma, la lignée et l’état actuel), et les prompts la rendent utile (les équipes disposent de workflows répétables et standardisés).
Sécurité et limites de confiance
La sécurité dans MCP suit un principe critique : l’application host agit comme intermédiaire de sécurité entre le LLM et vos systèmes back-end. Le modèle d’IA ne voit jamais les identifiants. Le host n’expose pas tous les serveurs à chaque requête — il contrôle ce à quoi l’utilisateur est autorisé à accéder et quels serveurs sont invoqués.
Chaque serveur MCP s’exécute dans son propre processus avec ses propres identifiants, de sorte que compromettre un serveur ne compromet pas les autres. Cette isolation est appliquée au niveau du système d’exploitation pour le transport stdio et par une authentification séparée pour le transport HTTP.
Pour les opérations sensibles, le consentement explicite de l’utilisateur est requis. Lorsque l’IA souhaite invoquer un outil avec des effets de bord — déclencher un pipeline, modifier des données — le host le présente à l’utilisateur pour approbation avant exécution. L’utilisateur voit exactement ce qui va se passer et peut le rejeter.
Un pattern de sécurité critique appelé « Roots » permet aux serveurs de spécifier des limites de système de fichiers. Un serveur peut se voir accorder l’accès à /data/warehouse/ mais explicitement refuser /etc/passwd. Cela empêche les serveurs de s’échapper de leur périmètre prévu.
Pour l’authentification sur les serveurs distants, MCP mandate OAuth 2.1 avec PKCE. L’enregistrement dynamique de client (RFC 7591) permet aux serveurs d’acquérir des identifiants à l’exécution sans stocker de secrets dans des fichiers de configuration. La validation des tokens se fait des deux côtés — le host s’assure que les tokens proviennent du bon émetteur, le serveur valide que les tokens sont délimités à son usage, et ni l’un ni l’autre ne transmet les tokens aux services back-end en amont (évitant les attaques « confused deputy » où une requête malveillante trompe un serveur pour qu’il utilise son autorité au nom d’un attaquant).
Ces couches d’isolation permettent de construire des serveurs MCP qui accèdent aux bases de données de production sans que l’IA voie les identifiants, sans que d’autres serveurs y accèdent, et avec une auditabilité complète de qui a autorisé quel accès et quand.
Pourquoi MCP, et pas les API REST ?
La question évidente : nous avons déjà des API REST et des spécifications OpenAPI. Pourquoi MCP existe-t-il ?
La réponse tient au consommateur visé. Les API REST traditionnelles sont conçues pour des développeurs humains qui lisent la documentation, comprennent les schémas et écrivent du code d’intégration spécifique. L’API définit un contrat, le développeur comprend ce contrat et développe en conséquence. Requête-réponse, sans état, uniquement initié par le client.
MCP est conçu pour des modèles d’IA qui découvrent les capacités au moment de 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 d’API. Il interroge les outils disponibles, lit leurs descriptions et schémas, et décide comment les utiliser en fonction de la conversation. MCP prend en charge la communication initiée par le serveur via le sampling (permettant à votre serveur de demander que le LLM traite des données) et l’elicitation (permettant à votre serveur de demander plus d’informations à l’utilisateur). Ces capacités bidirectionnelles permettent des workflows qui sont maladroits ou impossibles avec REST.
MCP gère également plusieurs types de contenu naturellement — texte, images, ressources, structures imbriquées — tandis que les API REST retournent typiquement des schémas JSON fixes. Pour l’analyse exploratoire de données où l’IA a besoin de comprendre des structures complexes et de poser des questions de suivi, la flexibilité de MCP compte.
Cela dit, MCP n’est pas toujours le bon outil. Pour certains patterns d’accès aux entrepôts de données, les commandes CLI natives peuvent être plus efficaces en tokens que MCP. Pour les intégrations machine-à-machine à haut débit, REST est souvent plus simple. MCP brille lorsque vous connectez des assistants d’IA orientés humains à vos systèmes internes, en permettant à ces assistants d’explorer, de questionner et de guider l’action.
Le protocole en production
MCP scale sans réécriture. Le même serveur Python FastMCP qui s’exécute localement en mode stdio peut être déployé dans un environnement cloud avec le transport HTTP et l’authentification OAuth. Une équipe peut commencer avec Claude Desktop, puis ajouter Cursor, puis s’intégrer avec un agent personnalisé, sans changer le code du serveur ni reconstruire les connecteurs.
Plus de 5 800 serveurs MCP communautaires existent début 2026. L’écosystème MCP comprend des serveurs officiels pour les principales bases de données (Snowflake, BigQuery via Google’s GenAI Toolbox, ClickHouse), des outils de données (dbt, Databricks) et des plateformes (GitHub, Slack, Jira). Des serveurs communautaires couvrent d’autres plateformes, et un serveur personnalisé de base représente environ 50 lignes de Python.
Pour les ingénieurs de données, l’architecture permet de donner aux assistants d’IA un accès en temps réel à l’infrastructure de données — schéma, lignée, métriques de qualité, statut des pipelines — sans exposer les identifiants, sans dupliquer la logique d’authentification, et sans construire des intégrations séparées par outil d’IA.