Cette exploration du Model Context Protocol (MCP) est présentée en trois parties distinctes :

  • Partie I, l’article actuel, introduit les concepts fondamentaux du MCP.
  • Partie II approfondira une implémentation spécifique, en démontrant un hôte personnalisé exploitant l’API VertexAI de Google et le modèle Gemini.
  • Partie III présentera une implémentation pratique d’un serveur personnalisé adaptée à un cas d’usage particulier.

Les parties sont liées, mais faiblement couplées : vous pouvez les lire séparément.

À propos des systèmes agents

Avant de commencer, établissons un langage commun et quelques clarifications qui seront utilisées tout au long de cette série d’articles :

Un agent est un concept général. C’est une entité capable d’interagir avec un environnement.
Un environnement fournit des informations qui le rendent observable par l’agent. Il offre également des capacités permettant à l’agent d’interagir avec lui.
En interagissant avec l’environnement, l’agent le modifie. Ces modifications apportent une utilité à l’agent (un agent incapable de modifier un environnement est inutile).

Lorsqu’on parle d’agents, on évoque aussi souvent l’autonomie. L’autonomie est une propriété variable d’un agent – c’est la capacité qu’a l’agent d’agir de manière indépendante.
Il peut exister plusieurs niveaux d’autonomie. Plus un agent est autonome, moins il a besoin d’interaction humaine pour fonctionner.

Note : Je ne vais pas entrer dans les détails ici, mais ne confondez pas agents et workflows. Un workflow est un processus d’exécution préprogrammé, une représentation automatisée d’un processus humain. Voyez-le comme un graphe d’exécution.
Même si un maillon peut intégrer une automatisation cognitive, il ne faut pas le confondre avec le concept d’agentivité que nous utilisons ici.

À propos des environnements

Même si l’(r)évolution actuelle de l’IA concerne le processus de raisonnement, considérons l’aspect le plus crucial qui rendra ces IA utiles à l’humanité : les environnements.

Pour être pragmatique, illustrons cela avec l’environnement le plus utilisé aujourd’hui : une fenêtre de chat.
Dans un chatbot (comme Claude, Gemini ou ChatGPT), le modèle est un LLM (Large Language Model), et il génère des informations textuelles (c’est de l’IA générative). Son objectif est de compléter une invite et de remplir une fenêtre de contexte.

Note : Bien que la fenêtre de chat soit un exemple courant, il faut mentionner qu’un environnement peut aussi être une base de données, une API, un système physique (via des capteurs et des actionneurs) ou tout autre système fournissant des informations et des actions.

La fenêtre de contexte est comme un cahier (de taille limitée) dans lequel vous stockez votre conversation.
L’interface de chat est un type d’interface utilisateur, une représentation de l’environnement. Vous pouvez écrire dans la fenêtre de chat… et l’agent peut aussi y écrire.

Note : Ceci est une simplification pour faciliter l’explication. La fenêtre de contexte pourrait être considérée comme faisant partie de l’environnement, mais je la sépare ici pour clarifier l’explication qui viendra en Partie II de cette série (où nous approfondirons la notion d’agent).

Un schéma dessiné à la main illustrant le Model Context Protocol (MCP)

L’environnement est fermé.

En tant qu’humains, nous sommes aussi des agents, et nous interagissons avec de nombreux environnements.

Par exemple, le World Wide Web (WWW) peut être vu comme un environnement, et le navigateur est l’outil qui nous permet d’interagir avec lui. En cliquant sur un lien, nous modifions ce qui est affiché.
De plus, dans le monde numérique, nous avons accès à de multiples capacités nous permettant d’interagir avec un système – par exemple, ajouter un article à un panier ou réserver un hôtel.

Ainsi, pour rendre les agents encore plus utiles, nous devons leur donner la capacité d’interagir avec un environnement plus large que la seule fenêtre de chat.

En tant qu’humains, nous pourrions alors déléguer des tâches cognitives et utiliser ces agents comme de véritables assistants. Nous pourrions ainsi nous libérer de tâches répétitives (attention, nous parlons d’agents, pas de workflows).

Un schéma illustrant une interaction élargie du Model Context Protocol (MCP)

Le problème est donc le suivant : comment faire interagir un agent avec l’environnement… n’importe quel environnement ?

La solution au problème

Donner à un agent la capacité d’interagir avec un environnement numérique n’est pas simple.
En réalité, le modèle peut comprendre une intention ; il peut raisonner dans une certaine mesure, mais la plupart du temps, le seul environnement avec lequel il peut interagir est la fenêtre de chat.

Nous devons donc lui fournir de nouvelles capacités qu’il pourra déclencher lorsque nécessaire.

Ces capacités sont présentées sous forme d’outils numériques et sont généralement exposées sous forme de fonctions (bien qu’il puisse exister d’autres interfaces).

Chaque outil est alors spécialisé pour accomplir une tâche précise.

Comment l’agent peut-il utiliser l’outil ?

La question est donc : comment l’agent peut-il utiliser un outil ? Et comment choisit-il le bon outil si plusieurs lui sont fournis ?
Gardez à l’esprit que l’interaction avec le modèle se fait aujourd’hui exclusivement via le langage naturel.

Nous devons donc mettre en place un mécanisme de liaison (une traduction de la requête en langage naturel de l’agent vers un appel structuré à l’outil) pour donner à l’agent la possibilité d’exécuter l’outil.

Un schéma illustrant l’intégration d’outils dans le Model Context Protocol (MCP)

La plupart des moteurs d’exécution de modèles génératifs proposent un SDK (Software Development Kit) permettant d’interagir avec le modèle et d’étendre ses capacités en profondeur. (Dans la deuxième partie de cette série, nous verrons comment implémenter un agent en utilisant les services VertexAI de Google).

