Le terme est très employé, souvent à la place de « charte graphique », et la confusion coûte cher. Beaucoup d’entreprises paient un design system alors qu’elles ont besoin d’une charte, et l’inverse arrive aussi.
À retenir
Une charte décrit une marque. Un design system décrit une interface, et surtout il existe en code autant qu’en maquette. Il se justifie quand plusieurs personnes construisent un produit numérique en parallèle. Sur un site vitrine ou une communication print, c’est un investissement sans retour.
La différence, concrètement
Une charte graphique dit à quoi ressemble votre marque : logo, couleurs, typographies, principes.
Un design system dit comment est construite votre interface : à quoi ressemble un bouton, dans quels états, avec quels espacements, et comment on l’utilise dans le code. C’est une bibliothèque de composants, documentée, partagée entre le design et le développement.
La distinction pratique tient en une phrase : une charte se lit, un design system s’utilise.
Ce qu’un design system contient
Les fondations. Couleurs, typographies, espacements, rayons, ombres, points de rupture d’affichage. Exprimés en valeurs nommées et réutilisables plutôt qu’en valeurs brutes.
Les composants. Boutons, champs de formulaire, cartes, menus, messages d’alerte. Chacun dans tous ses états : normal, survolé, actif, désactivé, en erreur, en chargement.
Les règles d’assemblage. Comment les composants se combinent, quelles grilles, quels comportements sur mobile.
La documentation d’usage. Quand utiliser ce composant plutôt qu’un autre, ce qu’il ne faut pas en faire.
Le lien avec le code. C’est ce qui distingue un design system d’une bibliothèque de maquettes. Si les composants n’existent qu’en maquette, chaque développeur les réinterprète et le système se dissout.
Quand il se justifie
Quatre situations, et il en faut au moins deux.
Plusieurs personnes construisent l’interface en parallèle. Deux designers, trois développeurs, ou des équipes séparées. Sans référentiel commun, les écarts apparaissent en semaines.
Le produit est un logiciel ou une application. Beaucoup d’écrans, beaucoup d’états, beaucoup de cas particuliers. C’est le terrain naturel du design system.
Le produit évolue en continu. Un système permet de changer une valeur à un endroit et de la voir se propager partout. Sans lui, chaque évolution devient une chasse aux occurrences.
L’accessibilité est un enjeu. Traiter les contrastes, la navigation au clavier et les états de focus composant par composant est le seul moyen de tenir dans la durée.
Quand il ne se justifie pas
Un site vitrine de quelques pages. Une charte et des gabarits suffisent largement.
Une communication essentiellement print. Le design system ne traite pas ce terrain.
Une équipe d’une seule personne sur un produit stable. Le coût de maintenance dépasse le gain.
Un produit dont on ne sait pas encore à quoi il ressemblera. Construire un système sur des hypothèses non validées produit un référentiel qu’il faudra jeter. Commencez par le produit, systématisez ensuite.
Le coût réel : la maintenance
C’est le point que les projets sous-estiment systématiquement.
Un design system n’est pas un livrable, c’est un produit. Il a des utilisateurs (vos designers et vos développeurs), il évolue, il se documente, il se corrige. Sans quelqu’un pour en assurer l’entretien, il diverge du produit réel en quelques mois et devient un référentiel auquel plus personne ne se réfère.
C’est le mode d’échec le plus fréquent : un système construit avec soin, puis contourné parce qu’il ne suit plus.
Prévoyez explicitement qui l’entretient et à quel rythme, avant de le construire.
Ce qui se délègue là-dedans
Se délègue bien : la production des composants en maquette, leur déclinaison dans tous les états, la documentation, les vérifications de contraste et de cohérence, la mise à jour après une décision.
Se délègue difficilement : les arbitrages de conception. Décider qu’un composant doit exister, ou qu’il faut au contraire en supprimer trois, suppose de connaître le produit et ses usages.
Le partage naturel place la décision chez vous et la production à l’extérieur, ce qui correspond bien à un modèle de collaborateur dédié.
Par où commencer sans surinvestir
Ne commencez pas par les fondations théoriques. Commencez par ce qui existe déjà.
Recensez les composants réellement utilisés dans votre produit. Vous en trouverez plus que prévu, souvent en plusieurs variantes involontaires : quatre styles de bouton, trois tailles de champ.
Unifiez ces variantes, documentez le résultat, et arrêtez-vous là. Un système de vingt composants réellement utilisés vaut mieux qu’un système de cent conçus par anticipation.
Questions fréquentes
Un design system remplace-t-il la charte graphique ? Non. Ils traitent des objets différents et coexistent : la charte pour la marque, le système pour l’interface.
Faut-il un outil particulier ? Les principaux outils de maquette gèrent les bibliothèques partagées, le plus souvent à partir d’une offre payante. Le sujet n’est pas l’outil, c’est la synchronisation avec le code.
Combien de temps pour en construire un ? Cela dépend entièrement du périmètre. Un système minimal sur un produit existant se construit beaucoup plus vite qu’un système exhaustif conçu à l’avance.
Qui doit en être responsable ? Une personne nommée, côté produit ou design. Sans responsable identifié, il se dégrade.
Pour aller plus loin
Le document de marque est traité dans le guide de la charte graphique. L’application au produit relève de l’UX/UI externalisé sur un produit.
Rouge Hexagone fournit des profils dédiés à la production et à la maintenance de composants. Voir la fiche designer UX/UI.
