WebGPU : quels jeux mobiles lancer en web-native

Réponse directe — quels jeux mobiles lancer en web-native maintenant que WebGPU est partout ? WebGPU est pris en charge par environ 84 % de l’usage navigateur suivi et, depuis Safari 26, il est activé par défaut sur iOS, iPadOS et macOS — le dernier vrai trou dans la raquette est comblé. Mais la capacité GPU n’est plus la contrainte bloquante pour la distribution mobile web-native : ce sont désormais la taille du téléchargement initial, la disponibilité des threads et la couverture GPU sur Android qui le sont. Lancez en web-native dès maintenant le hyper-casual, le puzzle, l’idle/merge, les jeux de cartes, le multijoueur temps réel façon .io et le 3D stylisé en session courte — des titres qui peuvent tenir sous 20 Mo de téléchargement initial et tourner sur un seul thread. Retenez le mid-core en session longue, le 3D open-world et tout ce qui dépend d’une physique multithread ou d’un client de confiance, car les backends WebGPU des moteurs que la plupart des studios utilisent réellement restent étiquetés expérimentaux.

Le discours autour du web-native a changé de ton ces dix-huit derniers mois, et une bonne partie de ce ton se trompe d’une manière bien précise. « WebGPU est là, donc le mid-core peut désormais sortir sur le web » n’est pas ce que disent les données. Ce qu’elles disent est plus étroit et plus utile : le plafond graphique a monté, tandis que le plafond de livraison a à peine bougé. Si vous construisez un canal web-native autour du premier fait en ignorant le second, vous allez livrer un titre magnifique au rendu… que personne ne joue jamais, parce qu’il ne finit jamais de se télécharger.

Cet article est un guide de décision, pas un article de tendance. Pour la vue canal — portails, CPM, médiation publicitaire, séquence de lancement en 12 semaines — direction notre guide de distribution web-native, et les conditions de revenu propres à chaque surface sont détaillées dans notre guide de monétisation HTML5. Ici, la question est de savoir si le format technique de votre titre survit au contact du navigateur.

Ce que WebGPU a vraiment changé — et ce qu’il n’a pas changé

L’état des lieux de la standardisation et du déploiement, en juillet 2026 :

• La spécification WebGPU est un W3C Candidate Recommendation Draft daté du 14 juillet 2026 — assez stable pour développer dessus, mais encore formellement pré-Recommendation.
• Chrome a déployé WebGPU sur Mac, Windows, ChromeOS et, point critique pour le mobile, sur Android 12+ avec les GPU ARM, Qualcomm et Intel depuis Chrome 121, selon le wiki de statut d’implémentation gpuweb.
• WebKit a déployé WebGPU dans Safari 26.0 pour macOS, iOS, iPadOS et visionOS, activé par défaut. C’est l’événement qui a changé la donne : Safari iOS était la dernière surface majeure à ne pas l’avoir.
• Firefox l’a déployé sur Windows (141+) et macOS (147+) ; Firefox sur Android reste désactivé par défaut, Mozilla prévoyant de travailler sur Android courant 2026.
• Samsung Internet le prend en charge à partir de la version 24.
• caniuse.com affiche un total de 82,17 % de support complet plus 1,46 % de support partiel — environ 84 % de l’usage navigateur mondial suivi.

Jusqu’ici, tout va bien. Voici ce qui n’a pas changé.

Les gains de performance phares mis en avant pour WebGPU proviennent surtout de patterns que les scènes de gameplay n’ont pas. Le snapshot rendering de Babylon.js en est l’exemple le plus clair. La documentation du moteur indique elle-même que les gains de perf « peuvent être très importants, surtout en mode fast SR » — et précise sur la même page que « la scène doit rester globalement statique pour que ce mode fonctionne comme prévu », qu’ajouter ou retirer des meshes ne fonctionne pas, et qu’en mode fast, même animer une lumière casse le snapshot. C’est une optimisation formidable pour un configurateur de produit. Ce n’est pas quelque chose sur quoi peut s’appuyer un match-3 avec un plateau qui spawn en continu, ou un shooter avec des ennemis en pool. Lisez les benchmarks de démos WebGPU avec ce filtre en tête.

