06 · Projets
Murex
Murex – Design system sur deux technologies
La demande
Chez Murex, des centaines d'applications et des milliers d'écrans cohabitaient sur deux socles techniques, Java Swing et Angular, sans source de vérité commune. Chaque équipe recréait ses composants, et le passage du design au développement se payait à chaque projet.
La solution
J'ai commencé par un audit d'interface et des entretiens avec designers, développeurs et product managers. Puis j'ai construit le design system de zéro, sur quatre ans : atomic design piloté par des design tokens indépendants de la technologie, bibliothèque Figma avec variables et modes, accessibilité WCAG dans les fondations, documentation sur zeroheight, processus de contribution et versioning.
Analyse
J'ai commencé par un audit d'interface à grande échelle : inventaire des composants, relevé des couleurs et des styles de texte en doublon, puis une cartographie de ce que Swing et Angular savent faire, et de ce qu'ils ne font pas de la même manière. J'ai complété avec des entretiens auprès de designers, de développeurs et de product managers.
- ce qui était réellement réutilisé d'un projet à l'autre ;
- ce qui était recréé faute d'être trouvable ;
- les contraintes que chaque technologie impose au design.
Conception
L'architecture est en atomic design, pilotée par des design tokens indépendants de la technologie : on prend une décision une fois et elle se décline aussi bien en Swing qu'en Angular. Dans Figma, ça donne une bibliothèque partagée avec des composants en auto layout, des variants et des component properties, puis des variables avec modes pour le thème et la densité. L'accessibilité WCAG est posée dans les fondations, pas ajoutée après coup.
Le vrai sujet n'était pas de dessiner des composants, mais de faire tenir une même décision dans deux technologies qui ne se ressemblent pas.
Documentation
Plusieurs dizaines de composants et de patterns sont documentés sur zeroheight : anatomie, états, règles d'usage, do and don't, et les specs de passage au développement. C'est devenu la référence commune des designers et des développeurs, l'endroit où une question se règle sans avoir besoin d'une réunion.
Gouvernance et itération
Un design system qu'on ne fait pas vivre redevient vite une bibliothèque morte. J'ai donc mis en place un processus de contribution, le versioning de la bibliothèque et un changelog. Les patterns les plus exigeants, les tableaux de données denses et les formulaires complexes, ont été repris en continu à partir des retours des équipes.