Design system : les étapes de création de A à Z

Design system: les étapes de création de A à Z

Le projet avance, mais chaque nouvelle page ajoute une couche de friction. Les décisions se répètent, les composants dérivent et le temps de production part dans des micro-arbitrages.

Un design system bien construit remet de l’ordre dans ce quotidien. Il rassemble les fondations visuelles, les composants, les règles d’usage et les correspondances avec le code dans un référentiel partagé. Le gain peut atteindre 30 à 35 % sur les temps de conception et de développement des projets suivants — à condition de ne pas le réduire à une simple bibliothèque de composants dans Figma.

La bonne méthode consiste à avancer par étapes: observer l’existant, cadrer un premier périmètre utile, structurer les variables, créer les composants critiques, connecter le design au code, puis organiser la maintenance. Pas besoin de fabriquer une cathédrale dès le premier sprint. Il faut surtout construire un système que l’équipe pourra vraiment utiliser.

1. Auditer l’existant avant de créer quoi que ce soit

La première étape d’un design system ne se passe pas dans Figma. Elle se passe dans les écrans déjà produits.

C’est l’audit de l’interface, parfois appelé inventaire visuel. Son objectif est simple: comprendre ce qui existe réellement, et non ce que la documentation affirme exister. Dans beaucoup de produits, la charte graphique annonce trois niveaux de gris, tandis que les fichiers de conception en utilisent onze. Le bouton principal existe en quatre hauteurs. Les champs de formulaire changent de rayon selon les pages. Les mêmes cartes sont dupliquées au lieu d’être utilisées comme composants.

Ce désordre n’est pas un problème esthétique. Il révèle les décisions qui n’ont jamais été formalisées.

Cartographier les écrans et les répétitions

Commencez par rassembler les parcours principaux:

• page d’accueil et pages de destination;
• connexion, inscription et récupération de mot de passe;
• recherche, filtrage et affichage des résultats;
• fiches produit ou pages de contenu;
• tunnel de commande ou parcours de conversion;
• tableaux de bord et espaces connectés;
• messages d’erreur, confirmations et états vides;
• versions mobiles et intermédiaires du site responsive.

L’objectif n’est pas de capturer chaque écran au pixel près. Il s’agit de repérer les motifs qui reviennent. Un inventaire visuel peut être réalisé directement dans Figma, dans un tableau partagé ou dans un outil de documentation. Pour chaque élément, notez le nombre de variantes, les différences observées et son niveau de criticité.

Un même composant présent sur vingt écrans mérite évidemment plus d’attention qu’un élément utilisé une seule fois dans une page secondaire. C’est ici que le périmètre du premier système commence à apparaître.

Repérer les doublons visuels

Pour chaque famille d’éléments, posez quatre questions:

1. Combien de versions existent aujourd’hui?

2. Ces versions répondent-elles à un besoin réel ou proviennent-elles d’une duplication historique?

3. Les différences concernent-elles l’apparence, le comportement ou uniquement le contenu?

4. Le composant est-il déjà utilisé dans le code, dans Figma, ou dans les deux?

Prenons le cas d’un bouton. Vous pouvez trouver un bouton bleu de 48 pixels de haut sur la page d’accueil, un bouton bleu de 44 pixels dans le tunnel de commande et un bouton bleu de 40 pixels dans l’espace client. Ce n’est pas forcément trois composants. Il peut s’agir d’un même composant avec trois tailles, à condition que ces tailles aient un rôle clair et documenté.

À l’inverse, si les trois boutons ont des comportements différents au clavier, des contrastes variables et des libellés qui ne respectent pas les mêmes règles, le problème dépasse le simple rangement visuel.

Un audit efficace ne cherche pas à rendre l’interface jolie. Il cherche à rendre visibles les décisions répétées, les exceptions et les dettes qui ralentissent l’équipe.

Définir le MVP du système

