Qu'est-ce qu'un design token ?

La plus petite décision de design stockée sous forme de données — une valeur nommée comme brand-600 ou space-4 que les outils de design et le code lisent tous les deux. Les tokens transforment « notre bleu » d'une conversation en une référence qui se résout de façon identique partout.

Qu'est-ce que le format DTCG ?

Le format JSON du W3C Design Tokens Community Group — une manière neutre vis-à-vis des outils d'écrire les tokens ($value, $type, références) pour qu'un seul fichier puisse alimenter Figma, CSS et n'importe quel pipeline de build. Il est devenu le format d'échange sur lequel convergent les outils de tokens modernes.

Les design tokens sont-ils la même chose que les variables CSS ?

Non — les tokens sont la source, les propriétés personnalisées CSS n'en sont qu'un export. Le même fichier de tokens peut aussi devenir un thème Tailwind, des Figma Variables ou du code natif. Écrire les valeurs directement en CSS saute la couche qui maintient le design et le code synchronisés.

Que sont les tokens sémantiques ?

Des noms de rôle — background, text-primary, accent — qui pointent vers des valeurs primitives comme brand-600. Les composants consomment les rôles, si bien qu'un changement de marque ou de thème redirige les rôles sans toucher au moindre composant.

Comment les tokens arrivent-ils dans Figma ?

Sous forme de Figma Variables — des collections de valeurs nommées avec des modes clair et sombre. Générées à partir de la même source que les exports de code, elles permettent aux designers de lier remplissages et espacements aux mêmes noms que ceux référencés par les développeurs.

Les tokens doivent-ils vivre dans git ?

Oui. Un fichier de tokens est du code source pour les décisions de design : relisible en pull requests, comparable d'une version à l'autre et réversible — la traçabilité qu'un guide de style au format PDF n'a jamais.

Design tokens : le guide pratique

Les design tokens sont des décisions de design stockées sous forme de données — des valeurs nommées pour la couleur, la typographie, l’espacement et le rayon, qui vivent dans un seul fichier et s’exportent vers chaque outil qui en a besoin : CSS, Tailwind, Figma, code natif. Ils sont la couche qui garde un système de design honnête : quand les fichiers de design et les feuilles de style lisent la même source, ils ne peuvent pas diverger. Ce hub rassemble nos guides sur le format, le nommage et le workflow ; la version en un écran, c’est une source de tokens rendue en quatre exports.

L’idée en un seul geste

Un token remplace une valeur par une référence. Au lieu que #2563eb apparaisse dans quarante feuilles de style et trente remplissages Figma, brand-600 apparaît partout et se résout vers la valeur à un seul endroit exactement. Le gain intuitif, c’est qu’un nom porte une intention là où une valeur ne le peut pas : #2563eb ne dit rien du moment où l’utiliser, brand-600 si — et un changement fait derrière un nom se fait une fois, se relit une fois, et est digne de confiance partout où le nom apparaît. Chaque question difficile du travail sur les tokens — nommage, découpage en couches, gestion des thèmes, migration — est une variation autour de ce geste unique passé à l’échelle, et les guides ci-dessous les prennent tour à tour. Ce que sont les design tokens est l’introduction de base ; design tokens vs variables CSS démêle la distinction que la terminologie brouille — les propriétés personnalisées ne sont qu’un export d’un fichier de tokens, pas la chose elle-même.

Le format qui l’a emporté

Le format DTCG — le JSON du groupe communautaire du W3C — est ce qui se rapproche le plus d’un standard pour les tokens : $value et $type par token, des références entre tokens, des types composites pour la typographie et les ombres. Nos guides couvrent sa lecture, son écriture et la discipline de l’aller-retour qui permet à un fichier de tokens d’être édité par des outils sans perdre ce que les humains y ont ajouté : le format DTCG expliqué parcourt un vrai fichier ligne par ligne, importer des tokens existants couvre l’aller-retour lui-même, et Style Dictionary vs export direct pèse le moment où un pipeline de transformation mérite sa place plutôt que d’écrire les exports directement.

Nommage et couches — là où les systèmes de tokens tiennent ou s’effondrent

