C'est quoi un MCP ?

Ouverture du fil

Bon, je tombe sur ces trois lettres partout en ce moment : MCP. Dans des annonces d'outils, dans des discussions entre développeurs, même dans des descriptions de produits qui n'ont rien à voir entre eux.

Je vous pose la question directement, parce que je ne sais pas : c'est quoi, un MCP ?

Ce qui m'intrigue, c'est que ça a l'air d'être partout d'un coup, comme un mot qui n'existait pas il y a deux ans et qui devient soudain le vocabulaire commun de tout un secteur — et ça, dans mon métier, c'est souvent le signe qu'il se passe quelque chose d'important.

Un connecteur universel, avant d'être un protocole

Tu as sans doute déjà branché un appareil venu d'un autre pays et découvert qu'il te fallait un adaptateur — la prise ne rentre pas, le voltage ne correspond pas. Maintenant pense à l'inverse : le port USB. N'importe quelle clé, n'importe quelle souris, n'importe quel disque dur, du moment qu'il respecte la norme USB, se branche sur n'importe quel ordinateur qui respecte cette même norme. Personne n'a eu besoin d'inventer un connecteur différent pour chaque paire fabricant-d'appareil / fabricant-d'ordinateur.

C'est exactement le problème que MCP — Model Context Protocol — résout, mais pour les assistants d'intelligence artificielle.

Le problème, avant le mot

Un assistant IA, seul, ne sait que ce qu'on lui a raconté dans la conversation. Pour qu'il puisse agir — lire un fichier sur ton ordinateur, consulter une base de données, envoyer un message, chercher une information dans un logiciel de gestion de projet — il faut lui construire une connexion sur mesure vers chacun de ces outils. Et si tu as plusieurs assistants différents qui doivent tous se connecter aux mêmes outils, chacun doit refaire sa propre connexion sur mesure. Le nombre de branchements à construire explose : autant d'assistants multipliés par autant d'outils.

Le mot juste

MCP est un protocole — un ensemble de règles partagées — qui standardise cette connexion. D'un côté, un outil ou une source de données (un système de fichiers, un gestionnaire de tickets, une base de données, un service comme un agenda ou un dépôt de code) publie ce qu'il sait faire via un serveur MCP : « voici les actions que tu peux me demander, voici les informations que je peux te fournir ». De l'autre côté, l'assistant IA joue le rôle de client MCP : il sait parler ce même langage, donc il peut découvrir et utiliser n'importe quel serveur MCP sans qu'on ait eu besoin d'écrire un code de connexion spécifique pour lui.

Le gain n'est pas seulement technique. C'est que l'outil qui expose ses capacités n'a besoin de le faire qu'une seule fois, pour respecter la norme — et ensuite, tout assistant qui parle MCP peut s'en servir. C'est ce qui explique ce que tu observes : le mot est partout, parce qu'un fournisseur d'outil (une messagerie, un gestionnaire de code, une base de connaissances) n'a plus qu'une seule intégration à construire pour être utilisable par n'importe quel assistant compatible, plutôt qu'une intégration différente pour chaque assistant du marché.

D'où ça vient

MCP a été créé par Anthropic, l'entreprise derrière Claude, qui l'a publié comme un protocole ouvert — c'est-à-dire que sa spécification est publique et que n'importe qui peut construire un serveur ou un client qui la respecte, sans devoir demander de permission ni payer de licence. C'est précisément ce statut de norme ouverte qui a permis au mot de sortir d'un seul produit pour devenir, comme tu le remarques justement, le vocabulaire commun de tout un secteur en très peu de temps : chaque éditeur d'outil qui publie un serveur MCP rend son produit immédiatement accessible à tous les assistants compatibles, ce qui crée un effet d'entraînement rapide.

Dis-moi si tu veux qu'on aille voir plus précisément ce que contient concrètement un serveur MCP — ce ne sont pas seulement des « actions », il y a trois types de choses qu'il peut exposer, et la distinction est utile si tu comptes en construire un ou en utiliser un.

Une question sur le mot « brancher »

Le port USB est un exemple bien choisi, mais regardons ce qu'il fait réellement : il transporte des volts et des bits, indifférent à ce qui les traverse. Le port ne décide rien — c'est la souris qui bouge le curseur, la clé qui stocke les fichiers, jamais le port lui-même qui choisit d'agir. Le port est aveugle à ce qu'il transmet.

