Design Tokens en 2026 : comment synchroniser Figma et l’interface en production sans corrections manuelles

Un design system devient difficile à maintenir lorsqu’une même décision existe à plusieurs endroits déconnectés. Une couleur de marque peut avoir une valeur hexadécimale dans Figma, une autre dans le CSS et une version plus ancienne dans une application mobile. Le même problème peut concerner les espacements, les rayons de bordure, la typographie et les états des composants. Les design tokens réduisent cette duplication en attribuant des noms stables et des valeurs réutilisables aux décisions visuelles importantes. En 2026, la connexion entre conception et production est nettement plus pratique qu’il y a quelques années : les variables Figma peuvent représenter des tokens, le Design Tokens Community Group a publié sa première spécification stable et les fichiers de tokens peuvent circuler entre les processus de conception et de développement dans des formats standardisés. L’objectif n’est pas de remplacer les designers ou les développeurs. Il s’agit d’éviter de recopier constamment des valeurs entre différents outils et de corriger manuellement des incohérences prévisibles.

Pourquoi les Design Tokens sont devenus le lien entre Figma et la production

Un design token représente une décision de conception nommée plutôt qu’une simple couleur ou une valeur numérique enregistrée. Au lieu d’indiquer à un développeur qu’un bouton utilise la couleur #2563EB, par exemple, un design system peut définir une couleur primitive puis la référencer à travers un token sémantique comme colour/action/primary. Cette distinction est importante, car le nom sémantique décrit la raison pour laquelle la valeur est utilisée. Si la couleur de marque change ultérieurement, l’équipe peut modifier le token sous-jacent au lieu de rechercher une ancienne valeur hexadécimale dans des centaines de frames, de composants et de feuilles de style. La même approche s’applique aux espacements, aux dimensions, aux valeurs liées à la typographie, aux bordures et à de nombreuses autres décisions récurrentes.

Les variables Figma offrent une représentation pratique de ce modèle côté design. Figma prend actuellement en charge les variables de couleur, numériques, textuelles et booléennes, tandis que les variables peuvent également faire référence à d’autres variables. Cela permet de séparer les valeurs brutes des décisions qui les utilisent. Une valeur bleue peut être stockée dans une collection primitive, tandis que les éléments de l’interface utilisent des variables sémantiques comme text/link/default ou background/action/primary. Figma prend également en charge les modes, qui permettent à la valeur associée à une variable de changer selon le contexte. Les thèmes clair et sombre constituent l’exemple le plus évident, mais les modes peuvent aussi représenter différentes marques, tailles d’appareils ou autres variantes contrôlées, sans nécessiter un ensemble distinct de composants pour chaque cas.

Le changement majeur pour 2026 est que l’échange de tokens ne dépend plus entièrement de conventions propriétaires. Le Design Tokens Community Group a publié sa première spécification stable, la version 2025.10, le 28 octobre 2025. Figma a ensuite introduit l’importation et l’exportation natives de design tokens basées sur le format DTCG. Une équipe peut donc conserver les données des tokens dans des fichiers JSON structurés au lieu d’inventer un format différent pour chaque outil utilisé. Cela ne rend pas la synchronisation automatique à lui seul, mais permet aux designers et aux développeurs de travailler avec un vocabulaire commun. Au lieu de traduire les décisions de conception à chaque transmission entre équipes, les deux parties peuvent utiliser les mêmes valeurs, les mêmes noms et les mêmes relations.

Créer une structure de tokens compréhensible par les designers et les développeurs

Les structures de tokens les plus fiables comportent généralement plusieurs niveaux. Les tokens primitifs stockent les valeurs de base telles que colour/blue/500, spacing/16 ou radius/8. Les tokens sémantiques expliquent l’usage de ces valeurs avec des noms comme colour/text/primary, colour/background/surface ou spacing/component/medium. Des tokens propres aux composants peuvent être ajoutés lorsqu’un composant nécessite réellement une décision spécifique et contrôlée, par exemple button/background/primary/default. Cette organisation évite que le design system ne devienne une liste de centaines de valeurs sans relation entre elles. Plus important encore, elle permet à une modification visuelle de se propager de manière prévisible : une primitive peut changer tandis que les références sémantiques et celles des composants restent intactes.

