Comment le protocole de contexte du modèle permet aux agents d’IA de découvrir et d’appeler des outils

Demandez à un assistant IA de « créer une page d’accueil minimale dans Figma pour un SaaS IA appelé FlowAI, avec un fond sombre, un titre principal, un bouton d’appel à l’action et trois cartes de fonctionnalités », et un assistant bien connecté peut le faire : il génère la structure dans Figma sans que vous ayez besoin d’ouvrir l’application, ni que quiconque écrive une intégration personnalisée pour Figma. Le premier résultat constitue un point de départ, et vous pouvez continuer à itérer en demandant de nouvelles écrans, des modifications typographiques ou de polices. La même approche fonctionne avec de nombreuses autres applications.

Cela soulève des questions évidentes. Comment un modèle de langage contrôle-t-il une autre application ? Le MCP n’est-il qu’une autre API ? Que se passe-t-il réellement entre la demande et le résultat, et pourquoi ce protocole fait-il l’objet d’un tel débat ? Cet article répond à chacune de ces questions, afin que vous puissiez comprendre le MCP en tant qu’ingénieur plutôt que de le considérer comme une boîte noire.

Qu’est-ce que le MCP ?

MCP, le Model Context Protocol, est une méthode standard permettant aux applications d’IA de découvrir des outils externes et de les utiliser. Dans le cas de Figma, l’image la plus simple à se faire est celle d’une chaîne : l’application d’IA communique avec MCP, qui à son tour communique avec Figma. Vous décrivez ce que vous souhaitez, le modèle interprète la demande, vérifie quels outils sont disponibles via MCP, puis invoque celui qui convient à la tâche.

Figma n’est qu’un exemple. Grâce au même protocole, une application d’IA peut accéder à une base de données, à Slack, à GitHub et pratiquement à n’importe quel autre système disposant d’un serveur MCP.

Dans ce contexte, un « outil » désigne simplement une fonction que un service met à disposition pour que le modèle puisse l’appeler, comme « créer une frame », « rechercher des messages » ou « exécuter une requête ». MCP donne à ces fonctions une forme commune, permettant ainsi à toute application d’IA compatible de les trouver et de les utiliser.

Le problème d’intégration résolu par MCP

En l’absence de protocole commun, chaque combinaison d’une application d’intelligence artificielle et d’un outil nécessite un code personnalisé. Connecter un assistant à Figma constitue une intégration ; en connecter un second à Figma en est une autre. Ajouter Slack implique une nouvelle intégration, tout comme l’ajout d’une base de données. Le nombre d’intégrations augmente avec le produit du nombre d’applications et de outils, ce qui rend leur maintenance rapidement impossible à gérer.

Avec MCP, chaque fournisseur d’outils expose ses fonctions une seule fois via le protocole, et chaque application d’intelligence artificielle implémente ce protocole une seule fois. Toute application compatible peut alors utiliser n’importe quel outil compatible. Une façon utile de s’en souvenir : MCP agit comme un adaptateur universel entre les modèles d’intelligence artificielle et les outils dont ils ont besoin.

MCP remplace-t-il les APIs ?

Non. Les APIs ne disparaîtront pas. Figma, Stripe et Slack disposent toujours de leurs APIs, et votre base de données PostgreSQL existe toujours derrière tout ce que vous construisez dessus. En pratique, de nombreux serveurs MCP ne sont que des couches légères par-dessus des APIs existantes.

Ce qui change, c’est la manière dont ces fonctionnalités sont présentées et utilisées par une application IA. Dans une intégration traditionnelle, un développeur lit la documentation de l’API, choisit le bon point d’entrée, écrit le code client, gère l’authentification, envoie des requêtes et analyse les réponses. Toutes ces décisions sont prises à l’avance et codées.

Avec MCP, l’application IA peut demander à un serveur, en temps de exécution, quels outils il propose. Un serveur destiné à un magasin en ligne pourrait répondre par des outils tels que :

• rechercher des produits
• récupérer une commande
• créer un remboursement

Chaque outil est accompagné d’un nom, d’une description de sa fonction et d’un schéma d’entrée structuré que le modèle peut lire. En fonction de la demande de l’utilisateur, le modèle choisit l’outil approprié et fournit des arguments conformes au schéma. La décision concernant l’opération à effectuer passe du code écrit à l’avance au raisonnement du modèle au moment de la demande.

Les trois éléments fondamentaux : hôte, client et serveur

MCP est organisé autour de trois rôles.

L’hôte

L’hôte est l’application d’intelligence artificielle avec laquelle l’utilisateur interagit réellement : un assistant de chat, un outil de codage par IA ou toute application ayant un modèle linguistique à son cœur. Il contrôle la conversation ainsi que le modèle, et décide quels serveurs le modèle est autorisé à utiliser.

Le client MCP

Le client est la composante située à l’intérieur de l’hôte qui gère la communication avec un serveur MCP. Dans la conception du protocole, un hôte exécute généralement un client par connexion au serveur ; ainsi, un assistant connecté à Figma et GitHub maintient deux sessions de client distinctes.

Le serveur MCP

Le serveur met à disposition des outils à l’application IA et les relie à des systèmes réels. Lorsqu’un outil est invoqué, c’est le serveur qui communique réellement avec l’API de Figma, exécute la requête de base de données ou envoie le message sur Slack.

Que se passe-t-il lors d’une invocation d’outil