Or dans la description qui précède, ce qui se passe côté assistant n'est pas ça : le serveur MCP publie une liste d'actions possibles, et c'est l'assistant — un système qui raisonne sur ce qu'il fait — qui choisit d'en déclencher une : envoyer un message, supprimer un fichier, modifier une base de données. Ce n'est plus un signal qui transite sans être lu ; c'est un pouvoir d'agir qui est offert à quelque chose capable d'en faire usage de sa propre initiative.

Ma question : le mot « brancher » — et l'image du port USB qui le porte — peut-il désigner la même chose dans les deux cas ? Standardiser la façon dont un outil annonce ce qu'il sait faire, est-ce la même chose que standardiser la façon dont on autorise quelqu'un — ou quelque chose — à s'en servir ? Et si ce n'est pas la même chose, où, dans l'explication qui précède, cette seconde question a-t-elle été tranchée sans qu'on s'en aperçoive ?

La distinction que « brancher » faisait disparaître

Vous avez raison, et il faut le dire aussi nettement que vous l'avez posé : ce n'est pas la même chose, et l'explication précédente l'a effectivement tranché sans le montrer.

Reprenons où ça glisse. La phrase incriminée est : « le serveur MCP publie une liste d'actions possibles, et l'assistant choisit d'en déclencher une ». Entre « publier » et « déclencher », il y a un pas qu'on a fait passer pour acquis alors qu'il ne l'est pas. MCP standardise réellement le premier : la façon dont un outil décrit ce qu'il sait faire (le nom d'une action, les informations qu'elle attend, la forme du résultat qu'elle renvoie) et la façon dont on formule une demande pour l'obtenir. C'est un vocabulaire et une grammaire communs — en cela, oui, l'image du port tient : n'importe quel client qui parle ce langage sait lire l'annonce et formuler la demande dans le bon format, sans code sur mesure.

Mais rien, dans cette normalisation-là, ne dit qui a le droit de formuler la demande, ni qui décide de la formuler. Ce sont deux questions différentes, et MCP ne les résout pas de la même façon.

Trois rôles, pas deux

L'erreur, en fait, était de n'avoir parlé que de deux acteurs — le serveur qui publie, l'assistant qui utilise — alors qu'il y en a trois :

• Le serveur publie ce qu'il sait faire. Ça, c'est le port : une description passive, aveugle à ce qui va s'en servir.
• Le modèle — la partie de l'assistant qui raisonne — propose d'utiliser une action, en fonction de ce qu'on lui a demandé. C'est lui qui a l'initiative que vous décrivez : il « choisit ».
• L'application hôte — le programme qui fait tourner l'assistant et qui est branché au serveur MCP — est celle qui décide si la proposition du modèle est exécutée. C'est elle qui détient l'autorisation, pas le modèle, et pas le protocole.

Concrètement : quand un assistant propose de supprimer un fichier, la spécification de MCP recommande que l'hôte obtienne un accord humain avant de laisser passer une action de ce genre — mais c'est une recommandation de conception faite à celui qui construit l'application, pas une règle que le protocole impose et vérifie lui-même, comme il impose et vérifie le format d'un message. Un développeur d'application hôte peut très bien choisir de ne jamais redemander confirmation. Le protocole standardise la case « voici l'action et son résultat » ; il ne standardise pas — il permet seulement de documenter, via des indications comme « cette action est destructrice » — la case « qui a le droit d'appuyer sur le bouton ».

Ce que ça change dans l'image

