WebGL 2 ou WebGPU non pris en charge ? Comment résoudre le problème dans tous les navigateurs (2026)

Dernière mise à jour : septembre 2026.

Si un jeu ou une page 3D indique que votre navigateur ne prend pas en charge WebGL 2 ou WebGPU, la cause est presque toujours l’une des quatre suivantes : l’accélération matérielle est désactivée, votre GPU ou son pilote figure sur la liste de blocage du navigateur, le navigateur est trop ancien pour l’API, ou vous utilisez une machine virtuelle ou une session de bureau à distance sans véritable GPU. Activez l’accélération matérielle, mettez à jour le pilote graphique et le navigateur, puis confirmez le résultat à l’aide d’un test de compatibilité. Pour WebGPU, vérifiez également la plateforme : en septembre 2026, Firefox ne le propose que sous Windows et sur les Mac Apple Silicon, tandis que Chrome sous Linux ne le prend en charge que sur les GPU Intel Gen12+ et les cartes NVIDIA récentes.

Cette page est consacrée au dépannage. Pour comprendre les deux API et choisir celle sur laquelle baser votre création, consultez WebGPU ou WebGL pour les jeux.

Réponse rapide

• Commencez par établir un diagnostic : ouvrez l’outil de vérification WebGL et WebGPU. Il indique si WebGPU, WebGL 2 et WebGL 1 fonctionnent, ainsi que le nom du GPU utilisé par votre navigateur. Si le moteur de rendu indique SwiftShader, llvmpipe ou « Software », le rendu est effectué par le processeur et les solutions ci-dessous s’appliquent.
• Chrome et Edge : dans Paramètres, Système, activez « Utiliser l’accélération graphique si disponible », puis relancez le navigateur. Consultez chrome://gpu (ou edge://gpu). Si WebGL est indiqué comme « Software only » ou « Unavailable », mettez à jour le pilote du GPU. En dernier recours : chrome://flags/#ignore-gpu-blocklist.
• Firefox : dans Paramètres, Général, Performances, décochez « Utiliser les paramètres de performance recommandés », puis cochez « Utiliser l’accélération graphique matérielle si disponible ». Consultez la section Graphiques de about:support. En dernier recours : dans about:config, définissez webgl.force-enabled sur true.
• Safari : passez à Safari 26 pour WebGPU et à Safari 15 ou version ultérieure pour WebGL 2. Il n’existe aucun réglage d’accélération à activer.
• Le message d’Unity « does not support graphics API WebGL 2 » signifie que canvas.getContext('webgl2') n’a rien renvoyé. Les mêmes solutions s’appliquent et, sur Safari, ce message indique une version antérieure à 15.
• Appareil professionnel ou scolaire, machine virtuelle, bureau à distance : le GPU est bloqué par une politique ou n’est pas disponible. Contactez le service informatique ou jouez sur un appareil équipé d’un véritable GPU.

Tableau de référence

Prise en charge de WebGPU en septembre 2026, d’après le wiki sur l’état de l’implémentation de WebGPU (mis à jour le 13 août 2026), les notes de version de Firefox et WebKit, ainsi que caniuse.

Navigateur	Windows	macOS	Linux	Android	iOS et iPadOS
Chrome et Edge	113+ (Windows sur ARM : derrière un indicateur)	113+	144+ sur Intel Gen12+, 147+ sur NVIDIA (pilote 535.183.01+) sous Wayland, autres configurations derrière des indicateurs	121+ sur Android 12+ avec des GPU ARM, Qualcomm ou Intel, 139+ pour Imagination sur Android 16+, prise en charge de Samsung Xclipse en cours	Utilise le moteur WebKit d’Apple ; effectuez donc le test sur l’appareil
Firefox	141+ (22 juillet 2025)	145+ sous macOS 26 avec Apple Silicon, 147+ sur toutes les versions de macOS prises en charge avec Apple Silicon, uniquement dans Nightly sur les Mac Intel	Nightly uniquement, sortie prévue en 2026	Derrière un indicateur	Utilise le moteur WebKit d’Apple
Safari	s.o.	26+ (15 septembre 2025, sous macOS Tahoe, Sequoia et Sonoma)	s.o.	s.o.	26+

