L’avènement du Web 2.0 2.0 : MCP

• Le Model Context Protocol (MCP) est adopté rapidement et s’impose comme un nouveau standard ouvert
• La valeur centrale de MCP ne réside pas dans la perfection, mais dans l’ouverture et l’interopérabilité
• Le véritable sens du Web 2.0 n’est pas celui de plateformes fermées, mais des API ouvertes et du partage des données
• Un mouvement de retour s’amorce, quittant l’ère de la fermeture pour retrouver les valeurs du Web ouvert
• L’adoption de MCP pourrait pousser les développeurs à exiger davantage de contrôle des plateformes et de transparence

---

MCP : l’émergence d’un nouveau Web ouvert

Ces derniers mois, l’intérêt des développeurs pour le Model Context Protocol (MCP) a explosé. Le point de départ remonte à 2023, lorsque Anthropic l’a conçu pour permettre à son propre système LLM (Claude) d’interagir avec diverses applications. Ensuite, OpenAI a pris en charge le même protocole dans ChatGPT, ce qui l’a rapidement imposé comme standard. Il est désormais en cours d’adoption sur de grandes plateformes, y compris Windows.

Ce qui est intéressant, ce n’est pas tant la clarté ou le degré d’achèvement de MCP que sa facilité d’usage et sa rapidité. Contrairement aux standards traditionnels, conçus de manière rigoureuse, MCP est une spécification plutôt ambiguë et définie de façon souple, mais sa grande force est qu’elle fonctionne réellement dans la pratique. Surtout, son importance tient au fait qu’il s’agit d’un protocole ouvert, utilisable par tous.

Le vrai sens du Web ouvert

Dans le Web réel, le véritable progrès se produit lorsque des standards imparfaits et un peu limités sont adoptés rapidement. C’est ce type de dynamique qui a rendu possibles des innovations comme « écoutez où que vous preniez vos podcasts ».

L’esprit du Web 2.0 visait un écosystème ouvert : API ouvertes, partage des données, et plus grand pouvoir de contrôle pour les utilisateurs et les développeurs. Il faut rappeler que des plateformes fermées comme Facebook sont précisément celles qui ont fait disparaître le Web 2.0. Autrefois, Flickr, del.icio.us, Upcoming et d’autres ont porté une culture centrée sur le partage et la connexion, et les discussions sur les standards ouverts d’API et de protocoles étaient actives sur des plateformes comme les live blogs.

Le retour de l’ouverture

Une génération plus tard, les attentes autour de l’interopérabilité remontent de nouveau. Pendant des années, on a vu se répéter les mêmes expériences : grandes entreprises technologiques verrouillant leurs API et faisant disparaître des services. Par exemple, l’outil d’analyse de données de réseau social créé par l’auteur a finalement été abandonné après le blocage de l’API par la plateforme. De telles politiques ont détruit la vision du Web 2.0 fondée sur l’ouverture des données et la compatibilité. Elles ont aussi rendu courants des problèmes comme l’impossibilité d’intégrer du contenu ou la limitation de la portabilité des données.

Mais avec l’arrivée de MCP, l’IA pourrait devenir le déclencheur d’un retour de la programmabilité et de l’ouverture. Le fait que plusieurs plateformes adoptent le même protocole peut créer un cercle vertueux sur le plan technique.

Lorsque les plateformes adoptent un protocole tel quel et respectent fidèlement sa standardisation, cela produit des effets positifs pour tout l’écosystème. L’auteur souligne que la volonté des développeurs de « faire mieux que la spécification » peut paradoxalement nuire à l’écosystème. Même HTML, par exemple, n’est pas une spécification parfaite, mais il a malgré tout servi de base à l’interopérabilité massive d’Internet.

L’importance du respect des standards

Une nouvelle génération de développeurs fait directement l’expérience de la puissance de l’innovation fondée sur un même protocole et un même format. Cette expérience pourrait raviver une forme d’attachement quasi obsessionnel aux standards ouverts. L’ambiance rappelle l’époque où des formats ouverts comme RSS, Podcast, OpenID, OAuth ou OpenSocial donnaient réellement du pouvoir aux utilisateurs.