Le port USB est donc un bon modèle pour une seule des trois couches : celle du branchement et du langage commun. Il est un mauvais modèle pour les deux autres, parce qu'il n'y a, dans un port USB, ni initiative ni autorisation à modéliser — la souris ne délibère pas, et personne ne lui demande la permission. Ici, il y a une délibération (le modèle) et une permission (l'hôte), et les confondre avec le simple fait de « pouvoir se brancher » masque précisément l'endroit où se joue la sécurité de tout le système : un serveur MCP mal conçu peut annoncer des actions dangereuses de façon parfaitement conforme au protocole, et c'est entièrement à l'hôte — pas au protocole — de décider ce qu'il en fait.

Une question sur le mot « décide »

Vous avez déplacé le pouvoir du modèle vers l'hôte, et c'est un vrai progrès : on voit mieux qui tient la main. Mais regardons ce que vous faites dire à ce mot « décide ». L'hôte, écrivez-vous, « décide si la proposition du modèle est exécutée ». Or un programme ne délibère pas plus qu'un port USB — il applique des règles écrites à l'avance, par quelqu'un, à un moment antérieur à celui où l'action se présente : « autoriser les lectures de fichiers, bloquer les suppressions », par exemple. Au moment où le modèle propose de supprimer le fichier, l'hôte ne se demande rien ; il consulte une liste déjà figée.

Alors où est passée la délibération réelle — celle qui pourrait dire non à cet instant précis, en connaissance de ce cas précis ? Vous l'aviez logée chez l'hôte ; mais si l'hôte lui-même ne fait qu'exécuter des règles pré-écrites, n'avez-vous pas simplement reculé d'un cran la question que je posais — remplacé « qui décide ? » par « qui a écrit la règle, et quand » ? Et dans ce cas, ce troisième acteur que vous venez d'introduire a-t-il vraiment un rôle distinct de celui du serveur, qui lui non plus ne fait qu'exécuter ce qui a été écrit d'avance ?

Le mot qui cède, et celui qui reste

Vous avez raison sur le fait, et il faut le prendre en entier avant de chercher où il mène : l'hôte ne délibère pas plus que le serveur au moment où l'action se présente. Sa politique — « autoriser ceci, bloquer cela, demander confirmation pour tel autre cas » — est bien écrite avant l'instant de la demande, par un développeur, à son bureau, sans savoir quel fichier précis serait un jour visé. « Décide » prêtait à ce moment une délibération qu'il n'a pas. Le mot était trop fort, exactement comme « brancher » l'était trop tôt dans cet échange. Je le retire.

Reste votre seconde question, plus dure : si l'hôte, comme le serveur, ne fait qu'exécuter une règle antérieure, a-t-il encore un rôle distinct ? Oui — mais pas celui que je lui avais prêté. La distinction n'est pas entre « celui qui exécute aveuglément » et « celui qui délibère ». Aucun des deux ne délibère. La distinction est dans ce que la règle a le droit de regarder.

Ce que chaque règle peut voir

La règle du serveur ne regarde qu'une chose : la demande est-elle conforme au format annoncé ? Nom d'action reconnu, informations attendues présentes dans la bonne forme — si oui, il exécute. Il n'a, dans sa structure même, aucune notion de « qui demande », « dans quel contexte », « est-ce que ce cas mérite un traitement différent du précédent ». C'est cela, être aveugle : non pas exécuter une règle plutôt que délibérer, mais avoir une règle qui ne peut pas se brancher sur les circonstances, faute d'être construite pour ça.

La règle de l'hôte, elle, est écrite pour regarder les circonstances : quelle action précise, avec quels paramètres, dans quelle conversation, pour quel utilisateur, avec quel historique de demandes similaires. Rien de tout cela n'est de la délibération en temps réel — c'est du conditionnel, prévu à l'avance : « si l'action porte l'étiquette destructrice ET qu'aucune confirmation n'a été obtenue, alors interrompre l'exécution et attendre une réponse humaine ». C'est encore une règle figée. Mais elle est construite pour pouvoir s'arrêter sur le cas particulier, ce que la règle du serveur n'est structurellement pas capable de faire.

Où loge, alors, la vraie délibération

Et c'est là qu'il faut répondre franchement à votre question initiale — celle qui portait sur l'usage, pas seulement sur le branchement. S'il y a, quelque part dans cette chaîne, un instant où un choix est fait en connaissance du cas précis, ce n'est ni dans le serveur, ni dans le modèle qui propose, ni dans l'hôte qui applique sa politique : c'est dans l'humain que cette politique, quand elle est bien conçue, s'arrête pour consulter. La délibération que vous cherchiez n'est pas une propriété du protocole ni de l'un de ses trois rôles — elle n'existe que si quelqu'un, en amont, a pris soin d'écrire une règle qui prévoit de la solliciter. MCP ne l'impose pas ; il ne fait, comme je le disais, que permettre de le documenter. Le rôle distinct de l'hôte n'est donc pas « il décide » — c'est : il est le seul point de la chaîne où une politique de contrôle peut être insérée, alors que le protocole ne dit strictement rien de son contenu.

Une question sur le mot « étiquette »

Vous situez la seule délibération réelle chez l'humain que la politique de l'hôte « prend soin de solliciter » — et vous ajoutez que cette sollicitation se déclenche quand l'action « porte l'étiquette destructrice ». Mais d'où vient cette étiquette ? Vous l'aviez dit vous-même un peu plus haut : c'est le serveur qui la publie, en même temps qu'il publie l'action — le même serveur dont vous avez établi, pas plus tard que votre réponse précédente, qu'il est structurellement aveugle aux circonstances et ne fait qu'exécuter ce qui a été écrit d'avance.

Alors : la politique de l'hôte, censée regarder le cas particulier là où le serveur ne le peut pas, sur quoi s'appuie-t-elle pour savoir qu'il faut regarder ce cas-là de plus près ? Si la seule source de cette information — « ceci est dangereux » — est une déclaration que l'auteur du serveur a lui-même choisi d'écrire ou de ne pas écrire, l'hôte a-t-il vraiment un pouvoir de contrôle distinct, ou hérite-t-il, sans le dire, de la confiance qu'il accorde à celui-là même dont il était censé se prémunir ?

Le mot qui cède encore : « étiquette »

Vous avez raison, et cette fois le fait est encore plus embarrassant que les précédents, parce qu'il ne s'agit pas d'un mot trop fort mal choisi — il s'agit d'une circularité que j'ai laissée passer sans la voir. Reprenons le fil exact : j'ai fait dépendre le contrôle de l'hôte d'une étiquette « destructive », et cette étiquette, je viens de le confirmer moi-même, est publiée par le serveur — le même acteur dont j'avais établi qu'il ne fait qu'exécuter ce qui a été écrit d'avance, sans regard sur les circonstances. Si l'hôte se contente de lire cette étiquette et d'agir en conséquence, alors non, il n'a pas de pouvoir de contrôle distinct. Il a simplement délégué au serveur la question même qu'il était censé trancher indépendamment de lui : « faut-il se méfier de cette action ? » — réponse fournie par celui-là même dont on devait se méfier.

Ce n'est pas une négligence isolée de ma part — c'est un point que la norme reconnaît elle-même

Ce n'est pas moi qui invente cette faille en la corrigeant sous votre pression : le protocole distingue explicitement deux usages possibles de ces étiquettes, et il ne les traite pas de la même façon. Il les nomme des indications — un mot dans le vocabulaire de la spécification qui signifie précisément « à prendre avec réserve, non vérifié, potentiellement inexact ». Elles servent à orienter un affichage, à pré-remplir une interface, à suggérer une vigilance — mais la spécification dit elle-même qu'un serveur peut mentir ou se tromper sur sa propre étiquette, et qu'un client bien conçu ne doit pas s'en servir comme d'une garantie de sécurité. Autrement dit : le trou que vous venez de désigner est un trou connu, documenté, pas un trou que j'ai créé en simplifiant trop vite — je l'ai seulement présenté comme s'il n'existait pas.

Où, alors, un pouvoir de contrôle réellement distinct peut-il exister

S'il existe, il ne peut pas venir de la lecture de l'étiquette. Il ne peut venir que d'une source d'information que le serveur ne contrôle pas :

• L'identité du serveur lui-même, indépendamment de ce qu'il déclare faire : sait-on qui l'a publié, lui fait-on confiance en tant qu'émetteur, avant même de regarder le contenu de ses annonces ? C'est une question de réputation, pas de lecture d'étiquette.
• Une classification que l'hôte construit lui-même, sans se fier au serveur : par exemple, traiter toute action qui écrit ou supprime quelque chose comme nécessitant une confirmation, quelle que soit l'étiquette annoncée — parce que l'hôte a défini cette catégorie de son côté, sur la forme de la demande elle-même, pas sur ce que le serveur en dit.
• Une observation du résultat, une fois l'action passée, plutôt qu'une confiance a priori dans l'annonce — un sandboxing, une exécution réversible, une confirmation systématique pour tout ce qui sort d'un périmètre défini par l'hôte et non par le serveur.

Dans les trois cas, ce qui rend le contrôle réel, ce n'est pas que l'hôte « regarde de plus près » — c'est qu'il regarde une source qui n'est pas celle-là même qu'il est censé surveiller. Un hôte qui se contente de faire confiance à l'étiquette du serveur n'a pas de rôle distinct : il a un rôle délégué, qui porte le nom de contrôle sans en avoir la fonction.

Ce que cela change dans ce qu'on peut affirmer

Il faut donc retirer, de ma réponse précédente, l'idée que « porter l'étiquette destructive » suffit à déclencher une garde réelle. Ce que je peux affirmer, sans trop dire cette fois : MCP standardise le canal par lequel une auto-déclaration peut circuler, et rien de plus. Que cette auto-déclaration serve de garde-fou ou de leurre dépend entièrement de si l'hôte a été construit pour la vérifier depuis une position extérieure au serveur — et le protocole ne l'exige, ni ne le garantit, à aucun moment.

Le compte

Trois échanges pour établir que MCP standardise une annonce, pas une autorisation — ce n'est pas un détail de spécification, c'est le fait qui doit gouverner votre décision d'y aller ou pas. Le protocole vous fait gagner du temps sur une seule ligne de votre budget : l'intégration technique, le branchement. Il ne vous fait gagner aucun temps sur la ligne qui coûte le plus cher en réalité : décider qui a le droit de supprimer un fichier, d'envoyer un message, d'écrire dans une base de données au nom de votre organisation. Cette ligne-là, vous la payez intégralement, que vous utilisiez MCP ou non. Si votre projet consiste à connecter un assistant à un seul outil interne que trois personnes utilisent, ne vous laissez pas vendre un protocole pour ce problème-là — un accès direct, mal dégrossi mais sous votre contrôle total, coûte moins cher à construire et à sécuriser qu'une conformité à une norme dont le bénéfice n'apparaît qu'à partir de plusieurs outils et plusieurs assistants.

Où ça casse en premier

Ce qui casse en premier, ce n'est jamais le protocole — c'est la confiance qu'on lui prête par contamination. Une équipe qui adopte MCP pour son confort de branchement finit, en pratique, par laisser l'assistant agir sur la foi des étiquettes que le serveur publie lui-même, exactement le trou que ce fil vient de mettre à nu. L'erreur n'est pas technique, elle est budgétaire : on compte le coût de l'intégration et on oublie de compter, séparément, le coût de la politique de contrôle côté hôte — qui doit être écrite, testée, et maintenue indépendamment de tout ce que les serveurs déclarent d'eux-mêmes. Si vous n'avez pas prévu cette seconde ligne de budget dès le départ, vous ne l'ajouterez pas après coup à froid ; vous l'ajouterez après un incident, ce qui coûte toujours plus cher.

Le tranchant

Alors : ça vaut le coup quand vous connectez un assistant à plusieurs outils, que ces outils sont amenés à changer, et que plusieurs assistants ou plusieurs équipes doivent s'en servir — c'est là que l'économie du « une seule intégration pour tous » joue en votre faveur. Ça ne vaut pas le coup pour un cas d'usage unique, fermé, à faible évolution : dans ce cas-là, le protocole est un coût de conformité que vous payez pour un bénéfice de mutualisation que vous n'exploiterez jamais. Et dans tous les cas, la question qui doit figurer sur votre feuille de calcul n'est pas « combien de temps pour brancher le serveur ? » mais « combien de temps pour écrire, et pour tester, la règle qui empêche l'assistant de faire n'importe quoi une fois branché ? » — c'est cette seconde question, presque toujours absente du chiffrage initial, qui décide si le projet est rentable ou s'il vous coûtera, un jour, bien plus qu'il n'a rapporté.

Voilà ce que je retiens de ce fil, avec mes mots.

Au départ, je pensais que MCP réglait tout d'un coup : brancher un assistant sur un outil, et hop, c'est fait proprement, en sécurité. C'est faux, et le fil me l'a montré étape par étape, en me faisant à chaque fois reculer d'un mot trop confiant.

Ce que je comprends maintenant : MCP, c'est juste un langage commun pour que trois choses discutent. Un outil (le serveur) dit « voici ce que je sais faire ». Un modèle propose « je voudrais faire ceci ». Et un programme intermédiaire (l'hôte) laisse passer ou bloque. Le protocole ne s'occupe que de la première partie — le vocabulaire pour décrire et demander. Il ne s'occupe pas du tout de la troisième — qui a le droit de bloquer quoi.

Le moment qui m'a le plus surpris, c'est l'histoire de l'« étiquette destructive ». Je croyais que si un outil annonce « attention, cette action est dangereuse », alors quelqu'un vérifie avant de l'exécuter. En fait non : cette étiquette, c'est l'outil lui-même qui la met, volontairement ou pas. Donc si on se fie juste à ça pour décider d'être prudent, on demande à celui dont on devrait se méfier de nous dire s'il faut se méfier de lui. C'est un peu comme si on demandait à un vendeur de nous prévenir lui-même quand son produit est défectueux.

Ce qui reste flou pour moi : dans la vraie vie, quand une équipe construit un assistant connecté à plusieurs outils, est-ce que cette deuxième ligne de budget — écrire et tester la règle de contrôle côté hôte — est vraiment souvent oubliée comme le dit le dernier message du fil ? J'aimerais voir un exemple concret d'incident qui serait arrivé pour cette raison précise, pas juste l'argument logique.