L'authentification dans le protocole MCP en 2026 : hier, aujourd'hui et demain

Le Model Context Protocol (MCP), présenté par Anthropic en novembre 2024, avait été conçu comme une interface locale pour des commandes simples. Mais le passage aux serveurs distants a fait de l'authentification une partie obligatoire du protocole, et non un ajout facultatif.

Ce qu'était MCP à ses débuts

MCP est conçu pour donner au modèle une interface afin de dialoguer avec un système, un programme ou un serveur. Cette technologie est arrivée avec l'essor des agents et des grands modèles de langage et, pour l'industrie, elle était totalement nouvelle il y a seulement deux ans environ. Les premières versions de MCP ne fonctionnaient qu'en local : l'utilisateur pouvait demander au modèle de « lancer la calculatrice », de « consulter l'agenda » ou de « supprimer les photos superflues de la galerie », et l'agent exécutait la commande sur le même appareil, sans avoir à se connecter nulle part.

• Le Model Context Protocol a été créé par Anthropic en novembre 2024
• Les premiers usages de MCP étaient locaux : lancer la calculatrice, consulter l'agenda, supprimer des fichiers de la galerie
• Les premières versions du protocole n'exigeaient pas d'authentification, car le modèle et le serveur MCP tournaient sur le même appareil

Ce qui a changé avec les serveurs distants

MCP a assez vite dépassé le stade d'outil local pour devenir un protocole destiné aux serveurs distants : l'utilisateur colle dans Claude l'adresse de son serveur MCP, et le modèle détermine seul ce que ce serveur sait faire, où se connecter et comment communiquer avec lui.

Dès lors que le serveur ne fait plus partie du même appareil, une question se pose : qui l'appelle exactement, et doit-il seulement répondre à cette requête ? Un modèle qui reçoit l'adresse d'un serveur tiers ne peut plus partir du principe que celui-ci se trouve physiquement chez l'utilisateur. Il ne doit faire confiance qu'aux serveurs qui ont prouvé leur identité. C'est précisément le rôle de l'authentification.

«

Dès que MCP est devenu distant, l'authentification a cessé d'être optionnelle », peut-on lire dans un article de Habr consacré à l'histoire et à l'avenir de l'authentification dans MCP.

Pourquoi c'est important pour les développeurs

Tant que MCP restait un outil local, le développeur n'avait pas à se demander qui se connectait au serveur : serveur et modèle partageaient le même appareil et le même périmètre de confiance. Avec le passage aux serveurs distants, cette séparation a disparu, et l'authentification est devenue un élément de base de l'architecture, à prévoir dès le début du travail sur un serveur plutôt qu'à ajouter après coup.

C'est pourquoi l'auteur de l'article de Habr construit son récit autour de trois étapes : « comment c'était », « comment c'est » et « comment ce sera ». MCP est passé d'un outil local sans aucun mécanisme de vérification des connexions à un protocole où la question de l'accès distant et de la confiance envers le serveur se pose pour chaque nouvel intégrateur.

Ce que cela signifie

Pour les équipes qui connectent des serveurs MCP à Claude et à d'autres agents, la question « qui vérifie la connexion, et comment » ne peut plus être repoussée. Elle fait partie de l'architecture de base de tout serveur distant dès le premier jour.

Questions fréquentes

Quand le protocole MCP est-il apparu ?

Anthropic a créé le Model Context Protocol en novembre 2024, comme une interface par laquelle le modèle peut communiquer avec des systèmes, des programmes et des serveurs externes.

Comment MCP fonctionnait-il avant le passage aux serveurs distants ?

MCP était à l'origine local et réglait des tâches modestes : les requêtes types, comme « lance la calculatrice », « consulte l'agenda » ou « supprime les photos superflues de la galerie », s'exécutaient sur un seul appareil, sans besoin d'authentification.

À quoi sert le protocole MCP ?

À donner au modèle une interface unique pour communiquer avec des systèmes, des programmes et des serveurs externes, au lieu d'écrire à chaque fois une intégration distincte pour chaque outil.