MCP n’est pas mort : c’est un problème d’architecture, pas de protocole

Denis Yarats lâche une bombe sur X. Le cofondateur et directeur technique de Perplexity annonce en interne qu’ils abandonnent MCP — le Model Context Protocol, standard ouvert qui permet à un agent IA de découvrir et connecter des outils tiers dynamiquement — au profit d’APIs directes et de CLIs. En quarante-huit heures, le débat embrase la sphère IA francophone et anglophone. Un développeur poste qu’il a codé un wrapper CLI pour Playwright en trente minutes — « ça fonctionnait 100 fois mieux » — pour apprendre que Vercel l’avait déjà fait. « Thank god MCP is dead. Just as useless of an idea as LLMs.txt was. » Le consensus s’installe vite, comme toujours sur X.

Problème : tout le monde répond à la même question en parlant de trois problèmes différents.

Le procès instruit contre MCP — et ce qu’il révèle vraiment

Les griefs sont réels. Inutile de les balayer d’un revers de main.

La fenêtre de contexte saturée, d’abord. Dans la majorité des implémentations MCP observées dans la nature, les définitions de tools — des schémas JSON parfois massifs — sont injectées en totalité à chaque début de session, qu’elles soient utiles ou non. C’est le degré zéro de l’usage des tools : charger l’intégralité du catalogue au cas où, comme si un développeur importait toutes ses dépendances npm dans chaque fichier par précaution. Le résultat est mécanique : des milliers de tokens consommés avant que l’agent n’ait commencé à travailler. Ce problème est d’autant plus aigu que, comme je l’ai détaillé dans Comment les IA lisent le web, chaque token a un coût réel sur la qualité du raisonnement disponible pour la tâche elle-même.

L’authentification distribuée, ensuite. Connecter un serveur MCP tiers implique de lui confier des credentials, souvent via des flux OAuth bricolés sur des surfaces que personne n’a auditées. La promesse de sécurité de MCP repose sur un modèle de confiance que l’écosystème n’a pas encore résolu proprement.

L’activation et la désactivation manuelles, enfin. Les utilisateurs de Claude in Chrome via MCP le savent : jongler entre les serveurs actifs selon la tâche en cours n’a rien d’automatique. C’est une friction cognitive permanente.

Ces trois problèmes sont réels. Mais voilà ce qu’on omet systématiquement de mentionner : aucun des trois n’est dans la spec MCP. La spécification prévoit des primitives de sampling et de pagination pour les outils — des mécanismes qui permettent précisément de charger les définitions à la demande plutôt qu’en bloc. Personne ne les implémente. Ce qu’on juge en 2026, c’est un écosystème immature qui utilise un protocole puissant de la manière la plus naïve possible. Condamner MCP pour ça, c’est condamner SQL parce que quelqu’un a écrit SELECT * sur une table de cent millions de lignes.

Yarats a raison — mais il parle d’autre chose

Perplexity est un Product. MCP est un Enabler. Confondre les deux, c’est confondre une ligne directe avec le protocole 5G : la ligne directe est plus rapide pour un appel point à point, mais elle ne scale pas à un réseau.

Perplexity opère sur un pipeline déterministe et connu : search → rerank → generate. La topologie est fixe, définie au build, et la latence est une contrainte critique — c’est un produit grand public où chaque centaine de millisecondes compte. Dans ce contexte, câbler une API directe est la décision d’architecture correcte. Non pas parce que MCP est mauvais, mais parce que MCP répond à un problème que Perplexity n’a structurellement pas : la découverte et la composition dynamique d’outils inconnus au moment du build.

Le wrapper Playwright en trente lignes obéit à la même logique. L’environnement est connu, le besoin est fixe, l’agent n’a pas à découvrir quoi que ce soit dynamiquement. C’est de l’intégration directe bien nommée. C’est efficace, c’est la bonne décision pour ce périmètre — et ça n’a aucun rapport avec le problème auquel MCP s’attaque.

Dire que Perplexity abandonne MCP prouve que MCP est mort, c’est comme dire que Spotify n’utilise pas de WebSockets pour ses playlists statiques, donc WebSockets est une technologie inutile. L’outil et le cas d’usage ne se recoupent pas. Le verdict ne s’applique pas.

La carte que personne ne dessine — trois couches, trois problèmes

Le débat est confus parce qu’il mélange trois couches d’abstraction qui répondent à des compromis radicalement différents. La matrice ci-dessous oppose deux axes : la performance brute (latence minimale) et la capacité de composition dynamique (flexibilité maximale).

