veza/apps/web/dev_audit/frontend/10_recommendations.md

Phase K — Score Global & Recommandations

---

Tableau de synthèse

Catégorie	Score /10	Pondération	Score pondéré	Justification (1 phrase)
Architecture	7.0	×1.3	9.1	Feature-based solide mais migration incomplète (dualité views/features, AuthContext/authStore)
Design System	7.5	×1.0	7.5	SUMI v2.0 mature avec tokens complets, dark/light, quelques fuites z-index
Cohérence UI	6.5	×1.0	6.5	Composants bien centralisés, toast dualité et variant="glass" non défini
Accessibilité	5.5	×1.0	5.5	ARIA correct, focus-visible, mais sémantique HTML insuffisante et skip nav absent
Sécurité	7.0	×1.5	10.5	httpOnly JWT, DOMPurify, Zod, mais open redirect et API keys en localStorage
Performance	6.5	×1.2	7.8	Lazy loading systématique, request dedup, mais React.memo insuffisant
Dette technique	6.0	×1.0	6.0	client.ts monolithe (2237L), dualité structurelle, ~262 any/as any en prod
Scalabilité	6.5	×1.0	6.5	Theming prêt, virtualisation OK, i18n partiel, pas de white-labeling
Maturité perçue	6.5	×1.0	6.5	Identité SUMI distinctive, beta avancée, features ComingSoon
SCORE GLOBAL			66.0 / 99
Moyenne pondérée			6.6 / 10

---

Recommandations immédiates (semaine 1-2)

1. Corriger l'open redirect dans usePlaylistNotifications

