
Design system : ce terme désigne la référence commune de vos interfaces, qui réunit des design tokens (couleurs, typographies, espacements), des composants réutilisables, leurs règles d’usage et leur traduction en code. Il permet à plusieurs écrans, produits et équipes de rester cohérents tout en concevant et en développant plus vite. Il se construit par étapes : inventaire de l’existant, tokens, composants clés, documentation, puis gouvernance. Pour un seul petit site, un kit UI léger suffit souvent.
En bref
- Un design system relie une bibliothèque de design et une bibliothèque de code qui partagent les mêmes noms et les mêmes règles.
- Il apporte cohérence, rapidité, accessibilité intégrée aux composants et refontes plus simples.
- Il se justifie avec plusieurs produits ou équipes, ou une interface qui évolue souvent.
- Commencez petit (tokens et composants clés), puis nommez un responsable et versionnez.
Qu’est-ce qu’un design system, concrètement ?
Plus qu’un fichier de maquettes, c’est un ensemble d’éléments reliés, entretenu comme un produit interne :
- Design tokens : les valeurs de base nommées (couleurs, tailles de texte, espacements, arrondis, ombres, animations).
- Composants : boutons, champs, cartes, menus, avec tous leurs états (survol, focus, erreur, désactivé).
- Patterns : des assemblages récurrents, comme un formulaire d’inscription ou un parcours de paiement.
- Règles d’usage : quand utiliser chaque composant, et quand l’éviter.
- Deux bibliothèques synchronisées : l’une dans l’outil de design (Figma, par exemple), l’autre dans le code.
La spécification du Design Tokens Community Group du W3C, stable depuis octobre 2025, décrit les tokens comme les éléments indivisibles d’un design system et propose un format commun pour les échanger entre outils.
Design system, charte graphique, brand book, kit UI : quelles différences ?
Ces outils se complètent plus qu’ils ne se remplacent.
| Outil | Contenu | Usage principal | Limite |
|---|---|---|---|
| Brand book (plateforme de marque) | Mission, valeurs, ton, personnalité | Aligner la communication | Ne dit rien des interfaces |
| Charte graphique (style guide) | Logo, palette, typographies, règles visuelles | Cohérence sur tous les supports | Ni composants ni comportements |
| Kit UI | Composants dessinés dans un outil de design | Accélérer les maquettes | Pas de code, peu de règles |
| Design system | Tokens, composants design et code, patterns, documentation, gouvernance | Faire évoluer plusieurs produits de façon cohérente | Demande un responsable et un entretien continu |
Pourquoi mettre en place un design system ?
- Cohérence : le même bouton et le même message d’erreur sur le site, l’application et l’espace client.
- Rapidité : les équipes assemblent des composants existants au lieu de tout redessiner et recoder.
- Accessibilité intégrée : contraste (au moins 4,5:1 pour le texte courant au niveau AA des WCAG), focus visible et libellés de champs sont réglés une fois dans le composant, puis hérités partout.
- Collaboration : designers et développeurs partagent le même vocabulaire.
- Refontes facilitées : changer une couleur de marque ou ajouter un mode sombre revient à modifier des tokens, pas des centaines d’écrans.
Votre entreprise a-t-elle vraiment besoin d’un design system ?
Il se justifie quand plusieurs produits coexistent (site, application mobile, back-office), quand plusieurs équipes ou prestataires interviennent, ou quand l’interface évolue chaque mois.
À l’inverse, un site vitrine de quelques pages, rarement mis à jour, n’en a pas besoin : une charte graphique, un kit UI léger et un thème bien paramétré suffisent. Une bibliothèque de code documentée a un coût que seul un usage régulier rentabilise.
Une voie intermédiaire consiste à adapter un système public à votre marque, comme Material Design de Google ou Carbon, le système open source d’IBM. Le DSFR, système de design de l’État français, est en revanche réservé aux sites en .gouv.fr : à étudier, pas à réutiliser.
Comment construire un design system, étape par étape ?
- Inventorier l’existant : capturez les boutons, champs, couleurs et tailles de texte en production, puis repérez les doublons.
- Définir les tokens : couleurs, typographie, espacements, arrondis, ombres et animations, nommés selon leur rôle (« couleur-texte-erreur »), pas selon leur valeur.
- Concevoir les composants de base : bouton, champ de saisie, case à cocher, interrupteur, carte, notification, avec tous leurs états.
- Documenter : rôle, cas d’usage, exemples à suivre et à éviter, règles d’accessibilité.
- Implémenter en code : une bibliothèque partagée, alimentée par les mêmes tokens que les maquettes.
- Diffuser : migrez les écrans existants au fil des évolutions plutôt qu’en une seule fois.
Du fichier de design au code
Dans Figma, les variables stockent les tokens et gèrent des modes comme clair et sombre (leur publication dans une bibliothèque d’équipe dépend de l’abonnement). Côté code, les tokens deviennent des variables CSS ou des fichiers propres à chaque plateforme. Les composants sont documentés dans un outil comme Storybook, qui permet de les développer, de les documenter et de les tester isolément, y compris pour l’accessibilité.
Comment faire vivre un design system dans la durée ?
Prévoyez trois choses dès le départ :
- Un responsable : un binôme designer et développeur front-end, avec du temps réservé, qui arbitre les demandes.
- Un versionnement : numéros de version, journal des modifications, annonce anticipée des changements incompatibles.
- Un processus de contribution : les équipes proposent de nouveaux composants, revus puis intégrés s’ils servent à plusieurs produits.
Les pièges les plus fréquents
- Tout construire avant de livrer : des mois de travail sans usage réel donnent des composants que personne n’adopte.
- Aucun responsable : chacun crée ses variantes et la cohérence disparaît.
- Design et code qui divergent : sans tokens communs, maquettes et code s’éloignent à chaque version.
- Oublier l’accessibilité : un composant défaillant propage son défaut à tous les écrans qui l’utilisent.
FAQ
Combien de temps faut-il pour créer un design system ?
Cela dépend du nombre de produits et de composants. Une première version limitée aux tokens et aux composants courants peut servir très tôt, puis s’enrichir projet après projet. Un design system n’est jamais terminé : il évolue avec vos interfaces.
Peut-on partir d’un design system existant comme Material Design ?
Oui, c’est un bon raccourci pour une application métier ou un premier produit : vous adaptez les tokens à votre marque et profitez de composants éprouvés. La contrepartie : un rendu parfois générique et une dépendance aux évolutions du système.
Un design system est-il compatible avec WordPress ?
Oui. Le fichier theme.json d’un thème WordPress centralise couleurs, typographies et styles, ce qui permet d’y reporter vos tokens. Les blocs et les compositions du thème jouent ensuite le rôle de composants.
Comment mesurer l’intérêt d’un design system ?
Fixez des indicateurs avant de commencer : délai pour livrer un nouvel écran, nombre d’anomalies d’interface, part des écrans conformes aux composants officiels. Comparez-les après quelques mois et demandez aux designers et aux développeurs ce qui les freine encore.
Créer votre design system avec Uteek
Chez Uteek, agence digitale basée aux Berges du Lac 2, à Tunis, notre équipe de design UX/UI peut auditer votre interface et créer un design system adapté à la taille de votre produit, du kit UI léger à la bibliothèque partagée avec vos développeurs. Découvrez notre offre de design graphique et UX/UI, parcourez nos réalisations ou parlez-nous de votre projet.