Couche 1 — LLMs.txt : la découvrabilité statique

LLMs.txt est le robots.txt de l’ère IA. Un fichier texte placé à la racine d’un domaine, pour déclarer aux agents et aux crawlers ce que le service est, ce qu’il autorise, et quelles pages sont pertinentes. Volontaire, léger, orthogonal aux deux autres couches.

Son cas d’usage principal est bien compris : améliorer la qualité de l’ingestion à la crawl-time. Mais son cas d’usage sous-estimé est plus intéressant : l’usage à la query-time, quand un agent autonome fetch le fichier avant d’interagir avec le service, pour comprendre ce qu’il peut faire et ce qu’il ne peut pas faire. C’est une forme de contrat déclaratif entre le service et l’agent — sans overhead de protocole, sans authentification, sans état. Latence quasi-nulle, flexibilité quasi-nulle. Utile précisément parce que limité.

LLMs.txt ne remplace rien. Il complète.

Couche 2 — API + CLI : l’intégration directe

La fondation. Mature, précise, performante. Le choix structurellement correct quand trois conditions sont réunies : l’environnement est sous contrôle de bout en bout, les outils sont connus au moment du build, et la latence est une contrainte. C’est le monde de Perplexity, de la plupart des pipelines de production actuels, et de Claude Code — dont les Hooks illustrent à la perfection ce que l’intégration directe bien architecturée permet d’accomplir sans aucune couche de découverte dynamique.

La performance est maximale. La flexibilité est sacrifiée — et c’est un choix assumé, pas un défaut.

Couche 3 — MCP : la composition dynamique

MCP devient pertinent quand les deux conditions précédentes disparaissent : l’environnement n’est pas entièrement contrôlé, et les outils ne sont pas tous connus au build.

Cas d’usage concret : un orchestrateur multi-tenant qui doit connecter des outils tiers à la demande selon les besoins d’un client spécifique. Une marketplace d’outils IA où les services s’ajoutent sans redéploiement de l’orchestrateur. Un environnement enterprise où les équipes changent, où les APIs internes évoluent, où un nouvel outil doit être disponible à l’agent le jour de son déploiement sans intervention sur le code central.

Dans ces contextes, la latence supplémentaire induite par la couche de découverte est un coût acceptable — et souvent négligeable face au coût humain de l’intégration manuelle. MCP ne remplace pas les APIs. Il s’appuie sur elles et ajoute une couche de négociation dynamique au-dessus.

Pour les lecteurs de ce blog : l’article WebMCP couvre précisément le moment où cette Couche 3 commence à infuser le navigateur — les sites web qui déclarent leurs capacités sous forme de tools structurés, découvrables dynamiquement. C’est le pont entre la Couche 1 et la Couche 3, et c’est déjà en early preview dans Chrome Canary.

Le précédent UDDI/WSDL — pourquoi ça avait échoué, et pourquoi cette fois c’est différent

Ceux qui ont une mémoire de l’industrie reconnaîtront le pattern. Dans les années 2000, UDDI promettait exactement ce que promet MCP aujourd’hui : la découverte automatique de services web, un annuaire universel où les applications pourraient trouver et composer des APIs tierces sans intégration manuelle préalable. Le W3C était derrière, IBM et Microsoft signaient des chèques. UDDI est mort d’une mort discrète et embarrassée.

La raison de l’échec est précise, et elle est instructive : les machines de l’époque ne savaient pas interpréter des schémas ambigus sans code généré au préalable. L’intégration restait humaine. Quelqu’un devait écrire le binding WSDL, tester les edge cases, gérer les versions. La promesse de la découverte automatique se heurtait à la réalité de l’interprétation — les services étaient découvrables, mais pas utilisables sans intervention.

Les LLMs changent exactement cette variable. Un agent peut aujourd’hui lire une définition de tool imparfaite, inférer l’intention du développeur, tolérer une ambiguïté dans le schéma, et composer l’appel sans qu’un humain ait écrit un binding. C’est la différence structurelle qui rend MCP viable là où UDDI ne l’était pas. Ce n’est pas de l’optimisme — c’est la conséquence logique de ce que les modèles de raisonnement font déjà en production.

