Serveur MCP ou API : que proposer dans votre produit ?

Un serveur MCP ne remplace pas votre API : il donne aux clients IA un moyen standard de découvrir et d’appeler les outils qui s’appuient sur votre service. Pour un produit utilisé à la fois par des applications et des assistants, le choix MCP vs API revient souvent à proposer 2 interfaces qui partagent les mêmes règles métier. Conservez l’API pour les intégrations applicatives et ajoutez MCP lorsque l’accès depuis les clients IA existants répond à un besoin précis de vos clients.

MCP et API : que compare-t-on exactement ?

On compare une interface logicielle généraliste à un protocole conçu pour les intégrations avec l’IA. Une interface de programmation d’application, ou API, définit la manière dont un logiciel demande des données ou déclenche des actions. REST, pour Representational State Transfer, est un style d’architecture couramment utilisé pour les API HTTP. Le protocole MCP, pour Model Context Protocol, standardise l’accès des applications IA compatibles à des fonctionnalités externes.

Imaginez que votre produit soit un atelier. L’API en est l’entrée de service, avec des consignes documentées. Le serveur MCP ajoute un accueil capable de présenter les prestations disponibles dans un format que les clients IA comprennent déjà. Derrière ce comptoir, les personnes qui font le travail et les règles qu’elles appliquent restent essentielles.

Pour un développeur, il s’agit donc d’un adaptateur autour de fonctionnalités existantes. Pour un responsable produit, c’est un nouvel endroit où les clients peuvent utiliser le produit. Pour la personne chargée de l’exploitation, c’est une interface supplémentaire dont quelqu’un doit gérer les accès et les défaillances.

MCP peut aussi exposer des fonctionnalités locales sans appeler d’API HTTP. L’utiliser comme surcouche est pratique, mais ce n’est pas obligatoire. La documentation de l’architecture MCP distingue l’application IA des serveurs qui lui fournissent des fonctionnalités. Pour une présentation plus générale du protocole, consultez notre article sur ce qu’est MCP.

Serveur MCP ou API REST : les différences en un tableau

REST convient aux intégrations directes entre applications ; MCP ajoute une interface d’outils commune aux clients IA compatibles. Dans les deux cas, il vous revient de contrôler les autorisations et de garantir le bon fonctionnement métier.

Ces distinctions s’appuient sur les recommandations de conception des API REST, les transports MCP et la spécification d’autorisation MCP. Le partage des règles métier, dans la dernière ligne, relève d’une recommandation d’architecture.

Une API peut déjà disposer d’un schéma lisible par machine. La spécification OpenAPI décrit les interfaces HTTP aussi bien pour les humains que pour les logiciels. MCP se distingue par son contrat commun pour les échanges à l’exécution avec les applications IA, et non par une capacité exclusive à décrire des paramètres.

Ce que MCP apporte à une API existante

MCP permet de réutiliser la même interface d’outils dans plusieurs applications hôtes compatibles. L’hôte est l’application IA qui coordonne le modèle et ses connexions. Vous implémentez les fonctionnalités du serveur ; l’hôte fournit son client MCP.

Concrètement, MCP apporte :

• La découverte des outils : tools/list indique à un client connecté quelles opérations sont disponibles.
• Une définition standard des outils : un nom, une description et un schéma JSON Schema pour les entrées. JSON Schema décrit les champs attendus et leurs types. Un outil peut aussi déclarer un schéma de sortie.
• Un mode d’appel commun : tools/call transmet le nom de l’outil et ses arguments ; les résultats reviennent dans le format de message MCP.

La spécification des outils définit ces opérations. Un service de gestion de tickets peut, par exemple, déclarer create_ticket, en précisant quand l’utiliser et quels champs il exige. Le client peut exploiter cette définition sans qu’un plugin spécifique à ce service ait été développé dans l’application hôte.

L’intérêt dépend des utilisateurs visés. Si votre propre backend est le seul appelant, vous maîtrisez peut-être déjà les deux côtés de l’intégration. Si vos clients veulent accomplir la même tâche dans différentes applications IA prises en charge, un protocole commun devient plus utile.

Serveur MCP ou API : le déploiement reste un choix à part

Ajouter MCP n’oblige pas à déployer un service supplémentaire. Vous pouvez placer un gestionnaire MCP à côté de votre API, déployer un adaptateur distinct qui l’appelle ou exposer directement une couche de services existante. Le choix dépend des besoins d’isolation, de la répartition des responsabilités et du rythme des mises en production.

