Un design system est un ensemble partagé de décisions de conception, de composants réutilisables et de règles écrites qui donne à une équipe les moyens de construire des interfaces cohérentes sans tout redécider à chaque écran. Il sert à aligner conception, développement et rédaction, à loger l’accessibilité dans le socle et à faire évoluer un site sans le fragmenter.
Les cinq couches d’un design system
Un système de design complet se lit en cinq couches, de la plus abstraite à la plus humaine : des valeurs, des briques, des règles, une documentation et une gouvernance.
Des tokens qui nomment les décisions
La première couche est celle des design tokens. La spécification du Design Tokens Community Group, groupe communautaire hébergé par le W3C, les définit comme une information associée à un nom lisible par un humain, au minimum une paire nom et valeur. Ce nom circule partout à la place de la valeur brute.
Un bleu précis vit dans un token de base ; un token sémantique nommé « couleur d’action principale » pointe vers lui. Quand la teinte change, une seule définition bouge et tous les boutons suivent.
Des composants et leurs règles d’usage
La deuxième couche est la bibliothèque de composants : boutons, champs, alertes, onglets, en-têtes. Un composant d’interface associe une structure, une apparence et un comportement, avec tous ses états (repos, survol, focus clavier, erreur, désactivé), et n’appelle que des tokens.
La troisième couche écrit les règles d’usage : un seul bouton principal par écran, une alerte réservée aux informations bloquantes, des libellés qui décrivent le résultat de l’action. Sans elles, la bibliothèque tourne au catalogue où chacun pioche selon son humeur.
Une documentation et une gouvernance
La quatrième couche explique la raison de chaque décision et les détournements à éviter. La cinquième désigne qui tranche : une personne ou un petit groupe examine les demandes, arbitre et publie les changements. Élargie aux outils et aux circuits de conception, cette fonction prend le nom de DesignOps ; dans une petite structure, un responsable nommé en tient lieu.
Charte graphique, kit d’interface, guide de style : où passe la frontière
Trois termes voisins désignent chacun une pièce du système, jamais le tout.
- La charte graphique fixe l’identité visuelle : logo, couleurs, polices, principes de mise en page. Elle ne dit rien du comportement d’un formulaire mal rempli.
- Le kit d’interface propose des composants dessinés pour composer des écrans, sans leur code, leurs règles ni leur historique.
- Le guide de style encadre l’écriture et la présentation : registre, ponctuation, format des dates, majuscules.
Le système englobe ces pièces et y ajoute des tokens partagés entre conception et code, des composants réellement développés et une gouvernance. Test rapide : si changer la couleur principale oblige à retoucher des dizaines de fichiers à la main, l’équipe possède une charte, pas encore un système. Les corrections décrites dans cinq astuces pour améliorer un webdesign, échelle typographique resserrée et espacement fondé sur un multiple unique, sont justement les premières décisions qu’un système transforme en tokens.
À quoi sert un système de design au quotidien
Le bénéfice visible est la cohérence : un même objet se comporte partout de la même manière. Pour l’équipe, l’intérêt se situe ailleurs.
- Moins de décisions répétées : le rayon d’angle d’un bouton ne se discute plus à chaque écran.
- Une accessibilité traitée à la source : un contraste vérifié dans un token se retrouve dans chaque composant qui l’emploie.
- Un vocabulaire partagé : « alerte bloquante » veut dire la même chose pour tous.
- Des évolutions par petites touches : ajuster une teinte revient à modifier un token.
Le dispositif a ses limites. Il ne remplace ni l’observation des usagers ni la qualité des contenus et, trop rigide, il produit des pages interchangeables que les équipes finissent par contourner. Son effet sur les délais dépend de la taille du site et de la discipline de maintenance ; il se constate sur la durée.
À partir de quand un petit site en tire profit
Le seuil se mesure moins en pages qu’en nombre de mains. Un design system commence à rapporter dès que plusieurs personnes produisent des écrans sans se concerter à chaque fois. Les signaux qui l’annoncent :
- des nuances de bleu presque identiques et des marges choisies au jugé cohabitent déjà ;
- les mêmes questions reviennent à chaque section : quel gris, quel espacement, quel style de lien ;
- un deuxième site ou une application doit partager l’identité du premier ;
- une refonte partielle doit avancer sans casser l’existant.
Le troisième cas pèse lourd dans une architecture headless, où un même contenu alimente plusieurs interfaces qui, sans tokens communs, dérivent chacune de leur côté. Un site vitrine tenu par une seule personne, lui, se passe de gouvernance formelle : une page de référence des tokens, une poignée de composants et quelques règles préparent le terrain si l’équipe grandit.
Bâtir un premier socle, chantier par chantier
Inventorier ce qui existe
Tout commence par un relevé des variantes de boutons, de champs, de titres, de couleurs et d’espacements, classées par famille. Les doublons sautent aux yeux, gris presque jumeaux ou marges inventées pour une seule page. Chacun devient une décision à prendre, pas une faute à reprocher.
Nommer les tokens de couleur, de typographie et d’espacement
Les tokens de couleur se construisent en deux étages : une palette de base, puis des rôles (texte, fond, action, erreur) qui pointent vers elle. Chaque paire texte et fond se contrôle alors. Les WCAG 2.2, recommandation du W3C dans sa version du 12 décembre 2024, exigent au niveau AA un contraste d’au moins 4,5 pour 1 pour le texte courant et de 3 pour 1 pour le grand texte, seuil que le critère 1.4.11 étend aux composants d’interface et aux éléments graphiques nécessaires à la compréhension. Vérifié sur le token sémantique, le contraste profite à chaque composant.
Typographie et espacement suivent la même logique, chaque taille ou marge portant un nom plutôt qu’un nombre.
Pour stocker ces décisions, le format du Design Tokens Community Group, stable depuis sa version 2025.10 parue à l’automne 2025, décrit chaque token en JSON par une valeur, un type et une description ; un token peut renvoyer à un autre en citant son chemin entre accolades. Le groupe précise que ce texte n’est pas un standard du W3C.
Passer aux composants, du plus fréquent au plus rare
La bibliothèque démarre par les briques les plus employées : bouton, lien, champ de saisie, alerte. Trois critères de niveau AA des WCAG 2.2 se règlent à cette étape : un focus clavier visible (2.4.7), un élément focalisé jamais entièrement caché par un contenu de la page, un bandeau fixe par exemple (2.4.11), des cibles d’au moins 24 pixels CSS de côté, hors exceptions prévues (2.5.8). La méthode dite atomic design, qui assemble des atomes en molécules puis en organismes, aide à ordonner ce travail sans devoir être suivie à la lettre.
Versionner dès la première publication
Chaque publication reçoit un numéro à trois niveaux qui distingue correctifs, ajouts compatibles et changements obligeant à reprendre l’existant, avec des notes lisibles par des non-développeurs. Un token voué à disparaître passe d’abord par la propriété de dépréciation prévue par le même format, qui accepte une explication en clair.
Le Système de design de l’État, un exemple public à observer
Le Système de design de l’État offre un exemple complet, documenté en français. Son dépôt de code public le présente comme un ensemble de composants web HTML, CSS et JavaScript destiné aux équipes des sites publics, pour créer des interfaces de qualité et accessibles ; il est développé, maintenu et géré par le Service d’information du Gouvernement. Fondamentaux, composants et modèles de pages y sont séparés, et les notes de version classent chaque changement en ajout, évolution, correctif ou suppression, en signalant à part ceux qui cassent la structure HTML.
Son usage reste réservé à l’administration : le dépôt rappelle qu’en raison de son rôle de marqueur d’identité visuelle de l’État, il ne doit pas être utilisé par des entités extérieures. Pour un site privé, il se lit comme une leçon de méthode, pas comme une réserve de composants.
Faire vivre le système sans le figer
Un système de design n’est jamais terminé. Quelques habitudes comptent davantage que l’outil retenu :
- un circuit de demande où chaque besoin est examiné puis intégré, adapté ou refusé par écrit ;
- une revue périodique des composants peu employés ;
- un contrôle d’accessibilité repris à chaque version ;
- une documentation publiée en même temps que le code.
Les dérives se repèrent tôt : valeurs brutes qui réapparaissent, variantes locales qui se multiplient, ajouts que personne ne valide. Chacune appelle une décision collective plutôt qu’une interdiction de plus.
Questions courantes sur la mise en place d’un design system
Un design system doit-il exister dans le code pour mériter son nom ?
Un jeu de composants présent dans un seul outil de conception reste un kit d’interface. Le système commence quand les mêmes décisions vivent des deux côtés : tokens partagés, composants réellement codés, règles écrites. Une petite équipe peut démarrer par les tokens, traduits en variables CSS, puis coder les composants peu à peu. L’essentiel est qu’une seule source fasse foi et que tout écart entre écran conçu et écran livré soit traité comme une anomalie.
Les design tokens remplacent-ils les variables CSS ?
Non, ils les précèdent. Un token décrit une décision dans un format neutre, indépendant de la technologie d’affichage ; les variables CSS en sont une traduction possible, au même titre que les ressources d’une application mobile. Dans un projet uniquement web, la différence paraît mince. Elle devient nette dès qu’une deuxième plateforme doit afficher les mêmes couleurs et les mêmes espacements.
Un design system rend-il un site accessible à lui seul ?
Non. Il règle en amont une partie des exigences, comme les contrastes portés par les tokens, le focus visible ou la taille des cibles, et chaque écran qui emploie ces briques en profite. La conformité aux WCAG s’apprécie pourtant page par page : structure des titres, textes de remplacement des images, clarté des libellés et ordre de lecture échappent au système. Un audit régulier des pages réelles reste nécessaire.