Si vous avez recherché « model context protocol architecture diagram » en espérant trouver quelque chose que vous pourriez réellement dessiner sur un tableau blanc et expliquer à votre équipe, vous êtes au bon endroit. La plupart des explications sur MCP s'arrêtent à « il connecte l'IA aux outils » ou se plongent directement dans les détails de la spécification sans jamais répondre à la question architecturale fondamentale : qui communique avec qui, dans quel ordre, et qui est responsable de quoi.
Cet article vous donne une vision au niveau de l'implémentation. Pas seulement des définitions.
Ce que la plupart des équipes découvrent après la mise en production
- MCP se place au-dessus des API : il standardise la manière dont les LLM découvrent et appellent les API, il ne les remplace pas.
- L'architecture client-serveur ouverte signifie qu'un hôte peut exécuter plusieurs clients, chacun se connectant indépendamment à un serveur différent.
- MCP définit l'interface d'intégration ; le contrôle des accès, la gouvernance des données et la sécurité sont à votre charge.
Ce qu'est le Model Context Protocol et pourquoi Anthropic l'a introduit
Le model context protocol est un protocole ouvert introduit par Anthropic en novembre 2024. La définition de la spécification officielle est précise : MCP est une manière standardisée pour les applications d'IA de se connecter à des sources de données, outils et systèmes externes via une interface cohérente, au lieu de créer une connexion sur mesure pour chacun d'eux.
C'est précisément ce dernier point qui compte. Avant MCP, chaque équipe qui connectait un LLM à un outil écrivait son propre adaptateur. Format différent, approche d'authentification différente, gestion des erreurs différente. Multipliez cela par des dizaines d'outils, et vous obtenez des dizaines d'intégrations ponctuelles à maintenir séparément. La norme MCP existe pour ramener tout cela à une forme de protocole unique.
Anthropic l'a introduit, mais ce n'est pas un produit exclusif à Anthropic. La spécification MCP est ouverte, maintenue publiquement et déjà adoptée dans les IDE, assistants de code, plateformes d'IA et piles d'agents d'entreprise. Au premier trimestre 2026, la cartographie de l'écosystème des protocoles de DigitalApplied a identifié MCP aux côtés d'A2A, ACP et UCP comme quatre protocoles distincts bénéficiant d'une adoption significative dans le secteur. Cela signifie que MCP n'est plus une curiosité expérimentale. Il fait partie de la manière dont les systèmes d'agents en production sont réellement construits.
Le model context protocol permet à toute application d'IA conforme d'accéder à tout outil ou source de données conforme, sans intégration personnalisée pour chaque paire. C'est toute sa proposition de valeur. Tout le reste en découle.
Le modèle client-serveur derrière l'architecture MCP
La spécification MCP officielle décrit une architecture client-hôte-serveur dans laquelle chaque hôte peut exécuter plusieurs instances clientes. Quatre composants. Chacun est distinct.
Voici ce qui déroute les utilisateurs : les termes « client » et « serveur » ont une signification précise dans MCP qui ne correspond pas toujours à l'usage de ces mots dans les réseaux en général. Et « hôte » désigne encore autre chose, pas simplement un autre mot pour serveur. Décomposons cela afin que vous puissiez réellement dessiner le diagramme.
Hôte MCP : l'application qui exécute le LLM
L'hôte MCP est l'application qui intègre ou exécute le grand modèle de langage et lance l'ensemble du processus. Pensez à Claude Desktop, Cursor ou à une application d'IA personnalisée créée par votre équipe. L'hôte est ce avec quoi l'utilisateur interagit réellement.
L'hôte est également responsable du contrôle des accès et de la gouvernance des données. Ce détail est constamment négligé, alors qu'il est crucial en production. MCP ne sécurise pas automatiquement les systèmes. L'hôte décide quels serveurs peuvent être connectés, à quel périmètre de données chaque client peut accéder et qui est autorisé à invoquer quels outils. Si vous déployez une application d'IA qui interagit avec des systèmes sensibles sans avoir réfléchi à cette couche, vous avez mis en production une faille de gouvernance.
Un hôte, plusieurs clients. C'est le modèle.
Client MCP : le connecteur un-à-un au sein de l'hôte
Chaque client MCP vit à l'intérieur de l'hôte et maintient une connexion un-à-un avec un seul serveur MCP. Un client, un serveur. C'est la contrainte.
Mais un même hôte peut démarrer plusieurs clients simultanément, chacun pointant vers un serveur différent. Ainsi, si votre hôte doit communiquer en même temps avec un serveur de bases de données, un serveur GitHub et un serveur interne de gestion des tickets, il exécute trois clients. Chaque client gère son propre cycle de vie de connexion, son propre état de session et communique indépendamment avec le serveur qui lui est associé.
La distinction entre serveur et client est importante ici : le client n'est pas l'élément visible par l'utilisateur. C'est la couche de connecteur à l'intérieur de l'hôte. Les traiter comme interchangeables est le moment où les diagrammes commencent à devenir erronés.
La checklist pratique avant de mettre cela en place :
- Vérifiez que l'application hôte prend en charge plusieurs connexions clientes simultanées.
- Chaque paire client-serveur nécessite sa propre configuration d'authentification.
- Le cycle de vie du client (démarrage, arrêt, gestion des erreurs) est géré par l'hôte.
- Si un serveur tombe en panne, seul le client qui y est connecté est affecté, et non l'ensemble de l'hôte.
Serveur MCP : exposition des outils, ressources et prompts
Le serveur MCP est le processus indépendant qui expose des capacités au client. C'est ce que votre équipe construit, ou adopte à partir d'une bibliothèque d'implémentations de serveurs MCP existants, lorsque vous souhaitez donner à un LLM l'accès à une source de données ou à un outil interne.
Un serveur expose trois types de capacités, appelées primitives : les outils, les ressources et les prompts. Nous couvrirons ces trois éléments dans la section suivante.
Le serveur s'exécute indépendamment de l'hôte. Il n'a pas besoin de savoir quel hôte ou client s'y connecte. Cette indépendance rend l'écosystème composable : vous pouvez créer un serveur pour votre instance interne de Confluence et tout hôte MCP conforme peut s'y connecter. Aucun connecteur personnalisé par application d'IA. Le serveur expose simplement ses capacités ; le client les découvre.
Du point de vue de la décision de développement, c'est là que se fait le vrai travail. Lorsque les équipes demandent « comment connecter notre assistant IA à nos outils internes ? », la réponse est : vous créez ou adoptez un serveur MCP pour chaque outil. Les sources de données auxquelles votre LLM doit accéder sont empaquetées sous forme de ressources et d'outils côté serveur.
Primitives MCP : explication des outils, ressources et prompts
La spécification MCP définit trois types de capacités que les serveurs exposent aux clients. Elles sont appelées primitives et rendent MCP utile au-delà d'une simple définition générique de protocole. Chacune répond à un objectif différent.
Comprendre les trois vous permet de passer de « MCP connecte l'IA aux outils » à « voici ce que notre serveur expose réellement et pourquoi ».
Outils et appels de fonctions dans MCP
Les outils MCP sont des fonctions exécutables que le LLM peut invoquer via le client. Si vous avez utilisé les appels de fonctions dans l'API d'OpenAI, le modèle vous est familier : vous décrivez une fonction, le grand modèle de langage décide quand l'appeler, puis elle est appelée avec des arguments spécifiques.
Ce que MCP standardise, c'est la manière dont les modèles d'IA découvrent ces fonctions sur différents serveurs. Sans MCP, chaque serveur utilise son propre format de découverte. Avec MCP, le client demande au serveur de lister ses outils disponibles avec le même format de requête, quel que soit le serveur. Le LLM voit un schéma d'outil cohérent, quel que soit le nombre de serveurs impliqués.
Exemple concret : un serveur pour GitHub expose des outils tels que search_repository, get_file_contents et create_pull_request. Le LLM peut tous les découvrir, comprendre leurs paramètres et les exécuter via le client sans aucune intégration personnalisée côté hôte. Le serveur s'appuie sur des appels d'API vers GitHub pour ces outils. MCP se place au-dessus de ces API ; il ne les remplace pas.
Le protocole MCP gère également ce qui se passe lorsqu'un appel d'outil échoue, est limité par le débit ou renvoie une réponse inattendue. Ce cycle de vie se situe au niveau du protocole, ce qui signifie que le LLM n'a pas à le gérer directement.
Accès aux données via les ressources MCP
Les ressources sont le mécanisme utilisé par les serveurs MCP pour exposer des données structurées ou non structurées au client. Là où les outils exécutent des actions, les ressources fournissent du contexte. Un outil peut exécuter une requête de base de données ; une ressource expose le schéma afin que le LLM puisse fournir un contexte pertinent avant de décider quoi interroger, ou inclure directement des données dans son raisonnement.
Les ressources peuvent être des documents, des enregistrements de base de données, le contenu de fichiers, des résultats d'analytique, ou tout élément donnant au LLM des informations utiles. Le client les récupère, et le serveur renvoie les données dans un format standardisé.
C'est important pour les équipes qui connectent des applications LLM à des sources de données existantes. Au lieu d'écrire une logique de récupération personnalisée pour chaque source, vous encapsulez la source dans un serveur MCP et exposez les données pertinentes sous forme de ressources. Le LLM peut les interroger sans rien connaître du système de stockage sous-jacent.
Couche de transport : comment STDIO et HTTP+SSE font circuler les messages entre le client et le serveur
La couche de transport est le canal de communication entre le client MCP et le serveur. La spécification MCP utilise JSON-RPC 2.0 comme format de message pour tous les transports, ce qui signifie que la structure des requêtes et des réponses reste cohérente, quelle que soit la couche de transport choisie.
Deux transports sont définis dans le protocole de base : STDIO et HTTP avec Server-Sent Events.
STDIO est le transport local. L'hôte lance le serveur MCP comme sous-processus, et le client ainsi que le serveur communiquent via les flux d'entrée et sortie standard. C'est typique des déploiements MCP locaux, où le serveur s'exécute sur la même machine que l'hôte. La plupart des intégrations IDE, telles que Cursor et les extensions VS Code, utilisent STDIO car le serveur est un processus local. La configuration est simple ; il n'y a aucune surface réseau à gérer.
HTTP+SSE est le transport distant. Le serveur s'exécute comme processus distinct, potentiellement sur une autre machine ou dans un autre environnement, et la communication entre le client MCP et le serveur passe par HTTP. Les Server-Sent Events gèrent les messages du serveur vers le client, tandis que le client envoie ses messages via des requêtes HTTP POST classiques. C'est ce que vous utilisez lorsque le serveur est hébergé à distance, partagé entre plusieurs hôtes ou déployé comme service.
Les versions de protocole pour chacun sont définies dans la spécification, et les deux transports ne sont pas interchangeables à l'exécution. Vous en choisissez un au moment du déploiement, et ce choix a des conséquences.
| Situation | Transport | Pourquoi |
|---|---|---|
| Sous-processus local (plugin IDE, application de bureau) | STDIO | Même machine, faible surcharge, aucune exposition réseau |
| Serveur distant partagé (accès à l'échelle de l'équipe) | HTTP+SSE | Multi-machines, accessible depuis plusieurs hôtes |
| Serveur déployé dans le cloud | HTTP+SSE | Accessible par le réseau par conception |
| Développement/tests sur une machine locale | STDIO | Configuration la plus simple, aucune configuration d'authentification requise |
🤔 Attendez.
Le choix du transport semble relever d'une préférence de connectivité. Il s'agit en réalité d'une décision de frontière architecturale. STDIO implique que votre serveur s'exécute sur la machine de l'hôte MCP : cela définit votre modèle de déploiement, votre périmètre de sécurité et la possibilité de partager le serveur avec d'autres hôtes. HTTP+SSE signifie que votre serveur est accessible sur le réseau : cela ouvre des questions de gouvernance entièrement différentes. Le choix « simple » s'accompagne d'engagements architecturaux.
Comment l'architecture MCP se compare à une intégration API directe
Voici l'idée fausse la plus persistante que je rencontre : MCP remplacerait les API. Ce n'est pas le cas. Soyons clairs sur ce qu'il fait réellement.
MCP est une couche de protocole standard qui se place au-dessus des API. Lorsqu'un serveur MCP expose un outil tel que search_database, cet outil s'appuie sur un appel d'API, une requête de base de données ou une lecture de fichier. MCP standardise la manière dont le LLM découvre et invoque l'outil. L'API sous-jacente existe toujours. MCP fournit simplement une interface cohérente pour l'appeler.
L'analogie la plus parlante est le Language Server Protocol, utilisé par tous les principaux éditeurs de code. LSP a standardisé la manière dont les éditeurs communiquent avec les outils d'analyse de langage. Avant LSP, chaque éditeur écrivait des intégrations personnalisées avec chaque serveur de langage. Après LSP, tout éditeur conforme peut se connecter à tout serveur de langage conforme. MCP applique le même modèle aux applications d'IA et aux outils externes.
Le problème de connexion des systèmes d'IA que MCP résout est parfois appelé le problème d'intégration N×M. Sans protocole standard, N applications d'IA devant se connecter à M outils nécessitent jusqu'à N×M connecteurs personnalisés. Avec une norme MCP, chaque application d'IA implémente MCP une fois, côté client, chaque outil implémente MCP une fois, côté serveur, et toute paire conforme peut se connecter.
📊 En pratique :
Sans MCP, connecter des assistants IA à cinq outils internes implique cinq couches d'intégration personnalisées, chacune avec sa propre authentification, gestion des erreurs et mécanisme de découverte, maintenues séparément à mesure que les cinq outils évoluent. Avec MCP, un seul client conforme dans l'hôte se connecte aux cinq serveurs avec le même protocole. Lorsqu'un serveur met à jour son schéma d'outils, le client découvre le changement via le flux standard de négociation des capacités, et non via une mise à jour d'adaptateur sur mesure.
Les systèmes externes dont votre LLM a besoin — bases de données, API, stockages de fichiers, services internes — ne disparaissent pas derrière MCP. Ils sont toujours là. MCP vous évite simplement d'écrire un connecteur unique pour chaque application d'IA qui doit y accéder.
Où l'architecture MCP s'inscrit dans les workflows d'IA agentique
Voici une autre idée fausse qu'il convient d'aborder directement : MCP n'est pas un framework d'agents.
Un système agentique a besoin, au minimum, d'une couche de planification, qui décide de la prochaine action ; d'une couche de mémoire ou de gestion du contexte, qui suit ce qui s'est passé ; et d'une couche d'accès aux outils, qui se connecte aux systèmes externes pour réaliser des actions. MCP gère la troisième. Il ne gère pas les deux premières.
Lors de la création d'agents d'IA, le framework d'agents situé au-dessus de MCP est responsable de la logique : quel objectif poursuivre, quelles étapes suivre, quand réessayer, quand abandonner, comment gérer le contexte sur plusieurs tours. MCP gère la façon dont ces outils et sources de données sont accessibles une fois que le framework a décidé d'y accéder.
La relation est la suivante : les systèmes agentiques utilisent MCP pour atteindre les outils ; ils n'utilisent pas MCP pour exécuter les agents.
Cette distinction est importante lors de la conception de systèmes agentiques. Lorsque votre workflow commence à se comporter anormalement, vous devez savoir si le problème se situe dans la logique de l'agent — mauvaise décision, mauvais objectif, mauvaise gestion du contexte — ou dans la couche d'accès aux outils — mauvais serveur, appel échoué, mauvais paramètre. Si vous avez confondu les deux, le diagnostic devient beaucoup plus difficile.
En pratique, le workflow se place au-dessus de MCP dans la pile. Le framework d'agents décide quand appeler un outil ; MCP gère la manière dont cet appel est effectué et dont la réponse revient. Le comportement d'IA sensible au contexte dépend du framework d'agents pour gérer le contexte ; MCP fournit uniquement le mécanisme permettant de récupérer du contexte supplémentaire lorsque le framework le demande.
Exemple concret : une équipe d'outillage pour développeurs d'une organisation d'ingénierie de taille moyenne souhaitait que son assistant de code IA recherche dans des référentiels de code internes, déclenche des exécutions CI/CD et crée des tickets d'incident sans quitter l'IDE. Elle a créé trois serveurs MCP, un pour chaque outil, chacun exposant les outils et ressources pertinents, puis les a connectés à l'hôte IDE via la couche cliente. Les systèmes d'IA dans l'IDE appellent désormais ces outils. Mais la logique qui détermine quand déclencher une exécution CI plutôt que simplement afficher un avertissement réside dans le framework d'agents au-dessus de l'ensemble. La communication entre les composants d'IA et les serveurs relève de MCP. Le raisonnement sur l'action à entreprendre n'en relève pas.
Si vous utilisez conjointement AI Agent Builder et MCP Server Builder de Latenode, cette séparation devient visible dans le canvas : le serveur MCP expose les outils disponibles, et le workflow d'agent décide quand les invoquer. Cette séparation ne constitue pas seulement une architecture propre sur un diagramme : elle rend le débogage possible lorsqu'un agent prend une mauvaise décision.
Responsabilités en matière de sécurité et de gouvernance dans un déploiement MCP
MCP définit l'interface d'intégration. Il ne met pas en œuvre votre politique de sécurité. Les équipes qui mettent en production des systèmes connectés à MCP en s'attendant à ce que le protocole gère le contrôle des accès le découvrent en production, généralement à un moment peu opportun.
Voici les responsabilités qui relèvent de votre implémentation, et non de MCP lui-même :
- Application du contrôle des accès (hôte)
L'hôte décide à quels serveurs MCP chaque client peut se connecter et quel périmètre est autorisé pour chaque connexion. MCP ne fournit aucun mécanisme intégré pour empêcher un client de se connecter à un serveur auquel il ne devrait pas avoir accès. L'application d'IA doit implémenter explicitement cette vérification avant de démarrer un client.
- Définition du périmètre des données par outil et ressource (serveur)
Le serveur est chargé de renvoyer uniquement les données que le demandeur est autorisé à consulter. Si votre serveur MCP encapsule une base de données et qu'un client envoie une requête de ressource, le serveur doit appliquer les contrôles d'accès au niveau des lignes ou du schéma avant de renvoyer les résultats. Le modèle de langage et la couche cliente ne peuvent pas savoir si les données renvoyées ont été correctement limitées.
- Gestion du cycle de vie de l'authentification (hôte et serveur)
Les jetons OAuth, clés API et identifiants de service expirent. L'hôte doit gérer le renouvellement des jetons pour les clients, et le serveur doit valider l'authentification à chaque requête, pas uniquement au moment de la connexion. Un schéma d'échec courant : l'authentification passe au démarrage, se dégrade silencieusement, puis commence à renvoyer des erreurs 401 plusieurs heures plus tard. Le tableau de bord semble souvent normal jusqu'à ce que quelqu'un remarque que les données ne circulent plus.
- Journalisation d'audit (hôte et serveur)
MCP n'inclut aucune piste d'audit intégrée. Si vous avez besoin d'un historique indiquant quels outils ont été appelés, avec quels arguments, par quel client et quelles réponses ont été renvoyées, vous devez créer cette journalisation vous-même, à la fois côté serveur pour les invocations d'outils et côté hôte pour les événements de session.
- Isolation des serveurs (serveur)
Chaque serveur MCP doit fonctionner indépendamment, avec son propre ensemble d'identifiants et son propre périmètre d'accès. Un serveur disposant de permissions étendues qui est compromis expose tout ce qui entre dans ce périmètre. Si une requête échoue sur un serveur, elle ne devrait pas se propager aux autres. L'isolation est une décision architecturale, pas une garantie du protocole.
