WebGL : capacités, confidentialité et usage pratique

WebGL fournit aux applications web une surface graphique gérée par le navigateur pour les contenus interactifs en 2D et en 3D. Il convient aux scènes qui nécessitent des dessins fréquents, une interaction spatiale ou un travail graphique difficile à exprimer clairement avec les éléments habituels d’une page. Un usage de WebGL respectueux de la confidentialité commence par une question plus précise que « que peut révéler cet appareil ? » : quel résultat graphique la personne demande-t-elle, quel niveau de prise en charge lui faut-il et quelle solution reste utilisable si le chemin préféré est indisponible ?

La prise en charge n’est pas une simple réponse par oui ou par non. Dans un environnement donné, un navigateur peut fournir WebGL 1, WebGL 2, les deux ou aucun. Une fonction disponible sur un appareil peut manquer sur un autre en raison des règles du navigateur, du logiciel graphique, des choix du système d’exploitation ou des limites de ressources. Une application doit traiter ces différences comme des paramètres de compatibilité, et non comme un motif pour recueillir un profil détaillé de l’appareil.

Cette distinction sépare la gestion normale des capacités du suivi. Une application graphique peut avoir besoin de savoir si elle peut afficher une scène demandée. Elle a rarement besoin de conserver un vaste inventaire de l’appareil à l’origine de cette décision. Pour connaître la technique de suivi et son impact sur la confidentialité, consultez l’aperçu de l’empreinte WebGL. Pour l’API graphique plus récente et son modèle de prise en charge distinct, consultez le guide de confidentialité WebGPU.

Choisir WebGL pour une tâche graphique précise

Commencez par le résultat que la personne doit voir ou contrôler. WebGL sert souvent aux cartes interactives, aux vues de produits, à la visualisation scientifique, aux jeux, aux simulations et aux effets d’image. Ces tâches peuvent impliquer de nombreux objets, des mises à jour fréquentes ou des changements qui tirent parti d’une chaîne graphique dédiée. Le choix est justifié lorsqu’il rend la tâche visible possible ou l’améliore nettement.

Tout visuel n’a pas besoin de WebGL. Une illustration statique peut mieux convenir sous forme d’image. Un graphique simple peut être plus facile à lire, à imprimer et à parcourir avec des éléments sémantiques de page ou un composant accessible. Les commandes ordinaires appartiennent au HTML, dont les libellés, le focus, la sélection de texte, la traduction et l’assistance technologique sont bien pris en charge. Choisir une surface plus simple réduit le travail de développement et les décisions de compatibilité que l’application doit gérer.

Cette distinction compte aussi pour la confidentialité. Si une page utilise WebGL uniquement pour un résultat visuel précis, elle peut limiter ses vérifications à ce résultat. Une page qui initialise des graphismes sans objectif visible et recueille de nombreuses informations sur l’environnement crée une autre relation avec la personne. L’API technique peut être la même, mais l’usage des données, leur conservation et les attentes de la personne diffèrent.

Définissez l’expérience minimale avant de commencer l’implémentation. Précisez la scène, les interactions importantes, la qualité visuelle acceptable et le moment où une représentation plus simple suffit. Une vue de produit peut exiger rotation et zoom, mais pas des effets cinématographiques. Une visualisation de données peut nécessiter des sélections et des libellés clairs sans animation continue. Ces choix aident l’application à demander uniquement la prise en charge graphique qu’elle utilise réellement.

Dans la mesure du possible, gardez les actions essentielles du produit en dehors de la surface de dessin. La navigation, les commandes d’achat, les actions de compte, les choix de consentement et les liens d’aide doivent rester des commandes ordinaires de la page. La scène WebGL peut soutenir la tâche sans devenir le seul moyen de parcourir l’application. Cela facilite aussi la reprise si le contexte graphique devient indisponible après le chargement.

