Victor Michel a relancé un dashboard B2B self-service que les clients de MSC boudaient : observation terrain, co-conception avec des clients pilotes, déploiement progressif.
Logistique maritime · B2B
800
navires (1re compagnie maritime mondiale)
B2B
dashboard self-service pour les clients
Lead UX · Observation terrain · Stratégie produit
Le contexte.
MSC est la première compagnie maritime au monde, avec une flotte d’environ 800 navires. Ses clients professionnels, importateurs, exportateurs et transitaires, organisaient encore une grande partie de leurs expéditions par téléphone et par e-mail, avec la charge que cela représente pour les équipes des deux côtés.
Pour changer cela, MSC avait lancé une première application en self-service. Des mois après sa sortie, elle restait très peu utilisée, sans que personne sache vraiment pourquoi. Les clients continuaient d’appeler et d’écrire comme avant.
Victor Michel, aujourd’hui fondateur de Brutux Studio, a mené la conception UX de la relance. Plutôt que de redessiner l’interface d’emblée, il a proposé une démarche que l’équipe produit n’avait pas envisagée : aller voir les clients travailler avant de toucher au moindre écran, puis construire la solution avec eux plutôt que la livrer clé en main.
Le défi : Quand un dashboard B2B ne trouve pas son public, le premier réflexe est de revoir l’interface. Or une application peut être correctement dessinée et passer à côté de la réalité du travail. Le défi était double : comprendre ce que les équipes logistiques faisaient vraiment au quotidien, puis convaincre que l’observation était le chemin le plus court vers l’adoption.
La démarche.
01
Observer les équipes logistiques
Victor a organisé et conduit lui-même une observation terrain sur plusieurs jours, chez différents clients. Il a suivi leurs flux de travail réels, les outils utilisés au quotidien et les contournements inventés pour compenser ce qui manquait. Ces contournements en disaient plus sur les besoins que n’importe quel cahier des charges.
02
Isoler les usages critiques
L’analyse de ces observations a fait émerger quelques usages prioritaires : suivre les conteneurs, retrouver les documents, être prévenu d’un retard avec une action concrète à la clé. Le reste pouvait attendre. Concentrer le produit sur l’essentiel était la condition de son adoption.
03
Co-concevoir avec des clients pilotes
Les enseignements ont été partagés lors d’ateliers de priorisation réunissant l’équipe produit et des clients pilotes. Maquettes participatives et arbitrages sur les fonctionnalités : la solution s’est construite avec ses futurs utilisateurs, qui sont devenus ses premiers défenseurs.
04
Tester en conditions réelles
Un prototype haute fidélité a ensuite été testé sur place, en situation de travail. Le zoning puis les wireframes du tableau de bord se sont appuyés sur ce que le terrain avait montré, écran par écran, et les tests ont révélé quelles informations devaient être lisibles d’un coup d’œil. Tester là où le travail se fait, avec le bruit, les interruptions et les écrans partagés, montre ce qu’aucune salle de réunion ne laisse voir.
05
Déployer par étapes
Le déploiement s’est fait progressivement, d’abord auprès d’un premier groupe de clients, avec des itérations chaque semaine au début. Ce rythme a permis de corriger vite, d’observer l’effet de chaque changement et d’élargir l’accès une fois le produit stabilisé.
Les écrans.
MSC : zoning du tableau de bord, organisation des blocs d’information
MSC : wireframe du tableau de bord self-service
Ce que ce projet a appris
Le meilleur redesign consiste parfois à ne presque rien redessiner. L’application existante n’était pas mauvaise : elle avait été conçue sans regarder les gens travailler. Quelques jours d’observation ont apporté plus d’enseignements exploitables que des mois de tickets au support. Depuis, Victor défend la même règle auprès de chaque équipe produit : avant d’ajouter des fonctionnalités, comprendre le processus réel.
Ce que ça change pour votre projet
Un SaaS B2B ou un logiciel métier qui peine à être adopté souffre souvent du même mal. Avant de proposer une refonte, Brutux Studio commence par un audit UX qui inclut, quand c’est possible, de l’observation terrain et des entretiens avec les utilisateurs réels. L’objectif : identifier les quelques usages qui comptent vraiment, les concevoir avec les équipes concernées, puis déployer par étapes plutôt que d’un seul bloc.