MCP vs API classique : quelles différences et quand choisir ?

MCP et les APIs classiques ne s’opposent pas : ils répondent à des besoins différents et peuvent fonctionner ensemble. Une API classique expose les fonctions d’un service à des applications qui connaissent son contrat. MCP décrit une manière standard pour qu’un client d’IA découvre des outils, ressources et prompts fournis par un serveur. Si vous construisez le cœur d’un produit, une API reste généralement la base. Si vous voulez rendre un contexte ou un outil utilisable par plusieurs clients IA compatibles, MCP peut servir de couche d’adaptation contrôlée.

Verdict rapide : ne remplacez pas une API métier stable par MCP uniquement parce que le terme est nouveau. Gardez une API quand vous maîtrisez les consommateurs, les endpoints et les contrats. Ajoutez MCP lorsque le besoin est réellement de connecter une application d’IA à des capacités explicitement limitées, avec découverte et permissions adaptées.

Présentation d’une API classique

Une API est une interface qui permet à un logiciel d’appeler un autre logiciel. Dans le web, elle utilise souvent HTTP : un client envoie une requête vers un endpoint, le serveur vérifie l’identité et les droits, puis retourne une réponse. Une API peut créer un compte, lire une commande, publier un contenu ou calculer un résultat selon le contrat défini par son éditeur.

L’avantage d’une API est la précision. Son équipe définit les endpoints, les schémas, les codes d’erreur, les politiques d’authentification et les limites de débit. Les applications clientes intègrent ce contrat de manière explicite. Cette approche est adaptée aux applications mobiles, frontends, services internes et automatisations où les actions sont connues à l’avance.

Présentation de MCP

MCP, pour Model Context Protocol, est un protocole qui organise la relation entre un client d’IA et un serveur exposant des capacités. Ces capacités peuvent être des ressources à lire, des outils à appeler ou des modèles de prompts. Le client peut découvrir ce qui est proposé et transmettre un contexte ou une demande selon le protocole.

MCP est utile quand le même type de contexte doit être présenté à des assistants différents ou quand un outil doit être décrit de façon structurée à un client d’IA. Il n’annule pas les mécanismes métier : un serveur MCP peut appeler une API existante en arrière-plan. Il doit alors appliquer exactement les mêmes contrôles d’identité, d’autorisation, de validation et de journalisation.

Tableau comparatif : MCP vs API classique

Critère	API classique	MCP
But principal	Exposer les fonctions d’un service	Exposer contexte et outils à un client IA
Client typique	Frontend, mobile, service, script	Application ou environnement d’IA compatible
Contrat	Endpoints, méthodes, schémas et erreurs	Capacités, outils, ressources et messages du protocole
Découverte	Souvent documentation ou SDK	Capacités décrites par le serveur
Premier usage conseillé	Fonction métier stable	Recherche ou ressource en lecture seule
Sécurité	Authentification, autorisation, validation	Les mêmes, plus contrôle du contexte et des outils IA

Ce tableau simplifie volontairement. Une API peut aussi alimenter une IA, et MCP peut exposer un outil qui correspond à une opération métier. Le choix dépend du consommateur et du niveau de contrôle attendu, pas d’une hiérarchie de modernité. La section du 2026-10-18 porte sur tools/list, les contrôles exigés par la spec, et les cas où l’API REST reste le contrat.

Cas d’usage selon votre profil

Équipe qui construit un SaaS

Pour une application web ou mobile, commencez par une API claire. Elle doit préciser les actions, les rôles, les limites et les erreurs. Si l’équipe veut plus tard permettre à un assistant de rechercher une documentation ou préparer une action, un serveur MCP peut consommer cette API avec un compte à permissions réduites. Ne donnez pas au serveur MCP un accès administrateur parce que l’API le permet techniquement.

Développeur qui automatise une documentation

Un serveur MCP de recherche en lecture seule est un bon pilote. Il donne à l’assistant une source de vérité sans lui permettre de modifier le contenu. L’API ou le moteur de recherche existant reste la couche qui accède réellement aux données ; MCP décrit la capacité au client IA.