Le mouvement et la densité visuelle nécessitent leurs propres limites. Une scène animée peut exprimer un changement spatial, mais un mouvement continu peut distraire ou gêner. Respectez la préférence de réduction des animations, proposez une commande de pause lorsque le mouvement n’est pas essentiel et ne faites pas dépendre les instructions d’une animation brève. La personne doit encore comprendre l’état de l’expérience lorsque la scène est immobile.

L’utilisation des ressources est aussi un choix de produit. Les scènes détaillées peuvent consommer de la mémoire, de la batterie et du temps de traitement. L’application doit adapter son contenu selon le déroulement réel de la tâche et les choix explicites de qualité, sans tenter de déduire une identité détaillée de l’appareil. Proposez un niveau de détail inférieur lorsqu’il est utile et conservez la tâche principale lorsque des effets facultatifs sont supprimés.

Un objectif précis facilite également la maintenance. Si une mise à jour du navigateur modifie le comportement graphique, l’équipe peut comparer le résultat touché à une exigence définie. Sans cette exigence, le travail de compatibilité tend à devenir une recherche sans limite de différences environnementales. Une responsabilité claire transforme WebGL en composant applicatif circonscrit plutôt qu’en vérification générale des capacités.

Traiter la prise en charge WebGL comme un contrat de compatibilité

Les spécifications WebGL de Khronos définissent le contrat de plateforme pour WebGL et WebGL 2. MDN documente l’API du point de vue d’une application et décrit la relation entre les deux générations. WebGL 2 ajoute des capacités de plateforme à WebGL 1, mais sa présence ne doit pas être supposée simplement parce que le navigateur est récent. L’environnement effectif comprend le navigateur, le système d’exploitation, la pile graphique, les règles administratives et l’état des ressources.

Une application a donc besoin d’un niveau minimal de prise en charge explicite. Décidez si WebGL 1 suffit, si WebGL 2 est nécessaire ou si l’expérience propose plusieurs niveaux de qualité. Reliez ce choix aux fonctions visibles. Si une fonction dépend réellement du contrat plus récent, expliquez pourquoi le chemin inférieur ne peut fournir le même résultat. Si la différence ne concerne que la finition visuelle, gardez l’interaction principale sur le chemin le plus largement pris en charge.

Les vérifications de capacité doivent répondre à une question précise de l’application. Il peut s’agir de savoir si le contexte graphique requis peut être créé, si la scène peut être rendue au niveau de qualité pris en charge ou si une entrée multimédia nécessaire est utilisable. Arrêtez-vous dès que l’application dispose de l’information nécessaire pour choisir un chemin compatible. Un inventaire complet de l’environnement n’est pas requis pour choisir entre une scène standard, une scène réduite et une autre solution sans WebGL.

La création du contexte peut échouer même si une visite précédente a réussi. La personne peut modifier les réglages du navigateur, une mise à jour système peut changer la prise en charge graphique, un administrateur peut appliquer une règle ou le navigateur peut refuser la demande dans les conditions présentes. Traitez l’échec comme une branche normale du produit. Ne laissez ni canevas vide, ni chargement sans fin, ni commande désactivée sans explication.

La prise en charge peut aussi changer pendant que la page est ouverte. Le navigateur peut perdre un contexte graphique lorsque des ressources sont récupérées ou que l’environnement graphique change. Conservez l’interface autour de la scène, expliquez simplement ce qui s’est passé et proposez une action de reprise limitée. Si la restauration risque de supprimer du travail non enregistré, expliquez-le avant de réessayer et gardez si possible l’état de l’application en dehors de la surface graphique.

Une fois la tentative de reprise limitée épuisée, cessez les nouvelles tentatives et affichez le repli HTML équivalent avec les mêmes données de tâche et commandes essentielles. Conservez l’état de l’application déjà placé hors du canevas ; ne prétendez pas pouvoir récupérer un état qui n’existait que dans le contexte graphique perdu. Il s’agit d’une limite du parcours produit : le fixture actuel n’a observé qu’une restauration réussie et n’a pas vérifié la branche d’échec de restauration.

