Un produit puissant que personne ne dépassait le premier écran
Kaya Finance édite un logiciel de gestion de trésorerie pour PME. Trois cents clients, une rétention solide, et un onboarding qui perdait sept nouveaux comptes sur dix avant la première utilisation réelle.
KAYA
- Contexte
- SaaS B2B — 300 clients, Lyon
- Rôle
- Product Manager, rattaché au CEO
- Équipe
- 1 designer · 3 développeurs · 1 CTO
- Durée
- 4 mois — 2025
Ce que j'ai porté — le cadrage du problème, les huit tests
d'utilisabilité, l'arbitrage du périmètre, la définition des métriques
d'activation, la présentation au comité de direction et l'arbitrage de
renoncer au recrutement de deux commerciaux.
Ce que je n'ai pas fait — les maquettes finales (designer
interne), l'implémentation (équipe technique), l'instrumentation Amplitude
(CTO).
01 — Contexte
Le problème
L'équipe avait passé quatre ans à construire un moteur de prévision de trésorerie remarquable. Les clients installés l'adoraient — 94 % de rétention annuelle. Le problème se situait entièrement dans les quinze premières minutes.
Le coût d'acquisition d'un essai gratuit atteignait 180 €. Avec 29 % d'activation, chaque client payant coûtait donc bien plus cher qu'il ne fallait. La direction envisageait de recruter deux commerciaux pour accompagner manuellement chaque inscription.
Ce que disaient les chiffres
- Activation (premier scénario de prévision créé) : 29 % des inscrits.
- Temps médian jusqu'à la première valeur : 12 minutes 40.
- Abandon concentré à l'écran 3 sur 6 : import des données bancaires.
- 47 tickets de support par semaine, dont 31 sur la même question.
- Trois interfaces différentes cohabitaient selon l'ancienneté des modules.
Recruter des commerciaux aurait masqué le problème à un coût récurrent. J'ai proposé l'inverse : rendre les quinze premières minutes évidentes.
02 — Recherche
Ce qu'on a appris
Huit tests d'utilisabilité modérés avec des dirigeants de PME n'ayant jamais vu le produit, plus l'analyse de 200 sessions enregistrées et le dépouillement de six mois de tickets support.
L'import bancaire arrivait trop tôt
Le produit demandait de connecter un compte bancaire réel à l'écran 3, avant d'avoir démontré la moindre valeur. Sept utilisateurs sur huit ont exprimé la même réticence : « je ne connecte pas mes comptes à un outil que je n'ai pas encore vu fonctionner ».
Le vocabulaire était celui des développeurs
« Instancier un scénario », « paramétrer un connecteur », « flux canonique ». Aucun dirigeant de PME n'utilise ces mots. Les tickets support étaient en réalité des demandes de traduction.
La cohérence visuelle coûtait de la confiance
Trois générations d'interface se succédaient au fil de la navigation. Plusieurs testeurs ont cru changer d'application. Sur un produit financier, l'incohérence se lit comme un défaut de sérieux.
03 — Solution
Les décisions
La valeur avant l'engagement
Nouveau parcours : jeu de données de démonstration proposé dès l'écran 1, adapté au secteur déclaré à l'inscription. L'utilisateur voit sa première prévision en moins de deux minutes, avec des chiffres crédibles. L'import bancaire est repoussé à l'écran 6, une fois la valeur démontrée.
Une réécriture complète de l'interface
Chaque libellé a été réécrit depuis le point de vue de l'utilisateur. « Instancier un scénario » est devenu « Créer une prévision ». « Connecteur » est devenu « Banque ». Les actions portent le même nom du bouton jusqu'au message de confirmation. Ce travail seul a supprimé 31 tickets hebdomadaires.
Un design system, pas une charte
72 composants documentés dans Figma, avec pour chacun : les états, les règles d'usage, les cas où il ne faut pas l'employer, et les jetons correspondants côté code. La documentation vit dans le même dépôt que le produit, ce qui la rend révisable comme du code.
Une divulgation progressive assumée
Les 40 paramètres avancés, autrefois tous visibles, sont désormais regroupés derrière un panneau « Réglages fins ». Les utilisateurs experts les retrouvent en un clic ; les nouveaux ne les rencontrent jamais. Aucune fonctionnalité n'a été supprimée.
Ce qui n'a pas fonctionné
Une visite guidée interactive en cinq étapes, testée pendant six semaines. Taux de complétion : 18 %. Les utilisateurs la fermaient pour explorer seuls. Remplacée par des aides contextuelles déclenchées à la première hésitation détectée — un principe plus discret et plus efficace.
03 bis — Arbitrage
Ce que nous n'avons pas fait
Recruter deux commerciaux pour accompagner chaque inscription
C'était la solution privilégiée par la direction à mon arrivée : un coût récurrent pour compenser un problème de conception. Argument qui a emporté la décision : le coût d'acquisition par client payant serait passé de 1 636 € à davantage encore, alors que l'objectif était de le faire baisser. Écarté au premier comité.
Refondre le moteur de prévision
Demandé par deux clients importants. Trois mois de développement estimés, pour une population minoritaire — alors que l'onboarding concernait 100 % des inscrits. Reporté. C'était le bon arbitrage : la rétention annuelle des clients installés était déjà à 94 %, il n'y avait rien à sauver de ce côté-là.
Simplifier le produit en supprimant les 40 paramètres avancés
Séduisant sur le papier, et cohérent avec le diagnostic. Écarté après entretien avec les comptes les plus anciens : ces paramètres étaient la raison exacte de leur fidélité. La divulgation progressive a permis de servir les deux populations sans arbitrer entre elles.
Outils
Ce qui a servi
04 — Le relevé
Avant, après, écart
Mesures relevées 90 jours après le déploiement, sur une cohorte de 1 240 nouveaux inscrits. Sources : Amplitude, base support interne.
« Notre design system a survécu à deux changements d'équipe. C'est le meilleur indicateur de qualité que je connaisse. »
Thomas Leroy, CTO
05 — Apprentissages
Ce que j'en retiens
- Les mots sont de l'interface. La réécriture des libellés a produit plus d'effet mesurable que la refonte visuelle. Elle n'a coûté que huit jours.
- Demander la confiance avant de la mériter fait fuir. Repousser l'import bancaire de trois écrans a suffi à récupérer la moitié des abandons.
- Un design system se juge en jours de livraison, pas en beauté. Neuf jours devenus trois : c'est l'argument qui a convaincu la direction de financer sa maintenance.
- Les visites guidées sont rarement la réponse. Un produit qui a besoin d'être expliqué a un problème de conception, pas un problème de pédagogie.