L’arrivée du Web 2.0 2.0 : MCP

 (anildash.com)
2 points par GN⁺ 2025-05-25 | 1 commentaires | Partager sur WhatsApp
  • Le Model Context Protocol (MCP) est une spécification créée par Anthropic pour relier les LLM à des applications et systèmes externes, et il s’est diffusé comme une interface commune entre plusieurs plateformes après sa prise en charge par OpenAI dans ChatGPT
  • Même si la spécification est souple et incomplète, si plusieurs acteurs adoptent rapidement la même manière de faire, un protocole ouvert peut gagner en influence sur le web réel
  • La valeur d’origine du Web 2.0 était plus proche d’un écosystème de développeurs et d’utilisateurs construit par des API ouvertes et des outils interopérables que de sites sociaux fermés
  • MCP pourrait raviver, dans le sillage des outils de codage IA, l’espoir d’une plateforme programmable, alors que les grandes plateformes comme Facebook et Twitter ont affaibli les attentes en matière d’interopérabilité en fermant leurs API
  • MCP n’est pas une solution miracle, et il comporte aussi une forte exposition aux risques de sécurité ainsi qu’un manque de transparence dans le traitement des données, mais il peut offrir une nouvelle occasion d’exiger conformité aux standards et transparence

Pourquoi MCP s’est diffusé comme un standard

  • Le Model Context Protocol, ou MCP, est une spécification conçue par Anthropic pour Claude
    • Son objectif est de permettre aux LLM de demander des informations à diverses applications ou d’interagir avec d’autres systèmes
  • Quand OpenAI a pris en charge le même protocole dans ChatGPT il y a quelques mois, MCP s’est installé comme un standard adopté un peu partout
  • Son intégration à Windows montre aussi l’ampleur de sa diffusion
  • Le point important n’est pas tant le degré d’achèvement de la spécification que le fait que plusieurs acteurs ont rapidement adopté la même interface
  • MCP ressemble davantage à une spécification souple, mais il rappelle la manière dont le web a réussi par le simple fait d’être ouvert et fonctionnel

Ce que désignait à l’origine le Web 2.0

  • Le Web 2.0 ne désignait pas des sites fermés et propriétaires comme Facebook
  • Au cœur de la première communauté Web 2.0, il y avait un mouvement dans lequel plusieurs sites proposaient des API ouvertes, permettant aux développeurs et aux utilisateurs de relier personnes et données
  • Flickr, Del.icio.us et Upcoming étaient des sites emblématiques d’une époque qui a lancé des fonctionnalités comme les tags et le partage social
  • Des plateformes comme LiveJournal et Movable Type ont elles aussi influencé les travaux sur les standards ouverts autour des API et des protocoles
  • Les valeurs communes de l’époque étaient relativement claires
    • construire des outils, technologies et plateformes sur des données ouvertes et des protocoles ouverts
    • laisser le contrôle aux utilisateurs
    • permettre aux développeurs d’interagir avec les systèmes via des outils cohérents et interopérables

L’interopérabilité rompue par les plateformes fermées

  • Pendant toute une génération, il est devenu difficile pour les développeurs de considérer comme acquise l’interopérabilité entre applications et plateformes
  • Cela s’est accompagné de critiques affirmant que les grands VC et les leaders de la tech avaient mis fin à l’ère de l’ouverture
  • Les outils d’analyse de l’activité sur les réseaux sociaux ont connu des cas où produits et services destinés aux utilisateurs ont été interrompus quand les grandes plateformes sociales ont fermé leurs API
  • Des plateformes comme Facebook et Twitter ont brisé, pour beaucoup, les attentes du Web 2.0 autour des données ouvertes et des technologies interopérables
  • En conséquence, il est devenu courant que les utilisateurs aient du mal à gérer leurs réseaux comme ils le souhaitent
    • impossible de voir des photos Instagram intégrées dans la timeline Twitter
    • difficile d’utiliser des fonctions comme l’import ou l’export de followers, possibles sur le fediverse ou Bluesky
    • difficile de contrôler son réseau avec l’application de son choix

