MCP

Nº 039 · v2026-08EN : MCP

MCP est une prise standard entre le logiciel qui pilote un modèle et les outils ou documents auxquels il doit accéder. Comme une prise électrique normalisée : chaque appareil se branche sans câble sur mesure, et en changer ne demande pas de refaire l’installation.

Ce que ce n’est pas

MCP n’est pas une capacité du modèle. Un modèle ne connaît pas ce protocole, ne s’y connecte pas et ignore jusqu’à son existence : c’est le harnais qui parle ce langage, va chercher ce qu’il faut, puis le lui donne à lire comme n’importe quel texte. Ce n’est pas non plus une intelligence supplémentaire ni un produit à acheter : c’est une convention de branchement, de la plomberie. Brancher une source par ce moyen ne rend donc pas un système plus compétent, cela lui donne accès à davantage de choses.

En profondeur

Le problème de multiplication

Le problème que ce protocole résout est un problème de multiplication. Sans convention commune, chaque produit qui pilote un modèle doit écrire une connexion sur mesure vers chaque outil et chaque source de données, et le travail recommence à chaque nouvelle combinaison. Une interface standard renverse le calcul : celui qui expose un outil le décrit une fois, celui qui construit un harnais sait lire cette description, et les deux côtés évoluent séparément. Le sigle désigne un protocole de contexte destiné aux modèles, publié comme spécification ouverte, ce qui explique qu’il n’appartienne à aucun produit en particulier.

Ce qui transite

Ce qui transite est de la description et du résultat, jamais de l’intelligence. Un service branché annonce ce qu’il sait faire et ce qu’il peut fournir ; le harnais reprend ces annonces, les place dans le contexte, et le modèle peut alors réclamer une action par un appel d’outils. Le circuit reste donc celui de toujours : le modèle demande, le harnais exécute, le résultat revient sous forme de texte. Le protocole change la façon dont le harnais atteint l’outil, pas la façon dont le modèle décide, et il ne dispense d’aucun des contrôles qu’on placerait autour d’un outil écrit à la main.

Ce qui a changé

Le protocole a cessé de ne transporter que du texte. Une extension normalisée permet à un service de livrer, en réponse à un appel, une interface complète que le logiciel hôte affiche dans la conversation : un graphique que l’on explore, un formulaire que l’on remplit, un lecteur que l’on manipule. Cette interface s’exécute isolée du reste de l’application, dans un cadre qui l’empêche d’atteindre la page qui la contient, et tout ce qu’elle réclame repasse par le chemin de contrôle d’un appel ordinaire. Le déplacement compte pour deux raisons. La réponse d’un service n’est plus seulement lue par le modèle, elle est vue et manipulée par une personne, ce qui sort du régime « tout est du texte » qui gouverne le reste du lexique. Et la surface de confiance s’élargit : accepter un service, ce n’est plus seulement accepter ses descriptions, c’est accepter du code d’affichage écrit ailleurs.

Le risque déplacé

La facilité de branchement déplace le risque plutôt qu’elle ne le supprime. Connecter une source devient une affaire de minutes, alors que décider qui a le droit de l’interroger, sur quelles données et avec quelle trace reste un travail de gouvernance entier. S’ajoute une question de confiance : un service branché décrit lui-même ses outils, et cette description est du texte que le modèle va lire, donc une porte d’entrée pour des instructions indésirables. Enfin, chaque source raccordée occupe de la place dans le contexte et sollicite l’attention du modèle : un harnais surchargé de connexions choisit moins bien, pas mieux.

Sous le capot3 temps · la forme réelle des objets

Le protocole tient en une enveloppe (JSON-RPC 2.0) et deux gestes : un service annonce ce qu’il sait faire, l’hôte s’en sert. Ce qu’il annonce peut être un outil, un document, et depuis peu une interface. Les trois temps suivent cet ordre.

