Introduction au MCP pour les Développeurs

Pourquoi le MCP change la donne pour les développeurs

Le Model Context Protocol (MCP) est un standard ouvert qui redéfinit la façon dont les applications d’intelligence artificielle interagissent avec le monde extérieur. Avant lui, chaque framework imposait sa propre grammaire pour déclarer un outil et l’appeler : LangChain avait la sienne, CrewAI une autre, les Mistral Agents et les OpenAI Assistants encore d’autres. Concrètement, un développeur qui avait écrit un connecteur vers son API de facturation pour LangChain devait le réécrire intégralement pour le rendre utilisable dans CrewAI, puis une troisième fois pour un agent maison. Le travail se dupliquait à chaque changement d’outillage, et partager un outil entre équipes relevait du bricolage.

MCP répond à ce problème par un protocole de communication unifié entre un client IA et des serveurs d’outils. L’image la plus parlante est celle de la prise USB : peu importe le client — Claude, Le Chat, Cursor, VS Code — et peu importe le serveur — GitHub, Notion, votre API interne — le format du branchement reste identique. Vous écrivez votre connecteur une fois, et il fonctionne partout.

L’architecture client-serveur

Le MCP repose sur une architecture client-serveur volontairement simple. D’un côté, le client est l’application qui met en œuvre l’IA : un chatbot comme Le Chat de Mistral ou Claude, un environnement de développement comme VS Code ou Cursor, ou encore un SDK d’agents tel que le Mistral Agent SDK ou le Claude Agent SDK. De l’autre, le serveur est le programme qui expose des capacités — tools, resources et prompts — à ce client.

Toute la conversation entre les deux se déroule en JSON. Le client commence par demander au serveur quels outils il propose ; le serveur répond par une description textuelle de chacun : son nom, ses paramètres, son rôle, le format de son retour. C’est cette description, et elle seule, que le modèle de langage exploite ensuite pour décider quand et comment appeler un outil.

Client (Le Chat)              Serveur MCP (GitHub)
      |                              |
      |--- "Quels outils as-tu ?" -->|
      |<-- Description JSON tools ---|
      |                              |
      |--- Appel: create_issue({}) ->|
      |<-- Résultat JSON ------------|

Ce qui distingue MCP du function calling

Le function calling classique et MCP ne s’excluent pas ; ils placent simplement la frontière ailleurs. Avec le function calling, vous définissez les outils côté client, vous les transmettez au modèle et vous gérez vous-même leur exécution — chaque framework ayant son propre format de définition. Avec MCP, les outils vivent sur un serveur, local ou distant ; le client n’en connaît que la description textuelle, et l’exécution incombe au serveur.

L’avantage décisif tient dans la réutilisabilité. Un serveur MCP GitHub écrit une fois se branche indifféremment sur Le Chat, Claude, Cursor ou votre propre SDK, sans une ligne de réécriture. C’est ce qui transforme un connecteur interne en brique partageable à l’échelle d’une entreprise.

Les trois primitives du protocole

MCP ne se limite pas aux outils. Le protocole définit trois types de capacités, et ce qui les sépare tient à ce que le serveur met réellement à disposition. Les tools sont des fonctions exécutables : créer un ticket, envoyer un email, requêter une API — le modèle les déclenche pour agir sur le monde. Les resources sont des données consultables — fichiers, bases de données, documentation — que le client peut lire sans rien provoquer ; exposer le contenu d’un fichier de configuration relève de cette catégorie, pas des tools. Les prompts, enfin, sont des templates de prompts réutilisables avec paramètres : un serveur d’équipe peut ainsi diffuser une instruction de revue de code éprouvée, plutôt que de laisser chacun la réécrire de mémoire.

Dans les faits, les tools concentrent environ 90 % des usages actuels : ce sont eux que l’on branche en premier, et souvent les seuls que l’on implémente. Les resources et les prompts ouvrent néanmoins des possibilités que nous explorerons en détail à la leçon 3.

Le flux de décision du modèle

Lorsqu’un utilisateur pose une question au client, le modèle déroule un cycle en cinq temps :

1. Il reçoit la question et la liste des outils disponibles (descriptions MCP)
2. Il décide : répondre directement, ou appeler un outil ?
3. S’il appelle un outil, il formule les arguments en JSON
4. Le serveur exécute et retourne le résultat
5. Le modèle intègre le résultat et formule sa réponse (ou appelle un autre outil)

Ce cycle se répète autant de fois que la tâche l’exige. Imaginez un utilisateur qui demande de transformer une plainte repérée sur Reddit en ticket de développement : le modèle interroge Reddit, crée une entrée dans Linear, puis ouvre l’issue GitHub correspondante — trois serveurs enchaînés, sans que l’utilisateur quitte l’interface de chat.

Un écosystème en pleine expansion

En avril 2026, des centaines de serveurs MCP sont disponibles : GitHub, Notion, Slack, Gmail, PayPal, Hugging Face, Semgrep, et bien d’autres. Les principaux clients IA supportent le protocole nativement. Surtout, rien ne vous limite à consommer l’existant : vous pouvez créer vos propres serveurs pour exposer vos outils internes, vos bases métier ou vos procédures maison.

C’est précisément l’objet de ce cours : vous rendre capable de comprendre, d’utiliser et de construire des serveurs MCP en Python.

Points clés à retenir

• MCP est un standard ouvert de communication client-serveur pour l’IA
• Il unifie l’écosystème fragmenté du function calling
• L’architecture repose sur un client (chatbot, IDE, SDK) et un serveur (outils, resources, prompts)
• La communication se fait en JSON avec des descriptions textuelles
• Un serveur MCP est réutilisable sur tous les clients compatibles