Un fichier Figma impeccable. Des dizaines de composants soigneusement nommés et documentés. Pourtant, chaque dev a refait son propre bouton. Comment un système aussi soigné peut-il finir aussi peu suivi ?
14 Juillet 20268 min de lecture
La brique de base
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 #166169 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 :
teal-700, 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.
La lisibilité
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.