La question semble appeler une réponse par éditeur, et ce n’est pas le cas. En 2026, la ligne de partage passe entre les surfaces, pas entre les fournisseurs : l’application de bureau ChatGPT peut lancer un serveur MCP sur votre machine, ChatGPT dans un onglet de navigateur non. Claude Code et Claude Desktop le peuvent tous les deux. Tous les éditeurs de code dotés d’un client MCP — Cursor, VS Code, Zed, Devin Desktop — le peuvent. Tout ce qui tourne dans le cloud de quelqu’un d’autre, par définition, ne le peut pas.
Cette distinction compte plus qu’il n’y paraît. Un serveur local est un programme que votre client lance et avec lequel il dialogue par l’entrée et la sortie standard ; aucun port n’est ouvert, aucun identifiant n’est émis, et vos données ne quittent jamais la machine pour rejoindre les outils de l’assistant. Un serveur distant est une URL, c’est-à-dire un exploitant, un jeton et un trajet réseau. Choisir un client, c’est donc en partie choisir où vos données doivent se trouver avant qu’un assistant puisse s’en servir.
Ce tour d’horizon indique qui prend en charge quoi, vérifié dans la documentation de chaque éditeur le 15 août 2026. Si le protocole lui-même vous est inconnu, ce qu’est un serveur MCP en donne le vocabulaire ; si vous avez déjà choisi un client et cherchez seulement le chemin du fichier de configuration, la configuration MCP dans VS Code, Zed et Devin Desktop en donne la version fichier par fichier.
| Client | stdio local | Distant | Comment il demande |
|---|---|---|---|
| Claude Code | Oui | HTTP, SSE, WebSocket | Demande ; les serveurs de projet doivent d’abord être approuvés |
| Claude Desktop | Oui | Oui | Approbation explicite avant chaque action |
| Application de bureau ChatGPT | Oui | Oui | Quatre modes d’approbation, partagés avec Codex |
| Codex CLI / extension IDE | Oui | Oui | default_tools_approval_mode |
| ChatGPT sur le web | Non | Oui, HTTPS uniquement | Au niveau du connecteur, selon la formule |
| Cursor | Oui | SSE, Streamable HTTP | Demande par défaut ; les Run Modes peuvent autoriser |
| VS Code | Oui | HTTP | Confiance accordée une fois au serveur, puis à chaque appel |
| Zed | Oui | Oui | Demande avant toute action d’outil |
| Devin Desktop | Oui | Streamable HTTP, SSE | Demande par défaut ; règles par outil |
Une ligne de ce tableau est la raison d’être de cet article.
Cherchez cette question et vous trouverez des affirmations catégoriques dans les deux sens, souvent sur des pages mises à jour cette année. Les deux ont été vraies à un moment, et c’est pourquoi elles persistent.
L’état actuel, d’après la documentation d’OpenAI : « L’application de bureau
ChatGPT, Codex CLI et l’extension IDE prennent en charge les serveurs MCP et
partagent la configuration MCP du même hôte Codex. » Cette configuration
partagée se trouve dans ~/.codex/config.toml, ou dans un .codex/config.toml
propre au projet pour les projets de confiance, et elle prend explicitement en
charge les « serveurs STDIO : des serveurs qui tournent comme un processus local
(démarré par une commande) ».
L’application de bureau est donc un client MCP local. Configurez un serveur une fois et la CLI, l’extension d’éditeur et l’application de bureau le voient tous les trois — vous ne le paramétrez pas trois fois.
ChatGPT sur le web est un autre produit, avec une autre réponse. Un connecteur personnalisé y est un serveur MCP distant joint en HTTPS via SSE ou Streamable HTTP : vous collez une URL, vous ne pointez pas vers une commande. ChatGPT tourne dans le cloud d’OpenAI et ne peut donc joindre que des serveurs exposés sur internet ; en exécuter un en local suppose de placer un tunnel devant. Les connecteurs personnalisés dépendent aussi de la formule — disponibles sur Plus, Pro, Business, Enterprise et Edu, pas sur Free ni Go.
Aucune des deux moitiés de la réponse d’internet n’est fausse. Ce sont des réponses à des questions différentes, et la question qui vaut la peine d’être posée est : devant quel ChatGPT êtes-vous assis ?
Claude Code accepte les serveurs stdio avec claude mcp add --transport stdio,
et les serveurs distants en HTTP, SSE — déprécié au profit de HTTP — et
WebSocket. La configuration a trois portées : locale, projet (.mcp.json,
versionné) et utilisateur (~/.claude.json). Un .mcp.json versionné ne se
connecte pas en silence : les serveurs qu’il déclare restent « en attente
d’approbation » jusqu’à ce que vous lanciez Claude en mode interactif dans un
espace de travail de confiance et que vous les approuviez, ce qui est un réglage
par défaut raisonnable pour un fichier qui arrive avec un git clone.
Claude Desktop lit claude_desktop_config.json — sur macOS dans
~/Library/Application Support/Claude/, sur Windows dans %APPDATA%\Claude\ —
et démarre chaque serveur configuré au lancement de l’application. Le modèle
documenté est l’approbation action par action : « Toutes les actions requièrent
votre approbation explicite avant leur exécution, ce qui vous garantit un
contrôle total sur ce que Claude peut consulter et modifier. » Les extensions
installées depuis Settings → Extensions sont la version empaquetée de la même
chose, ce qui explique que l’installation en un clic et le JSON écrit à la main
aboutissent au même endroit.
Cursor documente trois transports — stdio, SSE et Streamable HTTP — avec une
configuration de projet dans .cursor/mcp.json et une configuration globale
dans ~/.cursor/mcp.json. Sur le consentement, c’est explicite : « Cursor
demande une approbation avant d’utiliser des outils MCP par défaut. »
L’automatisation se choisit via les Run Modes, où les outils MCP autorisés
s’exécutent immédiatement en mode Auto-review et où tout le reste passe par un
classifieur.
VS Code prend en charge à la fois les serveurs HTTP distants et les serveurs
stdio locaux, configurés au niveau de l’espace de travail dans
.vscode/mcp.json ou au niveau de l’utilisateur via la commande MCP: Open User
Configuration. Il ajoute une étape que les autres ne mettent pas en avant :
avant qu’un serveur démarre pour la première fois, vous devez confirmer que vous
lui faites confiance, avec la possibilité d’examiner sa configuration depuis la
boîte de dialogue. La confiance est une propriété du serveur, pas de chaque
appel.
Zed configure les serveurs MCP depuis Settings → AI → MCP Servers, avec une
forme command/args/env pour les serveurs locaux et une forme
url/headers pour les distants. Ses permissions sont les plus fines du lot :
agent.tool_permissions.default demande une approbation avant toute action
d’outil, appels d’outils MCP compris, et des règles individuelles peuvent viser
mcp:<server>:<tool_name> — vous pouvez donc pré-approuver la lecture et
conserver une demande sur tout ce qui écrit.
Devin Desktop est celui qui a changé de nom. Cognition a renommé Windsurf en Devin Desktop le 2 juin 2026 par une mise à jour à distance ; abonnements, extensions, raccourcis clavier et connexions MCP existantes ont été repris sans intervention de l’utilisateur, et l’agent local Cascade a été remplacé par Devin Local, Cascade étant abandonné le 1er juillet 2026. La prise en charge de MCP est restée intacte : les serveurs « peuvent être configurés de deux façons : comme une commande locale (transport stdio) ou comme un serveur distant (transport HTTP) », avec des fichiers utilisateur, projet et surcharge locale ignorée par git, et les outils MCP demandent une approbation par défaut. Si vous suivez un ancien tutoriel Windsurf, les conseils sur le protocole restent valables ; seuls le nom du produit et les chemins de fichiers ont changé.
Tous les clients de ce comparatif demandent par défaut. C’est la bonne nouvelle, et c’est aussi là que se cache le détail utile, car une demande à chaque appel est inutilisable et aucune demande du tout n’est pas sûre. La question de conception intéressante, c’est ce qu’un client fait entre les deux.
Trois mécanismes sont en usage, et la plupart des clients les combinent :
.mcp.json fonctionnent ainsi.writes de Codex « demande pour les outils qui
ne sont pas marqués en lecture seule » — chercher est silencieux, modifier ne
l’est pas.mcp:<server>:<tool_name> chez Zed et
tools.<tool>.approval_mode chez Codex permettent de décider outil par outil,
seul mécanisme assez précis quand un même serveur propose les deux types.C’est l’asymétrie qu’il vaut la peine de comprendre, car elle repose sur l’honnêteté du serveur quant à ceux de ses outils qui modifient des choses. Un serveur qui déclare tout en lecture seule met en échec toutes les politiques côté client au-dessus de lui. Quand vous connectez un serveur que vous n’avez pas écrit, cette déclaration fait partie de ce à quoi vous accordez votre confiance — le même jugement que celui abordé dans ce qui rend l’accès en écriture MCP sûr.
Les serveurs locaux ne sont pas automatiquement le meilleur choix, et un comparatif qui conclurait l’inverse aurait quelque chose à vendre.
Un serveur distant est la bonne forme quand les données ne sont pas sur votre machine au départ — un suivi de tickets hébergé, une API de paiement, un tableau de bord de supervision. Placer un processus local devant un service cloud ajoute une étape et ne résout rien. Les serveurs distants fonctionnent aussi depuis un navigateur, depuis un téléphone et depuis le portable d’un collègue sans que personne n’installe quoi que ce soit, et un seul exploitant peut corriger un bug pour tout le monde d’un coup. Si la contrainte de votre équipe est « il faut que ça marche pour cinquante personnes sans droits d’administration », le tout-distant n’est pas une limite, c’est l’exigence.
Les serveurs locaux l’emportent sur un ensemble de cas plus étroit mais plus net : les données sont déjà sur la machine, elles sont assez sensibles pour que vous préfériez qu’elles ne voyagent pas, ou il n’existe pas de version hébergée à laquelle se connecter. Les enregistrements de vos propres réunions cumulent les trois.
Le serveur MCP de Speak-Y est un processus stdio local, ce qui le place dans la colonne de gauche du tableau pour chaque client qui en possède une. Votre assistant cherche dans les enregistrements et lit les transcriptions, les résumés et les tâches à faire directement dans la bibliothèque présente sur votre machine, sans relais cloud sur le trajet et sans rien à faire passer par un tunnel.
La séparation lecture/écriture correspond aux mécanismes clients décrits plus
haut. La lecture n’a besoin de rien d’autre en fonctionnement. Les commandes qui
modifient quelque chose — étiquettes, titres, noms d’intervenants,
retranscription, partage dans un canal d’équipe — passent par l’application
Speak-Y en cours d’exécution, sont déclarées à votre client MCP comme modifiant
des données, si bien qu’il demande avant de les exécuter à moins que vous
n’accordiez une permission permanente, et sont journalisées dans l’application,
où elles peuvent aussi être désactivées. Si vous préférez qu’un assistant ne
puisse jamais rien faire d’autre que lire, démarrer le serveur avec
--read-only dans la configuration de ce client fait que les commandes
modifiantes ne lui sont jamais publiées.
L’installation se fait en un clic depuis Paramètres → Intégrations, et c’est gratuit sur toutes les formules, y compris Free — ce qui n’est pas la norme chez les preneurs de notes de réunion, où MCP se trouve plutôt derrière une offre cloud payante.
Pour ChatGPT en particulier, la conséquence pratique de tout ce qui précède est que l’application de bureau est la surface à utiliser. Elle partage la configuration de Codex : le serveur que vous ajoutez pour Codex CLI y est déjà. Le guide ChatGPT desktop et vos données personnelles détaille cette mise en place, et si vous comparez plus généralement les deux formes, MCP local ou cloud traite de ce que chacune expose, et à qui.
Cela dépend du ChatGPT dont vous parlez. L’application de bureau ChatGPT le peut : elle partage sa configuration MCP avec Codex CLI et l’extension IDE via le même hôte Codex, et cette configuration prend en charge les serveurs STDIO démarrés par une commande sur votre machine. ChatGPT sur le web ne le peut pas — un connecteur web est un serveur MCP distant joint en HTTPS, un serveur local doit donc d’abord être exposé par un tunnel. Vérifié le 15 août 2026.
Un serveur stdio local est un programme que le client démarre sur votre machine et avec lequel il dialogue par l’entrée et la sortie standard. Aucun port réseau n’est ouvert et aucune donnée ne quitte l’ordinateur pour l’atteindre. Un serveur distant est un point d’accès HTTPS que le client joint par internet, en général avec un jeton d’authentification, et vos requêtes voyagent jusqu’à celui qui l’exploite.
Tous les grands clients demandent par défaut, mais la granularité diffère. Cursor demande son accord avant d’utiliser un outil MCP et exécute immédiatement les outils autorisés en mode Auto-review ; Zed demande avant toute action d’outil et accepte des règles par outil comme mcp:server:tool_name ; Codex propose quatre modes d’approbation, dont writes ne demande que pour les outils qui ne sont pas marqués en lecture seule. Un serveur peut aussi marquer certains outils comme étant en lecture seule, pour que le client sache lesquels sont sans risque.
Non. Cognition a renommé Windsurf en Devin Desktop le 2 juin 2026 par une mise à jour à distance, et l’agent local autrefois appelé Cascade a été remplacé par Devin Local, Cascade étant abandonné le 1er juillet 2026. Abonnements, extensions, raccourcis clavier et connexions MCP existantes ont été repris sans aucune intervention de l’utilisateur.
Tous ceux de ce comparatif capables de lancer un serveur local, car le serveur MCP de Speak-Y est un processus local et non un service hébergé : Claude Code, Claude Desktop, l’application de bureau ChatGPT et Codex, Cursor, VS Code, Zed et Devin Desktop. Il est gratuit sur toutes les formules, y compris Free, et s’installe en un clic depuis Paramètres → Intégrations.