Design System

Un design system est l'ensemble structuré et documenté des règles, composants et ressources qui définissent l'interface d'un produit ou d'une marque : variables de style, bibliothèque de composants réutilisables, principes d'usage, et gouvernance pour le faire vivre. C'est un produit interne, pas un livrable figé.

Une charte graphique en PDF décrit une intention ; un kit d'interface fournit des écrans. Le design system, lui, fournit des pièces réellement utilisées en production, identiques dans l'outil de maquette et dans le code. La différence tient à ce dernier point : si la maquette et le code divergent, ce n'est plus un système, c'est une documentation.

Les couches qui le composent

• Les fondations, ou jetons de design : couleurs, échelle typographique, espacements, rayons, ombres, durées d'animation. Exprimés sous forme de variables, ils sont la source de vérité
• Les composants : bouton, champ, sélecteur, carte, modale, avec tous leurs états, y compris survol, focus clavier, désactivé, chargement et erreur
• Les patterns : combinaisons éprouvées, comme un formulaire complet, un tableau filtrable ou une page de connexion
• La documentation : ce que fait chaque composant, quand l'utiliser et surtout quand ne pas l'utiliser
• La gouvernance : qui arbitre, comment on propose un ajout, comment on publie une version sans casser l'existant

La chaîne outillée relie les variables de l'outil de maquette aux variables CSS du code, souvent via un thème appliqué au framework en place, et expose les composants dans un catalogue interactif.

Ce que ça change concrètement

• Une cohérence visuelle qui ne dépend plus de la vigilance de chacun
• Un gain de temps réel : on assemble au lieu de redessiner à chaque page
• L'accessibilité traitée une fois pour toutes au bon endroit : contrastes, taille des cibles, visibilité du focus
• Un vocabulaire commun entre design, développement et métier
• Une refonte moins coûteuse : changer une poignée de variables suffit à faire évoluer l'ensemble

Les pièges

• Le construire trop tôt et trop gros, avant d'avoir un usage réel qui le valide
• Laisser la maquette et le code se désynchroniser, jusqu'à ce que plus personne ne sache qui fait foi
• N'assigner aucun propriétaire : sans mainteneur ni budget, un design system meurt en quelques mois
• Verrouiller au point que les équipes le contournent ; il faut prévoir des échappatoires documentées
• Confondre bibliothèque de composants et design system : le code sans les règles ni la gouvernance ne tient pas

Quand le lancer

Dès que deux produits, deux équipes ou deux prestataires travaillent sur la même marque, l'investissement se rentabilise. Sur un site vitrine unique, un jeu de variables et une dizaine de composants documentés suffisent largement : viser plus serait du gaspillage.