Le nommage est donc beaucoup plus important qu’il n’y paraît au premier abord. Les noms basés uniquement sur l’apparence vieillissent mal. Un token appelé blue-button peut devenir trompeur après un changement d’identité visuelle qui rend le bouton vert, tandis que action-primary reste pertinent. Le même principe s’applique aux espacements et à la typographie. Les noms doivent, autant que possible, décrire une fonction et suivre une convention unique dans Figma et dans le code. Si Figma utilise colour/background/primary alors que le code appelle la valeur équivalente mainBlueBackground, la synchronisation oblige encore les développeurs à traduire manuellement les concepts. Définir le vocabulaire avant de créer des centaines de variables coûte généralement moins cher que renommer un système déjà largement utilisé.

Les modes doivent également représenter de véritables variantes plutôt que servir à stocker des alternatives sans rapport entre elles. Un mode clair et un mode sombre peuvent contenir des valeurs différentes pour la même variable sémantique d’arrière-plan ou de texte, puisque la signification reste identique alors que le contexte change. Figma peut importer des fichiers JSON au format DTCG sous forme de modes et, lorsque plusieurs fichiers sont importés dans une nouvelle collection, chaque fichier compatible peut créer un mode. Les équipes doivent être attentives au nommage pendant ce processus, car Figma normalise les noms de tokens imbriqués avec des barres obliques et des conflits de noms peuvent entraîner l’ignorance de certains tokens dupliqués pendant l’importation. Une politique de nommage courte couvrant la hiérarchie, les majuscules, les abréviations et les tokens obsolètes permet d’éviter de nombreux problèmes.

Créer un processus contrôlé de synchronisation entre Figma et le code

La première décision opérationnelle consiste à déterminer d’où doivent provenir les modifications approuvées des tokens. Certaines équipes préfèrent un modèle code-first, dans lequel les fichiers JSON de tokens stockés avec la base de code constituent la référence officielle et les modifications approuvées sont ensuite importées dans Figma. D’autres permettent aux responsables du design system de créer les variables dans Figma avant de les exporter ou de les synchroniser avec le dépôt de développement. Les deux modèles peuvent fonctionner. Les problèmes apparaissent lorsque Figma et le code sont considérés comme deux sources d’autorité indépendantes et que des personnes peuvent modifier le même token des deux côtés sans processus de réconciliation. Un responsable clairement identifié et une direction de synchronisation documentée ont plus de valeur qu’une chaîne d’outils complexe aux responsabilités mal définies.

Pour de nombreuses équipes, un processus pratique en 2026 commence par des fichiers de tokens compatibles avec le format DTCG et placés sous contrôle de version. Une modification proposée suit alors une discipline de révision similaire à celle des autres ressources partagées du produit : l’auteur modifie un token, la différence apparaît dans l’historique des changements, les réviseurs vérifient son impact et la version approuvée sert à mettre à jour les sorties nécessaires. L’importation native des tokens dans Figma peut ensuite mettre à jour les variables et les modes correspondants sans obliger un designer à modifier chaque valeur manuellement. Si Figma constitue la source de création, les données exportées peuvent suivre le chemin inverse. Le contrôle de version ajoute une protection importante, car l’équipe peut voir précisément ce qui a changé et rétablir un état précédent lorsqu’une mise à jour produit un effet indésirable.

Les grandes organisations peuvent automatiser davantage ce processus avec l’API REST Variables de Figma. L’API permet de lire, créer, mettre à jour et supprimer des variables et elle est spécifiquement documentée pour les processus reliant Figma aux systèmes d’intégration continue ou à une source de référence du design system. L’accès à l’API REST Variables est actuellement soumis aux exigences de l’offre Enterprise de Figma, il ne faut donc pas la présenter comme une solution universelle pour toutes les équipes. Les structures plus petites peuvent tout de même mettre en place un processus efficace autour de l’importation et de l’exportation natives, de fichiers de tokens validés et de plugins adaptés. Le point essentiel est que le transfert régulier des valeurs doit suivre une procédure reproductible plutôt que dépendre du souvenir de quelqu’un chargé de recopier une nouvelle couleur ou un nouvel espacement dans plusieurs endroits.

