Faut-il exiger que votre agent IA parle MCP ?

Non comme critère d’achat, oui comme critère de sortie. MCP ne vous dit rien de ce qu’un agent vaut ; il vous dit quelque chose du coût que vous paierez le jour où vous en changerez.

C’est une distinction utile parce que le protocole est devenu un argument commercial. En 2026, MCP est le standard de fait : plus de 13 000 serveurs publiés sur GitHub, des SDK Python et TypeScript qui totalisent plus de 97 millions de téléchargements mensuels, une adoption par OpenAI, Google DeepMind et Microsoft, et une gouvernance passée sous la Linux Foundation via l’Agentic AI Foundation. Tout le monde le met sur sa page produit. Presque personne n’explique ce que ça change.

Ce que MCP règle vraiment

Le Model Context Protocol, créé par Anthropic fin 2024, normalise une seule chose : la grammaire par laquelle un modèle découvre et utilise un outil extérieur. Comment un serveur déclare ses fonctions et ses données, comment un client les découvre, comment un modèle les appelle.

Avant, chaque éditeur écrivait son propre connecteur vers chaque outil. Trente agents fois trente logiciels, c’est neuf cents intégrations à écrire et à maintenir. Avec un protocole commun, c’est trente serveurs et trente clients.

Le gain est réel, et il est d’abord économique. Il déplace le coût d’intégration de chaque paire vers chaque extrémité, ce qui change la structure du marché : un petit éditeur peut se brancher sur un écosystème qu’il n’aurait jamais eu les moyens de construire.

Et il traite le bon problème. On estime que 85 % des erreurs d’agents en entreprise viennent d’un manque de contexte plutôt que d’une insuffisance du modèle. Un agent qui ne voit pas votre ATS ne se trompe pas parce qu’il raisonne mal, il se trompe parce qu’il devine.

Les trois choses qu’il ne règle pas

La qualité de la connexion. Le protocole décrit comment appeler une fonction, pas ce que cette fonction fait bien. Un serveur MCP qui expose votre ATS peut ne donner accès qu’aux dix derniers profils, ignorer les champs personnalisés, ou retourner des dates dans un format que personne ne vérifie. Il est parfaitement conforme et parfaitement inutile.

Les droits. MCP dit comment parler à un outil ; il ne dit pas qui a le droit d’en faire quoi. C’est un point que beaucoup de démonstrations escamotent : brancher un serveur MCP donne souvent à l’agent l’ensemble des capacités que ce serveur expose, sans que quiconque ait décidé, fonction par fonction, laquelle est nécessaire.

La maintenance. Les 13 000 serveurs publiés ne sont pas maintenus en tant qu’ensemble. La plupart sont des projets individuels, et la conformité au protocole ne dit rien de ce qui se passera le jour où l’outil exposé changera son API, ce qui arrive plusieurs fois par an chez n’importe quel éditeur SaaS actif. En production, la disponibilité d’un connecteur compte beaucoup moins que la question de savoir qui le répare.

Un connecteur est une liste de droits

C’est la lecture qui manque partout, et elle est plus importante que le protocole lui-même.

Chaque serveur branché est un canal par lequel du contenu extérieur entre dans le contexte d’un agent qui, lui, a des droits. Un serveur qui lit vos emails fait entrer du texte écrit par n’importe qui ; un serveur qui navigue sur le web fait entrer des pages que personne n’a relues. C’est exactement la configuration qui rend l’injection de prompt indirecte efficace : source non fiable d’un côté, capacité d’agir de l’autre, même contexte.

La standardisation aggrave mécaniquement le problème, puisqu’elle rend l’ajout d’une connexion trivial. Ajouter un outil devient une ligne de configuration, alors que la décision qu’elle porte, accorder une capacité, mériterait la même attention qu’une ouverture de droits dans n’importe quel autre système.

D’où une règle simple, valable quel que soit le protocole : inventoriez les serveurs comme vous inventoriez les accès, et pour chacun, demandez s’il lit ou s’il écrit. Regarder la liste des connexions d’un agent sous cet angle est instructif, et presque personne ne le fait.

