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 à un 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 consultez :

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 hasard. 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 label 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 unique contrainte a plus d'impact visuel que la palette. Une plage de graisses large (corps 400, labels 600, titres 700, hero 800) 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 c'est ce léger décalage qui 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 type d'affichage entre 48 et 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 le texte est grand, 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 » sans que personne ne sache expliquer pourquoi.

/* 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 de tableau. Les petits labels en majuscules nécessitent un tracking positif pour la même raison optique pour laquelle le type 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 le rendre, et un ensemble gradué de gris quasi-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 bords 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 plane, 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. Si un traitement style Linear échoue souvent sur une landing page, ce n'est pas parce qu'il a été mal exécuté, mais parce 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 que tout le monde répète est que « Linear est violet ». Au moment où j'écris, l'interface observable s'apparente plutôt à du quasi-monochrome avec un seul accent à haute chroma 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 gradient 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, car 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 qui utilise rounded-lg et plus encore sur tout. Le padding est compact, dans la fourchette de 8 à 12px pour les contrôles, plutôt que les 16 à 24px livré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 un 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 un usage que votre produit n'a 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 à n'importe quel 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 cette 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. Un « 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 réside rarement dans un chiffre unique. Il s'agit plutôt de constater que tous les poids se situent entre 400 et 510, ou que chaque rayon est de 6 ou 12, rien d'autre. Les plages sont des règles ; les valeurs uniques ne sont que des échantillons.

4. 4

   Notez ce qui est absent

   Pas d'ombres. Pas de poids au-dessus de 510. Pas de second accent. Pas de dégradés. Les absences constituent la partie la plus précieuse d'une analyse technique (teardown) et celle qui ne survit jamais lors de l'exportation d'une palette.

5. 5

   Convertissez chaque observation en instruction

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

Nous avons échantillonné 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 IA. Les résultats expliquent pourquoi les systèmes dérivés d'une analyse technique se dégradent.

Les trois quarts de ces fichiers ne contiennent aucune prohibition. Mais comme le montre l'analyse ci-dessus, l'identité réside dans les prohibitions : pas de gras, pas d'ombres, pas de second accent. Un fichier qui liste les valeurs hex de Linear tout en omettant ses restrictions n'a capturé que la partie la moins distinctive du système en rejetant le reste.

Le chiffre des adjectifs vagues aggrave la situation. « Clean » apparaît dans 39 % de ces fichiers et « modern » 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 l'IA convergent vers le même aspect. Aucun de ces mots ne contraint quoi que ce soit.

Si le résultat d'une analyse technique est destiné à un agent de code, il doit pouvoir être lu une fois et appliqué sur des dizaines de fichiers. Cela implique des tokens nommés avec des fonctions définies, et une liste d'interdictions explicite. 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 proportion du fichier est constituée de la section Never et des prohibitions intégrées à chaque règle. C'est là tout l'enjeu. Si vous donnez à un agent une palette et un nom de police, vous lui donnez la permission de faire tout le reste comme il l'entend, alors que le reste constitue la majeure partie de l'interface.

Il existe une version de cet exercice qui produit quelque chose de pire que votre point de départ. Cela arrive quand l'analyse technique devient l'objectif : 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 en retour une imitation compétente qui n'a aucune raison d'exister.

Les design systems réellement performants découlent d'un argumentaire sur le lecteur. Celui de Linear soutient qu'un utilisateur intensif passant la journée sur un outil recherche la densité et la sobriété. Un produit d'apprentissage pourrait prôner un espacement généreux et de la chaleur. Un tableau de bord financier pourrait prôner des couleurs d'état réservées et une échelle neutre capable de survivre à un tableau dense. Les règles découlent de l'argument ; elles ne s'y substituent pas.

Utilisez donc l'analyse technique pour le calibrage, pas pour le contenu. Elle vous indique à quoi ressemble un système rigoureux : la précision des chiffres, le nombre d'éléments interdits, l'étroitesse des plages de valeurs. Ensuite, allez formuler votre propre argumentaire pour votre propre produit.