Ne transformez pas chaque différence environnementale en variante du produit. Quelques niveaux fondés sur des résultats sont plus simples à tester et à expliquer que de nombreuses branches propres à un appareil. Par exemple, un mode standard, un mode aux effets réduits et une solution statique sont des expériences concrètes dont l’équipe peut être responsable. Ils limitent aussi les informations de capacité que l’application doit traiter.

Attribuez clairement la responsabilité de la prise en charge par version. Consignez les familles et plages de versions de navigateurs prises en charge, la génération WebGL requise par chaque expérience et la solution de repli hors de cette plage. Cette trace relève de la politique de compatibilité du produit. Elle ne doit pas promettre que chaque appareil ou pilote graphique produira des pixels identiques.

Les déclarations de compatibilité doivent décrire les résultats, pas les détails internes. « La rotation interactive est disponible » est utile. Une longue liste de détails graphiques sous-jacents est plus difficile à interpréter et peut révéler davantage que nécessaire pour la décision. Une formulation fondée sur le résultat reste aussi plus stable lorsque le navigateur modifie son implémentation tout en conservant le même comportement visible.

Revoyez le contrat lorsque le produit ajoute une technique visuelle, augmente la complexité de la scène, change les entrées multimédias ou exige WebGL 2. Une nouvelle version du navigateur n’impose pas à elle seule de réécrire la politique. Modifiez le contrat lorsque les besoins visibles ou les éléments de prise en charge vérifiés changent.

Construire une amélioration progressive et des solutions utiles

L’amélioration progressive maintient l’utilité de la page avant la confirmation du chemin graphique préféré. Affichez d’abord en HTML ordinaire le contenu autour de la scène, les commandes, les libellés et l’état. Ajoutez l’expérience WebGL lorsque le navigateur peut accomplir la tâche nécessaire. La personne dispose ainsi d’éléments compréhensibles si les scripts tardent, si l’initialisation graphique échoue ou si une règle empêche la création du contexte.

Les solutions de repli doivent conserver l’objectif, pas imiter chaque détail visuel. Une vue de produit en trois dimensions peut utiliser une galerie d’images bien choisies. Une carte interactive peut proposer une liste consultable, un résumé d’itinéraire ou une carte statique adaptée à la tâche. Une visualisation scientifique peut inclure un tableau, les principaux constats et un format de données téléchargeable. Un jeu peut afficher un message clair d’indisponibilité s’il n’existe aucune interaction équivalente, mais les commandes de compte et d’achat doivent rester utilisables.

La solution de repli doit correspondre au même état des données. Si les filtres modifient la visualisation WebGL, le tableau ou le résumé doit refléter ces filtres. Si une option choisie modifie le modèle de produit représenté, la galerie et la description doivent changer également. Deux représentations incohérentes créent un problème d’accessibilité et un problème de correction du produit.

Ne présentez pas une qualité visuelle réduite comme une erreur si elle permet toujours d’accomplir la tâche. Une scène aux effets réduits peut être un mode pris en charge, pas une version défectueuse du mode préféré. Expliquez les différences qui influent sur l’interaction ou le sens, sans imposer à la personne des détails d’implémentation. Un réglage de qualité simple permet un choix prévisible sans exiger de connaître l’environnement graphique.

Le chargement nécessite lui aussi une solution définie. Les grandes scènes et textures peuvent demander du temps même lorsque WebGL est disponible. Affichez une progression correspondant au travail réel de l’application, laissez une commande d’annulation et évitez les téléchargements lourds avant l’accès à la fonction. Si des ressources facultatives échouent, conservez les parties de la scène qui permettent encore la tâche au lieu d’abandonner toute l’expérience.

Le réseau peut affecter une expérience WebGL indépendamment de la prise en charge graphique. Le navigateur peut créer le contexte avec succès alors qu’un modèle, une image ou un fichier de données reste indisponible. Signalez ces situations séparément. Dire que WebGL n’est pas pris en charge lorsqu’une ressource manque conduit à de mauvaises décisions d’assistance et à une collecte inutile de capacités.

