Un serveur MCP local et un serveur distant se ressemblent parfaitement une fois lancés : même liste d’outils dans le client, même conversation, même résultat. La différence tient à ce que vous avez remis pour en arriver là. Un serveur local est un programme sur votre machine que le client démarre et avec lequel il dialogue par l’entrée et la sortie standard, et ce que vous remettez est une ligne de commande. Un serveur distant est le point d’accès HTTPS de quelqu’un d’autre, et ce que vous remettez est un identifiant — avec tout ce qu’il déverrouille, aussi longtemps que vous le laissez en vie.
La question utile avant de coller une URL dans une boîte de dialogue de connecteur n’est donc pas « ce serveur est-il digne de confiance », à laquelle personne ne peut répondre depuis une page de fiche. Ce sont trois questions plus étroites qui, elles, ont des réponses consultables : à quoi le jeton est limité, où aller pour le reprendre, et ce que le catalogue dans lequel vous avez trouvé le serveur a réellement vérifié. Les réponses ci-dessous s’appuient sur la spécification MCP et la documentation des éditeurs telles qu’elles étaient le 16 août 2026.
La révision actuelle de la spécification, 2026-07-28, traite les deux transports comme des contextes de sécurité différents. L’autorisation est facultative dans MCP, et son champ d’application est explicite : les implémentations qui utilisent un transport HTTP devraient se conformer à la spécification OAuth, tandis que les implémentations stdio ne devraient pas la suivre du tout et récupérer plutôt leurs identifiants depuis l’environnement. HTTP+SSE, l’ancien transport distant, est déprécié ; Streamable HTTP est celui auquel s’attendre.
| Local (stdio) | Distant (Streamable HTTP) | |
|---|---|---|
| Ce que vous remettez | Une commande que votre client exécutera | Une URL, et le plus souvent une autorisation OAuth |
| Où le code s’exécute | Votre machine, votre compte utilisateur | Une infrastructure exploitée par quelqu’un d’autre |
| Identifiants | Pris dans l’environnement | Jeton d’accès lié à ce seul serveur |
| Ce que fait « déconnecter » | Arrête de lancer un processus | Supprime la copie du jeton côté client ; l’autorisation peut survivre |
| Pire cas si l’auteur est hostile | Code arbitraire avec vos privilèges | Tout ce qu’atteignent les scopes approuvés |
Aucune des deux colonnes n’est la colonne sûre. Un serveur local est du code arbitraire qui s’exécute sous votre identité — c’est précisément pourquoi la spécification exige qu’un client proposant une configuration locale en un clic affiche la commande exacte qu’il exécutera, sans troncature, et obtienne au préalable une approbation explicite. Un serveur distant ne pose aucun code sur votre machine, mais il déplace vos données vers un exploitant et laisse un chemin d’accès qui survit à votre attention. Les deux échouent dans des directions différentes ; notre comparaison de ce que chaque type peut voir entre dans le détail.
Le modèle d’autorisation est OAuth 2.1, et la partie qui mérite d’être comprise
côté utilisateur est la liaison d’audience. Les clients doivent implémenter
Resource Indicators for OAuth 2.0 (RFC 8707) : le paramètre resource doit être
envoyé à la fois dans la requête d’autorisation et dans la requête de jeton, en
nommant le serveur précis auquel le jeton est destiné. Les serveurs doivent
vérifier que les jetons ont été émis pour eux, n’accepter que des jetons valides
pour leurs propres ressources, et ne doivent en accepter ni en transmettre aucun
autre. Faire suivre le jeton d’un client vers une API en aval — le
« token passthrough » — est purement interdit.
Un jeton correctement implémenté est donc inutile auprès d’un autre serveur. Cela ferme le rejeu, la réutilisation d’identifiants entre services et toute une classe d’attaques confused deputy — et absolument rien concernant l’exploitant lui-même. La liaison d’audience dit où le jeton fonctionne, pas ce que l’entreprise à l’autre bout fait de ce que ses outils récupèrent pour vous. Cela, c’est leur politique de confidentialité qui y répond, pas le protocole.
Ce sont les scopes qui décident réellement de votre exposition. La spécification
pousse les serveurs vers le moindre privilège : scopes_supported est censé
être l’ensemble minimal nécessaire au fonctionnement de base, tout le reste
étant demandé de façon incrémentale lors de la première tentative d’une
opération privilégiée. Les serveurs qui suivent cette règle demandent peu
d’emblée ; ceux qui ne la suivent pas affichent un seul écran de consentement
qui liste tout. Cet écran est le dernier moment où la décision vous appartient.
Il existe deux surfaces de révocation, et la plupart des gens n’utilisent que la première.
Dans l’assistant. Dans Claude, les connecteurs personnalisés vivent sous Customize > Connectors, où vous en ajoutez un en collant l’URL du serveur ; les utilisateurs Free sont limités à un seul. C’est sur cette même page que vous le déconnectez, et que vous activez ou désactivez les outils individuels du serveur au lieu de les accepter tous. Anthropic énonce sa position de confiance sans détour dans son centre d’aide : les connecteurs personnalisés vous permettent de connecter Claude à des services arbitraires qui n’ont pas été vérifiés par Anthropic. Dans ChatGPT, les serveurs distants arrivent par le mode développeur — Settings → Security and login, sur le web, acceptant les points d’accès SSE et streaming HTTP. La documentation d’OpenAI le qualifie elle-même de puissant mais dangereux, cite l’injection de prompt et les actions d’écriture destructrices parmi les risques, et exige par défaut une confirmation pour les actions d’écriture.
Chez le service auprès duquel vous avez donné l’autorisation. C’est celle que les gens sautent. Supprimer le connecteur retire la copie du jeton détenue par votre client ; l’autorisation enregistrée dans votre compte Google, GitHub, Atlassian ou Notion est un objet distinct avec sa propre durée de vie, et un jeton de rafraîchissement qui y est attaché peut survivre au connecteur bien longtemps. La recommandation d’Anthropic le dit — révoquez en déconnectant le connecteur dans les paramètres de Claude ou dans les paramètres de sécurité du service tiers. Faites les deux, et repérez cette page des applications connectées avant de connecter.
Le registre MCP officiel, à registry.modelcontextprotocol.io, est l’endroit
naturel où chercher des serveurs, et il est facile de surinterpréter ce que
signifie une fiche. La charte de son groupe de travail est précise. Publication
et confiance couvrent les flux d’authentification — GitHub OAuth, GitHub OIDC,
vérification DNS et HTTP — plus la propriété des espaces de noms, l’outillage de
modération et le signalement communautaire. Explicitement hors périmètre :
classer les implémentations de serveurs MCP ou choisir entre elles pour le
compte des clients ou des utilisateurs finaux, et héberger, distribuer ou
exécuter du code de serveur, parce que le registre est un catalogue de
métadonnées, pas un registre de paquets.
Un espace de noms vérifié prouve donc que celui qui a publié l’entrée contrôle l’organisation GitHub ou le domaine qui figure dans son nom. C’est un signal réel : il rend le typosquatting plus difficile et vous donne quelqu’un à tenir pour responsable. Ce n’est ni une revue de code, ni un audit de sécurité, ni une recommandation — identité établie, comportement toujours inconnu.
Un principe de la spécification mérite d’être emporté dans chaque connexion : les descriptions du comportement des outils, annotations comprises, doivent être considérées comme non fiables sauf si elles proviennent d’un serveur de confiance, et les hôtes doivent obtenir le consentement explicite de l’utilisateur avant d’invoquer un outil. Une description d’outil est un texte écrit par une partie distante et lu par votre modèle — la définition même d’une entrée non fiable, et la raison pour laquelle « le serveur a dit qu’il était en lecture seule » n’est pas un contrôle de sécurité.
Le précédent concret est CVE-2025-6514, publié le 9 juillet 2025 contre
mcp-remote, le proxy que beaucoup de clients utilisaient pour atteindre des
serveurs distants. Noté 9,6, il permettait à un serveur malveillant d’obtenir
une injection de commande système sur la machine qui se connectait, via une
valeur authorization_endpoint forgée dans le flux OAuth — affectant les
versions 0.0.5 à 0.1.16 et corrigé en 0.1.16. Rien n’avait à être approuvé dans
une conversation : se connecter constituait toute l’attaque. Tout ce qu’un
serveur distant envoie est une donnée que votre logiciel analyse, et la
connexion elle-même fait partie de votre surface d’attaque.
Tout ce qui précède est le prix à payer pour atteindre quelque chose qui vit réellement dans le cloud de quelqu’un d’autre — votre suivi de tickets, votre CRM, votre agenda. C’est un prix raisonnable pour ceux-là et un prix étrange pour des fichiers déjà posés sur votre disque, et c’est pourquoi Speak-Y livre un serveur local plutôt qu’un point d’accès hébergé.
Son serveur MCP est un processus que votre client démarre sur votre machine. La
lecture n’a besoin de rien d’autre en fonctionnement : résultats de recherche,
transcriptions, comptes rendus de réunion et actions à mener sortent directement
de la bibliothèque présente sur le même ordinateur, sans jeton émis ni relais
intermédiaire. Les commandes qui modifient quelque chose — étiqueter un
enregistrement, nommer les intervenants, partager dans un canal d’équipe —
passent par l’application en fonctionnement, sont déclarées à votre client comme
modifiant des données pour qu’il demande d’abord, et sont journalisées là où
vous pouvez les désactiver. Ajouter --read-only aux arguments du serveur
signifie que les commandes modifiantes ne sont jamais publiées à ce client — une
garantie plus forte qu’une description qui promet de bien se tenir.
L’installation se fait en un clic depuis Paramètres → Intégrations,
gratuitement sur toutes les formules, y compris Free.
Le compromis joue dans les deux sens : un serveur local ne peut pas servir ChatGPT dans un onglet de navigateur, et il ne tourne que là où l’application tourne. Si cette contrainte compte, quels clients savent démarrer un serveur local est le comparatif à lire ensuite — et si la question est ce qu’un assistant devrait avoir le droit de modifier une fois connecté, où se situe la limite sur l’accès en écriture traite ce point. L’aperçu de MCP liste ce que le serveur de Speak-Y expose.
Un serveur local est un programme sur votre propre machine que le client démarre et avec lequel il dialogue par l’entrée et la sortie standard : ce que vous remettez est une ligne de commande, et aucun jeton n’est émis. Un serveur distant est un point d’accès HTTPS exploité par quelqu’un d’autre : ce que vous remettez est un identifiant, en général un jeton d’accès OAuth 2.1, et les données que ses outils touchent voyagent vers l’infrastructure de cet exploitant.
Selon la spécification d’autorisation de MCP, le jeton est lié à un serveur et à un ensemble de scopes. Les clients doivent envoyer un indicateur de ressource RFC 8707 nommant le serveur dans la requête d’autorisation comme dans la requête de jeton, et le serveur doit vérifier que les jetons ont été émis pour lui — il ne doit accepter ni faire suivre aucun autre jeton. Cela empêche le rejeu du jeton auprès d’un autre service. Cela ne dit rien de ce que l’exploitant fait des données que ses propres outils récupèrent pour vous.
À deux endroits, et la plupart des gens ne font que le premier. Supprimer le connecteur dans votre assistant efface la copie du jeton détenue par le client ; l’autorisation OAuth enregistrée chez le service auprès duquel vous l’avez accordée est un objet distinct et survit généralement. Anthropic recommande de révoquer les permissions en déconnectant le connecteur dans les paramètres de Claude ou dans les paramètres de sécurité du service tiers. Repérez la page des applications connectées du fournisseur avant de connecter, pas après.
Non. Le registre vérifie la propriété de l’espace de noms — un nom en io.github.* via l’authentification GitHub, un nom fondé sur un domaine via une vérification DNS ou HTTP — ce qui prouve que l’éditeur contrôle ce nom. Sa charte place explicitement hors périmètre le classement des implémentations de serveurs et le choix entre elles, et précise que le registre est un catalogue de métadonnées, pas un registre de paquets : il n’héberge, ne distribue ni n’exécute de code de serveur.
Seulement ce qu’atteignent les scopes que vous avez approuvés. Le risque est que les scopes soient plus larges que la tâche : un jeton accordé pour une boîte mail ou un disque entier est disponible pour chaque outil exposé par ce serveur, aussi longtemps que vit l’autorisation. Lisez l’écran de consentement plutôt que la page marketing, et utilisez les contrôles par outil là où le client en propose — les paramètres de connecteur de Claude permettent d’activer et de désactiver les outils un par un, et le mode développeur de ChatGPT exige par défaut une confirmation pour les actions d’écriture.