Créer un design system à partir d'un site importé dans Figma

Un import vous donne des calques, pas un design system. Pour passer de l'un à l'autre, vous auditez les valeurs que la page répète, vous regroupez les quasi-doublons en une échelle et vous nommez ce qui reste en tokens primitifs et sémantiques dans Figma. Ce tutoriel suppose que la page est déjà dans Figma et que vous connaissez les variables. En octobre 2026, prévoyez de faire l'essentiel à la main.

Ces étapes valent pour la refonte d'un site sans fichier de design, pour l'analyse de la page d'un concurrent ou pour la reconstruction d'une page ancienne. L'objectif est un petit système que vous pouvez réellement maintenir, pas un inventaire complet de tout ce que la page contient. Comptez une à deux heures pour une page marketing typique, et davantage pour une interface produit aux nombreux états. Le prérequis est simple : une page importée ouverte dans Figma, avec les polices résolues, et un droit de modification sur le fichier où vivront les variables.

Auditer l'import avant de nommer quoi que ce soit

Commencez par nettoyer l'import. Supprimez le bruit caché et aplatissez les calques qui n'existent qu'à cause de la façon dont la page a été construite. Nommer des tokens sur du désordre revient à donner un joli nom à des déchets.

Relevez ensuite ce qui se répète. Il vous faut cinq listes :

1. Couleurs de remplissage et de texte
2. Tailles de police, avec graisse et interligne
3. Valeurs d'espacement (padding et gap)
4. Rayons de coin
5. Ombres

Comptez combien de fois chaque valeur apparaît. Une valeur utilisée une fois est une exception, pas un token. Une valeur utilisée douze fois est une candidate.

Une limite qu'il vaut mieux énoncer clairement : la page produit d'UnHTML ne dit pas que les propriétés personnalisées CSS ou les design tokens de la page d'origine sont transférés dans Figma. Traitez l'import comme des valeurs brutes et construisez vous-même les variables. La capture web propre à Figma est différente, et nous y revenons vers la fin.

Regrouper les quasi-doublons en une échelle

Les pages réelles sont désordonnées. Vous trouverez quatre gris qui diffèrent de quelques points de luminosité, et des valeurs de padding comme 14px, 15px et 16px côte à côte. Choisissez une valeur par groupe et alignez les autres dessus.

Tenez un tableau de travail pour que les décisions restent visibles :

Ne courez pas après chaque valeur isolée. Si une valeur n'apparaît qu'une ou deux fois et n'entre pas dans l'échelle, laissez-la en dérogation locale. Gardez la première passe plus petite que ce que suggère l'audit. Elle est plus facile à défendre et plus facile à étendre.

D'abord les tokens primitifs, ensuite les sémantiques

Le guide de Figma sur les tokens sépare les tokens en couches, et cette séparation est la colonne vertébrale du système.

Les primitifs définissent ce qui existe

Les tokens primitifs listent chaque valeur du système, comme chaque couleur de marque ou chaque palier d'espacement. Figma les décrit comme "for reference only" (à titre de référence uniquement) : vous ne les appliquez donc pas directement aux maquettes. Nommez-les d'après leur valeur, par exemple gray/500 ou space/16.

Les sémantiques disent comment l'utiliser

Les tokens sémantiques portent l'intention. Dans l'exemple de Figma, surface/brand-contrast pointe vers le primitif pink/400. Comme les tokens sémantiques sont des alias des primitifs, modifier la valeur de base met à jour tout ce qui en dépend. Préférez les mots entiers aux abréviations et gardez des préfixes cohérents, pour que les noms restent valables quand le système grandit.

Tokens de composant, seulement si nécessaire

Un token de composant indique où une valeur s'applique, sous la forme button-primary-background-default. Ajoutez-en quand un composant doit s'écarter de la couche sémantique partagée. Passez-les sur la première passe.

Des variables pour les valeurs, des styles pour les valeurs composées

Les variables et les styles de Figma font des métiers différents. La plupart des équipes utilisent les deux. Les variables prennent en charge les alias, plusieurs modes pour les thèmes, les portées et la code syntax. Les styles contiennent des valeurs composées, comme plusieurs remplissages ou plusieurs ombres sur un même calque.