Débutant ou petite équipe

Ne créez pas deux couches si une seule suffit. Si vous avez besoin d’une route pour votre frontend, construisez et sécurisez l’API. Si vous avez besoin de demander à un assistant « retrouve cette procédure », utilisez un serveur MCP limité ou un outil existant après avoir vérifié sa provenance. La complexité a un coût de maintenance et de sécurité.

Sécurité : le point commun le plus important

Ni MCP ni une API ne sont sûrs par défaut. Une API doit contrôler qui appelle, à quoi cette personne a accès, quelles données sont acceptées et ce qui est journalisé. Un serveur MCP qui s’appuie sur cette API doit conserver ces contrôles, pas les contourner pour « faciliter » la conversation.

MCP ajoute un risque spécifique de contexte non fiable. Une ressource renvoyée par le serveur peut contenir une instruction hostile ou une donnée sensible. Le client doit traiter ce contenu comme des données, pas comme une autorisation. Les outils avec effets de bord, comme créer une issue, envoyer un message ou modifier une base, demandent des confirmations, un environnement de test et une cible explicite.

Authentification et autorisation

L’authentification répond à « qui appelle ? ». L’autorisation répond à « que peut-il faire ? ». Gardez cette différence dans les deux architectures. Un token valide ne doit pas automatiquement donner le droit d’accéder à toutes les ressources. Préférez des comptes dédiés et des scopes limités pour un serveur MCP, particulièrement pendant un pilote.

Avantages et limites

Une API classique offre un contrat maîtrisé et souvent bien adapté à des consommateurs connus. Elle demande toutefois de documenter et maintenir les intégrations. MCP facilite la présentation cohérente de capacités à des clients IA, mais introduit un nouveau serveur, un modèle de permissions et des flux de contexte à auditer.

Le mauvais choix est celui qui masque la responsabilité. Une API trop générale ou un serveur MCP à permissions trop larges devient difficile à sécuriser. La solution robuste est souvent hybride : API métier stable, serveur MCP restreint pour un cas IA précis et observations avant élargissement.

Comment choisir en cinq questions

Qui est le client : une application classique ou un environnement IA ?
L’action est-elle une fonction métier stable ou une ressource/outillage de contexte ?
Les permissions peuvent-elles être limitées à un cas lecture seule ?
L’équipe peut-elle documenter, tester et journaliser la nouvelle couche ?
Existe-t-il déjà une API à réutiliser plutôt qu’une seconde source de vérité ?

Vérification : votre réponse décrit un consommateur concret, une donnée ou action précise et un modèle d’autorisation. Si elle se résume à « parce que c’est IA », le besoin n’est pas assez défini.

FAQ

MCP remplace-t-il REST ?

Non. MCP et REST répondent à des contextes différents. Un serveur MCP peut s’appuyer sur une API REST existante.

Faut-il une API avant un serveur MCP ?

Pas toujours, mais une séparation claire des données et des autorisations reste nécessaire. Une API existante peut simplifier la réutilisation d’un contrat métier.

MCP est-il réservé aux données de texte ?

Non. Le protocole décrit des capacités ; les données et outils disponibles dépendent du serveur et du client.

Quelle approche coûte le moins cher ?

Le coût dépend de l’infrastructure, de la maintenance, des appels et du contexte. Sans mesure de votre usage, aucun classement de coût n’est fiable.

Puis-je exposer une API de production à un assistant ?

Commencez par un environnement de test ou une capacité lecture seule avec un compte limité. Toute action de production demande une revue séparée.

Recommandation finale

Choisissez l’API classique pour le contrat métier de votre produit et MCP pour un besoin IA clairement borné. L’architecture la plus cohérente est celle où chaque couche garde ses responsabilités : API sécurisée, serveur MCP minimal et client qui demande des confirmations avant les actions sensibles.

Mise à jour du 2026-10-18 : découverte des outils, sécurité, et quand REST reste préférable

