Jetons d’espacement : nommage et paliers

Les jetons d’espacement sont des entrées nommées pour les paliers d’une échelle d’espacement — space-4 ou space-md au lieu d’un 23px brut — stockées dans une source unique et consommées aussi bien par les outils de design que par le code. Ils transforment une liste de nombres en un vocabulaire partagé : un espace se choisit par son nom, et le nom se résout à la même valeur partout où il apparaît.

Cet article couvre les deux conventions de nommage dominantes et leurs compromis, les alias sémantiques, le nombre de paliers à exposer, et le chemin d’export qui porte une même échelle vers CSS, Tailwind et Figma. Il suppose qu’une échelle existe déjà — le hub système d’espacement explique comment on en construit une.

Pourquoi nommer les paliers, au fond ?

Parce que les noms sont ce qui rend un menu partagé. Une échelle d’espacement limite quelles valeurs existent ; les jetons rendent communicable le choix entre elles. Deux personnes qui cherchent « l’espace entre les champs de formulaire » arrivent au même jeton, là où elles n’arriveraient peut-être pas au même nombre. Il est aussi plus facile de garder en tête huit paliers nommés que huit valeurs en pixels : personne ne débat pour savoir si un espace doit faire 23px ou 26px quand le vrai choix est entre space-4 et space-5. La conversation monte d’un niveau — un palier de plus ou un palier de moins — qui est le niveau où les décisions d’espacement ont leur place.

Les jetons d’espacement doivent-ils utiliser des nombres ou des tailles de t-shirt ?

Les deux conventions largement répandues, comparées :

Aucune colonne ne l’emporte. Les noms numériques passent l’échelle avec élégance et restent honnêtes sur le fait qu’ils sont des positions sur une échelle ; les noms de t-shirt sont plus agréables à dire et à retenir. Ce qui fait mal, c’est de changer plus tard : les noms de jetons se répandent dans les composants, les feuilles de style, les bibliothèques de design et la documentation, et un renommage touche chacun d’eux. Choisissez une convention tôt et laissez-la être ennuyeuse.

Sur le nombre de paliers : exposez toute l’échelle, et gardez l’échelle courte — entre 6 et 10 paliers convient à beaucoup de produits. Un ensemble de jetons bien plus grand que l’échelle qui le sous-tend est le signe que des valeurs ponctuelles se réintroduisent sous de nouveaux noms.

Que sont les jetons d’espacement sémantiques ?

Des alias qui nomment une intention et pointent vers un palier : un gap-section qui se résout à space-7, un padding-card qui se résout à space-4. Les paliers bruts restent la source unique des valeurs ; les alias consignent pourquoi une valeur a été choisie.

Le bénéfice apparaît quand l’échelle change. Ré-échelonnez le système — une base plus grande, un ratio différent — et chaque espace de section du produit bouge de concert, parce que chacun pointe vers un alias qui pointe vers un palier. L’intention de mise en page survit au ré-échelonnement, et personne ne part à la chasse aux 64 codés en dur. Gardez les alias peu nombreux et véritablement structurels (sections, cartes, rythme des formulaires) ; un alias par composant réintroduit la prolifération que l’échelle a été construite pour éliminer.

Comment les jetons passent-ils du design au code ?

Par un format de fichier neutre vis-à-vis des outils. Le Design Tokens Community Group définit un format JSON — DTCG — pour les design tokens, afin qu’un seul fichier puisse alimenter de nombreux outils. Une échelle d’espacement exportée dans le format DTCG ressemble à ceci :

{
  "space": {
    "1": { "$value": "8px",  "$type": "dimension" },
    "2": { "$value": "11px", "$type": "dimension" },
    "3": { "$value": "16px", "$type": "dimension" },
    "4": { "$value": "23px", "$type": "dimension" },
    "5": { "$value": "32px", "$type": "dimension" },
    "6": { "$value": "45px", "$type": "dimension" },
    "7": { "$value": "64px", "$type": "dimension" }
  }
}

Les valeurs ne sont pas arbitraires — c’est une vraie échelle (base 16, ratio 2, deux notes par intervalle), et c’est là tout l’intérêt : le fichier de jetons est généré à partir de trois nombres, pas assemblé à la main.

À partir de cette source unique, les mêmes paliers se rendent en propriétés personnalisées CSS, en bloc de thème Tailwind v4 et en Variables Figma. Ouvrez la vue d’export dans Scale Composer — la même échelle rendue en jetons DTCG, propriétés personnalisées CSS, Tailwind v4 et Variables Figma. Changez un paramètre de l’échelle et chaque export le reflète, parce que les quatre se lisent depuis les mêmes paliers.

Pourquoi garder Figma et le code synchronisés est-il un problème de jetons ?

Parce que la dérive est structurelle, pas morale. Quand les designers maintiennent une liste d’espacements dans Figma et que les développeurs en maintiennent une autre en CSS, les deux finissent par diverger — quelqu’un ajoute un palier d’un côté, arrondit une valeur de l’autre, et six mois plus tard le fichier de design et le produit décrivent discrètement des systèmes différents. Demander à chacun d’être plus prudent traite un problème de source comme un problème de discipline. Avec une source générée unique qui alimente les deux côtés — Variables Figma pour le fichier de design, propriétés personnalisées ou thème pour le code — les listes n’ont pas l’occasion de diverger, parce qu’aucun côté ne maintient de liste. Les deux en lisent une.

Exportez la même échelle dans votre stack

Essayez le bout « code » du chemin : exportez cette échelle en thème Tailwind v4 — les paliers arrivent sous forme de bloc @theme prêt à coller dans une feuille de style. Ajoutez ensuite une note à l’échelle et exportez à nouveau : les paliers intermédiaires apparaissent dans le bloc, nommés et ordonnés, sans une seule valeur choisie à la main.