---

Novembre 2024 : le jour où l’on a arrêté de recâbler M×N connecteurs

Il faut se souvenir du monde d’avant. En 2023, la première vague d’intégration d’outils dans les LLM reposait sur le function calling d’OpenAI, puis sur les plugins de ChatGPT. Le principe était simple : le modèle remplissait du JSON, l’application appelait la fonction. Le problème l’était tout autant : chaque fournisseur avait sa propre convention, chaque outil sa propre plomberie, et chaque combinaison modèle × outil devait être recâblée à la main. C’est le fameux problème d’intégration « N×M » — N modèles, M outils, N×M connecteurs à maintenir.

C’est exactement ce que le Model Context Protocol a entrepris de résoudre. Introduit par Anthropic en novembre 2024 — le 25 novembre selon la fiche Wikipedia du protocole —, MCP est un standard ouvert et open-source porté par les ingénieurs David Soria Parra et Justin Spahr-Summers. La promesse tient en quatre mots : build once, integrate everywhere. On écrit un serveur MCP une fois, et n’importe quel client compatible — Claude, ChatGPT, VS Code, Cursor, MCPJam — peut s’y brancher sans réécrire une ligne de glue. La documentation officielle résume l’ambition : standardiser l’accès des LLM aux fichiers, aux fonctions et aux sources de données, en visant explicitement les silos d’information et les systèmes legacy qui pourrissent la vie des DSI.

Ce dossier ne parle pas de découverte. Il ne vous expliquera pas « ce qu’est MCP » pour la centième fois. Il part d’un constat désagréable : entre le tutoriel qui fait clignoter un serveur local en cinq minutes et le service MCP qui tient la charge en production, il y a un fossé que beaucoup d’équipes sous-estiment — et dans lequel elles tombent.

De projet Anthropic à colonne vertébrale : OpenAI, DeepMind, Linux Foundation et la valse des révisions

L’adoption a été rapide, presque brutale. OpenAI a annoncé son ralliement autour de mars 2025 (les sources tierces citent des articles VentureBeat du 27 mars 2025 et TechCrunch du 25 mars 2025), suivi par Google DeepMind. Microsoft a intégré le protocole dans Visual Studio Code, Cursor en a fait un pilier de son expérience développeur. En décembre 2025, Anthropic a franchi le pas symbolique décisif : faire don de MCP à l’Agentic AI Foundation, un fonds hébergé sous la Linux Foundation, cofondé par Block et OpenAI, avec le soutien affiché de Google, Microsoft, AWS et Cloudflare. Le geste compte : un protocole qui prétend devenir une infrastructure ne peut pas rester la propriété d’un seul éditeur.

Reste la question qui fâche : la gouvernance a beau être ouverte, la spec bouge vite. Les révisions se sont enchaînées — 2024-11-05 pour la première mouture, 2025-03-26, 2025-06-18, 2025-11-25, puis 2026-07-28, la plus récente à ce jour. Chacune a introduit sa dose de changements : transport streamable HTTP, OAuth 2.1, élicitation, sampling, roots, et plus récemment les tasks ainsi que la dépréciation progressive du SSE résiduel. La révision du 28 juillet 2026 est d’ailleurs présentée par plusieurs analyses comme un tournant « stateless », avec une refonte de l’autorisation et une migration à mener sans régression.

Un avertissement de rigueur, ici : le détail normatif exact de chaque révision — quel champ a été ajouté quand, quel comportement est passé de SHOULD à MUST — doit se vérifier dans les sources primaires de la spec, pas dans les articles de vulgarisation. Les extraits disponibles confirment la chronologie et les grands thèmes, pas chaque alinéa. Traitez donc ce qui suit comme une carte de terrain, pas comme un texte de loi.

Ce que la spec impose vraiment : transports, cycle de vie, autorisation, primitives

Décortiquons ce qui structure réellement une implémentation MCP.

Les transports. Deux modes coexistent. Le premier, stdio, fait tourner le serveur comme un processus fils du client, communiquant par entrée/sortie standard : simple, local, sans réseau, idéal pour un outil de fichiers ou un accès à une base locale sur le poste du développeur. Le second, streamable HTTP, expose le serveur comme un service distant, accessible par plusieurs clients, potentiellement multi-tenant. Le SSE (Server-Sent Events) historique, longtemps utilisé pour le transport distant, est en voie de dépréciation — la spec du 28 juillet 2026 acte ce mouvement. Si vous démarrez un nouveau serveur distant aujourd’hui, partir sur SSE est un pari perdant.

