Bao-Link
Retour aux articles

Atomic Design : Architecture de Composants UI

Illustration éditoriale abstraite haut de gamme pour un article intitulé « Atomic Design : Architecture de composants UI ». L'image représente une hiérarchie minimaliste et sophistiquée de modules géométriques en verre ou en métal, allant de petites unités isolées (atomes) à des structures complexes imbriquées (organismes). Une esthétique raffinée et sobre, mettant l'accent sur la précision structurelle et la modularité.
Partager
LinkedIn X (Twitter) WhatsApp

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.

Roadmap — Développement

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.

Temps de développement économisé
-30%

Réduction du temps de création de nouvelles pages avec une bibliothèque Atomic Design bien structurée

  Brad Frost 

Niveaux hiérarchiques
5

Atomes → Molécules → Organismes → Templates → Pages : chaque niveau ajoute de la complexité

  Brad Frost 

Créateur
Brad Frost

Méthodologie popularisée en 2013 : livre « Atomic Design » disponible gratuitement

  bradfrost.com 

Le Contexte

Qu'est-ce que l'Atomic Design ?

L’Atomic Design est une méthodologie de création de systèmes de design créée par Brad Frost en 2013. Elle s’inspire de la chimie : les atomes (éléments les plus petits) se combinent en molécules, qui forment des organismes, jusqu’aux pages complètes.

Ce n’est pas une méthode CSS, ni une bibliothèque : c’est une convention d’architecture pour organiser vos composants UI, quel que soit le framework (React, Vue, Svelte, Astro) ou la méthode de styling (CSS, Tailwind, CSS-in-JS).

L’objectif : créer une bibliothèque de composants cohérente, réutilisable et maintenable à l’échelle.

📖
Quand les utiliser ?

Dès que vous avez plusieurs composants : sans Atomic Design, chaque développeur crée ses propres boutons, avec des tailles, couleurs et styles divergents.

C’est le plus petit investissement possible pour transformer le chaos en système prévisible. Commencez par là.

🧠
Pourquoi l'Atomic Design ?

L’Atomic Design est comme une recette de cuisine bien organisée : Ingrédients (atomes) → Mélanges (molécules) → Plats préparés (organismes) → Menus (templates) → Repas servi (pages). Chaque niveau s’appuie sur le précédent pour créer un résultat cohérent.

Les 5 Niveaux de l’Atomic Design

Chaque niveau ajoute de la complexité et de la composition. Un composant ne doit exister qu’à un seul niveau.

Atomes : Les Briques Élémentaires

Les atomes sont les plus petites unités fonctionnelles : un bouton, un champ de saisie, une icône, un label. Ils ne contiennent pas d’autre composant : juste du HTML natif. Ils sont le socle de toute la bibliothèque.

jsx
// Button.jsx : Atome
export function Button({ children, variant, ...props }) {
return (
  <button className={`btn btn-${variant}`} {...props}>
    {children}
  </button>
);
}
📖
Astuce

Bénéfice : vous créez un bouton une seule fois, il est réutilisé partout. Fini les 4 versions différentes du même composant dans votre projet.

Molécules : La Première Composition

Une molécule est un groupe fonctionnel d’atomes. Exemple : une barre de recherche (Input + Button), une fiche produit (Image + Title + Price + Button). La molécule est la plus petite unité réutilisable dans une interface.

jsx
// SearchBar.jsx : Molécule
import { Button, Input } from '../atoms';
export function SearchBar({ onSearch }) {
return (
  <form onSubmit={e => { e.preventDefault(); onSearch(e.target.q.value); }}>
    <Input name="q" placeholder="Rechercher..." />
    <Button type="submit">Rechercher</Button>
  </form>
);
}
📖
Astuce

Bénéfice : vous assemblez des briques sans réécrire le code. Une SearchBar composée de Input + Button ne dépend pas du contexte : elle fonctionne partout.

Organismes : Les Sections Complexes

Un organisme est une section complète de l’interface, composée de molécules et d’atomes. Exemple : un en-tête (logo + SearchBar + panier), une liste de produits (ProductCards). Les organismes sont souvent liés à un contexte métier précis.

jsx
// Header.jsx : Organisme
import { SearchBar, ProductCard } from '../molecules';
export function Header({ cartCount }) {
return (
  <header className="header">
    <div className="logo">MonSite</div>
    <SearchBar onSearch={handleSearch} />
    <Button>Panier ({cartCount})</Button>
  </header>
);
}
📖
Astuce

Bénéfice : vous construisez des sections entières en quelques lignes. Le Header est toujours cohérent, quelle que soit la page : le designer et le développeur parlent le même langage.

Templates : La Mise en Page

Un template est une mise en page qui positionne les organismes sans contenu réel. C’est le squelette de la page. Les templates sont souvent créés en amont par le designer dans Figma. Ils servent de contrat entre design et développement.

