// overview
// année
2k22–2k26
// entreprise
Kazaar, Starton
// rôle
Lead Product Designer
// migration
18 mois itératif
Design System
Design Tokens
Figma
Token Studio
Atomic Design
Dev Handoff
Governance
// vision
Il n'y a pas d'équipe design et d'équipe dev. Il y a une équipe Design System — et des collaborateurs qui la consomment.
Un design system n'est pas une bibliothèque de composants. C'est un langage commun : un ensemble de décisions de design documentées, automatisées, et accessibles à toute l'organisation. Designers et développeurs y trouvent les composants, les bonnes pratiques, les règles d'accessibilité, la taxonomie UX — une seule source, pour tous.
// contenu
Composants · Best practices · Design decisions · How-to · Accessibilité · UX wording
// utilisateurs
Designers, développeurs, contributeurs externes
// objectif
Passer d'une librairie consommée à un système qui governe
// diagnostic
Avant de concevoir, il faut nommer précisément l'état initial. Le problème n'est jamais l'absence de composants — c'est l'absence de cohérence, de gouvernance et de pipeline. Ce tableau est le point de départ systématique de chaque projet de design system.
// avant
// après
0 theme
4 themes
2 librairies
1 design system
Pas de gouvernance
1 pipeline automatisé
62+ composants
46 composants rationalisés
6 jours de rebranding
1h de rebranding
Documentation fragmentée
1 source de vérité
// méthode
Trois piliers non négociables. Un design system sans les trois devient rapidement une dette de plus.
// pilier_01
Une source de vérité — une valeur, un endroit, pour designers et développeurs
// pilier_02
Un pipeline d'automatisation — de la décision de design au code sans friction
// pilier_03
Une gouvernance évolutive — protocole de contribution, review, deprecation
01
Audit & diagnostic
Recensement de toutes les valeurs hardcodées, des composants redondants, et des zones de friction entre design et développement. Le diagnostic chiffré permet d'objectiver le besoin et d'aligner les parties prenantes.
02
Architecture des tokens
Structuration des fondations en trois couches : valeurs primitives (couleurs brutes, tailles), variables sémantiques (couleur-surface, espacement-md), tokens de composants (button-padding, input-border). Tout en REM sur base grille 8pt.
03
Construction de la librairie Figma
Création des composants en atomic design — atoms, molecules, organisms. Chaque composant est connecté aux tokens via Token Studio, avec variants, états interactifs et propriétés documentées directement dans Figma.
04
Pipeline technique
Connexion Figma → Token Studio → repo Git via push automatique. Les tokens sont exportés en JSON, transformés par Style Dictionary, et injectés dans la configuration CSS/Tailwind/React Native du projet.
05
Gouvernance & documentation
Mise en place d'un protocole de contribution : decision tree pour créer ou modifier un composant, changelog, review design + dev avant merge. Documentation hébergée dans Supernova, liée aux tokens Figma en temps réel.
// pipeline
flow: Designer → Figma → Token Studio → push → repo → Style Dictionary → code
→ Le designer est acteur du pipeline, pas intermédiaire
→ Un changement de token dans Figma se propage jusqu'au code
→ Aucune valeur hardcodée — tout référencé par nom sémantique
01
Pipeline flow
De la décision de design au code — Figma → Token Studio → push → repo → Style Dictionary → production.
// token_pipeline
02
Tokens structure
Architecture en couches — primitives, variables sémantiques, tokens de composants. Base grille 8pt en REM.
// tokens.json
03
Documentation
Composants documentés avec usage, variants et états — directement liés aux tokens Figma via Supernova.
// component_docs
04
Documentation
Guidelines d'usage et best practices — accessibles à toute l'équipe design et développement.
// guidelines
// gouvernance
La maintenance est un enjeu clé. Un design system sans protocole d'évolution devient rapidement une dette. La refonte doit s'accompagner d'un processus qui permet au système de scaler sereinement — tout en préservant la relation designer-développeur.
Governance flow
Decision tree pour créer ou modifier un composant — de la question initiale à l'intégration dans la CORE LIB.
// governance_flow
// impact
1h
de rebranding complet — contre 6 jours avant
4
thèmes supportés par un seul design system
1
pipeline design-to-dev — contre 0 avant