Le design system de Linear, lu comme un ensemble de contraintes

Commencez ici, car la plupart des confusions ultérieures viennent de l'omission de ce point. Linear ne publie pas de design system. Il n'y a pas de @linear/tokens sur npm, pas de Storybook, pas de site de documentation équivalent à design.linear.app, ni de bibliothèque Figma publiée par l'entreprise. Comparez cela avec Carbon d'IBM, Polaris de Shopify ou Salesforce Lightning, qui proposent tous des packages installables et une documentation publique par choix produit délibéré.

À la place, on trouve trois types de ressources secondaires, et il est utile de savoir laquelle vous lisez :

Cette distinction est cruciale car une extraction peut vous dire qu'une surface est #0f1011, mais ne peut pas vous dire s'il s'agit d'une étape délibérée au-dessus du canevas ou d'un accident. Tout ce qui suit est énoncé au niveau où cela peut être réellement étayé : des motifs observables, avec le raisonnement laissé visible pour que vous puissiez le remettre en question.

S'il n'y a qu'une chose à retenir : la typographie de Linear se situe dans une plage de graisses étroite, environ 400 à 510, sur pratiquement tout le produit. Un titre d'affichage de 72px et un libellé de 15px sont différenciés par la taille et la couleur, pas par la graisse. Le gras, au sens du 700 utilisé par la plupart des interfaces, est fonctionnellement absent.

Cette seule contrainte a plus d'impact visuel que la palette. Une plage de graisses large — 400 pour le corps, 600 pour les libellés, 700 pour les titres, 800 pour le hero — est le défaut de tout framework UI et de toute interface générée par IA. Cela paraît bruyant et générique, car la hiérarchie est hurlée plutôt que composée. Une plage étroite force la hiérarchie à être portée par la taille, l'espacement et la couleur, ce qui est plus long à maîtriser et beaucoup plus difficile à imiter par accident.

Le détail des polices variables est ce qui rend le 510 possible. Une graisse de 510 n'est pas une coupe statique ; elle existe parce que l'interface utilise une police variable où toute valeur sur l'axe est disponible. Tenter de reproduire cela avec des graisses statiques conduit au 500, ce qui est proche, et ce léger décalage explique pourquoi les réplications semblent « presque » correctes.

C'est le détail que la plupart des reproductions oublient totalement, et c'est une question de mesure plutôt que de goût. Dans Linear, l'espacement des lettres (letter-spacing) devient négatif à mesure que la taille augmente : le texte d'affichage dans la plage 48–72px se situe autour de -0.022em, les titres de taille moyenne autour de -0.012em, et le corps de texte autour de -0.010em. La relation est monotone : plus la police est grande, plus le tracking est serré.

La raison est optique, pas décorative. Des glyphes dessinés pour être lisibles à 16px possèdent des blancs latéraux (sidebearings) dimensionnés pour 16px. Si on les passe à 64px, ces espaces s'agrandissent aussi, et le mot semble visuellement se fragmenter en lettres isolées. Le design typographique professionnel compense cela avec des tailles optiques ; le design d'interface compense avec une rampe de tracking. La plupart des design systems définissent une seule valeur de letter-spacing, ou aucune, et leurs titres paraissent « lâches » d'une manière que personne ne sait nommer.

/* The ramp, expressed as tokens. Values shown are the pattern,
   not Linear's — pick your own by eye at each step. */
:root {
  --tracking-display: -0.022em;  /* 48px and up */
  --tracking-heading: -0.012em;  /* 20-32px */
  --tracking-body:    -0.010em;  /* 13-17px */
  --tracking-label:    0.02em;   /* small caps, 11-12px: loosens */
}

Notez l'inversion en bas. Les petits labels en majuscules nécessitent un tracking positif pour la même raison optique pour laquelle le texte d'affichage demande un tracking négatif. Une rampe qui ne va que dans une seule direction ne représente que la moitié de la règle.

Linear sépare les surfaces avec des bordures d'une largeur sub-pixel — 0,5px sur les écrans capables de les afficher — et un ensemble gradué de gris presque noirs, plutôt qu'avec des ombres portées. Le canevas se situe environ à #08090a, les surfaces de cartes un cran au-dessus vers #0f1011, et les panneaux surélevés encore au-dessus. Les bordures utilisent un gris à faible contraste autour de #23252a pour les contours structurels, avec un cran légèrement plus clair pour les séparateurs de section.

