8 janvier 2026·5 min read

Apps local-first : pourquoi j'y crois pour certains produits

Local-first ne marche pas pour tout. Retour sur Inner Gallery et les vrais cas d'usage où garder les données sur l'appareil change la donne.

TL;DR

Local-first fonctionne très bien pour les apps à données personnelles (photos, notes, journal). Ça devient complexe dès qu'il y a de la collaboration temps réel. Le papier d'Ink & Switch pose les bonnes bases, mais l'implémentation demande des compromis.

Tu ouvres Inner Gallery en mode avion. Tes photos s'affichent instantanément, tu peux les organiser, les chiffrer, créer des albums. Zéro latence, zéro serveur.

J'ai construit Inner Gallery sur ce principe après avoir lu le papier d'Ink & Switch sur le local-first software. Et si les apps fonctionnaient d'abord sur l'appareil, avec le cloud en option ?

Deux ans plus tard, je peux te dire une chose : local-first, c'est fantastique... pour les bonnes apps.

Ce que local-first change vraiment

Latence zéro : Pas d'attente, pas de spinners. Tu tapes, ça réagit. Point.

Privacy by design : Tes données ne quittent jamais ton appareil sauf si tu le décides explicitement.

Résilience : Métro, ascenseur, wifi pourri ? L'app fonctionne parfaitement.

Contrôle total : Tu veux supprimer tes données ? Tu supprimes l'app. Fini.

Inner Gallery illustre ces bénéfices. Tes photos sont chiffrées avec ta clé privée, stockées localement. Apple ne peut pas les voir, je ne peux pas les voir, personne ne peut les voir sauf toi.

Local-first, c'est reprendre le contrôle de ses données. Mais ça coûte en complexité technique et en fonctionnalités collaboratives.

Les apps parfaites pour local-first

Après Inner Gallery et mes expérimentations, j'ai identifié les cas où local-first excelle :

Vaults personnels : gestionnaires de mots de passe, coffres-forts photo, journaux intimes. La confidentialité prime sur tout.

Outils de création : éditeurs de texte, apps de dessin, IDEs. Tu veux que ça réponde instantanément, que ça fonctionne partout.

Apps de quantified self : tracking d'habitudes, mesures de santé, données personnelles. C'est TON corps, ce sont TES données.

Ces apps partagent un point commun : l'utilisateur est propriétaire absolu des données ET les fonctionnalités collaboratives sont secondaires.

Où local-first devient un cauchemar

J'ai testé des prototypes local-first pour d'autres domaines. Résultat : c'est l'enfer.

Réseaux sociaux : Comment faire un feed sans serveur ? Comment modérer ? Comment découvrir du contenu ?

Marketplaces : Comment synchroniser le stock ? Comment gérer les paiements ? Comment éviter la double vente ?

Apps collaboratives : Comment merger les modifications ? Comment gérer les conflits ? Comment notifier les changements ?

Si ton app vit de la collaboration en temps réel ou de la découverte de contenu, local-first va te compliquer la vie pour zéro bénéfice.

Les compromis techniques que tu dois assumer

Synchronisation complexe : Si tu veux synchro multi-appareils, prépare-toi aux CRDTs (Conflict-free Replicated Data Types). C'est passionnant intellectuellement, c'est l'enfer à déboguer.

Espace de stockage : Toutes les données sur l'appareil, ça prend de la place. Inner Gallery stocke les photos en local, ça peut vite monter en GB.

Backup et restauration : Comment l'utilisateur sauvegarde ses données ? iCloud ? Export manuel ? C'est à toi de gérer.

Performance : Recherche dans 10 000 photos locales vs recherche côté serveur optimisé ? Il faut optimiser différemment.

Pour Inner Gallery, le MVP est 100% local. Une sync chiffrée côté client est prévue à terme — les données ne quitteront jamais l'appareil en clair.

Martin Kleppmann avait raison

Martin Kleppmann, chercheur derrière les CRDTs, l'avait prédit : local-first demande de repenser l'architecture from scratch. Tu ne peux pas juste ajouter du local-first à une app existante.

Avec Inner Gallery, j'ai conçu dès le départ pour le local. Core Data pour le stockage, FileManager pour les photos, chiffrement symétrique local. Aucun composant réseau, aucune API, aucun serveur.

Ce choix architectural influence tout : UI (pas de states de loading), UX (aucun message "hors ligne"), business model (pas d'abonnement SaaS possible).

Mes règles pour décider

Tu hésites entre local-first et client-serveur classique ? Je me pose ces questions :

Les données sont-elles personnelles et sensibles ? Si oui, local-first a du sens.
L'app fonctionne-t-elle seule ou en collaboration ? Solo = local-first possible, collab = serveur.
La latence zéro est-elle critique ? Création, édition = oui. Social, e-commerce = non.
As-tu les compétences pour gérer la complexité ? Local-first n'est pas trivial.

Pour Inner Gallery : données ultra-sensibles, usage solo, latence critique, expertise suffisante. Le choix était évident.

Pour Coachy (mon app de coaching avec IA), c'était l'inverse : données moins sensibles, coaching collaboratif, IA côté serveur nécessaire. Architecture classique client-serveur.

Local-first brille pour les apps personnelles et sensibles. Pour le reste, client-serveur reste plus simple et plus adapté.