La question de sécurité subsiste, et il faut la prendre au sérieux. Un serveur MCP mal configuré est une surface d’attaque réelle — un vecteur d’injection de prompts malveillants via des outils tiers compromis, un risque que des chercheurs en sécurité ont déjà documenté. La réponse architecturale correcte : le serveur MCP est un processus isolé par design, pas une injection dans le runtime principal. La menace n’est pas dans le protocole, elle est dans le déploiement négligent — ce qui est vrai de n’importe quelle dépendance tierce, de n’importe quel service OAuth, de n’importe quelle lib npm. Le sandboxing des serveurs MCP est un problème d’implémentation résolu dans les environnements sérieux. Ce n’est pas une raison d’enterrer le protocole.

« Les modèles avancés n’ont pas besoin de tout ça »

L’argument circule beaucoup. Il est vrai dans un contexte étroit, et dangereux généralisé.

Vrai pour : le développeur qui contrôle son environnement de bout en bout, connaît ses APIs, a câblé ses outils manuellement, et supervise chaque appel. Dans ce contexte, MCP est du surcoût inutile — et le reconnaître est une décision d’architecture saine, pas un aveu de faiblesse.

Dangereux généralisé : en environnement enterprise, les services changent, les équipes tournent, les outils s’ajoutent. Sans MCP, chaque évolution d’une API tierce déclenche une intervention humaine sur le wrapper. Ce n’est pas un bug visible, pas une panne spectaculaire — c’est une maintenance cognitive silencieuse qui s’accumule. La dette se rembourse à chaque onboarding d’un nouveau développeur qui doit comprendre comment tel wrapper appelle telle API dans telle version. Multipliez par cinquante outils, quatre équipes, deux ans de turnover.

Il y a aussi une dimension contextuelle souvent négligée : plus la fenêtre de contexte d’un modèle est large — et l’évolution vers le CAG va dans ce sens — plus le coût d’injection des définitions de tools complexes devient proportionnellement acceptable. Ce qui était prohibitif avec une fenêtre de 8K tokens devient anecdotique avec une fenêtre de 200K. L’argument du « contexte saturé » contre MCP a une date de péremption.

Ce que ça change — et ce que ça ne change pas

MCP survivra ou mourra sur la qualité de ses implémentations, pas sur sa spec. Les primitives sont là. La pagination des tools, le sampling à la demande, l’isolation des serveurs — les outils pour éviter les trois problèmes légitimement reprochés à MCP existent dans la spécification. L’écosystème doit mûrir pour les utiliser. Ce n’est pas une garantie de succès, mais c’est une condition nécessaire.

LLMs.txt restera un standard de niche utile — jamais universel, jamais sexy, mais fonctionnel pour ce qu’il fait. C’est suffisant.

Les APIs ne disparaissent pas. Elles sont la fondation sur laquelle LLMs.txt et MCP s’appuient. Toute la discussion sur les « abstractions inutiles » rate ce point : ce ne sont pas des remplaçants des APIs, ce sont des couches de coordination au-dessus d’elles.

Conclusion

« MCP is dead » est le signe que l’écosystème sort de la phase évangélisation. C’est en réalité une bonne nouvelle — non pas parce que MCP est mort, mais parce qu’on commence enfin à poser la bonne question : mort pour qui, et pour quel problème ?

La maturité d’une technologie se mesure précisément à ce moment : quand les gens cessent de se demander si elle est « bonne » ou « mauvaise » pour commencer à se demander dans quel contexte elle est pertinente. C’est le passage de l’évangélisation à l’architecture.

Ceux qui enterrent MCP aujourd’hui parce que Perplexity préfère les APIs directes sont exactement les mêmes qui, en 2007, expliquaient que l’iPhone n’avait pas besoin d’App Store — parce qu’il y avait déjà le web mobile. L’argument était techniquement défendable. Safari rendait des pages web. Les développeurs pouvaient coder des webapps. Steve Jobs lui-même l’avait dit avant de se raviser. Pourquoi une couche de distribution supplémentaire ?

On connaît la suite. L’App Store n’a pas remplacé le web mobile — il a créé un écosystème de composition dynamique au-dessus d’un réseau existant. Exactement ce que MCP tente de faire pour les agents. L’intégration verticale gagne toujours les batailles de court terme. L’écosystème ouvert gagne les guerres de long terme — quand il arrive à maturité.

La question n’est pas de savoir si MCP est mort. La question est de savoir si l’écosystème aura la patience de laisser le protocole mûrir — ou si les développeurs pressés, convaincus d’avoir trouvé mieux avec trente lignes de code, tueront dans l’œuf ce qu’ils auraient fini par utiliser dans deux ans.