Formation Claude Code et Model Context Protocol

Le protocole MCP définit un cadre pour relier un hôte compatible à des serveurs qui exposent des capacités ou des informations.

Les rôles, primitives, transports et formats évoluent. La formation utilise la spécification et la documentation officielles actuelles plutôt qu’un inventaire figé de versions ou de fonctions.

La documentation anglaise distingue host, client et server. Le client maintient un échange JSON-RPC avec chaque serveur, qui publie des outils, des ressources ou des prompts. Les instructions fournies par le serveur restent du contenu non fiable tant qu’elles ne sont pas auditées.

Les serveurs MCP ne sont pas fiables par défaut. Leur source, leur éditeur, leurs dépendances, leurs permissions et leurs destinations sont examinés avant usage.

La compatibilité de ces connecteurs avec le terminal Anthropic ou un autre produit se vérifie dans la documentation officielle et avec la version réellement installée.

Partir d'une tâche précise et réversible, puis vérifier si des serveurs MCP sont réellement nécessaires.

Consulter le dépôt, la documentation et la licence officiels des serveurs retenus. Un annuaire communautaire n'est pas une preuve de sécurité ni de maintenance.

Commencer en lecture seule avec un compte de test, des contenus fictifs et les droits minimaux.

Placer les outils, ressources, chemins et destinations autorisés sur une liste blanche explicite.

Refuser par défaut le scraping, l'enrichissement, l'envoi de messages, les écritures en base et les déploiements.

Définir un propriétaire, des journaux, une limite d'usage et une procédure d'arrêt avant l'accès à un système réel.

La commande claude mcp add ajoute des connecteurs au terminal. Un processus local est lancé avec stdio, souvent via npx ; un service distant utilise de préférence HTTP. Toutes les options, dont --scope et --env, se placent avant le nom, puis -- sépare ce nom de la commande locale. Aucun secret n’est écrit en dur.

Le client prévoit trois portées : local reste privé au projet courant dans ~/.claude.json ; project écrit la configuration d’équipe dans .mcp.json et demande une approbation avant exécution ; user rend le réglage privé disponible dans tous les projets de la personne. claude mcp list affiche les serveurs configurés et leur état. Dans /mcp, on contrôle aussi l’authentification et les capacités annoncées.

Tool Search est activé par défaut dans les environnements compatibles : au démarrage, Claude Code charge les noms des outils et les instructions fournies par les serveurs, puis découvre leurs définitions à la demande. Les ressources et prompts restent consultables par les mécanismes documentés du client. Le comportement est vérifié avec la version et l’environnement réellement utilisés.

Les ateliers s’appuient sur des connecteurs officiels de code source, de messagerie et de navigateur. La version locale du serveur GitHub est lancée en lecture seule avec les toolsets utiles. Slack utilise un espace de test, l’approbation de l’administrateur et des autorisations de lecture sans chat:write. Le navigateur démarre avec npx @playwright/mcp@latest --isolated, sans extension ni état de connexion personnel.

Pour un processus local, --env KEY=value transmet une variable à la commande et conserve sa valeur dans la configuration générée : cette option ne masque rien, donc aucun secret littéral ne lui est passé. Dans un réglage partagé, le bloc env référence ${VAR} et la valeur vient de l’environnement du poste. Un plugin peut fournir une configuration prête à relire, mais pas contourner les permissions ni l’approbation.

La spécification MCP définit deux transports standards. Avec stdio, le client lance un processus local et réserve ses flux au protocole ; les journaux partent sur une sortie séparée. Pour un service distant, Streamable HTTP est le choix courant. L’ancien transport autonome HTTP+SSE est remplacé, mais Streamable HTTP peut encore utiliser SSE pour diffuser certaines réponses.

La documentation de Claude Code présente aussi WebSocket pour un service distant qui pousse des événements. Cette extension se configure avec type: "ws" dans .mcp.json ou avec claude mcp add-json : --transport ws n’existe pas. Elle utilise des en-têtes ou headersHelper, sans flux OAuth natif. HTTP reste préférable pour un échange classique requête-réponse.

