MCP ou API : quelle différence, et pourquoi ça change tout

« On a déjà une API, pourquoi ajouter un protocole ? » C'est l'objection que j'entends le plus souvent en revue d'architecture, et elle est légitime. La réponse n'est pas que MCP remplace votre API. C'est que votre API et le modèle ne parlent pas la même langue. Un endpoint qui existe, et un modèle qui sait quand et comment l'appeler à l'exécution, ce sont deux problèmes différents.

Le point de départ : une API existe déjà, pourquoi un standard

Vous avez sans doute déjà une API REST, GraphQL ou gRPC. Elle est documentée, authentifiée, versionnée. Vu de l'ingénieur, un agent qui veut lire une fiche client appelle GET /clients/:id, point final. Sauf qu'une API est écrite pour un développeur : quelqu'un qui lit la doc, choisit le bon endpoint et écrit le code d'appel. Un modèle, à l'exécution, n'a rien de tout ça. Il a une conversation, un contexte, et une décision à prendre. Tout l'écart entre « l'endpoint existe » et « le modèle sait s'en servir au bon moment » est précisément ce qu'un standard vient combler.

Ce qu'une API classique fait, et ce qu'elle ne dit pas au modèle

Une API expose des opérations. Ce qu'elle ne fournit pas, dans une forme qu'un modèle peut consommer à l'exécution : la liste des actions disponibles, à quoi sert chacune en langage clair, les arguments attendus et leur forme, ce que renvoie un appel, et comment s'authentifier pour cet utilisateur précis. Une spec OpenAPI en couvre une partie, mais elle est pensée pour le temps de développement, pas pour un modèle qui décide en direct. Résultat : les équipes réécrivent aujourd'hui un « outil » par endpoint, à la main, puis le réécrivent encore pour chaque framework. Du travail invisible, répété, et jamais tout à fait identique d'une application à l'autre.

• La description que le modèle lit pour comprendre quand et pourquoi utiliser l'outil.
• Le schéma des arguments, et leur validation avant l'appel.
• L'authentification par utilisateur, pas un jeton unique qui donne tout à tout le monde.
• Le formatage du résultat pour qu'il tienne dans le contexte : pagination, troncature.
• La traduction des erreurs de l'API en quelque chose que le modèle peut comprendre et rattraper.

Ce que MCP ajoute : décrire et appeler vos outils de façon standard

MCP ne remplace pas votre API : il se place devant. Un serveur MCP expose vos capacités dans une forme standard que la couche modèle sait déjà lire : des outils (des actions), des ressources (des données consultables), des gabarits de prompt réutilisables. Chaque outil embarque sa propre description et son schéma d'entrée, et le client (Claude, ou votre runtime d'agent) les découvre à la connexion, sans rien coder en dur. Le vrai changement est là : la définition de l'outil vit avec l'outil, une fois, côté serveur, au lieu d'être copiée-collée dans chaque application. L'idée est proche d'une spec OpenAPI, mais consommée à l'exécution par le modèle, avec en plus le transport de l'appel et l'authentification. Pour la version sans technique, à faire lire à un dirigeant, j'ai écrit MCP, le standard qui branche l'IA sur vos outils.

MCP vs plugins propriétaires : le piège de la dépendance

Avant MCP, brancher un modèle sur des outils passait par le format propriétaire de chaque éditeur : les plugins de l'un, les « tools » d'un framework, les « actions » d'un autre. Chacun son manifeste, son flux d'authentification, son cycle de vie. Un connecteur écrit pour l'un ne tourne pas chez les autres : c'est de l'enfermement au niveau de l'intégration, le moins visible et le plus coûteux à défaire. MCP casse ça en étant un standard partagé : adopté par Anthropic, OpenAI, Google et Microsoft, puis confié à la Linux Foundation fin 2025. Ce qui compte ici, plus que la technique, c'est la gouvernance neutre : un connecteur écrit pour MCP continue de marcher quand vous changez de modèle ou de framework d'agent.

Écrire le branchement une fois, réutiliser partout

Le bénéfice concret pour l'architecture : vous exposez votre CRM (ou votre outil de tickets, ou une base interne) comme un seul serveur MCP. Ensuite, votre agent de support, votre copilote interne et un futur workflow consomment tous le même serveur. Un seul endroit pour l'authentification, les quotas, le journal d'audit et les descriptions d'outils. Un seul endroit à corriger en cas de bug, ou à resserrer quand une permission est de trop. Vous arrêtez de maintenir N connecteurs presque identiques éparpillés dans N applications. C'est la version technique de ce que je décris dans brancher l'IA sur vos outils existants.

Un connecteur par outil, pas un connecteur pour chaque combinaison outil / application / framework. C'est là que le coût d'intégration cesse de se multiplier.

Quand une simple API suffit, quand MCP prend tout son sens

Tout n'a pas besoin de MCP, et je le dis franchement. Un appel direct à votre API suffit largement quand l'intégration est déterministe, dans une seule application, et que le flux de contrôle est écrit par un humain : un cron qui appelle un endpoint n'a pas besoin d'un protocole pour le modèle. La règle que j'utilise par défaut : si c'est un humain qui a écrit le flux, un appel d'API classique fait le travail ; si c'est le modèle qui l'écrit à l'exécution (un agent, au sens propre), vous voulez vos outils décrits dans un standard que la couche modèle comprend.

• Un modèle ou un agent décide lui-même quel outil appeler, et dans quel ordre.
• Plusieurs applications ou agents partagent les mêmes outils.
• Vous voulez changer de modèle sans réécrire vos connecteurs.
• Vous exposez vos outils à d'autres équipes, ou à des tiers.

Ce que ça implique pour votre architecture et votre sécurité

MCP concentre la surface « ce que l'IA peut faire » dans une couche unique et adressable. C'est bon pour le contrôle, et ça concentre aussi le risque au même endroit. Traitez un serveur MCP comme n'importe quel service privilégié : il se teste, se versionne et gère les pannes partielles comme une API de production, c'est le sujet de la fiabilité en production. Concrètement, quelques règles non négociables :

• Derrière votre authentification, avec un périmètre par utilisateur, pas un jeton unique tout-puissant.
• Le minimum de droits par outil : chaque action n'accède qu'à ce dont elle a strictement besoin.
• Une validation humaine sur les actions irréversibles : paiement, suppression, envoi à un client.
• Chaque appel journalisé, pour pouvoir auditer après coup.
• Jamais un serveur exposé sur internet sans authentification : on en a déjà recensé des centaines grands ouverts.

Dernier point d'architecture : parce que le serveur peut tourner là où vivent vos données, MCP se marie bien avec un hébergement privé ou sur site quand la souveraineté compte. Rien de tout ça n'est un plugin qu'on installe en cinq minutes : c'est un choix de conception, entre vos API existantes, vos agents et vos contraintes de sécurité. Si vous pesez où MCP doit s'insérer dans votre stack, c'est précisément le genre de décision que je prends en tant qu'architecte IA.