DOCS/v2/immersif-frontiere-plan.md

Contenu immersif — frontière entre le Studio IA et le canal XR — 📦 V2

Statut : document de frontière, écrit le 2026-09-11. Rien de codé.

Ce document ne remplace ni studio-plan.md ni vr-quest-unity-plan.md. Il tranche ce que ces deux plans se renvoient mutuellement en dépendance : le Studio met la 3D en lot 11 en disant « dépend du chantier VR », et le plan VR décrit les POI sur GLB (§9) en supposant un GLB qui arrive de quelque part, sans jamais dire d'où. Ce n'est pas un trou de conception, c'est une frontière que personne ne tient.

⚠️ Rien ici n'est V1. La bascule Postgres et le backlog V1 passent avant. Et le gate du Studio reste celui du lot 4 : si un conservateur ne produit pas 10 images cohérentes seul, aucune ligne de 3D ne s'écrit.

---

1. Les trois couches

La confusion vient de ce que « module 3D » désigne trois choses distinctes, décrites dans deux documents différents. Les voici séparées.

Couche 1 — Ressources immersives

Trois nouveaux types de ressource, qui s'affichent partout où une ressource s'affiche :

ResourceType += Panorama360   -- image équirectangulaire
                Video360      -- vidéo équirectangulaire
                Model3D       -- GLB

Indépendant de la VR. Indépendant de l'IA. Un client web sans casque et sans Studio en profite.

⚠️ Les trois valeurs se décident d'un coup, en une migration, en fin d'enum. Aujourd'hui ResourceType s'arrête à Text = 10 (Data/Resource.cs:94-110, avec le commentaire qui interdit d'insérer au milieu). studio-plan.md §5 réserve déjà Model3D = 11.

Décision — Video360 est un type distinct, pas un flag IsEquirectangular sur Video. L'enum distingue déjà Image / ImageUrl : un type séparé est cohérent avec l'existant et rend le filtrage trivial dans le sélecteur de ressource, qui est le point de passage unique de toute l'app (select_resource_modal.dart:24 embarque ResourcesScreen).

Couche 2 — Consommation

Trois usages de ces ressources :

Usage	Porté par	Canaux
SectionModel3D + POI (titre, description, audio, multilingue)	une section	web, mobile, VR
ImmersiveBackground — fond d'une visite	Configuration	VR, dégradé ailleurs (§4)
ImmersiveBackground — fond du menu général	ApplicationInstance VR	VR
Rendu immersif complet	app Quest (Unity)	VR

Le back-office XR (Device.AppType + onglet flotte, 8-12 j) se tient debout tout seul dans cette couche : il rend le canal administrable et démontrable avant tout engagement sur Unity.

Couche 3 — Studio IA

Une source d'approvisionnement pour la couche 1, pas un module parallèle. C'est la reformulation qui règle la frontière : le Studio ne possède pas ses assets, il alimente la médiathèque, qui reste la bibliothèque unique (studio-plan.md §3.0).

Ce que le Studio apporte que le client ne peut pas obtenir ailleurs, dans l'ordre de valeur :

1. L'asset atterrit dans la médiathèque, référencé par une section, donc il part offline. C'est le point non réplicable. Un asset généré ailleurs est un fichier à re-uploader à la main, et il ne part offline que s'il finit référencé par un champ de section (GetReferencedResourceIds).
2. L'identité visuelle est injectée côté serveur, jamais retapée. La cohérence des quarante images d'un parcours, pas l'accès au modèle.
3. Le bon format, la bonne dimension, le bon prompt contextuel — le titre et la description de la fiche alimentent le prompt, la validation affecte directement au champ cible.

---

2. Ce que chaque couche vend

Il n'y a pas d'add-on casque. Arbitré le 2026-08-31 (vr-quest-unity-plan.md §6), reconfirmé ici parce que la question revient : un add-on « VR » ne se vendrait que le jour où l'app Unity existe et où le client achète un casque. L'add-on « Contenu immersif », 70 €/mois et plus, vend la couche 1 — qui s'affiche déjà en web, mobile et kiosk. Un client le souscrit et en a pour son argent sans casque. Le casque est le haut de gamme de l'add-on, pas sa condition d'existence.

Ce qui est vendu	Véhicule	Montant
Ressources immersives (360, GLB, POI) + l'app Quest quand elle sortira	add-on « Contenu immersif »	à partir de 70 €/mois, s'accroche à n'importe quel palier
Génération IA (images, puis props et scènes)	add-on Studio, crédits dédiés	voir studio-plan.md §3.5
Casques	achat client	hardware
Provisioning, config borne, formation, journée sur site	onboarding one-shot	1200-1500 €, seulement s'il y a des casques
Modélisation 3D d'atelier, photogrammétrie d'objets de collection	sur devis, hors Studio	3 à 15 k€

2bis. Quota IA et crédits Studio — deux monnaies, et pourquoi

Arrêté le 2026-09-11. La question « le Studio consomme-t-il le quota IA ? » revient à chaque conversation. Réponse : non, et voici le critère pour ne plus se la reposer.

Le critère n'est pas « IA / pas IA ». C'est « consommé en temps réel par le visiteur » contre « produit une fois par le client ». Cette ligne décide du modèle de facturation parce qu'elle décide de la forme de la courbe d'usage.

	Quota IA	Crédits Studio
Unité	tokens / mois	crédits
Renouvellement	reset mensuel, non reporté	rechargeables, expiration 12 mois
Véhicule	attribut du palier	add-on
Courbe d'usage	récurrente, suit la fréquentation	en pics (préparation d'une expo)
Couvre	chat visiteur, canal vocal, traduction	images, 3D, scènes, vidéo, TTS pré-généré

