# Quels serveurs MCP peut-on installer en toute sécurité?

Date: 2025-04-05 · Author: Robert Scales · https://guidetoartificialintelligence.com/fr/apprendre/serveurs-mcp-installer-en-securite/

**Answer:** Aucun serveur MCP n’est sûr par défaut : chacun est un programme qui tourne sur votre ordinateur et dont les descriptions d’outils sont lues par votre assistant d’IA. Les plus sûrs viennent d’une source que vous pouvez identifier, demandent l’accès le plus restreint, ont un code et des descriptions d’outils lisibles, et sont figés à une version que vous avez vérifiée.

Le Model Context Protocol (MCP) permet à des assistants comme Claude Desktop ou l’éditeur de code Cursor de se connecter à de petits programmes appelés **serveurs**, qui leur donnent de nouveaux outils : lire des fichiers, chercher dans une base de données, envoyer des courriels. Les serveurs de la communauté se sont multipliés depuis la présentation de MCP en novembre, et en installer un se résume souvent à une ligne dans un fichier de configuration. C’est justement cette facilité qui mérite qu’on prenne une pause.

Deux faits déterminent le risque. D’abord, un serveur MCP local est un programme qui tourne sur votre machine avec les permissions de votre compte d’utilisateur; il peut donc faire tout ce que pourrait faire un programme que vous avez téléchargé. Ensuite, votre assistant lit les **descriptions d’outils** de chaque serveur, le texte qui explique ce que fait chaque outil, et les traite comme des consignes. La spécification MCP publiée le 26 mars le dit clairement : les outils équivalent à l’exécution de code arbitraire, les descriptions du comportement des outils doivent être considérées comme non fiables à moins que le serveur ne soit digne de confiance, et l’application devrait obtenir votre consentement explicite avant l’exécution de tout outil. Le protocole lui-même ne peut pas imposer ces principes; c’est aux applications et à vous de le faire.

## Une liste de contrôle

Servez-vous-en avant d’ajouter un serveur. Le serveur de la dernière colonne est donné à titre d’exemple.

| Question | Ce qu’il faut regarder | Exemple : un serveur de « recherche dans les notes » |
|---|---|---|
| **Qui l’a créé?** | Une organisation que vous pouvez identifier : les serveurs de référence du projet MCP lui-même, ou le serveur officiel du service auquel il se connecte. Méfiez-vous des copies anonymes qui portent des noms populaires. | Publié par l’entreprise de l’application de notes, sur son propre compte GitHub |
| **Pouvez-vous le lire?** | Code source disponible, activité récente, un outil de suivi des problèmes où l’on répond aux signalements. | Petit code, lisible en 20 minutes |
| **À quoi touche-t-il?** | L’accès le plus restreint qui fait le travail. Un serveur de fichiers devrait recevoir un dossier, pas votre dossier personnel au complet. | Lecture seule, un dossier de notes |
| **Va-t-il en ligne?** | S’il n’a besoin que de données locales, il ne devrait faire aucun appel réseau. S’il le doit, vers quelles adresses? | Aucun appel réseau dans le code |
| **De quels secrets a-t-il besoin?** | Des clés d’API pour son propre service seulement, avec le niveau de permission le plus bas que vous pouvez créer. | Aucun |
| **Que disent ses outils?** | Lisez chaque description d’outil en entier. Des instructions destinées au modèle, ou des mentions d’autres outils ou fichiers, sont des signaux d’alarme. | Un outil, une phrase simple |
| **Quelle version?** | Installez une version précise que vous avez examinée, plutôt que la plus récente à chaque lancement. | Numéro de version fixé dans la configuration |