Le support moteur est réel, mais pas activé par défaut en production. Le manuel officiel de la ligne Unity 6.3 LTS indique encore clairement que WebGPU est expérimental et « non pris en charge par tous les navigateurs et appareils ». PlayCanvas dispose sans doute du moteur de rendu WebGPU le plus mature parmi les moteurs web, mais il a été livré en bêta opt-in, avec pour plan annoncé qu’« une fois que nous serons satisfaits de la maturité du support WebGPU, il deviendra la valeur par défaut » — et deux ans plus tard, ce n’est toujours pas le cas. L’export web de Godot est réellement utilisable, mais les compute shaders et le renderer Forward+ ne sont pas sur la table dans le navigateur.

En clair : WebGPU est une couche d’optimisation en option, au-dessus d’une base WebGL 2 que vous devez livrer de toute façon. Tout plan produit qui traite WebGPU comme un plancher plutôt que comme un plafond est mal calibré. C’est aussi pourquoi, au sein de notre practice interactive, nous traitons le web-native comme une décision d’ingénierie avant d’être une décision de canal — l’économie du canal ne compte qu’une fois que le build a passé les portes de livraison ci-dessous.

Les trois contraintes qui déterminent vraiment la compatibilité web-native

1. Le budget de téléchargement initial — le vrai garde-barrière

Les portails ne négocient pas là-dessus, et les chiffres sont publics.

Surface	Téléchargement initial	Autres limites strictes
Poki	Objectif sous 8 Mo	Canvas 16:9, mise à l’échelle vers 640×360 / 836×470 / 1031×580
CrazyGames (général)	≤ 50 Mo	Total des fichiers ≤ 250 Mo, 1 500 fichiers max
CrazyGames (éligibilité page d’accueil mobile)	≤ 20 Mo	Temps pour atteindre le gameplay ≤ 20 secondes

Sources : prérequis Poki, prérequis techniques CrazyGames.

Ce seuil de 20 Mo pour la page d’accueil mobile chez CrazyGames est le chiffre le plus utile de toute la planification web-native, car c’est là que se joue réellement le placement en découverte. WebGPU n’y change rien. Votre heap WASM, vos atlas de textures et votre banque audio pèsent le même poids quelle que soit l’API graphique à laquelle vous vous liez.

2. Les threads — et l’en-tête que vous ne pourrez probablement pas définir

Le WASM multithread nécessite SharedArrayBuffer, qui exige lui-même l’isolation cross-origin via les en-têtes de réponse COOP et COEP. L’équipe d’ingénierie de Godot a posé le problème opérationnel avec précision dans son rapport d’avancement sur l’export web : « La plupart des jeux web sont publiés sur des plateformes tierces où les auteurs du jeu ne peuvent parfois même pas définir les en-têtes requis pour le support de SharedArrayBuffer. » Leur conclusion a été de faire de l’export monothread la valeur par défaut en pratique.

Traduit en contrainte de conception : sur un build web distribué en portail, budgétez pour un seul thread. Les solveurs physiques, les requêtes de navmesh, la décompression d’assets et la logique de gameplay se partagent un seul cœur. Les titres dont le budget de frame suppose un pool de workers ne se portent pas proprement ; ceux qui sont server-authoritative (la plupart des jeux .io) ou réellement légers en simulation, si.

3. Mémoire et couverture GPU — les deux modes de défaillance silencieux

Memory64 a été déployé dans Chrome 133 et Firefox 134, ce qui rend désormais techniquement possible une mémoire linéaire WASM au-delà de 4 Go. Ce n’est pas gratuit pour autant : l’équipe SpiderMonkey a mesuré que la pénalité du wasm64 « peut aller de seulement 10 % à plus de 100 % — un ralentissement x2 juste en changeant la taille de pointeur ». Pour un jeu, c’est un mauvais compromis. Restez en wasm32 et considérez les 4 Go comme un plafond strict dont vous devriez rester très loin sur mobile.