Cela a une conséquence pratique pour une page importée. Les valeurs simples comme les couleurs, les espacements et les rayons vont dans des variables. Une ombre à plusieurs couches reste un style, et un dégradé aussi, car les variables ne peuvent pas contenir de dégradés. Pour voir comment ces deux éléments arrivent depuis la page, lisez comment box-shadow devient un effet Figma et ce qu'il advient des dégradés CSS.

Refléter les tokens en propriétés personnalisées CSS

Si un développeur doit implémenter le système, donnez-lui des tokens qui correspondent. La référence MDN est claire sur les règles qui comptent : les propriétés personnalisées ont pour portée les éléments sur lesquels elles sont déclarées, elles participent à la cascade et elles s'héritent. Les noms sont sensibles à la casse : deux graphies du même nom sont donc deux propriétés différentes.

Un reflet minimal du tableau ci-dessus ressemble à ceci :

:root {
  --gray-500: #6b7280;
  --space-16: 16px;
  --radius-4: 4px;

  --text-secondary: var(--gray-500);
  --card-padding: var(--space-16);
}

Le premier bloc est la couche primitive. Le second est la couche sémantique, écrite sous forme d'alias avec var(). La structure correspond une à une aux collections Figma.

Le soin apporté aux noms paie une seconde fois. Quand vous capturez une page avec la capture web propre à Figma, Figma lie les variables CSS aux variables Figma dans un ordre fixe : il compare d'abord le nom CSS à la code syntax de la variable, puis au nom de la variable, et enfin se rabat sur la variable la mieux adaptée dont la portée est la plus limitée. Définissez la code syntax de vos variables, gardez des noms CSS lisibles et capturez depuis un serveur de développement où les outils de build n'ont pas brouillé les noms. Les variables de couleur avec opacité ne sont pas liées : vérifiez-les donc à la main.

Vérifier le système par rapport à la page

Un jeu de tokens ne vaut que s'il peut reconstruire la page dont vous êtes parti. Choisissez deux ou trois frames représentatives de l'import et reliez leurs remplissages, couleurs de texte, padding et rayon de coin aux nouvelles variables, en partant de la couche sémantique. Comparez ensuite le résultat à l'original.

Attendez-vous à de petits décalages. Ramener 14px et 15px de padding à 16px déplace les éléments d'un pixel ou deux, et c'est le compromis que vous avez accepté en regroupant l'échelle. Si un décalage est assez grand pour modifier la mise en page, le groupe était mal choisi : scindez-le en deux tokens ou gardez la valeur isolée en dérogation locale. C'est aussi là que vous trouvez les valeurs que l'audit a manquées, comme une couleur de survol qui n'existe que sur un seul composant.

Documenter le système pour que d'autres puissent l'utiliser

Notez à quoi sert chaque collection. Une courte description sur chaque collection de variables suffit : de quelle couche il s'agit (primitive ou sémantique), si les designers peuvent l'appliquer directement et qui valide les changements. Utilisez les options de portée des variables Figma pour qu'une variable d'espacement n'apparaisse pas dans le sélecteur de couleur.

Si vous maintenez aussi le reflet CSS, considérez les collections Figma comme la source de vérité et mettez la feuille de style à jour quand elles changent. Deux sources de vérité divergent vite. Le mode sombre et les autres thèmes sont le seul cas où il vaut la peine d'ajouter tôt un second mode, car, grâce aux alias, seule la couche sémantique change d'un mode à l'autre.

Les composants et les styles viennent ensuite

Une fois les tokens en place, la réutilisation est l'étape suivante. En Pro, UnHTML transforme la typographie récurrente en styles de texte partagés et les éléments répétés en composants, comme expliqué dans transformer un import Pro en composants et en styles de texte. Faites d'abord les tokens. Les composants et les styles de texte auront alors de vraies variables auxquelles se lier, au lieu de valeurs hexadécimales isolées.

Conclusion

Auditez ce que la page répète, ramenez les quasi-doublons à une échelle et séparez le résultat en tokens primitifs et sémantiques. Mettez les valeurs simples dans des variables, gardez les valeurs composées en styles et reflétez les noms en CSS pour que designers et développeurs partagent le même vocabulaire. Commencez petit et n'ajoutez un token que lorsqu'une valeur l'a mérité. L'import vous évite de reconstruire la page. Le système reste votre décision.