Design system · Collaboration · 4 min · 1 octobre 2026
Un design system n’est pas un fichier Figma. C’est un contrat avec les développeurs.
Pourquoi la plupart des design systems meurent dans Figma, et les trois règles qui font qu’un système tient dans le code.
Un design system qui vit seulement dans Figma est une bibliothèque de dessins. Les développeurs la regardent, puis ils codent ce qu’ils peuvent. Six mois plus tard, le produit a trois boutons primaires et cinq nuances de gris, et le designer passe ses journées à faire la police.
Pendant cinq ans sur le SaaS de Gutenberg Technology, j’ai appris qu’un système tient à une seule condition : chaque décision de design a un équivalent dans le code, nommé pareil. Un token de couleur dans Figma est une variable CSS. Une variante de bouton est une prop. Si le nom diffère, la règle sera oubliée.
Première règle : les tokens d’abord. Couleurs, espacements, typographie, rayons, ombres. Avant tout composant. Ce sont eux qui rendent un changement global possible en une ligne.
Deuxième règle : les composants ont des états avant d’avoir des variantes. Repos, survol, focus, actif, désactivé, chargement, erreur. Un bouton sans état focus n’est pas un composant, c’est un rectangle.
Troisième règle : le système se documente là où les développeurs lisent. Pas dans une page Notion, dans le code : un Storybook, des commentaires, des exemples. Sur Mallettico, le design system vit directement dans le code : des jetons, des composants et leurs états, et aucune maquette à tenir à jour à côté. C’est l’ordre qui change tout.