Côté couverture GPU, la page de statut gpuweb est explicite : le support Android de Chrome est arrivé pour les GPU ARM, Qualcomm et Intel, tandis que les GPU Xclipse de Samsung sont encore listés comme en cours. En pratique, cela veut dire qu’une part non négligeable des appareils Galaxy sous Exynos basculera sur WebGL 2. Si votre titre ne tient son framerate que sous WebGPU, vous avez livré un titre cassé sur du matériel que vous ne pouvez pas énumérer à l’avance. Interrogez l’adaptateur, prévoyez un repli propre, et testez ce chemin de repli comme un build à part entière.

Quels genres mobiles peuvent partir en web-native dès maintenant ?

Ici, être « prêt » signifie : ce genre peut-il franchir les portes du téléchargement, des threads et du repli sans réécriture ?

Genre	Maturité web-native	Facteur déterminant	Y aller maintenant ?
Hyper-casual / arcade	Prêt	Rentre dans le budget de 8 Mo de Poki ; une base WebGL 2 suffit	Oui — portails en premier
Puzzle, match, mots	Prêt	Faible poids d’assets, sessions courtes, compatible monothread	Oui
Multijoueur temps réel façon .io	Prêt	Server-authoritative ; client léger ; WebGPU aide sur le volume de draw calls	Oui
Idle, merge, gestion	Prêt	Contraint par l’UI plutôt que par le GPU	Oui
Cartes, plateau, casino social	Prêt	Charge de rendu triviale ; le vrai travail de design porte sur le flux de paiement	Oui
3D stylisée en session courte (course, arène, runner)	Conditionnel	Ne passe qu’avec un budget d’assets très serré ; WebGPU est ici vraiment structurant	Piloter un titre
RPG mid-core / 4X / stratégie à fort contenu	Pas encore	Le téléchargement initial et l’architecture de streaming dépassent toutes les limites des portails	PWA first-party uniquement
3D open-world ou session longue (20+ min)	Pas encore	Throttling thermique, plafond mémoire, cycle de vie de l’onglet navigateur	Non
Shooters compétitifs avec exigences anti-triche	Pas encore	Le modèle de confiance client ne survit pas au navigateur	Non

Deux nuances à bien intégrer. D’abord, « pas encore » ne veut pas dire « jamais » — un titre mid-core peut toujours tourner en build web first-party sur votre propre domaine, où vous contrôlez les en-têtes, la politique de cache et le séquencement du chargement, et où la règle des 8 Mo des portails ne s’applique pas. C’est un jeu de rétention et de DTC, pas de découverte. Ensuite, la ligne conditionnelle est celle où WebGPU justifie vraiment sa place : la 3D stylisée en session courte est la seule catégorie où les avantages de l’API en draw calls et en compute font la différence entre un titre qui sort et un titre qui ne sort pas.

Si la question n’est plus de savoir si vous devez construire un canal web-native mais où le positionner par rapport aux alt-stores, à l’OEM et au carrier billing, la logique de séquencement se trouve dans notre framework de distribution multi-canal. Et si la surface cible est Telegram, TikTok ou Messenger plutôt qu’un portail de jeux, les contraintes changent encore — ce canal est couvert dans notre playbook instant games.

Comment valider la maturité web-native en deux semaines ?

Ne commanditez pas un portage sur la base d’un tableau de genres. Lancez un sprint de mesure et laissez les chiffres décider.

