Pourquoi un design system
Un design system n'est pas un projet esthétique. C'est un investissement opérationnel qui produit trois bénéfices mesurables.
1. Réduction du temps de développement
Un développeur qui doit créer un formulaire n'a plus à réinventer les champs, les validations, les états d'erreur. Il assemble des composants existants. Sur nos projets, la mise en place d'un design system mature réduit typiquement le temps de développement d'une nouvelle page de 30 à 50 %.
2. Cohérence produit
Dans une application B2B mature, les utilisateurs voient des dizaines d'écrans. Sans design system, chaque écran dérive légèrement. Résultat : charge cognitive plus élevée, adoption plus lente.
3. Maintenabilité
Un changement de couleur, de typographie, d'espacement se fait en un seul endroit. Cela évite les migrations douloureuses tous les 2 ans.
Les composants d'un design system
1. Design tokens
Les valeurs fondamentales : couleurs, typographies, espacements, rayons, ombres. Stockés sous forme de variables (CSS, JS), réutilisables partout.
2. Composants
Les briques d'interface : boutons, champs, cartes, modales, tableaux. Chaque composant a :
Une anatomie claire (structure interne)
Des variantes (primaire, secondaire, ghost, danger…)
Des états (défaut, hover, focus, disabled, error)
Des règles responsive
Des règles d'accessibilité
3. Patterns
Compositions de composants pour des cas d'usage : formulaire, liste, dashboard, onboarding. Exemple : un formulaire de connexion n'est pas un composant, c'est un pattern.
4. Documentation
Chaque composant a sa fiche : nom, description, anatomie, variantes, états, exemples de code, règles d'usage.
5. Gouvernance
Qui peut ajouter un composant ? Qui valide une évolution ? Comment gérer les versions ?
Commencer : les 3 premiers mois
Ne pas chercher à tout construire d'un coup. Trois mois suffisent pour un design system minimal viable.
Mois 1 — Audit et fondations
Inventaire des composants existants dans l'application
Identification des duplications
Choix des design tokens (couleurs, typographie, espacements)
Création de la bibliothèque Figma de base
Mois 2 — Premiers composants
Sélection des 10-15 composants les plus utilisés
Design des composants avec toutes leurs variantes
Implémentation en code (React, Vue, ou autre)
Documentation initiale
Mois 3 — Première adoption
Migration d'une page pilote
Recueil des retours
Ajustements
Formation de l'équipe
Après ces 3 mois, le système est utilisable. Il faut ensuite l'enrichir progressivement.
Design tokens : la fondation
Les design tokens sont la base du design system. Mal conçus, ils rendent tout le reste difficile.
Structure à trois niveaux
Tokens primitifs — valeurs brutes : blue-500: #3B82F6, space-4: 16px
Tokens sémantiques — rôles : color-primary: var(--blue-500), spacing-md: var(--space-4)
Tokens de composants — spécifiques : button-primary-bg: var(--color-primary)
Pourquoi cette séparation
Elle permet de changer les valeurs primitives sans toucher aux composants. Si le bleu primaire change, tous les composants qui l'utilisent se mettent à jour automatiquement.
Format
Les tokens doivent être exportables en JSON, CSS variables, JavaScript, Swift, Kotlin. L'outil Tokens Studio ou un pipeline maison peuvent automatiser cette génération.
Documenter et outiller
Storybook
Storybook est l'outil de référence pour documenter les composants. Il permet de visualiser chaque composant, ses variantes, ses états, de tester les interactions.
Figma
La bibliothèque Figma doit refléter exactement le code. Variants, auto-layout, tokens. Les designers et développeurs travaillent sur la même base.
Documentation écrite
Pour chaque composant :
Quand l'utiliser (et quand ne pas l'utiliser)
Anatomie détaillée
Règles d'accessibilité
Exemples de code
Do / Don't
Automatisation
Un design system bien outillé génère automatiquement : la documentation HTML, les captures d'écran, les tests visuels.
Faire adopter le design system
Le plus dur n'est pas de construire un design system. C'est de le faire adopter.
Ce qui fonctionne
Montrer, ne pas imposer — démonstration des gains sur une page réelle
Impliquer les équipes — les développeurs qui utilisent le système doivent pouvoir proposer des améliorations
Former — sessions courtes, régulières
Faciliter — la documentation doit être accessible et à jour
Mesurer — partager les gains observés (temps de développement, bugs évités)
Ce qui ne fonctionne pas
Imposer par décret — sans démonstration de valeur, adoption artificielle
Figer — un design system qui n'évolue pas est abandonné
Négliger la gouvernance — sans règles, le système devient un chaos
Sous-investir dans la documentation — un composant non documenté n'est pas utilisé
Checklist design system
☐ Audit des composants existants
☐ Design tokens définis (couleurs, typo, espacements)
☐ Bibliothèque Figma alignée sur le code
☐ 10-15 composants prioritaires implémentés
☐ Documentation pour chaque composant
☐ Storybook déployé
☐ Tests visuels automatisés
☐ Processus de contribution défini
☐ Formation des équipes
☐ Page pilote migrée