Le Model Context Protocol (MCP) connaît actuellement un engouement considérable dans l'écosystème de l'intelligence artificielle. Présenté comme le standard universel pour les intégrations d'agents IA, ce protocole semble pourtant destiné à une popularité éphémère. Son adoption massive repose davantage sur des malentendus techniques et une facilité d'implémentation trompeuse que sur une réelle valeur ajoutée à long terme.
Cette analyse technique dévoile pourquoi MCP, malgré son succès apparent, représente une solution transitoire qui sera rapidement dépassée par des alternatives plus robustes et mieux intégrées aux infrastructures existantes. Comprendre ses limites permet aux développeurs d'anticiper l'évolution du paysage des outils d'automatisation intelligente et d'éviter des investissements techniques voués à l'obsolescence.
Qu'est-ce que le Model Context Protocol et pourquoi fait-il parler de lui ?
Le Model Context Protocol prétend résoudre le fameux "problème NxM" : avec N agents et M ensembles d'outils, les utilisateurs devraient théoriquement créer de nombreux connecteurs sur mesure. Cette promesse attire naturellement les développeurs cherchant à simplifier leurs architectures d'intégration.
Le mythe du problème NxM
Une idée reçue répandue suggère que MCP serait indispensable pour l'appel de fonctions par les modèles d'IA. C'est faux. Les modèles capables d'utiliser des outils reçoivent simplement une liste des fonctions disponibles avec chaque requête. Si le modèle souhaite invoquer un outil, il retourne des paramètres au format JSON que l'application doit ensuite interpréter et exécuter.
Le véritable problème surgit lorsque les utilisateurs veulent réutiliser des ensembles d'outils entre différents agents, chacun possédant des API légèrement différentes. Par exemple, l'API de Gemini expose les outils via des functionDeclarations imbriquées dans un tableau tools, tandis qu'OpenAI utilise un tableau plat avec type: "function".
Dans la pratique, ces différences restent mineures – même sémantique, légères variations de structure JSON – et des frameworks comme LangChain, LiteLLM ou SmolAgents les abstraient déjà efficacement. Ces solutions exécutent les appels d'outils dans le même environnement d'exécution que l'agent, contrairement à l'approche de MCP.
L'approche MCP : isolation par processus séparés
MCP gère l'exposition et l'invocation des outils via des processus distincts. Une configuration JSON contrôle quels serveurs MCP démarrer, chacun s'exécutant dans son propre processus de longue durée et gérant les invocations d'outils de manière indépendante. L'application orchestrant l'agent présente toujours les résultats aux utilisateurs.
Cette architecture abstrait certes la génération de schémas et l'invocation, mais au prix d'un contrôle considérablement réduit. La logique des outils s'exécute dans un processus séparé, rendant la gestion des ressources opaque. L'application perd le contrôle sur les instructions des outils, la journalisation et la gestion des erreurs. Chaque appel d'outil franchit une barrière de processus, introduisant latence et complexité.
Les problèmes structurels qui condamnent MCP
La commodité apparente de MCP masque des défauts architecturaux profonds qui limitent sérieusement son utilité pratique et sa viabilité à long terme.
Boîtes à outils incohérentes et surcharge cognitive
Les agents deviennent moins efficaces à mesure que le nombre d'outils augmente. Avec un ensemble d'outils bien organisé et cohérent, ils performent correctement. Avec un ensemble plus large et désorganisé, ils peinent. OpenAI recommande de maintenir le nombre d'outils bien en dessous de 20, pourtant de nombreux serveurs MCP dépassent largement ce seuil.
L'adéquation d'un outil à une tâche dépend non seulement du travail à accomplir, mais aussi des autres outils disponibles. Une pince peut arracher un clou, mais si un marteau est disponible, c'est probablement le meilleur choix. Lorsque les outils sont distribués isolément, leurs instructions ne peuvent pas indiquer "utilisez-moi uniquement quand vous n'avez pas de marteau", privant les agents de guidance cohésive.
Cette problématique rappelle les défis rencontrés dans l'intégration contextuelle des assistants IA, où la compréhension globale de l'environnement utilisateur s'avère cruciale pour des recommandations pertinentes.
Dans les canaux #mcp des agents de codage open source, on trouve invariablement des utilisateurs qui peinent à faire utiliser les outils par l'agent comme ils le souhaitent, ou qui se plaignent du nombre considérable de tokens brûlés par les instructions des outils.
Environnements d'exécution arbitraires et problèmes de gestion
Chaque serveur MCP démarre un processus séparé qui survit pendant toute la durée de la session de l'agent. Même en état de fonctionnement normal, cela introduit une collection de processus qui restent principalement inactifs, hormis pour traiter des requêtes occasionnelles de l'agent.
En état d'erreur, on retrouve tous les tracas habituels : sous-processus pendants, fuites mémoire, contention de ressources. Les utilisateurs rencontrent ces problèmes, quand ils parviennent à faire fonctionner les serveurs. Dans les canaux de support, la plainte la plus courante concerne la difficulté à faire démarrer les serveurs.
| Problème | Cause | Impact |
|---|---|---|
| Serveurs qui ne démarrent pas | Dépendances manquantes ou incompatibles | Frustration utilisateur, abandon |
| Variables d'environnement incomplètes | MCP hérite seulement USER, HOME, PATH | Échecs avec nvm, environnements virtuels |
| Multiples instances runtime | Chaque serveur lance son propre processus | Perte de mise en cache, pooling connexions |
| Débogage complexe | Orchestration subprocess opaque | Temps de résolution problèmes élevé |
MCP n'offre aucun moyen aux serveurs de déclarer leurs besoins en runtime ou dépendances. Certains auteurs contournent cela en intégrant l'installation dans la commande de lancement (par exemple uv run some_tool mcp), ce qui ne réussit que si l'utilisateur a déjà les bons outils installés.
Les développeurs Python ou Node peuvent être à l'aise pour déboguer des problèmes d'environnement, mais probablement moins pour déboguer des problèmes Node ET Python ET d'autres runtimes simultanément. Cette complexité technique fait écho aux défis d'infrastructure multimodale que rencontrent les plateformes IA modernes.
Vulnérabilités de sécurité : le talon d'Achille de MCP
MCP pousse les utilisateurs à installer des serveurs depuis npm, pip ou GitHub, héritant ainsi des risques habituels de la chaîne d'approvisionnement, mais sans même les garde-fous minimaux que ces écosystèmes fournissent.
Absence de provenance et d'authentification
Il n'existe aucun éditeur central ni système de signature : n'importe qui peut distribuer un démon qui s'exécute sur votre machine et MCP n'offre aucune vérification de provenance. La spécification MCP ne mandate pas l'authentification, laissant les décisions de sécurité aux auteurs individuels de serveurs.
Résultat : une analyse a trouvé 492 serveurs MCP fonctionnant sans aucune authentification client ni chiffrement du trafic. Même le propre Filesystem MCP Server d'Anthropic présentait une faille d'échappement de sandbox via traversée de répertoire (CVE-2025-53110).
Incidents de sécurité documentés
Les vulnérabilités MCP s'accumulent rapidement :
- CVE-2025-65149 : Score CVSS 9.6 - Exécution de code à distance dans mcp-remote (plus de 437 000 téléchargements)
- CVE-2025-49596 : Score CVSS 9.4 - RCE dans l'inspecteur MCP d'Anthropic
- CVE-2025-53967 : Exécution de code à distance dans Figma MCP Server (600 000+ téléchargements)
- Fuite de données Asana : Défaut d'isolation tenant exposant les données d'environ 1 000 clients
- Fuite Supabase MCP : "Trifecta létale" injection de prompt → appel d'outil → exfiltration de données, extraction de bases SQL complètes incluant tokens OAuth
Contrairement aux agents humains qui cliquent prudemment dans une API, les agents IA peuvent être manipulés via injection de prompts pour appeler des outils de manières non prévues. Ces risques ne sont pas uniques à MCP, mais les meilleures mitigations reposent sur l'infrastructure de sécurité existante : tokens OAuth à portée limitée, identités de service avec permissions minimales, journalisation d'audit.
MCP contourne cette infrastructure plutôt que de s'appuyer sur elle. Un argument de défense courant affirme que MCP isole les identifiants – l'agent communique avec un socket sans jamais voir vos tokens API. Mais ce modèle de menace est étroit : un agent capable d'invoquer mcp.github.delete_repo() n'a pas besoin de votre token pour causer des dommages.
Ces préoccupations de sécurité rejoignent les risques identifiés dans l'utilisation d'IA pour des tâches critiques sans supervision appropriée.
Pourquoi MCP a-t-il connu un tel engouement malgré ses défauts ?
Avec ces problèmes manifestes, on peut légitimement se demander pourquoi MCP a gagné la popularité qu'il connaît. Il a bénéficié d'un soutien massif d'Anthropic et n'a eu aucun mal à séduire les éditeurs d'outils, les fournisseurs d'agents et les entreprises.
Un canal marketing à faible friction pour les auteurs d'outils
Publier un serveur MCP est extrêmement simple. L'absence d'exigences de démarrage signifie qu'il n'est même pas nécessaire de publier sur npm ou pip : vous pouvez déposer une annotation @mcp.server dans votre dépôt et héberger un petit manifeste JSON pointant vers votre commande d'entrée.
Cela fournit un narratif attractif pour attirer l'attention sur les projets IA : un utilisateur peut théoriquement ajouter facilement quelques outils MCP d'un projet, en tirer de la valeur, et suivre son intérêt pour en apprendre davantage sur le projet. La charge de support retombera principalement sur les mainteneurs d'agents.
Une fois que les éditeurs ont commencé à apparaître, il est devenu difficile de justifier de ne pas supporter MCP. Votre projet pouvait être perçu comme opposé aux standards ouverts. Cette dynamique rappelle l'adoption rapide des outils IA marketing où la pression concurrentielle accélère l'intégration.
Crédibilité IA pour les entreprises
Au cours des dernières années, quiconque observant les panneaux publicitaires de San Francisco a vu les outils d'entreprise se rebaptiser vers l'IA. Le support MCP offrait un moyen facile de transformer votre outil de gestion de projet en solution "IA-powered".
Le positionnement de MCP comme "standard ouvert" a accru la pression à l'adoption – l'absence de support MCP pouvait signaler un manque de volonté d'adopter les standards ouverts. Cette stratégie de positionnement s'inscrit dans la course mondiale à l'adoption IA où les entreprises cherchent à afficher leur modernité technologique.
Crédibilité open source pour Anthropic
Le statut de MCP comme standard ouvert pour l'IA et l'adoption par les entreprises ont grandement bénéficié à Anthropic. La grande crainte des investisseurs est que l'adoption en entreprise ne persiste pas – l'adoption du standard ouvert d'Anthropic a aidé à atténuer cette inquiétude.
Alternatives supérieures à MCP pour chaque cas d'usage
Qui bénéficie réellement de MCP ? Plusieurs types d'utilisateurs interagissent potentiellement avec ce protocole, mais pour chacun, des alternatives plus simples et robustes existent.
Tableau comparatif : MCP vs alternatives
| Type d'utilisateur | Promesse MCP | Meilleure alternative | Avantage |
|---|---|---|---|
| Utilisateurs techniques finaux | Partager outils entre agents | Scripts locaux + ligne de commande | Contrôle total, débogage simple, pas de processus zombie |
| Utilisateurs non techniques | Utiliser différents outils avec agents | Interfaces utilisateur dédiées | Pas de configuration JSON, expérience guidée |
| Développeurs d'applications internes | Standardisation des intégrations | API REST + OpenAPI | Standards éprouvés, authentification robuste, monitoring |
| Développeurs d'agents | Permettre aux utilisateurs d'échanger des outils | Plugins avec sandboxing | Sécurité, isolation, gestion des dépendances |
| Auteurs d'outils | Distribution facile | Bibliothèques SDK + documentation | Intégration native, performance, maintenabilité |
Pour les utilisateurs techniques : scripts et outils en ligne de commande
Les utilisateurs techniques souhaitant créer des outils et les partager entre différents agents qu'ils utilisent n'ont pas besoin de MCP. Un utilisateur technique capable d'éditer une configuration JSON MCP peut tout aussi facilement écrire un script Python ou Node local que l'agent peut invoquer directement.
Ces scripts s'exécutent dans l'environnement de l'utilisateur avec accès complet aux outils, bibliothèques et configurations existants. Pas de problèmes de variables d'environnement, pas de processus zombies, débogage transparent. Les outils de génération de contenu modernes excellent précisément dans la création de ce type de scripts utilitaires.
Pour les développeurs d'applications : API REST et standards établis
Les développeurs d'applications en production ont besoin de contrôle, d'observabilité et de sécurité. MCP n'offre aucun de ces éléments. Les API REST avec spécifications OpenAPI fournissent des schémas standardisés, une documentation automatique, une validation de types et s'intègrent naturellement aux systèmes d'authentification, de journalisation et de monitoring existants.
Le mode transport HTTP de MCP ne résout rien – c'est juste une autre API HTTP, mais avec la surcharge protocolaire de MCP au lieu des patterns REST/OpenAPI éprouvés au combat. Cette approche architecturale s'aligne avec les meilleures pratiques d'intégration IA dans les systèmes de production.
Pour les développeurs d'agents : systèmes de plugins avec sandboxing
Les développeurs d'agents souhaitant permettre aux utilisateurs finaux d'échanger des ensembles d'outils ont besoin de systèmes de plugins appropriés avec sandboxing, gestion des dépendances et politiques de sécurité. MCP n'offre rien de tout cela.
Des systèmes de plugins matures comme ceux de VSCode, Figma ou WordPress fournissent des manifestes déclaratifs, isolation des ressources, API versionnées et mécanismes de révision. Ils s'appuient sur des décennies d'apprentissages en matière de sécurité et d'extensibilité que MCP ignore.
L'avenir post-MCP : vers quelles solutions converger ?
MCP représente une phase transitoire dans l'évolution des architectures d'agents IA. Son succès temporaire illustre un besoin réel de standardisation, mais sa mise en œuvre révèle les limites d'une approche déconnectée des infrastructures éprouvées.
Convergence vers les standards établis
L'industrie convergera naturellement vers des solutions s'appuyant sur l'infrastructure existante plutôt que de la contourner. Les API REST avec OpenAPI, les systèmes d'authentification OAuth, les architectures de microservices avec service mesh offrent déjà tout ce que MCP prétend apporter, avec en prime la maturité, la sécurité et l'écosystème d'outils.
Les modèles d'IA deviennent suffisamment sophistiqués pour générer eux-mêmes les wrappers d'API nécessaires à partir de spécifications OpenAPI. Cette approche élimine le besoin de serveurs MCP tout en conservant la flexibilité et le contrôle. Les plateformes comme Meta AI et ses concurrents intègrent déjà ces capacités nativement.
Intégration native dans les modèles de fondation
Les futurs modèles de fondation intégreront probablement des capacités d'appel d'outils plus sophistiquées directement dans leur architecture, rendant obsolète toute couche d'abstraction externe. Les travaux sur les modèles simulateurs de mondes suggèrent que les prochaines générations d'IA comprendront intrinsèquement les interactions avec les systèmes externes.
Cette évolution rendra MCP aussi pertinent que les frameworks d'abstraction de bases de données qui ont précédé les ORM modernes : une solution intermédiaire rapidement dépassée par des approches plus intégrées et performantes.
Leçons pour les développeurs en 2026
Pour les développeurs investissant dans des architectures d'agents IA aujourd'hui, plusieurs principes émergent :
- Privilégier les standards éprouvés : REST, OpenAPI, OAuth offrent maturité et écosystème
- Maintenir le contrôle : Exécuter les outils dans le même runtime que l'agent préserve observabilité et performance
- Sécuriser par design : S'appuyer sur l'infrastructure de sécurité existante plutôt que de la contourner
- Optimiser la cohérence : Concevoir des ensembles d'outils cohérents plutôt que d'agréger des sources disparates
- Anticiper l'évolution : Les capacités natives des modèles rendront obsolètes les abstractions externes
Ces principes s'appliquent particulièrement aux créateurs de contenu IA qui doivent équilibrer innovation et pérennité technique.
Conclusion : MCP, un détour instructif vers de meilleures solutions
Le Model Context Protocol illustre parfaitement comment l'engouement autour d'une technologie peut masquer ses défauts structurels. Son adoption rapide témoigne d'un besoin réel de standardisation dans l'écosystème des agents IA, mais sa mise en œuvre révèle les dangers d'ignorer décennies de bonnes pratiques en architecture logicielle.
Les problèmes de MCP – boîtes à outils incohérentes, gestion opaque des processus, vulnérabilités de sécurité, contournement des infrastructures éprouvées – ne sont pas des bugs corrigeables mais des conséquences directes de ses choix architecturaux fondamentaux. Le rapport coût-bénéfice ne justifie tout simplement pas l'adoption de cette complexité supplémentaire.
Pour les développeurs et les entreprises, la leçon est claire : investir dans des solutions s'appuyant sur les standards établis (REST, OpenAPI, systèmes de plugins matures) plutôt que dans des abstractions fragiles promises à l'obsolescence. Les modèles d'IA évoluent rapidement vers des capacités d'intégration natives qui rendront MCP aussi pertinent qu'un framework d'abstraction de l'an 2000.
L'histoire de MCP restera comme un détour instructif – un rappel que dans la course à l'innovation IA, les solutions durables s'appuient sur des fondations solides plutôt que sur des raccourcis séduisants mais fragiles. Pour aller plus loin dans l'utilisation d'outils IA robustes et pérennes, créez votre compte gratuit sur Roboto et découvrez une plateforme conçue selon les meilleures pratiques d'architecture et de sécurité.
