Deux marques, deux sites, et au bout de quelques mois deux boutons « Valider » qui n'ont plus la même hauteur, trois gris presque identiques et un formulaire refait de zéro parce que personne ne savait que l'autre équipe en avait déjà un. Un design system Figma partagé règle ce problème, à une condition : décider d'abord ce qui est commun aux marques et ce qui leur appartient, sinon on obtient des marques identiques ou une bibliothèque que personne n'ose toucher.
J'ai conçu le design system Figma de Moonworkers, ma propre entreprise, en partant des utilisateurs (personas, wireframes, puis composants). J'ai aussi construit pour un client un design system Figma commun à plusieurs marques. Voici la méthode que j'en ai tirée, ce que Figma permet aujourd'hui, et ce que ça coûte vraiment.
01Ce qu'un design system Figma contient, et ce qu'il n'est pas
Nielsen Norman Group, dans son article Design Systems 101, décrit un design system comme un ensemble de standards pour gérer la conception à grande échelle, avec des composants et des modèles réutilisables. Il distingue trois pièces : le guide de style (couleurs, typographie, ton), la bibliothèque de composants et la bibliothèque de modèles (mises en page, gabarits de pages).
Dans Figma, la bibliothèque est le fichier publié qui contient les composants, les styles et les variables. Quand quelqu'un publie une mise à jour, Figma la propose dans chaque fichier qui utilise ces éléments, et chacun l'accepte ou l'ignore.
La bibliothèque n'est donc qu'une partie du design system. Le reste, ce sont des règles : quand utiliser tel composant, comment nommer, qui décide d'ajouter une variante. Sans ces règles, le risque est connu : chacun détache l'instance, la modifie dans son coin, et la bibliothèque devient décorative.
02Plusieurs marques : séparer ce qui est commun de ce qui change
La question à trancher en premier n'est pas technique. Il faut lister, marque par marque, ce qui doit rester différent : la couleur principale, souvent la typographie des titres, parfois l'arrondi des coins, le ton des messages. Tout le reste a vocation à être commun : la grille, les espacements, le comportement d'un champ en erreur, l'accessibilité d'un bouton.
Pour ranger ça, je travaille en trois couches :
- Les valeurs brutes : la palette complète, l'échelle des espacements, les tailles de texte. Elles n'ont pas de sens par elles-mêmes (« bleu 600 », « espace 4 »).
- Les rôles : « couleur d'action », « fond de carte », « texte secondaire ». Chaque rôle pointe vers une valeur brute.
- Les composants : ils n'utilisent que des rôles, jamais une valeur brute ni une couleur en dur.
Une marque, dans ce modèle, c'est simplement un autre jeu de correspondances entre les rôles et les valeurs. Le bouton ne sait pas pour quelle marque il est dessiné : il demande la « couleur d'action » et reçoit la bonne.
C'est la logique des design tokens. Le groupe communautaire du W3C sur les design tokens a publié le 28 octobre 2025 la première version stable de sa spécification. Son module Format définit un token comme une information associée à un nom lisible, au minimum une paire nom et valeur, et prévoit les alias : un token peut pointer vers un autre, écrit entre accolades. Les rôles, ce sont ces alias.
J'y tiens pour une raison qui vient de l'intégration plutôt que du design. Sur un projet, deux outils n'utilisaient pas la même unité, centimètres d'un côté, millimètres de l'autre, et tout un rendu s'est retrouvé déformé. Depuis, ma règle est que la donnée de référence est explicite et écrite à un seul endroit. Un design system multi-marques applique cette règle aux couleurs et aux espacements.
03Le ranger dans Figma : bibliothèque, variables, modes et collections étendues
Dans Figma, les rôles deviennent des variables, regroupées en collections. Les modes permettent à une même collection de porter plusieurs jeux de valeurs : clair et sombre, contraste renforcé, tailles d'écran. Un objet en mode « Auto » prend le mode de son parent, ce qui permet de basculer une page entière d'un coup. Le nombre de modes par collection dépend de votre offre.
Pour plusieurs marques, la solution la plus simple est un mode par marque. Elle tient tant que chaque marque n'a pas elle-même plusieurs modes : dès qu'il faut une marque A en clair et en sombre, puis une marque B en clair et en sombre, un seul axe de modes ne suffit plus.
C'est pour ce cas que Figma a ajouté les collections étendues. Une collection parente porte la structure des variables et des modes. Chaque marque en est une extension, qui hérite de tout et ne surcharge que ce qui change. Une variable non surchargée suit automatiquement les mises à jour du parent. La fonction est réservée à l'offre Enterprise, ce qui compte dans la décision.
Extensions locales ou dans des fichiers séparés
Dans sa présentation à Schema by Figma 2025, dont j'ai lu la transcription, Chad Bergman explique qu'on peut définir les extensions dans le même fichier que la collection parente, ou dans des fichiers séparés que chaque équipe de marque possède. Dans le même fichier, les mises à jour se propagent tout de suite et la maintenance reste centralisée. Dans des fichiers séparés, chaque équipe expérimente librement, mais les mises à jour deviennent plus difficiles à publier.
Figma donne une règle empirique : jusqu'à 10 marques, tout dans la même bibliothèque ; au-delà, des fichiers séparés. La même présentation annonce l'import et l'export natifs des variables au format de la spécification du W3C, ce qui ouvre la voie à des tokens partagés avec le code.
04La méthode que je suis, étape par étape
Avant d'ouvrir Figma
- Faire l'inventaire des écrans existants de chaque marque et relever les doublons : combien de boutons, de gris, de tailles de titre différents.
- Écrire la liste de ce qui doit rester propre à chaque marque, et la faire valider par les personnes qui portent ces marques. Une ligne par élément, avec la raison.
- Nommer les rôles avec les développeurs, pour que la « couleur d'action » porte le même nom dans Figma et dans le code.
Dans Figma
- Créer les valeurs brutes, puis les rôles qui pointent vers elles, pour une seule marque d'abord.
- Reprendre les composants pour qu'ils n'utilisent que des rôles. C'est l'étape la plus longue.
- Ajouter la deuxième marque, en mode ou en collection étendue, et vérifier chaque composant dans les deux marques, côte à côte, au même niveau de finition.
- Publier la bibliothèque avec une note de version, puis annoncer qui valide les demandes de changement.
L'étape 6 est celle que j'ai apprise sur les maquettes : quand on montre plusieurs pistes au même niveau de finition, la discussion compare enfin des choix, et j'en parle dans l'article sur le prototype cliquable avant le développement. Mettre les marques côte à côte révèle aussi le rôle mal nommé, celui qui marche pour une marque et casse l'autre.
Ce site applique la même idée à petite échelle. Je l'ai construit moi-même, et le contenu s'y affiche en vert phosphore parce qu'une seule variable de couleur est redéfinie dans la zone de contenu, alors que les titres et la navigation gardent le blanc. Un composant, deux contextes, une seule valeur à changer.
05Ce que ça coûte, et quand je ne le ferais pas
Un design system se maintient, et c'est là que la plupart s'abîment. L'article de Nielsen Norman Group recommande au minimum un designer d'interaction, un designer visuel et un développeur pour le faire vivre, et note qu'il vaut surtout la peine quand l'entreprise prévoit des années de travail de conception reproductible. J'en tire une règle simple : pas de design system sans une personne nommée qui décide des changements, sinon la bibliothèque prend du retard sur les sites.
Je ne le ferais pas pour un prototype ou une campagne ponctuelle, ni quand les marques n'ont presque rien en commun : forcer un socle partagé produit alors des composants pleins d'exceptions. Les collections étendues ne règlent pas tout non plus. Elles demandent l'offre Enterprise, et la présentation de Figma prévient que les modes déjà appliqués dans les fichiers repassent par défaut après la migration : il faut les réappliquer.
Dernière limite : Figma n'est qu'une moitié. Si les rôles n'existent pas aussi dans le code, les marques divergeront quand même, simplement plus tard. C'est le même problème que dans une spécification d'intégration : tant que les deux côtés ne lisent pas le même document, chacun fait juste dans son coin.
06Par où commencer lundi
Prenez deux écrans comparables, un par marque, par exemple la page de contact. Comptez les couleurs, les tailles de texte et les composants qui diffèrent. Écrivez à côté de chaque différence si elle est voulue ou accidentelle. Cette liste vous dira si un design system partagé vous fera gagner du temps, et vous donnera la première version de vos rôles.
C'est le genre de chantier que je mène en mission courte : un diagnostic de l'existant, la structure posée en direct avec l'équipe, puis une transmission documentée pour que la bibliothèque vive sans moi. Les règles écrites plutôt que les corrections à la main, c'est aussi ce qui fait tenir mes machines de contenu. Si vous voulez en parler, mes services décrivent comment je travaille.