Comment déployer un serveur MCP auto-hébergé en 2026 ? Points clés de la nouvelle version sans état

Le 28 juillet 2026, la spécification MCP a supprimé l’initialisation et l’identifiant de session au niveau du protocole : cette évolution change la manière de concevoir certains services distants, mais ne supprime pas les états métier de votre application (annonce officielle). Cette semaine, vérifiez d’abord les clients et les opérations que vous utilisez, puis choisissez stdio pour une intégration locale ou Streamable HTTP pour un outil partagé par une équipe. Ne migrez pas un usage individuel simplement pour suivre la nouvelle spécification.

Cet article s’adresse aux développeurs qui hésitent à déplacer un service MCP de leur poste vers un serveur.
Il aide les petites équipes à partager leurs outils sans confondre accès distant et exposition publique.
Les responsables techniques y trouveront une méthode pour cadrer la compatibilité et la persistance des données métier.

Commencez par le lieu d’exécution et le nombre de clients

Le choix du transport est d’abord une décision d’usage, pas une obligation liée à la date de la spécification. Avec stdio, un client lance un processus MCP local et échange avec lui par les flux d’entrée et de sortie du processus. Cette intégration reste adaptée si l’outil doit lire un dépôt présent sur le poste, accéder à des fichiers locaux ou utiliser un environnement de développement qui n’existe pas sur un serveur.

À l’inverse, si plusieurs développeurs ou plusieurs applications doivent interroger le même service, un déploiement distant en Streamable HTTP facilite la centralisation de son cycle de vie. Vous pouvez déployer le service une fois, mettre à jour sa configuration au même endroit et éviter de demander à chaque utilisateur de gérer le processus local. La documentation du SDK TypeScript officiel distingue précisément le service distant en Streamable HTTP du serveur local en stdio (guide officiel des transports).

Un service distant ne doit pas nécessairement être ouvert à tout Internet. Vous pouvez décider qu’il ne sera accessible qu’aux clients et aux réseaux prévus par votre architecture. Séparez cette décision de celle du transport : choisir HTTP ne fixe pas, à lui seul, les règles d’exposition, d’identité ou d’autorisation. La documentation officielle sur le service HTTP décrit le modèle de transport ; adaptez ensuite les contrôles d’accès aux besoins de votre application (instructions de service HTTP du SDK).

Distinguez le mécanisme de session des données métier

La publication du 28 juillet 2026 annonce le retrait de l’échange initialize/initialized et de l’en-tête Mcp-Session-Id dans le protocole concerné (notes de publication MCP). La description officielle des transports permet de vérifier les règles correspondantes dans la spécification de cette version (spécification des transports MCP).

La conséquence pratique n’est pas « le serveur n’a plus besoin de mémoire ». Elle est plus précise : ne fondez pas la répartition des requêtes entre plusieurs instances sur un identifiant de session protocolaire supprimé, et ne supposez pas qu’un client récent enverra l’ancien échange d’initialisation. En revanche, votre service peut continuer à avoir besoin de reconnaître un utilisateur, de vérifier ses droits, de retrouver une tâche en cours ou de stocker le résultat d’une opération.

Distinguez donc ces couches avant de modifier le déploiement :

• État du protocole : étapes et identifiants utilisés par les échanges MCP. C’est cette couche qui change dans la version citée.
• État d’autorisation : identité, rôles, accès aux outils et règles de validation. Il demeure nécessaire dès que votre service doit contrôler les actions.
• État métier : objets créés, modifications demandées, progression d’un traitement ou résultat à consulter ultérieurement. Il relève de votre application et de ses stockages.
• État d’exécution : tâches longues, reprises après incident, temporisation et résultats d’erreur. Il faut le traiter en fonction du comportement attendu, même si la couche protocolaire n’utilise plus de session.

La documentation de la spécification est la référence pour les règles de transport ; la documentation du SDK décrit l’implémentation proposée par ce SDK. Ne déduisez pas d’une évolution normative que toutes les versions d’un client ou d’une bibliothèque ont déjà adopté le même comportement. Pour un service qui écrit dans une base, lance un traitement ou modifie un document, définissez notamment comment éviter les doublons si le client réessaie une requête et comment reprendre le travail après l’arrêt d’un processus.

Préparez la migration selon les dépendances réelles

Une migration sûre commence par un inventaire, pas par une mise à jour simultanée de tous les composants. Notez les versions en cours d’utilisation, le transport effectivement configuré, les fonctions appelées et les données qui doivent survivre à une fermeture du client. La page officielle de migration du SDK TypeScript détaille les indications de compatibilité associées à la spécification du 28 juillet 2026 (guide officiel de compatibilité et migration).

Procédez ensuite par étapes vérifiables :