Le même tableau présenté sous forme de grille. Le vert signifie que la fonctionnalité est activée par défaut dans la version stable. Deux cellules sont partiellement vertes, car la réponse dépend du GPU : Chrome sous Linux (Intel Gen12+ ou NVIDIA récent sous Wayland) et Firefox sous macOS (Apple Silicon uniquement). Firefox sous Linux et Android, ainsi que Chrome sous Windows sur ARM, nécessitent encore Nightly ou un indicateur.

WebGL 2 constitue la référence minimale. D’après caniuse, il est disponible dans Chrome 56+, Edge 79+, Firefox 51+, Safari 15+ et Safari sous iOS 15+, tandis que la page de compatibilité d’Unity indique Chrome 58+ sous Android. Si WebGL 2 échoue dans un navigateur récent, le problème vient de la machine, et non de la version du navigateur.

Le diagnostic en 30 secondes

Commencez par l’outil de vérification WebGL et WebGPU. Il s’exécute au chargement de la page et ne téléverse aucune donnée. Relevez trois informations.

Sur une machine présentant le problème, la page ressemble à ceci.

Voici à quoi ressemble un navigateur bloqué ou limité au rendu logiciel dans l’outil de vérification : une bannière orange, une zone de rendu noire sans indication du nombre d’images par seconde et les trois cartes d’API marquées « Non ». Notez l’encadré « Comment résoudre le problème », qui recommande déjà d’activer l’accélération matérielle.

Les API qui fonctionnent. Si WebGL 2 fonctionne et que seul WebGPU échoue, consultez le tableau ci-dessus, car WebGPU dépend à la fois du navigateur, du système d’exploitation et du GPU ; la réponse peut donc être « pas encore sur cette plateforme ». Si WebGL 2 échoue également, poursuivez votre lecture : cela indique un problème d’accélération, de pilotes ou de liste de blocage.

La ligne du moteur de rendu. Un véritable GPU apparaît sous une forme telle que « ANGLE (NVIDIA, NVIDIA GeForce RTX 4060 ...) » ou « Apple M2 ». SwiftShader, llvmpipe, « Microsoft Basic Render Driver » ou toute mention contenant « software » signifie que votre navigateur effectue le rendu sur le processeur. Les jeux deviennent extrêmement lents et WebGPU n’apparaît pas.

La page GPU du navigateur. Dans Chrome, saisissez chrome://gpu dans la barre d’adresse (dans Edge : edge://gpu). La section « Graphics Feature Status » indique pour WebGL et WebGL2 « Hardware accelerated », « Software only, hardware acceleration unavailable » ou « Unavailable », tandis que la section « Problems Detected », plus bas, précise la cause, généralement en mentionnant une entrée de la liste de blocage ou un pilote. Dans Firefox, about:support comporte une section Graphiques où « Composition » indique si l’accélération est activée, tandis qu’un journal des échecs ou des décisions explique les éventuels blocages. Safari ne possède aucune page équivalente.

Le « rendu logiciel » signifie ceci : les navigateurs tiennent une liste des combinaisons de GPU et de pilotes connues pour provoquer des plantages ou des erreurs de rendu. Lorsque votre machine correspond à une entrée, ils désactivent la fonctionnalité ou utilisent à la place un moteur de rastérisation exécuté par le processeur. La liste de blocage de Chromium désactive toute accélération GPU avec Microsoft Basic Render Driver (« l’accès au GPU est bloqué si les utilisateurs n’ont pas installé le pilote graphique approprié après l’installation de Windows »), avec VMware et VirtualBox, ainsi qu’avec les anciens pilotes Intel et NVIDIA. Les entrées reposent sur les versions des pilotes, ce qui explique pourquoi leur mise à jour résout si souvent le problème. Une chose a changé en 2026. Chromium se rabattait auparavant sur SwiftShader, une implémentation de WebGL exécutée par le processeur, chaque fois que le GPU était bloqué. WebGL « fonctionnait » donc, mais lentement. La documentation des stratégies Edge de Microsoft indique qu’à partir de la version 144, SwiftShader est obsolète et que « la création du contexte WebGL échoue dans les scénarios où SwiftShader est utilisé ». La documentation SwiftShader de Chromium dit la même chose pour Chrome, avec --enable-unsafe-swiftshader comme option d’activation explicite. Une machine sur liste de blocage qui lançait auparavant un jeu lent affiche désormais une erreur « non pris en charge ».

