Carte interactive
Cette roadmap est conçue pour une navigation sur écran d'ordinateur. Pour une expérience optimale, ouvrez cette page sur un écran plus large.
des équipes frontend ont un design system : le standard de l'industrie
de tâches complétées plus rapidement avec un design system mature
de réduction grâce à la réutilisation de composants et la réduction de dette technique
des entretiens techniques couvrent l'architecture CSS : un enjeu réel pour les équipes
Quand votre projet dépasse 20 composants, le choix de l’architecture frontend devient critique.
Deux décisions clés structurent votre projet :
Chaque approche résout un problème différent, et elles peuvent se combiner. Le choix dépend de votre projet, pas de la tendance du moment.
L’architecture frontend, c’est comme construire une maison :
Le plan (architecture) reste le même quel que soit le matériau (framework). Mais un bon plan avec un matériau inadapté ne fonctionne pas. Choisissez d’abord le plan, puis le matériau.
Objet : Organiser les composants en 5 niveaux : atoms → molecules → organisms → templates → pages. Quand l’utiliser : Design System, bibliothèque de composants réutilisables. Principe : Chaque niveau compose le précédent pour créer des interfaces complexes.
atoms/ ← Button, Input, Icon, Label
molecules/ ← SearchBar, CartItem, LoginForm
organisms/ ← Header, Footer, ProductGrid
templates/ ← LandingPage, Dashboard
pages/ ← index.tsx, product.tsxObjet : Convention de nommage CSS : .block__element--modifier.
Quand l’utiliser : Tout projet CSS, quelle que soit la taille.
Principe : Chaque classe a un nom unique qui décrit sa fonction dans la hiérarchie.
/* Block = le composant principal */
.cart { }
/* Element = un élément enfant du block */
.cart__item { }
.cart__total { }
/* Modifier = une variation du block ou de l'element */
.cart__item--featured { }
.cart--checkout { }Objet : Organiser les fichiers par domaine métier (features/cart/, features/auth/). Quand l’utiliser : Applications métier complexes, multi-équipes. Principe : Tout pour une feature est au même endroit : composants, hooks, utils, styles.
features/
├── cart/
│ ├── components/ ← CartItem, CartSummary
│ ├── hooks/ ← useCart
│ ├── utils/ ← formatPrice
│ └── styles/ ← cart.css
├── auth/
│ ├── components/ ← LoginForm, SignupForm
│ ├── hooks/ ← useAuth
│ └── utils/ ← validateEmail| Critère | Atomic Design | BEM | Feature-based |
|---|---|---|---|
| Objet | Composition de composants | Nommage CSS | Organisation de dossiers |
| Quand l'utiliser | Design System, bibliothèque | Tout projet CSS | Apps métier complexes |
| Échelle | 20+ composants | Toute taille | 50+ composants, multi-équipes |
| Courbe d'apprentissage | Moyenne | Basse | Moyenne |
| Réutilisabilité | Inter-features | Intra-projet | Intra-feature |
| Scalabilité équipe | Bonne | Bonne | Excellente |
BEM suffit. Convention CSS claire, pas de tooling complexe. Organisez votre CSS par block et laissez la structure de dossiers simple (`components/`, `styles/`).
Atomic Design est idéal. La composition hiérarchique (atomes → molécules → organismes) crée un langage commun entre design et développement. Ajoutez Storybook pour documenter.
Feature-based pour l'isolation par domaine. Chaque équipe possède sa feature (auth, cart, dashboard) avec ses composants, hooks et utils. Réduisez les conflits de fusion.
Combinez les approches : Feature-based pour l'organisation des dossiers, Atomic Design pour la composition des composants, BEM pour le nommage CSS. Chaque méthode gère un aspect différent.
Ces trois approches ne sont pas mutuellement exclusives. Vous pouvez les combiner pour couvrir chaque aspect de votre architecture :
Feature-based gère l’organisation des dossiers (par domaine métier). Atomic Design gère la composition des composants au sein de chaque feature.
features/
├── cart/
│ ├── atoms/ ← Button, Input, Icon
│ ├── molecules/ ← CartItem, PriceTag
│ └── organisms/ ← CartSummary, CartHeader
├── auth/
│ ├── atoms/
│ ├── molecules/ ← LoginForm, SignupForm
│ └── organisms/ ← AuthModalFeature-based gère les dossiers. BEM gère le nommage CSS au sein de chaque feature.
/* features/cart/styles/ */
.cart { }
.cart__item { }
.cart__item--featured { }
.cart__total { }
/* features/auth/styles/ */
.auth { }
.auth__form { }
.auth__form--login { }Pour les grands projets : Feature-based (dossiers) + Atomic Design (composants) + BEM (CSS).
features/cart/
├── atoms/
│ ├── Button/
│ │ ├── Button.jsx
│ │ ├── Button.stories.jsx
│ │ └── button.css ← .cart__button {}
├── molecules/
│ └── CartItem/
│ ├── CartItem.jsx
│ └── cart-item.css ← .cart__item {}
└── organisms/Identifier les zones à risque : doublons, incohérences, temps de navigation
Extraire les composants réutilisables en atomes/molécules/organismes
Regrouper par domaine métier quand les équipes dépassent 5 personnes
Approche progressive : Ne migratez pas tout d’un coup. Commencez par BEM (le plus simple), ajoutez Atomic Design quand vous avez besoin de réutilisabilité, passez à Feature-based quand les équipes grandissent.
Atomic Design = la recette qui dit comment assembler les ingrédients (atomes → molécules → plats). BEM = l’étiquetage des bocaux dans les placards (chaque ingrédient a un nom unique). Feature-based = l’organisation de la cuisine par recette (tout pour le gâteau est au même endroit).
| Critère | React | Vue | Svelte | Astro |
|---|---|---|---|---|
| Type | Bibliothèque UI | Framework progressif | Compilateur | Framework content-first |
| Part de marché | 42% | 18% | 8% | 4% |
| Performance | Bonne (Virtual DOM) | Bonne (Proxy) | Excellente (compilation) | Excellente (zéro JS) |
| Courbe d'apprentissage | Moyenne | Basse | Basse | Basse |
| Écosystème | Massif (npm) | Mature | En croissance | En croissance |
| SSR/SSG | Next.js, Remix | Nuxt | SvelteKit | Natif |
Astro : Zéro JS par défaut, performance maximale, SEO excellent. Idéal pour le contenu statique et les sites orientés performance.
React : Écosystème massif, state management mature. Ajoutez Next.js uniquement si vous avez besoin de SSR/SSG pour le SEO ou d'un backend intégré. Pour un outil interne, React seul suffit.
Vue + Nuxt : Syntaxe intuitive, progressif, documentation excellente. Parfait pour les équipes qui veulent simplicité et productivité.
Svelte : Performance native, compilation sans Virtual DOM. Le framework le plus rapide pour les interfaces riches en animations.
React ou Vue : Composants riches, bibliothèques UI (MUI, Ant Design, Vuetify). Les deux offrent un écosystème mature pour l'enterprise.
Astro ou Next.js : Astro pour le catalogue (SSG), Next.js pour le panier temps réel (SSR). Les deux gèrent le SEO.
Faut-il utiliser une bibliothèque existante ou créer sa propre solution ?
| Critère | Bibliothèque | Implémentation Maison |
|---|---|---|
| Temps de mise en place | ⚡ Rapide | 🐢 Lent |
| Maintenance | ✅ Géré par la communauté | ⚠️ À votre charge |
| Personnalisation | ⚠️ Limitée par l'API | ✅ Totale |
| Taille (bundle) | ⚠️ Parfois lourde | ✅ Optimale |
| Accessibilité | ✅ Souvent testée | ⚠️ À tester soi-même |
| Apprentissage | 📚 Courbe d'apprentissage | 🎯 Connaissances internes |
Règle pratique : Si la bibliothèque fait < 20% du travail et vous pousse à contourner 80% du temps, implémentez-le maison. Sinon, utilisez la bibliothèque.
Vue et Svelte n’ont pas d’article dédié dans la bambouseraie. Car **je me suis spécialisé **coté frontend dans React, NextJs et Astro, je ne voudrais pas crée de contenu erroné sur un framework que je n’utilise pas régulièrement.
React = la voiture : polyvalente, écosystème massif, partout dans le monde. Vue = le tramway : simple, efficace, parfait pour les trajets définis. Svelte = le vélo électrique : léger, rapide, zéro émission. Astro = le train à grande vitesse : performant pour les longues distances (contenu statique).
Comment choisir entre o2switch, Vercel, Hetzner et Cloudflare pour héberger votre frontend ?
Découvrez l'article complet
en un clic
Le CSS a ses propres patterns. BEM est le plus connu, mais pas le seul :
| Méthodologie | Signification | Principe | Quand l'utiliser |
|---|---|---|---|
| BEM | Block Element Modifier | .block__element--modifier : convention de nommage | Le plus simple, tout projet |
| OOCSS | Object-Oriented CSS | Sépare structure (layout) et skin (visuel) | Haute réutilisabilité visuelle |
| SMACSS | Scalable & Modular Architecture for CSS | 5 catégories : Base, Layout, Module, State, Theme | Sites à contenus distincts |
| ITCSS | Inverted Triangle CSS | Triangle inversé : Settings → Tools → Generic → Elements → Objects → Components → Utilities | Grandes équipes, enterprise |
Combo courante : BEM pour le nommage + ITCSS pour la structure. C’est le standard de l’industrie pour les projets scalables.
Au-delà d’Atomic Design, d’autres patterns existent :
| Pattern | Description | Quand l'utiliser |
|---|---|---|
| Atomic Design | Hiérarchie atoms → molecules → organisms → templates → pages | Design Systems |
| Compound Components | Parent gère l'état via Context, enfants composent ensemble | Tabs, modals, dropdowns |
| Headless Components | Expose la logique sans markup (ex: useCombobox()) : le composant gère l'état, les événements et l'accessibilité, mais c'est vous qui définissez le HTML rendu | Bibliothèques accessibles (Radix UI, Headless UI, React Aria) |
| Custom Hooks | Logique réutilisable via use* | React moderne, composition |
| Container/Presentational | Containers = logique, Presentational = UI | Séparation nette, Storybook |
Headless = “sans markup” = pas de HTML imposé. Vous définissez votre propre structure HTML et CSS, la bibliothèque gère uniquement la logique (état, événements, accessibilité). À ne pas confondre avec “unstyled” qui fournit le HTML mais pas le CSS. Découvrir les autres types de composants
ArticleComposants UI : Le Hub de votre Design SystemConstruisez et organisez votre bibliothèque de composants UI : design tokens, atomic design, Figma ↔ code, Storybook, et workflow complet du design au déploiement.
Singleton, Factory, Observer, Strategy : quels patterns GoF sont réellement utiles en frontend ?
En cours de rédaction
Cet article est en cours de rédaction. Inscrivez-vous à la newsletter pour être averti de sa publication.
Newsletter
Un récap par mois de ce qui a vraiment compté. Pas de spam, promis.
Comment organiser vos fichiers au-delà de Feature-based ?
| Pattern | Structure | Quand l'utiliser |
|---|---|---|
| Flat (by type) | components/, hooks/, utils/ | Petits projets, prototypes |
| Domain-Driven-Design (DDD) | user/, order/, payment/ | Apps métier complexes |
| Feature-based | features/cart/, features/auth/ | Multi-équipes |
| Feature-Sliced Design | app/ > pages/ > widgets/ > features/ > entities/ > shared/ | Tendance 2025 : le plus recommandé |
Feature-Sliced Design (FSD) est devenu le pattern de référence en 2025. Il aligne le code avec les besoins métier et impose des frontières claires entre les modules.
Vos progrès sont sauvegardés localement sur votre appareil. Aucune donnée n'est collectée. La durée de conservation dépend de la durée de rétention des données de votre navigateur.
Le meilleur choix d’architecture frontend, c’est celui qui évolue avec votre projet : pas celui qui suit la dernière tendance.
Je donne vie à vos idées en créant des sites web et applications intuitifs, esthétiques et fonctionnels.
Vue d'ensemble des design patterns frontend, backend, CSS, composants, state management et anti-patterns. Guide de décision pour choisir le bon pattern selon votre contexte.
Créez des composants React réutilisables avec les patterns Atom/Molecule/Organism. Maîtrisez les props, le state et la composition de composants.
Maîtrisez les composants Astro (.astro) avec leurs slots, props et patterns. Créez des composants performants avec zero JavaScript par défaut.
Explorez les API CSS les plus récentes : Container Queries, CSS Nesting, @layer, la pseudo-classe :has() et les sélecteurs modernes. Techniques qui redéfinissent l'écriture du CSS.
Maîtrisez les variables CSS avancées : thème dark/light automatique, fallbacks robustes, manipulation JavaScript et cas d'usage concrets pour des thèmes dynamiques.
L'Atomic Design est une méthodologie de conception de systèmes de composants UI. Organisez votre bibliothèque en Atomes, Molécules, Organismes, Templates et Pages.
Maîtrisez BEM (Block Element Modifier) : nommage, structure de dossiers, états, et combinaison avec Atomic Design. Convention CSS claire pour tout projet.
Adoptez l'architecture Feature-based pour structurer votre projet frontend par domaine métier. Composants, hooks, utils, styles : tout dans une feature.
Guide complet des monorepos : pnpm workspaces, Turborepo, Nx et Lerna. Comparaison, arborescence, CI/CD et cas d'usage concrets.
React est la bibliothèque JavaScript la plus utilisée pour créer des interfaces utilisateur. Maîtrisez les composants, les hooks, le state management et l'écosystème React.
Astro est le framework web optimisé pour le contenu. Créez des sites rapides avec l'architecture Islands, zéro JavaScript par défaut et multi-frameworks.
Créez des hooks personnalisés pour réutiliser la logique d'état et d'effets secondaires. Découvrez les patterns avancés de composition de hooks.
L'Islands Architecture d'Astro permet d'isoler les composants interactifs en îlots de JavaScript, optimisant les performances au maximum.
Le projet Bao-Link raconte l'évolution du site et de ses outils: la création d'un premier site WordPress vitrine, puis le passage à Astro avec un site 100% sur mesure, sans template, centré sur le SEO et l'expérience utilisateur ainsi que les projets liés : diag-application et personas.
Étude de cas complète : migration d'un site e-commerce WordPress/WooCommerce vers une architecture Astro SSR + proxy Express, avec déploiement et optimisation SEO.
Étude de cas complète : création d'un site WordPress professionnel puis migration vers Hugo pour des performances optimales et un SEO décuplé.
Discutons ensemble de vos objectifs et transformons votre vision en une réalité performante et pérenne.
