Gérer un seul produit avec un seul Design System est déjà un défi. Mais quand une organisation porte plusieurs marques, sous-marques ou déclinaisons thématiques, la complexité change d’échelle.
La tentation est grande de dupliquer les bibliothèques : une par marque, chacune avec ses couleurs, ses typographies, ses composants. Le résultat est prévisible : des systèmes qui divergent, une maintenance qui explose et une cohérence qui s’effrite.
Il existe pourtant une approche plus robuste : construire un système unique dont seules les valeurs changent selon le contexte. C’est exactement ce que permettent les Design Tokens et les Variables, à condition de bien les architecturer.
Design Tokens : rappel des fondamentaux
Les Design Tokens sont des valeurs de design nommées et réutilisables (couleurs, typographies, espacements, rayons de bordure, durées d’animation) qui remplacent les valeurs codées en dur par des références abstraites partagées entre design et développement. Ils constituent la source unique de vérité pour toutes les décisions visuelles d’un système.
Leur architecture repose sur trois niveaux : les tokens primitifs stockent les valeurs brutes, les tokens sémantiques leur donnent du sens (« couleur de fond par défaut », « texte secondaire »), et les tokens composants appliquent ces décisions à des éléments précis. Chaque niveau pointe vers le précédent : modifier un primitif se répercute automatiquement dans toute la chaîne. C’est ce mécanisme qui rend le multi-marques possible. Pour aller plus loin sur les fondamentaux, notre article Design Tokens couvre le sujet en détail.
Variables et Modes dans Figma : le levier natif pour le multi-marques
Ce que les Variables Figma changent concrètement
Les Variables remplacent les styles statiques par des valeurs dynamiques applicables aux couleurs, aux nombres, aux chaînes de texte et aux booléens. Elles peuvent pointer les unes vers les autres via un système d’aliasing, ce qui permet de reproduire l’architecture primitifs, sémantiques et composants directement dans Figma. Les modifications se propagent instantanément à tous les composants qui consomment la variable.
Les Modes : basculer d’une marque à l’autre sans dupliquer
Un Mode est un jeu de valeurs alternatif pour une même collection de variables. Le cas d’usage classique est le light/dark, mais les Modes servent aussi à gérer plusieurs marques dans une seule bibliothèque.
Chaque marque devient un Mode : mêmes noms de variables, valeurs différentes. Le basculement s’opère en un clic sur le canvas, sans toucher aux composants.
Structurer ses collections pour un système multi-marques
La collection Primitifs stocke la palette de couleurs, l’échelle typographique et les espacements, avec un Mode par marque.
La collection Sémantiques regroupe les tokens d’usage qui pointent vers les primitifs et restent communs à toutes les marques.
Une collection Composants optionnelle peut venir compléter l’ensemble pour les tokens spécifiques à certains éléments. Les Modes peuvent aussi se combiner : marque × light/dark, marque × responsive.
Concevoir des composants « brand-agnostic »
Le principe : la structure reste, les valeurs changent
Un bouton, une carte, un formulaire ne doivent jamais contenir de valeur codée en dur.
Chaque propriété visuelle (couleur, typographie, espacement, rayon, ombre) doit être pilotée par un token sémantique.
Quand le Mode change, le composant s’adapte automatiquement sans aucune intervention manuelle.
Ce que cela permet en pratique
Une seule bibliothèque de composants suffit pour toutes les marques. Les maquettes multi-marques sont réalisables en quelques clics, sans duplication de fichiers.
La maintenance s’en trouve drastiquement réduite : corriger un composant le corrige pour l’ensemble des marques simultanément.
Les limites à anticiper
Certaines marques peuvent nécessiter des composants spécifiques qui n’existent pas dans le tronc commun.
Les différences structurelles entre marques (layouts, navigation, densité d’information) ne se résolvent pas uniquement par les tokens.
Il faut définir clairement ce qui est mutualisé et ce qui reste propre à chaque marque avant de commencer.
Nommer ses tokens : la convention qui conditionne tout le reste
Pourquoi le naming est un enjeu stratégique
Un mauvais nommage rend le système inutilisable au-delà de l’équipe qui l’a créé. Le nom d’un token doit exprimer son rôle, pas sa valeur : « color-text-primary » plutôt que « blue-500 ».
Dans un contexte multi-marques, nommer par la valeur rend le token incohérent dès que la marque change.
Une convention lisible pour designers et développeurs
La taxonomie recommandée suit la logique catégorie / usage / variante / état (ex : color/background/primary/hover).
Elle doit s’aligner avec les conventions de nommage du code (kebab-case, camelCase) dès la conception des tokens.
La convention doit être documentée et accessible à toutes les parties prenantes, sans exception.
Du design au code : synchroniser les tokens entre Figma et le développement
L’enjeu : une source de vérité partagée
Les tokens définis dans Figma doivent correspondre exactement à ceux utilisés dans le code. Toute désynchronisation crée de la dette technique et des incohérences visuelles.
Le token doit être le langage commun entre designers et développeurs, pas un artefact design isolé.
Les outils de la chaîne de synchronisation
Tokens Studio (ex-Figma Tokens) permet de gérer des tokens avancés dans Figma et de les exporter en JSON. Style Dictionary d’Amazon transforme ensuite ces fichiers JSON en variables CSS, SCSS, Swift, Kotlin, etc.
L’API REST Figma et l’API Plugin permettent de lire et d’écrire les variables programmatiquement. Le workflow idéal : Figma, export JSON, transformation, variables CSS, déploiement.
Versioning et gouvernance des tokens
Les tokens doivent être traités comme du code : versioning sémantique, changelog, revue par les pairs.
Il faut définir qui peut créer, modifier ou supprimer un token, et communiquer les mises à jour aux équipes produit pour éviter les ruptures silencieuses.
Retours d’expérience : ce que les organisations multi-marques ont appris
Les bénéfices constatés
Une seule bibliothèque à maintenir au lieu d’une par marque réduit significativement la charge de maintenance.
L’ajout d’une nouvelle marque se fait en quelques jours au lieu de plusieurs semaines. La cohérence inter-marques s’améliore mécaniquement, car les composants partagent la même logique.
Le dark mode, le responsive et l’accessibilité (contraste élevé, daltonisme) se gèrent avec le même mécanisme de Modes.
Les pièges à éviter
Vouloir tout mutualiser est la première erreur : certaines différences entre marques sont structurelles, pas seulement cosmétiques. Sous-estimer le travail de naming est la deuxième : une convention bancale au départ coûte très cher à corriger.
Négliger la documentation est la troisième : sans guide d’usage clair, les contributeurs contournent le système. Oublier les développeurs dans la conception de l’architecture tokens est la quatrième : le système doit être pensé design et code dès le départ.
Un système, plusieurs identités : la promesse tenue des tokens
Les Design Tokens et les Variables Figma rendent possible ce qui semblait contradictoire : unifier la structure tout en préservant la singularité de chaque marque. L’architecture en trois niveaux (primitifs, sémantiques, composants) est le socle de cette flexibilité. Les Modes permettent de basculer d’une identité à l’autre sans multiplier les bibliothèques ni les composants.
Mais cette approche ne fonctionne que si elle est portée par une convention de nommage solide, une gouvernance claire et une synchronisation rigoureuse entre design et code. Le multi-marques n’est pas un ajout tardif : c’est une décision d’architecture qui se prend dès la fondation du Design System.
