Chaque client qui nous parle de design system a en tête la même image : une bibliothèque de composants magiques, réutilisables partout, qui s'adaptent automatiquement au contexte. Web, mobile, email, PDF — un seul composant Button pour les gouverner tous.
Cette image est fausse. Et c'est précisément pour ça que la plupart des design systems finissent abandonnés deux ans après leur lancement.
Pourquoi l'idée séduit autant
La promesse est réelle : une source de vérité unique qui garantit la cohérence visuelle et réduit le travail répétitif. C'est un objectif légitime. Mais entre l'objectif et l'implémentation, il y a une confusion fondamentale : le design token n'est pas le composant.
Les tokens — couleurs, typographies, espacements, rayons de bordure — peuvent effectivement être universels. Un fichier de variables CSS et leurs équivalents en Kotlin, Swift ou Expo sont tout à fait partageables. C'est même une bonne pratique.
Le composant, lui, est indissociable de son contexte d'exécution. Un Button React avec ses pseudo-classes CSS n'est pas le même objet qu'un TouchableOpacity React Native avec son feedback haptique, lui-même différent d'un UIButton Swift avec son menu contextuel long-press.
Les trois patterns qui échouent systématiquement
1. Le composant "wrapper universel"
On encapsule tout dans une interface commune avec des props qui changent le comportement selon la plateforme. Ça commence proprement. Après 18 mois, le composant a 47 props, la moitié sont mutuellement exclusives selon la plateforme, et personne ne sait plus quelle combinaison est valide où.
2. La bibliothèque Storybook exhaustive
On documente chaque composant dans tous ses états possibles. C'est utile. Mais si la bibliothèque n'est pas maintenue en temps réel avec le produit, elle dérive. Six mois plus tard, Storybook montre une version des composants qui n'existe plus dans l'app réelle. La doc ment, et l'équipe arrête de l'utiliser.
3. Le design system comme projet séparé
Une équipe dédiée construit "le système" pendant que les équipes produit continuent à avancer. Résultat classique : le système arrive en retard sur les besoins, trop abstrait pour être utile immédiatement, et les équipes produit ont déjà implémenté leurs propres solutions ad hoc.
Un design system qui n'est pas extrait du produit réel, mais construit pour un produit hypothétique, sera toujours décalé par rapport aux besoins concrets.
Ce qui fonctionne : la séparation par couche
L'approche qu'on préconise distingue trois niveaux, sans essayer de les fusionner :
Ce qui est universel
- Design tokens (couleurs, typo, espacement)
- Logique métier et états
- Règles d'accessibilité
- Nomenclature et conventions de nommage
Ce qui est spécifique
- Implémentation des composants UI
- Gestion des interactions (hover, haptic, focus)
- Layout et responsive
- Animations et transitions
Concrètement : un fichier tokens.json partagé, transformé via Style Dictionary en variables CSS pour le web, en constantes Swift pour iOS, en fichier Kotlin pour Android. Les composants, eux, sont implémentés séparément sur chaque plateforme, mais ils partagent les mêmes tokens et les mêmes règles de comportement.
La règle des 80/20
Dans tous les projets que nous avons menés, environ 80% de la valeur d'un design system vient de 20% de son contenu :
- La palette de couleurs et ses variantes sémantiques (primary, danger, success, muted…)
- La typographie : les 4 ou 5 styles de texte que l'équipe utilise vraiment
- L'espacement : une grille cohérente (4px, 8px, 16px, 24px, 40px)
- Les composants de base : Button, Input, Card — pas les 200 variantes imaginées en atelier
Un design system avec 15 composants solides et maintenus est infiniment plus utile qu'une bibliothèque de 200 composants dont 170 sont en draft depuis 8 mois.
Quand commencer, et comment
La meilleure façon de démarrer un design system : ne pas le démarrer comme un projet. Extraire au fur et à mesure, à partir du produit réel. Le premier composant doit résoudre un problème concret, pas anticiper un besoin hypothétique.
Milestone 1 : tokens uniquement. Couleurs, typo, espacement dans un fichier partagé.
Milestone 2 : les 5 composants les plus utilisés dans le produit actuel.
Milestone 3 : documentation des patterns d'usage — pas des composants, des patterns.
Milestone 4 : gouvernance légère — une règle de contribution, pas un comité d'architecture.
À chaque étape, la question est la même : est-ce que ça résout un problème réel pour l'équipe aujourd'hui ? Si la réponse est non, on attend.
Vous construisez un produit multi-plateforme ?
On vous aide à définir l'architecture de votre design system dès le départ — sans sur-ingénierie.
Parler architecture