Nous sommes désormais à un moment où l’initiative n’appartient plus uniquement aux grandes entreprises : les communautés de développeurs et d’utilisateurs peuvent elles-mêmes faire valoir leurs exigences. Chacun doit pouvoir demander aux plateformes le contrôle de l’expérience et la transparence, et lorsqu’un standard ouvert comme MCP est adopté, la transparence sur le fonctionnement interne de la plateforme et sur l’usage des données doit impérativement suivre. MCP est ouvert, mais reste encore insuffisant sur des points comme les mécanismes internes et les enjeux de sécurité, ce qui appelle des améliorations ultérieures.

Le possible retour de l’esprit du Web 2.0

MCP n’est pas une solution miracle à tous les problèmes, mais il pourrait servir de déclencheur pour raviver l’écosystème ouvert de l’ère Web 2.0. Les limites demeurent, notamment l’exagération du discours sur l’IA et l’absence de critique suffisante.

Cependant, chez les jeunes développeurs en particulier, la valeur d’un Web programmable et du dépassement de la fermeture est en train d’être redécouverte. Le Web n’était pas la propriété de quelques géants, mais un espace ouvert que chacun pouvait utiliser à sa manière ; MCP pourrait contribuer à faire revivre cette philosophie.

[GN⁺]

Avis Hacker News

• J’ai l’impression que beaucoup de gens passent à côté du fait que le cœur de MCP est bien adapté aux logiciels d’entreprise : les LLM peuvent jouer le rôle d’une sorte de traducteur universel, une couche intermédiaire flexible qui relie des systèmes difficiles à connecter entre eux. En pratique, l’adoption de serveurs MCP progresse aussi activement dans le secteur du B2B SaaS. En interne, les discussions se multiplient également sur l’ajustement des restrictions ou de la structure en fonction des usages des API. Même si le protocole n’est pas « enterprise-ready » à bien des égards, je pense que ce n’est pas si important. Dans l’histoire des standards, il a souvent suffi qu’une spécification imparfaite et « bricolée » réponde à la demande du marché pour être adoptée
  • Je comprends MCP comme une sorte de RPC fonctionnant sur une connexion longue, généralement basée sur WebSocket. Personnellement, je trouve le RPC plus simple, d’abord parce qu’il évite des débats inutiles dans la conception des endpoints REST, comme faut-il tout remplacer avec POST ou ne modifier que certains champs avec PUT ; ensuite parce que le LLM n’a pas besoin de connaître la terminologie ou la sémantique REST, il lui suffit de voir une méthode RPC pour l’appeler immédiatement. Au final, ces deux points sont de gros atouts
  • Du point de vue des entreprises, je veux souligner que MCP est un excellent modèle économique. Chaque requête de données est directement liée à l’exécution payante d’un LLM. En revanche, il est regrettable qu’avec MCP il n’y ait absolument aucune optimisation du type négociation de schéma pour rendre les futures requêtes moins coûteuses
  • On a déjà REST et OpenAPI, avec des capacités de self-discovery en quelque sorte. Je pars aussi du principe que les entreprises qui proposeront MCP fourniront de toute façon de bonnes API
  • C’est vraiment un point auquel j’adhère : dans les grandes entreprises, beaucoup d’ingénieurs se contentent de faire du bon travail entre 9 h et 17 h et ne pensent plus du tout à leur entreprise une fois la journée terminée. Du point de vue de l’entreprise, il est donc parfaitement logique de chercher à maximiser la productivité des employés pendant leurs heures de travail