Le cycle de vie. Une session MCP commence par un initialize : le client et le serveur échangent leurs versions de protocole et négocient leurs capacités respectives. Ce qui suit dépend de cette négociation — le serveur annonce qu’il sait faire de l’élicitation, le client annonce qu’il sait faire du sampling, et les deux s’accordent sur un terrain commun. Les notifications (changement de liste d’outils, mise à jour de ressources) circulent ensuite dans ce cadre. C’est un détail que les POC oublient systématiquement : si votre client ne gère pas une capacité, votre serveur ne doit pas la présumer.

L’autorisation. C’est le gros morceau de la période récente. La spec s’appuie sur OAuth 2.1, avec plusieurs RFC compagnes : les Resource Indicators (RFC 8707) pour que le jeton soit lié à la ressource visée et pas utilisable ailleurs, la Protected Resource Metadata (RFC 9728) pour que le client découvre automatiquement comment s’authentifier, et le Dynamic Client Registration pour l’enregistrement des clients sans intervention manuelle. En pratique, c’est cette pile qui fait la différence entre un serveur MCP utilisable en entreprise et un jouet.

Les primitives. Au-dessus, quatre briques structurent les interactions : l’élicitation (le serveur demande une information complémentaire à l’utilisateur, typiquement une confirmation avant une action sensible), le sampling (le serveur sollicite le LLM du client pour générer du contenu), les roots (le périmètre de fichiers ou de ressources que le client autorise le serveur à toucher), et les tasks (des opérations longues, asynchrones, avec suivi d’état). Ces primitives sont précisément les zones où la spec laisse le plus de latitude aux implémentations — et donc où les SDK Python, TypeScript, Java, Rust et Go divergent en pratique. Un serveur écrit avec un SDK donné peut se comporter différemment chez un client écrit avec un autre, sans que personne n’ait violé la spec.

stdio ou streamable HTTP ? L’arbre de décision du praticien

Le choix du transport n’est pas une question de goût, c’est une question de modèle de déploiement. Voici comment trancher.

Critère	stdio	streamable HTTP
Modèle d’usage	Poste de développeur, mono-utilisateur	Service partagé, multi-tenant
Isolation	Processus local, surface réseau nulle	Exposé sur le réseau, surface d’attaque réelle
Latence	Minimale (pas de saut réseau)	Dépend du réseau et de l’hébergement
Auth	Souvent implicite (contexte OS)	OAuth 2.1 obligatoire en pratique
Debug	Simple : on lit stdout	Complexe : sessions, reconnexions, corrélation
Coût d’exploitation	Quasi nul	Hébergement, scaling, quotas, supervision
Cas typique	Outil de fichiers, base locale	SaaS distant, passerelle d’entreprise

La règle de pouce : si l’outil vit sur la machine de l’utilisateur et n’a de sens que pour lui, stdio. Si l’outil est un service partagé, une API SaaS ou une ressource d’entreprise, streamable HTTP. Le troisième cas — la passerelle d’entreprise qui agrège plusieurs serveurs derrière un point d’entrée unique — est le plus délicat, parce qu’il cumule les problèmes d’auth, de multi-tenant et de routage.

Les pièges classiques, tous observés sur le terrain : le SSE résiduel qu’on garde « pour l’instant » et qui bloque la migration suivante ; les timeouts mal calibrés qui tuent les appels longs alors que les tasks existent précisément pour ça ; les reconnexions qui perdent l’état de session ; et les sessions collantes mal gérées quand on met plusieurs instances derrière un load balancer. Ce dernier point mérite une insistance : une session MCP n’est pas un cookie, et la faire reposer sur l’affinité réseau est une dette technique qui se paie au premier redéploiement.

OAuth, multi-tenant et secrets : là où 90 % des POC MCP meurent

Voici la vérité inconfortable : la majorité des serveurs MCP qui ne passent jamais en production ne meurent pas d’un problème de protocole. Ils meurent d’un problème d’authentification.

Le scénario typique : un POC qui marche parce que le développeur a collé un jeton d’API en dur dans la configuration. On le branche sur un vrai utilisateur, puis sur deux, puis sur un client externe — et là, tout casse. Parce qu’il faut propager un contexte utilisateur à travers la chaîne, isoler les tenants, gérer la rotation des secrets, et surtout définir des scopes par outil. Un serveur qui expose « lire un ticket » et « fermer un ticket » ne doit pas accorder les deux avec le même jeton.

Les garde-fous à poser avant la première mise en prod :

