MCP est-il mort ? Quand utiliser MCP pour l'IA d'entreprise

La semaine dernière, Charles Chen a publié « MCP is Dead  Long Live MCP ! », soutenant qu'une grande partie des critiques contre le Model Context Protocol (MCP) vise la mauvaise cible, et brouille souvent la frontière entre les cas où MCP est excessif et ceux où il résout de vrais problèmes.

Pour beaucoup de workflows locaux et mono-utilisateur, l'argument est juste. Si vous développez sur votre propre machine, avec un petit ensemble d'outils, et que vous contrôlez vous-même tout l'environnement, MCP peut ajouter une structure dont vous n'avez pas besoin.

Mais le problème est différent à l'échelle de l'entreprise. Vous n'essayez pas simplement d'aider un modèle à appeler un outil sur un seul laptop. Vous essayez de déployer l'IA de manière sûre et cohérente dans toute une organisation. Quand on prend du recul et qu'on regarde ce qu'il faut pour exécuter l'IA comme un service gouverné et observable pour des milliers de personnes, c'est là que MCP commence à compter.

La vraie question n'est pas de savoir si MCP est mort. C'est quand MCP ajoute une complexité inutile, et quand il fait réellement le travail à votre place ?

Là où l'article a raison

Le billet de Charles voit juste sur plusieurs points, surtout pour les développeurs individuels :

‍Pour les développeurs solo, les CLI sont souvent le meilleur outil. Si le modèle « connaît » déjà des outils comme curl, jq, git, psql ou aws grâce à l'entraînement, vous n'avez pas besoin de schémas ou de documentation supplémentaires pour en tirer de la valeur. Dans de nombreux cas, le modèle peut utiliser ces outils directement, ce qui coûte moins de tokens et se configure plus simplement.

‍Envelopper chaque endpoint REST dans MCP est excessif. Si vous faites seulement quelques appels à des API spécifiques depuis votre propre agent, des wrappers faits main ou de petites CLI peuvent parfaitement suffire. MCP n'améliore pas automatiquement ces appels.

‍MCP sur stdio est généralement la mauvaise abstraction pour des outils locaux. Pour un agent local et un outil local, un MCP basé sur stdio peut simplement ajouter de la structure sans apporter beaucoup de valeur. Un CLI léger peut être l'option la plus directe.

‍Le cycle de hype autour de « MCP pour tout » était réel. Pendant un temps, MCP a été présenté comme la réponse à tous les problèmes d'intégration, sans clarifier quand c'est réellement le bon choix et quand cela ajoute simplement de la complexité inutile.

Si vous ne faites qu'exécuter un seul agent sur votre propre machine, en parlant à quelques API que vous contrôlez, il est difficile de contester ces critiques.

Mais ce n'est pas ce que la plupart des entreprises essaient de faire.

La distinction qui compte vraiment

Le texte original met en avant deux distinctions qui comptent beaucoup, surtout du point de vue entreprise :

1. stdio local vs. MCP distant sur HTTP
2. Le laptop d'un utilisateur unique vs. tout le parc IA d'une entreprise

Sur votre laptop, vous contrôlez tout :

• Vous possédez les clés API.
• Vous êtes le seul utilisateur.
• Vous êtes à l'aise pour déboguer directement afin de comprendre ce qui n'a pas fonctionné.
• Vous n'avez pas besoin d'un modèle de permissions ni d'un journal d'audit pour savoir qui a lancé quoi.

À l'échelle d'une entreprise, les questions changent :

• Qui a le droit d'appeler quel outil, au nom de qui, et sous quelle identité ?
• Comment rendre les mêmes capacités disponibles sur plusieurs surfaces IA, comme les IDE, les chatbots, les agents, sans réécrire les intégrations à chaque fois ?
• Comment voir quels outils sont réellement utilisés, lesquels échouent, et où les agents se bloquent ?
• Comment maintenir les prompts, skills et docs à jour sur toutes ces surfaces ?

Ce ne sont pas des questions de conception de CLI. Ce sont des questions de plateforme.

C'est là que les serveurs MCP distants cessent de ressembler à de simples « wrappers d'API » et commencent à ressembler à une infrastructure partagée : une couche commune pour les outils, l'identité, la politique et la diffusion à l'échelle de l'entreprise.

Si vous voulez aller plus loin sur la manière dont nous avons mis cette infrastructure en œuvre en pratique, nous expliquons cela plus en détail dans notre article « Glean's MCP servers bring full company context to where your AI runs ».

