Cinq builds propres à l'appareil depuis une seule base de code

Cinq surfaces vraiment différentes depuis une seule base de code — tableau de bord admin, tableau de bord super-admin, borne (écran tactile), comptoir (opérateur), affichage (statut de file passif, une TV dans une salle d'attente). Chacune a des routes différentes, des préoccupations différentes et un matériel différent. Un build de borne n'a aucune raison de livrer du code d'admin ; un build d'affichage n'a aucune raison de livrer la gestion interactive de formulaires.

vite.config.ts
vite.config.admin.ts
vite.config.super-admin.ts
vite.config.kiosk.ts
vite.config.display.ts
vite.config.counter.ts

Chaque config pointe vers une entrée différente et peut appliquer ses propres variables d'environnement de build, pour que le bundle livré à une borne n'inclue vraiment pas le code réservé aux admins — une vraie réduction de la taille du bundle et de la surface d'attaque, pas juste du confort de routage.

Pourquoi pas une seule application avec une vérification de rôle à l'exécution

Une seule application qui décide « borne vs admin vs affichage » via une vérification à l'exécution livre quand même tout le code à chaque appareil ; le navigateur cache juste conditionnellement des morceaux. Correct pour une application web normale où chacun a un vrai navigateur et une bande passante raisonnable. Pour du matériel dédié — bornes et affichages montés sur TV qui pourraient être plus vieux ou contraints en bande passante, et qui ne devraient avoir aucun chemin de code capable d'exposer jamais accidentellement une fonctionnalité d'admin même dans un bug — des bundles minimaux vraiment séparés sont le choix le plus défendable.

L'identité de l'appareil est fixée au moment du build plutôt que résolue à l'exécution :

environment:
  VITE_KIOSK_DEVICE_CODE: KIOSK-001
  VITE_OPERATOR_DEVICE_CODE: COUNTER-001

Marche bien quand une machine est provisionnée une fois avec un build précis et tourne juste — pas de connexion « quel appareil es-tu » à chaque démarrage. Le coût : réassigner quel appareil physique est KIOSK-001 implique de reconstruire et redéployer cette image, pas de changer une valeur à l'exécution — un vrai coût opérationnel si le matériel est souvent échangé ou déplacé.

La règle : quand plusieurs « rôles » front-end correspondent à du matériel physique différent avec des contraintes et des frontières de confiance différentes, des builds séparés valent généralement la complexité ajoutée. Quand c'est vraiment le même genre d'appareil — un navigateur, utilisé par une personne, juste avec des permissions différentes — une seule application avec du routage par rôle est plus simple et le meilleur défaut.