Les MCP, la porte dérobée de ton IA

Les serveurs MCP donnent à ton IA un accès réel à ton Mac : fichiers, shell. Pratique, mais c'est une porte dérobée. Voilà comment la verrouiller.

Une porte de verre bleu entrouverte dans le flanc d'une puce Apple Silicon, un filet de lumière dorée qui fuit par l'interstice.

Le confort qui te tend un piège

Tu installes Claude Desktop sur ton Mac. En quelques clics, tu lui branches un serveur qui lit tes fichiers, un autre qui interroge ta base de données, un troisième qui lance des commandes dans ton terminal. D’un coup, ton assistant ne se contente plus de discuter, il agit. Il ouvre tes documents, réécrit ton code, trie tes dossiers pendant que tu bois ton café.

C’est bluffant. C’est aussi le moment exact où tu viens d’ouvrir une porte sur ta machine sans en garder la clé.

Ces petits connecteurs s’appellent des serveurs MCP. Ils sont la raison pour laquelle ton IA est passée de bavarde à utile. Ils sont aussi la surface d’attaque la plus mal comprise de tout l’écosystème IA de 2026. Et le problème n’est pas théorique : une faille de conception dans le protocole a exposé environ 200 000 instances à l’exécution de code à distance, en avril dernier.

Voyons ce que tu branches vraiment sur ton Mac quand tu ajoutes un MCP. Et surtout, comment le faire sans te faire avoir.


Un MCP, c’est quoi au juste

MCP, ça veut dire Model Context Protocol. Anthropic l’a publié fin 2024 comme une norme ouverte, et tout le monde l’a adoptée, Claude bien sûr, l’app Claude Desktop comme l’outil en ligne de commande Claude Code, mais aussi Cursor, Windsurf, et une bonne partie des outils IA que tu croises.

L’idée est simple, presque évidente. Un modèle de langage, tout seul, ne sait que parler. Il ne peut ni ouvrir un fichier, ni lire ta base, ni envoyer un mail. Le MCP est le câble standard qui relie ton assistant à des outils extérieurs. Un serveur MCP d’un côté expose une capacité, lire des fichiers, requêter une API, exécuter une commande. L’assistant de l’autre côté décide quand s’en servir.

Pense à une prise universelle. Avant, chaque appareil avait son branchement propriétaire. Le MCP, c’est la prise unique où tu enfiches ce que tu veux : un connecteur pour tes fichiers, un pour ton agenda, un pour ton dépôt Git. Ton IA pioche dedans à la demande.

Concrètement, le flux ressemble à ça. Tu demandes à Claude de ranger tes captures d’écran. Le modèle repère qu’il a un serveur MCP filesystem à disposition. Il l’appelle, liste ton dossier, déplace les fichiers. Tu vois le résultat, pas la mécanique. Le serveur a exécuté une action réelle sur ton disque, décidée par le modèle, déclenchée par ta phrase.

C’est exactement là que le confort bascule en risque.


Pourquoi c’est une porte dérobée

Reprends le flux, mais regarde qui décide et qui exécute.

Toi, tu écris une phrase en langage naturel. Le modèle, une boîte statistique que personne ne contrôle ligne à ligne, décide quel outil appeler et avec quels arguments. Le serveur MCP exécute ce qu’on lui demande, sur ta machine, avec tes droits. Entre les trois, il n’y a pas de garde du corps. Personne pour lever la main et dire “attends, tu es sûr de vouloir supprimer ça ?”.

Un serveur MCP mal conçu ou franchement malveillant, c’est un exécuteur de commandes qui obéit à un intermédiaire que tu ne pilotes pas. Le modèle peut être manipulé par une consigne cachée, un texte piégé dans un fichier qu’il lit, une page web qu’on lui fait ouvrir. On appelle ça une injection de prompt. Le résultat : ton assistant se retrouve à lancer une action que tu n’as jamais demandée, via un serveur qui, lui, n’a aucune raison de refuser.

Et le vrai piège est dans la configuration. Un fichier de config MCP, ce n’est pas une liste de préférences bien sages. C’est, en pratique, un script shell déguisé. Il définit quels exécutables lancer, avec quels arguments, quelles variables d’environnement. Charger une config MCP que tu n’as pas lue, c’est lancer un script que tu n’as pas relu, et potentiellement malveillant. La nuance, c’est que celui-ci a l’air inoffensif parce qu’il est planqué dans un fichier JSON.