La portée d’installation local, project ou user ne doit pas être confondue avec les autorisations OAuth demandées au service. Pour un serveur HTTP protégé par OAuth, l’authentification se termine dans /mcp ou avec claude mcp login <nom> ; le client conserve et renouvelle les jetons. Un service sans OAuth peut utiliser des en-têtes ou headersHelper. Une configuration partagée peut référencer ${VAR}, mais jamais contenir la valeur secrète.

Dans la CLI, --scope règle uniquement l’emplacement d’installation. Le périmètre OAuth décrit, lui, les droits demandés au fournisseur ; ce sont deux contrôles différents.

Le premier atelier GitHub relie le terminal à la version locale du serveur officiel, lancée en mode --read-only. L’outil consulte un ticket GitHub et ses commentaires, puis prépare une synthèse sans modifier le dépôt. Le groupe réduit les --toolsets et vérifie les permissions des jetons ou de l’authentification retenue.

Le deuxième atelier utilise Playwright MCP avec --isolated pour examiner une page locale de test. Ce mode efface l’état à la fermeture, mais ne limite pas à lui seul les URL ou le réseau accessibles : l’environnement d’exercice impose aussi ses propres restrictions. Aucune session personnelle, publication, achat ou envoi n’est autorisé.

Le troisième cas utilise le serveur officiel Slack, dont l’adresse figure dans les sources, ou son plugin pour Claude Code. L’atelier reste dans un espace de test approuvé et demande uniquement les autorisations de recherche et de lecture nécessaires. Les fonctions d’écriture restent exclues.

Enfin, les connecteurs internes interrogent une petite API de catalogue fictif avec des paramètres étroits. Les participants contrôlent les réponses invalides et comparent cet accès à un moteur web générique. Chaque outil doit répondre à un besoin précis sans élargir inutilement le périmètre du client.

Les jetons d’accès et autres secrets restent dans un coffre, un gestionnaire d'identifiants ou le mécanisme prévu par l'environnement. Ils ne figurent jamais dans un prompt, un exemple, un journal ou le dépôt Git.

Lorsqu’un champ de configuration exige un token, la valeur utilisée pour les essais reste limitée et révocable. Si elle expire ou est refusée, le message indique la cause sans la recopier.

Les entrées sont validées et limitées. Les chemins, requêtes et identifiants inattendus sont refusés avant l'appel au système cible.

Les sorties sont minimisées et filtrées selon les droits de l'utilisateur. Une page, un ticket ou un document récupéré peut contenir une injection indirecte de prompt : ses instructions sont traitées comme du contenu, jamais comme un ordre fiable.

Pour Streamable HTTP, le service valide l'en-tête Origin, authentifie chaque connexion et écoute sur 127.0.0.1 plutôt que 0.0.0.0 lorsqu'il reste local. Son code et ses destinations réseau sont examinés avant usage.

Toute action externe exige une confirmation humaine portant sur l'action, la destination et les éléments concernés.

Les appels d'écriture utilisent idempotence, déduplication, limites de fréquence et journal d'audit.

La rotation et la révocation des jetons sont testées avec des valeurs factices. Une revue de sécurité et un test de restauration précèdent l'activation sur des informations ou services réels.

À la racine du dépôt, le fichier .mcp.json décrit les connexions partagées et demande une approbation avant leur premier lancement. Ce fichier doit rester valide et lisible. Il peut référencer ${VAR}, mais pas contenir les valeurs sensibles ; chaque chemin local est contrôlé sur le poste concerné.

Après claude mcp add, on relit les configurations avec claude mcp get, claude mcp list et /mcp. Le diagnostic contrôle le répertoire de travail, la commande npx, l'exécutable, les arguments et les capacités annoncées.

Pour un processus local, une sortie parasite dans le canal du protocole peut casser l'échange. Pour un service distant, on vérifie l'URL, le certificat, l'authentification et les délais. Les erreurs observées doivent nommer la cause et le remède sans divulguer d'identifiant.

Lors d'une migration depuis l'ancien transport HTTP+SSE, on relève l’URL et les comportements de session avant de rejouer les mêmes tests avec Streamable HTTP.

L’ancienne route n’est retirée qu’après confirmation qu’aucun client ne l’utilise. Les deux mécanismes peuvent coexister pendant la transition ; Streamable HTTP conserve par ailleurs un mode de diffusion événementielle.

