Depuis deux ou trois ans, le mot design tokens est partout. Dans les offres d’emploi, dans les noms de plugins Figma, dans les présentations de design systems, sur les CV. À force d’être répété, il a fini par perdre une bonne partie de son sens. Beaucoup de gens qui parlent de tokens parlent en fait de variables CSS qu’ils ont juste renommées.
Ce n’est pas un détail vocabulaire. Le vrai sujet des design tokens, c’est la construction d’une identité visuelle qui tient sur plusieurs surfaces : un site, une vitrine, un blog, une appli, un email, une plaquette PDF. Tant qu’on confond tokens et variables CSS renommées, on rate cet usage. Et c’est dommage, parce que c’est probablement la seule vraie raison d’en faire.
Ce que le mot voulait dire au départ
L’idée des design tokens, telle qu’elle a été formulée par les équipes de Salesforce vers 2014 puis reprise par le W3C, tient en une phrase : une décision de design, isolée, nommée, et stockée dans un format neutre, pour pouvoir être consommée par plusieurs cibles (CSS, iOS, Android, documentation, outils de design).
Le point intéressant n’est pas le format, pas non plus le fait d’avoir une variable. C’est la décision elle-même.
Prenons un exemple. Quand vous écrivez :
:root {
--color-blue-500: #3B82F6;
}
Vous avez créé une variable. Elle nomme une couleur. C’est utile, mais ce n’est pas un token au sens fort. Personne, en regardant ce nom, ne sait pourquoi cette couleur existe ni où elle doit s’appliquer.
Maintenant :
:root {
--color-link-active: var(--color-blue-500);
--color-feedback-error: #B91C1C;
}
On commence à voir une décision : le lien actif du site est de cette couleur, l’erreur est de cette couleur. La valeur peut changer demain, le rôle reste. Voilà ce qui sépare une palette d’un système.
Règle de pouce : si le nom de votre variable décrit son apparence (bleu, gros, arrondi), ce n’est pas un token. Si le nom décrit son rôle (lien, accent éditorial, erreur), vous tenez un début de système.
La vraie raison d’en faire : porter une identité
Les tokens prennent leur sens quand on essaie de tenir une identité de marque cohérente à travers plusieurs supports qui n’ont, techniquement, presque rien en commun.
L’exemple le plus connu est Material Design de Google. Ce qu’on appelle communément « Material » n’est pas un thème ni une bibliothèque de composants : c’est, à la base, un système de tokens (md.sys.color.primary, md.sys.color.surface, md.sys.shape.corner.medium, etc.) qui encode l’identité visuelle Material. N’importe quel produit Google peut piocher dans ce système et ressortir reconnaissable. Le système ne range pas les couleurs, il transporte une identité d’un produit à l’autre.
Côté français, on cite souvent le système Vertex de Decathlon. Il faut savoir ce qu’on va y chercher : c’est avant tout une réussite de système, pas un manifeste graphique. L’identité visuelle Decathlon n’est pas spectaculaire, et ce n’est pas là que Vertex impressionne. Ce qui frappe, c’est l’ingénierie : tokens, composants, documentation, gouvernance, propagation à des sites e-commerce, des applis, des bornes magasin, des affichages physiques, avec une vraie discipline pour que chaque équipe n’ait pas à redécider ce qu’est « l’orange Decathlon » ou « l’espacement de titre ». Très bien fait pour ce que ça vise, à condition de regarder le bon plan.
À une autre échelle, sur The Interstice, j’ai cinq sites techniquement disparates : du HTML/CSS pur, du Next.js, un thème WordPress, un blog Astro, une landing isométrique. Aucun framework partagé. Ce qui fait que ces cinq sites se lisent comme un même projet, c’est un fichier tokens.css unique, propagé par un petit script Python, qui définit l’encre, le crème, l’ocre, le terre, la signature « entre le pixel et l’idée ». Les composants changent, le moteur change, l’identité non.
L’usage qui justifie l’effort est là. Pas ranger ses couleurs : tenir une promesse visuelle d’un endroit à l’autre.
Le token-washing
Le piège le plus fréquent, c’est ce que j’appellerais le token-washing. Vous prenez votre fichier variables.css existant, vous le renommez tokens.css, vous changez quelques préfixes, et vous annoncez que vous avez « adopté les design tokens ». Tout le monde a un peu fait ça, moi le premier.
Le problème n’est pas le fichier. Le problème, c’est que rien n’a bougé sur le fond : les noms restent visuels, le système reste une palette, et le jour où vous voulez changer la couleur d’accent globalement, vous devez encore faire un Find & Replace dans tout le code parce que --bleu-principal est utilisé pour des choses qui n’ont rien à voir (un lien, un bouton, une bordure de carte, un état actif de menu).
Renommer ne suffit pas. Ce qui change un système, c’est la discipline sémantique : refuser de réutiliser un token visuel directement, et passer systématiquement par une couche d’intention.
Les deux étages d’un système qui tient
Il y a typiquement deux étages.
Le premier, ce sont les primitives : les valeurs brutes. La palette de couleurs, les tailles de police, les espacements, les rayons de bordure. Les noms sont descriptifs (color-ocre-clair, space-4, radius-md). Ces tokens-là ne sont jamais utilisés directement dans les composants.
Le deuxième étage, ce sont les tokens sémantiques : ils nomment une intention et pointent vers une primitive. color-link, color-link-hover, color-background-editorial, color-feedback-error. Les composants ne consomment que ces tokens-là.
/* Étage 1 : primitives (ne pas utiliser directement) */
:root {
--color-encre: #1C1A17;
--color-creme: #F5F0E8;
--color-ocre: #C4913A;
}
/* Étage 2 : sémantique (ce que les composants utilisent) */
:root {
--text-default: var(--color-encre);
--bg-editorial: var(--color-creme);
--link-active: var(--color-ocre);
}
Avec cette séparation, deux choses deviennent possibles. D’abord, changer la valeur d’une primitive sans casser le sens (passer d’un ocre #C4913A à #B98428 n’affecte que les choses qui sont censées être ocres, partout, d’un coup). Ensuite, faire varier la sémantique selon le contexte : un mode sombre se construit en redéfinissant les tokens sémantiques sans toucher aux primitives.
Si vous n’avez qu’un étage et que vos composants tapent dans les noms visuels, vous avez une palette bien rangée, pas un système.
Le test qui sépare le marketing de la réalité
Comment savoir si un système de tokens fonctionne, et pas juste sur le papier ? Une jauge suffit : changer la valeur d’un token primitif doit avoir un effet propre et prévisible, partout, sans surprise.
Si vous changez --color-ocre et que la moitié du site reste sur l’ancienne couleur parce que quelqu’un a hardcodé #C4913A à trois endroits, vous n’avez pas de système. Si vous le changez et qu’un bouton qui n’aurait pas dû changer devient soudain ocre, vous n’en avez pas davantage : votre sémantique est cassée.
C’est un test ennuyeux à faire, mais c’est le seul qui dit la vérité.
Le bon dosage d’outillage
Autour des tokens, une industrie entière s’est construite : Style Dictionary, Tokens Studio pour Figma, Specify, Supernova, Knapsack, etc. Tous ces outils sont valables dans leur contexte. Mais ils ne sont pas le sujet.
Pour la plupart des projets (un site, une vitrine, un blog, un portfolio, un petit système multi-sites), vous n’avez besoin de rien d’autre qu’un fichier tokens.css et d’une convention claire de nommage. Ajouter un pipeline JSON → Style Dictionary → CSS pour quinze couleurs, c’est se créer une infrastructure dont le coût d’entretien dépasse le bénéfice. C’est typiquement le moment où le mot à la mode commence à coûter cher.
L’outillage devient pertinent à partir du moment où vous avez :
- plusieurs cibles techniques à servir avec les mêmes décisions (web + iOS + Android + emails) ;
- plusieurs équipes qui modifient le système en parallèle ;
- plusieurs marques ou plusieurs thèmes à dériver d’une base commune.
Tant qu’aucune de ces conditions n’est remplie, un fichier CSS bien tenu, lu et accepté par tout le monde, fait mieux le travail que n’importe quel outil sophistiqué.
À retenir : la complexité de l’outillage doit suivre la complexité du problème, pas l’inverse. Un système surdimensionné se fait abandonner.
Une note sur le contraste
Un point que les présentations marketing oublient presque toujours : un token de couleur n’est pas une valeur isolée. Il vit en relation avec d’autres tokens, et certaines de ces relations sont contraintes par l’accessibilité.
Sur le système qui sert The Interstice (cinq sites partagent le même fichier tokens.css), j’ai un gris secondaire pensé pour le texte sur fonds sombres. Il a un bon contraste sur encre, sur terre nuit, sur les footers profonds. Sur le fond crème éditorial, le ratio tombe à 2,8:1, en-dessous du minimum WCAG AA. Le token existe, sa valeur est correcte dans son contexte, mais son usage doit être restreint. Ce genre de contrainte ne se voit pas dans le nom du token. Elle vit dans la documentation à côté.
Un système de tokens qui tient n’est donc pas juste un fichier. C’est un fichier plus les règles d’emploi de chaque entrée. Sans la deuxième moitié, on construit une jolie palette qui produit, en pratique, des interfaces inaccessibles.
Une lecture pour aller plus loin
Pour qui veut creuser, il y a un bon point d’entrée en français : The Design Tokens Book , porté par Frontguys, librement téléchargeable en PDF, avec une version imprimée et une série de meetups DesignOps associés. On y trouve à la fois la théorie, des retours d’expérience d’équipes, des ateliers et des points de vue d’experts. Si l’article ci-dessus vous a donné envie de passer à la pratique, c’est probablement la première étape à faire.
Quand un système de tokens est bien fait, on l’oublie. Ce silence est le vrai signe qu’il fonctionne.