Design System : ce text-red-500 qui vous arrangerait bien…

5 conseils pour traduire votre Design System en composants graphiques, sachant que cette étape vient après la conception…

Publié le 23 juillet 2025

craft

Nous nous intéressons aujourd'hui à l'implémentation d'un Design System, j'entends par là sa traduction en composants utilisables au sein d'interfaces graphiques.

Naturellement, un rappel s'impose : qu'est-ce, au juste, qu'un Design System ?

La grammaire de l'expérience utilisateur

Un Design System est "un ensemble de blocs de construction et de normes qui aident à préserver la cohérence visuelle des produits et des expériences" (définition : Figma). Cela va du ton employé, reflet des valeurs et de la personnalité de la marque, à la définition du moindre espacement.

Dit autrement, c'est un guide de styles qui introduit un systématisme, une grammaire visuelle dont l'utilisateur n'a pas nécessairement conscience, mais qui amoindrit très effectivement l'apprentissage nécessaire lorsqu'il aborde un nouveau produit. L'interaction étant facilitée, l'utilisateur et l'organisation atteignent plus certainement leurs objectifs.

Concevoir un Design System est un investissement important pour toute organisation, mais un investissement qui porte rapidement ses fruits :

Il diminue le nombre de décisions à prendre en phase de conception, permettant aux designers d'accéder à des considérations de plus haut niveau ;
Son implémentation au travers d'une bibliothèque de composants permet des gains de productivité importants en phase de développement ;
Il assure le respect de l'état de l'art en matière de compatibilité mobile et d'accessibilité, pour peu que ces considérations aient été prises en compte lors de la création du Design System.

Atlassian propose une excellente documentation de son Design System . Sa structuration ("Brand", "Foundations", "Tokens", "Components"…) reflète bien le chemin de pensée et la logique de construction pyramidale issue de l'Atomic Design.

Un Design System repose entre autres sur la notion de design token : un jeton est une valeur nommée désignant une couleur, un espacement, une typographie, etc. Par exemple :

color.background.danger

correspond à une nuance bien précise de rouge. En général, on restreint au maximum le nombre de tokens pour une même dimension (ici, la couleur) : 36 nuances d'une même couleur, c'est l'infini, cela va à l'encontre de l'idée-même de Design System.

5 recommandations pour traduire un Design System en composants graphiques

Au risque d'enfoncer des portes ouvertes, rappelons la nécessité de constituer une bibliothèque de composants (React, Vue, Angular, Web Components, ce que vous voulez), importée par tous les actifs informatiques de votre organisation. De la sorte, si changement il doit y avoir, il n'a lieu qu'en un seul endroit ; ce changement peut concerner la valeur d'un token ou bien le framework CSS lui-même. Le corollaire, c'est que vous ne voulez pas la moindre classe CSS en dehors du Design System, pas le moindre
```
text-red-500
```
(Tailwind CSS, à titre d'exemple) qui, pourtant, vous arrangerait bien. Facile à dire, compliqué à mettre en œuvre.
Ce
```
text-red-500
```
qui, pourtant, vous arrangerait bien, il ne s'agit pas de le rajouter tel quel au Design System : il faut lui donner du sens. Créer un composant
```
RedText
```
serait absurde, parce que ce serait nommer la chose d'après sa forme et non sa fonction. Peut-être l'utilisation de la couleur rouge signale-t-elle un danger (composant
```
Danger
```
?), à moins que le rouge ne soit la couleur primaire de votre Design System, auquel cas ça n'a rien à voir. En bref : pas de place pour la contingence, tout a du sens, tout doit être pensé (ces réflexions devraient occasionner quelques échanges entre développeurs et designers…)
Vient ensuite la question de savoir comment invoquer les tokens. La réponse dépend en partie de l'outil sur lequel vous reposez : un framework tel que Tailwind CSS permet la définition d'un thème (par exemple la couleur
```
background_danger
```
), et de faire directement appel aux classes CSS générées à partir de ce thème (
```
bg-background_danger
```
). Mais vous pourriez souhaiter introduire une couche d'abstraction supplémentaire et définir pour cela une fonction
```
token
```
invoquée comme suit :
```
token('color.background.danger')
```
, cette fonction n'étant rien d'autre qu'un gros
```
switch
```
.
Signalons également le pattern Compound Component, qui se révèle très utile pour créer des composants de haut niveau tel que le
```
PageLayout
```
de cette capture d'écran (à gauche, le Design System, à droite son utilisation dans un produit). Un composant composé expose plusieurs sous-composants, qui peuvent être utilisés ensemble de manière déclarative, tout en partageant une logique ou un état commun géré par le composant parent (à l'aide de l'API
```
Context
```
, en React). Parfois, comme c'est le cas ici, ce pattern est utilisé seulement pour apporter de la structure, sans aucune logique d'interaction.
Finissons enfin par les recommandations d'usage : testez dûment vos composants (utilisez pour cela des tests de composants plutôt que des tests end-to-end), proposez une belle documentation (Storybook peut vous y aider), assurez un versionning propre (rétro-compatibilité, changelog, release notes) et mettez votre Design System à disposition des développeurs au travers d'un monorepo ou bien d'un package NPM interne.

Conclusion

Un bon Design System, c'est ce qui fait que votre UI est "tirée au cordeau". Alors, si je n'avais qu'un conseil à vous donner, ce serait celui-ci : ne mettez pas la charrue avant les bœufs. Dans la mise en place d'un Design System, le développement intervient tout à la fin. Consacrez peut-être 90% du temps à la conception du Design System et 10% à son implémentation.