Bao-Link
Retour aux articles

Composants UI : Le Hub de votre Design System

Schéma d'architecture d'un design system (DS) montrant la hiérarchie des composants, des atomes aux templates, avec les connexions entre Figma et le code
Partager
LinkedIn X (Twitter) WhatsApp

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

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.

Un Design System (DS) n’est Pas une Bibliothèque

Cohérence UI
+20 %

de taux de conversion constaté après mise en place d'un design system cohérent (Forrester)

Temps de développement
-30 %

réduction du temps de création de nouvelles pages avec une bibliothèque de composants réutilisables

Votre designer livre des maquettes impeccables, et votre développeur code un truc qui n’y ressemble pas ? Le problème n’est pas le talent : c’est l’absence d’un langage commun.

Le Contexte

Design System ≠ Bibliothèque de Composants

Beaucoup confondent design system et bibliothèque de composants. Une bibliothèque vous donne des Lego. Un design system vous donne la notice, les plans, les règles d’assemblage, les couleurs, les tolérances : et les Lego.

En pratique :

  • Design system → l’ensemble des règles, tokens, composants, documentation et outils
  • Bibliothèque de composants → l’implémentation technique (React, Astro, Vue)
  • Style guide → la partie visuelle uniquement (couleurs, typographie, espacements)

Le design system est le conteneur. La bibliothèque de composants est le contenu.

i
Information

Cet article est le hub central de tout l’écosystème composants UI. Chaque sous-sujet (tokens, atomic design, outils, frameworks) est détaillé dans un article dédié. Utilisez les liens ci-dessous pour naviguer.

📖
Quand adopter un design system

3+ projets ou 5+ développeurs : c’est le seuil où un ** Design System dédié devient rentable**. Avant, une bibliothèque informelle suffit : le surcoût de maintenance dépasserait les bénéfices.

🧠
Analogie

Un Design System est une recette de cuisine : les tokens sont les ingrédients, les composants les préparations, la documentation la recette. Sans recette, chaque cuisinier improvise.

SANS DESIGN SYSTEM
  • Chaque page est conçue et développée de zéro
  • 3 nuances de vert différentes dans la même app
  • Les boutons n’ont pas la même hauteur selon les pages
  • Refonte = tout casser et recommencer
  • L’équipe passe 40 % du temps à corriger des incohérences
AVEC DESIGN SYSTEM
  • Bibliothèque de composants réutilisables
  • Tokens unifiés (Design ↔ Code en synchro)
  • Cohérence visuelle garantie sur toutes les pages
  • Refonte = changer les tokens, les composants suivent
  • L’équipe se concentre sur la valeur métier

Les 5 Piliers d’un Design System

PilierRôleArticles clés
Design TokensLe vocabulaire visuel unifiécouleurs, typo, espacements, ombres, breakpoints
ComposantsLes briques d'interface réutilisablesatomes, molécules, organismes, variants
ArchitectureLa méthodologie d'organisationAtomic Design, hiérarchie, composition
DocumentationLe catalogue vivant des composantsStorybook, tests visuels, playground
WorkflowLe flux Design → CodeFigma, tokens, intégration, QA, déploiement

Design Tokens

Design Tokens : Le Vocabulaire Visuel

Les tokens sont les atomes de votre langage de design : couleurs, typographie, espacements, ombres, breakpoints. Ils unifient Figma et le code.

📖
Quand les utiliser

Dès 2 dashboards ou 3 pages : les tokens sont le plus petit investissement possible pour un design system. Commencez par eux.

🧠
Analogie

Les tokens sont les notes de musique du design : seuls, ils ne font pas un UI, mais sans eux, design et développement ne jouent pas dans le même orchestre.

?

Du Figma au CSS

Comment transformer vos couleurs Figma en variables CSS exploitables par vos composants React, sans erreur humaine ni duplication ?

Découvrez l'article complet
en un clic

Design Tokens

Exemple de token

css
--color-primary: #22c55e;
--space-md: 16px;
--font-body: 1rem/1.5 "Inter", sans-serif;

