Design system : pourquoi et comment en créer un

Un design system est un ensemble structuré de fondations visuelles (couleurs, typographies, espacements), de composants réutilisables (boutons, cartes, formulaires) et de règles de documentation qui permettent de concevoir et développer un site web cohérent, maintenable et scalable. Ce n'est pas un simple UI kit : il inclut aussi des design tokens (valeurs nommées), des règles d'utilisation et une logique de gouvernance. Figma est le standard pour le construire, et la méthodologie Client-First (Finsweet) est la référence pour le traduire dans Webflow. Un design system n'est pas réservé aux grandes entreprises : même un site vitrine de 5 à 10 pages bénéficie d'un système structuré, parce qu'il réduit les incohérences, accélère la production et simplifie la maintenance. Cet article couvre la définition, les composants, la construction dans Figma, et la traduction dans Webflow.

À mesure qu'un site web grandit, les incohérences s'accumulent. Un bouton qui change de taille selon les pages. Des marges différentes entre des sections qui devraient être identiques. Des couleurs qui varient légèrement d'une page à l'autre. Des composants recréés depuis zéro à chaque nouvelle page au lieu d'être réutilisés. Ces problèmes ne se voient pas toujours individuellement, mais leur accumulation produit un site qui manque de finition, qui est difficile à maintenir, et qui crée des allers-retours coûteux entre designers et développeurs.

Le design system est la solution structurelle à ces problèmes. C'est un système organisé qui centralise les décisions de design (couleurs, typographies, espacements, composants) dans une source unique, partagée entre tous les intervenants du projet. Il ne s'agit pas d'un exercice théorique réservé aux grandes entreprises tech : c'est un outil concret qui améliore la qualité et l'efficacité de n'importe quel projet web, y compris un site vitrine de quelques pages.

Cet article est un guide complet pour comprendre et créer un design system adapté à un projet web. Il couvre ce que c'est réellement, pourquoi c'est indispensable, quels composants il contient, comment le construire concrètement dans Figma, et comment il se traduit dans Webflow avec la méthodologie Client-First. L'objectif est de vous donner un chemin d'action clair, que vous soyez designer, chef de projet ou fondateur.

‍

Qu'est-ce qu'un design system ?

Un design system est un ensemble structuré de règles, de fondations visuelles, de composants réutilisables et de processus qui permettent de concevoir et développer des interfaces cohérentes et scalables. Il crée un langage commun entre les designers, les développeurs, les chefs de produit et les équipes marketing, ce qui réduit les interprétations divergentes et les allers-retours pendant le projet.

La confusion la plus fréquente est de considérer un design system comme un simple UI kit. Un UI kit est une collection d'éléments graphiques (boutons, icônes, cartes) prêts à être utilisés. C'est une bibliothèque visuelle, utile mais incomplète. Un design system va beaucoup plus loin. Il inclut les fondations (design tokens : couleurs, typographies, espacements), les composants documentés (avec leurs états, variantes et règles d'utilisation), les patterns (assemblages de composants pour des cas d'usage récurrents), et une logique de gouvernance (comment le système évolue, qui peut le modifier, quelles sont les règles de décision). En d'autres termes, un design system est un produit interne au service du projet, pas un livrable figé.

En bref, un design system est un système organisé qui centralise les décisions de design, les composants réutilisables et leur documentation dans une source unique. Il permet de concevoir et développer un site web cohérent, maintenable et scalable, en créant un langage commun entre tous les intervenants du projet.

‍

Pourquoi votre site web a besoin d'un design system

L'idée qu'un design system est réservé aux grandes entreprises ou aux produits SaaS complexes est un malentendu courant. En réalité, tout projet web qui dépasse une ou deux pages bénéficie d'un système structuré, et les avantages sont concrets et mesurables.

Cohérence visuelle sur toutes les pages

Sans design system, les incohérences visuelles s'accumulent naturellement au fil du projet. Un designer crée une première page avec certains espacements, puis une deuxième page avec des espacements légèrement différents. Un bouton a un rayon de bordure de 8 pixels sur une page et de 12 pixels sur une autre. Ces écarts semblent mineurs individuellement, mais ensemble ils produisent un site qui manque de professionnalisme et dilue l'identité de marque. Le design system élimine ces incohérences en imposant des règles claires et des composants standardisés que tout le monde utilise.