Le reset mensuel est juste pour le quota IA : l'usage suit la fréquentation, il est corrélé aux vacances scolaires, et il est normal qu'il ne se reporte pas.

Il est faux pour le Studio. Un musée génère 200 images en trois semaines pour préparer une expo, puis rien pendant cinq mois. Un forfait mensuel se gaspille dix mois sur douze : le client a le sentiment de payer pour rien, et la capacité provisionnée ne sert pas.

➡️ Correction à porter dans studio-plan.md §3.5 : ImageCreditsMonthKey et le Kind: MonthlyReset deviennent inutiles. Le CreditLedger est déjà append-only avec un Kind: Grant — il encaisse le modèle rechargeable sans changement de schéma. Gratuit à décider maintenant, migration en prod plus tard.

Le TTS pré-généré va côté Studio, et c'est contre-intuitif puisque c'est « de l'IA ». Trois raisons : il se facture au caractère et non au token, il produit un fichier (donc du stockage, comme une image générée), et il se déclenche par pics quand le conservateur rédige. Le mettre sur le quota tokens visiteur mélangerait deux courbes sans rapport.

La traduction est le cas limite, laissé où il est. Par le critère ci-dessus elle devrait être en crédits Studio — déclenchée par le client, une fois, produisant un asset durable. Mais elle est déjà sur le quota tokens, elle est très bon marché, et la déplacer ne rapporterait rien. Décision : ne pas y toucher, mais le savoir plutôt que de le redécouvrir.

Vérifié dans le code le 2026-09-11 — ce que le quota IA couvre réellement :

Endpoint	Débite le quota	Note
POST /api/Ai/chat	✅ AiController.cs:394
POST /api/Ai/translate	✅ AiController.cs:347
POST /api/Ai/reindex/{instanceId}	❌	Les embeddings RAG coûtent et passent gratuitement
GET /api/Ai/insights/{instanceId}	❌	idem

⚠️ Trou existant, indépendant du Studio : deux endpoints facturés chez Google ne débitent rien. Et AiTokensPerMonth vaut 0 en Essentiel et Pro, 20_000_000 en Premium (MyInfoMateDbContext.cs:607-637) — donc le quota IA est aujourd'hui un attribut du palier, pas un add-on. À ne pas confondre avec les crédits Studio, qui sont un add-on.

