MCP va-t-il remplacer les API ?

Non. La plupart des serveurs MCP appellent une API existante. Les API restent la base des échanges entre logiciels ; MCP ajoute une couche standard pour que les applications d'IA puissent s'en servir.

Faut-il être développeur pour utiliser MCP ?

Pour brancher un serveur existant dans Claude, ChatGPT ou un éditeur de code, non : il suffit généralement d'ajouter une adresse ou une configuration et de s'authentifier. Pour créer un serveur sur mesure ou le sécuriser, oui.

MCP fonctionne-t-il avec d'autres modèles que Claude ?

Oui. MCP a été lancé par Anthropic mais il est ouvert : ChatGPT, Gemini, Microsoft Copilot, Cursor et Visual Studio Code le prennent en charge, et le protocole est aujourd'hui géré par l'Agentic AI Foundation (Linux Foundation).

MCP vs API : différences et lequel choisir

L’essentiel en 30 secondes

Une API est appelée par du code écrit pour elle ; MCP est un protocole standard qui expose des outils, des données et des prompts à n'importe quelle application d'IA compatible.
Un serveur MCP s'appuie généralement sur une API existante : MCP ne remplace pas les API, il les rend utilisables par un modèle.
Gardez une API (ou Make, Zapier) pour les traitements fixes, répétitifs et à fort volume ; MCP sert quand la demande varie et croise plusieurs outils.
MCP ajoute des risques (injection de prompt, outils trop permissifs) : droits minimaux et confirmation humaine pour les actions sensibles.

Une API expose les fonctions d'un logiciel à du code écrit par un développeur, qui décide quel appel faire, quand et avec quels paramètres. MCP (Model Context Protocol) est un protocole standard qui expose des outils à une application d'IA (Claude, ChatGPT, Cursor, VS Code…) : l'application découvre les outils disponibles et le modèle choisit lesquels appeler pour accomplir la demande¹. Les deux ne s'opposent pas (le vocabulaire est expliqué dans notre présentation de ce qu'est un serveur MCP) : un serveur MCP s'appuie le plus souvent sur une API existante et ajoute par-dessus une description que le modèle peut comprendre.

Qu'est-ce qui distingue MCP d'une API ?

Critère	API (REST, GraphQL…)	MCP
Qui l'utilise	Du code écrit pour cette API	Une application d'IA (l'« hôte ») via un client MCP
Qui décide des appels	Le développeur, à l'avance	Le modèle, au moment de la demande, sous le contrôle de l'application
Découverte	Documentation lue par un humain (ou spécification OpenAPI)	Le client interroge le serveur (tools/list) et reçoit noms, descriptions et schémas des outils2
Format	Propre à chaque API	Identique pour tous les serveurs : JSON-RPC 2.02
Ce qu'on expose	Des endpoints	Des outils (actions), des ressources (données) et des prompts (modèles de requêtes)3
Transport	HTTP en général	stdio (serveur local) ou Streamable HTTP (serveur distant)2
Intégrations à écrire	Une par couple application-service	Un serveur par service, réutilisable par tous les clients compatibles

La vraie différence tient dans la dernière ligne. Sans MCP, connecter cinq outils à trois applications d'IA demande quinze intégrations spécifiques. Avec MCP, chaque outil publie un serveur et chaque application un client : c'est le problème qu'Anthropic décrivait en lançant le protocole en novembre 2024⁴.

Comment fonctionne un appel MCP ?

L'application d'IA (l'hôte) ouvre un client MCP par serveur configuré.
Le client peut demander au serveur ce qu'il sait faire (server/discover dans la version 2026-07-28 de la spécification) puis la liste de ses outils (tools/list)².
Le modèle reçoit ces descriptions avec la demande de l'utilisateur et propose d'appeler un outil avec des arguments.
L'application exécute l'appel (tools/call) et renvoie le résultat au modèle, qui continue ou répond.

Le modèle ne se connecte jamais directement à vos systèmes : c'est l'application hôte qui exécute les appels. La spécification recommande d'ailleurs qu'un humain puisse toujours refuser une invocation d'outil⁵. Parler d'une IA « totalement autonome » est donc un choix de configuration, pas une propriété du protocole.

Quand garder une API classique ?

Le traitement est toujours le même : une commande crée une facture, un formulaire crée un contact dans le CRM. Un script ou un outil comme Make ou Zapier fait le travail de façon prévisible et à un coût fixe, sans modèle de langage à payer à chaque exécution.
Le résultat doit être identique à chaque fois : calculs, exports comptables, synchronisations. Un modèle peut interpréter une demande différemment d'une fois à l'autre.
Le volume est élevé : des milliers d'appels par heure passent mieux par du code que par des conversations avec un modèle.

Quand MCP apporte-t-il quelque chose ?

La demande change à chaque fois : « quelles pages ont perdu des clics ce mois-ci et pourquoi ? », « prépare un brouillon d'article sur ce sujet dans WordPress ». Écrire un script pour chaque variante n'a pas de sens.
La tâche croise plusieurs outils : Search Console, CMS, CRM, base de données. Le modèle enchaîne les appels et vous gardez la validation.
Vous utilisez déjà un assistant compatible : Claude, ChatGPT, Gemini, Microsoft Copilot, Cursor ou VS Code prennent en charge MCP⁶. Un serveur écrit une fois sert dans chacun.

Exemple concret : relier un assistant à la Search Console et à WordPress permet de demander une analyse des requêtes en baisse, puis de faire préparer un brouillon d'article, que l'équipe relit avant publication. Les mêmes opérations restent possibles avec les API seules, mais il faut écrire et maintenir le code de chaque scénario. Voir notre article sur l'automatisation de WordPress avec MCP, et le panorama MCP en marketing : serveurs et cas d'usage.

Quels risques propres à MCP faut-il connaître ?

Donner des outils à un modèle crée des risques que l'intégration API classique n'avait pas : un contenu lu par le modèle (page web, e-mail, document) peut contenir des instructions qui détournent ses actions (injection de prompt) ; une description d'outil malveillante peut orienter le modèle ; un serveur trop permissif peut agir avec plus de droits que l'utilisateur. La documentation officielle consacre une page aux bonnes pratiques de sécurité, dont l'autorisation OAuth pour les serveurs distants⁷. En pratique : droits minimaux pour chaque serveur, confirmation humaine pour toute action d'écriture ou de suppression, serveurs de sources connues. Nous détaillons ces points dans notre article sur les points de vigilance en sécurité MCP.

Où en est le standard en 2026 ?

Anthropic a publié MCP en open source le 25 novembre 2024⁴, puis l'a confié en décembre 2025 à l'Agentic AI Foundation, un fonds de la Linux Foundation cofondé par Anthropic, Block et OpenAI, avec le soutien de Google, Microsoft et AWS⁶. La spécification est versionnée par date ; la version courante (2026-07-28) rend le protocole sans état : chaque requête porte sa version et ses capacités, ce qui simplifie l'hébergement de serveurs distants². Des SDK officiels existent pour les principaux langages.

Pour aller plus loin, voir le guide complet du serveur MCP (rôles, transports, fonctionnement), notre tutoriel de création d'un serveur et l'exemple d'un serveur MCP branché sur Odoo. Pour connecter vos propres outils à un assistant IA, c'est le travail de notre équipe, qui assure la mise en production d'outils IA.