Productivité accrue

Quand les composants sont définis et documentés dans un design system, les designers et les développeurs les réutilisent au lieu de les recréer depuis zéro à chaque page. Un bouton, une carte de témoignage, un formulaire de contact n'ont besoin d'être conçus qu'une seule fois. Chaque nouvelle page se construit à partir de composants existants, ce qui accélère considérablement la production. Sur un projet de refonte de site, ce gain de temps se traduit directement en réduction de budget et de délai.

Scalabilité

Ajouter de nouvelles pages ou de nouvelles sections à un site est plus rapide et plus fiable quand les fondations sont structurées. Un nouveau type de page (landing page, page service, article de blog) se construit en assemblant des composants existants et en les adaptant au contenu spécifique. Si le design system est bien conçu, l'ajout de contenu ne nécessite pas de créer de nouveaux composants mais de combiner ceux qui existent déjà. Cette scalabilité est ce qui permet à un site de grandir sans que la qualité se dégrade.

Maintenance simplifiée

Quand un composant central est modifié dans le design system, la modification se répercute partout automatiquement. Changer la couleur primaire de la marque, ajuster la taille d'un bouton ou modifier la typographie d'un titre se fait en un seul endroit, et toutes les pages du site héritent de la modification. Sans design system, cette même modification doit être appliquée manuellement sur chaque page, ce qui prend du temps, crée des oublis et génère des incohérences.

Collaboration fluide

Le design system devient le référentiel unique pour toute l'équipe. Le designer sait quels composants utiliser et dans quel contexte. Le développeur sait comment les implémenter et quelles classes CSS leur correspondent. Le chef de projet peut vérifier la cohérence du site par rapport au système défini. Les discussions ne portent plus sur "quel bleu utiliser pour ce bouton" mais sur "quel composant convient le mieux à ce cas d'usage". C'est un gain de clarté qui réduit les malentendus et les allers-retours.

Un design system n'est pas un investissement réservé aux projets de grande envergure. Même un site vitrine de 5 à 10 pages bénéficie d'un système structuré, parce que les avantages (cohérence, productivité, maintenance) se manifestent dès les premières pages. Et quand le site évolue (ajout d'un blog, de nouvelles pages services, d'une section portfolio), le design system est déjà en place pour absorber cette croissance sans perte de qualité.

‍

Les composants d'un design system

Un design system se compose de plusieurs couches, chacune avec un rôle spécifique. La couche la plus profonde définit les règles fondamentales, et les couches suivantes les appliquent sous forme de composants et de patterns.

Les fondations (design tokens)

Les fondations sont les valeurs de base qui définissent l'identité visuelle du site. Elles sont exprimées sous forme de "design tokens", c'est-à-dire des valeurs nommées qui représentent des décisions de design. Au lieu d'utiliser directement le code hexadécimal #2563EB dans chaque composant, on crée un token appelé color-primary qui contient cette valeur. Si la couleur primaire change un jour, on modifie le token en un seul endroit et tout le site se met à jour.

Les fondations couvrent la palette de couleurs (primaires, secondaires, neutres, sémantiques pour les messages de succès, d'erreur, d'alerte), les typographies (familles de polices, tailles, graisses, hauteurs de ligne), le système d'espacements (marges et paddings standardisés, idéalement en rem pour l'accessibilité), les grilles et breakpoints (largeur des conteneurs, colonnes, comportement responsive), ainsi que les rayons de bordure, les ombres et l'iconographie.

Les composants UI

Les composants UI sont les éléments d'interface réutilisables qui constituent les briques de construction du site. Les plus courants sont les boutons (avec leurs variantes : primaire, secondaire, ghost, et leurs tailles : small, medium, large), les champs de formulaire (input, textarea, select, checkbox), les cartes (produit, témoignage, article, membre d'équipe), les éléments de navigation (menu, breadcrumb, pagination), les modales, les alertes et les badges.

Chaque composant est documenté avec ses états (par défaut, hover, focus, actif, désactivé), ses variantes et ses règles d'utilisation. Un bouton primaire n'est pas simplement "un rectangle bleu avec du texte blanc". C'est un composant qui a une taille minimum, un comportement au survol, un état désactivé, et des règles sur quand l'utiliser (action principale de la page) et quand ne pas l'utiliser (action secondaire, auquel cas on utilise le bouton secondaire).