La plupart des systèmes de tokens échouent socialement avant d’échouer techniquement : des noms que personne ne peut prédire, des couches que personne ne respecte. La décision porteuse est le découpage en couches primitive, sémantique et composant — les primitives portent les valeurs (brand-600), les sémantiques portent les rôles (text-primary), les composants consomment les rôles — parce que c’est cette indirection qui permet à un changement de marque ou de thème de rediriger les rôles sans toucher au moindre composant. Les conventions de nommage rendent les couches lisibles, et cinq anti-patterns des tokens catalogue les façons dont elles s’érodent en pratique. À partir de là, les guides de workflow prennent le relais : une source de vérité unique décrit la boucle de bout en bout, relire les changements de tokens dans git rend les décisions de design comparables comme n’importe quel autre code, et comment les développeurs consomment réellement les tokens est le test de réalité vu du côté qui reçoit. Pour les organisations qui gardent encore un guide de style au format PDF, design tokens vs guide de style expose ce que chacun peut faire que l’autre ne peut pas.

Là où les tokens rencontrent le reste du système

Les tokens portent les valeurs que d’autres systèmes décident : les mathématiques d’échelle des échelles typographiques et de l’espacement, les rôles dérivés des échelles de couleur, les paires de thème du mode sombre. La couche des tokens est l’endroit où tout cela devient livrable — c’est pourquoi ce hub se lit mieux après les autres et est référencé par chacun d’eux. C’est aussi la couche qu’écrit Scale Composer : chaque décision d’échelle prise là — couleur, typographie, espacement, grille — atterrit dans un seul fichier DTCG, prêt pour les exports que décrit ce hub.

Les guides de ce hub

Cinq anti-modèles de tokens
Les bonnes pratiques des design tokens enseignées par l'échec : cinq anti-modèles — prolifération, saut de couche, échappatoires, noms d'apparence et fichiers en écriture seule.
Comment les développeurs consomment vraiment les tokens
La transmission des design tokens vue depuis le poste du développeur : propriétés personnalisées CSS, thèmes Tailwind, Figma Variables — et pourquoi le fichier de tokens doit être traité comme une API.
Conventions de nommage des design tokens
Conventions de nommage des design tokens : l'anatomie catégorie-concept-variante-état, cinq règles qui survivent aux refontes de marque, et les micro-décisions à trancher une seule fois.
Design tokens vs guide de style
Design tokens vs guide de style : le guide porte l'intention et l'usage pour les humains, les tokens portent les valeurs pour les machines — et comment les deux se composent sans dérive.
Design tokens vs variables CSS : quelle différence ?
Design tokens vs variables CSS : les tokens sont la source neutre par rapport aux outils, les propriétés personnalisées un export généré. Comment ils se relient et quand les variables suffisent.
Importer vos tokens existants sans rien perdre
Comment importer des design tokens sans perdre le travail fait main : le contrat d'aller-retour, un test de point fixe en cinq minutes, et ce qu'il faut auditer avant de faire confiance à un outil.
Le format de tokens DTCG expliqué
Le format DTCG expliqué : $value et $type sur chaque token, groupes, références et types composites — ainsi que ce que contient réellement un fichier de design tokens généré.
Primitive, sémantique, composant : les trois couches de tokens
Les design tokens sémantiques se situent entre les primitives et les composants. Comment l'architecture à trois couches transforme les changements de marque, les thèmes et les exceptions en modifications d'une seule couche.
Que sont les design tokens ?
Que sont les design tokens ? Des décisions de design nommées — brand-600 contient un bleu précis — composées par références et exportées vers CSS, Figma et le code natif.
Revoir les changements de tokens dans Git
Gestion de versions des design tokens : pourquoi les changements de tokens ont leur place dans git, comment lire un diff de tokens de six lignes et la checklist de revue qui repère les changements de design silencieux.
Style Dictionary vs export direct
Style Dictionary vs export direct : ce qu'apporte un pipeline de transformation de tokens, quand les exports intégrés vous suffisent, et comment un fichier DTCG standard garde les deux voies ouvertes.
Une source unique de vérité : le workflow des tokens
Design tokens source unique de vérité : le workflow en cinq étapes — décider, exporter, commiter, consommer, changer — et la panne que chaque étape sautée laisse revenir.

Ressentez la source unique

L’argument en faveur des tokens se compresse en une seule interaction : changez un paramètre d’échelle et regardez chaque export se mettre à jour — DTCG, propriétés personnalisées CSS, thème Tailwind et Figma Variables qui bougent ensemble, parce que les quatre sont lus à partir des mêmes décisions. C’est cette simultanéité qu’achète une couche de tokens ; tout le reste n’est que mise en œuvre.