MCP ou API REST : quelle différence, et lequel choisir ?

Une API REST expose des ressources (commandes, factures, produits) derrière des URL et des verbes HTTP. Le développeur lit la documentation, choisit les appels, écrit le code qui les enchaîne et gère les erreurs. Tout est décidé à l’avance : le programme fait exactement ce qu’on lui a dit de faire, des milliers de fois par jour s’il le faut.

Un serveur MCP expose des outils décrits en langage naturel, avec un schéma de paramètres. Un client MCP (Claude, Cursor, Visual Studio Code…) se connecte, récupère la liste des outils, et c’est le modèle qui décide, au fil de la conversation, lequel appeler et avec quels arguments. Le « code d’intégration » n’est plus écrit à l’avance : il est composé à la volée à partir de votre demande.

Autrement dit, la différence entre MCP et une API ne tient pas au transport — les deux passent par HTTP — mais à qui lit la description et qui décide de l’enchaînement. REST suppose un humain qui code ; MCP suppose un modèle qui raisonne. C’est pour cela que les deux ne s’opposent pas : ils répondent à deux usages différents.

Beaucoup de comparatifs résument la différence entre MCP et API REST par une formule : REST serait sans état, MCP avec état. C’était une lecture possible des premières versions du protocole, qui prévoyaient une poignée de main initialize et un identifiant de session facultatif. Ce n’est plus une description juste.

La spécification MCP du 28 juillet 2026 rend le protocole explicitement sans état : plus d’échange initialize, plus d’en-tête Mcp-Session-Id, chaque requête se suffit à elle-même. Dans les versions précédentes déjà, le transport Streamable HTTP laissait au serveur le choix d’ouvrir une session ou non.

Le serveur MCP d’Ondes PRO a fait ce choix dès le départ : il n’émet aucun identifiant de session et ne garde rien en mémoire entre deux appels. Une requête GET sur son adresse répond 405, comme la spécification le permet pour un serveur qui n’ouvre pas de flux. Il annonce aujourd’hui les versions de protocole 2025-06-18, 2025-03-26 et 2024-11-05 ; son fonctionnement sans session correspond déjà au modèle retenu par la suite.

Le vrai critère n’est donc pas l’état, mais l’interlocuteur. Si vous lisez « il faut REST pour la scalabilité, MCP garde des sessions », vérifiez de quelle version du protocole parle l’auteur.

Non, et la façon dont la plupart des serveurs MCP sont construits le montre : un outil MCP finit presque toujours par appeler une API. MCP est une couche de description et de découverte pensée pour les modèles de langage ; il ne remplace ni le transport, ni la logique métier, ni les contrôles d’accès qui vivent derrière l’API.

Une API REST reste irremplaçable dès qu’un traitement doit être déterministe : synchroniser un catalogue chaque nuit, afficher le stock sur un site, recevoir un webhook à chaque paiement. Personne ne veut qu’un modèle « décide » de la manière d’importer 5 000 commandes. À l’inverse, écrire du code pour répondre une fois à « quelles factures de Studio Nord sont en retard ? » serait disproportionné : c’est exactement ce que MCP rend immédiat.

Le serveur MCP n’est pas une seconde porte d’entrée avec ses propres règles. L’outil ondes_appeler rejoue la requête sur la vue réelle de l’API v1 : mêmes contrôles de permission, mêmes portées de clé, mêmes quotas, même idempotence, même cloisonnement entre sociétés, mêmes messages d’erreur structurés. Aucune ligne de contrôle n’est réécrite côté MCP, donc aucune ne peut diverger.

La documentation suit le même principe. Les outils ondes_guide, ondes_chercher et ondes_ressource servent, section par section, le guide engendré depuis les routes réelles de votre espace — celui que lit un développeur dans l’administration. Le contexte permanent du serveur pèse environ 2 700 tokens, là où l’ancien fichier de documentation qu’on copiait dans les dépôts en pesait 44 000, et devenait faux dès qu’il était copié.

Conséquence pratique : ce que votre assistant fait par MCP, votre code peut le refaire par REST à l’identique, et inversement. Les appels passés par MCP figurent d’ailleurs dans le même journal que les appels REST, marqués « MCP ».

Le protocole n’est ni plus ni moins sûr qu’une API : tout dépend de ce que le serveur autorise. Le risque propre à MCP tient à l’autonomie du modèle — il peut enchaîner des appels que personne n’a relus. C’est pourquoi les garde-fous d’Ondes PRO sont dans le serveur : écritures en mode test par défaut quand la ressource a un jumeau, simulation, plan à confirmer pour l’assistant intégré, et annonce systématique du mode employé.

Côté identité, une connexion OAuth agit avec vos droits complets, pendant une heure par jeton, et se révoque immédiatement ; une clé API garde ses portées limitées, que vous l’utilisiez en REST ou en MCP. Le détail est sur la page sécurité du serveur MCP.