Même token dans Figma, dans le thème React, et dans les variables CSS.

  • Couleurs : primaire, secondaire, neutre, sémantique (succès, erreur, avertissement)
  • Typographie : famille, échelle (display, heading, body, caption), graisses, hauteurs de ligne
  • Espacements : échelle 4/8/12/16/20/24/32/48/64 px
  • Ombres : définition des profondeurs (sm, md, lg, xl)
  • Breakpoints : points de rupture responsive (sm, md, lg, xl, 2xl)
  • Motion : durées, easing, transitions standardisées

Composants

Composants : Les Briques de l’Interface

Chaque composant est un élément d’interface encapsulé avec son style, sa logique et ses variants. Il existe en version Atome (bouton, input), Molécule (barre de recherche), et Organisme (navigation, formulaire).

📖
Quand créer un composant

Règle des 3 occurrences : même pattern visuel utilisé 3 fois dans l’interface → extrayez-le en composant. Avant, le coût d’abstraction dépasse le bénéfice.

🧠
Analogie

Un composant bien conçu est une brique Lego : forme précise, assemblage standard, réutilisable partout, remplaçable sans tout casser.

?

Un Composant Bien Typé

Comment un composant React expose-t-il ses variants (default, hover, error, disabled) tout en restant typé en TypeScript, sans duplication de code ?

Bientôt disponible

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.

Composant React : Props typées et variants
interface ButtonProps {
variant: 'primary' | 'secondary' | 'ghost';
size: 'sm' | 'md' | 'lg';
disabled?: boolean;
children: React.ReactNode;
onClick?: () => void;
}

export function Button({ variant, size, disabled, children, onClick }: ButtonProps) {
const base = 'rounded-lg font-medium transition-colors';
const variants = {
  primary: 'bg-emerald-600 text-white hover:bg-emerald-700',
  secondary: 'bg-stone-200 text-stone-900 hover:bg-stone-300',
  ghost: 'bg-transparent text-stone-600 hover:bg-stone-100',
};
const sizes = { sm: 'px-3 py-1.5 text-sm', md: 'px-4 py-2', lg: 'px-6 py-3 text-lg' };

return (
  <button
    className={`${base} ${variants[variant]} ${sizes[size]}`}
    disabled={disabled}
    onClick={onClick}
  >
    {children}
  </button>
);
}

Un bon composant

✅ Props typées (TypeScript)
✅ Variants documentés (default, hover, active, disabled, error)
✅ Accessible (ARIA, focus, contraste)
✅ Responsive (s’adapte au contexte)
✅ Testé (tests unitaires + visuels)

Les pièges à éviter

❌ Composant trop générique (veut tout faire, ne fait rien bien)
❌ Props qui mutent le style depuis l’extérieur (adieu la cohérence)
❌ Composant de 500 lignes (monolithe, pas un composant)
❌ Pas de documentation (dans 3 mois, personne ne saura comment l’utiliser)

Architecture

Architecture : Atomic Design

La méthodologie Atomic Design organise vos composants en 5 niveaux hiérarchiques qui garantissent évolutivité et cohérence.

📖
Quand l'utiliser

10+ pages et 3+ développeurs : seuil où l’Atomic Design devient rentable. En dessous, une hiérarchie plate (composants / pages) suffit.

🧠
Analogie

L’Atomic Design, c’est construire une maison :

  • atomes = briques,
  • molécules = murs,
  • organismes = pièces,
  • templates = plans,
  • pages = maison.
?

200 Composants, une Structure

Comment organiser 200 composants dans une arborescence Atomic Design sans se perdre entre atoms/, molecules/ et organisms/ ?

Découvrez l'article complet
en un clic

