De la capture d’écran au système de style : un playbook design tokens sur 5 jours que les clients adoptent vraiment | Blanche

La plupart des projets de design tokens ne s’enlisent pas parce que les équipes ne comprennent pas les tokens. Ils s’enlisent parce que le travail démarre trop grand.

Un scénario typique en agence ressemble à ça :

L’UI est un patchwork de décisions “on ship et on verra” à travers les pages marketing, l’interface produit et les campagnes.
Plusieurs designers interprètent la même marque différemment.
Le frontend mélange des utilitaires Tailwind, du CSS ad-hoc et une librairie de composants à moitié terminée.
Le client veut “un design system”, mais ce dont il a vraiment besoin, c’est de cohérence qu’il peut maintenir.

La solution n’est pas une initiative design system de 12 semaines. C’est un set minimal de tokens livrable qui peut être adopté en quelques jours, pas en trimestres — et un workflow qui rend le gonflement difficile et les progrès évidents.

Callout: L’objectif des tokens n’est pas une taxonomie parfaite. C’est de réduire la prise de décision et les incohérences tout en augmentant la vitesse de livraison.

Pourquoi la plupart des projets de design tokens s’enlisent (et comment l’éviter)

1) Ils démarrent avec une page blanche

Si vous commencez le travail des tokens en inventant une architecture de tokens immaculée, vous êtes déjà en retard. Les vrais clients n’ont pas des UIs immaculées — ils ont des captures d’écran, du CSS legacy, et “ce style de bouton de la campagne de l’an dernier”.

À retenir : Commencez par extraire ce qui existe, puis resserrez.

2) Ils confondent tokens “primitifs” et tokens “sémantiques”

Les équipes sautent souvent directement sur des tokens sémantiques comme button.primary.background, alors qu’elles n’ont pas stabilisé la palette, l’échelle typographique ou les règles d’espacement.

À retenir : Verrouillez d’abord les primitifs, puis mappez la sémantique.

3) Ils créent des tokens pour tout

Le gonflement des tokens arrive quand vous tokenisez chaque cas limite :

color-blue-487
padding-card-compact-v2
shadow-modal-legacy

Ça donne une impression de rigueur, mais c’est ingérable.

À retenir : Tokenisez les décisions, pas les artefacts.

4) Il n’y a pas de gouvernance

Sans owner, les tokens deviennent une décharge. Sans versioning, chaque changement devient une alerte incendie.

À retenir : La gouvernance n’est pas de la bureaucratie — c’est ce qui rend l’adoption sûre.

Le workflow d’extraction sur 5 jours : de l’audit → primitifs → composants

C’est conçu pour les agences : rapide, adoptable, et résilient aux handoffs.

Day 1: Auditer l’UI comme un détective (pas comme un perfectionniste)

Inputs :

15–30 écrans clés (ou templates de pages) à travers produit + marketing
CSS existant (si disponible)
Fichiers Figma (s’ils existent)

Ce que vous cherchez : la répétition et la dérive.

Faites un “inventaire de captures d’écran”

Créez un board (FigJam, Miro, ou même Figma) avec des captures d’écran groupées par zone d’UI :

Boutons
Formulaires
Navigation
Cartes
Alertes/toasts
Blocs typographiques
Affichage de données (tables, badges)

Puis annotez ce qui est incohérent :

Combien de bleus sont utilisés pour les liens ?
Combien de rayons d’angle existent ?
Combien d’ombres apparaissent ?

Tooling utile :

Figma : inspection des couleurs/typos de la sélection
Chrome DevTools Coverage + recherche CSS
Stylelint ou stats PostCSS (si vous avez une codebase)

Livrable en fin de Day 1 :

Une liste de primitifs candidats (couleurs, typo, spacing, rayons, ombres)
Une liste des 10 composants les plus “douleur” (souvent boutons, inputs, cartes)

Rule: Vous n’auditez pas tout. Vous auditez ce qui génère 80% de la production UI.

Day 2: Extraire les primitifs dans un set minimal de tokens “v0”

Les primitifs sont vos matières premières. Gardez-les simples et stables.

Commencez par le plus petit set qui peut être livré

Un v0 pratique inclut généralement :

Couleur : échelle de neutres + 1–2 échelles de marque + couleurs sémantiques de statut
Typographie : familles de polices, tailles de base, interlignages, graisses
Espacement : une échelle par pas (ex. 4, 8, 12, 16…)
Rayons : 2–3 options max
Ombres : 2–4 niveaux max
Bordures : 1–2 épaisseurs

Exemple (primitifs) :

color.neutral.0…900
color.brand.50…900
space.1…12
radius.sm | radius.md | radius.lg
shadow.1…4

Évitez le piège couleur le plus courant

Les clients ont souvent un “bleu de marque” plus 14 bleus légèrement différents. Ne les encodez pas tous.

À la place :

