WebGPU, la 3D temps réel qui sort des studios créatifs
WebGPU dessine désormais dans Chrome, Safari et Firefox, iPhone compris. Son usage réel a été multiplié par sept en un an. L'article donne le code de départ, le repli vers WebGL et ce que les études mesurent sur la 3D en e-commerce.
Au 30 septembre 2026, 0,40 % des pages chargées dans Chrome ouvrent un canevas WebGPU, d'après les compteurs d'usage de Chrome (opens in a new tab). Un an plus tôt, la part était de 0,05 %. WebGL, l'interface 3D historique du web, reste présent sur 27 % des chargements (opens in a new tab). L'écart reste considérable mais l'usage de WebGPU a été multiplié par plus de sept en douze mois.
WebGPU est l'interface qui donne à une page web l'accès au processeur graphique de l'appareil, le GPU. Elle succède à WebGL, publié en 2011. Chrome l'active depuis la version 113 (opens in a new tab) sur ordinateur, sortie au printemps 2023. Le verrou principal a sauté le 15 septembre 2025, quand Safari 26 (opens in a new tab) l'a livrée sur macOS, iOS, iPadOS et visionOS. Depuis cette date, une scène 3D écrite pour WebGPU s'affiche sur un iPhone.
La 3D temps réel a longtemps été associée aux sites de studios créatifs, primés et lourds. Les usages qui grandissent avec WebGPU sont plus ordinaires. Un configurateur de produit, un outil de dessin comme Figma ou un modèle d'IA exécuté dans le navigateur en font partie. Les bibliothèques ont absorbé l'essentiel de la complexité. Three.js choisit seul entre WebGPU et WebGL selon l'appareil, ce qui ramène la question du support à une ligne d'import.
Ce que WebGPU change par rapport à WebGL
WebGL dérive d'OpenGL ES, une interface graphique conçue avant les processeurs graphiques actuels. Les systèmes d'exploitation sont passés depuis à d'autres interfaces, Metal chez Apple, Direct3D 12 chez Microsoft et Vulkan sur Android et Linux. Chaque appel WebGL doit donc être traduit. L'équipe WebKit le dit dans son annonce de Safari 26. WebGPU "correspond mieux à Metal et au matériel sous-jacent", alors que WebGL imposait un coût de traduction important.
Trois différences comptent pour un projet web.
- Les calculs généralistes. Un compute shader est un programme exécuté par le processeur graphique sans rien dessiner. Il traite des données en parallèle pour une simulation de particules, de la physique, du traitement d'image ou l'exécution d'un modèle d'IA. WebGL ne le permettait pas. Il fallait dessiner des triangles pour déclencher un calcul (opens in a new tab) puis ranger les données dans des textures
- La préparation du rendu. Les réglages graphiques sont décrits une fois dans un objet appelé pipeline puis réutilisés. Le navigateur a moins de vérifications à refaire à chaque image
- Le langage des shaders. WGSL, pour WebGPU Shading Language, remplace GLSL. Il est identique sur tous les navigateurs et tous les systèmes
Les gains de vitesse dépendent de ce que fait l'application et les chiffres publiés portent sur des cas précis. Babylon.js soumet une scène statique plus de dix fois plus vite (opens in a new tab) grâce à une fonction de WebGPU qui enregistre les commandes de dessin pour les rejouer. Ce gain porte sur le travail du processeur central. La puissance graphique disponible reste la même. Un modèle de génération d'images de TensorFlow.js a tourné trois fois plus vite après son passage de WebGL à WebGPU, selon la même source.
Figma, qui a migré son moteur de rendu vers WebGPU (opens in a new tab) en 2025, rapporte une amélioration sur certaines catégories d'appareils, des résultats neutres sur d'autres et aucune régression. Passer à WebGPU n'accélère donc pas mécaniquement une scène existante. Le bénéfice apparaît sur les scènes chargées en objets et sur les calculs que WebGL ne savait pas faire.
Le support de WebGPU par les navigateurs en octobre 2026
WebGPU fonctionne dans les trois moteurs de navigateur, avec des trous selon le système d'exploitation.
| Navigateur | Depuis | Couverture |
|---|---|---|
| Chrome et Edge sur ordinateur | Version 113, printemps 2023 | Windows, macOS et ChromeOS. Linux depuis la version 144 pour les puces Intel récentes, la 147 pour NVIDIA |
| Chrome sur Android | Version 121, janvier 2024 | Android 12 et suivants, puces Qualcomm et ARM |
| Safari | Version 26, septembre 2025 | macOS, iOS, iPadOS et visionOS dans leur version 26 |
| Firefox | Version 141, juillet 2025 | Windows. Mac à puce Apple depuis les versions 145 et 147. Ni Linux ni Android |
Le support de WebGPU par navigateur et par système en octobre 2026
Les dates viennent des annonces de Chrome pour Android (opens in a new tab) et pour Linux (opens in a new tab), de WebKit (opens in a new tab), de Mozilla (opens in a new tab) et du tableau de compatibilité de MDN (opens in a new tab).
Ces trous expliquent le statut officiel. WebGPU reste classé Baseline "limited availability" (opens in a new tab), le niveau attribué à une fonctionnalité qui manque encore dans une partie des navigateurs de référence. Can I Use (opens in a new tab) estime à 85,72 % la part des internautes dont le navigateur la prend en charge complètement. La spécification n'est pas terminée non plus. Le W3C la publie au stade de Candidate Recommendation Draft (opens in a new tab), une étape antérieure à la recommandation finale.
Trois populations restent à l'écart. Ce sont les appareils Apple restés sous une version antérieure du système, les utilisateurs de Firefox sous Linux et Android puis les téléphones Android anciens dont la puce ne gère pas les interfaces graphiques récentes. Pour ces derniers, Chrome 146 a introduit en février 2026 un mode de compatibilité (opens in a new tab) qui fait tourner WebGPU sur OpenGL ES 3.1, d'abord sur Android. Il se demande explicitement avec requestAdapter({ featureLevel: "compatibility" }).
La mesure de l'adoption demande une précaution. Le compteur le plus souvent cité, celui des appels à requestAdapter(), atteint 11,5 % des chargements de page (opens in a new tab) dans Chrome. Il compte les pages qui interrogent le processeur graphique, pas celles qui dessinent. Un article de recherche déposé en juin 2026 (opens in a new tab), pas encore relu par des pairs, observe que l'usage de WebGPU au chargement des pages consiste surtout à sonder l'adaptateur sans lancer aucun rendu. Le chiffre qui décrit l'usage réel est celui des canevas WebGPU, soit 0,40 %.
Initialiser WebGPU sans bibliothèque
L'initialisation suit toujours les trois mêmes étapes, documentées sur MDN (opens in a new tab). La page demande un adaptateur, qui représente le processeur graphique. Elle obtient ensuite un appareil logique, l'objet qui crée les ressources. Elle relie enfin cet appareil à un élément <canvas>.
async function initWebGPU(canvas) {
if (!navigator.gpu) return null;
const adapter = await navigator.gpu.requestAdapter();
if (!adapter) return null;
const device = await adapter.requestDevice();
const context = canvas.getContext("webgpu");
context.configure({
device,
format: navigator.gpu.getPreferredCanvasFormat(),
alphaMode: "premultiplied",
});
return { device, context };
}Les trois étapes de l'initialisation
Les deux retours null ne couvrent pas le même cas. navigator.gpu est absent quand le navigateur ne connaît pas WebGPU. requestAdapter() renvoie null quand le navigateur le connaît mais refuse de l'activer sur cette machine, parce que le pilote graphique figure sur une liste de blocage (opens in a new tab) ou que l'accélération matérielle est désactivée. Tester seulement navigator.gpu laisse donc passer des appareils sur lesquels rien ne s'affichera.
Deux changements rendent obsolètes une partie des exemples publiés avant 2025. Les informations sur la carte graphique se lisent désormais dans la propriété adapter.info, décrite sur MDN (opens in a new tab), l'ancienne méthode requestAdapterInfo() ayant été retirée de Chrome. Depuis Chrome 140 (opens in a new tab), un adaptateur ne sert qu'une fois. Un second appel à requestDevice() sur le même adaptateur échoue et il faut en demander un nouveau.
Three.js choisit entre WebGPU et WebGL selon l'appareil
Peu de projets écrivent du WebGPU brut. La plupart passent par une bibliothèque et Three.js est la plus installée, avec 22 millions de téléchargements (opens in a new tab) sur npm pendant la dernière semaine de septembre 2026. Son moteur de rendu WebGPURenderer s'importe depuis three/webgpu. D'après sa documentation (opens in a new tab), il utilise WebGPU quand le navigateur le prend en charge et se replie sinon sur WebGL 2.
import * as THREE from "three/webgpu";
const canvas = document.querySelector("#product-viewer");
const renderer = new THREE.WebGPURenderer({ canvas, antialias: true });
renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));
renderer.setSize(canvas.clientWidth, canvas.clientHeight, false);
const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(
35,
canvas.clientWidth / canvas.clientHeight,
0.1,
100
);
camera.position.set(0, 1, 4);
const product = new THREE.Mesh(
new THREE.BoxGeometry(1, 1, 1),
new THREE.MeshStandardMaterial({ color: "#c8a45a" })
);
const light = new THREE.HemisphereLight("#ffffff", "#444444", 3);
scene.add(product, light);
renderer.setAnimationLoop(() => {
product.rotation.y += 0.01;
renderer.render(scene, camera);
});Une scène Three.js avec WebGPURenderer
Ce code ne contient aucun test de support. Le visiteur sous Chrome ou Safari 26 obtient WebGPU, celui sous Firefox Linux obtient WebGL 2 et la scène est la même. L'option forceWebGL: true passée au constructeur permet de vérifier le repli pendant le développement sans changer de machine.
Une contrainte distingue ce moteur de l'ancien WebGLRenderer. Son initialisation est asynchrone. La documentation de la classe (opens in a new tab) garantit qu'il est prêt quand le rendu passe par setAnimationLoop(). Dans tous les autres cas, il faut attendre renderer.init() avant le premier appel à render(). Le cas se présente sur un configurateur. Redessiner soixante fois par seconde une image qui ne change pas sollicite le processeur graphique et la batterie sans bénéfice visible. Le rendu à la demande ne dessine qu'après une interaction.
await renderer.init();
function draw() {
renderer.render(scene, camera);
}
controls.addEventListener("change", draw);
colorPicker.addEventListener("input", (event) => {
product.material.color.set(event.target.value);
draw();
});
draw();Rendu à la demande sur un configurateur
Les méthodes renderAsync() et computeAsync(), présentes dans de nombreux tutoriels, sont dépréciées depuis la version r181 d'après le guide de migration (opens in a new tab) de Three.js. React Three Fiber accepte ce moteur depuis sa version 9, dont la propriété gl peut recevoir une fonction asynchrone (opens in a new tab). Le choix entre Three.js, WebGL brut et une bibliothèque d'animation d'interface est traité dans un guide distinct (opens in a new tab).
Ce qu'un compute shader ajoute à une scène
Le compute shader est la partie de WebGPU sans équivalent dans WebGL. L'exemple suivant, écrit en WGSL, déplace des particules. Les positions et les vitesses vivent dans la mémoire du processeur graphique et y restent d'une image à l'autre.
struct Particle {
position: vec2f,
velocity: vec2f,
}
@group(0) @binding(0)
var<storage, read_write> particles: array<Particle>;
@compute @workgroup_size(64)
fn main(@builtin(global_invocation_id) id: vec3u) {
let index = id.x;
if (index >= arrayLength(&particles)) {
return;
}
let particle = particles[index];
particles[index].position = particle.position + particle.velocity * 0.016;
}Un compute shader WGSL qui déplace des particules
Chaque exécution de main traite une particule et le processeur graphique en lance des milliers en parallèle, par groupes de 64. En WebGL, la même mise à jour passait le plus souvent par une boucle JavaScript sur le processeur central puis par un envoi des positions à chaque image. Le nombre de particules affichables était borné par ce trajet. Three.js donne accès au même mécanisme sans écrire de WGSL, à travers TSL, son langage de shaders écrit en JavaScript et importé depuis three/tsl.
Le calcul sur processeur graphique sert aussi hors de la 3D. La bibliothèque Transformers.js exécute des modèles d'IA dans le navigateur avec l'option device: "webgpu". Son éditeur Hugging Face annonce une exécution jusqu'à 100 fois plus rapide (opens in a new tab) qu'avec WebAssembly, une comparaison entre processeur graphique et processeur central. Le chiffre vient de l'éditeur et vaut comme ordre de grandeur du meilleur cas.
Ce que les études mesurent sur la 3D et les ventes
Le chiffre le plus repris vient de Shopify. Les marchands qui ajoutent du contenu 3D à leur boutique constatent "en moyenne une hausse de conversion de 94 %", écrit la plateforme dans une note de mai 2022 (opens in a new tab). Aucune méthode n'accompagne ce chiffre. La note ne précise ni l'échantillon ni la période ni le groupe de comparaison.
L'étude de cas Rebecca Minkoff (opens in a new tab), publiée elle aussi par Shopify, est plus précise. Les visiteurs qui manipulent un sac en 3D ont 44 % de chances en plus de l'ajouter au panier et 27 % de chances en plus de commander. L'écart compare cependant des visiteurs qui ont choisi d'interagir à des visiteurs qui ne l'ont pas fait. Une personne déjà décidée à acheter examine davantage le produit, avec ou sans 3D. Ces chiffres décrivent une corrélation et viennent d'une plateforme qui vend la fonctionnalité.
La mesure la plus solide est académique. Une étude parue en 2022 dans le Journal of Marketing (opens in a new tab) a analysé les données d'un détaillant international de cosmétiques dont l'application mobile proposait l'essayage en réalité augmentée. Ses auteurs en résument les résultats (opens in a new tab) en deux temps. L'effet sur les ventes est positif et "l'impact global paraît faible". Il est plus fort pour les marques les moins connues, pour les produits de niche et pour les produits les plus chers.
L'étude porte sur la réalité augmentée dans une application et non sur un site en WebGPU. Le mécanisme qu'elle décrit ne dépend pas de la technologie. La visualisation réduit l'incertitude de l'acheteur et pèse là où cette incertitude est forte. Une marque installée qui vend un produit connu en tire peu. Un fabricant peu connu dont le produit est cher, configurable ou difficile à se représenter en photo se trouve dans le cas où l'effet mesuré est le plus net.
Les limites de WebGPU à prévoir avant la mise en production
L'appareil graphique peut disparaître en cours de session. Figma l'a constaté sous Windows pendant son déploiement. L'appareil WebGPU était parfois perdu sans pouvoir être redemandé, ce qu'aucun test au chargement ne détectait. L'équipe a construit un repli dynamique vers WebGL, déclenché pendant l'utilisation. L'interface prévoit ce cas avec la promesse device.lost, documentée sur MDN (opens in a new tab).
device.lost.then((info) => {
if (info.reason === "destroyed") return;
console.warn(`WebGPU device lost: ${info.message}`);
startWebGLFallback();
});Réagir à la perte de l'appareil graphique
Le poids du code s'ajoute à celui de la page. La version principale de Three.js pèse 185 Ko une fois compressée, d'après Bundlephobia (opens in a new tab), avant le premier modèle 3D et la première texture. Charger la scène après le contenu, au moment où le visiteur approche de la zone concernée, garde le texte et les images de la page hors de cette attente. L'arbitrage entre richesse visuelle et métriques de performance est détaillé dans l'article sur le paradoxe des sites primés (opens in a new tab).
Un canevas est invisible pour les technologies d'assistance. Rien de ce qui s'y dessine n'est lu par un lecteur d'écran et MDN demande de fournir un contenu alternatif (opens in a new tab) entre les balises. Sur un configurateur, les options restent de vrais boutons HTML placés à côté de la scène. Le prix, la référence et les caractéristiques restent du texte. La scène 3D enrichit alors une page qui fonctionne sans elle, selon la logique de l'amélioration progressive (opens in a new tab).
Tous les outils ne sont pas au même stade. Three.js, Babylon.js et PlayCanvas proposent un moteur WebGPU. Unity qualifie encore son export WebGPU d'expérimental (opens in a new tab) dans sa documentation et garde WebGL 2 par défaut.
Quand choisir WebGPU pour un projet de site
- Sur un nouveau projet 3D avec Three.js, partir sur
WebGPURenderer. Le repli vers WebGL 2 couvre les navigateurs manquants sans code supplémentaire - Sur une scène WebGL existante qui fonctionne, rien ne presse. Le retour d'expérience de Figma montre un gain sur une partie des appareils seulement
- Sur une scène limitée par son nombre d'objets, WebGPU réduit le travail du processeur central à chaque image
- Sur un projet qui demande une simulation, des particules en masse ou de l'IA locale, WebGPU apporte ce que WebGL ne sait pas faire
- Sur un projet Unity destiné au web, rester sur WebGL 2 tant que l'export WebGPU est qualifié d'expérimental
- Le WebGPU brut sans bibliothèque concerne les équipes qui écrivent leur propre moteur de rendu
Ce que WebGPU retire du débat sur la 3D
Jusqu'en 2025, WebGPU ne fonctionnait que dans Chrome et Edge, ce qui la cantonnait aux démonstrations. Depuis septembre 2025, elle tourne sur iPhone. Un seul moteur de rendu couvre les navigateurs qui la connaissent et ceux qui ne la connaissent pas. Le coût technique d'une scène 3D sur un site de marque, de fabricant ou de commerçant a baissé d'autant.
La question qui reste porte sur le produit. Les données disponibles indiquent un effet réel et concentré là où l'acheteur hésite faute de pouvoir se représenter ce qu'il achète. Un produit cher, configurable ou peu connu entre dans ce cas. Un produit que quelques photos suffisent à décrire en tire moins.