Linear m’a plongé dans le local-first rabbit hole

• En utilisant Linear, ma vision du développement d’applications web a profondément changé.
• Linear fonctionne en local-first, offrant une expérience fluide et réactive avec une interaction immédiate sans latence réseau.
• Cette approche donne à chaque client une base de données indépendante et synchronise les changements avec le serveur de manière asynchrone.
• Toutefois, la mise en œuvre est complexe, notamment pour la synchronisation distribuée, la résolution de conflits et la gestion hors ligne.
• Des solutions variées de l’écosystème local-first comme Jazz, Electric SQL et Zero apparaissent, avec une amélioration progressive de l’expérience développeur.

---

Aperçu

Après avoir utilisé Linear, un outil de gestion de projets, j’ai été fortement inspiré par la vitesse et l’expérience utilisateur remarquables de l’approche local-first. Ce qui était frappant, c’est de ne plus sentir des problèmes courants d’applications web comme la latence réseau, les états de chargement ou les rafraîchissements de page. Grâce à cette expérience, j’ai plongé en profondeur dans les principes techniques et les cas d’application concrets du paradigme local-first.

La plongée dans le trou du lapin

En analysant les dessous techniques de Linear, j’ai découvert qu’ils utilisent l’IndexedDB du navigateur comme une véritable base de données. Toutes les modifications sont d’abord traitées immédiatement en local, puis synchronisées en arrière-plan via GraphQL et Websockets.

• Le terme local-first peut être compris de différentes manières : comme une stratégie UX (réactivité immédiate) ou comme une philosophie consistant à conserver et synchroniser les données localement.
• Dans les applications web traditionnelles, le serveur était la source unique de vérité, mais dans une architecture local-first, chaque client possède sa propre base de données.
• En rapprochant la base de données de l’utilisateur, la latence réseau est éliminée des interactions utilisateur.

Le défi : ce n’est pas trivial

En essayant d’implémenter directement l’approche de Linear, j’ai compris que la complexité est conséquente.

• Gestion de la transition hors ligne/ligne.
• Résolution des conflits entre clients distribués.
• Synchronisation partielle (conçue pour ne pas télécharger l’intégralité des données).
• Migration de schéma des données en cache.
• Sécurité et contrôle d’accès en environnement distribué.
• Ces domaines demandent une quantité considérable de temps et d’efforts d’ingénierie.

L’écosystème local-first en 2025

Au vu des standards de 2025, plusieurs solutions puissantes émergent dans l’écosystème local-first.

• Electric SQL : moteur de synchronisation basé sur Postgres
• PowerSync : solution orientée entreprise
• Jazz : outil pour construire des applications local-first facilement
• Replicache : solution historique majeure (développement arrêté)
• Zero : nouvelle orientation de l’équipe Replicache
• Triplit : synchronisation basée sur TripleStore
• Instant : mise en avant de l’expérience développeur
• LiveStore : fournit une couche de synchronisation temps réel

Approfondissement : Jazz

Jazz attire l’attention par sa promesse unique : « rendre la création d’applications local-first aussi simple que la mise à jour d’un état ».

Le modèle mental

Jazz introduit une structure de collaboration en temps réel appelée Collaborative Values (CoValues).

• Définir un schéma avec Jazz et Zod : cette définition ne se limite pas à un type simple, mais agit comme un objet actif synchronisé automatiquement.
• Sans route API dédiée, logique requête/réponse ou DTO, il suffit de modifier l’état d’un objet pour que la synchronisation se fasse automatiquement.

Comment Jazz y parvient

L’architecture interne de Jazz se résume à :

• Garantie d’unicité : attribution automatique d’un identifiant unique à chaque donnée.
• Event sourcing : conservation de l’historique des modifications sous forme d’événements, pour améliorer l’efficacité de la synchronisation temps réel.
• Chiffrement de bout en bout : chiffrement des données côté client avant la synchronisation. Le serveur ne voit que des blobs chiffrés.
• Conception des autorisations basée sur les groupes : droits d’accès par groupe au lieu d’ACL traditionnelles, avec une distinction claire de la propriété.

Les compromis

Cette architecture est très productive pour le prototypage et le développement rapide d’interfaces, mais certains aspects doivent être pris en compte.

Le serveur est aveugle

Avec le chiffrement de bout en bout, le serveur ne peut pas lire les données des utilisateurs. Si les données auxquelles le serveur doit absolument avoir accès ne sont pas définies au préalable, cela limite la supervision et la prévention du stockage malveillant.

Le voyage dans le temps est obligatoire

L’event sourcing stocke en permanence tout l’historique des changements. Cela rend l’Undo/Redo très pratique, mais la suppression peut devenir difficile à implémenter lorsque l’on doit respecter des contraintes légales telles que le GDPR.

Le stockage prend de l’ampleur

Comme les suppressions ne sont pas appliquées, l’empreinte mémoire augmente progressivement. Cela convient aux petits projets, mais dans un SaaS à grande échelle, le coût de stockage peut grimper fortement.

Le développement local a encore des limites

L’authentification repose sur les Passkeys par défaut ; en auto-développement ou en local, on rencontre encore quelques frictions, notamment pour HTTPS, la gestion des certificats et la migration des clés. Une amélioration est toutefois prévue avec notamment l’intégration de Better Auth.

Mais honnêtement ? Cela vaut le coup

Malgré ces contraintes, l’expérience développeur et la productivité de Jazz restent très impressionnantes. Bien que la solution soit encore à ses débuts, de plus en plus de problèmes devraient se résorber progressivement.

Exploration : Electric SQL et Zero

Contrairement à Jazz, Electric SQL et Zero adoptent une approche incrémentale.

• Il est possible d’utiliser les tables Postgres existantes telles quelles.
• Electric SQL permet de synchroniser l’UI en s’abonnant à une partie d’une table via une reactive query (Shape).
• La manière de gérer les mutations diffère de celle de Jazz, avec des options variées, notamment l’intégration avec LiveStore.
• Zero ressemble à Electric, mais dispose d’un support intégré pour la synchronisation des changements.

Quand le local-first est-il pertinent ?

L’auteur résume ci-dessous les situations où le paradigme local-first est adapté et celles où il est plus difficile à appliquer.

Adapté :

• Outils de création (design, écriture, musique, etc.)
• Applications collaboratives
• Applications mobiles nécessitant un mode hors ligne
• Outils pour développeurs
• Applications de productivité personnelle

Défiant :

• Logique métier serveur à grande échelle
• Exigences strictes de contrôle d’audit
• Systèmes d’analyse de gros volumes
• Systèmes profondément intégrés
• Systèmes qui refusent fréquemment les requêtes côté serveur

Perspectives

Le local-first représente un véritable changement de paradigme dans le développement web. Linear a déjà prouvé un avantage utilisateur significatif. Le développeur doit déterminer si ces compromis structurels conviennent à son projet.

En créant une application personnelle avec Jazz, l’auteur est en train d’expérimenter directement les vrais avantages et les limites de l’abstraction. L’écosystème en est encore au stade initial, et les outils ainsi que les patterns devraient se renforcer avec le temps. Néanmoins, les avantages de conserver les données localement sont clairs et ne devraient pas disparaître.

Si l’on peut accepter les contraintes dans un nouveau projet, il y a suffisamment de valeur à tester le local-first. Dans le pire des cas, on se forme à un nouveau pattern d’architecture ; dans le meilleur, on peut offrir une expérience utilisateur quasi impossible à ralentir. Dans la course à la réactivité autour des 300 ms, c’est un avantage majeur.