Le premier périmètre doit rester volontairement ciblé. Une base de départ de 12 à 20 composants critiques est souvent plus efficace qu’une bibliothèque de 80 éléments incomplètement documentés.

Pour sélectionner ces composants, croisez trois critères:

• fréquence d’utilisation: combien d’écrans utilisent l’élément?
• impact produit: l’élément intervient-il dans une conversion ou un parcours essentiel?
• coût de divergence: combien de temps perdez-vous lorsque chaque équipe le recrée?

Les boutons, champs, liens, alertes, menus, modales, cartes, onglets et éléments de navigation arrivent souvent en tête. Mais le bon choix dépend du produit. Une application de gestion aura peut-être besoin de prioriser les tableaux, les filtres et les sélecteurs de dates. Un site de commerce commencera par les cartes produit, les options, les prix et les étapes du panier.

Ne cherchez pas à traiter tous les cas limites avant d’avoir stabilisé les usages principaux. Le MVP n’est pas une version pauvre du design system. C’est une première surface de contact qui permet de tester les conventions avec de vrais projets.

2. Construire l’architecture des variables

Une fois l’inventaire établi, il faut passer des éléments visibles aux règles qui les alimentent. C’est le rôle des variables de conception, ou design tokens: elles transforment les choix visuels en valeurs nommées, réutilisables et transmissibles au développement.

Sans cette couche, l’équipe peut bien créer des composants, mais elle continuera à modifier les valeurs directement dans chaque instance. Le système aura l’apparence d’un référentiel tout en fonctionnant comme une collection de copies.

Les trois niveaux de variables

Une architecture robuste s’organise généralement sur trois niveaux.

Les valeurs primitives sont les briques de base. Elles indiquent qu’un bleu, un espacement ou un rayon existe dans le système. Mais elles ne disent pas encore pourquoi cette valeur est utilisée.

