Design Tokens : comment les vrais systèmes de design restent cohérents

Un code hexadécimal est une valeur. Un token est une décision avec un nom. Les systèmes de design sont faits de décisions, pas de valeurs.

Cette distinction, c'est tout le sujet. Codez #0EA5E9 en dur dans quatorze composants Figma, recevez une demande de mode sombre, et vous voilà face à une semaine de recherche-remplacement. Nommez-le color-interactive-primary et vous changez une valeur pendant que chaque surface se met à jour. Ce n'est pas de la magie, juste des décisions nommées.

Ce qu'est vraiment un design token

Un design token est une variable nommée qui stocke une décision de design. Il peut contenir une couleur, une valeur d'espacement, une taille de police, un rayon de bordure, une ombre, une durée. Le nom est le contrat. La valeur derrière le nom peut changer sans casser quoi que ce soit qui l'utilise.

L'approche classique sans tokens commence quand un designer choisit #1D4ED8 pour les boutons principaux, le code en dur dans le composant bouton, puis copie ce code hexadécimal dans la carte, le badge et le lien. Six mois plus tard, la marque évolue. Vous avez maintenant un problème de maintenance qui grossit avec chaque composant livré.

Les tokens renversent ça. Vous nommez la décision (color-action-default), assignez la valeur une seule fois, et tout ce qui référence le token reste synchronisé. La valeur est un détail d'implémentation. Le nom est le système.

Les trois niveaux qui font fonctionner les tokens

Les tokens bruts ne sont que des variables. Ce qui rend un système de tokens vraiment utile, c'est la hiérarchie. Chaque système de production qui mérite d'être étudié utilise trois niveaux.

Les primitifs sont votre palette. Chaque bleu, chaque pas d'espacement et chaque rayon vit ici comme une valeur nommée sans opinion sur l'endroit où elle est utilisée. Vous ne consommez pas les primitifs directement dans les composants.

Les tokens sémantiques mappent des rôles aux primitifs. Le token color-surface-default peut pointer vers un quasi-blanc en mode clair et un quasi-noir en mode sombre, et le composant ne sait jamais quelle valeur brute il reçoit. Il connaît uniquement le rôle.

Les tokens de composant sont les plus spécifiques. Ils existent quand un composant a besoin d'une décision intentionnellement différente du défaut sémantique. Un bouton de danger pointe son arrière-plan vers un rôle de retour critique plutôt que vers le rôle interactif par défaut. La plupart des composants n'ont pas besoin de leurs propres tokens ; ils consomment directement les tokens sémantiques.

Pourquoi les tokens battent les valeurs codées en dur

La vitesse de changement est l'argument évident, mais ce n'est pas le vrai. Le vrai argument, c'est la précision.

Quand un designer livre un fichier plein de codes hexadécimaux bruts, le développeur ne sait pas lesquels sont intentionnels et lesquels sont accidentels. Est-ce que #1A1A2E est l'arrière-plan, ou quelqu'un a-t-il pris la mauvaise couleur en pipette ? Les tokens suppriment l'ambiguïté. Un nom de token sémantique est une documentation qui voyage avec la valeur.

Les tokens sont aussi le contrat de handoff entre les outils de design et le code en 2026. Les variables Figma se mappent directement aux propriétés personnalisées CSS. Un token défini dans un fichier Figma peut être exporté, commité et consommé dans le code sans une seule étape manuelle. L'écart entre design et implémentation s'effondre quand les deux côtés parlent les mêmes noms de tokens.

Pour les équipes qui font du travail d'accessibilité, les tokens ajoutent une couche de sécurité supplémentaire. Vous auditez la palette sémantique en un seul endroit et garantissez que color-text-default atteint toujours un contraste de 4,5:1 par rapport à color-surface-default, quel que soit le thème actif.

Comment les vrais systèmes de design structurent leurs tokens

Trois systèmes méritent d'être connus : Shopify Polaris, IBM Carbon et GitHub Primer. Ils abordent le modèle à trois niveaux différemment, et les différences sont instructives.

