La Renaissance du logiciel local-first : pourquoi vos applications reviennent sur votre appareil

En 2019, un laboratoire de recherche appelé Ink & Switch a publié un essai décrivant ce qu'il appelait le « local-first software ». Le postulat était simple et les implications significatives : les applications devraient stocker leurs données sur l'appareil de l'utilisateur, fonctionner pleinement sans connexion Internet, et considérer le cloud comme une couche de synchronisation plutôt que comme la source de vérité. La réponse de la communauté des développeurs a été chaleureuse, intellectuellement engagée, et surtout théorique. Les outils pour construire des applications local-first de qualité production n'existaient pas vraiment à l'époque.

Sept ans plus tard, ils existent. ElectricSQL a atteint la version 1.0 en mars 2025, apportant une synchronisation Postgres de production vers SQLite local. Automerge et Yjs — les deux bibliothèques CRDT dominantes — ont considérablement mûri. La conférence Local-First à Berlin a attiré des chercheurs, des startups et des ingénieurs d'entreprises établies. Et l'IA sur appareil a donné à cette approche architecturale une nouvelle raison commerciale d'exister, au-delà de l'idéologie.

Ce que local-first signifie vraiment

Le terme est utilisé de manière vague, il vaut donc la peine d'être précis. Une application local-first stocke ses données principales sur l'appareil de l'utilisateur — dans une base de données locale, sous forme de fichiers bruts, ou dans le stockage du navigateur — et synchronise ces données vers d'autres appareils ou un serveur en tant qu'opération secondaire. L'invariant critique de conception est que l'application fonctionne pleinement sans connexion réseau. Pas « elle affiche des données en cache » — elle fonctionne, lit et écrit, avec l'ensemble des fonctionnalités.

Les sept principes originaux d'Ink & Switch incluent : opérations instantanées sans spinners de chargement, fonctionnalité hors ligne complète, synchronisation transparente entre appareils, collaboration en temps réel, longévité des données (l'application fonctionne même si l'entreprise ferme), sécurité par défaut, et propriété des données utilisateur avec portabilité d'exportation. La plupart des applications cloud-first échouent sur au moins quatre d'entre eux. La plupart des applications local-first construites avec les outils actuels peuvent atteindre les sept.

La technologie qui rend cela possible : les CRDT

La raison pour laquelle la synchronisation local-first était auparavant peu pratique est le conflit de fusion. Si vous éditez un document sur votre téléphone hors ligne, et que quelqu'un d'autre édite le même document sur son ordinateur portable, comment fusionner les deux versions lorsque votre téléphone se reconnecte ? L'approche naïve consiste à choisir une version et à jeter l'autre, ce qui est catastrophique pour la collaboration. L'approche sophistiquée implique des transformations opérationnelles — des algorithmes complexes qui fonctionnent, mais nécessitent un serveur central pour arbitrer.

Les CRDT, ou Conflict-Free Replicated Data Types, résolvent ce problème avec des mathématiques plutôt qu'avec de l'infrastructure. Un CRDT est une structure de données conçue pour que des éditions concurrentes sur plusieurs répliques puissent toujours être fusionnées en un résultat cohérent sans aucun coordinateur central. Les mathématiques garantissent la cohérence éventuelle — toutes les répliques aboutissent au même état — sans jamais avoir besoin d'un serveur pour trancher. Google Docs, Figma et WhatsApp utilisent tous des CRDT pour leurs fonctionnalités de collaboration et de synchronisation entre appareils.

Pour les applications local-first, cela signifie que deux téléphones peuvent éditer le même document entièrement hors ligne, se reconnecter, et arriver automatiquement à un résultat fusionné correct. Le cauchemar des conflits de fusion que les développeurs redoutaient s'avère en pratique largement inexistant pour les scénarios typiques d'édition de documents et de données.

Les outils sont prêts pour la production

Yjs est la référence par défaut de l'industrie pour l'édition collaborative en temps réel de texte. Écrit en JavaScript avec un port rapide en Rust (Yrs), il s'intègre directement avec ProseMirror, Tiptap et CodeMirror — couvrant la majeure partie du paysage des éditeurs de texte enrichi. Si vous avez utilisé un éditeur de documents web au cours des trois dernières années, vous avez probablement utilisé Yjs sans le savoir.

Automerge adopte une approche différente, stockant l'historique complet de chaque changement en tant qu'objet de première classe. Cela le rend plus proche de Git pour les données d'application : vous pouvez brancher, diff, fusionner et appliquer des changements de manière sélective entre répliques. Compilé en WebAssembly pour une utilisation web, il échange une empreinte plus grande contre des capacités historiques plus riches.