⚠️ L'add-on immersif doit porter sa propre enveloppe de stockage, explicite et finie, avec facturation du dépassement. Un client Pro à 99 € a un quota dimensionné pour du Pro ; une vidéo 360 de 5 minutes pèse des Go, un monde exporté en splats aussi. Le principe est posé dans vr-quest-unity-plan.md §6 — il n'est toujours pas chiffré, et il doit l'être avant d'ouvrir la couche 1 à la vente.

---

3. Génération de scène 3D — état réel du marché

Révisé le 2026-09-11. Une première passe de cette analyse concluait « ne pas faire, l'assemblage est la seule voie ». C'était fondé sur un état du marché périmé : la conclusion change, la limite qui la motivait reste vraie.

Ce qui existe

Marble (World Labs) génère des environnements 3D persistants depuis du texte, une image, une vidéo ou un panorama, et expose une World API depuis janvier 2026 — à partir de ~0,12 $ le monde en draft. Exports : splats (SPZ/PLY), panorama 360, collider mesh basse résolution, et mesh texturé GLB sur le palier Pro, qui porte aussi les droits commerciaux.

➡️ Ça entre dans la couche fournisseur sans rien y changer : un GenerationModel de plus en base, ProviderKey = "worldlabs", Kind = Scene3D. C'est exactement ce que studio-plan.md §3.6 a été conçu pour absorber.

La limite qui ne bouge pas

Un monde Marble est une scène capturée, excellente vue depuis et autour de son point de vue, qui dégrade dès qu'on s'en éloigne. Chiffres rapportés côté Quest 3 standalone : plafond raisonnable autour de 500k splats (2M restant du domaine du VR filaire), environnements cadrés sur une grille de ~10×10 m, et un cas mesuré à 12 fps sous Unity contre 19 dans le navigateur Oculus. Une borne publique doit tenir 72 fps, huit heures par jour, sans personne à côté.

Et il n'y a pas de sémantique : pas de sol identifié, pas d'objets nommés, pas d'interactions. Le collider mesh fourni donne la collision, pas la compréhension de la scène.

Position retenue

Usage	Verdict
Fond immersif d'une visite ou du menu VR (le visiteur regarde autour de lui depuis un point fixe)	✅ oui, c'est le cas d'usage nominal de la techno
Monde de référence en roomscale stationnaire : le visiteur est dans la scène, sur ~3 m	✅ oui — et c'est mieux qu'un assemblage de props Meshy
Environnement navigable, le visiteur se déplace librement dedans	❌ non en V2. Ni la perf en borne, ni la sémantique n'y sont
Props d'ambiance générés depuis du texte, placés sur ancres	✅ oui, faible risque : un prop raté se jette

Le cadre retenu est le roomscale stationnaire, pas un diorama. Arbitré le 2026-09-11 : une zone d'environ 3 m où le visiteur tourne sur lui-même, se penche et tend le bras, mais ne se déplace pas. C'est exactement la zone où Marble est bon — son point de capture — et où le budget de perf tient.

Ce n'est pas un pis-aller : la contrainte supprime d'un coup la locomotion, les collisions, le motion sickness, la cohérence d'échelle au-delà du champ proche et l'essentiel du budget de perf. Et elle est meilleure produit qu'un diorama vu de l'extérieur, parce que le visiteur est dans la scène. Le but n'a jamais été de faire un jeu VR.

Placement sur ancres prédéfinies, jamais libre. Le template d'environnement Unity expose N snap points ; le client y accroche ses props. Un éditeur de placement libre en 3D dans un back-office web est un chantier à lui seul, pour un gain nul à ce stade.

Image → GLB : mature en API, piégeux en produit

Meshy / Tripo / Rodin ont des API qui marchent, et le multi-vues améliore nettement le résultat. Mais ce qui sort est un objet isolé, silhouette lisible, topologie sale, texture baked, échelle et pivot arbitraires.

Précisé le 2026-09-15 — tout passe par fal, y compris Meshy. Vérifié ce jour : fal expose Meshy (v5, v6-preview, v7), Hi3D, Tripo3D, Hunyuan3D et Trellis. Aucun second fournisseur à intégrer. Le multi-vues a un endpoint dédié, meshy/v7/multi-image-to-3d (~1,20 , 1,40 en ultra), face à ~0,02–0,05 $ en mono-image : facteur ~25, donc deux lignes de catalogue et une bascule annoncée à l'écran. Hi3D est excellent en fidélité structurelle mais mono-image seulement. Détail du flux de prise de vue guidé : studio-plan.md, lot 11 et décision 24.

