L'essentiel sur le design system SaaS
Un SaaS B2B sans design system ressemble a une ville ou chaque architecte aurait construit ses propres normes d'electrique et de plomberie. Les boutons ne sont pas au meme endroit d'une page a l'autre, les couleurs varient d'un module au suivant, et chaque nouveau developpeur reinvente les composants que ses collegues ont deja construits dans d'autres squads. Le resultat : une experience utilisateur incoherente et une velocity front-end structurellement bridee.
Un design system ce n'est pas un projet Figma — c'est un systeme vivant compose de trois couches : les design tokens (le vocabulaire commun : couleurs, typographies, espacements sous forme de variables), la librairie de composants (Button, Modal, DataTable, Form — developpes en React et/ou Vue avec Storybook), et la gouvernance (le process qui assure que le systeme est utilise et evolue sans diverger).
Cas client SaaS B2B (logiciel RH, 12 developpeurs, 3 squads produit) : zero composant partage avant l'intervention Nehos, 80 composants documentes dans Storybook livres en 4 mois, adoption a 100 % de l'equipe en 3 mois, -65 % de temps de developpement mesuré sur les nouvelles features front-end.
Le ROI d'un design system est reel mais demande 3 a 6 mois pour se materialiser — le temps que l'adoption se consolide. Les equipes qui abandonnent au bout de 6 semaines, avant que la masse critique de composants soit atteinte, ne verront jamais le ROI. La gouvernance et l'adoption sont au moins aussi importantes que la qualite technique des composants.
Design system SaaS : finissez avec les composants dupliques et les design reviews sans fin
Quand chaque squad reinvente le meme bouton, la meme modal et le meme tableau de donnees, 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.
Adapté à toute taille de structure
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 premiere modal, un premier formulaire. Tout le monde les utilise. Puis les squads se divisent — produit, onboarding, settings, analytics. Chaque squad recrute ses propres developpeurs, adopte ses propres conventions, et reecrit les composants selon ses propres standards. Au bout de 18 a 24 mois, il existe dans la codebase 4 versions differentes du composant Button, 6 implementations du Select, 3 patterns de validation de formulaire et 2 systemes de grille incompatibles. La consequence sur la velocity est mesurable. Selon une etude 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 developpeurs dont 6 travaillent majoritairement sur le front-end, c'est l'equivalent de 2 developpeurs temps plein occupes a reinventer des roues. La consequence sur l'experience utilisateur est encore plus dommageable. Les incoherences de design — espacements differents d'un module a l'autre, couleurs semantiques utilisees differemment selon les squads, comportements d'interaction non standardises — creent une experience fragmentee qui nuit a la perception de qualite du produit. Dans un SaaS B2B ou le produit est utilise plusieurs heures par jour par les clients, ces incoherences s'accumulent et degradent la satisfaction perçue. La relation design-dev est une troisieme victime. Quand il n'existe pas de source de verite unique pour les composants, le designer cree ses maquettes dans Figma avec une liberte totale, et le developpeur les reimplemente de son cote — avec les ecarts inevitables de spacing, de couleurs et de comportements. Les design reviews deviennent des sessions de detection d'ecarts plutot 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'accessibilite est systematiquement sacrifiee dans un environnement sans design system. Chaque developpeur 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'accessibilite au niveau du composant : un Button accessible une fois est accessible partout ou il est utilise. C'est la seule facon realiste d'atteindre une conformite WCAG AA systematique dans un SaaS B2B actif.
La methode 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 frequence d'utilisation et par complexite de standardisation. Cette etape est souvent revelante : la majorite des SaaS B2B ont deja 60 a 70 % des composants atomiques quelque part dans leur codebase — ils sont simplement dupliques et incoherents. La couche de fondation est le systeme de design tokens. Nehos definit les tokens en deux niveaux : les tokens primitifs (les valeurs brutes — `blue-500: #3B82F6`, `spacing-4: 16px`, `font-size-base: 16px`) et les tokens semantiques (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 theme en modifiant seulement les tokens semantiques — ce qui est critique pour les SaaS qui proposent du white-labeling ou des themes sombres. Les tokens sont definis 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 coherente : les props sont typees avec des interfaces TypeScript explicites, les variants sont definis comme des types litteraux union (`variant: 'primary' | 'secondary' | 'ghost' | 'destructive'`), les etats 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 etats, et les cas limites (texte long, icones 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 detectee 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 memes composants via des Web Components ou des adaptateurs specifiques — ce qui permet de partager les tokens et les comportements sans dupliquer le code. L'accessibilite est integree au niveau composant : chaque composant respecte les criteres WCAG 2.1 AA — ratios de contraste, gestion du focus visible, navigation clavier, roles ARIA corrects, labels associes. Les tests d'accessibilite automatiques (axe-core via Storybook Accessibility addon) sont executes en CI — un composant qui fail les tests d'accessibilite ne peut pas etre merge. La gouvernance est la couche la moins visible mais la plus critique pour la perennite du design system. Nehos definit 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 deprecier les anciens composants. Un changelog public (dans Storybook) trace toutes les evolutions 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 metriques : la velocity front-end (temps moyen pour developper une feature front-end equivalente, avant/apres), 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'accessibilite, incoherences rapportees par les clients).
-65 %
de temps de developpement par feature front-end apres adoption du design system — SaaS B2B logiciel RH, 12 developpeurs, mesure sur 20 features comparees avant/apres sur 3 squads
80
composants documentes dans Storybook et publies en npm interne (atomiques + moleculaires + complexes) livres en 4 mois pour un SaaS B2B de 12 developpeurs
100 %
d'adoption du design system par les 12 developpeurs de l'equipe (0 nouveau composant custom cree hors design system) atteint 3 mois apres 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 probleme : pourquoi design system saas est un enjeu critique
Les chiffres parlent d'eux-memes : 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 premiere modal, un premier formulaire. Tout le monde les utilise. Puis les squads se divisent — produit, onboarding, settings, analytics. Chaque squad recrute ses propres developpeurs, adopte ses propres conventions, et reecrit les composants selon ses propres standards. Au bout de 18 a 24 mois, il existe dans la codebase 4 versions differentes du composant Button, 6 implementations du Select, 3 patterns de validation de formulaire et 2 systemes de grille incompatibles.
La consequence sur la velocity est mesurable. Selon une etude 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 developpeurs dont 6 travaillent majoritairement sur le front-end, c'est l'equivalent de 2 developpeurs temps plein occupes a reinventer des roues. (source : Figma Blog)
La consequence sur l'experience utilisateur est encore plus dommageable. Les incoherences de design — espacements differents d'un module a l'autre, couleurs semantiques utilisees differemment selon les squads, comportements d'interaction non standardises — creent une experience fragmentee qui nuit a la perception de qualite du produit. Dans un SaaS B2B ou le produit est utilise plusieurs heures par jour par les clients, ces incoherences s'accumulent et degradent la satisfaction perçue.
La relation design-dev est une troisieme victime. Quand il n'existe pas de source de verite unique pour les composants, le designer cree ses maquettes dans Figma avec une liberte totale, et le developpeur les reimplemente de son cote — avec les ecarts inevitables de spacing, de couleurs et de comportements. Les design reviews deviennent des sessions de detection d'ecarts plutot 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'accessibilite est systematiquement sacrifiee dans un environnement sans design system. Chaque developpeur 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'accessibilite au niveau du composant : un Button accessible une fois est accessible partout ou il est utilise. C'est la seule facon realiste d'atteindre une conformite WCAG AA systematique dans un SaaS B2B actif.
Pour approfondir ce sujet, consultez notre page construction design system SaaS.
#Notre approche en 4 phases
La methode 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 frequence d'utilisation et par complexite de standardisation. Cette etape est souvent revelante : la majorite des SaaS B2B ont deja 60 a 70 % des composants atomiques quelque part dans leur codebase — ils sont simplement dupliques et incoherents.
#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 systeme de tokens : couleurs primitives et semantiques (color-primary-500, color-bg-surface), echelle typographique, grille d'espacement (4px base), rayons, ombres. Documentation dans Figma Variables.
#Phase 2 — Construction des composants atomiques et Storybook (semaines 4-8)
Developpement 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 cle : Nehos definit les tokens en deux niveaux : les tokens primitifs (les valeurs brutes — blue-500: #3B82F6, spacing-4: 16px, font-size-base: 16px) et les tokens semantiques (la signification — color-primary: var(--blue-500), color-bg-surface: var(--gray-50), space-component-gap: var(--spacing-4)).
#Phase 3 — Composants moleculaires et complexes (semaines 9-14)
Developpement des composants moleculaires : Card, Modal, Drawer, DataTable, Form, Toast/Notification, Navigation (Sidebar, Topbar, Breadcrumb), DatePicker, Select avec recherche, Combobox. Composants complexes specifiques 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 cle : Les tokens sont definis 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 etape.
#Resultats mesures
On vous donne les vrais chiffres. Pas les projections — les mesures.
| Indicateur | Resultat | Source |
|---|---|---|
| -65 % | de temps de developpement par feature front-end apres 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 + moleculaires + complexes) livres en 4 moi... | Livraison projet Nehos 2025 (2025) |
| 100 % | d'adoption du design system par les 12 developpeurs 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 developpement par feature front-end apres adoption du design system — SaaS B2B logiciel RH, 12 developpeurs, mesure sur 20 features comparees avant/apres 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 + moleculaires + complexes) livres en 4 mois pour un SaaS B2B de 12 developpeurs. Un indicateur complementaire qui confirme l'impact operationnel. Source : Livraison projet Nehos 2025.
100 % — d'adoption du design system par les 12 developpeurs de l'equipe (0 nouveau composant custom cree hors design system) atteint 3 mois apres 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 conges et de la paie), 12 developpeurs dont 6 principalement front-end, 3 squads produit independantes (Absence, Paie, Analytics). Codebase React/TypeScript. Aucun composant partage — chaque squad avait developpe ses propres Button, Input, Modal et DataTable. Figma : 3 fichiers Figma independants sans tokens partages. Temps moyen de developpement d'une feature front-end : 12 jours. Budget design system : 811 k€ HT.
#Le defi
Unifier l'experience utilisateur des 3 modules (les clients se plaignaient des incoherences de design en passant de l'un a l'autre), accelerer la velocity front-end, et preparer l'infrastructure pour un white-labeling multi-tenant prevu dans la roadmap Q3 2026 (necessitant un systeme de themes base sur des tokens). Contrainte : ne pas bloquer les squads pendant la construction du design system — les sprints produit devaient continuer.
#Solution deployee
Phase 1 (3 semaines) : audit codebase (ts-morph) — 47 composants Button identifies, 8 implementations de Modal, 5 DataTable differentes. Phase 2 (5 semaines) : definition des tokens (Figma Variables + Style Dictionary) — 120 tokens primitifs, 48 tokens semantiques, support dark mode et white-labeling themes. Phase 3 (8 semaines) : construction des 80 composants atomiques et moleculaires en React/TypeScript, Storybook 8, Chromatic, Vitest + Testing Library, accessibilite 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.
#Resultats obtenus
Resultats a 6 mois post-livraison : -65 % de temps de developpement par feature front-end (de 12 jours a 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 ete livre en 6 semaines — un chantier qui aurait pris 4 a 5 mois sans le systeme de tokens en place.
Decouvrez aussi notre librairie composants Storybook React.
#Pourquoi Nehos pour design system saas
Notre approche est simple : pas de PowerPoint, des resultats.
Expertise sectorielle SaaS / Startup — On connait les contraintes reglementaires, les outils metier, 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 demontrable, on vous le dit. On a deja refuse des projets — et nos clients nous en remercient.
Stack maitrisee — 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 dependance a un outil qu'on decouvre sur votre projet.
Accompagnement apres go-live — TMA, monitoring, evolution. On ne disparait pas apres la mise en production.
#Pour aller plus loin
- simulateur ROI design system
- conformite accessibilite WCAG SaaS
- solutions engineering SaaS et startup
Sources citees dans cet article :