MCP : l’USB‑C de l’intelligence artificielle

par Jacky THIERRY •

Les grands modèles de langage (LLM) sont impressionnants, mais ils souffrent d’un défaut architectural fondamental : ce sont des « cerveaux dans un bocal ». Ils sont isolés de vos données réelles, coupés des informations en temps réel et aveugles à votre environnement de développement.

Jusqu’à présent, résoudre ce problème impliquait de construire des pipelines RAG (Retrieval-Augmented Generation) complexes ou d’écrire du code d’intégration sur mesure. Si vous vouliez connecter Claude, GPT et Llama à GitHub, Jira et PostgreSQL, vous faisiez face au problème (N x M) : 3 modèles x 3 services = 9 connecteurs différents à maintenir.

Voici le Model Context Protocol (MCP). Il promet d’être l’USB-C du monde de l’IA : un standard ouvert qui permet de connecter vos données une seule fois et de les utiliser avec n’importe quel modèle.

Qu’est-ce que MCP ?

À la base, MCP est un standard ouvert minimaliste, composable et neutre. Il standardise la manière dont les modèles d’IA interagissent avec des systèmes externes.

L’architecture

La topologie se compose de trois parties simples :

  1. Hôte (Host) : l’application dans laquelle le LLM « vit » (par exemple ChatGPT, Claude Desktop, Cursor, Raycast).
  2. Client : le connecteur interne dans l’hôte qui parle le protocole.
  3. Serveur (Server) : un processus séparé qui expose vos données ou votre logique.

Le protocole

Pour les développeurs, c’est la partie rassurante. MCP est basé sur JSON-RPC 2.0.

Il supporte une communication locale via stdio (sécurisé, simple à déboguer) ou à distance via SSE (Server-Sent Events) pour du streaming HTTP.

Les primitives

Un serveur MCP expose trois capacités principales. Imaginons que nous construisions un serveur Poké-MCP :

  • Ressources (Resources) : lecture passive de données.
    • Exemple : lire un fichier statique type_chart.csv ou accéder à l’équipe courante via pokedex://my-team/current.
  • Outils (Tools) : actions exécutables (donner des « mains » au LLM).
    • Exemple : catch_pokemon(name: string, ball_type: string) ou check_evolution_status(id: int).
  • Prompts : templates pré-définis pour guider le LLM.
    • Exemple : un prompt « stratégie de Champion d’Arène » qui charge automatiquement les stats de votre équipe et les match-ups de type probables du Champion dans le contexte.

MCP vs. APIs standards

Vous pourriez demander : « Pourquoi ne pas simplement donner au LLM la spec OpenAPI de la PokéAPI ? »

Les APIs REST sont optimisées pour le code, tandis que MCP est optimisé pour le contexte.

  • Abstraction “LLM-friendly” : les serveurs MCP formatent les données spécifiquement pour un LLM. Au lieu de renvoyer un énorme JSON avec 500 attaques quand vous interrogez « Dracaufeu », le serveur MCP peut résumer les stats de combat pertinentes.

  • Gestion du contexte : le serveur gère la pagination. Il évite d’inonder le LLM avec toutes les formes d’un Pokémon quand vous avez simplement demandé les Pokémon de la Gen 1.

  • Sampling (le mode “appel à un ami”) : MCP permet au serveur de mettre en pause l’exécution et de demander de l’aide au LLM avant de terminer une tâche.

    Exemple : imaginez un outil appelé optimize_team. Le script Python voit que Pikachu peut apprendre Tonnerre ou Vive-Attaque, mais un script ne comprend pas la stratégie. Il « sample » le LLM : « Pikachu est dans une équipe avec Dracaufeu (Feu). Quelle attaque complète le mieux l’équipe ? » Le LLM répond « Tonnerre », puis le script met à jour la base de données avec cette attaque. L’outil emprunte le cerveau du LLM pour décider.

  • Hot-swapping : comme changer une cartouche Game Boy sans éteindre la console. Si vous développez votre propre « outil Pokédex » et ajoutez les formes shiny, vous n’avez pas besoin de redémarrer l’hôte. Les changements peuvent être pris en compte immédiatement, rendant la boucle de dev très rapide et les mises à jour en production plus transparentes.

Anatomie d’une requête

Voyons un exemple concret. Vous avez installé votre Poké-MCP et vous demandez à Claude : « Quelles sont les stats de base de Dracaufeu ? »

  1. Découverte : l’hôte scanne les serveurs MCP connectés et voit les outils disponibles.
  2. Intention : le LLM décide qu’il doit appeler l’outil get_pokemon_stats.
  3. Protocole : le client construit une requête JSON-RPC :
json 
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "get_pokemon_stats",
    "arguments": { "name": "charizard" }
  }
}
  1. Exécution : le serveur MCP reçoit la requête, récupère les données depuis une base ou une API externe, et formate le résultat de manière concise.
  2. Réponse : le LLM reçoit les données structurées (PV: 78, Attaque: 84, Att. Spé: 109...) et génère la réponse en langage naturel : « Dracaufeu est un type Feu/Vol avec une Attaque Spéciale massive de 109. »

Sécurité et gouvernance

Pour les développeurs, laisser une IA exécuter du code fait peur. Vous ne voulez pas qu’un LLM libère par erreur vos Pokémon shiny. MCP répond à cela avec :

  • Contrôle utilisateur : une approbation explicite est requise pour les actions. Si le LLM tente d’appeler release_pokemon(id=25), l’hôte affiche une boîte de dialogue : « Claude veut exécuter 'release_pokemon'. Autoriser ? »
  • Isolation : avec le transport stdio, le serveur s’exécute localement sur votre machine. Vos clés API (ou l’emplacement secret de votre sauvegarde) restent dans vos variables d’environnement locales et ne sont jamais envoyées au cloud du fournisseur du LLM.

La réalité actuelle : limites

MCP est puissant, mais ce n’est pas magique.

  • Fenêtre de contexte : si votre serveur MCP renvoie le texte complet de chaque entrée du Pokédex pour 1 000+ Pokémon, vous saturerez la fenêtre de contexte, augmentant les coûts et rendant les modèles « oublieux ».
  • Latence : chaque aller-retour (Hôte → Client → Serveur → API → Hôte) ajoute de la latence. Des combats en temps réel pourraient être trop lents.
  • Prompt injection : si les données renvoyées par MCP contiennent du texte malveillant (par exemple un Pokémon nommé « IgnorePreviousInstructions »), le LLM peut être piégé.

Conclusion

MCP est plus qu’un standard technique de plus : c’est le chaînon manquant qui transforme les LLM de « cerveaux dans un bocal » en agents connectés et capables. Il équilibre le besoin d’un contexte riche avec une sécurité stricte et un contrôle développeur.

Pour la première fois, vous pouvez construire un connecteur une fois et l’exécuter immédiatement dans tout votre écosystème—que ce soit dans Claude, votre IDE ou vos outils internes. Les silos de données commencent enfin à se briser. Il est temps de connecter.