3D dans le navigateur : technologies et frameworks
3D dans le navigateur : technologies et frameworks
Le web est devenu discrètement une plateforme sérieuse pour les expériences 3D. Ce qui a commencé par de simples cubes tournants a évolué en configurateurs de produits pour les grandes marques, en visualisations de données pour les scientifiques, en jeux à grande échelle et en expériences immersives de réalité augmentée/réalité virtuelle — le tout fonctionnant dans un onglet de navigateur, sans installation requise.
Les technologies de base qui alimentent la 3D web
À la base, il y a quelques technologies clés qui rendent tout cela possible. Considérez-les comme les couches d'un gâteau — chacune repose sur la précédente.
WebGL 2 est la base universelle. Il est présent dans tous les navigateurs depuis des années, il est stable et dispose d'un vaste écosystème d'outils et de bibliothèques. Si vous construisez pour le web aujourd'hui, WebGL 2 est ce sur quoi votre code s'exécute finalement, que vous l'écriviez directement ou que vous utilisiez un framework par-dessus.
WebGPU est la nouvelle venue brillante. C'est une API graphique moderne de bas niveau qui donne aux développeurs un contrôle plus direct sur le GPU — similaire à Vulkan, Metal ou DirectX 12 sur les plateformes natives. Elle permet les shaders de calcul (utilisation du GPU pour des calculs généraux, pas seulement graphiques), un meilleur multithreading et des performances plus prévisibles. La prise en charge des navigateurs croît rapidement : elle est disponible dans Chrome et Edge, disponible derrière un flag dans Firefox et dans Safari Technology Preview. Pour les nouveaux projets où les performances comptent, il vaut la peine d'y prêter attention.
WebXR est la façon d'apporter la réalité virtuelle et augmentée au navigateur. C'est l'API standard pour les casques VR comme Meta Quest, Apple Vision Pro et même les simples visionneuses Cardboard, ainsi que pour la RA sur les téléphones et tablettes. WebXR gère le travail complexe de suivi de la position de la tête, de rendu des vues stéréoscopiques et de gestion des entrées du contrôleur — afin que vous puissiez vous concentrer sur la construction de l'expérience.
WebAssembly (Wasm) mérite également une mention. Il permet d'exécuter du code écrit en C++, Rust ou d'autres langages à une vitesse quasi native dans le navigateur. C'est ainsi que des moteurs lourds comme Unity, Unreal et Godot peuvent exporter vers le web — ils compilent leur cœur C++ en WebAssembly et l'exécutent aux côtés de JavaScript.
Enfin, les formats de compression de textures GPU comme Basis Universal et KTX2 vous permettent d'expédier des textures qui restent compressées dans la mémoire GPU, économisant ainsi la bande passante et la mémoire — crucial pour les appareils mobiles.
Frameworks de haut niveau : vous ne voulez probablement pas écrire du WebGL brut
Écrire du WebGL brut, c'est comme construire un moteur de voiture à partir de zéro — possible, mais rarement la meilleure utilisation de votre temps. Les frameworks gèrent le code passe-partout, fournissent des abstractions utiles et vous permettent de penser en termes de scènes, d'objets et de matériaux plutôt qu'en termes de tampons, de shaders et d'appels de dessin.
Three.js est le roi incontesté de l'écosystème. Il existe depuis 2010, possède une immense communauté, une excellente documentation et fonctionne avec tous les principaux formats 3D. Il vous offre un graphe de scène (un arbre d'objets), des caméras, des lumières, des matériaux, des géométries, des systèmes d'animation, des effets de post-traitement et des chargeurs pour GLTF, OBJ, FBX, etc. L'écosystème React l'a adopté via React Three Fiber (R3F), qui vous permet d'écrire des scènes Three.js de manière déclarative en tant que composants React — un changement de jeu si vous construisez déjà avec React.
Babylon.js adopte une approche différente — c'est plus comme un moteur de jeu complet dans le navigateur. Il dispose d'un puissant éditeur visuel, d'une physique intégrée, d'un éditeur de matériaux basé sur les nœuds, d'un excellent support TypeScript et d'une implémentation WebXR de première classe. Si vous construisez quelque chose qui ressemble à un jeu ou si vous avez besoin d'un flux de travail piloté par un éditeur, Babylon.js est un excellent choix.
PlayCanvas est unique car il est natif du cloud. L'éditeur s'exécute dans votre navigateur, votre projet vit dans le cloud et plusieurs personnes peuvent collaborer en temps réel. Il utilise une architecture de système entité-composant et est populaire auprès des équipes qui construisent des publicités jouables, des jeux instantanés et des outils 3D collaboratifs.
A-Frame adopte une approche déclarative, de type HTML. Vous écrivez des scènes 3D sous forme d'éléments HTML personnalisés :
OGL est le choix du minimaliste — juste quelques kilo-octets, sans opinion, juste une fine couche au-dessus de WebGL. Idéal pour les projets à taille limitée comme les bannières publicitaires ou lorsque vous voulez construire vos propres abstractions à partir de zéro.
L'écosystème React : la 3D pilotée par les composants
Si vous êtes un développeur React, React Three Fiber (R3F) est transformateur. C'est un moteur de rendu React pour Three.js — ce qui signifie que vous écrivez votre scène 3D en utilisant JSX, comme votre interface utilisateur.
L'écosystème R3F s'est enrichi d'outils. @react-three/drei vous donne des dizaines de composants prêts à l'emploi : contrôles d'orbite, superpositions HTML, texte, cartes d'environnement, chargeurs, etc. @react-three/postprocessing apporte des effets de post-traitement. @react-three/rapier et @react-three/cannon-es ajoutent de la physique. Vous pouvez construire des applications 3D étonnamment complexes avec très peu de code passe-partout.
Pour WebXR dans React, il y a React XR, qui apporte la même approche déclarative au développement AR/VR.
Formats de fichiers : glTF est le JPEG de la 3D
Si vous mettez de la 3D sur le web, glTF 2.0 (GL Transmission Format) est la norme. On l'appelle souvent le "JPEG de la 3D" — un format libre de droits, efficace et prêt à l'exécution, maintenu par le Khronos Group (les mêmes personnes derrière WebGL et WebGPU).
glTF se décline en deux versions : .gltf (JSON + fichiers de données binaires séparés) et .glb (tout dans un seul fichier binaire). Pour le web, .glb est généralement préféré — un fichier, une requête, une mise en cache facile.
glTF prend en charge les matériaux de rendu basé sur la physique (PBR) prêts à l'emploi — workflow métallique/rugosité, cartes normales, cartes d'occlusion, cartes émissives. Il gère les animations, le rigging squelettique (skinning) et les cibles de morphing (blend shapes). Pour la compression, Draco réduit considérablement la taille de la géométrie, et KTX2/Basis Universal gère la compression des textures qui reste compressée sur le GPU.
D'autres formats existent — USDZ pour l'AR Quick Look d'Apple, FBX et OBJ comme formats d'échange hérités — mais pour la livraison sur le web, glTF est la réponse. Évitez FBX/OBJ pour une utilisation web en production ; ils sont verbeux, manquent de standardisation et ne se compressent pas bien.
Le pipeline d'actifs : de la modélisation au navigateur
Obtenir un modèle 3D de votre logiciel de modélisation dans le navigateur de manière efficace implique quelques étapes.
La modélisation se fait dans des outils comme Blender (gratuit et excellent), Maya, Cinema 4D ou Modo. Lors de l'exportation, utilisez l'exportateur glTF officiel de Khronos pour Blender — il est maintenu par les auteurs de la spécification et produit la sortie la plus propre.
L'optimisation est là où la magie opère pour les performances web. glTF Transform (un outil en ligne de commande) peut appliquer la compression de géométrie Draco, redimensionner et compresser les textures en KTX2/BasisU, générer des mipmaps, supprimer les données inutilisées, etc. Meshoptimizer compresse davantage les tampons de sommets et d'indices. Le glTF Validator détecte les violations de spécification avant que vous n'expédiiez.
Pour l'hébergement, utilisez un CDN avec des en-têtes CORS appropriés et la prise en charge des requêtes HTTP Range — cela permet le chargement progressif de grands modèles. Certaines équipes utilisent des CDN 3D spécialisés qui gèrent la conversion de format et l'optimisation à la volée.
Physique et interaction : rendre cela réel
La 3D statique est jolie ; la 3D interactive est engageante. Pour la physique, les principales options dans le monde JavaScript/Wasm sont Cannon-es (un port léger de Cannon.js), Rapier (un moteur moderne et rapide basé sur Rust compilé en Wasm, avec une excellente intégration R3F via @react-three/rapier), Ammo.js (un port de la physique Bullet standard de l'industrie — puissant mais lourd) et Jolt Physics (un port Wasm plus récent et très rapide).
Pour l'interaction, le raycasting est la technique fondamentale — tirer un rayon invisible de la caméra à travers la position de la souris/du doigt pour voir quel objet 3D a été touché. Les bibliothèques fournissent des contrôles prêts à l'emploi : OrbitControls pour tourner autour d'un objet, DragControls pour déplacer des choses, TransformControls pour la translation/rotation/échelle de type gizmo. Dans WebXR, vous obtenez une interaction basée sur le contrôleur — pointer, saisir, téléporter — gérée par l'intégration XR du framework.
Budgets de performance : garder cela fluide
Le web est un environnement hostile pour les performances. Les utilisateurs sont sur tout, des téléphones phares aux ordinateurs portables de cinq ans. Viser 60 images par seconde signifie que vous avez 16,6 millisecondes par image. Pour la VR, vous avez besoin de 90fps (11,1ms) ou même 120fps (8,3ms).
Budgets approximatifs à viser : moins de 100 000 triangles pour le mobile, moins de 1 million pour le bureau. Moins de 50 appels de dessin est idéal ; moins de 200 est acceptable. Mémoire de texture inférieure à 100 Mo sur mobile, 500 Mo sur bureau. La complexité des shaders compte — évitez les branchements dynamiques, limitez les échantillons de texture, gardez les nombres d'instructions bas.
Les outils de profilage sont vos amis. L'onglet Performance de Chrome DevTools, Spector.js pour la capture d'images, le panneau de statistiques intégré de three.js et detect-gpu pour classer les appareils à l'exécution. L'idée clé : mesurez sur des appareils réels, pas seulement sur votre machine de développement.
Amélioration progressive : dégradation gracieuse
Tous les appareils ne peuvent pas exécuter votre scène 3D sophistiquée. L'amélioration progressive signifie fournir une expérience utilisable partout, puis ajouter la 3D là où elle est prise en charge.
Commencez par un repli 2D — une image hero, un carrousel, un graphique statique. Détectez la prise en charge de WebGL (et WebGPU, WebXR) à l'exécution. Pour les appareils bas de gamme, servez des modèles à faible nombre de polygones, des textures plus petites et désactivez les effets coûteux comme les ombres, le bloom ou les réflexions d'écran. Des outils comme detectGPU de three.js ou le WebGL Report peuvent aider à classer les niveaux de capacité des appareils.
L'objectif n'est pas de faire en sorte que tout ait l'air identique partout — c'est de faire fonctionner l'expérience de base partout, et de la faire briller là où le matériel le permet.
Travaillons ensemble
Vous avez besoin de plus d'informations, d'aide pour votre projet ou pour développer une idée?
Qu'il s'agisse d'une question simple, d'un doute rapide ou d'une discussion de 5 minutes, envoyez-moi un message—cela ne coûte rien et je suis toujours prêt à vous aider. J'aime comprendre un problème, être créatif dans les solutions et me concentrer sur des idées simples, fiables et faciles à réaliser rapidement.
Me contacter →