Un design system SaaS est l’ensemble des composants, des règles et des décisions visuelles que toutes les personnes qui conçoivent ou développent votre produit réutilisent. Grâce à lui, une décision de design se prend une fois, puis sert sur tous les écrans. Le bon moment pour le construire arrive quand plusieurs personnes livrent des écrans en parallèle, et il vaut mieux alors commencer petit que viser l’exhaustivité.
Avant ce seuil, une bibliothèque légère suffit. Après, chaque mois d’attente ajoute des écarts qu’il faudra corriger. Voici comment situer votre produit, par quoi commencer, ce que le système doit contenir et comment éviter qu’il soit abandonné au bout d’un an.
Qu’est-ce qu’un design system pour un SaaS ?
Le Nielsen Norman Group le définit comme un ensemble de standards pour gérer le design à grande échelle, fait de composants et de modèles réutilisables (Nielsen Norman Group). Le mot clé est « échelle » : un design system n’a d’intérêt que si plusieurs écrans, plusieurs personnes ou plusieurs équipes doivent rester cohérents.
Dans un SaaS, cette échelle arrive vite. Chaque sprint ajoute un écran, un filtre, une modale ou un nouveau statut. Sans référence commune, chaque ajout est une petite décision de design prise à nouveau, souvent un peu différemment.
Plus qu’une bibliothèque de composants
Trois termes circulent, et ils ne désignent pas la même chose. Le UI kit, c’est la boîte de pièces graphiques. La bibliothèque de composants, c’est cette boîte rangée et nommée, côté maquette ou côté code. Le design system, c’est la boîte avec son mode d’emploi : pourquoi chaque pièce existe, quand s’en servir, qui peut en ajouter une.
Les systèmes publics montrent bien cette structure. Le GOV.UK Design System s’organise en styles, en composants et en modèles pour des tâches courantes, comme saisir un nom, une adresse ou créer un compte (GOV.UK Design System). Les modèles sont la partie la plus précieuse : ils disent comment assembler les composants pour résoudre un vrai problème d’utilisateur.
En France, le Système de design de l’État est présenté comme un ensemble de composants réutilisables régi par des standards et une gouvernance ; il est obligatoire pour les sites et applications mobiles de l’État depuis juillet 2023 (info.gouv.fr). Standards et gouvernance : c’est exactement ce qui manque aux bibliothèques qui s’effritent.
Ce qu’il change pour un SaaS B2B
Le Nielsen Norman Group décrit le problème qu’il résout : sans système, les grandes organisations finissent par concevoir et coder plusieurs versions d’un même élément, avec à la clé des incohérences, du temps perdu et un code désordonné (Nielsen Norman Group). Un SaaS de quinze personnes vit déjà ce problème à son échelle.
Pour vos utilisateurs, la différence se voit au quotidien. Un statut « en attente » qui a la même couleur et le même libellé partout se lit sans réfléchir.
Un tableau qui trie et filtre toujours de la même manière s’apprend une fois. Dans un outil utilisé plusieurs heures par jour, cette constance compte plus qu’un bel écran d’accueil.
Pour vos équipes, le gain est ailleurs : moins de débats sur des détails déjà tranchés, des maquettes plus rapides, et des développeurs qui assemblent au lieu de reconstruire. C’est ce que couvre notre accompagnement en design UX/UI et design system, de l’architecture des écrans jusqu’aux composants documentés.
Quand construire un design system SaaS ?
La question n’est pas « faut-il un design system ? » mais « lequel, et à quel moment ? ». Le même produit passe par plusieurs stades, et chacun appelle un niveau de formalisation différent.
Trois moments, trois réponses : le design system suit la maturité du produit.
Trop tôt : tant que le produit cherche sa forme
Tant que vous testez encore ce que le produit doit faire, un système complet fige trop de choses. Les parcours changent d’une semaine à l’autre, des écrans entiers disparaissent. Documenter des composants qui ne survivront pas au prochain test utilisateur ne sert personne.
À ce stade, une bibliothèque légère, adaptée à votre métier, suffit : une palette, une échelle typographique, quelques composants de base. Notre façon de travailler s’y prête bien.
Le studio itère surtout avec des prototypes réalisés avec l’IA, et les éléments qui reviennent d’un prototype à l’autre signalent ce qui méritera plus tard d’entrer dans le système. Il naît ainsi de l’usage, pas d’un catalogue.
Si vous en êtes au lancement, notre page création de SaaS décrit comment nous enchaînons prototype, conception et développement sans accumuler de dette d’interface.
Le bon moment : plusieurs personnes livrent des écrans
Le signal le plus fiable n’est pas la taille de l’entreprise, mais le nombre de personnes qui produisent des écrans en parallèle. Deux designers, ou une équipe de développement qui conçoit elle-même certaines pages : les écarts commencent dès que deux personnes font le même choix chacune de leur côté.
D’autres signes vont dans le même sens :
- Vous avez trois versions d’un même composant, par exemple trois façons d’afficher un message d’erreur.
- Un nouvel écran prend des jours de design alors qu’il ressemble beaucoup à un écran existant.
- Les développeurs demandent régulièrement « quelle couleur ? », « quel espacement ? », « quel libellé ? ».
- Un client ou un partenaire demande une version à ses couleurs, un mode sombre ou un mode contraste élevé.
À ce moment, le design system se construit pendant un projet de design ou de refonte, sur les vrais écrans, et non comme un chantier isolé. Chez nous, ces projets durent de 2 à 6 mois, par cycles de 6 semaines.
Trop tard : chaque module a ses propres règles
Quand le produit a grandi plusieurs années sans référence commune, il faut d’abord défaire avant de construire. Chaque module a ses boutons, ses tableaux et ses règles implicites, et personne n’ose toucher aux zones les plus anciennes.
Ce n’est pas une impasse, mais le design system devient alors un chantier de migration : il doit cohabiter avec l’existant et remplacer les anciens composants écran par écran. Nous détaillons cette situation dans notre article sur les signes qu’un SaaS B2B a besoin d’une refonte.
Victor Michel, fondateur du studio, a conçu un design system complet, de zéro, pour la refonte de l’application d’espace client de Bouygues Telecom, utilisée par quinze millions de clients mobiles. Tokens, composants et règles d’usage ont été maintenus tout au long du projet, pour que plusieurs équipes livrent sur une même base.
Par quoi commencer ?
Un design system ne démarre pas par une page blanche dans Figma. Il démarre par ce que votre produit contient déjà, même dans le désordre.
Inventorier ce qui existe déjà
Faites des captures de tous les écrans, puis regroupez les éléments par famille : boutons, champs, tableaux, badges, modales, messages. Le simple fait de voir côte à côte vos sept variantes de bouton principal suffit souvent à convaincre une équipe.
Notez pour chaque famille combien de variantes existent, lesquelles sont justifiées et lesquelles sont des accidents. Cet inventaire rejoint une partie de l’audit UX d’un SaaS, qui croise ce relevé avec les difficultés réelles des utilisateurs.
L’inventaire donne aussi l’ordre de travail. Les familles les plus utilisées et les plus incohérentes passent en premier. Celles qui n’apparaissent que sur un écran secondaire peuvent attendre.
Poser les design tokens
Les design tokens nomment vos décisions visuelles. Material Design les décrit comme de petites décisions de design réutilisables, et les répartit en trois classes : les tokens de référence, les tokens système et les tokens de composant (Material Design).
En pratique, cela donne deux niveaux minimum. D’abord les valeurs brutes, comme un bleu précis. Ensuite les usages, comme « couleur de lien » ou « bordure de champ en erreur », qui pointent vers ces valeurs. Les écrans n’utilisent que les usages : changer une couleur ne demande plus de retoucher chaque page.
C’est aussi ce qui rend les thèmes possibles. Atlassian traite le mode clair, le mode sombre et le contraste élevé comme des thèmes qui changent les valeurs d’un même jeu de tokens (Atlassian Design System).
Victor Michel, fondateur du studio, a conçu pour Metroscope, l’IA de maintenance prédictive des centrales EDF, un design system industriel doté de modes haute visibilité. Sans tokens, ce type de variante devient vite ingérable.
Le format se standardise. Le groupe communautaire du W3C consacré aux design tokens a publié le 28 octobre 2025 la première version stable de sa spécification, un format de fichier pour échanger des tokens entre outils ; ce n’est pas une norme officielle du W3C (W3C Design Tokens Community Group).
Traiter d’abord les composants qui reviennent partout
Dans un SaaS B2B, quelques composants portent l’essentiel de l’usage. Commencez par eux plutôt que par une liste théorique de cinquante éléments :
- Les tableaux, cœur de la plupart des écrans métier : colonnes, tri, sélection multiple.
- Les étiquettes de statut, dont la couleur et le mot doivent suffire.
- Les champs de saisie, avec leur aide contextuelle et leur validation.
- Les modales et confirmations, surtout pour les actions irréversibles.
- Les états vides, quand une liste ne contient encore rien.
Sur EPItrack, un SaaS de gestion des équipements de protection conçu par le studio, le design system couvre tableau de bord, tableaux, statuts, catalogue et fiches produit. Un même code visuel signale partout les niveaux d’urgence : le responsable HSE voit d’un coup d’œil quel contrôle approche, quel que soit l’écran.
EPItrack : statuts et tableaux viennent du même design system.
Que contient un design system complet ?
Un système utile tient sur quatre piliers. Aucun ne suffit seul : des composants sans règles se détournent, des règles sans code restent des intentions.
Les quatre piliers d’un design system qui tient dans le temps.
Des composants avec tous leurs états
Un composant n’est pas une image figée. Un bouton a un état normal, survolé, actif, désactivé et en chargement. Un tableau a un état vide, un état en erreur, un état sans droits et un état avec des données très longues.
Ces états font la qualité perçue d’un SaaS. Ce sont eux que l’on oublie dans les maquettes, puis que chaque développeur improvise. Les documenter une fois dans le système, c’est éviter des dizaines de petites décisions prises sous la pression d’un sprint.
Des règles d’usage, de rédaction et d’accessibilité
Chaque composant a besoin d’une notice : quand l’employer, quand en choisir un autre, avec quel libellé. Ces règles de rédaction appartiennent au système autant que les couleurs.
« Supprimer » ou « Retirer » ? « Enregistrer » ou « Valider » ? Tranchées une fois, ces questions ne reviennent plus à chaque revue de sprint.
L’accessibilité se règle aussi à ce niveau. Les WCAG 2.2 demandent, au niveau AA, des cibles d’au moins 24 par 24 pixels CSS, avec quelques exceptions (W3C). Intégrée au bouton, au lien et à la case à cocher, la règle s’applique à tous les écrans sans que personne n’ait à y penser.
Même chose pour les contrastes, l’ordre de focus au clavier et les libellés explicites. Un composant conforme reproduit sa conformité partout où il est utilisé. Un composant qui ne l’est pas reproduit le défaut tout aussi fidèlement.
Un lien direct avec le code
Un design system qui n’existe que dans Figma finit par diverger du produit réel. Les tokens doivent être exportés vers le code, et chaque composant de la maquette doit correspondre à un composant développé, avec le même nom.
Le plus simple reste qu’une même équipe dessine et développe. Quand le studio prend aussi en charge le développement, chaque composant de la maquette existe dans le code de votre produit, sous le même nom et avec les mêmes états.
Le lien avec le code sert aussi les agents de code IA. Un assistant qui génère un écran respecte mieux un système dont les tokens et les composants sont nommés et documentés, que des styles éparpillés dans le code.
Quelles erreurs éviter, et comment le faire vivre ?
La plupart des design systems ne meurent pas d’un mauvais départ. Ils meurent d’un abandon progressif, quand l’équipe trouve plus rapide de le contourner que de l’utiliser.
Les erreurs qui le condamnent
Ces erreurs reviennent dans la plupart des projets :
- Reprendre un kit téléchargé tel quel : il ignore vos statuts, vos tableaux et le vocabulaire de vos utilisateurs.
- Commencer par le haut : une centaine de composants dessinés avant d’avoir un seul écran réel qui les utilise.
- Livrer sans documentation : un composant que personne ne sait quand utiliser sera recréé à côté.
- Le construire en vase clos, loin des développeurs, qui découvrent le résultat le jour de la livraison.
- Ne désigner personne pour arbitrer les demandes d’évolution.
La dernière est la plus fréquente. Un système sans responsable devient une bibliothèque de plus, que chacun enrichit à sa façon, et les doublons reviennent par la petite porte.
Une gouvernance à la mesure de l’équipe
Inutile de créer un comité. Il faut une personne qui tranche, et une règle simple pour décider. Elle doit pouvoir s’expliquer en une phrase.
Le Nielsen Norman Group en propose une : un changement utile à trois équipes ou plus a sa place dans le système ; s’il ne sert qu’un cas, c’est probablement une exception, et dans le doute on le prototype d’abord avec une seule équipe (Nielsen Norman Group).
Dans un SaaS plus petit, remplacez « équipes » par « écrans » ou « modules », le principe reste le même. Ajoutez un canal unique pour les demandes, un journal des changements et une revue courte à chaque fin de cycle.
Cette exigence est forte dans les logiciels où une erreur coûte cher, ceux de la finance ou des organisations internationales. Notre page agence UX/UI à Genève décrit comment nous travaillons avec ces équipes, depuis Thonon, sur leurs interfaces et leurs bibliothèques de composants.
Surveiller la dérive
Même bien gouverné, un système dérive : une couleur presque identique ajoutée en urgence, un composant détaché de sa source, un écart silencieux entre la maquette et le code. Ces écarts sont invisibles un par un, et coûteux tous ensemble.
Desy, un produit conçu et développé par le studio, s’attaque précisément à ce problème. L’outil lit le code pour en tirer les tokens réellement utilisés, signale ce qui pourrait être regroupé et suit l’évolution des écarts au fil des versions. Son résultat peut être transmis aux agents de code IA, pour qu’ils travaillent avec le système plutôt qu’à côté.
Sans outil, une revue trimestrielle fait déjà beaucoup : comparez les tokens du code avec ceux de la maquette, listez les composants créés hors du système, et décidez pour chacun s’il entre dans le système ou s’il disparaît.
Six points à vérifier pour qu’un design system reste utilisé.
Un design system n’est pas un livrable que l’on range une fois terminé : c’est un outil de travail qui suit le produit. Commencez petit, au moment où plusieurs personnes livrent des écrans, et donnez-lui un responsable dès le premier jour. Pour le construire sur vos vrais écrans, voyez notre offre de design UX/UI et design system, ou parlons de votre produit directement.
Sources
- Nielsen Norman Group : Design Systems 101
- Nielsen Norman Group : Your Design System Needs an Enforcer
- GOV.UK Design System : styles, composants et modèles
- info.gouv.fr : le Système de design de l’État
- Material Design 3 : design tokens
- Atlassian Design System : design tokens
- W3C Design Tokens Community Group : première version stable de la spécification
- W3C : nouveautés des WCAG 2.2