Depuis sa publication par Anthropic fin 2024, le Model Context Protocol est devenu rapidement le standard de facto pour connecter les LLM aux sources de données externes. En 2026, MCP est supporté nativement par Claude, GPT-4, Gemini, Mistral et la grande majorité des frameworks d'agents. Comprendre MCP est devenu un prérequis pour tout architecte travaillant sur des systèmes de context engineering en production.
Qu'est-ce que le Model Context Protocol (MCP) ?
MCP est une spécification de protocole qui définit comment un client LLM communique avec un serveur de contexte. Il standardise trois types d'interactions :
- Tools (outils) : fonctions que le LLM peut appeler : une recherche dans une base documentaire, une requête SQL, un appel API.
- Resources (ressources) : données statiques ou dynamiques que le LLM peut consulter : un fichier, un document, un snapshot de base de données.
- Prompts : templates de prompts réutilisables exposés par le serveur.
Avant MCP, chaque intégration LLM ↔ source de données nécessitait un développement ad hoc. MCP normalise cette couche d'intégration, rendant les connecteurs interopérables entre tous les LLM compatibles. C'est l'équivalent, pour l'IA, de ce qu'était HTTP pour le web.
Architecture MCP dans un pipeline de context engineering
Dans une architecture de context engineering, MCP joue le rôle de couche de transport entre les sources de contexte et le LLM. Voici comment les composants s'articulent :
Le client MCP (côté LLM)
C'est l'application ou l'agent qui utilise le LLM. Il envoie des requêtes aux serveurs MCP pour récupérer du contexte ou exécuter des outils. Claude Desktop, VS Code Copilot, Cursor et la plupart des agents LLM modernes sont des clients MCP natifs.
Les serveurs MCP (côté sources)
Chaque serveur MCP expose un ensemble de sources de contexte via le protocole standard. Il peut s'agir d'un serveur dédié à Notion, d'un autre à votre base SQL, d'un troisième à votre moteur RAG interne. Chaque serveur est indépendant et peut être développé dans n'importe quel langage (Python, TypeScript, Go…).
Le hub de contexte (orchestrateur)
Dans une architecture mature, un orchestrateur centralise les appels aux différents serveurs MCP selon la requête. C'est lui qui décide quel serveur interroger, dans quel ordre, avec quel budget de tokens. C'est la couche d'intelligence du context engineering.
Pourquoi MCP change les règles du jeu en entreprise
Fin du vendor lock-in contextuel
Avant MCP, si vous construisiez votre pipeline de contexte autour de l'API d'un LLM particulier, vous étiez dépendant de ce fournisseur. Avec MCP, votre architecture de contexte est indépendante du LLM. Migrer de Claude vers GPT-4o ou vice-versa ne nécessite pas de refondre vos connecteurs de contexte.
Sécurité et gouvernance natives
MCP intègre nativement des mécanismes d'authentification (OAuth 2.0, JWKS) et de contrôle d'accès au niveau du transport. Chaque appel à un serveur MCP est authentifié et loggé. C'est une fondation solide pour la conformité RGPD et AI Act.
Écosystème ouvert en croissance rapide
Plus de 5 000 serveurs MCP open source couvrent déjà les principales sources de données enterprise : Notion, Confluence, Slack, GitHub, Snowflake, Salesforce, Google Drive, SharePoint et des dizaines d'autres. Vous n'avez pas nécessairement à développer vos connecteurs from scratch.
Implémenter MCP dans votre architecture : les étapes pratiques
Étape 1 : Identifier vos sources prioritaires
Listez les sources que votre LLM doit interroger en priorité. Pour chacune, vérifiez si un serveur MCP open source existe déjà. Si oui, évaluez sa maturité (tests, maintenance, sensibilité sécurité). Si non, planifiez son développement : un serveur MCP simple se développe en quelques heures avec FastMCP (Python) ou le SDK TypeScript officiel.
Étape 2 : Déployer vos serveurs MCP
Déployez chaque serveur MCP en local (stdio) pour les environnements de développement, en HTTP streamable (avec OAuth/JWKS) pour la production. Le mode stdio est immédiat à mettre en place. Le mode HTTP produit est plus complexe mais obligatoire pour la conformité et la scalabilité.
Étape 3 : Configurer l'orchestration
Un LLM connecté à 10 serveurs MCP sans orchestration créera du bruit et des inefficacités. L'orchestrateur doit implémenter une logique de routing : pour quelle requête aller chercher quel contexte, dans quel serveur, avec quel budget de tokens. C'est la couche intelligente qui transforme un ensemble de connecteurs en un vrai pipeline de context engineering.
Étape 4 : Activer les métriques de qualité
Chaque appel MCP doit être logué avec suffisamment d'information pour calculer des métriques RAGAS : quelle ressource a été utilisée, quel chunk a été retourné, quelle réponse a été produite. Sans cette instrumentalisation, vous ne pouvez pas mesurer ni améliorer la qualité de votre contexte.
Étape 5 : Tester et sécuriser
Avant mise en production, testez vos serveurs MCP sur : la précision des outils exposés, la robustesse face aux entrées malformées, la résistance aux tentatives d'injection de prompt via des documents malicieux. Un serveur MCP qui ingère du contenu utilisateur non filtré est un vecteur d'attaque potentiel.
MCP vs RAG : complémentaires, pas concurrents
Une confusion fréquente : penser que MCP remplace le RAG. Ce n'est pas le cas. Voici comment les deux coexistent :
| Aspect | MCP | RAG |
|---|---|---|
| Rôle | Protocole de transport et d'exposition | Technique de retrieval sémantique |
| Ce qu'il résout | Connexion standardisée LLM ↔ source | Sélection des fragments pertinents |
| Relation | Un serveur MCP peut exposer un moteur RAG | Un pipeline RAG peut être exposé via MCP |
| Maturité | Standard 2024, adopté massivement | Technique établie depuis 2023 |
Dans notre architecture Dataloma : le serveur MCP de context hub expose un moteur de retrieval hybride (vectoriel + BM25) comme outil. Le RAG est la technique ; MCP est le canal par lequel le LLM y accède.
Les pièges courants à éviter
Trop de serveurs MCP non orchestrés
Connecter 20 serveurs MCP sans orchestrateur crée une surcharge contextuelle. Le LLM ne sait pas quoi appeler, quand, et avec quelle priorité. Résultat : latences élevées, contextes contradictoires, coûts en tokens inutiles.
Serveurs MCP sans authentification en production
Le mode stdio est pratique en développement. En production, tout serveur MCP doit être derrière une authentification OAuth 2.0 avec scope de permissions minimal. Un serveur MCP non authentifié expose vos sources de données à toute application qui peut le rejoindre.
Absence de versioning des serveurs MCP
Un changement d'API dans votre serveur MCP sans versioning peut casser silencieusement tous les agents qui l'utilisent. Exposez toujours vos serveurs MCP avec un numéro de version explicite et maintenez la compatibilité ascendante.
L'architecture Dataloma : MCP au cœur du context engineering
Dataloma a été architecturé dès l'origine autour de MCP. Notre plateforme expose trois serveurs MCP :
- dataloma-context-hub : moteur hybride (vectoriel + BM25 + GraphRAG), mémoire persistante, évaluation RAGAS. Plus de 80 outils MCP exposés.
- dataloma-ingestion : pipeline multi-sources (Notion, Confluence, GitHub, Snowflake, Slack, CSV/Excel, multimodal). Plus de 100 outils MCP exposés.
- dataloma-orchestrator : patterns multi-agents, quality scoring DQ, knowledge graph persistant. Plus de 60 outils MCP exposés.
Chaque serveur communique via MCP, est compatible avec tous les LLM du marché et peut être déployé localement (stdio) ou en production (HTTP streamable avec OAuth).
C'est cette architecture qui permet à nos clients de déployer un context engineering d'entreprise sans dépendance à un seul fournisseur LLM et avec une traçabilité native de chaque interaction.