Serveurs MCP : intégration et écosystème

Comment connecter un serveur MCP à Claude et Claude Code, réutiliser les serveurs existants, et sécuriser le tout : transports distants, authentification et bonnes pratiques.

Dans le premier article, nous avons posé les bases du Model Context Protocol ; dans le deuxième, nous avons construit un serveur de A à Z. Reste la question qui transforme un prototype en outil du quotidien : comment intégrer un serveur MCP dans son environnement de travail, en réutilisant l’écosystème existant, sans ouvrir une faille de sécurité ? C’est l’objet de ce dernier article.

I. Connecter un serveur à Claude et Claude Code  

Dans le tutoriel, nous avons branché notre serveur à Claude Desktop via claude_desktop_config.json. Claude Code, l’assistant en ligne de commande, offre une approche encore plus directe avec la sous-commande claude mcp :

# Ajouter un serveur local (tout ce qui suit « -- » est la commande à lancer)
claude mcp add gestionnaire-taches -- python /chemin/absolu/vers/server.py

# Lister les serveurs configurés
claude mcp list

L’intégration peut être enregistrée à différentes portées : seulement pour vous, partagée avec l’équipe via un fichier .mcp.json versionné dans le dépôt, ou globale à votre machine. Versionner la configuration au niveau du projet est particulièrement pratique : chaque membre de l’équipe dispose des mêmes serveurs dès le git clone.

II. Réutiliser l’écosystème : les serveurs prêts à l’emploi  

L’un des grands intérêts d’un standard, c’est de ne pas réinventer la roue. Avant d’écrire un serveur, vérifiez s’il existe déjà. La communauté et les éditeurs en publient des dizaines :

Installer un serveur existant suit la même logique que notre serveur maison : une commande à lancer, déclarée dans la configuration de l’hôte. En quelques minutes, un assistant peut ainsi lire votre dépôt, interroger une base ou récupérer une page web — sans une ligne de code de votre part.

III. Du local au distant : les transports  

Jusqu’ici, nos serveurs tournaient en local et communiquaient via stdio (entrée/sortie standard). C’est parfait pour un outil personnel sur votre machine, mais cela ne permet pas de partager un serveur entre plusieurs utilisateurs ou de l’héberger.

Pour cela, MCP définit un transport distant, basé sur HTTP. Le serveur devient alors un service accessible par le réseau, auquel plusieurs hôtes peuvent se connecter.

Le passage au distant change la donne : on quitte le périmètre rassurant de sa propre machine pour exposer des capacités sur le réseau. D’où les deux sections suivantes.

IV. Authentification et autorisation  

Tant qu’un serveur tourne en local, l’utilisateur est le périmètre de sécurité. Dès qu’il est distant, il faut répondre à deux questions : qui se connecte ? (authentification) et a-t-il le droit de faire cette action ? (autorisation).

La spécification MCP s’appuie sur OAuth pour les serveurs distants. Concrètement :

• L’hôte ne stocke pas vos identifiants ; il obtient un jeton d’accès à portée limitée.
• Ce jeton n’autorise que certaines actions (principe du moindre privilège).
• Il peut expirer et être révoqué sans changer votre mot de passe.

Le réflexe à retenir : un serveur distant ne doit jamais accorder plus de droits que ce dont la tâche a réellement besoin.

V. Sécurité : les risques et comment s’en prémunir  

Donner des outils à un modèle, c’est puissant — et donc risqué. Les principaux pièges :

• Injection de prompt indirecte : une donnée lue par le modèle (un ticket, une page web) peut contenir des instructions cachées qui le détournent. Ne faites jamais aveuglément confiance au contenu rapporté par un outil.
• Serveurs non fiables : installer un serveur MCP, c’est exécuter du code tiers. Vérifiez la source, lisez la description des outils, épinglez une version.
• Permissions trop larges : un serveur qui a accès à tout devient une cible de choix. Limitez la portée (lecture seule quand c’est possible, accès restreint à un dossier ou une base).
• Fuite de jetons : un jeton d’accès volé donne les mêmes droits que vous. Stockez-les de façon sécurisée, faites-les expirer.

La meilleure défense reste l’humain dans la boucle : la plupart des hôtes demandent une confirmation avant d’exécuter un outil qui modifie l’état du monde. Gardez ce garde-fou actif.

VI. Bonnes pratiques d’intégration  

Pour finir, une liste de réflexes qui font la différence en production :

• Auditez avant d’installer. Traitez un serveur MCP comme n’importe quelle dépendance : source connue, version épinglée, mises à jour suivies.
• Appliquez le moindre privilège. Chaque serveur ne reçoit que les accès strictement nécessaires.
• Isolez ce qui est sensible. Faites tourner les serveurs à risque dans un environnement cloisonné (conteneur, utilisateur dédié).
• Préférez la lecture seule quand la tâche ne nécessite pas d’écrire.
• Gardez la confirmation utilisateur pour toute action irréversible.
• Documentez vos serveurs comme une API : c’est ce que le modèle et vos collègues liront.

Conclusion  

Ce troisième article clôt la série : comprendre MCP, construire un serveur, puis l’intégrer proprement dans un écosystème. La promesse du protocole — un connecteur universel entre les modèles et le monde réel — ne tient que si l’on garde en tête que chaque capacité ajoutée est aussi une surface d’attaque. Bien conçu, sécurisé et réutilisé intelligemment, un serveur MCP transforme un simple modèle de langage en véritable assistant opérationnel.

À vous de jouer : commencez par brancher un serveur existant, observez le modèle s’en servir, puis construisez le vôtre.

Useful links  

• Serveurs de référence MCP
• Utiliser MCP avec Claude Code
• Spécification : autorisation (OAuth)
• Bonnes pratiques de sécurité MCP