Un design system est un système vivant qui te permet de gérer les couleurs, la typographie, les espacements, les composants et les règles depuis une source unique, puis de les réutiliser de façon cohérente sur chaque produit, au lieu de concevoir chaque écran de zéro. On le confond avec une charte graphique, mais la différence est la suivante : un document décrit seulement « à quoi cela doit ressembler », tandis qu'un design system fournit aussi du code fonctionnel, des composants prêts à l'emploi et les règles pour les combiner. Autrement dit, il fait parler designers et développeurs la même langue.
Que résout réellement un design system ?
Sur un petit projet, tu peux écrire la couleur d'un bouton directement dans l'écran sans que personne ne le remarque. Mais avec dix, vingt, cinquante écrans, les petites décisions dispersées partout (#3b82f6 à un endroit, #3a80f0 à un autre) se transforment en incohérence et en cauchemar de maintenance. Un design system centralise ces décisions et résout ces problèmes :
- Cohérence : le même bouton, le même espacement, la même ombre sur chaque page.
- Vitesse : construire un nouvel écran devient aussi simple que d'assembler des pièces prêtes.
- Maintenance : changer la couleur de marque se résume à mettre à jour une seule valeur.
- Langage commun : le designer dit « bouton primary » et le développeur connaît le composant exact.
Couche 1 : les design tokens
Un token est la plus petite unité nommée d'une décision de design. Au lieu d'une valeur brute #1e293b, tu lui donnes un nom signifiant comme color-text-primary. Ainsi le nom reste stable même si la valeur change, et tout se met à jour automatiquement. L'approche la plus propre utilise deux niveaux de tokens : d'abord les valeurs brutes (primitives), puis les alias sémantiques.
:root {
/* Primitif : valeurs brutes */
--blue-500: #3b82f6;
--slate-900: #0f172a;
--space-2: 8px;
--space-3: 12px;
/* Sémantique : alias qui expriment l'intention */
--color-action: var(--blue-500);
--color-text: var(--slate-900);
--radius-button: 8px;
}
.btn-primary {
background: var(--color-action);
color: white;
padding: var(--space-2) var(--space-3);
border-radius: var(--radius-button);
}Pour passer en thème sombre, tu redéfinis seulement les tokens sémantiques ; tu ne touches jamais au code des composants. C'est exactement là que réside l'évolutivité.
Couche 2 : les composants
Si les tokens sont la peinture, les composants sont les briques. Bouton, champ de saisie, carte, modale, navigation... chacun est une pièce autonome qui utilise des tokens et se réutilise sans cesse. Un bon composant est conçu avec ses variantes : les styles primary/secondary/ghost d'un bouton, ses états hover et disabled, ses tailles small/medium/large. Il faut y penser de façon systématique, pas un par un.
- Approche atomique : de petites pièces (atomes) se combinent en plus grandes (molécules, organismes).
- Responsabilité unique : un composant fait bien une chose ; tu n'y enfouis pas de logique métier.
- Accessibilité dès le départ : focus clavier, contraste et attributs ARIA sont intégrés au composant.
Couche 3 : documentation et règles d'usage
Même les meilleurs tokens et composants sont inutiles si personne ne sait s'en servir. La documentation explique, avec des exemples, à quoi sert chaque composant, quand l'utiliser (et quand ne pas l'utiliser). En pratique, trois éléments sont recommandés : des exemples de composants en direct, du code copiable et des règles « do / don't ». Des outils comme Storybook sont courants pour montrer les composants dans un environnement isolé ; côté design, les bibliothèques Figma exposent les mêmes tokens et composants aux designers.
Comment une petite équipe le met-elle en place ?
Tenter de bâtir un système géant de zéro est un piège pour la plupart des petites équipes. La voie réaliste est d'avancer par étapes :
- 1. Fais l'inventaire : combien de boutons, de couleurs et de tailles de police différents ton produit actuel a-t-il ? Souvent bien plus que nécessaire.
- 2. Commence par les tokens : fige les échelles de couleur, de typographie et d'espacement. C'est ici que le retour est le plus élevé.
- 3. Standardise les 5 à 10 composants les plus utilisés : bouton, champ, carte suffisent ; ne fais pas tout d'un coup.
- 4. Garde le principe de source unique : design (Figma) et code doivent utiliser les mêmes noms ; s'ils divergent, le système meurt.
- 5. Versionne et communique : documente les changements et annonce-les ; un design system vit comme un produit.
Tu n'as besoin d'aucun outil spécial ; même de simples variables CSS et un dossier de composants bien nommé constituent un point de départ amplement suffisant pour une petite équipe.
Questions fréquentes
Un design system et une charte graphique, est-ce la même chose ?
Non. Une charte graphique est un document décrivant les règles de marque (logo, couleur, ton). Un design system inclut cela mais fournit en plus du code fonctionnel, des composants réutilisables et des tokens. La charte dit « voilà à quoi cela doit ressembler » ; le design system dit « voici une pièce prête, utilise-la ».
Un design system est-il superflu pour un projet solo ?
Une version légère en vaut presque toujours la peine. Même seul, figer les tokens de couleur et d'espacement t'aide à te souvenir de tes propres décisions plus tard et à rester cohérent. Tu n'as peut-être pas besoin d'une bibliothèque de composants complète, mais la couche de tokens est rentable à toute échelle.
Par quel outil commencer ?
Les simples propriétés personnalisées CSS suffisent pour les tokens. Pour documenter les composants, Storybook, et côté design les bibliothèques Figma, sont des choix courants. Les principes comptent plus que les outils : source unique, noms sémantiques et croissance progressive.
Tu veux une interface cohérente et évolutive ? Des couleurs de marque à une bibliothèque de composants fonctionnelle, je peux t'aider à mettre en place un design system. Contacte-moi et parlons de ton projet.