Qu’est-ce que MCP ? Le Model Context Protocol expliqué pour 2026

MCP signifie Model Context Protocol, une norme ouverte qui aide les applications d’IA à se connecter à des outils et à des informations en dehors de la fenêtre de discussion. Imaginez un assistant consultant les fichiers d’un projet ou recherchant une commande, plutôt que de vous demander de tout copier dans un message.

Anthropic a présenté MCP en novembre 2024. Son intérêt est de réduire le travail d’intégration répété : un service peut exposer une interface commune que différentes applications compatibles comprennent. C’est de la plomberie, mais de la plomberie utile. Personne ne veut un robinet de cuisine différent pour chaque marque de tasse.

Ce guide explique les principales idées en date de mai 2026, avec la spécification de novembre 2025 comme référence technique. MCP rend les connexions plus réutilisables ; il ne rend pas toutes les applications, tous les systèmes d’autorisation et tous les outils interchangeables.

Sommaire

• Qu’est-ce que MCP, en termes simples ?
• Hôtes, clients et serveurs
• MCP, API et appels de fonctions
• Gouvernance et feuille de route 2026
• À quoi pourrait-il servir ?
• Premiers pas
• Autorisations, confidentialité et sécurité
• Questions et réponses sur MCP

Qu’est-ce que MCP, en termes simples ?

Une application d’IA doit disposer d’un moyen d’accéder à un calendrier, un dépôt de code ou une base de données. Sans interface commune, les développeurs peuvent finir par construire sans cesse des adaptateurs similaires. MCP donne à l’application et au service une manière commune de décrire les capacités disponibles et d’échanger des messages.

La comparaison familière avec un « USB-C pour l’IA » traduit cette intention. Il ne faut pas l’étendre jusqu’à garantir que tout se branche sans configuration. L’authentification, les fonctionnalités prises en charge et les restrictions propres à l’hôte comptent toujours.

MCP ne donne pas non plus au modèle une connaissance permanente de vos fichiers. Il fournit à une application des moyens d’obtenir des informations pertinentes pendant le travail. La quantité de ces informations qui parvient au modèle, et ce qui est conservé, dépendent de l’application qui l’entoure et de ses réglages.

Hôtes, clients et serveurs

La spécification décrit trois rôles :

• Hôte : l’application que vous utilisez. Elle coordonne le modèle, les connexions et les décisions d’autorisation.
• Client : le composant à l’intérieur de cet hôte qui gère une connexion à un serveur particulier.
• Serveur : le processus local ou le service distant qui expose des capacités par l’intermédiaire de MCP.

Le client et le serveur négocient ce qu’ils prennent en charge. Une connexion ne donne pas automatiquement au serveur le droit de voir toute la conversation ou tout ce qui est accessible par un autre serveur.

Outils, ressources et prompts

Les outils décrivent des opérations, comme rechercher un enregistrement ou créer un ticket. Ils sont conçus pour un usage piloté par le modèle, l’hôte contrôlant la manière dont les appels sont proposés et approuvés.

Les ressources fournissent des données contextuelles identifiées par un URI, par exemple un document ou un schéma de base de données. Leur utilisation est pilotée par l’application : un hôte peut proposer un sélecteur de fichiers, une recherche ou une sélection automatique.

Les prompts sont des modèles de messages réutilisables, conçus pour être explicitement sélectionnés par l’utilisateur, par exemple en choisissant un modèle de révision. Ce sont des modes d’interaction prévus, pas une obligation pour toutes les applications d’afficher la même interface.

Connexions locales et distantes

Les messages MCP utilisent JSON-RPC. La spécification de novembre 2025 définit deux transports standard : l’entrée/sortie standard, couramment utilisée avec un sous-processus local, et Streamable HTTP pour les connexions à des services.