Les tests couvrent une session expirée, une permission refusée, une coupure réseau et un paramètre incomplet. Claude Desktop et Claude Code n'utilisent pas forcément les mêmes configurations : un connecteur visible dans l’application n'est importé dans le terminal que par une procédure explicite et documentée. Les portées local et user restent distinctes.

Au début d’une intervention Claude, claude mcp list donne l’état des serveurs connus. Pour chacun, l’équipe relève l’état de la connexion et la source attendue avant le premier appel.

claude mcp get <nom> détaille la configuration, la portée et l’état d’un serveur. Dans /mcp, le client vérifie aussi le nombre d’outils, les capacités chargées et les éventuelles demandes d’accès. Cette lecture évite d’élargir les droits pour résoudre un simple défaut d’installation.

Si un outil est superflu, claude mcp remove <nom> le retire. Une nouvelle connexion est ensuite ouverte avec des données fictives afin de confirmer que les erreurs précédentes ne masquaient pas un second problème.

Après un changement de branche ou d’équipe, claude mcp reset-project-choices permet de revoir les décisions d’approbation des serveurs partagés. Chaque choix est relu dans le contexte du dépôt de travail actuel.

Le même outil est testé sur un processus local stdio et un service distant fictif. L’équipe compare le flux, les paramètres et les messages observés sans contacter de ressource BGB. Dans les journaux, le libellé anglais server distingue le composant MCP du terminal Claude.

Le module de développement reste borné à une capacité de consultation sur un corpus fictif. Le formateur vérifie la documentation officielle actuelle, puis retient un seul SDK, Python ou TypeScript, pour l'exercice guidé.

Le groupe définit un schéma d'entrée étroit, une sortie minimale et des messages précis avec cause et remède. Il sépare l'accès au corpus de l'exposition MCP afin de tester chaque partie et l’interface API.

Avec le SDK retenu, chaque tool possède un name stable, une description courte et un schéma pour ses args. Le modèle refuse les args inconnus avant l’appel. Un exercice compare ensuite le même tool dans les SDK Python et TypeScript sans multiplier les dépendances : le code, les fichiers et le résultat attendu restent identiques.

Pour une API distante, l’en-tête Authorization reçoit un token limité depuis l’environnement. Ni Authorization ni le token ne sont écrits dans les fichiers du projet. Le guide d’essai montre comment renouveler ce token, vérifier le scope et retirer l’accès ; il ne contient aucune valeur réelle.

Le passage en production n’est pas inclus dans l’atelier. Avant toute production, le propriétaire doit revoir les tools exposés, leur name, leurs args, les journaux et le contexte transmis. Cette revue distingue aussi l’usage dans Claude Desktop de celui dans le terminal, car Desktop et le client de développement peuvent charger des configurations différentes.

Aucune base externe ni ressource de l'entreprise n'est connectée. Les essais couvrent les permissions, les entrées malformées, les délais, les doublons et les destinations interdites.

Le livrable est un prototype local relu avec sa configuration et ses droits documentés. La formation ne déploie pas de service distant et n'accorde aucune autonomie en production.

Chaque compétence est vérifiée dans une situation de travail simulée, sur un corpus et des données fictives. Le participant doit expliquer son choix avant de lancer une commande.

Il sait ajouter un serveur MCP dans le terminal Claude, puis connecter ce serveur à une tâche de lecture précise sans étendre le périmètre.

Il inspecte la solution avant d’autoriser son premier outil, puis compare deux implémentations qui exposent la même capacité afin de retenir celle qui demande le moins de droits.

Il sait retirer un accès devenu inutile et relire le résultat dans Claude. Sur un exercice GitHub, il conserve le mode lecture seule et justifie chaque capacité gardée.

Le compte rendu nomme l’option retenue, celle qui a été écartée et les accès désactivés. Le propriétaire du système valide cette décision.

La formation s'adresse à des développeurs qui utilisent déjà Claude Code. Il faut savoir lire du code, lancer des commandes dans un terminal et utiliser Git. Il n'est pas nécessaire d'avoir déjà écrit un serveur MCP.

Le parcours suit une structure simple, découpée en modules. Chaque module enchaîne un point de théorie court, une démonstration par le formateur, puis de la pratique. On avance étape par étape : concept MCP, connexion d'un premier serveur, puis écriture d'une capacité maison.

