Protocole de contexte modèle (MCP) : Connexion entre IA et outils

Dernière mise à jour : June 28, 2026

MCP — le Model Context Protocol — est un standard ouvert qu'Anthropic a publié fin 2024 pour connecter les assistants et agents IA aux sources de données et outils externes. Au lieu d'écrire une intégration sur mesure pour chaque modèle et chaque outil, vous exposez un serveur MCP unique et tout client compatible MCP peut l'utiliser. J'ai connecté un serveur de système de fichiers et un serveur GitHub à Claude Code la semaine dernière et la différence dans ce que l'agent pouvait réellement faire a été immédiate. Cet article couvre ce qu'est MCP, comment fonctionne le modèle client-serveur, les types de capacités fondamentales, et comment exécuter des serveurs dans votre propre configuration.

Réponse rapide : qu'est-ce que MCP ?

MCP est un protocole basé sur JSON-RPC 2.0 qui standardise la connexion entre une application hôte IA (le client MCP, comme Claude Desktop ou Claude Code) et les serveurs externes qui exposent des données et des actions. Un seul serveur MCP peut faire connaître trois types de capacités aux clients :

• Tools — fonctions que le modèle peut appeler (interroger une base de données, envoyer un message, rechercher dans un dépôt).
• Resources — données structurées que le modèle peut lire (contenu de fichiers, réponses API, enregistrements).
• Prompts — modèles de prompts réutilisables et paramétrés que l'utilisateur peut invoquer.

L'objectif est un « USB-C pour les intégrations IA » : un serveur, de nombreux clients, pas de colle spécifique à chaque modèle. La spécification et les SDK sont open source et maintenus sur modelcontextprotocol sur GitHub, avec la documentation canonique à modelcontextprotocol.io.

Pourquoi MCP existe-t-il ?

Avant MCP, chaque intégration d'outil était un cas isolé. Si vous vouliez qu'un assistant lise vos problèmes GitHub et interroge également Postgres, vous écriviez deux connecteurs personnalisés, puis vous les réécriviez lorsque vous changeiez de modèle ou d'hôte. La motivation déclarée d'Anthropic est de mettre fin à cette duplication avec un protocole partagé — les docs officiels le décrivent comme donnant aux modèles un « accès standardisé » aux fichiers locaux, bases de données et API.

Ce cadrage est important pour les flux de travail agentiques en particulier. Un agent qui ne fait que discuter est un chatbot ; un agent capable de lire votre dépôt, d'exécuter une requête et d'appeler un outil en boucle est un véritable travailleur. MCP est la plomberie qui rend le second portable. Si vous souhaitez avoir une vue d'ensemble de l'endroit où cela s'inscrit dans la conception des agents, consultez notre article sur l'automatisation des agents IA.

Comment fonctionne le modèle client-serveur ?

MCP suit une topologie hôte-client-serveur :

• Host — l'application que l'utilisateur exécute (Claude Desktop, Claude Code, une extension IDE).
• Client — réside à l'intérieur de l'hôte, maintient une session 1:1 avec un serveur.
• Server — un processus qui expose des capacités via un transport.

Un hôte peut exécuter plusieurs clients, chacun parlant à un seul serveur. Le protocole est JSON-RPC 2.0, avec trois phases de cycle de vie que je teste chaque fois que j'ajoute un nouveau serveur :

1. Initialize — le client envoie la version du protocole, les capacités et les informations du client ; le serveur répond avec les siennes.
2. Capability negotiation — les deux parties déclarent ce qu'elles prennent en charge (outils, ressources, prompts, échantillonnage, racines).
3. Operation — le client demande des listes d'outils, invoque des outils, lit des ressources, et le serveur renvoie les résultats en flux.

Options de transport

stdio est le défaut pour la configuration locale et c'est ce que claude mcp add utilise sauf si vous passez une URL HTTP. Pour un guide plus approfondi sur claude mcp add et la décision stdio vs HTTP, consultez notre guide d'intégration MCP de Claude Code.

Quels sont les trois types de capacités, en pratique ?

La majeure partie de la valeur de MCP réside dans les trois types de capacités. Voici comment chacun se comporte réellement lorsqu'un modèle l'utilise.

Tools (appelé par le modèle)

Les outils sont le moteur. Le modèle décide de les appeler en fonction de la conversation. J'ai exécuté un serveur exposant un outil search_logs et le modèle l'a appelé sans prompt au moment même où j'ai demandé « pourquoi le déploiement a-t-il échoué à 2h du matin ? » Les définitions d'outils incluent un JSON Schema pour les arguments, de sorte que le modèle reçoit des entrées typées et validées.

