Design system · bibliothèque React
2020-2025 · 6 min de lecture
Un seul système, autant d'identités que de clients
Création du design system et de la bibliothèque de composants de tout l'écosystème SKALES : ~200 composants, de Figma jusqu'au code, capables d'afficher l'identité visuelle de chaque client sans toucher un seul composant.
- Design system
- Theming
- Accessibilité
- Développement React
- Client
- SKALES : plateforme, add-ons, apps clientes, outils low-code
- Rôle
- Initiateur et responsable du design system, co-développeur de la bibliothèque React
- Durée
- Design system fin 2020, bibliothèque dès 2021
- Ce qui a changé
- Des composants réécrits par chaque application devenus un socle unique, thématisable par client
Le problème
Chaque application SKALES recodait ses propres boutons, formulaires et tableaux, avec leurs petites différences et leurs bugs. Le même bouton existait en plusieurs versions, et chaque correction devait être répliquée partout, quand elle l'était.
Le symptôme le plus parlant concernait les états. Des boutons censés être désactivés ne l'affichaient pas : ni grisés, ni masqués, ils invitaient à cliquer sur une action impossible. Rien de grave pour la sécurité, mais une source constante de confusion et de tickets.
La solution
Un design system dont tout part de décisions élémentaires nommées : les design tokens. Les composants ne contiennent aucune valeur en dur : changer de thème revient à changer les tokens, jamais les composants. C'est ce qui a rendu possible l'affichage de l'identité de chaque client, et des thèmes adaptés aux troubles visuels.
Un design system est un produit à part entière, avec ses propres utilisateurs. Pour ceux qui construisent, développeurs et designer, la promesse était la vitesse et la fiabilité. Pour ceux qui en bénéficient, utilisateurs finaux et clients, la cohérence et l'appropriation.
Démarche
Traiter le design system comme un produit : deux publics, deux promesses, et une gouvernance qui tient dans la durée.
- Audit des composants existants
- Benchmark de fondations techniques
- Design tokens
- Figma + Storybook
- Développement React
- Contrastes WCAG
Choisir la fondation en raisonnant en coût de production
Nous avons retenu Material UI après l'avoir comparé à ses deux vrais concurrents sur le rendu visuel obtenu et le coût de production réel. Trois développeurs pour environ 200 composants : chaque heure d'implémentation comptait.
L'argument décisif était la thématisation : Material UI permet de changer tout le thème à l'exécution. C'était exactement ce qu'il fallait pour afficher l'identité de chaque client et proposer des thèmes adaptés aux troubles visuels. Son principal défaut, un style très reconnaissable, se corrigeait justement par nos propres tokens. Chakra UI a aussi été testé, puis écarté : son écosystème était encore restreint à l'époque.
Option Atout Limite pour notre cas HTML/CSS natif Liberté visuelle totale Tout à reconstruire : états, accessibilité, navigation clavier. Coût intenable à trois Bootstrap Connu de tous, rapide à démarrer Rendu daté et reconnaissable, thématisation profonde laborieuse Material UIOption retenue Thématisation dynamique, accessibilité intégrée, composants riches (tableaux, sélecteurs de date) Look « Material » à neutraliser, surcharges de style parfois verbeuses Des tokens avant les composants
Tout part de décisions élémentaires nommées : couleurs, typographie, espacements, rayons, états. Les composants ne contiennent aucune valeur en dur, donc changer de thème ne touche jamais un composant.
La palette d'origine posait un vrai problème d'accessibilité : le vert de la marque n'a qu'un contraste de 1,89:1 avec du texte blanc, loin des 4,5:1 requis. Plutôt que de le retirer, je lui ai donné un rôle où il fonctionne (accent sur fond sombre, à 7,98:1) et confié les actions principales au bleu pétrole, à 8,08:1. L'identité est préservée, les contrastes sont conformes.
Côté typographie, les clients choisissaient leur police parmi les Google Fonts : le système fixait donc l'échelle et les graisses, pas la famille. Inter par défaut pour l'interface, pour sa lisibilité en petite taille et ses chiffres tabulaires dans les tableaux, et Manrope pour les titres.
Répartition des rôles de couleur
- Action principale : Bleu 700, texte blanc (8,08:1)
- Accent et mise en avant : Vert 400, texte Neutre 900 (7,98:1)
- Texte principal : Neutre 900 sur Neutre 100 (13,30:1)
- Erreur : 5,62:1 · Avertissement : 4,67:1, tous vérifiés selon les WCAG
FondationsVoir en grand ↗
Palette complète en dix paliers, rôles de couleur avec leur ratio de contraste, échelle typographique et grille d'espacement de 4 px. ThemingVoir en grand ↗
Le même écran sous plusieurs thèmes client, et les variantes pensées pour le daltonisme, obtenues en changeant les tokens, jamais les composants. Des états définis une fois pour toutes
Chaque composant interactif spécifie les mêmes états : par défaut, survol, focus, actif, désactivé, chargement, erreur. Le bug des boutons désactivés ne pouvait plus se reproduire, puisque l'état n'était plus redéfini application par application.
Le même raisonnement s'applique à la validation des saisies : quand annoncer une erreur, comment la formuler, et ce que l'utilisateur doit pouvoir faire ensuite. Ces règles vivent dans le système, pas dans la tête de chaque développeur.
Button et InputVoir en grand ↗
Les variantes et les sept états spécifiés pour les deux composants les plus utilisés du système, avec leurs cotes et leurs tokens. Validation des saisiesVoir en grand ↗
Quand une erreur apparaît, comment elle est formulée, et ce que l'utilisateur peut faire ensuite : tout est spécifié au niveau du système. Faire vivre le système, et le développer moi-même
Un design system ne vaut que s'il reste la source de vérité. J'ai conçu sa documentation pour qu'un composant Figma et son équivalent codé soient strictement identiques : Storybook côté code, et pour chaque composant une fiche détaillée avec cotes, typographies, couleurs et variantes d'états. Tout nouveau besoin client suivait le même chemin, sans raccourci : prototype, validation, intégration Figma + Storybook, mise en production.
Participer moi-même au développement React, aux côtés de deux développeurs, a été déterminant. Je concevais en connaissant le coût de chaque choix, et la fidélité entre maquette et produit ne dépendait pas d'une traduction approximative. Quelques développeurs trouvaient au début le processus plus long ; la stabilité obtenue les a rapidement convaincus.
La gouvernance en quatre temps
- Nouveau besoin client identifié
- Prototype et validation
- Intégration simultanée dans Figma et Storybook
- Mise en production sur les applications
Ce que j'en retiens
“Poser une référence avant de changer. Les gains étaient évidents pour l'équipe, mais difficiles à chiffrer : le coût des tickets liés à l'interface n'avait jamais été suivi avant le projet. Aujourd'hui, je mettrais en place dès le lancement quelques indicateurs simples (tickets d'interface, temps de livraison d'un écran, taux de réutilisation) pour pouvoir démontrer la valeur du système, et pas seulement la constater.”
Résultats
- ≈ 200
- Composants du système
- La totalité
- Produits SKALES couverts
- ×2 à ×2,5
- Vitesse sur les applications complexes
- ≈ ½ journée / semaine
- Temps récupéré par développeur
Au lancement, le gain sur la production d'un écran n'était que d'environ 5 %, insuffisant pour rentabiliser l'effort de construction. Une fois le système et la bibliothèque arrivés à maturité, nous produisions des applications complexes 2 à 2,5 fois plus vite que nos concurrents, un constat partagé par plusieurs clients.