Le point aveugle : votre ATS n’a pas de serveur

Les 13 000 serveurs publiés donnent une impression de couverture universelle qui ne résiste pas au premier cas réel.

Regardez ce que couvre l’écosystème : GitHub, Slack, Postgres, Notion, Google Drive, Stripe, les grands du SaaS américain. Regardez maintenant votre pile. Un ATS français de recrutement, un outil de gestion de mission conçu pour les ESN, un logiciel de facturation choisi il y a huit ans, un extranet client développé en interne. Il y a de fortes chances qu’aucun des quatre n’ait de serveur MCP, et qu’aucun n’en ait avant longtemps, parce que l’éditeur a trois cents clients, pas trois cent mille.

C’est la limite pratique du standard, et elle est structurelle : un protocole n’élargit pas le marché d’un connecteur, il en abaisse seulement le coût unitaire. Les outils de niche restent des outils de niche.

Ce qui déplace la question, pour une ESN, du protocole vers l’engagement. Trois choses valent d’être demandées, et elles sont plus décisives que la conformité : Combien de temps pour un connecteur vers un outil que vous ne couvrez pas ? La réponse honnête se compte en semaines si l’outil a une API documentée, et « on ne sait pas » s’il n’en a pas. Les deux sont acceptables ; l’absence de réponse ne l’est pas.

Qui le maintient ensuite ? Un connecteur écrit une fois pour un client et jamais repris est une dette qui vous reviendra.

Que se passe-t-il quand il n’y a pas d’API du tout ? Certains outils n’en exposent aucune. Un éditeur sérieux vous le dira franchement plutôt que de promettre une intégration qu’il devra bricoler.

Un agent qui couvre parfaitement quinze outils que vous n’utilisez pas ne vaut rien. Un agent qui couvre les quatre que vous utilisez vaut tout, protocole ou pas.

La question qui remplace « parlez-vous MCP »

Elle tient en une phrase : que se passe-t-il quand l’outil d’en face change ?

C’est là que se joue la différence entre un éditeur qui a coché une case et un éditeur qui exploite des intégrations en production. Un fournisseur SaaS modifie une API, déprécie un champ, change une pagination, durcit un quota. Le connecteur casse. La vraie question est de savoir combien de temps vous restez sans le savoir, et qui corrige.

Trois questions dérivées suffisent à départager.

Qui maintient le connecteur que vous utilisez chez moi ? Vous, la communauté, ou le fournisseur lui-même ? Les trois réponses sont acceptables, et chacune porte un délai de réparation différent.

Comment sais-je qu’une intégration est tombée ? Un agent qui échoue en silence sur une source vous rend des résultats incomplets qui ressemblent à des résultats complets. C’est nettement plus dangereux qu’une panne visible, qui au moins se signale.

Que se passe-t-il si je pars ? Si vos connecteurs sont conformes MCP, vous emportez le travail d’intégration. Sinon, vous payez pour le refaire entièrement ailleurs. C’est la seule question où le protocole compte vraiment, et elle ne se pose pas au moment de signer mais trois ans plus tard.

Ce que ça change concrètement à l’achat

MCP est une bonne nouvelle pour l’acheteur, à condition de le ranger au bon endroit de la grille.

Ce n’est pas un critère de capacité. Un agent qui parle MCP n’est pas meilleur qu’un agent qui ne le parle pas : il est plus facile à remplacer. Et un éditeur avec des connecteurs propriétaires éprouvés, une API documentée et une équipe qui répare vaut mieux qu’un éditeur conforme qui n’a jamais géré une rupture d’API.

Ce n’est pas non plus un critère de sécurité : il en ajoute plutôt, en abaissant le coût d’ajout d’un canal non fiable.

C’est un critère de réversibilité, et c’est un bon. Rangez-le à côté de l’export de vos données et de la portabilité de votre configuration, pas à côté de ce que l’agent sait faire. Ce qu’il sait faire se juge autrement, notamment sur la différence entre un agent et un workflow, et cette différence-là, aucun protocole ne la donne.