Ce dont les entreprises ont vraiment besoin de cette couche

Si l'on enlève les détails du protocole pour se concentrer sur les résultats, la plupart des entreprises veulent les mêmes quatre choses de leur couche « IA-vers-outils » :

1. Auth centralisée, par utilisateur, et gestion des secrets

Dans une entreprise de 10 000 personnes avec cinq outils IA en jeu, « donnez simplement une clé API à l'agent » ne passe pas à l'échelle. Vous ne voulez pas que chaque développeur (ou chaque host d'agent) détienne des clés API longue durée pour Jira, Salesforce, Slack et les services internes. Vous voulez :

• Une seule connexion (OAuth ou SSO) au « gateway d'outils » de l'entreprise.
• Des jetons à durée de vie courte émis par utilisateur.
• La possibilité de révoquer l'accès de manière centralisée lorsqu'une personne part ou change de rôle.

Un serveur MCP distant s'insère naturellement dans ce rôle : le serveur détient les secrets  les utilisateurs et les hosts s'authentifient auprès du serveur  le serveur relaie vers les API sous-jacentes.

Du point de vue de Glean, c'est exactement pourquoi nous avons associé les serveurs MCP distants à OAuth centralisé et à Glean Protect — afin que les clients puissent activer ou désactiver des outils à un seul endroit et faire appliquer les permissions de bout en bout.

2. Télémétrie et observabilité à l'échelle de l'organisation

Quand on a de nombreuses équipes, de nombreux hosts et de nombreux outils, il faut pouvoir répondre à des questions comme :

• Quels outils font réellement bouger les choses ?
• Quels outils échouent ou expirent en timeout ?
• Quelles équipes surutilisent ou sous-utilisent certaines actions ?

Avec un serveur centralisé, vous pouvez émettre des traces et des métriques standard, comme OpenTelemetry, et obtenir une vue unique et cohérente de la manière dont les outils sont utilisés dans toute l'organisation. Cette vue devient encore plus importante à mesure que les agents commencent à exécuter des actions autonomes au-dessus de votre index et de votre Enterprise Graph, et pas seulement à répondre à des questions.

3. Prompts/skills et docs standardisés sur toutes les surfaces

L'article original fait une observation importante : les prompts MCP sont essentiellement des skills fournis par le serveur, et les resources MCP sont des docs fournies par le serveur. Cela vous donne un moyen de :

• Publier une seule skill « revue de code » ou « triage d'incident » et la faire apparaître de manière cohérente dans de nombreux outils.
• Garder les docs synchronisées entre équipes et dépôts, sans copier du Markdown dans chaque projet.
• Injecter du contexte dynamique, comme le dernier statut, les prix ou les mises à jour de politique, dans les prompts et les docs au moment de la requête.

C'est la même idée derrière Glean skills. C'est une façon de packager l'expertise en skills réutilisables que les agents peuvent invoquer partout où ils s'exécutent. MCP fournit une couche de transport neutre pour ces skills et ces docs, afin qu'ils ne soient pas enfermés dans une seule application.

4. Une surface d'intégration unique pour de nombreux hosts

Les entreprises modernes ne vivent pas dans une seule interface. Elles ont :

• des IDE comme Cursor, VS Code, Windsurf
• des apps de chat IA comme Claude, ChatGPT
• des assistants internes et des builders d'agents
• des outils verticaux avec des agents intégrés

Sans protocole, chaque paire devient une intégration sur mesure. Avec MCP, on se rapproche de « integrate once, use everywhere » : définir les outils à un seul endroit, les connecter à de nombreux hosts, et garder votre Enterprise Graph et votre logique de politique derrière une surface unique.

Tout cela ne consiste pas à économiser quelques tokens dans votre fenêtre de contexte. Il s'agit d'exécuter l'IA comme une plateforme gouvernée et observable.

Quand vous n'avez probablement pas besoin de MCP

Il vaut la peine d'être explicite sur les cas où nous n'opterions pas d'abord pour MCP :

• Vous construisez un workflow personnel unique entre un LLM et une ou deux API que vous contrôlez.
• Toute la logique vit sur votre laptop ou dans un seul service que vous contrôlez de bout en bout.
• Vous n'avez pas besoin d'auth partagée, de télémétrie ou de séparation multi-tenant.
• Vous êtes à l'aise pour documenter l'usage dans un README ou AGENTS.md et en rester là.

Dans ces situations, un CLI ou un wrapper SDK minimal est souvent exactement le bon choix. Vous itérez plus vite avec moins de surcharge, et vous pouvez toujours « monter » vers MCP plus tard si vos workflows le dépassent.

Quand MCP apporte une vraie valeur

À l'inverse, MCP commence à mériter sa place dans des schémas comme ceux-ci :

N'importe quel host, les mêmes outils.

Vous voulez que Cursor, Claude, ChatGPT et votre assistant interne puissent tous :

• Rechercher dans le même Enterprise Graph.
• Utiliser les mêmes outils pour ouvrir un ticket ou mettre à jour un enregistrement.
• Respecter les mêmes permissions et règles d'audit.

Un serveur MCP partagé vous donne un seul endroit pour définir ces outils et un seul endroit pour faire appliquer la politique, tandis que chaque host parle simplement le même protocole.

Des outils approuvés par l'administration, faciles à utiliser.

La sécurité et l'IT veulent :

• Approuver quels serveurs et outils MCP sont visibles.
• Configurer OAuth, les redirect URIs et les listes d'autorisation des hosts.
• Voir l'usage et les erreurs sans devoir retracer les problèmes à travers des systèmes déconnectés et des scripts custom.

C'est beaucoup plus simple quand on a un concept de premier ordre pour les serveurs et outils MCP dans une console d'administration, soutenu par une couche de serveur central, au lieu d'une prolifération de CLI et de scripts ponctuels.

Des skills et docs à l'échelle de l'entreprise.

Vous voulez :

• Que les SREs, PMs et ingénieurs voient les mêmes runbooks d'incident et prompts de triage, quelle que soit la surface d'agent qu'ils utilisent.
• Que ces prompts et docs restent à jour, y compris avec du contexte dynamique comme le statut courant ou les informations de version).
• Une visibilité sur les skills et docs réellement utilisées.