Avec stdio, le client lance un processus et échange des messages via son entrée et sa sortie standard. Avec Streamable HTTP, il contacte un endpoint MCP en HTTP. Ce sont les modes de transport standard ; dans le cas d’une connexion réseau, le point d’accès doit toujours être joignable depuis le client réellement utilisé.

Le schéma illustre l’option où MCP sert de surcouche à l’API. Appeler un service interne commun est également valable, à condition que le parcours MCP conserve les mêmes contrôles d’autorisation et de validation.

API ou MCP : créer le même ticket par les deux interfaces

Le ticket obtenu doit être identique, quelle que soit l’interface qui en demande la création. Prenons un outil fictif de suivi des incidents : un client souhaite créer un ticket intitulé « Login button fails » dans le projet EXAMPLE. Les noms et champs ci-dessous illustrent des contrats applicatifs ; ils ne correspondent pas à une API tierce.

Avec l’API REST

L’application envoie une requête authentifiée à POST /tickets, avec ce corps JSON : {"project_key":"EXAMPLE","title":"Login button fails","request_key":"demo-ticket"}.

L’API détermine l’identité de l’appelant, vérifie son accès au projet, valide le titre, puis appelle le service de création de tickets. Celui-ci renvoie l’identifiant et le statut du ticket créé.

Ici, request_key est une clé d’idempotence définie par l’application : relancer la même demande logique avec la même clé doit renvoyer le résultat initial, au lieu de créer un autre ticket. C’est un choix de conception propre à cet exemple, pas une garantie fournie automatiquement par REST.

Avec le serveur MCP

Le serveur déclare un outil nommé create_ticket, avec une description telle que « Créer un ticket dans un projet auquel l’utilisateur actuel a accès ». Son inputSchema exige les champs de type chaîne de caractères project_key, title et request_key.

Après avoir découvert l’outil, le client envoie une requête tools/call dont les paramètres sont {"name":"create_ticket","arguments":{"project_key":"EXAMPLE","title":"Login button fails","request_key":"demo-ticket"}}. Il s’agit des paramètres d’appel, pas d’un message complet du protocole.

L’adaptateur transmet les arguments au même service de gestion de tickets ou appelle l’endpoint POST /tickets existant. Il renvoie l’identifiant et le statut du ticket dans le résultat de l’outil. MCP standardise la découverte et l’appel ; votre application définit ce que signifie créer un ticket.

Des contrôles communs aux deux interfaces

L’adaptateur ne doit jamais permettre de contourner les permissions du projet. Déduisez l’identité et l’organisation de l’appelant d’un contexte d’authentification fiable, puis vérifiez son accès au projet. Un identifiant d’organisation n’est pas digne de confiance simplement parce qu’un modèle l’a fourni.

Conservez la même clé d’idempotence lorsque vous relancez une même action. Des demandes répétées du modèle avec des clés différentes ne sont pas automatiquement des doublons : votre application doit donc définir comment repérer et examiner les écritures répétées.

Quels clients IA documentent leur prise en charge de MCP ?

Claude, ChatGPT, Cursor et GitHub Copilot documentent tous la prise en charge de MCP, mais leurs modes de connexion diffèrent. Les vérifications ci-dessous ont été réalisées à partir de leur documentation officielle en ligne le 17 octobre 2026. Elles attestent d’une prise en charge documentée, pas d’un test pratique d’interopérabilité pour chaque serveur, fonctionnalité ou révision du protocole.

Claude

Claude, l’assistant IA d’Anthropic, prend en charge les connecteurs MCP distants personnalisés. Sa documentation sur les connecteurs précise que ces connexions partent de l’infrastructure cloud d’Anthropic. Pour ce mode de connexion, un endpoint accessible uniquement depuis votre ordinateur portable ne suffit donc pas. Les règles de l’organisation déterminent aussi qui peut ajouter un connecteur.

Pour un produit hébergé, vérifiez l’accessibilité du service et le parcours d’authentification du client avant de promettre une intégration fonctionnelle. La configuration d’un serveur local dans l’application de bureau relève d’un autre mécanisme.

ChatGPT

ChatGPT, l’application IA d’OpenAI, documente la connexion d’un serveur MCP personnalisé via Plugins. Le guide de démarrage d’OpenAI décrit l’ajout d’une URL MCP en HTTPS, la configuration de l’authentification, la création et l’installation du plugin, puis son invocation dans une conversation. Une interface visuelle personnalisée est facultative.

