Figma variables et theming : construire un design system prêt pour le dark mode

Pourquoi la plupart des design systems ne sont pas prêts pour le dark mode

La réponse tient en une phrase : parce qu'ils ont été pensés couleur par couleur, pas relation par relation. Un bouton bleu reste bleu dans les Styles Figma classiques, quel que soit le thème. Il faut donc dupliquer le composant, créer une variante "dark", puis prier pour que personne n'oublie de la mettre à jour au prochain redesign.

Chez Mazette.co, on a repris en 2026 le design system d'un client e-commerce dont l'équipe produit avait ajouté un dark mode "à la volée" trois ans plus tôt. Résultat : 340 composants, dont environ 90 existaient en double (light et dark), avec des écarts de teinte visibles à l'œil nu entre les deux versions d'un même bouton. Le vrai coût n'était pas visuel, il était humain : chaque évolution de la charte demandait deux fois plus de temps de maintenance, côté design comme côté développement Webflow en aval.

Les Variables Figma, arrivées en version stable en 2023 et considérablement enrichies depuis (modes multiples, alias imbriqués, liaison directe aux tokens de code), résolvent structurellement ce problème. Mais seulement si l'architecture derrière est pensée dès le départ pour ça.

L'architecture à trois niveaux : primitives, sémantiques, composants

Un design system theming-ready s'organise toujours selon la même hiérarchie, quel que soit le produit. C'est la structure qui change tout, bien plus que le nombre de couleurs disponibles.

Niveau 1 : les variables primitives

Ce sont les valeurs brutes, sans intention d'usage. Gray-100, Gray-900, Blue-500. Elles ne référencent rien d'autre qu'elles-mêmes et ne devraient jamais être appliquées directement sur un calque de production. Elles servent uniquement de réservoir pour le niveau suivant.

Niveau 2 : les variables sémantiques

C'est le cœur du système. Une variable comme background/surface/primary ou text/color/muted pointe vers une primitive différente selon le mode actif. En light mode, surface/primary alias Gray-50. En dark mode, la même variable alias Gray-900. Le composant, lui, ne change jamais : il consomme toujours surface/primary, sans savoir ce qu'il y a derrière.

Niveau 3 : les variables de composant

Certains cas nécessitent un niveau supplémentaire, notamment pour les composants complexes (cartes, modales, tableaux) où plusieurs états sémantiques se croisent. Une variable card/border/default qui alias surface/border/subtle évite de reconstruire la logique à chaque nouveau composant.

Cette architecture à trois niveaux, c'est exactement ce qu'utilisent les design systems matures comme celui de Shopify Polaris ou d'Atlassian : jamais de couleur brute posée directement sur un composant final.

Comment configurer les modes dans Figma pour le dark mode

Concrètement, il faut créer une collection de variables dédiée au theming, distincte de la collection des primitives. Dans cette collection sémantique, on ajoute deux modes : Light et Dark. Chaque variable sémantique reçoit alors deux valeurs, une par mode, en aliasant les primitives correspondantes.

Un point que beaucoup d'équipes ratent : il faut aussi prévoir un mode par défaut clair au niveau du fichier, et surtout appliquer le mode au niveau de la frame racine de chaque écran, pas calque par calque. C'est ce réglage au niveau du frame qui permet de prévisualiser un écran entier en dark mode d'un simple clic dans le panneau des variables, sans retoucher un seul élément.

Pour les marques multi-produits ou multi-clients (fréquent dans nos projets d'agence), on ajoute une troisième dimension : les modes de marque. Une collection "Brand" avec un mode par client, croisée avec la collection "Theme" (light/dark). Cela permet à un seul fichier Figma de générer, en théorie, quatre combinaisons de rendu sans dupliquer un seul composant.

Les erreurs les plus fréquentes qu'on corrige en audit

Nommer les variables par leur valeur plutôt que par leur usage

Appeler une variable sémantique white ou black au lieu de surface/inverse est l'erreur la plus courante. Le jour où le dark mode inverse la logique, le nom devient un mensonge : la variable "white" contient une valeur sombre. Toujours nommer par intention, jamais par teinte.

Oublier les couleurs sémantiques d'état

Les couleurs de succès, d'erreur, d'alerte et d'information doivent elles aussi passer par le système de modes. Un rouge d'erreur en light mode (souvent trop saturé et agressif en dark) doit être désaturé ou éclairci pour le mode sombre, sinon l'accessibilité en pâtit fortement — le contraste WCAG AA (4.5:1 minimum) est souvent cassé sur ces couleurs vives quand elles sont simplement recopiées telles quelles.

Négliger les élévations et les ombres

En light mode, la profondeur se lit via des ombres portées. En dark mode, les ombres sont quasiment invisibles sur fond sombre : la profondeur doit plutôt se traduire par des variations de luminosité de surface (une carte plus claire que le fond). C'est un point que beaucoup de design systems oublient totalement, avec des interfaces dark mode qui paraissent "plates".

Ne pas anticiper le transfert vers le développement

Un design system theming-ready n'a de valeur que si les variables sémantiques sont exportées proprement vers le code, en CSS custom properties ou en tokens JSON via un plugin comme Tokens Studio. Sur nos projets Webflow, ce sont ces mêmes variables sémantiques qui deviennent les Custom Properties du site, permettant un vrai toggle dark mode côté production, pas juste côté maquette.

{{webdesign}}

L'avis Mazette.co : le dark mode n'est jamais le vrai sujet

Sur un projet récent pour une scale-up SaaS B2B, la demande initiale était simple en apparence : "on veut un dark mode". Après audit du fichier Figma existant, le vrai chantier n'était pas la création d'un thème sombre, mais la refonte complète de l'architecture des variables, jusque-là composée à 100% de Styles couleur classiques appliqués en dur sur 210 composants. Le dark mode a finalement pris trois jours de production une fois l'architecture sémantique posée. La refonte de l'architecture, elle, en a pris douze.

C'est le vrai enseignement qu'on répète à chaque client : investir dans les variables sémantiques n'est jamais un coût lié au dark mode. C'est un investissement dans la vélocité de toute évolution future de la marque, qu'il s'agisse d'un thème sombre, d'un rebranding, ou d'une déclinaison multi-marque. Un client qui nous demande "juste" un dark mode a en réalité besoin qu'on répare les fondations de son design system — et c'est souvent là que se niche la vraie valeur d'un accompagnement product design mené jusqu'au bout, plutôt qu'une simple livraison de maquettes.

Ce travail se prolonge naturellement côté développement : une architecture de variables bien pensée dans Figma s'implémente directement en variables CSS dans Webflow, sans traduction manuelle fastidieuse ni divergence entre design et code. C'est cette continuité entre Webflow et Figma qui, dans notre expérience, fait gagner le plus de temps sur la durée de vie d'un produit — bien plus que n'importe quel raccourci pris en amont.