Du token Figma au composant React en 5 étapes — et la moitié de la glue d'avant ne sert plus à rien

La moitié de mon pipeline de tokens a disparu en un an

Il y a un an, mon pipeline pour passer d'un design token Figma à un composant React comptait une bonne dose de plomberie : un fichier de configuration JavaScript qui réexposait les tokens, des constantes importées manuellement dans chaque composant, un thème provider qui jonglait avec tout ça. Aujourd'hui, la moitié de ce code a disparu de mes projets — non pas parce que j'ai trouvé une astuce, mais parce que l'écosystème a rattrapé le besoin. Tailwind v4, sorti en janvier 2025, expose désormais tous les tokens comme variables CSS par défaut via sa configuration CSS-first. La spécification Design Tokens du W3C a atteint sa première version stable le 28 octobre 2025. Quand l'outillage absorbe ta plomberie, t'accrocher à ton ancien pipeline devient de la dette, pas de la maîtrise.

Le contrat de fond, lui, n'a pas bougé : un design token est un vocabulaire partagé entre Figma et le code qui ne laisse aucune place à l'interprétation. Quand un designer pose color/action/primary dans Figma, le développeur sait exactement quelle variable utiliser. Ce qui a changé, c'est la quantité de code qu'il faut écrire pour faire vivre ce contrat. Voici les cinq étapes telles que je les pratique en 2026, avec ce que j'ai gardé et ce que j'ai jeté.

Étape 1 — Structurer les variables dans Figma

Tout part d'une hiérarchie de variables rigoureuse, et elle n'a rien perdu de son importance — c'est même elle qui rend tout le reste possible, y compris la lisibilité par l'IA. Je crée trois collections : les primitives (valeurs brutes, hex et pixels), les sémantiques (alias contextuels comme surface/primary ou text/on-primary), et les tokens de composant (button/padding-md, card/radius). Cette hiérarchie à trois niveaux permet de basculer un thème entier en touchant uniquement la couche primitive.

La convention de nommage doit se traduire telle quelle en chemin CSS : color/surface/primary devient --color-surface-primary. Pour les types que Figma ne gère pas nativement — ombres composites, typographies complètes, transitions — le plugin Tokens Studio reste indispensable, et il exporte directement au format JSON conforme DTCG. Détail qui compte depuis fin 2025 : Figma a ajouté l'import/export natif des variables en novembre 2025, précisément aligné sur la spec stable. Pour des systèmes simples, ça réduit encore la dépendance aux plugins tiers.

Étape 2 — Exporter au format Design Tokens stable

C'est ici que la mise à jour la plus importante se joue. L'article que j'aurais écrit l'an dernier vous aurait dit que la spec W3C était en « Second Editor's Draft » — un brouillon mouvant sur lequel j'ai personnellement reconstruit des pipelines plus d'une fois. C'est terminé : la version 2025.10, publiée le 28 octobre 2025, est stable, neutre et supportée par plus de dix outils. Concrètement, le format est plus riche et plus précis qu'avant. Une couleur n'est plus une simple chaîne hexadécimale mais un objet portant son espace colorimétrique — Display P3, Oklch, l'ensemble de CSS Color Module 4 sont désormais couverts — avec ses composantes, son alpha et un repli hexadécimal. Les dimensions et durées deviennent des objets structurés avec valeur et unité.

Deux voies d'export : Tokens Studio avec synchronisation Git intégrée, ou l'API REST Figma Variables pour un export programmatique branché en CI/CD. Pour un projet mature, je privilégie la seconde — le fichier JSON est versionné dans le dépôt et suit l'évolution des tokens avec la même rigueur que le code. Le point clé : ce fichier est ta source de vérité machine, et il doit être propre, parce que tout ce qui suit en dépend.

Étape 3 — Transformer avec Style Dictionary v5

Style Dictionary convertit ce JSON en ce dont ta stack a besoin. La version 5, alignée sur la spec 2025.10, a remplacé la v4 dont parlait encore la plupart des tutoriels : son format d'export par défaut est désormais le JSON DTCG, ses transformations gèrent nativement les nouveaux types d'objets couleur et dimension, et elle exige Node 22. Si tu fais tourner du v4 sur un ancien format, tu n'es pas cassé, mais tu accumules une dette qui se paiera au prochain refactor de thème.