• Je me demande combien de temps il faudra avant qu’apparaisse une expérience de contrôle d’une créature de type cafard via un serveur MCP. Il existe déjà depuis plus de dix ans de nombreux précédents, comme les expériences de robo-roach ou de cafard cyborg
• Autrefois, les développeurs Unix rédigeaient des spécifications très rigoureuses, mais les temps ont changé. J’aimerais avancer que cette rigidité et la fatigue liée à l’extensibilité ont été l’un des facteurs de l’échec des architectures basées sur XML. À l’époque, on avait des architectures excessivement complexes avec XSL, XHTML, XSD, WSDL, RDF, RSS, etc., ce qui a ouvert la voie au succès de formats simples comme JSON. Cela dit, j’ai aussi observé récemment un regain d’usage de XML, notamment dans les prompts système de LLM comme ceux d’Anthropic, où l’on utilise beaucoup de texte structuré comme XML ou Markdown. Malgré cela, je pense que le modèle MCP est mauvais : au lieu de demander au modèle d’« aller chercher » l’information, il vaut mieux la lui « pousser », c’est-à-dire fournir le contexte à l’avance
  • Ce qui est intéressant, c’est qu’en créant récemment un langage d’extension macro basé sur JSON, je me suis rendu compte que je réinventais en fait XSLT ou XPath. J’ai été impressionné par la spécification XPath, remarquable pour l’exploration de graphes. Des outils comme BaseX sont utiles parce qu’ils permettent d’importer du XML arbitraire dans une base de données puis de l’interroger avec XPATH/XQUERY. Si l’on veut créer pour un LLM une interface de données fiable afin d’éviter les hallucinations, je pense que la meilleure solution consiste à intégrer un schéma XML dans le prompt système et à lui faire générer des requêtes sur les données
  • Je me demande jusqu’où un « modèle où l’on pousse le contexte à l’avance » peut réellement aller. Si l’utilisateur connaît déjà l’information à l’avance, il résoudra simplement le problème directement ; et la plupart des besoins autour de MCP reviennent à dire : « traite juste la requête sans m’obliger à apprendre comment connecter 15 sources »
  • Les LLM gèrent bien le XML sous forme de tags, mais dans la pratique on n’utilise presque jamais de vrais blocs XML complets (<?xml version="1.0" encoding="UTF-8"?>, namespaces, schémas, etc.) ; on se contente généralement d’un assemblage de tags façon SGML
  • Je veux insister sur le fait que la vraie raison de l’échec du web sémantique, c’est qu’il n’a pas réussi à intégrer l’insertion publicitaire ni à se raccorder à un modèle économique
  • Je suis critique envers l’approche du « contexte poussé ». La capacité de traitement du contexte des LLM (context window) reste très limitée, donc il est optimal de ne transmettre que le strict nécessaire. Il y a davantage de chances de dépasser cette limite si chaque modèle peut sélectionner lui-même et pull uniquement le contexte dont il a besoin
• MCP donne l’espoir qu’avec la popularité de l’IA, différentes plateformes deviendront programmables pour toutes sortes d’usages, mais je pense au contraire que c’est voué à l’échec, car la raison de l’échec du web sémantique était aussi l’incapacité à bâtir une structure de revenus. Il en va de même pour les fonctions de « recherche » où l’IA explore le web en profondeur à votre place. Par exemple, on aurait pu publier les menus de restaurants sous forme de métadonnées pour automatiser des demandes comme « trouver les tacos les moins chers du Texas », mais dans la réalité on assiste à un affrontement d’infrastructures entre le verrouillage des données et les crawlers IA qui le contournent. Globalement, cela montre surtout l’inefficacité du système actuel
  • Au fond, MCP n’est qu’une forme évoluée de robots.txt. C’est essentiellement un modèle du type : « si vous décrivez bien mes ressources, je les exploiterai ». Dans les années 1990, les systèmes d’agents basés sur Java ont aussi échoué à cause des asymétries d’information entre agents, et je crains que si l’on supprimait complètement cette limite de conception, c’est tout le fonctionnement social et économique qui pourrait se gripper
  • Avant même la question du revenu monétaire, le vrai problème des API ouvertes est qu’à moins d’y consacrer des ressources pratiquement illimitées, la vague de bots de requêtes d’agents IA finit par épuiser les ressources et mène à la faillite. À long terme, j’estime qu’une tarification RPC en pay-per-call sera une alternative plus stable. Les opérateurs de modèles ou d’agents joueraient alors le rôle de chambre de compensation des paiements, et intégreraient ce coût dans les abonnements ou d’autres formules similaires
  • L’idéal architectural REST à la HATEOAS a été très à la mode au début des années 2010, mais en dehors d’outils d’automatisation comme les fichiers swagger yaml, il a disparu sans réelle extension pratique. À mon avis, son vocabulaire trop difficile a aussi contribué à son échec
  • Je ne suis pas d’accord avec l’idée que le texte lisible par l’humain serait une barrière artificielle. Exiger d’un restaurant qu’il sache produire du JSON ou qu’il adopte un logiciel est, au contraire, une véritable barrière artificielle. Grâce aux outils de NLP, on peut désormais exploiter les données existantes telles quelles, ce qui fait tomber les coûts de développement presque à zéro. Certes, il subsiste une part d’imprécision linguistique, mais c’est une caractéristique inhérente au langage humain, et je n’y vois pas un gros problème
  • En restant prudent puisque cela a été mentionné dans le cadre d’une critique du web sémantique, je pense qu’un restaurateur réellement motivé peut publier des métadonnées à tout moment, et que cela peut faciliter la mise en relation entre acheteurs et vendeurs. Avec les plugins WordPress, par exemple, il existe déjà un support pour des métadonnées comme schema.org/Restaurant, Menu, MenuItem, Offer. Au final, je soupçonne que le plus gros obstacle est plutôt le gatekeeping de services comme Cloudflare. C’est en pratique un vrai frein aux idées d’automatisation en Python
