Les logiciels local-first (2019)

 (inkandswitch.com)
2 points par GN⁺ 2025-07-06 | 1 commentaires | Partager sur WhatsApp
  • Les logiciels local-first sont une approche qui vise à réunir à la fois les avantages de la collaboration basée sur le cloud et ceux de la propriété des données personnelles
  • Les applications cloud existantes excellent en collaboration en temps réel et accessibilité, mais posent des problèmes comme la propriété des données et l’accès à long terme
  • Les logiciels local-first considèrent le stockage local comme l’emplacement principal des données, et ajoutent ensuite des fonctions de synchronisation et de collaboration
  • Ce type de logiciel offre des avantages en matière de rapidité, prise en charge hors ligne, confidentialité et contrôle utilisateur, mais présente aussi une forte complexité de mise en œuvre pour la collaboration en temps réel ou la synchronisation multi-appareils
  • Pour concrétiser cette vision, divers modèles technologiques existants sont comparés et analysés, tandis que l’on explore la possibilité de développer à l’avenir des modèles plus idéaux

Les limites des applications cloud et de la propriété des données

  • La plupart des utilisateurs se servent de diverses applications cloud comme Google Docs, Figma ou Slack pour rédiger des documents, concevoir et collaborer
  • Ces services sont accessibles via un navigateur ou une application mobile, et stockent généralement les données sur un serveur
  • Les logiciels basés sur le cloud offrent les avantages de la collaboration et de l’accès aux données depuis n’importe où, mais plus on investit de temps dans l’application, plus la valeur des données qu’elle contient augmente
  • Des entretiens avec des experts ont confirmé qu’au-delà des avantages fonctionnels des applications cloud, il existe des défauts majeurs comme la perte de propriété et l’incertitude sur l’accès à long terme
  • Le fait que le droit de conserver et posséder les contenus et données créés ou produits directement par l’utilisateur soit limité engendre à la fois une anxiété psychologique et des risques concrets

Ce que signifie réellement posséder ses données

  • Les données stockées dans le cloud semblent être « à soi », mais en pratique, le contrôle de gestion et d’accès appartient au fournisseur de service cloud
  • En cas d’arrêt du service ou de panne serveur, cela peut entraîner l’impossibilité d’accéder aux données ainsi que des difficultés pour leur conservation à long terme
  • Le cœur du problème n’est pas tant la propriété intellectuelle au sens strict, mais le sentiment de possession et de contrôle des données ressenti par l’utilisateur
  • Les anciennes applications centrées sur le stockage local (éditeurs de texte, gestion de versions, divers outils) garantissaient une propriété complète des données et une réelle autonomie

Comparaison des avantages et inconvénients du cloud et du local

  • « application cloud = collaboration et accessibilité », « application locale = propriété et autonomie »
  • Il faut viser la meilleure combinaison de ces deux approches plutôt que de les opposer dans un choix binaire
  • La propriété des données et la collaboration en temps réel ne sont pas nécessairement incompatibles, et il est possible de concevoir un modèle logiciel qui réalise les deux
  • Cette approche est définie comme le logiciel local-first, avec comme structure de base une combinaison de stockage local, de réseau et de serveurs auxiliaires

Les 7 idéaux du logiciel local-first

  • Dans les applications cloud, le serveur joue le rôle de « copie maîtresse » des données, ce qui impose un aller-retour vers le serveur à chaque requête et provoque une latence dans l’expérience utilisateur
  • À l’inverse, les logiciels local-first traitent la copie du stockage local comme la version principale des données, la synchronisation (via le serveur) n’étant qu’un mécanisme secondaire
  • Ce changement de perspective apporte des avantages concrets en matière de rapidité de réponse, de fonctionnement hors ligne et de contrôle des données

1. Rapidité (réactivité)

  • Une application local-first traite toutes les opérations dans le système de fichiers local, ce qui permet une réactivité immédiate sans attendre les délais liés aux requêtes serveur
  • La synchronisation se fait silencieusement en arrière-plan, sans jamais interrompre l’expérience utilisateur

