Filarr Mobile : ce qu'on a construit cette semaine (graphe, chiffrement, sync, CI)

Cette semaine, la branche mobile de Filarr a reçu 72 commits en deux jours. Vue graphe complète, persistance chiffrée AES-256-GCM avec clé matérielle, 2FA TOTP, fusion desktop-mobile sans doublons, chaîne CI/CD pour Android et iOS. L'app avance vite vers la sortie.

Le thème de la semaine : de "fonctionnel" à "fini"

Il y a un stade dans le développement d'une app mobile où tu te dis "ok, les features principales tournent." Et puis il y a le stade suivant, celui où tu tests vraiment sur un appareil réel, tu listes tout ce qui cloche, et tu passes deux jours à tout corriger. C'est exactement là qu'on est cette semaine.

72 commits entre le 7 et le 9 août sur la branche feat/design-system-desktop. Pas des commits de confort : de la parité desktop sérieuse, de la sécurité embarquée, de la sync rendue robuste, et toute la plomberie pour livrer l'app sur les stores. Voici ce qui s'est passé, thème par thème.

1. Le graphe de notes est là, complet, moteur de forces inclus

La vue graphe, c'était la dernière grande feature manquante sur mobile. Cette semaine, elle a atterri complète : noeuds, liens, simulation de forces avec répulsion et ressorts, réglages de rendu, et les rétroliens calculés localement note par note.

Concrètement : si tu as des centaines de notes liées entre elles dans Filarr sur desktop, tu peux maintenant ouvrir le graphe depuis ton téléphone et voir exactement la même organisation. Les clusters se forment naturellement. Tu peux zoomer, naviguer, voir quels noeuds sont connectés à quoi.

Le moteur reprend la philosophie qu'on a affinée sur desktop pour la v2.1 : répulsion Coulomb, ressorts Hooke, gravité vers le centroïde. Pour ceux qui ont suivi la comparaison Obsidian vs Filarr, le graphe mobile reprend exactement la même simulation de forces que la version desktop.

Les rétroliens sont calculés en local, sans appel réseau. Le graphe fonctionne entièrement hors ligne, ce qui est la cohérence attendue pour une app vraiment local-first.

On a aussi ajouté le filtre par étiquette dans la vue notes, et le filtre par carnet (la même parité que sur desktop). Avec un état vide explicite quand aucune note ne correspond au filtre, pour ne pas laisser l'utilisateur devant un écran blanc muet.

2. L'état de l'app survit au redémarrage, chiffré avec la clé matérielle

Sur desktop, l'état de l'app est chiffré via la FEK (File Encryption Key) dérivée de ton mot de passe. Sur mobile, on avait besoin d'un mécanisme équivalent adapté aux contraintes mobiles. Cette semaine, c'est en place : l'état persisté est chiffré en AES-256-GCM, avec une clé stockée dans le secure enclave de l'appareil (keychain iOS, keystore Android).

Ce que ça change pour toi : si tu ouvres Filarr sans connexion, l'app charge ton coffre tel que tu l'as laissé. Aucune donnée en clair sur le disque. Si quelqu'un accède au stockage de ton téléphone via un backup non chiffré ou un accès physique, il ne voit que des blobs opaques.

On a aussi corrigé au passage un bug sérieux : une simple lecture de note pouvait écraser une écriture concurrente. Ce genre de race condition est silencieux et destructeur. C'est la catégorie de bug qu'on veut absolument régler avant la sortie.

Pour les curieux sur l'architecture de chiffrement, l'article KEK et FEK explique la hiérarchie de clés utilisée sur desktop. Le mobile reprend le même modèle à deux niveaux, adapté aux APIs de sécurité de chaque plateforme.

3. Sécurité : 2FA TOTP, biométrie dédiée, appairage QR

Trois features de sécurité ont atterri cette semaine.

La 2FA TOTP. Le mobile ignorait jusqu'ici le second facteur configuré sur le compte. Ce n'était pas acceptable. Désormais, si tu as activé l'authentification à deux facteurs, le mobile te la demande à la connexion, avec un écran dédié et un jeton de défi détruit après usage (le token ne survit pas au processus).

L'écran de déverrouillage biométrique. Plutôt que d'intégrer la biométrie en douce dans le flux général, on a créé un écran dédié. Ça donne un parcours clair : tu sais exactement à quelle étape tu es et pourquoi l'app te demande ton empreinte ou ton visage.

L'appairage par QR (EF-202). C'est le même protocole que sur desktop, sans risque de faute de frappe. Tu scannes le QR affiché sur l'autre appareil, l'échange de clés ECDH se fait, ta FEK est transférée chiffrée. La clé ne quitte jamais un appareil en clair. Si tu veux comprendre comment ce transfert fonctionne exactement, l'article sur la sync zero-knowledge décrit le mécanisme en détail.

