Clients MCP : qui demande avant que l’IA modifie vos données (2026)

2026-09-29

Tout client MCP qui compte en 2026 demande avant qu’un assistant exécute un outil qui modifie quelque chose. Cette partie de la réponse est banale et rassurante. La partie utile, c’est ce qui se passe après la première demande, car personne ne clique longtemps quarante fois par jour sur « Autoriser » : chaque client propose un moyen de ne plus être sollicité, et les clients diffèrent nettement par la finesse de ce moyen.

En bref : Claude Code, Zed, Cursor et Devin Desktop permettent de préapprouver des outils MCP individuels par leur nom. Codex, le moteur de l’application de bureau ChatGPT, peut à la place décider d’après les étiquettes du serveur lui-même — demander pour tout ce qui n’est pas marqué en lecture seule. VS Code fait les deux au niveau de la boîte de dialogue et ajoute des interrupteurs valables pour tout l’espace de travail. Aucune de ces conceptions n’est fausse, mais elles échouent de manières différentes, et l’échec qui doit vous préoccuper dépend de qui a écrit le serveur.

Ce comparatif complète notre tour d’horizon des clients MCP capables de lancer un serveur local. Celui-là répond à « est-ce que ça démarre » ; celui-ci répond à « que se passe-t-il quand l’assistant décide de modifier quelque chose ». Tout ce qui suit a été vérifié dans la documentation de chaque éditeur le 29 septembre 2026.

La réponse courte

Deux colonnes portent l’essentiel du sens. « Autorisation permanente la plus fine » vous dit si vous pouvez faire confiance à search sans faire confiance à share. « Décide d’après les annotations » vous dit si le client fait ce tri à votre place — à partir d’étiquettes que le serveur a écrites sur lui-même.

Codex et l’application de bureau ChatGPT : quatre modes et une étiquette

Codex a la conception la plus explicite, et comme l’application de bureau ChatGPT, Codex CLI et l’extension IDE partagent un même fichier de configuration, elle couvre les trois. Chaque serveur MCP reçoit un default_tools_approval_mode, et chaque outil peut le surcharger avec tools.<tool>.approval_mode. Les valeurs documentées sont auto, prompt, writes et approve.

La plus intéressante est writes. Selon OpenAI, elle « demande pour les outils qui ne sont pas marqués en lecture seule ». La recherche s’exécute sans bruit, tout le reste s’arrête et demande, et un outil sans aucune annotation compte comme une écriture — le défaut prudent quand un serveur ne dit rien. En plus des modes, la documentation des approbations de Codex précise que les appels d’outils MCP destructifs exigent toujours une approbation lorsque l’outil annonce une annotation destructive, sauf s’il annonce aussi une annotation de lecture.

Un changement à connaître si votre configuration est ancienne : Codex ne prend plus en charge approval_policy = "untrusted", et ce réglage retiré peut empêcher le client de démarrer. La confiance envers un projet se règle désormais avec le trust_level du projet.

ChatGPT sur le web suit le même principe. En mode développeur, disponible sur les comptes Pro, Plus, Business, Enterprise et Education, « les actions d’écriture exigent par défaut une confirmation » ; ChatGPT respecte readOnlyHint et traite tout outil qui en est dépourvu comme une écriture. Un choix peut être mémorisé par outil pour le reste d’une conversation, et pas plus longtemps.

Claude Code et Claude Desktop : des règles que l’on écrit par nom

Claude Code ne lit pas les annotations pour décider. Il utilise des règles d’autorisation réparties en trois listes — allow, ask et deny — évaluées dans un ordre fixe : deny, puis ask, puis allow. Les outils MCP se nomment mcp__<server>__<tool>, donc mcp__notes__search autorise un outil, mcp__notes__get_* une famille, et mcp__notes ou mcp__notes__* couvre le serveur entier. Le mode par défaut s’appelle désormais Manual ; les modes plus permissifs comprennent acceptEdits, auto, où un classifieur examine les actions à votre place, et bypassPermissions.

Deux détails penchent du côté de la sécurité. Les serveurs déclarés dans le .mcp.json versionné d’un projet ont besoin de votre approbation avant même de se connecter. Et l’auteur d’un serveur peut marquer un outil avec _meta["anthropic/requiresUserInteraction"], après quoi Claude Code affiche sa demande à chaque appel — même en acceptEdits, auto et bypassPermissions.

Les réglages des connecteurs de Claude Desktop, sous Customize → Connectors, classent les outils d’un serveur en catégories, comme lecture seule et écriture/suppression, et chaque catégorie ou outil peut être réglé sur Always allow, Needs approval ou Blocked.

