Design systems : le moment où ça tient ou casse

Un design system ne meurt jamais d'un coup. Il s'érode : une exception acceptée ici, un composant dupliqué là, et six mois plus tard l'équipe produit a repris l'habitude de dessiner à côté du système.

Le point de bascule

Dans les projets que nous avons observés, le moment critique arrive toujours au même endroit : la première demande qui ne rentre pas dans le système. Ce que l'équipe fait de cette demande détermine la suite.

Un design system qu'on ne peut pas faire évoluer devient un design system qu'on contourne.

Les signaux d'érosion

• Des valeurs de couleur en dur réapparaissent dans les nouvelles pages.
• Deux composants portent le même nom dans Figma et dans le code, sans faire la même chose.
• Plus personne ne sait qui décide d'ajouter un token.

La gouvernance avant les tokens

Les systèmes qui survivent ne sont pas les mieux dessinés, ce sont ceux dont on sait qui les fait évoluer et à quel rythme. Un propriétaire identifié et un rituel de revue mensuel pèsent plus lourd qu'une bibliothèque exhaustive.

Ce qu'on recommande

Commencer petit et fermé : peu de composants, peu de tokens, mais aucune exception tolérée. Il est beaucoup plus simple d'ouvrir un système strict que de resserrer un système permissif.