En combinant ces trois rôles, le flux devient clair : le client permet à l’hôte de découvrir les outils proposés par le serveur et de les invoquer avec des paramètres correctement structurés lorsque le modèle décide qu’ils sont nécessaires.

Ce n’est pas une demande simple à envoyer et à oublier. Il s’agit d’une conversation entre le client et le serveur. Ils établissent d’abord une session et s’accordent sur les capacités disponibles, puis le client demande la liste des outils, avant d’envoyer des appels aux outils et de recevoir leurs résultats. En réalité, ces messages utilisent JSON-RPC, transmis soit via les entrées/sorties standard pour les serveurs exécutés localement, soit via HTTP pour ceux qui sont distants.

C’est le modèle de langage qui différencie cela d’une intégration conventionnelle. Il n’y a pas de séquences d’appels prédéfinies ; le modèle lit les descriptions des outils, détermine ceux qui répondent aux besoins de l’utilisateur et les demande dans l’ordre requis par la conversation.

Décortiquer un assistant e-commerce

Prenons l’exemple d’un assistant de support pour une boutique en ligne dont le serveur MCP expose trois outils :

• get_order

search_products

create_refund

get_order est disponible, et décide de l’appeler en utilisant le numéro de commande du client. La demande est transmise depuis le client vers le serveur, qui interroge la base de données des commandes ou l’API interne des commandes et renvoie des données structurées concernant la commande. Le modèle transforme ensuite ces données en une réponse naturelle, par exemple : « Votre commande a été expédiée hier et devrait arriver jeudi. »

Le client reprend la conversation en disant : « En fait, remboursez-le. » Comme le modèle conserve le contexte de la conversation, il sait à quel ordre se réfère « cela ». Il constate que la fonction create_refund est disponible et l’appelle en utilisant les mêmes détails d’ordre. Si le serveur expose également une fonction comme notify_finance, le modèle pourrait intégrer cette étape dans le flux de travail également.

Cette division du travail constitue l’idée fondamentale de MCP. Le modèle décide quelle fonction utiliser et avec quels arguments. Le serveur effectue l’opération réelle. Dans un système en production, on ajouterait un élément supplémentaire à ce flux : un remboursement étant une action irréversible, de nombreuses équipes exigent une confirmation explicite de l’utilisateur ou des vérifications de politique sur le serveur avant de l’exécuter, plutôt que de se fier uniquement au jugement du modèle.

Ce que MCP vous offre

Trois avantages se distinguent particulièrement.

1. Standardisation : les applications d’IA interagissent avec des outils externes de manière cohérente, plutôt que selon un schéma différent pour chaque intégration.
2. Flexibilité : le modèle découvre les outils disponibles et lit directement leurs schémas, vous évitant ainsi de devoir décrire manuellement chaque fonction dans un prompt système très long.
3. Réutilisabilité : un serveur MCP est créé une seule fois et peut ensuite servir de nombreuses applications d’IA compatibles.

Ce que MCP ne fait pas

Il est utile d’être précis quant à ses limites, car le battage médiatique autour du protocole peut les rendre floues.

• MCP n’est pas de la magie, et il ne rend pas une API sous-jacente plus performante qu’elle ne l’est déjà.

Cela ne rend pas un système d’IA fiable. Le modèle peut encore choisir l’outil incorrect ou transmettre des arguments erronés, il est donc essentiel de maintenir une validation et un traitement des erreurs adéquats sur le serveur.

Cela ne résout pas les problèmes d’authentification ou de sécurité. Les serveurs ont toujours besoin de identifiants, de contrôle d’accès et d’audit, et les sorties des outils peuvent contenir du contenu non fiable qui tente d’influencer le modèle.

Cela ne signifie pas que chaque système interne doit être exposé à un agent d’IA. Accordez uniquement l’ensemble minimal d’outils et de permissions nécessaires réellement à un cas d’utilisation donné.

L’usage d’une API par une IA n’est pas une nouveauté ; les développeurs connectent des modèles à des API depuis des années. Ce que MCP apporte, c’est une interface standardisée permettant à un modèle de découvrir et d’utiliser de nombreux outils différents sans avoir besoin d’une intégration sur mesure pour chacun d’eux.

Points clés

• MCP est un protocole permettant de connecter des applications d’IA à des outils. Il s’appuie sur les APIs plutôt que de les remplacer.
• Les serveurs exposent des outils accompagnés de descriptions et de schémas d’entrée ; l’hôte ainsi que ses clients gèrent la découverte et la communication.
• Le modèle choisit quel outil appeler et avec quels arguments ; le serveur effectue réellement l’opération.
• La standardisation transforme un réseau croissant d’intégrations ponctuelles en composants qui sont créés une fois puis réutilisés.
• La fiabilité, l’authentification, le principe du moindre privilège ainsi que la confirmation des actions à risque restent de votre responsabilité.

Si vous débutez, commencez par relier des serveurs MCP existants, tels que ceux de GitHub, Slack ou Figma, à un assistant que vous utilisez déjà, et observez comment le modèle choisit les outils. Une fois la valeur ajoutée évidente, créer votre propre serveur pour une base de données ou un service interne constitue la prochaine étape logique. Pour comprendre comment MCP s’intègre dans des frameworks d’agents plus larges, consultez notre article sur la standardisation de l’intégration des outils dans LangGraph grâce à MCP.