La révolution du MCP et la recherche de cas d’usage viables de l’AI en entreprise

Lorsque Anthropic a présenté le Model Context Protocol fin 2024 — un standard ouvert pour connecter les modèles de langage aux outils externes, bases de données et APIs — peu de gens anticipaient la rapidité avec laquelle cette initiative remodèlerait le paysage de l'IA d'entreprise. Peu plus d'un an après, MCP a évolué d'un protocole de niche en standard de facto soutenu par des dizaines de plateformes. Cependant, derrière la croissance rapide se cache une vérité inconfortable : l'industrie n'a toujours pas trouvé de réponse à une question fondamentale — quels cas d'usage de l'IA en entreprise sont vraiment durables.

C'est précisément de cela que parle le chercheur en IA Sebastian Vollkommer dans une interview exhaustive pour KDnuggets. Sa position est à la fois optimiste et honnêtement lucide. D'un côté, MCP résout une réelle douleur d'ingénierie.

Avant l'arrivée du protocole, chaque intégration d'un modèle d'IA avec un système d'entreprise — qu'il s'agisse d'un CRM, d'une base de connaissances ou d'un outil interne — nécessitait un développement personnalisé. Cela ressemblait à l'époque pré-USB, quand chaque appareil avait besoin de son propre connecteur. MCP a offert une « prise » unifiée : une façon standardisée de décrire les outils disponibles, de transmettre le contexte et de recevoir les résultats.

Pour les développeurs, cela signifie qu'un serveur MCP écrit une fois pour Salesforce ou PostgreSQL fonctionne avec n'importe quel modèle compatible — Claude, GPT, Gemini ou alternatives open-source.

Cependant, Vollkommer attire l'attention sur ce que l'industrie préfère discuter discrètement : la sécurité de l'écosystème MCP reste un problème grave. Le protocole par sa nature même élargit la surface d'attaque. Quand un modèle de langage obtient accès aux systèmes d'entreprise par les serveurs MCP, tout un spectre de menaces émerge — des injections de prompts forçant le modèle à exécuter des actions imprévues, à la compromission des serveurs MCP eux-mêmes, qui peuvent être substitués par des versions malveillantes.

Le problème est aggravé par le fait que l'écosystème croît plus vite que les pratiques d'audit et de vérification ne se constituent. La communauté documente déjà des cas où des serveurs MCP tiers contenaient des vulnérabilités permettant l'accès à des données auxquelles le modèle ne devrait jamais toucher.

Mais la thèse la plus provocatrice du chercheur concerne non la technologie, mais la logique métier. Vollkommer pose la question de manière directe : quels cas d'usage de l'IA en entreprise peuvent vraiment être considérés comme stables ? Par stabilité, il entend non seulement la fiabilité technique, mais la valeur économique durable — une situation où une solution d'IA apporte prévisiblement plus que ne coûte son déploiement et sa maintenance.

Et ici le tableau est moins rose que celui que peignent les fournisseurs. De nombreuses entreprises qui ont déployé des agents d'IA pour automatiser les flux de travail ont rencontré des modèles se comportant de manière imprévisible dans les cas limites, nécessitant une supervision humaine constante et coûtant plus que prévu. L'écart entre les démonstrations impressionnantes et le travail productif quotidien reste important.

Cet écart est particulièrement visible dans le contexte des soi-disant agents d'IA — systèmes autonomes capables d'exécuter des chaînes d'actions sans implication humaine constante. MCP crée essentiellement une base infrastructurelle pour eux, donnant aux agents un accès standardisé aux outils. Mais plus l'agent gagne en autonomie, plus les enjeux sont élevés.

Une erreur dans la génération de texte est un désagrément. Une erreur d'un agent qui envoie des e-mails aux clients au nom de l'entreprise, modifie des enregistrements de base de données ou initie des opérations financières est une catastrophe potentielle. Vollkommer insiste sur le fait que l'industrie a besoin non seulement de standards techniques comme MCP, mais aussi de standards de confiance : des façons formalisées de déterminer quel niveau d'autonomie est permissible pour un scénario spécifique et quelles garanties le système doit assurer.

Le paradoxe du moment actuel est que la standardisation accélère et expose simultanément les problèmes. MCP abaisse la barrière d'entrée pour créer des intégrations d'IA, ce qui attire inévitablement plus d'expérimentateurs et augmente le nombre de déploiements. Mais chaque nouveau déploiement est un autre test de charge qui révèle les limites des modèles, du protocole et de la préparation d'entreprise. En quelque sorte, MCP joue pour l'industrie de l'IA le même rôle que HTTP a joué pour le web précoce : il crée un langage commun, mais ne garantit pas la qualité de ce qui sera dit dans ce langage.

Pour le marché russe, ces conclusions sont particulièrement pertinentes. Les entreprises nationales développant leurs propres modèles de langage et plateformes d'IA font face à un choix : suivre MCP comme standard mondial ou développer des approches alternatives d'intégration. Étant donné que le protocole est ouvert et non lié à un fournisseur spécifique, le soutenir semble pragmatique — mais avec des investissements dans ses propres mécanismes de sécurité et d'audit.

La leçon principale des observations de Vollkommer est simple mais importante : standardiser l'infrastructure est une condition nécessaire mais insuffisante pour la maturité de l'industrie de l'IA. Tant que les questions de prévisibilité, de sécurité et de justification économique ne seront pas résolues, la révolution MCP restera une révolution de tuyauterie — un travail d'ingénierie impressionnant dont la valeur est déterminée par ce qui finit par couler dans ces tuyaux.