En résumé, le diagnostic repose sur trois questions posées dans un ordre précis, chacune associée à une seule solution.

Descendez dans la colonne de gauche et arrêtez-vous au premier non. L’ordre est important : mettre à jour le pilote ne sert à rien tant que l’accélération est désactivée, et la question de WebGPU ne se pose qu’une fois WebGL 2 fonctionnel, car l’absence de WebGPU sur une machine saine vient généralement de la plateforme et non d’une panne.

Chrome et Edge

Chrome et Edge partagent le moteur Chromium : tout ce qui suit s’applique donc aux deux. Remplacez chrome:// par edge:// lorsque nécessaire.

Le réglage de l’accélération matérielle

Ouvrez Paramètres, puis Système, et vérifiez que l’option « Utiliser l’accélération graphique si disponible » est activée. Dans Edge, elle se trouve sous Système et performances. Relancez le navigateur, car le réglage ne s’applique qu’après un redémarrage. Il est étonnamment souvent désactivé, car de nombreux conseils visant à « corriger les scintillements de Chrome » recommandent de le couper. Ouvrez ensuite chrome://gpu. Si WebGL et WebGL2 indiquent « Hardware accelerated », le problème est résolu. Sinon, le navigateur refuse volontairement votre GPU, et la raison figure sous « Problems Detected ».

Windows

Le responsable habituel est un pilote obsolète ou générique. Si le moteur de rendu indique « Microsoft Basic Render Driver », Windows ne dispose d’aucun véritable pilote pour votre GPU et Chromium bloque alors tout. Installez directement le pilote de NVIDIA, AMD ou Intel au lieu d’attendre Windows Update. Sur un ordinateur portable doté de deux GPU, Paramètres Windows, Système, Affichage, Graphiques permet d’affecter le navigateur au GPU hautes performances. Un navigateur exécuté sur la puce intégrée peut réussir la vérification tout en étant extrêmement lent dans un jeu exigeant.

Windows sur ARM, notamment les ordinateurs portables Snapdragon, constitue un cas particulier pour WebGPU : le wiki sur l’état de l’implémentation l’indique comme disponible derrière chrome://flags/#enable-unsafe-webgpu ou l’option --enable-unsafe-webgpu. WebGL 2 y fonctionne normalement.

macOS

Les Mac rencontrent rarement ce problème, car Apple fournit le pilote avec le système d’exploitation. Si Chrome signale un rendu logiciel sur un Mac, vérifiez le réglage de l’accélération, une version très ancienne de macOS ou l’utilisation d’une machine virtuelle. Mettre macOS à jour revient à mettre le pilote à jour.

Linux

C’est sous Linux que WebGPU présente le plus de restrictions. D’après le wiki, Chrome fournit WebGPU par défaut sous Linux pour les GPU Intel Gen12 et plus récents à partir de Chrome 144, ainsi que pour les GPU NVIDIA avec le pilote 535.183.01 ou plus récent sous Wayland à partir de Chrome 147. Toutes les autres configurations — AMD, anciens GPU Intel et NVIDIA sous X11 — nécessitent la série d’options indiquée par le wiki : --enable-unsafe-webgpu --ozone-platform=x11 --use-angle=vulkan --enable-features=Vulkan,VulkanFromANGLE. Le déploiement exécute WebGPU sur Vulkan tandis que le reste du navigateur demeure sur OpenGL, d’où une activation limitée à certaines familles de GPU.

Pour WebGL 2 sous Linux, il faut déterminer si Mesa utilise votre GPU ou le moteur de rastérisation logicielle llvmpipe. Si le moteur de rendu indique llvmpipe, mettez à jour les pilotes Mesa de votre GPU, ou le pilote propriétaire NVIDIA.

Ignorer la liste de blocage

