Design system et composants UI : la méthode pour arrêter de réinventer vos interfaces

Trois designers qui dessinent chacun leur version du bouton « Valider ». Quatre développeurs qui recodent la même modale sur quatre écrans différents. Une couleur de marque qui existe en sept nuances selon qui l’a appliquée. Si ça vous parle, vous avez besoin d’un design system.

Le design system, ce n’est pas un énième outil à la mode. C’est la réponse à un problème très concret : quand une équipe grandit ou qu’un produit se décline sur plusieurs supports, la cohérence visuelle se dégrade vite. Et avec elle, la vitesse de production, la qualité perçue et la confiance des utilisateurs. Un design system et ses composants UI servent justement à éviter ce dérapage en centralisant les règles et les briques qui composent vos interfaces.

Ce guide est construit pour les agences, les équipes produit et les entreprises qui se posent la question. On va voir ce que recouvre vraiment la notion, de quoi se compose un design system moderne, comment le construire sans se perdre, quels outils utilisent réellement les équipes, et surtout quand il vaut mieux s’en passer (oui, ça arrive).

Le design system, c’est quoi exactement ?

Un design system est un référentiel structuré qui regroupe les règles, les composants UI, les styles graphiques et la documentation nécessaires pour concevoir des interfaces cohérentes. Pensez-y comme au langage commun entre vos designers, vos développeurs et votre chef de produit. Tout le monde parle la même langue, utilise les mêmes briques, applique les mêmes règles.

Ce système va plus loin qu’une simple charte graphique. La charte définit l’identité (logo, couleurs, typographies) mais reste statique. Le design system intègre aussi le comportement des éléments : comment un bouton réagit au survol, à quoi ressemble un champ de formulaire en erreur, quelle animation accompagne l’ouverture d’une modale. Et il va encore au-delà avec les composants codés, prêts à l’emploi, que les développeurs intègrent directement dans leurs applications.

Attention à ne pas confondre avec une UI kit. Une UI kit, c’est un paquet de composants visuels dans Figma ou Sketch. Un design system, c’est la UI kit + la documentation + le code + les principes + la gouvernance. La différence paraît subtile mais elle est énorme en pratique : sans documentation ni code, une UI kit dérive au bout de six mois.

À quoi sert concrètement un design system

Les bénéfices promis sont souvent survendus. Dans la réalité, un design system bien tenu apporte quatre gains mesurables :

• Cohérence visuelle garantie sur tous les supports. Site web, application mobile, extranet, emails transactionnels : le même bouton ressemble partout au même bouton. Ça paraît évident et pourtant, sans système central, c’est quasi impossible à tenir au-delà d’une dizaine d’écrans.
• Vitesse de production multipliée. Une étude d’InVision sur 2000 équipes produit a montré que celles qui utilisent un design system mature livrent 34% plus vite en moyenne. Plus besoin de redessiner ou recoder les éléments de base à chaque fonctionnalité.
• Qualité technique améliorée. Les composants sont testés une fois puis réutilisés. Ça limite la dette technique, facilite les audits d’accessibilité et simplifie la maintenance à long terme.
• Communication plus fluide entre métiers. Designers, devs, PM et UX writers parlent le même vocabulaire. Un composant « Card primary » signifie la même chose pour tout le monde, avec la même documentation accessible en un clic.

Côté coût, il faut être honnête : un design system demande un investissement de départ. Pour une agence ou un produit de taille moyenne, comptez entre deux et quatre mois de travail pour une première version utilisable. L’amortissement se fait généralement dès le deuxième ou troisième projet qui s’appuie dessus.

Les briques d’un design system moderne

Un design system complet s’articule autour de cinq couches qui s’empilent les unes sur les autres.

Les fondations (design tokens)

Les design tokens sont les plus petites unités de votre système : une couleur, une taille de police, un espacement, un rayon de bordure. Ils sont nommés de façon sémantique (par exemple color-primary-500 plutôt que bleu-fonce) et stockés dans un format partagé, souvent du JSON.

L’intérêt ? Si demain votre marque change de bleu principal, vous modifiez la valeur du token à un seul endroit. Toutes les interfaces qui utilisent color-primary-500 se mettent à jour automatiquement, que ce soit côté Figma, côté React ou côté application iOS.

La bibliothèque de composants UI

C’est le cœur visible du design system. On y retrouve tous les éléments standardisés qu’utilisent vos interfaces :

• Boutons (primaires, secondaires, tertiaires, en lien, destructifs)
• Champs de formulaire (input, textarea, select, radio, checkbox, toggle)
• Éléments de navigation (header, footer, breadcrumb, pagination, menu latéral)
• Affichage de données (tableau, carte, liste, badge, chip, avatar)
• Feedback (modale, toast, alerte, tooltip, skeleton de chargement)
• Mise en page (grille, conteneur, séparateur, espaceur)

Chaque composant existe avec ses différents états : normal, survolé, actif, désactivé, en erreur, en chargement. Et pour chaque état, on à la maquette Figma ET le code React, Vue ou Angular correspondant.

Les patterns et templates