Transformer les tokens partagés en valeurs de production plutôt que de les recopier manuellement

Une fois qu’un fichier de tokens approuvé existe, l’équipe de développement a besoin d’une méthode reproductible pour le transformer en valeurs utilisables par l’application. Des outils comme Style Dictionary sont couramment utilisés à cette fin, car ils peuvent convertir une collection centrale de tokens en sorties adaptées au CSS, à JavaScript, à iOS, à Android et à d’autres environnements de développement. Style Dictionary prend en charge l’approche DTCG, même si les équipes utilisant des parties plus récentes ou plus spécialisées de la spécification 2025.10 doivent vérifier les notes de compatibilité actuelles avant de s’y engager. Pour un système classique de couleurs, d’espacements et de typographie, le principe reste simple : conserver la décision une seule fois et générer les représentations nécessaires pour chaque produit au lieu de maintenir manuellement plusieurs listes parallèles.

Prenons l’exemple d’une modification apportée à un token sémantique nommé colour/background/brand. Dans un processus non synchronisé, un designer change la couleur dans Figma, envoie un message à un développeur, le développeur recherche la valeur CSS correspondante, un autre développeur met à jour l’application mobile et quelqu’un remarque plus tard qu’un état de survol utilise encore l’ancienne couleur. Avec des tokens partagés, la valeur approuvée est modifiée à sa source, les références continuent à pointer vers le même nom sémantique et le code généré reçoit la valeur mise à jour dans le cadre du processus normal de build. Une révision reste nécessaire, notamment pour l’accessibilité et les effets visuels inattendus, mais le transfert répétitif de la valeur disparaît.

Le Dev Mode de Figma contribue à maintenir cette connexion pendant le handoff. Les développeurs qui inspectent une variable peuvent voir son nom, sa collection, son mode actif, sa valeur résolue et sa chaîne d’alias au lieu de recevoir uniquement la valeur brute finale. Figma permet également d’associer une syntaxe de code aux variables, avec des extraits actuellement disponibles pour CSS, SwiftUI et Compose. Un développeur peut donc constater qu’un élément utilise une variable validée du design system au lieu de traiter chaque valeur inspectée comme une instruction isolée. Cela est particulièrement utile pendant les revues de code : une couleur codée en dur comme #1F2937 peut être remise en question lorsqu’un composant devrait utiliser le token de texte établi, ce qui facilite la détection des écarts avant qu’ils ne soient intégrés à l’interface publiée.

Éviter les corrections manuelles exige aussi une gouvernance, pas seulement de l’automatisation

La synchronisation des tokens échoue lorsque les équipes se concentrent sur l’exportation des valeurs mais négligent la manière dont ces valeurs sont créées et modifiées. Toutes les mesures présentes dans un fichier Figma ne doivent pas devenir des tokens. Si les designers créent une nouvelle variable pour chaque marge, couleur ou rayon légèrement différent, la bibliothèque de tokens devient rapidement plus difficile à comprendre que les valeurs brutes qu’elle devait remplacer. Une bonne question consiste à déterminer si la décision est répétée, significative ou susceptible d’évoluer dans le cadre du système. Une couleur de surface récurrente mérite un token ; une coordonnée utilisée une seule fois dans une illustration, probablement pas. Une collection volontairement limitée permet aux designers de sélectionner plus facilement la bonne variable et aux développeurs de faire davantage confiance aux résultats générés.