1. Établissez l’inventaire : relevez les clients, serveurs, SDK et configurations concernés. Distinguez les intégrations locales en stdio des services distants en Streamable HTTP.
2. Vérifiez les sources officielles actuelles : confirmez le comportement de la version de spécification visée et les instructions correspondant à la version stable du SDK réellement utilisée. Ne copiez pas une configuration issue d’un exemple ancien sans vérifier qu’elle correspond encore à votre combinaison de versions.
3. Repérez les dépendances à l’ancien cycle de session : recherchez les hypothèses liées à l’initialisation, à l’en-tête de session, à la conservation d’un contexte ou à l’envoi répété d’une requête.
4. Préparez un environnement de test : utilisez un client représentatif et un service non critique. Gardez la configuration de production en place pendant les essais, afin de pouvoir revenir au comportement connu si une intégration échoue.
5. Validez des opérations concrètes : testez une lecture, une opération avec autorisation, une écriture si elle existe, ainsi que les erreurs attendues. Vérifiez le résultat côté application, pas seulement la réussite d’une connexion.
6. Basculez progressivement : ne déplacez que les clients validés. Conservez une voie de retour documentée et évitez de mettre à jour simultanément clients, SDK, service et stockage si cela vous empêcherait d’identifier l’origine d’un échec.
7. Surveillez la période de transition : examinez les journaux, les reprises, les refus d’accès et les doublons éventuels. Une fois les usages stabilisés, retirez les configurations de compatibilité qui ne sont plus nécessaires.

Si un ancien client dépend d’un mécanisme supprimé ou d’un transport différent, ne déclarez pas la combinaison compatible avant de l’avoir testée. Les notes de migration du SDK sont un point de départ pour vérifier son périmètre ; la compatibilité finale dépend aussi des versions et de la configuration de votre client et de votre serveur.

Vérifiez les opérations longues et les reprises

Les appels rapides et sans effet de bord ne posent pas les mêmes questions qu’une opération qui écrit des données, attend un traitement externe ou doit survivre à une déconnexion. Dans ces cas, concevez explicitement la suite de l’opération dans la couche métier.

Avant la mise en service, répondez aux questions suivantes :

• Si le client renvoie une requête après un délai d’attente, le service peut-il créer deux fois le même élément ?
• La progression d’une tâche longue est-elle enregistrée ailleurs que dans la mémoire du processus ?
• Après un redémarrage, votre application sait-elle distinguer une tâche terminée, en cours ou échouée ?
• Les journaux indiquent-ils l’appel, le résultat et l’erreur sans exposer les secrets ou des données auxquelles l’opérateur ne devrait pas avoir accès ?
• Les droits sont-ils vérifiés à chaque opération sensible, y compris lors d’une reprise ?

Si vous ne pouvez pas répondre à l’une de ces questions, la suppression d’une session protocolaire ne règle pas le problème. Ajoutez le stockage ou les contrôles nécessaires au niveau de l’application, puis testez le chemin de reprise avant de rendre le service commun à plusieurs utilisateurs. La propriété recherchée est la prévisibilité de l’opération, pas une promesse de hausse de performances liée à la nouvelle spécification.

Situez la charge avant de choisir un serveur

Un serveur dédié se justifie surtout si vous devez faire fonctionner durablement un outil partagé, plusieurs services ou des conteneurs associés, et si vous souhaitez administrer vous-même leur environnement. Il est moins adapté à un essai ponctuel, à une charge légère ou à un besoin qui exige une élasticité à très court terme : dans ces cas, une exécution locale ou une offre à la demande peut être plus proportionnée.

Pour le dimensionnement, mesurez d’abord la consommation réelle de votre processus MCP et de ses dépendances. Ajoutez les besoins des autres conteneurs qui tourneront sur la même machine, les fichiers et données conservés localement, ainsi que la marge nécessaire lors des déploiements ou des traitements. Il n’existe pas de besoin minimal universel déductible du seul fait qu’un service parle MCP.

La grille ci-dessous reprend les options publiées pour les serveurs OVN Cloud ; vérifiez la fiche de configuration avant de retenir une machine, notamment si votre application stocke des données durables ou partage le serveur avec d’autres conteneurs (configurations des serveurs dédiés).

Ces caractéristiques décrivent le matériel proposé, pas une configuration MCP minimale, un nombre de clients garanti ou une mesure de performance. Le modèle de serveur ne fournit pas de GPU ; ne choisissez donc pas cette machine pour entraîner un modèle ou pour une charge qui exige une accélération graphique. Pour un service MCP classique, le critère pertinent reste la charge réellement mesurée de ses outils et de ses dépendances. Si plusieurs services partagent la machine, incluez-les dans le même relevé.

