Comment Je Construis des Systèmes de Design de Production Avec Figma Make
Le mois dernier, j'ai ouvert le dashboard d'un client et j'ai compté cinq nuances différentes de bleu. Trois styles de boutons qui remplissaient le même objectif. Deux composants de carte complètement différents placés côte à côte sur la même page. L'application fonctionnait bien. Elle ressemblait simplement à ce que quatre designers différents avaient chacun construit un quart sans jamais se parler.
C'est ce qui arrive quand on fait l'impasse sur le système de design.
J'ai livré des projets sans en avoir un. Au début de ma carrière, je pensais que les systèmes de design étaient du superflu — quelque chose dont les équipes entreprise avec des départements de design dédiés avaient besoin, pas les développeurs indépendants ou les petites agences qui construisent vite. J'avais tort, et chaque projet que j'ai construit sans un m'a fini par me le faire payer. Les incohérences s'infiltrent lentement. Un border radius légèrement différent ici. Un poids de police qui ne correspond pas là. Au troisième mois, l'interface ressemble à une courtepointe de patchwork cousue par un comité, et chaque nouvelle fonctionnalité exige que vous preniez cinquante micro-décisions qui auraient dû être prises une seule fois.
Le problème n'a jamais été la motivation. Le problème était le temps. Construire un système de design approprié à partir de zéro prend des jours — cataloguer les couleurs, définir les échelles typographiques, concevoir les états des composants, documenter les règles d'espacement. Des jours que je n'avais pas avec des délais serrés.
Puis j'ai trouvé un flux de travail qui réduit ce délai de jours à heures en utilisant Figma Make, et cela a changé ma façon d'aborder chaque nouveau projet. Le piège, c'est que la sortie générée par l'IA est un point de départ, pas une ligne d'arrivée, et l'écart entre « généré » et « prêt pour la production » est là où la plupart des systèmes de design échouent. Je vais vous montrer exactement où se situe cet écart et comment le combler, mais d'abord — l'étape de préparation que 90% des tutoriels ignorent complètement.
Le Travail Avant le Travail
Voici ce que je vois les développeurs faire mal systématiquement : ils ouvrent Figma, fixent un canevas vide et commencent à concevoir. Pas de références. Pas d'inventaire de composants. Pas de vision claire des pages dont ils ont réellement besoin.
C'est comme écrire du code sans cahier des charges. Vous produirez quelque chose, mais ce ne sera probablement pas ce dont le projet a besoin.
Avant de toucher à un quelconque outil de design, je construis trois choses :
Un inventaire de pages. Chaque écran dont l'application a besoin, listé. Pas wireframé, pas designé — juste nommé et décrit. « Dashboard — affiche les KPIs, le flux d'activité récente et les boutons d'action rapide. » « Paramètres — édition du profil utilisateur, préférences de notification, gestion du compte. » « Tableau de données — filtrable, triable, avec édition inline et actions en lot. »
Ça semble basique parce que ça l'est. Mais j'ai vu des équipes sauter cette étape et finir par concevoir des pages dont elles n'ont pas besoin tout en oubliant celles dont elles ont besoin.
Un recensement de composants. Pour chaque page de l'inventaire, je liste chaque composant d'interface que cette page nécessite. Le dashboard a besoin de : cartes de statistiques, éléments du flux d'activité, boutons d'action, une barre de navigation, une barre latérale. Le tableau de données a besoin de : en-têtes de tableau, colonnes triables, pagination, chips de filtrage, modales d'édition, états vides, skeletons de chargement.
Rédiger cette liste vous force à voir les patterns avant d'avoir designé quoi que ce soit. Les cartes de statistiques et les cellules du tableau de données ont toutes deux besoin d'une typographie cohérente. Les chips de filtrage et les boutons d'action ont tous deux besoin d'états définis. Le recensement des composants est le moment où la portée de votre système de design devient visible.
Un mood board avec un but. Pas un tableau Pinterest de jolies interfaces. Une collection structurée de références visuelles organisées par type de composant et mise en page. J'utilise beaucoup mobin.com pour cela — il agrège des exemples réels d'interfaces de centaines d'entreprises, donc vous référencez des designs de production, pas de l'art conceptuel.
Mes mood boards sont organisés en sections : « Références de navigation », « Références de mise en page de tableaux », « Références de composants de cartes », « Références de mise en page de dashboard ». Chaque section contient 4 à 6 captures d'écran montrant différentes approches du même composant ou pattern de mise en page.
Ce travail de préparation prend environ une heure. Il en économise dix en aval. Quand je demande finalement à Figma Make de générer des pages, les instructions sont suffisamment spécifiques pour produire un résultat utile dès le premier essai plutôt qu'au troisième.
Cette spécificité est essentielle quand on travaille avec des outils de design basés sur l'IA. Laissez-moi vous montrer pourquoi.
Générer des Pages UI Qui N'Ont Pas l'Air Générées par l'IA
Figma Make est un outil de génération de design propulsé par l'IA qui fonctionne à l'intérieur de Figma. Vous décrivez ce que vous voulez, et il produit des fichiers de design éditables — mises en page, composants, pages complètes. La qualité du résultat varie de « étonnamment bon » à « nécessite un retravail important » en fonction entièrement de la façon dont vous formulez votre prompt.
Mon flux de travail génère les pages dans un ordre spécifique car chaque page construit le contexte pour la suivante.
Navigation d'abord. La barre de navigation ou la barre latérale apparaît sur chaque page, elle définit donc le ton visuel de toute l'application. Je prompte Figma Make avec des références de mon mood board : « Génère une navigation latérale avec ces sections : Dashboard, Projets, Analytiques, Équipe, Paramètres. Référence de style : [description des exemples du mood board que j'ai aimés]. Inclure les états replié et déplié. »
La première génération obtient généralement la structure correcte et le style à 70%. J'ajuste les couleurs, peaufine l'espacement et affine les choix d'icônes manuellement. Cela prend environ quinze minutes et produit un composant de navigation que je réutiliserai sur chaque page.
Dashboard ensuite. Avec le composant de navigation établi, la page du dashboard a une ancre visuelle. Mon prompt inclut les composants spécifiques de mon recensement : « Génère une page de dashboard avec : 4 cartes de statistiques KPI en haut, un flux d'activité dans la colonne gauche, un panneau d'actions rapides à droite, et un graphique montrant les tendances hebdomadaires. Utiliser le style du composant de navigation déjà établi. »
Figma Make produit une mise en page avec une structure réelle — pas une grille générique, mais un arrangement réfléchi qui ne nécessite généralement qu'un repositionnement mineur. Les cartes de statistiques sont livrées avec une hiérarchie d'information sensée. Le flux d'activité a un espacement raisonnable entre les éléments.
Pages riches en données ensuite. Les tableaux sont là où la plupart des designs générés par l'IA trébuchent, car les tableaux ont plus d'états que tout autre composant : par défaut, survol, sélectionné, en édition, en chargement, vide, erreur, filtré, tri ascendant, tri descendant. Je prompte chaque état explicitement.
« Génère une page de tableau de données avec : des en-têtes de colonnes triables, des états de survol de ligne, un mode d'édition inline pour la colonne "statut", une barre de filtrage avec des filtres actifs style chip, une pagination avec sélecteur de taille de page, un état vide pour zéro résultat, et un état de skeleton de chargement. »
Cela produit plusieurs artboards dans Figma — un pour chaque état. Tous ne sont pas parfaits, mais avoir les états générés comme point de départ fait gagner un temps énorme comparé à la construction manuelle de chacun.
Cartes, modales et composants secondaires en dernier. À ce stade, le langage visuel est établi à travers la navigation, le dashboard et les pages de tableau. Les composants secondaires héritent naturellement de ce langage.
Une chose sur laquelle je veux être honnête : Figma Make ne produit pas des designs de production pixel-perfect. Il produit des premiers brouillons solides. Les mises en page sont cohérentes. Les relations entre composants ont du sens. La hiérarchie visuelle est généralement correcte. Mais les détails — valeurs exactes de padding, choix spécifiques de poids de police, variations subtiles de couleur entre les états interactifs — ceux-là nécessitent un raffinement humain.
Je consacre environ 30% de mon temps de design à la génération avec Figma Make et 70% au raffinement. Ce ratio peut donner l'impression que l'IA ne fait pas gagner beaucoup, mais considérez ceci : les 30% remplacent ce qui représentait auparavant 60-70% du calendrier (créer des mises en page initiales à partir de zéro). La phase de raffinement est plus rapide et plus ciblée parce que vous polissez, pas vous ne construisez.
Les pages sont terminées. Maintenant vient la partie que la plupart des gens font à l'envers.
Construire le Système de Design Après les Pages (Pas Avant)
Cela va sembler contre-intuitif. La sagesse conventionnelle dit : construisez votre système de design d'abord, puis concevez les pages en utilisant ces composants du système. C'est l'approche classique, et pour les grandes équipes avec des ingénieurs de systèmes de design dédiés, ça marche.
Pour les développeurs indépendants et les petites équipes, j'ai trouvé que l'ordre inverse fonctionne mieux. Concevez les pages d'abord (avec l'assistance de l'IA), puis extrayez le système de design des patterns qui émergent.
Pourquoi ? Parce que concevoir les pages d'abord vous donne un contexte d'utilisation réel. Vous voyez quels composants apparaissent réellement sur plusieurs pages (ceux-là vont dans le système) versus lesquels sont ponctuels (ceux-là non). Vous voyez quelles valeurs de couleur vous avez réellement utilisées de façon répétée versus lesquelles étaient des accents uniques. Le système de design devient le reflet de besoins réels, pas une bibliothèque spéculative de composants que vous pourriez utiliser un jour.
Après que mes pages sont raffinées, je prompte Figma Make pour générer ce que j'appelle un Système de Design Minimum Viable (MVDS) :
« En te basant sur les pages UI que j'ai créées, génère un système de design qui inclut : palette de couleurs avec des valeurs primaire, secondaire, neutre, succès, avertissement et erreur ; échelle typographique avec les niveaux de titre H1-H6, texte courant, légendes et libellés ; échelle d'espacement ; valeurs de border radius ; et composants principaux — boutons (primaire, secondaire, ghost, destructif) avec tous les états (par défaut, survol, actif, désactivé, chargement), champs de saisie (par défaut, focus, erreur, désactivé), cartes, badges, tailles d'avatar et styles de cellules de tableau. »
La sortie MVDS de Figma Make est réellement utile. Pas exhaustive, mais utile. Les couleurs correspondent à ce que j'ai réellement utilisé dans les designs de pages. L'échelle typographique reflète les vraies relations entre les titres. Les composants ont le bon ADN visuel.
Ce qu'il manque — et c'est prévisible — ce sont les cas limites. Boîtes d'alerte, notifications toast, états vides, patterns de chargement, composants de filtre, variantes de pagination, structures de modales avec différents types de contenu. Ceux-ci nécessitent un second passage de génération.
« Étends le système de design avec : composants d'alerte (info, succès, avertissement, erreur avec variantes rejetables et persistantes), notifications toast, spinners de chargement et écrans skeleton, illustrations d'état vide, pagination avec numéros de page et variantes charger plus, shells de modale pour dialogues de confirmation et modales de formulaire, et menus déroulants avec recherche. »
Ce second passage produit un système plus détaillé, mais voici un avertissement pratique : les systèmes de design très détaillés peuvent être trop volumineux pour une importation directe dans certains outils de développement. Si vous prévoyez de pousser ceci dans un codebase via l'export de code de Figma, découpez le système en morceaux — fondations (couleurs, typographie, espacement), composants principaux (boutons, inputs, cartes) et composants complexes (tableaux, modales, navigation) — et importez-les séparément.
J'ai appris cela après une importation ratée qui a planté mon environnement de développement parce que le fichier de design tokens faisait 3 000 lignes. Le découpage a résolu le problème immédiatement.
Du Design au Code Sans Perdre la Tête
C'est ici que le flux de travail se divise, et le chemin que vous empruntez dépend de la configuration de votre équipe.
Chemin A : Export direct de code pour développeurs indépendants.
Figma Make peut générer du code à partir de vos designs. Pour les projets React, Vue ou HTML/CSS vanilla, c'est un gain de temps légitime — vous obtenez du code de composants qui correspond à votre design visuel sans traduire manuellement les pixels en CSS.
Mais — et c'est critique — le code généré aura des valeurs en dur partout. color: #3B82F6 au lieu de var(--color-primary). font-size: 16px au lieu de var(--text-body). padding: 24px au lieu de var(--space-6).
Livrer des valeurs en dur, c'est de la dette technique déguisée en vélocité. Le moment où un client dit « est-ce qu'on peut rendre la couleur primaire un peu plus foncée ? », vous faites un rechercher-remplacer dans cinquante fichiers au lieu de modifier une seule variable.
Avant de pousser du code Figma Make dans votre dépôt, effectuez un passage de refactoring pour convertir les valeurs en dur en design tokens. Je prompte Figma Make explicitement pour cela : « Refactorise ce code de composant pour utiliser des CSS custom properties pour toutes les valeurs de couleur, typographie, espacement et border radius. Génère un fichier de design tokens correspondant qui définit ces variables. »
La sortie nécessite une revue — l'IA crée parfois des tokens redondants ou nomme mal les variables — mais elle gère 80% de la conversion correctement. Les 20% restants sont du nettoyage manuel rapide.
Astuce pro : Établissez votre convention de nommage des tokens avant le passage de refactoring et incluez-la dans le prompt. « Utiliser le format --color-[nom-sémantique] pour les couleurs, --text-[nom-taille] pour la typographie, --space-[numéro-échelle] pour l'espacement. » Un nommage cohérent dès le départ prévient le chaos de nommage des tokens plus tard.
Chemin B : Handoff Figma pour les équipes.
Si vous travaillez avec d'autres développeurs ou une équipe de design, le chemin d'export de code crée des conflits de merge et de la confusion sur la propriété. À la place, gardez tout dans Figma comme source de vérité.
Organisez votre fichier Figma avec une structure claire :
- Page 1 : Système de Design — fondations et composants
- Page 2 : Écrans UI — toutes les pages de l'application
- Page 3 : États des Composants — documentation des états interactifs
- Page 4 : Notes de Handoff — annotations pour les développeurs
Partagez le fichier Figma avec votre équipe. Itérez collaborativement. Quand les designs sont finalisés, les développeurs peuvent utiliser les outils d'inspection de Figma ou Figma MCP pour reconstruire les composants dans le framework de leur choix avec le système de design comme référence.
Ce chemin est plus lent mais produit moins de maux de tête d'intégration pour les équipes multi-personnes. Le système de design vit à un seul endroit, tout le monde référence la même source, et les changements se propagent via le fichier Figma plutôt que via des PRs de code.
J'utilise le Chemin A pour mes projets en solo et le travail client où je suis le seul développeur. J'utilise le Chemin B pour les projets d'agence chez Ramlit où plusieurs développeurs doivent implémenter les mêmes designs. Les deux fonctionnent. Aucun n'est universellement meilleur.
Les Erreurs Que Je Continue de Voir (Y Compris les Miennes)
Laissez-moi vous épargner de la douleur en cataloguant les échecs que j'ai vécus et observés.
Erreur 1 : Traiter la sortie de l'IA comme finale. J'ai vu des développeurs exporter le code généré par Figma Make directement en production sans passage de raffinement. L'interface fonctionne mais semble décalée — espacement incohérent, relations de couleurs légèrement fausses, composants qui ne s'alignent pas tout à fait entre eux. Le design généré par l'IA est un brouillon. Toujours un brouillon. La phase de raffinement n'est pas un polissage optionnel ; c'est là que le design devient professionnel.
Erreur 2 : Construire trop de système de design trop tôt. Ma première tentative de MVDS incluait 47 variantes de composants. J'en ai utilisé 12 dans le projet réel. Les 35 autres sont restées inutilisées, encombrant le système et semant la confusion dans le fichier de design tokens. Commencez minimal. Ajoutez des composants quand une page en a réellement besoin, pas quand vous imaginez qu'une page future pourrait en avoir besoin.
Erreur 3 : Sauter le mood board. Quand je suis pressé, je suis tenté de sauter la collecte d'inspiration et d'aller directement au prompt. La qualité de la sortie baisse sensiblement. Figma Make fonctionne significativement mieux quand vos prompts référencent des patterns visuels spécifiques : « tableau avec des en-têtes fixes comme Notion » versus « génère un tableau ». Le mood board n'est pas de la décoration — c'est de l'ingénierie de prompt pour l'IA visuelle.
Erreur 4 : Ignorer les états responsives. Figma Make génère des mises en page desktop par défaut. Si votre application a besoin de mises en page mobile ou tablette — et en 2026, c'est le cas — vous devez prompter explicitement pour ces breakpoints. Je génère le desktop d'abord, puis je prompte : « Crée des variantes responsives de cette page pour tablette (768px) et mobile (375px), en ajustant la mise en page tout en conservant les mêmes styles de composants. » Les variantes mobile nécessitent généralement plus d'ajustement manuel que le desktop, mais partir d'une mise en page générée vaut mieux que partir de rien.
Erreur 5 : Oublier le mode sombre. Si votre application supporte le mode sombre — et de plus en plus, les utilisateurs l'attendent — générez vos design tokens avec les deux valeurs, clair et sombre, dès le départ. Adapter rétroactivement le mode sombre à un système de tokens existant est douloureux. Je le sais parce que je l'ai fait trois fois, et chaque fois j'ai juré que je me souviendrais de l'inclure dès le début. J'ai finalement tenu parole au quatrième projet.
Ce Qui Change Quand Vous Travaillez de Cette Façon
Après avoir utilisé ce flux de travail sur huit projets en six mois, les différences mesurables sont claires.
Le temps de handoff du design au développement a baissé d'environ 60%. Les plus grandes économies sont venues de l'élimination de la phase du canevas vide. Partir de mises en page générées par l'IA et d'états de composants plutôt que d'artboards vides compresse la phase créative sans sacrifier la qualité — à condition d'investir dans la phase de raffinement.
La cohérence de l'interface s'est améliorée sur chaque projet. Même le MVDS — la version minimale — impose suffisamment de cohérence pour éliminer l'aspect « construit par un comité ». Les clients le remarquent. Deux clients différents ont commenté que l'interface semblait « plus soignée que prévu » sur des projets où j'ai utilisé ce flux de travail. Ils ne peuvent pas articuler ce qui est différent, mais ils ressentent la cohérence.
La réutilisation des composants entre projets est devenue pratique. Quand vos systèmes de design suivent la même structure de tokens et convention de nommage, les composants du Projet A se transfèrent au Projet B avec un ajustement minimal. Mon composant bouton, mon composant carte, mes styles de tableau — ils ont été affinés sur huit projets. Chaque itération est meilleure que la précédente, et mettre en place la base visuelle pour un nouveau projet prend des heures au lieu de jours.
La conversation design avec les clients a changé. Avant ce flux de travail, les premières revues de design portaient souvent sur la correction d'incohérences : « Ces deux pages ne ressemblent pas à la même application. » Maintenant les conversations se concentrent sur des questions stratégiques : « Le dashboard devrait-il prioriser le flux d'activité ou les KPIs ? » C'est une utilisation bien plus productive du temps de chacun.
Les gains rapides apparaissent dès le premier projet — génération de pages plus rapide, résultat plus cohérent. Le bénéfice composé se manifeste vers le troisième ou quatrième projet, quand vos composants affinés et vos conventions de tokens établies commencent à produire des dividendes récurrents.
Les Systèmes de Design Sont de l'Infrastructure, Pas de la Décoration
Il y a un changement de mentalité enfoui dans tout ce flux de travail que je veux rendre explicite, parce que c'est la chose qui m'a pris le plus longtemps à intérioriser.
Un système de design n'est pas un livrable agréable que l'on crée à des fins de documentation. C'est de l'infrastructure. C'est la fondation sur laquelle chaque décision visuelle de votre application repose. Quand la fondation est solide, chaque page que vous construisez dessus est plus rapide, plus cohérente et plus facile à maintenir. Quand la fondation est absente, chaque page est un projet de construction isolé avec ses propres règles.
Les outils d'IA comme Figma Make ont rendu la construction de cette infrastructure considérablement plus rapide. Ce qui était autrefois un investissement de plusieurs jours — et donc facile à sauter sous la pression des délais — est maintenant quelques heures de travail concentré. Le calcul coût-bénéfice a changé. Sauter le système de design ne fait plus gagner un temps significatif, mais la dette qu'il crée est exactement la même qu'elle a toujours été.
Mon défi pour vous est spécifique : choisissez votre prochain projet — celui qui est dans votre pipeline en ce moment. Avant d'écrire une seule ligne de code frontend, consacrez une matinée à ce flux de travail. Collectez votre inspiration. Générez vos pages. Extrayez votre MVDS. Configurez vos design tokens.
Quand vous commencerez à construire l'interface avec cette fondation sous vos pieds, faites attention à combien c'est différent. Faites attention au nombre de décisions déjà prises. Faites attention à la vitesse à laquelle vous avancez quand vous ne réinventez pas l'espacement et les choix de couleur pour chaque composant.
Ce sentiment ? C'est ce qu'on ressent quand on livre avec un système. Et une fois que vous l'avez ressenti, vous ne reviendrez pas à la courtepointe de patchwork.
Travaillons Ensemble
Vous cherchez à construire des systèmes d'IA, automatiser des flux de travail ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous aider.
- Fiverr (builds sur mesure et intégrations) : fiverr.com/s/EgxYmWD
- Portfolio : mejba.me
- Ramlit Limited (solutions entreprise) : ramlit.com
- ColorPark (design et branding) : colorpark.io
- xCyberSecurity (services de sécurité) : xcybersecurity.io
