Design system : pourquoi le poser dès la v1 d'un SaaS

Sur la plupart des SaaS qu'on auditade, le scénario est toujours le même : six versions du même bouton, quatre styles de tableau, trois palettes de gris qui se croisent. Chacun fait au mieux à un instant T, sans coordination. Et au bout de 18 mois, refactorer l'interface coûte plus cher que la refaire.

Le design system n'est pas un luxe pour grosses équipes. C'est un investissement minimal qui se rentabilise à partir du deuxième écran.

Ce que c'est vraiment

Un design system n'est pas une bibliothèque Figma. C'est trois choses, dans cet ordre :

1. Des décisions documentées : pourquoi on utilise cette couleur pour les erreurs, cette taille pour le titre H2, cette règle pour les espacements.
2. Des composants réutilisables : bouton, champ, modal, ligne de tableau, navigation. Une seule source de vérité.
3. Un pont vers le code : tokens partagés (couleurs, espacements, typographies) qui vivent à la fois dans Figma et dans le code.

Sans le point 3, le design system reste un beau document Figma que personne ne consulte. Avec, il devient l'infrastructure invisible du produit.

Pourquoi tôt et pas plus tard

L'argument classique contre : « On est encore en early stage, on va figer trop tôt. » C'est l'inverse qui se produit.

1. La dette de design s'accumule plus vite que la dette technique

Un composant mal pensé qui revient sur 30 écrans, c'est 30 endroits à corriger le jour où vous voulez le rectifier. Si vous attendez la v3 pour mettre de l'ordre, vous reprenez chaque page une à une.

2. Le développement est plus rapide

Avec un système, le développeur sait quoi utiliser. Sans système, chaque page redevient une discussion : « Quelle couleur pour ce bouton ? On a une grille pour les espacements ? » Multipliez par 200 décisions micro par sprint.

3. L'onboarding d'une nouvelle personne devient trivial

Designer ou dev, peu importe : un design system clair est la meilleure documentation produit qui existe.

4. Le produit gagne en qualité perçue

Un produit cohérent paraît mieux fait. Pas parce qu'il est plus joli, mais parce que le cerveau de l'utilisateur dépense moins d'énergie à s'orienter.

La version minimale viable

Pas besoin d'aller chercher Material Design ou Polaris. Pour une v1 SaaS, le système minimum tient en cinq jours de design :

Les tokens

• Couleurs : 5 nuances de gris, 1 couleur primaire (3 variantes), 1 couleur de succès, 1 d'erreur, 1 d'avertissement.
• Espacements : une échelle géométrique (4, 8, 12, 16, 24, 32, 48, 64).
• Typographies : 2 familles maximum, 5 tailles, 3 graisses.
• Rayons : 2 ou 3 valeurs (par exemple : 4 px, 8 px, 16 px).
• Ombres : 3 élévations.

Les composants de base

• Bouton (3 variantes : primary, secondary, ghost) avec ses états (hover, focus, disabled, loading).
• Champ de saisie (avec label, helper, erreur, états).
• Carte / panneau.
• Navigation principale.
• Ligne de tableau ou de liste.
• Modal / drawer.

À ce stade, vous couvrez 80 % des écrans d'un SaaS. Le reste se construit en composant ces briques.

Le pont Figma → code

C'est l'étape qui transforme un design system décoratif en design system opérationnel.

• Utilisez Figma Variables pour stocker les tokens.
• Exportez-les avec un outil comme Tokens Studio ou via l'API Figma.
• Côté code, consommez-les via CSS variables, Tailwind config, ou un fichier de design tokens dédié.

Une couleur change ? Vous l'ajustez dans Figma, vous régénérez les tokens, le produit suit. Plus de discussion sur « la bonne nuance de gris ».

Quand passer à la v2

Vous saurez qu'il faut faire évoluer le système quand vous remarquez l'un de ces signaux :

• Plusieurs composants similaires ont divergé en production (deux versions du même formulaire, par exemple).
• L'équipe demande régulièrement « est-ce qu'on a quelque chose pour ça ? » et la réponse est non.
• Vous lancez une nouvelle section produit avec une typologie d'interactions différente.

À ce moment-là, on fait un audit, on consolide, et on ajoute les composants qui manquent. Pas avant.

L'erreur la plus chère

L'erreur la plus chère, c'est de confondre design system et library Figma. Une bibliothèque Figma sans tokens partagés avec le code, sans documentation des décisions, sans gouvernance, ce n'est pas un design system : c'est un classeur. Joli, mais sans effet sur le produit.

En une phrase

Le design system n'est pas un livrable. C'est une infrastructure.

Si votre SaaS a passé la barre des 20 écrans, c'est probablement déjà le moment. Voir services Produit SaaS.