La stack technologique des jeux web en 2026
Trois technologies font tourner les jeux web : WebGL, WebGPU et WebAssembly. Chacune répond à des besoins différents et implique ses propres compromis. Ce guide vous aide à choisir en fonction de ce que vous développez réellement, et non de la technologie qui suscite le plus d’engouement.
La réponse rapide
WebGL 2.0 fonctionne partout et convient parfaitement à la plupart des jeux. Utilisez-le si vous avez besoin d’une large compatibilité, en particulier sur mobile. WebGPU offre des shaders de calcul et de meilleures performances, mais vous perdrez des utilisateurs sur les navigateurs et appareils plus anciens. WebAssembly accélère votre code côté CPU : il est donc utile pour la physique et la recherche de chemin, mais ne vous aidera pas si votre goulot d’étranglement se situe au niveau du GPU.
En 2026, la plupart des jeux utilisent WebGL avec une prise en charge facultative de WebGPU pour les navigateurs compatibles. Wasm est employé de manière sélective pour les portions de code critiques, et non pour l’ensemble du jeu.
WebGL 2.0 : le choix sans surprise qui fonctionne
WebGL 2.0 est stable depuis 2017. Tous les navigateurs modernes le prennent en charge. Votre jeu fonctionne sur Chrome, Firefox, Safari et Edge, y compris dans des versions datant de plus de cinq ans. Il fonctionne sur Safari iOS 15+, Chrome pour Android et Samsung Internet. Il s’exécute même dans les navigateurs de consoles, comme Edge sur Xbox et le navigateur de PlayStation.
Voici à quoi ressemble une configuration WebGL 2 de base :
const canvas = document.getElementById('game');
const gl = canvas.getContext('webgl2');
if (!gl) {
// Fallback to WebGL 1 or show error
const gl1 = canvas.getContext('webgl');
if (!gl1) {
showError('Your browser does not support WebGL.');
return;
}
}
// Now you have a GL context
gl.clearColor(0.1, 0.1, 0.1, 1.0);
gl.clear(gl.COLOR_BUFFER_BIT);Ce que vous obtenez
WebGL 2 permet le rendu instancié, afin de dessiner des milliers d’objets avec un seul appel de rendu. Il dispose du transform feedback pour les systèmes de particules et les simulations exécutés côté GPU. Vous bénéficiez de plusieurs cibles de rendu pour le rendu différé et les G-buffers, de textures 3D pour les effets volumétriques et de textures entières pour stocker des données avec précision.
gl.drawArraysInstanced(gl.TRIANGLES, 0, vertexCount, instanceCount);Ce que vous n’obtenez pas
Vous ne pouvez pas exécuter de shaders de calcul pour les calculs généralistes sur GPU. Il n’y a pas de textures sans liaison, ce qui vous limite au nombre d’unités de texture. Pas de mappage persistant ni de contrôle explicite de la mémoire. Pas de mesh shaders ni de pipeline géométrique moderne.
Pour la plupart des jeux 2D et de nombreux jeux 3D, ces limites n’ont aucune importance. Certains des jeux web les plus populaires jamais créés ont été publiés avec WebGL 2.
WebGPU : lorsque vous avez besoin de davantage
WebGPU est conçu autour du fonctionnement réel des GPU modernes. Chrome l’a intégré en mai 2023 et, fin 2025, tous les principaux navigateurs le prenaient en charge. Chrome 113+, Safari 26+ et Edge 113+ sont tous compatibles. Firefox l’a activé à partir de la version 141 sous Windows, depuis juillet 2025, et de la version 145 sur les Mac Apple Silicon, tandis que son déploiement se poursuit sous Linux et Android. Chrome pour Android le prend en charge sur les appareils récents, tout comme Safari iOS 26+.
Le problème est que les appareils et navigateurs plus anciens ne le prennent pas en charge. Vous avez donc besoin d’une stratégie de repli.
Ce que vous obtenez
Les shaders de calcul permettent d’exécuter des calculs généralistes sur GPU pour la physique, les particules, l’IA et le traitement d’images.
// A compute shader that processes data in parallel
const computeShaderCode = `
@group(0) @binding(0) var<storage, read_write> data: array<f32>;
@compute @workgroup_size(64)
fn main(@builtin(global_invocation_id) id: vec3<u32>) {
data[id.x] = data[id.x] * 2.0;
}
`;Vous bénéficiez également d’une gestion explicite des ressources, ce qui réduit les mauvaises surprises en matière de performances, de render bundles permettant de préenregistrer des appels de rendu pour les réutiliser, ainsi que de WGSL, un langage de shaders moderne conçu pour les GPU plutôt qu’un bricolage inspiré du C.
Configuration pratique de WebGPU
Voici comment initialiser WebGPU avec un repli vers WebGL :
async function initGraphics(canvas) {
// Try WebGPU first
if (navigator.gpu) {
const adapter = await navigator.gpu.requestAdapter();
if (adapter) {
const device = await adapter.requestDevice();
const context = canvas.getContext('webgpu');
context.configure({
device,
format: navigator.gpu.getPreferredCanvasFormat(),
});
return { type: 'webgpu', device, context };
}
}
// Fall back to WebGL 2
const gl = canvas.getContext('webgl2');
if (gl) {
return { type: 'webgl2', gl };
}
// Last resort: WebGL 1
const gl1 = canvas.getContext('webgl');
if (gl1) {
return { type: 'webgl', gl: gl1 };
}
throw new Error('No graphics API available');
}Quand WebGPU est réellement utile
WebGPU excelle lorsque vous avez besoin de shaders de calcul pour mettre à jour des millions de particules sans allers-retours avec le CPU, pour la détection de collisions et la simulation de tissus accélérées par GPU, pour la génération procédurale de terrains, de textures ou de maillages, pour des effets de post-traitement complexes comme le SSAO, le bloom et la profondeur de champ, ou encore pour exécuter des modèles entraînés servant au comportement des PNJ ou aux effets visuels.
Si vous créez un jeu de réflexion ou un visual novel, WebGPU ne vous aidera pas. Si vous développez un jeu d’action riche en particules ou un monde 3D complexe, le compromis en matière de compatibilité peut en valoir la peine.
WebAssembly : du code CPU rapide
WebAssembly exécute du code compilé à une vitesse proche de celle du code natif. Il ne concerne pas les graphismes, mais l’accélération de votre code côté CPU.
Quand il est utile
Wasm convient bien aux moteurs physiques — Box2D, Bullet et Rapier disposent tous de versions Wasm —, à la recherche de chemin sur de grandes grilles, à la décompression des ressources, à l’émulation d’anciennes consoles de jeu et au portage de bases de code C++ ou Rust existantes vers le web.
Quand il n’est pas utile
Votre GPU ne se soucie pas de savoir si les appels de rendu proviennent de JavaScript ou de Wasm : le rendu ne sera donc pas plus rapide. Le code limité par les entrées-sorties, comme le chargement de ressources ou les requêtes réseau, n’en bénéficiera pas non plus. Et si votre code JavaScript s’exécute déjà en moins d’une milliseconde, Wasm ne vous fera rien gagner.
Un exemple pratique de Wasm
Voici une fonction Rust minimale compilée en Wasm pour la physique :
// src/lib.rs
#[no_mangle]
pub extern "C" fn step_physics(dt: f32) {
// Your physics code here
}Compilez-la avec :
wasm-pack build --target webUtilisez-la en JavaScript :
import init, { step_physics } from './physics_bg.wasm';
await init();
function gameLoop(dt) {
step_physics(dt); // Runs at near-native speed
render();
requestAnimationFrame(gameLoop);
}Le multithreading se complique
Wasm peut utiliser des threads pour le traitement parallèle, mais cela nécessite SharedArrayBuffer, ce qui impose d’activer des en-têtes d’isolation interorigines sur votre serveur :
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corpCes en-têtes provoquent des incompatibilités. Les iframes tierces dépourvues d’en-têtes CORP cessent de fonctionner, certains scripts d’analyse ne fonctionnent plus et les fenêtres contextuelles OAuth peuvent échouer. Vous pouvez utiliser credentialless à la place de require-corp pour limiter les dégâts, mais cela reste compliqué.
Si vous ne pouvez pas définir ces en-têtes parce que vous utilisez un hébergement mutualisé ou itch.io, vous ne pouvez pas employer les threads Wasm. Le Wasm monothread fonctionne néanmoins parfaitement.
Des décisions concrètes pour de vrais jeux
Si vous créez un jeu de plateforme 2D, utilisez WebGL 2 via une bibliothèque comme Phaser ou PixiJS. Oubliez WebGPU, qui serait excessif, et Wasm, puisque JavaScript est suffisamment rapide pour la physique 2D. Une large compatibilité compte davantage que les dernières fonctionnalités, et votre principal frein sera le contenu, non la technologie.
Si vous créez un monde ouvert en 3D, commencez avec WebGL 2, mais prévoyez une voie de migration vers WebGPU. Envisagez Wasm pour la physique avec Rapier ou Bullet. Vous voulez toucher le public le plus large possible dès maintenant, mais les shaders de calcul pourront plus tard améliorer la végétation, les particules et les niveaux de détail. L’exécution de la physique dans Wasm limite la consommation du budget CPU.
Si vous portez un moteur C++, utilisez Wasm via Emscripten. Les graphismes utiliseront WebGL 2 par défaut, ou WebGPU si votre moteur le prend en charge. Vous disposez déjà du code et Emscripten s’occupe de la traduction.
Si vous créez un jeu de réflexion, utilisez Canvas 2D ou WebGL 2 via Phaser. Oubliez tout le reste. Les jeux simples doivent rester simples.
Si vous avez absolument besoin de performances maximales et acceptez de perdre certains utilisateurs équipés de navigateurs plus anciens, optez pour WebGPU avec Wasm. Mesurez simplement l’impact réel sur votre public avant de vous engager.
Ce qui rend réellement les jeux rapides
Voici, par ordre d’importance, les facteurs qui déterminent si votre jeu web fonctionne correctement.
La taille des ressources représente environ la moitié des performances perçues. Un jeu de 2 Mo qui se charge en une seconde paraît plus rapide qu’un jeu de 50 Mo offrant un meilleur nombre d’images par seconde. Compressez tout. Chargez à la demande ce qui peut l’être.
Les appels de rendu comptent énormément pour les jeux 3D et peuvent représenter 30 % de votre budget de performances. Regroupez votre géométrie. Utilisez des atlas de textures. Instanciez les objets répétés. Cela compte bien plus que le choix entre WebGL et WebGPU.
Les performances de JavaScript représentent peut-être 15 %. Évitez les allocations dans les boucles critiques. Utilisez des tableaux typés. Profilez avant d’optimiser.
Le choix de l’API graphique ? Honnêtement, peut-être 5 %. Pour la plupart des jeux, l’API importe moins que la manière dont vous l’utilisez.
Si votre jeu est lent, vérifiez d’abord si vous chargez trop de données dès le départ. Vérifiez ensuite si vous effectuez trop d’appels de rendu. Puis regardez si votre code JavaScript fait quelque chose d’inefficace dans la boucle de jeu. Ce n’est qu’après tout cela que vous devriez vous demander si une autre API graphique pourrait vous aider.
Ce que j’utiliserais réellement
Pour un nouveau jeu web démarré aujourd’hui, j’utiliserais Three.js ou Babylon.js pour le rendu, car ces bibliothèques font abstraction de WebGL et de WebGPU. Pour la physique, j’opterais pour Rapier — écrit en Rust et compilé en Wasm — si j’avais besoin de physique 3D, ou simplement pour le moteur physique 2D intégré du moteur dans le cas de jeux plus simples. Howler.js ou directement l’API Web Audio pour le son. Vite pour la compilation, car il est rapide en développement et produit de bonnes versions de production. Enfin, un hébergement statique sur Netlify, Vercel, GitHub Pages ou itch.io.
Cette stack permet de publier des jeux qui fonctionnent sur plus de 98 % des appareils, tout en étant prêts pour WebGPU lorsque celui-ci deviendra la solution par défaut.
Testez avant de vous engager
Avant d’arrêter votre choix sur une stack technologique, créez un petit prototype et testez-le réellement. Vérifiez le temps de chargement en 3G à l’aide de la limitation réseau de Chrome DevTools. Votre jeu devrait être jouable en moins de cinq secondes sur une connexion lente. Testez les performances sur un téléphone Android d’entrée de gamme : empruntez-en un ou utilisez BrowserStack. S’il fonctionne sur cet appareil, il fonctionnera partout. Testez-le spécifiquement sur Safari, car ce navigateur est suffisamment différent pour réserver des surprises. Et si votre jeu doit être publié sur Newgrounds ou Kongregate, testez-le dans une iframe.
Ces tests détectent davantage de problèmes réels que tous les débats sur WebGL et WebGPU.
Pour aller plus loin
Comparatif des moteurs de jeux web présente des moteurs complets si vous ne voulez pas tout créer de zéro. Three.js + USDC dans le navigateur explique comment charger des ressources USD dans Three.js. Comment publier sur itch.io aborde la publication une fois votre projet terminé.
Pour des tutoriels pratiques qui approfondissent chaque API :
- Principes fondamentaux de WebGL pour les créateurs de jeux — shaders, buffers, textures et boucle de rendu
- Bien démarrer avec WebGPU — configuration du périphérique, pipelines et shaders WGSL
- Web Workers pour la logique de jeu — transfert des tâches vers des threads en arrière-plan
- COOP/COEP et SharedArrayBuffer — en-têtes requis pour le multithreading Wasm
- Bibliothèques de physique pour les jeux — Rapier, Cannon-es, Ammo.js, Matter.js et bien d’autres
La bonne stack technologique est celle qui vous permet de publier votre jeu. Choisissez ce que vous connaissez, testez tôt et optimisez plus tard.
WebGL, physique et pipeline de ressources sont pris en charge. Il vous suffit de décrire le jeu.