Serveur MCP: lequel brancher, à quelles conditions

Un serveur MCP, et les deux façons de le faire tourner

Un serveur MCP est un programme qui expose des capacités à une application d'IA. La documentation officielle le définit sans détour: le mot serveur désigne le programme qui fournit le contexte, quel que soit l'endroit où il tourne. Ce n'est donc pas forcément une machine distante, et c'est la première source de confusion.

Il expose trois choses. Des outils, qui sont des fonctions que le modèle peut appeler. Des ressources, qui sont des données à lire. Des invites, qui sont des gabarits de conversation. Côté client, une seule capacité subsiste dans la version actuelle: l'élicitation, qui permet au serveur de demander une information ou une confirmation à l'utilisateur.

Le choix qui structure tout le reste est celui du transport, et il n'y en a que deux.

Un serveur de fichiers lancé par ton client de bureau tourne en stdio sur ta machine. Un serveur d'observabilité opéré par l'éditeur du produit tourne en HTTP chez lui. Les deux s'appellent serveur MCP, ils n'ont pas le même modèle de menace, et confondre les deux est la première erreur de cadrage.

Où trouver ceux qui existent, et ce que ça ne garantit pas

Il existe un registre officiel, avec une politique de modération et des agrégateurs tiers qui le relaient. À côté, le dépôt modelcontextprotocol/servers héberge des implémentations de référence, dont le serveur de fichiers que la documentation cite en exemple. Et la plupart des éditeurs sérieux publient désormais le leur.

Voilà pour la disponibilité. Sur la confiance, il faut être clair: figurer dans un registre n'est pas un audit de sécurité. Un registre modéré écarte les cas grossiers, il ne vérifie pas ce que le code fait de tes données une fois lancé.

La documentation officielle va plus loin, et c'est la phrase qu'il faut retenir de tout cet article: les descriptions du comportement d'un outil, y compris ses annotations, doivent être considérées comme non fiables tant qu'elles ne viennent pas d'un serveur de confiance. Autrement dit, ce qu'un serveur raconte sur lui-même ne prouve rien. Le seul modèle qui tienne est celui de la dépendance logicielle: tu l'installes parce que tu fais confiance à qui la publie, pas parce que sa fiche est bien rédigée.

Les cinq questions à poser avant de brancher

Ces cinq points viennent des risques que la documentation de sécurité officielle décrit elle-même. Ce ne sont pas des précautions de principe, ce sont des attaques documentées avec leurs contre-mesures.

1. Le serveur tourne-t-il en local ? Un serveur local est un binaire téléchargé et exécuté sur ta machine, avec les privilèges de ton client. La documentation liste explicitement l'exfiltration de données et l'escalade de privilèges via une commande de démarrage malveillante. Un client correct doit t'afficher la commande exacte, sans troncature, avant de la lancer.
2. Quel est le périmètre réel des outils exposés ? Un outil est une exécution de code arbitraire. La liste se découvre avec tools/list, et elle peut changer en cours de route, le serveur pouvant notifier un changement. Ce qui était sûr hier n'est pas garanti sûr demain.
3. Qui a émis le jeton ? La spécification est catégorique: un serveur MCP ne doit accepter aucun jeton qui ne lui a pas été explicitement délivré. Un serveur qui repasse ton jeton à une API en aval sans valider son audience est un problème, pas une intégration.
4. Comment l'état est-il rattaché à l'utilisateur ? Le protocole est sans état, donc un serveur qui doit se souvenir de quelque chose émet une poignée que le client lui renvoie. La règle: la possession d'une poignée ne vaut pas authentification. Sans liaison serveur au compte, n'importe qui devinant une poignée agit à ta place.
5. Le serveur agit-il en mandataire vers un tiers ? C'est le cas le plus délicat, celui du député confus: un mandataire mal construit laisse récupérer un code d'autorisation sans consentement, en exploitant un cookie posé lors d'une session légitime.

Ces cinq questions se posent en dix minutes et elles éliminent la plupart des mauvaises surprises. Ce qu'elles n'éliminent pas, c'est le besoin d'une politique d'actions écrite: ce qui part automatiquement, ce qui demande une confirmation humaine, ce qui reste interdit. Un serveur bien choisi branché sans cette politique reste un système qui peut agir seul sur des données réelles.

Quels serveurs valent le branchement

Plutôt qu'un palmarès qui sera périmé dans trois mois, voilà les familles qui rendent service et le risque propre à chacune.

Le meilleur serveur MCP est donc celui dont tu connais l'éditeur, dont tu peux lire le code ou dont tu paies déjà le produit. Ces trois critères éliminent le gros du catalogue et c'est très bien: la valeur ne vient pas du nombre de serveurs branchés. Chaque outil supplémentaire occupe de la fenêtre de contexte, augmente la surface d'attaque et ajoute un chemin par lequel une réponse peut partir de travers.

En pratique, sur les projets qu'on livre, trois à cinq serveurs bien choisis couvrent tout ce qui compte. Au-delà, on observe surtout des agents qui hésitent entre des outils redondants.

Ce qui a changé au 28 juillet 2026

La version courante de la spécification porte la date du 28 juillet 2026, et elle déplace assez de choses pour que les tutoriels antérieurs induisent en erreur.

Le protocole est désormais sans état. Chaque requête transporte sa version et les capacités qui la concernent, donc le serveur n'infère rien des échanges précédents. Une requête server/discover obligatoire permet au client de connaître les versions et capacités acceptées avant tout le reste, avec des réponses qui peuvent être mises en cache.

Deux capacités côté client sont abandonnées: l'échantillonnage, qui permettait à un serveur de demander une complétion au client, et la journalisation. La documentation oriente vers une intégration directe aux API des fournisseurs pour la première, et vers stderr ou OpenTelemetry pour la seconde. Un serveur qui repose encore dessus est un serveur qui n'a pas suivi.

Les notifications de changement deviennent explicitement demandées: le client ouvre un flux et nomme les types d'événements qu'il veut recevoir. Rien n'arrive plus par défaut.

Si tu évalues un serveur aujourd'hui, la première question technique est donc simplement de savoir quelle version il annonce. C'est visible dès la découverte, et ça en dit long sur l'entretien du projet.