Ce parcours documenté exige que le serveur soit accessible depuis ChatGPT ; les instructions de développement le rendent accessible sur l’Internet public. Une commande de démarrage local issue de la configuration d’un autre client ne constitue pas une configuration équivalente.

Cursor

Cursor, l’éditeur de code IA, documente les connexions stdio, Server-Sent Events (SSE) et Streamable HTTP. Sa documentation MCP décrit la prise en charge des outils, la configuration via mcp.json et OAuth pour les serveurs qui l’exigent. SSE est un mécanisme de diffusion d’événements depuis un serveur.

Un outil de développement local et un service hébergé peuvent donc utiliser des modes de connexion différents. Adaptez votre déploiement au transport et à la configuration d’authentification pris en charge : « fonctionne dans Cursor » ne suffit pas à définir précisément la compatibilité.

GitHub Copilot

GitHub Copilot, l’assistant de programmation IA de GitHub, documente MCP dans plusieurs environnements du produit. Sa documentation sur la disponibilité couvre les environnements de développement intégrés (IDE), l’interface en ligne de commande, l’application Copilot et la configuration du dépôt pour l’agent cloud et la revue de code. La CLI prend en charge les serveurs locaux et distants ; la compatibilité varie selon l’éditeur, et les règles de l’organisation peuvent encadrer les accès.

Précisez l’environnement que vous comptez prendre en charge, par exemple Copilot dans un éditeur donné. Une connexion réussie en CLI ne prouve pas que la configuration du dépôt ou les règles de l’organisation du client autorisent ce même serveur ailleurs.

Pour découvrir des intégrations déjà disponibles, consultez le guide des meilleurs serveurs MCP. Ici, la question est de savoir si votre propre produit doit en proposer un.

Quand proposer MCP, une API ou les deux ?

Proposez MCP lorsqu’il permet d’accomplir une tâche précise depuis le client IA que votre client utilise déjà. L’enthousiasme pour un protocole ne suffit pas à justifier une interface supplémentaire à maintenir.

Proposez MCP lorsque :

• Vos clients demandent à rechercher des données dans votre produit ou à effectuer une action bien délimitée depuis une application IA existante compatible avec MCP.
• Vous devez exposer les mêmes fonctionnalités utiles à plusieurs applications hôtes compatibles.
• La tâche gagne à laisser l’assistant choisir parmi des opérations bien décrites en s’appuyant sur le contexte de la conversation.
• Vous pouvez prendre en charge le transport, l’authentification et le parcours d’installation du client visé, et désigner un responsable des incidents et des évolutions.

Conservez uniquement l’API lorsque :

• Vos appelants sont des applications, des tâches planifiées ou des intégrations partenaires dont le workflow est déjà défini.
• Vous maîtrisez l’application IA et son adaptateur d’API, sans avoir besoin de compatibilité avec des applications hôtes externes.
• Personne ne sait citer une tâche client qui gagnerait à rendre des outils accessibles depuis un autre client.
• Votre gestion des autorisations ou le comportement de votre service est encore instable. Stabilisez ces éléments avant d’ajouter un autre contrat.

Proposez les deux lorsque : les intégrations classiques restent importantes et que vos clients veulent aussi un accès conversationnel. Un produit de gestion de tickets peut conserver son API pour l’application web et les automatisations, tout en proposant une sélection d’outils MCP permettant à un assistant de rechercher et de créer des tickets.

Côté développement, réutilisez la couche de services. Côté produit, définissez les tâches et les clients pris en charge. Côté exploitation, assurez-vous de pouvoir identifier l’utilisateur à l’origine de chaque action et de révoquer son accès. Ces responsabilités restent distinctes, même lorsqu’une seule personne les assume toutes.

MCP, API et CLI : à chacun ses utilisateurs

Ces interfaces peuvent servir différents appelants au-dessus d’un même service. Une interface en ligne de commande, ou CLI, fournit des commandes aux personnes et aux scripts. Une API donne au code applicatif un contrat d’interaction programmable. MCP fournit aux applications hôtes IA compatibles une interface d’outils commune.

Si un script de déploiement utilise déjà une CLI ou une API fiable, ajouter MCP ne l’améliorera pas forcément. Si un client veut créer des tickets depuis son assistant, MCP peut éviter de développer une intégration propre à cette application hôte. Gardez l’interface adaptée à l’appelant ; ne migrez pas une automatisation qui fonctionne uniquement pour en uniformiser le sigle.

Une interface de plus à sécuriser et à maintenir

