En mai 2026, le développeur Ivan Bogomolov a publié un court article sur son blog personnel, soulignant un fait frappant : un moteur de jeu 3D Godot 4 complet, doté d'un moteur de rendu compatible GL, du moteur physique Jolt, du runtime GDScript et d'un interpréteur narratif, exporté vers WebAssembly pour seulement 35 Mo.

À titre de comparaison :

• L'image Docker par défaut de Node.js pèse 421 Mo.

• La page d'accueil de Facebook charge 44 Mo de ressources.

• Le moteur de jeu était plus léger que les deux.

Son article soulevait une question logique : si un moteur de jeu complet se compile en une fraction d'une image Docker minimale, WebAssembly peut-il également servir de conteneur pour les serveurs de jeu ?

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

Qu'est-ce que WebAssembly ?

WebAssembly (WASM) est un format d'instructions binaires conçu pour s'exécuter dans les navigateurs à une vitesse proche du natif. Il a été créé en tant que cible de compilation : vous écrivez du 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, aucun build spécifique au système d'exploitation, un comportement cohérent partout.

Cette portabilité constitue tout son attrait. Un binaire unique fonctionnant sous Chrome, Firefox, sur un serveur ou sur un nœud edge semble correspondre exactement aux besoins d'un workflow de déploiement conteneurisé. En pratique, le fossé entre « fonctionne partout » et « fait tourner un serveur de jeu » s'avère important.

L'argument de la taille : 35 Mo pour un moteur de jeu complet

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

Cette différence de taille importe pour de réelles raisons opérationnelles. Des binaires plus petits réduisent les temps de démarrage à froid des serveurs de jeu (le temps nécessaire pour télécharger l'image sur l'hôte et lancer une instance de jeu). Pour les studios gérant leur propre orchestration, les coûts de trafic sortant (egress) liés à la distribution des images sont également un facteur mineur, 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 ayant développé leur propre orchestration interne, comme ceux utilisant Agones, le temps de démarrage à froid et la capacité du registre sont des contraintes qui exigent des investissements d'ingénierie ciblés. Sur les plateformes gérées, ces problèmes sont résolus dès la conception : par exemple, la plateforme d'Edgegap affiche un temps médian de déploiement de serveur de 2 secondes à partir d'un démarrage à froid (provisionné de zéro et mesuré jusqu'à ce que le conteneur soit prêt, selon les données de la plateforme) et comprend un registre de conteneurs de 10 Go. Les studios désireux de comprendre l'impact de l'egress sur leurs coûts d'infrastructure spécifiques peuvent évaluer sa répercussion grâce à la tarification d'Edgegap à l'aide de notre calculateur d'hébergement de serveurs de jeu.

Cet argument d'efficacité justifie de prendre WASM au sérieux en tant que technologie serveur. Le problème est que la taille du binaire n'est qu'une des composantes de ce dont un serveur de jeu a besoin.

Le problème du serveur commence avec WASI

Pour s'exécuter en dehors d'un navigateur, WebAssembly a besoin d'une interface avec le système d'exploitation sous-jacent.

Cette interface est WASI : la WebAssembly System Interface. 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 plutôt que dans le bac à sable d'un navigateur.

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

Les serveurs de jeux multijoueurs reposent sur les sockets. Ils ont besoin d'UDP brut pour une transmission de paquets rapide et à faible surcharge. Ils nécessitent également un accès au système de fichiers pour la configuration, la journalisation et la persistance de l'état.

Dans son état de 2026, WASI n'offre d'accès fiable à aucun des deux au niveau d'exigence requis par les serveurs de jeu. Comme Bogomolov l'a fait remarquer sans détour dans son article : « wasip1 est toujours en preview, pas de sockets dans le runtime standard ».

La prise en charge des langages vient aggraver la situation : seuls Rust et C/C++ constituent aujourd'hui des cibles de compilation WASM viables. La prise en charge de wasip1 par Go est encore en version préliminaire. Zig n'y est pas encore. Cette contrainte limite à elle seule les studios capables ne serait-ce que de tenter un build serveur en WASM.

Le multithreading sans threads

Les serveurs de jeu ne sont pas des programmes à thread unique. La simulation physique, les E/S réseau, la réplication de l'état du jeu et le traitement des entrées des joueurs s'exécutent généralement de manière concurrente. Les moteurs sont conçus autour de ce postulat.

La prise en charge du multithreading par WebAssembly est limitée. Les mécanismes existants nécessitent des solutions de contournement au niveau de la couche applicative, utilisant des interruptions et un ordonnancement coopératif pour simuler une exécution concurrente. Le résultat n'équivaut pas à de véritables threads du système d'exploitation. Cela engendre des surcharges de coordination, complexifie le code et rend le débogage plus difficile sous forte charge.

Un studio qui contournerait les restrictions de sockets de WASI devrait encore régler la question du threading avant que son serveur de jeu ne puisse fonctionner correctement à grande échelle. Il ne s'agit pas de tâches d'intégration mineures, mais de lacunes architecturales fondamentales dans la spécification actuelle de WASM.

Même en résolvant tout cela : le mur des WebSockets

Supposons qu'une équipe consacre les efforts d'ingénierie nécessaires pour contourner les limitations de sockets de WASI et mette au point un modèle de threading robuste sous la charge.

Il subsiste encore un obstacle majeur : les WebSockets.

