MCP vs API : pourquoi le nouveau protocole étend les interfaces au lieu de les remplacer

À mesure que MCP gagnait en popularité, un slogan audacieux a commencé à circuler : les API ne sont plus nécessaires. La vidéo ancre cette question dans le e-commerce. Lorsqu'un client ouvre la page des commandes, l'application appelle une interface de commandes et affiche l'enregistrement renvoyé à l'écran. La question est de savoir pourquoi MCP a vu le jour alors que ce dispositif fonctionne.

Le processus de paiement se lit comme un résumé du modèle traditionnel. L'application appelle d'abord une interface de paiement, puis effectue une mise à jour des stocks, et atteint enfin une interface e-mail pour le message de confirmation. C'est le développeur qui décide quel appel se produit, quand et dans quel ordre. Comme le flux est figé dans le code, il arrive prédéfini et rigide.

Le tableau se brise dès que l'utilisateur formule une phrase au lieu d'appuyer sur des boutons. Le modèle peut comprendre une requête comme trouve ma dernière commande et envoie-moi les détails de suivi, mais il n'a aucune carte des interfaces disponibles. Il ne peut pas dire laquelle s'exécute en premier ni quelles entrées chacune attend. Nourrir le modèle avec toute la documentation des interfaces n'a de sens pour personne.

Deux concepts sont clarifiés à ce stade. Un outil est une action unique qu'une application d'IA peut entreprendre : rechercher, rédiger et envoyer côté messagerie, ou consulter l'historique et ouvrir des enregistrements côté dépôt. Un serveur MCP est le programme qui publie ces capacités via le protocole de contexte de modèle : des outils porteurs d'actions à côté de ressources porteuses d'informations comme des fichiers, des documents ou des enregistrements.

De retour dans l'exemple du e-commerce, le tableau se met en place. Les interfaces client, commandes et e-mail restent exactement où elles sont ; rien n'est remplacé. Un serveur MCP superposé au-dessus d'elles propose trois outils : récupérer le client, récupérer la dernière commande, envoyer un e-mail. Lorsqu'une requête arrive, l'application se connecte au serveur et découvre le catalogue d'outils, chaque entrée expliquant son objectif et les entrées attendues.

En lisant la requête, le modèle aligne les outils : d'abord le client, ensuite la dernière commande, enfin l'e-mail. En coulisses, chaque outil appelle son interface correspondante, collecte le résultat et le restitue à l'application. Les systèmes existants continuent de fonctionner sans être touchés. MCP présente les capacités actuelles comme des outils adaptés à l'IA.

La distinction finale constitue l'épine dorsale de la pièce. Avec les interfaces classiques, les développeurs définissent le flux et le figent dans le code ; dans le dispositif MCP, les développeurs publient les capacités sous forme d'outils et c'est le modèle qui choisit. La découverte diffère de la même manière : les développeurs lisent des documents et cherchent des points de terminaison, tandis que le serveur MCP diffuse des définitions d'outils standard. Lorsqu'un outil d'annulation de commande apparaît demain, la prochaine connexion le découvre simplement.