C'est un véritable compromis, pas un choix strictement supérieur, et il est important d'être honnête sur le coût. Les ombres communiquent la profondeur de manière pré-attentive ; le lecteur sait qu'une carte est au-dessus de la page sans même y prêter attention. Les hairlines ne le font pas. Ce que l'on gagne, c'est une surface plate, dense et précise où une grande quantité d'informations peut cohabiter sans bruit visuel — ce qui est exactement ce dont un gestionnaire de tickets a besoin, et exactement ce dont un site marketing n'a pas besoin.

C'est sur cette dernière ligne qu'il faut agir. La raison pour laquelle un traitement style Linear échoue souvent sur une landing page n'est pas qu'il a été mal exécuté ; c'est que la stratégie d'élévation a été choisie pour la densité d'information, puis appliquée à une surface ne contenant que quatre cartes.

L'observation couleur que tout le monde répète est : « Linear, c'est du violet ». Au moment où j'écris, l'interface observable s'apparente plutôt à du quasi-monochrome avec un seul accent à haute chromie utilisé pour l'action primaire et l'état actif, plus un petit ensemble de fonds chromatiques réservés aux tags et labels. La teinte spécifique de l'accent a changé au fil des redesigns ; le fait structurel, lui, est resté.

Le fait structurel est un ratio. L'accent apparaît sur un faible pourcentage de pixels — un bouton primaire, un indicateur de navigation actif — et tout le reste est gris. Copier la teinte et l'appliquer avec une densité SaaS typique (titres accentués, icônes accentuées, liens accentués, bordures accentuées, hero avec dégradé accentué) produit quelque chose qui partage la palette de Linear, mais aucun de son caractère.

Les couleurs de tags méritent d'être traitées à part car elles appartiennent à un système différent. Quelques fonds chromatiques — un violet, un bleu sarcelle, un corail, un vert — existent pour rendre les labels distinguables d'un coup d'œil, comme fonctionnent les séries catégorielles dans une palette de tableau de bord. Ce ne sont pas des couleurs de marque ni des couleurs de statut ; un système qui confond les trois finit par être incapable d'afficher une erreur en rouge parce que le rouge signifie déjà « marketing » sur un label quelque part.

Les rayons sont serrés — environ 6px sur les contrôles et 12px sur les conteneurs plus larges — contrairement à l'habitude de l'écosystème actuel qui utilise rounded-lg et plus encore sur tout. Le padding est compact, dans la plage 8–12px pour les contrôles, plutôt que les 16–24px proposés par la plupart des bibliothèques de composants.

Tout cela découle de la même source que les hairlines : la densité. Un outil dense ne peut pas gaspiller 24px de padding par contrôle, et des rayons trop larges sur de petits éléments finissent par « manger » l'élément. La règle sous-jacente n'est pas « utilisez 6px », mais que le rayon doit évoluer avec l'élément ; or, la plupart des systèmes appliquent un seul token de rayon aussi bien à un bouton de 28px qu'à un panneau de 400px.

Copier cela est le mauvais résultat, et pas seulement pour des raisons de marque. Un design system est la conséquence d'une décision produit. La densité de Linear sert des personnes qui passent six heures par jour dans un gestionnaire de tickets ; ce lecteur a des besoins différents de quelqu'un qui arrive sur une page de tarifs pour quarante secondes. Transposer ce traitement de surface d'un contexte à l'autre revient à créer une interface optimisée pour une tâche que votre produit n'effectue pas.

L'élément transférable, c'est la méthode. Chaque observation ci-dessus suit le même schéma : remarquer un motif, identifier la contrainte qui le produit, puis consigner cette contrainte sous forme de règle. C'est un exercice reproductible que vous pouvez appliquer à tout produit que vous admirez, et c'est ce qui transforme un mood board en quelque chose qu'un agent peut exécuter.

1. 1

   Capturez trois écrans, pas un seul

   Un seul écran vous indique la palette. Trois écrans vous indiquent quelles décisions sont cohérentes — et c'est la cohérence qui distingue un système d'une simple page.

2. 2

   Mesurez, ne vous fiez pas à l'œil

   Ouvrez les outils de développement et examinez les valeurs calculées : font-weight, letter-spacing, border-width, border-radius, padding. Notez les chiffres réels. Le « tracking serré » n'est pas une règle ; -0.022em au-dessus de 48px en est une.