Conservez les entrées de la personne lors d’un changement de chemin. Si elle configure un produit, choisit un lieu ou modifie une plage de données avant l’échec de l’initialisation graphique, reportez ses choix dans la solution de repli. Ne lui faites pas refaire son travail parce que la couche de présentation a changé. Garder l’état de l’application hors de la scène facilite cette continuité.

Testez volontairement les solutions de repli. Vérifiez l’expérience sans WebGL, sans WebGL 2, avec des ressources facultatives bloquées ou lentes, ainsi qu’après une perte de contexte pendant l’interaction. Ces tests couvrent des branches du produit, pas l’identification d’appareils. Le résultat attendu est un état utilisable avec des actions claires, pas un catalogue des différences de chaque environnement.

Reliez l’aide à des symptômes observables. Les instructions peuvent expliquer comment réessayer, choisir la vue simplifiée, conserver le travail ou contacter l’assistance avec une référence d’erreur ordinaire. Ne demandez pas par défaut un rapport graphique étendu. Si un dossier d’assistance nécessite des diagnostics, demandez uniquement les éléments pertinents, expliquez leur usage et fixez une durée de conservation.

Garder l’expérience accessible en dehors de l’image matricielle

Un canevas WebGL affiche des pixels. Les objets qu’il contient ne deviennent pas automatiquement des titres, boutons, champs de formulaire ou un ordre de lecture compréhensible par les technologies d’assistance. L’accessibilité dépend donc de l’interface autour du canevas et des informations équivalentes fournies par la page.

Donnez au visuel un nom et une description accessibles et concis qui indiquent son but. « Vue interactive du produit » est plus utile que « canevas WebGL ». Si la scène présente des données, fournissez les valeurs, relations ou conclusions importantes sous forme de texte ou de contenu structuré. Si elle permet des actions, proposez des commandes atteignables et compréhensibles sans dépendre uniquement de la position du pointeur dans l’image.

L’accès au clavier nécessite un véritable modèle d’interaction. La personne doit pouvoir atteindre la fonction, comprendre les actions disponibles, déplacer le focus de façon prévisible et quitter la fonction sans rester bloquée. Des boutons ordinaires pour zoomer, réinitialiser, mettre en pause, changer de vue ou effectuer d’autres actions importantes sont plus faciles à nommer et à utiliser que des zones invisibles dans un dessin. Gardez l’indication de focus visible sur la page et la scène.

N’exprimez pas le sens uniquement par la couleur, la profondeur, le mouvement ou des détails visuels fins. Les graphiques ont besoin de libellés et de motifs distinctifs. Les cartes ont besoin d’informations textuelles sur les lieux. Les changements d’état doivent être annoncés en dehors de l’effet visuel. Un avertissement qui ne paraît que sous la forme d’un bref flash rouge peut être manqué ou ne pas être perçu comme prévu.

Le texte intégré à une scène graphique a des limites pratiques. Il ne réagit pas nécessairement au zoom du texte, à la traduction, à la sélection, aux préférences de contraste ou aux outils de lecture comme le texte HTML. Utilisez du texte de page pour les instructions, libellés, avis juridiques, prix et autres informations à lire précisément. Réservez le texte dessiné aux cas où il fait réellement partie du visuel et donnez le même sens ailleurs.

Respectez les préférences de mouvement avant de lancer une animation. Réduisez ou retirez les mouvements de caméra, effets de particules et transitions automatiques non essentiels lorsque la personne demande moins de mouvement. La commande de pause doit arrêter les mouvements continus significatifs, pas seulement masquer un effet pendant que la scène continue à changer. L’état immobile doit toujours présenter la tâche et le résultat actuel.

Les interactions tactiles, au pointeur et au clavier doivent mener aux mêmes résultats importants. Un geste peut rendre l’usage d’une scène agréable, mais ne doit pas être l’unique façon de choisir un produit, examiner une donnée ou poursuivre un parcours. Proposez des commandes et des indications adaptées aux modes d’entrée pris en charge, sans supposer comment la personne interagira à partir de la taille de l’écran.

