Si vous avez trouvé cet article en recherchant « qu'est-ce que MCP » ou « model context protocol JSON-RPC », vous vous trouvez probablement dans l'une de ces deux situations. Soit vous avez lu quatre articles sur MCP sans toujours pouvoir expliquer en une phrase ce qu'il fait réellement, soit quelque chose dans votre chaîne d'outils IA se comporte étrangement et quelqu'un a évoqué MCP comme raison. Dans les deux cas, vous êtes au bon endroit.
MCP est décrit de bien des façons : comme un framework, une plateforme, un connecteur IA, ou un moyen de fournir des outils aux LLM. La plupart de ces descriptions sont techniquement proches de la vérité, mais passent complètement à côté du mécanisme. MCP est une spécification de protocole de communication : un ensemble défini de règles qui indique comment une application IA et un serveur fournissant des outils communiquent entre eux. Il fonctionne sur JSON-RPC 2.0. C'est tout. Tout le reste correspond à ce que vous construisez par-dessus.
L'affirmation vérifiable défendue par cet article est la suivante : MCP résout le problème d'intégration NxM en donnant aux LLM un moyen standardisé et indépendant du transport d'accéder à des outils et données externes via un protocole de base défini sur JSON-RPC 2.0 — et il fonctionne précisément parce qu'il n'a pas réinventé la couche de messagerie depuis zéro.
Ce que la plupart des présentations omettent totalement
- MCP est une spécification de protocole fondée sur JSON-RPC 2.0, pas une plateforme ; comprendre cette différence transforme votre manière de l'implémenter.
- JSON Schema permet aux LLM de savoir quels arguments un outil accepte avant de l'appeler ; ignorez le schéma et vous obtiendrez de la confusion à l'exécution, pas une erreur de compilation.
- La séparation client/serveur dans MCP n'est pas la même que dans REST : les deux côtés peuvent initier des requêtes, ce qui surprend la plupart des développeurs la première fois.
Le problème que MCP résout : l'isolement des LLM et l'enfer des intégrations NxM
Avant MCP, connecter un modèle IA à un outil externe impliquait d'écrire une intégration sur mesure. À chaque fois. Avec trois modèles IA et cinq outils, vous pouviez potentiellement avoir 15 connecteurs différents à créer, maintenir et mettre à jour dès que quelque chose changeait de l'un ou l'autre côté. C'est le problème NxM : N modèles multipliés par M outils, avec une matrice qui grandit rapidement.
Je retrouve constamment ce schéma dans le support : des équipes avaient déjà intégré la même logique de lecture de fichiers ou d'interrogation de bases de données dans trois agents IA différents, faute de moyen standard pour la partager. Une équipe avait un connecteur Python, une autre un wrapper TypeScript, une troisième utilisait un contournement fondé sur curl. Des bases de code différentes, pour le même résultat. Personne ne réutilisait quoi que ce soit, car rien n'avait été conçu pour être réutilisé. Le développement et le débogage se faisaient de façon isolée pour chaque implémentation.
L'API d'appel de fonctions d'OpenAI a permis de réduire ce problème spécifiquement pour ChatGPT. Mais elle était propriétaire : une solution pour un seul hôte, et non une spécification que d'autres modèles IA pouvaient adopter. L'écosystème au sens large avait besoin d'autre chose : une norme que n'importe quel hôte pouvait implémenter, que n'importe quel serveur d'outils pouvait utiliser, et qui n'exigeait pas de code sur mesure pour chaque association.
MCP est la réponse d'Anthropic à ce besoin. Publié sous la forme d'une spécification ouverte avec des SDK publics, il définit une interface commune : une interface de chat peut se connecter à un serveur MCP de la même manière que n'importe quel autre hôte, en suivant le même protocole. Les modèles IA d'un côté et les outils de l'autre utilisent un langage commun plutôt qu'un langage sur mesure. La matrice NxM se réduit à N+M.
Quel est le protocole de base de MCP et pourquoi JSON-RPC l'alimente
C'est là que la plupart des présentations de MCP perdent leur audience. Elles décrivent ce que MCP permet de faire — fournir des outils aux LLM, lire des ressources, utiliser des modèles de prompts — mais omettent ce qu'il est réellement sur le plan mécanique. La spécification MCP est explicite : tous les messages entre les clients et serveurs MCP doivent suivre la spécification JSON-RPC 2.0, en utilisant les types de messages de requête, de réponse et de notification JSON-RPC 2.0 comme protocole de base.
Ce n'est pas un détail. C'est l'architecture. MCP n'est pas un nouveau format de messagerie. C'est un ensemble de règles construit sur un protocole existant et bien compris. La spécification JSON-RPC 2.0 définit un protocole RPC sans état, léger et indépendant du transport qui utilise JSON comme format de données. « Indépendant du transport » est ici le point important : JSON-RPC ne se préoccupe pas de savoir si les messages transitent via stdio, HTTP, WebSockets ou autre chose. MCP hérite directement de cette flexibilité, ce qui explique pourquoi le même serveur MCP peut communiquer avec un IDE local via stdin/stdout et avec un service cloud distant via HTTP sans changer le format des messages.
MCP n'est pas non plus un format d'outil propriétaire d'Anthropic. L'analyse des déploiements en entreprise de Synvestable pour 2026 estimait l'adoption de MCP parmi les entreprises du Fortune 500 à environ 28 % dans les 18 mois suivant sa disponibilité — un chiffre indicatif plutôt qu'exact compte tenu de la divulgation partielle des données, mais la tendance est claire : cette spécification entre en production dans des organisations qui ne standardisent pas sur des solutions propres à Anthropic. La raison est simple : l'interopérabilité fondée sur JSON-RPC est réelle, et ne relève pas d'un discours marketing.
Voyez les choses ainsi : MCP fournit la spécification à l'écosystème. JSON-RPC fournit à MCP sa grammaire de messagerie. JSON Schema fournit à chaque appel d'outil son vocabulaire. Ces trois couches sont distinctes, et les confondre est à l'origine de la plupart des confusions d'implémentation.
Pourquoi JSON-RPC 2.0 plutôt que REST ou GraphQL
La réponse honnête à cette question est généralement « parce que cela convient mieux », ce qui reste peu satisfaisant tant que vous ne comprenez pas ce que signifie « convient » dans ce contexte.
REST est orienté ressources. Vous modélisez le monde sous forme de noms (endpoints) et de verbes (méthodes HTTP). Cela fonctionne bien pour les opérations CRUD, mais devient maladroit pour des besoins comme « invoquez cette fonction avec ces paramètres et donnez-moi un résultat ». JSON-RPC est orienté actions. Toute l'API se trouve derrière un seul endpoint, et ce que vous appelez est une méthode nommée. Cela correspond naturellement à « appelez cet outil avec cette charge utile ».
GraphQL résout un problème différent : récupérer des données structurées depuis un graphe. C'est puissant pour ce cas d'usage, mais excessif ici.
Ce qui rend JSON-RPC 2.0 particulièrement utile pour MCP est le type de notification. Une notification est un message JSON-RPC à sens unique : elle ne nécessite pas de réponse. MCP utilise les notifications pour des éléments comme les mises à jour de progression et les signaux de capacité, lorsque l'expéditeur n'a pas besoin d'attendre. JSON-RPC permet également d'envoyer plusieurs requêtes dans un lot, ce qui importe lorsqu'un agent IA doit distribuer efficacement plusieurs appels d'outils. REST ne dispose d'aucun équivalent natif pour ces deux modèles. JSON gère les charges utiles de bout en bout, ce qui maintient un format cohérent et analysable dans tout langage disposant d'une bibliothèque JSON.
Comment JSON Schema se rattache au protocole
C'est le détail que la plupart des présentations ignorent, alors qu'il s'agit précisément de ce qui rend les outils MCP lisibles par machine plutôt que simplement accessibles par machine.
Lorsqu'un serveur MCP expose un outil, il n'enregistre pas seulement un nom. Il fournit un schéma — plus précisément une définition JSON Schema — qui décrit les entrées acceptées par l'outil et la forme que doivent prendre ces entrées. La spécification MCP impose JSON Schema 2020-12 comme dialecte par défaut.
Pourquoi est-ce important ? Parce qu'un LLM qui appelle un outil ne devine pas les arguments. Il lit le schéma. Le schéma est le contrat entre le serveur d'outils et le LLM : « cet outil accepte un objet avec un champ obligatoire nommé query de type chaîne, ainsi qu'un champ facultatif nommé limit de type entier ». Le LLM peut construire automatiquement un appel valide à partir de cette description. Sans schéma, les outils disponibles sont opaques : il faut expliquer à l'IA comment les appeler à l'aide de prompts, au lieu de lui permettre de le découvrir via le protocole.
Du point de vue du support : les échecs d'invocation d'outils les plus fréquents que je constate sont des incompatibilités de schéma, où le LLM envoie un objet params qui ne correspond pas à ce que le serveur a déclaré. L'erreur est généralement opaque, car la validation se produit côté serveur et la réponse indique simplement « paramètres non valides ». Vérifiez d'abord le schéma. Cela lève l'ambiguïté avant que le débogage ne s'enlise.
Composants essentiels de MCP : hôtes, clients et serveurs
La terminologie employée ici déroute beaucoup de monde, y compris des personnes qui comprennent parfaitement REST et RPC. MCP utilise les termes « client » et « serveur » d'une façon liée à leur sens habituel, mais pas identique. Se tromper sur ce point conduit à un modèle mental où le LLM serait le client, ce qui amène à faire de mauvaises hypothèses sur l'endroit où les choses échouent lorsqu'elles échouent.
MCP comporte trois rôles structurels :
L'hôte est l'application que l'utilisateur utilise réellement. Claude Desktop est un hôte. Cursor est un hôte. Une application IA personnalisée créée par votre équipe et qui fait appel à un LLM est un hôte. L'hôte est responsable de l'expérience utilisateur et de la gestion du LLM. Il contient un client MCP.
Le client MCP réside dans l'hôte. C'est le gestionnaire de protocole : l'élément qui sait parler MCP et JSON-RPC, gère les connexions à un ou plusieurs serveurs MCP, achemine les requêtes et transmet les réponses au LLM. L'erreur courante consiste à considérer le client MCP comme passif, à l'image d'un simple client HTTP qui envoie des requêtes. Ce n'est pas le cas. Le client MCP gère la découverte des capacités et maintient l'état de la session. Le LLM lui-même ne connaît pas les détails du protocole ; c'est le rôle du client.
Le serveur MCP expose des outils, des ressources et des prompts. Il ne doit pas nécessairement s'agir d'un serveur web au sens traditionnel. C'est un processus capable de recevoir des messages MCP JSON-RPC et d'y répondre. Le serveur peut être un sous-processus local communiquant via stdio, ou un service distant derrière un endpoint HTTP. Le protocole reste identique du point de vue du client dans les deux cas.
La confusion que je rencontre le plus souvent dans le support ressemble à ceci : un développeur crée un serveur MCP, le connecte à une application IA, puis se demande pourquoi le « client » — qu'il a identifié comme l'application visible par l'utilisateur — envoie des requêtes auxquelles le serveur ne s'attend pas. La réponse est généralement que le client MCP intégré dans l'hôte est le véritable interlocuteur, et qu'il possède sa propre séquence d'initialisation et de négociation des capacités, laquelle doit s'exécuter avant de pouvoir appeler un outil.
C'est généralement là que le ticket commence.
Ce qu'un serveur MCP expose réellement
Un serveur MCP s'exprime à travers trois primitives. Trois seulement. C'est tout son vocabulaire.
Les outils sont des fonctions exécutables. Ils prennent des entrées, effectuent une action et renvoient des résultats. « Recherchez dans cette base de données », « envoyez cet e-mail », « exécutez cette requête » : ce sont tous des outils. Le LLM les appelle lorsqu'il doit effectuer une action ou récupérer des résultats calculés. Les outils définis avec JSON Schema sont découvrables automatiquement.
Les ressources sont des données lisibles. Fichiers, enregistrements de base de données, réponses d'API, valeurs de configuration : tout ce que le LLM doit lire sans avoir besoin de l'invoquer comme une fonction. Les ressources sont les sources de données et outils externes qui fournissent du contexte sans exiger l'exécution d'une fonction.
Les prompts sont des modèles d'interaction. Dans MCP, un prompt est une manière prédéfinie de structurer une interaction : des modèles de prompts réutilisables que l'hôte peut sélectionner et que le LLM peut utiliser avec des paramètres spécifiques. Voyez-les comme des amorces de conversation nommées avec des emplacements à renseigner. Un prompt pourrait être « résumer ce document » avec un paramètre de document, exposé par le serveur afin que l'hôte puisse le proposer comme option sélectionnable par l'utilisateur.
C'est l'ensemble complet. Tout serveur MCP que vous rencontrerez expose une combinaison de ces trois éléments. Avant de créer ou de déboguer un serveur MCP, la première question est toujours la suivante : quelles primitives fournit-il réellement et sont-elles correctement déclarées ?
De quoi les clients MCP sont responsables
Les clients MCP ne sont pas passifs. C'est le détail d'implémentation qui piège la plupart des développeurs lors de leur première application connectée à MCP.
Le client se trouve dans l'hôte et gère la connexion à un ou plusieurs serveurs MCP. Il prend en charge le processus de découverte des capacités : lors de l'initialisation, le client demande au serveur ce qu'il prend en charge, et le serveur répond avec la liste de ses outils, ressources et prompts disponibles. À partir de ce moment, le client sait ce que le LLM peut appeler. Le LLM lui-même n'interroge pas directement le serveur ; le client maintient cet état pour son compte.
Les clients sont également responsables de la gestion du cycle de vie : établir la connexion, maintenir la session et gérer les déconnexions. Si le serveur s'arrête au milieu d'une session, le client doit décider quoi faire : afficher une erreur, tenter une reconnexion ou échouer proprement dans le mécanisme de gestion des erreurs de l'hôte. La plupart des implémentations MCP débutantes ignorent la logique de cycle de vie et découvrent cette lacune la première fois qu'un processus serveur s'arrête de manière inattendue.
Une autre responsabilité du client souvent passée sous silence : dans MCP, le serveur peut également envoyer des requêtes au client. C'est l'un des points où MCP diffère d'un modèle mental REST simpliste. La négociation des capacités est bidirectionnelle. Le client doit être implémenté pour recevoir, et pas seulement pour envoyer. Sur le plan architectural, cela ajoute une complexité que les développeurs REST n'anticipent pas lors de leur première lecture de la spécification.
Comment l'authentification s'intègre à la connexion MCP
Réponse courte : MCP ne gère pas l'authentification à votre place. Le protocole de base la délègue entièrement à la couche de transport ou à la couche applicative.
C'est l'hypothèse qui provoque le plus de failles de sécurité dans les déploiements MCP. Des équipes lisent la spécification MCP, implémentent un serveur, connectent un client, puis passent à autre chose — sans ajouter réellement d'authentification. Le protocole fonctionne parfaitement. Le serveur est discrètement ouvert à tout processus pouvant l'atteindre.
Ce que MCP indique, c'est que les serveurs sont open source et que l'authentification doit être gérée par l'implémentation, et non par le protocole lui-même. Pour les connexions stdio locales, l'authentification n'est souvent pas nécessaire parce que seuls des processus locaux peuvent de toute façon atteindre le serveur. Pour des serveurs MCP distants via HTTP, l'authentification implique généralement OAuth à la couche de transport ou la validation de clés API dans la gestion HTTP du serveur. Rien de cela n'est automatique. Les deux nécessitent une implémentation explicite.
Si vous exposez un serveur MCP via HTTP et que vous n'avez pas explicitement configuré l'authentification, considérez ce serveur comme public jusqu'à ce que vous le fassiez.
Mécanismes de transport : comment les messages MCP circulent réellement
MCP spécifie le format des messages — JSON-RPC sur JSON — mais n'impose pas la manière dont ces messages circulent entre le client et le serveur. C'est le rôle de la couche de transport. Deux options principales existent, et choisir la mauvaise pour votre configuration constitue l'une des erreurs les plus fréquentes lors d'une première implémentation.
Le choix n'est pas arbitraire. Il dépend du fait que votre client et votre serveur s'exécutent sur la même machine, sur le même réseau ou quelque part sur Internet. Il dépend de votre configuration de proxy et d'équilibreur de charge. Il dépend également de la latence que vous pouvez tolérer. La plupart des guides ne mentionnent pas ce dernier point, ce qui explique pourquoi les équipes choisissent HTTP pour tout, puis se demandent pourquoi les appels d'outils locaux semblent lents.
MCP et sa couche de messagerie JSON-RPC fonctionnent de la même façon, quel que soit le transport. Un appel d'outil a un format de message identique, qu'il transite via stdin ou HTTP. Le transport n'est que le canal. Ce qui change, ce sont les canaux disponibles et les éléments qui échouent lorsqu'ils sont mal configurés.
🤔 Attendez.
Que se passe-t-il pour les requêtes MCP en cours lorsque la connexion de transport est interrompue au milieu d'une session ? La plupart des présentations de MCP décrivent l'initialisation et les appels d'outils dans le cas nominal, mais une interruption de connexion pendant l'exécution d'un agent en plusieurs étapes est un véritable cas opérationnel. MCP lui-même ne définit pas la sémantique de reconnexion : cela relève de l'implémentation. Si votre client MCP ne gère pas explicitement la reconnexion, les connexions perdues produisent des échecs silencieux : le LLM cesse de recevoir les résultats d'outils, l'hôte peut ne pas afficher d'erreur, et l'utilisateur obtient une réponse bloquée ou incomplète sans indication claire de la cause.
Transport stdio : quand la communication entre processus locaux est pertinente
Stdio est la voie la plus simple. Le client MCP lance le serveur comme sous-processus et communique via stdin et stdout à l'aide de messages JSON-RPC. Le client écrit dans stdin du serveur. Le serveur écrit ses réponses dans stdout. C'est toute la couche de transport.
Cette configuration offre une latence plus faible que HTTP pour les appels d'outils locaux, car aucune pile réseau n'est impliquée et aucun surcoût de connexion n'existe au-delà de l'initialisation MCP. C'est le choix par défaut pour des outils comme Claude Desktop et Cursor, où le serveur MCP réside sur la même machine que l'application hôte.
La contrainte pratique est évidente : stdio ne fonctionne que lorsque le client et le serveur s'exécutent sur la même machine. Sans exception. Si votre serveur MCP doit être partagé entre plusieurs hôtes ou s'il se trouve sur une machine distante, stdio n'est pas une option. Cela couvre proprement la plupart des cas d'usage d'IDE locaux et d'assistants de bureau, ce pour quoi il a précisément été conçu.
Transport HTTP plus SSE : ce qu'il apporte et où il échoue
HTTP avec SSE (Server-Sent Events) est le transport adapté aux environnements distants. Le serveur expose un endpoint HTTP. Le client ouvre un flux SSE pour les messages serveur-vers-client. Les requêtes HTTP POST gèrent les appels client-vers-serveur. Cette combinaison offre une communication bidirectionnelle sur une infrastructure HTTP standard, ce dont vous avez besoin pour tout serveur MCP qui ne s'exécute pas localement.
La variante plus récente « HTTP streamable » consolide une partie de ce mécanisme, mais le modèle central reste le même : une direction via SSE, l'autre via POST.
Le véritable point de friction est la prise en charge de SSE. SSE n'est pas toujours géré correctement par tous les proxys, équilibreurs de charge et passerelles API. Certains interrompent les connexions longues. D'autres mettent les réponses en mémoire tampon et cassent la sémantique de streaming requise par SSE. Dans les environnements de production avec Nginx, AWS API Gateway ou des proxys d'entreprise dans la chaîne, cela provoque des échecs silencieux : la connexion SSE du client est interrompue, la file de messages serveur-vers-client s'accumule, et rien dans les journaux applicatifs n'indique pourquoi. Vous observez un appel d'outil bloqué côté LLM et rien d'évident côté infrastructure.
Si votre serveur MCP HTTP+SSE fonctionne en local mais échoue en préproduction, vérifiez la configuration du proxy et de l'équilibreur de charge avant de déboguer l'implémentation MCP elle-même. Cela résout la plupart de ces cas plus rapidement que toute autre approche.
À quoi ressemble le cycle de vie MCP en pratique
Lire la spécification MCP comme un document statique fait manquer un élément important : MCP décrit une session active avec une séquence d'étapes définie. Deux systèmes doivent établir une connexion, négocier et parvenir à une compréhension mutuelle avant qu'un outil puisse être appelé. Comprendre cette séquence distingue « j'ai lu des informations sur MCP » de « je sais construire avec MCP ».
Le workflow de la première connexion au premier résultat d'outil comporte trois phases réelles : l'initialisation et la négociation des capacités, puis l'appel d'outil proprement dit — ou la lecture d'une ressource, ou la récupération d'un prompt — puis le traitement de la réponse. Les systèmes IA construits sur MCP dépendent du bon déroulement de cette séquence. Si la négociation des capacités produit une incompatibilité, l'appel d'outil n'est jamais tenté. Si l'appel d'outil produit un objet params mal formé, le serveur le rejette avant l'exécution de la moindre logique métier. Les applications IA contextuelles ont besoin que ces trois phases fonctionnent correctement.
Négociation des capacités lors de l'initialisation
Lorsqu'un client MCP se connecte à un serveur pour la première fois, après l'établissement de la connexion de transport, les deux parties échangent une poignée de main. Le client envoie une requête initialize qui inclut la version du protocole qu'il prend en charge ainsi que ses propres capacités. Le serveur répond avec la version du protocole qu'il prend en charge et ses capacités. Si les versions correspondent — ou si une version négociée acceptable est convenue — la session se poursuit. Dans le cas contraire, c'est à ce moment que l'incompatibilité apparaît : ni au milieu d'un workflow, ni dans un appel d'outil, mais bien pendant l'initialisation.
C'est en réalité utile. Le fait que les incompatibilités de version apparaissent au moment de la poignée de main plutôt que pendant l'exécution permet de savoir immédiatement qu'un serveur utilise une version obsolète du protocole que votre client ne prend pas en charge. La réponse initialize comprend également l'identifiant des outils, ressources et prompts disponibles sur le serveur. Le client construit sa connaissance des capacités du serveur à partir de cette réponse avant même d'émettre un appel d'outil.
Si vous vous trompez dans la séquence d'initialisation, tout ce qui suit échoue silencieusement ou produit des erreurs déroutantes. C'est la première chose que je vérifie lorsqu'une personne me dit que son intégration MCP « ne fonctionne pas ».
Comment un appel d'outil circule dans le protocole
Après une initialisation réussie, l'invocation d'un outil correspond à un seul cycle requête/réponse JSON-RPC. Le client envoie une requête avec un nom de méthode correspondant à l'outil, un identifiant de requête unique et un objet params structuré conformément à la déclaration JSON Schema de l'outil. Le serveur valide les params selon le schéma, exécute l'outil et renvoie un résultat JSON structuré portant le même identifiant de requête.
L'étape de validation des params est essentielle. Un objet params mal formé — un champ obligatoire manquant, un type erroné, une clé inattendue que le schéma ne définit pas — renvoie une erreur JSON-RPC avant l'exécution de toute logique métier. Du point de vue du serveur, ce comportement est correct. Du point de vue du LLM, recevoir un code d'erreur alors qu'il attendait du contexte supplémentaire produit une confusion qui se manifeste ensuite sous la forme de réponses hallucinées ou incomplètes.
C'est exactement le scénario rencontré dans le travail d'ingénierie de Latenode : lorsque des ingénieurs connectent des serveurs MCP à des systèmes internes et se heurtent à des erreurs opaques de validation JSON-RPC, le problème est généralement une incompatibilité de schéma : l'agent IA construit un objet params qui ne correspond pas à la déclaration du serveur. Dans un workflow Latenode, un nœud JavaScript peut gérer directement la mise en forme des paramètres avant que la requête n'atteigne le serveur, tandis que le RAG intégré permet à un nœud IA de lire la spécification MCP officielle afin de valider la structure de la charge utile. La correction s'effectue au niveau du canevas, et non dans une trace de pile à 23 h. Les codes d'erreur standards s'appliquent : -32600 correspond à une requête non valide, -32601 à une méthode introuvable et -32602 à des paramètres non valides. Ces trois codes couvrent la majorité des échecs d'appels d'outils.
Considérations de sécurité que la plupart des configurations MCP gèrent mal
La sécurité dans MCP ne dépend pas du caractère sécurisé ou non du protocole lui-même. Le protocole est bien spécifié et la couche JSON-RPC est bien comprise. Les risques proviennent de la manière dont l'exposition des outils est configurée, de ce que ces outils peuvent atteindre et de ce qui se produit lorsqu'un composant compromis ou malveillant entre dans la session.
Injection de prompt via les réponses d'outils
Un LLM qui appelle un outil MCP considère la réponse de l'outil comme du contexte supplémentaire fiable. Si une source de données non fiable se trouve quelque part dans le pipeline — un résultat de recherche web, un fichier téléversé par un utilisateur, une API tierce — une réponse malveillante peut injecter des instructions qui redirigent le comportement du LLM. La protection repose sur la désinfection des sorties à la couche outil et une séparation nette entre les prompts système fiables et les données renvoyées par les outils. Traitez les réponses d'outils comme des entrées non fiables, et non comme du contexte privilégié.
Exposition trop permissive des outils serveur
Un serveur MCP qui expose par défaut toutes les fonctions disponibles donne à l'utilisateur final — et au LLM — accès à tout ce que le serveur peut atteindre. La plupart des équipes exposent ce qui est pratique, et non ce qui est nécessaire. Le principe d'exposition minimale des outils s'applique : chaque outil enregistré doit avoir un périmètre défini, et les outils qui accèdent à des systèmes sensibles doivent nécessiter un contexte explicite avant de pouvoir être appelés. Le sandboxing au niveau des outils — limiter ce qu'un outil donné peut lire, écrire ou exécuter — n'est pas facultatif en production.
Absence d'authentification sur les serveurs MCP distants
Comme indiqué dans la section consacrée au transport : MCP via HTTP sans couche d'authentification est un serveur ouvert. Les API accessibles via ces outils deviennent alors accessibles à toute personne pouvant atteindre l'endpoint. Exigez une authentification à la couche de transport ou applicative avant qu'un serveur MCP ne dépasse le cadre du développement local. OAuth ou la validation de clé API avec HTTP+SSE sont deux solutions raisonnables. Aucune n'est automatique.
Absence de chiffrement de la couche de transport pour HTTP+SSE
SSE sur HTTP non chiffré signifie que tous les messages MCP — y compris les appels d'outils, les données renvoyées par les ressources et les métadonnées de session — circulent en clair. Dans les environnements LAN, cela peut être acceptable. Dans tout environnement comportant du trafic externe, TLS est nécessaire. La spécification MCP ne l'impose pas. Votre infrastructure doit s'en charger.
Empoisonnement d'outils provenant d'un serveur compromis
C'est le modèle de menace auquel la plupart des équipes ne pensent pas avant un incident. Si l'un des serveurs MCP enregistrés dans une session est compromis, le LLM ne peut pas distinguer ses réponses des réponses légitimes. Un serveur empoisonné peut injecter des instructions dans les réponses d'outils et influencer le comportement du LLM durant toute la session — pas uniquement les appels adressés à ce serveur. Chaque serveur MCP enregistré fait partie de la surface de confiance du LLM. La question n'est pas « cet outil est-il sûr ? », mais « tous les serveurs enregistrés sont-ils sûrs ? »
💡 L'aspect contre-intuitif :
La surface de confiance de MCP ne se limite pas aux outils que l'utilisateur appelle intentionnellement : elle s'étend à chaque serveur enregistré dans la session. Un utilisateur qui déclenche un seul appel d'outil fait implicitement confiance aux autorisations et sorties de tous les serveurs MCP connectés, y compris de ceux avec lesquels il n'a jamais interagi directement. Cela recadre entièrement la sécurité MCP : il ne s'agit pas de demander « ce protocole est-il sûr ? », mais « ai-je audité chaque serveur que cette session peut atteindre ? ». La plupart des équipes ne l'ont pas fait.
MCP en pratique : écosystèmes réels et perspectives
La spécification prend davantage d'importance lorsque vous observez ce qui se construit au-dessus. GitHub dispose désormais de serveurs MCP pour les opérations sur les dépôts. Docker a publié des outils MCP. L'écosystème d'OpenAI commence à croiser cette norme. Des SDK TypeScript et Python existent et sont activement maintenus par le projet MCP. Les développeurs qui auraient auparavant écrit un connecteur personnalisé pour chaque modèle IA peuvent désormais écrire un seul serveur MCP et l'exposer à tout hôte compatible.
C'est le véritable test pour savoir si une spécification a réellement résolu le problème NxM : les implémentations sont-elles réutilisées entre les fournisseurs de modèles et les hôtes, ou les équipes écrivent-elles toujours du code personnalisé pour chaque association ? Les éléments issus des premiers déploiements en entreprise — aussi imprécis que puisse être le chiffre de 28 % cité dans l'analyse de Synvestable — suggèrent que la réutilisation s'opère à une échelle significative, ce qui signifie que la spécification remplit son objectif.
Pour les équipes qui s'appuient sur Latenode, MCP Server Builder permet d'exposer un workflow Latenode comme serveur MCP, appelable depuis Claude Desktop, Cursor ou tout autre hôte compatible MCP. Les workflows situés derrière ce serveur peuvent exploiter plus de 5 500 intégrations, exécuter de l'IA sur des documents téléversés grâce au RAG intégré, ou lancer une logique personnalisée dans un nœud JavaScript. Les détails du protocole restent invisibles pour la personne qui appelle l'outil. De son côté, il ne s'agit que d'un outil découvert lors de la négociation des capacités. De votre côté, c'est un workflow d'automatisation complet.
La spécification MCP définit l'interface. Ce que vous placez de l'autre côté de cette interface dépend de vous.
Si vous construisez quelque chose qui doit continuer à fonctionner lorsque les choses se passent mal : implémentez d'abord la gestion du cycle de vie, pas les outils. Ajoutez des journaux à la couche de transport. Validez vos déclarations JSON Schema avec de véritables charges utiles de test avant de connecter un LLM. Et n'oubliez pas que chaque serveur MCP que vous enregistrez fait partie de votre surface de confiance dès que la poignée de main est terminée.
Le protocole est propre. La partie difficile, comme souvent, est tout ce qui l'entoure.