Atomic Design
Analyse Technique : Avancé
Atomic Design : Arborescence
design-system/
├── tokens/
│ ├── colors.css
│ ├── typography.css
│ └── spacing.css
├── atoms/
│ ├── Button.tsx
│ ├── Input.tsx
│ └── Label.tsx
├── molecules/
│ ├── SearchBar.tsx
│ ├── Card.tsx
│ └── Modal.tsx
├── organisms/
│ ├── Header.tsx
│ ├── Footer.tsx
│ └── ContactForm.tsx
├── templates/
│ ├── Landing.tsx
│ └── Dashboard.tsx
└── pages/
├── index.tsx
└── dashboard.tsx

L’Atomic Design structure visuellement votre projet en 5 niveaux. Cette arborescence montre comment un simple atome (le bouton) se compose jusqu’à former une page complète.

NiveauRôleExempleAutonome ?
AtomsÉlément de baseBouton, Input, Icône✅ Oui
MoleculesAssemblage d'atomesBarre de recherche✅ Oui
OrganismsSection fonctionnelleHeader, Formulaire✅ Oui
TemplatesStructure de pageLanding, Dashboard❌ Non (a besoin de contenu)
PagesInstance de templateindex.tsx✅ Oui

Documentation

Documentation : Storybook

Storybook est le catalogue vivant de vos composants : chaque composant est présenté avec ses états, ses variants, son code source, et même des tests visuels.

📖
Quand l'utiliser

15+ composants ou 3+ développeurs : Storybook devient indispensable. En dessous, une documentation MDX légère suffit.

🧠
Analogie

Storybook est le showroom de vos composants : chaque modèle dans toutes ses finitions, fiche technique incluse, essai possible. Sans showroom, vos composants restent invisibles.

?

Documentation qui s'Écrit Seule

Comment configurer Storybook pour auto-générer la documentation des props TypeScript d'un composant, sans l'écrire manuellement ?

Découvrez l'article complet
en un clic

Storybook Integration
Storybook : Story d'un composant Button
import type { Meta, StoryObj } from '@storybook/react';
import { Button } from './Button';

const meta: Meta<typeof Button> = {
title: 'Atoms/Button',
component: Button,
argTypes: {
  variant: { control: 'select', options: ['primary', 'secondary', 'ghost'] },
  size: { control: 'select', options: ['sm', 'md', 'lg'] },
},
};

export default meta;
type Story = StoryObj<typeof Button>;

export const Primary: Story = {
args: { variant: 'primary', children: 'Cliquer' },
};

export const Secondary: Story = {
args: { variant: 'secondary', children: 'Annuler' },
};

export const Disabled: Story = {
args: { variant: 'primary', disabled: true, children: 'Désactivé' },
};

Avantages de Storybook

Playground interactif pour chaque composant
Tests visuels (Chromatic, Loki) pour détecter les régressions
Documentation auto-générée à partir du code
Addons : accessibilité, themes, knobs, actions

Workflow

Workflow Design → Code

Le flux de travail idéal va de la maquette Figma au composant React/Astro sans perte d’information.

📖
Quand l'automatiser

Dès qu’un designer et un développeur collaborent : automatisez le pont Figma → Code. C’est le plus gros gain de productivité d’un design system.

🧠
Analogie

Ce workflow est une chaîne de montage : le designer conçoit (Figma), les tokens sont le cahier des charges, les développeurs construisent les pièces (composants), la QA (Quality Assurance) vérifie l’assemblage (tests visuels,Chromatic,…), le déploiement livre au client.

?

Figma → Code Automatisé

Comment connecter Figma → Tokens Studio → variables CSS sans réécrire manuellement chaque token à chaque mise à jour ?

Bientôt disponible

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.

Workflow : Token Figma exporté en CSS
// tokens.json (exporté depuis Tokens Studio / Figma)
{
"color": {
  "primary": { "value": "#22c55e", "type": "color" },
  "secondary": { "value": "#6366f1", "type": "color" },
  "background": { "value": "#ffffff", "type": "color" }
},
"space": {
  "sm": { "value": "8px", "type": "spacing" },
  "md": { "value": "16px", "type": "spacing" },
  "lg": { "value": "32px", "type": "spacing" }
},
"font": {
  "body": { "value": "1rem/1.5 Inter", "type": "typography" }
}
}
Workflow : Variables CSS générées
/* tokens.css (généré par Style Dictionary) */
:root {
--color-primary: #22c55e;
--color-secondary: #6366f1;
--color-background: #ffffff;
--space-sm: 8px;
--space-md: 16px;
--space-lg: 32px;
--font-body: 1rem/1.5 Inter;
}
1