2. Synchronisation multi-appareils

  • Les utilisateurs modernes travaillent sur plusieurs appareils ; une application local-first doit donc elle aussi assurer la synchronisation des données entre appareils
  • La synchronisation au niveau des fichiers est simple pour un utilisateur seul, mais en cas d’édition simultanée par plusieurs personnes, des problèmes de conflit apparaissent

3. Priorité au hors ligne

  • Les logiciels local-first permettent de créer et modifier des données à tout moment hors ligne, puis de synchroniser automatiquement lors du retour du réseau
  • Le partage et la synchronisation des données entre appareils peuvent aussi se faire par Bluetooth, Wi‑Fi local et d’autres moyens
  • Pour un véritable support hors ligne, on privilégie la forme d’un exécutable installé en local

4. Collaboration et gestion des conflits

  • Les approches traditionnelles (pièces jointes par e-mail, outils de gestion de versions, etc.) sont peu pratiques quand plusieurs personnes travaillent en même temps sur le même fichier, en raison des conflits et des fusions manuelles
  • Les applications cloud (comme Google Docs) réduisent fortement la difficulté et les frictions de la collaboration grâce à l’édition collaborative en temps réel
  • Les logiciels local-first ont eux aussi le potentiel de mettre en œuvre la collaboration en temps réel, les suggestions de modification, les validations et d’autres workflows collaboratifs, même si cela reste un défi technique

5. Conservation à long terme des données

  • Avec une application local-first, l’accès aux données reste garanti même si l’éditeur du logiciel disparaît
  • Les formats de fichiers courants (texte, PDF, JPEG, etc.) peuvent rester compatibles longtemps, et même pour les formats devenus incompatibles, il est possible d’y accéder via une machine virtuelle ou un émulateur
  • Sans véritable conservation à long terme des données, le risque d’un âge sombre numérique — où les humains du futur ne pourraient plus accéder ni interpréter les données d’aujourd’hui — pourrait devenir réel

6. Confidentialité et sécurité

  • Une architecture cloud centralisée est vulnérable à divers incidents de sécurité, comme le piratage ou les abus internes
  • Les professionnels qui manipulent des données personnelles ou sensibles peuvent, avec une architecture local-first, renforcer leur sécurité et leur indépendance grâce au chiffrement de bout en bout
  • Les grandes entreprises comme Google peuvent exploiter les données internes de multiples façons, tandis que les logiciels local-first redonnent le contrôle au détenteur des données

7. Propriété et contrôle par l’utilisateur

  • L’accès aux données peut être bloqué ou restreint arbitrairement par un fournisseur de service cloud (faux signalement automatisé, changement de politique, etc.)
  • Dans un environnement local-first, c’est l’utilisateur qui décide directement de l’usage, de la modification, de la sauvegarde et de la conservation de ses données
  • Il ne s’agit pas seulement de droit d’auteur au sens juridique, mais bien de l’autonomie réelle de l’utilisateur et de son contrôle sur les données

Comparaison de différents modèles logiciels

  • Pièces jointes d’e-mail + fichiers locaux : excellents pour la rapidité, le hors ligne, la conservation à long terme et le contrôle, mais peu pratiques pour la collaboration et la synchronisation entre appareils
  • Applications web cloud (Google Docs, Trello, etc.) : excellentes pour la collaboration en temps réel et l’accessibilité, mais faibles sur la rapidité, le hors ligne, la propriété et la confidentialité
  • Services de synchronisation de fichiers (Dropbox, etc.) : très bons pour la rapidité, le hors ligne, la conservation à long terme et le contrôle, mais limités pour la collaboration et sur mobile
  • Systèmes de gestion de versions (Git, etc.) : excellents pour la rapidité, le hors ligne, la conservation à long terme et le contrôle, mais moins adaptés aux fichiers non textuels et à la collaboration en temps réel
  • Clients mobiles (Firebase, CloudKit, etc.) : solides sur la synchronisation et le hors ligne, mais limités en matière de données personnelles, de confidentialité et de pérennité du service
  • Réplication multi-maître (bases de données, par ex. CouchDB) : forte sur le hors ligne et la synchronisation, mais difficile ou insuffisante pour réaliser pleinement les idéaux de collaboration, de confidentialité et de contrôle

