[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-mcp-production-transport-auth-scaling-defis":3},{"article":4,"author":55},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":16,"meta_description":17,"focus_keyword":18,"og_image":19,"canonical_url":19,"robots_meta":20,"created_at":15,"updated_at":15,"tags":21,"category_name":35,"related_articles":36},"d0000000-0000-0000-0000-000000000514","a0000000-0000-0000-0000-000000000066","MCP en production : resoudre les defis de transport, auth et scaling","mcp-production-transport-auth-scaling-defis","Un guide approfondi sur l'exploitation des serveurs Model Context Protocol en production — selection du transport, patterns d'authentification, strategies de scaling, journalisation d'audit et architectures de passerelle pour les deployments enterprise.","## Du prototype a la production : ce qui change\n\nConstruire 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**.\n\nCet 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.\n\n## Scalabilite du transport : stdio vs SSE vs Streamable HTTP\n\nLe MCP definit trois mecanismes de transport. Choisir le bon pour la production est votre premiere decision architecturale.\n\n### Transport stdio\n\nLe transport stdio communique via les flux d'entree\u002Fsortie standard. L'application Host lance le serveur MCP comme processus enfant et echange des messages JSON-RPC via stdin\u002Fstdout.\n\n**Avantages :**\n- Zero configuration reseau\n- Isolation au niveau du processus\n- Pas de conflits de ports\n- Latence la plus faible (pas de pile reseau)\n\n**Limitations :**\n- Le serveur doit tourner sur la meme machine que le Host\n- Un processus serveur par session Client\n- Pas de repartition de charge\n- Pas de scaling horizontal\n\n**Ideal pour :** Les outils de developpement locaux, les extensions IDE, les applications desktop mono-utilisateur.\n\n### Transport SSE (Server-Sent Events)\n\nLe 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.\n\n**Avantages :**\n- Accessible via le reseau (serveur distant)\n- Compatible avec l'infrastructure HTTP existante\n- Prend en charge plusieurs clients simultanes\n- Fonctionne a travers les pare-feu et proxies\n\n**Limitations :**\n- Streaming unidirectionnel (SSE uniquement serveur-vers-client)\n- Necessite l'affinite de session (connexion stateful)\n- Certains repartiteurs de charge ont des problemes avec les connexions SSE de longue duree\n- Pas de semantique de reconnexion integree au protocole\n\n**Ideal pour :** Les deployments de petite a moyenne taille, les outils internes, les equipes avec une infrastructure HTTP existante.\n\n### Transport Streamable HTTP\n\nStreamable 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.\n\n**Avantages :**\n- Modele requete\u002Freponse entierement stateless\n- Fonctionne avec n'importe quel repartiteur de charge HTTP\n- Gestion de session integree via l'en-tete `Mcp-Session-Id`\n- Prend en charge les reponses streaming et non-streaming\n- Compatible avec les CDN et les proxies\n\n**Limitations :**\n- Necessite un stockage de session cote serveur (Redis, base de donnees)\n- Overhead par message legerement superieur a stdio\n- Transport plus recent — moins d'outillage dans l'ecosysteme\n\n**Ideal pour :** Les deployments cloud en production, les plateformes multi-tenant, les environnements enterprise.\n\n### Matrice de comparaison des transports\n\n| Caracteristique | stdio | SSE | Streamable HTTP |\n|-----------------|-------|-----|-----------------|\n| Support reseau | Non | Oui | Oui |\n| Scaling horizontal | Non | Limite | Oui |\n| Repartition de charge | Non | Affinite de session requise | LB HTTP standard |\n| Gestion de session | Par processus | Memoire serveur | Store externe |\n| Latence | La plus faible | Faible | Faible |\n| Compatible pare-feu | N\u002FA | Oui | Oui |\n\n## Authentification et autorisation\n\n### Integration OAuth 2.0\n\nLes 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.\n\nLe flux se deroule ainsi :\n\n1. Le MCP client se connecte au serveur et envoie une requete `initialize`\n2. Le serveur repond `401 Unauthorized` avec un en-tete `WWW-Authenticate` contenant l'URL de metadonnees OAuth\n3. Le Client recupere la configuration OAuth depuis `\u002F.well-known\u002Foauth-authorization-server`\n4. Le Client obtient un token d'acces via un flux d'autorisation base sur le navigateur\n5. Les requetes suivantes incluent le token Bearer dans l'en-tete `Authorization`\n\n### Autorisation au niveau des outils\n\nL'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.\n\nApproches recommandees :\n\n- **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.\n- **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.\n- **Filtrage dynamique des outils** : Filtrer la liste des outils disponibles en fonction des permissions de l'utilisateur authentifie.\n\n## Scaling horizontal avec Redis\n\nEn 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.\n\n```\nClient → Load Balancer → MCP Server 1 ↔ Redis\n                       → MCP Server 2 ↔ Redis\n                       → MCP Server 3 ↔ Redis\n```\n\nChaque 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.\n\n### Auto-scaling sur Kubernetes\n\nDeployer 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).\n\n## Journalisation d'audit\n\nLes deployments enterprise necessitent des pistes d'audit detaillees chaque fois qu'une AI appelle un outil externe. Pour chaque appel d'outil, enregistrez :\n\n- **Horodatage** : Heure de l'appel\n- **ID utilisateur** : L'utilisateur qui a initie l'action AI\n- **Nom de l'outil** : L'outil MCP appele\n- **Parametres d'entree** : Les donnees envoyees a l'outil\n- **Resultat** : Les donnees retournees par l'outil\n- **Duree d'execution** : Le temps pris par l'appel\n- **Erreurs** : Toute erreur survenue\n\nUtilisez la journalisation structuree (format JSON) et envoyez les logs a un systeme de gestion centralise (ELK Stack, Datadog, CloudWatch).\n\n## Architecture de passerelle\n\nPour 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.\n\nResponsabilites de la passerelle :\n\n- **Centralisation de l'authentification** : Gerer toute la validation OAuth au niveau de la passerelle\n- **Limitation de debit** : Appliquer des limites par utilisateur et par outil\n- **Routage** : Router les requetes vers les serveurs backend appropries en fonction du nom de l'outil\n- **Collecte des logs d'audit** : Enregistrer tous les appels d'outils au niveau de la passerelle\n- **Disjoncteur** : Gerer les degradations en cas de panne des serveurs backend\n\n## FAQ\n\n**Q : Peut-on utiliser le transport stdio en production ?**\nR : 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.\n\n**Q : Faut-il persister les sessions MCP ?**\nR : 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.\n\n**Q : Comment gerer le versionnage des serveurs MCP ?**\nR : 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.\n\n**Q : Quelle est la taille maximale des messages MCP ?**\nR : 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.","\u003Ch2 id=\"du-prototype-a-la-production-ce-qui-change\">Du prototype a la production : ce qui change\u003C\u002Fh2>\n\u003Cp>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 : \u003Cstrong>la scalabilite du transport\u003C\u002Fstrong>, \u003Cstrong>l’authentification et l’autorisation\u003C\u002Fstrong>, \u003Cstrong>la gestion des sessions a grande echelle\u003C\u002Fstrong>, \u003Cstrong>les pistes d’audit\u003C\u002Fstrong> et \u003Cstrong>l’orchestration multi-serveurs\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"scalabilite-du-transport-stdio-vs-sse-vs-streamable-http\">Scalabilite du transport : stdio vs SSE vs Streamable HTTP\u003C\u002Fh2>\n\u003Cp>Le MCP definit trois mecanismes de transport. Choisir le bon pour la production est votre premiere decision architecturale.\u003C\u002Fp>\n\u003Ch3>Transport stdio\u003C\u002Fh3>\n\u003Cp>Le transport stdio communique via les flux d’entree\u002Fsortie standard. L’application Host lance le serveur MCP comme processus enfant et echange des messages JSON-RPC via stdin\u002Fstdout.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Avantages :\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Zero configuration reseau\u003C\u002Fli>\n\u003Cli>Isolation au niveau du processus\u003C\u002Fli>\n\u003Cli>Pas de conflits de ports\u003C\u002Fli>\n\u003Cli>Latence la plus faible (pas de pile reseau)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Limitations :\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Le serveur doit tourner sur la meme machine que le Host\u003C\u002Fli>\n\u003Cli>Un processus serveur par session Client\u003C\u002Fli>\n\u003Cli>Pas de repartition de charge\u003C\u002Fli>\n\u003Cli>Pas de scaling horizontal\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Ideal pour :\u003C\u002Fstrong> Les outils de developpement locaux, les extensions IDE, les applications desktop mono-utilisateur.\u003C\u002Fp>\n\u003Ch3>Transport SSE (Server-Sent Events)\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Avantages :\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Accessible via le reseau (serveur distant)\u003C\u002Fli>\n\u003Cli>Compatible avec l’infrastructure HTTP existante\u003C\u002Fli>\n\u003Cli>Prend en charge plusieurs clients simultanes\u003C\u002Fli>\n\u003Cli>Fonctionne a travers les pare-feu et proxies\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Limitations :\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Streaming unidirectionnel (SSE uniquement serveur-vers-client)\u003C\u002Fli>\n\u003Cli>Necessite l’affinite de session (connexion stateful)\u003C\u002Fli>\n\u003Cli>Certains repartiteurs de charge ont des problemes avec les connexions SSE de longue duree\u003C\u002Fli>\n\u003Cli>Pas de semantique de reconnexion integree au protocole\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Ideal pour :\u003C\u002Fstrong> Les deployments de petite a moyenne taille, les outils internes, les equipes avec une infrastructure HTTP existante.\u003C\u002Fp>\n\u003Ch3>Transport Streamable HTTP\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Avantages :\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Modele requete\u002Freponse entierement stateless\u003C\u002Fli>\n\u003Cli>Fonctionne avec n’importe quel repartiteur de charge HTTP\u003C\u002Fli>\n\u003Cli>Gestion de session integree via l’en-tete \u003Ccode>Mcp-Session-Id\u003C\u002Fcode>\u003C\u002Fli>\n\u003Cli>Prend en charge les reponses streaming et non-streaming\u003C\u002Fli>\n\u003Cli>Compatible avec les CDN et les proxies\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Limitations :\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Necessite un stockage de session cote serveur (Redis, base de donnees)\u003C\u002Fli>\n\u003Cli>Overhead par message legerement superieur a stdio\u003C\u002Fli>\n\u003Cli>Transport plus recent — moins d’outillage dans l’ecosysteme\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Ideal pour :\u003C\u002Fstrong> Les deployments cloud en production, les plateformes multi-tenant, les environnements enterprise.\u003C\u002Fp>\n\u003Ch3>Matrice de comparaison des transports\u003C\u002Fh3>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Caracteristique\u003C\u002Fth>\u003Cth>stdio\u003C\u002Fth>\u003Cth>SSE\u003C\u002Fth>\u003Cth>Streamable HTTP\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Support reseau\u003C\u002Ftd>\u003Ctd>Non\u003C\u002Ftd>\u003Ctd>Oui\u003C\u002Ftd>\u003Ctd>Oui\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Scaling horizontal\u003C\u002Ftd>\u003Ctd>Non\u003C\u002Ftd>\u003Ctd>Limite\u003C\u002Ftd>\u003Ctd>Oui\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Repartition de charge\u003C\u002Ftd>\u003Ctd>Non\u003C\u002Ftd>\u003Ctd>Affinite de session requise\u003C\u002Ftd>\u003Ctd>LB HTTP standard\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Gestion de session\u003C\u002Ftd>\u003Ctd>Par processus\u003C\u002Ftd>\u003Ctd>Memoire serveur\u003C\u002Ftd>\u003Ctd>Store externe\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Latence\u003C\u002Ftd>\u003Ctd>La plus faible\u003C\u002Ftd>\u003Ctd>Faible\u003C\u002Ftd>\u003Ctd>Faible\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Compatible pare-feu\u003C\u002Ftd>\u003Ctd>N\u002FA\u003C\u002Ftd>\u003Ctd>Oui\u003C\u002Ftd>\u003Ctd>Oui\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch2 id=\"authentification-et-autorisation\">Authentification et autorisation\u003C\u002Fh2>\n\u003Ch3>Integration OAuth 2.0\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>Le flux se deroule ainsi :\u003C\u002Fp>\n\u003Col>\n\u003Cli>Le MCP client se connecte au serveur et envoie une requete \u003Ccode>initialize\u003C\u002Fcode>\u003C\u002Fli>\n\u003Cli>Le serveur repond \u003Ccode>401 Unauthorized\u003C\u002Fcode> avec un en-tete \u003Ccode>WWW-Authenticate\u003C\u002Fcode> contenant l’URL de metadonnees OAuth\u003C\u002Fli>\n\u003Cli>Le Client recupere la configuration OAuth depuis \u003Ccode>\u002F.well-known\u002Foauth-authorization-server\u003C\u002Fcode>\u003C\u002Fli>\n\u003Cli>Le Client obtient un token d’acces via un flux d’autorisation base sur le navigateur\u003C\u002Fli>\n\u003Cli>Les requetes suivantes incluent le token Bearer dans l’en-tete \u003Ccode>Authorization\u003C\u002Fcode>\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch3>Autorisation au niveau des outils\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>Approches recommandees :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Controle d’acces base sur les roles (RBAC)\u003C\u002Fstrong> : Attribuer des permissions d’outils aux roles. Exemple : le role \u003Ccode>analyst\u003C\u002Fcode> accede aux outils de requete en lecture seule, le role \u003Ccode>admin\u003C\u002Fcode> accede aux operations d’ecriture.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Controle base sur les scopes\u003C\u002Fstrong> : Utiliser les scopes OAuth pour limiter l’acces aux outils. Exemple : le scope \u003Ccode>mcp:tools:query:read\u003C\u002Fcode> autorise uniquement les requetes SELECT.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Filtrage dynamique des outils\u003C\u002Fstrong> : Filtrer la liste des outils disponibles en fonction des permissions de l’utilisateur authentifie.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"scaling-horizontal-avec-redis\">Scaling horizontal avec Redis\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Client → Load Balancer → MCP Server 1 ↔ Redis\n                       → MCP Server 2 ↔ Redis\n                       → MCP Server 3 ↔ Redis\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Chaque requete inclut l’en-tete \u003Ccode>Mcp-Session-Id\u003C\u002Fcode>, et n’importe quelle instance de serveur peut recuperer l’etat de session depuis Redis pour continuer le traitement.\u003C\u002Fp>\n\u003Ch3>Auto-scaling sur Kubernetes\u003C\u002Fh3>\n\u003Cp>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).\u003C\u002Fp>\n\u003Ch2 id=\"journalisation-d-audit\">Journalisation d’audit\u003C\u002Fh2>\n\u003Cp>Les deployments enterprise necessitent des pistes d’audit detaillees chaque fois qu’une AI appelle un outil externe. Pour chaque appel d’outil, enregistrez :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Horodatage\u003C\u002Fstrong> : Heure de l’appel\u003C\u002Fli>\n\u003Cli>\u003Cstrong>ID utilisateur\u003C\u002Fstrong> : L’utilisateur qui a initie l’action AI\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Nom de l’outil\u003C\u002Fstrong> : L’outil MCP appele\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Parametres d’entree\u003C\u002Fstrong> : Les donnees envoyees a l’outil\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Resultat\u003C\u002Fstrong> : Les donnees retournees par l’outil\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Duree d’execution\u003C\u002Fstrong> : Le temps pris par l’appel\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Erreurs\u003C\u002Fstrong> : Toute erreur survenue\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Utilisez la journalisation structuree (format JSON) et envoyez les logs a un systeme de gestion centralise (ELK Stack, Datadog, CloudWatch).\u003C\u002Fp>\n\u003Ch2 id=\"architecture-de-passerelle\">Architecture de passerelle\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>Responsabilites de la passerelle :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Centralisation de l’authentification\u003C\u002Fstrong> : Gerer toute la validation OAuth au niveau de la passerelle\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Limitation de debit\u003C\u002Fstrong> : Appliquer des limites par utilisateur et par outil\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Routage\u003C\u002Fstrong> : Router les requetes vers les serveurs backend appropries en fonction du nom de l’outil\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Collecte des logs d’audit\u003C\u002Fstrong> : Enregistrer tous les appels d’outils au niveau de la passerelle\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Disjoncteur\u003C\u002Fstrong> : Gerer les degradations en cas de panne des serveurs backend\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"faq\">FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Q : Peut-on utiliser le transport stdio en production ?\u003C\u002Fstrong>\nR : 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Q : Faut-il persister les sessions MCP ?\u003C\u002Fstrong>\nR : 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Q : Comment gerer le versionnage des serveurs MCP ?\u003C\u002Fstrong>\nR : Utilisez le champ de version du serveur dans la reponse \u003Ccode>initialize\u003C\u002Fcode>. 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Q : Quelle est la taille maximale des messages MCP ?\u003C\u002Fstrong>\nR : 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.\u003C\u002Fp>\n","fr","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:39.158631Z","MCP en production : transport, auth et defis de scaling","Guide technique pour exploiter des serveurs MCP en production. Couvre la selection du transport, l'authentification OAuth, le scaling horizontal avec sessions Redis, la journalisation d'audit et les patterns de passerelle.","mcp production scaling",null,"index, follow",[22,27,31],{"id":23,"name":24,"slug":25,"created_at":26},"c0000000-0000-0000-0000-000000000008","AI","ai","2026-03-28T10:44:21.513630Z",{"id":28,"name":29,"slug":30,"created_at":26},"c0000000-0000-0000-0000-000000000012","DevOps","devops",{"id":32,"name":33,"slug":34,"created_at":26},"c0000000-0000-0000-0000-000000000013","Security","security","Ingénierie",[37,43,49],{"id":38,"title":39,"slug":40,"excerpt":41,"locale":12,"category_name":35,"published_at":42},"d0000000-0000-0000-0000-000000000677","Pourquoi Bali devient le hub impact-tech d'Asie du Sud-Est en 2026","pourquoi-bali-devient-hub-impact-tech-asie-sud-est-2026","Bali se classe 16e parmi les écosystèmes startups d'Asie du Sud-Est. Avec une concentration croissante de bâtisseurs Web3, de startups IA durables et d'entreprises eco-travel tech, l'île se forge une identité de capitale impact-tech de la région.","2026-03-28T10:44:49.517126Z",{"id":44,"title":45,"slug":46,"excerpt":47,"locale":12,"category_name":35,"published_at":48},"d0000000-0000-0000-0000-000000000676","Le patchwork de la protection des données ASEAN : checklist de conformité pour les développeurs","patchwork-protection-donnees-asean-checklist-conformite-developpeurs","Sept pays de l'ASEAN disposent désormais de lois complètes sur la protection des données, chacune avec des modèles de consentement, des exigences de localisation et des structures de sanctions différents. Voici une checklist pratique de conformité pour les développeurs.","2026-03-28T10:44:49.504560Z",{"id":50,"title":51,"slug":52,"excerpt":53,"locale":12,"category_name":35,"published_at":54},"d0000000-0000-0000-0000-000000000675","La transformation numérique de 29 milliards de dollars d'Indonesia : opportunités pour les éditeurs de logiciels","transformation-numerique-29-milliards-dollars-indonesia-opportunites-editeurs-logiciels","Le marché des services informatiques d'Indonesia devrait atteindre 29,03 milliards de dollars en 2026, contre 24,37 milliards en 2025. L'infrastructure cloud, l'IA, le e-commerce et les centres de données tirent la croissance la plus rapide d'Asie du Sud-Est.","2026-03-28T10:44:49.469231Z",{"id":13,"name":56,"slug":57,"bio":58,"photo_url":19,"linkedin":19,"role":59,"created_at":60,"updated_at":60},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]