Design system SaaS : finissez avec les composants dupliques et les design reviews sans fin
Quand chaque squad réinvente le même bouton, la même modal et le même tableau de données, une part importante de la vélocité front-end part dans de la recréation. Un design system Nehos — tokens Figma/CSS, Storybook, composants React/Vue — met fin à ce gaspillage et aligne design et dev en permanence.
Nos clients types
La dette front-end dans un SaaS B2B en croissance suit un pattern quasi-universel. Au debut, l'equipe est petite et partage naturellement les conventions de code. Un premier bouton est cree, une première modal, un premier formulaire. Tout le monde les utilise. Puis les squads se divisent — produit, onboarding, settings, analytics. Chaque squad recrute ses propres développeurs, adopte ses propres conventions, et réécrit les composants selon ses propres standards. Au bout de 18 à 24 mois, il existe dans la codebase 4 versions différentes du composant Button, 6 implementations du Select, 3 patterns de validation de formulaire et 2 systèmes de grille incompatibles. La consequence sur la velocity est mesurable. Les equipes sans design system passent une part importante de leur temps front-end sur des taches de recreation de composants existants ailleurs dans le projet. Pour une equipe de quelques développeurs front-end, c'est l'équivalent d'un ou plusieurs développeurs temps plein occupés à réinventer des roues. La consequence sur l'expérience utilisateur est encore plus dommageable. Les incohérences de design — espacements différents d'un module a l'autre, couleurs sémantiques utilisées différemment selon les squads, comportements d'interaction non standardises — créent une expérience fragmentée qui nuit a la perception de qualité du produit. Dans un SaaS B2B ou le produit est utilise plusieurs heures par jour par les clients, ces incohérences s'accumulent et dégradent la satisfaction perçue. La relation design-dev est une troisième victime. Quand il n'existe pas de source de verite unique pour les composants, le designer cree ses maquettes dans Figma avec une liberté totale, et le développeur les reimplemente de son cote — avec les écarts inévitables de spacing, de couleurs et de comportements. Les design reviews deviennent des sessions de détection d'écarts plutôt que des sessions de validation de valeur. Cette friction permanente entre design et dev est l'un des principaux facteurs de ralentissement des cycles de delivery. Enfin, l'accessibilité est systématiquement sacrifiée dans un environnement sans design system. Chaque développeur implemente les interactions clavier, les aria-labels et les contrastes de couleur selon sa propre comprehension des standards WCAG — quand il les implemente. Un design system impose l'accessibilité au niveau du composant : un Button accessible une fois est accessible partout où il est utilise. C'est la seule façon réaliste d'atteindre une conformité WCAG AA systématique dans un SaaS B2B actif.
La méthode Nehos pour construire un design system SaaS commence par un audit de l'existant — pas par du greenfield. Cet audit cartographie tous les composants existants dans la codebase (analyse statique avec ts-morph ou AST grep), identifie les variantes et les duplications, et classe les composants par fréquence d'utilisation et par complexité de standardisation. Cette étape est souvent revelante : beaucoup de SaaS B2B ont déjà une grande partie des composants atomiques quelque part dans leur codebase — ils sont simplement dupliques et incohérents.
La couche de fondation est le système de design tokens. Nehos définit les tokens en deux niveaux : les tokens primitifs (les valeurs brutes — blue-500: #3B82F6, spacing-4: 16px, font-size-base: 16px) et les tokens sémantiques (la signification — color-primary: var(--blue-500), color-bg-surface: var(--gray-50), space-component-gap: var(--spacing-4)). Ce double niveau permet de changer l'ensemble du thème en modifiant seulement les tokens sémantiques — ce qui est critique pour les SaaS qui proposent du white-labeling ou des thèmes sombres. Les tokens sont définis dans Figma Variables, exportes via Style Dictionary en CSS custom properties, en JSON (pour React), et en SCSS (pour les projets existants).
La librairie de composants est construite avec React et TypeScript strict. Chaque composant suit une API cohérente : les props sont typées avec des interfaces TypeScript explicites, les variants sont définis comme des types littéraux union (variant: 'primary' | 'secondary' | 'ghost' | 'destructive'), les états sont exhaustifs (default, hover, focus, active, disabled, loading, error). Storybook 8 est utilise comme reference vivante : chaque composant a ses stories qui documentent tous les variants, tous les états, et les cas limites (texte long, icônes absent, valeurs extremes). Les tests visuels de non-regression sont automatises via Chromatic (integration Storybook) dans le pipeline CI/CD — une pull request qui casse un composant est détectée automatiquement avant le merge.
Pour les SaaS qui ont une surface produit en Vue (souvent des projets ayant migrate progressivement de Vue vers React, ou des produits multi-framework), Nehos livre des wrappers Vue qui exposent les mêmes composants via des Web Components ou des adaptateurs spécifiques — ce qui permet de partager les tokens et les comportements sans dupliquer le code.
L'accessibilité est intégrée au niveau composant : chaque composant respecte les critères WCAG 2.1 AA — ratios de contraste, gestion du focus visible, navigation clavier, roles ARIA corrects, labels associes. Les tests d'accessibilité automatiques (axe-core via Storybook Accessibility addon) sont executes en CI — un composant qui fail les tests d'accessibilité ne peut pas être merge.
La gouvernance est la couche la moins visible mais la plus critique pour la pérennité du design system. Nehos définit le process de contribution : pour ajouter un nouveau composant, une PR avec stories Storybook, tests unitaires Vitest + Testing Library, et visual snapshot Chromatic est requise. Un tech lead est nomme 'design system owner' dans chaque organisation cliente — son role est de valider les nouvelles contributions et de déprécier les anciens composants. Un changelog public (dans Storybook) trace toutes les évolutions et les breaking changes. La formation des equipes — 2 sessions de 2 heures par squad — est incluse dans la livraison.
Le ROI est mesure sur trois métriques : la velocity front-end (temps moyen pour développer une feature front-end équivalente, avant/après), le taux d'adoption (% de nouveaux composants crees qui reutilisent le design system vs composants custom), et le taux d'incidents UI en production (regressions visuelles, bugs d'accessibilité, incohérences rapportées par les clients).
À mesurer
temps de développement par feature front-end avant et après l'adoption du design system, mesuré sur un échantillon de features comparables entre les squads
À mesurer
composants documentés dans Storybook et publiés en npm interne (atomiques, moléculaires et complexes)
À mesurer
part des nouveaux composants qui réutilisent le design system plutôt que des composants custom
À mesurer
part du temps front-end passée à recréer des composants qui existent déjà ailleurs dans le projet, avant et après le design system
#Le problème : pourquoi design system saas est un enjeu critique
Le constat : La dette front-end dans un SaaS B2B en croissance suit un pattern quasi-universel. Au debut, l'equipe est petite et partage naturellement les conventions de code. Un premier bouton est cree, une première modal, un premier formulaire. Tout le monde les utilise. Puis les squads se divisent — produit, onboarding, settings, analytics.
Chaque squad recrute ses propres développeurs, adopte ses propres conventions, et réécrit les composants selon ses propres standards. Au bout de 18 à 24 mois, il existe dans la codebase 4 versions différentes du composant Button, 6 implementations du Select, 3 patterns de validation de formulaire et 2 systèmes de grille incompatibles.
La consequence sur la velocity est mesurable. Les equipes sans design system passent une part importante de leur temps front-end sur des taches de recreation de composants existants ailleurs dans le projet. Pour une equipe de quelques développeurs front-end, c'est l'équivalent d'un ou plusieurs développeurs temps plein occupés à réinventer des roues.
La consequence sur l'expérience utilisateur est encore plus dommageable. Les incohérences de design — espacements différents d'un module a l'autre, couleurs sémantiques utilisées différemment selon les squads, comportements d'interaction non standardises — créent une expérience fragmentée qui nuit a la perception de qualité du produit.
Dans un SaaS B2B ou le produit est utilise plusieurs heures par jour par les clients, ces incohérences s'accumulent et dégradent la satisfaction perçue.
La relation design-dev est une troisième victime. Quand il n'existe pas de source de verite unique pour les composants, le designer cree ses maquettes dans Figma avec une liberté totale, et le développeur les reimplemente de son cote — avec les écarts inévitables de spacing, de couleurs et de comportements.
Les design reviews deviennent des sessions de détection d'écarts plutôt que des sessions de validation de valeur. Cette friction permanente entre design et dev est l'un des principaux facteurs de ralentissement des cycles de delivery.
Enfin, l'accessibilité est systématiquement sacrifiée dans un environnement sans design system. Chaque développeur implemente les interactions clavier, les aria-labels et les contrastes de couleur selon sa propre comprehension des standards WCAG — quand il les implemente. Un design system impose l'accessibilité au niveau du composant : un Button accessible une fois est accessible partout où il est utilise. C'est la seule façon réaliste d'atteindre une conformité WCAG AA systématique dans un SaaS B2B actif.
Pour approfondir ce sujet, consultez notre page construction design system SaaS.
#Notre approche en 4 phases
La méthode Nehos pour construire un design system SaaS commence par un audit de l'existant — pas par du greenfield. Cet audit cartographie tous les composants existants dans la codebase (analyse statique avec ts-morph ou AST grep), identifie les variantes et les duplications, et classe les composants par fréquence d'utilisation et par complexité de standardisation.
Cette étape est souvent revelante : beaucoup de SaaS B2B ont déjà une grande partie des composants atomiques quelque part dans leur codebase — ils sont simplement dupliques et incohérents.
#Phase 1 — Audit UI et definition des tokens de design (semaines 1-3)
Audit de la base de code existante : inventaire des couleurs, typographies, espacements et composants utilises. Identification des inconsistances et des duplications. Definition du système de tokens : couleurs primitives et sémantiques (color-primary-500, color-bg-surface), échelle typographique, grille d'espacement (4px base), rayons, ombres. Documentation dans Figma Variables.
#Phase 2 — Construction des composants atomiques et Storybook (semaines 4-8)
Développement des composants atomiques (Button, Input, Select, Checkbox, Badge, Avatar, Tag) en React avec TypeScript strict. Variants et states documentes dans Storybook 8 : default/hover/focus/disabled/error. Tests unitaires Vitest + Testing Library. Publication du package npm interne. Synchronisation tokens Figma <> code via Style Dictionary.
Point clé : Nehos définit les tokens en deux niveaux : les tokens primitifs (les valeurs brutes — blue-500: #3B82F6, spacing-4: 16px, font-size-base: 16px) et les tokens sémantiques (la signification — color-primary: var(--blue-500), color-bg-surface: var(--gray-50), space-component-gap: var(--spacing-4)).
#Phase 3 — Composants moléculaires et complexes (semaines 9-14)
Développement des composants moléculaires : Card, Modal, Drawer, DataTable, Form, Toast/Notification, Navigation (Sidebar, Topbar, Breadcrumb), DatePicker, Select avec recherche, Combobox. Composants complexes spécifiques au SaaS : filtres avances, tableaux triables/filtrables/paginés, layouts page. Wrappers Vue pour les composants partages.
#Phase 4 — Adoption equipe et gouvernance (semaines 15-16)
Sessions de formation (2h par squad) sur l'utilisation des composants et la contribution au design system. Definition du process de contribution : Storybook PR review, visual regression testing (Chromatic), changelog. Tableau de bord d'adoption : % de composants custom remplace par le design system, velocity par squad.
Point clé : Les tokens sont définis dans Figma Variables, exportes via Style Dictionary en CSS custom properties, en JSON (pour React), et en SCSS (pour les projets existants).
On s'appuie sur notre design system avec Radix UI et shadcn/ui pour cadrer chaque étape.
#Ce qu'on mesure
Nous ne publions pas de chiffres de résultats pour ce type de projet : chaque contexte est différent. Voici les indicateurs qu'on met en place dès le pilote pour décider, chiffres réels à l'appui, d'aller plus loin ou non.
| Indicateur | Ce qu'on regarde |
|---|---|
| Temps par feature | temps de développement par feature front-end avant et après l'adoption du design system, mesuré sur un échantillon de features comparables entre les squads |
| Composants documentés | composants documentés dans Storybook et publiés en npm interne (atomiques, moléculaires et complexes) |
| Adoption | part des nouveaux composants qui réutilisent le design system plutôt que des composants custom |
| Temps de recréation | part du temps front-end passée à recréer des composants qui existent déjà ailleurs dans le projet, avant et après le design system |
#Exemple de situation : SaaS B2B logiciel RH
Ce n'est pas une référence client : c'est une situation type, telle que nous la rencontrons dans ce secteur.
#Contexte
Un SaaS B2B de logiciel RH (gestion des absences, des congés et de la paie), avec une équipe de développeurs dont une partie principalement front-end, répartis en trois squads produit indépendantes (Absence, Paie, Analytics). Trois fichiers Figma indépendants, sans tokens partagés, et aucun composant mutualisé. Le développement d'une feature front-end prend du temps, et le budget d'un design system doit rester compatible avec les sprints produit en cours.
#Le défi
Unifier l'expérience utilisateur des trois modules (les clients se plaignent des incohérences de design en passant de l'un à l'autre), accélérer la vélocité front-end et préparer l'infrastructure d'un white-labeling multi-tenant prévu dans la roadmap, qui nécessite un système de thèmes basé sur des tokens. Contrainte : ne pas bloquer les squads pendant la construction du design system, les sprints produit devant continuer.
#Solution envisagée
Une construction en plusieurs phases. Audit des composants existants dans la codebase, puis définition des tokens (Figma Variables et Style Dictionary) en deux niveaux, primitifs et sémantiques, avec support du dark mode et de thèmes white-label. Construction de la bibliothèque de composants React documentée dans Storybook, avec wrappers Vue pour les modules legacy. Formation des squads en sessions courtes et définition de la gouvernance de contribution.
#Ce qu'on mesure
On ne promet pas de chiffre. On mesure le temps de développement d'une feature front-end avant et après, le taux d'adoption (composants qui réutilisent le design system face aux composants custom) et le nombre d'incohérences UI signalées par les clients. La comparaison avec la situation de départ permet de calculer le retour réel.
#Pourquoi Nehos pour design system saas
Notre approche est simple : pas de PowerPoint, des résultats.
Expertise sectorielle SaaS / Startup — On connaît les contraintes réglementaires, les outils métier, les workflows terrain. Chokri Siala (CTO) pilote ce type de projet personnellement.
Approche ROI-First — On chiffre le retour avant de coder. Si le retour attendu n'est pas démontrable, on vous le dit avant de démarrer.
Stack maîtrisée — React, TypeScript, Storybook 8, Chromatic, Vitest, Testing Library, axe-core, Figma Variables, Style Dictionary, shadcn/ui, Radix UI, Vue Web Components, GitHub Actions. Pas de dépendance a un outil qu'on découvre sur votre projet.
Accompagnement après go-live — TMA, monitoring, evolution. On ne disparaît pas après la mise en production.
#Pour aller plus loin
- simulateur ROI design system
- conformité accessibilité WCAG SaaS
- solutions engineering SaaS et startup
Sources citées dans cet article :
Questions & réponses
Questions frequentes sur le design system SaaS
Une librairie de composants (comme shadcn/ui, MUI ou Ant Design) est un ensemble de composants pre-construits que vous installez et utilisez. Un design system est l'infrastructure complete qui inclut les tokens de design (la grammaire de votre marque), la librairie de composants (construite sur vos tokens), la documentation (Storybook), les guidelines d'usage, et surtout la gouvernance — le process qui assure que le système evolue de manière cohérente. La distinction pratique : vous pouvez partir de shadcn/ui ou de Radix UI comme fondation atomique et construire votre design system dessus — c'est souvent ce que nous recommandons pour les SaaS B2B qui veulent aller vite sans réinventer les comportements d'accessibilité. Voir notre guide construire un design system avec Radix UI et shadcn/ui.
Oui, et c'est un cas de figure courant dans les SaaS qui ont migre progressivement d'un framework a l'autre ou qui ont des produits distincts sur des stacks différentes. La stratégie la plus robuste en 2025-2026 est de construire les composants en React (qui reste le framework dominant) et de les exposer en Vue via des Web Components (custom elements) ou via un adaptateur Vue spécifique. Les tokens CSS sont par nature framework-agnostiques — ils fonctionnent identiquement dans React, Vue, Svelte ou Angular. Le rendu visuel est donc toujours coherent. Les comportements interactifs complexes (DatePicker, Combobox, DataTable avec virtualisation) nécessitent parfois un développement spécifique par framework. La couverture type comprend les composants React du quotidien, plus des wrappers Vue pour les composants les plus utilisés dans les modules legacy Vue.
C'est le risque numéro 1 — et il est quasi-systématiquement lie a deux causes : l'absence de gouvernance claire et le manque de masse critique de composants au moment du lancement. Sur la gouvernance : nommez un 'design system owner' avec du temps dedie (une part significative du temps d'un senior dev ou d'un tech lead). Définissez un process de contribution clair. Rendez le design system plus facile a utiliser que de créer un composant custom — si les PR reviews sont trop longues ou les docs trop lacunaires, les devs contournent. Sur la masse critique : un design system qui ne couvre pas l'essentiel des composants utilises au quotidien ne sera pas adopte. C'est pourquoi nous livrons systématiquement un minimum de 70 à 80 composants avant de former les equipes — plutôt que de livrer 20 composants et d'espérer une adoption progressive.
Le ROI devient mesurable plusieurs mois après le go-live, avec un pic à mesure que l'adoption se consolide. Il commence à apparaître quand l'adoption dépasse la moitié des nouveaux développements. Il devient flagrant quand la grande majorité des développements utilisent le design system et que les squads ne passent plus de temps sur la recréation de composants. Il est normal que la vélocité front-end baisse légèrement pendant la phase de migration avant de remonter. Le ROI se calcule en comparant le temps de développement par feature et le coût de construction, sur vos données.
Storybook est à la fois la documentation vivante et l'outil de testing du design system. Dans notre setup, Storybook est integre dans le pipeline CI/CD (GitHub Actions) : chaque Pull Request qui modifie un composant genere automatiquement un build Storybook de preview (heberge sur Chromatic) accessible au designer et aux reviewers. Les tests visuels de non-regression (snapshots Chromatic) détectent les changements visuels involontaires et bloquent le merge si des regressions sont détectées. Les tests d'accessibilité (axe-core via Storybook Accessibility addon) sont executes en meme temps. Le designer peut commenter directement sur le build Storybook de la PR — plus besoin de partager des screenshots. Cette integration raccourcit le cycle de feedback design-dev.
Oui — et c'est l'un des cas d'usage les plus puissants d'un design system base sur des tokens sémantiques. Le white-labeling consiste a remplacer les tokens sémantiques (color-primary, color-bg-surface, font-family-base) par les valeurs de la marque du client — sans toucher aux composants. Techniquement, cela se fait en CSS custom properties : chaque client a un fichier de tokens overrides qui est injecte au chargement de l'application. L'ensemble des composants adopte automatiquement les couleurs et les typographies du client. Cette architecture permet de livrer un white-labeling multi-tenant bien plus vite qu'un chantier qui ne reposerait pas sur des tokens. Pour les SaaS B2B qui ont ou prévoient du white-labeling dans leur roadmap, un design system base sur des tokens sémantiques est un prérequis non négociable.