Cookies necessaires
Toujours actifs. Ils assurent le fonctionnement technique du site et la memorisation de votre choix de consentement.
Vous connaissez cette situation ?
Une équipe passe des semaines à préparer un beau Design System sur Figma. Couleurs, boutons, espacements, composants, variantes... C’est propre, bien rangé, presque parfait.
Puis les développeurs s’y mettent.
Et quelques mois plus tard, on retrouve trois boutons différents, des couleurs écrites en dur dans le CSS et des composants qui se ressemblent... mais ne fonctionnent pas pareil.
Le plus drôle ? Tout le monde utilise officiellement le même Design System. 😅
Après des années sur des projets Front-End, j’en ai retenu une chose : un Design System peut être parfait dans Figma et devenir un vrai casse-tête dans le code.
Alors, qu’est-ce qui coince ?
Les maquettes sont jolies, les variantes sont définies. Puis arrive le développement, et les questions fusent :
Le travail de design n’est pas forcément mauvais. On a juste oublié de poser les bonnes questions au bon moment.
Un composant, ce n’est pas seulement ce qu’on voit. C’est aussi ce qu’il fait.
Les développeurs Front-End doivent donc participer dès le début. Pas juste pour dire « c’est faisable », mais pour anticiper les vrais usages. Découvrir tous les problèmes en plein développement, ce n’est jamais une bonne affaire.
Le Design System prévoit un bouton principal. Très bien. Mais dans l’appli, un développeur crée sa classe CSS, un autre son composant Angular, et un troisième récupère un vieux bouton d’un autre projet « parce que ça fera l’affaire ».
Résultat : trois boutons qui se ressemblent, trois codes différents. Et le jour où il faut corriger un souci d’accessibilité, il faut tous les retrouver. Bonjour la maintenance !
Personne n’a forcément mal travaillé. Le composant officiel était peut-être introuvable, trop compliqué, ou personne ne savait qu’il existait.
Si chaque développeur doit recréer un composant, ce n’est plus vraiment un système.
La solution n’est pas de demander plus d’attention, mais de fournir une vraie bibliothèque partagée : API claire, variantes définies, règles d’usage, et assez de souplesse pour les besoins réels. Le but, c’est de gagner du temps, pas d’en perdre.
Dans Figma, une couleur principale. Dans le CSS, cette même couleur copiée dans plusieurs fichiers, avec parfois de petites variations. Un bleu ici, un autre là. 16 px d’espacement sur une page, 15 sur une autre.
Personne ne remarque rien au début. Puis l’interface perd peu à peu sa cohérence.
C’est là qu’interviennent les Design Tokens : au lieu de recopier les valeurs partout, on les centralise.
:root {
--color-primary: #2563eb;
--spacing-md: 16px;
--radius-md: 8px;
}
.button {
background: var(--color-primary);
padding: var(--spacing-md);
border-radius: var(--radius-md);
}Quand une couleur change, plus besoin de chasser dans cinquante fichiers.
Petite précision : des variables CSS ne font pas, à elles seules, un système de tokens. Il faut aussi une convention de nommage, une méthode de synchronisation avec Figma et des responsabilités claires.
Le Design System doit parler le même langage dans Figma et dans le code. Sinon, chacun travaille avec sa propre version de la vérité.
Un bouton, ce n’est pas juste un rectangle avec du texte. Selon son rôle, il peut avoir :
Pas besoin de tous les états pour chaque bouton, mais il faut les avoir envisagés. Et ce n’est que le début : responsive, textes longs, contrastes, accessibilité... Même histoire pour les champs de formulaire, les menus, les modales.
Si ces comportements ne sont pas prévus, chaque développeur invente sa solution. Et une fois le composant utilisé dans vingt pages, le corriger devient beaucoup moins amusant.
Un bon composant doit fonctionner dans la vraie vie, pas seulement sur une maquette.
On voit à quoi ressemble le composant, mais pas comment l’utiliser. Quelle variante choisir ? Quelles propriétés ? Comment gérer une erreur ? Et si le comportement voulu n’existe pas ?
Quand les réponses sont dures à trouver, les développeurs improvisent. Et à force d’improviser, le système part dans tous les sens.
Storybook aide beaucoup : composants, variantes et états visibles directement avec leur code. Mais l’outil ne fait pas tout. Je préfère une documentation courte qui répond aux vraies questions plutôt que cinquante pages que personne ne lit.
Une bonne documentation doit aider à bosser, pas donner du travail en plus.
Une fois les composants livrés, le travail n’est pas fini. Les produits évoluent, il faut une variante ici, une correction d’accessibilité là. Mais qui décide ? Qui valide ? Qui vérifie que ça ne casse pas les applications existantes ?
Sans règles, on tombe dans l’un de ces deux cas : un système tellement verrouillé que personne n’ose y toucher, ou un système que tout le monde modifie dans son coin.
La solution tient en quelques points simples :
Pas besoin de trois réunions pour changer un arrondi de bordure. Mais pas question non plus de modifier un composant utilisé partout sans vérifier les conséquences.
Un Design System doit pouvoir évoluer sans devenir un chantier permanent.
C’est le signal le plus révélateur. Le Design System existe, la doc aussi, mais les équipes continuent à bricoler leurs propres solutions.
Pourquoi ? Composant trop rigide, variante manquante, ou adaptation tellement lourde qu’il est plus rapide de repartir de zéro. Et quand les délais sont serrés, on prend le chemin le plus simple.
On peut le reprocher aux développeurs. Mais posons-nous plutôt la question :
Et si le problème venait du Design System lui-même ?
Un outil censé faire gagner du temps ne devrait pas en faire perdre. D’où l’importance d’écouter les retours : quels composants posent problème, quelles adaptations reviennent sans cesse, qu’est-ce qui manque ? Pas seulement lors de réunions où tout le monde confirme que tout va bien. 🙂
Pas de recette magique, mais quelques habitudes qui changent beaucoup :
Pour mesurer, quelques indicateurs simples suffisent : nombre de composants dupliqués, fréquence des exceptions CSS, taux d’utilisation de la bibliothèque partagée, problèmes récurrents remontés par les équipes. Attention, ce ne sont pas des objectifs à atteindre à tout prix. Ils servent à vérifier que le système facilite vraiment le développement.
C’est l’un de ses rôles clés. Pas seulement écrire du CSS propre ou créer des composants Angular, mais prendre du recul : repérer ce qui peut être réutilisé, anticiper les problèmes, structurer les composants et aider chacun à travailler avec les mêmes règles.
Et surtout, faire le lien. Le designer pense cohérence, le développeur pense fonctionnement et maintenance, le responsable produit pense besoins et délais. Tout ce petit monde doit avancer ensemble.
Le Lead Front-End ne décide pas de tout. Il facilite les échanges, fait remonter les problèmes et évite que les mêmes erreurs se répètent d’un projet à l’autre.
On passe parfois des semaines à construire un Design System parfait, puis on considère que c’est terminé. En réalité, c’est souvent là que les choses sérieuses commencent.
Un Design System doit vivre avec les applications, évoluer avec les besoins, et rester assez simple et utile pour que les équipes aient envie de s’en servir.
Un Design System n’est pas réussi parce qu’il est beau dans Figma, ni parce qu’il contient plein de composants. Il est réussi quand ces composants sont réellement utilisés, compris et maintenus par les équipes.
Et vous, dans vos projets, votre Design System vous fait gagner du temps ou il vous donne parfois du travail en plus ?
#DesignSystem #FrontEnd #DeveloppementWeb