Figma gère enfin l'opacité à l'échelle des variables

Une variable numérique pour piloter l'opacité, enfin sans casser le lien avec la librairie

Figma vient d'ajouter une fonctionnalité qui semble modeste sur le papier, mais qui change concrètement le quotidien de toute équipe qui maintient un design system sérieux : la possibilité de contrôler l'opacité à l'échelle, directement dans le modal des variables, sans jamais détacher une couleur de sa librairie.

Concrètement, trois choses deviennent possibles :

• Aliaser l'opacité d'une couleur tout en gardant cette couleur liée à votre librairie, au lieu de devoir la détacher et ajuster l'opacité à la main.
• Définir l'opacité d'une variable de couleur via une variable numérique, et scoper ces variables numériques spécifiquement pour un usage dans les couleurs.
• Mettre à jour d'un coup l'opacité utilisée pour les états désactivés, les overlays, les scrims, et toutes ces couches semi-transparentes qui peuplent une interface moderne.

Pourquoi ce petit détail comptait autant

Si vous avez déjà construit une librairie Figma un peu dense, vous connaissez le problème : chaque variation d'opacité d'une même couleur finissait par devenir une couleur à part entière, ou pire, une couche détachée qui vivait sa vie loin du design system. Un bouton désactivé à 40% d'opacité, un overlay à 60%, un scrim à 80% : sans solution native, chaque cas se traduisait par une couleur figée, non synchronisée, qu'il fallait retoucher manuellement dès qu'une teinte de marque changeait.

Avec cette mise à jour, l'opacité devient un token à part entière, au même titre qu'une couleur ou un espacement. Elle peut être modifiée une seule fois, à la source, et se propager instantanément partout où elle est utilisée.

Un cas d'usage très concret : disabled states, overlays, scrims

Prenez un système avec ne serait-ce que cinq couleurs primaires, chacune déclinée en trois niveaux d'opacité pour gérer les états désactivés, les surbrillances et les fonds superposés. Sans cette fonctionnalité, cela représente potentiellement quinze couleurs à maintenir séparément. Avec une variable numérique scopée pour l'opacité, une seule valeur suffit à gérer la transparence sur l'ensemble de la palette, quelle que soit la couleur de base.

C'est exactement le genre de détail qui, à l'échelle d'un projet produit avec plusieurs dizaines d'écrans, fait gagner des heures de maintenance et évite des incohérences visuelles difficiles à repérer à l'oeil nu.

{{webdesign}}

L'avis de Mazette.co : une amélioration discrète, mais qui répare un vrai point de friction

Chez Mazette.co, Figma est notre outil de travail quotidien, que ce soit pour construire des interfaces produit ou préparer des designs qui partiront ensuite sur Webflow. Et sur ce type de mise à jour, notre avis est simple : c'est exactement le genre d'amélioration qu'on attendait sans forcément l'avoir demandée à voix haute.

La gestion de l'opacité était un angle mort assez frustrant dans les variables Figma. On s'en accommodait avec des workarounds : couches dupliquées, couleurs custom pour chaque état, petites astuces transmises d'un designer à l'autre dans l'équipe. Rien de bloquant, mais un frein réel à la scalabilité d'un design system, surtout sur des projets avec beaucoup d'états d'interface (formulaires complexes, dashboards, composants interactifs riches).

Ce qui nous plaît particulièrement ici, c'est la logique de fond : traiter l'opacité comme une variable numérique scopée, exactement sur le même modèle que les tokens de couleur ou d'espacement. Cela va dans le sens d'une tendance qu'on observe depuis plusieurs versions chez Figma : transformer le design system en un véritable système de données structurées, où chaque propriété visuelle devient un paramètre pilotable plutôt qu'une valeur figée à la main.

Pour nos clients, le bénéfice est très concret : moins de temps passé en maintenance sur les librairies de composants, moins de risques d'incohérence entre les différents états d'un même composant, et une meilleure capacité à faire évoluer une charte graphique sans tout reconstruire. C'est le genre de gain invisible pour l'utilisateur final, mais qui se ressent directement dans la vitesse et la fiabilité de nos livrables.

Un seul bémol : cette fonctionnalité arrive tardivement par rapport à des besoins qui existent depuis longtemps dans les équipes produit. Mais mieux vaut tard que jamais, et l'implémentation semble suffisamment réfléchie pour s'intégrer naturellement dans les workflows existants sans tout bouleverser.

Si vous travaillez sur un design system qui commence à montrer ses limites, ou si vous préparez une migration de vos maquettes vers un site en production, c'est le bon moment pour faire le point. Consultez notre méthode ou contactez-nous pour en discuter.