Design tokens 2026 : pipeline Figma → code sans friction

Depuis dix ans, le scénario se répète dans la plupart des équipes produit. Les designers maintiennent un fichier Figma soigneusement structuré : palettes, typographies, espacements, états de composants. Les développeurs maintiennent, en parallèle, un fichier tailwind.config.js ou un ensemble de variables CSS. Les deux fichiers se ressemblent. Les deux fichiers dérivent.

Le symptôme est connu. Le bleu primary dans Figma (#2563EB) n'est pas le --color-blue-500 dans Tailwind (#3B82F6). L'écart semble anodin en réunion, mais il s'accumule : à chaque nouvelle feature, un designer maquette avec la version Figma, un développeur implémente avec la version code, et personne ne remarque que les deux écrans ne sont pas identiques. Au bout de six mois, le design system est devenu une suggestion.

Les conséquences sont concrètes : temps de revue de design qui explose, allers-retours Slack pour valider chaque couleur, dette visuelle qui s'installe, et surtout, perte de confiance entre les deux équipes. Les designers finissent par redouter la mise en production. Les développeurs finissent par ignorer le fichier Figma. C'est le syndrome classique du design system mort-né.

La cause racine n'est pas un manque de discipline. C'est l'absence d'une source de vérité unique et d'un pipeline automatisé. En 2026, avec la maturité de Figma Variables, l'émergence du format W3C Design Tokens, et l'intégration CSS-native de Tailwind v4, ce pipeline est enfin atteignable. Ce dossier décrit comment le construire.

Figma a généralisé les Variables en 2024, et c'est le changement qui rend le pipeline moderne possible. Pour la première fois, Figma dispose de vraies variables typées : couleur, nombre, chaîne, booléen. On est loin des simples styles qui ne portaient qu'une valeur visuelle.

Le modèle est solide. Les Variables s'organisent en Collections (par exemple Primitives, Sémantique, Composants), chaque collection expose des Modes (light, dark, density-compact, density-comfortable), et les variables supportent les aliases. Une variable sémantique --color-bg-primary peut référencer --color-neutral-0 en mode light et --color-neutral-950 en mode dark. Le mode devient un switch de référence, pas une duplication.

Cette structure reflète exactement la hiérarchie attendue côté code : tokens bruts (palette, échelle de spacing, durées), tokens sémantiques (couleurs de fond, de bordure, d'accent par contexte), tokens de composants (variante primaire du bouton). Les deux arborescences, Figma et code, peuvent enfin être isomorphes, ce qui est la condition sine qua non d'une synchronisation automatique.

Sur nos projets récents, nous partons toujours d'un fichier Figma structuré en trois collections distinctes. Les designers travaillent uniquement sur les sémantiques et les composants ; les primitives ne sont modifiées qu'en début de cycle de marque. Cette discipline simplifie la revue de design et prépare le terrain pour l'export automatique.

Tokens Studio (anciennement Figma Tokens) est le plugin qui fait le pont entre Figma Variables et le code. Il synchronise les variables Figma vers un repo GitHub au format JSON, et ouvre une pull request automatique à chaque changement. C'est le maillon qui transforme une décision de design en un diff de code reviewable.

Le format d'export est aligné sur le W3C Design Tokens Format Module, le standard émergent porté par la communauté (Adobe, Amazon, Microsoft, Token Studio, Knapsack). Le brouillon spécifie la structure attendue : $type, $value, descriptions, extensions, groupes, alias. Adopter ce format n'est pas un choix cosmétique, c'est s'aligner sur le vocabulaire qui sera repris par tous les outils du secteur dans les prochaines années.

Concrètement, un token couleur ressemble à { "$type": "color", "$value": "#2563EB" }. Un alias devient { "$value": "{color.blue.600}" }. Les modes (light, dark) sont sérialisés en collections distinctes. Ce JSON est lisible, diffable, versionnable : exactement ce qu'il faut pour une revue de code saine.

Le grand avantage de Tokens Studio est la sync bidirectionnelle. Un développeur qui corrige un token directement dans le JSON (par exemple pour aligner un contraste WCAG) voit la correction remonter vers Figma. Plus de divergence silencieuse. La PR devient le lieu unique de discussion design-dev, avec captures d'écran, commentaires, et historique.

Style Dictionary, maintenu par Amazon, est le moteur de transformation. Il prend un dossier de tokens JSON en entrée et génère autant de sorties que nécessaire : variables CSS, constantes TypeScript, enums Swift, ressources Kotlin, XML Android, SCSS, LESS. C'est l'outil qui rend le pipeline multi-plateforme réaliste.

Le principe est simple et robuste. On déclare des transformateurs (changer un nom kebab-case en camelCase, convertir un hex en RGB, générer une variante opaque), des formats de sortie (un template CSS qui produit :root { --color-bg-primary: #fff; }), et des destinations (apps/web/styles/globals.css, apps/mobile/src/theme/tokens.ts, apps/docs/storybook/tokens.json). Une seule commande (style-dictionary build) régénère tout à partir du JSON source.

Sur un projet multi-plateforme typique, la source vit dans un repo dédié design-tokens. Les applications consommatrices (web, mobile, docs) ne commitent jamais de tokens manuellement : ils sont régénérés par CI à chaque merge. C'est l'application stricte du principe one source of truth, N outputs. Toute incohérence entre plateformes devient structurellement impossible.

La force de Style Dictionary est sa capacité de personnalisation. Pour Tailwind v4, nous écrivons un format personnalisé qui produit directement un bloc @theme. Pour Storybook, un format JSON adapté à l'addon Design Tokens. Pour les tests, un format TypeScript typé qui expose { color: { bg: { primary: "var(--color-bg-primary)" } } }, pratique pour les assertions dans les tests composants.

Le workflow productionnisé ressemble à ceci. Un designer modifie une variable dans Figma. Tokens Studio pousse le JSON mis à jour vers le repo design-tokens sur la branche feat/update-primary-blue. Une GitHub Action se déclenche, exécute style-dictionary build, puis ouvre des PR vers les repos consommateurs : apps/web (CSS), apps/mobile (TS), docs/storybook (JSON).

Chaque PR contient le diff des fichiers générés et un résumé des tokens modifiés. Les revues se font en équipe : un designer valide la cohérence visuelle, un développeur valide l'impact technique (renommage, suppression, ajout). Les workflows GitHub Actions permettent de bloquer la merge si un test échoue, par exemple un test de régression visuelle Chromatic ou un snapshot Playwright.

La validation automatique est non-négociable. À chaque PR, la CI exécute : checks de contraste WCAG (Pa11y, axe-core), vérification de la cohérence des aliases (pas de référence circulaire), validation du schéma JSON contre le format W3C. Si un token couleur ne passe pas le seuil 4.5:1 sur un fond donné, la PR est bloquée avec un message explicite. L'équipe ne découvre le problème qu'à la mise en production, c'est le pipeline qui l'attrape.

Sur un workflow mature, on ajoute une étape d'auto-merge pour les changements cosmétiques non-breaking (ajout d'un token, correction de contraste sans renommage). Les changements breaking (renommage, suppression) exigent une revue humaine explicite. Cette segmentation réduit la fatigue de revue tout en préservant la sécurité. Le ratio observé : 70 % de PR auto-merged, 30 % de PR manual review.

Tailwind v4 a changé la donne en poussant les tokens vers le CSS natif via la directive @theme. Fini le tailwind.config.js bavard qui dupliquait les variables en JavaScript. Désormais, les tokens vivent dans globals.css sous forme de custom properties réelles, et Tailwind les consomme pour générer les utilities.

Style Dictionary produit donc un bloc @theme directement. La sortie ressemble à @theme { --color-bg-primary: #ffffff; --color-fg-primary: #0a0a0a; --color-accent: #2563EB; --radius-md: 0.5rem; }. Tailwind v4 expose automatiquement les utilities bg-bg-primary, text-fg-primary, bg-accent, rounded-md. Pas de couche intermédiaire, pas de mapping manuel.

Le bénéfice majeur est le dark mode. En v3, il fallait ajouter dark: sur chaque classe, ce qui multipliait les variants et alourdissait le code. En v4 avec @theme, le dark mode devient un simple switch de variables : on redéfinit les tokens sémantiques dans un sélecteur [data-theme="dark"] ou @media (prefers-color-scheme: dark), et tout le design system bascule automatiquement. Le code des composants ne change pas. Une ligne de CSS suffit.

Sur la base VALRY LABS, ce changement a réduit le CSS final de 32 kB à 18 kB gzip (-44 %), tout en simplifiant radicalement la maintenance du dark mode. Les tokens générés par le pipeline Figma puis Style Dictionary sont désormais consommés nativement, sans couche JavaScript intermédiaire. Le pipeline gagne en cohérence et en performance.

Chaque token couleur du pipeline doit passer WCAG AA : ratio de contraste de 4.5:1 pour le texte normal, 3:1 pour le texte large (au moins 24 px regular ou 18.66 px bold) et pour les composants d'interface. Ce n'est pas une vérification manuelle en fin de projet, c'est un test automatisé qui s'exécute à chaque PR de tokens.

Concrètement, la CI fait tourner Pa11y ou axe-core sur une page de démonstration qui utilise tous les tokens sémantiques dans leurs contextes canoniques (texte sur fond, icône sur fond, bordure sur fond). Pour chaque combinaison, le ratio est calculé. Si une paire ne passe pas le seuil, la PR est bloquée. C'est l'équivalent d'un test unitaire, mais pour la lisibilité.

Pour les combinaisons à risque (un accent clair sur fond clair, par exemple), le pipeline génère automatiquement des tokens alternatifs. Si --color-accent ne passe pas sur --color-bg-primary, le système propose --color-accent-on-primary, une variante plus foncée calculée pour respecter le seuil. Le designer n'a pas à dériver manuellement la variante : le pipeline la suggère, et le designer valide.

Au-delà du contraste, le pipeline valide aussi la cohérence des états (hover, focus, active, disabled) : chaque état doit conserver un contraste suffisant. Les tokens de focus ring doivent être visibles sur tous les fonds possibles. Cette discipline automatique transforme l'accessibilité en propriété émergente du système, plutôt qu'en charge additionnelle. C'est la condition pour livrer un Lighthouse a11y supérieur ou égal à 95 durable.