Guide : construire et maintenir 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.

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 ?

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.

Les design tokens sont la base du design system. Mal conçus, ils rendent tout le reste difficile.

Structure à trois niveaux

1. Tokens primitifs — valeurs brutes : blue-500: #3B82F6, space-4: 16px
2. Tokens sémantiques — rôles : color-primary: var(--blue-500), spacing-md: var(--space-4)
3. 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.

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.

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é

• ☐ 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