Design system multi-marque : l'architecture de tokens qui tient à l'échelle

1. Le probleme du multi-marque

Quand un groupe gere plusieurs marques, la tentation initiale est de dupliquer : un DS par marque, chacun dans sa codebase, ses variables, ses composants. Le resultat est previsible. Six mois plus tard, vous avez six fois le meme bouton a maintenir, six rythmes de correction, et aucun moyen de pousser une fix de securite globale sans repercuter manuellement dans chaque repo.

L'alternative, c'est de partager la mecanique et de differencier la peinture. Un composant Button unique, des tokens qui savent que pour la marque A le fond est vert, pour la marque B il est bleu nuit, pour la troisieme marque il est gris anthracite. Le composant ne sait rien de tout ca, il consomme un alias : action/background. C'est l'alias qui change de valeur selon la marque active.

C'est exactement ce que permet une architecture a trois couches. Mais mal fichue, cette architecture devient vite un piege : trop de tokens, des noms incoherents, des composants qui bypassent les aliases et s'accrochent aux primitives. Voici comment l'eviter.

2. Les trois couches : primitives, semantiques, composant

Tout systeme de tokens solide repose sur une separation stricte entre ce qu'on stocke, ce qu'on signifie et ce qu'on consomme. Trois couches, trois roles, une seule direction d'aliasing : vers le bas, jamais vers le haut.

Dans Figma, ca se traduit en deux collections distinctes. La collection Primitives contient toutes les valeurs brutes, et ses variables ont le scope None : elles n'apparaissent pas dans les pickers de couleur ou de spacing. La collection Theme tokens contient les semantiques, avec des scopes adaptes (All fills pour les couleurs de fond, Text fill pour les textes, Stroke color pour les bordures).

La couche primitive est un dictionnaire. La couche semantique est une intention. C'est entre les deux que vit toute l'intelligence du systeme.

Principe de base de l'architecture de tokens

3. Les modes et themes : une collection, N identites

C'est ici que le multi-marque prend forme concretement. Dans Figma (variables V4) comme en CSS, un mode est simplement un ensemble de valeurs alternatives pour les memes alias. La collection Theme tokens peut ainsi exposer autant de modes que de marques :

• Marque A light : vert primaire, fond blanc, texte quasi-noir
• Marque A dark : meme palette, inversee sur fond #0B0B0B
• la marque B : bleu nuit dominant, accents specifiques a la marque
• 13 autres marques du groupe : chacune son mode, meme structure d'alias

Chaque mode re-mappe les semantiques vers les bonnes primitives. action/background pointe vers brand/600 en mode Marque A, vers accent/700 en mode Marque B. Les composants, eux, ne savent rien de tout ca. Ils consomment action/background et laissent le mode faire le travail.

En CSS, ca se traduit par une seule feuille de variables, surchargee par un attribut data-brand ou une classe. Aucun composant ne contient jamais #2D7D9A en dur.

4. L'aliasing : binder du semantique, jamais du primitif

C'est la regle la plus importante et la plus souvent violee. Quand un composant Figma ou un composant React bind directement une primitive, tout le systeme de theming saute. brand/500 ne reagit pas au dark mode. Il ne reagit pas au changement de marque. Il reste vert, quoi qu'il arrive.

Pour le design system, j'ai impose la regle suivante : zeo couleur brute dans un composant. Chaque fill est lie a un token semantique via setBoundVariableForPaint() dans l'API Plugin Figma, et via une var(--ds-*) en CSS. L'audit est automatise : un script parcourt tous les noeuds du ComponentSet et remonte les fills sans binding.

Cela implique aussi de distinguer les familles de tokens selon le contexte. Pour un texte standard, on utilise text/high-contrast dont le scope est Text fill uniquement. Pour un fond de card, on utilise surface/low-contrast avec le scope Frame fill. Cette specialisation des scopes evite les erreurs d'application et guide les designers naturellement vers le bon choix dans Figma.

5. Gouvernance : nommage, scopes, qui peut ajouter quoi

Un systeme de tokens sans gouvernance derive en quelques semaines. Chaque equipe ajoute ses propres tokens, les noms deviennent incoherents, et on se retrouve avec color-button-bg-hover-pressed-secondary a cote de btn/hover. Les deux font la meme chose, personne ne sait lequel est le bon.

La gouvernance repose sur trois regles simples :

• Convention de nommage stricte : categorie/variante, tout en minuscules, separateur slash. content/primary, surface/hover, border/error. Jamais de camelCase, jamais de couleur dans le nom semantique.
• Scopes explicites : chaque token declare les contextes ou il est applicable. Un token de spacing n'apparait pas dans un color picker. Un token de radius n'apparait pas dans un spacing field. Les scopes sont la premiere ligne de defense contre les mauvais usages.
• Droits d'edition differencies : les primitives sont editables uniquement par le core DS team. Les semantiques peuvent etre etendues par les brand owners, mais uniquement en ajoutant des modes sur la collection existante, pas en creant une nouvelle collection parallele.

En pratique, quand une nouvelle marque rejoint le groupe, le processus est clair : le brand owner fournit sa palette et son mapping (quelle primitive pour quel alias), le DS team cree le nouveau mode dans la collection Theme tokens, et tous les composants existants deviennent instantanement disponibles dans la nouvelle marque. Zero refonte.

6. Le passage au code : CSS vars et presets

En CSS, l'architecture se transpose directement. Les primitives sont des valeurs hardcodees dans un fichier primitives.css, charge une seule fois. Les semantiques sont des var(--ds-*) qui referencent les primitives, redefinies dans des blocs [data-brand="brand-a"], [data-brand="brand-b"], et [data-theme="dark"].

Ce qui donne en pratique :

• --ds-color-action-background vaut var(--ds-primitive-brand-600) en mode Marque A light, var(--ds-primitive-accent-700) en mode Marque B.
• En dark mode, la meme variable pointe vers une primitive plus sombre de la meme teinte.
• Les composants React et Angular consomment uniquement des var(--ds-color-*) dans leur CSS. Ils ne savent pas quelle marque est active.

Le changement de theme se fait en un seul attribut sur le html ou un conteneur parent : data-brand="brand-b". Toutes les variables cascadent. Dans un design system qui sert un portail multi-tenant, c'est la seule solution propre pour switcher d'identite sans recharger le JavaScript.

Pour les presets, chaque marque embarque un fichier brand-a.css minimal qui surcharge les semantiques. C'est ce fichier que les equipes produit importent. Jamais les primitives directement, jamais les composants sans leurs tokens.

Conclusion

Une architecture de tokens bien construite est invisible. Les designers composent dans Figma en changeant de mode, les developpeurs changent un attribut HTML, et la marque bascule sans friction. Ce qui permet ca, c'est la rigueur des trois couches et le respect absolu de l'aliasing semantique.

La dette se cree toujours au meme endroit : un composant qui bypasse les alias pour consommer une primitive, ou une equipe qui cree une collection parallele parce que la gouvernance n'etait pas claire. Ces petits raccourcis deviennent vite des murs.

Le systeme que j'ai mis en place sur un grand design system sert aujourd'hui 15 modes de marque, dark et light, avec un seul jeu de composants React et Angular. Chaque nouvelle marque est une affaire de deux jours de configuration, pas six mois de refonte.