Streamable HTTP peut utiliser les Server-Sent Events pour la diffusion en flux. Il remplace l’ancien transport HTTP+SSE ; « MCP sur SSE » peut donc renvoyer à différentes générations d’instructions de configuration. Vérifier les versions aux deux extrémités est plus utile que de redémarrer sans cesse l’application en espérant la visite de la fée des adaptateurs.

MCP, API et appels de fonctions

MCP se place souvent devant une API existante. Le serveur doit toujours comprendre les opérations, les identifiants d’accès et les limites de ce service. Un serveur adossé à une base de données peut au contraire l’interroger directement. Rien n’impose à chaque serveur MCP d’encapsuler une API REST.

L’appel de fonctions est le mécanisme par lequel le modèle demande une opération avec des arguments structurés. MCP fournit une interface standard permettant à une application de découvrir et d’invoquer des capacités externes. L’hôte relie ces éléments ; le modèle ne parcourt pas de façon autonome une place de marché pour y connecter des serveurs arbitraires.

Cela réduit le travail répétitif sur les adaptateurs, mais les règles métier demeurent. Un outil de remboursement doit toujours vérifier la commande, les droits de l’utilisateur et le montant autorisé. Donner à l’outil une enveloppe standard ne rédige pas la politique de remboursement du magasin.

Gouvernance et feuille de route 2026

En décembre 2025, MCP a rejoint l’Agentic AI Foundation, sous l’égide de la Linux Foundation. Cela donne au projet un cadre neutre vis-à-vis des fournisseurs. Cela ne signifie pas que toutes les entreprises participantes exposent les mêmes fonctionnalités dans chaque produit.

La feuille de route du 9 mars identifie quatre priorités : le passage à l’échelle des transports, la communication entre agents, la gouvernance et la préparation aux usages en entreprise. Les travaux sur les transports comprennent la gestion des sessions et la mise à l’échelle des services distants. Ceux sur les agents comprennent l’amélioration de la fonctionnalité expérimentale Tasks. Les sujets liés à l’entreprise incluent les pistes d’audit et l’authentification.

Ce sont des priorités de travail en cours, pas la promesse que chaque élément est déjà disponible. En particulier, la feuille de route ne signifie pas que la prise en charge de HTTP reste à inventer, ni que chaque serveur peut déjà déléguer librement à un autre.

Le Registry officiel a été lancé en préversion en septembre 2025 comme catalogue de métadonnées de serveurs. Il aide les utilisateurs et les annuaires qui s’appuient sur lui à découvrir des services ; une inscription ne certifie pas que le logiciel répertorié est sûr pour vos données particulières.

À quoi pourrait-il servir ?

Voici des exemples de flux de travail, et non la promesse que tous les hôtes les prennent en charge dès l’installation :

• Programmation : inspecter un schéma de base de données pendant la préparation d’une migration, avec une connexion en lecture seule.
• Notes personnelles : récupérer des documents sélectionnés et demander un résumé sans coller manuellement chaque fichier.
• Service client : rechercher une commande, puis rédiger une réponse. Son envoi ou l’émission d’un remboursement devraient nécessiter des autorisations distinctes.
• Recherche : parcourir une collection de documents et renvoyer des passages pertinents avec leurs sources.

Ce dernier exemple peut combiner MCP avec la génération augmentée par récupération, ou RAG (en anglais). Le RAG consiste à retrouver des informations pour étayer une réponse ; MCP peut fournir la connexion au service de recherche. Aucun des deux ne garantit que la réponse obtenue interprète correctement les éléments trouvés.

Commencer sans connecter toute sa vie numérique

Commencez par une tâche modeste et un hôte qui documente sa compatibilité avec le serveur souhaité. Suivez ses instructions : un serveur local peut nécessiter un environnement d’exécution et une configuration de lancement, tandis qu’un serveur distant peut utiliser une URL et un parcours de connexion. La disponibilité peut dépendre de l’abonnement, des réglages de l’administrateur et du transport pris en charge.