Les prompts et resources MCP, fournis depuis un serveur central, sont conçus pour faire exactement cela.

Des agents qui survivent à un seul environnement.

Dès que vous voulez des agents qui :

• tournent dans CI/CD ou GitHub Actions
• se déclenchent depuis des systèmes de tickets ou des alertes
• apparaissent dans des apps SaaS que vous ne contrôlez pas

… vous êtes par définition dans un territoire distant, multi-tenant, audité et permissionné. C'est là que MCP sur HTTP, avec la bonne auth et la bonne journalisation, commence à ressembler beaucoup moins à une surcharge et beaucoup plus à la bonne approche.

Nous avons vu un schéma similaire se produire avec l'indexation versus la recherche fédérée : les protocoles comme MCP et les connecteurs fédérés sont excellents pour l'interopérabilité, mais le vrai levier vient quand ils s'appuient sur un index et un Enterprise Graph solides, capables de fournir un contexte pertinent et tenant compte des permissions à ces agents.

Sortir du cycle de hype

Charles a raison de pointer du doigt le cycle de hype porté par les influenceurs autour de MCP. Il y a six mois, tout le monde voulait se présenter comme « compatible MCP ». Aujourd'hui, le pendule a basculé dans l'autre sens, et la conversation tourne souvent autour de la raison pour laquelle un CLI serait plus simple.

Sous ce changement, l'histoire architecturale est assez simple. Sur une seule machine, les CLI directs et les wrappers ad hoc sont souvent l'outil le plus pragmatique.

À l'échelle de l'entreprise, les équipes finissent par avoir besoin :

• d'un contrat standard entre les hosts IA et les outils
• d'un endroit central pour gérer l'auth, la télémétrie et la politique
• d'un moyen partagé de diffuser skills et docs sur de nombreuses surfaces

MCP n'est pas le seul moyen d'y parvenir. Une entreprise pourrait construire son propre protocole, déployer un gateway personnalisé et brancher chaque host dessus. Mais si l'écosystème converge déjà vers un standard ouvert qui fournit une grande partie de cette base prête à l'emploi, il est légitime de se demander si c'est une infrastructure que vous voulez construire et maintenir vous-même.

Chez Glean, nous pensons que les protocoles ouverts et l'indexation forte sont complémentaires, et non concurrents :

• Notre Enterprise Graph et notre pile d'indexation assurent le gros du travail pour unifier, structurer et classer les données d'entreprise.
• Des standards ouverts comme MCP, les skills et les frameworks d'agents aident ce contexte à atteindre les agents et les hosts que nos clients utilisent réellement.

Donc non, nous ne pensons pas que MCP soit « mort ».

MCP sur un seul laptop a probablement été survendu. Mais MCP comme couche centrale pour l'IA d'entreprise ne fait que commencer.