jsx
// ProductPageTemplate.jsx : Template
export function ProductPageTemplate({ header, filters, products, footer }) {
return (
  <div className="page">
    {header}
    <aside>{filters}</aside>
    <main>{products}</main>
    {footer}
  </div>
);
}
📖
Astuce

Bénéfice : vous validez la structure avant de coder le contenu. Le squelette est prêt, il ne reste plus qu’à le remplir : comme un moule prêt à recevoir le béton.

Pages : L'Instance Finale

La page est une version concrète du template, remplie avec du contenu réel : données API, images, textes. C’est le niveau le plus concret. Chaque page est unique, mais construite à partir des composants des niveaux inférieurs.

jsx
// products.jsx : Page
const data = await fetchProducts();
export default function ProductsPage() {
return (
  <ProductPageTemplate
    header={<Header cartCount={data.cart} />}
    filters={<Filters categories={data.cats} />}
    products={<ProductList items={data.products} />}
  />
);
}
📖
Astuce

Si une page nécessite un composant qui n’existe pas, c’est un signal pour l’ajouter à la bibliothèque.

Structure de Dossiers Recommandée

Voici l’arborescence type d’un projet utilisant l’Atomic Design avec React. Chaque dossier correspond à un niveau.

Arborescence Atomic Design
src/
└── components/
  ├── atoms/              ← Boutons, Inputs, Icons, Labels
  │   ├── Button.jsx
  │   ├── Button.stories.jsx
  │   └── Button.test.jsx
  ├── molecules/          ← SearchBar, ProductCard, FormGroup
  │   └── SearchBar.jsx
  ├── organisms/          ← Header, ProductList, Footer, Sidebar
  │   └── Header.jsx
  ├── templates/          ← PageLayout, ProductPageTemplate
  │   └── ProductPageTemplate.jsx
  └── pages/              ← HomePage, ProductPage, AboutPage
      └── ProductsPage.jsx
i
Information

Les fichiers *.stories.jsx et *.test.jsx suivent une convention de nommage imposée par les outils : Storybook détecte automatiquement les fichiers *.stories.jsx, et les frameworks de test (Jest, Vitest) ceux en *.test.jsx. Le point sépare le nom du composant du type de fichier, comme package.json ou tsconfig.json.

Storybook est optionnel : vous pouvez utiliser l’Atomic Design sans l’intégrer. Pour plus de détails, consultez notre article sur Storybook IntegrationStorybook IntegrationArticleStorybook IntegrationIntégrez Storybook pour documenter et tester vos composants React. Créez un playground interactif pour votre bibliothèque de composants..

Guide de Décision : À Chaque Projet sa Structure

L’Atomic Design n’est pas toujours nécessaire. Tout dépend de la taille et de la complexité du projet.

1

Petit projet (< 10 pages, 1 développeur)

Utilisez une structure plate : components/Button.jsx, components/Header.jsx. Pas besoin d'Atomic Design : la séparation en niveaux ajoute de la complexité sans bénéfice. La règle : si vous avez moins de 20 composants, une structure plate suffit.

2

Projet moyen (10-50 pages, 2-5 développeurs)

Adoptez les 3 premiers niveaux : atoms/, molecules/, organisms/. Laissez de côté templates et pages (gérés par le router). L'Atomic Design devient utile pour organiser la collaboration entre développeurs et designer.

3

Design System complet (50+ pages, équipe dédiée)

Adoptez les 5 niveaux. Ajoutez Storybook pour documenter chaque composant, et des tests visuels (Chromatic, Percy). L'Atomic Design est alors le langage commun entre design et développement : chaque niveau correspond à un niveau de réutilisabilité.

4

Multi-produits (plusieurs applications, Design System partagé)

Étendez l'Atomic Design avec un monorepo (Nx, Turborepo, Lerna) et des workspaces (Yarn, pnpm) : packages/ui/atoms/, packages/ui/molecules/, apps/web/, apps/admin/. Chaque application consomme les composants du Design System via npm. Pour un guide complet, consultez notre article sur .

Cas d’Usage Concret : Refonte E-commerce

Composants audités
200+

composants React sans organisation commune

Gain de temps
40%

plus rapide à créer de nouvelles pages

Cohérence UI
+90%

de cohérence entre les pages

Onboarding
-60%

de temps d'intégration pour un nouveau développeur

Contexte : Une équipe de 5 développeurs gère un e-commerce avec 200+ composants React, chacun créé sans organisation commune.

Problème :

  • 4 versions différentes du composant Button
  • La barre de recherche existe en 3 implémentations
  • Nouveau développeur = 2 semaines pour retrouver ses marques

Solution : Migration vers Atomic Design en 3 phases :

  1. Inventaire : auditer tous les composants, les classifier en atomes/molécules/organismes
  2. Fusion : supprimer les doublons, garder la meilleure version de chaque composant
  3. Documentation : Storybook pour documenter chaque composant avec ses variantes

