Les design systems, sans le marketing
Le terme « design system » a été usé par deux ans de posts LinkedIn. Remettons donc la définition à plat.
Un design system est la source de vérité unique, exécutable et versionnée de l'apparence et du comportement de votre produit. « Exécutable » parce que les designers travaillent à partir des mêmes composants que ceux livrés par les développeurs. « Versionnée » parce que le système évolue dans le temps et que les anciennes versions doivent continuer à fonctionner. « Source de vérité unique » parce que s'il subsiste une ambiguïté, le système ne remplit pas son rôle.
Un fichier Figma avec quelques boutons dedans n'est pas un design system. Un Storybook avec 40 composants et aucun design token n'est pas un design system non plus. Le système, c'est le pont entre les deux.
Ce qui change quand on en a un
Trois choses, de façon mesurable :
La vitesse de développement des nouvelles fonctionnalités. Sur les projets où nous introduisons un vrai design system en cours de mission, la livraison de fonctionnalités s'accélère de 30 à 50 % en deux sprints. Les designers arrêtent de réinventer les patterns de formulaires. Les développeurs arrêtent de réimplémenter des boutons. Les PR raccourcissent.
La cohérence entre les surfaces. Les entreprises multi-produits sont le cas le plus évident, mais même les équipes mono-produit en profitent. Le site vitrine, l'application, le tableau de bord admin, les templates d'e-mails — s'ils partagent les mêmes tokens, ils ont l'air de venir de la même entreprise. Sans tokens partagés, ils divergent toujours.
Le coût d'onboarding. Un nouveau designer ou développeur peut livrer sa première PR dès sa première semaine, au lieu de son premier mois. Le système répond à la plupart des questions du type « comment fait-on X » avant même qu'on les pose.
Ce qu'il y a à l'intérieur
Un design system opérationnel comporte à peu près quatre couches. Sautez-en une et le système devient fragile.
1. Les tokens. Couleurs, typographie, espacements, rayons, ombres, durées d'animation, courbes d'accélération. Ce sont des données JSON, pas des images. Elles alimentent à la fois Figma (via des outils comme Tokens Studio) et le code (via Style Dictionary ou équivalent). La couche des tokens est la plus importante et la plus souvent négligée.
2. Les primitives. Boutons, champs de saisie, listes déroulantes, cases à cocher, boutons radio, interrupteurs, badges, infobulles, modales. Les éléments d'interface atomiques présents sur chaque écran. Ils doivent être implémentés une seule fois, avec une accessibilité correcte (anneaux de focus, ARIA, navigation au clavier), et documentés avec des tableaux de props.
3. Les patterns. Formulaires, navigation, états vides, états de chargement, états d'erreur, tableaux de données. Ce sont des compositions de primitives. Ils encodent des partis pris : « voici comment on gère un formulaire en plusieurs étapes », et non « voici une librairie de formulaires ».
4. Les guidelines. Voix et ton, standards d'accessibilité, règles de contenu (« on utilise la casse phrase dans les boutons »), principes d'animation. Les parties hors composants qui maintiennent la cohérence du travail.
Un mode d'échec courant : livrer le système, puis l'abandonner
La moitié des design systems que l'on voit dans les codebases clients ont été construits il y a deux ans, utilisés pendant six mois, puis discrètement contournés. Symptômes : un Storybook que plus personne ne met à jour, des composants dans le code qui font de l'ombre à ceux du design system, des valeurs hexadécimales de couleur codées en dur à 30 endroits différents.
Cela arrive généralement quand le système est traité comme un livrable ponctuel plutôt que comme un produit vivant. La solution est structurelle :
- Désignez un responsable. Même à temps partiel. Sans responsable, personne ne décide quand un nouveau composant est promu dans le système.
- Rendez le système plus simple à utiliser qu'à contourner. Si ajouter un nouveau composant au système prend plus de temps que de copier-coller, vous avez perdu.
- Effectuez un audit trimestriel. Parcourez chaque écran, comptez les écarts, corrigez-les. Nous utilisons une métrique simple : « pourcentage d'écrans n'utilisant que des composants du système ». Tout ce qui est en dessous de 80 % est un problème.
Commencer petit (et ne pas s'arrêter)
Inutile d'avoir une librairie de 200 composants pour parler de design system. Un v1 fonctionnel tient dans une seule librairie Figma et un seul package npm, et contient à peu près :
- 8 tokens de couleur
- 4 échelles typographiques
- Une échelle d'espacement (4 / 8 / 12 / 16 / 24 / 32 / 48)
- 6 composants : bouton, champ de saisie, liste déroulante, modale, carte, tableau
- 3 patterns : mise en page de formulaire, en-tête de page, état vide
C'est un vrai design system. Livrez-le vendredi, utilisez-le lundi, développez-le sur l'année suivante.
Quand vous n'en avez pas besoin
Une équipe de deux personnes construisant un produit unique pendant six mois ira plus vite sans la charge d'un système formel. Le point de bascule se situe à peu près à : trois designers/développeurs ou plus, plusieurs surfaces, ou un produit destiné à vivre plus de 18 mois. En dessous de ce seuil, contentez-vous de noter les conventions et avancez.
Au-delà, la question n'est plus « devons-nous construire un design system ? » — c'est « combien avons-nous déjà payé pour ne pas en avoir un ? ». Si vous voulez un second avis sur où en est le système de votre équipe, notre équipe UI/UX design réalise un audit léger comme point de départ.