Le mot “porte dérobée” est mérité pour une raison précise : tu ne vois rien passer. Pas de fenêtre de confirmation, pas de trace visible, pas d’alerte. Le modèle décide, le serveur exécute, et toi tu regardes le résultat en pensant que ton IA t’a rendu service.


L’incident qui a mis tout le monde d’accord

Ce n’est pas une hypothèse de labo. C’est arrivé, à grande échelle, en avril 2026.

Le 15 avril, l’équipe de recherche d’OX Security publie un rapport au titre peu modeste, “The Mother of All AI Supply Chains”. Le constat est brutal : l’interface principale des SDK MCP officiels, celle qui fait dialoguer l’outil et le serveur en local, permet à une simple configuration de déclencher l’exécution de commandes système arbitraires. Sans validation des entrées, sans isolation par défaut.

Les chiffres donnent le vertige :

  • 7 000 et plus serveurs MCP publics indexés
  • 150 millions et plus de téléchargements des SDK et serveurs concernés
  • environ 200 000 instances estimées vulnérables
  • 10 CVE émis, dont CVE-2026-30615 sur Windsurf : une injection de prompt via HTML malveillant menant à l’exécution de code en local, notée 8.0 sur 10 en sévérité

Côté Mac, ce ne sont pas des noms abstraits. Cursor, Windsurf et Claude Desktop utilisent ces SDK, et sont concrètement touchés par leurs intégrations MCP. Les chercheurs ont validé leurs attaques sur six plateformes en production. Ça marchait pour de vrai.

Et voilà le meilleur, ou le pire selon le côté où tu te trouves. La réponse d’Anthropic, telle que rapportée par OX Security et confirmée par plusieurs reprises, tient en deux mots : “by design”. Le comportement est jugé normal, à condition que l’utilisateur, ou le développeur en aval, fasse lui-même le travail de sécurisation. Anthropic refuse de modifier le protocole.

L’argument est défendable sur le papier. Un protocole n’est pas un bac à sable, et personne n’oblige un standard à border tous les usages. Sauf que dans les faits, Anthropic transfère la responsabilité du verrouillage à des gens qui n’ont jamais signé pour ça : le particulier qui installe Claude Desktop sans notion de sécurité, la PME qui branche un connecteur trouvé sur un dépôt public. Les correctifs viennent des outils en aval, Cursor, Windsurf et les autres, pas du protocole lui-même.

Traduction : le sandbox, c’est ton problème. Autant le savoir avant, pas après.

À lire : MCP d’Anthropic, un défaut de conception expose 200 000 instances, notre radar sur la faille et les CVE associés.


Durcir tes MCP sans renoncer au confort

Bonne nouvelle : tu n’as pas à choisir entre “IA branchée sur tout” et “IA débranchée et inutile”. Le curseur se règle. Voilà comment le mettre au bon endroit.

Avant de plonger dans les réglages, sache où ça se passe. Sur Claude Desktop, tes serveurs MCP se gèrent dans Réglages puis Développeur, et le bouton “Modifier la config” ouvre le fichier claude_desktop_config.json.

Dans Claude Desktop, Réglages puis Développeur, tes serveurs MCP locaux et le bouton pour ouvrir la config.

À l’ouverture, une config MCP ressemble à ça : quelques serveurs déclarés, chacun avec sa commande et ses accès. Rien de plus qu’un script qui attend son heure.

Une config MCP : deux serveurs déclarés, chacun avec sa commande et ses accès.

1. Inventorie tes serveurs MCP actifs. Sur Claude Desktop, va dans Réglages puis Développeur, et clique sur “Modifier la config” : ça ouvre ~/Library/Application Support/Claude/claude_desktop_config.json. Sur Cursor, va dans Réglages puis MCP. Sur Windsurf, la liste est accessible depuis l’IDE. Désactive tout serveur que tu n’as pas déployé toi-même ou dont tu n’as pas lu le code. Si tu ne sais plus pourquoi il est là, il ne devrait pas y être.

2. Applique le moindre privilège, sérieusement. Un serveur MCP filesystem ne doit jamais pointer sur / ni sur ~. Donne-lui le sous-dossier précis du projet en cours, rien de plus. Ton assistant n’a pas besoin d’un accès total à ton disque pour ranger trois captures d’écran.