chrome://flags/#ignore-gpu-blocklist (« Override software rendering list ») force Chrome à utiliser votre GPU même s’il figure sur la liste de blocage. C’est la bonne solution lorsque cette liste rejette votre GPU à tort, ou si vous préférez subir quelques anomalies occasionnelles plutôt que de ne pas avoir WebGL du tout. En revanche, ce n’est pas la bonne solution lorsque le blocage existe parce que le pilote plante : commencez donc par mettre le pilote à jour.

Chrome sur Android

WebGL 2 est disponible dans Chrome sur Android depuis la version 58. Sur n’importe quel téléphone récent, un échec de WebGL 2 indique donc généralement que le pilote GPU figure sur une liste de blocage. Sous Android, vous ne pouvez pas mettre ce pilote à jour séparément. Recherchez une mise à jour du système, puis essayez chrome://flags/#ignore-gpu-blocklist, également disponible sous Android.

WebGPU est arrivé sur Android avec Chrome 121 pour Android 12 ou plus récent et les GPU ARM, Qualcomm ou Intel, puis avec Chrome 139 pour les GPU Imagination sous Android 16 ou plus récent. Le wiki indique toujours que la prise en charge des GPU Xclipse de Samsung, présents dans les téléphones Galaxy équipés d’un processeur Exynos, est en cours. Un Galaxy Exynos entièrement à jour peut donc signaler l’absence de WebGPU. Le problème ne vient pas de votre côté.

Firefox

Accélération matérielle et contournement du blocage

Ouvrez Paramètres, Général, descendez jusqu’à Performances, décochez « Utiliser les paramètres de performance recommandés », puis vérifiez que « Utiliser l’accélération graphique matérielle si disponible » est cochée. Redémarrez Firefox. Consultez ensuite about:support, section Graphiques : « Composition » doit indiquer WebRender. Un blocage de WebGL apparaît dans le journal des échecs ou le journal des décisions, avec le pilote ou la fonctionnalité bloquée.

La page de Mozilla sur les pilotes graphiques bloqués décrit les réglages de contournement. Dans about:config, définissez webgl.force-enabled sur true pour ignorer un blocage WebGL et layers.acceleration.force-enabled sur true pour ignorer un blocage de la composition. Pour reprendre les termes de Mozilla : « faites-le à vos propres risques. Il existe généralement de bonnes raisons pour lesquelles des fonctionnalités sont bloquées ». Mettez d’abord le pilote à jour.

WebGPU : quelle version de Firefox sur quel système d’exploitation

Firefox est le navigateur où « WebGPU non pris en charge » correspond le plus souvent simplement à une limitation de la plateforme. D’après les notes de version, Firefox 141, publié le 22 juillet 2025, a activé WebGPU sous Windows. Firefox 145, publié le 11 novembre 2025, a ajouté macOS 26 Tahoe sur Apple Silicon. Firefox 147 a étendu cette prise en charge aux « appareils équipés de processeurs Apple Silicon sur toutes les versions de macOS prises en charge ». Les Mac Intel, Linux et Android restent exclus : la page des fonctionnalités expérimentales de MDN indique que, pour « d’autres plateformes telles que Linux et macOS sur processeur Intel, cette fonctionnalité est activée dans Nightly ». Le wiki prévoit Linux en 2026 et indique qu’Android nécessite un réglage expérimental.

La préférence est dom.webgpu.enabled dans about:config. Sur une plateforme où Firefox ne fournit pas encore WebGPU, la définir sur true dans la version stable expose une implémentation que Mozilla n’a pas finalisée pour ce système d’exploitation : attendez-vous donc à des plantages. Pour utiliser WebGPU avec Firefox sous Linux dès aujourd’hui, choisissez Nightly, où il est activé par défaut. Caniuse indique Firefox comme « désactivé par défaut », car le site suit les réglages expérimentaux par navigateur et non par système d’exploitation. Ne laissez donc pas cette page faire croire à un utilisateur Windows qu’il ne dispose pas de WebGPU.

Safari

Safari ne possède ni réglage d’accélération ni liste de blocage que vous puissiez contourner. Tout dépend de la version.

WebGL 2 nécessite Safari 15 ou plus récent sous macOS et iOS. La page de compatibilité d’Unity l’indique clairement : « Apple Safari ne prend pas en charge WebGL 2 dans les versions antérieures à Safari 15 ». Un Mac limité à une ancienne version de macOS ne peut pas obtenir une version plus récente de Safari. La solution consiste donc à mettre macOS à jour ou à installer Chrome ou Firefox, qui exécutent WebGL 2 sur d’anciennes versions de macOS.