Les modifications ont également besoin d’un responsable clairement identifié. Un processus mature détermine qui peut ajouter un nouveau token, qui approuve les changements apportés aux valeurs sémantiques existantes et ce qui se passe lorsqu’un token n’est plus nécessaire. Renommer ou supprimer un token établi peut affecter de nombreux composants même lorsque sa valeur visuelle ne change pas. La dépréciation est généralement plus sûre qu’une suppression immédiate : il est préférable de marquer l’ancien token comme obsolète, de fournir son remplacement, de migrer les usages puis de le supprimer seulement après vérification. Les historiques de modifications doivent expliquer l’objectif des changements importants au lieu de simplement indiquer qu’une valeur hexadécimale a été remplacée par une autre. Designers et développeurs disposent ainsi du contexte nécessaire pour déterminer si une modification est intentionnelle.

Les contrôles automatisés peuvent traiter les erreurs prévisibles avant même que la révision visuelle ne commence. Un fichier de tokens peut être vérifié pour détecter une syntaxe invalide, des noms dupliqués, des références manquantes, des types incohérents ou des valeurs codées en dur inattendues. Les contrôles visuels et d’accessibilité doivent ensuite couvrir les effets que la validation des tokens ne peut pas évaluer seule. Modifier un token de texte ou d’arrière-plan, par exemple, peut changer le contraste des couleurs dans de nombreux composants simultanément. Un build réussi ne prouve donc pas qu’une modification de design est adaptée. L’automatisation doit supprimer les vérifications répétitives afin que les équipes consacrent leur temps à la facilité d’utilisation, à la hiérarchie, à l’accessibilité et au contexte du produit plutôt qu’à la comparaison de listes de codes couleur.

Un plan d’adoption pratique pour les design systems existants en 2026

Un produit existant n’a pas besoin de convertir toutes ses décisions de conception en tokens en une seule fois. Une première étape plus sûre consiste à auditer les valeurs déjà répétées dans Figma et en production. Les couleurs constituent souvent le meilleur point de départ, car les incohérences sont visibles et les rôles sémantiques tels que le texte, les surfaces, les bordures, les actions et les états peuvent généralement être identifiés facilement. Les espacements, les rayons et la typographie peuvent suivre une fois que l’équipe a testé ses règles de nommage. Pendant l’audit, les valeurs codées en dur et répétées doivent être associées à des primitives et à des tokens sémantiques proposés. Des valeurs proches mais utilisées à des fins différentes ne doivent pas être fusionnées automatiquement simplement parce que leurs chiffres actuels sont identiques.

L’étape suivante consiste à lancer un test limité en production. Une famille de composants ou une partie clairement définie de l’interface peut utiliser les nouveaux tokens depuis la conception jusqu’au code publié. L’équipe peut ensuite répondre à des questions pratiques difficiles à résoudre dans une spécification théorique : les designers comprennent-ils les noms, les développeurs trouvent-ils les bons tokens dans Dev Mode, les valeurs du mode sombre sont-elles correctement résolues, le processus de génération du code produit-il des noms lisibles et un ancien token peut-il être remplacé sans provoquer de problèmes invisibles ? Une fois ces questions clarifiées, le même processus peut être étendu à d’autres composants. Cette approche progressive facilite également la suppression des anciens styles locaux au lieu de maintenir indéfiniment deux systèmes parallèles.

La réussite doit être mesurée par la réduction des écarts obtenue grâce au processus, et non par le nombre de tokens créés. Parmi les indicateurs utiles figurent la diminution des valeurs du design system codées en dur dans la production, la réduction des différences entre Figma et les composants publiés, le raccourcissement du délai entre l’approbation d’un changement de token et sa mise en œuvre, ainsi que la diminution des corrections manuelles pendant les revues de design. Figma a lui-même continué à réduire la distance entre conception et code en 2026 : une mise à jour de juillet a rapproché le comportement d’auto layout de celui du CSS, tandis qu’une autre mise à jour de juillet a permis aux écrans basés sur du code importés sur le canvas d’associer les couleurs, la typographie et les espacements à de nombreuses variables déjà présentes dans le fichier. Ces évolutions confirment la direction générale, mais un système de tokens fiable repose toujours sur un nommage clair, une responsabilité définie, des modifications contrôlées et une validation automatisée. Lorsque ces bases sont en place, Figma et la production peuvent partager les mêmes décisions de conception au lieu de les recréer encore et encore.