Lazy registration mobile : essayer avant de s'inscrire

Le taux de chute entre "télécharger une app" et "créer un compte" est brutal. Les études montrent que 40 à 60% des utilisateurs abandonnent au moment de l'inscription. Tu as payé pour l'acquisition, l'utilisateur a fait l'effort de télécharger, et il part parce que tu lui demandes son email avant même qu'il ait vu ta première fonctionnalité.

Ma solution pour TAMSIV : retarder l'inscription au maximum. Laisser l'utilisateur tout essayer — créer des tâches, dicter des mémos, explorer les features — sans jamais lui demander de compte. C'est ce qu'on appelle la lazy registration, et c'est la meilleure décision UX que j'ai prise.

Points clés à retenir :
- Supabase Anonymous Auth crée un compte invisible dès le premier lancement
- L'utilisateur obtient un vrai UUID et les mêmes permissions qu'un compte classique
- La migration anonyme vers compte réel conserve toutes les données intactes
- Les rappels d'inscription doivent être contextuels, jamais intrusifs
- Un onboarding de 3 slides maximum avec bouton "Passer" visible suffit

Pourquoi la friction d'inscription tue-t-elle les conversions ?

Pour comprendre le problème, mettons-nous à la place de l'utilisateur. Il découvre TAMSIV sur le Play Store, les screenshots l'intéressent, il télécharge. L'app s'ouvre et... formulaire d'inscription. Email, mot de passe, confirmation par email.

À ce moment-là, l'utilisateur ne sait pas si l'app vaut le coup. Il n'a rien vu, rien essayé. Tu lui demandes un engagement (ses données personnelles) en échange d'une promesse (ton app est géniale). C'est un deal déséquilibré.

Les chiffres sont sans appel. Selon AppsFlyer, le taux moyen d'inscription post-download dans les apps de productivité est de 45%. Ça signifie que plus de la moitié des utilisateurs qui téléchargent ne créent jamais de compte. C'est un gaspillage énorme de budget acquisition.

La lazy registration inverse le problème : au lieu de demander "inscris-toi pour essayer", on dit "essaie, et inscris-toi si ça te plaît".

Comment fonctionne l'Anonymous Auth de Supabase ?

Au premier lancement de TAMSIV, l'app crée automatiquement un compte anonyme via Supabase Anonymous Auth. L'utilisateur ne voit rien — pas de formulaire, pas de popup, pas de loading. Mais en arrière-plan, un vrai compte est créé :

• Un UUID unique est attribué (identique à un compte classique)
• Un JWT token est généré pour l'authentification
• Les RLS policies (Row Level Security) s'appliquent normalement
• L'utilisateur peut créer des tâches, des mémos, utiliser la voix — tout fonctionne

Techniquement, la seule différence entre un compte anonyme et un compte réel : pas d'email associé. Le UUID est identique, les permissions sont identiques, le stockage est identique. Pour le backend et la base de données, un utilisateur anonyme est un utilisateur comme un autre.

C'est élégant parce que ça évite de gérer deux "modes" dans le code. Pas de condition if (isAnonymous) { ... } partout. Les mêmes services, les mêmes RPC, les mêmes tables fonctionnent uniformément.

Comment designer un onboarding minimaliste ?

L'onboarding de TAMSIV, c'est 3 slides. Pas 7. Pas 10. Trois.

Chaque slide répond à une question :

1. "C'est quoi TAMSIV ?" — Une phrase. "Tes tâches et mémos, par la voix."
2. "Comment ça marche ?" — Une illustration animée du dictaphone.
3. "Par où commencer ?" — Un CTA direct vers le dictaphone.

Le bouton "Passer" est toujours visible. Toujours. Les utilisateurs impatients (et ils sont nombreux) doivent pouvoir sauter l'onboarding sans friction. Forcer quelqu'un à regarder 3 slides qu'il ne veut pas voir, c'est perdre sa confiance dès les premières secondes.

Ce design minimaliste est inspiré des recommandations de Nielsen Norman Group sur l'onboarding : montrer, pas expliquer. L'onboarding le plus efficace, c'est celui que l'utilisateur oublie immédiatement parce qu'il était naturel.

Que sont les empty states riches et pourquoi sont-ils importants ?

Après l'onboarding, l'utilisateur arrive dans l'app. Et tout est vide. Pas de tâches, pas de mémos, pas d'activité dans le feed. C'est un moment critique : soit l'utilisateur comprend quoi faire, soit il ferme l'app.

