MCP Dévore l'Économie des API

Model Context Protocol fait à l'intégration d'API ce que REST a fait à SOAP : remplacer la couche d'intégration écrite à la main par quelque chose qu'un agent peut découvrir et utiliser tout seul.

La première fois que la plupart des ingénieurs seniors voient un serveur MCP, ils le rejettent comme un wrapper autour de JSON-RPC. Ça l'est. C'était aussi le cas de REST sur HTTP en 2005.

La vraie question à laquelle MCP répond, c'est celle que REST a mal traitée pendant vingt ans : comment un logiciel expose-t-il ses capacités à un autre logiciel qu'il n'a jamais vu ? La réponse de REST était « lis la doc et écris un client ». Cette réponse ne tient que si le lecteur est un développeur humain.

Les API REST ont été conçues pour des humains écrivant du code client. Endpoints, docs, appels fetch à la main dans le bon ordre avec les bons paramètres. Chaque intégration est sur mesure.

Ça marche quand le consommateur est un développeur humain. Ça casse quand le consommateur est un LLM. Un LLM ne lit pas votre fichier Swagger pour décider lequel des douze endpoints enchaîner. Il lui faut la capacité décrite dans son entrée : nom de l'outil, ce qu'il fait, schéma d'entrée, schéma de sortie, effets de bord.

MCP fournit exactement cette forme. Un appel `tools/list` renvoie chaque capacité avec un schéma JSON sur lequel le modèle peut raisonner au moment de l'inférence. Pas de SDK, pas de génération de code, pas de ticket d'onboarding.

Ce qui rend MCP transformateur n'est pas une fonctionnalité isolée. C'est la composition au runtime.

Quand chaque service s'expose comme outils MCP, un agent peut les découvrir et les enchaîner à l'inférence. Un agent de support lit votre CRM, interroge votre service de facturation, rédige un message Slack et ouvre un ticket — avec des outils qu'il a découverts trente secondes plus tôt. Pas d'intégrations codées en dur. Pas de middleware spécifique au fournisseur.

C'est la philosophie Unix appliquée aux agents. De petits outils ciblés qui se composent. Le compositeur n'est plus un script shell ; c'est un modèle qui peut raisonner sur les outils à combiner et dans quel ordre.

Rendre trivialement facile la connexion d'agents à des outils arbitraires rend aussi trivialement facile leur connexion à des outils malveillants. L'empoisonnement d'outils — quand la description promet un comportement et que l'implémentation en fait un autre — est l'injection SQL de l'ère MCP.

La plupart des équipes qui livrent des serveurs MCP aujourd'hui n'y pensent pas. Elles se concentrent sur le fait que ça marche. Chaque grande crise de sécurité dans l'histoire du web a commencé pareil.

Les équipes qui gagneront dans l'économie MCP ne seront pas les plus rapides à livrer. Ce seront celles qui ont résolu la provenance des outils, l'assainissement des sorties et le sandboxing avant d'avoir à l'apprendre à la dure.

Si vous construisez du logiciel qu'un autre logiciel consomme, vous devriez déjà livrer une interface MCP. L'économie y oblige.

Une intégration REST coûte des jours à un développeur. Un outil MCP coûte des minutes. Quand l'intégration devient 100 fois moins chère, vous n'obtenez pas 100 fois plus des mêmes intégrations — vous obtenez des catégories entières d'intégrations qui ne valaient pas la peine avant. Stripe publie déjà un serveur MCP. Linear aussi. Supabase aussi.

Chaque SaaS finira par exposer des outils MCP. Chaque service interne aura une interface MCP. La seule vraie question est de savoir si vous en livrez une avant votre concurrent.