# 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) |