Les tests d’accessibilité doivent couvrir les mêmes états du produit que les tests visuels. Comme recommandation d’acceptation, vérifiez le chemin WebGL préféré, le chemin réduit, le repli, le chargement, les messages d’échec et la restauration du contexte. Contrôlez les noms, l’ordre du focus, le clavier, les annonces de lecteur d’écran, le zoom, le contraste et la réduction du mouvement avec les outils adaptés au public. Le fixture runtime actuel n’a vérifié que le nom du canevas et le texte de repli visible ; il n’a pas vérifié ces comportements, qui restent donc une recommandation et non un résultat du fixture. Une scène qui ne passe qu’une revue visuelle n’est pas complète.

Lorsqu’une interaction non visuelle entièrement équivalente est impossible, exposez honnêtement la limite et proposez le chemin pratique le plus proche du même résultat. Il peut s’agir d’une vue de données structurée, d’un parcours avec assistance ou d’un formulaire différent. La limite doit être un choix produit attribué, pas l’hypothèse que chaque personne peut utiliser l’image.

Limiter les données de confidentialité à la décision du produit

L’extension WEBGL_debug_renderer_info expose les chaînes du fabricant et du moteur de rendu du pilote graphique. MDN indique que ces données ne devraient généralement servir que dans des cas particuliers pour optimiser un contenu WebGL ou déboguer des problèmes de GPU, et que les réglages de confidentialité du navigateur peuvent limiter l’extension. Pour les vérifications ordinaires de compatibilité, il suffit de déterminer si le chemin nécessaire peut s’exécuter.

Utilisez uniquement la décision minimale qui permet de choisir un chemin pris en charge. Si l’application doit seulement savoir si sa scène standard démarre, ne recueillez pas un rapport détaillé sur l’environnement. Si elle choisit entre deux niveaux de qualité qu’elle propose, conservez le niveau choisi plutôt que chaque donnée ayant motivé ce choix. La minimisation des données facilite la documentation, les tests et le retrait du comportement.

Gardez les informations de compatibilité dans la session lorsque leur conservation durable est inutile. Une page peut choisir un chemin graphique pour la visite en cours sans en faire un identifiant persistant. S’il est utile de mémoriser une préférence de qualité choisie par la personne, conservez-la comme un choix compréhensible et modifiable. Ne présentez pas un profil technique déduit comme une préférence explicitement choisie.

Ne combinez pas les informations graphiques avec les données de compte, de réseau ou d’autres données du navigateur sans besoin clair et expliqué du produit. La combinaison change l’impact sur la confidentialité même si chaque valeur prise isolément semble ordinaire. Le guide sur les surfaces combinées du navigateur explique pourquoi plusieurs surfaces peuvent révéler davantage que chacune séparément.

Les diagnostics doivent être traités séparément de la compatibilité en cours d’utilisation. Les journaux opérationnels doivent consigner le résultat du produit, par exemple un échec d’initialisation de la scène ou de chargement d’une ressource, sans inventaire graphique étendu par défaut. Si une enquête d’assistance exige des détails supplémentaires, demandez-les dans le contexte du dossier, expliquez la collecte, restreignez l’accès et supprimez-les selon une durée définie.

N’utilisez pas les différences de capacité pour tirer des conclusions sensibles sur une personne. La prise en charge graphique n’établit pas de manière fiable l’identité, le revenu, le handicap, le lieu ou l’intention. Les décisions du produit doivent rester liées à la possibilité d’exécuter le visuel demandé. Les déductions étendues augmentent le risque pour la confidentialité sans améliorer la tâche graphique.

Les bibliothèques graphiques et analytiques tierces peuvent élargir le flux de données. Vérifiez ce qu’une bibliothèque recueille, quels services reçoivent les informations, si la collecte est nécessaire à l’affichage et combien de temps les données sont conservées. Charger un composant par commodité visuelle ne dégage pas l’application de sa responsabilité concernant les données qu’il envoie.

