Créer un design system sur Figma : le guide pratique

Si vous avez déjà passé vingt minutes à chercher la bonne nuance de gris dans un fichier Figma, ou recréé pour la quatrième fois le même bouton dans un style légèrement différent des précédents, ce guide est pour vous. Un design system bien construit élimine ces pertes de temps et garantit que chaque écran de votre interface parle le même langage visuel — qu'il soit créé aujourd'hui ou dans dix-huit mois.

Voici la méthode que j'applique pour construire des design systems sous Figma, des fondations aux composants, en passant par les modes de thème et la documentation intégrée.

Commencer par les fondations, pas par les composants

L'erreur classique est d'ouvrir Figma, de créer un superbe composant de carte produit, puis de réaliser trois semaines plus tard que sa couleur de titre ne correspond plus à la palette officielle. Les fondations — tokens de couleur, d'espacement, de typographie — doivent exister avant le premier composant. Elles sont le béton armé sur lequel tout le reste repose.

Un design system construit dans le mauvais ordre s'effondre à la première évolution de marque. Un design system construit dans le bon ordre encaisse les changements sans douleur.

Les variables de couleur

Depuis l'introduction des Variables dans Figma, la gestion des couleurs a été révolutionnée. La première étape est de créer une collection "Primitives" qui stocke toutes vos valeurs brutes :

• neutral-50 à neutral-950 — l'échelle de gris complète
• primary-100 à primary-900 — votre couleur principale dans toutes ses nuances
• secondary-100 à secondary-900 — votre couleur secondaire
• error, success, warning — les couleurs fonctionnelles

Ces primitives ne sont jamais utilisées directement dans les composants. Elles servent uniquement de répertoire de valeurs. Ce qui est utilisé dans les composants, c'est la collection "Semantic" — des tokens qui portent un sens contextuel :

• color/background/default → neutral-50
• color/background/surface → neutral-100
• color/text/primary → neutral-900
• color/text/muted → neutral-500
• color/accent → primary-500
• color/border/default → neutral-200

Cette architecture en deux niveaux est ce qui rend un changement de thème instantané et sans friction. Lorsque vous basculez en mode sombre, seule la collection Semantic change — les primitives restent identiques. Résultat : tous vos composants basculent automatiquement, sans retouche manuelle.

La hiérarchie typographique

La typographie est la partie la plus sous-estimée d'un design system. Une échelle typographique cohérente donne du rythme à l'interface et guide naturellement l'œil de l'utilisateur vers ce qui est important.

Je construis systématiquement les styles de texte suivants :

• Display — 3 tailles (72/56/44px) pour les grands titres de pages héros
• Heading — h1 à h4 (36/28/22/18px) pour la hiérarchie de contenu
• Body — lg, md, sm, xs (18/16/14/12px) pour les textes courants
• Label — md, sm, xs (14/12/11px) pour les boutons et étiquettes
• Mono — pour les blocs de données techniques

Pour chaque style, définissez la police, la taille, l'interligne, l'espacement des lettres et la graisse. Et surtout : liez la couleur aux variables sémantiques, jamais à une valeur HEX figée. Un texte de corps codé en dur devient inmaintenable dès que la palette évolue.

Choisir les polices

Pour un design system web, je recommande de travailler avec des polices disponibles en variable font — un seul fichier qui contient toutes les variations de graisse et parfois de chasse. Les variable fonts réduisent de 60 à 80 % le poids typographique chargé par rapport à des fichiers séparés par graisse. Des références comme Inter, Fraunces, Cabinet Grotesk ou Plus Jakarta Sans sont des choix solides et bien documentés.

Construire les composants atomiques

Avec les fondations en place, on peut passer aux composants. Je suis la méthodologie Atomic Design : atomes → molécules → organismes. Commencer par les atomes (bouton, champ, badge, tag) garantit que les molécules (carte, navigation) et organismes (header, section héros) s'appuient sur une base cohérente.

Le bouton — pierre angulaire du système

Le bouton est toujours le premier composant à créer. Il doit couvrir :

• Variantes visuelles — primary, secondary, ghost, destructive, link
• Tailles — sm (32px de hauteur), md (40px), lg (48px)
• États — default, hover, focused, active, disabled, loading
• Slots de contenu — texte seul / icône + texte / texte + icône / icône seule

Dans Figma, utilisez les propriétés de composant pour gérer les slots (boolean pour l'icône, texte pour le label, instance swap pour l'icône choisie). Vous obtenez un composant flexible avec une vingtaine de variants au lieu des deux cents que vous auriez en créant chaque combinaison manuellement.

Auto Layout — simuler Flexbox

