Pipeline Figma

Un pipeline est une chaîne automatisée de transformation et de distribution des design tokens ou d’autres artefacts de design :

• Source : tokens définis dans un format agnostique (souvent JSON).
• Transformation : conversion vers des formats ciblés (Figma Variables, CSS, iOS, Android, etc.).
• Distribution : mise à disposition dans les outils ou dépôts concernés (Figma, Storybook, GitHub, CI/CD, etc.).

Les outils clés

1. Style Dictionary (Amazon)

• Rôle : Moteur de transformation des Design Tokens.
• Fonction :
  • Prend des tokens en JSON/YAML (incluant le format DTS) et génère des fichiers pour React, iOS, Android, CSS, SASS, etc.
  • Très personnalisable : nécessite l’écriture de « formateurs » et « transformateurs » personnalisés pour les cas complexes.
• Cas d’usage :
  • Idéal pour les systèmes mono-repo ou multi-plateformes nécessitant un contrôle granulaire sur le processus de transformation
• Limites :
  • Pas d’interface graphique → pur outil de build, souvent lancé via Node.js ou intégré à un CI/CD.

Site : https://amzn.github.io/style-dictionary/

2. Nouveaux parseurs basés sur la DTS (ex: DTS parsers, d’autres outils de transformation)

Rôle : Simplifier la transformation des tokens grâce à la standardisation.

Fonction :

• Ils exploitent la structure normalisée de la Design Token Specification (DTS) pour effectuer des transformations standardisées et automatiques.

• Ils visent à réduire ou éliminer le besoin d’écrire des « formateurs » très personnalisés pour les cas d’usage courants.

Cas d’usage :

• Systèmes de design cherchant une interopérabilité maximale et une maintenance simplifiée des transformations basiques.

3. Tokens Studio (anciennement Figma Tokens)

• Rôle : Éditeur de tokens + orchestrateur de pipeline (avec connecteurs).
• Fonction :
  • Interface visuelle (plugin Figma ou web) pour créer, organiser, versionner des tokens.
  • Exporte vers :
    • Figma Variables (via plugin)
    • GitHub (via un format JSON structuré)
    • Style Dictionary (en tant que source d’entrée)
    • Storybook, Zeroheight, etc.
• Cas d’usage :
  • Vous voulez unifier la source de vérité design/dev (JSON, souvent compatible DTS) qui est ensuite consommée par Style Dictionary ou les nouveaux parseurs DTS pour la transformation finale en code.
  • Vous travaillez en équipe (design et dev) et avez besoin de collaboration.
• Relation avec Style Dictionary :
  → Tokens Studio peut alimenter Style Dictionary (en écriture JSON) → Style Dictionary transforme pour le code.

Site : https://tokens.studio

4. Storybook

• Rôle : Catalogue de composants UI pour les développeurs.
• Fonction :
  • Affiche les composants React/Vue/etc. avec leurs variantes, props, et exemples.
  • Peut consommer des Design Tokens (via un fichier de thème, ex. theme.ts).
  • Ne génère pas de tokens → seulement les affiche/utilise.
• Cas d’usage :
  • Documentation technique pour devs.
  • Tests visuels, a11y, interactions.
• Pas un outil de pipeline en soi → mais un point de consommation final.

Site : https://storybook.js.org

5. Zeroheight

• Rôle : Documentation de design system pour design & produit (moins technique que Storybook).
• Fonction :
  • Agrège :
    • Composants Figma
    • Règles de conception
    • Tokens (via Tokens Studio ou JSON)
    • Exemples d’usage
  • Affiche les tokens dans une interface humaine (pas de code brut).
• Cas d’usage :
  • Aligner design, produit, marketing.
  • Former les nouveaux arrivants.
• Pas un outil de génération → consomme les tokens (souvent via Tokens Studio).

Site : https://zeroheight.com

6. Zeplin (historique, en perte de vitesse)

• Rôle : Outil de handoff design → dev.
• Fonction :
  • Exporte des spécifications depuis Figma/Sketch.
  • Gère des guides de style et composants.
  • Supporte partiellement les variables Figma ou les tokens via intégrations.
• Comparaison :
  • Moins centré sur les tokens que Tokens Studio ou Zeroheight.
  • Plus orienté mesures, couches, assets que sémantique.
• Statut : remplacé dans les workflows modernes par Figma Dev Mode + Tokens Studio.

Site : https://zeplin.io

Les audiences et leurs besoins

Les audiences et leurs besoins

1. Dev / Build (développement et construction)

C’est l’audience la plus technique, centrée sur la transformation et l’intégration des tokens dans le code source.

• Rôle : Assurer que les valeurs de design (couleurs, espacements, typographies) définies par le Design sont disponibles dans tous les environnements de code (Web, iOS, Android, etc.) sous la bonne forme (variables CSS, constantes Swift, etc.).
• Outils Clés :
  • Style Dictionary : Moteur de transformation pur.
  • Parseurs DTS : Outils de transformation modernes et standardisés.
  • CI/CD (Continuous Integration/Continuous Deployment) : Systèmes qui lancent ces outils de transformation automatiquement (le Build).
• Besoin : Des fichiers de code générés automatiquement, mis à jour sans intervention manuelle du développeur, et faciles à importer dans leurs projets.

2. Dev (développement)

C’est l’audience qui consomme les composants et utilise les tokens dans leur code applicatif.

• Rôle : Utiliser les composants UI et les Design Tokens générés par le Design System pour construire les fonctionnalités du produit.
• Outils Clés :
  • Storybook : Catalogue de référence pour voir les composants et le code.
  • L’IDE (éditeur de code) : Pour écrire le code qui utilise les tokens.
