Qu'est-ce qu'un bon design system ?

Introduction

Un bon design system, c'est d'abord des décisions

Repartons de l'usage. Quand vous ouvrez un design system qui tient debout, vous ne tombez pas seulement sur une réserve de composants. Vous tombez d'abord sur une identité : pour quel projet et quelle cible, porté par quel ton. Viennent ensuite les décisions, celles qu'une équipe répète sans même y penser : pourquoi le bouton primaire est bleu et pas rouge, pourquoi tel composant existe et quel problème il règle. Et, ce qu'on oublie presque toujours, les interdits qui vont avec, comme par exemple l'interdiction d'utiliser la couleur d'accent ailleurs que sur l'action principale de l'écran.

Au fond, un design system ne stocke pas des pixels. Il stocke des décisions qu'on peut justifier et réemployer. Le composant, c'est la partie visible ; ce qui le fait tenir, c'est le raisonnement derrière.

Regardez Spotify. Son design system, Encore, lancé en 2019, a d'abord enflé côté mobile comme un catalogue de composants qui n'arrêtait plus de grandir. Le piège classique. En 2022, l'équipe a reconnu que le curseur était parti trop loin du côté de la flexibilité, et elle est revenue à un socle de décisions partagées pour tenir la cohérence d'un écran à l'autre. Si le vert de Spotify se reconnaît entre mille, c'est moins une affaire de couleur que de décisions tenues dans la durée.

Le design token : la plus petite décision nommée

Descendons jusqu'à la plus petite brique du système : le design token. Le terme a été forgé par Jina Anne chez Salesforce, autour de 2014, sur le Lightning Design System. L'idée a fait son chemin, puis s'est standardisée : le Design Tokens Community Group du W3C en maintient aujourd'hui un format neutre, indépendant des plateformes, stabilisé fin 2025.

La nuance a l'air technique, elle est en réalité philosophique. Plutôt que d'écrire #0055FF un peu partout, on donne un nom à la décision. Un token, ce n'est pas une valeur, c'est une intention rendue réutilisable. Et il vit sur deux étages qu'on aurait tort de mélanger.

• La primitive garde la valeur brute, sans contexte : blue-600, un bleu et rien de plus.
• Le sémantique porte le rôle, color.action.primary, et pointe vers la primitive.

Quand la primitive vous dit quelle est la valeur, le sémantique vous dit à quoi elle sert. Cette séparation n'a rien d'un caprice de puriste. C'est elle qui rend les thèmes possibles : pour passer en thème sombre, vous ne repeignez pas écran par écran, vous redéfinissez la couche sémantique une seule fois et tout suit. D'où une règle qu'on retient : les composants doivent se réfèrer aux tokens sémantiques, jamais directement aux primitives.

L'erreur qui tue un système : la valeur en dur

Reste l'erreur qui défait tout ça, et elle est terriblement banale : écrire une valeur en dur. Un #0055FF posé à la main, un 16px glissé au jugé. Ça paraît insignifiant, sauf que ça coupe le lien entre le pixel et la décision. Le jour où la marque change de bleu, cette valeur ne bougera pas d'un poil : elle est devenue orpheline, coincée dans son coin.

Autre erreur fréquente : pointer un composant directement sur une primitive, blue-600 au lieu de color.action.primary. On a bien nommé, on se croit tiré d'affaire, et on a sauté l'étape de l'intention. Le composant est bleu sans plus savoir pourquoi il l'est.

Mis bout à bout, ces petits écarts portent un nom : le design drift. C'est la dérive silencieuse entre ce que le système prescrit et ce qui part vraiment en production. Elle ne prévient pas, elle s'installe : une maquette figée qui ne reflète plus l'app, ou une interface reconstruite à la main plutôt que branchée sur les composants partagés. Il suffit ensuite d'une exception « juste pour cette fois » qui finit par se multiplier. Et un matin, on recompte quarante-sept gris presque identiques dans le même produit sans se souvenir de les avoir choisis.

Alors, comment enrayer ça ? En s'attaquant à la source : une seule source de vérité, des composants qui tapent dans le sémantique, un rythme d'audit qu'on tient vraiment.

Un système qui ne se lit pas ne sert à rien

Un système peut cocher toutes ces cases et rester lettre morte s'il ne se lit pas. Un token que personne ne comprend ne décide plus rien, il devient une énigme de plus dans le fichier. D'où le travail le moins glamour et le plus utile : documenter le pourquoi. Pour chaque famille, écrire ce qu'elle résout, dans quels cas on l'emploie et dans quels cas on l'évite. La valeur exacte ne suffira jamais ; ce qu'il faut faire passer, c'est l'intention.

Sauf qu'un deuxième lecteur vient de s'asseoir à la table, et il ne lit pas comme nous. L'agent qui génère vos écrans réclame exactement les mêmes décisions, mais dans une forme qu'il puisse suivre sans deviner. Un bon système, désormais, doit se laisser lire des deux côtés : par le designer qui l'édite et par la machine qui l'exécute.

C'est tout le pari du format DESIGN.md, né dans Google Stitch et ouvert en open source par Google Labs au printemps 2026, sous licence Apache 2.0. Un seul fichier, coupé en deux :

• En haut, les tokens en YAML : couleurs, typographies, espacements, arrondis, des valeurs qu'une IA lit sans avoir à interpréter.
• En dessous, de la prose en Markdown, de l'aperçu de marque jusqu'à une section « Do's and Don'ts ». C'est là, dans la prose, que descend l'interdit qu'un simple fichier de tokens ne portera jamais.

Et ce n'est pas qu'une jolie mise en forme. Un lint intégré vérifie les contrastes WCAG et repère les références cassées, ce qui fait basculer l'accessibilité du côté des vérifications automatiques plutôt que des bonnes intentions. Au bout du compte, une seule source, versionnée comme du code, que vous et l'agent consultez au même endroit.

Il faut l'admettre, cette manière de travailler a de quoi refroidir. On s'épanouit rarement dans un bloc de YAML austère quand on a l'habitude d'un fichier vivant, plein de couleurs et de cadres bien posés. Mais cette sobriété est justement ce qui fait tenir la promesse. Une charte graphique superbe va être ouverte une fois et admirée, puis elle sera glissée dans un dossier partagé où elle prendra la poussière. Un DESIGN.md, l'équipe y revient à chaque écran. Pour un designer, c'est l'assurance que ses décisions seront lues et respectées, plutôt que contournées faute d'avoir été rouvertes.