Aller au contenu

BRI-304 — Note de prépa kick-off (14h, lead dev front)

Ticket : BRI-304 — Design system drift detection, synchro Figma ↔ code · assigné à moi · In Progress · labels AI&Automations / Design / Techdays. Objectif du kick-off : verrouiller le périmètre V0 et se répartir l'extraction. Pas concevoir le cron.

En une phrase

Le DS vit dans deux mondes (Figma : variables/composants ; code : thème Tailwind/Uniwind + Storybook). Ils dérivent en silence. On veut détecter ces drifts — en commençant petit : comparaison manuelle des tokens couleur + typo.

Mon actif d'entrée (renforcé le 2026-06-11)

Côté Figma, l'extraction est faite : j'ai sorti via MCP tous les noms + clés des tokens couleur (marque, typo, core, bordures, 5 états complets, shiny, ghosts) et les 13 styles typo (9 Heading + 4 Text). Table remplie côté design → l'incertitude est côté code (son terrain) et côté matching de noms.

🎁 Ce que j'apporte de fort : 6 drifts déjà trouvés DANS Figma

Pendant l'extraction, j'ai repéré des incohérences internes à Uimmo — donc des drifts réels avant même de regarder le code (= critère de succès V0 à moitié atteint) : - D1 casse : brandborder500 (minuscule) vs brandBorder300/400 - D2 Info a des bordures numérotées (infoBorder600/950) alors que les autres états ont un seul xxxBorder - D3 infoBackground950 existe en double (dans le groupe + orphelin hors groupe) - D4 Core/white vit dans 2 collections (Colors + Primitives) - D5 la lib legacy 🖥️ WebApp pollue les recherches → l'extracteur doit filtrer sur la lib Uimmo - D6 tokens disabled multi-rôles (border + background + text)

⚠️ 2 constats techniques d'extraction (pour le cron)

  1. search_design_system renvoie noms + clés + scopes mais PAS les valeurs hex → pour les valeurs, l'extracteur devra passer par get_variable_defs (sur un nœud) ou l'API REST /variables.
  2. La key Figma est l'identifiant stable ; le nom peut dériver. Matching robuste côté Figma = par clé ; mais le pont Figma↔code reste par convention de nommage (le code n'a pas les clés) → d'où l'enjeu d'une convention partagée.

LE point dur (à ne pas rater)

La détection de drift = matcher un token Figma à son équivalent code par nom. Or les noms diffèrent probablement : - Figma : Typography/defaultHeading, Bricks specific/brandText, Spaces/lg - Code : text-heading ? brand ? spacing.lg ?

→ Le vrai livrable V0 n'est pas un script, c'est la table de correspondance nom-Figma ↔ nom-code. Elle révèle mécaniquement les premiers drifts.

Questions pour le lead dev (il a les réponses)

  1. Où vit le thème Tailwind/Uniwind ? Fichier unique ou éclaté ? Nommage régulier ?
  2. La convention de nommage code suit-elle Figma, ou une autre logique (sémantique/échelle) ?
  3. Storybook couvre-t-il déjà les composants du DS ? (lien BRI-132 MCP Storybook)
  4. Le thème est-il parsable proprement depuis un script/cron ?
  5. Routage des issues de drift : comment décider l'owner (designer vs dev) automatiquement ?

Décisions à acter

  • [ ] Périmètre V0 = couleurs + typo, comparaison manuelle (pas de cron)
  • [ ] Répartition : moi = Figma (noms + extraction) · lui = code (noms + extraction) · ensemble = table de matching
  • [ ] Format du livrable = table de correspondance + liste de drifts réels/actionnables
  • [ ] Prochain point daté

Agenda (~45 min)

Temps Sujet
5' Objectif + pourquoi maintenant (drift silencieux, passage à 2 PD)
10' État des lieux croisé : Figma (moi, BRI-299) ↔ code (lui : Tailwind/Uniwind/Storybook)
15' Matching par nommage — confronter les 2 conventions, repérer les écarts
10' Découpage V0 + répartition + format livrable
5' Décisions + prochain point

Piège à éviter

Ne pas se faire embarquer dans la V1/V2 (cron, dashboard, Code Connect auto). Le critère V0 est juste : les drifts identifiés sont réels et actionnables. Cap sur la table de matching.

Liens