Pourquoi seuls 14 visiteurs sur 100 terminent-ils l'onboarding ?
Entonnoir de conversion à interpréter et fluidifier
Contexte
Flowrate est un outil SaaS de gestion collaborative (suivi du temps, gestion de projets, facturation). Le problème à résoudre : sur 100 visiteurs de la landing page, seulement 14 terminent l'onboarding, alors que 58 cliquent sur le bouton d'inscription. La mission : comprendre où et pourquoi les utilisateurs abandonnent, puis proposer une feuille de route d'améliorations UX. L'analyse porte sur la version desktop, l'outil n'étant pas adapté au mobile.
Rôle et durée
Réalisation en solo, en tant que UX designer : audit heuristique, analyse des données d'usage, analyse croisée et roadmap. Durée d'environ 40 heures.
Recherche
Pas d'entretiens sur ce projet : la recherche repose sur un audit qualitatif et sur les statistiques d'usage du mois d'avril, croisés pour chaque point de friction.
- Repérer les irritants vécus en parcourant l'interfaceExploration libre comme un nouvel utilisateur, puis audit heuristique de Nielsen (gravité, justification, proposition d'amélioration). Exemple : boutons « Voir la démo », « Commencer » et « Nous contacter » inopérants, liens du footer renvoyant en haut de page.
- Savoir où les utilisateurs décrochentAnalyse quantitative par étape du parcours, comparée aux moyennes du secteur SaaS. Exemple : sur 100 visites, 14 onboardings terminés, soit 14 % contre 40 à 60 % pour un onboarding sain.
- Vérifier que les frictions ressenties se retrouvent dans les usagesAnalyse croisée : pour chaque constat qualitatif, la donnée quantitative associée, une conclusion et une recommandation.
Exemple : formulaire jugé intrusif, avec 46 % d'abandon, 3 min 42 passées et 4,6 erreurs par session.
Processus de conception
Du constat brut à un plan d'action classé et daté.
- Un grand nombre de frictions à identifier.Classer les points par gravité et par catégorie (navigation, contenu, formulaire, accessibilité, UI), puis les numéroter : 27 points de friction documentés dans le rapport d'analyse croisée.
- Des données difficilement exploitables seulesLes confronter à des repères du secteur et formuler des hypothèses plausibles : seuls 34 % des utilisateurs voient la formation en entier et 29 % cliquent sur « Passer temporairement », elle est perçue comme une contrainte.
- Définir l'ordre des actionsRoadmap UX avec priorité, catégorie, dépendances entre actions et planification sur 4 mois.
Solutions de design
Chaque problème est indiqué en rouge directement sur l'interface qui le montre, avec la solution recommandée juste en dessous.
Résultats et impact
Les recommandations n'ont pas été mises en œuvre dans le cadre du projet : l'impact reste donc attendu et non mesuré. Il serait suivi sur le taux de clic du CTA, l'abandon sur le formulaire, la fluidité de la configuration et surtout le taux de conversion final, aujourd'hui de 14 %.
- Un audit heuristique et une analyse croisée complète27 points de friction, chacun avec constat, donnée, conclusion et recommandation
- Une roadmap UX priorisée27 actions sur 4 mois : 13 de priorité haute, 9 moyenne, 5 basse
- Une présentation de restitutionDémarche, analyse quantitative, conclusions croisées et roadmap (2 juin 2026)
Réflexion critique
Cette analyse relie des frictions observées à des chiffres d'usage, mais elle reste une lecture d'hypothèses. Les statistiques montrent où les utilisateurs abandonnent, pas pourquoi : affirmer que les erreurs successives ou le ton anxiogène provoquent des abandons reste une interprétation plausible, que seuls des tests utilisateurs ou des entretiens permettraient de confirmer. L'audit repose en outre sur un seul parcours d'exploration, avec le biais que cela implique.
Les données elles-mêmes ont des limites. Elles portent sur un seul mois et sur un échantillon réduit : 100 visites, et seulement 17 utilisateurs à l'étape de formation, ce qui rend les écarts entre étapes fragiles. Les repères du secteur, issus de benchmarks généralistes sur le SaaS, donnent un ordre de grandeur plutôt qu'une norme exacte. Enfin, l'analyse ne couvre que la version desktop, alors que la question du mobile reste entière.
Ces tests et ces mesures n'étaient pas dans le périmètre du projet, qui se limitait à l'analyse et à la roadmap. Dans un cadre réel, les hypothèses les plus lourdes seraient d'abord validées par des tests utilisateurs sur l'inscription et la configuration. L'effet des corrections prioritaires serait ensuite mesuré par des comparaisons avant et après, par exemple sur l'abandon du formulaire et la conversion finale, avant de dérouler le reste de la roadmap.