Préserver les repères existants
L'objectif n'était pas de réinventer LeKiosque, mais de rendre l'expérience plus cohérente avec les habitudes déjà installées.
Plutôt que — réinventer le produit.
Étude de cas — SaaS B2B
LeKiosque
Réengager les utilisateurs sans bouleverser leurs habitudes
Refonte du parcours d'un SaaS de gestion de casiers connectés, après l'échec d'une première refonte.
v0 : version historique → v1 : refonte qui a échoué → v2 : version que j'ai conçue
Résumé
- Problème
- La refonte v1 avait fait perdre leurs repères aux utilisateurs : fonctionnalités disparues, parcours complexifié, version mobile inutilisable. Une minorité de comptes l'utilisait, la version historique (v0) restant en ligne.
- Objectif
- Réengager les utilisateurs sans bouleverser leurs habitudes de terrain.
- Résultat
- L'usage de la v2 s'est installé dans les mois qui ont suivi, sans coupure de la v0 (les utilisateurs ont migré par choix). Les demandes au support ont fortement diminué et portent essentiellement sur des détails. Cette évolution ne peut pas être attribuée aux seules modifications de l'interface.
- 60 %des comptes connectés à la v2, contre 30 % sur la v1
- 5-6tickets SAV après la v2, contre 20 sur trois mois
- 3familles d'irritants identifiées sur 20 tickets
01 — Le problème
Une refonte avait créé un problème d'adoption
LeKiosque est un SaaS de gestion de casiers connectés développé par Le Casier Français. Sa version historique (v0), conçue par un développeur senior, était très technique mais peu évolutive et peu responsive. Une refonte (v1) a été menée avant mon arrivée : plusieurs fonctionnalités avaient disparu, le parcours s'était complexifié et la version mobile était inutilisable. La direction a maintenu la v0 en ligne pour rassurer des utilisateurs parfois peu à l'aise avec le numérique, notamment des agriculteurs.
J'ai été missionnée, en alternance, pour revoir le parcours du SaaS. Mon rôle a été de comprendre ce qui freinait l'adoption de la v1 et de prioriser les évolutions capables d'améliorer l'expérience sans bouleverser les habitudes existantes.
Après le déploiement de la v1
30%
des comptes connectés à la nouvelle version
20
Tickets SAV en 3 mois
3
Familles d'irritants identifiées
Adoption suivie grâce aux logs de connexion, en comparant les comptes connectés à la v1 et à la v0, restée accessible pendant la transition. Sources qualitatives : entretiens avec des utilisateurs terrain, tickets SAV, retours des équipes SAV et commerciales.
02 — Comprendre
Comprendre avant de reconstruire
Le contexte imposait d'agir vite : une version historique était déjà installée, les moyens étaient limités et il fallait livrer les maquettes rapidement. J'ai croisé plusieurs sources : des entretiens avec des utilisateurs terrain, menés tout au long du projet, les retours des équipes SAV et commerciales, l'analyse des tickets de support, les logs de connexion et les échanges avec les développeurs.
Les entretiens et les retours des équipes ont éclairé les usages. Les tickets et les logs ont permis d'objectiver la fréquence des problèmes et de suivre l'adoption. L'analyse de 20 tickets a fait ressortir trois familles d'irritants :
01
14/20
Perte de repères
Des informations visuelles et des données utiles au quotidien, présentes dans l'ancienne version, avaient disparu ou étaient devenues moins accessibles.
02
4/20
Informations difficiles d'accès
Certaines informations et actions existaient toujours, mais demandaient plus d'effort pour être trouvées.
03
2/20
Problèmes fonctionnels
Bugs ou limites techniques plutôt que questions d'interface.
Répartition des remontées analysées (20 tickets SAV).
Ce que les retours montraient
Les utilisateurs n'avaient pas rejeté la nouveauté : ils avaient perdu leurs repères et n'avaient plus rien à quoi se raccrocher.
Le problème ne venait donc pas uniquement de la nouvelle interface, mais de la rupture qu'elle introduisait dans des usages déjà installés.
03 — Les décisions
Les choix qui ont guidé la refonte
Simplifier sans déplacer les usages
Les évolutions devaient améliorer les parcours sans imposer une nouvelle logique de navigation aux utilisateurs existants.
Plutôt que — imposer une nouvelle logique de navigation.
Privilégier la rapidité d'accès
Pour des utilisateurs qui travaillent quotidiennement avec les casiers, souvent sur tablette ou téléphone, la priorité était d'accéder rapidement à l'information et aux actions essentielles.
Plutôt que — tout afficher au même niveau.
Renoncer à la vue graphique des casiers
L'idée initiale était de représenter graphiquement les casiers pour se rapprocher de la réalité. Chaque casier portant plusieurs options possibles, cette vue complexifiait l'information et le développement, sur un outil utilisé en mobilité où l'on doit agir vite. Après discussion avec l'équipe de développement et la direction, j'y ai renoncé au profit d'une interface plus rapide à parcourir.
Plutôt que — une vue graphique des casiers.
Rendre le changement progressif
La v0 est restée en ligne et les fonctionnalités de la v2 ont été livrées une à une : une release hebdomadaire de correction, une fonctionnalité environ toutes les deux semaines, avec information des utilisateurs à chaque changement. J'ai participé à la rédaction de ces annonces ; le rythme a été décidé en équipe, selon les possibilités de chacun.
Plutôt que — un basculement unique.
Les arbitrages
Préserver vs. refondre
Une refonte complète aurait permis de repartir sur une architecture plus moderne, mais elle aurait aussi demandé aux utilisateurs existants de réapprendre le produit.
Simplifier vs. supprimer
L'objectif n'était pas de réduire les fonctionnalités, mais de rendre les fonctionnalités existantes plus accessibles.
Moderniser vs. familiariser
Le gain attendu ne venait pas d'une interface radicalement différente, mais d'une expérience plus lisible sans rupture avec les habitudes.
04 — La solution
Quatre évolutions qui ont changé l'expérience
La v1 étant inutilisable sur mobile, la v2 a été pensée pour tablette et téléphone, les terminaux des utilisateurs sur le terrain.
01
Créer sans quitter son contexte
‹›
Constat terrainPlusieurs remontées portaient sur la gestion des produits : création jugée moins intuitive, champ description trop étroit pour relire ou corriger un texte déjà saisi.
« Créer un produit est plus compliqué… ou beaucoup moins implicite. »Remontée client (extrait)
Le catalogue est le point de départ naturel de l'action : c'est là que l'utilisateur constate qu'un produit manque ou doit être corrigé.
Décision de conception
J'ai intégré la création et la modification directement depuis le catalogue.
Réponse dans l'interfaceLa fiche produit s'ouvre par-dessus le catalogue, qui reste visible en arrière-plan. → Un parcours plus court, sans changer le formulaire déjà connu.
02
Rendre les performances lisibles
‹›
Constat terrainLes retours sur l'écran Transactions convergeaient : chiffre d'affaires par site introuvable, classement imposé par date et heure, achats de plusieurs machines impossibles à voir sur un même écran, plusieurs clics pour obtenir le total du jour. Un client multi-sites indiquait ne plus utiliser la v1 pour ces raisons.
« Je n'ai pas le CA par site. […] Le gros problème selon moi c'est le classement par date et heure. »Remontée client (extrait)
Pour ces utilisateurs, l'écran sert avant tout à savoir rapidement ce qui a été vendu, et où, pour réapprovisionner.
Décision de conception
J'ai réorganisé la hiérarchie des transactions : totaux en tête, machines remises dans le tableau pour une vue globale, puis détail par jour, avec un tri et un choix entre tableau et graphique.
Réponse dans l'interfaceLe montant global s'affiche en tête, suivi des sous-totaux par machine et par jour, avec des vues par panier, produit, semaine, mois ou année. → Retrouver chiffre d'affaires et volumes sans manipulation supplémentaire.
03
Faire des alertes un outil d'action
‹›
Constat terrainPlusieurs remontées signalaient la disparition des couleurs orange et rouge qui évoluaient à l'approche de la date de péremption dans la v0.
« Il est nécessaire de remettre la nouvelle version avec les codes couleurs. »Remontée client (extrait)
Savoir immédiatement quels casiers vider ou réapprovisionner en priorité.
Décision de conception
J'ai réintroduit un code couleur sur les dates limites de vente, en retravaillant la densité et la hiérarchie du tableau.
Réponse dans l'interfaceChaque DLV est colorée selon sa proximité (vert, orange, rouge) dans le tableau de disposition. → Un repère de la v0 retrouvé, dans une interface plus lisible.
04
Les détails qui comptent
Moins visibles, ces irritants revenaient dans les usages quotidiens : chercher une valeur dans une longue liste, ne pas savoir si une action avait abouti, rester bloqué à la connexion. J'ai ajouté une recherche dans les listes déroulantes, des feedbacks de validation explicites et un parcours de récupération du mot de passe plus direct.
05 — Conception et validation
Concevoir avec les contraintes du produit
J'ai discuté les choix de conception avec les développeurs au fil des itérations, pour vérifier leur faisabilité et limiter les écarts à l'intégration. Chaque fonctionnalité a fait l'objet d'une fiche de test et d'un compte rendu de test fonctionnel, en interne. La direction, qui fait le lien avec le métier, a testé les évolutions avant leur sortie, et les maquettes ont été validées par le service commercial et la direction. Les clients n'étaient pas disponibles pour tester, mais leurs retours, relayés par le commercial, demandaient surtout un retour aux bases. Je n'ai pas conduit de tests utilisateurs sur ce projet.
06 — Impact
Une expérience plus familière, mieux adoptée
60%
des comptes connectés à la v2, contre 30 % sur la v1 (logs de connexion)
Avant
30 %
Après
60 %
Dans les mois qui ont suivi. La v0 restant accessible, les utilisateurs ont migré par choix, sans y être forcés.
5-6
Tickets SAV après la v2
contre 20 sur les trois mois suivant la v1, essentiellement des détails et non plus de grosses frustrations
Limites de ces chiffres
- Ils décrivent une évolution, pas l'effet isolé de mes choix : le rythme de releases et l'information des utilisateurs ont pu jouer.
- Environ 40 % des comptes ne sont pas connectés à la v2.
- Je n'ai plus accès aux logs ni aux dates exactes : ces chiffres sont des ordres de grandeur.
- L'échantillon de tickets est petit (20 au départ).
07 — Ce que je retiens
Sur un produit existant, améliorer l'expérience ne signifie pas forcément tout repenser.
Le principal enjeu était de comprendre ce qu'il fallait changer, et surtout ce qu'il fallait préserver.
Ce projet m'a appris
01
L'adoption est aussi un problème de repères
Moderniser ne suffit pas si l'interface rompt avec ce que les utilisateurs savaient déjà faire.
02
Les irritants du quotidien comptent
Une recherche difficile, un feedback absent ou une récupération de mot de passe compliquée semblent secondaires isolément, mais leur répétition dégrade fortement l'expérience.
03
Sur un produit mature, le design consiste aussi à savoir quoi ne pas changer.
04
Ce que je ferais avec plus de temps
Des tests utilisateurs sur prototype avant le développement.