Un design system, même pour un petit site
Un design system n'est pas réservé aux grosses équipes
Un design system sert dès le premier petit site, et l'idée qu'il faut une grosse équipe pour le justifier est fausse. Même un site vitrine de cinq pages manipule des couleurs, des espacements, des tailles de texte, des boutons répétés partout. Ces décisions de design existent, que vous les formalisiez ou non. La seule question est de savoir si elles vivent au même endroit ou si elles se dispersent en dur dans le code.
Sans cadre, c'est la dispersion qui gagne. Un bleu légèrement différent ici, un padding au jugé là, une taille de titre recopiée à la main sur trois pages. Tout va bien jusqu'au jour où le client veut changer sa couleur principale. On chasse alors les occurrences une par une, en priant de n'en oublier aucune. Poser quelques règles dès le départ évite cette dette, pour un coût initial quasi nul. Ce n'est pas de la sur-ingénierie, c'est de l'hygiène de base.
Les tokens, ma base de travail
Ma fondation, ce sont les tokens : des décisions de design transformées en variables réutilisables. Couleurs, échelle d'espacement, rampe typographique, rayons de bordure, ombres. Au lieu d'écrire une valeur en dur à chaque usage, je la nomme une fois et je la réutilise partout. Le design cesse d'être une suite de valeurs éparpillées pour devenir un petit système cohérent où chaque choix a sa place.
Concrètement, je déclare ces tokens en variables CSS sur le :root, puis je les expose dans la configuration Tailwind pour les manipuler comme des classes utilitaires. Un seul endroit fait foi. Changer la couleur de marque devient une ligne à modifier, répercutée sur tout le site instantanément. Cette approche gère aussi le mode sombre proprement : je redéfinis les mêmes tokens dans un contexte différent, et toute l'interface suit sans que je touche au reste. La cohérence n'est plus un effort de discipline, elle est structurelle.
Une poignée de composants, pas une bibliothèque
Au-dessus des tokens, je construis quelques composants réutilisables, et seulement quelques-uns : bouton, champ de formulaire, carte, conteneur, titre de section. Pas une bibliothèque exhaustive qui couvrirait des cas que ce site ne rencontrera jamais. Juste les briques qui reviennent réellement d'une page à l'autre. L'objectif n'est pas la complétude, c'est d'éliminer la répétition là où elle existe vraiment.
Chaque composant encapsule ses variantes et ses états : un bouton primaire, secondaire, désactivé, en chargement. Cela garantit qu'un bouton ressemble à un bouton sur toutes les pages, sans que j'aie à y penser. Le bénéfice est double. La cohérence visuelle devient automatique, parce qu'on passe toujours par la même brique. Et l'ajout d'une page se fait par assemblage de composants existants plutôt que par copier-coller de blocs entiers. Un nouveau besoin se traduit alors par une variante propre du composant, pas par une version sauvage qui dérive de l'original.
Éviter la sur-ingénierie
Le vrai piège d'un design system sur petit site, c'est d'en faire trop. Je n'ai pas besoin de Storybook, d'un thème abstrait à dix niveaux d'indirection, ni d'un package publié séparément pour cinq pages. Ces outils sont précieux à grande échelle et inutiles ici ; les installer ajoute de la complexité sans rien rapporter. Le design system reste un moyen, jamais une fin.
Je m'impose donc deux règles simples. La première : j'extrais un composant quand je le répète une troisième fois, pas avant. Anticiper une réutilisation qui n'arrive pas, c'est créer de l'abstraction pour rien. La seconde : je nomme mes tokens par intention plutôt que par valeur. « couleur-primaire » plutôt que « bleu-600 », pour que le sens survive à un changement de palette. Le jour où le bleu devient vert, le nom reste juste.
Bien calibré, ce petit système fait gagner du temps dès la deuxième page et rend les évolutions futures presque indolores. Dimensionné à la taille du projet, ni plus ni moins, il transforme un site qu'on bricole en un site qu'on fait évoluer sereinement. C'est exactement le niveau de structure que je cherche : assez pour tenir dans la durée, pas assez pour peser.
Headless CMS : donner les clés du contenu sans casser le site