Formation Claude Code et Model Context Protocol

Le Model Context Protocol (MCP) définit un cadre pour relier un hôte compatible à des serveurs qui exposent des capacités ou des données.

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

Un serveur MCP n'est pas fiable par défaut. Son code, son éditeur, ses dépendances, ses permissions et ses destinations sont examinés avant connexion.

La compatibilité avec Claude Code ou un autre client se vérifie dans la documentation officielle du produit et avec la version réellement installée.

Partir d'une tâche précise et réversible, puis vérifier si un serveur MCP est nécessaire.

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

Commencer en lecture seule avec un compte de test, des données fictives 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 connexion d'un serveur MCP à Claude Code passe par la commande claude mcp add : transport stdio pour un serveur local lancé en sous-processus (souvent via npx), SSE ou HTTP pour un serveur distant — l'authentification passe alors par OAuth ou par token. Le drapeau --scope fixe la portée (local, project, user), l'option --env transmet les variables d'environnement (jetons, URL) — jamais en dur dans le code.

Trois portées de configuration : locale (votre machine), projet — le fichier .mcp.json à la racine du dépôt, versionné avec le code pour toute l'équipe — et utilisateur. claude mcp list affiche les serveurs connectés, et Claude Code liste au démarrage de la session chaque outil exposé — nom, description, contenu attendu — par serveur.

Exemples travaillés en atelier : le serveur GitHub MCP en lecture pour trier les tickets ; un serveur filesystem borné aux fichiers d'un répertoire de travail précis ; le serveur Playwright (npx @playwright/mcp) qui donne à l'agent un navigateur web pour tester une page ; un serveur Slack limité à un canal autorisé. Mode lecture seule d'abord, paramètres élargis ensuite — ou pas. Claude Desktop et claude.ai partagent le même standard de connecteurs : un server MCP écrit une fois sert tous les clients, et la console Anthropic centralise les accès API.

Les 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 un fichier suivi par Git.

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. Un serveur local peut toujours transmettre des données à une destination externe selon son code.

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

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

Une revue de sécurité et un test de restauration précèdent l'activation sur des données ou services réels.

Choisir un SDK et des exemples depuis la documentation officielle actuelle du projet MCP. Les noms de paquets et API sont vérifiés au moment de l'atelier.

Définir un schéma d'entrée étroit, des erreurs explicites — cause et remède — et une sortie minimale pour chaque capacité de l'API exposée.

Séparer authentification, logique métier et exposition MCP afin de pouvoir tester chaque couche.

Utiliser des données fictives, des doubles de test et un service cible isolé avant toute connexion réelle.

Tester les permissions, entrées malformées, délais, reprises, doublons et destinations interdites.

Versionner la configuration, documenter les droits et soumettre le déploiement à une revue humaine.

La formation s'adresse à des développeurs qui utilisent déjà Claude Code. Le niveau attendu reste raisonnable : lire du code, lancer des commandes dans un terminal, connaître Git. Pas besoin d'avoir écrit un serveur MCP avant.

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 portent sur des cas réels de développeurs. Chaque atelier part d'un besoin concret. Chacun travaille sur son poste, avec un compte de test et des fichiers fictifs.

La formation se donne en ligne, à distance. 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.

Un serveur MCP ne travaille pas seul. Dans Claude Code, il s'ajoute 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 un serveur MCP pour lire des fichiers, interroger une API ou récupérer du contexte. Une skill regroupe des instructions et un savoir-faire réutilisables pour un type de tâche. Les commandes, elles, déclenchent le tout depuis le terminal.

L'intégration se fait par couches. Le serveur MCP donne l'accès aux données ou au système, l'agent décide de la suite, la 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 tâches réelles de développeurs : trier des tickets, préparer une analyse de code, tester une page. Le serveur MCP fournit le contexte, 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.