Que sont les design tokens ?

Les design tokens sont des décisions de design stockées sous forme de données nommées. Chaque token associe un nom à une valeur — brand-600 contient un bleu précis, space-4 un espacement précis — et les tokens vivent dans un fichier neutre vis-à-vis des outils, à partir duquel chaque format cible est généré : CSS pour le web, variables pour Figma, ressources pour le code natif.

Cette définition condense trois idées, et chacune porte une part du poids : un token est une décision dotée d’un nom, les tokens se composent par références, et le système composé s’exporte vers chaque cible. Cet article — le premier volet de notre guide des design tokens — construit la définition une étape à la fois.

Que signifie « une décision de design dotée d’un nom » ?

Chaque produit accumule des décisions de design : le bleu de la marque est tel hex, le corps de texte fait 16px, les cartes reçoivent tel padding. Ce qui varie, c’est l’endroit où ces décisions vivent. Dans beaucoup d’équipes, elles vivent dans la mémoire de quelqu’un, dans un jeu de diapositives ou dans un guide de style en PDF — des endroits qu’une personne peut lire mais que rien ne peut exécuter. Un token déplace la décision dans les données :

"brand-600": { "$value": "#2563eb", "$type": "color" }

Le nom est la poignée de la décision ; la valeur est sa réponse actuelle. Une fois qu’une décision devient une donnée, les outils peuvent faire ce que les outils font : la valider, comparer deux de ses versions, en générer du code, retrouver chaque endroit où elle est utilisée. Un PDF qui indique « bleu principal, à utiliser pour les boutons » a besoin d’un interprète humain ; un fichier de tokens énonce la même décision sous une forme sur laquelle une étape de build peut agir.

Comment les tokens deviennent-ils un système ?

Par les références. La valeur d’un token peut être le nom d’un autre token, et ce seul mécanisme transforme une liste plate de constantes en décisions composées. La convention courante est en couches : les tokens sémantiques nomment des rôles et pointent vers des tokens primitifs qui nomment des valeurs —

"background": { "$value": "{neutral.50}",  "$type": "color" },
"accent":     { "$value": "{brand.600}",   "$type": "color" }

background → neutral-50 et accent → brand-600 sont des décisions à part entière, distinctes de ce que neutral-50 et brand-600 stockent réellement. « L’accent est la couleur de marque » et « la couleur de marque est ce bleu » peuvent désormais changer indépendamment : un changement de marque modifie la seconde affirmation, un thème repointe la première, et ni l’un ni l’autre ne touche aux composants qui consomment accent.

Comment les tokens parviennent-ils au code et aux outils de design ?

Par l’export. Le fichier de tokens lui-même est délibérément neutre — du JSON qui n’appartient à aucun outil en particulier — et chaque cible en reçoit une vue générée : des propriétés personnalisées pour les feuilles de style, un bloc de thème pour Tailwind, des Figma Variables pour le fichier de design, des ressources clé-valeur pour les plateformes natives. Une seule source, plusieurs rendus, les mêmes noms partout.

Scale Composer fonctionne ainsi de bout en bout : il dérive la typographie, l’espacement et les rampes de couleur, plus les rôles sémantiques des thèmes clair et sombre, à partir d’une seule échelle partagée, et tout ce qu’il dérive ressort sous forme d’un unique fichier de tokens DTCG, accompagné des propriétés personnalisées CSS, d’un bloc @theme Tailwind v4 et de Figma Variables, le hex porté à côté des valeurs OKLCH. Ouvrez un système de tokens généré dans Scale Composer — les sections du fichier d’un côté, et les mêmes noms rendus en exports CSS, Tailwind et Figma à côté.

À quoi ressemble le même bouton avec et sans tokens ?

D’abord la version « guide de style », telle qu’un PDF la formulerait :

Les boutons principaux utilisent le bleu de la marque (#2563EB) comme arrière-plan, avec du texte blanc.

Ensuite la version « tokens » :

{
  "color":    { "brand": { "600": { "$value": "#2563eb", "$type": "color" } } },
  "semantic": { "accent": { "$value": "{color.brand.600}", "$type": "color" } },
  "button":   { "background": { "$value": "{semantic.accent}", "$type": "color" } }
}

Le contenu est le même, mais la version en tokens porte une trace. Demandez quel est l’arrière-plan du bouton et le fichier répond par sauts : button.background → semantic.accent → brand-600 → #2563eb, soit oklch(0.546 0.215 262.9). Chaque saut est une décision qui peut changer sans perturber les autres — repointez accent pour un thème, changez ce que stocke brand-600 pour un changement de marque, détachez button.background de accent le jour où le bouton a réellement besoin de cesser de le suivre. La phrase du PDF renferme une seule décision fusionnée ; la trace en renferme trois séparables.

D’où vient le terme ?

Deux phrases d’histoire : Salesforce a forgé le terme « design tokens » vers 2014, quand son design system devait desservir le web et les plateformes natives à partir d’un seul jeu de décisions, et a construit un outillage qui traduisait un unique fichier de tokens dans le format de chaque plateforme. Le terme a dépassé son origine — aujourd’hui, le Design Tokens Community Group (designtokens.org) maintient un format d’échange partagé sur lequel les outils de design et les pipelines de build ont largement convergé.

Pourquoi l’industrie a-t-elle convergé vers les design tokens ?

À cause de la dérive : les fichiers de design et le code livré divergent sur des valeurs censées être identiques. La dérive n’a pas de solution par le process — demander aux designers et aux développeurs de tenir deux listes synchronisées traite un problème structurel comme un problème de discipline, et les listes divergent à nouveau à la prochaine échéance. La version intuitive est presque arithmétique : deux copies de quoi que ce soit, tenues par des mains différentes, s’écartent ; plus il y a de copies, plus vite elles dérivent. Les tokens changent la forme du problème de sorte qu’il ne reste rien à synchroniser — une copie est la source, et les N−1 autres en sont des vues générées. Le fichier de design et la feuille de style s’accordent parce que ni l’un ni l’autre n’est tenu à la main ; les deux sont lus à partir des mêmes décisions.

Que ne sont pas les design tokens ?

Pas seulement des variables. Les variables sont le mécanisme de stockage ; les tokens sont des variables plus la discipline — noms fondés sur les rôles, couches, références — qui rend les décisions stockées navigables. Un --blue peut contenir tout ce que son auteur a tapé ; un système de tokens est structuré pour qu’un lecteur puisse dire à quoi sert une valeur et ce qui en dépend.

Pas seulement pour les grandes équipes. Ce sont les organisations multiplateformes qui ont nommé le problème en premier, mais un designer seul qui refond la marque d’un petit site affronte la même dérive à plus petite échelle : les mêmes valeurs dupliquées entre un fichier de design et une feuille de style, divergeant en silence.

Pas une fonctionnalité de Figma. Les Figma Variables sont une cible parmi d’autres des tokens — un endroit où atterrit une vue générée — et non l’endroit où les tokens sont définis. Considérer une cible unique comme la source remet les décisions à l’intérieur d’un seul outil, ce qui est précisément la situation à laquelle les tokens existent pour mettre fin.

Suivez une décision de bout en bout

Une définition se fixe une fois qu’on a soi-même suivi une véritable chaîne de sauts. Ouvrez les rôles sémantiques dans Scale Composer et suivez un token — choisissez accent, descendez jusqu’à l’étape primitive qu’il référence et à la valeur qui y est stockée, puis changez la couleur de départ et observez la décision au-dessus rester stable pendant que la réponse en dessous change.