Protocole MCP et API : quelles sont les différences ?

Le protocole MCP (Model Context Protocol) et les API (interfaces de programmation d'application) sont deux méthodes qui permettent de connecter des systèmes distincts. Le protocole MCP n'existerait pas sans les API, sur lesquelles reposent ses fonctionnalités. 

La différence entre ces technologies réside dans leur fonctionnement et leurs objectifs :

• Le protocole MCP connecte les modèles de langage à des outils et données externes. Il alimente des workflows qui s'adaptent et improvisent en temps réel. 
• Les workflows traditionnels d'API suivent un ensemble de règles immuables. Une fois deux systèmes connectés, les interactions sont limitées à des actions spécifiques qu'un développeur programme.

Choix entre le protocole MCP et une API

Pour une application qui n'utilise pas de grand modèle de langage (LLM), le choix le plus simple et rapide sera l'API. Celle-ci conviendra également pour connecter un LLM à un service que l'utilisateur contrôle, grâce à l'appel natif de fonctions du LLM (une fonction intégrée qui met en forme le résultat que fournit le modèle pour obtenir une commande exécutable). 

Le protocole MCP est à privilégier lorsque le même outil doit fonctionner dans plusieurs applications d'IA, lorsque l'utilisateur a recours à des outils qu'il n'a pas créés ou lorsque le modèle doit découvrir de nouvelles fonctionnalités au moment de l'exécution. 

Découvrir Red Hat AI

Le protocole Open Source MCP standardise la connexion entre les applications d'IA et les outils et données externes. Il fonctionne comme un câble USB-C qui relie des appareils à différents accessoires et qui permet la transmission de données.

Avant l'invention du protocole MCP, les équipes de développement devaient créer des intégrations personnalisées d'API pour chaque cas d'utilisation spécifique. Autrement dit, elles réécrivaient les mêmes intégrations plusieurs fois de manière légèrement différente. Chaque connexion entre une application d'IA et un service externe était faite sur mesure, ce qui prenait beaucoup de temps.

En savoir plus sur le protocole MCP 

Une API permet à un produit ou à un service de communiquer avec d'autres produits et services sans connaître les détails de leur mise en œuvre. On pourrait comparer les API à des contrats, la documentation représentant l'accord entre les parties : si la partie 1 envoie une requête à distance structurée d'une certaine manière, le logiciel de la partie 2 devra répondre selon les conditions définies.

En savoir plus sur les API

Pour bien comprendre, prenons l'exemple concret de la réservation d'un rendez-vous médical sur un site web. 

Dans ce scénario, un utilisateur souhaite prendre rendez-vous jeudi avec le docteur Martin, à 14h. Celui-ci reçoit déjà un patient à 14h, mais il a un créneau libre à 14h30. Sinon, le docteur Thomas est disponible à 14h. 

Dans le cadre d'un workflow traditionnel d'API, le développeur du logiciel écrit un script qui le connecte directement à l'API du cabinet médical. Lorsque l'utilisateur tente de prendre rendez-vous à 14h avec le docteur Martin, l'application effectue un appel d'API pour déterminer si ce créneau est disponible chez ce médecin. 

La base de données du cabinet comprend qu'un rendez-vous est déjà réservé à 14h. Elle renvoie une erreur et affiche un message du type : « Le créneau sélectionné n'est pas disponible ».

La suite dépend de l'utilisateur. Comme le logiciel ne peut pas s'adapter, l'utilisateur doit recommencer le processus et essayer de demander un nouveau rendez-vous à une autre heure ou avec un autre médecin. 

Dans le cadre d'un workflow basé sur le protocole MCP,une application d'IA se connecte au serveur MCP du cabinet et vérifie la disponibilité du docteur Martin à 14h. Parce qu'elle repose sur un LLM, elle est en mesure d'évaluer les autres options et d'interagir avec l'utilisateur. 

Elle peut afficher le message suivant : « Le créneau de 14h avec le docteur Martin n'est pas disponible. Vous pouvez prendre rendez-vous avec le docteur Martin à 14h30. Si vous souhaitez voir un médecin à 14h, vous pouvez prendre rendez-vous avec le docteur Thomas qui est disponible à cette heure. Que préférez-vous faire ? »

L'utilisateur vérifie son agenda et répond : « rendez-vous à 14h avec le docteur Thomas ». L'application lance ensuite une nouvelle demande de prise de rendez-vous pour 14h avec le docteur Thomas, que l'utilisateur devra confirmer. 

Le protocole MCP offre aux modèles d'IA un moyen dynamique de déterminer quel outil utiliser, quand l'utiliser et comment comprendre le résultat. Il est particulièrement utile dans les situations suivantes :

• L'application repose sur des LLM ou des workflows agentiques. Un LLM n'est pas capable d'appeler des API ni d'exécuter du code lui-même. Pour résoudre ce problème, l'application qui exécute le modèle appelle des outils. Le protocole MCP standardise la description et la distribution de ces outils afin d'assurer la compatibilité de chacun avec différentes applications d'IA. 
• Le workflow comprend des tâches complexes en plusieurs étapes. Lorsqu'un programme doit interroger une base de données, résumer les résultats et mettre à jour une application tierce, le protocole MCP lie ces étapes à l'aide d'un agent IA.
• Le workflow peut inclure une part d'improvisation. Une application qui fonctionne avec le protocole MCP peut évaluer les différentes options, gérer des obstacles inattendus et adapter sa stratégie. 
• Les outils doivent être portables. Un seul serveur MCP peut communiquer avec toute application d'IA conforme au protocole MCP. Après l'avoir assemblé, il est donc possible de le réutiliser avec d'autres clients compatibles.
• Il est prévu d'ajouter des fonctionnalités en temps réel. Le protocole MCP permet d'ajouter des fonctionnalités pendant l'exécution de l'application, ce qui évite d'avoir à programmer toutes les fonctions possibles à l'avance. 

Les API restent la solution de référence pour assurer la rapidité et la prévisibilité de la connexion entre des programmes informatiques. Elles sont particulièrement utiles dans les situations suivantes :

• La tâche est simple et vise un seul objectif. La récupération d'un numéro dans une base de données est un exemple de tâche simple qui ne nécessite pas le protocole MCP.
• Aucun LLM n'est impliqué. Si le logiciel repose sur un système classique d'apprentissage automatique ou sur du code back-end standard qui n'utilise pas l'IA, les API traditionnelles suffisent amplement pour traiter les données brutes. 
• La rapidité et l'efficacité sont prioritaires. Les API traditionnelles peuvent répondre en quelques millisecondes. Si les appels d'outils MCP et les processus sont aussi très rapides, le workflow global inclut toutefois des opérations d'inférence des modèles qui font passer le temps de réponse à plusieurs secondes. 
• Chaque décision que prend le système doit être contrôlée. Les API traditionnelles suivent toujours exactement les instructions. 

S'il est techniquement possible de connecter un LLM directement à une API traditionnelle avec du code personnalisé, cette approche n'est pas vraiment avantageuse. Les équipes de développement sont obligées d'écrire du code personnalisé pour chaque application d'IA à prendre en charge. De plus, la logique fixe des API (« si A se produit, exécuter B ») n'offre pas la flexibilité dont l'IA agentique moderne a besoin pour raisonner et accomplir des tâches en temps réel.

Le protocole MCP a été créé pour prendre en charge la découverte dynamique, une fonction puissante des agents IA qui leur permet de se connecter à un serveur, de vérifier les fonctionnalités disponibles, puis de les utiliser immédiatement, sans intervention humaine. 

La découverte dynamique repose sur des fonctionnalités de serveur et un schéma lisible par une machine. Autrement dit, ce n'est plus un développeur qui va lire un manuel en ligne, mais un schéma structuré (écrit dans le langage JSON standard) qui va permettre à un LLM de déterminer lui-même les noms des outils, les exigences de paramètres et les types de données. Le protocole MCP classe ensuite ces fonctionnalités de serveur dans trois catégories : 

• Les outils qui permettent à l'agent d'effectuer une action
• Les ressources qui fournissent du contexte à l'agent
• Les instructions génératives qui servent de modèles d'instruction

Plus l'utilisation du protocole MCP se généralise, plus le nombre d'intégrations préconçues augmente. Il s'agit de serveurs MCP prêts à l'emploi pour les plateformes couramment utilisées, comme GitHub, Slack et Google Drive. Grâce aux schémas lisibles par une machine, à la découverte en temps réel et aux outils préconçus, les agents disposent de suffisamment d'informations pour créer de véritables workflows d'IA sensibles au contexte. Dans le cadre de ce processus, les agents vont évaluer en continu un environnement en temps réel, extraire du contexte des ressources MCP, sélectionner le bon outil pour un moment précis et adapter le raisonnement en fonction des commentaires envoyés dans le monde réel. 

Découvrir les serveurs MCP pour Red Hat OpenShift® AI

L'authentification de base ne suffit pas pour sécuriser les serveurs MCP. Il faut mettre en place des règles précises pour chaque action, des clés numériques aux limites strictes et un système capable de traiter tous les langages de sécurité qu'utilisent ces outils.

Découvrir l'authentification et l'autorisation pour la passerelle MCP

Remplacer les API par le protocole MCP

Le protocole MCP n'offre pas une solution universelle qui remplacerait totalement les API. Son objectif est d'aider les modèles d'IA à communiquer avec les outils. On peut s'en passer si l'application n'utilise pas de modèle de langage. 

Maintenant que les entreprises ont adopté le protocole MCP, la question est de savoir comment le mettre en œuvre en toute sécurité. Les serveurs MCP peuvent permettre aux agents IA d'accéder à un grand nombre d'outils et de données. Sans couche de gouvernance, il n'existe toutefois aucun moyen cohérent de contrôler les niveaux d'accès individuels, d'imposer des limites de débit ou d'appliquer une politique de sécurité. 

En savoir plus sur la passerelle MCP pour Red Hat OpenShift

Définition d'une passerelle MCP

Une passerelle MCP se situe entre les agents IA et les serveurs MCP auxquels ils se connectent. En plus de contrôler le trafic au niveau de l'infrastructure, elle achemine chaque appel d'outil entre les agents IA et les serveurs MCP via un seul point de contrôle géré. 

Les passerelles MCP servent à protéger les connexions des serveurs MCP à grande échelle. Elles interviennent dans les domaines suivants :

• Sécurité : les entreprises peuvent appliquer le contrôle d'accès basé sur les rôles pour mettre en place des garde-fous et, par exemple, permettre à un agent marketing d'accéder au serveur MCP des réseaux sociaux, mais pas au serveur des paiements.
• Observabilité : les passerelles créent un journal d'audit centralisé qui enregistre des informations telles que l'utilisateur ayant lancé l'agent, l'outil MCP utilisé et la réponse renvoyée. 
• Coût : les passerelles appliquent des limites de débit aux jetons textuels consommés par agent. Elles aident également les équipes à déterminer le coût d'utilisation de chaque outil. 
• Fiabilité : en cas de panne d'un service, les passerelles peuvent basculer automatiquement une demande d'outil vers un nouveau point de terminaison. 

La gamme Red Hat® AI offre des fonctionnalités d'inférence rapides, flexibles et efficaces au moyen d'un serveur basé sur vLLM. Elle relie de manière fiable les modèles aux données pour unifier la personnalisation et le développement d'agents spécialisés sur une seule et même plateforme. Conçus sur une base Open Source, nos produits donnent un contrôle total sur les workflows d'IA, de bout en bout et à toutes les échelles. 

La gamme Red Hat AI inclut Red Hat AI Enterprise, une plateforme qui permet de déployer, gérer et mettre à l'échelle des opérations d'inférence d'IA, des workflows d'IA agentique et des applications basées sur l'IA dans tous types d'infrastructures.

Découvrir Red Hat AI