Les patterns

Les patterns sont des assemblages de composants qui forment des sections récurrentes du site. Une section hero (titre + sous-titre + CTA + image), une section témoignages (grille de cartes témoignages + titre de section), un footer (logo + navigation + mentions légales + réseaux sociaux), un formulaire de contact (champs + bouton + message de confirmation). Les patterns ne sont pas de nouveaux composants : ils sont construits à partir des composants existants, assemblés selon des règles de mise en page définies.

La documentation

Un design system sans documentation est une bibliothèque que personne ne sait utiliser correctement. Chaque fondation, chaque composant et chaque pattern doit être accompagné de directives claires : dans quel contexte l'utiliser, quelles variantes existent, quelles sont les règles à respecter (et à ne pas transgresser), et des exemples concrets de bon et de mauvais usage. Cette documentation est ce qui transforme une collection de composants en un véritable système. Sans elle, chaque designer interprète les composants à sa façon, et les incohérences réapparaissent.

Voici un récapitulatif des couches d'un design system :

‍

Comment construire un design system dans Figma

Figma est le standard du marché pour la conception de design systems. Son système de composants, de variantes et de styles partagés en fait l'outil le plus adapté pour construire un design system structuré et collaboratif. Voici les cinq étapes à suivre.

1) Auditer l'existant

Si un site existe déjà, la première étape est d'analyser ce qui est en place. Identifier les incohérences (couleurs qui varient, espacements non standardisés, composants différents d'une page à l'autre), les éléments récurrents (boutons, cartes, sections qui reviennent sur plusieurs pages), et les styles utilisés de facto (même s'ils ne sont pas formalisés). Cet audit produit la liste des éléments à standardiser et les décisions de design à formaliser dans le nouveau système. Pour un nouveau projet, cette étape est remplacée par l'analyse des besoins et l'étude des moodboards.

2) Définir les fondations

Créer les styles de couleurs dans Figma (Color Styles) avec une nomenclature claire : primary, secondary, neutral-100 à neutral-900, success, error, warning. Créer les styles de texte (Text Styles) pour chaque niveau typographique : heading-1 à heading-6, body-large, body-base, body-small, caption, label. Définir les variables d'espacement (Variables dans Figma) avec des paliers cohérents : 4px, 8px, 12px, 16px, 24px, 32px, 48px, 64px (ou leurs équivalents en rem). Ces fondations sont les briques élémentaires sur lesquelles tous les composants seront construits. Prendre le temps de les définir correctement à cette étape évite des problèmes en cascade sur tout le reste du design system.

3) Construire les composants

Créer chaque composant comme un "Component" Figma avec ses variantes grâce aux Component Properties et aux Variants. Un bouton, par exemple, aura des variantes pour le type (primary, secondary, ghost), la taille (small, medium, large) et l'état (default, hover, disabled). Utiliser l'Auto-layout pour que les composants s'adaptent au contenu (un bouton qui s'agrandit avec son texte, une carte qui s'adapte à la longueur du paragraphe). Construire les composants du plus simple au plus complexe : commencer par les éléments atomiques (boutons, badges, champs de saisie) avant de passer aux composants composés (cartes, en-têtes de section, formulaires).

4) Documenter les règles d'utilisation

Ajouter des annotations pour chaque composant : dans quel contexte l'utiliser, quelles variantes choisir selon la situation, quelles sont les règles à respecter. Créer des exemples visuels de bon usage ("do") et de mauvais usage ("don't"). Par exemple : "Utiliser le bouton primaire pour l'action principale de la page. Ne pas utiliser deux boutons primaires côte à côte." Cette documentation peut prendre la forme de frames dédiées dans le fichier Figma, organisées par catégorie de composant.

5) Organiser et partager

Structurer la bibliothèque par catégories logiques : une section pour les fondations (couleurs, typographies, espacements), une section pour les composants UI (boutons, formulaires, cartes, navigation), et une section pour les patterns (sections de page, templates). Publier la bibliothèque comme Team Library dans Figma pour que tous les designers du projet y aient accès et puissent utiliser les composants dans leurs maquettes. Chaque modification de la bibliothèque publiée se propage automatiquement à tous les fichiers qui l'utilisent, ce qui garantit la cohérence à l'échelle du projet.

