Stratégie de synchronisation Figma pour les palettes de marque custom

English summary: Custom brand palettes (accent, secondary) introduced in ADR-024 follow the exact same Tokens Studio → Figma Variables sync pipeline as the existing Radix palettes, living in the same "Primitives" collection with no special-case process. Designers never edit Figma variables directly — every palette change flows through a PR with mandatory Principal Designer approval.

>

*The original French version follows below — preserved unaltered as the historical record.*

Contexte

ADR-024 a introduit deux palettes de marque custom (accent rose-corail et secondary bordeaux) dans tokens/primitives.json. Contrairement aux palettes Radix UI déjà présentes (Teal, Blue, Red, etc.), ces palettes :

1. Ne sont pas dans Figma Community — Tokens Studio ne peut pas les importer depuis un fichier partagé officiel 2. N'ont pas de documentation de référence externe — les utilisateurs doivent comprendre chaque step depuis le JSON seul 3. Peuvent évoluer — les valeurs hex sont décisions de design, pas des constantes issues d'un système tiers

La question soulevée dans la dette d'ADR-024 :

Comment les palettes custom sont-elles synchronisées avec Figma de manière fiable, gouvernée, et sans créer une seconde source de vérité ?

Décision

Principe : même pipeline que les palettes Radix

Les palettes custom (accent, secondary) sont traitées exactement comme les palettes Radix dans le pipeline de sync. Il n'existe pas de processus spécial pour elles.

tokens/primitives.json
  ↓ (Tokens Studio lit ce fichier)
Variables Figma — Collection "Primitives"
  ↓ (les designers utilisent via semantic tokens)
Variables Figma — Collection "Semantic" + "Component"

Tokens Studio ne fait pas de distinction entre une palette Radix et une palette custom — il lit le JSON et mappe les tokens à des Variables Figma selon la structure du fichier.

Configuration Tokens Studio

Collection Figma cible : Primitives (même collection que primitive.color.teal, primitive.color.blue, etc.)

Nommage automatique dans Figma :

• primitive/color/accent/1 → variable Figma accent/1
• primitive/color/accent/9 → variable Figma accent/9
• primitive/color/secondary/9 → variable Figma secondary/9
• etc.

Les tokens _readme (type other) sont ignorés par Tokens Studio à l'import — ils ne génèrent pas de variables Figma. Ils servent exclusivement à la documentation du JSON pour les agents et développeurs.

Import order (inchangé depuis ADR-011) : 1. primitives.json → Collection Primitives 2. semantic.json → Collection Semantic 3. component.json → Collection Component

Quand les valeurs custom changent

Toute modification des valeurs hex d'une palette custom suit le processus standard :

1. Ouvrir une PR de type token(primitives) sur une branche token/brand-palette-update 2. Modifier les valeurs dans tokens/primitives.json 3. Approbation obligatoire du Principal Designer (règle gouvernance ADR-001, ADR-004) 4. Merge → le pipeline de sync Tokens Studio détecte le changement au prochain pull depuis Figma

Les designers ne modifient pas les valeurs directement dans Figma. Si une teinte ne convient pas, ils ouvrent une issue / soumettent une PR — pas une modification locale de variable Figma.

Documentation des steps dans Figma

Les descriptions des variables Figma (champ description dans Tokens Studio) sont renseignées depuis le champ $description de chaque token JSON. Les designers voient directement dans le panneau Figma :

✅ Modifier les valeurs hex dans tokens/primitives.json via PR
✅ Ajouter un nouveau step intermédiaire (ex: accent/9-5) si justifié
✅ Mettre à jour les $description pour améliorer la documentation Figma
❌ Modifier les variables Figma directement (jamais — direction JSON → Figma)
❌ Créer une nouvelle palette sans ADR et sans approbation Principal Designer