Les runtimes serveur WASM communiquent par défaut via WebSockets. Les WebSockets reposent sur TCP, ajoutant une couche de connexion persistante avec sa propre surcharge de poignée de main (handshake), de trame 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 prohibitif.

Les jeux utilisent UDP plutôt que TCP pour une bonne raison. UDP est léger et rapide, sans poignée de main, sans surcharge de livraison garantie et sans blocage en tête de ligne. Un paquet qui arrive en retard est simplement ignoré, ce qui est bien préférable à une connexion bloquée en attente de retransmission. Tout le pan du code réseau des jeux, de la compensation de lag au rollback, repose sur les propriétés d'UDP.

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

Compatibilité des plugins : la taxe (invisible) du portage

Au-delà des contraintes d'infrastructure, il existe un coût de développement pratique que les studios anticipent rarement. La plupart des packages de magasins d'assets, des plugins de moteur et des SDK tiers ne se compilent pas automatiquement vers WebAssembly. Ils ciblent des plateformes natives : Windows, Linux, macOS.

Leur portage exige un travail manuel. Le soutien de la communauté pour le développement de jeux sous WASM reste modeste comparé aux déploiements basés sur Docker. La documentation est rare, les tutoriels sont peu nombreux et les cas particuliers ont tendance à ne se révéler que lorsqu'une équipe est déjà bien avancée dans un projet.

Pour les studios ayant d'importantes dépendances de plugins ou pour les équipes ne disposant pas d'une solide expertise en programmation système, la seule charge de travail liée au portage peut rendre une approche de serveur WASM impraticable, indépendamment des gains d'efficacité théoriques.

La place réelle de WASM aujourd'hui : les jeux WebGL solo

Il existe un contexte où WASM contourne chacune des limitations mentionnées plus haut : 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 de l'OS. 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 posent aucun problème pour cet usage.

Godot en est une parfaite illustration. Le moteur exporte vers WebAssembly par défaut pour sa cible web. Un jeu Godot solo est distribué sous la forme d'un binaire de 35 Mo qui s'exécute dans n'importe quel navigateur moderne, sans aucune installation. Pour le déploiement sur serveur Linux, Godot exporte plutôt un binaire natif. Cette distinction n'est pas fortuite : elle reflète fidèlement les limites actuelles des capacités de WASM.

L'écosystème Rust et WebAssembly montre une réalité similaire. L'une des ressources d'apprentissage WASM les plus référencées est le livre officiel Rust and WebAssembly, qui guide la création du Jeu de la vie de Conway sous forme de projet WASM pour navigateur. C'est l'exemple canonique d'un fonctionnement réussi de la technologie. Il s'agit également d'une application solo, cantonnée au navigateur, sans aucune exigence de mise en réseau côté serveur.

WASM convient parfaitement aux jeux web solo. Les backends multijoueurs représentent un défi totalement différent.

Un avis éclairé : la courbe d'adoption

L'infrastructure pour faire tourner WASM en tant que technologie côté serveur existe déjà, du moins sous une forme expérimentale. Cloudflare Workers exécute des modules WASM en périphérie (edge). containerd/runwasi apporte la prise en charge des charges de travail WASI à containerd. KWasm ajoute la prise en charge de WebAssembly aux nœuds Kubernetes, bien que ses propres responsables déconseillent pour le moment de l'utiliser en production. Les outils se développent, méticuleusement.

Cette trajectoire rappelle la façon dont les nœuds ARM ont fait leur entrée dans le paysage de l'infrastructure cloud. ARM a offert de réels avantages en termes de coûts et de densité pendant des années avant de s'imposer comme un choix par défaut pour les charges de travail cloud. L'intérêt technique était évident dès le départ. L'adoption a pris du retard pour des raisons de maturité d'écosystème, de support des chaînes d'outils et d'inertie organisationnelle. Puis la tendance s'est inversée.

Déterminer si WASM suivra la même courbe pour les serveurs de jeu relève, précisons-le, de l'opinion plutôt que d'un modèle établi. Les limitations actuelles sont concrètes et documentées. Ce qui les fera évoluer, et à quel rythme, dépend des décisions des éditeurs de navigateurs, des mainteneurs de runtimes et des organismes de normalisation. Bogomolov conclut son article sur la même question ouverte : « Pourquoi l'adoption de WASM stagne-t-elle ? L'argument de la taille de transfert est pourtant déjà là. »

C'est une excellente question. 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 les serveurs de jeu en 2026. Docker reste le choix pragmatique pour les studios déployant des serveurs multijoueurs dédiés, et les outils opérationnels qui l'entourent sont matures, bien documentés 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 un réel impact sur les performances de démarrage à froid et les coûts de trafic sortant, et des mesures concrètes peuvent être prises par les studios avec les outils existants. Pour Unreal Engine, Edgegap a publié un guide sur l'analyse et l'optimisation des builds de serveurs de jeu par le profilage de serveur. Pour Unity, les conseils d'optimisation des builds serveur sont directement traités dans la documentation d'Edgegap.

Les gains que WASM pourrait un jour offrir sur le plan de la taille sont atteignables dès aujourd'hui avec les outils actuels, sans attendre la maturation de l'écosystème.

—

Cet article s'inspire d'une publication originale d'Ivan Bogomolov, parue sur son blog personnel. Tous les droits sur le contenu original appartiennent à leurs propriétaires respectifs.