Pendant près d’un an, la réponse honnête à « est-il sûr de connecter un assistant IA à mes notes ? » tenait au fait que la connexion se contentait de les lire. C’était vrai de la plupart des serveurs MCP pour notes de réunion, et cela rendait la question de la sécurité facile : un outil qui ne peut rien changer ne peut pas changer la mauvaise chose.
Ce n’est plus là que se situe la question intéressante. Les assistants étiquettent désormais des enregistrements, renomment des intervenants, relancent la transcription et publient des notes dans des canaux partagés — et la version utile de la question est plus étroite : que faut-il réunir avant de laisser un modèle modifier vos données ? Quatre choses, et aucune n’est « l’éditeur promet d’être prudent » : le client demande avant l’appel, la modification est assez restreinte pour tenir en une phrase, les changements irréversibles sont signalés comme tels, et il existe un journal que vous pouvez lire ensuite.
Cet article porte sur l’endroit où passe cette ligne. Si le protocole lui-même vous est nouveau, ce qu’est un serveur MCP en pose d’abord les bases.
« Accès en écriture » est une seule expression pour trois choses très différentes, et c’est de les confondre qui rend le sujet plus effrayant qu’il ne l’est.
Étiqueter. Tags, titres, noms d’intervenants. Ces actions ajoutent ou remplacent des métadonnées à côté d’un enregistrement. Si l’assistant étiquette la mauvaise réunion, vous ouvrez l’application et retirez le tag. Le pire des cas est de ranger derrière un modèle trop zélé.
Remplacer le contenu. Relancer la transcription d’un enregistrement produit un nouveau texte et abandonne l’ancien — y compris les corrections que vous aviez faites à la main. Rien n’a quitté votre machine, mais quelque chose qui vous appartenait a disparu. C’est la catégorie où « réversible » cesse discrètement d’être vrai.
Quitter la machine. Publier un enregistrement dans un canal d’équipe, partager une transcription par e-mail, accorder un accès à quelqu’un. Ici la modification ne porte pas d’abord sur vos données — elle porte sur qui les a vues. L’annulation est une opération technique sur un fait social, et elle ne fonctionne pas.
Un modèle de sécurité qui traite ces trois cas comme un seul réglage se trompera dans les deux sens : trop bruyant pour le premier, trop permissif pour le troisième.
MCP dispose d’un vocabulaire pour cela. Une définition d’outil peut porter des
annotations : readOnlyHint (l’outil se contente de lire), destructiveHint
(il peut écraser au lieu d’ajouter), idempotentHint (l’appeler deux fois ne
change rien de plus) et openWorldHint (il s’adresse à des systèmes
extérieurs). Un serveur qui publie un outil de partage sans openWorldHint se
décrit mal.
Deux phrases de la spécification décident de ce que vaut ce vocabulaire. D’abord, sur le devoir du client : « pour la confiance, la sûreté et la sécurité, il DEVRAIT toujours y avoir un humain dans la boucle, capable de refuser l’invocation d’un outil ». Ensuite, sur les annotations elles-mêmes : les clients « DOIVENT considérer les annotations d’outils comme non fiables, sauf si elles proviennent de serveurs de confiance ».
Lues ensemble, ces deux phrases règlent l’architecture. Les annotations sont la façon dont un serveur déclare un risque ; elles ne sont pas un verrou qu’il pourrait fermer. La barrière vit dans le client, et la demande de confirmation que vous voyez avant l’exécution d’un outil est une décision de votre client, éclairée par la déclaration du serveur. Claude Code, par exemple, demande par défaut pour les outils MCP, alors que ses propres outils intégrés ne le font pas.
La conséquence pratique est inconfortable et mérite d’être dite franchement : le moment où vous décidez quoi que ce soit est le moment où vous accordez une permission permanente. Après « toujours autoriser », la boîte de dialogue n’est plus un contrôle. Accordez-la outil par outil plutôt que serveur par serveur — une recherche toutes les heures, très bien ; un partage toutes les heures, non.
L’axe utile n’est pas lecture contre écriture. C’est ce que coûte une erreur.
| Action | Annulation | Pourquoi |
|---|---|---|
| Ajouter ou retirer un tag | Oui, dans l’application | Métadonnées à côté de l’enregistrement |
| Renommer un enregistrement ou un intervenant | Oui, dans l’application | Une étiquette, pas le contenu |
| Relancer la transcription | Non | Remplace le texte, corrections manuelles comprises |
| Publier dans un canal d’équipe | Non | Des collègues l’ont peut-être déjà lu |
| Partager une transcription par e-mail | Non | Les destinataires gardent ce qu’ils ont reçu |
Tout ce qui figure dans les trois dernières lignes mérite une confirmation explicite à chaque fois ; tout ce qui figure dans les deux premières, probablement pas. La liste des outils est l’endroit où un éditeur déclare ceux qu’il propose, et elle mérite d’être lue avant de connecter quoi que ce soit.
Les demandes de confirmation s’usent. Une seule tâche de recherche peut en produire des dizaines, y compris pour des outils incapables de modifier quoi que ce soit, et le résultat documenté est que les gens désactivent les demandes en bloc plutôt que de lire la suivante. Un contrôle qui vous entraîne à le balayer n’est pas un contrôle.
Un journal ne s’use pas, parce qu’on le lit après coup et seulement quand on a une question. Les recommandations de la spécification aux clients incluent la journalisation de l’usage des outils à des fins d’audit, et le même raisonnement vaut pour le serveur : si un assistant peut modifier quelque chose, vous devez pouvoir voir ensuite ce qu’il a modifié, quand, et sur quel enregistrement.
Le test utile pour toute intégration MCP avec accès en écriture : si le modèle a fait cette nuit quelque chose que je n’attendais pas, où le lirais-je aujourd’hui ? Si la réponse est « nulle part », c’est que la boîte de dialogue portait à elle seule tout le modèle de sécurité.
Il y a deux façons d’empêcher un assistant de modifier des choses, et elles ne sont pas interchangeables.
Par client, dans la configuration de ce client. Un serveur démarré en mode
lecture seule ne publie que ses outils de lecture. La différence avec un refus
d’appel n’est pas cosmétique : un outil que le modèle ne voit pas est un outil
qu’il ne proposera pas, si bien que vous n’avez jamais droit à « je publie cela
dans le canal d’équipe » suivi d’une erreur. Dans Speak-Y, c’est l’option
--read-only dans les args du serveur, et elle laisse six outils de lecture
en place.
Globalement, dans l’application. Un seul interrupteur qui couvre d’un coup tous les clients connectés, quel que soit celui qui a demandé.
La distinction compte parce qu’une option dans le fichier de configuration de Cursor retient Cursor et rien d’autre. L’option par client dit « Cursor n’a le droit que de lire, Claude Code a le droit de tout faire » ; seul l’interrupteur dans l’application est une affirmation sur tous.
Speak-Y sépare délibérément les deux moitiés, et la séparation se voit de l’extérieur.
La lecture est locale et n’exige rien d’allumé. Recherche, transcriptions, résumés, tâches à faire et tags proviennent de la bibliothèque sur votre Mac, ouverte en lecture seule par un processus séparé ; l’application n’a pas besoin de tourner. Rien n’est téléversé pour que l’assistant lise — même si, comme avec tout serveur MCP, ce qu’il lit part vers le fournisseur de votre modèle avec la conversation, ce qui est une autre question que celle du lieu de stockage.
Les modifications passent par l’application en cours d’exécution. Étiqueter, renommer, retranscrire et publier dans un canal d’équipe sont exécutés par le même code que celui placé derrière les boutons de l’interface, et non par une seconde implémentation avec sa propre idée des règles. Si l’application ne tourne pas, ces outils le disent au lieu de fonctionner à moitié.
Chaque action est déclarée et journalisée. Les outils modifiants sont
publiés avec readOnlyHint: false ; la retranscription et la publication dans un
canal portent en plus destructiveHint, et la publication porte
openWorldHint, parce que c’est la seule action qui quitte la machine. Les 50
dernières actions sont listées dans Paramètres → Intégrations avec l’heure,
l’opération, l’enregistrement et le résultat — et sans le texte des
transcriptions, qui survivrait sinon à l’enregistrement dont il provient.
L’interrupteur des actions de l’assistant est sur le même écran, et le serveur
est gratuit sur tous les forfaits.
Vérifié le 13 août 2026, dans la documentation de chaque éditeur :
La liste de Fireflies est la plus intéressante, parce que « partager cette transcription avec ces adresses e-mail » est précisément la catégorie d’action où la confirmation du client est la seule chose entre une instruction mal comprise et un destinataire. Ce n’est pas une critique de la fonctionnalité — l’annoncer dans la liste des outils est la façon honnête de la livrer. C’est un argument pour lire cette liste avant d’accorder une permission permanente à un serveur entier.
Rien de tout cela n’exige de faire confiance aux intentions d’un éditeur, et c’est bien l’idée. « Est-il sûr de laisser un assistant modifier mes données ? » n’a pas de réponse générale, mais se décompose en questions qui en ont une : ce qui change, qui confirme, ce qui est annulable, et où c’est écrit.
Si vous n’avez pas encore connecté d’assistant, le point de départ pratique est connecter ses notes de réunion en MCP, qui parcourt l’installation et les premières requêtes avant que tout cela ne devienne pertinent.
Il l’est dans un sens étroit : un outil qui ne peut rien changer ne peut pas changer la mauvaise chose. Mais la lecture seule est un instrument grossier, pas un modèle de sécurité. Ce qui vous protège vraiment, c’est de savoir quelles modifications sont réversibles, d’avoir un client qui demande avant les irréversibles, et de pouvoir lire ensuite ce qui a été fait. Un serveur en lecture seule vous offre la première propriété en renonçant à la fonctionnalité.
C’est une propriété de votre client, pas du serveur. La spécification MCP dit qu’il devrait toujours y avoir un humain dans la boucle, capable de refuser l’invocation d’un outil, et des clients comme Claude Code demandent par défaut pour les outils MCP. Les serveurs peuvent déclarer un outil comme modifiant ou destructeur au moyen d’annotations, mais la spécification impose aux clients de les considérer comme non fiables tant que le serveur n’est pas de confiance : elles éclairent la demande, elles ne l’imposent pas.
La boîte de dialogue cesse d’être un contrôle pour cet outil, et tous les appels suivants s’exécutent sans rien demander. C’est un échange raisonnable pour un outil de recherche, et mauvais pour un outil qui partage des données avec d’autres personnes. Accordez la permission permanente outil par outil plutôt que serveur par serveur, et considérez le journal d’activité comme ce qui répond à la question de ce qui s’est réellement passé.
Oui, si le serveur propose un mode lecture seule réglé dans la configuration du client lui-même. C’est le cas de Speak-Y : ajouter --read-only aux args dans la configuration MCP d’un client ne publie que les outils de lecture pour ce client, si bien que Cursor peut être limité à la lecture pendant que Claude Code garde l’accès complet. Un interrupteur dans l’application s’applique au contraire à tous les clients d’un coup.
Deux catégories. Relancer la transcription remplace le texte actuel d’un enregistrement, corrections manuelles comprises. Publier un enregistrement dans un canal d’équipe le rend visible aux collègues, et le retirer ensuite ne le fait pas oublier. Tags, titres et noms d’intervenants sont des étiquettes et peuvent être remis en état dans l’application.