À retenir
- En dessous de deux produits et de trois personnes qui dessinent, un design system coûte plus qu’il ne rapporte.
- Commencez par les jetons — couleurs, typographie, espacements — avant les composants.
- Un design system vit dans le code autant que dans l’outil de design ; sinon il diverge en trois mois.
- Comptez 15 000 à 60 000 € pour une première version utilisable, puis un budget d’entretien continu.
- Le signal le plus fiable : vos développeurs redemandent trois fois la même valeur d’espacement.
« Il nous faudrait un design system. » On entend cette phrase dans des entreprises qui n’ont qu’un seul produit, un seul designer, et pas encore de deuxième écran. Dans ce cas, la réponse honnête est non — et cela nous fait perdre des missions.
Un design system est un investissement industriel. Il devient rentable au-delà d’un certain seuil, et coûteux en dessous. Voici comment situer votre entreprise par rapport à ce seuil.
Les cinq signaux qui montrent que le moment est venu
Comptez combien vous en cochez.
- Vous avez au moins deux produits ou surfaces — une application mobile et un back-office, un site et une extension, deux applications métier.
- Au moins trois personnes produisent de l’interface, designers et développeurs confondus.
- La même question revient chaque semaine : « quelle couleur pour ce bouton ? », « quel espacement entre ces blocs ? », « il existe déjà un composant pour ça ? ».
- Vous voyez des divergences visibles : trois nuances de bleu presque identiques, quatre tailles de bouton, deux styles de champ de formulaire dans le même parcours.
- Le temps de mise en production d’un écran augmente alors que l’équipe est plus expérimentée qu’il y a un an.
Trois signaux ou plus : construisez-le. Un ou deux : contentez-vous d’une bibliothèque de composants partagée, sans la gouvernance ni la documentation qui vont avec. Zéro : concentrez-vous sur le produit.
Le test des trois espacements. Demandez à trois développeurs de votre équipe quelle marge ils mettraient entre un titre de section et le paragraphe suivant. Si vous obtenez trois valeurs différentes, vous payez déjà le coût de l’absence de système — simplement, il est invisible parce qu’il est réparti sur tout le monde.
Ce qu’il faut construire, dans l’ordre
L’erreur classique est de commencer par les composants les plus visibles. On dessine trente variantes de boutons, on ne documente rien, et six mois plus tard chaque équipe a recréé les siennes.
1. Les jetons (2 à 4 jours)
Couleurs, typographie, espacements, rayons, ombres, durées d’animation. Ce sont les décisions les plus structurantes et les moins chères à prendre. Elles doivent exister sous forme de variables, dans l’outil de design et dans le code — la même valeur, le même nom.
Une échelle d’espacement à six valeurs suffit dans 90 % des cas. Elle élimine à elle seule la moitié des débats.
2. Les primitives (1 à 2 semaines)
Bouton, champ de saisie, sélecteur, case à cocher, badge, carte, modale, message d’alerte. Avec tous leurs états : par défaut, survol, focus, actif, désactivé, chargement, erreur. Les états sont ce qui distingue un vrai composant d’une jolie maquette — et c’est aussi là que se joue l’accessibilité, un sujet que nous traitons dans notre article sur le RGAA et l’accessibilité numérique.
3. Les motifs (en continu)
Formulaire long, tableau de données, état vide, chargement, gestion d’erreur, onboarding. Ce sont des assemblages de primitives avec des règles d’usage. Ils s’ajoutent au fil des besoins réels, jamais par anticipation.
4. La documentation (en continu)
Pour chaque composant : à quoi il sert, quand ne pas l’utiliser, et un exemple copiable. Trois phrases suffisent. Une documentation de quarante pages que personne ne lit vaut moins qu’une phrase juste au bon endroit.
Le coût réel
| Périmètre | Budget | Délai |
|---|---|---|
| Jetons + 10 composants, une plateforme | 15 000 – 25 000 € | 3 à 5 semaines |
| Jetons + 25 composants, web + mobile | 35 000 – 60 000 € | 8 à 12 semaines |
| Entretien annuel | 10 – 15 % du coût initial | En continu |
Le poste que tout le monde oublie est le dernier. Un design system n’est pas un livrable : c’est un produit interne avec des utilisateurs, des demandes d’évolution et une dette. Sans propriétaire identifié et sans temps dédié, il devient un musée en moins d’un an.
Partir d’une base existante
Dans la majorité des cas, nous recommandons de ne pas partir de zéro. Une base open source mature vous apporte gratuitement l’accessibilité, la gestion du clavier, les états et le comportement des composants complexes — sélecteurs, modales, menus. Ce sont précisément les parties les plus longues et les plus faciles à rater.
Vous appliquez ensuite vos jetons de marque, et vous ne construisez sur mesure que les composants qui vous distinguent réellement. Économie typique : 60 à 70 % du coût initial, et une accessibilité bien meilleure que ce qu’une équipe produit en partant de rien.
Le meilleur design system n’est pas le plus complet, c’est celui que l’équipe utilise sans y penser. Tout composant que les gens contournent est un composant à corriger ou à supprimer.
Comment savoir s’il fonctionne
Trois indicateurs, mesurables sans outil particulier :
- Le temps de production d’un nouvel écran standard. Il doit baisser d’au moins 30 % dans les trois mois suivant l’adoption.
- Le nombre de valeurs uniques de couleur et d’espacement dans le code. Il doit diminuer, pas augmenter.
- La proportion d’écrans construits uniquement à partir de composants du système. Sous 70 %, le système ne répond pas aux besoins réels : ce sont ses règles qu’il faut revoir, pas la discipline de l’équipe.
Si vous hésitez sur votre situation, décrivez-nous vos produits et la taille de votre équipe. Nous vous dirons honnêtement si le moment est venu — y compris quand la réponse est « pas encore ».



