DOCS/kanban/cards/5-planifie/330-meta-quest-app-unity-meta-xr-sdk.md

title, area, horizon, tags, flag, src

title	area	horizon	tags	flag	src
Meta Quest — app Unity + Meta XR SDK	doc	v2	XR	warn | V2 · POC écrit en entier, rien n'a jamais tourné	v2/vr-quest-unity-plan.md §2 (lots XR-4, XR-5), §4, §5 · roadmap.md — section XR

Stack tranchée le 31/08 : Unity 6 LTS + OpenXR + Meta XR feature group. Le contenu se récupère par GET /api/configuration/{id}/export — un seul appel qui renvoie configuration, sections et ressources, donc aucun DTO C# à réécrire endpoint par endpoint. Unity n'est pas une nécessité technique : le mode kiosk vient de la gestion d'appareil, pas du moteur. Unity gagne sur l'exploitation sans surveillance — cache offline multi-Go, décodage 8K, et un build figé là où le navigateur du casque s'auto-mettrait à jour et pourrait casser la borne un mardi matin. Retenu : WebXR pour la maquette, Unity pour la borne, à rouvrir si l'usage devient « casque 5 min avec un agent à côté ».

✅ Le POC est écrit en entier — E0 à E10, entre le 11 et le 12/09. Unity 6000.0.83f1, projet URP dans vr-app/, APK sideloadé sur un Quest 2 (Horizon OS v207). Mesuré sur casque : un décor glTF de 50 Mo charge en 1,4 s et tient 72 FPS, GPU au maximum.

Item	Ce qui est écrit
E2-E3	Appairage par code PIN (PairingService) et lecture de l'export. ⚠️ Un 404 sur POST /api/device ne veut pas dire « introuvable » : il n'y a pas d'ApplicationInstance VR sur l'instance.
E4	Cache d'abord : l'app démarre sur le disque, se rafraîchit en fond, et l'échec du rafraîchissement ne se voit pas. Écriture atomique — une borne se débranche le soir. C'est l'argument n°1 d'Unity contre le web.
E5	Menu flottant en arc à 2,2 m, qui ne suit pas la tête. Trois moyens de viser : manette (gâchette), main (pincement), tête (1,2 s, contre le « Midas touch »). ⚠️ « À la tête », pas « aux yeux » — le Quest 2 n'a pas d'eye tracking. ⚠️ La dépendance E5 → E1 du plan était fausse : OVRInput et OVRHand viennent du Core SDK, donc E1 sort du chemin critique.
E6	Image et vidéo 360° en skybox. Le retour au menu ne reste pas planté dans le décor : 4 s, puis il s'efface et revient quand on baisse les yeux — toute la valeur d'une 360 est d'y être. ⚠️ Deux pièges invisibles dans l'éditeur : Skybox/Panoramic doit être dans Always Included Shaders (sinon ciel magenta sur le casque seul), et une équirectangulaire décodée pèse 134 Mo — compressée en ASTC et libérée à la sortie, sinon l'app meurt après quelques 360.
E8	Slider, Map, Parcours et Event, dans une même vue paginée. ⚠️ Deux écarts assumés : la Map est une liste de POI, pas la maquette 3D promise (elle demande SectionModel3D) ; le Parcours est rendu comme une Map, pour la même raison.
E9	Télémétrie « tire et oublie ». ⚠️ Route /api/stats/event, et appType y part en chaîne parsée par nom : une faute de frappe retombe sur Mobile sans erreur.
E10	Fin de visite à la repose du casque ou après 90 s, menu recentré devant le visiteur suivant, nouvelle session de stats. ⚠️ Le verrouillage de l'app sur le casque n'est pas du code : c'est le mode appareil de Meta.

⚠️ Rien de E2 à E10 n'a jamais tourné — ni contre un vrai serveur, ni sur le casque. Le code compile, c'est tout ce qu'on sait. Plan de test §25, 9 blocs, écrit pour ça ; son §25.7 (déclarer une 360 dans le manager) se joue sans casque.

⚠️ Le risque est produit, pas technique, et il est intact. Le CMS est 2D : un Article sur un panneau flottant est moins bon qu'une tablette. La valeur du canal vient du contenu 360°, que peu de clients possèdent. Go/no-go conditionné à un client pilote disposant déjà de vidéos 360° — rien de ce qui a été codé ne répond à cette question-là.

🟡 XR-5, la supervision de flotte : l'essentiel est écrit (12/09). Un battement HTTP toutes les 3 min remplit enfin les colonnes batterie / version / dernier vu de l'onglet XR, qui affichaient « — » faute d'alimentation — Update n'écrivait ni AppVersion ni LastSeen. Pas de MQTT : à 1-3 casques il coûterait dix fois plus de code pour remonter trois chiffres ; il redeviendra utile pour pousser vers le casque, pas pour remonter. Reste : le client MQTT le jour où l'on voudra recharger une configuration à distance, et une alerte quand un casque ne donne plus signe.

🟡 E7, la maquette 3D, est écrit aussi (12/09). SectionModel3D est un vrai type de section — une maquette n'a ni fond cartographique, ni zoom, ni coordonnées terrestres — mais il réutilise le GeoPoint, qui portait déjà deux rattachements : les points gardent titre, description, audio et multilingue. ✅ L'« éditeur de placement 3D », annoncé comme le seul morceau non trivial du lot, n'était pas à écrire : vr-app/viewer sait déjà le faire et son protocole postMessage existait déjà, pensé pour ce cas. Le manager le monte en iframe, comme il le fait déjà trois fois ailleurs. Côté casque, rien de dessiné non plus : on construit un manifeste et on le passe au moteur de la piste S. ⚠️ Le viewer n'a jamais tourné, et doit être servi sous le même domaine que le manager.

Reste au lot : E11 (distribution : Horizon Store ou canal privé, à revérifier avant toute offre). ⚠️ MDM rétrogradé le 31/08 : inutile à 1-3 casques, sideload + mode appareil suffisent.