MCP n'est-il qu'une façon plus sexy d'appeler une API ?
Si vous avez l'instinct technique, l'idée vous a probablement traversé l'esprit, et c'est la question la plus pointue de tout ce domaine. En dessous, un connecteur MCP ne fait très souvent rien de plus qu'envelopper une API qui existait déjà. Même endpoint, même appel, les mêmes données qui reviennent. Alors où est la révolution, exactement.
Réponse honnête, celle qui respecte votre intelligence : au niveau du fil, vous n'avez pas tort. MCP n'est pas une nouvelle loi de la physique. C'est fréquemment une API avec un ruban autour.
Sauf que le ruban est tout l'enjeu, et le balayer comme cosmétique passe à côté de la seule chose qui a réellement changé. Ce qui a changé, ce n'est pas la plomberie. C'est pour qui elle est faite, et à quel moment elle sert.
Trente ans d'intégration, conçus pour un humain
Pendant l'essentiel des trois dernières décennies, le problème central du logiciel d'entreprise n'était pas l'intelligence. C'était l'intégration. Faire parler un système à un autre. Et l'artisan discret de tout le monde logiciel moderne, c'était l'API : un contrat publié qui dit voici exactement comment vous pouvez demander à mon système de faire quelque chose, et voici exactement ce que vous recevrez en retour.
Mais une API a été conçue avec un client très précis en tête. Un programmeur humain. Une personne qui lit la documentation, la comprend, et écrit à l'avance du code précis qui appelle exactement la bonne fonction exactement de la bonne manière. L'intégration se décide au moment du build, par une personne, puis se fige dans le logiciel. Cette hypothèse a parfaitement tenu pendant trente ans.
Le tournant agentique : l'appelant est désormais un modèle
Puis les agents ont brisé l'hypothèse. Parce que la chose qui saisit l'outil n'est plus un programmeur qui a lu le manuel mardi dernier. C'est un modèle, qui décide sur l'instant, à l'exécution, quel outil utiliser et comment.
Un modèle ne peut pas s'asseoir avec cent manuels d'API différents, chacun écrit dans son propre style maison, et improviser à la volée un code impeccable contre eux. L'ancien contrat était écrit pour le mauvais lecteur. C'est l'écart que MCP a été construit pour combler, et c'est pourquoi la différence est réelle même quand l'endpoint en dessous est identique.
Des outils auto-descriptifs que le modèle lit sur-le-champ
Voici la différence concrète. Une API se décrit à une personne, une fois, dans une documentation qu'on lit avant d'écrire du code. Un outil MCP se décrit à un modèle, à chaque fois, sous une forme que le modèle peut lire et raisonner sur l'instant. Il annonce : voici ce que je sais faire, voici les entrées dont j'ai besoin, voici la situation dans laquelle vous voudriez m'utiliser.
L'intégration a donc cessé d'être ce qu'un programmeur câble à l'avance pour devenir ce qu'un agent peut découvrir et utiliser de lui-même, à l'exécution, sans que personne n'ait écrit du code pour cette combinaison exacte auparavant. C'est le même appel sous-jacent, représenté pour un consommateur d'une tout autre nature : un consommateur probabiliste, qui décide lui-même de ce qu'il va saisir. Qualifier cela de cosmétique, c'est dire qu'une carte de restaurant n'est qu'une version plus sexy de l'inventaire de la cuisine. Techniquement les mêmes articles. Un lecteur complètement différent. Et le lecteur a toujours été l'enjeu.
Ce que cela signifie pour vous
Deux conséquences pratiques en découlent, et toutes deux sont faciles à manquer.
D'abord, vos API existantes ne sont pas prêtes pour les agents du seul fait qu'elles existent. Un endpoint conçu pour un intégrateur humain soigneux peut être une arme chargée entre les mains d'un modèle qui l'appellera avec assurance sur la foi d'une description lue dans une entrée peut-être empoisonnée. Exposer une API à un agent est une décision de sécurité, pas un exercice d'emballage.
Ensuite, envelopper n'est pas gouverner. Rendre un outil accessible à un modèle est la moitié facile. Décider ce que l'agent a le droit d'en faire, appel par appel, sous quelle autorité, c'est la moitié qui compte, et elle relève d'un point de décision de politique avec des capacités étroites et typées, pas d'une autorisation large du type « l'agent peut accéder au système ».
La question à apporter à votre prochaine revue d'intégration n'est donc pas « pouvons-nous exposer cette API à notre agent ? ». Vous le pouvez presque toujours. C'est : cet agent devrait-il pouvoir appeler cette action, avec ces arguments, dans cette situation, et qui décide à chaque appel ? MCP vous donne une porte propre. Qu'elle ouvre sur une frontière que vous contrôlez, ou sur un trousseau de clés remis à un système probabiliste, ne dépend que de vous.
Si vous voulez rendre vos systèmes existants réellement prêts pour les agents, en sécurité, prenez rendez-vous.