Passer d'une marketplace à une plateforme de productivité
Comment une restitution terrain a cadré la roadmap et débloqué quatre chantiers produit.
uxstrategyproblematiquesuser research
//context
La direction produit avait tranché le cap : sortir Kazaar du modèle e-shop pour en faire une plateforme de productivité. Le quoi était posé. Le comment ne l'était pas.
Faire basculer une marketplace vers une plateforme, ce n'est pas une liste de fonctionnalités à empiler. C'est un pari sur un secteur opaque, l'impression et la PLV, avec ses chefs de projet, ses fournisseurs, et des clients qui changent tous les six mois. Ajouter des features à l'intuition, c'était prendre le risque de construire vite et à côté du besoin réel.
// Le terrain, pas l'atelier
J'ai mené une étude sur tout l'écosystème qui gravite autour de Kazaar et d'Altavia. Pas un atelier en salle avec les hypothèses de l'équipe, mais des entretiens sur le terrain, auprès de ceux qui vivent les frictions au quotidien : chefs de projet inStore, procurement, GBD, agences, fournisseurs, clients internationaux.
Le protocole était volontairement ouvert. Deux à trois questions larges, un espace pour laisser les gens raconter leur travail réel plutôt que répondre à un questionnaire fermé. L'objectif n'était pas de confirmer une idée produit. C'était de remonter des insights qualifiés, pas des intuitions.
Global experience mapping
L'étude m'a permis de dresser une matrice des personas et de leurs besoins.
// Ce que le terrain a révélé
Quatre frictions coûteuses, structurantes pour le business :
- Un client qui change. Les demandes deviennent plus urgentes, calées sur des attentes de livraison au lendemain, portées par des interlocuteurs qui tournent tous les six mois. L'outillage n'a pas suivi, et l'écart est comblé à l'effort par les chefs de projet.
- Une communication non persistante. Le téléphone reste le canal principal des échanges. L'information ne se stocke nulle part. Un brief complet peut prendre jusqu'à cinq jours d'allers-retours par mail et par téléphone.
Une saisie répétitive. Chaque acteur a son propre ERP, personne ne partage. Résultat : tout le monde ressaisit la même information, sans source de vérité unique. - Une donnée ni structurée ni exploitée. Les besoins de reporting et de conformité RSE existent, mais la donnée dort. On la possède, on ne s'en sert pas.
- Et un persona qu'on ne regardait pas : les fournisseurs. Maillon négligé, alors qu'ils opèrent en flux tendu, sur des ERP très granulaires, avec des APIs, et un taux d'échec de livraison quasi nul. Une opportunité entière, invisible tant qu'on ne l'avait pas cartographiée.
// La restitution comme point de bascule
Le livrable n'est pas un compte rendu d'entretiens. C'est une restitution qui est devenue la mémoire partagée de l'équipe : un document qui aligne tout le monde sur le pourquoi avant de discuter du quoi.
Présentée à la direction, elle a fait une chose précise : elle a transformé un cap stratégique en priorités lisibles. Chaque friction qualifiée sur le terrain est devenue un chantier de la roadmap 2025.
// Quatre frictions, quatre chantiers livrés
- La refonte du parcours de création de commandeC'était le plus gros point de douleur : au-delà de trois éléments, créer une commande devenait impossible et chronophage. La refonte a supprimé totalement les critiques sur ce parcours et réduit de 70 % le temps de création d'une commande complexe, multi-produits.
- Un module d'inboxPour sortir les échanges du téléphone et les rendre persistants, un espace de conversation entre les parties prenantes d'un projet. Résultat : environ cinq heures gagnées sur le délai de réponse dans les échanges clients.
- Le dashboard « My Task »Un suivi temps réel de l'ensemble des commandes, tous business confondus, pensé pour les chefs de projet. Un premier dashboard avait été rejeté par le passé. Celui-ci a trouvé son public et alimente aujourd'hui un flux continu de retours d'expérience qui le font évoluer.
- La restructuration des workspaces clients.Adapter la structure et les équipes des clients au produit, et poser un modèle de droits et de permissions différenciés selon les utilisateurs. C'est le point d'entrée d'un chantier IAM/RBAC que je détaille dans une étude de cas dédiée.
// Les solutions
Tasks viewer
Dashboard structuré des tâches, avec des raccourcis d'actions pour retirer la friction de retrouver l'information.
Workspace management
Les clients peuvent gérer leurs workspaces de façon à structurer leurs besoins.
Rôle et permissions
Les utilisateurs disposent de rôles avec des permissions associées, pour limiter l'accès aux features sensibles.
Refonte du parcours de création de projet
Réduction importante du temps de création de projet grâce à un système matriciel.