1. Design dans Figma/Penpot

Créez les composants avec Auto Layout, définissez les tokens.

2

2. Export des tokens

Plugins (Tokens Studio, Design Tokens) → JSON → variables CSS.

3

3. Intégration en code

Composants React/Astro qui consomment les tokens via les variables CSS.

4

4. Documentation

Storybook pour cataloguer, tester et documenter chaque composant.

5

5. QA + Déploiement

Tests visuels + a11y + Lighthouse avant merge.

Les outils du workflow

Design

Figma, Penpot, Sketch

Tokens

Tokens Studio, Style Dictionary

Composants

React, Astro, Vue, Svelte

Documentation

Storybook, Catalog, Docusaurus

Tests

Chromatic, Loki, Percy

Déploiement

CI/CD, npm pack, GitHub Packages


Headless vs Styled vs Unstyled : Comprendre la Différence

Le choix entre un composant headless, styé ou unstyled détermine votre niveau de contrôle sur l’interface.

TypeMarkup (HTML)CSSLogiqueExemples
Headless❌ Vous créez❌ Vous gérez✅ GéréRadix UI, Headless UI, React Aria
Avec styles✅ Fourni✅ Fourni✅ GéréMUI, Chakra UI, Ant Design
Unstyled✅ Fourni❌ Vous gérez✅ GéréBase UI, Ark UI
i
Information

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.

🧠
L'analogie du moteur de voiture
  • Headless = le moteur seul (la logique). Vous fournissez TOUT le reste : châssis & intérieur (HTML), carrosserie & peinture (CSS).
  • Avec styles = une voiture clé en main (moteur + châssis & intérieur + carrosserie & peinture).
  • Unstyled = le moteur + le châssis & intérieur monté (la logique et le HTML fourni), mais sans carrosserie ni peinture (CSS à créer).

Quand utiliser chaque type ?

ContexteType recommandéPourquoi
Design System sur-mesureHeadlessContrôle total sur le HTML et CSS
Prototype rapideAvec stylesTout est fourni, pas de config
Migration progressiveUnstyledHTML standard, CSS à ajouter
Accessibilité critiqueHeadlessLogique d'accessibilité testée

Bibliothèques Headless populaires

BibliothèqueFrameworkDescription
Radix UIReactPrimitives non stylées, accessibles
Headless UIReact, VueComposants sans styles, transitions
React AriaReactHooks d'accessibilité Adobe
Ark UIReact, Vue, SvelteComposants machine à états
Base UIReactComposants non stylés Google

Maturité d’un Design System

Tout design system passe par des stades de maturité. Voici comment évolue le vôtre :

  • Bibliothèque informelle

    Quelques composants copiés-collés d'un projet à l'autre. Pas de tokens, pas de documentation.

  • Bibliothèque structurée

    Composants extraits dans un package partagé. Les bases commencent à être documentées.

  • Design system naissant

    Tokens définis, composants documentés (Storybook), premiers tests visuels.

  • Design system mature

    Figma ↔ Code synchronisé, CI/CD avec tests visuels, thème clair/sombre, a11y intégré.

  • Design system contributif

    Toute l'équipe contribue, les designers modifient les tokens dans Figma → PR automatique, les composants sont utilisés en production par 5+ projets.

tokens.css : Structure d'un design system
/* tokens.css : Généré par Style Dictionary */
@layer tokens {
:root {
  /* Couleurs */
  --color-primary-500: #0ea5e9;
  --color-success: #22c55e;
  
  /* Typographie */
  --font-sans: 'Inter', system-ui, sans-serif;
  --text-base: 1rem;
  
  /* Espacements */
  --space-4: 1rem;
  --space-8: 2rem;
  
  /* Bordures */
  --radius-md: 0.375rem;
}
}

