Design system vs bibliothèque de composants : la différence qui coûte cher

Une bibliothèque de composants est un ensemble de parties d'interface codées et réutilisables avec des API définies. Un design system est l'ensemble complet des décisions qui régissent l'apparence et le comportement d'une interface — ainsi que les artefacts qui encodent ces décisions, dont l'un est généralement une bibliothèque de composants.

C'est exact, mais légèrement inutile, car cela ne vous aide pas à savoir lequel vous possédez. Voici un test pour y parvenir.

La plupart des équipes échouent à ce test et s'en étonnent, car la bibliothèque de composants semblait être la partie la plus difficile. C'était la partie la plus coûteuse. Mais ce n'était pas la partie qui détermine si le produit possède sa propre identité.

Cette dernière ligne mérite d'être lue deux fois. L'échec d'une bibliothèque de composants est visible : deux sélecteurs de date, trois implémentations de boutons, un bug corrigé dans l'un et pas dans l'autre. L'échec d'un design system est invisible de l'intérieur : tout est cohérent, rien ne cloche, et le produit pourrait être n'importe lequel.

C'est ici que cela devient contre-intuitif. L'adoption d'une bibliothèque de composants bien conçue rend parfois un produit *plus* générique, et non moins ; il est donc essentiel d'en comprendre le mécanisme plutôt que de blâmer la bibliothèque.

Une bibliothèque est livrée avec des valeurs par défaut. Ces valeurs sont, par nécessité, neutres — elles doivent fonctionner pour des milliers de produits sans lien entre eux, elles encodent donc la version la moins tranchée de chaque décision. En l'installant, vous héritez d'un ensemble complet de décisions de design choisies spécifiquement pour être inoffensives.

Avant la bibliothèque, le produit n'avait pas de système et semblait incohérent. Après, il a un système, mais c'est celui de quelqu'un d'autre, optimisé pour une généralité maximale. L'incohérence est résolue, mais un problème d'identité est créé — et comme ce second problème ne produit aucune erreur, il reste anonyme pendant longtemps.

Ceci n'est pas un argument contre les bibliothèques de composants. C'est l'argument selon lequel en installer une ne réalise que la moitié du travail, et la moitié accomplie est celle qui était déjà visible.

Plusieurs termes adjacents sont utilisés indifféremment. Ce ne sont pas des synonymes, mais des segments différents.

Un ensemble de tokens mérite une attention particulière car c'est l'artefact le plus souvent confondu avec un système complet. Un fichier de valeurs nommées est réellement nécessaire, mais il n'indique à personne l'usage autorisé de --color-primary — or, c'est cette décision qui détermine si l'interface paraît sobre ou comme un template thématique.

Quatre éléments, dont aucun ne peut résider dans l'API d'un composant, et qui décident tous de l'apparence du produit.

1. 1

   Règles de composition

   La manière dont les composants s'assemblent. Une seule action primaire par section. Contrôles liés groupés, contrôles non liés séparés par un palier d'espacement complet. Tableaux jamais imbriqués dans des cartes. Une bibliothèque de composants n'a aucune opinion sur ce qui entoure ses composants, alors que l'espace entre les composants représente la majeure partie d'un écran.

2. 2

   Densité et rythme

   S'agit-il d'un outil dense ou d'une surface marketing aérée. Un même bouton, avec un padding de 8px dans une ligne de tableau et de 16px dans un hero, produit deux produits différents. La bibliothèque supporte les deux et n'en choisit aucun.

3. 3

   Motifs

   L'élément spécifique et récurrent qui rend le design unique — un traitement particulier des angles, l'utilisation signature d'une ligne de séparation, une manière cohérente de tracer les graphiques. Les motifs font la différence entre un résultat correct et un résultat caractéristique, et ils n'ont aucune place dans l'API d'un composant.

4. 4

   Interdictions

   Ce qui ne doit jamais être fait. Pas de dégradés. Pas d'élévation d'ombre. Pas de graisse de police supérieure à 600. Aucune couleur en dehors de l'ensemble des tokens. Une bibliothèque de composants ne peut rien interdire, car interdire est la seule chose qu'une bibliothèque généraliste ne doit pas faire.

Le point d'interdiction dépasse le cadre du design. Le rôle d'une bibliothèque est d'être utilisable par de nombreux produits, ce qui signifie autoriser tout ce qui est raisonnable. Le rôle d'un system est de rendre un produit cohérent, ce qui nécessite d'écarter la majeure partie de ces options. Ils sont structurellement opposés, c'est pourquoi l'un ne peut se substituer à l'autre.

La différence est plus facile à observer sur une seule primitive. Une bibliothèque de composants vous fournit un Button avec une prop variant et n'a aucune opinion sur l'apparence de chaque variante. Un system décide — et cette décision couvre des états pour lesquels la bibliothèque n'a laissé qu'un emplacement :

Cette distinction était gérable lorsque des humains concevaient chaque écran. Un développeur ayant vu les dix derniers écrans assimilait les conventions non écrites et les reproduisait globalement. Le design system existait dans la tête des gens, sans documentation, et cela fonctionnait tant que les personnes restaient en poste.

Un agent de code IA n'a pas cette mémoire. Il lit ce qui se trouve dans le dépôt, écrit un écran et repart de zéro. Tout ce que l'équipe savait sans jamais l'avoir écrit est simplement absent, et l'agent comble le vide avec la moyenne statistique de tout ce qu'il a vu — c'est pourquoi les interfaces générées par IA convergent vers le même aspect.

Nous avons analysé 299 fichiers DESIGN.md écrits spécifiquement pour combler ce manque. Les chiffres montrent que la plupart n'y parviennent pas : 86 % spécifient les couleurs en hexadécimal brut sans rôle sémantique, 76 % n'énoncent aucune interdiction, 57 % ne définissent aucun motif, 69 % ne disent rien sur le mode sombre et 44 % ne contiennent aucune valeur de taille concrète. 54 % s'appuient sur au moins un adjectif vague, avec « clean » dans 39 % des cas et « moderne » dans 36 %.

Lues à la lumière des quatre points ci-dessus, ces données révèlent un corpus de fichiers qui documentent la bibliothèque de composants en l'appelant design system. Les règles de composition, la décision de densité, les motifs et les interdictions sont pour la plupart absents.

La bonne nouvelle est que vous n'avez rien à reconstruire. Si vous disposez d'une bibliothèque de composants et de tokens, la couche du design system est un document, et il est court.

## Intent

A dense tool for people who work in it for hours. Quiet, information-first.
Not a marketing surface: nothing here has to convince anyone of anything.

## Density

Controls: 8-12px padding. Table rows: 32px. Section gap: 32px.
Marketing surfaces run one step up on every value.

## Elevation

A surface step plus a 1px border. Never a box-shadow.

## Composition

One primary action per section. Related controls share a group;
unrelated ones are separated by a full spacing step.
Tables are never nested inside cards.

## Motifs

Section headings carry a 2px accent rule on the left edge.
Numeric columns are always tabular-nums, always right-aligned.

## Never

- No gradients
- No drop shadows
- No font-weight above 600
- No colour value outside the token set
- No border-radius above 12px

Trente lignes. Il ne contient rien que votre bibliothèque de composants sache déjà, mais tout ce dont un nouvel ingénieur — ou un agent — a besoin pour construire un écran qui appartient à votre produit plutôt qu'aux valeurs par défaut de la bibliothèque.

Presque toujours les deux, mais l'ordre dépend de votre problème actuel.