Introduction : un standard qui remplace enfin le bricolage
Un design token n'est plus une simple variable Figma ou un fichier JSON maison propre à chaque équipe. Depuis fin 2025, il obéit à une norme commune : le W3C Design Tokens Format Module, porté par le Design Tokens Community Group (DTCG).
Nous avons croisé trois vidéos très différentes pour comprendre ce que ce standard change vraiment. Une vue d'ensemble pédagogique sur la sémantique des tokens, un deep-dive avec le co-chair du groupe de travail W3C, et une démonstration pratique sur Penpot, premier éditeur à l'avoir adopté nativement.
Leur point commun : le token n'est plus prisonnier d'un seul outil. Il pilote enfin le design et le code, sans traduction manuelle entre les deux.
Ce que la spécification W3C stabilise
Après cinq ans de travail communautaire, la version 2025.10 du Design Tokens Format Module est devenue la première édition stable de la norme. Elle a traversé trois versions préliminaires avant d'être validée par le terrain.
Ce n'est pas un détail technique isolé : 24 organisations au moins la soutiennent, parmi lesquelles Adobe, Google, Meta, Microsoft, Amazon et Figma. Plus de dix outils, dont Penpot, Sketch, Framer ou zeroheight, la supportent déjà ou l'implémentent.
La fin programmée du format propriétaire
Avant ce standard, chaque outil exportait ses tokens dans son propre format. Migrer une bibliothèque de Figma vers Sketch, ou vers un pipeline de build, imposait des scripts de conversion maison, fragiles et à réécrire à chaque mise à jour.
Le nouveau format JSON, avec l'extension .tokens ou .tokens.json, devient une API stable pour les créateurs de plugins et les développeurs d'outils. Un token exporté depuis un éditeur peut être réimporté ailleurs sans perte de sens ni de structure.
Des cas d'usage réels, pas une norme théorique
La spec couvre la gestion de thèmes multiples, les espaces colorimétriques modernes comme Display P3 ou Oklch, et les relations entre tokens par héritage et alias. Elle prévoit aussi la génération de code cross-plateforme, vers iOS, Android, le web ou Flutter.
Un rapport sectoriel récent (zeroheight, 2026) situe l'adoption des design tokens à 84 % des équipes produit, contre 56 % un an plus tôt. Les tokens sont devenus la norme, pas l'exception, même si 40 % des équipes gèrent encore la synchronisation à la main faute de vrai pipeline.
Figma passe à l'intégration native
C'est la vidéo officielle de Figma, tournée à la conférence Schema 2025 avec le co-chair du Design Tokens Community Group, qui donne la mesure du changement côté outil. Jusqu'ici, importer ou exporter des variables au format standard imposait un plugin open source tiers.
Figma a délibérément attendu la stabilisation de la norme avant de l'intégrer, pour ne pas influencer le marché avec une implémentation prématurée.
Un import qui comprend le contexte
Le nouveau système d'import ne se contente pas de copier des valeurs : il interprète la collection cible. Sur une collection vierge, il crée les variables et mappe les valeurs sur plusieurs modes automatiquement.
- collection vide → création des variables
- mode existant → mise à jour des valeurs
- collection étendue → ajout sélectif d'overrides
Cette logique s'appuie sur les mêmes principes que la conversion des styles en variables dans Figma, mais avec un format d'échange qui survit désormais à la sortie de l'outil.
Extended Collections : hériter au lieu de dupliquer
Le vrai saut concerne le multi-marque. Les Extended Collections permettent à une marque enfant d'hériter automatiquement de la structure et des modes d'une collection racine, tout en ne redéfinissant que ce qui change.
Une collection FigJam peut ainsi hériter des tokens Figma Colors et ne surcharger que ses teintes propres. Les équipes choisissent de loger l'extension dans le même fichier, pour une mise à jour instantanée, ou dans un fichier séparé, pour une autonomie d'expérimentation.
Migrer sans tout casser
Figma propose une méthode en six étapes pour les structures centralisées, testée auprès de vingt entreprises : exporter les valeurs, supprimer les modes existants, créer l'extension, réimporter les overrides, publier, puis accepter les mises à jour.
Un point de vigilance subsiste après la migration : les réglages de mode appliqués aux calques repartent sur le mode par défaut. Il faut les réappliquer manuellement, au niveau de la page ou de l'équipe.
La sémantique que le standard vient enfin uniformiser
La vidéo la plus pédagogique des trois ne parle presque pas du standard W3C, et c'est révélateur. Elle documente une pratique de nommage déjà largement partagée, que la norme vient simplement figer dans un format commun.
Nommer l'intention, pas la couleur
Un bouton ne reçoit pas « un vert » : il reçoit une intention de succès. Chaque état, success, warning ou error, se décompose en quatre tokens identiques (icône, texte, bordure, surface) pour que le designer applique toujours la même structure.
La distinction Action / On-Action suit la même logique : un token pour l'élément cliquable, un autre pour ce qui repose dessus. Cette rigueur de nommage est justement ce que le format DTCG permet de documenter et d'échanger tel quel, plutôt que de le réinventer par équipe.
Une architecture à deux ou trois niveaux
Pour organiser ces tokens, deux modèles dominent. Le modèle à trois niveaux, Brand → Alias → Mapped, sépare la couleur brute, son premier rôle, puis son usage final : utile pour le multi-marque ou un mode sombre complexe.
Le modèle à deux niveaux, Primitives → Semantic, adopté par des bibliothèques comme Untitled UI, va plus vite à mettre en place. Cette architecture recoupe la logique de la documentation des spécifications de composants dans Figma : sans nommage rigoureux, la spec la plus complète reste illisible pour l'équipe de dev.
Sur le terrain : Penpot et le format déjà natif
Penpot n'attend pas une implémentation propriétaire à convertir plus tard. L'éditeur open source a adopté le brouillon du standard DTCG comme format natif de ses tokens, avant même la sortie de la version stable.
Du kit de démarrage à l'export JSON standard
Le Design Tokens Starter Kit, disponible sur le Penpot Hub, importe des sets de tokens organisés par catégories : couleurs, dimensions, rayons de bordure. L'export génère un fichier JSON lisible, qu'on peut découper en plusieurs fichiers pour séparer les thèmes des fondations.
Cette continuité entre l'outil de design et les nouveautés collaboratives de Penpot 2.0 confirme une bascule de fond : les tokens deviennent agnostiques vis-à-vis de la plateforme de sortie.
L'effet de propagation, concrètement
Changer un token de densité de 1 à 1.2 recalcule automatiquement tous les espacements de l'interface. Basculer entre Light Mode et Dark Mode ne change que les valeurs de sortie des tokens sémantiques, jamais leur nom.
La démonstration va jusqu'à l'accessibilité : le plugin de contraste intégré signale un texte trop pâle, et corriger la variable à la source suffit à remettre toute l'interface en conformité.
Ce que révèlent les trois vidéos, mises bout à bout
Les trois sources n'éclairent pas le même problème. La vidéo généraliste documente une pratique de nommage déjà mature, indépendante de tout format. Le deep-dive Figma décrit le standard lui-même et son intégration native. La démonstration Penpot montre ce que ça donne une fois le format déjà adopté dans un outil.
Ce triple regard confirme que le changement n'est pas cosmétique. Un token nommé selon les mêmes principes peut désormais voyager d'un outil à l'autre sans réinterprétation, grâce à une seule spécification partagée.
Faut-il migrer ses tokens vers le format W3C maintenant ?
Pour une bibliothèque déjà mature sous Tokens Studio ou un format maison, la question se pose surtout à un renouvellement d'outil ou sur un projet multi-marque. La méthode de migration en six étapes de Figma reste la plus documentée à ce jour.
Pour un nouveau projet, la réponse est plus simple : démarrer directement au format DTCG évite une migration future. C'est notamment l'argument qui pèse dans un comparatif entre Penpot et Figma en 2025, pour les équipes qui veulent limiter leur dépendance à un seul éditeur.
Conclusion : le token, enfin un langage commun
Le design token n'a jamais été qu'une valeur nommée. Ce qui change avec le DTCG, c'est que ce nom et sa structure survivent désormais au changement d'outil, de designer ou de plateforme de sortie.
Reste la partie qui ne s'automatise pas : décider quelle intention porte chaque token, et où tracer la frontière entre fondation et sémantique. Le standard structure l'échange ; la rigueur de nommage reste notre travail.
Liens pratiques
Cet article de synthèse est basé sur les vidéos :
- Comprendre les Design Tokens : structurer l'architecture et la sémantique de vos interfaces numériques
- Standardisation du W3C et nouveautés Figma : une révolution pour la gestion des design tokens
- Optimiser son workflow design avec les tokens et les composants dynamiques sur Penpot
Articles générés via Vidiome, puis fusionnés et enrichis.