Les empty states riches sont la solution. Au lieu d'un écran vide avec un message générique ("Aucune tâche"), chaque écran vide contient :

• Une illustration engageante (pas un icon générique)
• Un message actionnable : "Appuie sur le micro pour créer ta première tâche"
• Un CTA direct : un bouton qui lance immédiatement l'action

Le feed vide dit : "Dicte ta première tâche et regarde-la apparaître ici." Le bouton lance directement le dictaphone. En un tap, l'utilisateur est dans l'action.

Les empty states servent de tutoriel implicite. Pas besoin d'un guide de 10 écrans — chaque écran vide explique sa propre fonctionnalité. C'est du coaching in-context, le pattern le plus efficace pour l'apprentissage mobile.

À quel moment demander l'inscription ?

C'est la question stratégique. Trop tôt, tu perds l'utilisateur. Trop tard, tu n'as jamais son email. Le timing est un art délicat.

J'ai identifié 4 moments stratégiques pour rappeler doucement l'inscription :

1. Après la 5ème tâche créée. L'utilisateur a investi du temps. Il a du contenu qu'il ne veut pas perdre. Le rappel dit : "Crée un compte pour sauvegarder tes tâches sur tous tes appareils." La peur de la perte est un levier puissant.

2. Après 3 jours d'utilisation. L'habitude commence à se former. Le rappel est contextuel : "Tu utilises TAMSIV depuis 3 jours — crée un compte pour ne rien perdre."

3. Quand il essaie une feature Pro. Le système d'abonnements nécessite un compte. Le rappel est naturel : "Cette feature est disponible en Pro — crée un compte pour y accéder."

4. Quand il tente de rejoindre un groupe. Les groupes collaboratifs nécessitent une identité. Le rappel est fonctionnel : "Pour rejoindre un groupe, crée un compte pour que tes coéquipiers puissent te reconnaître."

Le point commun : chaque rappel apporte de la valeur. Pas "inscris-toi parce qu'on veut ton email", mais "inscris-toi parce que ça débloque quelque chose pour toi". Jamais intrusif. Toujours contextuel.

Comment migrer un compte anonyme vers un compte réel ?

C'est la partie magique. Supabase permet de lier un compte anonyme à un email sans perdre aucune donnée. Le processus technique :

1. L'utilisateur clique "Créer un compte" (un des rappels contextuels)
2. Il entre son email et un mot de passe
3. Supabase "lie" l'email au compte anonyme existant
4. Le UUID ne change pas
5. Toutes les données (tâches, mémos, préférences) restent intactes
6. Le token JWT est renouvelé avec les infos du compte réel

Pour l'utilisateur, c'est invisible. Il a l'impression de "créer" un compte, mais en réalité il "complète" un compte qui existait déjà. Pas de migration de données, pas de fusion de comptes, pas de perte. C'est magique du point de vue UX.

C'est similaire à ce que fait Firebase Anonymous Auth, mais l'implémentation Supabase est plus propre car le UUID reste identique. Avec Firebase, la migration peut parfois changer l'UID, ce qui casse les références en base.

Quels sont les risques de la lazy registration ?

Ce n'est pas que des avantages. Voici les risques que j'ai identifiés et comment je les gère :

Perte de données si l'app est désinstallée. Un compte anonyme sans email, c'est un compte sans moyen de récupération. Si l'utilisateur désinstalle l'app, tout est perdu. C'est le risque principal, et c'est exactement pourquoi les rappels d'inscription sont importants.

Comptes zombies en base. Beaucoup d'utilisateurs créeront un compte anonyme, essaieront l'app 2 minutes, et ne reviendront jamais. Ça génère des comptes et des données orphelines. J'ai mis en place un nettoyage automatique : les comptes anonymes inactifs depuis plus de 30 jours sont supprimés.

Pas d'email pour le marketing. Sans email, impossible d'envoyer des emails de réengagement, des newsletters, ou des notifications de features. C'est un coût commercial réel de la lazy registration. Le compromis : les utilisateurs qui s'inscrivent sont des utilisateurs convaincus, pas des utilisateurs forcés.

Synchro multi-device impossible. Un compte anonyme ne peut pas se connecter sur un autre appareil. L'utilisateur ne profite pas du système d'auth QR code ni de l'app web tant qu'il n'a pas créé de compte. C'est justement un des leviers de conversion.