Point de vue des développeurs et orientations futures

  • Un logiciel local-first idéal doit intégrer dès le départ la conception et l’implémentation du hors ligne, de la synchronisation multi-appareils, de la collaboration en temps réel, de la confidentialité et du contrôle utilisateur
  • Mais en pratique, il n’existe pas encore de technologie ouverte capable de satisfaire simultanément tous ces idéaux
  • Les nouvelles techniques issues de la recherche récente en informatique — par exemple les Conflict-free Replicated Data Types (CRDTs) et les méthodes de synchronisation de données distribuées — pourraient constituer la base essentielle des futurs logiciels local-first

Conclusion

  • Les logiciels local-first représentent une orientation importante pour équilibrer collaboration, indépendance, confidentialité et souveraineté des données à l’ère numérique
  • Ils peuvent offrir aux experts, créateurs et autres professionnels un sentiment de propriété sur leurs données ainsi qu’une protection à long terme, tout en ouvrant la voie à des changements positifs dans l’ensemble des secteurs
  • À l’avenir, il sera nécessaire de poursuivre la recherche et l’expérimentation autour de meilleures infrastructures, outils de développement, architectures et algorithmes capables de concrétiser cet idéal

À lire aussi

1 commentaires

 
GN⁺ 2025-07-06
Avis sur Hacker News

  • Je suis totalement d’accord, à 100 %. Je travaille moi aussi sur ce problème, et j’en ai assez du modèle où l’on met ses données dans le cloud pour ne faire que payer un abonnement. En ce moment, je développe une app de suivi fitness, avec l’intention d’appliquer le modèle de Sublime : achat unique au départ, mises à jour pendant quelques années, synchronisation sur tous les appareils, utilisation à vie. Ensuite, si l’on veut de nouvelles mises à jour, il suffit de racheter une nouvelle version. L’objectif est qu’elle soit d’une qualité suffisante pour pouvoir continuer à l’utiliser telle quelle. C’est le modèle que je voudrais pour 90 % des logiciels. Il faut pouvoir acheter à un prix juste, avoir un produit excellent, et qu’il fonctionne correctement même sans intégration cloud. Au-delà de la confidentialité des données, ce modèle a beaucoup d’avantages. Il reste encore des défis, notamment côté tooling, mais les bases techniques sont déjà là. Le plus grand avantage du logiciel local-first, c’est une structure d’incitations saine. La récompense ne vient pas de la pub, du suivi des utilisateurs ou de la maximisation de l’« engagement », mais du produit lui-même. On a l’impression d’un logiciel vraiment centré sur l’utilisateur.

    • Le modèle d’Obsidian pour la prise de notes est aussi un très bon exemple. Le client est gratuit, et le service de synchronisation est vendu en option. Gros point fort : les notes sont des fichiers Markdown, donc on n’a même pas absolument besoin du client.

    • Je serais curieux de savoir comment tu comptes gérer la synchronisation sans utiliser d’infrastructure cloud.

    • Entièrement d’accord. Si ça ne te dérange pas, je serais aussi curieux d’en savoir plus sur la stack technique de ton app de fitness tracking, surtout sur la manière dont tu gères la synchronisation entre appareils.

    • Il existe aussi beaucoup d’apps purement locales qui se monétisent par la publicité, donc « pas de pub » n’est pas toujours vrai.

  • En ce moment à Berlin, la conférence Local-first Software (https://www.localfirstconf.com/) organisée par Ink and Switch est très active, et une autre conférence, Sync Conf (https://syncconf.dev/), a même vu le jour cette année en novembre à San Francisco. Lors d’une conférence récente, les co-auteurs de l’article ont eux-mêmes participé à une table ronde, ce qui était très instructif pour comprendre ce qu’ils ont appris dans le contexte des outils de développement pour le logiciel local-first. Je recommande vivement la vidéo de la table ronde. Dans la communauté, « Sync » est en train de s’imposer comme un élément central du local-first, et les dev tools comme les moteurs de synchronisation sont plutôt vus comme des outils de support pour implémenter les propriétés du local-first, sans être eux-mêmes du local-first. Une compilation complète des talks de ces dernières années a aussi été mise en ligne ici. Le développement d’outils pour la collaboration temps réel et asynchrone progresse très vite, et l’arrivée récente de l’IA crée un marché où ces moteurs de synchronisation deviennent de plus en plus nécessaires. Les apps d’IA sont par nature des environnements collaboratifs multi-utilisateurs, ce qui rend indispensables les bases techniques construites par la communauté des moteurs de synchronisation.

  • Il y a déjà eu par le passé des discussions très animées sur ce sujet, donc cela vaut le coup de les lire si ça vous intéresse : 2019-05, 191 commentaires
    2019-11, 241 commentaires
    2020-07, 9 commentaires
    2020-08, 134 commentaires
    2021-02, 90 commentaires
    2022-06, 30 commentaires
    2023-10, 50 commentaires

  • Je soutiens l’idée que chaque app n’a pas besoin de sa propre plateforme de sync. Cette tendance semble venir de la difficulté, propre aux apps mobiles, à combiner et modulariser différents programmes. Si l’on veut du vrai local-first, il suffit d’utiliser le système de fichiers. Côté utilisateur, on peut alors choisir soi-même parmi des solutions existantes comme git, box, etc. La procédure d’inscription à la sync propre à chaque app est presque aussi opaque et fragile qu’un SaaS, donc c’est une vraie charge.

    • Je suis d’accord sur le fait que toutes les apps n’ont pas besoin d’un moteur de sync, mais je ne pense pas que le système de fichiers soit une solution miracle au local-first. Pour deux raisons. La première, c’est la concurrence d’accès. Si on veut juste du strict local-first, alors n’importe quelle sync peut convenir, mais on peut vouloir plus que ça. Par exemple, je veux une expérience où ma femme et moi pouvons modifier chacun de notre côté sur nos téléphones, même sans communication réseau, et que tout se fusionne automatiquement proprement ensuite. Quelque chose d’aussi naturel que DropBox. La deuxième raison, c’est qu’un moteur de synchronisation doit comprendre en profondeur la structure et la sémantique des données pour offrir une meilleure expérience de sync. git ou box ont plusieurs limites face à ce besoin d’édition concurrente sémantique.

    • J’ai déjà essayé d’implémenter une approche reposant uniquement sur le système de fichiers, mais il est difficile de coordonner entre clients le moment où l’édition d’un fichier doit être autorisée, donc les conflits de fichiers deviennent inévitables.

  • Tout système dépendant d’une connexion en ligne entraîne inévitablement des coûts de maintenance et d’exploitation. Sans architecture local-first ou local-only, il est impossible d’avoir un système fiable sur le long terme. Les appareils connectés et les voitures connectées sont, du point de vue pratique, de parfaits exemples d’ingénierie absurde.

    • Tout cela vient au fond des revenus par abonnement. Les entreprises avec un modèle d’abonnement génèrent plus de chiffre d’affaires, lèvent plus facilement des fonds, et gagnent sur le marché face à celles qui ne l’ont pas. C’est précisément pour cela que le logiciel local-first a disparu.

  • Je suis au contraire critique envers l’idée de traiter techniquement le problème de fiabilité du cloud, par exemple en évitant les architectures centralisées. Par le passé, les problèmes de manque de contrôle et de confiance liés au logiciel fermé ont été résolus par des modèles économiques, comme le développement open source ou les contrats de maintenance. Je pense qu’il faut aussi une réponse de ce type pour les problèmes du cloud. On pourrait, par exemple, créer des contrats ou licences standardisés qui explicitent les droits des utilisateurs, puis orienter le marché pour ne choisir que des fournisseurs qui appliquent ces licences certifiées. On pourrait y inclure des clauses garantissant la portabilité des données, la transparence sur leur utilisation, les procédures à suivre lors d’un arrêt de service, et bien d’autres choses. Bien sûr, le plus gros obstacle est de savoir pourquoi les fournisseurs accepteraient un tel dispositif. Par peur de perdre leurs clients, ils pourraient limiter cette licence à des abonnements annuels ou exiger des frais supplémentaires.

    • Lorsqu’un problème business ou politique peut être abordé par une solution technique, je pense au contraire que c’est souvent une approche plus robuste. Parce qu’elle peut bloquer techniquement des intérêts adverses dès le départ. Le chiffrement côté client en est un excellent exemple. Il y a trop de tentations, et il est trop difficile de surveiller et de détecter les abus, pour se reposer uniquement sur une politique de confidentialité ou des règles bureaucratiques. Si les données sont chiffrées de telle manière qu’elles sont mathématiquement illisibles sur le serveur, une grande partie du problème disparaît. En revanche, si l’on veut vraiment traiter ces données côté serveur, il faut alors en pratique utiliser ses propres serveurs.

    • Même si l’on règle cela par contrat en cas d’arrêt du service, si le fournisseur cloud fait faillite et se contente de prévenir les clients puis d’exporter les données, il ne reste au final qu’un énorme fichier JSON. Sans développer soi-même une app ou sans que quelqu’un en crée une, cela est pratiquement inutile. L’intention est bonne, mais cela reste inférieur à une app locale qui permet d’utiliser durablement les données d’une app arrivée en fin de vie.

    • Même une clause garantissant la portabilité des données ne résout pas vraiment le problème : en pratique, migrer de gros volumes de données est difficile et prend beaucoup de temps. Si cela doit être fait dans l’urgence en situation de crise, c’est encore pire. Même entre bases de données open source de même version, chaque service a trop de variables pour que ce soit simple. En fin de compte, la solution réaliste consiste à garder ses données dès le départ dans son propre environnement et à pouvoir les « débrancher » si nécessaire. Il y a peut-être là une combinaison possible entre BYOC (bring your own cloud) et open source. Dans notre entreprise, nous exploitons déjà un produit de données basé sur le BYOC, donc je sais d’expérience que cette architecture est réellement possible.

    • Même si un contrat définit les responsabilités en cas d’arrêt d’un service cloud, une fois qu’une entreprise décide effectivement de fermer, il n’est pas du tout évident d’imaginer comment faire appliquer et superviser cela dans la réalité.

    • Ce n’est pas seulement un problème business ou politique, c’est aussi un problème de sécurité des données. L’une des principales raisons d’éviter le modèle par abonnement ou le cloud, c’est le besoin de protéger mes données. Toute donnée transmise sans chiffrement local peut être compromise à n’importe quel moment.

  • Cette lecture me paraît rafraîchissante. Je pense que davantage d’apps devraient devenir local-first. Si l’utilisateur ne veut pas de synchronisation cloud, cette option devrait absolument être garantie. Brisqi (https://brisqi.com), que je développe, est aussi une app fondée sur cette philosophie offline-first. Une app local-first, c’est fondamentalement une architecture qui continue à fonctionner parfaitement hors ligne, indéfiniment. L’expérience hors ligne est la base, et la sync cloud n’est qu’une amélioration optionnelle. Une app fondée sur un cache temporaire ne peut pas être considérée comme offline-first. Il faut stocker les données dans une base locale ; un vrai offline-first signifie que les données sont conservées indépendamment d’Internet. La plupart des apps dites « offline-first » ne sont en réalité que offline-tolerant, c’est-à-dire qu’elles ne prennent en charge le mode hors ligne que de façon limitée. Construire une app offline-first est bien plus difficile qu’une web app uniquement en ligne. Il faut un mécanisme de synchronisation solide, sans perte de données, même lors des transitions entre hors ligne et en ligne. J’explique ma méthode d’implémentation sur le blog : https://blog.brisqi.com/posts/how-i-designed-an-offline-firs....

  • Même si ces principes restent centrés sur le grand public, ils ont aussi du sens. Chez Sentinel Devices (www.sentineldevices.com), nous développons actuellement pour des sites industriels comme le SCADA et l’automatisation industrielle une architecture où l’exécution, l’analyse et la prise de décision se font entièrement en local sur les équipements du client, car les données ne peuvent absolument pas sortir du site. Nous ne fournissons aucun serveur externe. Cette focalisation sur les principes on-device a un côté presque renversant, aussi bien pour les clients que pour les fournisseurs. Beaucoup d’entreprises de la donnée et de l’IA ignorent ce marché parce qu’il est trop difficile, en pratique, d’y fournir leurs services. Nous devons souvent insister sur le fait qu’il n’y a aucune connectivité et que tout est traité entièrement en local pour que les clients comprennent bien. Si le local-first devenait plus familier dans le grand public, le secteur industriel évoluerait lui aussi bien plus vite.

    • Même le secteur du SCADA pousse désormais tout vers le cloud. Leur slogan, c’est « gérez votre usine depuis votre smartphone ». Mais cela augmente aussi le risque d’ouvrir le contrôle des usines au moindre hacker amateur.

    • Le sujet est vraiment passionnant, et je vous soutiens dans cette démarche. Une question toutefois : j’ai vu sur votre page carrières que tous les postes sont uniquement en présentiel. Est-ce parce que le développement local-first exige réellement du travail offline sur site, ou est-ce plutôt une question de management ?

  • Les projets sur lesquels je travaille, selfhostblocks et skarabox, visent eux aussi à rendre le self-hosting facile pour tous, sur une base NixOS. Ils fournissent de manière déclarative presque tout : https, SSO, LDAP, sauvegardes, snapshots ZFS, etc. On peut y stocker la plupart des données via Vaultwarden, Nextcloud et autres, et inclure aussi des services comme Home assistant. C’est en concurrence avec YUNoHost, mais avec de meilleurs objectifs. SelfHostBlocks se présente comme un ensemble de blocs de construction que chacun peut librement étendre et auto-héberger. C’est plus une approche de bibliothèque que de framework. C’est aussi une alternative à un NAS, entièrement open source. Même si cela peut paraître simple pour quelqu’un qui a des compétences techniques, l’objectif est d’abaisser la barrière d’entrée pour que des non-techniciens puissent aussi l’installer sur du matériel, sans devoir passer par nix ou la CLI.

    • Je soutiens vraiment ce genre de projet. Il existe énormément d’alternatives FOSS extraordinaires, mais dans les faits elles ne sont faciles à installer que pour les techniciens, au niveau « docker compose up », ce qui reste une barrière pour le grand public. Beaucoup d’apps auto-hébergeables reposent sur une architecture web app + DB + serveur + frontend, alors que dans mon cas, je ne les utilise en réalité que sur une seule machine. Un programme desktop purement local me suffirait largement, mais même cela reste hors de portée si l’on n’est pas développeur. Il y a clairement un décalage entre les FOSS auto-hébergeables de haute qualité et les vrais utilisateurs. Il faut davantage de projets pour combler cet écart. Je vais moi-même essayer selfhostblocks, et je vous souhaite le meilleur pour la suite.

    • J’adore qu’il inclue hledger. C’est peut-être un peu déroutant pour les débutants en comptabilité en texte brut, mais c’est vraiment un excellent logiciel.

    • Merci beaucoup d’avoir réalisé quelque chose d’aussi propre et soigné.

  • En parcourant l’article, j’ai l’impression qu’il couvre la plupart des points essentiels, mais que la motivation du premier paragraphe paraît un peu faible. On a presque l’impression de lire quelque chose comme : « la tarte aux pommes est délicieuse et nourrissante, mais un jour elle pourrait soudain prendre feu et disparaître, emportant même le bavoir auquel je tenais ».