La principale contrepartie est une interface supplémentaire à prendre en charge, même si le code MCP est déployé avec votre API. Quelqu’un doit maintenir les descriptions des outils, les schémas, les dépendances, l’intégration de l’authentification et la compatibilité avec les clients.

Distinguer les identifiants d’accès des permissions

La spécification d’autorisation de MCP décrit un cadre fondé sur OAuth 2.1 pour les implémentations HTTP. OAuth permet d’accorder à une application un accès limité à un service. L’autorisation est facultative au niveau du protocole ; cela ne signifie pas qu’il est recommandé de laisser les données privées d’un produit sans protection. Le mode de gestion des identifiants d’accès en stdio diffère du cadre HTTP.

Un adaptateur peut devoir gérer des identifiants d’accès distincts : ceux que le client présente au serveur MCP et ceux qu’il utilise lui-même auprès du service sous-jacent. Vérifiez l’audience du jeton, c’est-à-dire le service auquel il est destiné, et respectez le périmètre autorisé pour l’utilisateur. Les recommandations de sécurité interdisent d’accepter aveuglément des jetons destinés à une autre ressource et de les transmettre en aval.

Dans l’exemple du ticket, des identifiants de service dotés de droits étendus ne doivent pas transformer silencieusement chaque utilisateur connecté en administrateur de projet. Conservez le contrôle d’accès dans l’opération métier commune, quelle que soit la façon dont l’adaptateur gère ses identifiants d’accès.

Concevoir les outils autour de tâches que vous pouvez prendre en charge

Exposez une action utile dont le périmètre est clair. Commencez par create_ticket ou par une recherche au périmètre limité, plutôt que par un outil sans restriction acceptant n’importe quelle URL, méthode et corps de requête.

C’est une recommandation de conception produit, pas une restriction du protocole. Une interface plus restreinte est plus facile à expliquer, à soumettre à des autorisations et à dépanner. Ne recopiez pas tous vos endpoints internes dans le catalogue d’outils au seul motif qu’un générateur sait produire leurs définitions.

Rédigez des descriptions qui précisent l’objectif de l’action et ses effets de bord. Renvoyez assez d’informations pour identifier le résultat, sans y inclure de champs sensibles sans rapport avec la tâche. Un schéma définit une structure ; il ne prouve pas que l’action demandée est autorisée ou appropriée.

Pouvoir suivre les erreurs à travers les deux interfaces

Suivez l’appel de l’outil jusqu’à l’opération sous-jacente. Consignez l’identité autorisée, le nom de l’outil, l’identifiant de requête pertinent et le résultat, sans journaliser d’identifiants d’accès ni de données sensibles superflues.

Distinguez les échecs de validation, les refus d’accès, les limites de débit et l’indisponibilité d’un service en amont. Si une écriture dépasse le délai d’attente après son envoi, appliquez les règles de nouvelle tentative de l’opération commune pour déterminer si elle a abouti avant de réessayer. MCP ne définit pas cette garantie métier à votre place.

Un serveur local demande de gérer les dépendances et les permissions d’exécution ; un serveur hébergé demande de gérer le déploiement et la disponibilité. Dans les deux cas, la maintenance reste nécessaire.

Versions et limites : maintenir deux contrats compatibles

La compatibilité du protocole et celle des outils se gèrent séparément. Lors de la vérification du 17 octobre 2026, la documentation MCP désignait 2026-07-28 comme la révision courante du protocole. Sa documentation sur les versions décrit la déclaration de version à chaque requête et la compatibilité avec les révisions antérieures fondées sur une négociation initiale.

Cela ne prouve pas que tous les clients cités plus haut implémentent cette révision. Choisissez un kit de développement logiciel (SDK) pris en charge et testez les révisions et fonctionnalités utilisées par les clients que vous visez.

Le contrat métier de votre outil est un autre sujet. Si create_ticket n’accepte plus une clé de projet et exige désormais un autre identifiant, conserver la même révision du protocole MCP ne rend pas cette modification compatible. Maintenez l’ancien contrat pendant la migration ou introduisez un remplaçant clairement distinct, avec sa documentation et une politique de retrait de l’ancienne version.

De même, fixez les limites en fonction du service et de l’application hôte que vous prenez réellement en charge : taille des résultats, périmètre des données autorisées, durée des requêtes et limites de débit en amont. Une connexion réussie au protocole ne prouve ni qu’une réponse volumineuse sera utile au modèle, ni qu’une écriture longue pourra être relancée sans risque.