Shopify Polaris conserve les primitifs dans une échelle de couleurs (color-sky-100 à color-sky-900) et les alise vers des rôles sémantiques comme --p-color-bg-fill-active. Les tokens de composant sont rares, donc la plupart des composants consomment des tokens sémantiques. La convention est rôle-puis-état, ce qui se lit naturellement dans le code, puisque vous savez à quoi sert bg-fill-disabled sans contexte supplémentaire.

Voir en direct sur polaris.shopify.com

IBM Carbon va loin dans les couches sémantiques. Son ensemble de couleurs inclut des tokens de retour explicites comme support-error et support-success, des tokens d'état interactif, et des tokens de couche pour les surfaces imbriquées (un composant sur un panneau sur une page a chacun besoin d'une valeur de surface différente). C'est plus complexe, mais IBM livre des logiciels d'entreprise où chaque état imbriqué compte.

Voir en direct sur carbondesignsystem.com

GitHub Primer expose sa couche primitive comme "primitives" et sa couche sémantique comme "functional tokens", documentés publiquement sur primer.style. Le theming de Primer permet à GitHub de livrer les thèmes clair, sombre, clair à fort contraste et sombre atténué depuis un seul ensemble de composants. Chaque thème est une assignation de valeur différente aux mêmes noms de tokens.

Le schéma est cohérent dans les trois cas : primitifs comme échelle, tokens sémantiques comme noms de rôles, et theming comme échange de valeur au niveau sémantique. Les composants restent intacts.

---

Brainy aide les designers à construire des systèmes qui passent à l'échelle, pas des écrans ponctuels. Découvrez ce que nous construisons pour les créateurs sur /creators.

---

Nommer les tokens sans perdre la tête

Le nommage des tokens divise les équipes. Trop générique et les noms ne portent aucune information. Trop spécifique et vous écrivez un nouveau token pour chaque composant.

Une convention de nommage qui fonctionne nomme quatre parties : catégorie, rôle, variante et état. Vous ne les utiliserez pas toutes à chaque fois, mais la structure empêche le chaos ad hoc.

Exemples concrets, écrits comme les propriétés CSS personnalisées qu'un développeur consomme réellement :

• color-surface-default définit l'arrière-plan de page par défaut
• color-text-subtle est le texte secondaire à contraste réduit
• color-interactive-primary-hover est l'état hover d'une action principale
• spacing-component-md est le rembourrage interne moyen pour les composants
• radius-interactive est le rayon de coin pour les éléments cliquables

Deux règles évitent la plupart des disputes. Ne jamais encoder la valeur brute dans le nom, car color-blue-500 ne dit rien sur le rôle. Ne jamais nommer par composant au niveau sémantique, car button-primary-color dans le niveau sémantique signifie que vous avez sauté le niveau sémantique.

Pour les systèmes typographiques qui passent à l'échelle, la même convention s'applique, et font-size-body-lg bat text-18px à chaque fois.

Un seul ensemble de tokens, modes clair et sombre

Le mode sombre est là où les systèmes de tokens portent leurs fruits le plus visiblement. Si vous avez nommé vos tokens par rôle, le mode sombre est un échange de valeur, pas une refonte.

Voir en direct sur primer.style

Le mécanisme est simple. Votre token sémantique color-surface-default pointe vers un primitif quasi-blanc en mode clair et quasi-noir en mode sombre. Le composant qui le consomme ne change jamais. Vous changez de thème en échangeant le mappage de valeur au niveau sémantique.

Les propriétés personnalisées CSS rendent cela mécanique :