Choisissez une échelle de marque (50–900) capable de gérer les états hover/active.
Mappez les bleus legacy vers les valeurs d’échelle les plus proches.
Créez un bucket “legacy” temporaire uniquement si nécessaire, et prévoyez de le supprimer.

Callout: Si vous ne pouvez pas supprimer un token plus tard, ce n’est pas un token — c’est une couche de compatibilité permanente.

Livrable en fin de Day 2 :

Un fichier de tokens primitifs (JSON) + un draft de collection de variables Figma

Day 3: Créer des tokens sémantiques qui reflètent l’intention produit

Les tokens sémantiques sont ceux que designers et développeurs devraient utiliser au quotidien. Ils encodent le sens :

color.text.default
color.surface.canvas
color.border.muted
color.action.primary
color.action.primaryHover

Une convention de nommage qui survit aux handoffs

Un pattern robuste est :

Catégorie (color, space, radius, type)
Rôle (text, surface, border, action)
Intention (default, muted, primary, danger)
État (hover, active, disabled, focus)

Exemples :

color.text.default
color.text.muted
color.surface.default
color.surface.raised
color.action.primary.default
color.action.primary.hover
color.action.primary.disabled

Comment éviter le gonflement des tokens

Utilisez ces contraintes :

Chaque token sémantique doit mapper vers un primitif. Pas de valeurs hex brutes.
Chaque token doit avoir au moins deux consommateurs. Si un seul composant l’utilise, c’est probablement un token de composant.
Préférez la composition à la prolifération. Par exemple, utilisez color.border.default largement plutôt que de créer color.border.card, color.border.table, color.border.modal.

Livrable en fin de Day 3 :

Couche de tokens sémantiques définie et mappée vers les primitifs
Un court doc “règles d’usage des tokens” (1 page)

Day 4: Connecter les tokens aux composants (Figma + code) avec une fine couche d’adoption

C’est là que les projets de tokens deviennent réels.

Pattern 1: Les variables CSS comme source de vérité en production

Une approche pragmatique :

Stocker les tokens en JSON (pour la portabilité)
Générer des variables CSS (pour le theming runtime)
Optionnellement générer des types TypeScript (pour la sécurité)

Des outils que les équipes utilisent vraiment :

Style Dictionary (classique, flexible)
Tokens Studio (excellent pour les workflows Figma ↔ tokens)
Panda CSS / Vanilla Extract (styling typé)
Tailwind (peut consommer des variables CSS et les mapper vers des utilities)

Exemple de sortie (conceptuel) :

--color-text-default
--color-surface-default
--radius-md
--space-4

Ensuite, les composants référencent des variables plutôt que des valeurs hard-codées.

Pattern 2: Theming avec fallbacks

Si vous avez besoin de light/dark ou multi-brand :

Définissez des tokens sémantiques par thème
Gardez les primitifs stables
Utilisez des fallbacks pour éviter de casser des pages

Une règle sûre :

Les primitifs changent rarement
Les tokens sémantiques peuvent changer selon le thème
Les tokens de composant changent le plus (et doivent être traités avec prudence)

Pattern 3: Alignement avec la librairie de composants

Si vous avez une librairie de composants (React, Vue, Web Components), implémentez les tokens au niveau le plus bas :

Le Button de base utilise color.action.primary.*
Input utilise color.border.default, color.text.default, color.surface.default

À retenir : Si les composants ne consomment pas les tokens, les tokens ne sont que de la documentation.

Livrable en fin de Day 4 :

Tokens qui alimentent des variables CSS
3–5 composants cœur refactorés pour utiliser les tokens de bout en bout

Day 5: Gouvernance, versioning et documentation “client-proof”

C’est la partie que les agences sautent — et celle qui détermine si les clients continuent réellement d’utiliser le système.

Handoff + gouvernance : versioning, docs et ownership

Décider qui approuve les changements de tokens

Un RACI simple fonctionne bien :

Owner (Accountable) : Design System Lead (agence ou client)
Approvers (Responsible) : 1 représentant design + 1 représentant frontend
Contributors : tout designer/dev via PR
Informed : parties prenantes produit/marketing

Callout: Si tout le monde peut ajouter des tokens, le nombre de tokens ne fait qu’augmenter.

Versionner les tokens comme un produit

Traitez les tokens comme un package :

Utilisez SemVer (major/minor/patch)
Publiez un changelog
Exigez un template de PR : “ce qui a changé, pourquoi, captures d’écran, notes de migration”

Règles empiriques :

Patch : corriger une typo, ajuster la documentation, aucun changement visuel
Minor : ajouter des tokens, non cassant
Major : changer/supprimer des tokens, changements visuels probables

Documenter les décisions, pas seulement les valeurs

Les clients n’ont pas besoin d’un site design system de 40 pages pour démarrer. Ils ont besoin de :

Inventaire des tokens (table)
Guidelines d’usage (quand utiliser quoi)
Journal de décisions (pourquoi vous avez choisi une échelle, ce que vous avez déprécié)
Notes de migration (quoi mettre à jour dans le code)

