La question posée en comité d'architecture n'est pas de savoir si MCP est mûr. Elle est de savoir quelle révision parle chacun des deux bouts de votre chaîne, parce que la réponse détermine ce que vous pouvez brancher aujourd'hui.
Ce que MCP fait, en une phrase
MCP est un protocole ouvert qui décrit comment un modèle découvre les outils disponibles, les appelle et lit des ressources. Il joue pour l'accès aux outils le rôle qu'un connecteur standard joue pour une base de données : écrire une fois un serveur MCP devant votre ERP évite d'écrire une intégration par assistant.
Le protocole a été versé le 9 décembre 2025 à l'Agentic AI Foundation, aux côtés d'autres projets, avec une gouvernance ouverte réunissant les principaux acteurs du secteur. Il n'est donc plus le format d'un seul éditeur.
La révision du 28 juillet 2026 change la nature du protocole
La révision en vigueur porte la date du 28 juillet 2026 et rend le protocole sans état. Ce n'est pas un ajustement de surface.
- La poignée de main initiale disparaît, ainsi que les sessions de niveau protocole et l'en-tête qui les portait.
- Le point d'entrée HTTP en lecture longue disparaît, avec la reprise de flux et l'identifiant de dernier événement.
- Chaque requête porte désormais sa version de protocole et les capacités du client ; le serveur s'identifie dans chaque résultat.
- Un flux rompu perd la requête en cours : le client doit la réémettre avec un nouvel identifiant.
- Tout serveur doit implémenter un point de découverte, et chaque résultat porte un type explicite.
- Les listes deviennent cacheables, avec une durée de validité et une portée, et les serveurs devraient renvoyer leurs outils dans un ordre déterministe.
Pour une direction technique, le point le plus directement exploitable est ailleurs. Les requêtes en HTTP portent maintenant des en-têtes qui indiquent la méthode et le nom appelés. Une passerelle ou un répartiteur de charge peut donc router et appliquer une politique sans lire le corps du message. C'est ce qui rend le protocole administrable dans une architecture d'entreprise.
La révision s'accompagne d'un calendrier de dette technique daté. Plusieurs fonctions historiques, dont l'échantillonnage côté serveur, la journalisation et l'enregistrement dynamique de client, sont dépréciées depuis le 28 juillet 2026 et deviennent éligibles au retrait à partir du 28 juillet 2027. La fenêtre minimale annoncée est de douze mois, et rien n'a encore été retiré.
Personne ne parle encore la même révision
C'est le fait qui doit gouverner votre calendrier, et il se vérifie en quelques minutes.
Le jour même de la publication de la révision, son auteur historique indiquait que la prise en charge arrivait prochainement dans ses produits, sans date ni priorité. Au 3 août 2026, la documentation destinée aux développeurs d'un autre grand fournisseur référence encore la révision de novembre 2025 et décrit l'ancien transport.
La matrice de compatibilité des extensions, maintenue par la communauté, donne la mesure de l'écart. L'extension d'autorisation administrée par l'entreprise compte un seul client. Le mode d'autorisation entre services n'en compte aucun. Une extension officielle de gestion de tâches n'a même pas de colonne dans cette matrice.
Un second écart mérite d'être connu. L'ensemble des serveurs de référence s'est rétracté : sept sont encore maintenus, quatorze ont été archivés depuis mai 2025 dans un dépôt qui les désigne comme n'étant plus maintenus. Les connecteurs vers les principales forges, messageries et bases de données que beaucoup d'articles citent encore comme officiels n'en font plus partie. Vérifiez l'état du serveur avant de le mettre dans une architecture cible.
Ce que la spécification ne sécurise pas
C'est le point que la plupart des présentations passent sous silence, et il faut l'énoncer sans caricature dans un sens ni dans l'autre.
La spécification écrit que l'autorisation est optionnelle pour les implémentations MCP. En transport local, elle demande même de ne pas suivre le cadre d'autorisation. Aucune primitive de gestion de rôles n'existe dans le protocole. Et le texte va jusqu'à indiquer que MCP ne peut pas faire respecter ses principes de sécurité au niveau du protocole lui-même.
Autre point, souvent mal compris : les descriptions de comportement des outils, annotations comprises, doivent être considérées comme non fiables tant qu'elles ne proviennent pas d'un serveur de confiance. C'est la porte d'entrée de l'injection de consignes par un serveur tiers.
La formulation juste tient en une phrase : MCP standardise le branchement, pas la sécurité.
Quand l'autorisation est implémentée, elle devient en revanche exigeante. Le protocole s'appuie sur OAuth 2.1, qui est encore à l'état de brouillon à l'IETF. Le serveur doit publier ses métadonnées de ressource protégée, le client doit transmettre un paramètre identifiant la ressource visée, et le serveur doit vérifier que le jeton lui était bien destiné. La spécification écrit qu'un serveur MCP ne doit accepter aucun jeton qui ne lui a pas été explicitement délivré.
Le passage au sans-état a créé une classe d'attaque nouvelle, traitée dans les recommandations de sécurité : le détournement de jeton d'état. La règle posée est nette, la possession d'un tel jeton ne vaut pas authentification, et il doit être lié à l'identité vérifiée de l'utilisateur.
Ce que la recherche mesure sur l'écosystème
Une étude relue par les pairs, acceptée à la conférence DSN 2026, a analysé plus de 67 000 serveurs recensés sur six registres publics. Elle identifie 833 serveurs vulnérables et 18 descriptions trompeuses, soit environ 1,2 % de l'échantillon.
Ce chiffre mérite d'être lu dans les deux sens. Il contredit le récit d'un écosystème massivement dangereux. Il reste élevé en valeur absolue quand on installe un serveur trouvé dans un registre public sans le lire.
Un préprint de mai 2026, qu'il faut nommer comme tel, relève par ailleurs que sur près de huit mille serveurs MCP distants actifs, environ 40 % exposent des outils sans authentification. C'est la statistique qui justifie la règle interne la plus simple : aucun serveur MCP distant tiers dans le périmètre de production sans revue.
Une précision d'honnêteté sur les volumes. Aucun total fiable de serveurs MCP n'est publiable : le registre officiel n'expose pas de compteur global, et les chiffres qui circulent couvrent des périmètres différents et non comparables. Les déclarations d'éditeurs, qu'il s'agisse de dizaines de milliers de serveurs publiés ou de centaines de connecteurs dans un annuaire produit, sont des ordres de grandeur commerciaux, pas des mesures.
Côté Claude Code, ce qui marche aujourd'hui
Pour les équipes qui travaillent avec Claude Code, l'ajout d'un serveur se fait en ligne de commande. Un serveur distant s'ajoute en précisant le transport HTTP et son adresse ; un serveur local s'ajoute en donnant la commande à exécuter.
Deux points de vigilance. Le transport par événements envoyés par le serveur est déprécié, la documentation recommandant d'utiliser HTTP quand c'est possible. Et le transport par WebSocket ne prend en charge ni l'authentification par OAuth ni l'option de transport, ce qui le réserve à des usages internes contrôlés.
Écrire un serveur MCP ou exposer une API : comment trancher
| Situation | Ce qui convient | Pourquoi |
|---|---|---|
| Un seul assistant, un seul outil, usage interne | Appel d'outil classique | MCP ajoute une couche sans bénéfice de réutilisation |
| Plusieurs assistants doivent accéder au même système | Serveur MCP | Écrit une fois, réutilisé par chaque client compatible |
| Système exposé à des tiers ou à des partenaires | Serveur MCP avec autorisation complète | Le protocole impose alors la validation d'audience et la portée des jetons |
| Besoin d'un contrôle d'accès par rôle | Couche applicative en amont | Aucune primitive de rôle n'existe dans la spécification |
Un levier de cloisonnement mérite d'être connu, parce qu'il est propre et peu utilisé. La liste des outils renvoyée par un serveur ne doit pas dépendre de la connexion, mais elle peut dépendre de l'autorisation présentée sur la requête, les identifiants étant une entrée par requête et non un état de connexion. Un même serveur peut donc exposer une surface réduite à un compte de service et une surface complète à un développeur identifié.
Sur le coût et le délai d'une intégration, je ne donnerai pas de fourchette : rien de sourçable n'existe, et les durées annoncées par les éditeurs concernent leurs propres connecteurs sur leurs propres produits.
Cadrer un premier branchement
- 1Établir la matrice de compatibilité : révision parlée par le client, révision parlée par le serveur, extensions réellement implémentées de part et d'autre.
- 2Décider du périmètre de droits avant d'écrire la première ligne : un serveur MCP hérite exactement des permissions que vous lui accordez, et rien dans le protocole ne les restreindra à votre place.
- 3Choisir le mode d'autorisation avec l'équipe qui gère les identités, sans le traiter comme une option de fin de projet.
- 4Traiter tout serveur tiers comme du code non fiable : lecture du code, épinglage de version, exécution cloisonnée.
- 5Prévoir la dette : les fonctions dépréciées le 28 juillet 2026 deviennent retirables à partir du 28 juillet 2027.
MCP règle un vrai problème, celui de la multiplication des intégrations propriétaires. Il ne règle ni la gouvernance des accès, ni la confiance envers un serveur tiers, et sa spécification le dit elle-même. C'est un protocole de branchement, et le branchement n'a jamais été la partie difficile d'un système d'information.
- 01Ce que MCP fait, en une phrase
- 02La révision du 28 juillet 2026 change la nature du protocole
- 03Personne ne parle encore la même révision
- 04Ce que la spécification ne sécurise pas
- 05Ce que la recherche mesure sur l'écosystème
- 06Côté Claude Code, ce qui marche aujourd'hui
- 07Écrire un serveur MCP ou exposer une API : comment trancher
- 08Cadrer un premier branchement
Questions fréquentes
