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

En 2019, le laboratoire de recherche Ink & Switch publiait un essai décrivant ce qu'il appelait le « logiciel local-first ». Le principe était simple, et ses implications majeures : les applications doivent stocker leurs données sur l'appareil de l'utilisateur, fonctionner pleinement sans connexion Internet, et traiter le cloud comme une couche de synchronisation plutôt que comme source de vérité. La réponse de la communauté des développeurs a été chaleureuse, intellectuellement engagée et principalement 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 stable en production vers SQLite local. Automerge et Yjs — les deux bibliothèques CRDT dominantes — ont considérablement mûri. La Local-First Conference à Berlin a attiré chercheurs, startups et ingénieurs d'entreprises établies. Et l'IA sur l'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 est donc utile d'être précis. Une application local-first stocke ses données primaires sur l'appareil de l'utilisateur — dans une base de données locale, sous forme de fichiers simples, ou dans le stockage du navigateur — et synchronise ces données vers d'autres appareils ou un serveur en opération secondaire. L'invariant de conception critique 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 indicateurs 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é de l'export. La plupart des applications cloud-first échouent à au moins quatre de ces principes. La plupart des applications local-first construites sur 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 impraticable, ce sont les conflits de fusion. Si vous modifiez un document sur votre téléphone hors ligne, et que quelqu'un d'autre modifie 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 modifications concurrentes sur plusieurs réplicas puissent toujours être fusionnées en un résultat cohérent sans coordinateur central. Les mathématiques garantissent une cohérence éventuelle — tous les réplicas 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 modifier 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 se révèle 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 de l'industrie pour l'édition collaborative de texte en temps réel. Écrit en JavaScript avec un portage 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 ces 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 modification comme un objet de première classe. Cela le rend plus semblable à Git pour les données d'application : vous pouvez créer des branches, comparer, fusionner et appliquer sélectivement des modifications entre réplicas. Compilé en WebAssembly pour une utilisation web, il échange une empreinte plus importante contre des capacités d'historique plus riches.

ElectricSQL occupe un créneau différent : au lieu de gérer directement les CRDT, il synchronise des sous-ensembles d'une base de données PostgreSQL vers SQLite local sur le client. Pour les équipes qui utilisent 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. La version 1.1, publiée en août 2025, offre 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 l'appareil. Les unités de traitement neuronal (NPU) délivrant 70 TOPS ou plus 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 vers l'appareil, les données sur lesquelles elle opère suivent naturellement — vous ne pouvez pas avoir un assistant IA vraiment 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 un tandem naturel.

Deuxièmement : la fatigue du cloud et la réglementation sur la vie privée. Des années de fuites de données, de politiques d'entraînement IA opaques 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 droit 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 Linear — l'un des exemples les plus cités d'architecture local-first — stocke ses données primaires dans IndexedDB dans le navigateur et 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 faire 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, pas 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, pour quoi facturer ? 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 simples 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 le verrouillage 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 abonnements 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 pour prendre vos données en otage.

L'écosystème est encore jeune si l'on considère la familiarité des développeurs traditionnels. 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 à celui de React en 2013. La technologie est prête. La documentation et l'expérience développeur rattrapent leur retard.