Un pattern est une combinaison récurrente de composants qui résout un problème d’interface précis. Par exemple : « comment afficher une liste filtrée de résultats ? » ou « comment présenter un wizard de paiement en plusieurs étapes ? ». Les templates sont des pages complètes prêtes à adapter : page de connexion, tableau de bord, profil utilisateur, page d’erreur 404.

La documentation

Sans doc, votre design system est mort avant de naître. La documentation explique pour chaque composant :

• À quoi il sert et quand l’utiliser
• Quand NE PAS l’utiliser (tout aussi important)
• Les variantes disponibles et leurs usages
• Les règles d’accessibilité associées
• Des exemples concrets de code

Les principes de conception

C’est la couche la plus stratégique. Elle répond à la question : « quand notre documentation ne couvre pas un cas, comment décide-t-on ? » Ça peut être des principes comme « privilégier la clarté à l’esthétique », « l’accessibilité n’est jamais optionnelle » ou « un seul message principal par écran ». Ces principes guident les choix quand la règle précise n’existe pas.

Atomic design : la méthode qui structure tout

Brad Frost a formalisé en 2016 une méthode devenue la colonne vertébrale de beaucoup de design systems : l’atomic design. L’idée vient de la chimie. On part des plus petites briques pour assembler des structures de plus en plus complexes.

Cette hiérarchie force à penser la réutilisabilité dès le départ. Si vous modifiez l’atome « bouton », toutes les molécules, organismes et pages qui l’utilisent héritent du changement. C’est exactement le comportement qu’on veut.

En pratique, tout le monde n’applique pas strictement les cinq niveaux. Certaines équipes fusionnent atomes et molécules ou sautent directement des composants aux templates. L’important, c’est le principe : des briques petites vers des briques grosses, avec une logique d’héritage claire.

Construire un design system étape par étape

Vouloir lancer un design system parfait dès le départ est la meilleure façon de ne jamais le finir. La méthode qui fonctionne procède par itérations.

1. Audit de l’existant. Avant d’ajouter quoi que ce soit, cartographiez ce qui existe déjà. Capturez 50 à 100 écrans de vos interfaces actuelles. Listez tous les boutons utilisés (souvent vous en trouverez 15 variantes différentes pour 3 usages réels). Notez les incohérences, les doublons, les couleurs qui dérivent.
2. Définition des fondations. Figez vos design tokens : palette de couleurs (une douzaine de tokens max, pas 80), échelle typographique (5 à 7 tailles), système d’espacement (souvent basé sur des multiples de 4 ou 8 pixels), rayons de bordure, ombres portées.
3. Construction des composants prioritaires. Ne cherchez pas à couvrir 100% des besoins d’entrée. Commencez par les 10 à 15 composants que vous utilisez le plus souvent : bouton, input, card, modal, dropdown, navigation. Le reste viendra au fil des projets.
4. Mise en place de la documentation. Chaque composant publié doit avoir sa fiche : description, variantes, règles d’usage, exemples, code. Sans cette étape, personne ne va adopter votre système.
5. Implémentation technique. Côté code, les tokens deviennent des variables CSS ou des constantes dans votre framework. Les composants se traduisent en composants React, Vue ou Web Components selon votre stack. Un seul conseil ici : ne mélangez pas plusieurs frameworks, ça multiplie la maintenance par trois.
6. Test en conditions réelles. Lancez le design system sur un nouveau projet ou une nouvelle fonctionnalité. Récoltez les retours. Ajustez. Un système qui n’a jamais servi sur du vrai produit est un système mort-né.
7. Itération continue. Un design system évolue. Prévoyez des cycles réguliers (par exemple un sprint sur deux) pour ajouter des composants, corriger des incohérences, faire évoluer la documentation.

Budget réaliste pour une première version utilisable : deux designers et un développeur pendant trois mois à temps partiel. Pour un design system mature couvrant un produit complexe, on parle plutôt d’une équipe dédiée sur la durée.

Les outils qu’utilisent vraiment les équipes

Le paysage des outils pour design systems s’est beaucoup professionnalisé ces dernières années. Voici les références qui reviennent dans la majorité des équipes :

• Figma domine largement la partie design. Les bibliothèques partagées, les variants, les auto layouts et les variables permettent de construire un design system complet directement dans l’outil. La plupart des équipes agences et produits y travaillent.
• Storybook est le standard côté développement. Ce service permet de visualiser chaque composant dans toutes ses variantes, d’interagir avec, et de générer automatiquement la documentation à partir du code. Plus de 60 000 projets open source l’utilisent.
• Zeroheight ou Supernova centralisent la documentation partagée entre design et dev. Ces plateformes se connectent à Figma et à Storybook pour produire une documentation unifiée, consultable par toute l’équipe.
• Style Dictionary (Amazon) ou Tokens Studio for Figma gèrent les design tokens. Ils permettent de définir les tokens une fois et de les exporter vers tous les formats cibles : CSS, iOS, Android, JSON.
• Notion ou GitBook suffisent pour démarrer si vous n’avez pas encore le budget pour Zeroheight. Moins intégrés mais parfaitement viables pour une première version.

