Design system pour petites équipes : commencer par les tokens

« Design system », ça sonne comme un truc d’entreprise avec une équipe dédiée et un site de documentation. Pourtant, une petite équipe en a encore plus besoin : avec deux designers et trois développeurs, chaque incohérence se corrige à la main, encore et encore. L’astuce, c’est d’en construire un petit, dans le bon ordre.

Ce qu’est vraiment un petit design system

Trois niveaux, et seuls les deux premiers sont nécessaires pour démarrer :

Les tokens — des décisions nommées : couleurs, tailles de texte, espacements, arrondis, ombres, animations.
Les composants — les briques réutilisables construites à partir de ces tokens : boutons, champs, cartes.
Les patterns et les règles — la façon dont les composants se combinent : formulaires, états vides, mises en page. À rédiger plus tard, quand vous vous surprenez à répéter les mêmes explications.

La plupart des équipes commencent au niveau deux et construisent une superbe bibliothèque de boutons sur 37 gris légèrement différents. Commencez par les tokens.

Étape 1 : les tokens

Couleur

Définissez deux niveaux. Les tokens primitifs forment la palette ; les tokens sémantiques disent à quoi sert une couleur :

tokens.css

:root {
  /* Primitives */
  --blue-500: #0777d2;
  --blue-600: #0563b0;
  --gray-50: #f8f9fa;
  --gray-900: #111418;
  --red-600: #d92d20;

  /* Semantic — components only use these */
  --color-bg: #ffffff;
  --color-surface: var(--gray-50);
  --color-text: var(--gray-900);
  --color-text-muted: #5b6370;
  --color-primary: var(--blue-500);
  --color-primary-hover: var(--blue-600);
  --color-danger: var(--red-600);
  --color-border: #e3e6ea;
}

[data-theme='dark'] {
  --color-bg: #0d1117;
  --color-surface: #161b22;
  --color-text: #e6edf3;
  --color-border: #30363d;
}

Les composants ne référencent que les tokens sémantiques. C’est ce qui fait d’un mode sombre, d’un changement d’identité ou d’un client en marque blanche une modification d’un seul fichier.

Profitez-en pour vérifier le contraste : le texte courant exige au moins 4,5:1 par rapport à son fond (WCAG AA), le grand texte 3:1.

Typographie

Choisissez une ou deux familles et une échelle de six à huit tailles. Une échelle modulaire (chaque palier environ 1,2 à 1,25 fois le précédent) garde un rythme cohérent :

css

:root {
  --text-xs: 0.75rem;
  --text-sm: 0.875rem;
  --text-base: 1rem;
  --text-lg: 1.25rem;
  --text-xl: 1.5rem;
  --text-2xl: 2rem;
  --text-3xl: 2.75rem;
  --leading-tight: 1.15;
  --leading-normal: 1.6;
}

Espacements, arrondis, ombres, animations

Une échelle d’espacement par pas de 4 ou 8 pixels (4, 8, 12, 16, 24, 32, 48, 64), deux ou trois arrondis, deux ou trois ombres, et deux ou trois durées avec une seule courbe d’accélération. Chaque valeur hors échelle est une décision que quelqu’un devra reprendre.

Avec Tailwind CSS

Si vous utilisez Tailwind, le thème est votre fichier de tokens. Faites-le pointer vers les variables CSS pour que les mêmes tokens pilotent les deux :

tailwind.config.ts

export default {
  theme: {
    extend: {
      colors: {
        bg: 'var(--color-bg)',
        surface: 'var(--color-surface)',
        text: 'var(--color-text)',
        muted: 'var(--color-text-muted)',
        primary: { DEFAULT: 'var(--color-primary)', hover: 'var(--color-primary-hover)' },
        danger: 'var(--color-danger)',
        border: 'var(--color-border)',
      },
    },
  },
}

Étape 2 : les dix premiers composants

Ils couvrent la plupart des écrans d’un produit :

Bouton — principal, secondaire, discret, destructif ; tailles ; états de chargement et désactivé
Champ de texte — avec libellé, aide et message d’erreur
Liste déroulante / combobox
Case à cocher, bouton radio et interrupteur
Carte — le conteneur de presque tout
Modale / dialogue — avec piège à focus et fermeture par Échap
Toast — pour les confirmations et les erreurs
Onglets
Badge / étiquette
État vide — une icône, une ligne de texte, une action

Ne construisez pas l’accessibilité de zéro : des bibliothèques headless comme Radix UI, React Aria ou Headless UI gèrent le focus, la navigation au clavier et l’ARIA, et vous les habillez avec vos tokens. shadcn/ui est un point de départ apprécié, qui copie des composants basés sur Radix dans votre propre code, où ils vous appartiennent.

Chaque composant a besoin de ses états

Ce qui distingue une démo d’un produit, ce sont les états. Pour chaque composant, concevez et développez : par défaut, survol, focus (visible !), actif, désactivé, chargement, erreur et vide. Les états de focus sont les plus souvent oubliés — et ce sont ceux dont dépendent les personnes qui naviguent au clavier.

Étape 3 : garder Figma et le code synchronisés

Les mêmes noms des deux côtés. Si Figma l’appelle color/text/muted et le code --gray-500, ils vont diverger. Utilisez les Variables Figma avec les noms sémantiques de votre fichier de tokens.
Une seule source de vérité pour les valeurs. Une petite équipe peut simplement convenir que le code fait foi, et mettre à jour les variables Figma quand les tokens changent. Les équipes plus grandes exportent les variables en JSON et en génèrent le CSS (Style Dictionary ou Tokens Studio).
Les composants Figma reflètent les props du code. Une variante Figma size=sm, variant=secondary doit correspondre à <Button size="sm" variant="secondary">.

Étape 4 : ne documenter que ce qui se répète

La documentation n’a pas besoin d’être un site. Une seule page dans votre dépôt, avec la liste des tokens, une capture de chaque composant et quelques règles (« un seul bouton principal par écran », « les actions destructives demandent confirmation »), suffit. Ajoutez une règle chaque fois que vous expliquez deux fois la même chose en revue.

Les erreurs que je vois le plus souvent

Trop de variantes. Cinq styles de boutons que personne ne sait distinguer. Commencez avec trois.
Les valeurs en dur qui reviennent en douce. Une règle de lint ou un point de check-list de revue de code (« aucune valeur hexadécimale hors de tokens.css ») garde le système honnête.
Concevoir des composants dont aucun écran n’a encore besoin. Créez un composant quand le deuxième écran en a besoin, pas avant.
Considérer le système comme terminé. C’est un produit dont votre propre équipe est l’utilisatrice. Revisitez-le tous les quelques mois.

Combien de temps ça prend ?

Pour un petit produit, une première version — tokens, dix composants avec leurs états, variables Figma et un guide d’une page — représente environ une à trois semaines de design et de développement cumulés. Elle est rentabilisée dès que vous construisez un nouvel écran en un après-midi, ou activez le mode sombre en une journée.

Vous partez de zéro, sans logo ni marque ? Commencez par là — voir l’identité de marque dont une startup a besoin au lancement.