Les variables sémantiques ajoutent cette intention. color-action-primary est plus utile que `blue-500 lorsque l’on travaille sur un bouton d’action. Si la marque change de bleu, le rôle reste identique et l’interface peut évoluer sans révision manuelle de chaque écran.

Les variables de composant interviennent au dernier niveau. Elles permettent de préciser qu’un bouton possède un espacement horizontal particulier, qu’un champ affiche une bordure spécifique au focus ou qu’une carte applique une ombre différente lorsqu’elle devient interactive.

Nommer pour accélérer les décisions

Le nommage est souvent traité comme un détail. C’est une erreur: une convention floue crée des discussions à chaque nouvelle variable.

Une bonne règle de nommage doit être:

• prévisible pour une personne qui rejoint l’équipe;
• cohérente entre Figma et le code;
• indépendante de la couleur actuellement utilisée;
• assez précise pour éviter les doublons;
• compatible avec les futurs thèmes ou modes d’affichage.

Préférez un nom qui décrit la fonction à un nom qui décrit uniquement l’apparence. surface-action-primary survivra à une évolution de palette. bleu-bouton deviendra rapidement ambigu si le bouton passe au vert ou si la même teinte est utilisée ailleurs.

Autre point très pratique: décidez dès le début de l’écriture des noms. Les espaces, les tirets, les majuscules et les niveaux de profondeur doivent suivre la même logique dans les variables Figma, les propriétés des composants et les variables CSS. Cette discipline paraît minuscule. Elle évite pourtant une quantité impressionnante de nettoyage plus tard.

Relier les variables à l’accessibilité

Les variables ne servent pas seulement à accélérer la production. Elles permettent aussi de sécuriser les fondamentaux.

Pour les couleurs, prévoyez dès le départ les rôles de texte principal, texte secondaire, surface, bordure, action, information, succès, avertissement et erreur. Vérifiez les contrastes selon les exigences WCAG AA, notamment pour les textes courants et les éléments interactifs.

Le focus visible doit également être une variable du système, pas une décision ajoutée à la dernière minute. Même logique pour les états désactivé, survolé, pressé, sélectionné et en erreur. Si ces états sont absents des fondations, chaque équipe les inventera à sa manière.

Un design system accessible ne se contente donc pas de proposer une belle palette. Il donne à l’équipe les moyens de produire des interfaces utilisables au clavier, lisibles avec un contraste suffisant et compréhensibles dans les situations d’erreur.

3. Structurer les composants avec une logique claire

Après les fondations vient le travail le plus visible: créer les composants. Ici encore, le risque consiste à aller trop vite et à transformer le fichier en musée de variantes.

La méthode Atomic Design, popularisée par Brad Frost, propose une organisation en cinq niveaux: atomes, molécules, organismes, modèles et pages. Cette structure peut être utile pour réfléchir aux relations entre les éléments, mais elle ne doit pas devenir une obligation administrative. Le système doit rester compréhensible par l’équipe qui l’utilise.

Partir des comportements, pas des captures d’écran

Un composant n’est pas uniquement une forme. C’est un ensemble de propriétés, d’états et de comportements.

Pour un bouton, documentez au minimum:

• les tailles disponibles;
• les variantes visuelles;
• la présence éventuelle d’une icône;
• les états normal, survol, focus, pressé et désactivé;
• le comportement lorsque le libellé est long;
• la règle à appliquer lorsqu’une action est irréversible;
• l’usage prévu sur mobile et sur grand écran.

Pour un champ de formulaire, ajoutez les états vide, rempli, en erreur, valide, désactivé et en lecture seule. Précisez le rôle du libellé, le format du message d’erreur et la manière dont l’aide est associée au champ.

Cette granularité peut sembler excessive lorsque l’on crée le composant. Elle devient un véritable raccourci dès que plusieurs designers ou développeurs travaillent dessus. Plus la décision est écrite une fois, moins elle doit être rediscutée dix fois.

Éviter le composant impossible à maintenir

Un composant trop générique finit souvent par devenir impraticable. Si un bouton possède vingt propriétés, douze variantes et des exceptions imbriquées, personne ne saura quelle combinaison utiliser.

Pour éviter cette dérive, demandez-vous:

1. La variante correspond-elle à un usage distinct?

2. Est-elle utilisée dans plusieurs contextes?

3. Son comportement change-t-il réellement?

4. Peut-elle être exprimée par une propriété simple?

5. Est-elle suffisamment fréquente pour appartenir au système?

Une différence ponctuelle ne mérite pas forcément une nouvelle variante. Elle peut relever du contenu, de la composition de la page ou d’un cas spécifique documenté séparément. À l’inverse, un état qui revient dans plusieurs parcours doit être intégré au composant plutôt que recréé à chaque fois.

Le bon niveau d’abstraction est celui qui réduit les décisions sans empêcher l’interface de répondre à ses besoins réels.

Documenter avec des exemples qui servent vraiment

Une page de documentation utile commence par l’usage. Elle indique:

• ce que le composant permet de faire;
• dans quel contexte l’utiliser;
• quand ne pas l’utiliser;
• quelles variantes sont disponibles;
• quels états doivent être prévus;
• quelles règles d’accessibilité s’appliquent;
• quels contenus ou longueurs de texte peuvent poser problème.

Les exemples « à faire » et « à éviter » sont particulièrement efficaces. Une simple phrase expliquant qu’un bouton principal doit rester réservé à l’action prioritaire peut éviter la présence de quatre boutons concurrents sur le même écran.

La documentation doit aussi montrer les erreurs fréquentes. Que se passe-t-il si le titre d’une carte produit occupe trois lignes? Si une alerte contient un lien? Si le menu déborde sur un écran de petite largeur? Ce sont ces situations qui révèlent la maturité d’un composant, bien plus que sa version idéale.

4. Faire travailler Figma et le code sur la même base

Un design system devient réellement puissant lorsque le fichier de conception et l’interface développée parlent la même langue. Sans alignement, deux référentiels apparaissent: le premier dans Figma, le second dans le code. Ils commencent par diverger doucement, puis chacun devient la source de vérité de sa propre équipe.

Le principe à viser est simple: un changement doit pouvoir circuler sans traduction manuelle inutile.

Établir des conventions communes

Les noms des variables, des composants et des propriétés doivent être identiques ou suffisamment proches pour être compris sans interprétation.

Si le composant Figma s’appelle Button / Primary tandis que le composant développé s’appelle ActionControl / Main, l’équipe devra maintenir une table de correspondance permanente. Ce n’est pas impossible, mais c’est une friction supplémentaire. À l’échelle d’un produit, ces petits écarts s’accumulent très vite.

Définissez un vocabulaire partagé pour:

• les composants;
• les propriétés;
• les variantes;
• les tailles;
• les états;
• les niveaux de couleur;
• les espacements;
• les points de rupture responsive.

L’auto-layout dans Figma doit également traduire une intention d’interface réelle. Un bouton dimensionné par une largeur fixe ne se comportera pas comme un bouton dont la largeur s’adapte au contenu. Une carte conçue uniquement pour un titre court cassera dès qu’elle recevra un contenu éditorial plus long.

Créer des composants miroirs dans Storybook

Storybook peut servir de catalogue vivant pour les composants développés. Il permet de présenter les variantes, de tester les états et de vérifier le rendu sans devoir naviguer dans toute l’application.

L’intérêt n’est pas de dupliquer la documentation de Figma. Il est de rapprocher les deux représentations:

• Figma montre la composition, les règles visuelles et les usages;
• Storybook montre le comportement réel dans le navigateur;
• le code applique les variables et les contraintes;
• les revues visuelles détectent les écarts avant la mise en production.

Des outils de documentation collaborative comme Zeroheight peuvent également centraliser les règles, les visuels et les liens vers le code. Le choix de l’outil importe moins que la clarté du parcours. Une personne doit savoir où trouver la définition d’un composant, son usage recommandé, ses états et sa version disponible.

Automatiser la boucle de validation

L’automatisation devient intéressante lorsque le système est suffisamment structuré. Les variables peuvent être exportées au format JSON depuis les variables Figma, puis transformées avec Style Dictionary en variables CSS ou en classes Tailwind.

Un pipeline peut ensuite suivre cette séquence:

1. une variable ou un composant est modifié;

2. les fichiers de variables sont reconstruits;

3. une demande de revue est ouverte;

4. les composants sont rendus dans différents états;

5. une comparaison visuelle repère les régressions;

6. la modification est validée avant sa diffusion.

Des outils comme Chromatic facilitent cette revue visuelle autour de Storybook. L’objectif n’est pas de transformer chaque modification en procédure lourde. C’est exactement l’inverse: automatiser les contrôles répétitifs pour que l’équipe se concentre sur les décisions de conception.

La source unique de vérité n’est pas un fichier magique. C’est une chaîne de production cohérente, où le nom, la valeur et le comportement restent alignés du prototype jusqu’au navigateur.

Prévoir le responsive dès la conception

Le design system doit aussi gérer les changements de contexte. Un composant n’est pas terminé parce qu’il fonctionne sur une largeur d’écran de référence.

Pour chaque élément important, vérifiez:

• son comportement sur petit écran;
• la façon dont les textes longs sont gérés;
• la réduction ou la réorganisation des espacements;
• le passage d’une disposition horizontale à verticale;
• les zones tactiles;
• la navigation au clavier;
• la présence d’un contenu traduit plus long.

Un tableau, une barre de navigation ou une carte produit ne se résout pas toujours avec une simple réduction de taille. Il peut nécessiter une autre composition. Le design system doit documenter cette règle, sinon elle sera réinventée à chaque nouvelle page.

5. Installer une gouvernance qui ne ralentit pas l’équipe

La gouvernance est souvent le parent pauvre du projet. On lance une bibliothèque, on annonce qu’elle est prête, puis chacun retourne à ses anciennes habitudes. Six mois plus tard, le système existe encore dans un fichier, mais plus personne ne le consulte.

La gouvernance ne consiste pas à créer une réunion de validation pour chaque rayon de bordure. Elle sert à organiser les contributions, les évolutions et les arbitrages.

Nommer un responsable et un circuit de contribution

Le design system a besoin d’un ou plusieurs propriétaires clairement identifiés. Leur rôle peut être partagé entre design et développement, mais la responsabilité doit être visible.

Ce groupe doit pouvoir:

• accepter ou refuser une nouvelle variante;
• prioriser les composants à améliorer;
• suivre les problèmes connus;
• publier les changements;
• retirer les éléments obsolètes;
• expliquer les décisions prises.

Le circuit de contribution doit rester court. Une demande peut contenir le problème rencontré, les écrans concernés, la solution proposée et son impact sur les composants existants. Une fois la décision prise, elle doit être documentée. Sinon, la même discussion reviendra sous une autre forme quelques semaines plus tard.

Mesurer l’adoption, pas seulement le nombre de composants

Un design system rempli de composants inutilisés n’est pas un succès. Les bons indicateurs parlent de production réelle:

• part des écrans utilisant les composants officiels;
• temps moyen nécessaire pour créer une nouvelle page;
• nombre de variantes locales détectées;
• fréquence des demandes de support;
• nombre de régressions visuelles;
• délai entre une modification de variable et sa disponibilité dans le produit;
• retour des designers et développeurs sur les points de friction.

Le taux d’adoption ne doit pas être interprété seul. Si les équipes contournent un composant, il faut comprendre pourquoi. Il est peut-être trop rigide, mal documenté, difficile à trouver ou incompatible avec une contrainte technique.

L’usage est une donnée de conception. Un composant peu utilisé n’est pas forcément inutile, mais il mérite une enquête avant d’être conservé par inertie.

Prévoir une feuille de route

Le système doit évoluer avec le produit. Organisez une feuille de route par horizons:

• court terme: corriger les incohérences et stabiliser les composants du MVP;
• moyen terme: traiter les parcours secondaires et les variantes responsive;
• long terme: ajouter les thèmes, les modes d’affichage, les besoins multi-marques ou les composants plus complexes.

Cette feuille de route doit suivre les besoins des équipes, pas une envie de collectionner les composants. Une nouvelle fonctionnalité prioritaire peut faire remonter un élément absent du système. À l’inverse, une variante demandée par une seule page peut attendre.

La documentation doit évoluer au même rythme. Chaque changement important mérite une note de version claire: ce qui change, pourquoi, comment migrer et à partir de quand l’ancienne version ne doit plus être utilisée.

6. Déployer le système dans le quotidien de l’équipe

Un design system ne s’installe pas avec un grand soir. Il s’adopte par petites victoires, au fil des projets.

Commencez par choisir un produit pilote ou un parcours suffisamment représentatif. Utilisez-le pour vérifier:

• la structure des composants;
• la facilité de recherche;
• la qualité des variantes;
• la cohérence entre Figma et le code;
• la rapidité de prise en main par une personne extérieure au projet.

Organisez ensuite une courte session de prise en main. Montrez comment trouver un composant, modifier ses propriétés, consulter ses règles et signaler un problème. Une équipe n’a pas besoin d’un cours théorique sur le design system. Elle a besoin de savoir comment gagner du temps dès le prochain écran.

Une méthode de déploiement en six étapes

1. Rassembler les écrans existants

Sélectionnez les parcours principaux et capturez les variantes réellement utilisées.

2. Trier les incohérences

Regroupez les doublons de couleurs, de typographies, d’espacements, de boutons et de champs.

3. Définir les fondations

Formalisez les variables primitives, sémantiques et liées aux composants.

4. Construire les 12 à 20 composants prioritaires

Préparez leurs propriétés, leurs états, leurs contraintes responsive et leurs règles d’accessibilité.

5. Relier Figma et le code

Alignez les conventions, publiez les composants miroirs et automatisez les contrôles quand le volume le justifie.

6. Lancer une boucle d’amélioration continue

Mesurez l’adoption, recueillez les retours, corrigez les blocages et faites évoluer la feuille de route.

Cette progression est volontairement pragmatique. Elle évite de passer plusieurs mois à documenter un système que personne n’a encore testé sur une vraie fonctionnalité.

Les erreurs qui font perdre le bénéfice du système

Certaines erreurs reviennent dans presque tous les projets. Elles ne viennent pas d’un manque de compétence, mais d’une mauvaise séquence de travail.

La première consiste à commencer par les composants les plus spectaculaires. Une galerie, une carte complexe ou un module très graphique peut être passionnant à construire. Pourtant, si les boutons, les champs et les états d’erreur restent incohérents, le système ne résout pas les irritants prioritaires.

La deuxième est de figer trop tôt les décisions. Un système doit fournir un cadre, pas empêcher toute évolution. Les composants doivent être suffisamment stables pour être réutilisés, mais assez souples pour intégrer les retours du produit.

La troisième est de séparer complètement la conception et le développement. Si les composants sont pensés dans Figma puis « traduits » plus tard dans le code, l’équipe découvrira trop tard les contraintes de comportement, d’accessibilité ou de contenu.

La quatrième est de confondre documentation et inventaire. Une page qui affiche une grille de composants ne dit pas comment les utiliser. La documentation doit répondre aux questions concrètes: pourquoi ce composant existe-t-il? Quelle variante choisir? Que faire lorsque le contenu déborde? Quelle option éviter?

La dernière est de laisser les exceptions s’accumuler sans décision. Une exception peut être légitime. Dix exceptions non documentées indiquent généralement que le composant ou la règle de base doit évoluer.

Le bon niveau d’ambition pour commencer

Créer un design system ne signifie pas reproduire les systèmes les plus connus du marché. Une petite équipe peut commencer avec des fondations solides, quelques composants bien documentés et un processus simple de contribution.

Le point de départ idéal est souvent un problème très concret: trop de temps passé à corriger les mêmes écarts, trop de discussions sur les mêmes détails, trop de régressions lors des mises à jour. Le système doit répondre à cette friction avant de chercher à couvrir toutes les possibilités.

Un premier référentiel utile peut contenir:

• une palette structurée par rôles;
• une échelle d’espacements;
• une typographie et ses styles;
• des règles de grille et de responsive;
• les composants d’action et de formulaire;
• les messages d’état;
• les principes d’accessibilité;
• les règles de nommage;
• un espace de documentation partagé;
• un responsable et une feuille de route.

Ensuite, les besoins du produit feront le reste. Les composants complexes viendront lorsqu’ils auront un vrai terrain d’usage. Les variantes seront ajoutées lorsqu’elles éviteront une duplication récurrente. Le système grandira à partir de la production, pas à côté d’elle.

Un système vivant, pas une bibliothèque oubliée

Les étapes de création d’un design system suivent une logique très concrète: audit, fondations, composants, synchronisation, documentation et gouvernance. Chacune réduit une forme différente de friction. L’audit évite de reconstruire l’existant. Les variables sécurisent les décisions. Les composants accélèrent la conception. Le lien avec le code limite les écarts. La gouvernance empêche le référentiel de devenir obsolète.

Le résultat attendu n’est pas un fichier Figma parfait. C’est une équipe capable de concevoir et de livrer plus vite, avec moins d’hésitations et moins de divergence entre les écrans.

Commencez donc par les répétitions qui vous font perdre du temps chaque semaine. Donnez-leur des noms, des règles et des comportements partagés. Puis branchez ces décisions sur le code et mesurez ce qui change réellement dans les projets suivants. C’est là que le design system cesse d’être une promesse de méthode et devient un véritable raccourci de production.