WebGPU a été intégré à Safari 26.0 le 15 septembre 2025 sous macOS Tahoe, Sequoia et Sonoma, ainsi que sous iOS 26, iPadOS 26 et visionOS 26, avec une activation par défaut. L’article de lancement de WebKit indique que WebGPU « remplace WebGL sous macOS, iOS, iPadOS et visionOS, et constitue le choix recommandé pour les nouveaux sites et applications web ». Si vous utilisez Safari 26 et que WebGPU échoue toujours, vérifiez que la page est servie en HTTPS — WebGPU fonctionne uniquement dans un contexte sécurisé dans tous les navigateurs — et qu’elle ne se trouve pas dans une vue web intégrée.

Dans Safari 17 et 18, WebGPU est disponible derrière un réglage expérimental. Sous macOS, ouvrez Réglages Safari, Avancés, cochez « Afficher les fonctionnalités pour les développeurs web ». Un onglet Fonctionnalités expérimentales apparaît alors et permet d’activer WebGPU. Sous iOS 18, le chemin est Réglages, Apps, Safari, Avancé, Fonctionnalités expérimentales. Sur les anciennes versions d’iOS : Réglages, Safari, Avancé. Il s’agit de l’implémentation de préversion, adaptée à une démonstration, mais pas à la publication d’un jeu qui en dépend.

Quel que soit le navigateur corrigé, rechargez l’outil de vérification. Voici à quoi ressemble un résultat sain.

Voici ce que vous devriez voir après la correction : le triangle est rendu à 60 FPS, la ligne de rendu en direct indique WebGPU, et WebGPU comme WebGL 2 sont marqués comme pris en charge. Il est normal que WebGL 1 indique « Non » ici. L’outil demande d’abord un contexte WebGL 2 à un canevas, et un canevas ne peut conserver qu’un seul type de contexte : la vérification de l’ancienne version ne renvoie donc rien.

Ordinateurs professionnels, Chromebooks scolaires, machines virtuelles et bureaux distants

Si les réglages sont absents ou ne restent pas appliqués, vérifiez qui administre l’appareil. Les navigateurs gérés peuvent avoir l’accélération désactivée par une stratégie. Chrome et Edge disposent tous deux d’une stratégie HardwareAccelerationModeEnabled, et la documentation de Microsoft indique que, lorsqu’elle est désactivée, le navigateur « désactive l’accélération graphique ». Le commutateur dans les paramètres devient grisé ou revient à son état précédent, et chrome://policy répertorie les stratégies appliquées. Depuis Chromium 144, il existe également EnableUnsafeSwiftShader, une stratégie temporaire qui maintient actif l’ancien moteur de secours sur processeur pour les machines dépourvues de GPU. Si vous administrez une salle informatique scolaire qui vient de perdre l’accès à tous les sites WebGL, cette stratégie constitue une solution provisoire pendant que vous réglez les problèmes de pilotes.

Les machines virtuelles présentent un GPU virtuel que les navigateurs refusent. La liste de blocage de Chromium contient des entrées explicites (« Ne pas utiliser le rendu accéléré par GPU avec VMware sous Windows », « Le pilote VirtualBox est instable sous Linux », « Les pilotes Parallels antérieurs à la version 7 comportent des bugs »), qui désactivent toutes les fonctionnalités accélérées. Activez l’accélération 3D dans les paramètres de la machine virtuelle avec des outils invités à jour, ou acceptez que la VM serve à tester le fonctionnement sans GPU et jouez sur la machine hôte.

Le bureau à distance pose le même problème sous une autre forme. Une session RDP, un poste Citrix ou Horizon, ou un PC dans le cloud expose généralement une carte graphique basique ; le navigateur ne détecte donc aucun GPU exploitable. Exécutez plutôt le navigateur sur la machine locale qu’à l’intérieur de la session.

Les Chromebooks sont le cas le plus simple : ChromeOS prend en charge WebGPU depuis Chrome 113. Un échec y est donc presque toujours dû à une stratégie ou à un appareil qui ne reçoit plus de mises à jour.

