MCP en production : resoudre les defis de transport, auth et scaling

Du prototype a la production : ce qui change

Construire un serveur MCP qui fonctionne sur votre ordinateur portable est assez simple. En faire fonctionner un qui gere des milliers de sessions d’agents AI simultanement a travers une infrastructure distribuee est un defi d’ingenierie totalement different. Les deployments MCP en production doivent traiter cinq preoccupations que les prototypes peuvent ignorer : la scalabilite du transport, l’authentification et l’autorisation, la gestion des sessions a grande echelle, les pistes d’audit et l’orchestration multi-serveurs.

Cet article est un guide technique pour les equipes d’ingenierie qui transferent des serveurs MCP du developpement a la production. Nous supposons que vous avez construit au moins un serveur MCP et que vous comprenez les bases du protocole. Sinon, commencez par notre article sur la construction de votre premier serveur MCP.

Scalabilite du transport : stdio vs SSE vs Streamable HTTP

Le MCP definit trois mecanismes de transport. Choisir le bon pour la production est votre premiere decision architecturale.

Transport stdio

Le transport stdio communique via les flux d’entree/sortie standard. L’application Host lance le serveur MCP comme processus enfant et echange des messages JSON-RPC via stdin/stdout.

Avantages :

• Zero configuration reseau
• Isolation au niveau du processus
• Pas de conflits de ports
• Latence la plus faible (pas de pile reseau)

Limitations :

• Le serveur doit tourner sur la meme machine que le Host
• Un processus serveur par session Client
• Pas de repartition de charge
• Pas de scaling horizontal

Ideal pour : Les outils de developpement locaux, les extensions IDE, les applications desktop mono-utilisateur.

Transport SSE (Server-Sent Events)

Le transport SSE utilise HTTP pour les messages client-vers-serveur et les Server-Sent Events pour les messages serveur-vers-client. Le serveur fonctionne comme un service HTTP.

Avantages :

• Accessible via le reseau (serveur distant)
• Compatible avec l’infrastructure HTTP existante
• Prend en charge plusieurs clients simultanes
• Fonctionne a travers les pare-feu et proxies

Limitations :

• Streaming unidirectionnel (SSE uniquement serveur-vers-client)
• Necessite l’affinite de session (connexion stateful)
• Certains repartiteurs de charge ont des problemes avec les connexions SSE de longue duree
• Pas de semantique de reconnexion integree au protocole

Ideal pour : Les deployments de petite a moyenne taille, les outils internes, les equipes avec une infrastructure HTTP existante.

Transport Streamable HTTP

Streamable HTTP est le transport le plus recent, concu specifiquement pour les deployments en production. Il utilise des POST HTTP standard pour tous les messages, avec du streaming SSE optionnel pour les operations de longue duree.

Avantages :

• Modele requete/reponse entierement stateless
• Fonctionne avec n’importe quel repartiteur de charge HTTP
• Gestion de session integree via l’en-tete Mcp-Session-Id
• Prend en charge les reponses streaming et non-streaming
• Compatible avec les CDN et les proxies

Limitations :

• Necessite un stockage de session cote serveur (Redis, base de donnees)
• Overhead par message legerement superieur a stdio
• Transport plus recent — moins d’outillage dans l’ecosysteme

Ideal pour : Les deployments cloud en production, les plateformes multi-tenant, les environnements enterprise.

Matrice de comparaison des transports

Caracteristique	stdio	SSE	Streamable HTTP
Support reseau	Non	Oui	Oui
Scaling horizontal	Non	Limite	Oui
Repartition de charge	Non	Affinite de session requise	LB HTTP standard
Gestion de session	Par processus	Memoire serveur	Store externe
Latence	La plus faible	Faible	Faible
Compatible pare-feu	N/A	Oui	Oui

Authentification et autorisation

Integration OAuth 2.0

Les serveurs MCP en production ont besoin d’un moyen pour les clients de s’authentifier et de restreindre l’acces a des outils et ressources specifiques. Le protocole MCP prend en charge OAuth 2.0 pour les serveurs distants.

Le flux se deroule ainsi :

1. Le MCP client se connecte au serveur et envoie une requete initialize
2. Le serveur repond 401 Unauthorized avec un en-tete WWW-Authenticate contenant l’URL de metadonnees OAuth
3. Le Client recupere la configuration OAuth depuis /.well-known/oauth-authorization-server
4. Le Client obtient un token d’acces via un flux d’autorisation base sur le navigateur
5. Les requetes suivantes incluent le token Bearer dans l’en-tete Authorization

