Design system : par où commencer ?
Tokens, composants, documentation — le guide étape par étape pour créer votre design system.
C'est quoi exactement un design system (et ce que ce n'est pas)
On entend "design system" partout. Et souvent, on confond avec une bibliothèque de composants ou un simple kit UI Figma. La différence est fondamentale.
Un kit UI, c'est une collection de boutons, de cartes, de formulaires — des pièces de Lego joliment rangées. Un design system, c'est tout ça plus les règles qui gouvernent comment ces pièces s'assemblent, pourquoi elles existent, et comment elles évoluent dans le temps. C'est autant un outil qu'une documentation vivante, une philosophie de travail partagée entre designers et développeurs.
En clair : un design system répondra à la question "pourquoi ce bouton est-il violet et pas bleu ?" là où un kit UI se contente de te montrer un bouton violet.
Pour une agence comme Var Studio, ça change tout. Plutôt que de recréer les mêmes patterns de zéro sur chaque projet, on capitalise. On documente. On code vite — et on code juste.
Les design tokens : la fondation de tout
Si les composants sont la maison, les tokens sont les matériaux. Ce sont les valeurs atomiques qui définissent visuellement votre système : couleurs, typographie, espacements, ombres, rayons de bordure, durées d'animation.
Concrètement, un token ressemble à ça :
color.primary→#7B2FFFspacing.md→16pxradius.card→12pxshadow.elevated→0 4px 24px rgba(0,0,0,0.12)font.size.h2→2rem
L'idée clé : on ne hardcode jamais une valeur dans un composant. On référence toujours un token. Résultat ? Si demain le violet passe à #6318E8, on change un seul endroit et tout le système se met à jour.
Les tokens se déclinent en deux niveaux :
- Tokens primitifs — les valeurs brutes (
purple-500,gray-100). Ils ne sont jamais utilisés directement dans les composants. - Tokens sémantiques — les rôles (
color.background.primary,color.text.muted). C'est ce qu'on utilise dans le code.
Avec Tailwind CSS v4, on a une mécanique parfaite pour ça : les variables CSS définies dans globals.css via @theme inline sont des tokens. Chaque variable --color-primary, --spacing-section... devient un token utilisable dans toute l'app. C'est du design system natif, sans overhead.
L'architecture des composants : atomes, molécules, organismes
Une fois les tokens posés, on construit les composants. La méthode Atomic Design de Brad Frost reste la référence — pas parce que c'est tendance, mais parce qu'elle force à penser en niveaux de complexité.
Les atomes — les briques irréductibles :
- Bouton, input, label, badge, icône, avatar, séparateur
Les molécules — assemblages d'atomes avec une fonction précise :
- Champ de formulaire (label + input + message d'erreur)
- Carte de projet (image + titre + tags)
- Item de navigation (icône + texte + indicateur actif)
Les organismes — sections complètes et autonomes :
- Formulaire de contact complet
- Barre de navigation
- Section héro
- Grille de portfolio
La règle d'or : un composant ne devrait jamais connaître son contexte. Un bouton ne sait pas s'il est dans une modale ou dans un footer. Il reçoit des props, il s'affiche. Cette indépendance est ce qui rend un système vraiment réutilisable.
Pour les projets Next.js + TypeScript qu'on produit chez Var Studio, ça se traduit par des interfaces TypeScript propres sur chaque composant : les props sont la documentation.
Documentation : Storybook, Figma et les deux à la fois
Un design system non documenté est un design system mort. Personne ne l'utilise parce que personne ne sait ce qu'il contient.
Figma reste l'outil de référence côté design. Les Variables (depuis 2023) permettent de mapper directement les tokens dans Figma : même nomenclature, même hiérarchie qu'en code. Quand designer et développeur partagent les mêmes noms de tokens, les allers-retours s'évaporent.
Storybook est l'équivalent côté code. Chaque composant a sa story — une page isolée qui montre toutes ses variantes, ses états (hover, focus, disabled, error), ses différentes tailles. Ça sert à trois choses :
- Développer en isolation sans avoir à lancer toute l'app
- Tester visuellement les régressions
- Générer une documentation interactive pour toute l'équipe
L'idéal : Figma + Storybook en miroir. Chaque composant existe dans les deux, avec les mêmes noms, les mêmes variantes. Des outils comme Storybook Connect permettent même d'embarder les stories directement dans Figma.
Pour une petite agence, pas besoin de tout faire d'un coup. Une bonne documentation Notion avec les tokens, les patterns d'usage et les interdits ("ne jamais utiliser ce bouton sans label") vaut déjà énormément.
Faut-il vraiment un design system ? (la vraie question)
Soyons honnêtes : non, pas toujours.
Un design system demande un investissement initial significatif. Pour un site vitrine one-shot de cinq pages, créer un système complet avec Storybook et tokens hiérarchisés est du sur-engineering pur. Ça prend du temps, ça coûte de l'argent, et le client ne le voit pas.
Voici le vrai critère : la réutilisabilité dans le temps.
Tu as besoin d'un design system si :
- Tu travailles sur un produit évolutif (SaaS, app, e-commerce actif)
- Plusieurs développeurs touchent au même codebase
- Le projet va durer plus d'un an avec des mises à jour régulières
- Tu veux un white-label à décliner pour plusieurs clients
Tu peux t'en passer si :
- C'est un site vitrine avec peu de composants récurrents
- Tu es seul sur le projet pour une durée déterminée
- Le budget est serré et les besoins sont stables
Chez Var Studio, notre approche est pragmatique : on pose toujours les tokens (ça coûte une heure et ça paie tout de suite), on structure les composants avec l'Atomic Design en tête, mais on ne lance Storybook que quand la taille du projet le justifie. C'est le design system à l'échelle.
Les outils et références pour démarrer vite
Quelques ressources qu'on utilise ou qui ont notre respect :
Références existantes à étudier :
- Material Design (Google) — la référence absolue en termes de documentation, même si l'esthétique est à prendre ou laisser
- Radix UI — bibliothèque de primitives accessibles sans style imposé, parfaite comme base
- shadcn/ui — composants Radix + Tailwind préconstruits, qu'on copie-colle et adapte plutôt qu'installer comme dépendance. L'approche "own your components" est exactement ce qu'on préconise
L'outillage :
- Figma + Variables pour les tokens design
- Tailwind CSS comme système de tokens en production
- Storybook pour la documentation interactive
- Zeroheight ou Supernova pour les équipes qui veulent une doc unifiée Figma + code
La règle des trois "C" pour évaluer n'importe quel composant de votre système :
- Cohérent — respecte-t-il les tokens et les patterns établis ?
- Composable — peut-il s'assembler avec d'autres composants sans friction ?
- Couvert — a-t-il des états documentés (vide, chargement, erreur, succès) ?
Conclusion : commencer petit, mais commencer maintenant
Le meilleur design system est celui que ton équipe utilise réellement. Un fichier Figma impeccable que personne n'ouvre, c'est zéro. Un README avec cinq règles de couleurs que tout le monde lit, c'est déjà un système.
La vraie progression : tokens d'abord, composants ensuite, documentation en continu. Pas l'inverse.
Pour un premier projet, on recommande de poser les tokens couleurs et typographie dans Tailwind, de créer cinq à dix composants atomiques bien typés, et d'écrire un fichier COMPONENTS.md qui explique les conventions. Trois heures de travail pour des semaines d'itération plus fluides.
Un design system n'est pas un monument — c'est un outil vivant. Il grandit avec vos projets. Commencez petit, soyez consistent, documentez au fur et à mesure. Le reste suivra.
API REST vs GraphQL : le bon choix en 2026
Avantages, inconvénients et cas d'usage — on tranche le débat une bonne fois pour toutes.