3. Traite toute config tierce comme hostile par défaut. Un bout de config récupéré sur GitHub, un fichier partagé sur Slack, l’export d’un collègue, un dépôt cloné : lis la configuration intégralement avant de l’activer. Les chemins exécutables, les commandes, les variables d’environnement. Rappelle-toi que c’est un script shell déguisé. Personne ne lance un .sh inconnu sans le lire. Un .json de config MCP, c’est pareil.

4. Si tu es sur Claude Code, verrouille par la config, pas par la consigne. Tu peux écrire dans ton CLAUDE.md une règle du genre “n’active aucun serveur MCP sans mon accord”. Ça documente ton intention, mais ne te repose pas dessus : tu viens de lire pourquoi un modèle qu’on manipule n’obéit pas toujours aux consignes. La vraie serrure est dans ton settings.json. Tiens-y une liste blanche des outils MCP autorisés et refuse le reste avec permissions.deny, et laisse active la demande d’approbation pour tout serveur déclaré dans un .mcp.json de projet, ne l’auto-approuve jamais. Le CLAUDE.md rappelle la règle à l’humain, le settings.json l’impose à la machine.

Un settings.json avec une liste blanche d'outils MCP autorisés et un deny pour le reste.

5. Verrouille les serveurs qui écoutent le réseau. Certains MCP tournent comme un petit serveur HTTP local. Vérifie qu’il est lié à 127.0.0.1, jamais à 0.0.0.0. Sinon, une page web malveillante ouverte dans ton navigateur peut, dans le pire cas, déclencher une exécution sur ta machine.

~ % lsof -iTCP -sTCP:LISTEN -nP | grep node
node    41827 demo   23u  IPv4 0x9f3a5c  0t0  TCP 127.0.0.1:8787 (LISTEN)
node    41902 demo   25u  IPv4 0x9f3b1d  0t0  TCP *:8788 (LISTEN)

La première ligne est bien sagement sur 127.0.0.1. La seconde écoute sur *, donc sur toutes les interfaces : c’est celle que tu dois corriger.

6. Mets à jour les outils touchés. Cursor, Windsurf, Claude Desktop et les frameworks concernés ont publié des versions correctives à partir d’avril 2026. Vérifie dans les notes de version que la faille est explicitement traitée, pas juste “diverses améliorations de sécurité”.

7. Préfère le local au distant. Un serveur MCP qui tourne sur ta machine et n’expose rien au réseau est bien plus facile à raisonner qu’un connecteur distant hébergé chez un tiers. Chaque service extérieur ajouté à la boucle, c’est une entreprise de plus qui peut lire ce qui transite, ou se faire compromettre à ta place.

Et avant d’installer un nouveau serveur MCP tiers, pose-toi trois questions. Qui l’a écrit et le code est-il consultable ? De quels accès a-t-il réellement besoin, et est-ce que la config demande davantage ? Qu’est-ce qui se passe le jour où ce serveur est compromis ? Si tu ne peux pas répondre aux trois, ne l’installe pas.


En résumé

Les MCP sont ce qui rend ton assistant IA vraiment utile. Ils sont aussi ce qui le relie à tes fichiers, ta base, ton shell, avec tes droits et sans témoin. Le modèle décide, le serveur exécute, tu ne vois rien passer. C’est la définition d’une porte dérobée, et avril 2026 a prouvé qu’elle était grande ouverte pour environ 200 000 installations.

La souveraineté, ici, ne consiste pas à débrancher ton IA. Elle consiste à savoir ce qui est branché, à ne donner que le strict accès nécessaire, et à ne jamais charger une config que tu n’as pas lue. Un serveur MCP local, au périmètre serré, dont tu as lu le code, c’est un outil. Le même serveur, tiré d’un dépôt inconnu avec un accès à tout ton disque, c’est une faille avec une interface amicale.

Inventorie tes MCP. Coupe ceux que tu ne reconnais pas. Réduis les accès de ceux que tu gardes. Le reste, ce sont juste de bonnes habitudes que tu as déjà pour le reste de ta machine.

À lire aussi : Ton IA peut être éteinte par les US, monte la tienne et Apple Intelligence, ce qui sort vraiment de ton Mac.