Meta met fin à la Quest 2 : construire de la visualisation moléculaire qui survit au matériel

Quand Meta a annoncé la fin du support de la Quest 2, mon premier réflexe n'a pas été la nostalgie. Ça a été un git grep.

Je savais que dans notre base de code traînaient des dizaines de références à des API spécifiques au matériel : couches de confort, niveaux de batterie, fréquence de rafraîchissement par défaut, formats de texture internes. Rien de tout ça n'est censé fuiter dans la logique métier. Et pourtant.

C'était un mardi soir, dans mon petit bureau parisien, thé froid à côté du clavier. Je venais de lire la nouvelle sur la fin de la Quest 2. Mon casque, je l'avais depuis 2021. Je l'avais porté pour tester des prototypes de visualisation de protéines, pour montrer à des collègues pourquoi le spatial change la perception des structures, pour me rendre compte aussi de ce qui n'allait pas.

Une chose que j'ai apprise en construisant ce genre d'outil : le matériel VR n'est pas une plateforme stable. C'est un continuum qui se déplace sous vos pieds.

Alors j'ai repensé à la façon dont nous avons fini par architecturer tout ça. Et honnêtement, la nouvelle de la Quest 2 m'a moins inquiété que prévu. Parce qu'à un moment, on a arrêté de coder pour un casque. On a commencé à coder pour une structure.

Le vrai problème n'est pas la Quest 2

Le vrai problème, c'est que la VR scientifique attire des équipes qui n'ont pas les moyens de refaire leur pile à chaque cycle matériel. Un labo de bio-informatique n'a pas un département "plateforme VR". Il a un postdoc qui a appris Unity sur le tas, un cluster GPU qui tourne, et des données qui ne doivent pas bouger.

Donc la question n'est pas "comment migrer vers Quest 3 ou Vision Pro". La question est : comment faire en sorte que le rendu d'une molécule soit indépendant du casque qui l'affiche ?

Ça a l'air abstrait. Ça ne l'est pas. Ça change des décisions très concrètes : où vit la géométrie, qui possède la caméra, comment on décrit une interaction.

Séparer la scène du runtime

Dans notre cas, on a fini par traiter la scène moléculaire comme un asset pur : positions atomiques, rayons, topologie des liaisons, propriétés de surface. Rien qui dépende du moteur. Le format ressemble à ça :

{
  "atoms": [
    {"element": "C", "x": 0.0, "y": 0.0, "z": 0.0},
    {"element": "O", "x": 1.2, "y": 0.0, "z": 0.0}
  ],
  "bonds": [[0, 1, 2]],
  "surface": {"resolution": 0.3, "isovalue": 0.02}
}

Le runtime, lui, ne fait que consommer ce JSON. Quest 2, Quest 3, un navigateur WebXR, un écran plat : le même asset. Ce qu'on change, c'est l'adaptateur.

L'adaptateur, c'est une petite couche qui sait trois choses : comment instancier des maillages, comment mapper les entrées (manettes, mains, souris), et comment gérer la boucle de rendu. Le reste — la chimie, la sélection, l'analyse — est au-dessus.

Ce découpage a un coût. On paye en indirection. Mais on gagne en longévité. Et en VR scientifique, la longévité est plus rare que la performance brute.

Ce qu'on a appris en benchmarks

Je ne vais pas prétendre qu'on a des chiffres spectaculaires. Ce qu'on a, c'est un ordre de grandeur utile : une scène de quelques milliers d'atomes avec une surface implicite reste fluide tant qu'on ne dépasse pas une certaine densité de maillage par unité d'angle solide. Le facteur limitant n'est presque jamais le GPU. C'est le CPU qui reconstruit les buffers à chaque changement de conformation.

Donc on a arrêté de reconstruire. On met à jour. On garde les buffers alloués, on écrit dedans, on marque les plages sales. Le gain n'est pas "2x plus rapide". Le gain, c'est que la frame suivante arrive avant que l'utilisateur ait fini de tourner la tête.

En VR, c'est ça la vraie métrique. Pas les FPS moyens. Le pire cas.

Le piège du confort

La Quest 2 nous a appris quelque chose d'inconfortable : les API de confort (reprojection, throttling thermique, ajustement automatique de la résolution) sont utiles et opaques. Elles masquent la dette. Un rendu qui tient sur un casque bridé peut s'effondrer sur un casque qui pousse plus fort.

Donc on a rendu le budget de rendu explicite. Une variable de configuration. Un plafond qu'on peut baisser pour tester, augmenter pour la démo. Ça paraît trivial. Ça nous a évité de découvrir des problèmes en soutenance.

Ce que ça donne pour un labo

Concrètement, pour un utilisateur, ça ressemble à ça : il ouvre une session, charge une structure, la fait tourner entre ses mains, sélectionne un résidu, compare deux conformations côte à côte. Le tout dans un navigateur, ou dans un casque, selon ce qu'il a sous la main.

Pas de SDK propriétaire à installer. Pas de build spécifique au casque. Pas de "cette fonctionnalité n'est pas disponible sur votre appareil".

Le pont honnête : l'outil que nous construisons — NMRium pour l'analyse spectrale et les visualisations associées — n'est pas un moteur VR. Ce n'est pas non plus une plateforme de rendu 3D généraliste. C'est un ensemble d'outils d'analyse et de visualisation de données spectroscopiques et structurales, pensé pour tourner dans le navigateur, avec une architecture qui essaie de ne pas dépendre d'un matériel précis.

La fin de la Quest 2 ne change rien à ça. Et c'est exactement le point.

La leçon

Si vous construisez de la visualisation scientifique en VR, la question n'est pas "quel casque". C'est "qu'est-ce qui, dans mon code, est encore un casque ?".

Trouvez-le. Isolez-le. Mettez-le derrière une interface.

Le jour où Meta, Apple, ou n'importe qui annonce la fin d'un support, vous ne devriez pas avoir à réécrire votre science. Vous devriez avoir à réécrire un adaptateur.

Pour voir à quoi ressemble une visualisation qui ne dépend pas du casque, ça se passe ici : NMRium.