Un bon onboarding amène l'utilisateur à la valeur de l'application en moins de 60 secondes, avant toute inscription ou demande de permission. Ce n'est ni un tutoriel ni un formulaire. L'article liste les 5 erreurs qui font supprimer une application, les 4 modèles qui retiennent et une méthode en 5 étapes pour concevoir le vôtre avant le développement.
Posez la question autour de vous : « qu'est-ce qui décide qu'un utilisateur reste sur une application ou la supprime ? ». Beaucoup répondront « la valeur du produit », « les fonctionnalités » ou « le design ». Peu répondront « l'onboarding ». Ce sont eux qui ont raison.
Parce que dans la vraie vie d'une application mobile, les fonctionnalités, le design et la valeur du produit ne servent à rien si l'utilisateur n'arrive jamais jusqu'à eux. Il s'arrête à l'écran de démarrage, à l'écran d'inscription, au tutoriel de 6 pages, à la demande de notifications. Il referme. Il désinstalle. Vous avez payé le développement d'une application que personne n'a vraiment utilisée. En amont de l'onboarding, c'est aussi votre fiche store qui doit attirer les bonnes personnes, sinon vous soignez l'expérience de gens qui n'auraient jamais dû télécharger : voir la méthode ASO pour préparer votre fiche store.
L'onboarding n'est pas un détail qu'on règle en V2. C'est la mécanique la plus structurante de votre rétention, celle qui se joue dans les 60 premières secondes après l'ouverture. Voici comment le concevoir, ce qui le tue, et ce qui le fait marcher.
Onboarding : la définition que tout le monde rate
Le mot onboarding est un faux ami. La plupart des gens qui lancent une application, designers compris, le confondent avec deux choses très différentes : le tutoriel et l'inscription. C'est cette confusion qui fait que la plupart des onboardings sont mal conçus.
Onboarding ≠ tutoriel
Un tutoriel explique comment marche votre application. C'est une visite guidée : trois écrans avec des dessins, des flèches, des explications. Le problème : l'utilisateur n'est pas venu pour apprendre votre application. Il est venu pour l'utiliser. Chaque écran de tutoriel l'éloigne de son but. Et le plus souvent, il passe ces écrans dès qu'il en a la possibilité.
Onboarding ≠ inscription
Un formulaire d'inscription collecte des informations : email, mot de passe, nom, prénom, parfois préférences marketing. C'est utile pour vous, pas pour l'utilisateur. Et le placer en premier, c'est demander à quelqu'un qui ne vous connaît pas encore de vous donner son identité avant qu'il ait vu un seul bénéfice. C'est l'équivalent d'un commerçant qui demanderait votre carte d'identité avant de vous laisser entrer dans son magasin.
L'onboarding, c'est trois choses à la fois
Un bon onboarding accomplit en parallèle trois objectifs : (1) configurer l'expérience pour cet utilisateur précis (pas un tutoriel générique, une expérience adaptée), (2) amener à la première valeur en moins de 60 secondes (le premier moment de valeur), (3) collecter le minimum vital d'informations pour personnaliser, en repoussant tout le reste à plus tard. Si votre onboarding ne fait pas ces trois choses, ce n'est pas un onboarding. C'est une barrière.
Pourquoi 60 secondes (et pas 5 minutes)
L'attention sur mobile fonctionne par petites décisions : « ça vaut le coup ou pas ». À chaque écran, l'utilisateur évalue sans y penser s'il continue ou s'il abandonne. Pas en réfléchissant. En ressentant. Et il a une infinité d'autres applications à portée de pouce, des notifications qui le tirent ailleurs, des messages, des stories, des emails.
Concrètement, voici ce qui se passe, dans les grandes lignes, pendant les 60 premières secondes d'utilisation d'une application neuve :
- De 0 à 5 secondes : écran de démarrage et premier écran. L'utilisateur compare ce qu'il voit à ce qu'il imaginait en téléchargeant. Si ça correspond, il reste. Si ça déçoit ou si c'est confus, il commence déjà à hésiter.
- De 5 à 20 secondes : il essaie de comprendre comment utiliser l'application. Si c'est évident, il avance. Si on lui demande des choses, il compare le coût (son temps, ses données personnelles) au bénéfice qu'il perçoit.
- De 20 à 60 secondes : il atteint son premier moment de valeur. Il a vécu ce qu'il était venu chercher, ne serait-ce qu'un avant-goût. À partir de là, l'application passe de « nouvelle app à tester » à « app que je peux peut-être garder ».
- Au-delà de 60 secondes sans valeur : beaucoup d'utilisateurs pensent déjà à partir. Chaque seconde supplémentaire sans valeur est une fuite.
La règle qui en découle est implacable : tout ce qui retarde l'utilisateur sur le chemin de sa première valeur, sans contrepartie, doit disparaître. Pas être optimisé. Disparaître. Le reste viendra plus tard, une fois l'utilisateur engagé.
Les 5 erreurs qui tuent un onboarding
Ces cinq erreurs reviennent presque systématiquement dans les applications dont l'onboarding est raté. Aucune n'est due à un manque de talent : ce sont des choix par défaut, pris sans se poser de questions. C'est exactement ce qui les rend dangereuses.
1. Le tutoriel exhaustif
Trois à six écrans qui présentent les fonctionnalités, avec des illustrations et des flèches. Personne ne le lit vraiment. La plupart des utilisateurs font défiler les écrans jusqu'au bout sans lire, et retiennent peu de ce qu'ils ont vu. Vous avez consommé une partie de leur attention pour rien.
2. L'inscription avant la valeur
L'écran « créez un compte pour continuer » placé en deuxième écran. C'est l'erreur la plus coûteuse. Votre utilisateur ne sait pas encore ce que vaut votre application, et vous lui demandez son email. Sa réaction : « est-ce que ça vaut le coup que je donne mes informations à un truc que je ne connais pas ? ». Souvent, c'est non. Il quitte. L'inscription doit arriver après le premier moment de valeur, pas avant.
3. Les permissions agressives
Les fenêtres de demande de notifications, de localisation ou de contacts au tout premier lancement. Un utilisateur qui n'a pas encore compris ce que fait votre application refusera la plupart des permissions par réflexe. Et iOS n'affiche la demande système qu'une seule fois : une permission refusée ne se redemande pas. Vous venez de perdre l'accès aux notifications de cet utilisateur, parce que vous lui avez demandé trop tôt.
4. Le paywall masqué
L'utilisateur touche ce qu'il croit être « commencer » et tombe sur un écran d'abonnement à 9,99 € par mois avec un compte à rebours « offre limitée ». La frustration est immédiate, le sentiment de tromperie aussi. Même si votre application est gratuite avec une partie payante, ou sur abonnement, ne montrez l'écran de paiement qu'après que l'utilisateur a vécu assez de valeur pour comprendre pourquoi il devrait payer. Sinon, vous faites payer de la déception.
5. Le formulaire long
Cinq champs à remplir avant de pouvoir utiliser l'application : âge, ville, sexe, centre d'intérêt, pseudo. Chaque champ ajoute du temps, et chaque champ ajoute une occasion d'abandonner. Pour une première version, posez-vous la question pour chaque champ : « qu'est-ce qui se casse si je ne demande pas cette information maintenant ? ». Le plus souvent, rien ne se casse. Vous pouvez la demander plus tard, ou la déduire de l'usage.
Le fond du problème derrière ces 5 erreurs est toujours le même : on demande avant d'avoir donné. C'est la même logique qui fait que les applications avec trop de fonctionnalités abîment leur propre rétention : on alourdit la première session au lieu de la rendre fluide.
Les 4 modèles d'onboarding qui retiennent
Quand on regarde les applications qui retiennent le mieux dès le lendemain, on retrouve quatre modèles d'onboarding bien identifiés. Ils ne s'excluent pas : la plupart des applications les combinent. Mais chacun a sa logique, et il faut comprendre lequel correspond à votre produit.
1. Sans inscription (Duolingo, Headspace)
L'utilisateur peut commencer à utiliser l'application sans créer de compte. Duolingo vous fait choisir une langue, démarrer la première leçon et la réussir avant même de vous demander un email. Headspace vous fait écouter une courte méditation avant le moindre formulaire. La logique : laissez l'utilisateur apprécier le produit avant de lui demander quoi que ce soit. Une fois qu'il a vécu la valeur, il accepte volontiers de créer un compte pour sauvegarder sa progression.
Pour qui : les applications dont la valeur peut se montrer sans données personnelles. Applications de contenu, d'apprentissage, outils.
2. La personnalisation rapide (Spotify, Strava)
L'onboarding pose 2 ou 3 questions ciblées (pas 10) pour adapter tout de suite l'expérience. Spotify vous demande vos artistes préférés en cochant des bulles, et vous propose une playlist de bienvenue dans la foulée. Strava vous demande votre sport principal et votre niveau. La logique : la personnalisation est elle-même le premier moment de valeur. L'utilisateur sent que l'application le comprend.
Pour qui : les applications dont la valeur dépend fortement du profil de l'utilisateur (sport, contenu, place de marché, rencontre).
3. La démonstration immédiate (BeReal, TikTok)
L'utilisateur arrive directement sur le contenu vivant de l'application, sans onboarding du tout. TikTok vous montre des vidéos dès l'ouverture. La logique : la valeur est si évidente qu'elle se montre, elle ne s'explique pas. L'inscription vient quand l'utilisateur veut faire quelque chose qui demande un compte (publier, aimer un contenu, commenter).
Pour qui : les applications de contenu social où regarder a déjà une valeur en soi.
4. La configuration guidée (Nike Run Club, Notion)
Un onboarding plus structuré, en 3 à 5 étapes, qui configure réellement l'application pour l'utilisateur. Nike Run Club vous fait choisir un objectif (perdre du poids, courir un 5 km) et vous prépare un plan d'entraînement avant la première course. Notion vous demande votre cas d'usage et active les bons modèles. La logique : l'application fait pour vous un travail invisible, qui prouve qu'elle est sérieuse.
Pour qui : les applications complexes ou très personnalisables, où une mauvaise configuration gâche l'expérience.
Le modèle à choisir dépend de ce que votre application propose. Mais la règle commune à tous : chaque seconde d'onboarding doit produire de la valeur, ou être supprimée. Pas remplie d'illustrations sympathiques. Pas optimisée. Supprimée.
Construire votre onboarding en 5 étapes
Voici la méthode que j'applique au cadrage de chaque projet Zuhd Studio. Cinq étapes, faisables en une séance de travail concentré. Elle sert avant le développement, et reste valable après le lancement.
Étape 1 : définissez votre premier moment de valeur
Quelle est l'action précise après laquelle l'utilisateur peut dire « ah, oui, c'est ça que je suis venu chercher » ? Ce n'est pas la fin de l'onboarding. Ce n'est pas le compte créé. C'est le premier vrai usage. Pour Spotify, c'est « j'écoute ma première musique adaptée à mes goûts ». Pour une application de comptabilité, c'est « je vois mon premier chiffre calculé automatiquement ». Écrivez cette phrase. Si vous ne pouvez pas, vous ne savez pas encore ce que votre application apporte.
Étape 2 : listez tout ce qui peut attendre
Faites la liste complète de ce que votre onboarding prévoit de demander : inscription, mot de passe, profil, photo, bio, préférences, permissions, paramètres. Pour chaque ligne, posez la question : « qu'est-ce qui se casse si je ne demande pas ça maintenant ? ». Le plus souvent, la réponse est « rien ». Tout ce qui peut attendre doit attendre.
Étape 3 : concevez le chemin minimum
Dessinez le chemin le plus court possible entre l'ouverture de l'application et le premier moment de valeur. Idéalement, 2 à 4 écrans au plus, plus l'écran de valeur. Chaque écran sert un objectif unique : configurer, demander, ou donner. Si un écran fait deux choses, séparez-le ou supprimez-le.
Étape 4 : testez avec 5 personnes (sans contexte)
Donnez votre prototype à 5 personnes qui ne connaissent pas votre projet, sans rien expliquer. Filmez-les pendant les 90 premières secondes. Vous verrez tout de suite où elles hésitent, où elles touchent le mauvais endroit, où elles soupirent, où elles abandonnent. Cinq tests valent mieux que des semaines de débats. C'est l'un des investissements les plus utiles que vous ferez sur votre onboarding.
Étape 5 : améliorez sur les chiffres
Une fois l'application lancée, mesurez. Combien de personnes commencent l'onboarding ? Combien arrivent à l'étape 2, 3, 4 ? Combien atteignent le premier moment de valeur ? Combien reviennent le lendemain ? Sans ces données, vous avancez à l'aveugle. C'est ce que détaille la partie mesure de l'article sur la rétention : un onboarding mesuré étape par étape fait d'une application un produit qui s'améliore.
Pour mesurer ce parcours dès la sortie, l'étape 5 du guide gratuit explique pourquoi la mesure d'usage s'installe pendant le développement, pas après.
Si l'onboarding ne marche pas après le lancement
Si l'application est lancée et que peu d'utilisateurs reviennent le lendemain, l'onboarding est souvent le premier coupable. Voici comment faire un diagnostic rapide et corriger dans le bon ordre.
Le diagnostic en 30 minutes
Faites trois choses dans l'ordre : (1) chronométrez votre propre première session jusqu'au premier moment de valeur, (2) regardez le parcours de la première session dans votre outil de mesure d'usage et repérez les chutes les plus fortes, (3) demandez à 3 utilisateurs récents pourquoi ils sont restés, ou pourquoi ils ont arrêté. Ces trois entrées vous donnent l'essentiel du diagnostic.
Corriger dans le bon ordre
Une règle simple : commencez par la plus grosse chute du parcours. Si c'est l'écran d'inscription qui perd le plus de monde, c'est là que vous corrigez en premier (rendre l'inscription facultative, ou la déplacer après la valeur). Si c'est la demande de permission, c'est là (la déplacer ou l'expliquer). Une seule correction à la fois, mesurée sur 1 à 2 semaines, puis on passe à la suivante. Pas de refonte massive : elle empêche d'apprendre ce qui marche.
Ce que ça change pour votre projet
Un bon onboarding ne se voit pas. Il fait juste arriver l'utilisateur, sans qu'il s'en rende compte, à un moment où il vit la valeur. C'est silencieux, c'est court, c'est efficace. Et c'est dans ces 60 premières secondes que se joue la différence entre une application qu'on garde et une application qu'on supprime.
L'onboarding n'est pas une couche ajoutée à la fin du développement. C'est une décision de cadrage, parce qu'il conditionne l'architecture, le périmètre, et même la façon dont l'application gagnera de l'argent. Au cadrage, une fois le problème, la cible et les fonctionnalités posés, c'est l'un des premiers écrans que je détaille : comment l'utilisateur entre dans l'application, et en combien de temps il vit sa valeur.
Vous avez une idée d'application ?
Zuhd Studio la conçoit, la développe pour l'App Store et Google Play, et vous la livre en 60 jours, pour un prix fixe.