Design system

Ce qu'est un design system

Un design system est la source unique de vérité qui définit l'apparence, le comportement et la construction d'un produit. Il rassemble des composants réutilisables (boutons, formulaires, cartes, navigation), les règles visuelles qui les gouvernent et la documentation qui explique quand et comment utiliser chaque élément. Contrairement à une simple collection d'écrans, un design system est un produit à part entière: il est versionné, maintenu et utilisé aussi bien par les designers que par les développeurs.

L'objectif est la cohérence à grande échelle. Quand dix personnes travaillent sur la même interface répartie sur des dizaines de pages, le design system garantit qu'un bouton se ressemble et se comporte de la même façon partout, que les espacements suivent une seule échelle et que personne ne recrée un composant qui existe déjà. Il remplace les connaissances informelles et le copier coller par un standard partagé et documenté.

Les composantes essentielles

La plupart des design systems reposent sur quatre couches qui s'emboîtent.

• Les tokens: les plus petites décisions stockées sous forme de variables nommées, comme la couleur, l'espacement, la taille de police, le rayon de bordure ou l'ombre. Un token comme color-primary ou space-4 se réutilise partout et se modifie à un seul endroit.
• Les composants: des blocs d'interface réutilisables construits à partir des tokens, chacun avec ses états (par défaut, survol, désactivé, erreur) et ses variantes (primaire, secondaire, petit, grand).
• Les règles d'usage: les principes d'utilisation, qui couvrent le ton, l'accessibilité, les exemples à faire et à éviter, et le choix d'un composant plutôt qu'un autre.
• La documentation: la référence qui relie le tout, avec des exemples concrets, des extraits de code et les propriétés, pour que chacun adopte le système sans avoir à demander.

L'atomic design comme modèle mental

Beaucoup d'équipes organisent leurs composants avec l'atomic design, une méthode empruntée à la chimie. Les atomes sont les éléments les plus basiques (un label, un champ, un token de couleur). Les molécules combinent des atomes en petits groupes (un champ avec son label et son texte d'aide). Les organismes assemblent des molécules en sections complexes (une barre de navigation entière ou une carte produit). Les templates et les pages disposent ensuite ces organismes dans de vraies mises en page. Cette hiérarchie aide à raisonner sur la réutilisation: corrigez un atome une fois et chaque molécule, organisme et page qui l'utilise se met à jour automatiquement. L'atomic design n'est pas un règlement strict à appliquer à la lettre, mais une façon de penser qui garde les composants petits, combinables et prévisibles. En pratique, peu d'équipes nomment leurs dossiers atomes et molécules; ce qu'elles conservent, c'est la discipline de construire d'abord les plus petites briques réutilisables, puis d'assembler des motifs plus larges à partir d'elles, pour que la complexité reste maîtrisée à mesure que l'interface grandit.

Design system, charte graphique et kit UI

Ces trois notions sont souvent confondues, mais elles désignent des choses différentes. Une charte graphique est un document statique qui fixe les règles de marque: usage du logo, couleurs, typographie et ton. Elle dit à quoi ressemble la marque mais pas comment la construire. Un kit UI est une bibliothèque de composants visuels, généralement dans un outil comme Figma, que les designers glissent sur le canevas; il accélère les maquettes mais n'inclut ni code fonctionnel ni règles d'usage.

Un design system est le plus large des trois. Il englobe la charte et le kit UI, mais ajoute des composants codés, des tokens, de la documentation, une gouvernance et un versionnage. En résumé, la charte décrit, le kit UI fournit des pièces visuelles, et le design system offre un pont complet et maintenu entre le design et le code de production.

Quand il aide et quand il est excessif

Un design system devient rentable quand un produit a une vraie envergure ou une vraie durée de vie: plusieurs pages, plusieurs personnes qui touchent à l'interface, une feuille de route longue, ou plusieurs produits qui doivent former une même famille. Dans ces cas, l'investissement initial est récupéré de nombreuses fois grâce à une production plus rapide, moins d'incohérences et une intégration facilitée des nouveaux arrivants.

Il peut être excessif pour un petit site vitrine, une landing page isolée ou un prototype précoce dont les besoins changent chaque jour. Construire un système complet avant de savoir ce que l'on construit fait perdre du temps et fige les décisions trop tôt. Une approche pragmatique consiste à démarrer léger avec des tokens et une poignée de composants partagés, puis à faire grandir le système à mesure que les motifs se répètent. Les erreurs fréquentes sont de sur ingénierer trop tôt, de documenter des composants que personne n'utilise, et de laisser le système se désynchroniser du produit réel faute de responsable de sa maintenance.

Chez BeBranded

Chez BeBranded, nous construisons la plupart des sites dans Webflow avec la convention Client-First, qui offre un système de classes structuré et lisible se comportant comme un design system léger dès le premier jour. Nous définissons les tokens sous forme de variables globales (couleurs, espacements, typographie) et transformons les motifs récurrents en composants Webflow pour qu'un changement se propage sur tout le site. Pour les produits qui dépassent un simple site, nous étendons cette base en un système plus complet, avec des usages documentés et des conventions communes entre design et développement. Notre principe est la proportionnalité: assez de système pour rester cohérents et rapides, jamais au point de ralentir un projet qui n'en a pas besoin.