Cette mise à jour ne classe aucun protocole et ne contient aucun prix. Elle rapporte ce que la spécification MCP 2026-07-28 dit de la découverte des outils et de la sécurité, d’après les pages Tools, autorisation, versioning, le journal des changements et le billet de publication, relus le 2026-10-18. Aucun serveur n’a été démarré pour cette section. Un client resté sur 2025-06-18, révision déjà citée plus bas, n’a ni ttlMs, ni server/discover, ni le fonctionnement sans session décrit ici. Les rôles hôte, client et serveur sont ceux de MCP : définition, fonctionnement et sécurité.

Ce que `tools/list` renvoie

Un serveur qui déclare la capacité tools doit répondre à tools/list avec les outils disponibles pour la requête en cours. Chaque entrée a un nom, une description et un inputSchema en JSON Schema. Le titre, le schéma de sortie, les icônes et les annotations peuvent manquer. La liste peut être vide. Elle peut aussi changer plus tard. Elle ne doit pas varier d’une connexion à l’autre, ni parce qu’une autre requête a été envoyée sur la même connexion.

L’autorisation peut filtrer cette liste. La spec donne l’exemple d’un serveur qui ne renvoie que les outils permis par les scopes du jeton. Elle ne l’exige pas. Un compte limité à la lecture peut donc voir un outil d’écriture. Le refus doit alors se faire dans tools/call, pas seulement dans la liste affichée au modèle.

Tant que l’ensemble ne change pas, le serveur devrait renvoyer les outils dans le même ordre. Le résultat de liste inclut ttlMs et cacheScope. Le premier indique combien de temps la réponse peut être traitée comme fraîche. Le second vaut public ou private : il dit si un cache partagé a le droit de la stocker. La pagination passe par un curseur. Quand listChanged est annoncé, le serveur devrait notifier les clients qui ont ouvert subscriptions/listen avec toolsListChanged.

Le serveur doit implémenter server/discover. Cet appel annonce les versions supportées, les capacités et l’identité. Le client peut s’en servir avant le reste. Il peut aussi envoyer une autre requête directement et gérer UnsupportedProtocolVersionError si la version ne convient pas. En HTTP, les POST doivent porter Mcp-Method et Mcp-Name. Une passerelle peut router ou limiter le débit sur ces en-têtes, sans parser le JSON. Le billet du 28 juillet 2026 indique que le serveur rejette une requête dont les en-têtes et le corps divergent.

Cette liste est destinée au modèle. La spec parle d’outils model-controlled : le modèle les découvre et peut les invoquer à partir du prompt. Elle ne fixe pas l’interface. La page Tools recommande un humain capable de refuser l’appel, un affichage des outils exposés, un signe visible au moment de l’invocation, et une confirmation. Le principe général, sur la page de spécification, va plus loin : consentement explicite avant toute invocation. Un client qui saute la confirmation n’est pas rejeté pour ce motif. Le protocole ne vérifie pas l’interface.

Les noms d’outils ne sont uniques qu’à l’intérieur d’un serveur. Deux serveurs peuvent exposer search. Un client qui les agrège doit les distinguer, par exemple avec un préfixe. Le name renvoyé dans serverInfo n’est pas unique entre serveurs. Ce nom ne suffit pas à les distinguer.

Une API REST ne redécouvre pas la route à chaque appel. Le code appelle GET /orders/123 parce qu’une personne a écrit l’appel, ou parce qu’un SDK a été généré depuis la documentation.

Sécurité dans la révision 2026-07-28

MCP ne fait pas respecter ses propres principes. La page de spécification écrit que le protocole ne peut pas les appliquer. Parmi les mesures demandées aux implémentations : prévoir le consentement, documenter les effets, limiter l’accès aux données. L’utilisateur consent aux accès et aux opérations, et décide de ce qui est partagé. L’hôte ne transmet pas les données utilisateur à un serveur sans consentement explicite. Un outil est traité comme une exécution de code arbitraire. Les annotations qui décrivent son comportement sont non fiables, sauf si le serveur qui les envoie est de confiance.