• Fichier : features/playlists/hooks/usePlaylistNotifications.ts:203,219,235,251
• Temps estimé : 30 min
• Impact : Ferme une vulnérabilité de sécurité exploitable
• Action : Valider notification.link avant window.location.href (vérifier que l'URL est same-origin ou dans une allowlist)

2. Résoudre la dualité AuthContext vs authStore

• Fichiers : context/AuthContext.tsx, providers/AuthProvider.tsx
• Temps estimé : 2-4h
• Impact : Élimine la source de bugs auth, simplifie le modèle mental
• Action : Supprimer AuthContext.tsx et AuthProvider.tsx, s'assurer que tous les imports utilisent useAuthStore

3. Ajouter un skip navigation link

• Fichier : components/layout/Layout.tsx ou app/App.tsx
• Temps estimé : 30 min
• Impact : Conformité WCAG 2.4.1
• Action : Ajouter <a href="#main-content" className="sr-only focus:not-sr-only ...">Skip to content</a> + id="main-content" sur le <main>

4. Définir la variante glass dans Button

• Fichier : components/ui/button.tsx:14-35
• Temps estimé : 15 min
• Impact : Corrige des boutons sans style dans CloudIntegrationView et GearViewHeader
• Action : Ajouter glass: 'bg-white/10 text-foreground backdrop-blur-md border border-white/20 hover:bg-white/20' dans buttonVariants

5. Supprimer les fichiers legacy auth

• Fichiers : pages/auth/Login.tsx, pages/auth/Register.tsx, pages/auth/Login.test.tsx, pages/auth/Register.test.tsx
• Temps estimé : 30 min
• Impact : Élimine la confusion, réduit le code mort
• Action : Supprimer les fichiers, vérifier qu'aucun import ne les référence

---

Recommandations court terme (mois 1-2)

1. Éclater client.ts (2237L)

• Description : Découper le client HTTP monolithique en modules cohérents
• Prérequis : Aucun
• Effort : L
• Impact : Critique — maintenabilité et testabilité
• Découpage : httpClient.ts, requestValidation.ts, responseCache.ts, requestInterceptors.ts, validationMetrics.ts

2. Terminer la migration components/views/ → features/pages/

• Description : Migrer les 20 sous-dossiers de components/views/ vers features/*/pages/
• Prérequis : Convention de migration définie
• Effort : XL
• Impact : Majeur — architecture cohérente
• Suggestion : Migrer 3-4 views par sprint

3. Unifier le système de toast

• Description : Choisir entre addToast() et toast() react-hot-toast, supprimer l'autre
• Prérequis : Aucun
• Effort : M
• Impact : Majeur — cohérence DX et UX

4. Enrichir la sémantique HTML

• Description : Ajouter <aside> pour la sidebar, <article> pour les cards de contenu, <section> pour les zones de page
• Prérequis : Aucun
• Effort : M
• Impact : Majeur — accessibilité

5. Split usePlaylist.ts (631L)

• Description : Découper en usePlaylistCrud, usePlaylistCollaboration, usePlaylistAnalytics
• Prérequis : Aucun
• Effort : M
• Impact : Modéré — maintenabilité

6. Migrer z-index arbitraires vers tokens SUMI

• Description : Remplacer les ~31 fichiers avec z-[N] par z-[var(--sumi-z-*)] ou les classes utility
• Prérequis : Inventaire z-index complet
• Effort : M
• Impact : Modéré — cohérence design system

7. Ajouter React.memo sur les composants de liste

• Description : Mémoriser TrackList items, PlaylistList items, ChatMessages, SearchResults
• Prérequis : Aucun
• Effort : S
• Impact : Modéré — performance rendu

8. Compléter l'adoption i18n

• Description : Migrer les ~35 fichiers avec strings hardcodées vers t()
• Prérequis : Enrichir en.json et fr.json
• Effort : L
• Impact : Modéré — internationalisation

9. Ajouter loading="lazy" natif sur les images

• Description : Compléter le lazy loading JS par l'attribut natif
• Prérequis : Aucun
• Effort : S
• Impact : Modéré — performance

10. Résoudre la dualité layout/Sidebar vs ui/Sidebar

• Description : Fusionner ou distinguer clairement les deux composants Sidebar
• Prérequis : Comprendre les usages
• Effort : S
• Impact : Modéré — clarté code

---

Recommandations long terme (trimestre)

Consolidation du design system

• Publier SUMI v2.1 avec toutes les variantes manquantes (glass button, etc.)
• Créer un Storybook complet avec tous les composants documentés
• Établir un processus de review design pour chaque PR modifiant un composant UI

Migration architecturale

• Terminer la migration components/views/ → features/pages/
• Évaluer un passage à TanStack Router pour un routing file-based
• Envisager de déplacer les 30 sous-dossiers de components/{domain}/ vers les features correspondantes

Performance

• Implémenter le Server-Side Rendering (SSR) ou Static Site Generation (SSG) pour les pages publiques (profils, marketplace)
• Auditer et optimiser le bundle (tree-shaking framer-motion, subset fonts)
• Ajouter des tests de performance (Lighthouse CI déjà configuré mais non vérifié en fonctionnement)

Accessibilité

• Viser la conformité WCAG 2.1 AA complète
• Ajouter aria-hidden systématique sur les icônes Lucide
• Remplacer les role="button" sur div par des <button> natifs
• Implémenter un audit automatisé a11y dans la CI (pa11y-ci est installé)

---

Verdict final

1. Le frontend est-il présentable pour un investisseur aujourd'hui ?

OUI, avec réserves. Le design system SUMI donne une identité forte et distinctive. L'architecture est ambitieuse et la stack est moderne. Cependant, les 5 routes « ComingSoon », la migration incomplète et le loading screen non-brandé trahissent un produit en développement actif. Pour une démo investisseur, masquer les routes ComingSoon et ajouter un splash screen brandé serait recommandé.

2. Le frontend peut-il scaler sans refonte architecturale ?

OUI. L'architecture feature-based, le design system tokenisé, React Query pour le server state, et Zustand pour le client state sont des choix scalables. La virtualisation et la pagination serveur sont en place. Les problèmes identifiés (migration incomplète, client.ts monolithe) sont des dettes de refactoring, pas des blocages architecturaux. Un refactoring progressif suffit.

3. Une refonte complète est-elle nécessaire ou un refactoring suffit ?

UN REFACTORING SUFFIT. Les fondations sont saines : TypeScript strict, design system formalisé, tests présents, patterns modernes. La dette est structurelle (dualité views/features, AuthContext legacy) et technique (client.ts trop gros, any types), pas architecturale. Un plan de refactoring sur 2-3 mois avec des migrations progressives est la bonne approche.

4. Le projet respecte-t-il les standards minimaux d'un SaaS B2B/B2C en 2025 ?

OUI, pour un produit en beta. Le design system, le theming, l'i18n partiel, la sécurité (httpOnly JWT, CSRF, DOMPurify), les tests, le Storybook, et l'architecture feature-based sont conformes aux standards SaaS. Les lacunes (accessibilité sémantique, skip nav, React.memo, i18n incomplet) sont des points d'amélioration, pas des blocages. Le produit est au-dessus de la moyenne pour un projet en beta mais en dessous des standards d'un produit GA (General Availability).