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

J'ai passe des semaines a construire un systeme d'authentification anonyme qui permettait d'utiliser TAMSIV sans compte. C'etait elegant, ca marchait bien, et j'en etais fier. Cette semaine, j'ai tout supprime. Voici pourquoi c'etait la bonne decision.

Pourquoi j'ai supprime l'authentification anonyme

Quand j'ai lance TAMSIV en alpha, la lazy registration etait une evidence. Selon AppsFlyer, 40 a 60% des utilisateurs abandonnent au moment de l'inscription. En supprimant cette friction, je pensais maximiser la retention. Et ca a fonctionne, pendant un temps.

Mais en production, la realite est differente. Les comptes anonymes s'accumulaient dans la base de donnees. Des dizaines de comptes sans email, sans moyen de contact, sans possibilite de recuperation. Les metriques du dashboard admin devenaient illisibles : impossible de distinguer un vrai utilisateur d'un curieux qui a ouvert l'app 30 secondes.

Le probleme de securite etait encore plus concret. Un compte anonyme, c'est un compte avec un UUID et des donnees, mais sans identite verifiable. Si quelqu'un perdait son telephone, ses taches et memos disparaissaient avec. Pas d'email pour la recuperation. Pas de mot de passe pour la protection. Juste un token ephemere sur un appareil.

Comment cette decision a-t-elle simplifie le code ?

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

Le commit 7a0101d a touche le flow d'authentification complet. Au premier lancement, l'utilisateur arrive maintenant sur un ecran d'inscription ou de connexion. C'est plus simple, plus previsible, et ca garantit que chaque personne qui utilise l'app a fait un choix delibere.

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

Le bug du flash modal que personne n'avait remarque

En testant la nouvelle authentification, j'ai decouvert un bug vicieux. A chaque lancement de l'app, la modal des conditions generales d'utilisation apparaissait pendant une fraction de seconde avant de disparaitre. 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 probleme venait du timing. L'app chargeait le profil utilisateur depuis Supabase, et pendant ce chargement, le champ terms_accepted etait temporairement null. Le composant de la modal interpretait ce null comme "l'utilisateur n'a pas accepte 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 donnees avant d'evaluer l'etat de la modal. Pas de profil charge = pas de decision = pas de flash. Simple, mais il fallait le trouver. Ce type de bug ne se reproduit pas dans les tests automatises parce que les mocks retournent le profil instantanement.

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 maniere subtile. Un utilisateur qui avait un compte anonyme, que se passe-t-il quand il met a jour l'app ? Les tokens sont-ils invalides ? Le profil est-il accessible ? En isolant ce changement dans une release dediee, le debugging est simple : si quelque chose casse, je sais exactement ou chercher.

Les petites releases frequentes valent mieux que les grosses releases rares. C'est un principe que j'applique depuis le debut de TAMSIV, et qui m'a evite beaucoup de nuits blanches. Chaque build est un snapshot testable. Chaque version deployee a un perimetre clair.

Ce que ca change pour les utilisateurs

En pratique, le changement est minimal pour quelqu'un qui utilisait deja TAMSIV avec un compte. Rien ne change. Les taches, les memos, les groupes, tout reste en place.

Pour les nouveaux utilisateurs, l'experience est differente mais pas forcement pire. Au lieu d'atterrir directement dans l'app, ils passent par un ecran d'inscription. Email, mot de passe, c'est fait. Et a partir de la, leurs donnees sont securisees, synchronisables sur plusieurs appareils, et recuperables en cas de perte du telephone.

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

Les lecons d'un dev solo qui change d'avis

Changer d'avis sur une decision technique, c'est inconfortable. J'ai ecrit un article entier sur les benefices de la lazy registration. Et aujourd'hui je fais l'inverse. C'est embarrassant ? Un peu. Mais c'est aussi la realite du developpement : ce qui est optimal en alpha n'est pas forcement optimal en production.

En alpha, avec 12 testeurs recrutes, l'anonymat reduisait la friction. En production, avec des utilisateurs reels qui s'attendent a ce que leurs donnees soient en securite, l'inscription est un minimum. Le contexte a change, donc la decision change.

Si tu construis un produit et que tu hesites entre ces deux approches, ma recommandation est simple. En pre-lancement, la lazy registration est geniale pour valider ton produit. En production, l'inscription obligatoire est plus sage. Tu peux toujours offrir un essai gratuit genereux pour compenser la friction.

FAQ

Les utilisateurs anonymes existants perdent-ils leurs donnees ?

Les comptes anonymes qui avaient ete migres vers des comptes reels (avec email) ne sont pas affectes. Seuls les comptes restes purement anonymes, sans email associe, ne peuvent plus se connecter. Un nettoyage de ces comptes orphelins est prevu.

Est-ce que l'inscription prend longtemps ?

Deux champs : email et mot de passe. Pas de verification par SMS, pas de captcha, pas de formulaire a rallonge. L'objectif est de rester sous les 30 secondes entre l'ouverture de l'app et la premiere utilisation.

Le bug du flash modal affectait-il la securite ?

Non. C'etait un probleme purement visuel. La modal des CGU s'affichait brievement puis disparaissait. Aucune donnee n'etait exposee et les conditions restaient bien acceptees en base de donnees. C'etait un defaut de polish, pas de securite.