/* theme-provider.tsx */
export function ThemeProvider({ children }) {
return <div data-theme="light">{children}</div>;
}

Des zones d'ombre ?

Faut-il un design system dès le premier projet ?
Non. Un design system prend du temps à construire et à maintenir. Commencez par un projet, identifiez les patterns qui se répètent, et extrayez-les progressivement dans une bibliothèque. Lancez un design system officiel quand vous avez au moins 3 projets ou une équipe de 5+ développeurs.
Quel framework choisir pour les composants ?
React est le plus mature (Storybook, Chromatic, Testing Library). Astro est excellent pour les sites statiques avec des îles interactives. Vue et Svelte sont aussi de bonnes options. Le choix dépend de votre stack : si le projet est en Astro + React, utilisez React pour les composants interactifs et Astro pour les composants statiques.
Comment éviter le décalage Figma ↔ Code ?
La clé : les design tokens comme source de vérité unique. Si le designer modifie la couleur primaire dans Figma, le token change dans le fichier JSON exporté, et le développeur l'importe dans les variables CSS. Utilisez un plugin comme Tokens Studio pour Figma ou Design Tokens pour Penpot. L'idéal : une CI qui bloque si les tokens Figma et les variables CSS divergent.
Storybook vaut-il le coup pour un petit projet ?
Pour un projet solo ou une petite équipe (< 3 personnes), Storybook peut être overkill. Utilisez une documentation plus légère : un fichier MDX par composant, ou un catalogue via votre framework (Astro Viewer par exemple). Ajoutez Storybook quand l'équipe grandit ou quand vous avez besoin de tests visuels automatisés.
Quelle est la différence entre un design token et une variable CSS ?
Un design token est une décision de design (la couleur primaire est #22c55e). Une variable CSS est une implémentation technique (--color-primary: #22c55e). Le token existe dans Figma, dans le JSON, dans le code. La variable CSS est une représentation du token dans le navigateur. Les tokens sont la source de vérité, les variables CSS sont un canal de transmission.

Checklist Design System

Composants UI : 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.

"

Un design system, c’est comme une recette de cuisine : elle ne garantit pas un bon plat, mais sans elle, chaque cuisinier improvise avec des résultats différents.

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 du Cluster

1

Articles Connexes

2+9
Composants React
Cluster Brouillon Connexe

Composants React

Créez des composants React réutilisables avec les patterns Atom/Molecule/Organism. Maîtrisez les props, le state et la composition de composants.

Composants Astro
Brouillon Connexe

Composants Astro

Maîtrisez les composants Astro (.astro) avec leurs slots, props et patterns. Créez des composants performants avec zero JavaScript par défaut.

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.

Penpot : Le Design Open Source par les Standards du Web
Brouillon Connexe

Penpot : Le Design Open Source par les Standards du Web

Découvrez Penpot, l'alternative open source à Figma : SVG et CSS natifs, auto-hébergement, collaboration temps réel et souveraineté des données.

Atomic Design : Architecture de Composants UI
Connexe

Atomic Design : Architecture de Composants UI

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.

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.

Tokens Figma
Brouillon Connexe

Tokens Figma

Synchronisez vos design tokens entre Figma et votre code. Utilisez les plugins et outils pour maintenir la cohérence design-dev.

Theme Provider
Brouillon Connexe

Theme Provider

Implémentez un provider de thème pour gérer les thèmes clair/sombre et les tokens. Utilisez React Context ou les CSS variables pour une solution performante.

Variables CSS Avancées : Dark Mode, Thèmes Dynamiques et Custom Properties
Brouillon Connexe

Variables CSS Avancées : Dark Mode, Thèmes Dynamiques et Custom Properties

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.

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.

Feature-based Architecture : Organiser par Domaine Métier
Brouillon Connexe

Feature-based Architecture : Organiser par Domaine Métier

Adoptez l'architecture Feature-based pour structurer votre projet frontend par domaine métier. Composants, hooks, utils, styles : tout dans une feature.

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.