• Besoin : Une documentation technique claire, des exemples d’usage, et des composants facilement réutilisables.

3. Design + Dev (Collaboration unifiée)

Ce terme désigne un point de rencontre où les deux équipes travaillent sur la source de vérité du Design System.

• Rôle : Définir et versionner les tokens sémantiques. Le Designer crée la valeur ($color.brand.primary: #123456), et le Développeur garantit que cette structure est exploitable par le code. Ils partagent la même source.
• Outil Clé :
  • Tokens Studio : Il sert de hub visuel pour le designer (édition) et de source JSON exportable pour le développeur (ingestion par Style Dictionary/Parseurs DTS).
• Besoin : Une interface collaborative et un format d’export unique et standardisé (JSON/DTS).

4. Design, Produit, UX (Consommation de la documentation)

Ces rôles sont centrés sur la stratégie, la vision et l’expérience utilisateur, et non sur le code ou le design graphique pur.

• Rôle :
  • Design (UI/Graphique) : Utilise les tokens pour concevoir les interfaces dans l’outil de design (Figma).
  • UX (Expérience Utilisateur) : Se concentre sur le flux, l’ergonomie et l’accessibilité (Le « comment » l’utilisateur interagit).
  • Produit (Product Manager) : Définit le « quoi » et s’assure que le Design System soutient la stratégie business.
• Outils Clés :
  • Zeroheight : Plateforme de documentation visuelle et humaine (non-code) des tokens et des règles d’usage.
• Besoin : Une documentation claire, non technique, qui explique quand et pourquoi utiliser les tokens et les composants (les règles de conception).

5. Dev (legacy) / Handoff (Ancien Workflow)

Ce terme fait référence aux outils qui étaient le standard pour la « passation » (handoff) du design au développement avant la généralisation des Design Tokens et des variables de design intégrées.

• Rôle : Historiquement, fournir des spécifications statiques de mesures, couleurs, et polices.
• Outil Clé :
  • Zeplin : Il excellait à fournir des mesures précises (largeur, hauteur, espacement en pixels) et des extraits de code CSS basiques.
• Pourquoi « Legacy » ? Le concept de handoff statique est en déclin. Les Design Tokens (via Tokens Studio puis Code) et les fonctionnalités comme Figma Dev Mode fournissent désormais les informations de design et les variables de code directement dans l’outil de conception, rendant les plateformes d’inspection tierces moins essentielles.

En résumé, l’évolution du Design System est passée du Handoff statique (Zeplin) à la Source Unique et Transformable des Design Tokens (Tokens Studio + Style Dictionary), pour une Consommation documentée (Storybook, Zeroheight).

Comparaison des outils clés

Outil	Crée des tokens ?	Transforme des tokens ?	Affiche des tokens ?	Pour qui ?
Tokens Studio	✅	✅ (via plugins)	✅	Design + Dev
Style Dictionary	❌	✅✅✅	❌	Dev / Build
Parseur DTS(Standardisé)	❌	✅	❌	Dev / Build
Storybook	❌	❌	✅ (en contexte code)	Dev
Zeroheight	❌	❌	✅✅ (doc visuelle)	Design, Produit, UX
Zeplin	❌	❌ (limité)	✅ (handoff)	Dev (legacy)

Le rôle de l’architecte d’Information Documentation

L’Architecte d’Information Documentation (ou Information Architect spécialisé en documentation/Design System), joue un rôle crucial dans le pipeline des Design Tokens, car il est le garant de la clarté, de l’organisation et de l’accessibilité de la connaissance pour toutes les audiences.

Il est l’interface entre la source de vérité technique (les JSONs de tokens) et les utilisateurs finaux (Design, Dev, Produit).

Étape du Pipeline	Rôle (Architecte Doc)	Outils Clés
1. Définition de la Source (Tokens)	Il travaille avec l’équipe Design + Dev pour standardiser la nomenclature des tokens. Il s’assure que le nommage est sémantique, cohérent et facile à comprendre pour tous. (Ex: Éviter color-blue-300 au profit de color-action-primary-hover).	Tokens Studio (Pour auditer la structure et les alias)
2. Organisation et Structuration	Il définit l’architecture de l’information du Design System. Comment les tokens sont-ils regroupés ? (Couleurs, typographie, espacement, puis thèmes ?). Il crée la table des matières du système.	Outils de documentation (Zeroheight, Notion)
3. Documentation Visuelle (Design/Produit)	Il organise et rédige les règles d’utilisation pour les audiences Produit et Design. Il explique quand utiliser un token et non comment le coder. (Ex: « Utilisez $color.feedback.error pour toute action nécessitant une correction immédiate. »).	Zeroheight (plateforme principale)
4. Documentation Technique (Dev)	Il organise l’information pour les Développeurs. Il s’assure que les extraits de code générés (par Style Dictionary ou autre) sont facilement trouvables à côté des exemples de composants. Il structure la documentation Storybook.	Storybook (Pour l’organisation des histoires/docs)
5. Gouvernance et Maintenance	Il surveille la complétude de la documentation. Si un nouveau token ou composant est ajouté au pipeline, il est responsable de s’assurer qu’il est documenté avant d’être publié.	Processus CI/CD, Audits réguliers

• Le PO gère le “quoi” (priorités)
• Le dev gère le “comment” (implémentation)
• Le designer gère le “comment ça se voit” (UI/motion)
• L’Architecte d’Information Documentation gère le langage commun, la structure, la cohérence, la doc, la gouvernance, le système de design vu comme un système documentaire vivant.