Chartes de marque vs design tokens

Ouvrez côte à côte un PDF de charte de marque et un fichier de design tokens sur « le même » bleu. La page du PDF montre un échantillon, un paragraphe sur la confiance et la clarté, et un code hex composé en légende — une image de la valeur. Le fichier de tokens montre "brand-600": { "$value": "#2563eb" } — la valeur elle-même, sous une forme que Figma et un pipeline de build lisent directement. L’un est une documentation à propos de la couleur ; l’autre est la couleur, du point de vue du logiciel.

Les chartes de marque et les design tokens font des travaux différents, et la plupart des organisations ont besoin des deux : les chartes portent l’intention — pourquoi la marque a l’apparence qu’elle a, la voix, ce qui se fait et ce qui ne se fait pas, l’histoire dont un humain a besoin pour trancher un cas de jugement — tandis que les tokens portent les valeurs, les réponses lisibles par la machine que les outils de design et de build consomment sans interprétation. Le mode d’échec qui mérite un article, c’est d’utiliser l’un pour le travail de l’autre. Celui-ci fait partie de notre guide des couleurs de marque.

Quel est le vrai travail d’une charte de marque ?

Les chartes — le brand book, dans sa forme classique — existent pour transférer du jugement. Elles expliquent pourquoi le bleu est bleu, ce qu’il est censé transmettre, où il a sa place et où il ne doit jamais apparaître, ce que dégage la photographie, comment la marque s’exprime. Leur lecteur est un humain sur le point de prendre une décision que les règles n’avaient pas anticipée : un nouveau deck de partenariat, un mur de salon professionnel, un format que personne n’a encore conçu. L’intention, c’est ce qui se généralise au cas imprévu — une valeur seule ne peut pas vous dire si la nouveauté est fidèle à la marque.

Quel est le travail des design tokens ?

Les tokens sont les décisions de la marque sous forme de valeurs nommées : brand-600 est cette couleur exacte, text-primary est celle-ci, space-4 fait tant de pixels. Leurs consommateurs ne sont, pour l’essentiel, pas des personnes — les variables Figma, les feuilles de style, les bibliothèques de composants et les étapes de build les lisent directement, généralement dans un format standard comme le DTCG JSON. Un token répond à exactement un type de question — quelle est la valeur — et y répond à l’identique pour chaque consommateur, à chaque fois. Cette identité est tout l’enjeu : aucune interprétation, aucune approximation, aucune version du bleu qui dépende de qui l’a copiée.

Qu’est-ce qui déraille quand l’un fait le travail de l’autre ?

Un PDF comme source des valeurs se dégrade par approximation. Quand le brand book est l’endroit où vivent les valeurs, chaque lecteur les extrait à la main : une pipette sur l’échantillon (souvent depuis un export compressé), un code hex retapé de mémoire, une capture d’écran ajustée à l’œil. Chaque copie dérive un peu, chaque surface future copie sur la plus proche qui la précède, et en quelques années la marque a cinq bleus, dont aucun ne fait autorité. Le mécanisme, c’est la lecture humaine — une personne ré-exprime ce qu’elle a vu, et c’est dans la ré-expression que l’erreur s’introduit.

Les tokens comme source de l’intention n’expliquent rien. Un fichier JSON peut dire à un nouveau designer que brand-600 vaut #2563eb ; il ne peut pas lui dire pourquoi, ni que le bleu est réservé aux actions, ni que noyer une page sous cette couleur est précisément ce que la marque ne devrait jamais faire. Quand le cas imprévu se présente, un système réduit aux valeurs n’offre aucune aide — et le designer improvise, de façon plausible et hors marque.

La version intuitive : les humains retiennent l’essentiel et les machines retiennent les coordonnées. Un artefact destiné aux humains se lit et se raconte, et raconter approxime ; un artefact destiné aux machines se copie bit à bit. Adressez l’histoire au lecteur fait pour les histoires, et les nombres au lecteur fait pour les nombres.

À quoi ressemble une même décision écrite des deux façons ?

Une seule décision de marque — le bleu est notre couleur d’action — écrite sous chacun des artefacts.

Le paragraphe de charte, qui porte l’intention :

Le bleu est notre couleur d’action. Il apparaît partout où nous demandons quelque chose au lecteur — boutons, liens, le seul chiffre mis en avant sur une page de tarifs — et nulle part ailleurs. Sur des neutres calmes, il se lit comme de la décision ; étalé sur toute une page, il se lit comme du bruit. Les valeurs exactes vivent dans le fichier de tokens sous brand ; les remplissages interactifs utilisent accent avec sa couleur de texte associée on-accent.

Les entrées de tokens, qui portent les valeurs :

{
  "brand-600": { "$type": "color", "$value": "oklch(0.546 0.215 262.9)" },
  "accent":    { "$value": "{brand-600}" },
  "on-accent": { "$type": "color", "$value": "#ffffff" }
}

Ce oklch(0.546 0.215 262.9) correspond à #2563eb, et le texte blanc par-dessus mesure ≈5,2:1 — c’est pourquoi on-accent peut être déclaré plutôt qu’improvisé. Remarquez ce que chaque artefact porte que l’autre ne peut pas. Le paragraphe contient « et nulle part ailleurs » — une règle de retenue qu’aucun schéma de tokens n’encode. Les entrées contiennent la valeur exacte et son association vérifiée — une précision qu’aucun paragraphe ne conserve après avoir été retapé.

Ouvrez les décisions de couleur de cette charte comme un jeu de tokens vivant dans le Scale Composer — le bleu comme couleur de départ, la rampe qui en dérive, et les rôles sémantiques avec leurs vérifications de contraste posés à côté des noms auxquels la charte fait référence.

Comment relier chartes et tokens ?

Par référence, dans un seul sens. La forme moderne, ce sont des chartes qui nomment les tokens au lieu d’y incorporer les valeurs : le PDF montre la couleur et dit « ceci est brand-600 » ; le fichier de tokens possède le nombre. La ligne de partage tombe naturellement — les chartes disent notre bleu transmet de la décision et sert aux actions principales ; les tokens disent brand-600 vaut cette valeur exacte, et Figma et la base de code le consomment directement.

La raison, c’est la plus ancienne règle de la documentation : tout ce qui est énoncé à deux endroits finira par se contredire. Si le PDF incorpore #2563EB et que le fichier de tokens est ensuite corrigé ou affiné, le PDF a tort en silence — et c’est justement l’artefact que les gens capturent en photo. Si le PDF dit « brand-600 », il reste vrai à travers chaque changement de valeur. Quand c’est possible, les pages d’échantillons elles-mêmes sont régénérées à partir du fichier de tokens, si bien que même les images sont des rendus de la source plutôt que ses rivales.

Par où commencer ?

À partir de l’artefact que vous avez déjà. Si les chartes existent mais pas les tokens, récoltez chaque valeur littérale énoncée par le PDF — les codes hex, les tailles de police, les règles d’espacement — dans un seul fichier de tokens, puis modifiez les chartes pour qu’elles nomment les tokens au lieu d’incorporer les nombres. Transformez les valeurs énoncées par vos chartes en une source de tokens unique — partez de la couleur de marque comme couleur de départ, dérivez la rampe et les rôles sémantiques, et exportez le fichier DTCG, CSS ou Figma Variables que vos outils lisent directement.