Les travaux pratiques reprennent des situations de développeurs dans un environnement simulé. Chaque atelier part d'un besoin concret. Chacun travaille sur son poste, avec un compte de test et des données fictives.

Le format et la durée sont confirmés dans la convention avant inscription. La gestion des droits reste stricte pendant les exercices : lecture seule d'abord, aucune connexion à un système réel de l'entreprise.

Côté financement, un plan de formation d'entreprise ou une prise en charge OPCO peut parfois s'appliquer, sous réserve d'éligibilité. Chaque situation se vérifie auprès de l'organisme concerné avant l'inscription. Cette page ne garantit aucune prise en charge.

Les serveurs MCP ne travaillent pas seuls. Dans Claude Code, ils s'ajoutent aux agents, aux skills et aux commandes lancées depuis le terminal. Ce module montre comment ces briques se combinent pour automatiser des tâches précises.

Un agent reçoit une mission et enchaîne les étapes. Il peut appeler un outil exposé par l'un des serveurs pour lire des documents, interroger une API ou récupérer une information utile. Un skill regroupe des instructions et un savoir-faire réutilisables pour un type de tâche. Les commandes déclenchent le tout depuis le terminal.

L'intégration se fait par couches. Ces serveurs donnent accès à une source ou à un système, l'agent décide de la suite et le skill cadre la méthode. Même principe que dans le reste de la formation : rien n'est fiable par défaut.

En atelier, on part de situations de travail simulées : trier des tickets, préparer une analyse, tester une page. Les connecteurs fournissent les éléments, l'agent propose, l'humain relit et confirme avant toute écriture. Les noms d'outils, d'options et d'API se vérifient dans la documentation officielle actuelle.

Un plugin peut regrouper des commandes, lancer un serveur local et déclarer des outils liés à une API. Avant la connexion, l’équipe vérifie ce que le plugin installe, qui le maintient et quelles actions il expose.

Avant d’installer le plugin, on lit sa source officielle, son répertoire d’installation, ses URL sortantes et la manière dont il reçoit un jeton d’accès ou une variable d’environnement. Sa présence dans Desktop ne prouve pas qu’il est actif dans le terminal.

Une mise à jour du plugin est rejouée sur un compte de test. Les erreurs, les paramètres et les changements de flux sont consignés avant de conserver la nouvelle version.

Le serveur MCP officiel de GitHub peut être utilisé localement ou à distance selon la procédure documentée, mais les permissions GitHub restent vérifiées séparément. Pour un atelier navigateur, Playwright conserve ses propres restrictions ; l’origine officielle ne suffit pas à rendre chaque appel API acceptable.

L’atelier compare un plugin maintenu à un second plugin volontairement ancien. La recherche porte sur une racine de travail et un répertoire fictif : aucune donnée personnelle n’entre dans le test, et l’outil de recherche reste en lecture seule.

Le projet fil rouge part d'un besoin de recherche documentaire : retrouver une information dans une racine autorisée, puis produire une réponse sourcée. Le prototype expose un seul outil nommé search, avec une requête courte et un nombre maximal de résultats. Il ne peut ni écrire, ni sortir du répertoire prévu, ni appeler une URL fournie librement.

L'équipe implémente ce prototype dans le langage retenu pour la session et l'ajoute avec claude mcp add. Il utilise stdio et reçoit une racine de test explicite. Le programme limite ses accès aux racines obtenues avec roots/list.

Dans une configuration partagée qui ne provient pas d’un plugin, ${CLAUDE_PROJECT_DIR:-.} fournit une valeur de repli. Un petit corpus factice sert à tester les accents, une demande vide et un répertoire absent.

Une seconde étape consiste uniquement à lire et comparer des exemples assainis pour Streamable HTTP, WebSocket et l'ancien transport HTTP+SSE. Aucun service distant, flux OAuth ou identifiant réel n'est créé pendant l'exercice.

Le bilan compare ce prototype aux connecteurs officiels vus plus haut. Le choix retenu doit répondre au besoin avec peu de permissions, de dépendances et de maintenance. La popularité d'un plugin ne remplace pas la validation du responsable du système connecté.