Le Model Context Protocol (MCP) est en train de s’imposer comme le standard d’intégration des LLM en entreprise. Mais en quoi est-il vraiment différent d’une API classique ? Et surtout, faut-il choisir entre les deux ?
Vous n’y comprenez rien ? Alors cet article est fait pour vous !
Le contexte : pourquoi la question se pose maintenant
Depuis l’émergence des agents IA en entreprise ( copilotes métier, assistants documentaires, automatisation de processus ) les équipes d’architecture IT font face à une question récurrente : comment connecter ces agents aux systèmes existants du SI ?
La réponse évidente était jusqu’ici « via des API ». Sauf que les agents IA ont des besoins très différents d’une application classique. Et c’est précisément pour répondre à ces besoins que le MCP a été créé.
Les API : le modèle dominant, et ses limites face à l'IA
Une API fonctionne sur un principe simple : une application envoie une requête à un serveur, le serveur répond, et c’est terminé. Chaque échange est indépendant, sans mémoire du précédent. C’est ce qu’on appelle un modèle stateless.
Ce modèle a fait ses preuves depuis vingt ans. Il est stable, documenté, outillé, et parfaitement adapté aux intégrations classiques entre systèmes, applications web, mobiles, échanges B2B, microservices.
Mais face à un agent IA, trois limites structurelles apparaissent :
- Pas de mémoire entre les appels. Un agent IA conduit souvent un raisonnement en plusieurs étapes. Avec une API, il doit reconstruire le contexte à chaque requête, ce qui est coûteux et fragile.
- Pas de découverte autonome. Un LLM ne peut pas explorer ce que fait une API sans qu’on lui en injecte la documentation. Il ne peut pas « interroger » l’API pour savoir ce qu’elle sait faire.
- Pas de sémantique des intentions. Une API expose des ressources et des opérations CRUD. Elle ne parle pas en termes d’actions ou d’objectifs, le langage naturel d’un agent.
En résumé : les API sont conçues pour des applications qui savent exactement ce qu'elles veulent. Les agents IA, eux, raisonnent, explorent, et composent des actions à la volée. Ce sont deux paradigmes différents.
MCP : une couche de médiation pensée pour les agents
Le Model Context Protocol, lancé par Anthropic fin 2024 et rapidement adopté comme standard de facto par l’ensemble de l’industrie (OpenAI, Google, les principaux éditeurs d’IDE et d’outils IA), est un protocole ouvert qui standardise la façon dont un LLM communique avec les systèmes externes.
L’analogie la plus claire pour un DSI : MCP est aux agents IA ce que l’interface USB est aux périphériques. Avant l’USB, chaque périphérique avait son propre connecteur propriétaire. L’USB a tout standardisé, la connexion, la découverte, le protocole. MCP fait la même chose pour les intégrations LLM.
Ce qu'un serveur MCP expose
- Actions que le LLM peut déclencher
- Ex : interroger un CRM, envoyer un email, lancer un calcul
- Le modèle décide seul quand les utiliser
- Données injectées dans le contexte du modèle
- Ex : fichiers, bases documentaires, tableaux de bord
- Accessibles en lecture, identifiées par URI
- Instructions réutilisables et paramétrables
- Encodent des workflows métier standardisés
- Versionnables et gouvernables centralement
- Le serveur peut lui-même interroger le LLM
- Permet des boucles de raisonnement avancées
- Architecture bidirectionnelle, cas avancés
Comment fonctionne une session MCP ?
La différence clé avec une API : la session MCP est persistante. Le serveur connaît l’état de la conversation. Le LLM peut enchaîner plusieurs appels successifs en gardant le fil, exactement comme un collaborateur humain travaillerait en plusieurs étapes sur un même dossier.
Le LLM découvre dynamiquement ce que le serveur sait faire
La session reste ouverte et stateful, le contexte est maintenu tout au long du raisonnement de l'agent.
Comment fonctionne une session MCP ?
MCP n’est pas un remplacement de vos API . C’est un positionnement architectural complémentaire. Dans la quasi-totalité des cas concrets, un serveur MCP consomme lui-même des API en arrière-plan, il joue le rôle de façade agentique devant votre SI existant.
Les applications web, mobiles et intégrations B2B continuent d'appeler vos API directement, rien ne change pour elles.
La migration est donc progressive et non destructrice : vous exposez via MCP les systèmes pertinents pour vos cas d’usage IA, sans toucher à votre couche API existante.
Les points de vigilance pour les DSI
Sécurité et gouvernance
Un serveur MCP donne à un LLM la capacité d’agir sur vos systèmes. Les enjeux de gouvernance sont donc plus proches de ceux d’un accès humain que d’une intégration applicative classique. Il faut penser en termes de principe de moindre privilège (chaque outil n’a accès qu’à ce dont il a besoin), de traçabilité des actions déclenchées par l’agent, et d’authentification déléguée (l’agent hérite des droits de l’utilisateur qui le sollicite).
Scalabilité
Contrairement aux API , les sessions MCP sont persistantes et elles maintiennent un état. À forte charge, cela implique une gestion plus rigoureuse des ressources serveur (sessions actives, timeouts, affinité de session au niveau du load balancer). La bonne nouvelle : l’écosystème de solutions MCP Gateway commence à maturité, avec des outils de rate limiting et d’observabilité dédiés.
Observabilité
Les outils classiques d’APM (Datadog, Dynatrace, etc.) ne capturent pas nativement le raisonnement qui a conduit un LLM à déclencher un appel. Il faut prévoir une couche de traçabilité spécifique pour répondre aux questions du type « pourquoi l’agent a-t-il fait cette action ? » Une exigence qui devient vite critique pour la conformité et le debug.
Guide de décision rapide
FAQ : 4 questions pour voir ce que vous avez retenu
MCP remplace-t-il mes API existantes ?
Non. MCP est complémentaire à vos API REST, pas un substitut. Dans la quasi-totalité des cas, un serveur MCP consomme lui-même vos API existantes en arrière-plan. Vos applications web, mobiles et intégrations B2B continuent d'appeler vos API directement rien ne change pour elles. MCP ajoute simplement une façade agentique pour vos agents IA.
Faut-il être développeur pour mettre en place un serveur MCP ?
Oui, un minimum de compétences techniques est nécessaire pour déployer un serveur MCP sur mesure. Cela dit, l'écosystème mûrit rapidement : des serveurs MCP prêts à l'emploi existent déjà pour les outils les plus courants (Slack, GitHub, bases documentaires…). Pour un premier cas d'usage, une équipe technique interne ou un intégrateur peuvent mettre en place un serveur fonctionnel en quelques jours.
Quels sont les risques de sécurité liés à MCP ?
Un serveur MCP donne à un LLM la capacité d'agir sur vos systèmes, les enjeux sont donc plus proches d'un accès humain que d'une intégration applicative classique. Trois points de vigilance : appliquer le principe de moindre privilège, assurer la traçabilité complète des actions déclenchées par l'agent, et homologuer tout serveur MCP tiers comme vous le feriez pour n'importe quelle librairie tierce.
Par où commencer concrètement pour adopter MCP ?
Commencez petit : identifiez 2 ou 3 systèmes internes à fort usage dans vos cas d'usage IA actuels, base de connaissance, CRM, outil de ticketing. Exposez-les via un serveur MCP interne, construisez votre doctrine de gouvernance sur ces premiers retours, puis étendez progressivement. L'objectif n'est pas de tout migrer d'un coup, mais de bâtir une posture agentique solide avant de passer à l'échelle.
Ce qu'il faut retenir !
MCP et API REST répondent à des besoins fondamentalement différents. L’un est taillé pour les échanges entre systèmes déterministes. L’autre est conçu pour donner à des agents qui raisonnent la capacité d’agir sur votre SI de façon autonome et contextuelle.
Pour les DSI, l’enjeu n’est pas de choisir l’un ou l’autre, c’est de définir une politique claire sur quels systèmes internes exposer via MCP, avec quels droits, et selon quelles procédures d’homologation. Ces décisions architecturales prises aujourd’hui conditionneront la sécurité et l’agilité de vos environnements agentiques demain.
