J'ai supprime l'anonymat de mon app, et c'etait la bonne decision

J'ai passé des semaines à construire un système d'authentification anonyme qui permettait d'utiliser TAMSIV sans compte. C'était élégant, ça marchait bien, et j'en étais fier. Cette semaine, j'ai tout supprimé. Voici pourquoi c'était la bonne décision.

Pourquoi j'ai supprimé l'authentification anonyme

Quand j'ai lancé TAMSIV en alpha, la lazy registration était une évidence. Selon AppsFlyer, 40 à 60% des utilisateurs abandonnent au moment de l'inscription. En supprimant cette friction, je pensais maximiser la rétention. Et ça a fonctionné, pendant un temps.

Mais en production, la réalité est différente. Les comptes anonymes s'accumulaient dans la base de données. Des dizaines de comptes sans email, sans moyen de contact, sans possibilité de récupération. Les métriques du dashboard admin devenaient illisibles : impossible de distinguer un vrai utilisateur d'un curieux qui a ouvert l'app 30 secondes.

Le problème de sécurité était encore plus concret. Un compte anonyme, c'est un compte avec un UUID et des données, mais sans identité vérifiable. Si quelqu'un perdait son téléphone, ses tâches et mémos disparaissaient avec. Pas d'email pour la récupération. Pas de mot de passe pour la protection. Juste un token éphémère sur un appareil.

Comment cette décision a-t-elle simplifié le code ?

[PERSONAL EXPERIENCE] En retirant les sessions anonymes, j'ai supprimé un nombre surprenant de chemins conditionnels dans le code. Plus de if (isAnonymous) dans les services. Plus de logique de migration anonyme vers compte réel. Plus de nettoyage automatique des comptes zombies après 30 jours.

Le commit 7a0101d a touché le flow d'authentification complet. Au premier lancement, l'utilisateur arrive maintenant sur un écran d'inscription ou de connexion. C'est plus simple, plus prévisible, et ça garantit que chaque personne qui utilise l'app a fait un choix délibéré.

Est-ce que ça risque de faire perdre des utilisateurs au moment de l'inscription ? Probablement quelques-uns, oui. Mais ceux qui s'inscrivent sont des utilisateurs engagés. Et c'est exactement le type de métrique qu'on veut suivre en production.

Le bug du flash modal que personne n'avait remarqué

En testant la nouvelle authentification, j'ai découvert un bug vicieux. À chaque lancement de l'app, la modal des conditions générales d'utilisation apparaissait pendant une fraction de seconde avant de disparaître. Un flash rapide, presque subliminal. Le genre de truc que tu ne remarques pas consciemment, mais qui donne une impression de manque de polish.

[ORIGINAL DATA] Le problème venait du timing. L'app chargeait le profil utilisateur depuis Supabase, et pendant ce chargement, le champ terms_accepted était temporairement null. Le composant de la modal interprétait ce null comme "l'utilisateur n'a pas accepté les CGU" et s'affichait. Quelques millisecondes plus tard, le profil arrivait avec terms_accepted: true, et la modal disparaissait.

La solution dans le commit 8979543 : attendre le profil frais de la base de données avant d'évaluer l'état de la modal. Pas de profil chargé = pas de décision = pas de flash. Simple, mais il fallait le trouver. Ce type de bug ne se reproduit pas dans les tests automatisés parce que les mocks retournent le profil instantanément.

Pourquoi bumper une version pour "juste" 3 commits ?

[UNIQUE INSIGHT] En build in public, la tentation est forte de regrouper plein de changements dans une seule release pour qu'elle paraisse impressionnante. J'ai fait l'inverse. Le bump vers la version 1.04 (commit d900d21, versionCode 39) ne contient que ces trois changements. Et c'est volontaire.

Un changement d'authentification, c'est le genre de modification qui peut casser des choses de manière subtile. Un utilisateur qui avait un compte anonyme, que se passe-t-il quand il met à jour l'app ? Les tokens sont-ils invalides ? Le profil est-il accessible ? En isolant ce changement dans une release dédiée, le debugging est simple : si quelque chose casse, je sais exactement où chercher.

Les petites releases fréquentes valent mieux que les grosses releases rares. C'est un principe que j'applique depuis le début de TAMSIV, et qui m'a évité beaucoup de nuits blanches. Chaque build est un snapshot testable. Chaque version déployée a un périmètre clair.

Ce que ça change pour les utilisateurs

En pratique, le changement est minimal pour quelqu'un qui utilisait déjà TAMSIV avec un compte. Rien ne change. Les tâches, les mémos, les groupes, tout reste en place.

Pour les nouveaux utilisateurs, l'expérience est différente mais pas forcément pire. Au lieu d'atterrir directement dans l'app, ils passent par un écran d'inscription. Email, mot de passe, c'est fait. Et à partir de là, leurs données sont sécurisées, synchronisables sur plusieurs appareils, et récupérables en cas de perte du téléphone.

Le système d'authentification QR code pour l'app web fonctionne maintenant pour 100% des utilisateurs, pas seulement ceux qui avaient pris le temps de créer un compte. C'est un gain concret en UX pour la version desktop.

Les leçons d'un dev solo qui change d'avis

Changer d'avis sur une décision technique, c'est inconfortable. J'ai écrit un article entier sur les bénéfices de la lazy registration. Et aujourd'hui je fais l'inverse. C'est embarrassant ? Un peu. Mais c'est aussi la réalité du développement : ce qui est optimal en alpha n'est pas forcément optimal en production.

En alpha, avec 12 testeurs recrutés, l'anonymat réduisait la friction. En production, avec des utilisateurs réels qui s'attendent à ce que leurs données soient en sécurité, l'inscription est un minimum. Le contexte a changé, donc la décision change.

Si tu construis un produit et que tu hésites entre ces deux approches, ma recommandation est simple. En pré-lancement, la lazy registration est géniale pour valider ton produit. En production, l'inscription obligatoire est plus sage. Tu peux toujours offrir un essai gratuit généreux pour compenser la friction.

FAQ

Les utilisateurs anonymes existants perdent-ils leurs données ?

Les comptes anonymes qui avaient été migrés vers des comptes réels (avec email) ne sont pas affectés. Seuls les comptes restés purement anonymes, sans email associé, ne peuvent plus se connecter. Un nettoyage de ces comptes orphelins est prévu.

Est-ce que l'inscription prend longtemps ?

Deux champs : email et mot de passe. Pas de vérification par SMS, pas de captcha, pas de formulaire à rallonge. L'objectif est de rester sous les 30 secondes entre l'ouverture de l'app et la première utilisation.

Le bug du flash modal affectait-il la sécurité ?

Non. C'était un problème purement visuel. La modal des CGU s'affichait brièvement puis disparaissait. Aucune donnée n'était exposée et les conditions restaient bien acceptées en base de données. C'était un défaut de polish, pas de sécurité.