01
Ce qu’un service annonce
La réponse d’un service à la question « que sais-tu faire ? ». C’est la déclaration d’outil ordinaire, transportée par une enveloppe standard : ce que le protocole normalise, c’est le transport et les noms, pas le principe.
json
```
{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "tools": [
      {
        "name": "meteo_ville",
        "description": "Prévisions à sept jours pour une ville.",
        "inputSchema": {
          "type": "object",
          "properties": { "ville": { "type": "string" } },
          "required": ["ville"]
        },
        "_meta": {
          "ui": { "resourceUri": "ui://meteo/tableau", "visibility": ["model", "app"] }
        }
      }
    ]
  }
}
```
jsonrpc
La même enveloppe pour tout : lister, appeler, lire un document. C’est là toute l’économie du protocole, et la raison pour laquelle changer de service ne demande pas de réécrire le harnais.
inputSchema
Le même objet qu’une déclaration d’outil écrite à la main, au nom de champ près. Le modèle ne saura jamais d’où vient cette description : le harnais la lui présente comme les autres.
_meta.ui
L’accroche vers une interface. Sa présence annonce que la réponse de cet outil peut être affichée plutôt que lue, et permet à l’hôte de charger et d’examiner l’interface avant même le premier appel.
Le piègeLa description vient du service, donc d’un tiers, et elle finit dans le contexte que le modèle lit. Un service branché écrit littéralement une partie de votre prompt : c’est la porte d’entrée que la couche 2 signale, et elle est ici, dans ce champ.
02
Quand la réponse est une interface
La ressource désignée plus haut. Ce n’est ni une image ni un gabarit à trous : c’est une page complète, chargée par l’hôte et non par le modèle, qui n’en verra jamais le code.
json
```
{
  "uri": "ui://meteo/tableau",
  "name": "tableau_meteo",
  "mimeType": "text/html;profile=mcp-app",
  "_meta": {
    "ui": {
      "csp": {
        "connectDomains": ["https://api.exemple.org"],
        "resourceDomains": ["https://cdn.exemple.org"]
      },
      "prefersBorder": true
    }
  }
}
```
ui://
Un schéma d’adresse réservé aux interfaces. Il n’est pas atteignable depuis un navigateur : seul l’hôte le résout, par le protocole.
mimeType
Le type qui déclare « ceci est une interface, pas un document à lire ». C’est lui qui fait basculer l’hôte du mode texte au mode affichage.
csp
Les seules origines extérieures que la page pourra joindre. Tout le reste est refusé par défaut : l’isolation n’est pas déclarative de la part du service, elle est imposée par l’hôte.
Le piègeC’est le point qui sort du régime habituel du lexique. Partout ailleurs, ce qui revient d’un outil est du texte que le modèle lit ; ici, ce qui revient est du code que la personne voit. Le modèle, lui, ne voit toujours que du texte.
03
Ce que l’interface a le droit de faire
La page affichée ne peut rien exécuter elle même : elle demande, et l’hôte arbitre. Le canal est un simple échange de messages entre le cadre isolé et la page qui le contient, dans la même enveloppe JSON-RPC que le reste.
js
```
// dans le cadre isolé : la vue se présente, puis attend qu'on la nourrisse
await hote.demander('ui/initialize', { appCapabilities: {} });
hote.sur('ui/notifications/tool-result', (r) => dessiner(r.content));

// la personne clique : la vue ne fait rien, elle DEMANDE
bouton.onclick = () =>
  hote.demander('tools/call', {
    name: 'meteo_ville',
    arguments: { ville: 'Lyon' },
  });

// l'hôte applique alors le consentement et les droits de la session,
// exactement comme si le modèle avait produit la demande lui-même.
// Une interface n'ouvre donc aucun raccourci : elle emprunte le même
// point de contrôle, celui de l'exécution.
```
ui/initialize
La poignée de main. La vue annonce ce qu’elle sait faire, l’hôte répond ce qu’il autorise : ouvrir un lien, écrire dans la conversation, appeler tel outil et pas tel autre.
tools/call
La même méthode que celle du modèle. C’est la garantie architecturale de l’extension : deux demandeurs, un seul chemin d’exécution, donc un seul endroit à contrôler et à journaliser.
Le piègeLe cadre isolé empêche la page d’atteindre l’application hôte, ses jetons et son stockage. Il n’empêche pas ce qu’elle affiche d’être trompeur : un bouton peut porter un libellé qui ne correspond pas à l’appel qu’il déclenche, et c’est l’hôte, pas le service, qui doit montrer ce qui va réellement s’exécuter.

Montré ailleurs

appel d’outilsle tour de boucle et les quatre contrôles, identiques que l’outil vienne d’ici ou d’ailleurs
contextelà où atterrissent les descriptions annoncées par chaque service branché

Ce qui varieC’est le seul bloc du lexique dont le contenu suit une spécification datée, donc le seul à relire quand elle bouge : le cœur du protocole est versionné par date de révision, et l’extension qui porte les interfaces l’est séparément. Les noms de méthodes et de champs cités ici valent pour les révisions en vigueur à la date de cette fiche. Ce qui ne varie pas : une enveloppe JSON-RPC, un service qui décrit sans jamais exécuter chez vous, un hôte qui reste le seul point d’exécution, et une interface isolée qui doit repasser par ce point comme tout le monde.

Exemples datés

2026-08

Le protocole s’est imposé en moins de deux ans comme le mode de branchement par défaut des outils, adopté par la plupart des éditeurs de modèles et des environnements de développement. Des annuaires publics de services prêts à brancher se sont constitués, avec la difficulté qui va avec : rien ne garantit ce que fait réellement un service tiers auquel on ouvre ses données. Les premiers avis de sécurité publiés sur le sujet portent moins sur le protocole lui-même que sur la confiance accordée aux services branchés et sur l’étendue des droits qu’on leur consent.

Deux révisions structurent l’état actuel. La spécification du 28 juillet 2026 retire les sessions du cœur du protocole : chaque requête se suffit à elle même et peut être servie par n’importe quelle instance, ce qui aligne le protocole sur l’infrastructure HTTP ordinaire et simplifie sa mise à l’échelle. Elle formalise en même temps un mécanisme d’extensions versionnées séparément, négociées entre le client et le serveur. La première d’entre elles, publiée en janvier 2026, est celle qui porte les interfaces : un service peut renvoyer une page HTML que l’hôte affiche dans un cadre isolé, avec un canal de messages pour la nourrir et lui laisser demander des appels. Une seconde extension couvre les traitements longs, en rendant une prise sur laquelle le client revient au lieu de tenir une connexion ouverte.

Relations où vivent les voisins

S’exécute dans: harnais
Requiert: outil
Souvent confondu avec: API

Vérifier 3 questions · cliquez votre réponse

Niveau 1 · Reconnaître

Un produit annonce qu’il prend en charge ce protocole. Qu’est-ce que cela vous apprend sur son modèle ?

Niveau 2 · Distinguer

Quelle différence entre exposer une interface de programmation et exposer un service conforme à ce protocole ?

Niveau 2 · Distinguer

Vous branchez trois nouvelles sources de données par ce protocole. Qu’avez-vous gagné ?

Nº 039 · v2026-08 · première rédaction en août 2026 · responsabilité éditoriale Anthony Capirchio

Citer cette fiche

Lexigraph, « MCP », v2026-08, https://www.lexigraph.org/fr/mcp/, CC BY 4.0.

MCP