Refondre l'interface d'un outil métier complexe
Axeo System compte 20 000 utilisateurs et plus de 1 000 projets gérés en Europe. Une migration technique a ouvert une fenêtre rare : plutôt que de simplement porter l'existant, l'équipe a choisi de refaire l'application, flow par flow, en s'appuyant sur le design system tout juste posé.
Problème
Chaque écran portait ses propres incohérences : composants réinventés localement, actions peu lisibles, informations importantes masquées derrière des interactions non évidentes comme le survol.
Pour des utilisateurs qui passent leurs journées dans l'outil, ces frictions n'étaient pas anecdotiques : elles ralentissaient les tâches les plus courantes et rendaient chaque nouvel utilisateur dépendant d'un onboarding informel, porté par les collègues plutôt que par l'interface elle-même.
Mon rôle
En binôme avec une autre designer, j'ai pris en charge la refonte de plusieurs flows critiques de l'application. Cette étude de cas revient sur trois d'entre eux : les espaces de travail, la GED, et le parcours de workflow de sa création à son suivi.
Méthode
Le design system a changé la manière d'aborder chaque écran : plutôt que de redessiner un bouton ou une card, on partait directement des composants et des tokens déjà posés et documentés dans Storybook pour se concentrer sur la structure et le parcours plutôt que sur le détail visuel. Pour chaque flow, on repartait des irritants identifiés sur l'existant, puis on reconstruisait l'écran avec ces briques communes.
En parallèle nous avons mis en place un carnet de test par écran refondu : une checklist listant les états à vérifier (chargement, vide, erreur) et les comportements attendus afin de sécuriser le passage à la production sans dépendre d'un aller-retour permanent avec les développeurs.
La refonte
Résultat
Les flows redessinés ont bénéficié des mêmes fondations : composants cohérents, comportements déjà documentés, moins d'allers-retours avec les développeurs pour les implémenter. Les carnets de test ont fait le reste : chaque écran passait en production avec ses cas limites déjà vérifiés, sans surprise à l'intégration.
Ce projet m'a aussi appris à sortir du cadre designer = Figma :
- Défendre des décisions au-delà de l'esthétique, en comprenant les contraintes techniques et en arbitrant entre dette design et pragmatisme.
- Aligner des interlocuteurs qui ne parlaient pas le même langage (dev, PO, utilisateurs finaux).
- Prendre en charge des responsabilités PO en fin de projet et contribuer directement en front-end.