Un UI Kit pour stabiliser et faire évoluer le portail d'administration MaaS de Worldline MeTS.
Le portail admin MaaS est une interface web centralisée permettant aux agents de gérer les comptes mobilité, les souscriptions, les consommations et les pièces justificatives des usagers. Développé à partir d'un template sans maquettes ni documentation, le produit évoluait difficilement : chaque nouvelle fonctionnalité était conçue sans référence commune, rendant les développements incohérents et les démonstrations clients hasardeuses.
Challenge
Sans base de maquettes, l'équipe ne disposait d'aucun référentiel visuel pour faire évoluer le produit de manière cohérente. L'enjeu n'était pas de refondre l'interface existante, mais de la capturer fidèlement dans Figma et d'en extraire une bibliothèque de composants réutilisables, tout en identifiant au passage des axes d'amélioration UX/UI à proposer sans les imposer.
Approche
La mission a démarré par un inventaire complet du portail existant, écran par écran, pour identifier tous les composants et états à standardiser. J'ai également retrouvé le template d'origine utilisé pour construire le portail, ce qui m'a permis d'être au plus près du produit réel et de réutiliser directement certaines règles de style et les icônes.
J'ai ensuite construit la bibliothèque dans Figma selon une approche atomique : tokens de couleurs et de typographie en fondation, composants atomiques avec leurs variantes et états. Chaque page de composant intègre des exemples d'utilisation concrets pour donner du contexte, sans avoir à aller chercher un écran complet. Les Final Screens viennent compléter ce niveau : des écrans entiers construits uniquement avec les composants de la bibliothèque, pour valider la cohérence du système en situation réelle.
Le Figma a été organisé dès le départ pour être maintenu par les équipes, sans dépendre de ma présence.
Décisions clés
Inventaire avant conception
La tentation aurait été de partir sur un redesign, mais ce n'est pas ce qui m'était demandé. J'ai donc documenté l'existant dans sa totalité avant de toucher à quoi que ce soit : chaque écran, chaque état, chaque variante de composant répertoriée. Ce travail préalable a rendu la bibliothèque crédible pour les équipes, parce qu'elle reflétait exactement ce qu'elles utilisaient au quotidien.
Un kit ancré dans la réalité du produit, adoptable immédiatement sans période de transition.
Tokens en fondation
Lors de la création de mes composants, je déterminais les tokens : couleurs, typographies, propriétés, etc. Ce niveau d'abstraction permet de modifier une valeur à un seul endroit et de voir le changement se propager à l'ensemble du système. Sans tokens, chaque modification devient une opération manuelle à risque.
Un système qui évolue sans se désynchroniser, quelle que soit l'équipe qui y touche.
Final Screens
Un composant isolé ne dit pas grand chose sur la façon dont il s'intègre dans une interface réelle. J'ai donc ajouté des exemples d'utilisation directement dans chaque page de composant. Les écrans finaux sont venus ensuite, à la demande des équipes : on a d'abord reproduit les écrans existants pour valider que la bibliothèque couvrait tous les cas réels, puis créé de nouveaux écrans pour les nouvelles fonctionnalités. Ils servent de référence pour les développeurs et de support pour les démonstrations clients.
Le kit devient un outil de communication autant qu'un outil de production.
Ateliers de formation
Livrer un kit sans accompagnement, c'est prendre le risque qu'il ne soit pas utilisé. J'ai rédigé un guide de prise en main et animé des ateliers avec les équipes opérationnelles. L'enjeu était particulier : je quittais l'entreprise, et personne ne serait là pour répondre aux questions ensuite. Le kit devait pouvoir vivre sans moi.
Un kit vivant, maintenu par les équipes qui l'utilisent au quotidien.