• Puisque les LLM peuvent lire la documentation d’API et s’y adapter automatiquement, je pense que le respect de standards d’API n’est plus aussi indispensable qu’avant. Indépendamment de l’adoption ou non de la spécification MCP, le simple fait qu’on s’attende désormais à ce que chaque site « fournisse une API » est déjà un changement majeur
  • Dans la réalité, la documentation d’API peut être médiocre, et le LLM peut donc générer du mauvais code ou de mauvais appels. Si l’utilisateur corrige cela puis le renvoie au LLM, on finit de toute façon par construire une couche intermédiaire, autrement dit un serveur de style MCP. Donner à un LLM un accès direct à une API présente aussi des risques en matière de sécurité et de gestion des ressources, avec par exemple la possibilité d’une explosion des coûts en cas d’appels excessifs. Il existe plusieurs autres pain points, dont certains sont précisément résolus par une architecture avec une interface intermédiaire comme MCP. Que cet « intermédiaire » doive nécessairement être MCP est une autre question, mais à ce stade c’est une solution tout à fait pratique
• Ce qui m’inquiète le plus avec MCP, ce n’est pas l’immaturité du protocole en soi, mais le fait que le pouvoir d’amélioration et de correction soit concentré entre les mains d’équipes internes chez des acteurs comme Anthropic ou OpenAI. J’ai aussi le sentiment qu’il s’agit d’une spécification restée au stade du brainstorming, éloignée des besoins réels des développeurs et des opérateurs. Cela évoque pour moi l’ombre d’un duopole à la Visa-Mastercard
  • Il y a aussi le cas de Microsoft qui a rejoint le steering committee
• Le « web sémantique » n’était au fond qu’une structure grammaticale, et j’ai l’espoir que MCP, lui, ait une réelle possibilité de mise en œuvre concrète
• Il existe cette idée selon laquelle « les grands développeurs Unix à l’ancienne étaient excessivement pointilleux », mais il y a là une ironie : Unix a aussi été l’un des berceaux de la culture du « tenter vite et casser vite ». Les générations changent, mais la nature profonde des choses ne change pas vraiment
• Il y a une inquiétude très concrète : MCP pourrait être détourné, comme le SEO de Google, pour propager de la publicité et du spam à destination des IA
• Je pense qu’il faut se méfier de l’illusion selon laquelle MCP permettra à tout le monde d’accéder facilement à toutes sortes de données. En réalité, on risque surtout de se retrouver face à des couches successives d’authentification payante, à des IP en liste blanche autorisée et à d’autres mécanismes de sécurité, si bien que pour l’utilisateur final la réalité la plus parlante sera simplement une erreur « ERR 402 »