MCP (Model Context Protocol) est un protocole ouvert qui standardise la façon dont un assistant IA se connecte à des outils et à des données externes : fichiers, bases, services en ligne. Il ne remplace pas les API, il les enveloppe dans un format commun. Et il ne dispense pas de vérifier ce que l’on branche, car chaque serveur MCP peut agir à la place de l’assistant.
La référence reste la spécification officielle, publiée sur modelcontextprotocol.io. La révision en vigueur à la date de cette mise à jour, datée du 28 juillet 2026 (2026-07-28), est la plus profonde depuis le lancement du protocole. Lancé par Anthropic, MCP est confié depuis décembre 2025 à l’Agentic AI Foundation, une structure de la Linux Foundation cofondée avec OpenAI et Block ; ChatGPT, Gemini, Cursor et Microsoft Copilot l’ont adopté.
Le problème que MCP résout
Avant MCP, brancher un assistant IA sur un outil demandait une intégration sur mesure. Chaque couple « application d’IA + service » avait son propre code de liaison : un connecteur pour votre messagerie, un autre pour votre dépôt de code, un troisième pour votre base de données. Multipliez les assistants par les services et le nombre d’intégrations explose.
MCP reprend l’idée du Language Server Protocol, qui a standardisé la prise en charge des langages de programmation dans les éditeurs de code. Un service expose ses capacités une fois, dans un format commun. Tout assistant compatible peut ensuite s’y connecter, sans développement spécifique.
L’effort d’intégration se fait donc côté serveur, une seule fois, et profite à tous les clients.
Comment fonctionne MCP : hôte, client, serveur
La spécification distingue trois rôles, qui échangent des messages au format JSON-RPC 2.0 (un format standard d’appel de fonctions à distance) :
- L’hôte : l’application d’IA qui initie les connexions (un assistant de chat, un éditeur de code avec IA).
- Le client : le connecteur, intégré à l’hôte, qui dialogue avec un serveur donné.
- Le serveur : le service qui fournit du contexte et des capacités, en local sur votre poste ou à distance.
Ce qu’un serveur MCP expose
Un serveur peut proposer trois familles de fonctions :
- Resources : du contexte et des données, que l’utilisateur ou le modèle peut consulter (un fichier, une fiche, un enregistrement).
- Prompts : des modèles de messages et d’enchaînements, prêts à l’emploi pour l’utilisateur.
- Tools : des fonctions que le modèle peut décider d’exécuter, comme créer un ticket, lancer une requête ou envoyer un message.
Dans l’autre sens, la spécification prévoit l’Elicitation : le serveur peut demander une information complémentaire à l’utilisateur en cours de route.
Ce qui a changé avec la révision 2026-07-28
La génération précédente du protocole reposait sur une session : le client ouvrait la connexion par une étape d’initialisation, puis conservait un identifiant de session. La révision 2026-07-28 supprime ce mécanisme. Chaque requête est autonome et porte elle-même la version du protocole et les capacités du client. Selon le changelog officiel, le protocole devient stateless : les serveurs qui doivent garder un état entre deux appels le font au moyen de références passées comme arguments ordinaires des outils.
Une méthode de découverte, server/discover, permet au client de demander à la volée ce que propose un serveur. Les listes d’outils, de ressources et de prompts ne varient plus d’une connexion à l’autre, ce qui facilite leur mise en cache. Les notes de version de certains SDK (kits de développement) mentionnent aussi la dépréciation de trois fonctions, Roots, Sampling et Logging : à confirmer sur le blog officiel avant de s’appuyer dessus.
Des extensions facultatives complètent le socle, à activer des deux côtés : Tasks (opérations longues exécutées de façon asynchrone), MCP Apps (éléments d’interface interactifs affichés dans la conversation) et Skills over MCP (instructions structurées pour des workflows d’agents).
Attention : certains changements ne sont pas rétrocompatibles. Les SDK officiels prévoient une négociation vers les versions antérieures, mais une implémentation maison devra être revue.
MCP ou API : quelle différence ?
Une API (interface de programmation) décrit comment un logiciel parle à un autre. MCP ne la remplace pas : un serveur MCP s’appuie le plus souvent sur une API existante et la présente d’une manière que n’importe quel assistant sait lire.
La différence tient à ce que l’on standardise. Une API est propre à un service : endpoints, authentification, formats de réponse varient de l’un à l’autre, et un développeur écrit du code pour chacune. MCP, lui, normalise la conversation entre l’assistant et l’outil : comment découvrir les fonctions disponibles, comment les décrire au modèle, comment les appeler, comment demander l’accord de l’utilisateur.
Pour choisir, quelques repères :
- Vous écrivez une application classique qui appelle un service précis, de façon prévisible : l’API directe reste le choix le plus simple.
- Vous voulez qu’un assistant décide lui-même quel outil utiliser, parmi plusieurs, selon la demande : MCP apporte le cadre commun.
- Vous voulez réutiliser le même branchement dans plusieurs applications d’IA : un serveur MCP évite de tout réécrire.
Ce que l’on branche en pratique
Les serveurs MCP couvrent aujourd’hui des besoins très concrets. Leur point commun : l’assistant ne se contente plus de répondre, il consulte et agit.
- Le code et les dépôts : lire un projet, consulter des tickets, préparer une modification depuis un éditeur compatible.
- Les fichiers et documents : donner à l’assistant l’accès à un dossier précis plutôt qu’à tout le disque.
- Les bases de données : interroger des données en langage naturel, idéalement en lecture seule.
- Les outils de travail : agenda, messagerie, gestion de projet, documentation interne.
- Le navigateur et les tests : piloter une page web pour la vérifier ou en extraire des informations.
Le catalogue change d’un mois à l’autre. Pour un outil précis, partez du site de l’éditeur du service et de la documentation de votre assistant, qui indiquent quels serveurs sont pris en charge.
Sécurité : ce qu’il faut vérifier avant d’installer un serveur MCP
La spécification est explicite : MCP ouvre des chemins d’accès aux données et d’exécution de code arbitraire. Elle pose trois principes, que l’hôte doit appliquer et que vous devez surveiller :
- Le consentement explicite : l’utilisateur doit autoriser et comprendre les accès aux données et les opérations. Aucun outil ne doit s’exécuter sans son accord.
- La confidentialité : un hôte ne doit pas exposer vos données à un serveur, ni les transmettre ailleurs, sans votre consentement.
- La méfiance envers les outils : les descriptions et annotations d’un outil sont à considérer comme non fiables, sauf si le serveur est de confiance.
Le protocole ne peut pas imposer ces règles lui-même : c’est à chaque application, et à vous, de les tenir. Concrètement, avant d’installer un serveur :
- Vérifiez l’éditeur et la provenance : dépôt officiel du service, ou auteur identifiable et code lisible.
- Lisez la liste des outils exposés et demandez-vous ce que chacun peut modifier ou supprimer.
- Donnez le minimum de droits : un jeton en lecture seule, un dossier limité, un compte de test.
- Gardez la confirmation manuelle pour les actions sensibles (envoi, suppression, paiement).
- Méfiez-vous des contenus que l’outil ramène : une page web ou un document peut contenir des instructions cachées destinées à détourner l’assistant, ce que l’on appelle l’injection de prompt.
Un serveur MCP installé localement s’exécute avec vos droits. Traitez-le comme n’importe quel logiciel tiers : vous n’installeriez pas un exécutable inconnu sans vérification.
Par où commencer
Le plus sûr consiste à commencer petit. Choisissez un assistant compatible MCP, puis un seul serveur, sur un cas sans risque : lecture d’un dossier de documentation, ou d’une base de test. Observez les appels d’outils que l’assistant propose, refusez ce que vous ne comprenez pas, et n’élargissez les droits que lorsque l’usage est stable.
Pour aller plus loin, la spécification et les guides d’implémentation sont sur modelcontextprotocol.io, et le blog officiel annonce chaque nouvelle révision. Sans session à maintenir et avec la découverte à la demande, un serveur distant se déploie désormais comme un service web ordinaire. Le rythme auquel les éditeurs migreront leurs serveurs vers cette base dira si la promesse tient.
Sources
Questions fréquentes
C’est quoi le MCP ?
MCP (Model Context Protocol) est un protocole ouvert qui standardise la connexion entre un assistant IA et des outils ou des données externes. Un service expose ses capacités via un serveur MCP, et tout assistant compatible peut les utiliser.
Quelle est la différence entre un MCP et une API ?
Une API est propre à un service et décrit comment un logiciel l’appelle. MCP normalise la façon dont un assistant IA découvre, comprend et appelle des outils, et s’appuie souvent sur des API existantes.
Que signifie MCP dans l’IA ?
MCP signifie Model Context Protocol, soit « protocole de contexte pour les modèles ». Il définit comment un modèle reçoit du contexte et accède à des outils.
Un serveur MCP est-il sûr ?
Pas par défaut. La spécification demande un consentement explicite avant tout appel d’outil et recommande de traiter les descriptions d’outils comme non fiables, sauf serveur de confiance. Vérifiez la provenance et limitez les droits accordés.
Quelle est la version actuelle de la spécification MCP ?
La révision en vigueur est la 2026-07-28. Elle supprime les sessions au profit de requêtes autonomes et ajoute une méthode de découverte, server/discover.
Ils m’ont fait confiance
« Il ne se contente pas de corriger les symptômes, il cherche à comprendre l'origine des problèmes et à sécuriser les modifications effectuées. J'ai réellement le sentiment d'avoir trouvé un développeur qui comprend à la fois la technique et les enjeux globaux du projet. »
Évaluation client · projet WordPress · septembre 2026
5,0/5 sur 17 évaluations
Faire appel à mes services →
