01 — Situation
Une histoire commune.
Des interfaces qui ne l’étaient plus.
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.
02 — Direction
Ne pas dessiner
un kit de plus.
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 les outils.
Stabiliser les décisions.
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
Faire vivre le système
dans les décisions quotidiennes.
La gouvernance ne devait pas devenir un comité de validation central. Elle devait rendre les décisions plus visibles, plus rapides et plus faciles à reprendre.
- 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
Converger progressivement.
Sans nier le legacy.
- 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 est devenue la conséquence d’un meilleur outil de travail, pas seulement d’une règle organisationnelle.
06 — Impact
Moins de décisions répétées.
Plus d’autonomie collective.
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
Un Design System ne réussit pas parce qu’il couvre tout. Il réussit quand les équipes savent pourquoi l’utiliser, comment le faire évoluer et dans quels cas elles peuvent s’en écarter.