ElectricSQL occupe un créneau différent : au lieu de gérer les CRDT directement, il synchronise des sous-ensembles d'une base de données PostgreSQL vers SQLite local sur le client. Pour les équipes utilisant déjà Postgres, c'est le chemin le plus simple vers une architecture local-first — votre base de données existante reste ; vous ajoutez une couche de synchronisation devant elle. La version 1.1, publiée en août 2025, a offert des écritures 102 fois plus rapides et des lectures 73 fois plus rapides par rapport à la version précédente. Elle est en production chez Trigger.dev et gère des millions de mises à jour quotidiennes.

Pourquoi le timing est bon en 2026

Trois forces convergentes stimulent un regain d'intérêt pour l'architecture local-first au-delà de l'idéalisme des développeurs.

Premièrement : l'IA sur appareil. Les Neural processing units délivrant 70+ TOPS sont désormais standard dans les téléphones phares. Les Foundation Models d'Apple exécutent un modèle de langage de 3 milliards de paramètres entièrement sur l'appareil sur iPhone et Mac. Lorsque l'inférence IA se déplace sur l'appareil, les données sur lesquelles elle opère suivent naturellement — vous ne pouvez pas avoir un assistant IA véritablement privé si toutes vos notes et documents résident sur les serveurs d'un fournisseur. L'architecture de données local-first et l'inférence IA locale forment une paire naturelle.

Deuxièmement : la fatigue du cloud et la réglementation de la vie privée. Des années de fuites de données, de politiques opaques d'entraînement de l'IA et d'arrêts de service ont augmenté le coût de la dépendance au cloud dans l'esprit des utilisateurs. La conformité au RGPD, à HIPAA et au CCPA est considérablement simplifiée lorsque les données utilisateur restent sur les appareils des utilisateurs. Les équipes de la santé, du juridique et des services financiers sont de plus en plus attirées par les outils local-first précisément parce qu'ils simplifient le calcul de conformité.

Troisièmement : la performance. L'outil de gestion de projet de Linear — l'un des exemples les plus cités d'architecture local-first — stocke ses données principales dans IndexedDB dans le navigateur et les synchronise en arrière-plan. Chaque action est d'abord une écriture locale. Le résultat est une interface utilisateur qui semble instantanée par rapport aux outils cloud-first qui doivent effectuer un aller-retour vers un serveur à chaque clic. Les équipes décrivent systématiquement Linear comme l'outil de gestion de projet le plus rapide qu'elles aient utilisé. La vitesse, et non la philosophie, est ce qui pousse les utilisateurs à changer.

Le problème du modèle économique, et comment il est résolu

L'objection évidente au logiciel local-first d'un point de vue commercial : si les utilisateurs possèdent leurs données et peuvent les exporter librement, que facturez-vous ? Obsidian, l'application local-first la plus réussie en nombre d'utilisateurs (plus d'un million d'utilisateurs actifs), a répondu clairement. L'application est gratuite et open-source. Les notes sont stockées sous forme de fichiers Markdown bruts que vous possédez entièrement. Obsidian Sync — un module complémentaire optionnel à 4 $ par mois — fournit une synchronisation cryptée entre appareils. Vous payez pour le service, pas pour l'enfermement des données. Le modèle économique fonctionne parce que le produit est excellent, pas parce que les utilisateurs sont piégés.

ElectricSQL et PowerSync ont adopté le modèle open-core : hébergez vous-même le moteur de synchronisation gratuitement, payez pour la version cloud gérée. Linear facture des frais d'abonnement pour les fonctionnalités d'équipe et les intégrations, pas pour la garde des données. Le schéma émerge : les entreprises local-first facturent la commodité, la fiabilité et les fonctionnalités de collaboration — pas la détention de vos données en otage.

L'écosystème est encore tôt selon la mesure de la familiarité des développeurs mainstream. Construire une application local-first de production nécessite de comprendre les CRDT, la sémantique de synchronisation et la résolution de conflits à un niveau que la plupart des développeurs d'applications n'ont pas eu besoin d'atteindre auparavant. Les outils continuent de s'améliorer, mais il y a une raison pour laquelle l'essai d'Ink & Switch comparait l'état du développement local-first en 2025 à React en 2013. La technologie est prête. La documentation et l'expérience développeur rattrapent leur retard.