3. 3

   Cherchez la plage de valeurs, pas la valeur unique

   L'enseignement vient rarement d'un seul chiffre. C'est le fait que toutes les graisses se situent entre 400 et 510, ou que chaque rayon soit de 6 ou 12 et rien d'autre. Les plages sont des règles ; les valeurs uniques sont des échantillons.

4. 4

   Notez ce qui est absent

   Pas d'ombres. Pas de graisses au-dessus de 510. Pas de second accent. Pas de dégradés. Les absences sont la partie la plus précieuse d'une analyse et celle qui ne survit jamais à l'exportation d'une palette.

5. 5

   Convertissez chaque observation en instruction

   « L'élévation utilise une bordure de 1px et un saut de surface, jamais de box-shadow » est exécutable. « Minimaliste et précis » ne l'est pas. C'est à cette étape qu'une analyse devient un design system.

Nous avons analysé 299 fichiers DESIGN.md publiés dans des dépôts et répertoires publics pour voir ce que contient réellement un guide de design lorsqu'il est écrit pour être lu par un agent d'IA. Les résultats expliquent pourquoi les systèmes dérivés d'analyses se dégradent.

Trois quarts de ces fichiers ne contiennent aucune interdiction. Pourtant, comme le montre l'analyse ci-dessus, c'est dans les interdictions que réside l'identité — pas de gras, pas d'ombres, pas de second accent. Un fichier qui liste les valeurs hexadécimales de Linear en omettant ses restrictions ne capture que la partie la moins distinctive du système et rejette tout le reste.

Le chiffre concernant les adjectifs vagues aggrave la situation. « Clean » apparaît dans 39 % de ces fichiers et « moderne » dans 36 %. Ce sont deux mots qu'un modèle satisfera volontiers avec la moyenne de ses données d'entraînement, ce qui est la raison pour laquelle les interfaces générées par IA convergent vers le même aspect. Aucun de ces mots n'impose de contrainte.

Si le résultat d'une analyse est destiné à un agent de code, il doit pouvoir être lu une fois et appliqué à des dizaines de fichiers. Cela implique des tokens nommés avec des objectifs précis et une liste d'interdictions explicites. Voici la structure :

## Type

Weights: 400 and 510 only. Never use 600 or above; hierarchy is
carried by size and colour, not weight.

Tracking ramps with size:
- 48px and up: -0.022em
- 20-32px:     -0.012em
- 13-17px:     -0.010em
- 11-12px uppercase labels: +0.02em

## Elevation

Never use box-shadow. Elevation is a surface step plus a 1px border:
- canvas   -> surface   -> elevated
- Border: --border-subtle for structure, --border-strong for sections

## Accent

One accent. It appears on primary buttons and active nav state only.
Do NOT use the accent for headings, links, icons, borders or gradients.
Tag fills are a separate categorical set and are not brand colour.

## Never

- No gradients
- No drop shadows
- No second accent colour
- No font-weight above 510
- No border-radius above 12px

Remarquez quelle place occupent la section Never et les interdictions intégrées à chaque règle. C'est ce ratio qui importe. Si vous donnez à un agent une palette et un nom de police, vous lui donnez la permission de tout faire comme bon lui semble pour le reste, et ce « reste » constitue la majeure partie de l'interface.

Il existe une version de cet exercice qui produit quelque chose de pire que le point de départ. Cela arrive quand l'analyse devient le but : vous assemblez un ensemble rigoureux de règles décrivant le produit de quelqu'un d'autre, vous le donnez à un agent, et vous obtenez une imitation compétente mais sans raison d'exister.

Les design systems réellement performants découlent d'une réflexion sur l'utilisateur. Celui de Linear repose sur l'idée qu'un utilisateur expert, passant sa journée dans l'outil, recherche la densité et la sobriété. Un produit d'apprentissage pourrait prôner des espacements généreux et de la chaleur. Un tableau de bord financier pourrait opter pour des couleurs de statut réservées et une échelle neutre adaptée aux tableaux denses. Les règles découlent de l'argumentaire ; elles ne s'y substituent pas.

Utilisez donc l'analyse pour le calibrage, pas pour le contenu. Elle vous montre à quoi ressemble un système rigoureux — la précision des chiffres, le nombre d'interdictions, l'étroitesse des plages de valeurs. Ensuite, construisez cet argumentaire pour votre propre produit.