Theming dans Figma : le multi-marques ne demande plus de dupliquer tes collections (ce que Schema 2025 a changé)

Les variables ont remplacé les styles — et voici pourquoi

Depuis leur introduction en 2023, les variables Figma ont transformé la façon de concevoir un système de design. Avant, on dépendait des styles pour gérer couleurs, typographies et effets. Les variables vont bien plus loin : elles stockent quatre types de valeurs — Color, Number, String et Boolean — réutilisables dynamiquement à travers tous tes fichiers. C'est cette fondation qui rend enfin possible un theming vraiment systématique dans Figma.

La vraie puissance vient de la capacité des variables à se référencer entre elles. Un token sémantique comme color/surface/primary pointe vers une primitive color/blue/600, et cette relation est préservée partout. Change la primitive, et chaque référence se met à jour instantanément — exactement le comportement que les développeurs connaissent avec les custom properties CSS. C'est ce qui fait des variables un pont naturel entre design et code. Les variables Number, elles, sont sous-estimées : en définissant une échelle de spacing cohérente (4, 8, 12, 16, 24, 32, 48) appliquée via variables au gap et au padding de l'auto-layout, tu garantis une cohérence spatiale qui exigeait auparavant une discipline héroïque de chaque designer.

Collections et modes : la mécanique du theming

Les Variable Collections organisent tes tokens par catégorie logique : une collection couleurs, une espacements, une tailles typographiques. Cette séparation est structurelle, pas cosmétique, parce que les modes s'appliquent au niveau de la collection. Si ta collection de couleurs a un mode Light et un mode Dark, tu bascules toute la palette en un clic sans toucher aux espacements.

Et les modes ne se limitent pas au clair/sombre. Je m'en sers régulièrement pour les variantes de marque en multi-brand, les niveaux de densité d'interface, les breakpoints responsive, voire les locales linguistiques. Un mode Compact réduit les espacements de 20 %, un mode Brand-B remplace la palette entière — sans dupliquer un seul composant. Mais attention : le nombre de modes dépend de ton plan, et ces limites ont bougé à Schema 2025.

Plan	Modes par collection
Free / Starter	1 (theming impossible)
Professional	10 (relevé de 4 à Schema 2025)
Organization	20 (relevé à Schema 2025)
Enterprise	jusqu'à 40

Planifie ta stratégie de modes en fonction de ces contraintes dès le départ. Quatre modes, c'était le mur historique du plan Professional — beaucoup de systèmes multi-marques butaient dessus. Le passage à 10 change concrètement ce qu'une PME peut faire sans payer un plan Organization.

Le multi-marques ne demande plus de dupliquer tes collections

C'est le vrai changement de 2025, et il rend obsolète une bonne partie de ce qu'on écrivait sur le multi-brand. Historiquement, gérer plusieurs marques signifiait soit empiler les modes, soit dupliquer des collections entières — ingérable au-delà de deux ou trois marques. Schema 2025 a introduit les Extended collections : une équipe publie une version « marque blanche » de son système, que les autres étendent avec leur thème propre. L'extension reste liée au système parent et hérite automatiquement de ses mises à jour — nouvelle variable, ajustement de couleur — tout en conservant les valeurs qu'elle a explicitement surchargées.

Le pattern reste à deux couches. La première contient les décisions fondamentales — échelle typographique, grille de spacing. La seconde contient les tokens propres à chaque marque. Un composant Button fonctionne de façon identique pour toutes les marques ; seule son apparence change. Pour le responsive, je combine des modes de breakpoint (Mobile, Tablet, Desktop sur la collection de spacing) avec l'auto-layout : on applique un mode au frame parent, et tous les enfants héritent des bonnes valeurs — plus élégant et plus maintenable que des variantes de composants par taille d'écran.

Scoping et Code Syntax : le pont vers les développeurs

Le scoping est une fonctionnalité négligée mais fondamentale. Chaque variable peut être restreinte à des contextes précis — fills, strokes, corner radius, gap, padding, text, opacity. En limitant une variable de couleur au scope fills, tu empêches qu'elle soit appliquée par erreur à un trait ou à un texte. Cette contrainte élimine une catégorie entière d'erreurs d'utilisation.

La fonctionnalité Code Syntax associe à chaque variable un nom de code distinct du nom affiché. Ta variable s'appelle surface/primary côté designer et se référence comme --color-surface-primary en CSS, $surface-primary en SCSS ou surfacePrimary en JavaScript. En Dev Mode, les développeurs voient directement ces noms de code dans le contexte du composant inspecté — plus de tableau de correspondance manuel, le lien est vivant et à jour. Et depuis novembre 2025, Figma propose enfin l'import/export natif des variables, aligné sur la spec stable des design tokens : tu peux faire entrer et sortir tes tokens sans dépendre d'un plugin tiers.

Industrialiser la gestion de tokens

Pour un système de taille professionnelle, les variables natives ne suffisent pas toujours. Le plugin Tokens Studio, devenu un standard communautaire, étend Figma avec des références entre fichiers, des expressions mathématiques, la gestion de token sets modulaires, et un support complet du format W3C DTCG ; sa version 2.0 va au-delà du simple plugin avec une plateforme autonome. Et ici aussi, une mise à jour majeure : le format W3C Design Tokens n'est plus une spécification « émergente ». Il a atteint sa première version stable, la 2025.10, le 28 octobre 2025 — neutre, supporté par plus de dix outils. C'est un socle fiable, plus un brouillon mouvant.

Mon workflow type combine Tokens Studio pour la gestion dans Figma, un dépôt Git pour le versionnage des fichiers JSON, et Style Dictionary — désormais en version 5, alignée sur la spec 2025.10 — dans un pipeline CI/CD pour la transformation. La v5 exporte en JSON DTCG par défaut et gère nativement les nouveaux types d'objets couleur et dimension ; si tu fais encore tourner du v4, c'est le moment de planifier la migration. Chaque modification de token dans Figma synchronise vers Git, qui déclenche la génération de code CSS, Swift ou Android. Plus aucune intervention manuelle entre le design et la production.

Migrer progressivement, sans tout casser

Si tu as un système existant basé sur les styles, inutile de tout reprendre d'un coup. Figma supporte styles et variables en parallèle, ce qui permet de convertir collection par collection sans perturber le travail en cours. Je commence toujours par les couleurs, parce que c'est là que le gain du theming par modes est le plus immédiat et le plus visible, puis j'étends aux espacements et aux tailles typographiques dans un second temps. La règle qui m'a évité bien des dégâts : ne migre une collection que lorsqu'elle est stable. Convertir un système encore en mouvement, c'est se condamner à tout refaire deux semaines plus tard.

Le theming dans Figma a franchi un cap en 2025. Entre les limites de modes relevées, les Extended collections qui règlent enfin le multi-marques, l'import/export natif et une spec de tokens stabilisée, ce qui relevait du bricolage il y a un an est devenu une infrastructure solide. Reste la seule chose que l'outillage ne fera jamais à ta place : une convention de nommage propre et une discipline de tokens. Le jour où tu l'as, Figma fait le reste.