Comment donner votre système de design à un outil de codage IA

Pour donner votre système de design à un outil de codage IA, remettez-lui un fichier de tokens : exportez le système en propriétés personnalisées CSS ou en thème Tailwind — des formats que les agents de code lisent nativement — placez le fichier dans le projet, et demandez à l’outil de référencer les noms de rôles comme --color-accent plutôt que d’écrire des valeurs brutes. Le fichier reste la source unique des valeurs de design, et l’IA le consomme comme elle consomme le reste de votre code.

Les étapes ci-dessous citent Cursor, v0 et les outils de la classe Claude Code à titre d’exemples, mais ces noms sont illustratifs plutôt qu’une liste : le mécanisme, c’est un fichier dans le dépôt plus une instruction permanente, et il fonctionne dans tout outil qui lit les fichiers du projet. C’est la moitié pratique du dispositif décrit dans notre guide de l’IA et des systèmes de design — l’IA construit, tandis qu’une source déterministe détient les valeurs.

Quel format pour le fichier de tokens ?

Trois formats couvrent les cas pratiques, et ils peuvent porter les mêmes noms :

• Propriétés personnalisées CSS. Neutres vis-à-vis du framework et lues directement par tout outil qui écrit du CSS ; le guide des propriétés personnalisées de MDN explique comment elles se propagent en cascade et se résolvent. Le choix par défaut le plus sûr quand vous ne savez pas ce que l’IA va générer.
• Tailwind v4 @theme. Si le projet utilise Tailwind, le bloc de thème transforme vos tokens en classes utilitaires — l’agent écrit alors bg-accent et text-accent au lieu de valeurs arbitraires, soit la même discipline exprimée dans la grammaire de Tailwind.
• DTCG JSON. Le format d’échange neutre vis-à-vis des outils — ce n’est pas ce avec quoi un agent applique les styles directement, mais la source à partir de laquelle les deux autres sont générés, et la forme que vos tokens conservent lorsqu’ils passent d’un outil à l’autre. Notre article sur le format DTCG en parle.

Choisissez selon ce que l’IA écrit : un projet Tailwind reçoit le bloc @theme, tout le reste reçoit les propriétés personnalisées, et le fichier DTCG voyage à côté comme source des deux.

Comment le mettre en place, étape par étape ?

1. Exportez le système. Dans Scale Composer, une seule session exporte les quatre formats — DTCG JSON, propriétés personnalisées CSS, Tailwind @theme et Figma Variables — depuis le même état, de sorte que les noms concordent d’un format à l’autre. Si vos tokens vivent déjà ailleurs, importez d’abord le fichier ; l’aller-retour préserve ce qui est entré.
2. Placez le fichier dans le dépôt. Pour les propriétés personnalisées, un endroit ordinaire comme src/styles/tokens.css ; pour Tailwind, le bloc @theme va dans la feuille de style d’entrée. Ce qui compte, c’est que le fichier soit à l’intérieur du projet que l’outil peut voir.
3. Écrivez la règle permanente. La plupart des outils de codage IA lisent un fichier d’instructions au niveau du projet — le nom varie selon l’outil, pas l’idée. Ajoutez une règle du genre : toutes les couleurs, tailles de police et espacements proviennent de tokens.css ; référencez les propriétés personnalisées par leur nom ; n’introduisez pas de nouvelles valeurs hex ni de valeurs en pixels en dur.
4. Formulez vos prompts en rôles. Demandez « le rôle accent sur l’action principale », pas « un joli bleu ». Le vocabulaire du prompt doit correspondre au vocabulaire du fichier.
5. Inspectez les diffs à la recherche de valeurs brutes. Un nouveau code hex ou une valeur en pixels codée en dur qui apparaît dans un diff, c’est le signe que la source a été contournée. La correction n’est pas « change la couleur » — c’est « utilise le rôle ».

Pour voir ce que l’agent lirait réellement, ouvrez un thème Tailwind v4 généré dans Scale Composer — un bloc @theme où les rampes de couleur, les tailles typographiques et les pas d’espacement descendent tous d’une seule échelle globale, prêt à être collé dans un projet.

Pourquoi référencer des rôles plutôt que des valeurs brutes ?

Il y a une raison côté code et une raison côté modèle.

Côté code : une valeur brute copiée dans un composant est une bifurcation — correcte aujourd’hui, orpheline dès le premier changement de marque. Un rôle référencé est un lien vivant : changez ce que stocke --color-accent et chaque consommateur se met à jour, y compris le code que l’IA a écrit il y a des mois. L’indirection par les rôles est aussi ce qui rend un mode sombre praticable : Scale Composer dérive son mode sombre comme un jeu de valeurs distinct sous les mêmes noms de rôles — une dérivation, pas une inversion — de sorte que le code qui référence les rôles récupère des valeurs sombres réfléchies sans une seule modification.

Côté modèle : les noms restreignent l’espace des choix. Quand on lui demande « un bleu », un modèle échantillonne dans un ensemble de valeurs plausibles en pratique illimité. Quand on lui demande de choisir parmi une douzaine de noms de rôles dans un fichier qu’il peut voir, la bonne réponse est présente dans son contexte, et la tâche passe de la génération à la simple recherche. C’est de cet effondrement que vient la cohérence — et son absence explique pourquoi les interfaces générées par IA dérivent hors marque.

Comment garder le fichier comme source unique ?

Deux habitudes. D’abord, ne modifiez pas les exports à la main : une valeur éditée dans tokens.css la fait bifurquer de la source DTCG, et le prochain export la remplace. Quand une valeur doit changer, changez-la à la source — réimportez le fichier DTCG dans Scale Composer, ajustez, ré-exportez ; l’aller-retour est sans perte, si bien que le fichier peut circuler entre source et export sans dégradation. Ensuite, inscrivez la même attente dans les instructions de l’IA : le fichier de tokens est généré, donc l’outil doit proposer des changements à la source plutôt que d’éditer les valeurs en ligne.

Est-ce que ça marche en dehors de Cursor ?

Le mécanisme se généralise à tout outil qui lit les fichiers du projet — agents intégrés à l’éditeur, agents en ligne de commande, et générateurs web qui acceptent le contexte du projet. Pour les outils uniquement conversationnels, le même principe s’applique sous une forme plus grossière : collez le bloc de tokens au début de la conversation, et re-fournissez-le à chaque session, puisque la source vit alors dans la conversation plutôt que dans le dépôt. Les noms et fonctionnalités des outils changent vite ; le motif fichier-plus-instruction est resté stable parce qu’il s’appuie sur la seule chose que tous ces outils partagent — ils lisent ce qu’on met devant eux.

Partez de l’export

Si le projet n’est pas sous Tailwind, le même système sort en CSS pur : exportez la même échelle en propriétés personnalisées CSS — des noms de rôles identiques sous une forme neutre vis-à-vis du framework. Le format est un rendu ; les noms sont le contrat. Changez le rendu pour l’adapter à votre stack, et l’instruction que vous donnez à l’IA reste mot pour mot la même.