01 · Situation
Des produits issus d’une histoire commune,
avec des interfaces devenues divergentes.
Les produits avaient grandi par générations successives, avec leurs propres contraintes métier, technologies et habitudes de conception.
Cette autonomie locale avait permis d’avancer vite. Mais à l’échelle du portefeuille, elle produisait des composants réimplémentés, des comportements divergents, des styles propres à chaque équipe et une documentation difficile à maintenir.
- Décisions locales
- Les mêmes problèmes recevaient plusieurs réponses.
- Figma ≠ code
- La maquette ne décrivait pas toujours ce qui existait en production.
- Qualité variable
- Accessibilité et états d’interface étaient traités projet par projet.
- Legacy réel
- Une convergence complète ne pouvait pas passer par une refonte globale.
Compact · icône à gauche · rayon 12
Large · rayon 4 · bold
Dense · icône à droite · rayon 8
02 · Direction
Cadrer le Design System
comme un produit interne.
Créer un contrat commun entre
ce que le Design décide, ce que le Code implémente et ce que les produits utilisent réellement.
J’ai cadré le Design System comme un produit interne : une architecture, une documentation, un mode de contribution et une stratégie d’adoption. Le composant n’était plus la finalité, mais le point de rencontre entre des décisions partagées.
Le principe directeur était simple : traiter chaque évolution au bon niveau (fondation, token, composant ou pattern) afin qu’une décision utile à un produit puisse devenir réutilisable par les autres.
03 · Construction
Relier Figma, les tokens,
le code et la documentation.
- 01Foundations
- 02Semantic tokens
- 03Components
- 04Patterns
- Valeurneutral-600
- Intentiontext-muted
- Code
--color-text-muted - UsageTexte secondaire
Fondations
Couleurs, typographie, espacements, rayons et motion deviennent des choix nommés plutôt que des valeurs isolées.
Intentions
Les tokens sémantiques décrivent une fonction stable : action, texte, surface, bordure, feedback.
Composants
Les états, propriétés et comportements sont synchronisés entre bibliothèque Design et implémentation.
Décision structurante
Privilégier une base technique indépendante des frameworks produit, afin que le système puisse circuler entre plusieurs stacks sans créer un nouveau verrou.
04 · Gouvernance
Intégrer le système aux décisions
quotidiennes des équipes.
La gouvernance devait rendre les décisions visibles et faciles à reprendre, sans créer un comité de validation central.
- 01
Faire remonter le besoin
Un produit ou un designer identifie une limite, un nouvel usage ou une divergence.
- 02
Revoir ensemble
Design et Engineering vérifient cohérence, accessibilité et potentiel de réutilisation.
- 03
Arbitrer au bon niveau
La réponse devient un token, une variante, un composant, un pattern ou reste locale si nécessaire.
- 04
Synchroniser
Figma, code, documentation et historique évoluent dans le même mouvement.
- 05
Transmettre
Reviews, exemples et accompagnement permettent aux équipes d’utiliser le cadre sans dépendance.
05 · Adoption
Faire converger progressivement
les produits existants.
- Nouveaux produitsRéférence commune dès le départ
- Nouveaux écransAdoption à chaque évolution utile
- Produits historiquesMigration ciblée selon le risque et la valeur
Une refonte générale aurait ralenti les équipes et fragilisé des interfaces personnalisées. Nous avons donc privilégié les nouveaux développements, puis les opportunités de migration à forte valeur.
Cette stratégie a permis au système de prouver son utilité dans la production réelle. L’adoption a progressé parce que le système améliorait concrètement le travail des équipes, au-delà de la règle organisationnelle.
06 · Impact
Réduire les décisions répétées et
renforcer l’autonomie des équipes.
- 43Web Components
- 438tokens structurés
- 368composants Figma synchronisés
- 11produits concernés
- 14équipes utilisatrices
Une bibliothèque qui décrit ce qui peut réellement être livré.
Des composants partagés, documentés et testés une seule fois.
Des équipes qui concentrent leurs arbitrages sur les usages métier.
Un langage commun pour décider, contribuer et faire évoluer les interfaces.
Ce que je retiens
La réussite d’un Design System dépend de la capacité des équipes à l’utiliser, le faire évoluer et savoir quand s’en écarter.