Mais ce système est fortement couplé. Il nécessite des modifications importantes du code de l’agent. L’outil est donc intégré en dur dans l’agent.

Un diagramme illustrant la séparation des outils et du modèle dans MCP

Séparer l’outil offrirait de nombreux avantages :

  • L’outil n’a rien à voir avec l’IA (modélisation, science, etc.). Il relève du pur génie logiciel. Il peut donc évoluer indépendamment de l’agent et être utilisé par n’importe quel modèle ou même par un humain.
  • L’outil peut se rapprocher de l’environnement. Il peut servir de point d’entrée dans l’environnement. Son propriétaire est proche du métier et peut décider des ressources et des actions qu’il souhaite exposer aux agents.

Le Web pourrait ainsi devenir un écosystème d’outils utilisables par n’importe quel agent pour accomplir une tâche.

Model Context Protocol comme standard proposé

Pour créer cet écosystème d’outils permettant d’interagir avec le plus d’environnements possible, il est nécessaire de définir un standard : une méthode adéquate pour que l’agent et les outils puissent communiquer.

Pensez au World Wide Web : sans HTTP/HTML, le web ne fonctionnerait pas comme il le fait aujourd’hui. Ce standard doit définir comment les outils sont décrits et comment les agents peuvent interagir avec eux.

J’expose une fonction {{function_name}} qui {{description}} et qui nécessite les arguments suivants :

  • {{argument_name}} est un {{type}} qui représente {{description}}.

Par exemple, un outil pourrait être décrit dans un format structuré comme JSON. Voici un exemple simplifié de la manière dont un service météo pourrait être représenté :

{
  "function_name": "get_weather",
  "description": "Récupère la météo actuelle pour un emplacement donné.",
  "arguments": [
    {
      "name": "location",
      "type": "string",
      "description": "La ville ou la région pour laquelle récupérer les données météo."
    }
  ]
}

Vous avez saisi l’idée. Ensuite, cette description est sérialisée dans un langage informatique, ce qui permet de la transférer sur un réseau et de la rendre accessible via Internet.

C’est, en essence, ce qu’est MCP : un standard d’exposition et de communication.

MCP en détail

MCP est donc un standard conçu pour enrichir l’agent et lui fournir des outils qu’il pourra utiliser immédiatement (out-of-the-box).

Le langage universel de MCP

MCP introduit son propre vocabulaire, dont voici quelques concepts clés :

  • Les outils que nous décrivons sont appelés MCP Servers.
  • L’application qui exécute le modèle de langage est un hôte (host).
  • L’hôte communique avec le MCP Server en implémentant un MCP Client.

Ce qu’expose un serveur MCP

Le protocole MCP ne se limite pas à un simple vocabulaire. Il définit trois grandes catégories de capacités qu’un serveur peut fournir :

  • Ressources : un serveur peut exposer des ressources issues d’un environnement (ex. : “une liste de produits disponibles”, “le prix actuel d’une action”, “le profil d’un utilisateur”).
  • Outils : un serveur peut fournir des fonctions pour exécuter des tâches spécifiques (ex. : “calculer la distance entre deux points”, “envoyer un e-mail”, “réserver un vol”).
  • Prompts : un serveur peut fournir des modèles de texte préconçus pour aider l’hôte à raisonner et à formuler des réponses (ex. : “un modèle pour rédiger une description produit”, “un ensemble de règles pour formater un rapport”, “une base de connaissances sur un sujet spécifique”).

Ce standard permet ainsi d’étendre facilement les capacités d’un agent.

Je ne rentrerai pas ici dans les détails techniques de l’implémentation de MCP (ce sera le sujet de la Partie III de cette série, où nous parlerons des appels de procédure à distance, du JSON et d’autres aspects techniques).

Je conclurai cet article avec un ensemble de convictions que je souhaite partager.

Conclusions et convictions

Cette norme permet facilement d’étendre les capacités de n’importe quel agent. Elle change le paradigme commercial et constitue, selon moi, le catalyseur de la prochaine révolution numérique.

La première révolution fut Internet. Internet a apporté l’omnicanal. Une entreprise pouvait exposer ses services, et les utilisateurs pouvaient interagir avec elle depuis leur canapé.

Un utilisateur interagissant avec un ordinateur portable connecté à trois sites : A, B et C hébergés dans le cloud

La deuxième révolution fut le smartphone qui a apporté de véritables services numériques (accessibles avec les doigts) et le nomadisme : des services accessibles de partout. Mais c’était toujours à l’utilisateur de faire le routage cognitif pour utiliser un service ou un autre (dois-je d’abord réserver le train, ou l’hôtel… est-ce compatible avec mon agenda…).

La prochaine révolution est que vous ne ferez plus ces tâches cognitives par vous-même. Vous les déléguerez à un assistant. Mais quel assistant gagnera votre faveur ? L’assistant qui obtiendra le plus de faveur gagnera une guerre commerciale : il détiendra des millions, voire des milliards d’utilisateurs potentiels qu’il pourra diriger vers une entreprise selon la volonté du modèle.

Ce nouveau paradigme pourrait conduire à des changements significatifs dans la façon dont les entreprises fournissent des services et dont les utilisateurs interagissent avec eux. La compétition pour créer les assistants IA les plus utiles et les plus fiables sera probablement féroce : Quel hôte sera le plus utilisé ? Quelles données collectera-t-il pour améliorer son utilisation du meilleur outil… celui de votre entreprise préférée… ou celui fourni par l’entreprise qui paie le plus ?

À suivre :