Resources (contrôlé par l'application)

Les ressources sont adressées par URI et sont généralement sélectionnées par l'utilisateur, et non par le modèle — l'utilisateur attache une ressource comme un fichier ou un enregistrement, et l'hôte l'injecte dans le contexte. Cela est important pour le contrôle du périmètre : le modèle ne peut voir que ce que vous lui transmettez explicitement.

Prompts (invoqué par l'utilisateur)

Les prompts sont des modèles avec des arguments qui apparaissent dans l'interface utilisateur de l'hôte sous forme de commandes slash ou d'éléments de menu. C'est la capacité la moins utilisée — je les utilise pour encoder « réviser cette PR par rapport à notre guide de style » afin de ne pas avoir à coller les mêmes instructions chaque fois.

Comment configurer un serveur MCP ?

Configuration concrète, en utilisant Claude Code comme hôte. La même configuration de serveur fonctionne dans le fichier JSON de Claude Desktop.

1. Installer Node.js 20+ (ou Python 3.10+ avec uv).
2. Ajouter un serveur de référence, par exemple le serveur de système de fichiers : npx -y @modelcontextprotocol/server-filesystem /Users/you/projects
3. L'enregistrer dans Claude Code : claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /Users/you/projects
4. Vérifier la connexion : claude mcp list puis claude mcp get filesystem
5. Redémarrer l'hôte et chercher les outils du serveur dans la session.

C'est tout le cycle. Les serveurs de référence dans l'org GitHub couvrent le système de fichiers, Git, GitHub, Postgres, SQLite, Slack, Google Drive, Puppeteer, et plus encore.

Un serveur personnalisé minimal (Python)

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("status")

@mcp.tool()
def healthcheck(service: str) -> str:
    """Return the current status of a service."""
    return f"{service}: ok"

if __name__ == "__main__":
    mcp.run(transport="stdio")

J'ai testé ceci contre un endpoint de staging en environ dix minutes, y compris le câblage dans Claude Code. Pour des modèles plus généraux sur l'exposition de services internes comme API appelables par les agents, notre guide de développement d'API IA approfondit l'authentification et la limitation de débit.

À quoi ressemble l'écosystème en 2026 ?

L'écosystème s'est consolidé autour du registre officiel et d'une poignée de serveurs de référence bien entretenus. Je garde une liste courte de ceux que je fais réellement confiance en production :

• filesystem — lecture/écriture locale de fichiers avec restrictions root.
• github — problèmes, PRs, recherche, opérations sur les fichiers.
• postgres / sqlite — lecture seule par défaut, introspection du schéma.
• puppeteer / playwright — automatisation de navigateur pour les agents.
• slack — lectures de canaux et envoi de messages.

Pour orchestrer plusieurs serveurs derrière des sous-agents — un sous-agent possède la base de données, un autre possède le navigateur — notre article sur les sous-agents Claude Code présente le modèle d'équipe.

À faire attention ?

C'est la partie que la plupart des gens sautent. Les serveurs MCP s'exécutent avec vos identifiants et votre accès au système de fichiers, donc le périmètre est crucial.

• Traitez chaque serveur comme une dépendance. Épinglez les versions, auditez la source avant d'exécuter npx sur un dépôt inconnu. Un outil malveillant peut exfiltrer tout ce que voit le modèle.
• Restreignez les racines. Le serveur de système de fichiers n'est aussi sûr que le répertoire auquel vous le pointez — ne pas passer /.
• Préférez les configurations de base de données en lecture seule jusqu'à ce que vous ayez une raison concrète d'activer l'écriture.
• Faites attention à l'injection de prompts. Si un outil renvoie du contenu sur lequel le modèle agit ensuite, une entrée non fiable peut devenir des instructions. Assumez que toute ressource est hostile.
• Limitez les tokens OAuth. Les tokens Slack et GitHub doivent avoir le minimum de portée nécessaire au serveur, pas votre token personnel.

Je commence chaque nouveau serveur dans un compte sandboxé et j'observe les premiers appels d'outils avant de lui faire confiance lors d'une session réelle.

Point clé

MCP est un petit protocole qui résout un problème réel : il permet à un serveur d'exposer des outils, des ressources et des prompts à tout hôte IA compatible, éliminant ainsi la taxe d'intégration N-par-M. La mécanique est simple — initialiser, négocier, opérer via stdio ou HTTP — mais la posture de sécurité est ce qui détermine si cela appartient à votre flux de travail. Exécutez des serveurs que vous pouvez auditer, limitez strictement leurs identifiants et assumez que l'entrée non fiable est hostile. Faites cela et MCP est le moyen le plus propre de transformer un assistant en un agent capable d'interagir réellement avec vos systèmes.

Crédits images

• Code source affiché sur un écran de moniteur — photo par Markus Spiske sur Pexels
• Un développeur tapant sur un ordinateur portable tout en configurant un serveur dans un terminal — photo par Vlada Karpovich sur Pexels
• Composition abstraite de circuit imprimé symbolisant l'architecture en couches — photo par Christina Morillo sur Pexels