WebGPU en 2026 : disponible partout, mais pas encore par défaut
WebGPU est l'API graphique qui succède à WebGL dans le navigateur. Elle donne à une page web un accès moderne à la carte graphique, pour le rendu comme pour le calcul. En octobre 2026, elle fonctionne dans les quatre grands navigateurs, mais la plupart des moteurs de jeu web restent sur WebGL 2 par défaut.
Pour un jeu par navigateur, la question n'est donc plus « le joueur a-t-il WebGPU ? ». C'est « que voit le joueur qui ne l'a pas ? ». Cet article fait le point sur le support réel et sur ce que WebGPU change pour l'image d'un jeu. Il montre aussi comment concevoir avec un repli.
Les versions citées viennent des sources officielles. Ce sont la page d'état du groupe de travail WebGPU, l'annonce de Google sur web.dev et la documentation de chaque moteur. Les blogs que nous avons croisés se contredisent sur les dates, nous ne les citons pas.
Quels navigateurs supportent WebGPU en 2026 ?
Le support navigateur par navigateur
WebGPU est activé par défaut dans Chrome, Edge, Safari et Firefox, avec des trous selon le système. La page d'état d'implémentation du groupe de travail WebGPU, mise à jour le 02/10/2026, donne le détail.
| Navigateur | Activé par défaut | Encore absent ou derrière un réglage |
|---|---|---|
| Chrome et Edge | Windows, macOS, ChromeOS depuis la version 113 ; Android 12+ depuis la 121 (selon la puce) | une partie de Linux, Windows sur ARM |
| Safari | macOS, iOS, iPadOS et visionOS depuis la version 26 | support marqué partiel sur macOS par Can I use |
| Firefox | Windows depuis la 141 ; macOS depuis la 145 (Apple Silicon) puis la 147 (tous les Mac) | Linux (Nightly seulement), Android |
L'annonce de Google, « WebGPU is now supported in major browsers », date du 25/11/2025. Elle marque le moment où les quatre moteurs de navigateur ont livré l'API en version stable.
Ce que ça représente en joueurs
Selon Can I use, consulté le 19/10/2026, environ 89 % des utilisateurs ont un navigateur qui supporte WebGPU, dont 3,7 % partiellement. Le site classe pourtant l'API en « disponibilité limitée » parmi les grands navigateurs. Il reste donc environ un visiteur sur dix sans WebGPU, en moyenne mondiale. Ce sont Firefox sous Linux et Android, une partie des téléphones Android et des systèmes trop anciens.
Pour un jeu par navigateur, ce dixième n'est pas négligeable. Le joueur passe souvent d'un appareil à l'autre. Notre guide UX du jeu par navigateur fait de la continuité entre ordinateur et mobile un critère de choix. Un rendu qui disparaît sur un des deux appareils casse cette continuité.
Les moteurs de jeu web : WebGL 2 reste la base
Ce que disent les documentations officielles
Le support navigateur ne suffit pas : le moteur du jeu doit aussi savoir parler WebGPU. En octobre 2026, la documentation officielle des moteurs donne une image plus prudente que celle des navigateurs.
- Unity 6.3 → WebGPU est « expérimental et non supporté par tous les navigateurs et appareils », selon sa documentation ; la cible web par défaut reste WebGL 2.
- Godot 4.7 → l'export web cible uniquement WebGL 2 ; Godot « ne supporte pas encore WebGPU », d'après sa documentation d'export.
- three.js → son WebGPURenderer utilise WebGPU quand le navigateur le permet et bascule seul sur WebGL 2 sinon.
- Babylon.js et PlayCanvas → cités par Google parmi les bibliothèques qui supportent déjà WebGPU.
Le repli automatique devient la norme
Le modèle de three.js résume la situation : un seul code, deux moteurs de rendu. Le jeu demande WebGPU, et retombe sur WebGL 2 si le navigateur ne le fournit pas. Le joueur sans WebGPU voit le jeu, simplement avec un rendu moins riche.
Pour l'équipe, c'est une décision de conception autant que technique. Il faut savoir ce que le rendu de repli doit absolument garder, et ce qu'il peut perdre.
Ce que WebGPU change pour l'image d'un jeu par navigateur
Plus d'objets à l'écran, à moindre coût
WebGPU réduit le coût de chaque ordre de dessin envoyé à la carte graphique. Google cite les Render Bundles, qui enregistrent une suite de commandes de rendu pour la rejouer. Le Snapshot Rendering de Babylon.js, construit sur ces bundles, peut selon Google rendre une scène « environ 10 fois plus vite ».
Pour un designer de jeu, cela se traduit en densité. Il y a plus d'unités sur une carte, plus de vaisseaux dans une flotte, plus de particules dans une explosion. Une carte galactique avec des milliers d'étoiles animées devient raisonnable dans un onglet.
Le calcul GPU ouvre d'autres effets
WebGPU ajoute un pipeline de calcul, absent de WebGL. La carte graphique peut alors faire des calculs qui ne sont pas du dessin. Elle simule des particules ou de la physique, génère un terrain, ou exécute un modèle d'IA dans le navigateur.
Un jeu de stratégie peut s'en servir pour animer un champ d'astéroïdes, faire couler une nébuleuse ou calculer un brouillard de guerre. Ce sont des effets d'ambiance qui servent la direction artistique, comme les remplissages par shader que Figma apporte désormais aux maquettes.
Ce qui ne change pas : l'interface reste en HTML
La plupart des jeux de stratégie par navigateur sont d'abord des interfaces : listes de bâtiments, files de production, rapports, messagerie. Ces écrans sont en HTML et CSS, et WebGPU ne les touche pas. Notre anatomie du genre OGame-like montre à quel point ce genre repose sur des tableaux et des menus.
WebGPU concerne donc les couches visuelles du jeu : la carte, la vue de planète, les combats animés. C'est là qu'il peut changer l'expérience, et nulle part ailleurs.
Concevoir l'image d'un jeu avec un repli WebGL 2
Définir un rendu de base qui tient seul
La règle la plus sûre est de concevoir d'abord le rendu WebGL 2, puis d'ajouter la couche WebGPU par-dessus. Le rendu de base doit porter toute l'information de jeu : positions, états, menaces, ressources. WebGPU n'ajoute que de l'ambiance et de la densité.
- Dans le rendu de base → tout ce qui sert une décision du joueur, lisible sans effet.
- Dans la couche WebGPU → particules, lumière dynamique, foule d'objets décoratifs, simulations.
- Jamais dans la seule couche WebGPU → une information de jeu, comme une flotte ennemie ou une ressource rare.
Tester sur les deux rendus, à chaque version
Un jeu avec repli a deux apparences, et les deux doivent être relues. Le plus simple est de forcer le rendu WebGL 2 sur un poste de test. three.js le permet avec une option dédiée. Firefox sous Linux fournit aussi un vrai navigateur sans WebGPU en 2026.
Les maquettes doivent suivre la même logique. Une capture de la seule version WebGPU promet une image qu'environ un visiteur sur dix ne verra pas.
Faut-il passer un jeu par navigateur à WebGPU en 2026 ?
Pour un jeu dont l'image compte (carte 3D, combats animés, effets de particules), oui, avec un repli WebGL 2. Le support couvre environ 89 % des utilisateurs. Les moteurs qui le gèrent le mieux basculent seuls sur WebGL 2 pour les autres.
Pour un jeu de gestion surtout fait de menus et de tableaux, l'enjeu est faible : l'interface reste en HTML. Dans les deux cas, la décision de design est la même. Ce qui sert à jouer doit tenir sans WebGPU, ce qui sert l'ambiance peut en profiter.
