Les mots local et cloud sont employés à propos des serveurs MCP comme s’ils tranchaient la question de la confidentialité. Ils ne la tranchent pas. Ils répondent précisément à une seule question — où tourne le processus serveur — et laissent intacte celle qui intéresse réellement la plupart des gens : qui finit par pouvoir lire vos données.
En résumé : un serveur MCP local garde vos données hors de l’infrastructure de l’éditeur ; il ne les garde pas hors de la conversation. Tout ce que votre assistant lit à travers un serveur MCP, local ou cloud, part vers le modèle avec lequel vous discutez. Local change qui stocke vos données et qui peut les atteindre. Cela ne change pas ce que voit le modèle.
Cet article sépare ces deux choses. Si le protocole lui-même vous est inconnu, ce qu’est un serveur MCP en couvre d’abord les bases.
La spécification MCP, révision 2026-07-28, définit exactement deux transports standard, et ils correspondent proprement aux deux mots.
stdio — le local. Le client lance le serveur MCP comme sous-processus, et les deux communiquent par l’entrée et la sortie standard de ce processus, un message JSON-RPC par ligne. Il n’y a ni connexion réseau ni port. Quand le client se ferme, il ferme le flux d’entrée du serveur et le processus s’arrête. Voilà ce que « tourne sur votre machine » signifie concrètement.
Streamable HTTP — le cloud. Le serveur est un processus indépendant qui
expose un unique point d’accès HTTP, et chaque message est un POST HTTP vers
celui-ci. Le client le joint par le réseau à une URL du type
https://mcp.example.com/mcp. C’est le transport derrière chaque bouton
« connecter votre compte ».
La distinction relève du déploiement, pas des capacités. La spécification est explicite : la sémantique du protocole est identique sur tous les transports — un transport définit comment les messages sont encadrés et acheminés, pas ce qu’ils veulent dire. Un outil qui lit vos transcriptions de réunion fait le même travail dans les deux cas.
C’est la question que ces deux mots remplacent d’ordinaire, et elle a plus de deux réponses. Quatre parties peuvent potentiellement lire ce qui transite par une connexion MCP.
| Qui | Serveur local (stdio) | Serveur cloud (HTTPS) |
|---|---|---|
| L’éditeur du serveur MCP | Ne reçoit pas les données | Les stocke et répond à chaque requête |
| Le fournisseur de votre modèle | Voit tout ce que l’assistant lit | Voit tout ce que l’assistant lit |
| Votre application d’IA | Les lit en local pour composer le prompt | Idem |
| Quiconque détient le jeton | Aucun jeton à voler | Atteint les mêmes données jusqu’à révocation |
La ligne du milieu est celle qui surprend, et elle est identique dans les deux colonnes. Un serveur MCP n’ouvre pas au modèle un canal privé. Il récupère du texte et le remet au client, qui le place dans le prompt. À partir de là, les données ont quitté votre machine, où que le serveur ait tourné.
La première et la dernière ligne sont les endroits où le local l’emporte réellement. Avec stdio, il n’y a pas de compte, pas de copie stockée sur le disque de quelqu’un d’autre, et aucun identifiant susceptible d’être volé ou divulgué lors d’une fuite — parce qu’il n’y a rien à autoriser.
Il y a ici trois configurations, pas deux, et les éditeurs isolent rarement celle du milieu.
Serveur cloud, données cloud. L’éditeur héberge le serveur, vous l’autorisez en OAuth dans un navigateur, et votre client fait un appel HTTPS dès qu’il a besoin de quelque chose. La forme naturelle quand vos données vivent déjà dans le cloud de cet éditeur.
Processus local, données cloud. L’éditeur livre un serveur que vous exécutez
vous-même — une commande npx, uvx ou docker lancée par votre client IA,
porteuse d’une clé API. Rien là-dedans ne rend les données locales. Le processus
tourne sur votre portable, puis appelle l’API de l’éditeur par le réseau à
chaque requête. C’est le cas qu’il vaut la peine d’écarter quand on vous dit
qu’un serveur MCP est local.
Processus local, données locales. Les données sont déjà sur la machine, le serveur les lit donc sans le moindre appel réseau. C’est la seule configuration où « local » décrit les données et pas seulement le processus.
Ce qui trahit, c’est l’identifiant, pas la commande. Une connexion par navigateur signifie que les données appartiennent à l’éditeur et que vous en autorisez l’accès. Une clé API collée dans un fichier de configuration signifie qu’un processus local appelle leur API en votre nom. Ni l’un ni l’autre n’est une donnée locale.
Quand vous validez un écran OAuth pour un serveur MCP cloud, vous émettez un identifiant sur votre compte, et il vaut la peine de savoir ce que cet identifiant permet.
La spécification MCP s’appuie ici sur OAuth 2.1. Les clients doivent envoyer le
paramètre resource défini par la
RFC 8707 afin que le jeton soit
lié à un serveur précis, et les serveurs doivent vérifier qu’un jeton a bien été
émis pour eux et ne rien accepter ni transmettre d’autre. Cette mécanique existe
pour empêcher qu’un jeton émis pour un service soit rejoué contre un autre.
Trois conséquences pratiques :
Rien de tout cela ne s’applique à stdio. La spécification d’autorisation précise qu’elle couvre les transports HTTP, et que les implémentations en stdio ne doivent pas la suivre : elles récupèrent les identifiants dans l’environnement.
Local n’est pas synonyme de sûr, et la version honnête de cet argument doit dire ce que l’on cède en échange.
Il n’y a généralement aucune couche de permissions. Comme la spécification d’autorisation ne s’applique pas, un serveur stdio n’a le plus souvent aucune notion d’utilisateurs ni de scopes. Tout ce qui tourne sous votre compte utilisateur peut en général le démarrer et appeler ses outils. Sur une machine partagée ou administrée, cela compte.
Un serveur local à l’écoute sur un port est une autre bête. Certains
serveurs présentés comme locaux écoutent en réalité en HTTP. La spécification
traite le cas directement : les serveurs doivent valider l’en-tête Origin pour
prévenir les attaques par DNS rebinding, et, en usage local, ne se lier qu’à
127.0.0.1 plutôt qu’à 0.0.0.0. Sans ces protections, avertit-elle, des
attaquants pourraient se servir du DNS rebinding pour dialoguer avec des
serveurs MCP locaux depuis des sites web distants.
Vous héritez de la chaîne d’approvisionnement. Un serveur lancé avec npx
télécharge et exécute du code sur votre machine avec vos droits.
L’OWASP MCP Top 10, en bêta en
2026, range les attaques sur la chaîne d’approvisionnement et l’altération de
dépendances (MCP04:2025) ainsi que l’empoisonnement d’outils (MCP03:2025) parmi
ses dix catégories — des risques qu’une installation locale porte et qu’un point
d’accès hébergé n’a pas. La spécification est nette sur le cas général : les outils
représentent l’exécution de code arbitraire, et les descriptions du comportement
d’un outil doivent être tenues pour non fiables tant qu’elles ne proviennent pas
d’un serveur de confiance.
MCP n’ajoute pas de modèle de permissions à vos données. Il normalise la façon dont les outils sont décrits et appelés ; ce qu’un outil donné a le droit de toucher est une décision de l’auteur du serveur. Deux conséquences en découlent, quel que soit le transport :
Quatre questions, auxquelles la page de configuration de n’importe quel éditeur répond en une minute environ.
https:// désigne un
serveur cloud. Une commande npx, uvx ou docker désigne un processus sur
votre machine.Dit simplement, car le choix n’est pas à sens unique :
Le cloud ne perd que sur un seul axe, mais c’est celui dont parle cet article : une copie de vos données réside sur l’infrastructure de quelqu’un d’autre, joignable avec un identifiant.
Posez deux questions au lieu d’une. Où tourne le serveur vous dit qui stocke vos données et qui peut les atteindre avec un jeton. Que lit l’assistant vous dit ce qui part vers le fournisseur de votre modèle — et cette réponse-là est la même dans les deux cas.
Si la configuration que vous voulez est un processus local sur des données
locales, c’est ce que fait le serveur MCP de Speak-Y : il fait partie de
l’application de bureau, s’installe depuis Paramètres → Intégrations en un
clic, et lit les enregistrements déjà présents sur votre machine, sans compte,
sans clé API et sans copie hébergée. La lecture fonctionne même quand
l’application est fermée ; les outils qui modifient quelque chose passent par
l’application et demandent confirmation, et l’option --read-only limite un
client à la lecture. Le serveur est gratuit sur toutes les formules. La
documentation MCP couvre l’installation manuelle, la politique de
confidentialité indique ce qui est stocké et où, et si vous voulez
voir comment les autres outils de prise de notes répondent à la même question,
nous avons comparé leurs serveurs
MCP côte à côte.
Un serveur local est un programme que votre client IA lance sur votre propre ordinateur et avec lequel il dialogue par l’entrée et la sortie standard du processus — sans réseau. Un serveur cloud est un service web que le client joint en HTTPS, autorisé en OAuth. La spécification MCP appelle cela les transports stdio et Streamable HTTP.
Non. Un serveur local garde vos données hors des serveurs de l’éditeur, mais tout ce que l’assistant lit à travers lui part vers le fournisseur de votre modèle avec la conversation, exactement comme si vous l’aviez collé vous-même. Local contrôle le stockage et l’accès, pas ce que voit le modèle.
Il est plus confidentiel, mais pas automatiquement plus sûr. La spécification d’autorisation MCP ne concerne que les transports HTTP ; les serveurs stdio doivent au contraire récupérer les identifiants dans l’environnement, si bien qu’un serveur local n’a en général aucune couche de permissions. Tout ce qui tourne sous votre compte utilisateur peut le plus souvent l’atteindre.
Regardez les instructions d’installation. Une URL en https:// et une connexion par navigateur désignent le cloud de l’éditeur. Une commande comme npx, uvx ou docker désigne un processus sur votre machine. Un processus local porteur d’une clé API appelle malgré tout l’API de l’éditeur : la commande seule ne dit donc pas où vivent les données.
Claude Desktop exécute directement les serveurs locaux, installés comme extensions de bureau. ChatGPT se connecte à des points d’accès HTTPS distants en mode développeur : un serveur stdio local doit donc d’abord être exposé par un tunnel. Le même serveur peut ainsi être local sur un client et distant sur un autre.