Cursor, VS Code, Zed et Devin Desktop : les éditeurs

Cursor le dit clairement : « Cursor demande une approbation avant d’utiliser des outils MCP par défaut. » Le MCP suit les mêmes Run Modes que les commandes du terminal. En Auto-review, les appels de la liste d’autorisation s’exécutent immédiatement et tout le reste passe par un modèle classifieur ; Run Everything exécute chaque appel d’outil sans demander. La liste d’autorisation accepte des entrées server:tool avec jokers. Un piège : laisser vide la liste d’outils autorisés d’un serveur autorise tous les outils de ce serveur.

VS Code appelle son niveau par défaut Manual permissions : tout ce qui n’est pas approuvé automatiquement exige une confirmation. La boîte de dialogue permet d’approuver une seule utilisation ou d’accorder l’approbation pour la session, l’espace de travail ou toutes les invocations futures, et des approbations par outil peuvent être définies pour chaque serveur MCP. Allow all supprime entièrement les demandes, et Assisted permissions, où un modèle juge chaque appel, est marqué comme expérimental. Une exception mérite l’attention : les serveurs MCP fournis dans un plugin d’agent « sont implicitement approuvés lorsque vous installez le plugin » et sautent la demande de confiance distincte au démarrage. Installer le plugin, c’est prendre la décision de confiance.

Zed a le système de règles le plus lisible. agent.tool_permissions.default vaut confirm tant que vous ne le changez pas, avec allow et deny comme alternatives. Les règles nomment les outils MCP sous la forme mcp:<server>:<tool_name> et peuvent être réglées pour toujours autoriser, toujours confirmer ou toujours refuser, le refus l’emportant. La demande elle-même propose « Allow once », « Deny once » et « Always for » l’outil ; pour les outils MCP, seule l’option au niveau de l’outil existe.

Devin Desktop, l’ex-Windsurf, a changé de modèle en même temps que de nom. Son agent, Devin Local, « remplace les niveaux d’exécution automatique par un système d’autorisations plus fin », et par défaut il demande avant d’appeler tout outil MCP. Depuis la demande, vous pouvez autoriser un outil ou tous les outils de ce serveur, pour la session ou de façon permanente, et les règles Deny priment sur tout. Les administrateurs Enterprise peuvent préapprouver des serveurs ou des outils précis pour toute l’organisation.

Ce que les annotations peuvent et ne peuvent pas faire

La spécification MCP donne aux serveurs un vocabulaire pour décrire leurs outils : readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Elle dit aussi aux clients jusqu’où les croire : les clients « DOIVENT considérer les annotations d’outils comme non fiables, sauf si elles proviennent de serveurs de confiance ». Et elle demande un humain dans la boucle, capable de refuser n’importe quel appel d’outil.

Cela remet les deux conceptions ci-dessus en perspective. Un client qui décide d’après les annotations, comme le mode writes de Codex, est pratique avec un serveur de confiance : vous configurez une ligne, et chaque nouvel outil d’écriture ajouté par le serveur déclenche automatiquement une demande. Avec un serveur dont vous vous méfiez, il n’est ni plus ni moins sûr que l’honnêteté du serveur. Un outil qui modifie des données et se dit en lecture seule s’exécute sans demande.

Un client qui vous fait nommer les outils, comme Claude Code ou Zed, échoue dans l’autre sens. Il se moque de ce que prétend le serveur, mais un nouvel outil d’écriture ajouté par une mise à jour n’est couvert que si votre règle était assez large pour l’attraper — ou assez étroite pour le manquer et retomber sur une demande. Les règles par nom sont les plus sûres lorsqu’elles disent « autoriser ces lectures », et non « autoriser ce serveur ».

Une configuration raisonnable pour un serveur qui lit et écrit

Quel que soit le client, les quatre mêmes habitudes couvrent l’essentiel du risque :

1. Autorisez les lectures par nom, pas le serveur entier. Chercher et lire des transcriptions, c’est ce que fait un assistant toute la journée ; c’est là qu’une demande coûte le plus et protège le moins.
2. Gardez une demande sur tout ce qui partage ou remplace. Publier pour d’autres personnes et écraser du texte sont les deux types de modification qu’on ne peut pas annuler en remettant une valeur.
3. Ne vous fiez aux annotations que pour les serveurs de confiance. Pour un serveur issu d’un registre que vous n’avez jamais utilisé, nommez plutôt ses outils dans des règles.
4. Donnez à un client moins fiable une instance en lecture seule. Si le serveur prend en charge un mode lecture seule, un client peut être limité à la lecture pendant qu’un autre garde l’accès complet.

