Accueil › Guides

Vérifier un serveur MCP avant de l'installer ou de l'acheter : la checklist pratique

Connecter un serveur MCP prend une minute. Réparer les dégâts d'un serveur mal choisi peut prendre bien plus longtemps. Un serveur Model Context Protocol n'est pas une simple bibliothèque : il donne à un agent IA des outils capables de lire des fichiers, d'appeler des API et d'agir sur vos comptes, et c'est l'agent qui décide quand s'en servir. Ce guide détaille les vérifications à faire avant d'installer un serveur communautaire ou de payer pour un serveur hébergé, quel que soit l'endroit où vous l'avez trouvé.

1. Pourquoi un serveur MCP mérite plus de vigilance qu'une dépendance classique

Avec un paquet ordinaire, c'est votre code qui décide quoi appeler et quand. Avec MCP, un modèle de langage lit la liste des outils exposés par le serveur et leurs descriptions, puis choisit lesquels appeler selon ce qu'il a sous les yeux : votre demande, une page web, un e-mail, un document. Le code du serveur s'exécute avec les accès que vous lui donnez, et le texte qu'il envoie au modèle (noms d'outils, descriptions, résultats) devient une partie de ses instructions.

Les analyses de sécurité, dont celles du GenAI Security Project de l'OWASP, regroupent les risques principaux de la même façon : permissions trop larges, descriptions d'outils piégées, outils modifiés après validation et secrets qui fuient.

2. Vérifier qui le publie et si le code est lisible

Un serveur officiel publié par l'éditeur de l'API qu'il utilise n'a pas le même profil de risque qu'un fork anonyme au nom presque identique. Les noms trompeurs sont une technique connue dans tous les écosystèmes de paquets.

• L'éditeur est-il identifiable, et la documentation officielle renvoie-t-elle vers ce dépôt ?
• Le code source est-il disponible, et le paquet publié correspond-il bien à ce dépôt ?
• Le projet est-il maintenu : commits récents, issues traitées, journal des modifications ?
• Pour un serveur hébergé fermé : y a-t-il une société identifiée, des conditions d'utilisation et une politique de confidentialité ?

3. Lire chaque description d'outil, pas seulement le README

Le README s'adresse à vous ; les descriptions d'outils s'adressent au modèle, et c'est là que se cache l'« empoisonnement d'outil » (tool poisoning) : des instructions cachées demandant par exemple au modèle de lire un fichier de configuration et d'en transmettre le contenu en paramètre. La plupart des clients MCP permettent d'afficher la liste des outils : lisez-les en entier.

Signaux d'alerte : descriptions bien plus longues que nécessaire, consignes adressées à « l'assistant », références aux outils d'autres serveurs, demandes de cacher quelque chose à l'utilisateur, paramètres sans rapport avec la fonction annoncée.

4. Cartographier ce à quoi il peut accéder

Notez, outil par outil, ce qu'il peut lire et ce qu'il peut modifier, puis comparez avec votre besoin réel.

• Privilégiez les outils en lecture seule et les jetons d'API à portée limitée.
• Donnez à chaque serveur ses propres identifiants, révocables séparément.
• Gardez les secrets dans des variables d'environnement ou un coffre, jamais dans un prompt.
• Activez la confirmation à chaque appel pour tout outil qui écrit, envoie, supprime ou paie.
• Méfiez-vous des combinaisons : un serveur qui lit du contenu non fiable (e-mails, web) et un autre qui peut envoyer des données vers l'extérieur forment la paire classique d'exfiltration.

5. Figer la version et surveiller les changements

Valider un serveur une fois ne garantit pas qu'il restera identique. Si votre configuration charge toujours la dernière version, une mise à jour peut modifier les outils après votre relecture (le « rug pull »). Figez une version ou un commit, relisez les différences avant de mettre à jour et, pour un serveur hébergé, demandez comment les changements sont annoncés.

6. Tester d'abord en bac à sable avec de fausses données

Avant de brancher un nouveau serveur sur vos vrais comptes, testez-le sur un espace jetable : dossier de test, clé d'API sandbox, boîte mail factice. Lancez quelques tâches réalistes, lisez les journaux et observez quels outils sont appelés, avec quels arguments. Un serveur local peut aussi tourner dans un conteneur sans accès réseau superflu.

7. Questions en plus pour les serveurs MCP payants

Quand vous payez un serveur MCP ou un service d'agent, vous confiez aussi vos données à son opérateur. Demandez où les requêtes sont traitées et journalisées, combien de temps les données sont conservées, quelles sont les limites d'usage et ce qui se passe en cas de panne.

Une place de marché peut encadrer l'achat. Sur Kiosq, par exemple, les vendeurs proposent agents IA, serveurs MCP et automatisations ; les services à la demande sont payés en USDC sur Polygon et placés sous séquestre, et la Garantie Kiosq permet à l'acheteur de valider le résultat, d'obtenir une retouche gratuite puis de demander un remboursement. Cela protège la transaction, pas votre système : les vérifications techniques ci-dessus restent nécessaires.

8. Checklist express : on connecte ou pas ?

Si vous répondez oui à tout, vous en avez fait plus que la plupart des utilisateurs avant de cliquer sur « connecter ».

• Je sais qui publie le serveur, et le code ou la société sont vérifiables.
• J'ai lu toutes les descriptions d'outils sans rien trouver de suspect.
• Chaque outil n'accède qu'au strict nécessaire, avec des identifiants révocables.
• La version est figée, ou je sais comment les changements sont annoncés.
• Je l'ai testé avec de fausses données et les journaux sont conformes.
• Les actions d'écriture, d'envoi, de suppression et de paiement demandent ma confirmation.