1. Jours 1 à 3 — établir un plancher de taille. Exportez un build épuré sans contenu : runtime du moteur, une scène, une entrée. Compressez en Brotli. Si le build vide dépasse déjà 15 Mo, c’est le choix du moteur qui est la décision à prendre, pas votre budget artistique.
2. Jours 4 à 6 — mesurez le temps jusqu’à la première interaction, pas le temps de chargement. Sur un appareil Android milieu de gamme, en data mobile bridée, mesurez le délai entre l’ouverture de l’URL et la première frame sur laquelle le joueur peut agir. Le seuil de 20 secondes maximum de CrazyGames pour atteindre le gameplay est la borne extérieure ; les portails qui mettent en avant des titres visent une fraction de ce délai.
3. Jours 7 et 8 — auditez les dépendances aux threads. Passez au crible l’usage des workers, de SharedArrayBuffer, et tout sous-système moteur qui suppose un job system. Partez du principe que vous ne pourrez pas définir les en-têtes COOP/COEP sur les surfaces partenaires.
4. Jours 9 à 11 — testez le repli, pas le chemin nominal. Forcez WebGL 2 et mesurez le temps de frame sur un appareil Samsung Exynos et sur un Android milieu de gamme vieux de trois ans. C’est là que les portages web-native meurent en silence.
5. Jours 12 à 14 — plafond mémoire sur iOS Safari. Faites tourner une session de 20 minutes et surveillez les rechargements d’onglet. Safari mobile qui reprend la main sur votre onglet en pleine session est un bug de rétention qui n’apparaît jamais en QA desktop.

Si les étapes 1, 2 et 4 passent, vous avez un titre web-native, et le travail restant est du travail de canal. Si l’étape 1 échoue, la réponse honnête est que ce titre n’est pas un titre web-native cette année — et le bon réflexe est d’en choisir un autre dans votre catalogue plutôt que de passer deux trimestres à lutter contre un moteur.

FAQ

WebGPU est-il indispensable pour lancer un jeu mobile web-native en 2026 ?

Non. WebGL 2 reste la base que vous devez livrer, car Firefox sur Android et les GPU Xclipse de Samsung sous Chrome n’ont pas encore WebGPU activé. Traitez WebGPU comme un chemin de performance optionnel, avec un repli WebGL 2 obligatoire, et testez ce repli comme un build à part entière.

WebGPU permet-il aux titres mid-core de sortir sur les portails de jeux dès maintenant ?

Pas à lui seul. Les portes des portails portent sur la livraison, pas sur le rendu : Poki vise un téléchargement initial sous 8 Mo, et CrazyGames exige ≤ 50 Mo au départ, avec ≤ 20 Mo pour l’éligibilité à la page d’accueil mobile. WebGPU ne réduit pas la taille du build, donc les titres mid-core restent généralement des candidats à une PWA first-party plutôt qu’à un portail.

Puis-je utiliser du WebAssembly multithread sur un portail de jeux ?

En général, non. Le WASM multithread a besoin de SharedArrayBuffer, qui exige des en-têtes COOP et COEP que vous ne pouvez généralement pas définir sur des plateformes de publication tierces. C’est précisément ce qu’a évoqué l’équipe de Godot pour justifier de faire de l’export monothread la valeur par défaut en pratique. Prévoyez un budget de frame monothread pour vos builds portail.

Le backend WebGPU d’Unity est-il prêt pour la production ?

Le manuel officiel d’Unity 6.3 décrit encore WebGPU comme expérimental et non pris en charge par tous les navigateurs et appareils. C’est utilisable pour des pilotes et des prototypes, mais un plan de lancement commercial qui repose sur le chemin WebGPU d’Unity pour tenir la performance prend aujourd’hui un vrai risque planning.

Faut-il utiliser WebAssembly Memory64 pour dépasser la limite de 4 Go ?

Pour un jeu, presque certainement pas. SpiderMonkey a mesuré une pénalité du wasm64 allant de 10 % à plus de 100 % selon la charge de travail. Si un titre a besoin de plus de 4 Go de mémoire linéaire dans un onglet de navigateur, la bonne conclusion est que ce n’est pas un titre web-native — pas qu’il a besoin de pointeurs 64 bits.

---

Si vous avez un catalogue entre les mains et que vous essayez de déterminer quels deux titres méritent un build web-native cette année — et sur quel portail, quelle PWA ou quelle surface embarquée chacun doit atterrir — c’est exactement la conversation que notre practice interactive est là pour avoir. Parlez-nous de la taille de vos builds et de vos appareils cibles, et nous vous donnerons un avis franc sur les titres qui passent les portes.