Signaux d’alerte : une entrée de liste d’autorisation Cursor pour un serveur dont la liste d’outils est vide, un plugin VS Code que personne dans l’équipe n’a examiné, et « Always allow » cliqué sur un outil dont vous n’avez pas lu le nom.

Ce que cela donne dans Speak-Y

Le serveur MCP de Speak-Y est conçu pour les deux types de client. Les outils de lecture — rechercher des enregistrements, lire les transcriptions, les résumés et les actions à mener, lister les tags et les canaux — portent readOnlyHint et lisent la bibliothèque directement sur votre machine. Les outils qui modifient quelque chose — tags, titres, noms des intervenants, nouvelle transcription, partage dans un canal d’équipe — sont déclarés comme modifiant des données et passent par l’application Speak-Y en cours d’exécution, où chaque appel est journalisé et où ils peuvent être désactivés.

Deux d’entre eux sont marqués destructiveHint à dessein : retranscribe, car il remplace le texte actuel d’un enregistrement, corrections manuelles comprises, et share_to_channel, car des collègues peuvent lire un enregistrement avant que vous ne le retiriez. Dans le mode writes de Codex, ces demandes apparaissent sans aucune configuration ; dans Claude Code ou Zed, autorisez les outils de lecture par leur nom et laissez le reste en ask.

Si vous préférez qu’un client ne puisse que lire, démarrez le serveur avec --read-only dans la configuration de ce client : les outils qui modifient ne lui sont pas publiés du tout, il n’y a donc rien à approuver par accident. La mise en place se fait en un clic depuis Paramètres → Intégrations, et le serveur MCP est gratuit sur toutes les formules, y compris Free.

La demande d’approbation n’est qu’un des contrôles qui rendent un assistant capable d’écrire sûr à utiliser. Les autres — quelles modifications sont réversibles et ce que conserve le journal — sont traités dans ce qui rend l’accès en écriture MCP sûr, et la documentation MCP détaille la configuration client par client.

FAQ

Les clients MCP demandent-ils confirmation avant d’exécuter un outil qui modifie des données ?

Tous les grands clients demandent par défaut. Claude Code, Cursor, VS Code, Zed et Devin Desktop affichent une demande avant l’exécution d’un outil MCP tant que vous ne l’avez pas préapprouvé, et le mode développeur de ChatGPT exige une confirmation pour tout outil non marqué en lecture seule. Ce qui change, c’est la finesse de la préapprobation ensuite : par outil, par serveur, pour la session ou définitivement. Vérifié le 29 septembre 2026.

Quels clients MCP s’appuient sur l’annotation readOnlyHint pour décider quand demander ?

Codex et ChatGPT le font explicitement. Le mode d’approbation writes de Codex demande pour les outils qui ne sont pas marqués en lecture seule et demande toujours avant un outil qui se déclare destructif ; le mode développeur de ChatGPT traite tout outil sans readOnlyHint comme une action d’écriture. Claude Code, Cursor, VS Code et Zed ne documentent pas les annotations comme critère d’approbation : c’est vous qui écrivez les règles, par nom d’outil.

Peut-on approuver automatiquement les outils de lecture et rester sollicité avant les écritures ?

Oui, dans tous les clients de ce comparatif, mais le mécanisme diffère. Dans Claude Code, Zed, Cursor et Devin Desktop, vous autorisez les outils de lecture par leur nom, par exemple mcp__server__search dans Claude Code ou mcp:server:search dans Zed. Dans Codex, le mode writes le fait en une ligne, en comptant sur le serveur pour marquer honnêtement ses outils de lecture.

Les annotations d’outils comme readOnlyHint sont-elles une garantie de sécurité ?

Non. La spécification MCP indique que les clients doivent considérer les annotations d’outils comme non fiables, sauf si elles viennent de serveurs de confiance. Un serveur qui marque un outil d’écriture comme étant en lecture seule neutralise toute politique client fondée sur cet indice. Voyez les annotations comme une commodité pour les serveurs auxquels vous faites déjà confiance, et nommez explicitement les outils dans vos règles pour les autres.

Quelle est la façon la plus sûre de connecter un serveur de notes de réunion à un assistant IA ?

Préapprouver uniquement les outils de lecture, garder une demande sur tout ce qui modifie des données, et donner aux clients en qui vous avez moins confiance une instance en lecture seule. Avec Speak-Y, démarrer le serveur avec --read-only dans la configuration d’un client retire complètement à ce client les outils qui modifient, tandis qu’un autre client garde l’accès complet avec ses propres demandes.