Si un usage indépendant des données est facultatif, le texte de consentement doit nommer son objectif réel. Une formule générale sur l’amélioration des performances ne suffit pas lorsque des diagnostics détaillés sont conservés ou partagés. Offrez un choix réel lorsque cet usage est facultatif et maintenez, si possible, l’expérience principale sur le chemin pris en charge le moins intrusif.

La revue de confidentialité doit aussi couvrir les échecs. Une page de repli peut charger par erreur un autre module analytique, demander un rapport de diagnostic plus large ou révéler des détails d’erreur internes. Appliquez les mêmes règles de minimisation et de conservation aux états préféré, réduit et en échec. L’échec des graphismes ne justifie pas une collecte supplémentaire sans objectif clair.

Pour cette revue, capturez les requêtes réseau et les journaux d’assistance ou d’exploitation autour du démarrage normal, de l’indisponibilité de WebGL 2, de la perte de contexte et du repli HTML. Vérifiez qu’aucun inventaire de moteur de rendu ou de pilote n’est émis par défaut, que les champs d’assistance ont une finalité limitée et que des dates de conservation et de suppression sont définies. Ce sont des contrôles d’observabilité recommandés, pas des conclusions runtime : les fixtures actuels n’ont pas inspecté le trafic réseau, les charges analytiques, les champs de journal, les contrôles d’accès ni la conservation.

Attribuez un responsable à chaque champ de compatibilité conservé. Indiquez qui l’utilise, quelle décision en dépend, quand il expire et ce qui se passe lors du retrait de la fonction graphique. Supprimez les champs sans décision actuelle ni responsable. La maintenance de la confidentialité devient ainsi une pratique ordinaire du produit plutôt qu’une revue occasionnelle de données inexpliquées.

Relier les sources aux affirmations et aux éléments de compatibilité

Utilisez les spécifications publiques et la documentation des API pour relier chaque affirmation de compatibilité à un résultat observable de l’application :

• Disponibilité de WebGL et de WebGL 2 : La spécification WebGL 1.0 de Khronos et la spécification WebGL 2.0, avec la référence MDN de l’API WebGL, décrivent les deux générations de contexte et leurs capacités. Le résultat est vérifiable : demandez le contexte requis par la fonction, puis choisissez la scène standard, la scène réduite ou le repli sans WebGL lorsque ce contexte est indisponible. Cette vérification ne nécessite pas de profil d’appareil.
• Perte et reprise du contexte : MDN documente les événements webglcontextlost et webglcontextrestored. Le résultat est vérifiable : conservez l’état hors du canevas, annoncez la perte, tentez une reprise limitée et proposez le repli si elle échoue.
• Limite de confidentialité de WEBGL_debug_renderer_info : La référence MDN de l’extension explique que les chaînes du fabricant et du moteur sont facultatives, peuvent être limitées par les réglages de confidentialité et sont destinées aux cas particuliers d’optimisation ou de débogage du GPU. Le résultat est vérifiable : la sélection ordinaire de compatibilité fonctionne sans cette extension ; un diagnostic d’assistance, s’il est nécessaire, a un objectif explicite et une conservation limitée au lieu de devenir un profil persistant.

Ces liens étayent les affirmations sur le comportement de la plateforme ; les tests du produit doivent vérifier les résultats visibles ci-dessus, sans comparer les pixels, profiler les appareils ni tenter d’identifier un navigateur.

Matrice d’acceptation des capacités, du repli et de la perte de contexte

Utilisez cette matrice courte comme conseil d’acceptation de l’application. Chaque ligne associe une source publique, un résultat observable et une limite de confidentialité ; elle ne constitue pas une garantie de prise en charge inter-navigateurs ou en production :