Quelles promesses autour de MCP sont exagérées ?

MCP réduit les différences entre intégrations ; il ne supprime pas le travail d’intégration. Les affirmations suivantes méritent d’être nuancées :

• « L’IA a besoin de MCP pour appeler une API. » Une application IA peut implémenter ses propres outils. La documentation d’OpenAI sur le function calling décrit explicitement l’exécution de code par l’application après qu’un modèle a demandé l’utilisation d’un outil. MCP est utile lorsque l’objectif est de disposer d’une interface client-serveur commune.
• « Le schéma garantit la sécurité de l’action. » Une requête correctement structurée peut tout de même viser un projet interdit ou déclencher une écriture non souhaitée. Les permissions et les contrôles restent du ressort de l’application.
• « MCP remplace le backend. » Le protocole donne accès à des fonctionnalités ; il ne fournit ni vos règles de gestion des tickets, ni votre base de données, ni la fiabilité de votre service.
• « MCP conserve toujours un état de session. » Cette opposition systématique à REST ignore le modèle par requête de la spécification actuelle et la manière dont elle traite les anciennes sessions liées à une connexion. Vérifiez la révision du transport que vous implémentez.

La promesse la plus solide est mesurée et utile : vos clients peuvent réutiliser une interface d’outils prise en charge depuis des applications hôtes compatibles, tandis que vous gardez la maîtrise du service sous-jacent.

Par où commencer pour passer à la mise en œuvre ?

Choisissez une tâche client et un client IA cible avant de constituer un catalogue MCP. Pour un responsable produit qui évalue la création de tickets, l’étape suivante consiste à établir une courte liste de critères d’acceptation avec le développeur chargé de l’API existante.

1. 1

   Définir l’action commune

   Précisez ses entrées, son résultat, ses limites d’autorisation et son comportement face aux demandes en double. Conservez ces règles dans le service existant.

2. 2

   Exposer un outil au périmètre précis

   Ajoutez la définition et le gestionnaire MCP, choisissez le mode de connexion documenté du client et maintenez l’API existante à la disposition de ses appelants.

3. 3

   Vérifier les comportements essentiels

   Testez une requête autorisée, un refus d’accès au projet, une écriture répétée et une requête en échec vers le service en amont. Confirmez que les deux interfaces produisent le même résultat métier.

Consultez le guide de création d’un serveur MCP en Python pour les détails d’implémentation. Élargissez le catalogue une fois que le premier workflow justifie de continuer à le prendre en charge.

Questions fréquentes

Pourquoi utiliser MCP plutôt que des API ?

Utilisez MCP lorsqu’une interface d’outils standard, dont les fonctionnalités sont découvrables, permet à vos clients d’accéder à votre service depuis des applications IA compatibles. MCP sert souvent de surcouche à une API : il s’agit donc d’ajouter ce mode d’accès, plutôt que de remplacer le service sous-jacent.

Une API et un endpoint, est-ce la même chose ?

Non. Une API définit le contrat d’interface ; un endpoint est une adresse qui en expose une partie. Dans l’exemple des tickets, l’API comprend les opérations et les règles relatives aux données, tandis que /tickets est un chemin de ressource utilisé par une opération. L’explication des API par IBM distingue le contrat de l’adresse à laquelle la requête est envoyée.

Quels sont des exemples d’API ?

Créer un ticket, consulter le statut d’une commande ou rechercher les données d’un compte sont des exemples de fonctionnalités d’API. Un serveur MCP peut en exposer une sélection sous forme d’outils, tout en laissant leur implémentation dans l’application sous-jacente.

Quelle différence entre une API et un proxy ?

Une API définit la manière dont un logiciel interagit avec un service. Un proxy est un intermédiaire qui transmet les requêtes. Un adaptateur MCP peut appeler une API pour le compte d’un client, mais il présente aussi le contrat d’outils MCP ; la simple transmission de requêtes HTTP ne fournit pas de mécanisme de découverte des outils.

Quels sont les quatre types d’API ?

Il n’existe pas de classification universelle en quatre types. Les termes publique, privée et partenaire décrivent les publics autorisés à accéder à une API ; le terme composite décrit la combinaison d’opérations sous-jacentes. La présentation des API par IBM traite ces aspects comme des dimensions différentes. Ils ne déterminent pas s’il faut ajouter MCP à une API HTTP.

Pour vous aider à prendre des décisions concrètes sur le développement avec l’IA, abonnez-vous à la newsletter.