Le frontend s’appuie sur un **système de design KŌDŌ** riche (tokens CSS, thème clair/sombre) et un **Storybook stabilisé** (0 erreur réseau/console, contrat documenté). Les écarts principaux par rapport à des standards type Discord/Spotify portent sur : **utilisation encore forte de valeurs arbitraires** malgré les tokens, **états d’interface incomplets** dans de nombreuses stories (Loading/Error/Disabled/Focus), **plusieurs composants “monolithes”** difficiles à tester et à faire évoluer, **décorateur Storybook** sans gestion des transitions ni du feedback tactile, et **a11y** partiellement couverte (addon présent, tests a11y en “todo”).
Les problèmes sont classés en **Bloquant**, **Amélioration** et **Perfectionnement**.
- **Thème Tailwind v4** via `@theme inline` : couleurs (`--color-primary`, `--color-sidebar-*`), radius (`--radius-sm` à `--radius-2xl`), typo (font-sans, font-mono, font-display).
- **Composants UI de base** : `button.tsx` utilise des tokens (`bg-kodo-cyan`, `ring-kodo-cyan`, `focus-visible:ring-2`), CVA pour variants/sizes, pas de valeurs arbitraires dans les variants.
### Problèmes identifiés
| Criticité | Constat | Détail |
|-----------|--------|--------|
| **Amélioration** | Valeurs arbitraires nombreuses | Plus de **170 fichiers** contiennent des classes type `h-[…]`, `w-[…]`, `p-[…]`, `gap-[…]`, `rounded-[…]`. Ex. : `h-[400px]`, `w-[300px]`, `min-h-[600px]`, `w-[500px]`, `h-[70px]` dans stories et composants. |
| **Amélioration** | Stories comme source de dérive | Les stories utilisent souvent des conteneurs en `h-[600px]`, `w-[300px]` pour le rendu. Ces valeurs ne s’appuient pas sur les tokens (ex. `--radius-lg`, `h-96`, `max-w-3xl`). |
| **Perfectionnement** | Échelle d’espacement | Les tokens d’espacement (4px, 8px, 16px, 24px…) sont partiellement reflétés en Tailwind ; des `p-4`, `p-8` coexistent avec des `p-[12px]` ou `gap-[11px]` ponctuels. |
### Recommandations
- **Remplacer progressivement** les valeurs arbitraires par des tokens : par ex. `h-[400px]` → `h-[var(--height-panel)]` ou `min-h-96` si une scale est définie.
- **Documenter une scale de hauteurs/largeurs** (cards, modals, sidebars) dans le design system et l’utiliser dans les stories.
- **Linter / règle custom** (stylelint ou ESLint) pour limiter les `[…px]` / `[…]rem` hors tokens.
### Mise à jour (nettoyage systémique)
**Layout primitives** ont été ajoutées dans `src/index.css` pour **App/Layouts** et **App/Pages** :
- **Focus** : Le `Button` a `focus-visible:ring-2 focus-visible:ring-kodo-cyan` ; plusieurs composants UI (input, checkbox, select, tabs) ont du `focus:` ou `focus-visible:`.
- **Disabled** : Présent dans ~23 fichiers de stories (Button, Checkbox, VolumeControl, etc.).
### Problèmes identifiés
| Criticité | Constat | Détail |
|-----------|--------|--------|
| **Bloquant** | Addon a11y non exploité | Dans `.storybook/preview.tsx`, `a11y: { test: 'todo' }` — les tests a11y ne sont pas exécutés en CI ni utilisés comme garde-fou. |
| **Amélioration** | Loading “factice” sur Button | La story `LoadingState` du Button est un `disabled` + texte "Loading..." sans spinner ni `aria-busy`. Les standards SaaS montrent un état de chargement explicite (spinner + désactivation). |
| **Amélioration** | États manquants par type de composant | Beaucoup de composants “carte” ou “liste” n’ont qu’un état Default : pas de story **Empty**, **Error**, **Loading** ou **Disabled** (ex. plusieurs vues Playlist, Track, Chat, Commerce). |
| **Amélioration** | Hover / Active peu documentés | Peu de stories nommées "Hover" ou "Active" ; les variants sont surtout visuels. Pas de démo systématique des états interactifs (hover/active) pour les boutons et liens. |
| **Perfectionnement** | Focus visible inégal | Une soixantaine de fichiers de composants utilisent `focus:` ou `focus-visible:` ; d’autres (cards cliquables, list items, custom controls) peuvent ne pas avoir de ring/outline visible. |
### Recommandations
- Passer **a11y.test** de `'todo'` à une config réelle (ex. `runOnly` avec règles WCAG 2.1 AA) et faire échouer le build/audit si des violations sont détectées.
- Ajouter une story **Loading** réaliste au Button (spinner + `disabled` + `aria-busy`) et un état **Disabled** explicite partout où l’action peut être désactivée.
- Pour les listes/cartes (Playlist, Track, Chat, Commerce), ajouter au moins **Empty** et **Error** (et **Loading** si async).
- Documenter **Hover** / **Active** dans les stories des composants interactifs (boutons, nav, sidebar) pour valider la cohérence visuelle.
---
## 3. Complexité des composants (“composants dieux”)
### Composants les plus volumineux (≥ ~400 lignes)
| **Amélioration** | Trop de responsabilités dans un seul fichier | Réduit : **CloudFileBrowser** est désormais un module (FileToolbar, FileTable, FileGrid, etc.) dans `features/studio/components/cloud-file-browser/`. |
| **Amélioration** | Logique métier + UI mélangées | **CommentThread**, **ProfileForm**, **Search** : logique (appels API, état) et rendu (JSX) dans le même composant ; pas de découpage net en hooks + sous-composants. |
| **Perfectionnement** | Réutilisabilité limitée | **GearView**, **ProfileView** : vues “pages” très spécifiques ; extraire des blocs (Header, Stats, List, Filters) permettrait des stories et des tests plus ciblés. |
- **Router** : `parameters.router.initialEntries` pour les stories dépendant d’une route.
- **Thème** : bascule light/dark via globals Storybook (backgrounds).
- **Toasts** : en mode Storybook, toasts loggés en console (pas d’affichage intrusif).
### Problèmes identifiés
| Criticité | Constat | Détail |
|-----------|--------|--------|
| **Amélioration** | Pas de gestion des transitions | Aucun wrapper `prefers-reduced-motion` ni fourniture de context pour désactiver les animations en Storybook. Les transitions CSS (`--duration-*`) sont appliquées telles quelles ; pas de mode “réduit” pour les tests ou l’accessibilité. |
| **Amélioration** | Feedback tactile non simulé | Pas de décorateur ou paramètre pour simuler états tactiles (active, press) ou pointer (hover) de façon déterministe. Utile pour valider les états “pressed” / “hover” de boutons et cartes. |
| **Perfectionnement** | Couleurs de fond en dur | Le décorateur utilise `#0a0a0a` et `#ffffff` en inline style au lieu des tokens (`var(--background)`). En cas d’évolution du thème, le conteneur Storybook peut diverger de l’app. |
| **Perfectionnement** | Pas de “viewport” par défaut | Des viewports custom (mobile, tablet, desktop) existent ; le décorateur ne force pas de viewport par story. Pour un rendu type “app”, un conteneur largeur max (ex. 1440px) pourrait être optionnel. |
### Recommandations
- Ajouter un **paramètre** (ex. `parameters.motion: 'reduce'`) et un wrapper qui applique `prefers-reduced-motion: reduce` (media query ou class) pour tester le comportement sans animations.
- Utiliser **les tokens** pour le fond du conteneur : `background: 'var(--background)'` (et s’assurer que les variables sont bien appliquées dans l’iframe).
- Optionnel : décorateur ou paramètre pour forcer un **état “interaction”** (hover/active) sur le premier élément focusable, pour valider le focus visible et les états actifs dans les stories.
---
## 5. Accessibilité (a11y)
### Ce qui est en place
- **ARIA / rôles** : utilisés dans une soixantaine de composants (table, select, modal, tabs, pagination, breadcrumbs, tooltip, checkbox, progress, alert, etc.).
- **Contrastes** : palette KŌDŌ en oklch avec séparation sémantique (primary, destructive, muted, etc.) ; fonds et textes prévus pour être lisibles.
- **Focus visible** : `button`, `input`, `checkbox`, `select`, `tabs` ont des styles `focus-visible:ring` ou équivalent.
### Problèmes identifiés
| Criticité | Constat | Détail |
|-----------|--------|--------|
| **Bloquant** | Tests a11y non actifs | Tant que `test: 'todo'`, aucune violation a11y ne fait échouer l’audit ni le build. Risque de régressions (contraste, labels, rôles). |
| **Amélioration** | Contraste à vérifier sur cas réels | Les combinaisons `muted-foreground` sur `muted`, ou textes sur “glass” / dégradés, n’ont pas été vérifiées automatiquement. Un audit manuel ou des tests a11y ciblés (contrast, label) sont recommandés. |
| **Amélioration** | Zones cliquables non boutons | Cartes ou lignes entières cliquables sans `role="button"` ni `tabIndex={0}` ni gestion clavier (Enter/Space) — à vérifier dans les composants “card” et “list”. |
| **Perfectionnement** | Annonces live (toasts, chargement) | Pas de revue systématique des `aria-live`, `aria-busy`, `aria-atomic` pour les toasts et états de chargement. |
### Recommandations
- **Activer les tests a11y** dans Storybook : définir `a11y: { runOnly: { type: 'tag', values: ['wcag2a', 'wcag2aa'] } }` (ou équivalent) et intégrer le résultat à l’audit (ou au moins au build Storybook) pour faire échouer en cas de violations.
- Vérifier les **cartes et listes cliquables** : soit `<button>` ou `div` avec `role="button"`, `tabIndex={0}`, et gestion `onKeyDown` (Enter/Space).
- Planifier un **audit contraste** (manuel ou outil) sur les écrans clés (login, player, sidebar, modales) et documenter les ratios pour les combinaisons utilisées.
---
## 6. Tableau de synthèse par criticité
| Criticité | Thème | Action prioritaire |
|-----------|--------|--------------------|
| **Bloquant** | a11y | Activer les tests a11y dans Storybook (retirer `test: 'todo'`, définir des règles WCAG et les faire échouer le job si besoin). |
| **Amélioration** | Design system | Réduire les valeurs arbitraires (h-[…], w-[…]) en les remplaçant par des tokens ou des utilitaires Tailwind cohérents. |
| **Amélioration** | États d’interface | Compléter les stories : Loading réaliste (Button), Empty/Error/Loading pour listes et cartes, états Disabled et si possible Hover/Active. |
| **Amélioration** | Composants dieux | Découper CloudFileBrowser, CommentThread, ProfileForm/ProfileView en sous-composants et hooks testables. |
| **Amélioration** | Illusion applicative | Utiliser les tokens pour le fond du décorateur ; ajouter support reduced-motion et optionnellement états hover/active. |
| **Perfectionnement** | a11y | Revue `aria-live` / `aria-busy` pour toasts et chargement. |
---
## 7. Prochaines étapes suggérées
1.**Court terme** : Activer a11y dans Storybook et corriger les violations bloquantes ; ajouter les stories Empty/Error (et Loading si pertinent) aux composants listes/cartes les plus utilisés.
2.**Moyen terme** : Découper 2–3 composants “dieux” (ex. CloudFileBrowser, CommentThread) et aligner les nouvelles stories sur les tokens (réduction des valeurs arbitraires).
3.**Long terme** : Documenter une grille de hauteurs/largeurs et une checklist “états d’interface” pour toute nouvelle story ; intégrer reduced-motion et feedback tactile dans le décorateur.
---
*Rapport généré dans le cadre de l’audit frontend Veza — Storybook stabilisé, contrat dans `docs/STORYBOOK_CONTRACT.md`.*