L’erreur Unity « ne prend pas en charge l’API graphique WebGL 2 »

Voici le texte exact affiché aux joueurs :

Votre navigateur ne prend pas en charge l’API graphique « WebGL 2 », requise pour ce contenu.

Il provient du chargeur web de Unity lorsque la demande de contexte webgl2 renvoie null. La page de Unity sur la compatibilité des navigateurs indique que les builds Web nécessitent un navigateur « compatible WebGL 2 », WebGL 2 étant l’API graphique par défaut. Le chargeur ne dispose donc d’aucune solution de repli, sauf si le développeur en a ajouté une.

Si vous êtes joueur, voici les causes par ordre de probabilité : l’accélération matérielle est désactivée, le pilote du GPU figure sur une liste de blocage (et depuis Chromium 144, SwiftShader ne vient plus à la rescousse), vous utilisez une VM ou une session distante, ou vous êtes sous Safari 14 ou une version antérieure. Si l’outil de vérification valide WebGL 2 mais que le jeu échoue toujours, la page se trouve probablement dans un cadre intégré ou une vue web sans accès au GPU ; ouvrir directement l’URL du jeu résout alors le problème.

Si vous êtes développeur, la liste Graphics APIs dans Player Settings, Web, Other Settings détermine la fréquence à laquelle les joueurs rencontreront ce problème. Lorsque Auto Graphics API est activé, Unity essaie d’abord WebGL 2, et des discussions de la communauté signalent que le même avertissement apparaît lorsque le repli vers WebGL 1 réussit alors que WebGL 2 a échoué. Le message seul ne permet donc pas de savoir si le jeu a fonctionné. Un espace colorimétrique Linear impose uniquement WebGL 2. Ajouter « WebGL 1 (Deprecated) » permet aux très anciens navigateurs de rester compatibles, au prix de certains effets de post-traitement et formats de texture, ainsi que d’environ 1,5 Mo supplémentaires dans le fichier de données selon les mesures d’un développeur. Unity 6 permet également d’ajouter WebGPU, toujours indiqué comme expérimental, et son guide d’activation précise qu’Unity utilise la première API de la liste, puis passe aux suivantes en cas d’échec. L’ordre recommandé est donc WebGPU, puis WebGL 2. Quel que soit votre choix, remplacez le texte d’erreur par défaut de votre modèle par un message indiquant clairement au joueur la marche à suivre.

Du symptôme à la cause

Canevas noir ou vide, sans erreur. Un contexte a été créé, mais le GPU n’effectue aucun rendu. Causes habituelles : un contexte perdu juste après sa création, un GPU incapable de traiter le shader, ou une extension de confidentialité qui falsifie les informations WebGL. Essayez une fenêtre privée avec les extensions désactivées, puis recherchez dans la console des erreurs contenant « context lost » ou des erreurs de compilation de shader.

« WebGL context lost » en cours de jeu. Les notes de MDN sur la perte de contexte en donnent les raisons : plusieurs pages se disputent le GPU, un ordinateur portable bascule entre ses GPU intégré et dédié, le navigateur réinitialise le GPU pour interrompre un blocage provoqué par un autre onglet, ou un pilote se met à jour en arrière-plan. Fermez les autres onglets sollicitant fortement le GPU, branchez l’ordinateur portable pour qu’il cesse de changer de GPU, puis rechargez la page. Si cela se produit à chaque fois, le jeu épuise la mémoire du GPU de votre appareil : il s’agit alors d’un bug du jeu plutôt que d’un paramètre du navigateur.

Le jeu tourne à 1 à 5 images par seconde. Le rendu est logiciel. Vérifiez si le moteur de rendu mentionne SwiftShader, llvmpipe ou « Software », puis corrigez les paramètres d’accélération ou les pilotes. Sur un téléphone, un ratio de pixels de l’appareil de 3 signifie que neuf pixels sont dessinés pour chaque pixel CSS. Un jeu qui ne limite pas sa résolution sera donc extrêmement lent, ce qui relève de la responsabilité du développeur.