Le stack classique d’une agence qui démarre : Figma pour le design, Storybook pour le code, Notion pour la doc stratégique. Celui d’une grosse équipe produit : Figma + Storybook + Zeroheight + Style Dictionary, avec intégration CI/CD.

Design systems de référence qui font autorité

Certains design systems publics sont devenus des références étudiées par toutes les équipes. Les explorer est l’un des meilleurs moyens de comprendre ce qu’un système mature peut accomplir.

• Material Design (Google) reste la référence historique. Lancé en 2014, il couvre Android, web et iOS avec une cohérence rare. Material 3 Expressive, la dernière itération, pousse la personnalisation dynamique (Material You) à un niveau jamais vu.
• Human Interface Guidelines (Apple) n’est pas exactement un design system classique mais un guide très abouti pour iOS, macOS, watchOS et visionOS. Plus prescriptif que participatif.
• Carbon Design System (IBM) brille par sa rigueur. Documentation exhaustive, composants React et Vanilla, design tokens bien pensés. Une vraie leçon pour les produits B2B.
• Polaris (Shopify) se distingue par son approche « content first ». La documentation écrite est aussi soignée que les composants visuels. C’est le système qui m’a le plus marqué en termes de ton éditorial intégré.
• Atlassian Design System couvre Jira, Confluence et consorts. Très complet sur les patterns complexes : listes filtrables, assistants multi-étapes, tableaux de données.
• Primer (GitHub) est plus sobre mais ultra pragmatique. Un bon exemple de design system orienté développeurs.
• Salesforce Lightning impressionne par son étendue. C’est probablement le design system le plus vaste accessible publiquement.

Inspecter ces systèmes ne signifie pas les copier. Chacun porte l’ADN de son produit. Mais on y apprend beaucoup sur l’organisation de la documentation, la nomenclature des composants et la gestion des variants.

Gouvernance : qui fait vivre le design system

C’est la question qu’on oublie et qui tue 80% des design systems au bout d’un an. Sans gouvernance claire, le système se fige, prend de la dette, perd ses utilisateurs. Puis il meurt.

Trois modèles de gouvernance existent. Le modèle centralisé confie tout à une équipe dédiée qui gère, maintient et fait évoluer le système. C’est le choix des grosses boîtes (Google, Shopify). Avantage : cohérence maximale. Inconvénient : goulot d’étranglement quand toutes les équipes produit veulent des évolutions en même temps.

Le modèle fédéré distribue la responsabilité entre l’équipe core et les équipes produit. L’équipe core maintient les fondations et valide les contributions. Les équipes produit proposent des améliorations selon un processus défini. C’est souvent le meilleur compromis pour les entreprises de taille moyenne.

Le modèle communautaire fonctionne comme un projet open source interne. Tout le monde peut contribuer, les évolutions passent par des pull requests. Ça demande une culture d’entreprise mature.

Indépendamment du modèle, prévoyez :

• Un processus clair pour proposer un nouveau composant (cahier des charges, validation, tests)
• Une cadence de releases (mensuelle ou bimensuelle, pas plus rare)
• Un changelog lisible qui explique les évolutions et les breaking changes
• Un canal de communication dédié (Slack, Teams) où les utilisateurs du système posent leurs questions
• Des métriques d’adoption (quel pourcentage des projets utilisent vraiment le système ? quels composants sont les plus utilisés ?)

Quand ne PAS lancer un design system

Voilà le sujet que personne ne traite dans les articles marketing. Pourtant il est essentiel.

Un design system n’a pas de sens dans trois situations. D’abord si votre produit est encore en pré-lancement ou en phase d’exploration. À ce stade, vous avez besoin de flexibilité, pas de règles. Figer prématurément un système vous empêchera d’itérer librement sur l’identité et l’expérience.

Ensuite si votre équipe est très petite et votre produit très simple. Pour une équipe de deux designers sur un site vitrine de dix pages, un bon kit Figma avec quelques styles partagés suffit largement. Construire un vrai design system serait du sur-investissement.

Enfin, si vous n’avez pas la capacité de le maintenir dans la durée. Un design system abandonné est pire qu’un design system qui n’existe pas. Il reste dans Figma, commence à dériver, les équipes perdent confiance… et finissent par le contourner. Si vous ne pouvez pas dédier au moins 20% du temps d’un designer senior à sa maintenance, mieux vaut rester sur une UI kit plus modeste.

Une dernière chose : ne démarrez jamais un design system « parce que ça se fait ». Démarrez-le quand vous avez une douleur mesurable : incohérence qui nuit à la marque, temps de production qui explose, difficultés de recrutement parce que votre code est devenu un bazar. Un design system est une réponse à un problème, pas un ornement.

Questions fréquentes sur les design systems

Construire un design system, c’est accepter un pari : investir maintenant pour gagner du temps et de la cohérence demain. Ce n’est pas un projet parallèle, c’est un projet d’équipe qui engage designers, développeurs et chefs de produit. Bien mené, il devient l’infrastructure invisible sur laquelle reposent tous vos produits. Mal mené, il devient un cimetière de composants dans un coin de Figma. Le choix vous appartient.