Le scénario se répète : une équipe passe trois mois à construire un système de design complet (couleurs, typographies, composants, règles d’espacement). Six mois plus tard, la moitié des nouvelles pages est faite à côté, avec des boutons légèrement différents et des marges approximatives.
Le système n’est pas mauvais. Il est simplement plus coûteux à utiliser qu’à contourner.
Les quatre raisons de l’abandon
1. Il est trop loin du code. Un système qui vit dans un fichier de maquette et une documentation séparée oblige à traduire à la main. Cette traduction est exactement l’endroit où les écarts apparaissent. Tant que les jetons de design ne sont pas la source unique dont le code tire ses valeurs, la divergence est mécanique.
2. Il ne couvre pas le cas qu’on a. Un système qui traite les huit composants faciles laisse chacun improviser sur le neuvième. Et le neuvième (un tableau dense, un formulaire à étapes, un état d’erreur partiel) est celui qui prend du temps.
3. Personne ne sait s’il est respecté. Sans mesure, la dérive est invisible jusqu’au jour où elle est irréparable. Un simple relevé des couleurs et des tailles réellement présentes dans le code en dit plus long que n’importe quelle réunion.
4. Il n’a pas de propriétaire. Un système sans personne responsable de l’arbitrage devient un dépôt d’idées contradictoires. Il faut quelqu’un dont le travail inclut explicitement de dire non.
Ce qu’un système doit contenir en priorité
Pas les composants, mais les décisions. Un système utile commence par la liste courte de ce qui n’est plus discutable : l’échelle d’espacement, l’échelle typographique, la palette et ses usages, les rayons, les durées d’animation.
Ces décisions valent plus que trente composants, parce qu’elles s’appliquent aussi aux écrans que personne n’avait prévus. Un composant couvre un cas ; une échelle couvre tous les cas.
L’accessibilité se met dedans, pas à côté
Les contrastes, les tailles de cible tactile, les états de focus visibles, les libellés de champs : ce sont des propriétés de composants, pas un chantier séparé. Placés dans le système, ils sont acquis une fois. Traités après coup, ils sont à refaire écran par écran.
C’est l’argument le plus fort en faveur d’un système, et le moins souvent avancé.
Ce qui est surestimé
L’exhaustivité. Un système de quarante composants dont douze servent est plus difficile à maintenir qu’un système de quinze composants tous utilisés. Chaque composant inutilisé est une dette : il faut le tester, le documenter, le migrer à chaque évolution.
Surestimée aussi, la refonte complète. Un système se construit mieux par extraction (on part de l’existant, on relève ce qui se répète, on normalise progressivement) que par table rase, qui produit un beau système et un site qui ne l’utilise pas.