Des styles de couleur Figma aux vrais tokens

Les styles de couleur et les variables de Figma résolvent des problèmes différents. Un style est une peinture nommée — une définition de remplissage qui peut contenir une couleur unie, un dégradé ou une image. Une variable est une valeur nommée dotée de modes : une même variable peut contenir une valeur claire et une valeur sombre, et changer le mode d’un cadre bascule tous les remplissages qui lui sont liés. Transformer une palette Figma en vrais tokens, c’est déplacer ses couleurs unies dans des variables, superposées en une collection primitive (les échelons bruts de la rampe) et une collection sémantique (des rôles comme text/primary qui les référencent) — la même structure à deux couches que les design tokens ont dans le code.

L’écart entre ces deux fonctionnalités, c’est là que bien des configurations « notre design system vit dans Figma » calent en silence : un mur de styles de couleur bien nommés, incapables d’exprimer le mode sombre et que le code ne peut qu’imiter à la main. Cet article couvre la distinction, la configuration en couches, et le flux de travail qui va de la rampe générée au remplissage lié ; les rampes elles-mêmes font l’objet de notre guide des échelles de couleur.

Quelle est la différence entre les styles de couleur et les variables ?

Les styles sont la fonctionnalité la plus ancienne : des peintures nommées que vous appliquez aux remplissages et aux contours. Ils restent le seul foyer des dégradés et des remplissages d’image, et pour les équipes qui n’ont besoin que d’un nommage cohérent, ils font l’affaire. Ce qu’un style ne peut pas faire, c’est contenir plus d’une valeur — un style nommé background est une seule peinture, pour toujours, quel que soit le thème.

Les variables sont des valeurs nommées organisées en collections, et chaque collection peut définir des modes — des ensembles parallèles de valeurs pour les mêmes noms. Les variables peuvent aussi se référencer entre elles (alias), et elles se lient aux remplissages, aux contours et aux effets.

Pour la couleur, les modes sont la fonctionnalité décisive. Définissez une variable background avec une valeur claire et une valeur sombre, liez-la au remplissage d’un cadre, et le thème sombre cesse d’être un fichier parallèle à maintenir : sélectionnez le cadre, changez son mode, et tous les remplissages liés basculent d’un coup. Un thème sombre fondé sur des styles est au contraire un second jeu de styles appliqué à la main — une refonte qu’il faut refaire pour chaque écran.

Comment faut-il superposer les variables de couleur ?

En deux collections qui reflètent les couches de tokens dans le code.

La collection primitive contient la matière brute : les échelons de la rampe. De brand/50 à brand/900, de même pour l’échelle des neutres et les couleurs fonctionnelles — des noms qui décrivent ce qu’une couleur est. Les primitives n’ont généralement pas besoin de modes ; un échelon de rampe a la même valeur dans n’importe quel thème.

La collection sémantique contient les rôles : background, surface, text/primary, border/default, fill/brand — des noms qui décrivent à quoi une couleur sert. Chaque variable sémantique est un alias vers la collection primitive, et c’est la couche qui porte les modes : en mode clair, background référence un échelon quasi blanc, en mode sombre un échelon quasi noir. Le nom du rôle reste en place tandis que sa valeur voyage.

Le bénéfice de cette indirection est le même que celui que les tokens procurent dans le code : les designers travaillent avec un vocabulaire de rôles, la rampe peut être régénérée sans rien renommer, et le mode sombre est un simple redirigeage des alias plutôt que de nouvelles décisions écran par écran.

À quoi ressemble le flux de travail de bout en bout ?

D’abord la génération, ensuite la liaison.

Les rampes proviennent d’une seule couleur de départ. Donnez à Scale Composer une couleur de marque — #2563eb, soit oklch(0.546 0.215 262.9) — et il génère la rampe à dix échelons, l’échelle des neutres teintés et les couleurs fonctionnelles nativement en OKLCH, puis dérive les rôles sémantiques par surface avec vérification des planchers de contraste WCAG et report de l’APCA en parallèle. L’export Figma Variables emporte cette structure — primitives, alias sémantiques, valeurs hex à l’appui — de sorte que les collections décrites plus haut arrivent déjà construites plutôt qu’assemblées à la main.

Ouvrez l’export Figma Variables de la palette dans Scale Composer — les échelons de la rampe en collection primitive, les rôles en alias par-dessus, prêts à importer.

À partir de là, le contrat du designer est court : liez les variables sémantiques aux remplissages, jamais les échelons bruts — l’arrière-plan de la carte est surface/tint, pas brand/50, même s’ils se résolvent aujourd’hui vers la même valeur. Les échelons bruts servent à construire les rôles, pas à toucher les écrans.

Le mode sombre arrive ensuite sous forme de données. Scale Composer dérive la palette sombre au lieu de refléter la palette claire — sa propre courbe de luminosité, avec un chroma rehaussé d’environ 20 %, parce qu’un environnement sombre atténue la coloration perçue — et ces valeurs deviennent le second mode de la collection sémantique. Aucun écran n’est redessiné ; les cadres se re-résolvent.

Qu’apporte réellement la discipline de liaison ?

Voici la même carte promotionnelle construite deux fois. À l’écran aujourd’hui, les deux sont identiques au pixel près :

Notez que la version codée en dur ne contient aucune erreur — chaque hex est la valeur actuelle correcte. La différence n’apparaît que lorsque la palette change, c’est-à-dire précisément quand on a le moins de temps pour la corriger.

Lors d’un changement de marque, la couleur de départ change et les primitives se re-dérivent : la carte liée se met à jour partout où elle est instanciée, tandis que la carte codée en dur exige de retrouver cinq valeurs et de les ressaisir — multiplié par chaque écran qui l’a copiée. Au moment du mode sombre, la carte liée bascule avec le mode du cadre ; la carte codée en dur ne réagit pas du tout, alors quelqu’un fabrique un duplicata card-dark, et à partir de ce jour les deux dérivent indépendamment. La colonne liée coûte un peu de discipline à chaque remplissage ; la colonne codée en dur coûte une migration à chaque changement.

Que ne peuvent pas faire les variables pour vous ?

Deux limites honnêtes. D’abord, les variables de couleur contiennent des valeurs unies : les dégradés et les remplissages d’image vivent toujours dans les styles, si bien qu’un vrai fichier fait cohabiter les deux fonctionnalités — les variables pour les couleurs en forme de tokens, les styles pour le reste, plus pictural.

Ensuite, la discipline de liaison est humaine. Figma n’empêche personne de saisir un hex dans un remplissage, et un hex saisi court-circuite silencieusement toute la chaîne — il correspondra parfaitement jusqu’au premier changement de marque ou de mode, puis ressurgira comme une carte périmée dans une interface mise à jour. Aucune configuration d’outil ne remplace l’habitude d’équipe de se demander, à chaque remplissage, quel rôle est-ce ? La mise en couches rend le bon choix bon marché ; elle ne peut pas rendre le mauvais impossible.

La mécanique des modes est plus facile à croire une fois qu’on a vu les valeurs voyager. Exportez la même palette avec les modes clair et sombre côte à côte — les rôles sémantiques conservent leurs noms tandis que les deux jeux de valeurs reposent en dessous, les sombres re-dérivées plutôt qu’inversées.