Où l’héberger :

Zéro friction : README dans le repo des tokens
Mieux : Storybook + docs MDX
Enterprise : Backstage, Confluence (mais gardez la source proche du code)

Livrable en fin de Day 5 :

Doc de gouvernance (1–2 pages)
Package/repo de tokens versionné avec changelog
Workflow “comment demander un changement de token”

Patterns d’implémentation qui rendent les tokens rapides à adopter (et difficiles à casser)

Pattern A: Le “modèle de tokens à deux couches” (primitifs + sémantique)

C’est le sweet spot pour la plupart des clients d’agence.

Les primitifs stabilisent le langage visuel
La sémantique stabilise l’usage entre équipes

Vous pourrez ajouter des tokens de composant plus tard si la librairie mûrit.

Pattern B: Dépréciation plutôt que suppression

Quand vous devez changer un token :

Marquez les anciens tokens comme dépréciés
Gardez-les pendant un cycle de version minor
Fournissez un codemod ou des consignes de search/replace
Supprimez-les dans la prochaine version major

À retenir : La dépréciation est la façon de conserver la confiance tout en améliorant le système.

Pattern C: “Tokens de compatibilité” pour l’UI legacy

Si le client a des pages legacy qui ne peuvent pas être refactorées immédiatement, créez une petite couche de compatibilité :

legacy.color.link → mappe vers color.action.primary.default

Puis migrez progressivement les consommateurs vers les nouveaux tokens sémantiques.

À retenir : Les tokens de compatibilité sont un pont, pas une destination.

Métriques avant/après (ce qui compte vraiment pour les clients)

Les tokens n’ont de valeur que si vous pouvez prouver l’impact. Suivez :

Vitesse de livraison

Temps pour construire une nouvelle section de landing page
Temps pour implémenter une nouvelle variante de composant

Cohérence

Nombre de valeurs hex uniques dans le CSS en production (doit baisser)
Nombre de tailles de police/interlignages uniques (doit baisser)

Maintenabilité

Nombre d’overrides “one-off” par page/template
Fréquence des problèmes de design QA liés au spacing/couleur/typo

Préparation au rebrand

Temps pour mettre à jour la couleur de marque et propager sur les surfaces
Nombre de fichiers/composants touchés pour une mise à jour de marque

Un gain réaliste après adoption d’un set minimal de tokens :

Moins de régressions UI parce que les composants référencent des tokens sémantiques stables
Itération plus rapide parce que les designers arrêtent de débattre de “quel gris”
Les rebrands deviennent des changements contrôlés de variables, pas une chasse au trésor

Callout: Le ROI, ce ne sont pas les tokens. Le ROI, c’est moins de décisions et moins d’incohérences.

Un template de pitch client que vous pouvez réutiliser

Utilisez cette structure lors de votre prochain kickoff ou QBR.

1) Le problème (dans leur langage)

“En ce moment, les nouvelles pages et fonctionnalités sortent avec de petites différences visuelles qui s’additionnent — des gris différents, des espacements incohérents, des styles de boutons légèrement différents. Ça ralentit la livraison et rend les rebrands coûteux.”

2) La proposition (petite, rapide, sûre)

“En 5 jours, nous allons extraire un set minimal de tokens depuis votre UI existante et le connecter à Figma et à votre codebase via des variables CSS. Ce n’est pas une refonte — c’est une couche de cohérence.”

3) Les livrables

Set de tokens (primitifs + sémantique)
Variables Figma alignées avec le code
Implémentation en variables CSS
3–5 composants cœur refactorés
Workflow de gouvernance + versioning

4) Les métriques de succès

Réduire les couleurs uniques de X%
Réduire les tailles de typo uniques de Y%
Réduire le time-to-build pour de nouvelles sections de Z%
Réduire les incohérences QA par release

5) La prochaine étape

“Après l’adoption du v0, nous étendrons la couverture composant par composant, en priorisant les surfaces que vous livrez le plus.”

Conclusion : livrez le plus petit système de tokens qu’on ne peut pas ignorer

Un système de tokens que les clients utilisent vraiment n’est pas le plus complet. C’est celui qui :

Part de la réalité (captures d’écran, UI legacy, CSS en désordre)
Se livre vite (une semaine, pas un trimestre)
A des noms qui survivent aux handoffs
Fonctionne à travers Figma, variables CSS et composants
Inclut une gouvernance pour éviter qu’il ne se dégrade

Si vous dirigez une équipe en agence, l’avantage compétitif n’est pas “on fait des design tokens”. C’est on peut rendre votre UI cohérente sans vous ralentir.

Vous voulez un plan tokens fast-start pour votre client ?

Si vous partagez (1) 10–15 captures d’écran et (2) un lien vers le repo ou le CSS compilé, nous pouvons proposer un set de tokens v0, un schéma de nommage et un plan de livraison sur 5 jours adapté à votre stack (Webflow, React, Next.js, Tailwind, Storybook, etc.).