Ensuite, quelques habitudes. Ajoutez les serveurs un à la fois. Gardez les serveurs qui manipulent des données sensibles (courriel, finances, identifiants) hors de la même session d’assistant que les serveurs auxquels vous faites moins confiance. Laissez les demandes de confirmation activées, et lisez vraiment ce qu’un appel d’outil s’apprête à envoyer avant de l’approuver. Et souvenez-vous que le fichier de configuration lui-même peut contenir les clés de tous les serveurs que vous utilisez, ce qui en fait un butin qui vaut la peine d’être protégé.

> **À essayer :** ouvrez le fichier de configuration MCP de votre assistant et dressez la liste de tous les serveurs qu’il contient. Pour chacun, notez qui l’a créé, à quel dossier ou compte il a accès, et sa version. Retirez tout ce dont vous ne pouvez pas répondre.

## Vérifier vous-même les descriptions d’outils

La plupart des applications de clavardage affichent un court nom d’outil, pas la description complète que reçoit le modèle. Pour tout voir, connectez le serveur au **MCP Inspector**, l’outil de développement du projet MCP, et affichez la liste de ses outils : il montre en entier chaque description et chaque champ d’entrée. Cherchez surtout les longues descriptions pour des outils simples, des mots comme « important » ou « avant d’utiliser cet outil », et des champs d’entrée supplémentaires inattendus dont la tâche n’a pas besoin.

## Qu’est-ce que l’empoisonnement d’outils?

L’empoisonnement d’outils (*tool poisoning*) est le nom d’une attaque publiée le 1er avril par Invariant Labs, une entreprise de recherche en sécurité. Un serveur MCP malveillant cache des instructions dans une description d’outil. L’utilisateur voit un nom d’outil inoffensif; le modèle voit le texte complet et peut le suivre. C’est une forme d’**injection de prompt indirecte** : des instructions qui arrivent par les données que traite le modèle plutôt que par l’utilisateur.

Dans leur exemple, un outil qui prétend simplement additionner deux nombres porte une description qui demande au modèle de lire d’abord un fichier de configuration et la clé SSH privée de l’utilisateur (le fichier secret qui sert à se connecter à des serveurs), puis de transmettre leur contenu dans un champ d’entrée supplémentaire, tout en parlant d’arithmétique pour que l’utilisateur ne remarque rien. Lors d’un test avec Cursor, l’agent a bel et bien lu les fichiers et les a envoyés au serveur malveillant. La boîte de dialogue de confirmation n’affichait pas l’entrée complète; approuver l’appel n’a donc pas protégé l’utilisateur.

Les chercheurs décrivent deux variantes. Dans un **retournement** (*rug pull*), un serveur que vous avez approuvé modifie plus tard ses descriptions d’outils, si bien que votre examen précédent ne s’applique plus. Dans l’**occultation** (*shadowing*), la description d’un serveur malveillant change la façon dont le modèle utilise l’outil d’un *autre* serveur, digne de confiance; dans leur test, une instruction venant d’un faux outil d’addition a amené l’agent à envoyer chaque courriel à l’adresse de l’attaquant, quel que soit le destinataire demandé par l’utilisateur.

Les correctifs qu’ils proposent visent surtout les créateurs d’applications : montrer aux utilisateurs les descriptions d’outils complètes, figer les serveurs et les outils à des versions vérifiées au moyen d’une somme de contrôle (une empreinte qui change si le contenu change), et empêcher les serveurs de s’influencer les uns les autres. Tant que les applications ne le font pas, la liste de contrôle ci-dessus est votre protection : moins de serveurs, des sources connues, des versions fixes et des descriptions que vous avez lues vous-même.

## Sources

- MCP Security Notification: Tool Poisoning Attacks: https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks
- Model Context Protocol specification, version 2025-03-26 (overview): https://github.com/modelcontextprotocol/modelcontextprotocol/blob/c32bcaacd5514807c304064918097645a29dd1d2/docs/specification/2025-03-26/_index.md
- Quickstart (Model Context Protocol documentation): https://github.com/modelcontextprotocol/docs/blob/aeebcc279b27cef5c82a3dfc2d7f4e686a953fdc/quickstart.mdx