Deux ajouts pratiques supplémentaires : un cache hors-ligne plafonné avec éviction LRU (le mobile garde les fichiers récents localement jusqu'à une limite, supprime les moins récents quand elle est atteinte) ; et la reprise des uploads là où ils s'étaient arrêtés. Plus jamais repartir de zéro si ta connexion coupe en plein transfert.

4. Sync et interopérabilité desktop-mobile : les vraies brèches sont colmatées

La sync entre desktop et mobile reste la partie la plus délicate. Cette semaine, trois corrections majeures.

Vérification du checksum au téléchargement. On vérifie maintenant que sha256(octets) correspond au checksum stocké dans les métadonnées. Sans ça, un fichier corrompu en transit passait silencieusement. Désormais, si les octets ne correspondent pas, l'erreur est explicite.

Fusion des dossiers par nom, pas par ID. Avant, si un dossier desktop et un dossier mobile avaient des IDs différents mais le même nom, ils apparaissaient en double. On apparie maintenant par nom et on fusionne les métadonnées en préservant les champs desktop. Plus de doublons.

Le mobile écrit la famille "v2:". Les dossiers créés sur téléphone arrivent maintenant correctement sur l'ordinateur. Avant, ils restaient côté mobile uniquement. C'est le type de bug qui se voit immédiatement dès qu'on teste sur de vraies machines.

On a aussi corrigé l'affichage de la taille des fichiers d'origine desktop (elle s'affichait chiffrée au lieu de la taille en clair du fichier source) et gravé l'invariant "templates jamais en écriture" dans les docs du notes-bundle pour éviter toute régression future.

5. Parité desktop : cover de note, emoji, couleurs, CSV, markdown

On a comblé une série de manques de parité avec le desktop en une semaine.

Les covers de notes s'affichent maintenant sur mobile, avec le dégradé expo-linear-gradient. L'emoji d'identité d'une note (ou son icône Lucide, ou une image) s'affiche aussi, avec la gestion propre des trois cas d'encodage possibles. La description d'un dossier apparaît sous son titre, comme sur desktop.

Pour les dossiers, on peut maintenant choisir la couleur à la création et changer la couleur d'un dossier existant. Les dossiers appartenant au desktop ont leurs options renommer/recolorer grisées : on ne touche pas à ce que le desktop possède, c'est une règle d'interopérabilité explicite.

L'aperçu CSV/TSV est rendu en tableau natif. Le lecteur de notes gère maintenant les notes de bas de page, les liens wiki, les tableaux GFM, les listes de tâches et la règle horizontale : parité avec le rendu desktop. Et les notes du bureau se lisent enfin correctement via le rendu du JSON TipTap en HTML statique, ce qui était un manque majeur jusqu'ici.

Deux ajouts concrets supplémentaires : la lecture audio et vidéo depuis le coffre (tu ouvres un fichier .mp3 ou .mp4 stocké dans Filarr, il se lit directement) ; et la réception de fichiers depuis une autre application via ACTION_SEND (le classique "partager vers..." d'Android et iOS).

6. Corrections d'interface : la campagne "test sur appareil réel"

On a testé intensivement sur de vrais appareils cette semaine. Résultat : une quinzaine de corrections d'interface.

Le clavier masquait des zones de saisie et des boutons sur 11 surfaces différentes. C'est corrigé partout. La police monospace n'existait pas sur Android, les blocs de code s'affichaient en police variable : c'est réglé. La navigation était cassée sur deux points précis : la flèche retour ramenait toujours à l'Accueil peu importe où tu étais, et l'onglet actif restait bloqué sur son écran profond après navigation. Ces deux bugs sont réglés.

Le fond blanc au chargement d'une note (le flash blanc avant le rendu du contenu), les liens internes morts, le nom du thème illisible sur sa propre vignette, les textes de réglages tronqués, la pastille "AI" présente sans raison, le logo incorrect : tout ça a été corrigé lors de l'audit du dépôt. L'éditeur avait aussi ses feuilles de style codées en dur en français. C'est internationalisé.

7. CI/CD : la chaîne de livraison est posée pour Android et iOS

La partie invisible mais critique : on a mis en place cette semaine la chaîne complète de livraison.

Android. Un pipeline GitHub Actions qui lance les contrôles qualité, génère un SBOM (Software Bill of Materials, pour la transparence des dépendances), signe l'APK avec le keystore de production, et livre sur le Play Store. La signature se fait directement dans la CI, sans passer par EAS Build pour le chemin Android. Les commandes keytool sont documentées en PowerShell depuis le dossier secrets/ pour qu'aucun secret ne traîne dans le dépôt.

iOS. Build sur macos-15 avec Xcode sélectionné manuellement, uniquement sur les pushs vers des branches de release : pas sur chaque push de feature, pour ne pas brûler les minutes macOS. Hors production, on génère une seule ABI pour accélérer les builds.

C'est la fondation sans laquelle on ne peut pas distribuer. Elle est posée.

Et ensuite

L'app mobile est en finalisation. Les grandes features sont là. Ce qui reste : des cycles de test sur appareil, de la correction de bord, et la validation des flux d'onboarding complets (inscription, premier unlock biométrique, sync initiale avec un coffre desktop existant).

On avait annoncé le mobile en tests finaux quand on a passé le cap des 1 000 utilisateurs. On est dans la droite ligne de ce calendrier : sortie prévue dans un à deux mois. Pas une date ferme, mais c'est l'ordre de grandeur.

Prochaine étape concrète : bêta fermée avec un groupe d'utilisateurs desktop déjà actifs. Si tu veux faire partie de ce groupe, surveille les annonces.

Questions fréquentes

L'app mobile sera-t-elle gratuite ? Le local est gratuit, comme sur desktop. La sync cloud (pour accéder à ton coffre sur plusieurs appareils) est incluse dans le plan Solo à 4 euros par mois.

Le chiffrement sera-t-il le même que sur desktop ? Oui. AES-256-GCM par fichier, clé dérivée de ton mot de passe, zéro donnée en clair sur le disque. Le mobile utilise en plus la clé matérielle de l'appareil (secure enclave/keystore) pour chiffrer l'état persisté localement.

Peut-on utiliser le mobile sans compte ? Oui, en mode local uniquement. Tu peux ouvrir ton coffre sans créer de compte ni activer la sync.

Android et iOS sortiront-ils en même temps ? C'est l'objectif. La CI/CD est en place pour les deux plateformes.

Quand sort l'app mobile ? Dans un à deux mois. Les grandes features sont implémentées, il reste les cycles de test et la validation des flux complets.