• Dynamic Client Registration activé, pour ne pas maintenir à la main une liste de clients.
• Resource Indicators (RFC 8707) : le jeton est lié à la ressource ciblée, ce qui limite les dégâts en cas de fuite.
• Protected Resource Metadata (RFC 9728) : le client découvre la config d’auth automatiquement, ce qui évite les configurations divergentes.
• Isolation des tenants au niveau du stockage et des credentials, pas seulement au niveau applicatif.
• Rotation des secrets planifiée, avec un chemin de rechargement à chaud.
• Scopes granulaires par outil, jamais un scope fourre-tout.

Le piège vicieux, c’est la propagation du contexte utilisateur. Un serveur MCP appelé par un agent au nom d’un utilisateur doit savoir au nom de qui il agit, et le vérifier à chaque appel — pas seulement à l’ouverture de session. Les incidents de sécurité de l’été 2026, notamment les tests de l’agence britannique AISI en août 2026 où des agents ont exécuté 19 actions non autorisées, rappellent que la délégation d’autorité à un agent est un sujet sérieux, pas une formalité.

Versionner les outils sans casser les agents : compatibilité, dépréciation, tests de contrat

Un serveur MCP expose des outils avec des schémas d’entrée et de sortie. Renommer un champ, changer un type, retirer un paramètre : chacune de ces opérations peut faire tomber silencieusement un agent en production. Et « silencieusement » est le mot clé — l’agent ne plante pas, il appelle l’outil avec un JSON qui ne correspond plus, récupère une erreur ou, pire, un résultat vide, et continue sa route en produisant une réponse fausse.

Les stratégies qui tiennent :

Versionner les outils, pas seulement le serveur. Un serveur MCP peut exposer search_v1 et search_v2 en parallèle pendant une période de transition. Les agents anciens continuent de fonctionner, les nouveaux prennent la dernière version.

Déprécier progressivement, avec des notifications. Le cycle de vie MCP prévoit des notifications de changement de liste d’outils. Utilisez-les : un client averti peut adapter son comportement, un client non averti découvre le problème en production.

Tester les contrats. Un test de contrat vérifie que le schéma exposé par le serveur correspond à ce que le client attend. C’est la seule protection réelle contre le renommage de champ qui casse tout. Ces tests doivent tourner à chaque déploiement du serveur, pas seulement à l’écriture initiale.

Gérer les capacités négociées. Si votre serveur dépend de l’élicitation mais que le client ne la supporte pas, vous devez avoir un chemin de repli. La négociation de capacités à l’initialize est là pour ça — encore faut-il l’exploiter.

40 serveurs branchés, un contexte qui explose : contenir le gonflement

C’est peut-être le problème le plus sous-estimé du passage à l’échelle. Chaque serveur branché ajoute ses définitions d’outils dans le contexte du modèle. Chaque outil, avec son nom, sa description et son schéma JSON, consomme des tokens. Multipliez par quarante serveurs et vous avez une fenêtre de contexte qui se remplit avant même que l’utilisateur ait posé sa question.

Les chiffres précis par serveur varient trop selon la taille des descriptions pour être généralisables, et les mesures publiées sur Claude Desktop, Cursor, Cline ou Continue ne figurent pas dans les sources disponibles. Mais l’ordre de grandeur du problème est documenté ailleurs : un agent avec accès à quinze serveurs MCP ne sollicite en réalité qu’une demi-douzaine de serveurs par tâche. Autrement dit, la majorité du contexte chargé est du bruit.

Les parades :

• Sélection dynamique des outils : n’injecter dans le contexte que les outils pertinents pour la tâche en cours, en s’appuyant sur un routage en amont.
• Résumés de capacités : exposer au modèle une description courte du serveur, et ne charger le schéma complet qu’au moment de l’appel.
• Pagination : ne pas lister tous les outils d’un serveur d’un coup si la liste est longue.
• Mise en cache : les définitions d’outils changent rarement, leur traitement ne devrait pas être refait à chaque tour.

Le coût de ce gonflement est réel et mesurable en dollars. Les données du magazine sont sans ambiguïté : un agent non optimisé coûte environ 200 dollars par mois, contre 29 à 50 dollars pour un agent correctement architecturé. Le facteur est de l’ordre de quatre à sept. Ce n’est pas une optimisation cosmétique, c’est une ligne budgétaire.

Observer, tracer, déboguer une chaîne d’appels distribuée

Quand un agent appelle un outil qui échoue, et que trois serveurs et un LLM sont dans la boucle, le diagnostic devient un exercice d’archéologie. La question n’est jamais « est-ce que l’appel a échoué » — c’est « où, pourquoi, et avec quelles données ».

Ce qu’il faut instrumenter :