‍

Du design system Figma au développement Webflow

La qualité d'un design system dans Figma ne sert à rien s'il n'est pas fidèlement traduit dans le développement. C'est la transition entre le design et le code qui détermine si le site final respecte les règles définies dans le système, ou si les incohérences réapparaissent pendant l'intégration.

Chez BeBranded, le workflow suit un chemin précis : conception du design system et des maquettes dans Figma, puis développement dans Webflow avec la méthodologie Client-First de Finsweet. Client-First est un framework de classes CSS pour Webflow qui traduit la logique du design system en code structuré, maintenable et universel.

Les tokens de couleurs définis dans Figma (color-primary, color-secondary, neutral-100, etc.) deviennent des variables CSS globales dans Webflow. Si la couleur primaire change, elle est modifiée dans les variables Webflow et toutes les pages se mettent à jour automatiquement, exactement comme dans Figma. Les tokens typographiques (heading-1, body-base, caption) deviennent des classes de texte réutilisables dans Webflow, ce qui garantit que chaque titre et chaque paragraphe du site utilise les mêmes propriétés que celles définies dans le design system. Les espacements sont standardisés en rem plutôt qu'en pixels, ce qui assure à la fois la cohérence avec le système et le respect des préférences d'accessibilité des utilisateurs.

Les composants Figma sont reconstruits comme des composants Webflow (Components) avec les mêmes variantes. Un bouton qui a trois variantes dans Figma (primary, secondary, ghost) a trois classes correspondantes dans Webflow. Les patterns (section hero, footer, formulaire de contact) sont construits à partir de ces composants, exactement comme dans Figma. Client-First impose une convention de nommage universelle pour les classes CSS, ce qui signifie que n'importe quel développeur Webflow peut reprendre le projet et comprendre immédiatement la structure sans documentation supplémentaire.

Le plugin Figma-to-Webflow existe et permet d'exporter des éléments directement dans Webflow. Cependant, le code généré ne suit pas de convention de nommage, ne produit pas de structure responsive optimale, et crée des classes difficiles à maintenir. Pour les projets professionnels, un rebuild Client-First à partir des maquettes Figma est largement préférable. Notre article détaillé sur le choix entre plugin Figma-to-Webflow et rebuild Client-First couvre les avantages et limites de chaque approche.

Le client reçoit à la fin du projet le fichier Figma complet (design system + maquettes) et le site Webflow structuré en Client-First. Ces deux livrables forment la documentation complète du projet : le Figma pour le design, le Webflow pour l'implémentation. Si le site doit évoluer (nouvelles pages, nouvelles fonctionnalités, animations GSAP), le design system sert de cadre pour que les ajouts restent cohérents avec l'existant. Vous pouvez voir des exemples concrets de cette approche dans nos réalisations.

‍

Erreurs fréquentes avec les design systems

La première erreur est de confondre design system et UI kit. Un UI kit est une collection d'éléments graphiques prêts à l'emploi. C'est utile, mais ce n'est pas un système. Un design system inclut les fondations (tokens), les composants documentés, les patterns, les règles d'utilisation et la gouvernance. Utiliser un UI kit sans les couches manquantes produit des interfaces visuellement correctes mais structurellement fragiles, qui se dégradent dès que le projet évolue.

La deuxième erreur est de créer un design system trop complexe dès le départ. Vouloir documenter 80 composants, 12 variantes de bouton et 200 tokens de couleurs avant même d'avoir créé la première page est un piège. La bonne approche est de commencer par un MVP du design system : les fondations (couleurs, typographies, espacements) et les composants essentiels (boutons, cartes, formulaires, navigation). Le système se complète ensuite progressivement, au fur et à mesure que le projet le demande. Un design system est un produit vivant, pas un livrable figé.

La troisième erreur est de ne pas documenter les composants. Un composant sans documentation est un composant qui sera mal utilisé. Si rien ne dit quand utiliser le bouton primaire plutôt que le secondaire, ou quel espacement respecter entre une section et la suivante, chaque designer et chaque développeur interprétera les règles à sa façon. Les incohérences réapparaissent, et le design system perd sa raison d'être.

