Design system SaaS : finissez avec les composants dupliques et les design reviews sans fin
Quand chaque squad reinvente le même bouton, la même modal et le même tableau de données, on perd 30 a 40 % de la velocity front-end sur de la recreation. Un design system Nehos — tokens Figma/CSS, Storybook, composants React/Vue — met fin a 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. Selon une étude Figma (2024 State of Design Systems), les equipes sans design system passent en moyenne 35 % de leur temps front-end sur des taches de recreation de composants existants ailleurs dans le projet. Pour une equipe de 12 développeurs dont 6 travaillent majoritairement sur le front-end, c'est l'équivalent de 2 développeurs temps plein occupes a 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 : la majorité des SaaS B2B ont déjà 60 a 70 % 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).
-65 %
de temps de développement par feature front-end après adoption du design system — SaaS B2B logiciel RH, 12 développeurs, mesure sur 20 features comparées avant/après sur 3 squads
80
composants documentes dans Storybook et publies en npm interne (atomiques + moléculaires + complexes) livres en 4 mois pour un SaaS B2B de 12 développeurs
100 %
d'adoption du design system par les 12 développeurs de l'equipe (0 nouveau composant custom cree hors design system) atteint 3 mois après la formation et le go-live
35 %
du temps front-end passe sur de la recreation de composants existants dans les equipes SaaS sans design system — source Figma State of Design Systems 2024
#Le problème : pourquoi design system saas est un enjeu critique
Les chiffres parlent d'eux-mêmes : 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. Selon une étude Figma (2024 State of Design Systems), les equipes sans design system passent en moyenne 35 % de leur temps front-end sur des taches de recreation de composants existants ailleurs dans le projet. Pour une equipe de 12 développeurs dont 6 travaillent majoritairement sur le front-end, c'est l'équivalent de 2 développeurs temps plein occupes a réinventer des roues. (source : Figma Blog)
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 : la majorité des SaaS B2B ont déjà 60 a 70 % 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.
#Résultats mesures
On vous donne les vrais chiffres. Pas les projections — les mesures.
| Indicateur | Résultat | Source |
|---|---|---|
| -65 % | de temps de développement par feature front-end après adoption du design system — SaaS B2B logiciel RH, 12 developpeu... | Mesures velocity Nehos 2025 — SaaS B2B client (2025) |
| 80 | composants documentes dans Storybook et publies en npm interne (atomiques + moléculaires + complexes) livres en 4 moi... | Livraison projet Nehos 2025 (2025) |
| 100 % | d'adoption du design system par les 12 développeurs de l'equipe (0 nouveau composant custom cree hors design system) ... | Mesures adoption Nehos 2025 (2025) |
| 35 % | du temps front-end passe sur de la recreation de composants existants dans les equipes SaaS sans design system — sour... | Figma — State of Design Systems Report 2024 (2024) |
#Ce que ces chiffres signifient
-65 % — de temps de développement par feature front-end après adoption du design system — SaaS B2B logiciel RH, 12 développeurs, mesure sur 20 features comparées avant/après sur 3 squads. C'est le chiffre principal, celui qui justifie l'investissement. Source : Mesures velocity Nehos 2025 — SaaS B2B client.
80 — composants documentes dans Storybook et publies en npm interne (atomiques + moléculaires + complexes) livres en 4 mois pour un SaaS B2B de 12 développeurs. Un indicateur complémentaire qui confirme l'impact opérationnel. Source : Livraison projet Nehos 2025.
100 % — d'adoption du design system par les 12 développeurs de l'equipe (0 nouveau composant custom cree hors design system) atteint 3 mois après la formation et le go-live. Source : Mesures adoption Nehos 2025.
#Cas client : SaaS B2B logiciel RH (gestion des absences
Un cas concret vaut mieux qu'un argumentaire.
#Contexte
SaaS B2B logiciel RH (gestion des absences, des congés et de la paie), 12 développeurs dont 6 principalement front-end, 3 squads produit indépendantes (Absence, Paie, Analytics). Codebase React/TypeScript. Aucun composant partage — chaque squad avait developpe ses propres Button, Input, Modal et DataTable. Figma : 3 fichiers Figma indépendants sans tokens partages. Temps moyen de développement d'une feature front-end : 12 jours. Budget design system : 811 k€ HT.
#Le défi
Unifier l'expérience utilisateur des 3 modules (les clients se plaignaient des incohérences de design en passant de l'un a l'autre), accélérer la velocity front-end, et preparer l'infrastructure pour un white-labeling multi-tenant prévu dans la roadmap Q3 2026 (nécessitant un système de thèmes base sur des tokens). Contrainte : ne pas bloquer les squads pendant la construction du design system — les sprints produit devaient continuer.
#Solution déployée
Phase 1 (3 semaines) : audit codebase (ts-morph) — 47 composants Button identifies, 8 implementations de Modal, 5 DataTable différentes. Phase 2 (5 semaines) : definition des tokens (Figma Variables + Style Dictionary) — 120 tokens primitifs, 48 tokens sémantiques, support dark mode et white-labeling themes. Phase 3 (8 semaines) : construction des 80 composants atomiques et moléculaires en React/TypeScript, Storybook 8, Chromatic, Vitest + Testing Library, accessibilité WCAG AA. Phase 4 (2 semaines) : formation squads (3x sessions de 2h) + definition gouvernance contribution. Migration progressive des anciens composants : 1 sprint dedie par squad.
#Résultats obtenus
Résultats a 6 mois post-livraison : -65 % de temps de développement par feature front-end (de 12 jours à 4,2 jours en moyenne), adoption a 100 % (zero composant custom cree hors design system depuis le mois 3), 12 bugs d'incoherence UI signales par les clients avant le design system vs 1 seul signale depuis. Le white-labeling multi-tenant a été livre en 6 semaines — un chantier qui aurait pris 4 a 5 mois sans le système de tokens en place.
Découvrez aussi notre librairie composants Storybook React.
#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 ROI n'est pas démontrable, on vous le dit. On a déjà refuse des projets — et nos clients nous en remercient.
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 :
- Figma — State of Design Systems 2024 — ROI et adoption dans les equipes produit
- Storybook — Documentation officielle Storybook 8 pour composants React et Vue
- W3C — Web Content Accessibility Guidelines (WCAG) 2.1 — standards accessibilité composants
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 de notre cas client incluait 80 composants React + des wrappers Vue pour les 20 composants les plus utilises 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 (minimum 20 % 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 couvre moins de 60 % 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.
3 a 6 mois après le go-live, avec un pic de ROI a 9-12 mois. Le premier mois, la velocity peut meme baisser — le temps que les développeurs apprennent les nouvelles conventions et migrent les anciens composants. Le ROI commence à apparaître quand l'adoption depasse 50 % (la majorité des nouveaux développements utilisent le design system). Le ROI devient flagrant quand l'adoption atteint 80-90 % et que les squads ne passent plus de temps sur la recreation de composants. Sur notre cas client, la velocity front-end a baisse de 8 % pendant le premier mois de migration, puis a augmente progressivement — pour atteindre -65 % de temps par feature au mois 6. Le ROI total sur 12 mois (économie en temps dev vs coût de construction) était positif a 3,8x sur notre cas client.
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 réduit le cycle de feedback design-dev de 2-3 jours a quelques heures.
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. Notre cas client a utilise cette architecture pour livrer le white-labeling multi-tenant en 6 semaines — un chantier qui aurait pris 4 a 5 mois sans 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.