Une maquette peut être très cohérente sur trois écrans et commencer à se disperser dès qu’on en ajoute vingt.
Le premier bouton a un rayon de 8 pixels. Le suivant, créé deux semaines plus tard, en a 12. Une carte utilise une ombre, une autre une bordure. Le gris des textes secondaires varie légèrement. Les espacements semblent proches, mais ne suivent aucune règle précise.
Rien de tout cela n’est dramatique isolément.
Le problème apparaît lorsque ces petites décisions s’accumulent. L’interface finit par donner l’impression d’avoir été dessinée page après page, sans système commun.
C’est là qu’un UI kit ou un design system devient utile.
Je ne les vois pas comme des objets réservés aux grandes plateformes. Leur intérêt commence beaucoup plus tôt : dès qu’il faut transformer une identité graphique en règles suffisamment claires pour être réutilisées sans tout redessiner.
L’identité visuelle donne le langage. Le design system définit la manière dont ce langage est utilisé dans l’interface.
UI kit, bibliothèque de composants et design system : quelles différences ?
Les trois termes se croisent souvent, mais ils ne décrivent pas exactement la même chose.
Le UI kit
Le UI kit rassemble les éléments graphiques réutilisables d’une interface : boutons, champs, cartes, badges, navigation, modales, accordéons ou tableaux.
Il peut aussi contenir les couleurs, les styles typographiques, les icônes et les règles d’espacement.
Pour un site relativement simple, c’est souvent suffisant.
La bibliothèque de composants
Dans Figma, elle permet de publier les composants pour les réutiliser dans plusieurs fichiers. Lorsqu’un composant source est modifié, la mise à jour peut être propagée aux maquettes qui utilisent ses instances.
Le bénéfice est surtout opérationnel : on évite de copier-coller des boutons ou des champs qui commencent ensuite à évoluer chacun de leur côté.
Le design system
Le design system ajoute les règles qui expliquent comment utiliser ces éléments.
Il peut documenter les composants, les patterns, les principes d’accessibilité, les tokens, les comportements responsive et parfois leur équivalent développé.
Le GOV.UK Design System illustre bien cette organisation en distinguant styles, composants et patterns.
Un petit site a-t-il vraiment besoin d’un design system ?
Je ne construirais pas un design system complet pour un site vitrine de cinq pages.
Ce serait probablement plus long à créer qu’à utiliser.
En revanche, même un petit site gagne à avoir quelques règles stables : palette, styles de texte, espacements, boutons, champs de formulaire, navigation et deux ou trois types de cartes.
Dans ce cas, je parlerais plutôt d’un UI kit structuré.
Le besoin change lorsque le produit comporte plusieurs dizaines d’écrans, plusieurs designers ou une évolution continue.
Une plateforme SaaS qui ajoute des fonctionnalités chaque mois finira rapidement par payer le manque de système : mêmes composants recréés plusieurs fois, comportements différents, corrections répétées et difficulté à savoir quelle version est la bonne.
Le niveau de formalisation doit donc suivre la complexité réelle du produit.
Passer d’une charte graphique à des règles d’interface
Une charte peut indiquer :
Bleu principal : #2457FF
Très bien.
Mais une interface a besoin de réponses supplémentaires.
Ce bleu sert-il au bouton principal ? Aux liens ? Aux éléments sélectionnés ? Peut-il être utilisé comme fond ? Quel texte peut être posé dessus ? Existe-t-il une version plus claire pour un hover ou un état secondaire ?
Le passage vers l’UI consiste à attribuer des fonctions aux choix graphiques.
Même chose pour la typographie.
« Serif pour les titres, sans serif pour le texte » est une direction artistique. L’interface a ensuite besoin de niveaux précis : titre principal, titre de section, sous-titre, texte courant, label, bouton, légende.
C’est la suite logique du travail que je décris dans l’article consacré à l’identité visuelle d’un site web.
Définir les fondations avant de créer les composants
Je commence rarement par dessiner vingt variantes de cartes.
Je stabilise d’abord les valeurs communes.
Couleurs, typographies, espacements, rayons, bordures et quelques dimensions récurrentes servent ensuite de base aux composants.
Cette étape réduit les décisions prises au hasard.
Si le système utilise des espacements de 4, 8, 12, 16, 24, 32 et 48 pixels, je ne vais pas ajouter 19 pixels entre deux éléments simplement parce que cela fonctionne sur une maquette précise.
Je peux sortir de cette échelle si une composition le demande. Mais je veux pouvoir expliquer pourquoi.
Donner un rôle aux couleurs
Une palette pensée pour une identité graphique n’est pas encore un système de couleurs d’interface.
Une application a besoin de distinguer le texte principal du secondaire, les surfaces, les bordures, les actions, les erreurs ou les confirmations.
Je préfère donc travailler avec des rôles.
Par exemple :
text-primary
text-secondary
surface-primary
surface-muted
border-default
action-primary
error
success
Cette logique devient particulièrement utile lors d’un rebranding ou d’un changement de thème.
Si l’action principale passe du bleu au vert, le système peut changer sans rechercher manuellement chaque bouton dans cinquante écrans.
La construction de la palette en elle-même est détaillée dans mon article sur le choix des couleurs pour le web.
Construire une vraie hiérarchie typographique
Je préfère définir les styles à partir de leur usage plutôt que choisir la taille de chaque texte au moment de dessiner l’écran.
| Style | Usage principal |
|---|---|
| Display | Grand titre éditorial |
| Heading 1 | Titre principal d’une page |
| Heading 2 | Titre de grande section |
| Heading 3 | Sous-section ou titre de carte |
| Body | Texte courant |
| Body small | Informations secondaires |
| Label | Champs et composants |
Je teste ensuite ces styles avec des textes réalistes.
« Notre méthode » ne suffit pas à valider un H2 si les vrais titres du site ressemblent à « Comment nous accompagnons les équipes dans la refonte de leur plateforme métier ».
Un design system qui fonctionne uniquement avec des textes courts n’est pas très robuste.
Le sujet de la lisibilité et des associations typographiques est développé dans mon article sur la typographie web.
Éviter les espacements décidés écran par écran
L’espacement est l’un des endroits où les petites différences s’accumulent le plus vite.
16 pixels ici. 18 sur la page suivante. 22 dans une modal.
Chaque valeur semble plausible.
Au bout de plusieurs dizaines d’écrans, personne ne sait plus quelle distance utiliser.
Une échelle limitée évite ce problème.
Par exemple :
4 / 8 / 12 / 16 / 24 / 32 / 48 / 64
Je peux l’utiliser pour les marges internes, les écarts entre éléments ou les distances entre groupes.
Je ne cherche pas une perfection mathématique. Je veux surtout éviter que chaque designer invente une nouvelle valeur lorsqu’il ouvre Figma.
Rayons, bordures et ombres : limiter les variations inutiles
Le rayon des angles paraît être un détail.
Il se multiplie pourtant très vite.
Un bouton à 8 pixels, une carte à 12, une modal à 16, un badge à 6, puis une nouvelle carte à 20.
Si ces différences ont une fonction, très bien. Si elles viennent simplement des habitudes successives des designers, je préfère les réduire.
Je peux définir :
radius-small pour les petits contrôles
radius-medium pour les boutons et champs
radius-large pour les cartes ou grands conteneurs
Le même raisonnement s’applique aux ombres et aux bordures.
Une interface n’a généralement pas besoin de sept ombres légèrement différentes.
Design tokens : nommer la fonction plutôt que la valeur
Un design token associe une valeur à un nom réutilisable.
Au lieu d’utiliser directement :
#2457FF
je peux appeler cette valeur :
action-primary
La nuance paraît technique, mais elle change la manière dont le système évolue.
Le jour où le bouton principal devient vert, le rôle « action-primary » reste correct.
À l’inverse, un token nommé « blue-button » devient incohérent.
Le même principe fonctionne avec :
spacing-medium
radius-card
text-secondary
Les tokens fournissent aussi un vocabulaire commun au design et au développement lorsqu’ils sont suffisamment proches des valeurs utilisées dans le code.
Utiliser les variables Figma pour centraliser les valeurs
Les variables Figma permettent de stocker certaines valeurs et de les réutiliser dans le système.
Elles peuvent notamment servir à représenter des tokens et à gérer plusieurs modes, comme un thème clair et un thème sombre.
Voir : Figma – Guide des variables.
Par exemple :
surface-primary = #FFFFFF
en thème clair.
Puis :
surface-primary = #171717
en thème sombre.
Le composant utilise toujours la même variable. C’est sa valeur qui change selon le mode.
Cette approche est beaucoup plus propre que de dupliquer chaque écran pour modifier manuellement toutes les couleurs.
Créer les composants à partir des vrais besoins
Une fois les fondations stabilisées, je commence par les éléments qui reviennent réellement dans les écrans.
Boutons, champs, liens, cartes et éléments de navigation arrivent souvent très tôt.
Je ne crée pas une bibliothèque complète « au cas où ».
Si aucun écran n’utilise de carrousel, je ne passe pas du temps à documenter un carrousel imaginaire.
Le système doit d’abord refléter le produit.
Figma regroupe justement composants, styles, variables et bibliothèques dans sa documentation consacrée à la création de design systems.
Ce qu’un simple bouton doit réellement prévoir
Un bouton primaire paraît être l’un des composants les plus simples.
Il possède pourtant plusieurs états.
- default ;
- hover ;
- focus ;
- pressed ;
- disabled ;
- éventuellement loading.
Il peut aussi exister en plusieurs niveaux : primaire, secondaire, discret ou destructif selon le produit.
Je teste également les vraies longueurs de texte.
Envoyer
n’impose pas les mêmes contraintes que :
Enregistrer les modifications
Si la seconde formulation casse le composant, le problème doit être réglé dans le système plutôt que dans chaque écran.
Réduire le nombre de variantes inutiles
Une bibliothèque peut devenir illisible lorsqu’elle contient une version différente pour chaque petit cas.
Je préfère éviter :
Button Blue
Button Blue Hover
Button Blue Small
Button Blue Icon
Button White
Button White Small
et regrouper les variations dans un seul composant.
Par exemple :
Type : Primary / Secondary
Size : Small / Medium / Large
Icon : On / Off
State : Default / Disabled / Loading
Les propriétés et variantes de composants de Figma sont justement conçues pour ce type d’organisation.
Le but n’est pas de réduire artificiellement le nombre de composants. Il est d’éviter six éléments différents lorsque le comportement réel est le même.
Un composant n’est pas un pattern
Cette distinction me semble particulièrement utile.
Un champ texte est un composant.
Demander une adresse complète est un pattern.
Un bouton est un composant.
Concevoir une étape de confirmation est un pattern.
Le GOV.UK Design System sépare justement ces deux niveaux.
Sa section Components regroupe les éléments d’interface.
Sa section Patterns documente des tâches plus larges, comme demander une adresse ou gérer une confirmation.
Une bonne bibliothèque de boutons ne garantit pas un bon formulaire.
Tester les composants avec de vrais contenus
Une carte avec :
Titre de la carte
et trois lignes de lorem ipsum n’est pas un test très exigeant.
Je préfère essayer le vrai contenu le plus long du projet.
Par exemple :
Audit d’accessibilité numérique et accompagnement à la mise en conformité
Si le composant s’effondre dès qu’un titre dépasse quatre mots, il faut le savoir avant le développement.
Je teste aussi les cas très courts, les cartes sans image ou les champs avec des messages d’erreur longs.
Cela rejoint directement le travail décrit dans mon article sur la composition web : une maquette doit supporter les vrais contenus, pas uniquement ceux qui arrangent le design.
Décrire le comportement responsive, pas uniquement deux versions
Une capture desktop et une capture mobile ne disent pas toujours ce qui se passe entre les deux.
Pour un composant important, je préfère décrire le comportement.
Une carte peut rester horizontale tant que sa largeur dépasse une certaine valeur, puis passer en colonne.
Une image peut changer de ratio.
Deux boutons peuvent rester côte à côte puis s’empiler lorsque le texte ne tient plus.
Cette logique évite de raisonner uniquement avec trois appareils fictifs.
Le développeur comprend la règle au lieu d’essayer de deviner comment interpoler entre deux captures Figma.
Intégrer l’accessibilité dans les composants
C’est l’un des intérêts les plus concrets d’un système partagé.
Si le bouton possède un focus visible correctement prévu, tous les écrans utilisant ce composant récupèrent cette règle.
Si le champ de formulaire prévoit le label, le texte d’aide, l’erreur et l’état disabled, il n’est pas nécessaire de réinventer ces cas dans chaque formulaire.
Le GOV.UK Design System documente pour ses composants leur structure, leur usage et leurs exemples de code.
Je préfère corriger une règle au niveau du composant plutôt que retrouver la même erreur dans vingt écrans lors d’un audit en fin de projet.
Documenter ce qui mérite réellement une règle
Une documentation trop volumineuse peut devenir aussi peu pratique qu’une absence de documentation.
Pour un bouton, j’ai besoin de savoir quand utiliser Primary ou Secondary, comment traiter une action destructrice et quels états existent.
Je n’ai pas forcément besoin d’une page entière expliquant qu’un bouton sert à déclencher une action.
Je documente surtout les décisions sur lesquelles deux designers pourraient raisonnablement faire des choix différents.
Par exemple :
- peut-on avoir deux CTA primaires dans la même zone ?
- quand utiliser un bouton plutôt qu’un lien ?
- que devient une carte sans image ?
- quels contenus peuvent apparaître dans une modal ?
La documentation doit réduire les hésitations réelles.
Choisir des noms qui resteront compréhensibles
Avec cinq composants, presque n’importe quel nom peut fonctionner.
Avec cinquante, le problème devient visible.
Card final
Card new
Blue button 2
ne donnent aucune indication fiable six mois plus tard.
Je préfère des noms liés à la fonction ou à la famille :
Button / Primary
Form / Text input
Navigation / Breadcrumb
Le même principe s’applique aux tokens et variables.
Un nom fonctionnel survit mieux aux évolutions de la direction artistique.
Prévoir des exceptions sans casser tout le système
Un design system ne doit pas transformer chaque page en assemblage identique.
Une campagne ou une landing page peut avoir besoin d’une composition particulière.
Je garde simplement une distinction claire entre une vraie exception et une nouvelle variante créée pour éviter de résoudre un problème.
Un hero événementiel qui sort volontairement de la grille peut avoir du sens.
Créer un nouveau bouton parce que l’ancien semble légèrement trop petit sur une maquette mérite davantage de discussion.
Un système trop rigide finit de toute façon par être contourné. Il vaut mieux prévoir comment les exceptions sont décidées.
Faire correspondre suffisamment Figma et le code
Une bibliothèque parfaitement organisée dans Figma peut diverger du produit développé.
Le designer possède trois types de boutons. Le front-end en a cinq. Les noms ne correspondent pas. Le focus n’est pas le même.
À ce stade, il existe deux systèmes.
Je préfère donc rapprocher suffisamment les composants, les états, les tokens et les noms utilisés dans les deux environnements.
Ils ne seront jamais identiques dans leur fonctionnement interne, et ce n’est pas nécessaire.
Mais lorsque Button / Primary / Small correspond à une variante identifiable côté développement, les échanges deviennent beaucoup plus simples.
Le GOV.UK Design System illustre cette logique en fournissant pour ses composants des recommandations d’usage et du code prêt à intégrer.
Éviter le « Card final v3 » six mois plus tard
Le système continue à évoluer après la mise en ligne.
Un nouveau besoin apparaît. Un composant pose un problème. Une nouvelle règle d’accessibilité doit être intégrée. La marque change une couleur.
Il faut alors décider si le besoin mérite :
- une modification du composant existant ;
- une nouvelle variante ;
- ou un nouveau composant.
Sans cette discipline minimale, une bibliothèque finit vite avec :
Card
Card v2
Card final
Card final new
Sur une petite équipe, la gouvernance peut rester très simple : une personne responsable de la bibliothèque et une validation avant l’ajout de nouveaux composants suffisent souvent.
Cas concret : un site vitrine de quinze pages
Pour un site de cette taille, je ne construirais pas un système énorme.
Je préparerais un UI kit suffisamment complet pour que les nouvelles pages restent cohérentes.
Il contiendrait la palette, les styles typographiques, l’échelle d’espacement, les boutons, champs de formulaire, cartes, accordéons, navigation et quelques blocs éditoriaux récurrents.
Je documenterais davantage les comportements qui ne sont pas évidents : responsive, hover, focus, erreurs de formulaire et variantes de cartes.
Ce niveau de système suffit généralement à éviter que chaque nouvelle page introduise ses propres règles.
Cas concret : une plateforme SaaS
Une plateforme SaaS accumule beaucoup plus vite les cas d’usage.
Formulaires, tableaux, filtres, modales, notifications, menus, états de chargement et permissions créent rapidement des dizaines de composants et de variations.
Plusieurs équipes peuvent aussi travailler sur le produit en parallèle.
Dans ce contexte, je formaliserais davantage :
- les tokens ;
- les composants et variantes ;
- les patterns ;
- les états ;
- les règles responsive ;
- les principes d’accessibilité ;
- la documentation ;
- la correspondance avec le code.
Un champ texte correctement conçu peut alors être réutilisé dans trente écrans sans que chacun redéfinisse sa hauteur, son focus ou son message d’erreur.
Les erreurs que je rencontre le plus souvent
Construire tout le système avant d’avoir conçu les écrans
On finit souvent par créer des composants qui ne servent jamais.
Appeler « design system » une bibliothèque de composants
Une bibliothèque devient un système lorsqu’elle contient aussi les règles d’usage nécessaires à sa cohérence.
Créer une variante pour chaque petit écart
La bibliothèque devient plus compliquée à utiliser que les composants eux-mêmes.
Nommer les tokens uniquement d’après leur couleur
Le nom devient faux dès que la direction artistique change.
Tester uniquement avec des textes courts
Les vrais labels et titres font souvent apparaître les limites du composant.
Oublier les états
Focus, erreur, loading et disabled ne doivent pas apparaître pour la première fois pendant le développement.
Documenter desktop et mobile comme deux images indépendantes
Le comportement entre ces deux largeurs reste alors inconnu.
Écrire une documentation que personne ne consultera
Chaque règle doit justifier son existence par une vraie décision à prendre.
Laisser le design et le code évoluer séparément
Les composants finissent par porter le même nom tout en ayant des comportements différents.
Interdire toute exception
Le système devient trop rigide et les équipes le contournent au lieu de l’utiliser.
Ma méthode pour construire le système
Je pars des écrans déjà conçus.
Je fais d’abord un inventaire des boutons, champs, cartes, couleurs, espacements, navigations et composants récurrents.
Les doublons et incohérences apparaissent assez vite.
Stabiliser les fondations
Je fixe les couleurs fonctionnelles, la hiérarchie typographique, les espacements, rayons et bordures.
Regrouper les composants proches
Plusieurs boutons presque identiques deviennent parfois un seul composant avec quelques propriétés bien choisies.
Définir les états
Je travaille hover, focus, pressed, disabled, erreur ou loading lorsque le composant les utilise réellement.
Tester le contenu réel
Je cherche volontairement les titres, labels et messages les plus contraignants du projet.
Passer par plusieurs largeurs
Je vérifie la logique responsive avant de considérer le composant terminé.
Documenter les décisions ambiguës
Quand utiliser Secondary ? Que faire sans image ? Combien de boutons principaux dans une modal ?
Comparer avec le développement
Les deux systèmes doivent parler suffisamment le même langage pour éviter les divergences.
Prévoir la maintenance
Je définis qui peut modifier la bibliothèque et comment les nouvelles variantes sont validées.
Ce travail fait le lien entre l’identité visuelle et la conception UX/UI.
Ma checklist avant livraison
- Les couleurs possèdent-elles des rôles clairs ?
- La hiérarchie typographique couvre-t-elle les vrais contenus ?
- Les espacements suivent-ils une échelle identifiable ?
- Les rayons, bordures et ombres sont-ils limités à quelques règles ?
- Les composants courants sont-ils réellement réutilisables ?
- Les variantes inutiles ont-elles été supprimées ?
- Les principaux états sont-ils définis ?
- Les composants supportent-ils les contenus longs ?
- Le comportement responsive est-il documenté ?
- Les règles d’accessibilité sont-elles intégrées aux composants ?
- Les noms permettent-ils de retrouver les éléments rapidement ?
- La documentation explique-t-elle les vrais cas d’hésitation ?
- Figma et les composants développés restent-ils suffisamment proches ?
- La maintenance du système a-t-elle un responsable identifié ?
FAQ sur les design systems et UI kits
Quelle différence entre un UI kit et un design system ?
Le UI kit rassemble surtout les styles et composants graphiques réutilisables. Le design system ajoute les règles d’usage, les patterns, la documentation et parfois une bibliothèque de composants développés.
Un petit site web a-t-il besoin d’un design system ?
Pas forcément. Pour un site simple, un UI kit structuré avec quelques règles de base est souvent suffisant.
À partir de quand un design system devient-il utile ?
Son intérêt augmente avec le nombre d’écrans, la fréquence des évolutions, le nombre de personnes qui travaillent sur le produit et la quantité de composants récurrents.
Qu’est-ce qu’un design token ?
Un design token associe un nom à une valeur réutilisable comme une couleur, un espacement ou un rayon. Il permet de modifier le système de manière centralisée et facilite le partage d’un vocabulaire commun entre design et développement.
Quelle différence entre un composant et un pattern ?
Un composant est un élément d’interface réutilisable, comme un bouton ou un champ. Un pattern décrit une solution plus large à une tâche, par exemple saisir une adresse ou confirmer une action.
Faut-il créer tous les composants avant de commencer les maquettes ?
Non. Il est généralement plus efficace de laisser les vrais écrans faire émerger les besoins, puis de transformer les éléments récurrents en composants.
Un design system limite-t-il la créativité ?
Il limite surtout les incohérences répétées. Une page ou une campagne peut toujours introduire une exception lorsque celle-ci est justifiée.
Faut-il documenter chaque composant ?
Pas avec le même niveau de détail. Les composants simples ont besoin de peu d’explications. Les composants comportant plusieurs usages, états ou risques d’erreur méritent davantage de documentation.
Figma et le code doivent-ils être identiques ?
Non, mais leurs composants, noms, variantes et comportements doivent rester suffisamment proches pour éviter que deux systèmes parallèles apparaissent.
Sources et ressources
- Figma – Créer des design systems : composants, styles, variables et bibliothèques partagées.
- Figma – Guide des variables : variables, modes et représentation de design tokens.
- GOV.UK Design System : exemple de système structuré autour de styles, composants et patterns.
- GOV.UK Design System – Styles : typographie, couleurs, layout et autres fondations visuelles.
- GOV.UK Design System – Components : composants réutilisables et recommandations d’usage.
- GOV.UK Design System – Patterns : solutions documentées pour des tâches utilisateurs récurrentes.
À lire également sur TooNetCreation
- Comment créer une identité visuelle forte sans sacrifier l’expérience utilisateur ?
- Moodboard : comment passer de l’inspiration à une véritable direction artistique ?
- Comment choisir une palette de couleurs pour son identité visuelle et son site web ?
- Typographie web : comment choisir et associer les polices d’un site sans sacrifier la lisibilité ?
- Minimalisme ou maximalisme : quel style choisir pour son site web ?
- Composition web : comment créer une mise en page originale sans perdre la lisibilité ?
- Photographie, illustration ou 3D : comment choisir le bon langage visuel pour une marque ?
- Création d’identité visuelle et charte graphique
- Conception UX/UI et expérience utilisateur
