Style Dictionary vs export direct

Deux configurations de tokens, côte à côte. La première est un dépôt avec un répertoire build/ : une configuration Style Dictionary, une liste de transformations personnalisées, une dépendance npm avec ses propres notes de version, et des cibles de sortie pour le web, iOS, Android et un site de documentation. La seconde est un générateur dont le panneau d’export écrit directement du CSS, un thème Tailwind et des Figma Variables, avec le fichier de tokens versionné à côté du code et aucune étape de build. Aucune des deux équipes ne se trompe — elles ont des problèmes de formes différentes.

Style Dictionary est un pipeline de transformation : il prend un fichier source de tokens et le fait passer par des transformations et des formats configurables pour émettre n’importe quelle cible que vous définissez. L’export direct, c’est l’outil de génération qui émet lui-même les formats courants, sans pipeline à configurer. Le pipeline est la bonne voie quand vous avez de nombreuses cibles ou des cibles sur mesure ; l’export direct est la bonne voie quand les cibles web standard vous suffisent — et comme un fichier DTCG canonique peut alimenter un pipeline plus tard, choisir l’export direct aujourd’hui ne vous ferme pas la porte du pipeline demain.

C’est le chapitre outillage de notre guide des design tokens : ce qu’est réellement chaque voie, une comparaison honnête, et le même token suivi sur les deux.

Qu’est-ce que Style Dictionary ?

L’outil open source qui a défini la catégorie de la transformation de tokens, documenté sur styledictionary.com — quand il est question de pipelines de build de tokens, c’est généralement la référence, et c’est une infrastructure complémentaire plutôt qu’un concurrent d’un quelconque générateur. Ce n’est pas un outil de design : il n’a aucun avis sur ce que devraient être vos valeurs et aucune interface pour les décider. Il consomme une source de tokens, fait passer chaque token par des transformations — renommage dans la casse d’une plateforme, conversion d’unités, reformatage des couleurs selon la syntaxe de la cible — et remet les résultats à des formats qui écrivent les fichiers cibles : propriétés personnalisées CSS, maps Sass, constantes Swift, XML de ressources Android, JSON pour un site de documentation. Chaque jointure est configurable, et les transformations personnalisées sont du code ordinaire que vous écrivez et possédez.

Cette forme rend son terrain de prédilection évident : de nombreuses cibles, des règles de nommage propres à chaque plateforme, un pipeline de build existant dans lequel s’insérer. Il s’exécute comme une étape de build, et les équipes plateforme le traitent comme telle.

Qu’est-ce que l’export direct ?

L’outil qui a généré le système écrit aussi les formats consommateurs. Le Scale Composer fonctionne ainsi : il dérive la typographie, l’espacement, les rampes de couleur et les rôles sémantiques clair/sombre à partir d’une seule échelle partagée, puis exporte un fichier de tokens DTCG canonique en même temps que des propriétés personnalisées CSS, un bloc @theme Tailwind v4 et des Figma Variables, avec le hex porté à côté de l’OKLCH — aucune configuration, aucune dépendance de build, rien à maintenir hormis la sortie elle-même.

La limite honnête, c’est le menu : l’export direct couvre les formats qu’il couvre. Pour la plupart des produits web — une feuille de style, un thème utilitaire, un fichier de design — le menu constitue le repas entier. Mais une cible hors menu ne peut pas être ajoutée par configuration, puisqu’il n’y a pas de configuration ; c’est précisément là que commence le territoire du pipeline.

Comment les deux voies se comparent-elles ?

Le tableau est honnête dans les deux sens. « N’importe quelle cible » est une vraie puissance qui coûte une vraie responsabilité — la config, les transformations et les mises à jour de dépendances appartiennent à quelqu’un dans votre équipe. « Aucune mise en place » est une vraie économie qui vous impose un menu fixe. Aucune colonne ne domine ; la ligne décisive est généralement la dernière.

Ouvrez les exports directs côte à côte dans Scale Composer — un seul système généré, rendu simultanément sous forme de fichier DTCG, de propriétés personnalisées CSS, de thème Tailwind et de Figma Variables.

Devez-vous choisir ?

Souvent, non — et c’est le point central de l’article : comme la sortie canonique du Scale Composer est du DTCG standard, le fichier que produit l’export direct est une source valide pour un pipeline de transformation. Utilisez l’export direct pour la boucle quotidienne — décider, exporter, versionner, consommer. Le jour où une application native apparaît sur la feuille de route, pointez la source de Style Dictionary vers le même fichier versionné et ajoutez les nouvelles cibles ; rien n’est réécrit et la boucle quotidienne ne change pas. Le format d’échange est ce qui rend les deux voies composables plutôt qu’exclusives — le bénéfice de standardiser sur le DTCG plutôt que sur le dialecte privé d’un quelconque outil.

Le verrouillage échoue dans les deux sens. Quittez le générateur, et le fichier DTCG reste une entrée valide pour le pipeline. Adoptez le générateur tardivement, et il importe un fichier DTCG existant, en préservant les sections qu’il ne génère pas à travers l’aller-retour.

Quand avez-vous dépassé l’export direct seul ?

Trois signaux, dont un seul suffit :

1. Une cible que les formats intégrés ne couvrent pas. Des ressources d’application native, des variables de modèle d’e-mail, un site de documentation thématisé — tout ce qui exige une forme de fichier que le menu d’export ne propose pas.
2. Des transformations de nommage par plateforme. Le web veut --color-accent, Android veut color_accent, iOS veut colorAccent — le renommage systématique par cible est la mission qui définit le pipeline.
3. La génération de documentation. Quand le fichier de tokens doit aussi produire des pages de référence, la documentation n’est qu’une cible de format de plus.

Notez la forme du mouvement quand un signal arrive : un ajout, pas une migration. Le pipeline consomme le fichier que la boucle quotidienne produit déjà.

À quoi ressemble le même token sur chaque voie ?

Prenons une décision sémantique — accent référence brand-600, qui stocke #2563eb, oklch(0.546 0.215 262.9).

Voie directe. L’export CSS écrit la propriété personnalisée résolue :

:root {
  --accent: #2563eb; /* semantic.accent → color.brand.600 */
}

Voie pipeline. Une config — esquissée dans sa forme ici ; l’API exacte se trouve dans la documentation de l’outil — pointe vers le même fichier canonique et demande une cible de classe Android :

// config style-dictionary, forme non littérale
{
  source: ["design-tokens.json"],   // export canonique du Scale Composer
  platforms: {
    android: {
      transforms: ["name → snake_case", "color → #AARRGGBB"],
      files: [{ format: "android/resources", destination: "colors.xml" }]
    }
  }
}

émettant une ressource de la classe colors.xml :

<color name="semantic_accent">#FF2563EB</color>

Même décision, deux rendus : les points sont devenus des traits d’union et une propriété personnalisée sur une voie, du snake_case et un hex avec l’alpha en premier sur l’autre. La valeur est identique dans les deux cas, parce que les deux voies lisent la même source — tout l’argument, visible en trois lignes de sortie.

Partez du fichier que les deux voies partagent

Quelle que soit la voie qui vous convient aujourd’hui, elle commence par le même artefact. Exportez le fichier de tokens DTCG canonique depuis Scale Composer — les exports directs à ses côtés pour la boucle quotidienne, et le fichier lui-même prêt à devenir la source d’un pipeline le jour où une nouvelle cible apparaît.