En mai 2026, le développeur Ivan Bogomolov a publié un court संदेश sur son blog personnel, signalant quelque chose de frappant : un moteur de jeu Godot 4 complet en 3D, avec le moteur de rendu GL Compatibility, la physique Jolt, l’exécution GDScript et un interpréteur narratif, exporté vers WebAssembly pour seulement 35MB.

À titre de comparaison :

• L’image Docker Node.js par défaut pèse 421MB.

• La page d’accueil de Facebook charge 44MB de ressources.

• Le moteur de jeu était en dessous des deux.

Son message soulevait une question naturelle : si un moteur de jeu complet se compile à une fraction d’une image Docker basique, WebAssembly peut-il aussi servir de conteneur pour des serveurs de jeu ?

La réponse courte est : pas encore. Voici pourquoi.

Qu’est-ce que WebAssembly ?

WebAssembly (WASM) est un format d’instructions binaire conçu pour s’exécuter dans les navigateurs à une vitesse proche du natif. Il a été pensé comme cible de compilation : vous écrivez le code dans un autre langage (Rust, C ou C++), vous le compilez en WASM, et le résultat s’exécute dans n’importe quel environnement prenant en charge un runtime WASM. Aucune installation requise, aucune compilation spécifique à l’OS, un comportement cohérent partout.

Cette portabilité fait son attrait. Un seul binaire qui s’exécute dans Chrome, Firefox, sur un serveur ou sur un nœud en périphérie ressemble exactement à ce dont un flux de déploiement conteneurisé a besoin. En pratique, l’écart entre « s’exécute partout » et « exécute un serveur de jeu » s’avère important.

La question de la taille : 35MB pour un moteur de jeu complet

Les chiffres méritent qu’on s’y attarde. Un moteur de jeu 3D complet à 35MB, contre 144MB pour une image de base Python légère avant même d’ajouter une seule dépendance, contre 421MB pour la dernière version de Node.js. À titre de comparaison, la page d’accueil de Facebook charge 44MB de ressources. Le moteur de jeu est plus petit que tout cela.

La différence de taille compte pour de vraies raisons opérationnelles. Des binaires plus petits signifient des démarrages à froid plus rapides pour les serveurs de jeu (le temps nécessaire pour télécharger l’image sur un hôte de serveur et lancer une instance de jeu). Pour les studios qui gèrent leur propre orchestration, les coûts d’egress liés à la livraison des images sont aussi une considération mineure, bien que sur les plateformes gérées ce coût soit absorbé par le fournisseur plutôt que facturé au studio.

Pour les studios qui ont construit leur propre orchestration interne, comme ceux qui utilisent Agones, le temps de démarrage à froid et la capacité du registre sont des contraintes qui nécessitent un investissement d’ingénierie délibéré pour être résolues. Sur les plateformes gérées, ces problèmes sont résolus par conception : par exemple, la plateforme d’Edgegap démarre les serveurs de jeu à froid en 3 secondes en moyenne et inclut un registre de conteneurs de 10GB. Les studios curieux de comprendre comment l’egress influe sur leurs coûts d’infrastructure spécifiques peuvent explorer son impact sur leur configuration via la tarification d’Edgegap à l’aide de notre calculateur d’hébergement de serveurs de jeu.

C’est cet argument d’efficacité qui rend WASM digne d’intérêt en tant que technologie serveur. Le problème est que la taille du binaire n’est qu’une dimension parmi celles dont un serveur de jeu a besoin.

Le problème côté serveur commence avec WASI

Pour fonctionner en dehors d’un navigateur, WebAssembly a besoin d’une interface avec le système d’exploitation sous-jacent.

Cette interface, c’est WASI : l’interface système de WebAssembly. WASI permet à un binaire WASM d’accéder aux fichiers, aux variables d’environnement et aux entrées/sorties standard lorsqu’il s’exécute sur un runtime serveur au lieu d’un bac à sable de navigateur.

Le hic, c’est ce que WASI restreint actuellement. Les sockets TCP et UDP sont soit indisponibles, soit sévèrement limités selon le runtime et la combinaison de langage. Le modèle d’accès au système de fichiers est fondé sur des capacités et fortement cloisonné. Pour une API web ou une fonction serverless, ces contraintes sont gérables. Pour un serveur de jeu, ce sont des obstacles bloquants.

