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 dit pas si leur système vous sera utile. Voici le même ensemble organisé selon vos objectifs de réflexion.

La suite de cet article examine chaque système, ce qui est disponible et ce qu'il convient d'en retenir.

L'étude croisée 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.

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'administration, mais l'effet est le même : des composants qui s'affichent de manière identique, 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 — ce qui est généralement le signe que le changement sous-jacent est réel et non simplement une mode.

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é les couleurs. Lecture complète.

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 secteur, 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'apparence de Shopify. Lecture complète.

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, ainsi que le linter comme mécanisme d'application. Les deux sont reproductibles 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.

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 justifiant 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 que l'on conteste. À ignorer : l'esthétique, qui est délibérément institutionnelle.

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 ne possède aucune 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.

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.

Il y a un schéma dans ce tableau qu'il convient de noter : les systèmes ayant les identités visuelles les plus fortes sont ceux qui publient le moins. Ce n'est ni une coïncidence, ni un secret concurrentiel. Un système dont le but est de donner à un produit son identité propre n'a aucun intérêt à être installable, et un système conçu pour être adopté par des milliers d'équipes doit être suffisamment neutre pour y survivre. Neutralité et identité s'opposent.

Les systèmes ci-dessus sont ceux qu'il convient d'étudier de près. Ceux-ci méritent d'être connus, pour l'aspect spécifique dans lequel chacun excelle.

Tous deux sont importants pour une raison facile à ignorer : 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 plateforme précisément autour de ce que ces deux systèmes possèdent.

Cloudscape est le système 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.

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 avoir à prendre 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.

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 de répertoire 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.

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 rapport 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 construits à partir d'un seul ensemble de tokens prouvent qu'il est solide.

Il s'agit de systèmes complets rendus en direct, et non de captures d'écran. Chacun utilise un ensemble 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 aussi bien à une section hero marketing qu'à un tableau dense.

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. 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. 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 pour une taille de 48px est une règle.

3. 3

   Chercher la plage de valeurs, pas la valeur unique

   Le résultat est rarement un chiffre unique. C'est le fait que chaque graisse se situe entre 400 et 510, ou que le rayon ne soit jamais que de 6 ou 12. Les plages sont des règles ; les valeurs uniques sont des échantillons.

4. 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. 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 rédigés 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.

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 cohérence conceptuelle.

Chaque système présenté ci-dessus découle d'une décision concernant l'utilisateur. La densité de Linear soutient qu'un utilisateur intensif passant la journée sur un outil privilégie le calme et l'information. La sobriété de GOV.UK soutient que le lecteur peut être stressé, disposer d'une mauvaise connexion et ne pas avoir d'équipement spécifique. La neutralité de Carbon soutient que des milliers d'équipes l'adopteront, et qu'aucune d'elles n'est l'équipe de marque d'IBM.

Utilisez ces exemples pour calibrer votre rigueur — le degré de précision des chiffres, le nombre d'interdictions, l'étroitesse des plages de valeurs. Établissez ensuite votre propre argumentaire concernant votre propre utilisateur, et laissez les règles en découler.