Depuis quelques années, les design tokens se sont imposés dans les design systems comme un outil quasi incontournable. Mais avec l’arrivée en octobre 2025 de la première spécification stable du W3C Design Tokens Community Group (DTCG 2025.10), ils passent un cap décisif : celui d’un véritable standard ouvert, pensé pour la production et l’interopérabilité à grande échelle.
Cette normalisation change profondément la manière dont les équipes conçoivent, documentent et implémentent l’interface de leurs produits. Là où chaque outil et chaque organisation définissait ses propres formats et conventions, les design tokens deviennent désormais un langage commun entre designers, développeurs et outils, ouvrant la voie à un web plus cohérent, plus maintenable et plus facile à faire évoluer.
Les design tokens, brique fondamentale des design systems modernes
À l’origine, le concept de design tokens a été introduit par l’équipe design system de Salesforce (Jon & Jina). L’idée est simple : capturer les décisions de design , couleurs, espacements, typographies, rayons de bordure, ombres, animations , sous forme d’unités atomiques, stables et nommées. Ces unités deviennent alors les « pièces indivisibles » du design system, réutilisables partout dans le produit.
Dans une interface, cela se traduit par des noms comme color.brand.primary, spacing.l ou font..sm qui remplacent les valeurs brutes (#0055FF, 16px, etc.). Les maquettes, les bibliothèques de composants et le code se synchronisent autour de ce langage commun : si l’on change la valeur d’un token de couleur, toutes les occurrences de ce token se mettent à jour, du design jusqu’au front-end.
Les design tokens jouent ainsi le rôle de « single source of truth » pour les décisions de design. Au lieu de disperser styles et variables dans des fichiers Figma, des feuilles de style, des composants front et des documents de référence, les organisations cherchent à tout centraliser dans une base de tokens, puis à la propager dans les différents environnements. La standardisation DTCG vient précisément répondre à ce besoin de consolidation.
La spécification W3C DTCG 2025.10 : vers un format commun et stable
Le 28 octobre 2025, le W3C Design Tokens Community Group annonce la première version stable de la « Design Tokens Specification (2025.10) ». Cette version est présentée comme un format « vendor-neutral » et « production-ready » pour partager les décisions de design entre outils et plateformes. Concrètement, il s’agit d’un vocabulaire JSON standardisé pour décrire les tokens de couleur, typo, espacements, motion, bordures, ombres, dégradés, etc.
L’objectif affiché de la spec est clair : débloquer l’interopérabilité entre les outils de design, les codebases et les plateformes. Aujourd’hui encore, chaque éditeur propose son propre mécanisme d’export de styles ou de variables. Le DTCG vise à casser ces silos en définissant un format que tous peuvent comprendre et produire. On ne parle plus d’un simple « bon document de référence », mais bien d’une grammaire commune pour les pipelines design-to-code.
La spécification DTCG 2025.10 s’inscrit dans une trajectoire de maturité : après plusieurs « Editor’s Drafts », elle formalise les grandes briques nécessaires à l’usage en production, notamment le typage des tokens, les conventions de structure, et des mécaniques avancées comme les aliases et les groupes. C’est cette stabilisation qui permet aujourd’hui de dire que les design tokens sont en train de devenir un standard de facto du design web.
Un vocabulaire partagé : grammaire JSON, $type et typage standardisé
Un des apports majeurs du travail du DTCG est l’introduction d’une grammaire unifiée pour décrire les tokens. Dans les dernières versions de travail, on voit apparaître des propriétés préfixées par $ comme $type, $value, $description ou $extensions. Ce préfixe a pour rôle de distinguer clairement les métadonnées de la structure des tokens de leurs valeurs métier ou de leurs clés de nommage.
Le typage standardisé est un autre pilier de la spec. Les types de base incluent, entre autres, color, fontFamily, fontWeight, dimension, border, shadow, gradient et typography. En harmonisant ce vocabulaire, la spec permet aux outils et aux pipelines de comprendre ce que représente réellement un token, au-delà de sa simple valeur. Un token de type color ne se traite pas de la même manière qu’un token de type shadow ou transition.
Pour les équipes produit, cette normalisation change la donne. Elle simplifie l’écriture de transformateurs (build scripts, plugins, CI/CD) capables de convertir un même fichier de tokens en variables CSS, en JSON pour une app native, en variables Android ou iOS, ou encore en documentation lisible. En alignant les pipelines sur un langage et des types communs, on réduit considérablement la surface de friction entre design, front-end et back-end, et l’on sécurise la cohérence à long terme.
Interopérabilité et theming : un standard pensé pour le multi‑outils et le multi‑marques
Dès ses premiers documents, le DTCG souligne que la finalité de la spécification est de permettre un theming robuste et interopérable entre outils de design, design systems et codebases. Le format JSON retenu a été pensé pour couvrir des cas d’usage complexes : multi‑marques, dark mode, variations contextuelles selon la plateforme ou l’appareil, personnalisations par client, etc.
Pour cela, la spec introduit et affine plusieurs mécanismes structurants : les « groups », qui permettent d’organiser les tokens en ensembles logiques et hiérarchisés, et les « aliases », qui permettent à un token d’en référencer un autre. Ces briques ouvrent la voie à des architectures où l’on peut définir un socle de tokens « core » (par exemple les primitives de couleur ou de typographie), et décliner ensuite des thèmes spécifiques en les redéfinissant par alias.
En septembre 2025, le DTCG publie un appel à commentaires sur un nouveau module « Resolver » ainsi que sur les évolutions des « groups » et « aliases ». Le Resolver a pour vocation de décrire comment les références (aliases) doivent être évaluées et enchaînées, afin de permettre des scénarios de theming avancés : résolution conditionnelle selon le thème, priorités entre sources de tokens, héritage entre marques. Pour les grandes organisations, ces capacités sont essentielles pour gérer des portfolios de produits multi‑marques sans multiplier les forks de design system.
Une adoption massive par les éditeurs : convergence entre outils de design et code
Si la spécification DTCG a autant de poids, c’est aussi parce qu’elle est portée par un large écosystème d’éditeurs et d’acteurs du design system. Dès 2021‑2022, les principaux outils comme Figma, Sketch, Adobe XD, Framer, Zeplin, Zeroheight ou UXPin, ainsi que des initiatives comme Google Material Design, participent aux travaux du groupe et se déclarent favorables à l’émergence d’un standard commun.
Pour ces acteurs, l’enjeu est double. D’un côté, ils doivent répondre aux attentes de leurs utilisateurs, qui veulent pouvoir extraire, importer, synchroniser et versionner leurs design tokens sans se retrouver enfermés dans un format propriétaire. De l’autre, ils voient dans la spec DTCG l’opportunité de simplifier le passage du design vers le code, en proposant des exports et des intégrations standardisés avec les environnements de développement.
Les comptes‑rendus du DTCG insistent d’ailleurs sur un objectif explicite : rendre la collaboration entre design et développement « cheaper, faster, more integrated ». Un format commun de tokens réduit les conversions manuelles, les divergences de styles et la duplication des efforts. Les développeurs gagnent du temps sur l’intégration, les designers conservent la maîtrise des décisions visuelles, et les design systems peuvent enfin s’outiller avec des chaînes automatisées, partagées entre outils.
Architecture de tokens à grande échelle : de la marque aux produits
La montée en puissance des design tokens ne se limite pas au format technique. En parallèle du DTCG, d’autres groupes du W3C se sont penchés sur les enjeux d’architecture à grande échelle. Le Brand Identity Tokens Community Group, par exemple, a travaillé entre 2022 et 2023 sur une « Design Tokens Architecture Specification » destinée aux organisations multi‑marques complexes.
Ce travail porte sur la manière de structurer les tokens au‑delà du simple fichier plat : taxonomies, catégories, clusters, tiers (layers) de tokens, etc. Comment distinguer les tokens de marque (logo, palette, tonality) des tokens de produit (composants, patterns) ou des tokens de plateforme (web, iOS, Android) ? Comment modéliser les relations entre une marque globale, des sous‑marques et des déclinaisons régionales sans dupliquer inutilement les valeurs ?
Ces réflexions indiquent le degré de maturité atteint par le sujet. On n’est plus uniquement dans la question « comment stocker une couleur ? », mais dans « comment modéliser l’identité de marque à travers un système de tokens structuré, versionné et gouverné ? ». Pour les grandes organisations, c’est un enjeu stratégique : la manière dont les tokens sont architecturés conditionne la capacité à faire évoluer l’identité, à lancer de nouvelles marques ou à harmoniser un parc applicatif hétérogène.
Gouvernance et pérennité : les design tokens comme standard d’écosystème
Un autre signal fort de la montée en standardisation des design tokens réside dans la gouvernance mise en place par le DTCG. En octobre 2025, le groupe propose un cadre décisionnel formalisé, définissant les rôles de Contributor, Editor, Module Lead et Chair. Ce dispositif vise à clarifier qui peut proposer des changements, comment les arbitrer et comment coordonner le travail sur les différents modules de la spec.
Cette structuration rapproche le DTCG des pratiques d’autres standards web soutenus par le W3C. Elle garantit une plus grande transparence sur l’évolution de la spécification, une meilleure représentation des différents acteurs de l’écosystème, et une capacité à maintenir la spec dans le temps. Pour les organisations qui s’engagent à fond dans les design tokens, c’est un gage de confiance : les décisions ne sont pas prises arbitrairement par un seul fournisseur.
Cette gouvernance modulaire (par module de spécification) est également clé pour accompagner l’évolution du standard. Les besoins en theming, en accessibilité, en typographie ou en motion ne progressent pas tous au même rythme. En structurant le travail par briques, le DTCG peut faire avancer certaines parties plus rapidement, tout en conservant un noyau stable sur lequel les écosystèmes de tooling et de librairies peuvent se reposer.
Ce que cela change concrètement pour le design web
Pour les équipes produit, la stabilisation de la spécification DTCG 2025.10 marque un point de bascule. Là où, hier encore, la mise en place de design tokens nécessitait souvent de bricoler son propre format, ses propres scripts de build et ses propres conventions, il devient désormais possible de s’appuyer sur un standard reconnu. Cela signifie moins de travail d’infrastructure et davantage de focus sur le design et l’expérience utilisateur.
Les flux de travail design-to-code peuvent être rationalisés : un même fichier de tokens JSON conforme à la spec peut être lu par un outil de design, un pipeline front-end et une plateforme documentaire. La synchronisation entre maquettes et code devient moins fragile, car elle ne dépend plus uniquement d’exports manuels ou de plugins propriétaires. Les équipes peuvent segmenter clairement la responsabilité : les designers possèdent les tokens ; les développeurs consomment ces tokens via des APIs, des packages ou des builds automatisés.
Enfin, la montée en standard permet aux organisations de mutualiser leurs efforts. Les communautés open source, les éditeurs d’outils et les grandes entreprises peuvent collaborer sur des transformations, des lint rules, des visualiseurs ou des éditeurs de tokens qui s’appuient sur la même base. À terme, cela devrait conduire à un écosystème riche en bonnes pratiques, en modèles d’architecture de tokens et en patterns de theming, au bénéfice de tout le design web.
Les design tokens ont commencé comme une idée pragmatique pour rendre les design systems plus robustes et plus faciles à maintenir. Avec la publication de la version stable de la Design Tokens Specification (2025.10) du W3C DTCG, ils deviennent le socle d’un standard ouvert, interopérable et gouverné, qui dépasse largement le cadre d’un seul outil ou d’un seul fournisseur.
Dans ce contexte, considérer les design tokens comme une simple « bonne pratique » facultative n’est plus tenable. Ils s’imposent progressivement comme la colonne vertébrale des interfaces : une source unique de vérité, partagée entre design et développement, entre marques et plateformes. Pour les organisations qui veulent un design web cohérent, scalable et durable, le moment est venu d’embrasser pleinement ce standard, d’outiller leurs équipes autour de lui et de penser leur design system à travers le prisme des tokens.