Journal Le pari du local-first pour une application de gestion locative (et pourquoi la version Linux est gratuite)

Le contexte

Je développe seul, en Flutter, une application de gestion locative destinée aux
bailleurs privés français : baux, quittances, états des lieux, indexation IRL,
suivi des diagnostics, moteur fiscal. Rien de très sexy pour un public LinuxFr,
je vous l'accorde — mais un choix d'architecture qui, lui, mérite peut-être d'être
discuté ici : le local-first intégral, sans cloud du tout.

Je poste ce journal en toute transparence : je suis l'éditeur de l'app, elle est
payante sur certaines plateformes, et gratuite sur Linux. J'explique pourquoi
plus bas. Je ne suis pas là pour vendre quoi que ce soit — la version qui vous
concerne ne coûte rien — mais pour exposer des choix techniques et entendre vos
critiques, qui sont généralement plus utiles que n'importe quel retour utilisateur.

Le choix local-first

La quasi-totalité des solutions concurrentes sont des SaaS : vos données de
locataires, vos baux, vos montants de loyer partent sur des serveurs tiers, avec
un abonnement mensuel à la clé. J'ai fait le pari inverse : toutes les données
restent sur la machine de l'utilisateur, chiffrées, sans compte et sans serveur.

Concrètement :

• Stockage local via Hive (base clé-valeur en Dart), boîtes chiffrées en AES-256.
• La clé de chiffrement est dérivée du secret utilisateur via Argon2id, pas stockée en clair.
• Aucune télémétrie, aucun appel réseau pour les données métier. La seule requête sortante est la récupération d'un petit JSON de barèmes fiscaux au démarrage (pour éviter de republier l'app à chaque changement de taux) — et encore, l'app fonctionne sans.
• Les indices INSEE (IRL notamment) sont embarqués dans l'app, pas récupérés en ligne.

La question du multi-appareils

C'est LA difficulté du local-first : sans cloud, comment synchroniser entre le
téléphone et l'ordinateur ? Mon choix a été de ne pas synchroniser
automatiquement, mais de laisser l'utilisateur exporter/importer des sauvegardes
chiffrées, sur le support de son choix (clé USB, son propre cloud, peu importe —
c'est lui qui décide où vont ses données, pas moi). Moins magique qu'une sync
transparente, mais cohérent avec la promesse : je ne veux à aucun moment être un
intermédiaire technique entre l'utilisateur et ses données.

Je suis preneur de retours sur ce point : est-ce un compromis acceptable, ou une
béquille ? Des approches type CRDT sur transport chiffré de bout en bout m'ont
traversé l'esprit, mais la complexité me semblait disproportionnée pour le besoin.

Pourquoi Linux est gratuit

Deux raisons, honnêtes :

1. La cible « bailleur privé sous Linux » est trop petite pour qu'un prix ait un sens économique. Autant l'offrir.
2. C'est cohérent avec l'esprit de l'app : si je prône la maîtrise de ses propres données, distribuer librement sur la plateforme qui incarne le mieux cette valeur me paraît la moindre des choses.

La distribution se fait en .deb et en tar.gz (x86_64). Je me pose la
question du Flatpak : est-ce que ça vaut le coup pour une app de cette nature,
ou est-ce que le .deb + tarball suffisent à couvrir l'essentiel des usages ? Vos
avis m'intéressent.

Et l'open source ?

Question légitime, et je préfère être franc : je n'ai pas de position
définitive. Le cœur fiscal représente un travail considérable et c'est aussi mon
gagne-pain sur les autres plateformes ; ouvrir l'intégralité du code poserait des
questions que je n'ai pas encore tranchées. Je ne promets rien, ni dans un sens ni
dans l'autre. Je sais que ce n'est pas la réponse que certains attendent ici, mais
je préfère l'honnêteté à une promesse que je ne tiendrais pas.

Transparence sur la rédaction

Ce journal a été rédigé avec l'aide d'une IA (comme une partie de mon travail de
développement, d'ailleurs), puis relu et validé par moi. Je le mentionne parce que
je préfère le dire que le cacher.

Voilà. Je prends les critiques — sur l'archi, sur les choix de distribution, sur le
modèle. Et si vous trouvez des bugs sur la version Linux, je suis tout ouïe.