--- title: Back-office XR — le canal VR est administrable ---
Clos le 12/09. Le chantier tenait en trois lots, et les trois sont retombés : XR-1 le 11/09 (Device.AppType, migration 20260911135527_AddAppTypeToDevice, DeviceController.Create qui résout l'ApplicationInstance sur appType, ApiKeyAppType.VrApp en fin d'enum, 224 tests au vert), XR-3 qui était déjà fait sans que le plan le sache (export ouvert aux apps depuis 9cc45c5), et XR-2 le 12/09.
L'écran XR est une coquille à deux sous-onglets : « Configuration », qui réutilise AppConfigurationLinkScreen tel quel — il est déjà générique sur l'appType, zéro code neuf —, et « Casques », la grille avec pincode d'appairage, état connecté, batterie, version et dernier vu. i18n FR/EN/NL.
⚠️ Deux affirmations du plan étaient fausses, relevées dans le code. La grille kiosk ne liste pas des Device mais des AppConfigurationLink : le filtre par canal était déjà implicite, et le paramètre appType de /api/device ajouté par XR-1 ne sert pas à cet écran. Et batterie / version / dernier vu ne sont pas dans DeviceDTO, seulement dans DeviceDetailDTO — donc un appel de détail par casque, assumé sur une flotte qui se compte en unités.
Reste au plan deux puces purement documentaires de XR-3 : figer le JSON d'export comme contrat public versionné, et décider si l'export doit rendre toutes les langues d'un coup pour un casque en borne. Le prochain vrai coût est XR-4, l'app Unity — carte séparée.