Qu’est‑ce que le Model Context Protocol (MCP) ? La norme qui connecte l’IA aux outils et aux données

Le Model Context Protocol (MCP) est une norme ouverte qui permet aux applications d’IA de se connecter à des outils externes, des données, des invites et d’autres capacités via une interface cohérente. Au lieu de créer une intégration personnalisée pour chaque combinaison modèle‑système, les développeurs peuvent mettre en œuvre un protocole partagé entre un hôte IA et un serveur MCP.

Le MCP est souvent décrit comme un connecteur universel pour l’IA, mais l’analogie est incomplète. Le protocole ne se contente pas de déplacer des données. Il définit comment les participants établissent des capacités, exposent des ressources et des actions, échangent des messages structurés et maintiennent les limites de sécurité. Cela en fait une composante importante de l’infrastructure émergente pour les assistants et agents IA.

Pourquoi le MCP existe

Un modèle, à lui seul, ne peut pas voir les documents privés d’une entreprise, inspecter un dépôt local, interroger une base de données en temps réel ou appeler un service interne. Historiquement, les développeurs ont relié ces capacités via des plugins ponctuels et des API spécifiques aux applications.

Cette approche crée un problème d’intégration. Si dix applications d’IA doivent chacune se connecter à dix systèmes, les équipes peuvent finir par maintenir des dizaines d’adaptateurs sur mesure. Chaque adaptateur peut représenter les outils, le contexte, l’authentification, les erreurs et les mises à jour de manière différente.

MCP crée un contrat commun. Une application compatible MCP peut communiquer avec des serveurs MCP qui exposent des capacités dans un format connu. La spécification du Model Context Protocol définit le protocole, tandis que les hôtes et serveurs individuels décident des fonctionnalités et des politiques de sécurité qu’ils prennent en charge.

L’architecture du MCP

Le MCP sépare la conversation et la logique du modèle de l’application IA de la logique d’intégration requise par chaque source de données ou service. L’hôte peut maintenir plusieurs connexions client simultanément — une pour un serveur de système de fichiers, une pour un serveur de base de données et une autre pour une application métier — tout en présentant leurs capacités au modèle via une interface cohérente.

Le serveur n’est pas nécessairement un service Internet distant. Il peut s’exécuter localement à côté d’une application de bureau, au sein d’un réseau d’entreprise, ou en tant que service distant. Ce choix de déploiement modifie le transport et la frontière de confiance, mais pas la relation centrale : un client découvre les capacités d’un serveur et échange des messages structurés avec celui‑ci.

Le MCP utilise une architecture hôte‑client‑serveur.

• Host: l’application IA avec laquelle l’utilisateur interagit, comme un assistant, un environnement de codage ou une plateforme d’agents.
• Client: un composant du protocole créé par l’hôte pour maintenir une connexion avec un serveur MCP particulier.
• Server: un programme qui expose des outils, ressources ou invites sélectionnés aux clients MCP.

Un hôte peut se connecter à plusieurs serveurs simultanément. Un serveur peut fournir l’accès à un dépôt de fichiers, un autre à un système de gestion de projet, et un troisième à une base de données interne. L’hôte reste responsable de l’expérience utilisateur, de l’orchestration du modèle, du consentement et des informations placées dans le contexte du modèle.

Les messages sont structurés selon les conventions JSON‑RPC. Lors de l’initialisation, les participants négocient les versions du protocole et les capacités. Cette négociation est importante car les clients et les serveurs n’ont pas besoin d’implémenter chaque fonctionnalité optionnelle.

Outils, ressources et invites

MCP organise les capacités fournies par le serveur en plusieurs primitives. Les trois les plus familières sont les outils, les ressources et les invites.

Outils

Un outil est une fonction exécutable que l’application d’IA peut invoquer. Parmi les exemples : rechercher dans une base de données client, créer un ticket, exécuter une requête ou récupérer l’inventaire actuel. Une définition d’outil comprend un nom, une description et un schéma d’entrée afin que le modèle et le runtime sachent quels arguments sont attendus.

L’utilisation d’un outil peut modifier des systèmes externes, de sorte que les hôtes doivent afficher des descriptions significatives, valider les entrées, appliquer les autorisations et exiger une confirmation pour les actions ayant des conséquences.

Ressources

Une ressource est un contexte qu’une application peut lire, tel qu’un fichier, un enregistrement de base de données, une page de documentation ou un rapport généré. Les ressources utilisent des identifiants et peuvent exposer des métadonnées comme un nom et un type de média. Elles offrent aux hôtes un moyen standardisé de découvrir et de récupérer des informations sans faire croire que chaque opération de lecture est une action.

Invites

Les invites sont des modèles ou des flux de travail réutilisables qu’un serveur met à disposition de l’hôte. Elles peuvent aider les utilisateurs à invoquer correctement une capacité, fournir des arguments structurés ou combiner des instructions spécifiques au domaine avec le contexte pertinent.

MCP prend également en charge les capacités dans le sens inverse. Selon ce qui est négocié, un serveur peut demander à l’hôte d’obtenir des complétions de modèle ou des saisies utilisateur. Le principe de conception important est la négociation explicite des capacités plutôt que de supposer que chaque participant peut exécuter chaque opération.

Que se passe-t-il lors d’un appel d’outil MCP ?

Considérez un assistant de codage IA connecté à un serveur d’analyse de référentiel.

