Une scène 3D qui tourne dans un navigateur, sans plugin et sans installation, n'est plus une prouesse. C'est devenu une option parmi d'autres au moment de concevoir un site. La vraie question n'est donc plus « est-ce possible », mais « qu'est-ce que ça impose au reste du site ».
Ça impose beaucoup, et rarement là où on l'attend.
WebGL, Three.js, shaders : qui fait quoi
Les trois mots circulent ensemble et ne désignent pas la même chose.
WebGL est l'interface qui permet à une page web de parler à la carte graphique. C'est le socle, intégré aux navigateurs depuis des années : rien à installer côté visiteur.
Three.js est une bibliothèque posée dessus. Elle fournit les notions qu'on manipule réellement : une caméra, des lumières, des matériaux, des objets. Écrire une scène directement en WebGL reste possible, mais personne ne s'y résout sans motif précis.
Un shader est un petit programme exécuté par la carte graphique elle-même, pour chaque pixel ou presque. C'est lui qui produit une matière, une déformation, une lumière qu'aucune image fixe ne saurait rendre.
La hiérarchie tient en une phrase : WebGL est la porte, Three.js est l'outillage, les shaders sont l'endroit où se joue l'essentiel de ce qui se voit.
La question à trancher avant la technique
Est-ce que la 3D porte une information, ou est-ce qu'elle décore ?
Les deux réponses sont légitimes, elles n'engagent simplement pas le même projet. Un configurateur qui laisse voir un produit sous l'angle qu'on choisit porte une information : il remplace une question posée à un commercial. La visite d'un lieu remplace un déplacement. Une matière animée en fond de page ne remplace rien, elle installe une atmosphère, ce qui est un objectif valable mais qui ne se défend ni de la même manière ni au même budget.
Le piège consiste à financer le premier en croyant acheter le second, ou l'inverse. Tranchez avant d'ouvrir le sujet technique, pas après.
Le mur principal : un canvas ne contient aucun texte
C'est la contrainte que presque personne n'annonce, et c'est la plus lourde pour votre visibilité.
Une scène WebGL vit dans une balise canvas. Pour un moteur de recherche, pour un lecteur d'écran, pour un moteur de réponse, cette balise est vide. Le texte affiché dans votre scène, aussi lisible soit-il à l'œil, n'existe pas pour eux : il est dessiné, pas écrit.
Nous en faisons nous-mêmes les frais. Notre studio virtuel est la page la plus travaillée du site et la moins lisible par une machine : au moment où nous écrivons, la page entière rend environ 259 mots, navigation et pied de page compris. L'expérience est là, le texte n'y est pas.
Une scène 3D est vue par vos visiteurs et ignorée par tout le reste. Ce qui doit être trouvé doit exister ailleurs, en texte.
La règle qui en découle est simple : la couche immersive ne doit jamais être le seul endroit où vit l'information. Le même contenu doit exister en HTML, quelque part, sous une forme lisible. C'est l'exigence décrite dans notre article sur la citation par ChatGPT et Perplexity, poussée à son cas extrême.
Le poids se paie au premier chargement
Une scène doit être arrivée avant de pouvoir tourner. Géométries, textures, bibliothèque : tout cela se télécharge, et se télécharge avant que le visiteur ne voie quoi que ce soit si personne n'a décidé du contraire.
Les décisions qui comptent sont donc des décisions de chargement. Ne pas placer la 3D dans le chemin critique du premier affichage. Ne la déclencher que lorsqu'elle approche de l'écran. Compresser les textures, qui pèsent presque toujours plus que la géométrie. Et accepter de retirer de la scène ce qui ne se voit pas : un décor n'a pas besoin d'être modélisé pour être crédible.
Il n'existe pas de fréquence d'images garantie
Le même site tourne sur un poste de travail récent et sur un téléphone de trois ans, avec un écart de puissance que rien ne compense. Ajoutez la chauffe : un mobile qui chauffe réduit lui-même sa puissance pour se protéger, donc une scène fluide à la première minute peut ne plus l'être à la troisième.
Une expérience 3D se conçoit donc avec sa dégradation, pas seulement avec son état nominal. Une image fixe de qualité, affichée à la place de la scène quand la machine ne suit pas, est un résultat acceptable. Une scène qui saccade n'en est pas un.
Accessibilité et confort ne sont pas optionnels
Une navigation à la première personne peut donner la nausée, et ce n'est pas une façon de parler : caméra imposée, champ de vision étroit, accélérations subies. Le système d'exploitation expose un réglage de réduction des animations, que le navigateur transmet à la page. Une expérience sérieuse le lit et propose autre chose : pas une version appauvrie, un parcours équivalent.
Ajoutez le clavier. Si l'on ne peut avancer qu'à la souris, une partie de vos visiteurs reste dehors.
Ce qui casse, et qu'on ne voit pas venir
Deux exemples concrets, parce que ce sont eux qui font déraper les plannings et qu'ils ne figurent dans aucun devis.
Le contexte graphique se perd, et il ne revient pas tout seul. En développement, React monte un composant, le démonte et le remonte aussitôt pour débusquer les effets mal nettoyés. Si ce nettoyage libère le contexte graphique d'un canvas que React conserve, le remontage en redemande un et récupère celui qui vient d'être tué. Tout s'exécute ensuite dans le vide, sans la moindre erreur affichée. Nos composants WebGL créent pour cette raison leur propre canvas et le détruisent avec le contexte, plutôt que de le confier au rendu.
Certains réglages du moteur de rendu sont globaux. Une couleur de fond posée pour un rendu intermédiaire reste posée pour le rendu suivant. Le symptôme est spectaculaire, un bloc opaque qui recouvre la page, et la cause tient en une ligne oubliée. Ce genre de défaut ne se trouve pas en relisant le code, il se trouve en isolant.
Ce ne sont pas des anecdotes, c'est le coût réel de la 3D temps réel : pas la beauté de la scène, mais le temps passé sur des comportements que rien n'annonce.
Quand il vaut mieux s'abstenir
Si votre contenu est un catalogue à parcourir vite, la 3D ajoute de l'attente avant l'information. Si votre audience consulte surtout depuis des appareils modestes, vous concevez pour une minorité. Et si personne, chez vous ou chez votre prestataire, ne reprendra ce code dans deux ans, vous achetez une page qui vieillira sans pouvoir être réparée. Une scène 3D est du code, et le code demande de l'entretien.
Le bon usage est presque toujours local : un moment, une page, une démonstration. Rarement le site entier.
Ce qu'il faut en retenir
La 3D temps réel dans un navigateur est mûre, accessible, et parfaitement capable de porter un projet. Elle impose trois choses en retour : que l'information existe aussi en texte, que le chargement soit décidé plutôt que subi, et que la dégradation soit conçue au même titre que l'effet.
C'est ce que recouvrent le motion et le développement dans notre façon de travailler, et ce que vous pouvez parcourir directement dans nos réalisations. Si vous vous demandez si votre projet justifie ce niveau d'engagement, écrivez-nous : la réponse est parfois non, et c'est une réponse utile.
