Figma : bien structurer ses Design Tokens
Qu'est-ce qu'un Design Token ?
Un design token est une valeur de design (une couleur, un espacement, une taille de police, un rayon de bordure...) à laquelle on donne un nom sémantique plutôt que de l'utiliser brute. Au lieu d'écrire #6B21A8 partout dans un fichier, on définit une seule fois color/primary, et on référence ce nom dans toutes les maquettes.
Analogie développeur : un design token, c'est l'équivalent Figma d'une variable CSS custom property (var(--primary)) ou d'une valeur dans tailwind.config. Tu ne réponds jamais "cette couleur, c'est du violet" — tu réponds "c'est color/primary", et sa valeur exacte peut changer sans que tu aies besoin de retoucher un seul écran.
Le visuel plus haut dans cette page illustre exactement ce principe : chaque couleur porte un nom (color/primary, color/success) plutôt qu'un simple code hexadécimal — c'est cette indirection qui rend un Design System maintenable.
Les trois niveaux de tokens
Un système de tokens bien construit s'organise généralement en trois couches, chacune avec un rôle précis. C'est la structure recommandée par la plupart des équipes Design System matures (Google Material, Atlassian, Shopify Polaris).
| Niveau | Rôle | Exemple |
|---|---|---|
| Tokens primitifs | Les valeurs brutes, sans contexte d'usage | purple-700: #6B21A8 |
| Tokens sémantiques | Donnent un sens métier à un primitif | color-primary: {purple-700} |
| Tokens de composant | Spécifiques à un composant précis | button-bg-primary: {color-primary} |
purple-700 (primitif)
↓
color-primary (sémantique) ← référence purple-700
↓
button-bg-primary (composant) ← référence color-primaryPourquoi cette indirection en vaut la peine : si tu changes purple-700 pour un violet légèrement différent, color-primary et button-bg-primary se mettent à jour automatiquement — sans qu'il soit nécessaire de retoucher chaque composant un par un.
Sur un petit projet solo, les niveaux "sémantique" et "composant" peuvent parfois fusionner. Mais dès qu'un Design System dépasse une dizaine de composants — comme celui construit pour Keller Williams France avec plus de 30 composants Figma — cette séparation en trois couches évite qu'un changement de couleur se transforme en chasse aux références dans tout le fichier.
Bien nommer ses tokens
Le nommage est ce qui détermine si un système de tokens reste compréhensible dans six mois — pour toi, et pour quiconque reprend le fichier. La convention la plus répandue suit une structure hiérarchique constante :
catégorie/propriété/variante
color/text/primary
color/text/muted
color/background/surface
color/border/default
spacing/xs
spacing/sm
spacing/md
spacing/lg
radius/sm
radius/md
radius/full❌ Nommage descriptif
violet-foncegris-clair-fondpetit-espace- Décrit l'apparence, pas l'usage
- Casse si la couleur change de teinte
✅ Nommage sémantique
color/text/primarycolor/background/surfacespacing/xs- Décrit le rôle, pas l'apparence
- Reste valide même si la valeur change
Évite absolument de nommer un token d'après sa valeur visuelle actuelle, comme bleu-header. Si un jour le header passe au violet, soit tu renommes le token partout (source d'erreurs), soit tu gardes un nom qui ne correspond plus à rien — les deux options sont mauvaises.
Les Variables Figma : la mise en pratique
Depuis leur introduction, les Variables de Figma (menu latéral droit, icône en forme de losange à quatre pointes) sont l'outil natif pour créer de vrais design tokens directement dans l'interface — plus besoin de plugin tiers pour la structure de base.
Quatre types de variables sont disponibles :
| Type | Utilisation |
|---|---|
| Color | Couleurs de fond, de texte, de bordure |
| Number | Espacements, rayons de bordure, tailles d'icônes |
| String | Contenus texte réutilisables (labels, placeholders) |
| Boolean | États d'affichage (afficher/masquer un élément) |
Pour créer une collection organisée : ouvre le panneau Variables, crée une collection nommée Tokens, puis structure tes groupes avec le même / que pour les composants (color/primary, spacing/lg) — Figma génère automatiquement la même arborescence visuelle que dans le panneau Assets.
Une fois une variable créée, applique-la sur une propriété (couleur de fond, padding...) via le petit icône de losange qui apparaît au survol du champ dans le panneau de droite — plutôt que de re-sélectionner manuellement une couleur à chaque fois.
Modes et theming avec les Variables
L'un des plus gros avantages des Variables Figma : elles supportent plusieurs modes au sein d'une même collection. C'est exactement le mécanisme qui permet de gérer un thème clair et un thème sombre sans dupliquer aucune maquette.
Collection "Tokens"
├── Mode "Light"
│ ├── color/background/surface → #FFFFFF
│ └── color/text/primary → #111111
└── Mode "Dark"
├── color/background/surface → #1A1A1A
└── color/text/primary → #F5F5F5Une fois les deux modes définis, un simple sélecteur en haut du panneau de droite permet de prévisualiser instantanément toute une maquette en clair ou en sombre — sans dupliquer un seul calque. C'est le même principe que ton système de variables useColorScheme.tsx côté code : une seule structure de composants, deux jeux de valeurs.
Du design au code
L'intérêt final des tokens, c'est de créer un langage commun entre Figma et le code — pas seulement une organisation propre côté design. Une fois bien nommés, tes tokens Figma se traduisent presque terme à terme en variables CSS ou en configuration Tailwind :
/* app/globals.css — miroir direct des tokens Figma */
:root {
--color-primary: #6b21a8;
--color-text-primary: #111111;
--color-background-surface: #ffffff;
--spacing-xs: 4px;
--spacing-sm: 8px;
--spacing-md: 16px;
--spacing-lg: 24px;
--radius-sm: 8px;
--radius-md: 12px;
}Des outils comme le mode Dev Mode de Figma (payant) ou des plugins gratuits comme Tokens Studio permettent d'exporter directement les Variables Figma vers un fichier JSON, lui-même transformable en variables CSS ou en config Tailwind via un outil comme Style Dictionary. Le workflow complet devient : modifier un token dans Figma → exporter → régénérer les fichiers CSS → le site entier se met à jour.
Même sans automatiser tout ce pipeline, le simple fait d'avoir des noms identiques entre Figma et le code (color/primary côté design, --color-primary côté CSS) élimine énormément d'allers-retours de clarification entre design et développement.
Les erreurs fréquentes à éviter
Créer un token pour chaque valeur unique rencontrée — Si un token n'est utilisé qu'une seule fois dans tout le fichier, ce n'est probablement pas un vrai token, juste une valeur ponctuelle. Réserve les tokens aux valeurs réutilisées intentionnellement.
Dupliquer une collection de variables plutôt que d'utiliser les modes — Créer une collection Tokens Light et une collection Tokens Dark séparées casse la synchronisation automatique. Utilise toujours les modes au sein d'une seule collection.
Mélanger tokens primitifs et sémantiques dans la même collection sans distinction visuelle — Sans séparation claire (groupes nommés, ou collections distinctes), il devient impossible de savoir si purple-700 doit être modifié directement ou si c'est color-primary qui doit être retouché à la place.
Oublier de documenter l'intention d'un token — Figma permet d'ajouter une description à chaque variable (icône ℹ️ au survol). Un token color/danger avec la description "Utilisé pour les messages d'erreur et les actions destructrices (suppression)" évite qu'il soit mal réutilisé six mois plus tard pour un simple bouton secondaire.
En résumé
| Concept | À retenir |
|---|---|
| Design token | Une valeur nommée sémantiquement plutôt qu'utilisée brute |
| Trois niveaux | Primitif → Sémantique → Composant, du plus générique au plus spécifique |
| Nommage | catégorie/propriété/variante, toujours orienté usage et non apparence |
| Variables Figma | Color, Number, String, Boolean — organisées en collections avec / |
| Modes | Permettent de gérer plusieurs thèmes (clair/sombre) sans dupliquer les maquettes |
| Lien avec le code | Des noms identiques entre Figma et CSS fluidifient tout le passage au développement |
Un système de tokens bien pensé transforme un fichier Figma en véritable source de vérité pour toute l'équipe — designer comme développeur. C'est l'étape qui, combinée aux Main Components vus dans l'article précédent, fait vraiment basculer un fichier Figma de "collection de maquettes" à "Design System" au sens complet du terme.