:root { --color-surface-default: #ffffff; --color-text-primary: #111827; } [data-theme="dark"] { --color-surface-default: #0f172a; --color-text-primary: #f8fafc; }

Chaque composant référençant var(--color-surface-default) répond maintenant à l'attribut de thème sans aucun code supplémentaire. Shopify Polaris, GitHub Primer et IBM Carbon utilisent tous ce schéma à l'échelle de la production.

Le mode d'échec consiste à mélanger tokens sémantiques et primitifs dans les composants. Quand un composant référence directement color-blue-600 au lieu de color-interactive-primary, ce composant cesse de répondre au theming. Une seule référence primitive négligente brise tout le modèle. Les règles de lint qui signalent la consommation directe de primitifs dans le code de composant valent le temps de configuration.

Comprendre comment les choix de couleurs fonctionnent vous donne le fondement conceptuel, et les tokens vous donnent la structure pour agir dessus à travers chaque thème.

Quand les design tokens sont surdimensionnés

Les tokens ajoutent de l'indirection. L'indirection a des coûts. Soyez honnête sur le moment où ces coûts valent la peine d'être payés.

Les petites équipes avancent plus vite sans tokens. Une startup de trois personnes en quête d'adéquation produit-marché n'a pas besoin d'une hiérarchie à trois niveaux. Quand vous changez de direction visuelle toutes les deux semaines, une seule bibliothèque de styles Figma suffit.

L'antipattern à éviter est le nommage sémantique prématuré. Les tokens nommés color-blue et color-gray ajoutent de l'indirection sans signification. Soit vous nommez par rôle avec color-surface et color-text, soit vous restez avec des primitifs jusqu'à avoir assez de composants pour savoir quels sont réellement les rôles.

Un mauvais nommage de tokens est pire que pas de tokens du tout. Un token nommé button-color-for-the-checkout-page dans la couche sémantique est un piège de maintenance. La discipline de nommage n'est pas optionnelle, c'est la raison pour laquelle les tokens fonctionnent.

FAQ

Les design tokens remplacent-ils les styles Figma ?

Non, mais ils les étendent. Les variables Figma, sorties en 2023, sont l'équivalent natif le plus proche dans Figma, et elles se mappent aux tokens de code quand vous partagez les conventions de nommage entre les deux. Les styles Figma gèrent la typographie et les remplissages de couleur, tandis que les variables gèrent la hiérarchie complète des tokens, y compris les états et les décisions au niveau des composants.

Les tokens fonctionnent-ils sans système de design ?

Les tokens sont plus utiles dans un système de design, mais même un produit unique bénéficie du nommage sémantique au niveau des propriétés personnalisées CSS. Vous n'avez pas besoin d'un système formel pour arrêter de coder les valeurs hexadécimales en dur.

Quel outil utiliser pour gérer les tokens ?

Pour les petites équipes, les variables Figma plus un export JSON suffisent. Pour les équipes plus grandes, Style Dictionary (open source, par Amazon) est l'outil de build standard. Il prend une structure JSON de tokens et génère des propriétés personnalisées CSS, des constantes iOS Swift et du XML Android. Tokens Studio pour Figma est le plugin bridge populaire entre Figma et Style Dictionary.

Quel degré de granularité pour les tokens de composant ?

Seulement le niveau de granularité dont vous avez besoin. La plupart des composants peuvent consommer directement les tokens sémantiques. Les tokens spécifiques au composant ont du sens quand un composant s'écarte intentionnellement de la couche sémantique, comme un bouton d'action destructive ou une bannière avec une surface inhabituelle. En cas de doute, consommez les tokens sémantiques et créez des tokens de composant uniquement quand vous vous retrouvez à écrire des exceptions.

Les tokens peuvent-ils gérer l'espacement et la typographie, ou seulement les couleurs ?

Les tokens fonctionnent pour tout ce qui a une valeur discrète : couleur, espacement, typographie, rayon de bordure, ombre, durée de mouvement, easing de mouvement et z-index. Les systèmes les plus matures, comme IBM Carbon et l'Atlassian Design System, ont des tokens pour tout cela. Commencez avec les couleurs et les espacements, puis ajoutez les autres au fur et à mesure que le système mûrit.

Arrêtez de coder les valeurs en dur

Le chemin pratique n'est pas compliqué :

• Nommez vos primitifs comme une échelle
• Mappez ces primitifs à des rôles sémantiques
• Faites consommer à chaque composant des tokens sémantiques, jamais des primitifs
• Exportez les valeurs de tokens depuis une seule source (variables Figma, un fichier JSON ou un package de système de design) et laissez les outils de build les distribuer vers CSS, iOS et Android

Vous n'avez pas besoin d'une migration de trois mois pour commencer. Prenez un composant, nommez ses décisions, et ressentez la différence quand vous changez une valeur une seule fois et regardez tout se mettre à jour. Cette expérience est l'argument.

Pour plus d'écrits sur les systèmes de design, découvrez ce que Brainy couvre sur /paper.