veza/apps/web/dev_audit/frontend/09_scalability_ui.md

PHASE I — SCALABILITÉ UI

---

I1. Ajout de 50 écrans

Routing

• ✅ Prêt — React Router v6 avec lazy loading. Ajouter une route = 1 entrée dans routeConfig.tsx + 1 createLazyComponent dans lazyExports.ts.
• ✅ Pattern établi et reproductible.
• ⚠️ routeConfig.tsx croîtra linéairement — mais fichier de configuration, acceptable.

Design system

• ⚠️ Partiel — Les primitives UI couvrent les cas standards (Button, Card, Input, Table, Modal, Tabs, Badge, Avatar, Select, etc.).
• ⚠️ Manques pour 50 écrans : pas de composant Stepper, Timeline, Tree, Kanban, Calendar view, Rich Text Editor. Ces primitives devront être créées.
• ✅ Le pattern de création (Tailwind + forwardRef + variants via CVA) est bien établi.

Convention de nommage

• ✅ Scalable — Nommage cohérent : FeatureNamePage, useFeatureNamePage, FeatureNameSkeleton.
• ✅ Les feature modules ont une structure reproductible : components/, hooks/, pages/, services/, types/.
• ⚠️ La dualité components/ ↔ features/ brouille les conventions — à résoudre avant scale.

State management

• ✅ Supporte la complexité — Zustand pour UI state, React Query pour server state.
• ✅ L'ajout d'un nouveau store Zustand est trivial.
• ✅ React Query supporte le cache granulaire par feature.
• ⚠️ La duplication Auth (Context + Store) devra être unifiée avant d'ajouter plus de features auth-dépendantes.

Verdict : ⚠️ Partiel — L'architecture supporte 50 écrans techniquement, mais la dette organisationnelle (dualité components/features, code mort) ralentira significativement. Résolution estimée : 1-2 semaines de refactoring préalable.

---

I2. Theming / Dark mode

Tokenisation des couleurs

• ✅ Les couleurs sont tokenisées via CSS variables (--primary, --background, --foreground, etc.)
• ✅ Dark mode complet avec override de toutes les variables dans .dark
• ✅ ThemeProvider avec useTheme() hook
• ✅ Tailwind dark: variant configuré via @custom-variant dark (&:is(.dark *))

Valeurs hardcodées à migrer

• ⚠️ ~30 couleurs hex hardcodées dans 12 fichiers TSX (charts, Swagger, OAuth, settings)
• ⚠️ 5 fichiers CSS avec couleurs hardcodées dans les styles vanilla
• ⚠️ Les !important dans les fix CSS pourraient bloquer le theming

Switch de thème

• ✅ Prêt — ThemeSwitcher composant existant
• ✅ Persistence via Zustand store
• ✅ Respect de prefers-color-scheme

Verdict : ✅ Prêt — Le theming fonctionne. Ajout d'un 3ème thème (ex: high-contrast) nécessiterait ~30 fichiers à corriger pour les valeurs hardcodées.

---

I3. Internationalisation (i18n)

Système i18n

• ✅ i18next + react-i18next installés et configurés
• ✅ Dossier src/locales/ présent
• ✅ i18next-browser-languagedetector pour la détection automatique

Strings hardcodées

• ⚠️ MASSIF — Estimation grossière : la grande majorité des textes UI sont hardcodés en français ou anglais directement dans les composants TSX.
• ⚠️ Exemples : titres de pages, labels de boutons, messages d'erreur, placeholders, tooltips
• ⚠️ Migration vers i18n = effort XL (semaines de travail)

RTL support

• ❌ Non implémenté — Pas de dir="rtl" ni de classes logiques (ms-*, me-* au lieu de ml-*, mr-*)

Formatage localisé

• ✅ date-fns avec locale support potentiel
• ⚠️ Pas de formatage de nombres localisé détecté

Verdict : ⚠️ Partiel — L'infrastructure i18n est en place mais les strings ne sont pas externalisées. Effort de migration estimé : 3-4 semaines.

---

I4. White-labeling / Multi-tenant UI

Logo et branding

• ⚠️ Le design system "KODO" a une identité très forte (neon cyan, manga clips, gaming elements)
• ⚠️ Les couleurs sont tokenisées mais les gradients, clip-paths et effets visuels sont hardcodés
• ⚠️ Les noms thématiques (void, manga, shonen, terminal) sont culturellement spécifiques

Couleurs/fonts externalisables

• ✅ CSS variables permettent théoriquement de changer les couleurs
• ⚠️ 6 familles de fonts hardcodées dans le CSS — pas configurable par tenant
• ⚠️ Les gradients et glows sont définis en CSS, pas via un système de tokens dynamique

Layouts personnalisables

• ❌ Non prévu — Le layout est fixe (sidebar + header + main)
• ❌ Pas de système de slots ou de configuration de layout par tenant

Verdict : ❌ Bloqué — Le white-labeling nécessiterait une refonte significative du design system pour externaliser les éléments visuels. Le design est trop opinionné pour un multi-tenant.

---

I5. Performance à l'échelle

Virtualisation

• ✅ VirtualizedList composant avec @tanstack/react-virtual
• ✅ Chat messages virtualisés
• ⚠️ Pas de virtualisation systématique sur toutes les listes longues (TrackGrid utilise une grille classique)

Pagination

• ✅ useInfiniteQuery pour le scroll infini
• ✅ Pagination côté serveur (React Query)
• ⚠️ Pas de composant de pagination UI dédié détecté

Listes longues

• ✅ Skeletons pour le chargement progressif
• ⚠️ React.memo sous-utilisé sur les items de liste (5 instances seulement)
• ⚠️ Pas de loading="lazy" sur les images dans les listes

Verdict : ⚠️ Partiel — L'infrastructure est en place (virtualization, infinite scroll) mais pas systématiquement appliquée. À 10 000+ items, des bottlenecks de rendu apparaîtront.

---

Résumé scalabilité

Dimension	Verdict	Effort pour être prêt
+50 écrans	⚠️ Partiel	M (refactoring architecture)
Theming / Dark mode	✅ Prêt	S (nettoyer hardcoded values)
i18n	⚠️ Partiel	XL (externaliser toutes les strings)
White-labeling	❌ Bloqué	XL (refonte design system)
Performance à l'échelle	⚠️ Partiel	M (systématiser virtualisation + memo)