Quel impact sur la rétention et les métriques ?

Depuis l'implémentation de la lazy registration, les métriques ont significativement évolué :

• Taux d'exploration : plus de 80% des nouveaux utilisateurs créent au moins une tâche (contre ~40% avec inscription obligatoire)
• Rétention J1 : augmentation significative — les utilisateurs qui ont essayé l'app reviennent plus souvent
• Taux de conversion vers compte réel : environ 35% des utilisateurs finissent par s'inscrire (mais ce sont des utilisateurs engagés)
• Qualité des inscrits : les utilisateurs qui s'inscrivent après avoir essayé l'app ont une rétention J30 bien supérieure à ceux qui s'inscrivaient d'emblée

Le trade-off est clair : moins d'inscriptions, mais des inscriptions de meilleure qualité. C'est un choix délibéré qui s'aligne avec la philosophie de TAMSIV : on préfère des utilisateurs convaincus à des métriques gonflés.

Comment mesurer l'efficacité de l'onboarding ?

Le dashboard admin de TAMSIV suit plusieurs métriques clés :

• Funnel d'onboarding : combien d'utilisateurs voient chaque slide, combien sautent
• Time to first action : combien de temps entre l'ouverture et la première tâche créée
• Conversion anonyme → réel : à quel moment (jour, action) les utilisateurs s'inscrivent
• Taux d'abandon par étape : quel écran fait fuir les utilisateurs

Le "time to first action" est la métrique la plus importante. Plus il est court, plus l'onboarding est efficace. L'objectif est de descendre sous 60 secondes entre le premier lancement et la première tâche créée. Avec le dictaphone vocal, c'est parfaitement atteignable : ouvrir l'app, appuyer sur le micro, parler, c'est fait.

Ce que j'ai appris sur l'UX mobile en tant que dev solo

Construire l'onboarding de TAMSIV m'a appris une leçon fondamentale : en tant que dev solo, chaque friction que tu ajoutes se paie cher. Tu n'as pas le budget marketing de Todoist ou de Notion pour compenser un onboarding médiocre. Chaque utilisateur perdu au moment de l'inscription est un utilisateur que tu n'as pas les moyens de récupérer.

La lazy registration n'est pas juste une technique — c'est une philosophie : fais confiance à ton produit. Si ton app est bonne, les utilisateurs s'inscriront naturellement. Si elle ne l'est pas, forcer l'inscription ne changera rien.

C'est la même logique que j'ai appliquée au système de parrainage : la meilleure acquisition, c'est le bouche-à-oreille d'utilisateurs satisfaits. Et des utilisateurs satisfaits, ça commence par un onboarding qui respecte leur temps.

FAQ

Supabase Anonymous Auth est-il gratuit ?

Oui, Anonymous Auth est inclus dans le plan gratuit de Supabase. Les comptes anonymes comptent comme des utilisateurs normaux dans le quota (50 000 MAU sur le plan gratuit). Les comptes inactifs nettoyés automatiquement n'affectent pas les quotas une fois supprimés.

Les données d'un compte anonyme sont-elles sécurisées ?

Oui. Les mêmes policies RLS (Row Level Security) s'appliquent. Un utilisateur anonyme ne peut accéder qu'à ses propres données. La seule différence : sans email, le compte ne peut pas être récupéré en cas de désinstallation.

Peut-on combiner lazy registration et inscription sociale (Google, Apple) ?

Oui. Supabase permet de lier un compte anonyme à un provider OAuth (Google, Apple, GitHub). Le processus est identique à la liaison par email : le UUID reste le même, les données sont préservées.

Combien de temps garder les comptes anonymes inactifs ?

TAMSIV supprime les comptes anonymes après 30 jours d'inactivité. C'est un équilibre entre laisser le temps à l'utilisateur de revenir et éviter l'accumulation de données orphelines. Les comptes avec du contenu (tâches, mémos) sont conservés plus longtemps.

La lazy registration fonctionne-t-elle pour toutes les apps ?

Non. Les apps qui nécessitent une identité dès le départ (messagerie, réseau social, fintech) ne peuvent pas utiliser ce pattern. Il est idéal pour les apps utilitaires, de productivité, ou de contenu où l'utilisateur peut tirer de la valeur avant de s'identifier.