Moteurs de jeux web en 2026 : PlayCanvas face à Three.js, Babylon.js et Unity WebGL
Par Oleg Sidorkin, directeur technique et cofondateur de Cinevva
Si vous souhaitez publier en 2026 un jeu 3D fonctionnant dans un navigateur, vous avez le choix entre quatre solutions grand public et quelques options plus récentes. On les regroupe sous l'appellation « moteurs de jeux web », mais ce sont en réalité des outils très différents, conçus pour résoudre 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 une équipe qui développe professionnellement un moteur 3D web et qui a évalué toutes ces solutions avant de créer le sien.
Nous allons examiner chaque option, ce qu'elle est réellement, à qui elle s'adresse et quelles sont ses limites, puis vous proposer un petit guide de décision à la fin. Les numéros de version mentionnés sont exacts en juillet 2026.
Vous cherchez un panorama complet ? Cet article se concentre sur les quatre principales solutions 3D. Pour découvrir les 11 moteurs web classés et comparés, 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 | |
|---|---|---|---|---|---|
| Type de solution | Moteur complet + éditeur hébergé | Bibliothèque de rendu | Moteur complet + éditeur | Moteur de bureau, export web | Plateforme de mondes native pour l'IA |
| Architecture | Entité-composant (ECS) | Graphe de scène | Graphe de scène + composants | GameObject/composant | Graphe de scène + créateur IA |
| Scripts | TypeScript / JavaScript | JavaScript (à vous de créer le reste) | TypeScript / JavaScript | C# (compilé en Wasm) | Langage naturel + code |
| Moteur de rendu | WebGL2, WebGPU en cours de maturation | WebGL2, WebGPU en progression | WebGL2, WebGPU avancé | WebGL2 (export) | WebGPU uniquement |
| Éditeur | Hébergé, commercial | Aucun | Web, gratuit | Bureau, commercial | Immersif, au sein du monde |
| Physique | Ammo / intégrations | À fournir | 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 de navigateur produits comme en studio | 3D personnalisée, contrôle total | Jeux avec tout le nécessaire intégré | Portage de jeux Unity existants | Création de jeux dans le monde par IA |
La suite de cet article explique ce tableau.
PlayCanvas
PlayCanvas est ce qui se rapproche le plus, sur le web, d'un flux de travail à la Unity. Le moteur est open source sous licence MIT et se trouve à la version 2.20.6 en juillet 2026. Il repose sur un système entité-composant, la logique du jeu s'écrit en TypeScript ou en JavaScript, et les ressources passent par une chaîne de traitement côté serveur qui produit des fichiers GLB. De véritables jeux commerciaux l'utilisent, tout comme de grandes entreprises en production, Snap étant un exemple public.
Deux idées reçues sur PlayCanvas méritent d'être corrigées. Premièrement, bien que le moteur soit 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 flux de travail associant éditeur et cloud est payant. Deuxièmement, PlayCanvas privilégie WebGL2. Il propose une voie 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 est véritablement en tête est le Gaussian splatting 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 vous souhaitez créer des environnements photoréalistes numérisés, c'est une vraie raison de commencer ici.
Choisissez PlayCanvas si vous voulez un éditeur semblable à Unity et une chaîne de traitement gérée des ressources pour le navigateur, et si vous produisez le type de jeu que créerait un studio. Cherchez ailleurs si vous avez besoin des fonctions de calcul WebGPU dès aujourd'hui ou si vous souhaitez é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 très 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 physique, ni système d'entités, ni opinion imposée sur la manière de structurer un jeu. À vous de les ajouter ou de les trouver dans l'écosystème.
Ce compromis résume toute la proposition. Vous bénéficiez d'un contrôle maximal et de 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 déjà être utilisé, 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 souhaitez un contrôle total et une base minimale, et si vous 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 intègre les éléments que vous devriez autrement assembler vous-même : un modèle de composants, le moteur physique Havok, un éditeur web gratuit et une chaîne de traitement des ressources. Ses travaux sur WebGPU ont progressé rapidement et figurent parmi les plus avancés des moteurs généralistes, même s'il conserve WebGL2 comme voie offrant la compatibilité la plus large. Babylon.js 9.0, sorti en mars 2026, a encore renforcé cette avance avec un éclairage groupé sur les deux backends, un éclairage volumétrique reposant 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 souhaitez une solution prête à l'emploi, avec la physique intégrée et un éditeur gratuit. Cherchez ailleurs si vous voulez une dépendance très légère ou recherchez spécifiquement un flux de travail hébergé comparable à 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 bundle WebGL qui s'exécute dans le navigateur grâce à WebAssembly. C'est donc la réponse évidente dans un cas précis : vous avez déjà un jeu Unity et souhaitez en créer une version pour navigateur.
Pour un projet pensé d'abord pour le web, cette solution entraîne de véritables coûts. Le poids du runtime et du téléchargement est important, le démarrage est plus lent qu'avec un moteur web natif, et les performances dans les navigateurs mobiles constituent un problème connu. Unity est propriétaire et sa sortie WebGL cible WebGL2. Unity 6 propose un backend WebGPU expérimental, mais celui-ci est désactivé par défaut et n'est pas prêt pour la production.
Choisissez Unity WebGL si vous avez un projet Unity existant à porter vers le navigateur ou si votre équipe travaille déjà entièrement dans Unity. Cherchez ailleurs si le chargement instantané sur des téléphones de milieu de gamme est une exigence absolue, ou si vous partez de zéro avec une approche web-first.
La place de la création native pour l'IA et intégrée au monde
Toutes les solutions ci-dessus partagent une même hypothèse : un développeur construit le jeu à son bureau, dans un éditeur, puis publie un runtime. Cette hypothèse est correcte pour la plupart des projets et, si elle correspond au vôtre, choisissez l'une des quatre options précédentes.
Il faut néanmoins savoir que ce n'est plus la seule possibilité, car une catégorie différente est en train d'émerger. 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 souhaitez, puis un créateur IA transforme votre demande en terrain, en objets et en comportements pendant que vous êtes sur place. La création et le jeu ont lieu au cours de la même session. Sous le capot, cela nous a conduits à adopter exclusivement WebGPU avec un terrain reposant sur des shaders de calcul, à écrire un solveur de personnage personnalisé plutôt qu'un moteur physique généraliste, et à développer un système d'animation et de reciblage. Nous détaillons ces choix dans notre article expliquant pourquoi nous avons créé notre propre moteur WebGPU.
Cinevva ne remplace ni PlayCanvas ni Babylon. Si vous êtes développeur et créez un jeu précis, ces outils sont adaptés. Cinevva répond à un objectif différent : permettre aux personnes qui ne développent pas de moteurs de créer et de partager des espaces jouables simplement en les décrivant. Nous le mentionnons ici parce que la question « quel moteur de jeu web devrais-je utiliser ? » admet de plus en plus une cinquième réponse qui n'est pas du tout un moteur.
Matrice complète des fonctionnalités
Le tableau rapide ci-dessus en donne les grandes lignes. Voici la version détaillée, regroupée par sous-système. Quelques précisions utiles pour bien la lire : « À fournir » signifie que le moteur n'intègre pas la fonctionnalité, mais que l'écosystème ou votre propre code peut l'ajouter. Cela concerne particulièrement Three.js, qui est délibérément une bibliothèque de rendu : dans son cas, « À fournir » relève 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 incluse dans la version WebGL, plutôt que d'être native au web. Les cellules des solutions concurrentes reflètent leurs capacités prêtes à l'emploi et leur comportement bien documenté à la mi-2026. Les cellules de Cinevva correspondent à ce qui fonctionne dans notre version publiée, tandis que la mention « prévu » désigne 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 (WebGPU en progression) | WebGL2 (WebGPU avancé) | WebGL2 (export) |
| Shaders de calcul en production | Oui (dépendance centrale) | Bêta | Via WebGPU | Oui (WebGPU) | Export uniquement, limité |
| 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 Gaussian splatting 3D | Prévus | Oui (SuperSplat, référence du secteur) | Communauté | Oui | Extensions |
Monde et terrain
| Fonctionnalité | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Streaming intégré des grands mondes | Oui (chunks 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 |
| Fondu / machine à états | Oui (FSM de résolution) | Oui (graphe d'états d'animation) | Mixeur (fondu à fournir) | Oui | Oui (Mecanim) |
| Reciblage de squelette | Oui (pipeline) | Limité | Communauté | Partiel | Oui (humanoïde) |
| Cinématique inverse | Prévue | Limitée | Communauté | Oui | Oui |
Multijoueur et backend
| Fonctionnalité | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Multijoueur intégré | Oui (autorité à la périphérie) | À fournir (Photon/Colyseus) | À fournir | À fournir | À fournir (Netcode, non natif pour le web) |
| Monde partagé persistant | Oui (Durable Objects par chunk) | À 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, au sein du monde | Hébergé, de type logiciel de bureau (commercial) | Aucun (minimal) | Web (gratuit) | Bureau (commercial) |
| Création incarnée dans le monde | Oui | Non | Non | Non | Non |
| Création en langage naturel / par IA | Oui (créateur 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 |
|---|---|---|---|---|---|
| Chaîne de traitement des 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 MIT, éditeur propriétaire | MIT | Apache 2.0 | Propriétaire |
La tendance qui se dégage de cette matrice est le véritable enseignement. Les moteurs généralistes répartissent leurs atouts horizontalement : chacun couvre correctement la plupart des besoins, tout en vous laissant gérer le monde, le backend et le processus de création. Cinevva concentre ses capacités verticalement : la plateforme couvre moins de domaines, mais maîtrise 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 questions différentes.
Comment choisir
Choisissez l'outil en fonction de votre situation plutôt qu'à partir d'une simple liste de fonctionnalités. Si vous avez déjà un jeu Unity, exportez-le avec Unity WebGL et acceptez son poids. Si vous êtes un studio qui souhaite un workflow basé sur un éditeur pour créer des jeux sur navigateur, utilisez PlayCanvas. Si vous voulez un moteur complet et gratuit avec la physique incluse, utilisez Babylon.js. Si vous voulez un contrôle total et disposez de l’équipe nécessaire pour construire votre jeu à partir d’un moteur de rendu minimal, utilisez Three.js. Et 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 la catégorie dans laquelle nous travaillons, et vous pouvez essayer Cinevva.
Quel que soit votre choix, réalisez des prototypes concrets pour l’évaluer avant de vous engager. Chacune de ces solutions peut prendre en charge un véritable jeu, et changer de technologie à mi-parcours vous coûtera des mois que vous n’aurez pas consacrés à publier votre jeu.