Onboarding

L’onboarding est la première expérience : on apprend à connaître la personne, on lui montre un bilan qui donne envie d’arrêter, puis on crée le compte.

Les étapes

Le parcours enchaîne une série d’écrans (dans l’ordre) :

1. Welcome — écran d’accueil. Il porte le vent, le glyphe de l’icône de l’app, et annonce d’entrée la thèse du coach : « On ne se libère pas du tabac en comptant ce que l’on gagne, mais en réalisant qu’on ne perd rien. » Deux boutons de même largeur : « Commencer mon parcours » (plein) et « J’ai déjà un compte » (bordé). Voir Deux sorties, pas une.
2. Prénom — pour personnaliser le ton. Le clavier s’ouvre tout seul à l’arrivée sur l’écran.
3. Pourquoi arrêter — sélection de raisons (multi-choix).
4. Cigarettes par jour — sert au calcul des économies.
5. Depuis combien de temps — années de tabac, sert aux calculs de santé.
6. Bilan — le coût calculé, le prix du paquet détecté selon la région (voir Prix du paquet par pays). La 4ᵉ tuile affiche « +X jours d’espérance de vie à regagner ».
7. Tentatives précédentes — combien de fois on a déjà essayé.
8. Date d’arrêt — tout de suite, ou une date planifiée dans le futur.
9. Notifications — demande de permission (qu’on peut passer).
10. Preuve sociale — combien de personnes utilisent Kaiho, la note des stores et un carrousel de 12 avis, voir Preuve sociale.
11. Création de compte — Apple et Google en tête (Apple sur iOS seulement), puis « ou », puis email + mot de passe. L’écran de connexion (« J’ai déjà un compte ») suit le même ordre depuis octobre 2026 (ios#124, android#128) ; avant, il mettait l’email en premier.

Test A/B préparé : le Bilan avant la création de compte

Depuis ios#125 / android#129 (pas encore publiés, test pas encore lancé), l’ordre peut dépendre du test PostHog « Onboarding : Bilan avant la création de compte » (flag onboarding-bilan-before-signup, 50/50) :

• control : l’ordre ci-dessus.
• test : à la place du Bilan, un écran « On analyse tes réponses… » : un grand anneau se remplit de 0 à 100 % en environ 6 secondes (il ralentit vers la fin), trois lignes se cochent avec le détail des réponses de la personne (« 15 cigarettes par jour », « 12 ans de tabac », puis « Calcul en cours… » devenu « Révélé à la fin du parcours », jamais le montant) et une phrase de la méthode s’affiche pendant l’attente. À la fin : « Ton bilan est prêt, on te le montre à la fin du parcours » et un bouton « Continuer » (pas d’avance automatique). Le Bilan passe juste avant la création de compte. Le retour arrière saute l’écran d’analyse.

Le groupe est lu une seule fois, à l’entrée dans l’onboarding, puis figé (même après une relance de l’app). Si PostHog n’a pas répondu à ce moment-là, la personne suit l’ordre actuel et n’est pas comptée dans le test. Le groupe reste le même après la création du compte. Idée issue du point avec Rayan (régie pub, 21/10/26) : le Bilan est le « moment fort » de l’onboarding, placé juste avant le compte il doit donner envie d’aller au bout. Indicateur principal : la part qui termine la création de compte.

Écran « Confidentialité » retiré (oct. 2026, ios#123 / android#127)

Il venait entre la date d’arrêt et les notifications. Il ne recueillait aucun consentement : il listait seulement des engagements (données chiffrées, hébergées en UE, RGPD, jamais revendues, suppression possible). Le choix analytics reste dans le Profil, et la politique de confidentialité est liée sur l’écran de création de compte. Conséquence pour le suivi : plus d’onboarding_step_completed avec step_id = privacy, et le step_index des trois étapes suivantes baisse de 1 (voir Événements).

Deux sorties, pas une

Le Welcome sert deux publics : les nouveaux, et les revenants qui ont déjà un compte. Jusqu’à fin juillet 2026 il ne traitait que le premier — l’inscription était un gros bouton plein, la connexion une ligne de texte en taille footnote juste en dessous. Des gens qui avaient déjà un compte s’en recréaient un.

Ce n’était pas une intuition : sur 60 jours, 136 inscriptions ont échoué en « cette adresse est déjà utilisée ». Et ces 136 ne sont que la partie visible — quelqu’un qui repasse par Apple ou Google est simplement re-connecté, sans laisser de trace d’erreur.

Les décisions de conception en réponse :

• Les deux sorties ont le même poids. Même largeur, même surface tactile ; la hiérarchie est portée par le remplissage (l’inscription est pleine, la connexion est bordée), pas par la taille.
• Le libellé nomme la situation, pas l’action. « J’ai déjà un compte » plutôt que « Se connecter » : le revenant se reconnaît sans avoir à faire lui-même le raisonnement « donc je dois me connecter ».
• L’entrée ne parle pas de compte. Fin juillet, le bouton principal disait « Commencer mon inscription », pour qu’on devine qu’un compte allait être créé. En octobre 2026 (ios#123, android#127), il est revenu à « Commencer mon parcours » : pour un nouveau venu, « inscription » est une friction, et la mesure de septembre n’a montré qu’un effet faible de la refonte sur les doublons (sur Android, les échecs « adresse déjà utilisée » ne baissent que d’environ 17 %). « J’ai déjà un compte » reste : il ne s’adresse qu’aux revenants, pour qui le mot est exact.

L’effet se lit dans la part des deux sorties du Welcome (welcome_sign_in_tapped contre onboarding_started) : 10,9 % pour la connexion avant le changement. Voir Tracking.

Garde-fou sur l’adresse e-mail

Quand le domaine saisi ressemble à une faute de frappe d’un domaine connu, une suggestion apparaît sous le champ dès qu’on en sort : « Tu voulais dire … ? ». Un tap l’accepte.

C’est une suggestion, jamais un blocage : une adresse d’entreprise que l’app ne connaît pas ne doit pas empêcher une inscription. L’appariement est volontairement prudent et se tait dès qu’une correction pourrait être fausse — il ne touche ni aux variantes pays (hotmail.ca, yahoo.it), ni aux domaines professionnels.

Le besoin vient d’un constat en base : 14 comptes avaient une adresse structurellement valide mais indélivrable (@gmail.comd, @iclous.com, @bbox.frf…). Comme la confirmation d’e-mail est désactivée, ces personnes entraient normalement dans l’app, mais ne pouvaient jamais réinitialiser leur mot de passe. Les 14 adresses ont été corrigées à la main.

Le Welcome n’est pas compté comme une étape du funnel

Côté mesure, le funnel d’onboarding commence après le Welcome (qui est une simple landing). Voir Tracking.

Après l’onboarding

Une fois le compte créé, pour une personne non premium, le paywall (source onboarding_end) est présenté directement, en plein écran, juste après l’inscription. On entre dans l’app (l’accueil du Coach) à sa fermeture. Une personne déjà premium entre directement, sans paywall.

L’idée : capter l’intention d’achat à son pic, quand le profil vient d’être créé et que la personne a investi tout l’onboarding.

Une reprise à froid est gérée : si quelqu’un abandonne en plein milieu de la création de compte puis revient avec une session déjà connectée, l’app le récupère au bon endroit.

Vérifier qu’un compte existe (lancement et connexion)

Au lancement, et après une connexion, l’app regarde si le compte a fini l’onboarding : d’abord dans les données du téléphone, sinon en le demandant au serveur. Jusqu’en septembre 2026, si le serveur ne répondait pas, l’app concluait « pas de compte » et renvoyait la personne sur l’écran d’accueil de l’onboarding, alors qu’elle était bien connectée. Depuis le 1/8/2026, cela touchait 10 à 25 personnes par semaine sur Android (41 abonnés au total) et 4 à 10 sur iOS. Environ la moitié ne retrouvaient pas leur compte, et certaines s’en créaient un second, vide.

Nouvelle règle (PR android#117 et PR ios#110, publiées en 1.13.0 le 2/10/2026 sur Android et iOS) : un serveur qui ne répond pas veut dire « on ne sait pas », jamais « pas de compte ».

• Au lancement : si ce compte est déjà entré dans l’app sur ce téléphone, on le laisse entrer.
• À la connexion : même chose. Sinon, message d’erreur réseau sur l’écran de connexion, et plus de renvoi vers l’onboarding.
• En fin d’onboarding : l’inscription échoue proprement au lieu d’écrire le profil. Avant, ce cas pouvait écraser le vrai profil d’un compte existant, date d’arrêt comprise.
• Abonnement : l’app ne rattache le compte à RevenueCat qu’une fois son existence confirmée. Avant, un « Continuer avec Google » sur l’écran de connexion pouvait créer un compte vide et y faire transférer l’abonnement du téléphone. Cas réel : une abonnée a payé de juillet à septembre sans avoir le premium sur son vrai compte.

La cause (PR android#118 et PR ios#111, publiées en 1.13.0 le 2/10/2026 sur Android et iOS) : la connexion d’un utilisateur se renouvelle toutes les heures. Après plus d’1 h sans ouvrir l’app, l’app doit la renouveler au lancement. Si le téléphone n’a pas encore de réseau à ce moment-là, le renouvellement échoue. L’app croyait alors l’utilisateur déconnecté, alors que sa connexion était toujours là. Désormais, elle démarre sur les données du téléphone et renouvelle la connexion dès que le réseau revient. Seule exception : si le serveur refuse vraiment la connexion (déconnexion sur un autre appareil, compte supprimé), l’utilisateur est renvoyé vers l’écran de connexion.

Entre l’inscription et le paywall, l’app attend que la première synchronisation rapatrie le profil. Cette attente est plafonnée à 10 secondes sur les deux plateformes : si la synchro tarde ou ne répond pas, on continue sur les données locales plutôt que de rester sur un écran de chargement — la synchro rattrape ensuite en arrière-plan. Le plafond existait côté Android depuis l’origine ; iOS l’a rejoint.

Historique : le handoff « première leçon » (1.5.0 → réverti le 24 juillet 2026)

Entre le 9 juillet et le 24 juillet 2026, la fin d’onboarding a fonctionné autrement : au lieu du paywall présenté systématiquement en fin d’onboarding, un écran de transition déposait la personne dans la première leçon de la Clé 0, et le paywall onboarding_end était différé (présenté plus tard, hors du lecteur). L’objectif était la rétention.

Ce que la mesure a montré, puis la décision :

• L’activation a bondi : ouvrir une leçon en première session est passé de 30 % à 96 %, et le retour un jour suivant de 26 % à 37 % — effet réel et solide.
• Mais l’exposition au paywall a chuté : de 100 % (paywall systématique) à ~45–58 %, et le taux d’achat de 7,8 % à ~5,0 %. La conversion par vue de paywall n’avait pas baissé (elle était même un peu meilleure) — c’était bien un problème d’exposition. Un correctif (paywall éligible dès l’ouverture de la leçon, et branche « Plus tard » enfin couverte) a été livré le 20 juillet pour regagner l’exposition.
• Décision produit (24 juillet 2026) : revenir au paywall systématique en fin d’onboarding (systématique, mais toujours fermable : ce n’est pas un mur) malgré les gains d’activation/rétention. Le handoff, l’écran de transition et le paywall différé sont retirés.

Cet historique est conservé volontairement : les chiffres d’activation restent le meilleur argument connu si l’on voulait un jour réessayer une variante moins coûteuse en exposition.

La date d’arrêt planifiée

C’est un cas à part : on peut choisir une date d’arrêt dans le futur au lieu d’arrêter tout de suite.

• La date d’arrêt réelle n’est pas encore posée ; on enregistre une date planifiée.
• Trois rappels locaux sont programmés : J-3, J-1 et le jour J, à 9h.
• Le jour J, la personne confirme (ou pose sa date d’arrêt dans le profil), et le suivi démarre vraiment.

Voir aussi Notifications.