Architecture dossiers : la structure qui scale à 500+ fichiers

Architecture dossiers Vite/Next : la structure qui scale à 500+ fichiers

Une bonne structure de dossiers évite 70% des "où est ce composant ?". La règle Next Generation : organisation par domaine, pas par type.

Mauvais : organisation par type technique

src/
├── components/  (200 fichiers en vrac)
├── hooks/       (50 fichiers)
├── utils/       (80 fichiers)

→ Impossible de retrouver "tout ce qui touche au funnel".

Bon : organisation par domaine (feature-first)

src/
├── features/
│   ├── newsletter/
│   │   ├── components/
│   │   ├── hooks/
│   │   ├── api.ts
│   │   └── types.ts
│   ├── repurposing/
│   └── funnel/
├── components/
│   ├── ui/        (shadcn primitives)
│   ├── shared/    (composants vraiment réutilisés)
│   └── seo/       (jsonLd, SeoLayoutShell)
├── pages/         (1 fichier par route)
├── config/        (constantes décentralisées)
├── data/          (contenu statique typé)
├── lib/           (helpers cross-domaine)
└── integrations/  (supabase/, ai/, …)

Règles

• Un fichier features/X/components/Foo.tsx n'est consommé QUE par la feature X. S'il devient cross-feature → migrer vers components/shared/.
• Pas plus de 2 niveaux d'imbrication par feature.
• Les types vivent à côté du code qui les utilise. Pas de types.ts global de 800 lignes.
• index.ts barrel uniquement pour les exports publics d'une feature.

Anti-pattern : utils.ts géant

src/lib/utils.ts à 1200 lignes = tombe-tout. Split par domaine : stringUtils.ts, dateUtils.ts, urlUtils.ts. Chacun ≤ 200l.