Loïc BoninLB
← Veille

ia

Comprendre le Model Context Protocol (MCP)

2 juillet 2026·5 min de lecture

MCP en 2026 : Le standard qui connecte enfin les agents IA au monde réel

Si vous construisez des applications avec des agents intelligents, vous vous rendez compte que, par défaut, le modèle de langage est coupé du monde extérieur. Pour lui donner accès à vos fichiers, à vos bases de données ou à vos outils internes comme Slack et Jira, vous devez coder des passerelles spécifiques. C'est ici qu'intervient le Model Context Protocol (MCP) : il s'agit d'un standard ouvert qui agit comme une prise universelle entre les intelligences artificielles et vos sources de données.

Au lieu de réécrire un connecteur pour chaque nouveau modèle ou framework d'agent, vous écrivez un serveur MCP une seule fois. N'importe quel client compatible (comme votre éditeur de code, votre interface en ligne de commande ou vos orchestrateurs d'agents) peut alors s'y brancher pour utiliser ces ressources.

Voici comment fonctionne ce protocole, expliqué simplement, et pourquoi il change la façon dont nous construisons des applications IA.

Rôles et responsabilités : Host, Client et Server

Pour comprendre MCP, oubliez les schémas d'architecture complexes. Pensez plutôt au port USB-C.

Avant l'arrivée de l'USB-C, la connectivité des ordinateurs était un enfer. Il fallait un chargeur propriétaire pour le PC portable, un câble HDMI pour l'écran, un câble USB-A pour la souris, etc. Le monde de l'IA souffrait de la même fragmentation. Si vous vouliez que votre modèle lise un fichier Excel, vous deviez coder une intégration spécifique en utilisant des bibliothèques de manipulation de feuilles de calcul. Si vous changiez de modèle ou d'orchestrateur, vous deviez tout recoder. MCP est le port USB-C de l'IA.

Dans cette analogie :

  • L'ordinateur portable (le Host) : C'est votre application IA principale (comme Cursor, Claude Desktop ou votre orchestrateur d'agents personnalisé). Il possède un unique port d'entrée universel : le port USB-C.
  • La fiche et le contrôleur (le Client) : C'est la bibliothèque logicielle intégrée à votre agent qui sait lire et écrire des messages standardisés au format MCP (format en JSON-RPC 2.0).
  • Le périphérique (le Serveur) : C'est le traducteur universel branché sur votre outil. Un serveur MCP Excel prend les commandes standard du client et les traduit en requêtes lisibles par le moteur d'Excel.

Vous branchez l'agent sur le serveur. La connexion s'établit. L'agent utilise les outils exposés par le serveur sans jamais avoir besoin de savoir comment l'outil fonctionne sous le capot.

Ces trois rôles ne sont pas propres à MCP. Ils illustrent concrètement une des couches de configuration du harnais que nous avons détaillées dans notre article précédent. MCP standardise simplement la façon dont le Client et le Serveur communiquent au sein de cette architecture.

MCP dans votre flux de développement : pourquoi ça change quelque chose

Avant MCP, appeler une API depuis un agent voulait dire écrire du code d'authentification, gérer les formats de réponse et reproduire cette logique dans chaque agent, dans chaque framework. Avec MCP, l'écosystème gère ce travail une fois pour toutes. L'agent appelle un outil standard, le serveur MCP fait la traduction, et vous ne touchez pas à la logique d'intégration quand vous changez de modèle ou de framework.

Cela change l'équation du côté maintenabilité : vos agents deviennent modélaires. Si GitHub publie une nouvelle fonctionnalité dans son API, l'équipe GitHub met à jour son serveur MCP. Votre agent reçoit automatiquement les nouveaux outils lors de la négociation de connexion. Vous n'avez pas à lire une note de mise à jour, et encore moins à modifier votre code.

Le traitement des rapports Excel et Word

Imaginez un agent chargé de générer des rapports de facturation mensuels. Sans MCP, vous deviez écrire un script lourd qui télécharge des fichiers depuis un espace de stockage partagé, utilise une bibliothèque complexe pour parser les lignes du tableur Excel, calcule les totaux, puis utilise une autre bibliothèque pour générer un fichier Word.

Avec MCP, vous utilisez des serveurs existants :

  • L'agent appelle une action du serveur MCP pour lire le fichier Excel sur OneDrive.
  • Le serveur MCP renvoie les données sous forme de ressources structurées.
  • L'agent traite les données et utilise un outil du serveur MCP Word pour écrire le fichier final, puis demande à Outlook d'envoyer l'e-mail avec la pièce jointe.

Le développeur n'a pas écrit une seule ligne de code d'API OneDrive ou Office. Il a simplement configuré les serveurs MCP existants et laissé l'agent appeler les outils standardisés.

La gestion des documents avec Google Sheets et Drive

Prenons un cas d'usage courant : la qualification automatique de prospects enregistrés dans un tableur Google Sheets.

Sans MCP, vous devriez écrire un script spécifique pour vous authentifier à l'API Google, lire les lignes, envoyer le texte à votre modèle, puis réécrire dans le tableur via des requêtes API complexes.

Avec MCP, l'agent utilise simplement le serveur de l'application Google Sheets pour accomplir la tâche en trois étapes :

  • La lecture (Ressource) : L'agent accède au document Sheets pour analyser les informations des nouveaux prospects.
  • L'analyse (Raisonnement) : L'IA qualifie le profil du prospect grâce à ses capacités internes de compréhension.
  • L'action (Outil) : L'agent utilise l'outil d'écriture exposé par le serveur pour inscrire directement son verdict dans le tableur.

Toutes les actions et données sont découvertes dynamiquement par l'agent lors de la poignée de main MCP, sans que vous n'ayez eu à coder le moindre connecteur d'API Google.

La mise à jour de juillet 2026 : Le passage au Stateless

Jusqu'à mi-2026, MCP obligeait le Client et le Server à initier une poignée de main complexe et à garder une session ouverte en permanence, avec un identifiant de session. C'était un problème majeur en entreprise. Si vous deviez faire tourner des milliers d'agents interrogeant un groupe de serveurs MCP, vous deviez configurer vos routeurs pour renvoyer le même agent vers le même serveur physique à chaque requête. Si ce serveur tombait en panne, l'agent perdait sa session et son contexte.

La spécification de fin juin 2026 supprime cette contrainte. Le release candidate a été verrouillé le 21 mai 2026, avec une publication finale prévue le 28 juillet 2026. Pour les équipes d'ingénierie, cette mise à jour de la spécification change la donne : le protocole deviendra entièrement sans état (_stateless_), ce qui simplifie radicalement l'hébergement, la sécurité et le passage à l'échelle en production.

Chaque message envoyé par l'agent contiendra désormais tout le contexte nécessaire pour être traité de manière isolée. Concrètement, deux éléments disparaissent : la poignée de main initiale et l'identifiant de session. Le routage s'appuie désormais sur un en-tête de méthode MCP plutôt que sur une session, ce qui permet à un simple répartiteur round-robin de diriger le trafic sans inspection de paquets ni stockage de session partagé. Ce n'est pas un détail théorique : le SDK MCP dépassait déjà 97 millions de téléchargements mensuels en mars 2026, et cette bascule stateless vise justement à absorber ce volume sans complexité d'infrastructure. N'importe quel serveur disponible dans votre parc informatique peut y répondre. Cela permet enfin de placer les serveurs MCP derrière des répartiteurs de charge standards pour gérer la montée en charge.

L'authentification OAuth 2.0 ou OpenID Connect pourra s'appliquer directement au niveau de chaque appel, éliminant les risques de sécurité liés aux sessions persistantes compromises.

Exemple concret

Voici comment instancier un client MCP et lister ses outils disponibles à l'aide du SDK officiel en TypeScript :

Note : Cet exemple utilise le SDK v1 (@modelcontextprotocol/sdk), qui reste la version supportée en production. Le SDK v2, qui adopte de nouveaux noms de packages (@modelcontextprotocol/client, @modelcontextprotocol/server) et implémente la spécification _stateless_ de juillet 2026, est encore en beta à la date de publication.
typescript
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";
 
async function runOrchestrator() {
// 1. On définit le câble qui relie l'agent au serveur (stdio)
const transport = new StdioClientTransport({
command: "node",
args: ["./build/my-office-mcp-server.js"],
});
 
// 2. On instancie le Client MCP
const client = new Client(
{
name: "mon-agent-de-bureau",
version: "1.0.0",
},
{
capabilities: {
tools: {},
},
},
);
 
// 3. On établit la connexion
await client.connect(transport);
 
// 4. L'agent demande les outils disponibles
const response = await client.listTools();
console.log("Outils découverts :", response.tools);
 
// 5. L'agent utilise l'outil Excel exposé
const toolName = "read_excel_sheet";
if (response.tools.some((t) => t.name === toolName)) {
const result = await client.callTool({
name: toolName,
arguments: {
filepath: "documents/ventes_2026.xlsx",
sheet: "Q2",
},
});
console.log("Données Excel lues :", result.content);
}
}
 
runOrchestrator().catch(console.error);

Ce que MCP ne fait pas

Le protocole résout la connectivité technique entre un agent et un outil. Il ne résout pas l'intelligence de l'agent. Le serveur MCP n'a aucun moyen de savoir si l'agent fait une erreur de raisonnement. Il exécute les commandes qu'il reçoit.

C'est là qu'interviennent les Skills, mais attention à ne pas les confondre avec le protocole MCP lui-même. Les Skills sont un mécanisme distinct, porté par le harnais de l'agent (pas par le transport MCP), qui fournit un mode d'emploi détaillé pour bien utiliser un outil donné. MCP reste le tuyau qui transporte la commande. Le Skill vit du côté de l'agent et lui explique comment formuler cette commande correctement.

MCP ne gère pas non plus les discussions entre agents. Si vous avez besoin que trois agents négocient entre eux, vous devez utiliser le protocole A2A (Agent-to-Agent) ou un framework d'orchestration comme LangGraph. MCP reste strictement dédié à la relation entre l'agent et l'outil.

Sélection de serveurs MCP utiles pour les développeurs

L'intérêt de MCP se concrétise dans la richesse de son écosystème. Avant de coder un outil from scratch, vérifiez si quelqu'un ne l'a pas déjà fait.

Où trouver des serveurs MCP

Trois ressources font office de référence :

Versionning et CI/CD

Ces serveurs permettent à un agent de lire des tickets, créer des branches, déclencher des pipelines ou commenter des pull requests sans quitter son contexte.

  • GitHub MCP Server : Le serveur officiel de GitHub. Gestion des issues, pull requests, branches et workflows GitHub Actions directement depuis votre agent. github/github-mcp-server
  • GitLab MCP Server : Le serveur officiel de GitLab. Accès aux projets, merge requests et pipelines GitLab Duo via le protocole standard. docs.gitlab.com/user/gitlab_duo
  • Jenkins MCP Plugin : Permet à un agent de déclencher des builds Jenkins, de lire les logs d'exécution et de consulter l'état des jobs, sans accès direct à l'interface web. jenkinsci/mcp-server-plugin

Docker et Kubernetes

  • Docker Hub MCP : Interroge les images disponibles, leurs tags et leurs vulnérabilités connues directement depuis votre agent ou votre IDE. docker/hub-mcp
  • Kubernetes MCP Server : Lit l'état des pods, des deployments et des services dans un cluster. Utile pour connecter un agent de monitoring ou d'analyse d'incidents à votre infrastructure. containers/kubernetes-mcp-server

Sécurité

  • Trivy MCP (Aqua Security) : Lance des scans de vulnérabilités sur une image Docker, un répertoire ou une dépendance, et renvoie les résultats sous forme de ressources structurées directement exploitables par un agent. aquasecurity/trivy-mcp
  • Prowler MCP : Exécute des audits de conformité cloud (AWS, Azure, GCP) et expose les résultats à un agent pour une analyse ou une remédiation automatisée. prowler-cloud/prowler

Débogage et observabilité

  • Sentry MCP : Accès direct aux erreurs, traces et sessions Sentry. Un agent peut interroger les issues les plus récentes d'un projet, analyser une stack trace et créer un rapport de bug sans changer d'interface. mcp.sentry.dev

Documentation intégrée (Context7)

  • Context7 (Upstash) : Injecte la documentation technique d'une bibliothèque directement dans le contexte de l'agent, à la version exacte utilisée dans le projet. Fini les hallucinations d'API dépréciée. upstash/context7

Navigation web et web scraping

  • Playwright MCP (Microsoft) : Contrôle un navigateur Chromium via Playwright. Permet à un agent de naviguer, remplir des formulaires, cliquer et extraire du contenu de pages qui nécessitent JavaScript. microsoft/playwright-mcp
  • Firecrawl MCP : Scraping de pages web en Markdown propre, idéal pour alimenter un agent en contenu de pages statiques ou dynamiques sans écrire de parseur HTML. firecrawl/firecrawl-mcp-server

Bases de données

  • Postgres MCP (CrystalDBA) : Connexion à une base de données PostgreSQL en lecture seule ou en lecture-écriture. L'agent peut exécuter des requêtes, inspecter le schéma et analyser les performances sans accès direct au serveur. crystaldba/postgres-mcp

UI et Frontend

  • Shadcn/UI MCP : Accès aux composants et à la documentation de la bibliothèque Shadcn directement depuis votre CLI ou IDE. Un agent peut rechercher un composant, lire ses props et générer du code conforme à la version installée. ui.shadcn.com/docs/mcp
  • Figma MCP : Expose les fichiers et composants Figma d'un projet à un agent. Permet de générer du code de composant à partir des spécifications de design sans copier-coller manuellement depuis l'interface Figma. mcp/com.figma.mcp

Conclusion

Le Model Context Protocol standardise la connexion entre l'intelligence artificielle et vos outils métiers. En découplant la logique d'accès aux données des capacités cognitives du modèle, il apporte la modularité qui manquait à l'écosystème des agents.

La mise à jour sans état (_stateless_) lève les verrous d'infrastructure historiques. Les serveurs MCP ne sont plus des scripts isolés à session ouverte, mais des services prêts à être déployés derrière des répartiteurs de charge standards pour soutenir la mise en production.

Les serveurs listés dans la section précédente existent grâce à des équipes qui ont fait ce travail et l'ont mis à disposition du reste de l'écosystème. Avec la version stateless de juillet 2026, toute cette pile existante est prête à passer à un réel fondement d'architecture de l'informatique agentique.

Liens utiles

IALLM