Résultat (mesuré après 6 mois) : les KPIs ci-dessus parlent d’eux-mêmes.

Atomic Design vs Autres Approches

ApprocheQuand l'utiliserAvantageInconvénient
**Structure plate** (components/Button.jsx)< 20 composantsSimple, pas de learning curvePas de hiérarchie, chaos à grande échelle
**BEM** (convention CSS)Projets CSS uniquementConvention CSS clairePas de composition UI, que du style
**Atomic Design**20+ composants, multi-appsComposition hiérarchique, réutilisableLearning curve initiale, plus de dossiers
i
Information

L’Atomic Design n’exclut pas les autres approches. Vous pouvez combiner Atomic Design (hiérarchie de composants) avec Article en cours de rédaction : bem. (convention CSS). L’important est de choisir une convention et de la respecter. Pour une approche par domaine métier, découvrez notre article sur Article en cours de rédaction : feature-based.


Des zones d'ombre ?

L'Atomic Design est-il une méthode CSS ?
Non. L'Atomic Design est une méthode d'organisation de composants. Le CSS peut être géré avec n'importe quelle approche : CSS Modules, Tailwind, styled-components, CSS-in-JS. L'Atomic Design et le CSS sont orthogonaux : vous pouvez utiliser les deux indépendamment.
Atomic Design marche-t-il avec React, Vue, Svelte ou Astro ?
Oui, avec tous. L'Atomic Design n'est pas lié à un framework : c'est une convention de dossiers et de composition. Les exemples dans cet article sont en React, mais la structure atoms/molecules/organisms/templates/pages fonctionne avec Vue, Svelte, ou même des composants Astro (.astro).
Quelle est la différence entre Atomic Design et composants-ui ?
L'article composants UI est le hub central de tout l'écosystème composants. L'Atomic Design est une méthodologie spécifique d'organisation, détaillée ici. Pensez à composants-ui comme la table des matières, et atomic-design-methode comme un chapitre dédié à cette architecture particulière.
Faut-il toujours respecter strictement les 5 niveaux ?
Non. L'Atomic Design est un guide, pas une règle absolue. Beaucoup d'équipes fusionnent templates et pages, ou ajoutent un niveau sections entre organisms et templates. L'important est la logique de composition (du petit vers le grand), pas le nombre exact de niveaux.
Comment gérer les composants qui existent à plusieurs niveaux ?
C'est un signe que votre découpage n'est pas bon. Un composant doit exister à un seul niveau. Si vous avez besoin du même composant à deux niveaux différents, c'est que soit : (1) il est trop générique (montez-le d'un niveau), soit (2) il fait trop de choses (scindez-le en sous-composants).

Atomic Design : Les Points de Passage

0/10

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.

"

L’atomic design n’est pas une mode : c’est une méthode qui transforme un chaos de composants en un système pensé, durable et scalable.

Gaëtan Solis
Gaëtan Solis
Fondateur, Bao-Link
Orfèvre Digital

Prêt à lancer votre projet ?

Je donne vie à vos idées en créant des sites web et applications intuitifs, esthétiques et fonctionnels.

Orfèvre Digital
Disponible
En savoir plus

Articles Connexes

2+2
Storybook Integration
Connexe

Storybook Integration

Intégrez Storybook pour documenter et tester vos composants React. Créez un playground interactif pour votre bibliothèque de composants.

Composants UI : Le Hub de votre Design System
Cluster Connexe

Composants UI : Le Hub de votre Design System

Construisez et organisez votre bibliothèque de composants UI : design tokens, atomic design, Figma ↔ code, Storybook, et workflow complet du design au déploiement.

Figma pour les Développeurs : Du Design au Code
Brouillon Connexe

Figma pour les Développeurs : Du Design au Code

Maîtrisez le workflow Figma : Auto Layout, Dev Mode, design tokens et extraction de code. Guide pratique pour passer de la maquette au composant sans friction.

BEM : La Convention CSS qui Structure votre Code
Brouillon Connexe

BEM : La Convention CSS qui Structure votre Code

Maîtrisez BEM (Block Element Modifier) : nommage, structure de dossiers, états, et combinaison avec Atomic Design. Convention CSS claire pour tout projet.

Inspiration

Découvrez d'autres projets

Voir le portfolio
Développement 16 juillet 2026

ACM : Refonte E-commerce avec Astro, Express & WordPress

É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.

Astro Astro Express Express WordPress WordPress
Voir le projet
Développement 16 juillet 2026

Soair : La Transition Numérique Complète

É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é.

# Soair WordPress WordPress Hugo Hugo
Voir le projet
Prêt pour l'aventure

Besoin d'un
expert ?

Discutons ensemble de vos objectifs et transformons votre vision en une réalité performante et pérenne.

Prêt pour l'aventure

Suivez Bao-Link

Et restez informé des nouveaux articles et projets.

ou

Newsletter

Un récap par mois de ce qui a vraiment compté. Pas de spam, promis.