Partir du problème, pas de la liste
Les compilations de design systems sont généralement organisées par entreprise, ce qui est l'axe le moins utile : vous savez déjà qui est Airbnb, et cela ne vous indique pas si leur système vous sera utile. Voici le même ensemble organisé selon ce que vous cherchez à résoudre.
| Lire | Parce que | |
|---|---|---|
| "Où placer les composants spécifiques à un produit ?" | Carbon, Encore | Tous deux ont résolu le problème via des couches : une fondation non modifiable et des sous-systèmes spécialisés au-dessus |
| "Comment s'assurer que le système est réellement appliqué ?" | Stripe, SLDS 2 | L'un supprime la possibilité de dévier ; l'autre utilise le linting pour la détecter. La documentation est la troisième option, et c'est celle qui échoue |
| "Comment maintenir la cohérence sur quatre plateformes ?" | Airbnb DLS | Des composants définis par contrat plutôt que par composition : la seule chose qui survit à quatre implémentations différentes |
| "Comment permettre aux clients de personnaliser profondément le thème ?" | SLDS 2, Stripe Elements | Découplage de la structure et du style visuel, et une hiérarchie thème → variables → règles |
| "Pourquoi mon produit a-t-il l'air générique ?" | Linear | L'identité naît de ce qu'un système refuse de faire, et ces refus sont précisément ce que la plupart des systèmes omettent |
| "Comment le livrer aux utilisateurs ?" | Polaris | La question de savoir si vous ou vos utilisateurs contrôlez la version découle de celui qui est responsable de l'aspect visuel |
La suite de cet article examine chaque système, ce qui est disponible et ce qu'il convient d'en retenir.
Les trois systèmes ayant évolué au cours des dix-huit derniers mois
L'étude conjointe de Carbon, Polaris et Lightning révèle un point qu'aucun d'eux n'aborde individuellement. Tous trois ont récemment été restructurés, de manières différentes, sur un même postulat : le code consommant un design system n'est plus, de plus en plus, écrit par un humain lisant la documentation.
| Ce qui a changé | Le pari | |
|---|---|---|
| IBM Carbon | Déploiement d'un serveur MCP exposant la documentation, des exemples de code de composants, des graphiques et des composants expérimentaux aux agents | Les agents devraient récupérer le système au moment de la génération plutôt que de s'appuyer sur les données d'entraînement |
| Salesforce Lightning | SLDS 2 : architecture CSS découplée du style visuel par défaut, hooks de stylisation via des propriétés personnalisées, linter validant le balisage | La structure et l'apparence doivent être séparées, et les violations doivent être détectées mécaniquement |
| Shopify Polaris | React déprécié au profit de web components agnostiques vis-à-vis du framework, servis via un CDN | La livraison ne doit pas présumer du framework ayant généré la page |
Salesforce est le plus explicite, décrivant SLDS 2 comme le fondement de son design system agentique et évoquant des expériences utilisateur générées dynamiquement. La raison invoquée par IBM pour le serveur MCP inclut un code généré de plus haute fidélité. L'approche de Shopify vise à ce que les applications paraissent natives dans l'interface d'administration, mais l'effet est le même : des composants qui s'affichent identiquement, quel que soit l'outil qui les a assemblés.
Rien de tout cela n'a été coordonné. Trois entreprises avec des produits différents, des contraintes différentes et aucune raison de s'accorder sont arrivées à des conclusions compatibles dans la même fenêtre temporelle ; c'est généralement le signe que le changement sous-jacent est réel et non simplement une mode.
Les systèmes ouverts et installables
IBM Carbon
Open source, financé et construit par IBM, basé sur l'IBM Design Language comme couche de fondation de marque distincte, avec des systèmes de domaine (IBM Products, Cloud, IBM.com) au-dessus du cœur. React, Web Components et Elements sont maintenus par l'équipe Carbon ; Angular, Vue et Svelte sont maintenus par la communauté, et la documentation le précise, une transparence honnête que la plupart des systèmes omettent.
À retenir : la séparation en trois couches et la pratique de publier qui maintient chaque implémentation. À ignorer : l'adoption intégrale si la différenciation visuelle est cruciale pour votre produit, car la densité et les idiomes d'interaction portent l'identité d'IBM même après avoir modifié le thème des couleurs. Lecture complète.
Shopify Polaris
Fondations, tokens, composants et plus de 400 icônes axées sur le commerce. La bibliothèque React est désormais marquée comme dépréciée ; les web components sont chargés depuis un CDN Shopify et ajoutés automatiquement par Shopify CLI.
À retenir : le kit d'icônes de commerce si vous travaillez dans ce domaine, l'approche de nommage des tokens et le raisonnement sur le modèle de livraison. À ignorer : les composants en dehors d'une application Shopify. Ils donneront à votre produit l'aspect de Shopify. Lecture complète.
Salesforce Lightning
SLDS 1 a été lancé en 2015 comme un framework CSS avec une apparence intégrée. SLDS 2 l'a reconstruit autour de propriétés CSS personnalisées, a ajouté une bibliothèque Figma dont les noms de tokens correspondent exactement au code, et a déployé des outils de linting qui valident le balisage selon les règles.
À retenir : la parité de nommage entre Figma et le code, et le linter comme mécanisme d'application. Les deux sont copiables sans adopter une seule ligne de CSS Salesforce. À ignorer : le framework lui-même, sauf si vous construisez sur la Lightning Platform. Lecture complète.
GOV.UK Design System
L'exemple le plus probant d'un système construit autour d'une contrainte que personne d'autre ne prend aussi au sérieux : il doit fonctionner pour tout le monde, y compris les personnes utilisant d'anciens appareils, des connexions lentes, des lecteurs d'écran ou étant sous stress. Les composants sont accompagnés de recherches publiées sur la manière dont ils ont été testés et pourquoi ils ont cet aspect.
À retenir : la pratique de publier les preuves derrière chaque composant. Presque personne ne le fait, et c'est ce qui fait la différence entre un système que l'on suit et un système contre lequel on argumente. À ignorer : l'esthétique, qui est délibérément institutionnelle.
Atlassian Design System
Ancien, minutieusement documenté et exceptionnellement solide sur les directives de contenu et de ton plutôt que sur la seule spécification visuelle : la partie d'un design system que la plupart des équipes n'écrivent jamais.
À retenir : les normes de rédaction et de contenu. Si votre système n'a pas de section sur la formulation des textes, c'est le modèle à suivre. À ignorer : rien en particulier ; c'est une référence générale pertinente.
Les systèmes documentés mais privés
Cette catégorie prête à confusion, il est donc utile de le préciser clairement : plusieurs des design systems les plus cités ne peuvent pas être téléchargés. Ce qui existe, ce sont les écrits publiés par l'équipe à leur sujet, lesquels sont souvent plus utiles que ne l'aurait été le code.
| Disponible | L'enseignement à en tirer | |
|---|---|---|
| Stripe | Deux systèmes d'intégration publics (Apps UI toolkit, Elements Appearance API) ; le système interne n'est pas publié | La posture suit la limite de confiance : un vocabulaire fermé sur la surface de Stripe, une échelle de personnalisation sur la vôtre |
| Airbnb DLS | Comptes d'équipe publiés ; aucun package | Des composants en tant qu'unités autonomes avec des éléments déclarés, rejetant explicitement la composition atomique |
| Spotify Encore | Documentation d'équipe publiée ; aucun package | Couches concentriques, et l'aveu public qu'une flexibilité excessive a nécessité une nouvelle couche pour corriger le tir |
| Linear | Rien en première partie ; des extractions tierces d'une fiabilité variable | L'identité passe par la contrainte : une plage de graisses étroite, des traits fins plutôt que des ombres, une seule couleur d'accentuation utilisée avec parcimonie |
Méfiez-vous des « extractions » de systèmes privés par des tiers. Un rapport de style par scraping peut vous indiquer qu'une surface utilise un gris particulier. Il ne peut pas vous dire si ce gris est une étape délibérée d'une échelle ou un accident sur une page, et il ne capture jamais les interdictions, ce qui est pourtant l'élément qui aurait rendu la copie exploitable.
Il y a une tendance dans ce tableau qui mérite d'être notée : les systèmes dotés des identités visuelles les plus fortes sont ceux qui publient le moins. Ce n'est ni une coïncidence ni un secret industriel. Un système conçu pour qu'un produit unique lui ressemble n'a rien à gagner à être installable, tandis qu'un système conçu pour être adopté par des milliers d'équipes doit être assez neutre pour survivre à cette adoption. Neutralité et identité sont inversement proportionnelles.
Le reste du domaine, en bref
Les systèmes ci-dessus sont ceux qu'il faut étudier de près. Ceux-ci méritent que l'on sache qu'ils existent, avec la chose précise pour laquelle chacun excelle.
Systèmes de plateforme
| Prendre | Attention à | |
|---|---|---|
| Material Design | Le traitement public le plus complet de la motion et des couches d'état. Son modèle d'élévation et d'état d'interaction mérite d'être lu, même si vous ne l'utilisez jamais | L'adopter intégralement donne à un produit web l'apparence d'une application Android. Ses choix sont affirmés et lisibles pour les utilisateurs |
| Apple Human Interface Guidelines | La documentation la plus claire sur le *pourquoi* d'une convention plutôt que sur son *quoi*. Excellent sur les idiomes de plateforme et l'accessibilité | Il s'agit de directives, pas d'une bibliothèque de composants. Il n'y a rien à installer, et une application hors plateforme ne se transpose généralement pas. |
Les deux comptent pour une raison facile à manquer : ils fixent les conventions que vos utilisateurs ont déjà apprises. Même si vous ne construisez rien avec eux, ils définissent ce que signifie « le bouton retour se comporte normalement ». Le DLS d'Airbnb a tracé sa ligne de divergence par rapport à la plateforme précisément autour de ce que ces deux-là maîtrisent.
Grands systèmes produits
| Vaut le coup pour | |
|---|---|
| GitHub Primer | Une documentation exceptionnellement bonne sur le moment où il *ne faut pas* utiliser un composant, ainsi qu'une approche mature pour déployer le même système sur Rails, React et des pages statiques |
| Microsoft Fluent | La plus grande tentative publiée d'un système unique sur desktop, web et mobile avec des environnements natifs véritablement distincts. Instructif, surtout pour réaliser la difficulté de la tâche |
| AWS Cloudscape | Le meilleur exemple public d'un système conçu spécifiquement pour des interfaces de console denses et riches en données : tableaux, filtres, listes de ressources. Rare et utile si vous développez ce type de produit |
| Uber Base Web | Une architecture de thémage robuste et un modèle de surcharge qui permet aux utilisateurs d'accéder aux composants internes de manière structurée |
Cloudscape est le sous-estimé. La plupart des systèmes publiés sont optimisés pour le marketing et les interfaces d'applications générales ; très peu prennent au sérieux les interfaces opérationnelles denses, et ceux qui le font publient rarement. Si vous développez des logiciels d'administration ou de console, il est plus proche de votre problématique que Material ou Polaris.
Primitives et distribution
| Ce que c'est | Ce que ce n'est pas | |
|---|---|---|
| Radix Primitives | Comportements accessibles et sans style pour les composants complexes : menus, dialogues, comboboxes | Un design system. Il n'a délibérément aucune opinion sur l'aspect visuel |
| shadcn/ui | Un mécanisme de distribution associé à une convention de tokens : les composants sont copiés dans votre repo, et non installés comme dépendances | Un design system non plus. Il définit le nom de vos tokens, mais pas votre densité, votre composition, vos motifs ou vos interdictions |
| Tailwind | Un système de contraintes pour l'espacement, la couleur et la typographie, appliqué au niveau des classes | Opinioné sur votre produit. Ses valeurs par défaut sont neutres et largement utilisées, c'est pourquoi elles paraissent génériques |
Cette ligne mérite d'être soulignée car c'est là que se trouvent la plupart des équipes. Adopter Radix, shadcn et Tailwind offre un excellent comportement accessible, une couche de tokens et une stratégie de distribution, sans imposer de décisions sur la densité, la composition, les motifs ou les interdits. Cette combinaison produit l'interface cohérente, compétente et entièrement interchangeable que l'on décrit souvent comme ayant un aspect « généré par IA ». L'explication complète.
Les annuaires et leur utilité
Plusieurs catalogues volumineux indexent les design systems publics et répondent bien à une question précise : quelqu'un dans mon secteur a-t-il résolu ce problème, et comment l'a-t-il nommé ? Une galerie de composants est réellement utile pour comparer onze approches d'un sélecteur de date côte à côte avant d'en concevoir une douzième.
Ce qu'ils ne font pas, c'est vous dire quel système mérite d'être étudié. Une entrée d'annuaire se résume à un lien et une capture d'écran ; le raisonnement se trouve dans la documentation de l'équipe, pas dans le catalogue. Utilisez-les pour la vue d'ensemble et allez à la source pour l'analyse approfondie.
L'aspect d'un système appliqué plutôt que documenté
Chaque exemple ci-dessus est une documentation que l'on lit. C'est la limite intrinsèque de ce format : un design system ne peut être jugé que lorsque les mêmes décisions sont appliquées à des écrans qui n'ont aucun lien entre eux. Une landing page prouve qu'un système peut être esthétique une fois. Une landing page, un tableau de bord et une fiche de composants créés à partir d'un seul jeu de tokens prouvent qu'il tient la route.
Il s'agit ici de systèmes complets rendus en direct, et non de captures d'écran. Chacun utilise un jeu de tokens appliqué à trois surfaces distinctes. Vous ne vérifiez donc pas si vous aimez les couleurs, mais si les *mêmes* décisions survivent au passage d'une section hero marketing à un tableau dense.
Kit showcase · live surfaces
Verdant Finance
Live renderVerdant Finance rendered from its real tokens across 3 surfaces.
La question à se poser pour tout exemple
Non pas « est-ce attrayant ? » mais « pourrais-je prédire l'écran suivant ? ». Un vrai système rend le douzième écran prévisible à partir des trois premiers. Si vous ne pouvez pas deviner l'aspect d'une modale après avoir étudié la landing page et le tableau de bord, le système est un style, et un style ne survit pas à l'arrivée d'un second designer ou d'un agent.
Réaliser soi-même une analyse (teardown)
La version la plus précieuse de cet exercice est celle que personne n'a publiée, appliquée à un produit de votre propre secteur. Cela prend environ une heure.
- 1
Capturer trois écrans, pas un seul
Un seul écran vous montre la palette. Trois écrans vous montrent quelles décisions se répètent, et c'est la répétition qui distingue un système d'une simple page.
- 2
Lire les valeurs calculées, ne pas se fier à l'œil
Ouvrez les outils de développement et notez le font-weight, le letter-spacing, le border-width, le border-radius et le padding. Un « espacement serré » est une impression ; -0.022em au-dessus de 48px est une règle.
- 3
Chercher la plage de valeurs, pas la valeur unique
La conclusion est rarement un chiffre unique. C'est le fait que chaque graisse se situe entre 400 et 510, ou que le rayon soit toujours de 6 ou 12. Les plages sont des règles ; les valeurs isolées sont des échantillons.
- 4
Noter ce qui est absent
Pas d'ombres. Pas de dégradés. Pas de second accent. Pas de graisse au-dessus de 510. Les absences sont le résultat le plus précieux d'une analyse et la première chose perdue lors de toute extraction automatisée.
- 5
Convertir chaque observation en instruction
« L'élévation est un palier de surface plus une bordure de 1px, jamais un box-shadow » est exécutable. « Minimaliste et précis » ne l'est pas. C'est à cette étape qu'une analyse devient un design system.
L'étape quatre est celle sur laquelle il faut insister. Nous avons analysé 299 fichiers DESIGN.md conçus pour guider des agents d'IA et avons constaté que 76 % ne contiennent aucune interdiction, tandis que 86 % spécifient les couleurs en hexadécimal brut sans rôle sémantique et 57 % ne définissent aucun motif distinctif. Ces fichiers décrivent une palette. L'identité qu'ils tentaient de capturer résidait dans les absences.
Trois quarts des guides de design trouvés dans la nature n'interdisent rien. Pourtant, l'identité se forge par le refus, et une palette copiée laisse ces refus de côté.
L'erreur à éviter
Il existe une manière d'étudier les design systems qui produit un résultat pire que de partir de zéro. Cela arrive quand l'exercice devient acquisitif : en assemblant les meilleures parties de neuf systèmes, vous obtenez une interface compétente, mais sans aucune logique directrice.
Chaque système mentionné ci-dessus découle d'une réflexion sur son utilisateur. La densité de Linear démontre qu'un utilisateur expert, passant sa journée sur l'outil, recherche le calme et l'information. La sobriété de GOV.UK souligne que le lecteur peut être stressé, disposer d'une mauvaise connexion et qu'on ne peut rien présumer de son équipement. La neutralité de Carbon prouve que des milliers d'équipes adopteront le système, et qu'aucune d'entre elles n'appartient à l'équipe brand d'IBM.
Utilisez ces exemples pour calibrer votre niveau de rigueur : la précision des valeurs numériques, le nombre d'interdictions, l'étroitesse des plages de valeurs. Définissez ensuite votre propre approche en fonction de votre utilisateur, et laissez les règles en découler.
Les kits de design d'Identity Forge sont des systèmes complets en ce sens : rôles de couleurs sémantiques pour les modes clair et sombre, échelles de typographie et d'espacement, motifs, et consignes explicites (do's and don'ts), le tout sérialisé dans un fichier DESIGN.md qu'un agent de code peut exécuter. Parcourez les kits ou découvrez ce qu'est un fichier DESIGN.md.
Quels sont les meilleurs exemples de design system pour apprendre ?
Cela dépend de votre question. Carbon et Encore (Spotify) pour la superposition (layering), Stripe et SLDS 2 pour l'application des règles (enforcement) et le thémage, le DLS d'Airbnb pour les contrats multiplateformes, Polaris pour la livraison, Linear pour voir comment la contrainte crée l'identité, et GOV.UK pour la publication des recherches derrière chaque composant.
Quels design systems majeurs puis-je réellement télécharger ?
Carbon, Polaris, Lightning, GOV.UK et Atlassian sont disponibles publiquement. Le système interne de Stripe, le DLS d'Airbnb, Encore de Spotify et le système de Linear ne le sont pas : pour ces derniers, seules les publications des équipes sont accessibles, ce qui constitue souvent l'artefact le plus utile.
Dois-je copier un design system que j'admire ?
Copiez la rigueur, pas le contenu. Tout bon système est un ensemble de réponses à des questions posées sur un utilisateur spécifique ; reprendre les réponses sans les questions revient à adopter une interface optimisée pour le produit d'un autre. Utilisez des analyses détaillées (teardowns) pour calibrer la précision de vos propres règles.
Pourquoi si peu d'entreprises publient-elles leurs design systems ?
Parce qu'un système conçu pour rendre un produit distinctif n'a aucun intérêt à être installable, tandis qu'un système conçu pour une adoption large doit être assez neutre pour fonctionner pour des milliers de produits sans lien entre eux. La publication pousse un système vers la neutralité, ce qui est l'opposé de ce que recherche une marque forte.
Les annuaires de design systems valent-ils la peine d'être utilisés ?
Pour la vue d'ensemble, oui. Ils sont utiles pour comparer plusieurs implémentations d'un même composant avant de concevoir la vôtre. Pour l'analyse approfondie, non. Une entrée d'annuaire se résume à un lien et une capture d'écran ; le raisonnement qui rend un système digne d'étude se trouve dans les écrits de l'équipe.