Design system

Des centaines d'applications et des milliers d'écrans cohabitaient sur deux socles techniques : un logiciel historique en Java Swing et de nouvelles applications web en Angular. Aucune source de vérité commune n'existait. Chaque équipe recréait ses composants, les deux mondes divergeaient visuellement, et le passage du design au développement se payait à chaque projet.

J'ai mené un audit d'interface à grande échelle : inventaire des composants, relevé des couleurs et des styles de texte en doublon, puis cartographie de ce que Swing et Angular savent faire — et de ce qu'ils ne savent pas faire de la même manière. Des entretiens avec des designers, des développeurs et des product managers ont complété le tableau.

• 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.

L'architecture est en atomic design, pilotée par des design tokens indépendants de la technologie : une décision de design se prend une fois et se décline aussi bien en Swing qu'en Angular. Dans Figma, cela devient une bibliothèque partagée — composants en auto layout, variants et component properties, puis variables et modes pour le thème et la densité. L'accessibilité WCAG est posée dans les fondations, pas ajoutée après coup.

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 la référence commune des designers et des développeurs — le point où une question se règle sans réunion.

Un design system qu'on ne fait pas vivre redevient vite une bibliothèque morte. J'ai mis en place un processus de contribution, le versioning de la bibliothèque et un changelog. Les patterns les plus exigeants — tableaux de données denses, formulaires complexes — ont été repris en continu à partir des retours des équipes.