Avant de vous engager, vérifiez aussi la manière dont vous allez administrer le système, le stockage et les mises à jour. La page consacrée aux systèmes disponibles et aux modes de connexion SSH ou RDP aide à confirmer le parcours d’accès ; les modalités et périodes proposées figurent sur la page de facturation. Les tarifs ne sont pas repris ici : reportez-vous aux informations affichées pour la configuration choisie.

Questions fréquentes sur le déploiement MCP

Pour une équipe, comment rendre un outil MCP accessible à plusieurs développeurs ?

Déployez le service en Streamable HTTP si plusieurs clients doivent partager le même outil, puis décidez séparément de son périmètre d’accès et de ses autorisations. Il n’est pas nécessaire de le publier sans restriction sur Internet. Avant la mise en service, confirmez que chaque client sait utiliser le transport retenu et testez les fonctions partagées avec les droits prévus.

Le protocole sans état signifie-t-il qu’il n’y a plus rien à conserver ?

Non. La version du 28 juillet 2026 retire un mécanisme de session au niveau du protocole, et non les données de l’application. Si votre service doit retrouver une tâche, reprendre une écriture, vérifier les droits d’un utilisateur ou fournir un résultat après une interruption, définissez où ces informations sont enregistrées et comment elles sont récupérées.

Faut-il migrer une intégration locale en stdio vers HTTP ?

Pas si le client doit démarrer un processus local pour accéder aux fichiers ou aux outils du poste. stdio reste cohérent pour ce cas. Streamable HTTP répond plutôt au besoin d’un service partagé et administré à distance. Le choix doit suivre l’emplacement des ressources et le nombre de clients, non la seule date de la spécification MCP.

Comment savoir si un ancien client fonctionnera avec un serveur récent ?

Vérifiez les versions de la spécification et du SDK prises en charge des deux côtés, puis testez un parcours réel dans un environnement non critique. Portez une attention particulière à l’initialisation, à la gestion de session et au transport configuré. Gardez une configuration de retour arrière jusqu’à ce que lectures, écritures et erreurs soient validées avec les clients concernés.

Pour votre déploiement, la décision tient donc à l’usage : gardez stdio quand l’outil appartient au poste de travail ; envisagez Streamable HTTP lorsque plusieurs clients doivent partager un service administré de façon centralisée. Si cet usage exige une machine dédiée pour faire tourner durablement le serveur MCP et ses conteneurs associés, comparez votre charge mesurée aux configurations OVN Cloud plutôt que de choisir sur la seule nouveauté du protocole. Les VM partagées peuvent exposer à une concurrence de ressources, à des limites de configuration ou à une facturation difficile à rapprocher d’un service permanent ; un serveur physique dédié devient alors une option à étudier, sans être nécessaire pour un test bref ou une charge faible.

Dernière mise à jour : 25 octobre 2026. Les règles de protocole ont été vérifiées à partir de la publication officielle du 28 juillet 2026, de la spécification des transports, de la documentation du SDK TypeScript et de son guide de compatibilité. Avant toute mise à niveau, vérifiez à nouveau les versions stables et les instructions officielles correspondant à votre déploiement.

Questions fréquentes

1. Quel transport choisir pour partager un serveur MCP entre plusieurs développeurs ? Pour un outil utilisé par plusieurs clients, privilégiez Streamable HTTP : le service peut être déployé et administré au même endroit, sans lancer un processus local séparé sur chaque poste. Il n’a pas besoin d’être accessible publiquement pour autant. Définissez qui peut le joindre, comment les clients s’authentifient et quelles opérations ils sont autorisés à exécuter.
2. La nouvelle version sans état supprime-t-elle le besoin de conserver les sessions ? La modification du 28 juillet 2026 concerne le mécanisme de session au niveau du protocole MCP, notamment l’initialisation et l’identifiant de session. Elle ne rend pas sans état votre application : autorisations, données métier, tâches longues et progression d’un traitement peuvent toujours exiger une persistance. Conservez ces éléments dans la couche applicative appropriée.
3. Quand conserver stdio plutôt que passer à Streamable HTTP ? Conservez stdio lorsque le client MCP doit lancer un processus sur le poste de l’utilisateur et accéder directement à ses fichiers locaux ou à son environnement de développement. Choisissez plutôt Streamable HTTP quand plusieurs clients doivent joindre un service commun. Une nouvelle version de spécification ne suffit pas, à elle seule, à justifier une migration.
4. Un ancien client MCP peut-il se connecter à un serveur récent ? Ne le présumez pas : vérifiez les transports et les versions pris en charge par le client, le SDK et le serveur que vous utilisez. Si l’ancien client dépend encore de l’initialisation ou d’un comportement de session antérieur, testez le parcours complet avant la bascule. Gardez une configuration de retour arrière tant que les opérations représentatives ne sont pas validées.