WebGPU est absent sur une machine où WebGL 2 fonctionne. Consultez d’abord le tableau. Vérifiez ensuite l’URL : navigator.gpu n’est pas défini sur les pages en simple http://. Recherchez ensuite une ligne WebGPU dans l’état des fonctionnalités graphiques. Sous Chrome sur Linux et Firefox hors Windows, la réponse est généralement « pas encore disponible sur cette plateforme ».

Pour les développeurs : détecter, prévoir un repli et informer le joueur

Détectez les deux API avant de charger quoi que ce soit de volumineux, et affichez un message en cas d’échec plutôt qu’une page vide. La méthode recommandée par MDN pour WebGPU consiste à vérifier navigator.gpu, puis à appeler requestAdapter(), qui renvoie null lorsqu’aucun adaptateur n’est disponible. Pour WebGL, getContext('webgl2') renvoie null en cas d’échec.

async function pickRenderer(canvas) {
  if (navigator.gpu) {
    const adapter = await navigator.gpu.requestAdapter()
    if (adapter) return { api: 'webgpu', adapter }
  }
  const gl2 = canvas.getContext('webgl2', { failIfMajorPerformanceCaveat: true })
  if (gl2) return { api: 'webgl2', gl: gl2 }
  const gl2soft = canvas.getContext('webgl2')
  if (gl2soft) return { api: 'webgl2', gl: gl2soft, software: true }
  return { api: null }
}

Deux détails sont importants. failIfMajorPerformanceCaveat: true fait échouer getContext au lieu de vous fournir un contexte rendu par logiciel. Vous pouvez ainsi détecter que « le jeu tournera à 2 images par seconde », avertir le joueur, puis décider malgré tout d’accepter ou non le contexte logiciel. De plus, un canevas ne peut contenir qu’un seul type de contexte : faites donc votre choix avant de le créer, ou utilisez des canevas distincts. requestAdapter() accepte également featureLevel: 'compatibility', un sous-ensemble restreint de WebGPU destiné au matériel de classe OpenGL ES 3.1 et Direct3D 11.

Gérez également la perte de contexte. Écoutez l’événement webglcontextlost, appelez preventDefault() pour indiquer au navigateur que vous comptez effectuer une récupération, puis recréez les ressources GPU dans webglcontextrestored. Les jeux qui omettent cette étape présentent le symptôme « canevas noir, sans erreur » chaque fois qu’un ordinateur portable change de GPU.

canvas.addEventListener('webglcontextlost', (e) => {
  e.preventDefault()
  pauseGame()
})
canvas.addEventListener('webglcontextrestored', () => {
  recreateGpuResources()
  resumeGame()
})

Donnez au joueur une information utile. « WebGL 2 non pris en charge » est une impasse pour un élève de douze ans utilisant un Chromebook scolaire. Un meilleur message précise ce que vous avez détecté — le navigateur, le système d’exploitation, si WebGL 1 a fonctionné et si le moteur de rendu semblait logiciel —, fournit une solution en une ligne adaptée à son navigateur et renvoie vers une page comme celle-ci ou vers l’outil de vérification, afin qu’il puisse confirmer la résolution du problème. Enregistrez également le résultat dans vos données analytiques, car la proportion de joueurs chez qui WebGL 2 échoue vous indique s’il vaut la peine de développer une solution de repli plus légère.

Les moteurs prennent en charge la majeure partie de ce travail. Le moteur de rendu WebGPU de Three.js, Babylon.js et PlayCanvas se replient automatiquement sur WebGL 2, et le guide des technologies pour les jeux web explique le rôle de chacun. Si vous utilisez directement les API, les tutoriels Premiers pas avec WebGPU et Fondamentaux de WebGL pour les jeux commencent tous deux par un bloc de détection fonctionnel.

Questions fréquentes

Comment vérifier si WebGPU est activé dans mon navigateur ?

Ouvrez l’outil de vérification WebGL et WebGPU, qui indique si WebGPU est pris en charge ainsi que le fabricant et l’architecture de l’adaptateur. Dans Chrome ou Edge, chrome://gpu répertorie WebGPU dans l’état des fonctionnalités graphiques, et dans la console, navigator.gpu vaut undefined lorsque l’API n’est pas exposée. Elle fonctionne uniquement sur les pages HTTPS.

Comment activer WebGL dans Chrome ?