Cas	Condition étayée par la source	Résultat observable de l’application	Limite de confidentialité
Vérification de capacité	Création du contexte selon WebGL 1.0 et WebGL 2.0.	Le contexte requis est demandé ; la scène standard ou réduite démarre, ou une représentation sans WebGL utilisable est choisie.	Limitez le résultat à la décision de chemin de la session. Ne recueillez pas les détails du moteur, du pilote ou de la version du navigateur uniquement pour ce choix.
Repli	Les mêmes références d’API définissent l’indisponibilité du contexte demandé ; la référence MDN de l’API WebGL décrit la surface applicative.	Le repli conserve le même état de données, les commandes essentielles et le résultat de la tâche, avec un message clair plutôt qu’un canevas vide.	Consignez seulement le résultat (par exemple, context-unavailable) ; ne transformez pas ce chemin en demande de diagnostics plus large.
Perte et reprise du contexte	MDN documente les événements webglcontextlost et webglcontextrestored.	L’interface et l’état restent disponibles, une reprise limitée est tentée et la personne peut choisir le repli en cas d’échec.	Ne conservez pas d’inventaire graphique par défaut. Un diagnostic d’assistance doit être séparé, limité à son objectif et conservé pendant une durée définie.

L’acceptation signifie que le résultat visible réussit dans chaque ligne ; elle ne signifie pas que l’application peut identifier l’appareil ou reproduire des pixels identiques.

Vérifications d’acceptation reproductibles de l’application

Effectuez ces vérifications avec un même jeu de test de l’application et les mêmes données de tâche. Notez la version du navigateur, la révision de l’application et le chemin affiché à la personne. Le test porte sur un résultat du produit, pas sur la collecte d’une description de l’appareil.

Vérification	Préparation reproductible	Résultat observable	Objectif exclu de confidentialité
Création du canevas et du contexte	Chargez le jeu de test, créez le canevas et demandez le contexte requis par la fonction selon les spécifications WebGL de Khronos.	Le canevas signale un contexte utilisable et la scène standard atteint son état prêt ; si la création renvoie null, la page affiche l’alternative sans WebGL avec les mêmes données de tâche.	Ne lisez pas les détails du moteur, du pilote ou de la version du navigateur pour expliquer une réussite ou un échec.
Fonction requise indisponible	Laissez la création du contexte active, puis rendez indisponible la fonction ou l’extension WebGL 2 requise ; utilisez getExtension() sur MDN comme référence.	L’application détecte l’exigence manquante, choisit le chemin réduit ou le repli prévu, conserve les commandes et l’état et affiche un message limité.	N’énumérez pas toutes les extensions prises en charge et ne déduisez pas une classe d’appareil de la fonction manquante.
Perte du contexte	Pendant la scène prête, déclenchez le chemin de perte documenté et observez webglcontextlost.	Les commandes hors canevas restent utilisables, la perte est annoncée et l’application n’entre pas dans une boucle de réinitialisation illimitée.	Ne transformez pas l’événement en inventaire graphique ni en identifiant persistant.
Contexte rétabli ou reprise échouée	Laissez arriver webglcontextrestored, ou faites échouer la tentative de reprise limitée.	La scène revient à l’état prêt avec les données conservées, ou la personne peut choisir le repli avec un message de reprise clair.	Ne comparez pas les pixels et ne conservez pas de champs de diagnostic hors du cas d’assistance approuvé et limité dans le temps.

L’acceptation correspond à l’état visible et à la tâche accomplie dans chaque ligne. L’identification de l’appareil, la classification du moteur, la correspondance des pixels et l’idée que la prise en charge de WebGL prouverait une identité sont exclues de ce test.

Lire le résultat d’un seul jeu de test

L’enregistrement runtime-20261005 est un échantillon de reprise réussie de l’application. L’enregistrement complémentaire webgl-api-capabilities-and-recovery-failure-runtime-20261001 est un modèle déterministe de l’état de l’interface : il vérifie une tentative de reprise limitée, conserve la sélection, déplace le focus, affiche un repli HTML équivalent et n’émet aucune demande de diagnostic depuis ce jeu de test. Le modèle ne crée pas de contexte WebGL et ne démontre pas qu’un événement webglcontextlost réel atteint un moteur de production. Les deux enregistrements sont des observations locales de Chromium, et non une déclaration de compatibilité entre navigateurs ou de production ; répétez les vérifications réelles dans chaque environnement dont le produit assume explicitement la responsabilité.