1. L’hôte se connecte au serveur MCP et négocie les capacités prises en charge.
2. Le client demande la liste des outils disponibles.
3. Le serveur renvoie des définitions d’outils structurées, y compris leurs schémas d’entrée.
4. L’hôte met les descriptions d’outils sélectionnées à disposition du modèle.
5. Le modèle propose un appel d’outil, par exemple la recherche de références à une fonction.
6. L’hôte vérifie la politique et, si nécessaire, demande l’approbation de l’utilisateur.
7. Le client envoie la requête validée au serveur.
8. Le serveur exécute l’opération et renvoie du contenu structuré ou une erreur.
9. L’hôte décide quelle partie du résultat fournir au modèle pour l’étape suivante.

MCP standardise l’échange, mais ne décide pas si le modèle doit être autorisé à appeler un outil. Cette décision revient à l’hôte et à son niveau de politique.

MCP ne remplace pas les API

Un serveur MCP encapsule souvent des API existantes, des kits de développement logiciel, des outils en ligne de commande ou des pilotes de bases de données. Ces interfaces sous-jacentes effectuent toujours le travail réel. MCP ajoute une couche de découverte et d’interaction orientée IA au-dessus d’elles.

Cette distinction explique pourquoi MCP est complémentaire aux API REST, GraphQL et autres interfaces d’application. Un service de paiement peut conserver son API mature tandis qu’un serveur MCP expose un sous-ensemble soigneusement limité d’opérations avec des descriptions et des schémas adaptés aux modèles.

MCP vs. Appel de fonction

L’appel de fonction ou d’outil est une capacité du modèle : le modèle peut renvoyer une requête structurée pour invoquer une fonction. MCP est un protocole de découverte et de communication avec les fournisseurs d’outils et de contexte.

Les deux fonctionnent souvent ensemble. Un serveur MCP indique à l’hôte quels outils existent. L’hôte présente les définitions sélectionnées à un modèle. Le modèle émet un appel d’outil. L’hôte utilise alors MCP pour envoyer cette requête au serveur approprié.

MCP vs. Agent2Agent

MCP connecte une application d’IA à des capacités et à du contexte. Agent2Agent, ou A2A, se concentre sur la communication entre agents autonomes qui peuvent appartenir à différents systèmes ou organisations.

Un système pratique peut utiliser les deux. Un agent peut recourir à MCP pour accéder à ses outils et données, puis utiliser A2A pour déléguer une tâche plus importante à un autre agent. MCP répond à la question « Comment cette application peut‑elle utiliser cette capacité ? », tandis que A2A répond à « Comment ces agents peuvent‑ils coordonner le travail ? ».

Risques de sécurité et contrôles

Un hôte sécurisé maintient une liste blanche explicite de serveurs et d’outils, affiche un consentement significatif lorsqu’un accès est accordé, et associe chaque appel à l’utilisateur ou à l’identité de la charge de travail qui l’a autorisé. Les schémas d’outils doivent être suffisamment restreints pour rejeter les arguments inattendus, tandis que les journaux d’audit doivent enregistrer le serveur, la capacité, les entrées, le statut du résultat et le chemin d’approbation.

Les ressources retournées et les résultats d’outils constituent également une surface d’injection d’invite. Un document lu via MCP peut contenir du texte demandant au modèle d’ignorer ses instructions ou d’exfiltrer des données. L’hôte doit préserver la distinction entre le contenu non fiable et la politique du système, et il doit empêcher la sortie d’un serveur d’étendre silencieusement les permissions d’un autre serveur.

La normalisation améliore l’interopérabilité, mais elle ne rend pas un serveur fiable. Un serveur MCP peut exposer des données sensibles, des descriptions d’outils trompeuses, des actions dangereuses ou des dépendances compromises. Le contenu non fiable récupéré via une ressource peut également contenir des instructions d’injection d’invite destinées à manipuler le modèle.

Les contrôles importants comprennent :

• Principe du moindre privilège : ne fournir à chaque serveur que les identifiants et la portée nécessaires à son objectif.
• Confiance du serveur : vérifier la source, le code, la propriété et le chemin de mise à jour des serveurs avant de les connecter.
• Visibilité utilisateur : rendre clair quel serveur recevra les données et quelle action il exécutera.
• Validation des entrées : appliquer les schémas et les règles métier en dehors du modèle.
• Limites d’approbation : confirmer les actions sensibles, externes, financières ou destructrices.
• Minimisation des données : éviter d’envoyer des documents ou des conversations entiers lorsqu’une petite partie suffit.
• Journalisation et révocation : enregistrer les appels, surveiller les anomalies, et rendre les identifiants et les connexions faciles à désactiver.

Le projet MCP continue d’affiner son architecture et ses directives de sécurité. La mise à jour de la spécification 2026 du projet illustre comment la norme évolue vers une infrastructure plus simple, une autorisation et un déploiement en production.

Quand les développeurs devraient‑ils utiliser MCP ?

MCP est particulièrement adapté lorsque plusieurs clients d’IA ont besoin d’une connexion cohérente à la même capacité, lorsque les outils doivent être découverts à l’exécution, ou lorsqu’une équipe souhaite séparer l’orchestration d’IA du code d’intégration propre au système.

Un appel de fonction direct peut rester plus simple pour une petite application avec un seul backend étroitement contrôlé. L’adoption du protocole implique son propre travail opérationnel : gestion du cycle de vie des serveurs, tests de compatibilité, authentification, observabilité et gouvernance.

Ce qu’il faut retenir à propos du Model Context Protocol (MCP)

MCP est un langage commun entre les applications d’IA et les outils ainsi que le contexte qui les entoure. Sa valeur réside dans le remplacement des conventions d’intégration isolées par un protocole découvrable, structuré et extensible.

La norme n’élimine pas la nécessité d’une ingénierie rigoureuse. Les hôtes doivent encore décider quels serveurs sont fiables, quelles capacités exposer, quelles données partager, et quand une personne doit approuver une action. MCP rend les connexions portables ; la gouvernance les rend sûres et utiles.