Accédez à Paramètres, Système, activez « Utiliser l’accélération graphique si disponible », puis relancez Chrome. Ouvrez ensuite chrome://gpu et vérifiez que WebGL et WebGL2 sont indiqués comme « accélérés par le matériel ». Si ce n’est pas le cas, mettez à jour le pilote de votre GPU et, en dernier recours, activez chrome://flags/#ignore-gpu-blocklist.

Comment activer WebGPU dans Firefox ?

Sous Windows, WebGPU est activé par défaut depuis Firefox 141, et sur les Mac Apple Silicon depuis Firefox 145 sous macOS 26 et Firefox 147 sous toutes les versions de macOS prises en charge. WebGPU n’est pas encore disponible officiellement sous Linux, sur les Mac Intel et sous Android : la préférence dom.webgpu.enabled dans about:config expose l’implémentation inachevée, et Firefox Nightly l’active par défaut. Utilisez donc Nightly si vous en avez besoin aujourd’hui sur ces plateformes.

Safari prend-il en charge WebGPU ?

Oui, depuis Safari 26.0, publié le 15 septembre 2025, sous macOS Tahoe, Sequoia et Sonoma, iOS 26, iPadOS 26 et visionOS 26, avec une activation par défaut. Safari 17 et 18 le proposaient derrière un indicateur de fonctionnalité dans Réglages, Avancés, « Afficher les fonctionnalités pour les développeurs web ». WebGL 2 nécessite Safari 15 ou une version plus récente.

Pourquoi WebGL est-il indiqué comme bloqué ou rendu par logiciel alors que l’accélération matérielle est activée ?

Votre GPU ou son pilote figure sur la liste de blocage du navigateur, qui refuse donc de l’utiliser même lorsque l’accélération est activée. L’entrée concernée est indiquée sous « Problems Detected » dans chrome://gpu ou dans la section Graphismes de about:support sous Firefox. Mettez à jour le pilote depuis le site du fabricant du GPU et, si le blocage est obsolète, contournez-le avec chrome://flags/#ignore-gpu-blocklist ou webgl.force-enabled dans Firefox.

Pourquoi mon jeu Unity WebGL ne fonctionne-t-il pas dans le navigateur ?

Si la page affiche « Votre navigateur ne prend pas en charge l’API graphique WebGL 2 », le navigateur n’a pas pu créer de contexte WebGL 2. Activez l’accélération matérielle, mettez à jour le pilote du GPU, vérifiez que vous n’utilisez ni machine virtuelle ni session de bureau à distance et, sous Safari, passez à la version 15 ou à une version plus récente. Si l’outil de vérification indique que WebGL 2 fonctionne mais que le jeu échoue toujours, ouvrez directement l’URL du jeu plutôt que de l’utiliser dans un cadre intégré.

WebGL 2 fonctionne-t-il dans Chrome sous Android ?

Oui, depuis Chrome 58. Il fonctionne donc sur tout téléphone actuel, sauf si le pilote du GPU figure sur une liste de blocage, ce que vous pouvez corriger par une mise à jour du système ou avec chrome://flags/#ignore-gpu-blocklist. WebGPU est distinct : il nécessite Chrome 121 ou une version ultérieure sous Android 12 ou ultérieur avec un GPU ARM, Qualcomm ou Intel, Chrome 139 ou une version ultérieure pour les GPU Imagination sous Android 16 ou ultérieur, tandis que la prise en charge des GPU Samsung Xclipse est encore en cours de développement.

Contenus associés

• Test WebGL et outil de vérification WebGPU : découvrez ce que votre navigateur expose réellement, avec le nom et les limites du GPU
• WebGPU ou WebGL pour les jeux en 2026 : découvrez ces deux API et laquelle choisir pour vos créations
• Technologies des jeux web en 2026 : WebGL, WebGPU et Wasm, ainsi que les moteurs qui les utilisent
• Premiers pas avec WebGPU : votre premier code WebGPU, en commençant par la détection
• Fondamentaux de WebGL pour les jeux : l’API de référence, avec du code
• Outil de vérification de l’isolation interorigines : l’autre test pour répondre à la question « pourquoi ce jeu ne se charge-t-il pas ? », concernant SharedArrayBuffer et les threads