Autorisation au niveau des outils

L’authentification seule ne suffit pas. Les systemes de production ont besoin d’une autorisation fine qui controle quels outils un utilisateur peut appeler et quelles ressources il peut consulter.

Approches recommandees :

• Controle d’acces base sur les roles (RBAC) : Attribuer des permissions d’outils aux roles. Exemple : le role analyst accede aux outils de requete en lecture seule, le role admin accede aux operations d’ecriture.
• Controle base sur les scopes : Utiliser les scopes OAuth pour limiter l’acces aux outils. Exemple : le scope mcp:tools:query:read autorise uniquement les requetes SELECT.
• Filtrage dynamique des outils : Filtrer la liste des outils disponibles en fonction des permissions de l’utilisateur authentifie.

Scaling horizontal avec Redis

En utilisant le transport Streamable HTTP stateless, vous pouvez executer plusieurs instances de serveur MCP derriere un repartiteur de charge. L’etat de session est stocke dans Redis et partage entre toutes les instances.

Client → Load Balancer → MCP Server 1 ↔ Redis
                       → MCP Server 2 ↔ Redis
                       → MCP Server 3 ↔ Redis

Chaque requete inclut l’en-tete Mcp-Session-Id, et n’importe quelle instance de serveur peut recuperer l’etat de session depuis Redis pour continuer le traitement.

Auto-scaling sur Kubernetes

Deployer des serveurs MCP sur Kubernetes permet de scaler automatiquement les Pods en fonction du nombre de sessions actives ou de l’utilisation CPU. Utilisez des metriques personnalisees avec le Horizontal Pod Autoscaler (HPA).

Journalisation d’audit

Les deployments enterprise necessitent des pistes d’audit detaillees chaque fois qu’une AI appelle un outil externe. Pour chaque appel d’outil, enregistrez :

• Horodatage : Heure de l’appel
• ID utilisateur : L’utilisateur qui a initie l’action AI
• Nom de l’outil : L’outil MCP appele
• Parametres d’entree : Les donnees envoyees a l’outil
• Resultat : Les donnees retournees par l’outil
• Duree d’execution : Le temps pris par l’appel
• Erreurs : Toute erreur survenue

Utilisez la journalisation structuree (format JSON) et envoyez les logs a un systeme de gestion centralise (ELK Stack, Datadog, CloudWatch).

Architecture de passerelle

Pour les deployments a grande echelle, envisagez d’implementer un pattern de passerelle MCP. La passerelle agit comme un reverse proxy entre les MCP clients et les serveurs MCP backend.

Responsabilites de la passerelle :

• Centralisation de l’authentification : Gerer toute la validation OAuth au niveau de la passerelle
• Limitation de debit : Appliquer des limites par utilisateur et par outil
• Routage : Router les requetes vers les serveurs backend appropries en fonction du nom de l’outil
• Collecte des logs d’audit : Enregistrer tous les appels d’outils au niveau de la passerelle
• Disjoncteur : Gerer les degradations en cas de panne des serveurs backend

FAQ

Q : Peut-on utiliser le transport stdio en production ? R : Oui, mais uniquement dans des scenarios limites. Il convient aux applications desktop ou chaque utilisateur execute son propre processus MCP server local. Pour l’infrastructure serveur partagee, utilisez Streamable HTTP.

Q : Faut-il persister les sessions MCP ? R : Oui, si vous utilisez Streamable HTTP. L’etat de session inclut les capacites du client, la version du protocole negociee et les notifications enregistrees. Redis est le store de session recommande.

Q : Comment gerer le versionnage des serveurs MCP ? R : Utilisez le champ de version du serveur dans la reponse initialize. Pour les modifications incompatibles (suppression d’outils, changement de schemas), faites un bump de version majeure et supportez les anciennes et nouvelles versions pendant une periode de migration.

Q : Quelle est la taille maximale des messages MCP ? R : Le protocole ne definit pas de maximum, mais les limites pratiques dependent du transport. Pour Streamable HTTP, gardez les reponses en dessous de 10 Mo. Pour stdio, les tampons de pipe systeme (generalement 64 Ko) peuvent necessiter du chunking pour les grandes reponses.