⚠️ Pour un objet de collection, le problème n'est pas la qualité, c'est la véracité. Un visiteur qui fait tourner « le casque de Léon » croit voir l'objet. Deux conséquences :

• Sur un Model3D généré, la provenance visible est obligatoire, non désactivable — contrairement aux images, où le badge suffit et la gravure est une option (studio-plan.md décision n°6).
• L'offre doit séparer explicitement « objet numérisé » (photogrammétrie, sur devis, hors Studio) de « illustration 3D » (Studio). Les vendre sous le même mot est un risque réputationnel chez une institution scientifique.

Le vrai sur-scope : l'éditeur, pas la génération

vr-quest-unity-plan.md §9 signale l'éditeur de placement de POI comme « le seul morceau non trivial ». Il le sous-estime : Flutter web n'a pas de stack 3D éditable. model_viewer_plus est une WebView autour de <model-viewer>, en lecture seule.

➡️ Décision à prendre maintenant, parce qu'elle conditionne tout le chiffrage : l'éditeur de POI 3D est une page three.js embarquée en iframe, pas un widget Flutter. Précédent dans le repo : la démo villa d'Echternach (visitapp-web/src/app/demo/villa-echternach/scene.ts).

---

4. ImmersiveBackground — un type, deux porteurs

Configuration porte aujourd'hui ImageId et LoaderImageId, rien d'immersif. Poser un Configuration.BackgroundResourceId à plat, puis un autre champ sur l'ApplicationInstance, puis un troisième pour la scène, donne quatre champs « background » incohérents dans six mois.

ImmersiveBackground
  ResourceId
  Kind        -- Pano | Video360 | Scene3D
  FallbackResourceId?   -- 2D, pour les canaux qui ne savent pas rendre