C'est aussi à cette étape que ma plomberie a fondu. Avant, je générais en sortie un fichier CSS, un fichier de constantes JavaScript et de la documentation. Aujourd'hui, je génère surtout un bloc de custom properties CSS — parce que l'étape 4 va les consommer directement, sans repasser par un fichier de config JavaScript. La fonctionnalité expand reste précieuse : un token composite de type typography est décomposé automatiquement en sous-tokens (fontFamily, fontSize, fontWeight, lineHeight), chacun générant sa propre variable. Je ne garde les constantes JS que pour les rares composants qui ont besoin d'un accès programmatique aux valeurs.

Étape 4 — Brancher les composants React sur Tailwind v4

C'est l'étape qui a le plus changé. Tailwind v4 a abandonné le fichier tailwind.config.js au profit d'une configuration CSS-first : on déclare ses tokens dans un bloc @theme, et Tailwind les transforme en utilitaires tout en les exposant comme variables CSS au runtime.

@theme {
  --color-surface-primary: #0b1020;
  --color-action-primary: #2f6bff;
  --radius-card: 12px;
  --font-display: "Inter", sans-serif;
}

Autrement dit, la sortie de Style Dictionary alimente directement le @theme, qui devient l'unique source de vérité des tokens côté code. Plus de fichier de config JS à synchroniser à la main, plus de constantes réexportées : le token défini une fois est inspectable dans les DevTools du navigateur et surchargeable au runtime. Le nouveau moteur, bâti sur Lightning CSS, accélère au passage les builds complets d'un facteur cinq — pas l'argument principal, mais agréable.

Les composants, eux, n'utilisent que ces tokens. Pour le clair/sombre, je m'appuie sur React 19 — stable depuis décembre 2024, et en version 19.2.7 au moment où j'écris — avec un thème provider minimaliste qui bascule les custom properties, détecte les préférences système et persiste le choix. Les Server Components, désormais standardisés, changent où ce provider vit, mais pas le principe.

Étape 5 — Fermer la boucle avec Code Connect

La dernière étape rebranche le code sur Figma. Les fichiers .figma.tsx vivent à côté de tes composants React dans le dépôt, et l'API figma.connect() mappe chaque composant Figma à son équivalent JSX.

import figma from "@figma/code-connect";
import { Button } from "./Button";

figma.connect(Button, "https://figma.com/design/…?node-id=1-23", {
  props: {
    label: figma.string("Label"),
    variant: figma.enum("Variant", { Primary: "primary", Ghost: "ghost" }),
    disabled: figma.boolean("Disabled"),
  },
  example: ({ label, variant, disabled }) => (
    <Button variant={variant} disabled={disabled}>{label}</Button>
  ),
});

Les correspondances de props utilisent figma.string() pour les textes, figma.boolean() pour les toggles, figma.enum() pour les variantes, figma.instance() pour les sous-composants, et figma.className() pour mapper directement des classes Tailwind — pratique avec une stack v4. Le workflow s'orchestre en CLI :

figma connect create
figma connect publish

La nouveauté 2025 qui abaisse la barrière, c'est le Code Connect UI : on relie Figma à un dépôt GitHub depuis l'interface, avec des suggestions par IA pour trouver le bon fichier à mapper, sans écrire de config. J'ai longtemps réservé Code Connect aux équipes de plateforme ; cette version le rend viable pour un studio d'une personne. Des outils comme Anima, Locofy.ai ou Builder.io Visual Copilot génèrent un premier jet de code à partir des maquettes, et ils se sont améliorés — mais pour maintenir la synchronisation dans la durée, Code Connect reste la pièce fiable. Au bout du pipeline, quand un dev inspecte un composant dans Dev Mode, il voit le vrai code du projet. Le fossé Figma → React ne se franchit pas d'un saut : il se comble token par token, et désormais avec deux fois moins de plomberie qu'il y a un an.