Valider la compatibilité sans créer de profil d’appareil

Les tests de compatibilité doivent partir de résultats visibles par la personne. Vérifiez que la scène se charge, que les commandes répondent, que le contenu essentiel reste lisible, que la tâche demandée peut être accomplie et que les solutions de repli conservent l’état. Ces critères restent utiles après les mises à jour graphiques et du navigateur, car ils décrivent l’expérience promise par l’application.

Utilisez un ensemble documenté d’environnements pris en charge plutôt que de tenter de représenter tous les appareils possibles. Incluez les familles de navigateurs, systèmes et plages de versions qui comptent pour le produit. Dans cet ensemble, couvrez le chemin préféré, les niveaux de prise en charge inférieurs et l’alternative sans WebGL. L’objectif est la confiance dans les expériences dont l’équipe est responsable, pas une base de différences environnementales.

Limitez les scènes de test aux fonctions du produit. Un test de carte doit exercer les couches, libellés, sélections et déplacements réellement utilisés. Un test de vue de produit doit couvrir le chargement, la rotation, le zoom, les changements d’option et la reprise. Une démonstration graphique générale peut montrer que WebGL fonctionne, mais ne prouve pas que les ressources, interactions et replis du produit fonctionnent.

Vérifiez que l’objet, l’état, le libellé ou la relation de données demandés sont présents et utilisables. Consignez les échecs par rapport à ce résultat du produit. Le test doit déterminer si l’expérience fonctionne, pas caractériser l’appareil.

Séparez les changements du navigateur des modifications d’éléments et d’application. Fixez les entrées de test lorsque la reproductibilité compte, consignez la révision de l’application et notez la version du navigateur utilisée. En cas de changement de scène, ces informations aident à distinguer une nouvelle ressource, une modification du code, une mise à jour d’une dépendance ou un changement de comportement du navigateur. Elles facilitent la maintenance sans créer de profil durable des personnes.

Testez la perte et la reprise du contexte comme un comportement du produit. Conservez les commandes externes, l’état de l’application et un message d’état clair. Vérifiez que les tentatives de reprise sont limitées et que la personne peut choisir la solution de repli. Une boucle qui réinitialise sans cesse des graphismes lourds peut rendre la page moins utilisable et consommer des ressources sans rétablir la tâche.

Vérifiez aussi la confidentialité pendant les tests. Confirmez que le démarrage normal n’envoie pas d’inventaire graphique inutile, que le repli n’active pas des diagnostics plus larges et qu’une préférence de qualité mémorisée reflète un choix de la personne plutôt qu’une déduction opaque. Vérifiez que les journaux d’assistance ne contiennent que les champs de résultat limités approuvés par l’équipe.

La revue de version doit se concentrer sur les changements qui influent sur le contrat. Une nouvelle version du navigateur peut modifier la disponibilité, les performances, la gestion des ressources ou le comportement visuel. Une version de l’application peut ajouter une technique graphique ou accroître les besoins en ressources. Relancez les parcours concernés et mettez à jour l’aide uniquement lorsque les éléments changent une exigence visible.

Le processus de validation des versions du navigateur fournit un cadre plus large pour des mises à jour contrôlées. Pour WebGL, gardez le jeu de régression assez réduit afin que chaque scène ait un objectif nommé. Un petit ensemble de scènes du produit est plus utile que de nombreux exemples sans lien avec son comportement.

WebGL convient comme couche de présentation limitée avec une tâche claire, un niveau minimal écrit, des alternatives utiles et des tests fondés sur les résultats. Ne demandez que les capacités nécessaires pour choisir une expérience dont l’équipe est responsable. Gardez les actions et le sens essentiels accessibles hors de l’image, limitez les diagnostics conservés et examinez les changements selon le contrat visible. Ces pratiques permettent des graphismes web fonctionnels sans transformer la compatibilité en profilage d’appareil.

Sources publiques

• Spécifications WebGL de Khronos
• MDN : API WebGL
• MDN : WEBGL_debug_renderer_info