Brancher avant de construire
Réflexe d'ingénieur mal placé : « il me faut un accès aux notes de réunion, je vais coder un serveur ». Mauvais premier mouvement. L'écosystème MCP compte des milliers de serveurs publiés — systèmes de fichiers, bases de données, dépôts Git, messageries, navigateurs, CRM — et pour un besoin standard, il existe presque toujours une main déjà fabriquée, testée par des milliers d'utilisateurs, maintenue par un éditeur ou une communauté active.
Construire reste légitime — c'est tout l'objet de l'étape 7 — mais pour un cas précis : quand la main doit épouser votre système à vous (votre API interne, votre base métier, vos règles). Pour tout le reste, brancher l'existant coûte dix minutes là où construire coûte des jours, maintenance comprise.
Dix minutes, donc — mais pas n'importe lesquelles. Vous avez retenu de l'étape 4 qu'adopter une skill tierce sans la lire, c'est exécuter du non-audité. Brancher un serveur, c'est un cran plus engageant : la skill influence ce que le modèle dit, le serveur détermine ce qu'il peut faire. D'où un ritual — quatre temps, dix minutes bien investies :
① Choisir : la provenance avant les fonctionnalités
Trois vérifications, dans l'esprit exact de la checklist de l'étape 4 — un serveur s'audite comme une skill, avec un cran d'exigence en plus :
La provenance est engageante. Le serveur officiel d'un éditeur (celui du service que vous ciblez), le dépôt de référence d'une organisation identifiée, ou un projet communautaire dont le mainteneur est connu et actif. Le signal qui doit faire fuir : le fork anonyme d'un serveur populaire « avec deux améliorations » — c'est le canal de distribution préféré des versions piégées.
La maintenance est vivante. Derniers commits récents, issues traitées, compatibilité suivie avec les évolutions du protocole. Un serveur figé depuis dix mois dans un écosystème qui bouge chaque trimestre, c'est de la dette au branchement.
La version se fige. Vous adoptez une version précise — un tag, un commit — jamais « la dernière ». La raison est celle de la dérive de version vue à l'étape 4 : la confiance accordée aujourd'hui ne vaut pas procuration pour ce que le dépôt publiera demain.
② Inspecter : lire les tools comme des permissions
Le temps le plus important du ritual, et le plus négligé. Avant de brancher, ouvrez la documentation du serveur et lisez la liste de ses tools — pas ses promesses marketing, sa liste de tools. C'est l'équivalent exact de l'écran de permissions d'une application mobile : personne n'installe une app lampe-torche qui demande accès aux contacts et au micro ; le même bon sens s'applique ici, tool par tool.
La grille de lecture :
Chaque tool se justifie par votre besoin. Vous voulez lire des notes de réunion ; le serveur expose get_notes, search_notes — cohérent — mais aussi delete_notebook et share_externally ? Chaque tool que vous n'utiliserez pas est du privilège accordé pour rien : de la surface d'attaque gratuite. Certains hôtes permettent de n'activer qu'une partie des tools d'un serveur — quand c'est possible, faites-le ; sinon, le nombre de tools superflus pèse dans le choix du serveur lui-même.
Lecture et écriture ne se valent pas. Un serveur tout-lecture est une main qui regarde ; un serveur avec écriture est une main qui agit. Repérez chaque tool à effet de bord (créer, modifier, supprimer, envoyer) et demandez-vous, pour chacun : suis-je à l'aise à l'idée que le modèle puisse déclencher ça sur la foi de son raisonnement ? Vous vous souvenez du temps ④ de l'étape 5 : ce que le modèle lit peut l'influencer. Un tool d'écriture, c'est le maillon qui transforme une influence en action.
Le périmètre se restreint à la source. Le meilleur contrôle d'accès est celui configuré dans le système cible, pas espéré du serveur : un token qui ne voit que le carnet « Réunions », un compte PostgreSQL en lecture seule sur un seul schéma, un accès Git limité à un dépôt. Si le serveur tombe ou déraille, il ne peut pas faire plus que ce que son identifiant permet — c'est le moindre privilège appliqué là où il est incontournable.
③ Configurer : quatre lignes qui disent tout
La configuration d'un serveur local tient en quelques lignes dans le fichier de votre application hôte. Les voici, commentées — c'est le même vocabulaire chez tous les hôtes, aux détails de syntaxe près :
{
"mcpServers": {
"notes-reunion": {
"command": "npx",
"args": ["-y", "@editeur/serveur-notes@1.4.2"],
"env": {
"NOTES_API_TOKEN": "${NOTES_API_TOKEN}"
}
}
}
}Ligne par ligne :
"notes-reunion"— le nom local du serveur, celui que vous verrez dans les journaux et les demandes d'autorisation. Nommez clairement : dans six mois, « serveur3 » ne dira plus rien à personne."command"+"args"— ce qui sera exécuté sur votre machine au démarrage de l'hôte. Relisez cette ligne avec les yeux de l'étape 4 : c'est du code qui tourne chez vous. Notez le@1.4.2— la version figée du temps ①, inscrite dans la configuration même."env"— les secrets, transmis au serveur par variable d'environnement. Le serveur les détient, le modèle ne les voit jamais (temps ③ de la séquence, étape 5). Jamais de token en clair dans un fichier de configuration qui finira dans un dépôt Git ou une capture d'écran — la référence${...}pointe vers votre environnement.
Un serveur distant se configure différemment — une URL et une authentification, typiquement OAuth — mais la logique d'inspection est identique : mêmes tools, mêmes questions.
L'arbitrage local vs distant
Vous l'avez vu passer à l'étape 5 côté transports (stdio vs HTTP) ; le voici côté décision :
La règle de poche tient en une ligne : ce qui touche votre poste reste local, ce qui touche l'équipe se mutualise en distant — parce qu'un secret d'équipe copié sur vingt postes n'est plus un secret, et qu'une mise à jour à faire vingt fois n'est jamais faite vingt fois.
④ Tester : la première poignée de main
Le serveur est configuré, l'hôte redémarré. Trois vérifications avant l'usage réel :
La découverte dit la vérité. À la connexion, l'hôte affiche les tools découverts (le tools/list de l'étape 5). Comparez avec la liste inspectée au temps ② : c'est ce qui apparaît ici qui fait foi, pas la documentation. Un tool présent qui n'était pas documenté est un signal d'arrêt immédiat.
Le premier essai est en lecture. Demandez au modèle quelque chose d'inoffensif et de vérifiable — « liste les titres de mes notes de cette semaine ». Vous validez d'un coup la chaîne complète : connexion, authentification, périmètre du token, format des résultats.
L'observation précède l'élargissement. Utilisez le serveur quelques jours sur son périmètre restreint et regardez les demandes d'autorisation passer : les hôtes sérieux demandent confirmation avant les appels — au minimum les appels à effet de bord — et cette friction est une fonctionnalité. Le confort d'auto-approuver viendra bien assez tôt ; qu'il vienne après la confiance, pas avant. Et gardez le réflexe de l'étape 5 en tête : un serveur dont la liste de tools évolue en cours de session mérite une conversation avant de continuer.
📚Pour aller plus loin
Pour les geeks : l'hygiène des secrets, en pratique. Quatre règles qui évitent 90 % des fuites. Un secret par périmètre : le token du serveur notes ne sert qu'au serveur notes — mutualiser un token « à tout faire » entre serveurs, c'est garantir que la compromission d'un seul expose tout. Le fichier de configuration est un document sensible : s'il référence des variables, très bien ; s'il contient un token en clair, il est en chmod 600, exclu du dépôt Git, et absent des captures d'écran de vos tickets de support — les trois canaux de fuite les plus bêtes et les plus fréquents. La rotation est planifiée : un token de serveur MCP se régénère comme un mot de passe de service, à échéance fixe et immédiatement après tout doute. La révocation est testée : le jour où vous débranchez un serveur, son token est révoqué dans la foulée côté système cible — un serveur retiré dont l'identifiant survit est une porte dérobée en sommeil. Vous reconnaissez la logique : c'est la gestion des comptes de service d'un SI classique, appliquée aux mains du modèle.
📚Pour aller plus loin
Pour les geeks : le piège du lanceur de paquets. La configuration type utilise un lanceur (npx, uvx et équivalents) qui télécharge et exécute le paquet du serveur. Commodité réelle, mais mesurez ce que dit vraiment la ligne : à chaque démarrage, du code est récupéré depuis un registre public et exécuté sur votre machine. Trois conséquences pratiques. Épinglez toujours la version dans la commande (@1.4.2) : sans elle, le lanceur peut résoudre « la dernière », et votre temps ① n'a servi à rien — c'est l'équivalent local de la branche mouvante interdite à l'étape 4. Préférez l'installation locale pour les serveurs critiques : un paquet installé, versionné et vérifié une fois vaut mieux qu'une résolution réseau à chaque lancement — et fonctionne encore quand le registre est indisponible. Traitez le registre comme un fournisseur : le typosquatting (un caractère de différence dans le nom du paquet) est une voie d'attaque documentée et active ; copiez les noms depuis la source officielle, jamais de mémoire. Le paquet d'un serveur MCP mérite le niveau de méfiance d'une dépendance de production — parce que c'en est une.
📍 Parcours Skills & MCP — étape 6/9
- 🗺️ La carte avant le territoire
- 🔬 Anatomie d'une skill
- 🛠️ Créer sa première skill
- 🏛️ Skills en entreprise : gouvernance
- 🔌 MCP : le protocole expliqué
- ⚡ Utiliser un serveur MCP existant ← vous êtes ici
- ⚙️ Créer son serveur MCP minimal
- 🛡️ Sécuriser ses MCP
- 📡 L'écosystème : où trouver, où ça bouge
Prochaine étape → Créer son serveur MCP minimal : le moment que les geeks attendent — les deux tools du fil rouge en quelques dizaines de lignes commentées, et la boucle skill + MCP qui se ferme enfin.
Pour explorer l'écosystème des serveurs en attendant : notre fiche 40 outils Claude & MCP, stars GitHub en direct.