Figma a accéléré sa transformation en profondeur.
Avec Schema 2025, l’arrivée massive des Variables, des Modes, du Dev Mode, et la montée en maturité de la gouvernance DS, la plateforme ne se contente plus d’être un outil de design : elle devient une infrastructure de données pour les Design Systems.
Voici les nouveautés à ne pas manquer pour accompagner cette mutation.
Les Variables : le nouveau socle des Design Systems dans Figma
Source « Guide to variables in Figma » de Figma
Pourquoi les Variables redéfinissent la manière de concevoir
Avec l’introduction des Variables, Figma intègre enfin nativement ce que les équipes Design System structuraient jusque-là de manière indirecte : les équivalents fonctionnels des Design Tokens.
Là où les styles reposaient sur des valeurs figées, les Variables introduisent une logique fondamentalement différente.
Une même valeur (couleur, espace, rayon, typographie, etc.) peut désormais être déclinée selon plusieurs contextes : thème, plateforme, marque, état ou environnement d’usage. Le design cesse d’être une photographie statique pour devenir un système de règles dynamiques.
Cette évolution rend les styles traditionnels progressivement obsolètes. Ils ne disparaissent pas par effet de mode, mais parce qu’ils ne permettent plus de répondre à la complexité actuelle des produits numériques. Les Variables inaugurent un Design System vivant, capable d’évoluer sans être reconstruit à chaque nouvelle contrainte.
Une évolution déjà mise en avant dans Schema
Cette bascule est clairement formalisée dans les annonces autour de Schema 2025. Dans son récapitulatif officiel des évolutions Design System, Figma souligne que les Variables deviennent la base de la structuration des Design Systems, appelées à remplacer progressivement les logiques historiques fondées sur les styles statiques
(voir le récapitulatif Schema 2025 publié par Figma).
À travers Schema, Figma affirme une vision où le Design System s’organise d’abord autour de valeurs gouvernées, interconnectées et réutilisables, plutôt qu’autour de composants isolés. Les composants deviennent alors l’expression visible d’un système de décisions centralisé, et non plus la source de vérité elle-même.
Ce que cela implique pour les organisations
L’adoption des Variables n’est pas un simple changement d’outil, mais un changement de modèle mental pour les équipes.
Elle implique de :
- Repenser la hiérarchie des valeurs, en distinguant clairement les niveaux primitifs, sémantiques et composants ;
- Centraliser les décisions dans un système unique, lisible et partageable entre design et développement ;
- Prévenir la dette Design System en posant, dès le départ, une architecture propre et évolutive.
Les organisations qui abordent les Variables comme une simple fonctionnalité passent à côté de leur véritable potentiel. Celles qui les considèrent comme une infrastructure de décision posent les bases d’un Design System durable, gouverné et réellement scalable.
Les Modes : un système de thématisation enfin natif
Une gestion multi-contexte intégrée
Avec les Modes, Figma apporte une réponse attendue de longue date par les équipes Design System : la possibilité de gérer plusieurs contextes visuels sans dupliquer les styles, les composants ou les bibliothèques.
Le Dark Mode et le Light Mode peuvent désormais être pilotés à partir d’un même socle de valeurs. Les environnements multi-marques ou multi-produits bénéficient également d’un support natif, chaque Mode venant activer un ensemble de valeurs spécifiques sans remettre en cause l’architecture globale du système.
Sur le canvas, les valeurs dynamiques s’appliquent instantanément, permettant de visualiser, tester et comparer les contextes sans friction.
Cette approche met fin aux stratégies de contournement (duplication de fichiers, bibliothèques parallèles, overrides incontrôlés) qui fragilisaient la cohérence et la maintenabilité des Design Systems.
Pourquoi c’est une avancée stratégique
Au-delà du confort d’usage, les Modes représentent une avancée stratégique majeure pour les organisations matures.
Ils permettent enfin aux structures multi-produits et multi-marques d’unifier leurs variations dans un système unique, plutôt que de les disperser dans des implémentations concurrentes. Le Design System gagne en lisibilité, en gouvernance et en capacité d’évolution.
Les Modes transforment la thématisation en mécanisme structurel, et non plus en exception gérée à la marge. Le Design System peut ainsi évoluer, s’adapter et se déployer à grande échelle, sans multiplier les bibliothèques ni alourdir la dette technique et design.
Les Propriétés de Composant : une réponse au variant sprawl
Source « Explorer les propriétés des composants » de Figma
Ce que Figma permet désormais
Les équipes peuvent désormais :
- utiliser des booléens pour afficher ou masquer des éléments sans créer de nouvelles variantes ;
- recourir à l’instance swap pour moduler des contenus ou des sous-composants de manière contrôlée ;
- exploiter des propriétés de texte afin d’éditer les contenus sans générer d’override ;
- structurer clairement les états et comportements via des propriétés de variante plus lisibles.
Cette approche transforme la logique de conception : on ne multiplie plus les composants pour couvrir tous les cas, on définit des règles de configuration à l’intérieur d’un composant unique, plus robuste et plus prévisible.
Insights issus de l’article client “Schema Explained”
Cette orientation est cohérente avec les analyses partagées dans l’article Schema Explained, qui revient en profondeur sur l’évolution de Figma vers des Design Systems gouvernés par les tokens et les règles plutôt que par l’accumulation de composants.
L’article insiste notamment sur un point clé : réduire le nombre de variantes n’est pas un objectif esthétique, mais une nécessité structurelle pour garantir la maintenabilité, la compréhension et la gouvernance du Design System dans le temps.
Les bénéfices pour les équipes
Pour les équipes design et produit, les bénéfices sont immédiats :
- des composants plus simples à consommer, car mieux configurables ;
- des risques d’override fortement réduits, donc moins de dérives locales ;
- des bibliothèques plus légères et plus cohérentes, alignées sur une logique système plutôt que sur des cas isolés.
Les propriétés de composant marquent ainsi un passage important : le Design System n’est plus une collection exhaustive de variantes, mais un ensemble de composants intelligents, pensés pour évoluer sans se fragmenter.
Les Instances imbriquées : vers des composants réellement modulaires
Ce que cette approche rend possible
Avec la généralisation des instances imbriquées, Figma pousse encore plus loin la logique de modularité introduite par les propriétés de composant.
Cette approche permet de concevoir des composants très flexibles, capables de couvrir des cas complexes sans entraîner une explosion du nombre de variantes. Les combinaisons deviennent contrôlées par des propriétés, tandis que la structure interne du composant reste stable et maîtrisée.
Les équipes peuvent ainsi construire des composants à la logique interne robuste, tout en offrant une surface d’utilisation simplifiée aux designers consommateurs du Design System. La complexité est absorbée par l’architecture, pas exposée à l’usage.
Impact sur la qualité du Design System
L’impact sur la qualité globale du Design System est significatif.
Les instances imbriquées favorisent :
- une modularité accrue, où chaque sous-composant conserve un rôle clair ;
- une cohérence renforcée entre écrans, parcours et produits ;
- une réduction drastique de la duplication, au profit d’une logique systémique.
En pratique, cette approche rapproche le Design System d’une architecture logicielle bien conçue : des briques simples, combinables, gouvernées par des règles explicites.
Dev Mode : un transfert design–développement aligné et fiable
Source « Dev Mode » de Figma
Ce que Dev Mode apporte au quotidien
Avec le Dev Mode, Figma franchit une étape décisive dans l’alignement entre design et développement. L’objectif est clair : réduire les zones d’interprétation et faire du Design System un référentiel exploitable directement par les équipes techniques.
Concrètement, Dev Mode permet :
- l’inspection autonome des composants, sans dépendre d’un designer pour accéder à l’information ;
- un accès direct aux valeurs réelles, y compris les Variables et les Modes, telles qu’elles sont définies dans le système ;
- des spécifications lisibles et cohérentes, prêtes à être intégrées dans le code sans traduction approximative.
Le design n’est plus seulement montré, il est documenté par sa propre structure.
Les points soulignés dans Schema 2025
Cette orientation est pleinement assumée dans les communications autour de Schema 2025. Figma y présente le Dev Mode comme une « source technique de vérité » commune, pensée pour être partagée entre design, produit et développement, et non comme un simple outil d’export ou de mesure (voir le récapitulatif Schema 2025).
Le Design System devient ainsi un point de convergence : les décisions prises côté design sont visibles, compréhensibles et vérifiables côté développement, sans rupture ni réinterprétation.
Pourquoi c’est un changement majeur
Ce changement est structurant pour les organisations.
Il entraîne :
- une réduction significative des erreurs d’implémentation, liées aux interprétations ou aux écarts entre design et code ;
- une accélération du développement, grâce à des spécifications directement exploitables ;
- un meilleur alignement produit–tech, autour d’un langage commun et de valeurs partagées.
Avec Dev Mode, Figma ne se contente plus de faciliter la collaboration : elle outille la continuité entre conception et réalisation, condition indispensable à la maturité des Design Systems à grande échelle.
Schema 2025 : la gouvernance devient un enjeu central
Ce que Schema met en avant
Avec Schema 2025, Figma met en lumière un sujet longtemps sous-estimé : la gouvernance du Design System.
À mesure que les systèmes gagnent en complexité et en portée, la question n’est plus seulement comment concevoir, mais qui décide, comment et selon quelles règles.
Schema insiste notamment sur :
- la clarification des rôles entre contribution, validation et ownership ;
- la nécessité de s’appuyer sur un système de tokens stable et structuré pour éviter l’accumulation de dette Design System ;
- la mise en place de workflows DS explicites, capables de soutenir l’évolution du système sans le fragiliser.
Le Design System n’est plus un artefact laissé à la bonne volonté des équipes, mais un actif stratégique qui doit être piloté.
L’article client “Schema Explained” insiste sur la gouvernance
Cette lecture est renforcée par l’analyse proposée dans l’article Schema Explained, qui décrit l’entrée des Design Systems dans une nouvelle ère de maturité.
L’article souligne un point clé : les Design Systems se rapprochent désormais davantage d’une base de données gouvernée que d’une simple bibliothèque de composants. Les tokens, les règles et les dépendances deviennent les véritables fondations du système, bien avant ses manifestations visuelles.
Ce que cela implique pour les équipes
Pour les équipes design, produit et développement, cette évolution implique un changement profond dans la manière de travailler :
- des processus reproductibles, partagés et documentés ;
- un versioning rigoureux, pour sécuriser les évolutions et les déploiements ;
- un pilotage clair des évolutions du Design System, aligné avec les enjeux produit et techniques.
Schema 2025 acte ainsi une réalité devenue incontournable : un Design System ne scale pas sans gouvernance. Les outils sont désormais prêts ; reste aux organisations à se structurer pour en tirer pleinement parti.
IA et First Draft : un accélérateur, mais pas un pilote
Les apports
Avec l’intégration progressive de fonctionnalités d’IA et l’arrivée de First Draft, Figma propose de nouveaux leviers pour accélérer les phases amont de conception.
Ces outils permettent notamment :
- la génération rapide de premières propositions, utiles pour amorcer une réflexion ou explorer plusieurs pistes ;
- une exploration créative accélérée, en réduisant le temps nécessaire pour matérialiser des idées ;
- un prototypage initial plus productif, particulièrement pertinent lors des phases de cadrage ou d’idéation.
Utilisées à bon escient, ces fonctionnalités constituent un gain de temps réel et un soutien efficace à la réflexion des équipes.
Les limites
Cependant, ces apports doivent être abordés avec lucidité.
L’IA ne connaît ni votre produit, ni votre contexte, ni votre Design System. Elle n’intègre pas nativement vos tokens, vos règles ou votre gouvernance, sauf si ceux-ci sont explicitement encadrés et vérifiés.
Sans validation humaine, ces outils peuvent :
- générer des interfaces en déconnexion avec les règles du Design System ;
- introduire des incohérences invisibles à court terme ;
- créer une dette Design System silencieuse, difficile à identifier mais coûteuse à corriger.
First Draft et les outils d’IA doivent donc être considérés comme des accélérateurs, jamais comme des pilotes. Leur valeur réside dans leur capacité à soutenir la conception, pas à la remplacer.
UI3 : une interface repensée pour supporter la montée en complexité
Les nouveautés clés
Avec UI3, Figma adapte son interface à la réalité des Design Systems modernes, devenus plus vastes, plus structurés et plus complexes à manipuler au quotidien.
Parmi les évolutions notables :
- des panneaux mieux organisés, pensés pour réduire la surcharge cognitive ;
- une interface plus lisible pour explorer les composants, les propriétés et les Variables ;
- un accès direct au Dev Mode, intégré nativement dans le flux de travail ;
- des panneaux modulables, permettant à chaque profil (designer, lead DS, développeur) d’adapter son environnement.
UI3 ne se contente pas de moderniser l’apparence de Figma ; elle traduit une volonté claire de soutenir des usages plus avancés et plus systémiques.
Ce que cela change en pratique
Ces évolutions ont un impact direct sur le quotidien des équipes.
UI3 permet :
- une courbe d’apprentissage réduite, notamment pour les nouveaux arrivants sur des Design Systems complexes ;
- une meilleure navigation dans des bibliothèques riches et interconnectées ;
- une simplification globale du workflow Design System, en limitant les allers-retours et les frictions.
En rendant la complexité plus lisible et mieux outillée, UI3 accompagne la montée en maturité des Design Systems et rend leur pilotage plus accessible, sans sacrifier la rigueur nécessaire à leur gouvernance.
Figma fait entrer les Design Systems dans une nouvelle ère
Les évolutions introduites entre 2025 et 2026 marquent une rupture nette dans la manière d’envisager les Design Systems au sein de Figma.
Les Variables et les Modes deviennent le cœur de l’architecture, en instaurant une logique de valeurs gouvernées plutôt que de styles figés. Les propriétés de composant et les instances imbriquées permettent d’assumer pleinement la modularité, sans sacrifier la lisibilité ni multiplier les variantes. Le Dev Mode fluidifie enfin la collaboration avec les équipes de développement, en alignant design et technique autour d’une source de vérité partagée.
Avec Schema 2025, la gouvernance cesse d’être un sujet périphérique pour devenir un enjeu central : rôles clarifiés, décisions structurées, versioning maîtrisé. Le Design System s’affirme comme un système de données, piloté, maintenu et pensé pour durer.
Dans ce contexte, l’IA et First Draft jouent un rôle d’accélérateur, utile mais encadré, tandis que UI3 fournit l’interface nécessaire pour absorber cette montée en complexité.
2025–2026 marque ainsi une bascule : les Design Systems ne sont plus de simples bibliothèques d’interface, mais des infrastructures scalables, gouvernées et stratégiques, capables de soutenir des produits multiples, des organisations étendues et des cycles d’évolution rapides.
