# « MCP remplace toute API » : ce que ce raccourci simplifie à l’excès > Le Model Context Protocol ajoute de la découvrabilité pour un agent, mais ne remplace ni une API REST ni une API GraphQL déjà en place sur un site. - Auteur : WordPress Développement - Publié le : 2025-06-20 - Mis à jour le : 2026-09-30 - Catégorie : IA & MCP - URL : https://www.wpmoderne.fr/ia-mcp/mcp-remplace-toute-api-raccourci/ ## L’essentiel - MCP décrit des outils pour un agent, il ne transporte pas les données d'une application classique - Une API REST reste nécessaire pour un client web ou mobile - Confondre les deux couches complique une architecture sans raison « On va migrer toute l'API vers MCP » : cette phrase, entendue lors d'un cadrage de projet, part d'une confusion fréquente entre deux couches qui n'ont pas la même fonction. Le Model Context Protocol ne remplace pas une API REST ou GraphQL existante : il ajoute une couche de description destinée spécifiquement à un agent capable d'appeler des outils. Cette confusion mérite d'être clarifiée avant qu'un projet ne s'engage dans une réécriture inutile. Sur aucun de nos projets ayant adopté MCP, une seule route REST n'a été supprimée en conséquence — et c'est précisément le signe que le raccourci « MCP remplace toute API » simplifie à l'excès ce que ce protocole apporte réellement. ## Ce que transporte une API REST classique Une API REST WordPress, exposée via `register_rest_route()`, sert un client web, une application mobile ou un service tiers qui a besoin de lire ou d'écrire des données selon un contrat fixe, connu à l'avance par le développeur qui consomme l'API. Ce client sait exactement quelle route appeler et quel format de réponse attendre, parce que la documentation de l'API le lui indique. Cette API continue de fonctionner exactement de la même façon, que le site expose ou non un serveur MCP en parallèle. Les deux ne se substituent pas l'une à l'autre, elles répondent à des besoins différents. ## Ce qu'ajoute réellement un serveur MCP > L'essentiel à retenir : MCP décrit des outils pour un agent, il ne transporte pas les données d'une application classique ; Une API REST reste nécessaire pour un client web ou mobile ; Confondre les deux couches complique une architecture sans raison Un serveur MCP répond à un besoin différent : permettre à un agent, qui ne connaît pas à l'avance les capacités précises du site auquel il se connecte, de découvrir dynamiquement quels outils sont disponibles et comment les appeler correctement. Cette découvrabilité est ce qui manque structurellement à une API REST classique, pensée pour un développeur qui lit la documentation, pas pour un agent qui doit décider seul quel outil utiliser. - Découverte dynamique des outils disponibles, sans documentation externe préalable - Description standardisée des paramètres attendus par chaque outil - Format de communication commun à tous les clients compatibles MCP - Aucune garantie de performance ou de latence comparable à une API REST optimisée ## Un exemple concret : un site avec les deux couches Sur un projet e-commerce, l'API REST WooCommerce continue de servir l'application mobile de l'équipe commerciale, qui l'appelle avec un contrat fixe et documenté. En parallèle, un serveur MCP expose un sous-ensemble d'outils — vérifier un stock, créer une commande de test — destinés spécifiquement à un agent de support capable de répondre à une demande client en langage naturel. Ce qui compte dans cette architecture, c'est que la logique métier n'existe qu'à un seul endroit. La route REST et l'outil MCP appellent la même fonction PHP, qui vérifie le stock et applique les mêmes règles. L'un et l'autre ne sont que deux façons différentes d'y accéder : une route au contrat fixe pour l'application mobile, une description d'outil pour l'agent. ## À quoi ressemble un outil côté agent Le protocole repose sur des messages JSON-RPC 2.0. Un agent qui se connecte au serveur demande d'abord la liste des outils avec la méthode `tools/list`. Chaque outil est décrit par un nom, une description en langage naturel et un schéma JSON qui précise les paramètres attendus dans le champ `inputSchema`. ``` { "name": "verifier_stock", "description": "Renvoie la quantité disponible d'un produit à partir de sa référence.", "inputSchema": { "type": "object", "properties": { "sku": { "type": "string", "description": "Référence du produit, par exemple TS-001" } }, "required": ["sku"] } } ``` Pour l'utiliser, l'agent envoie ensuite une requête `tools/call` avec le nom de l'outil et ses arguments, puis reçoit un résultat sous forme de contenu que le modèle peut lire. ``` { "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "verifier_stock", "arguments": { "sku": "TS-001" } } } ``` ``` { "jsonrpc": "2.0", "id": 2, "result": { "content": [ { "type": "text", "text": "TS-001 : 14 unités disponibles." } ], "isError": false } } ``` On mesure ici la différence de nature entre les deux couches. Une route REST répond à une question que le développeur du client connaît déjà ; un outil MCP se présente lui-même à un interlocuteur qui ne l'a jamais vu. Rien dans cet échange ne permettrait de servir une page web, de paginer un catalogue de milliers de produits ou d'alimenter une application mobile qui attend un contrat stable. ## Les pièges d'une migration « tout MCP » Les projets qui ont envisagé de remplacer leur API par un serveur MCP butent en général sur les mêmes points. - **Les clients historiques cessent de fonctionner :** une application mobile ou un site web ne sait pas dialoguer en décrivant des outils ; elle appelle des routes précises et attend un format précis. - **Les droits d'accès sont à reprendre :** un outil exposé à un agent doit vérifier les mêmes capacités que la route correspondante. Aucune protection ne se transmet d'une couche à l'autre sans que vous l'écriviez. - **La surface d'appel s'élargit :** plus un site expose d'outils, plus un agent a de chances d'en choisir un de travers. Mieux vaut peu d'outils, bien décrits, que le miroir de toutes les routes. - **Les actions d'écriture demandent un garde-fou :** créer une commande ou supprimer un contenu depuis une instruction en langage naturel appelle une confirmation humaine ou un périmètre strictement limité. ## Quand ajouter un serveur MCP, et quand s'en passer Un serveur MCP a du sens lorsqu'un agent doit agir sur le site sans qu'un développeur ait prévu à l'avance chaque scénario : assistant de support, automatisation interne, outil d'administration piloté en langage naturel. Il n'apporte rien si le seul consommateur de votre API est votre propre front, dont le contrat est figé et versionné. Dans ce cas, l'API REST suffit, et la réécrire serait un coût sans bénéfice. La démarche raisonnable consiste à partir de l'existant : identifier les deux ou trois actions qu'un agent aurait réellement besoin d'accomplir, les décrire comme des outils qui appellent le code métier déjà en place, et laisser tout le reste de l'API tel quel. Le protocole lui-même évolue encore, avec des révisions successives de sa spécification : en figeant la couche métier derrière une fonction unique, vous limitez l'impact d'un changement de version à la seule couche de description. > Une couche de description n'est pas une couche de données : elle dit à l'agent ce qu'il peut demander, pas où le site range ses informations. ## Conclusion « MCP remplace toute API » est un raccourci séduisant, mais inexact. Le Model Context Protocol décrit des outils pour un agent ; l'API REST ou GraphQL sert des clients dont le contrat est connu d'avance. Les deux coexistent, s'appuient sur le même code métier, et n'ont ni les mêmes consommateurs ni les mêmes garanties. Avant de lancer une réécriture, posez-vous une question simple : qui appellera cette API, un agent qui découvre, ou un client qui connaît déjà le contrat ? La réponse indique, presque toujours, qu'il faut conserver l'existant et n'ajouter que ce qui manque.