Moteurs de jeux web en 2026 : PlayCanvas face à Three.js, Babylon.js et Unity WebGL
Par Oleg Sidorkin, CTO et cofondateur de Cinevva
Si vous voulez publier en 2026 un jeu 3D fonctionnant dans un navigateur, vous avez quatre options grand public et quelques solutions plus récentes. Elles sont souvent regroupées sous l’appellation « moteurs de jeux web », mais il s’agit réellement d’outils différents qui répondent à des problèmes différents. Un mauvais choix peut vous coûter des mois. Voici une comparaison actuelle et vérifiée, rédigée par des personnes qui développent professionnellement un moteur 3D web et qui ont évalué toutes ces solutions avant de créer le leur.
Nous allons examiner chaque option, ce qu’elle est réellement, à qui elle s’adresse et quelles sont ses limites, puis vous proposer un guide de décision rapide à la fin. Les numéros de version mentionnés sont exacts en septembre 2026 (moteur PlayCanvas 2.22, Three.js r185, Babylon.js 9.25, Unity 6.6).
Vous cherchez une vue d’ensemble complète ? Cet article se concentre sur les quatre principales solutions 3D. Pour découvrir un classement et une comparaison des 11 moteurs web, y compris des options 2D comme Phaser, Defold et Construct, consultez notre guide des meilleurs moteurs de jeux web pour 2026.
Comparaison rapide
| PlayCanvas | Three.js | Babylon.js | Unity WebGL | Cinevva | |
|---|---|---|---|---|---|
| Nature de l’outil | Moteur complet + éditeur hébergé | Bibliothèque de rendu | Moteur complet + éditeur | Moteur de bureau, export web | Plateforme de mondes conçue autour de l’IA |
| Architecture | Entité-composant (ECS) | Graphe de scène | Graphe de scène + composants | GameObject/composant | Graphe de scène + constructeur IA |
| Scripts | TypeScript / JavaScript | JavaScript (vous construisez le reste) | TypeScript / JavaScript | C# (compilé en Wasm) | Langage naturel + code |
| Moteur de rendu | WebGL2, WebGPU en cours de maturation | WebGL2, prise en charge croissante de WebGPU | WebGL2, prise en charge avancée de WebGPU | WebGL2 (export), WebGPU pris en charge depuis la 6.6 (facultatif) | WebGPU uniquement |
| Éditeur | Hébergé, commercial | Aucun | Web, gratuit | Application de bureau, commerciale | Immersif, intégré au monde |
| Physique | Ammo / intégrations | À fournir vous-même | Havok intégré | Intégrée (PhysX) | Solveur de personnage personnalisé |
| Licence | Moteur MIT, éditeur propriétaire | MIT | Apache 2.0 | Propriétaire | Propriétaire |
| Idéal pour | Jeux sur navigateur développés comme en studio | 3D personnalisée, contrôle total | Jeux avec toutes les fonctionnalités intégrées | Portage de jeux Unity existants | Création de jeux dans le monde avec l’IA |
La suite de cet article explique ce tableau.
PlayCanvas
PlayCanvas est ce qui se rapproche le plus, sur le web, d’un processus de travail à la Unity. Le moteur est open source sous licence MIT et en est à la version 2.22.0 en septembre 2026. La version 2.21 a ajouté une abstraction du moteur physique et les cubemaps KTX2, tandis que la 2.22 a introduit le mélange à double source et amélioré le brouillard volumétrique. PlayCanvas utilise un système entité-composant, la logique du jeu s’écrit en TypeScript ou JavaScript et les ressources passent par une chaîne de traitement côté serveur qui produit des fichiers GLB. De vrais jeux commerciaux l’utilisent, tout comme de grandes entreprises en production, Snap étant un exemple public.
Deux idées reçues à propos de PlayCanvas méritent d’être corrigées. Premièrement, si le moteur est sous licence MIT, l’éditeur visuel hébergé qu’utilisent réellement la plupart des équipes est un produit commercial, et non open source. Vous pouvez utiliser librement le moteur sans cet éditeur, mais le processus associant l’éditeur et le cloud est payant. Deuxièmement, PlayCanvas privilégie WebGL2. Il dispose d’une voie de rendu WebGPU, mais celle-ci est encore en cours de maturation et ne constitue pas le moteur de rendu par défaut. Ne choisissez donc pas PlayCanvas aujourd’hui en espérant utiliser des shaders de calcul WebGPU en production.
Le domaine dans lequel PlayCanvas se distingue réellement est le splatting gaussien 3D. Son éditeur et sa visionneuse SuperSplat, que l’équipe a publiés en open source, comptent parmi les meilleurs outils disponibles pour capturer et diffuser des scènes de splats sur le web, avec une diffusion en continu basée sur WebGPU pour les captures volumineuses. Si les environnements numérisés photoréalistes vous intéressent, c’est une véritable raison de commencer ici.
Choisissez PlayCanvas si vous voulez un éditeur semblable à celui de Unity et une chaîne de ressources gérée pour le navigateur, et si vous développez le type de jeu que produirait un studio. Cherchez ailleurs si vous avez besoin dès aujourd’hui du calcul WebGPU ou si vous voulez éviter un éditeur commercial hébergé.
Three.js
Three.js n’est pas un moteur de jeu. C’est une bibliothèque de rendu, et de loin la plus utilisée dans ce domaine. Elle fournit un graphe de scène, des caméras, des lumières, des matériaux, de la géométrie, des chargeurs et un moteur de rendu, puis s’arrête là. Il n’y a ni éditeur, ni moteur physique, ni système d’entités, ni conventions imposées pour structurer un jeu. Vous devez ajouter ces éléments vous-même ou les récupérer dans l’écosystème.
Ce compromis résume toute la proposition. Vous obtenez un contrôle maximal et la plus grande communauté de la 3D web, au prix de devoir créer ou assembler tout ce qui se trouve au-dessus du moteur de rendu. Son moteur de rendu WebGPU progresse régulièrement et peut être utilisé aujourd’hui (r185, publiée en juillet 2026, est la version actuelle), même si, comme pour les autres solutions, la voie WebGL2 reste l’option mature par défaut. Three.js est sous licence MIT.
Choisissez Three.js si vous voulez un contrôle total, une base minimale et disposez des compétences techniques nécessaires pour construire vos systèmes de jeu par-dessus. Cherchez ailleurs si vous voulez disposer immédiatement d’un éditeur et de systèmes de jeu.
Babylon.js
Babylon.js est un moteur complet sous licence Apache 2.0, soutenu par une équipe de Microsoft. Contrairement à Three.js, il inclut les éléments que vous devriez autrement assembler vous-même : un modèle de composants, le moteur physique Havok intégré, un éditeur web gratuit et une chaîne de gestion des ressources. Son travail sur WebGPU a progressé rapidement et figure parmi les plus avancés des moteurs généralistes, même s’il conserve WebGL2 comme voie assurant la compatibilité la plus large. Babylon.js 9.0 (mars 2026, désormais en version 9.25 en septembre 2026) a encore renforcé cette avance avec un éclairage groupé sur les deux moteurs de rendu, un éclairage volumétrique basé sur des shaders de calcul WebGPU et la prise en charge des ombres pour les splats gaussiens 3D.
Si votre raisonnement est « je veux un moteur complet, avec la physique incluse, et ses conventions me conviennent », Babylon constitue un excellent choix par défaut et probablement l’option gratuite la plus complète du secteur.
Choisissez Babylon.js si vous voulez une solution prête à l’emploi, un moteur physique intégré et un éditeur gratuit. Cherchez ailleurs si vous voulez une dépendance très légère ou si vous recherchez spécifiquement un processus hébergé semblable à celui de Unity.
Unity WebGL
Unity WebGL n’est pas un moteur web, mais une cible d’exportation. Vous développez dans l’éditeur de bureau Unity, en C#, puis compilez votre projet en un paquet WebGL exécuté dans le navigateur par l’intermédiaire de WebAssembly. Il s’agit donc de la réponse évidente dans un cas bien précis : vous possédez déjà un jeu Unity et vous voulez en créer une version pour navigateur.
Pour un projet pensé d’abord pour le web, cette solution entraîne des coûts réels. L’environnement d’exécution et les téléchargements sont lourds, le démarrage est plus lent qu’avec un moteur web natif et les performances sur les navigateurs mobiles constituent un problème bien connu. Unity est propriétaire et sa sortie web cible WebGL2 par défaut. Le backend WebGPU, initialement expérimental dans Unity 6, a quitté ce statut avec Unity 6.6 (août 2026) : il s’agit désormais d’une API graphique entièrement prise en charge pour les builds web, toujours désactivée par défaut, avec un paramètre Graphics Device Filtering qui permet de revenir à WebGL2 selon l’appareil. Unity 6.6 porte également la limite de mémoire Wasm à 16 Go. Cela comble sur le papier l’écart relatif aux shaders de calcul, mais ne change rien au poids des téléchargements ni au temps de démarrage sur mobile.
Choisissez Unity WebGL si vous disposez déjà d’un projet Unity à porter vers le navigateur ou si votre équipe travaille déjà entièrement avec Unity. Cherchez ailleurs si un chargement instantané sur les téléphones de milieu de gamme est indispensable, ou si vous partez de zéro avec une approche centrée sur le web.
La place de la création dans le monde et conçue autour de l’IA
Toutes les solutions ci-dessus reposent sur la même hypothèse : un développeur crée le jeu à son bureau, dans un éditeur, puis publie un environnement d’exécution. Cette hypothèse est valable pour la plupart des projets et, si elle correspond au vôtre, choisissez l’une des quatre solutions précédentes.
Il faut toutefois savoir que ce n’est plus la seule possibilité, car une autre catégorie est en train d’apparaître. Nous développons Cinevva, une plateforme de mondes exclusivement basée sur WebGPU dans laquelle les jeux sont créés depuis l’intérieur même du monde. Au lieu d’ouvrir un éditeur, vous incarnez un avatar présent dans l’espace, vous décrivez ce que vous voulez, puis un constructeur IA transforme votre demande en terrain, objets et comportements sous vos yeux. La création et le jeu se déroulent au cours de la même session. Sur le plan technique, cela nous a conduits à utiliser exclusivement WebGPU avec un terrain généré par shaders de calcul, à écrire un solveur de personnage personnalisé plutôt qu’un moteur physique généraliste, et à créer un système d’animation et de reciblage. Nous en parlons dans notre article expliquant pourquoi nous avons créé notre propre moteur WebGPU.
Cinevva ne remplace pas PlayCanvas ou Babylon. Si vous êtes un développeur qui crée un jeu précis, ces outils sont les bons. Cinevva poursuit un autre objectif : permettre aux personnes qui ne développent pas de moteurs de créer et de partager des espaces jouables en les décrivant. Nous le mentionnons ici parce que la question « quel moteur de jeu web dois-je utiliser ? » admet de plus en plus souvent une cinquième réponse qui n’est pas du tout un moteur.
Matrice complète des fonctionnalités
Le tableau rapide ci-dessus présente l’essentiel. Voici la version détaillée, organisée par sous-système. Quelques précisions sont nécessaires pour bien la lire. « À fournir » signifie que vous devez apporter votre propre solution : le moteur ne l’inclut pas, mais l’écosystème ou votre propre code peut l’ajouter. Cela concerne surtout Three.js, qui est délibérément une bibliothèque de rendu. Dans son cas, « À fournir » relève donc de sa philosophie plutôt que d’une lacune. Pour Unity, « Export uniquement » signifie que la fonctionnalité existe dans l’éditeur de bureau et est intégrée au build WebGL, plutôt que d’être native au web. Les cellules relatives aux concurrents reflètent leurs capacités prêtes à l’emploi et leur comportement bien documenté en septembre 2026. Les cellules de Cinevva décrivent ce qui fonctionne dans notre version publiée, la mention « prévu » indiquant ce qui est conçu mais pas encore développé.
Rendu
| Fonctionnalité | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Moteur de rendu principal | WebGPU uniquement | WebGL2 (WebGPU en bêta) | WebGL2 (prise en charge croissante de WebGPU) | WebGL2 (WebGPU avancé) | WebGL2 (WebGPU pris en charge depuis la 6.6, facultatif) |
| Shaders de calcul en production | Oui (dépendance fondamentale) | Bêta | Via WebGPU | Oui (WebGPU) | Oui (WebGPU, Unity 6.6+) |
| Création de shaders | Nœuds TSL + calcul | Fragments de shaders / GLSL | GLSL + nœuds (TSL) | Matériau nodal / GLSL / WGSL | ShaderLab / HLSL |
| Éclairage groupé / forward+ | Oui (froxel) | Oui | À fournir | Oui | Oui |
| Nuages volumétriques et météo | Oui | À fournir | À fournir | Partiel | À fournir |
| Outils de splatting gaussien 3D | Prévu | Oui (SuperSplat, référence du secteur) | Communauté | Oui | Extensions |
Monde et terrain
| Fonctionnalité | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Diffusion intégrée des grands mondes | Oui (blocs de 64 m) | À fournir | À fournir | À fournir | Export uniquement |
| Système de terrain | Carte de hauteur hybride + marching cubes/SDF | À fournir | À fournir | Extension | Intégré (bureau) |
| Sculpture du terrain à l’exécution | Oui (GPU) | À fournir | À fournir | À fournir | Non (pendant l’édition) |
| Grottes et surplombs (véritable topologie 3D) | Oui (marching cubes) | À fournir | À fournir | À fournir | À fournir |
| Feuillage et herbe instanciés par GPU | Oui | Oui | À fournir | Oui | Oui |
Physique et personnage
| Fonctionnalité | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Moteur physique | Solveur cinématique personnalisé | Intégration d’Ammo | À fournir (Rapier/Cannon/Ammo) | Havok intégré | PhysX intégré |
| Dynamique des corps rigides | Non (par conception) | Oui | À fournir | Oui | Oui |
| Contrôleur de personnage | Oui (FSM multimode) | Modèles / Ammo | À fournir | Oui | Intégré |
| Collision intégrée au terrain (SDF) | Oui | Non | À fournir | Non | Non |
Animation
| Fonctionnalité | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Animation squelettique | Oui | Oui | Oui | Oui | Oui |
| Mélange / machine à états | Oui (FSM de résolution) | Oui (graphe d’états d’animation) | Mixer (mélange à fournir) | Oui | Oui (Mecanim) |
| Reciblage de squelette | Oui (chaîne de traitement) | Limité | Communauté | Partiel | Oui (humanoïde) |
| Cinématique inverse | Prévu | Limitée | Communauté | Oui | Oui |
Multijoueur et backend
| Fonctionnalité | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Multijoueur intégré | Oui (autorité en périphérie du réseau) | À fournir (Photon/Colyseus) | À fournir | À fournir | À fournir (Netcode, non natif pour le web) |
| Monde partagé persistant | Oui (Durable Objects par bloc) | À fournir | À fournir | À fournir | À fournir |
| Chat vocal spatial | Oui (WebRTC + HRTF) | À fournir | À fournir | À fournir | À fournir |
Création et conception
| Fonctionnalité | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Éditeur | Immersif, intégré au monde | Hébergé, semblable à une application de bureau (commercial) | Aucun (minimal) | Web (gratuit) | Application de bureau (commerciale) |
| Création incarnée dans le monde | Oui | Non | Non | Non | Non |
| Création en langage naturel / par IA | Oui (constructeur IA) | Non | Non | Non | Non |
| Scripts | Langage naturel + JS | TypeScript / JS | JavaScript | TypeScript / JS | C# |
Ressources et distribution
| Fonctionnalité | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Pipeline de ressources côté serveur | Oui (GLB + LOD + KTX2 + Draco) | Oui (GLB) | Chargeurs uniquement | Outils d’importation | Oui |
| Génération de ressources par IA intégrée | Oui (3D, image, audio, musique) | Non | Non | Non | Non |
| Recherche fédérée de ressources | Oui (onze fournisseurs) | Boutique de ressources | Non | Non | Boutique de ressources |
| Fonctionne dans le navigateur, sans installation | Oui | Oui | Oui | Oui | Oui (lourd) |
| Licence du moteur | Plateforme propriétaire | Moteur sous licence MIT, éditeur propriétaire | MIT | Apache 2.0 | Propriétaire |
La tendance qui se dégage de ce tableau est le véritable enseignement. Les moteurs généralistes étendent leurs capacités horizontalement : chacun accomplit correctement la plupart des tâches, mais vous laisse gérer le monde, le backend et le processus de création. Cinevva se concentre verticalement : il fait moins de choses, mais prend en charge l’ensemble du parcours, du moteur de rendu jusqu’au monde partagé que vous créez de l’intérieur. Aucune de ces approches n’est intrinsèquement meilleure. Elles répondent à des besoins différents.
Comment choisir
Choisissez l’outil en fonction de votre situation plutôt qu’à partir d’une liste de fonctionnalités.
Si vous possédez déjà un jeu Unity, exportez-le avec Unity WebGL et acceptez son poids. Si vous êtes un studio à la recherche d’un workflow piloté par un éditeur pour créer des jeux web, utilisez PlayCanvas. Si vous voulez un moteur complet et gratuit avec la physique intégrée, utilisez Babylon.js. Si vous souhaitez un contrôle total et disposez de l’équipe nécessaire pour construire votre jeu à partir d’un simple moteur de rendu, utilisez Three.js. Enfin, si votre objectif n’est pas de créer un seul jeu, mais de permettre aux utilisateurs de créer et de jouer dans un monde partagé en décrivant ce qu’ils souhaitent, c’est précisément le domaine dans lequel nous travaillons, et vous pouvez essayer Cinevva.
Quel que soit votre choix, réalisez des prototypes concrets avant de vous engager. Chacun de ces outils peut faire tourner un véritable jeu, et changer de technologie en cours de route vous coûtera des mois que vous n’aurez pas consacrés à sa publication.
Questions fréquentes
PlayCanvas ou Babylon.js : lequel choisir ?
Choisissez PlayCanvas si vous voulez un éditeur hébergé de type Unity et un pipeline de ressources, et si le fait que l’éditeur soit un produit commercial vous convient (gratuit pour les projets publics, payant pour les projets privés). Choisissez Babylon.js si vous voulez une solution entièrement gratuite et ouverte (Apache 2.0), avec la physique Havok intégrée et le rendu WebGPU le plus avancé des deux. Ces deux moteurs sont proposés sous licence MIT ou Apache et prennent tous deux en charge WebGL2, avec WebGPU en complément. Notre comparatif des moteurs de jeux web les évalue selon la taille des builds et le temps de chargement, tandis que Three.js ou Babylon.js examine la différence entre bibliothèque et moteur.
PlayCanvas ou Unity pour les jeux web ?
Pour un jeu pensé d’abord pour le web, choisissez PlayCanvas : son runtime pèse entre 1 et 2 Mo, contre plus de 8 Mo pour un build Unity vide, il démarre plus rapidement sur les téléphones et son éditeur fonctionne déjà dans le navigateur. Unity l’emporte si vous disposez d’un projet Unity existant ou d’une équipe maîtrisant C#, et Unity 6.6 a réduit l’écart en matière de rendu en faisant de WebGPU une cible web officiellement prise en charge. Les comparatifs des deux aboutissent généralement à la même conclusion : PlayCanvas pour une diffusion nativement adaptée au navigateur, Unity pour son écosystème. Consultez Unity, Godot ou PlayCanvas pour le web pour un comparatif à trois.
Three.js ou Unity pour les jeux sur navigateur ?
Il s’agit de deux types d’outils différents. Three.js est une bibliothèque de rendu de 150 Ko sous licence MIT : elle permet donc d’obtenir les builds les plus légers et un contrôle total, mais vous devez créer vous-même les systèmes du jeu (ou utiliser un moteur qui repose dessus, comme Cinevva). Unity est un moteur complet exporté vers le navigateur : vous bénéficiez donc immédiatement de la physique, de l’animation et d’un éditeur, au prix d’un téléchargement volumineux et d’un démarrage plus lent sur mobile. Partez de Three.js si le jeu est pensé d’abord pour le web et que vous disposez d’ingénieurs. Partez de Unity si le jeu existe déjà sous Unity. Le guide comparatif complet présente les chiffres.