Un système de design n’est pas une bibliothèque de composants.

Ce qui se dégrade, et à quel moment

La trajectoire est reconnaissable. Une équipe produit une bibliothèque soignée : boutons, champs, cartes, tableaux, documentation. L’adoption démarre bien, parce que les nouveaux écrans y gagnent immédiatement.

Puis une équipe a besoin d’un tableau avec une colonne figée. Le composant standard ne le fait pas. Elle en crée une variante locale, ce qui est raisonnable. Six mois plus tard, quatre variantes de tableau coexistent, deux d’entre elles corrigent le même défaut d’accessibilité différemment, et personne ne sait laquelle utiliser pour un nouvel écran.

Le système n’a pas échoué techniquement. Il a échoué parce qu’il n’existait aucun chemin pour faire remonter un besoin légitime. Une exception qui ne peut pas devenir une évolution du système devient nécessairement une divergence.

Un système est d’abord un ensemble de décisions

Les travaux de vulgarisation du Nielsen Norman Group insistent sur cette distinction : une bibliothèque de composants est un livrable, un système de design est une pratique qui inclut des principes, une documentation, une gouvernance et des personnes qui la portent.

Les décisions en question sont concrètes et rarement écrites : à quel moment utilise-t-on une fenêtre modale plutôt qu’une page ? comment annonce-t-on une erreur de formulaire ? quel est l’intervalle d’espacement autorisé ? que fait l’interface pendant un chargement long ? Ces réponses valent davantage que le code qui les implémente, parce qu’elles sont ce qu’une nouvelle équipe doit connaître pour rester cohérente.

Une bibliothèque répond à la question « quoi utiliser ». Un système répond à la question « quoi faire quand rien ne convient ».

Les jetons comme contrat entre conception et code

Entre les maquettes et l’implémentation, la source de divergence la plus banale reste la valeur brute : une couleur saisie à la main, un espacement arrondi au jugé, une taille de police ajustée localement. Les jetons de design — des valeurs nommées, partagées et versionnées — suppriment cette catégorie entière de désaccords.

Un groupe communautaire du W3C travaille précisément à normaliser le format d’échange de ces jetons, afin qu’outils de conception et bases de code puissent s’appuyer sur une même définition. L’intérêt n’est pas la nomenclature : c’est qu’un changement de valeur cesse d’être une négociation entre deux équipes pour devenir une mise à jour unique et traçable.

La gouvernance minimale qui suffit

Beaucoup d’organisations reculent devant le mot gouvernance, en imaginant un comité. Ce n’est pas ce qui est nécessaire. Quatre éléments suffisent, et leur absence explique la plupart des échecs observés.

Le dernier point mérite une attention particulière, parce qu’il change la conversation avec la direction. Le nombre de composants publiés est un indicateur d’activité, pas de valeur. La proportion d’écrans réellement construits avec le système, elle, indique si l’investissement produit de la cohérence — et rend visible le moment où l’adoption cesse de progresser.

Un système de design utile ressemble donc moins à un catalogue qu’à un accord de travail : un petit nombre de décisions assumées, un moyen clair de les faire évoluer, et quelqu’un dont c’est la responsabilité. Les composants viennent après, et ils suivent.