Les serveurs de jeu multijoueurs vivent sur des sockets. Ils ont besoin d’UDP brut pour une livraison rapide et à faible surcharge des paquets. Ils ont aussi besoin d’un accès au système de fichiers pour la configuration, la journalisation et la persistance de l’état.

WASI, tel qu’il existe en 2026, ne fournit pas un accès fiable à l’un ou à l’autre au niveau requis par les serveurs de jeu. Comme Bogomolov l’a écrit clairement dans son billet : « wasip1 est toujours en aperçu, pas de sockets dans le runtime standard. »

Le support des langages complique encore le tableau : seuls Rust et C/C++ sont aujourd’hui des cibles de compilation WASM pratiques. Le support wasip1 de Go est encore en aperçu. Zig n’y est pas encore. Cette contrainte à elle seule limite déjà les studios qui peuvent même tenter une version serveur en WASM.

Le multithreading sans threads

Les serveurs de jeu ne sont pas des programmes monothread. La simulation physique, les entrées/sorties réseau, la réplication de l’état du jeu et le traitement des entrées des joueurs s’exécutent généralement en parallèle. Les moteurs sont conçus autour de cette hypothèse.

Le support du threading dans WebAssembly est limité. Les mécanismes existants nécessitent des contournements au niveau applicatif, en utilisant des interruptions et une planification coopérative pour approcher une exécution concurrente. Le résultat n’équivaut pas à de vrais threads OS. Cela introduit une surcharge de coordination, augmente la complexité du code et rend le débogage plus difficile sous charge.

Un studio qui résout les restrictions de sockets de WASI doit encore s’attaquer au threading avant que son serveur de jeu puisse fonctionner correctement à grande échelle. Ce ne sont pas des tâches d’intégration mineures. Ce sont des lacunes architecturales fondamentales dans la spécification actuelle de WASM.

Même si vous résolvez tout cela : le mur WebSocket

Supposons qu’une équipe investisse l’effort d’ingénierie nécessaire pour contourner les limitations de sockets de WASI et mette en place un modèle de threading qui tienne la charge.

Il reste encore un autre mur : les WebSockets.

Les runtimes serveurs WASM communiquent par défaut via WebSockets. Les WebSockets fonctionnent sur TCP, ajoutant une couche de connexion persistante avec son propre coût de handshake, de découpage des messages et de négociation de sécurité au-dessus de chaque message. Pour les navigateurs, c’est acceptable. Pour le trafic de jeu, c’est coûteux.

Les jeux utilisent UDP plutôt que TCP pour une raison. UDP est léger et rapide, sans handshake, sans surcharge de livraison garantie et sans blocage en tête de ligne. Un paquet qui arrive en retard est abandonné, ce qui est bien préférable à une connexion bloquée en attente d’une retransmission. Toute la discipline du netcode de jeu, de la compensation de latence au rollback, repose sur les propriétés d’UDP.

Acheminer le trafic de jeu via WebSockets efface donc une grande partie de l’avantage de performance que la petite taille du binaire WASM était censée apporter. Le serveur finit par dépenser des cycles CPU dans la surcharge WebSocket, ou par rencontrer des problèmes de résolution DNS à grande échelle, ou par générer des coûts d’egress qui rendent le déploiement difficile à justifier économiquement.

Compatibilité des plugins : la taxe de portage cachée

Au-delà des contraintes d’infrastructure, il existe un coût de développement concret que les studios prennent rarement en compte dès le départ. La plupart des paquets du magasin d’assets, des plugins de moteur et des SDK tiers ne se compilent pas automatiquement en WebAssembly. Ils ciblent des plateformes natives : Windows, Linux, macOS.

Les porter exige un travail manuel. Le soutien communautaire pour le développement de jeux en WASM est mince comparé aux déploiements basés sur Docker. La documentation est clairsemée, les tutoriels sont rares et les cas limites tendent à rester inconnus jusqu’à ce qu’une équipe soit déjà profondément engagée dans un projet.

Pour les studios ayant d’importantes dépendances à des plugins ou des équipes sans solide expérience en programmation systèmes, la seule charge de portage peut rendre une approche serveur en WASM impraticable, quels que soient les gains d’efficacité théoriques.