La quatrième erreur est de ne pas faire évoluer le design system. Un design system créé au démarrage du projet doit être mis à jour quand de nouveaux besoins apparaissent : un nouveau type de carte, une nouvelle variante de bouton, un nouveau pattern de section. S'il reste figé dans sa version initiale pendant que le site évolue, les designers finissent par créer des éléments en dehors du système, et la dette de design s'accumule.

La cinquième erreur est de négliger les tokens et d'utiliser des valeurs "en dur" à la place. Écrire le code hexadécimal #2563EB directement dans un composant au lieu d'utiliser le token color-primary rend le design system fragile. Si la couleur change, il faut retrouver et modifier chaque occurrence manuellement. Les tokens existent précisément pour éviter ce problème : ils centralisent les valeurs et permettent de les modifier en un seul endroit.

La sixième erreur est de ne pas impliquer le développeur dans la conception du design system. Un designer qui travaille seul peut créer des composants visuellement parfaits mais techniquement impossibles ou très coûteux à développer dans Webflow ou tout autre CMS. L'échange entre le designer et le développeur pendant la construction du système permet d'anticiper ces problèmes et de trouver des solutions réalistes avant qu'elles ne coûtent cher.

La septième erreur est de créer un design system sans projet concret. Un design system doit être au service d'un produit réel. Construire un système théorique "pour plus tard" sans site ni maquette concrète produit un système qui ne correspond à aucun besoin réel et qui devra être largement revu quand le vrai projet commence.

‍

Checklist : créer votre design system

1. Auditer l'existant (si un site existe déjà) : identifier les incohérences visuelles, les éléments récurrents et les styles utilisés de facto.
2. Définir la palette de couleurs avec des tokens nommés (primary, secondary, neutrals, semantic) dans les Color Styles de Figma.
3. Définir les styles typographiques (heading-1 à heading-6, body, caption, label) dans les Text Styles de Figma, avec les familles, tailles, graisses et hauteurs de ligne.
4. Définir le système d'espacements avec des paliers cohérents (8, 16, 24, 32, 48, 64 en pixels, ou leurs équivalents en rem) dans les Variables Figma.
5. Créer les composants essentiels (boutons, champs de formulaire, cartes, navigation) comme des Components Figma avec leurs Variants et l'Auto-layout.
6. Documenter chaque composant : contexte d'utilisation, variantes disponibles, états (hover, focus, disabled), exemples do et don't.
7. Construire les patterns récurrents (section hero, section témoignages, footer, formulaire de contact) à partir des composants existants.
8. Organiser la bibliothèque par catégories (fondations, composants, patterns) et la publier comme Team Library dans Figma.
9. Valider le design system avec le développeur avant de commencer l'intégration, pour vérifier la faisabilité technique de chaque composant.
10. Traduire les tokens Figma en variables CSS dans Webflow (couleurs, typographies, espacements).
11. Reconstruire les composants Figma comme des composants Webflow en suivant la méthodologie Client-First pour un code propre et maintenable.
12. Planifier des mises à jour régulières du design system au fur et à mesure que le projet évolue (nouveaux composants, nouvelles variantes, ajustements de tokens).

‍

Conclusion

Un design system est la fondation structurelle d'un site web cohérent, maintenable et scalable. Il centralise les décisions de design dans une source unique, fournit des composants réutilisables documentés, et crée un langage commun entre toutes les parties prenantes du projet. Ce n'est pas un exercice réservé aux grandes entreprises : même un site de quelques pages gagne en qualité et en efficacité avec un système structuré.

La bonne approche est de commencer par un MVP (fondations + composants essentiels), de le construire dans Figma avec des tokens, des composants et une documentation claire, puis de le traduire fidèlement dans Webflow avec la méthodologie Client-First. Ce workflow garantit que le design system ne reste pas un livrable Figma isolé, mais qu'il se retrouve dans chaque page du site en production.

Si vous avez un projet de site web et souhaitez un accompagnement de la conception du design system Figma au site Webflow en production, vous pouvez nous contacter pour un premier échange. Nous partirons de vos objectifs pour construire un système adapté à votre projet et à vos ambitions de croissance.