La corrélation. Un identifiant de trace qui traverse le client, chaque serveur MCP et chaque appel d’outil. Sans lui, vous avez des logs orphelins.

Les logs structurés. Pas « appel d’outil, 200 » — ce message n’explique rien. Il faut l’outil appelé, les paramètres (caviardés), la durée, le résultat ou l’erreur, et le lien vers la trace parente.

Les métriques. Latence par appel, taux d’échec par outil, coût par session. Un ordre de grandeur utile : un aller-retour de tool calling se compte en centaines de millisecondes — de l’ordre de 800 ms selon les mesures disponibles — ce qui signifie que dix appels d’outils ajoutent huit secondes à une réponse. À multiplier par le nombre d’utilisateurs.

Le replay d’incident. Pouvoir rejouer une session complète, avec les mêmes entrées, est la seule façon de reproduire un bug intermittent impliquant un LLM non déterministe.

Le contexte général n’aide pas : les agents en production affichent un taux d’échec global de 88 % selon les données du magazine, et un agent de support client non surveillé dépasse les 30 % de tâches ratées après trois semaines d’exploitation. La surveillance n’est pas optionnelle — c’est ce qui distingue un agent qui s’améliore d’un agent qui pourrit.

Checklist de mise en production : ce qu’il faut avoir coché avant d’ouvrir aux utilisateurs

Synthèse actionnable, à parcourir avant le grand saut.

Sécurité

• [ ] Aucun secret en dur, ni dans la config, ni dans le code.
• [ ] OAuth 2.1 en place avec Resource Indicators (RFC 8707).
• [ ] Protected Resource Metadata (RFC 9728) exposée et testée.
• [ ] Dynamic Client Registration activé.
• [ ] Scopes granulaires par outil, jamais de scope fourre-tout.
• [ ] Roots configurés pour limiter le périmètre d’accès aux fichiers.

Isolation et multi-tenant

• [ ] Contexte utilisateur propagé et vérifié à chaque appel, pas seulement à l’ouverture.
• [ ] Isolation des tenants au niveau du stockage.
• [ ] Rotation des secrets planifiée et testée à chaud.

Versionnement

• [ ] Outils versionnés, anciennes versions maintenues pendant la transition.
• [ ] Notifications de changement de liste d’outils implémentées.
• [ ] Tests de contrat exécutés à chaque déploiement.
• [ ] Chemin de repli pour les capacités non supportées par le client.

Observabilité

• [ ] Identifiant de trace de bout en bout.
• [ ] Logs structurés avec caviardage des données sensibles.
• [ ] Métriques de latence, taux d’échec et coût par session.
• [ ] Capacité de replay d’incident.

Exploitation

• [ ] Quotas par utilisateur et par serveur.
• [ ] Plan de rollback documenté et testé.
• [ ] Tests de charge sur le scénario multi-serveurs.
• [ ] Gouvernance des serveurs tiers : qui valide, qui audite, qui retire.

Et après ? L’horizon immédiat s’appelle les tasks — des opérations longues et asynchrones qui permettront aux agents de lancer un traitement de plusieurs minutes sans bloquer la session. Les webhooks événementiels, poussés par OpenAI à l’automne 2026, complètent ce tableau en donnant aux agents une troisième jambe de communication : réagir au monde, pas seulement l’interroger. Un registre officiel de serveurs se structure également, ce qui posera la question de la certification et de la confiance.

Mais soyons clairs sur ce que MCP ne résoudra pas à votre place. Le protocole standardise la plomberie ; il ne vous dira pas quels outils exposer, à qui, avec quels droits, ni comment surveiller ce qui se passe. Il ne vous protégera pas d’un agent qui décide mal. Il ne remplacera ni votre modèle de menaces, ni votre stratégie de versionnement, ni votre discipline d’observabilité. MCP vous donne un cadre commun — le reste, c’est de l’ingénierie.

---

Sources

• Introduction — Model Context Protocol (révision 2026-07-28)
• Model Context Protocol — Wikipedia (EN)
• Model Context Protocol — Wikipédia (FR)
• Model Context Protocol (MCP) — GeeksforGeeks
• What is MCP? — The AI Rankings
• MCP 2026-07-28 : la nouvelle spec décryptée — ottho.co
• MCP Events Complete the Agent Communication Model — forkast.news
• Safari 27 Ships a Native MCP Server — forkast.news
• Traçage des appels d’outils d’agent IA — apidog.com
• 2026 MCP vs Function Calling — zavcloud.com
• OpenAI Agents API 2026 : JSON Schema, Tool Calling — jsonsort.com