Où WASM s’insère réellement aujourd’hui : les jeux WebGL solo

Il existe un contexte où WASM contourne toutes les limitations ci-dessus : les jeux web solo côté client.

Un jeu solo exécuté dans un navigateur n’a pas besoin de sockets UDP bruts. Il n’a pas besoin de threading au niveau du système d’exploitation. Il n’a pas besoin d’interagir avec un écosystème de plugins conçu pour des cibles natives. Le navigateur fournit un environnement contrôlé où les contraintes de WASM ne sont tout simplement pas pertinentes pour le cas d’usage.

Godot le rend très concret. Le moteur exporte par défaut vers WebAssembly pour sa cible web. Un jeu Godot solo est livré sous forme de binaire de 35MB qui s’exécute dans n’importe quel navigateur moderne, sans installation. Pour un déploiement sur serveur Linux, Godot exporte plutôt un binaire natif. La distinction n’est pas accidentelle : elle reflète exactement où se situe aujourd’hui le plafond des capacités de WASM.

L’écosystème Rust et WebAssembly raconte une histoire similaire. L’une des ressources d’apprentissage WASM les plus citées est le livre officiel Rust et WebAssembly, qui explique comment construire le Jeu de la vie de Conway en tant que projet WASM basé sur le navigateur. C’est un exemple canonique d’une technologie qui fonctionne bien. C’est aussi une application solo, limitée au navigateur, sans exigences de réseau côté serveur.

WASM est un véritable bon choix pour les jeux web solo. Les backends multijoueurs sont un problème entièrement différent.

Un avis éclairé : la courbe d’adoption

L’infrastructure permettant d’exécuter WASM comme technologie côté serveur existe déjà, au moins sous forme expérimentale. Cloudflare Workers exécute des modules WASM en périphérie. containerd/runwasi apporte le support des charges de travail WASI à containerd. KWasm ajoute le support WebAssembly aux nœuds Kubernetes, bien que ses propres mainteneurs recommandent actuellement de ne pas l’utiliser en production. L’outillage se construit, prudemment.

Cette trajectoire ressemble à la manière dont les nœuds ARM sont entrés dans la conversation sur l’infrastructure cloud. ARM offrait depuis des années de réels avantages en coût et en densité avant de devenir un choix par défaut pour les charges de travail cloud. L’argument technique était clair très tôt. L’adoption a tardé pour des raisons de maturité de l’écosystème, de support de la chaîne d’outils et d’inertie organisationnelle. Puis cela a changé.

Que WASM suive le même parcours pour les serveurs de jeu est, pour être clair, une opinion et non un schéma établi. Les limites actuelles sont concrètes et documentées. Ce qui les fera évoluer, et à quel rythme, dépend de décisions prises par les fournisseurs de navigateurs, les mainteneurs des runtimes et les organismes de normalisation. Bogomolov termine son billet par la même question ouverte : « Pourquoi l’adoption de WASM a-t-elle ralenti ? L’argument de la taille de transfert est déjà là. »

C’est une question légitime. La réponse, pour les serveurs de jeu en particulier, est que la taille du binaire n’a jamais été le seul problème.

Ce que vous pouvez faire aujourd’hui

WASM n’est pas un conteneur viable pour serveur de jeu en 2026. Docker reste le choix pratique pour les studios qui déploient des serveurs multijoueurs dédiés, et l’outillage opérationnel qui l’entoure est mature, bien documenté et largement pris en charge.

Cela dit, la question d’efficacité soulevée par ses observations est bien réelle. La taille du binaire serveur a effectivement de l’importance pour les performances de démarrage à froid et les coûts d’egress, et il existe des mesures concrètes que les studios peuvent prendre avec les outils existants. Pour Unreal Engine, Edgegap a publié un guide sur l’analyse et l’optimisation des builds de serveurs de jeu via le profilage serveur. Pour Unity, les conseils d’optimisation des builds serveur sont directement couverts dans la documentation d’Edgegap.

Les gains qu’un jour WASM pourrait offrir sur le plan de la taille sont aujourd’hui atteignables avec les outils existants, sans attendre que l’écosystème arrive à maturité.

—

Cet article s’appuie sur un billet original d’Ivan Bogomolov, publié sur son blog personnel. Tous les droits sur le contenu original appartiennent à leurs propriétaires respectifs.