Dans les environnements d’administration système et de développement logiciel, le vrai sujet autour du Model Context Protocol n’est pas sa disparition, mais sa maturité. Le MCP n’est plus une simple nouveauté séduisante ni un connecteur “plug-and-play” que l’on branche sans réflexion. Il devient une véritable couche d’infrastructure, avec tout ce que cela implique en matière de gouvernance, de sécurité, de supervision, de gestion des accès et de montée en charge.

Autrement dit, le débat n’est plus de savoir si le MCP est “mort”, mais dans quels cas il mérite réellement d’être déployé.

Un protocole toujours vivant, mais désormais confronté au réel

Le MCP continue d’évoluer. Sa feuille de route met l’accent sur des sujets très concrets pour les équipes techniques: scalabilité du transport, communication inter-agents, gestion des sessions, gouvernance et préparation aux usages enterprise. Ce simple constat suffit à démontrer que le protocole n’est pas en phase terminale. Il entre plutôt dans une nouvelle étape: celle où il doit prouver sa valeur dans des architectures distribuées réelles, et non plus seulement dans des démonstrations élégantes.

C’est précisément là que beaucoup d’équipes commencent à changer de regard. Sur le papier, le MCP promet une standardisation des échanges entre modèles, outils, connecteurs, bases de données, moteurs de recherche internes, systèmes métiers et services tiers. En pratique, il ajoute aussi une couche intermédiaire supplémentaire, avec ses propres contraintes opérationnelles.

Et c’est souvent là que naît la friction.

Le vrai problème: la complexité opérationnelle

Pour un développeur ou un administrateur système, le MCP n’est pas seulement un protocole. C’est aussi une nouvelle surface à maintenir. Il faut gérer le transport, les permissions, le discovery des outils, la configuration partagée, les logs, les approbations, la sécurité des serveurs MCP, la latence réseau et, dans certains cas, la compatibilité entre plusieurs clients ou assistants.

Dans un petit projet, cette complexité peut sembler acceptable. Dans une infrastructure plus vaste, avec plusieurs équipes, plusieurs outils internes et plusieurs environnements, elle devient rapidement un sujet d’architecture à part entière.

C’est pourquoi il faut éviter une erreur de jugement assez fréquente: croire que le MCP est automatiquement la meilleure solution dès lors qu’un projet implique de l’IA. Ce n’est pas vrai. Dans de nombreux cas, une API directe, un connecteur natif ou une intégration plus simple restera plus lisible, plus sécurisable et plus facile à exploiter.

Le MCP devient pertinent lorsque le besoin d’interopérabilité est réel et durable.

Pourquoi les éditeurs majeurs continuent pourtant à le soutenir

Si le MCP était vraiment condamné, il serait difficile d’expliquer pourquoi les principaux acteurs du secteur continuent à le documenter, à l’intégrer et à le faire évoluer.

Anthropic l’intègre clairement dans Claude Code. La configuration des serveurs MCP, les fichiers .mcp.json, les déploiements pilotés par l’IT et les précautions de sécurité font désormais partie du flux de travail documenté. Le message est net: le MCP n’est pas un gadget, c’est un composant de plateforme.

OpenAI suit une logique comparable. La plateforme prend en charge les serveurs MCP distants dans sa couche d’outils, tout en insistant sur des notions essentielles pour les équipes d’exploitation: approbation préalable, filtrage des outils, journalisation, contrôle des données envoyées et prudence vis-à-vis des serveurs tiers.

Ce point est central. Les fournisseurs ne disent pas “branchez tout et cela fonctionnera tout seul”. Ils disent plutôt: “oui, le MCP est utile, mais il doit être déployé avec des garde-fous”.

Pour un public de sysadmins et de développeurs, cette nuance change tout.

MCP pour tous? Certainement pas

Le MCP n’est pas une réponse universelle. Il est particulièrement intéressant dans trois cas de figure.

Le premier concerne les environnements où plusieurs assistants ou plusieurs clients doivent accéder à un même ensemble d’outils de façon homogène. Dans ce contexte, le protocole peut jouer le rôle d’une couche commune, évitant de multiplier les intégrations spécifiques.

Le deuxième concerne les organisations qui veulent versionner, partager et gouverner une configuration commune entre plusieurs développeurs ou équipes. Là encore, le MCP peut apporter une forme de cohérence.

Le troisième concerne les architectures agencées autour d’agents, de workflows tool-based et de systèmes multi-outils, où la standardisation de l’accès aux capacités devient plus importante que la simplicité absolue de chaque connexion.

En revanche, si le besoin se limite à un ou deux appels bien définis, exposés par une API stable et interne, le MCP risque surtout d’ajouter une couche de complexité inutile. Cela signifie plus de maintenance, plus de points de défaillance, plus de latence potentielle et plus d’efforts de sécurisation.

Les vraies questions que doivent se poser les équipes techniques

Avant de mettre en place du MCP dans un environnement sérieux, il faut répondre à quelques questions simples, mais décisives.

D’abord, existe-t-il un besoin réel de standardisation entre plusieurs outils ou plusieurs clients, ou essaie-t-on simplement d’habiller une intégration classique avec une couche à la mode?

Ensuite, quelles données sortiront effectivement du périmètre, vers quels serveurs, et sous quel régime de confiance? Ce point est particulièrement sensible dès qu’un serveur MCP est opéré par un tiers.

Il faut aussi définir clairement la gouvernance: qui valide les outils exposés, qui approuve les flux, qui maintient les configurations partagées, qui surveille les journaux et qui réagit en cas d’abus ou de dérive?

Enfin, il faut évaluer le coût réel: coût de déploiement, coût de maintenance, coût de latence, coût de sécurisation et coût humain d’exploitation.

C’est seulement après cette analyse que le MCP peut être jugé pour ce qu’il est réellement: un protocole puissant, mais exigeant.

Le risque principal n’est pas l’échec du protocole, mais le mauvais usage

Le MCP souffre aujourd’hui moins d’un manque d’avenir que d’un excès d’attentes irréalistes. Pendant un temps, beaucoup l’ont présenté comme l’équivalent d’un “USB-C pour l’IA”: une interface universelle, simple, élégante, presque évidente.

Cette comparaison est utile pour expliquer l’idée générale, mais elle devient trompeuse dès qu’on parle de production. Dans la vraie vie, il faut gérer les sessions, les droits, les autorisations, les transports distants, la résilience, la charge, les serveurs non fiables, les risques de prompt injection et la traçabilité des actions.

Le protocole n’est donc pas en train de mourir. Il est en train de quitter le domaine des métaphores séduisantes pour entrer dans celui, beaucoup plus concret, de l’ingénierie de plateforme.

Et c’est précisément à ce moment-là que les équipes sérieuses commencent à l’évaluer correctement.

Conclusion

Dire que le MCP est mort est une formule provocatrice, mais techniquement inexacte. Le protocole continue à avancer, les grands acteurs le soutiennent, et son utilité reste réelle dans des architectures où l’interopérabilité est un besoin structurel.

En revanche, une chose a bel et bien disparu: l’illusion selon laquelle MCP serait une solution simple, évidente et universelle.

Pour les administrateurs systèmes comme pour les développeurs, la bonne approche consiste à le traiter comme toute autre brique d’infrastructure: avec méthode, critères d’usage, modélisation des risques, contrôles d’accès, observabilité et discipline d’architecture.

Le MCP n’est pas mort. Il est simplement devenu sérieux.