La page Tools distingue les contrôles. Le serveur doit valider les entrées, contrôler l’accès, limiter le débit et assainir les sorties. Le client devrait confirmer les opérations sensibles, montrer les arguments avant l’appel, vérifier le résultat avant de le passer au modèle, couper un appel trop long et journaliser l’usage. Afficher les arguments avant l’appel limite un cas concret : un prompt qui y place un secret que le serveur n’avait pas à recevoir.

L’autorisation HTTP est optionnelle. Lorsqu’elle est utilisée, le serveur MCP est un serveur de ressources OAuth. Il doit rejeter un jeton qui n’a pas été émis pour lui. L’API en amont ne reçoit pas ce jeton. Elle reçoit un autre jeton, émis par son serveur d’autorisation. La spec interdit de faire suivre le jeton du client MCP. En stdio, elle demande de ne pas suivre ce flux OAuth et de lire les identifiants dans l’environnement du processus.

Un serveur MCP placé devant une API tierce peut agir avec une autorisation obtenue pour un autre client. Si ce proxy garde un client ID statique et enregistre des clients dynamiquement, la spec exige un consentement utilisateur pour chacun de ces clients avant de transmettre la demande au serveur d’autorisation tiers. Créer un serveur MCP en TypeScript commence par un outil de lecture seule et une validation des entrées, plutôt que par ce proxy.

Quand une API REST reste préférable

Gardez l’API REST quand c’est votre code qui appelle : frontend, application mobile, autre service. Il a besoin d’une route, d’un schéma et d’erreurs stables. MCP vise un hôte d’IA qui choisit l’outil en lisant le prompt. Le frontend n’a pas à passer par ce choix pour afficher une commande.

Le paiement et la suppression de compte restent sur l’API. Un changement de rôle aussi. L’application appelle l’endpoint, avec son contrôle d’autorisation. Une recherche en lecture seule peut être exposée plus tard en MCP, avec un compte dont les scopes s’arrêtent à la lecture. Prévoyez la confirmation dans le client. Elle ne compense pas un outil de suppression déjà visible par le modèle.

Un écran qui charge toujours la même ressource se passe de découverte. GET /orders/123 désigne la commande. Un modèle qui liste les outils, en retient un et réécrit la réponse ne suit plus la route écrite dans le code. Le temps ajouté n’a pas été mesuré.

Sans client MCP compatible, ce serveur ne sert pas le frontend. Recopier chaque endpoint en outil pose un second problème : le modèle doit reconnaître un nom court, et deux outils search venus de deux serveurs se confondent. L’appelant d’une API vise une URL, pas un nom à deviner.

Une API sans authentification, sans validation et sans journal n’est pas plus sûre pour autant. Elle est le bon contrat quand le client est du code, que l’action est connue avant l’exécution, et que le modèle ne doit pas découvrir qu’il a le droit de la lancer.

Vérification : notez le client, code ou hôte IA, la route ou l’outil, et le jeton qui ne part pas vers l’API d’amont. Si la décision se résume à « MCP devant toute l’API », le périmètre n’est pas posé.

Pages relues le 2026-10-18

Sources et limites

Model Context Protocol — introduction : concepts et usages du protocole.
Model Context Protocol — specification, révision 2025-06-18 : contrat cité à la première publication. Un client sur cette révision n’a pas les champs décrits le 2026-10-18.
Model Context Protocol — specification, révision 2026-07-28 : principes de consentement et de sûreté des outils, relus le 2026-10-18.
Tools, révision 2026-07-28 : tools/list, schémas, ordre, contrôles serveur et client.
Authorization security considerations, révision 2026-07-28 : audience du jeton et interdiction de le transmettre à l’API d’amont.
MDN — Overview of HTTP : principes HTTP pour APIs web.
OWASP API Security Project : risques et contrôles des APIs.

Ce comparatif ne recommande aucun fournisseur ou produit. Les détails techniques dépendent de l’architecture et des versions choisies. La section du 2026-10-18 n’inclut aucun essai exécuté.