Il n’existe pas de procédure universelle consistant à « coller une chaîne de connexion dans les paramètres » qui fonctionne dans toutes les applications d’IA. Consultez à la fois les instructions de l’hôte et la documentation de l’éditeur du serveur avant toute installation.

1. Choisissez un serveur maintenu par un éditeur identifiable.
2. Examinez les autorisations demandées et la commande ou le service à connecter.
3. Utilisez un dossier de test ou un compte en lecture seule contenant des données non sensibles.
4. Essayez une petite demande et vérifiez quel outil a été exécuté et ce qu’il a renvoyé.
5. N’élargissez l’accès que lorsque la tâche l’exige réellement.

Les développeurs peuvent commencer avec un SDK officiel et un outil au périmètre restreint. Une courte démonstration peut présenter le protocole ; une utilisation fiable en production nécessite aussi de la validation, de l’authentification lorsque c’est pertinent, une gestion des erreurs et des tests. Trente lignes de code d’exemple sont une introduction, pas un service d’exploitation.

Autorisations, confidentialité et sécurité

Un serveur MCP local est un logiciel qui s’exécute sur votre ordinateur. Les recommandations de sécurité du projet abordent les risques liés aux paquets et aux commandes de démarrage malveillants, ainsi que l’intérêt de limiter les privilèges. « Local » n’est pas synonyme d’inoffensif.

Par ailleurs, l’hôte peut tout de même envoyer à un modèle dans le cloud des données lues localement. Même faire fonctionner le modèle localement (en anglais) ne fait pas disparaître un outil distant ou une API externe. La confidentialité dépend de l’ensemble du parcours de l’information.

Les outils et les documents récupérés peuvent aussi contenir des instructions trompeuses. Les traiter comme du contenu non fiable est utile, mais aucun interrupteur unique ne supprime l’injection de prompt. Limitez ce que les outils peuvent faire, donnez aux identifiants d’accès une portée appropriée et examinez les actions aux conséquences importantes.

La journalisation peut aider à comprendre les erreurs, mais enregistrer sans distinction chaque argument et chaque réponse peut créer un second réservoir d’informations privées. Consignez ce qui est nécessaire à la traçabilité, protégez l’accès, masquez les secrets et décidez de la durée de conservation des journaux.

Questions et réponses sur MCP

MCP est-il la même chose qu’une API ?

C’est un protocole d’échange de capacités et de contexte. Un serveur utilise souvent une autre API en arrière-plan, mais peut aussi travailler avec des fichiers, des bases de données ou des calculs locaux.

Faut-il écrire du code ?

Pas nécessairement. Certains hôtes proposent des interfaces d’installation. D’autres nécessitent une configuration ou un environnement d’exécution. La construction d’un serveur personnalisé relève d’une tâche de développement distincte.

Quels modèles prennent en charge MCP ?

La question généralement plus utile est de savoir quel hôte prend en charge le serveur et les fonctionnalités dont vous avez besoin. L’intégration de MCP est gérée par le logiciel applicatif qui entoure le modèle ; le seul nom d’un modèle connu ne la garantit pas.

Est-ce open source ?

Le protocole est ouvert, avec des implémentations et des outils open source. Chaque serveur peut avoir ses propres licences, conditions d’accès et tarifs.

MCP remplace-t-il le RAG ?

Non. Un système de recherche d’informations peut être proposé par l’intermédiaire d’un outil MCP. L’un consiste à trouver des informations utiles ; l’autre fournit une connexion standard.

L’intérêt pratique de MCP est qu’un assistant peut travailler avec l’information là où elle se trouve, grâce à une connexion réutilisable. Commencez petit et gardez des autorisations compréhensibles. Le chat peut réclamer un accès illimité à tous les placards, mais cela ne constitue pas une politique convaincante de contrôle d’accès.

Traduction française de l’article original en anglais du 2026-05-10. Traduction réalisée avec l’aide de l’IA le 2026-11-02 ; les références temporelles restent celles de l’original.