Ce que MCP pourrait rouvrir comme possibilités

  • L’essor de MCP, combiné à la popularité de l’IA chez les codeurs, nourrit l’idée que les plateformes peuvent s’ouvrir non seulement aux LLM, mais aussi à divers usages programmatiques
  • Le point clé est que d’autres plateformes ont adopté telle quelle la spécification créée par Anthropic
  • Quand une autre entreprise adopte fidèlement en second le protocole d’un tiers, l’ensemble de l’écosystème peut plus facilement fonctionner de la même manière
  • À l’inverse, copier, étendre puis finalement éliminer un protocole peut nuire à l’écosystème
  • Lorsqu’il existe une adoption de bonne foi autour d’une interface commune, la possibilité grandit de voir plusieurs outils et plateformes fonctionner ensemble

La difficulté de suivre réellement un standard

  • Prendre en charge un standard tel quel est plus difficile qu’il n’y paraît
  • Même lors du lancement d’un produit de cache sémantique pour plateformes IA, il n’a pas été facile de convaincre les développeurs d’utiliser simplement l’API ChatGPT standard
  • Les développeurs pensent facilement qu’ils peuvent « faire mieux », mais dès qu’ils s’éloignent du standard, le résultat peut au contraire empirer
  • Même une mauvaise spécification pleine d’incohérences peut être préférable si tout le monde l’implémente de la même façon
  • HTML aussi était une spécification incomplète à bien des égards, et pourtant le web a été construit dessus
  • L’Internet tout entier repose lui aussi sur plusieurs spécifications imparfaites

Exiger conformité aux standards et transparence

  • Une nouvelle génération de développeurs découvre la créativité et les possibilités qui naissent quand les outils et plateformes qu’elle apprécie utilisent les mêmes protocoles et formats
  • Des mouvements comme RSS, le podcasting, OpenID, OAuth et OpenSocial ont en partie conduit plus tard à des résultats comme le fediverse et ActivityPub
  • Développeurs, codeurs, passionnés de tech et utilisateurs ordinaires peuvent aussi exiger des plateformes un droit d’accès leur permettant de contrôler leur expérience par le code
  • Quand on accède à une plateforme via des standards ouverts comme MCP, il faut aussi exiger de la transparence sur ce qu’elle fait réellement
  • MCP est flexible, mais il laisse subsister plusieurs risques
    • manque de transparence sur la manière dont les plateformes traitent les données des utilisateurs
    • difficulté à savoir quelles actions se produiront lors d’interactions via MCP
    • risques de sécurité très élevés
    • le protocole ne traite pas suffisamment ces préoccupations

Les limites et les promesses d’une ouverture façon Web 2.0

  • MCP n’est pas une solution miracle qui résoudrait tous les problèmes de l’écosystème développeur
  • Il ne corrigera pas non plus l’emballement et la déformation du débat autour de l’IA
  • Mais il est possible que de jeunes développeurs, qui n’ont pas connu la période précédente du Web 2.0, profitent de MCP pour essayer de rapprocher le web de son architecture d’origine
  • Le web n’a pas été conçu comme une structure propriétaire ou contrôlée par quelques personnes dans une poignée de très grandes entreprises
  • Le web devait être programmable via des spécifications brutes adoptées à la hâte par tous, et ce plaisir de bricoler et hacker existait déjà avant même qu’un numéro de version soit associé au web

À lire aussi