Auto Layout est la fonctionnalité qui rend les composants Figma réellement utilisables. Il reproduit le comportement de Flexbox : les éléments enfants s'organisent automatiquement, et le conteneur s'adapte à leur taille.

Règles que j'applique systématiquement :

• Hug sur le conteneur pour qu'il épouse son contenu
• Fill sur les enfants qui doivent s'étirer dans l'espace disponible
• Gap et padding référencés depuis les tokens d'espacement, jamais en valeur fixe
• Clip content activé pour éviter les débordements inattendus

Un composant construit avec Auto Layout et des tokens d'espacement se comportera toujours correctement quel que soit son contenu — exactement comme son équivalent CSS.

Les modes de thème clair et sombre

Le thème sombre est aujourd'hui une attente standard. Avec les Variables Figma, l'implémenter proprement prend quelques heures.

Dans la collection "Semantic", créez deux modes : Light et Dark. Pour chaque token, assignez la primitive correspondante dans chaque mode :

• color/background/default → Light : neutral-50 / Dark : neutral-950
• color/text/primary → Light : neutral-900 / Dark : neutral-50
• color/surface → Light : neutral-100 / Dark : neutral-900
• color/border/default → Light : neutral-200 / Dark : neutral-800

Dans vos frames, appliquez le mode "Dark" au niveau du frame racine — tous les composants basculent automatiquement. Un design system avec modes de thème bien construits permet de présenter des interfaces complètes en thème sombre sans créer un seul composant supplémentaire.

Nommage et organisation

Un design system mal nommé est presque inutilisable. La convention que j'utilise : Catégorie / Sous-catégorie / Variante / État.

• Button / Primary / Default
• Button / Primary / Hover
• Input / Text / Error
• Card / Product / Highlighted

Pour les variables : catégorie/sous-catégorie/niveau.

• color/background/primary
• color/text/muted
• spacing/component/padding-sm
• radius/button/md

Organisez vos composants dans des sections sur une page dédiée "Components", et créez une table des matières en haut pour les systèmes d'une certaine ampleur.

La documentation intégrée

Un design system sans documentation est une bibliothèque sans catalogue. Créez une page "Docs" qui présente pour chaque composant :

• Les cas d'usage recommandés (quand utiliser ghost plutôt que secondary ?)
• Les do's and don'ts visuels avec exemples annotés
• Les contraintes d'accessibilité (ratio de contraste, taille de zone tactile minimale)
• Les tokens appliqués et leur équivalent CSS pour les développeurs

Cette documentation transforme le design system en véritable single source of truth consultable par designers, développeurs et product managers. C'est ce qui fait la différence entre un système utilisé et un système archivé.

Accessibilité intégrée dès la conception

Un design system est le meilleur moment pour intégrer l'accessibilité — changer les ratios de contraste au niveau des tokens les propage automatiquement à tous les composants. Vérifiez systématiquement :

• Ratio de contraste minimum 4.5:1 pour le texte normal (WCAG AA)
• Ratio minimum 3:1 pour le texte large (18px+ ou 14px+ en gras)
• Taille de zone tactile minimum 44×44px pour les éléments interactifs sur mobile
• Focus visible et cohérent sur tous les composants interactifs

Un audit WCAG AA au niveau du design system coûte deux heures. Le corriger composant par composant après intégration coûte deux semaines.

Maintenance sur la durée

Un design system vivant doit être activement maintenu. Pratiques essentielles :

• Auditez régulièrement les composants pour identifier ceux qui sont devenus obsolètes ou divergents
• Versionnez les évolutions majeures en dupliquant le fichier avant chaque refonte
• Communiquez les changements à toute l'équipe — une variable renommée sans prévenir casse les fichiers des autres
• Mesurez l'adoption : est-ce que les nouveaux écrans utilisent les composants du système ?

Le vrai indicateur de succès d'un design system, c'est quand les designers le consultent avant de créer quelque chose de nouveau — et non après.

Par où commencer concrètement

Si vous partez d'un projet existant sans design system :

• Faites un audit visuel de vos maquettes pour lister toutes les couleurs, tailles et espacements utilisés
• Identifiez les répétitions et les incohérences — elles vous diront où sont les vraies douleurs
• Créez vos tokens primitifs, puis sémantiques
• Refactorisez vos composants existants pour les lier aux tokens
• Documentez au fur et à mesure de la création

Le premier design system prend toujours plus de temps qu'on ne le pense. Mais dès le deuxième projet sur lequel on l'utilise, l'investissement est largement rentabilisé.

Construire un design system robuste sous Figma est un investissement qui se rembourse sur chaque écran que vous n'avez pas à recréer de zéro. Commencez par les fondations, soyez rigoureux sur le nommage, documentez au fur et à mesure — et votre futur moi vous remerciera.