Pas de compte, pas de mot de passe : pourquoi mes applications n'ont pas d'écran de connexion

Granyn, Hydrame, Subly, Stocky, Mintly, OldSchool — six applications, six métiers différents, et aucune ne vous a jamais montré un formulaire d’inscription. Pas de champ e-mail, pas de règles de mot de passe, pas d’e-mail “vérifiez votre compte” qui traîne, non lu, dans un dossier spam. Vous ouvrez l’application et ça fonctionne.

Ce n’est pas un oubli. C’est le point de départ par défaut de chaque application que je construis, et je dois activement m’en dissuader lorsqu’une fonctionnalité semble en réclamer un.

Le défaut que personne ne remet en question

La création de compte est devenue le premier écran de presque toutes les applications, y compris beaucoup qui n’ont aucune raison réelle d’en demander un. Un traqueur de garde-manger n’a pas besoin de savoir qui vous êtes pour se souvenir que vous n’avez plus d’œufs. Une application de budget n’a pas besoin de votre e-mail pour catégoriser un achat de café. À un moment donné, “inscrivez-vous d’abord” a cessé d’être un choix délibéré pour devenir un réflexe chez les développeurs — copier le modèle, brancher l’authentification, livrer.

Le coût de ce défaut retombe entièrement sur l’utilisateur, avant même qu’il ait vu une seule fonctionnalité : un mot de passe à inventer, un captcha à résoudre, un e-mail à confirmer, parfois un numéro de téléphone pour la “vérification”. C’est une friction réelle, facturée d’avance, sur chaque installation, pour une valeur nulle.

Ce qu’un compte rapporte réellement — et à qui

Soyons honnêtes sur l’échange : un compte profite surtout au développeur, pas à l’utilisateur. Il vous donne un identifiant stable autour duquel construire des statistiques, un levier pour relancer les gens par e-mail, et un moyen de justifier un abonnement lié à “vos données, dans notre cloud”. Rien de tout cela n’est intrinsèquement mauvais, mais rien n’est gratuit non plus.

Ce que ça vous coûte en retour : un serveur qui stocke des données personnelles, une base de données devenue une cible de fuite, un flux de réinitialisation de mot de passe à construire et à maintenir, et une boîte de support qui se remplit de tickets “j’ai oublié mon mot de passe” et “pouvez-vous supprimer mon compte”. Pour un développeur solo, ce n’est pas un détail — c’est une seconde application entière qui tourne à côté de celle que les gens voulaient réellement.

Ce que le local-first met à la place

Au lieu d’un compte, chaque application traite l’appareil comme le compte. Les données vivent dans une base SQLite locale via Room, dès le premier lancement. Il n’y a rien à quoi se connecter parce qu’il n’y a rien sur un serveur qui attend d’être réclamé.

La sauvegarde et la restauration existent toujours — elles n’ont simplement pas besoin d’un nom d’utilisateur pour cela. Sur Android, cela signifie l’export/import via le Storage Access Framework pour un fichier portable que vous contrôlez, plus Auto Backup for App Data comme filet de sécurité qui ne vous demande pas d’y penser. Si votre téléphone tombe en panne, vous restaurez à partir de ce fichier, pas d’un mot de passe que vous êtes censé vous rappeler dix-huit mois plus tard.

Granyn est le cas le plus clair. C’est une application de budget — la catégorie d’application à laquelle les gens sont le plus réticents à confier une connexion, parce qu’un compte de budget implique un serveur qui connaît vos revenus et vos habitudes de dépense. Granyn ne demande jamais, parce qu’elle n’a jamais besoin de savoir qui vous êtes, seulement ce que vous avez dépensé.

OldSchool illustre le même point sous un autre angle : ce sont des données médicamenteuses, parmi les plus sensibles qui soient. La bonne quantité d’infrastructure pour suivre si vous avez pris un comprimé, c’est zéro — pas de serveur, pas de connexion, pas de tiers susceptible d’être piraté.

Le compromis honnête

Ce n’est pas gratuit. Pas de compte signifie pas de synchronisation automatique entre deux téléphones. Si vous changez d’appareil, vous exportez et importez manuellement — une étape supplémentaire, délibérée, plutôt qu’une synchronisation invisible en arrière-plan qu’il faudrait faire confiance à un serveur pour gérer correctement. Cela signifie aussi qu’il n’y a pas de moment “j’ai perdu mon téléphone, je me connecte depuis un nouveau et tout revient”. Le fichier de sauvegarde est le compte, et le perdre sans sauvegarde signifie perdre les données.

Je pense que ce compromis en vaut la peine pour ce que font ces six applications. Aucune n’est collaborative — personne n’a besoin de partager un inventaire de garde-manger avec un inconnu, ou un journal d’hydratation avec une équipe. Si une fonctionnalité nécessite réellement que plusieurs personnes voient les mêmes données en temps réel, c’est le point où un compte commence à justifier son coût. Je n’ai atteint ce point avec aucune des six pour l’instant.

Où se situe réellement la limite

La règle que j’utilise est simple : si une fonctionnalité peut fonctionner sans savoir qui vous êtes, elle n’a pas le droit de le demander. Un écran de connexion n’est pas un réglage par défaut — c’est un compromis spécifique qu’une fonctionnalité spécifique doit justifier, en échange de quelque chose que l’utilisateur peut ressentir : synchronisation, partage, ou un service qui ne peut vraiment pas fonctionner sur l’appareil. En l’absence de cela, la réponse honnête à “pourquoi n’y a-t-il pas d’inscription” est qu’il n’y a jamais eu de bonne raison d’en construire une.