1 commentaires

 
GN⁺ 2025-05-25
Avis de Hacker News

  • Ce que beaucoup de gens ratent avec MCP, c’est que cela convient bien aux logiciels d’entreprise.
    Les LLM sont des traducteurs généralistes, donc ils font une bonne colle pour raccorder des systèmes cloisonnés qu’il serait extrêmement difficile de connecter sans une couche intermédiaire relativement souple.
    C’est pour cela que le secteur du SaaS B2B sort des serveurs MCP et discute en interne de la façon de repenser les API et leurs limites en fonction des nouveaux usages.
    Le protocole n’est pas « prêt pour l’entreprise » selon plusieurs définitions, mais comme le dit l’auteur, ce n’est pas si important. L’histoire des standards montre que même des choses brouillonnes et « mauvaises » peuvent être largement adoptées si elles tombent au bon moment auprès des bonnes personnes.

    • MCP n’est rien d’autre que du RPC sur une connexion longue, et la plupart du temps c’est du WebSocket. À mon avis, le RPC est plus facile à configurer.
      Il y a moins de débats du genre : modifier un champ d’un objet utilisateur, est-ce un PUT qui remplace l’objet utilisateur d’origine ou un POST ? J’ai perdu pas mal de temps avec les verbes REST.
      Un LLM n’a pas non plus besoin de comprendre la sémantique REST d’une API. Il voit les méthodes RPC disponibles et appelle celle qui semble convenir. Pour moi, l’essentiel se résume vraiment à ça.
    • C’est un bon modèle pour gagner de l’argent. Chaque requête de données implique un aller-retour LLM payant.
      Ce n’est pas comme si les endpoints négociaient entre eux un schéma permettant des requêtes bon marché à l’avenir.
    • On a déjà REST et OpenAPI.
      Rien qu’avec ça, des fonctions comme l’auto-découverte sont possibles.
      Un endroit qui fournirait MCP fournira de toute façon aussi une API correcte.
    • Totalement d’accord. Les grandes entreprises sont pleines d’ingénieurs qui veulent construire des choses sympas de 9 h à 17 h, puis rentrer chez eux et oublier le travail jusqu’au lendemain.
      Quelle entreprise ne voudrait pas tirer un maximum de productivité de ses employés pendant les heures de travail ?

  • Le passage « par rapport à l’époque où de vieux Unixiens grincheux écrivaient les spécifications » me semble être l’une des nombreuses raisons de l’échec du web sémantique. Cela ne contredit pas non plus l’idée de l’auteur selon laquelle « le pire, c’est mieux ».
    Je pense que les gens se sont trop emballés pour le côté eXtensible de XML, et qu’une certaine lassitude s’est installée. XSL, XHTML, XSD, WSDL, XSLT, RDF, RSS, etc., il y en avait trop.
    Ce dont le monde avait besoin à l’époque, c’était d’un simple format d’échange, et JSON répondait à ce besoin, tandis que côté XML on était proche d’une forme d’astronautique architecturale appliquée aux formats de données.
    Mais je crois aussi que l’heure de XML est maintenant venue. On voit souvent du XML dans les prompts système divulgués d’acteurs comme Anthropic. Les LLM semblent assez bien gérer les formats de texte structurés, en particulier Markdown et XML.
    Cela dit, je pense que MCP est le mauvais modèle. Plutôt que d’ordonner au modèle de « tirer » lui-même le contexte, je pense que nous devrions « pousser » le contexte vers le modèle.

    • Observation intéressante. Récemment, en créant un langage d’expansion de macros pour JSON, je me suis beaucoup intéressé à XML/XSLT.
      J’avais quatre balises de macro (#=, #&, #?, #!) qui se remplaçaient chacune par le résultat de leur expansion : affectation, substitution, branchement conditionnel façon cond, appel de fonction définie par l’utilisateur. Et j’ai fini par comprendre que j’étais en train de recréer XSLT.
      Ce que je voulais vraiment, c’était XPath. C’est une façon de décrire comment parcourir un graphe en avant et en arrière selon plusieurs axes, et c’est réellement une excellente spécification.
      Puis j’ai trouvé BaseX https://basex.org/, qui permet d’importer des documents XML arbitraires comme base de données interrogeable et de les requêter avec XPath ou XQuery.
      Pour créer une interface fiable, sans hallucination, vers un jeu de données en langage naturel, la meilleure approche me semble être de passer le schéma XML dans le prompt système et de faire écrire au modèle les requêtes qui récupèrent les données.
    • Je ne vois pas comment « pousser le contexte plutôt que laisser le modèle le tirer lui-même » pourrait fonctionner dans les cas où les gens veulent qu’un stagiaire résolve quelque chose pour eux.
      Si l’on connaissait déjà l’information à l’avance, on aurait probablement résolu le problème soi-même.
      La valeur de MCP me semble plutôt être : « ne me fais pas apprendre à raccorder 15 sources, exécute plutôt les requêtes qu’il faut pour moi ».
    • Les balises XML fonctionnent bien avec les LLM. Mais la plupart du temps, ce ne sont que des balises XML.
      Personne™ ne donne à un LLM du vrai XML commençant par une déclaration XML, ni n’utilise les namespaces, XSLT, XML Schema, etc.
      C’est plutôt un assemblage arbitraire de balises façon SGML.
    • Dans mon code perso, je manipule parfois XML comme format source de documents, mais je finis toujours par m’en éloigner à cause de tous les petits détails autour de la syntaxe.
      XML est une grosse spécification qui va bien au-delà des chevrons, et qui cherche à couvrir tous les cas, à gérer correctement la sécurité et l’encodage des caractères.
      Du coup, « l’édition en texte brut » n’est pas très intuitive. Si vous saisissez quelque chose comme ce paragraphe, cela peut être parsé en mode compatibilité, mais ne pas être valide.
      Comme format d’échange, ou comme format chargé dans une application conçue pour lui, il a davantage de potentiel ; et les LLM n’auront clairement pas de difficulté à le comprendre, donc c’est un bon point.
      Beaucoup de problèmes passés venaient de programmeurs pressés, qui manquaient de temps et voulaient ajouter vite des fonctionnalités, en brandissant des spécifications fortement structurées comme une massue. Si trois programmes différents et trois auteurs répètent chacun « XML ? On peut faire ça avec une regex », ça devient le bazar.
      Personnellement, le format qui se rapprochait vraiment de ce que je voulais était BBCode. C’est excellent comme format source pour beaucoup de choses. Fondamentalement, cela reste une famille à chevrons, mais avec juste assez de structure et de flexibilité pour servir de syntaxe frontend généraliste.
      Les premières implémentations étaient du genre « on peut faire ça avec une regex », mais après des décennies d’épreuve du terrain, il existe aujourd’hui des parseurs plus élégants.
    • Le web sémantique a échoué parce qu’il n’a pas trouvé comment y insérer de la publicité.

  • Je pense l’inverse de la phrase selon laquelle « l’essor de MCP, alors que l’IA gagne en popularité chez les codeurs, donne l’espoir que les LLM puissent ouvrir d’autres plateformes pour les rendre programmables à n’importe quelle fin, et pas seulement pour les contrôler »
    MCP est voué à l’échec pour la même raison précise que le Web sémantique a échoué. Parce que si quelque chose n’est pas verrouillé, personne ne gagne d’argent
    Je me demande quelle part de ce que l’IA fait à notre place pour chercher sur le Web — pardon, de ce qu’on appelle le « deep-research » — aurait pu être résolue d’une meilleure manière
    Les restaurants auraient pu publier leurs menus sous forme de métadonnées, et n’importe qui aurait pu trouver les tacos les moins chers du Texas avec un script Python. Dans la réalité, on verrouille les données derrière des barrières artificielles d’une main, et de l’autre on construit de l’IA, jusqu’aux data centers, pour les contourner. À l’échelle macro, c’est juste stupide

    • Je suis d’accord. MCP ressemble à robots.txt qui aurait évolué vers une forme de vie plus avancée, mais cela revient toujours à peu près à « décrivez-nous vos ressources pour que nous puissions les exploiter »
      La précédente vague d’agents est morte parce qu’au final tout le monde a compris qu’on ne pouvait pas faire confiance à son propre code exécuté sur une machine dont tout est sujet à négociation. C’était l’époque de Java dans les années 90
      Fondamentalement, entre agents qui interagissent, il existe un problème d’asymétrie d’information conçu intentionnellement. Si on le supprimait, une grande partie de la société cesserait de fonctionner
    • Ce n’est pas seulement qu’on ne gagne pas d’argent en fournissant une API ouverte gratuite. Pour exploiter une telle API, il faut en réalité des ressources illimitées
      Peu importe combien de ressources on jette sur le problème, quelqu’un trouvera un moyen de les épuiser pour un gain minuscule
      MCP ne fera qu’aggraver le problème, avec des agents IA se ruant comme des nuées de sauterelles sur les serveurs MCP publics
      L’option stable sera probablement une tarification RPC à l’appel. Au moins, l’entité qui exploite le modèle ou l’agent jouera le rôle de chambre de compensation, donc c’est plus plausible qu’à l’époque des API du Web 2.0
      Le modèle de facturation le plus probable sera sans doute d’inclure ces coûts dans les abonnements. Cela semble être la meilleure manière d’aligner les incitations
    • Au début des années 2010, HATEOAS était le rêve : rendre la consommation d’API triviale, mais au final on n’est guère allé plus loin que la génération de swagger yaml
      La personne qui a nommé cela HATEOAS avait dès le départ préparé le terrain pour son échec
    • Je vois la popularité de MCP comme un effet secondaire de la bulle de surchauffe qui pousse l’IA en ce moment. C’est simplement l’une des choses plausibles que l’on peut faire avec l’IA
      S’il y avait une valeur « facile » à publier des données dans un format standard, les endpoints interopérables auraient été bien plus largement adoptés
      Par exemple en utilisant schema.org ou une ontologie commune générale. Mais dans la réalité, on trouve beaucoup de formats sur mesure qui nécessitent à chaque fois un SDK magique spécial
    • Le texte lisible par une personne ordinaire n’est pas une « barrière artificielle ». C’est la nature même de notre monde
      Ce qui est une barrière artificielle, c’est d’exiger des restaurants qu’ils publient leurs menus sous forme de métadonnées
      La beauté des nouveaux outils de traitement du langage naturel est là. Le propriétaire d’un restaurant n’a pas besoin d’apprendre JSON ni d’acheter un package logiciel qui génère du JSON
      Nous pouvons utiliser les données telles qu’elles sont. Le coût de création d’outils utiles tend vers zéro
      Ce sera imprécis, mais le langage humain l’est déjà par nature

  • Ceux qui pensent qu’avec MCP ils pourront accéder à tout me font un peu pitié
    Ces choses seront cachées derrière des dizaines de couches de vérification de paiement et d’authentification. Bien sûr, il y aura aussi des IP en liste d’autorisation, et évidemment ce sera de l’IPv4
    Tout ce que vous verrez, ce sera ERR 402;

  • Ce qui m’inquiète le plus avec MCP, ce n’est pas que le protocole soit mal fichu, mais que sa correction et son amélioration dépendent uniquement des équipes internes d’Anthropic et d’OpenAI
    Les gens qui conçoivent le protocole ne donnent pas l’impression d’être des ingénieurs qui l’implémentent réellement eux-mêmes
    Cela évoque vaguement un duopole à la Visa-Mastercard

  • Maintenant que les LLM peuvent lire la documentation d’API et s’y adapter, n’est-il pas moins nécessaire qu’avant de suivre une API standard ?
    Pour moi, l’avantage important est qu’on commence à s’attendre à ce qu’un site « ait » une API, qu’il respecte ou non la spécification MCP

    • La documentation de l’API peut être très mal rédigée
      Même si la documentation est bonne, un LLM peut générer du code erroné pour interagir avec l’API. Si l’on corrige le code généré et qu’on fait appeler ce code par le LLM pour interagir avec l’API, on est de toute façon déjà sur la voie d’une couche intermédiaire. En pratique, on fabrique un serveur « à la MCP »
      Donner à un LLM un accès direct à une API pose aussi des problèmes de sécurité et d’allocation des ressources. Le LLM a une connaissance limitée de la dernière fois où l’API a été appelée. Il peut l’appeler trop souvent, et si chaque appel coûte cher, cela peut produire une facture d’infrastructure imprévue
      Il existe beaucoup d’autres points de douleur potentiels que l’on résout en plaçant quelque chose au milieu
      Les personnes raisonnables peuvent diverger sur la question de savoir si ce « quelque chose » doit être MCP. Pour l’instant, cela semble fonctionner suffisamment bien pour permettre aux gens de faire ce qu’ils ont à faire

  • Nous pouvons désormais créer le Web sémantique. Il suffit que les organisations créent un petit protocole pour partager leurs DDL SQL CREATE TABLE sous forme de fichiers statiques lisibles par les apps MCP. Une extension optionnelle de MCP suffit
    On pourrait alors comprendre et interroger les données en utilisant les outils déjà existants qui relient les appels de fonctions IA/LLM à SQL, et ce serait le Web sémantique
    Cette approche comble le chaînon manquant qui a toujours bloqué le Web sémantique : l’absence d’incitation pour les entreprises à utiliser des « types de données » standard plutôt que des types de données propriétaires
    Avec MCPQ, c’est-à-dire MCP avec requêtes, les organisations auraient soudain une raison de coopérer au niveau de la structure des données

  • Il s’avère que le « Web sémantique » était depuis le début un Web syntaxique, et peut-être que cette fois sera la bonne

  • Je me demande combien de temps il faudra avant que quelqu’un crée un serveur MCP pour contrôler quelque chose comme des cafards
    Références :
    https://www.technologynetworks.com/informatics/news/robo-roa...
    https://www.sciencealert.com/scientists-turned-cockroaches-i...
    Et beaucoup d’autres exemples qui remontent à plus de dix ans

  • L’expression « à l’époque où les spécifications étaient rédigées par de vieux Unixiens tatillons » est assez drôle
    C’est amusant que cette génération imagine les « vieux Unixiens » comme des gens tatillons. Unix était pourtant la rébellion ultime du move fast and break things face à l’école du MIT
    Certaines choses ne changent pas, on dirait :-)