Porté par Configuration (le fond d'une visite) et par l'ApplicationInstance VR (le fond du menu général — l'équivalent de home v3 côté mobile). Un seul type, deux porteurs, pas deux modèles.

Dégradation par canal, écrite dans le contrat — sinon les fonds casseront silencieusement :

Canal	Pano	Video360	Scene3D
VR (Quest)	rendu	rendu	rendu
Web	visite pivotante	visite pivotante	fallback 2D
Mobile	fallback 2D	fallback 2D	fallback 2D
Kiosk	fallback 2D	fallback 2D	fallback 2D

Chaque canal déclare ce qu'il sait rendre ; le fallback est Configuration.ImageId par défaut.

---

4bis. Viewer de scène et viewer d'asset — un socle, deux modes

Arrêté le 2026-09-11. La question « c'est le même viewer ? » se pose naturellement, et la réponse détermine un chiffrage à trois implémentations près.

Ce qui les sépare est la caméra, et c'est une opposition franche.

	Viewer d'asset (l'épée du roi)	Viewer de scène (le monde de référence)
Caméra	orbitale — l'objet au centre, on tourne autour, on zoome	look-around — on est au centre, on regarde autour
Le visiteur	manipule l'objet	est dans la scène, ne manipule rien
Donnée	un GLB léger, objet isolé	un splat / mesh d'environnement, lourd
POI	sur la surface, tournent avec l'objet	fixes dans l'espace, on les regarde

Ce qu'ils partagent : le loader GLB, le canvas, le raycast sur POI, et surtout le même modèle de POI — une position locale (x,y,z). Donc un socle de rendu avec un mode, pas deux implémentations. Et un seul éditeur dans le manager, avec un mode lui aussi.

⚠️ Le point qui compte pour le chiffrage : ils ne vivent pas au même endroit.

	Web (React)	Mobile (Flutter)	VR (Unity)
Viewer d'asset	✅	✅	✅ (item E7)
Viewer de scène	fallback pano	fallback 2D	✅ (item E5)

➡️ Le viewer d'asset est trois implémentations, le viewer de scène une seule plus deux dégradés. À budgéter dans cet ordre, pas l'inverse : l'intuition pousse à commencer par la scène parce qu'elle impressionne, alors que c'est l'asset qui coûte trois fois.

---

5. Décisions de rétro-compatibilité, du plus cher au moins cher

Les points 1 à 5 doivent être écrits dans studio-plan.md avant sa première migration. Les suivants peuvent s'écrire au fil de l'eau.

1. Pipeline d'ingestion unique côté serveur — ✅ porté dans studio-plan.md le 2026-09-13

Décision 14 : URL d'envoi signée par l'API, puis un ResourceIngestionService unique pour tout fichier, uploadé ou généré (§8 lot 0). Les gros fichiers — GLB, vidéos 360 — vont directement chez Google sans traverser le VPS.

Le trou le plus cher, et il est structurel, pas accidentel. Aujourd'hui l'upload est fait par le navigateur en direct (resources_screen.dart:247-256) ; le backend ne sait que supprimer (IResourceBlobService.DeleteAsync). Le Studio, lui, produit côté serveur et post-traite à la validation d'un brouillon.

➡️ Un GLB uploadé ne traverserait aucun traitement, un GLB généré traverserait le chemin Studio. Deux chemins par construction.

• Déplacer le point de passage de « validation d'un asset Studio » à « ingestion de tout asset, quelle que soit sa provenance »
• Un seul service de post-traitement, appelé par les deux chemins
• Le lot 0 (UploadAsync, CopyAsync, ProbeSizeAsync) est le prérequis mais ne suffit pas

Coût du retrofit : l'upload navigateur direct est partout dans manager-app, et il faudrait retraiter la base d'assets existante.

2. Normalisation canonique des GLB

• Pivot recentré, échelle normalisée, up-axis fixé — déterministes
• Budgets de validation (tris, taille de texture, poids) : rejet, pas réparation
• Draco + KTX2 dans le même passage
• Model3DVersion sur la ressource

Coût du retrofit : tout POI posé avant est perdu. C'est ce qui rend ce point non négociable, pas l'élégance du pipeline.

3. Invalidation et repositionnement des POI

Absent des deux plans. Et c'est structurellement plus grave qu'en géo : une lat/lon survit à un changement de fond de carte, un (x,y,z) local est détruit par un changement de pivot, d'échelle ou d'up-axis.

• POI attachés à (resourceId, modelVersion)
• Au remplacement ou à la régénération : POI conservés et marqués « à revalider », jamais supprimés en silence
• Écran de repositionnement dans l'éditeur

Peu de code si pris tôt. Coûteux en confiance client si découvert en prod.

4. Lignage en colonnes typées — ✅ porté dans studio-plan.md le 2026-09-13 (décision 20, lot 0)

Resource.AiProvenance (jsonb) distingue uploadé (null) de généré (non-null) et liste des referenceResourceIds[]. Mais un tableau dans un jsonb n'est pas un lignage requêtable, et rien ne couvre un GLB dérivé — reprocessé, décimé, regénéré depuis le même jeu de photos.

• Resource.Origin : Uploaded | Generated | Derived — colonne, pas jsonb
• Resource.SourceResourceId nullable — le lignage parent/enfant
• AiProvenance reste pour le détail (prompt effectif, seed, version d'identité)

Coût du retrofit : migration de données sur des assets déjà en base.

5. Renommer la monnaie de crédits — ✅ porté dans studio-plan.md le 2026-09-11

ImageCreditsPerMonth, ImageCreditsThisMonth, ImageCreditsMonthKey, ImageCreditsHardCap, SubscriptionPlan.ImageCreditsPerMonth. Or une 3D coûte 10 à 50 fois une image, et un monde Marble n'est pas une image du tout.

• ImageCredits* → StudioCredits* partout
• GenerationModel.CreditCost déjà par modèle : rien d'autre à faire côté tarification
• Et le modèle change aussi : crédits rechargeables à expiration 12 mois au lieu d'un quota mensuel. Un musée génère en pics, pas linéairement — un forfait mensuel se gaspille dix mois sur douze. Voir studio-plan.md §3.5 et le §2bis ci-dessus

Gratuit aujourd'hui. Migration de colonnes en prod plus tard. Le retrofit le moins cher à éviter et le plus bête à subir. ➡️ Fait : décision n°3 du tableau §2, bloc §3.5, schéma §5 et lot 1 de studio-plan.md sont à jour. Reste ouvert : le mapping Stripe checkout.session.completed → Kind: Grant pour la recharge.

6. Contrat fournisseur : multi-fichier et par kind — ✅ porté dans studio-plan.md le 2026-09-13 (décision 21, §3.6)

ProviderResult est pensé mono-fichier image. Une génération 3D retourne GLB + preview + parfois textures séparées ; un monde retourne splat + collider mesh + panorama.

• ProviderResult multi-fichier
• GenerationKind += Model3D, SceneProp, Scene3D
• Timeout et politique de retry par kind — le PollFallback à +90 s et le polling front à 2 s de studio-plan.md §3.7 sont dimensionnés pour un job image de 20-60 s
• Job composite : générer 8 props est un job parent + N enfants, pas un job

7. ImmersiveBackground comme type réutilisable

Voir §4. Deux porteurs, un type, dégradation par canal dans le contrat.

8. Les trois valeurs ResourceType d'un coup

Voir §1, couche 1.

9. Éditeur 3D = iframe three.js

Décision d'architecture, pas d'implémentation. Voir §3.

10. Chiffrer l'enveloppe de stockage de l'add-on immersif

Voir §2. Posé en principe le 31/08, jamais chiffré.

11. Provenance obligatoire sur un Model3D généré

Voir §3. Et séparer « objet numérisé » de « illustration 3D » dans l'offre.

---

6. Droits et modération — ce qui reste ouvert

Couvert par studio-plan.md : rightsHolder = l'instance (les droits sont au client, écrit dans la donnée), provenance complète, badge visiteur traduit dans les langues de la configuration, et la redirection des personnes identifiables vers les personnages.

Pas couvert, et spécifique à la 3D : rien sur les objets dont le client n'a pas les droits — prêts, dépôts, collections tierces. C'est le quotidien d'un musée, et générer un GLB depuis la photo d'un objet en dépôt n'est pas anodin.

➡️ Traitement retenu : CGU + une mention explicite dans l'écran de génération 3D, pas de vérification automatique. Pas de modération automatique entrée/sortie non plus. Acceptable au stade pilote — à condition de l'assumer par écrit, pas de le découvrir.

---

7. Chemin critique

Ce n'est pas celui qu'on croit. La génération 3D est en toute fin, et c'est la brique la moins risquée de la liste, parce qu'à ce stade tout ce qui la consomme existe et est validé.

Lot 0 — socle de stockage serveur          (prérequis dur, sert aussi le TTS)
  └─ + pipeline d'ingestion unique          (décision n°1)
        └─ Ressource 360°                   (le plus petit des trois chantiers médias)
              └─ SectionModel3D + POI       (GeoPoint réutilisé à 80 %)
                    └─ Back-office XR       (8-12 j, se tient debout tout seul)
                          └─ Studio images  (lots 1 à 6)
                                └─ ⛔ GATE lot 4 : un conservateur, 10 images, seul
                                      └─ Studio 3D + scènes
                                            └─ App Unity  (go/no-go client pilote)

Le go/no-go de l'app Unity reste conditionné à un client pilote disposant déjà de contenu immersif — et la couche 1 rend cette condition atteignable, puisqu'elle permet au client de fabriquer ce contenu au lieu de devoir le posséder d'avance. C'est le changement le plus important qu'apporte le Studio au dossier XR.

---

8. Ce qu'on ne fait pas

• Environnement VR navigable en V2 — roomscale stationnaire ~3 m seulement (§3)
• Placement libre de props — ancres prédéfinies
• Locomotion en VR — le visiteur tourne sur lui-même, il ne marche pas
• Les mécaniques de jeu du §9 — notées, pas planifiées
• Photogrammétrie / fac-similé d'objets de collection — sur devis, hors Studio
• Modération automatique entrée/sortie — CGU + provenance + rightsHolder (§6)
• Retopologie ou upscaling automatique — budgets de validation et rejet, pas de réparation
• Refonte du routing de manager-app — les deux switch numérotés en dur de main_screen.dart sont acceptés tels quels, comme dans studio-plan.md

---

9. Mécaniques de jeu immersives — 📝 idées notées, rien de planifié

Noté le 2026-09-11, à la suite du canal VR — pas dans son périmètre. Aucune de ces mécaniques n'est chiffrée ni engagée. Elles sont ici pour ne pas être reperdues, et parce que deux d'entre elles réutilisent des données qui existent déjà, ce qui change leur coût relatif.

Le principe structurant, à ne pas perdre : un jeu configurable par le client n'est pas un moteur de jeu, c'est un type de section. Trois mécaniques génériques couvrent l'essentiel de ce qui a du sens en musée, et toutes tiennent dans les ~3 m du roomscale stationnaire. Le client compose ; un vrai jeu sur mesure reste un devis.

Mécanique	Ce que c'est	Données	Coût
Répondre	Quiz immersif : question devant, réponses sur 3-4 panneaux autour, réponse au regard ou à la main. Fond = ImmersiveBackground de la configuration	SectionQuiz, déjà là	rendu seul, config nulle
Trouver	Chasse aux détails dans un pano 360 : « trouve les 5 détails », « repère les 3 erreurs ». Le client pose des hotspots	même geste que poser des POI → le même éditeur iframe sert deux fois	faible, et ça marche aussi en web sur pano pivotant → se vend sans casque
Ordonner	Tri chronologique ou logique : attraper des objets autour de soi et les ranger. Frise, étapes d'un procédé	OrderedTranslationAndResource, déjà dans le modèle	faible, config = une liste ordonnée
Avant / après	« À quoi ressemblait cette place en 1900 ? » — le visiteur devine, puis bascule	BeforeAfterPairs du lot 9 du Studio	rendu seul

Le meilleur rapport valeur/effort est « Répondre » : SectionQuiz est déjà configuré par les clients aujourd'hui. Le jeu, c'est le rendu — zéro donnée nouvelle, zéro apprentissage côté client.

Le plus intéressant commercialement est « Trouver », pour une raison qui n'a rien à voir avec la VR : il fonctionne sur un pano 2D pivotant en web. Une mécanique de jeu qui se vend sans casque, sur l'add-on immersif seul.

Écarté, et pourquoi :

Idée	Pourquoi non
Remontage d'objet (amphore à reconstituer)	Effet musée énorme, mais il faut un GLB pré-découpé en pièces. Le client ne peut pas le produire seul → casse la règle d'autonomie. Sur devis uniquement
Escape game VR	La logique conditionnelle n'est pas configurable en trois champs. L'escape game reste sur le canal mobile, où il fonctionne déjà
Tir, action, visée	Hors sujet produit
Dialogue avec un PNJ scripté	Le guide IA le fait déjà mieux, et sans script à maintenir
Tout ce qui demande de marcher	Contredit le roomscale stationnaire (§3)

---

10. Ce que ce document change dans les deux autres plans

Plan	À reprendre
studio-plan.md	Le lot 11 (3D) passe de quatre lignes à un lot réel : Scene3D comme GenerationKind, World Labs dans le catalogue, provenance obligatoire sur Model3D. Les décisions n°1, 4, 5 et 6 du §5 ci-dessus touchent des lots antérieurs (lot 0, lot 1, lot 3) et doivent y être écrites.
vr-quest-unity-plan.md	Le §9 (POI sur GLB) gagne la version de modèle, l'invalidation des POI et la décision « éditeur en iframe three.js ». Le §6 (pricing) gagne l'enveloppe de stockage chiffrée. Le §2 lot XR-4 gagne ImmersiveBackground comme source du fond de scène.
todo-features.md	La « Ressource 360° » devient les trois valeurs d'enum, en une migration.
Kanban	Les cartes 250, 280, 300, 320 et 330 restent valides. Ce document est la source à citer en src: pour la frontière.