--- title: L'app visiteur lit le détail d'instance, en vue réduite --- Corrigé le 08/09. GET /api/Instance/{id} renvoyait 403 à mymuseum-visitapp, qui l'appelle au démarrage pour la voix du guide : tout InstanceController porte [Authorize(SuperAdmin)] et GetDetail n'avait pas d'exception, contrairement à slug, byPin et app-key. Une clé API donne désormais accès à sa seule instance — clé croisée = 403 — et à une vue réduite : StripCommercialFields retire plan, quotas, usage IA, essai, TVA, facturation et le pinCode, qui ouvre l'appairage des tablettes. Le manager continue de tout voir.

Le piège, qui vaut pour tout le projet : le test « est-ce un utilisateur du manager » ne peut PAS se baser sur un claim de permission. AuthorizationMiddleware authentifie avec les schémas de la policy du contrôleur — JwtBearer et ApiKey — et peuple HttpContext.User avant de court-circuiter sur [AllowAnonymous]. Une clé API produit donc un User authentifié auquel le handler pose le claim Viewer : la première version laissait passer tout le monde. Elle ne se voyait pas, parce que les champs sensibles de l'instance testée étaient naturellement nuls — c'est le test croisé sur une instance avec un pinCode qui l'a révélée. Le test porte maintenant sur le schéma d'authentification.

⛔ Rectification : la carte annonçait une fuite de StripeCustomerId et StripeSubscriptionId. C'est faux — ils sont sur l'entité mais pas exposés par ToDTO. Ce qui fuyait vraiment : plan, quotas, TVA, facturation, pinCode.

Vérifié sur la préprod, cinq cas : 401 sans clé, 200 sur sa propre instance, 403 en croisé dans les deux sens, 200 pour le manager avec le DTO complet. Déployé en version-3.1.3.