Le logiciel local-first : pourquoi tes outils devraient fonctionner sans le cloud

Tu l'as déjà ressenti. L'app dont tu dépends tombe en « maintenance programmée » au pire moment possible — la veille d'une deadline, le matin d'un lancement, l'unique après-midi que tu avais bloquée pour avancer sur du vrai travail. Tu regardes un spinner, ou une page 502, ou un tweet enjoué annonçant qu'on « enquête sur un incident », et tu attends. Parce que tu n'as pas le choix. Tes données sont sur leur serveur, l'app n'est qu'un client léger, et sans leur serveur en ligne, tu n'as rien.

Ou alors c'est l'autre version. La société se fait racheter, et dix-huit mois plus tard, le produit autour duquel tu avais construit tout ton workflow est abandonné. Un post de blog remercie la communauté, la fenêtre d'export s'ouvre pour trente jours, et puis c'est fini. L'outil que tu utilisais tous les jours depuis trois ans est désormais une redirection vers une landing page pour un truc que tu ne veux pas.

Ou encore la version tarifaire. Le plan auquel tu étais abonné — celui qui avait du sens pour un solo opérateur ou une petite équipe — disparaît. La fonctionnalité que tu utilisais est désormais verrouillée derrière un plan qui coûte trois fois plus cher. Tu paies, ou tu pars. Mais partir signifie laisser tes données derrière toi, parce que l'export est un CSV qui a perdu la moitié des relations, ou une API qui te rate-limit jusqu'à la semaine prochaine, ou un format que rien d'autre ne sait lire.

C'est ça, le coût des logiciels dépendants du cloud, et les gens commencent à riposter.

Ce mouvement de riposte porte un nom. On l'appelle local-first, et je pense que c'est l'une des idées les plus importantes en architecture logicielle en ce moment — non pas parce que c'est nouveau (c'est en fait la plus vieille idée de l'informatique), mais parce qu'on l'a collectivement oubliée pendant la ruée vers l'or du SaaS, et qu'on s'en souvient maintenant que la note arrive.

Ce que « local-first » veut vraiment dire

Le terme « local-first » vient d'un paper de recherche de 2019 publié par Ink & Switch, le laboratoire fondé par l'équipe à l'origine d'Evernote. Le paper, « Local-first software: You own your data, in spite of the cloud », posait un ensemble de principes pour une autre façon de construire des logiciels. L'idée était simple dans l'esprit et difficile dans l'exécution : et si le logiciel que tu utilises tous les jours traitait ton appareil comme la source de vérité, et le cloud comme un confort optionnel ?

Voici les principes fondamentaux, tels que je les comprends :

Tes données vivent sur ton appareil d'abord, le cloud ensuite. Pas « synchronisées avec le cloud et mises en cache localement ». Localement d'abord. La copie locale est la vraie copie. La copie cloud n'est qu'un réplica.

L'app fonctionne sans connexion internet. Pas « se dégrade élégamment ». Fonctionne. Tu peux l'ouvrir, lire tes données, les modifier, en créer de nouvelles, et la fermer, le tout sans wifi, et rien ne casse.

Le cloud sert à la synchronisation et à la collaboration, pas à la fonctionnalité de base. C'est la distinction clé. Le cloud est une fonctionnalité, pas une dépendance. Il est là quand tu le veux et absent quand tu n'en as pas besoin.

Tu possèdes tes données. Aucun fournisseur ne peut t'en verrouiller l'accès. Si tu arrêtes de payer, si l'entreprise fait faillite, si tu te fais bannir pour une violation de conditions d'utilisation dont tu n'avais même pas conscience — tes données sont toujours sur ta machine, dans un format que tu peux lire.

Ça vaut le coup de comparer ça avec les deux architectures qui l'encadrent.

Le cloud-first, c'est ce qu'est la plupart des SaaS. Les données vivent sur un serveur. L'app — qu'il s'agisse d'une web app, d'une app mobile ou d'un wrapper Electron — est un client léger qui fetch et render. Si le serveur est down, ou si ton réseau est down, ou si ta session expire, tu n'as rien. Tu loues l'accès à tes propres données.

Le local-only, c'est l'autre extrême. Pense à une vieille app desktop des années 90, ou à un fichier SQLite que tu ouvres avec un script. Tout est sur ta machine. Pas de sync, pas de collaboration, pas de multi-appareils. Ça marche pour toujours, mais c'est isolé. Si ton disque dur meurt et que tu n'as pas de sauvegarde, c'est fini. Si tu veux travailler sur ton laptop et ton desktop, tu copies des fichiers manuellement.

Le local-first, c'est la synthèse. Tu récupères la permanence et la propriété du local-only, plus le confort de la synchronisation cloud — mais la sync est additive, pas fondatrice. Retire la sync et l'app fonctionne toujours. Retire le cloud et tu as toujours tes données.

Les problèmes que le local-first résout

Mettons les points sur les i concernant ce qui cloche vraiment dans les logiciels cloud-first, parce que les principes ci-dessus sont abstraits et que les problèmes, eux, sont concrets.

La dépendance à la disponibilité

Voici un fait amusant sur les apps cloud : elles peuvent tomber en panne à deux endroits. Ton réseau peut lâcher, ce qui veut dire que tu ne peux pas joindre le serveur. Ou leur serveur peut lâcher, ce qui veut dire que le serveur ne peut pas te joindre. Dans les deux cas, tu regardes un spinner. Tu n'as aucun contrôle sur l'un ou l'autre mode de défaillance. Tu peux upgrader ton forfait internet, mais tu ne peux pas empêcher AWS us-east-1 de passer une mauvaise journée.

Les apps local-first ne tombent en panne qu'à un seul endroit : ta machine. Si ta machine est allumée, l'app fonctionne. C'est tout. Pas de dépendance à un réseau que tu ne contrôles pas, pas de dépendance à un serveur que tu ne vois pas. Le rayon d'impact d'une défaillance passe de « tout l'internet entre toi et un data center » à « le laptop devant toi ».

Je ne dis pas que les machines locales ne tombent jamais en panne. C'est faux. Les disques durs meurent, les batteries gonflent, le café se renverse. Mais quand une machine locale lâche, c'est le problème d'une seule personne, et c'est un problème avec une solution connue (une sauvegarde, une nouvelle machine, une copie synchronisée sur un autre appareil). Quand un service cloud lâche, c'est le problème de tout le monde en même temps, et la seule solution est d'attendre.

Le problème de l'abandon

C'est celui qui me fait vraiment peur, parce que ce n'est pas hypothétique. Ça arrive tout le temps.

Une entreprise construit un outil. Des gens l'adoptent. Des gens construisent des workflows autour, y mettent des années de données, l'intègrent dans leur quotidien. Puis l'entreprise n'a plus d'argent, ou se fait racheter par quelqu'un qui veut l'équipe mais pas le produit, ou pivote vers des « solutions AI enterprise » ou whatever la mode du moment. Le produit est abandonné.

Quand une app cloud-first ferme, tu perds tout. Le serveur s'éteint, l'app arrête de fonctionner, et tes données — qui vivaient sur ce serveur — disparaissent. Peut-être que tu as un export. Peut-être que l'export est utilisable. Peut-être que tu as trente jours pour trouver une solution. Peut-être que non.

Quand une app local-first ferme, tu perds les mises à jour. C'est tout. L'app que tu as déjà installée continue de fonctionner. Tes données, qui vivaient sur ta machine, sont toujours sur ta machine. Tu peux continuer à utiliser l'outil indéfiniment — tu n'auras juste plus de nouvelles fonctionnalités ni de correctifs. À terme, les mises à jour de l'OS finiront peut-être par la casser, et c'est un vrai problème. Mais « à terme ça pourrait cesser de fonctionner » est une proposition très différente de « ça cesse de fonctionner le 31 mars et toutes tes données partent avec ».

Il y a un cimetière d'apps cloud qui ont emporté les données de leurs utilisateurs. Google Reader. Sunrise. L'ancien modèle de tarification de Workflowy (pas un abandon, mais un moment « tes données sont maintenant derrière un paywall »). Chaque petit SaaS qui a un jour manqué de runway. Le local-first est une protection structurelle contre ça. Tu ne peux pas être privé de tes propres données si elles n'ont jamais été sur le serveur de quelqu'un d'autre.

Le levier tarifaire

Le SaaS cloud possède un type de levier auquel je pense que les gens ne réfléchissent pas assez : il retient tes données en otage.

Je ne dis pas que les entreprises SaaS font ça malicieusement. La plupart ne le font pas. Mais l'architecture leur donne ce levier, qu'elles l'utilisent ou non. Si tu arrêtes de payer, elles peuvent couper ton accès. Et « accès » ici signifie « la capacité d'ouvrir, lire et utiliser les données que tu as passé des années à créer ». La fonctionnalité d'export est une valve qu'elles contrôlent. Elles peuvent la rendre bonne, ou en faire un CSV qui supprime chaque relation et chaque pièce jointe. Elles peuvent te donner 30 jours, ou ne rien te donner du tout.

Le local-first élimine ce levier entièrement. Si tu arrêtes de payer pour une app local-first, l'app continue de fonctionner. Tu gardes tes données. Tu gardes la capacité de les ouvrir, les lire, les modifier. Ce que tu perds, c'est la sync, les mises à jour, les fonctionnalités premium — les choses qui valent vraiment la peine qu'on les paie, par opposition à celles que tu paies parce que tu n'as pas le choix.

Ce n'est pas de l'anti-SaaS. Je paie plein de SaaS. Mais j'ai conscience, chaque fois que je le fais, que je loue un accès plutôt que je ne possède un outil. Le local-first, c'est posséder l'outil. Le modèle économique doit être différent — tu factures le logiciel, ou la sync, ou les mises à jour — mais la relation avec l'utilisateur est plus saine. L'utilisateur est un client, pas un otage.

Confidentialité et conformité

Tes données ne transitent pas par les serveurs de quelqu'un d'autre. Ce n'est pas qu'un point philosophique. C'est aussi un point juridique et opérationnel.

Si tu travailles avec des données soumises au RGPD, HIPAA, SOC 2, ou n'importe quelle soupe de normes de conformité, chaque serveur que tes données touchent est un passif. Chaque SaaS dans ta stack est un fournisseur que tu dois évaluer, un accord de traitement des données que tu dois signer, une surface de faille dont tu dois te soucier. Les logiciels cloud-first multiplient ces surfaces. Chaque outil est un endroit supplémentaire où vivent tes données, une entreprise supplémentaire qui pourrait subir une faille, un sous-traitant supplémentaire dans ton flux descendant.

Les logiciels local-first réduisent ces surfaces. Si tes données restent sur ta machine, elles ne touchent l'infrastructure de personne d'autre. Il n'y a pas de fournisseur à évaluer pour la fonctionnalité principale. Si la sync est optionnelle et que tu ne l'utilises pas, aucune donnée ne circule nulle part. Si tu utilises la sync, tu as fait un choix délibéré sur la destination de tes données, plutôt que de les voir partir vers un serveur par défaut parce que l'app ne fonctionne pas autrement.

Il y a aussi la question de la dignité tout court. Je ne pense pas que chaque note que j'écris, chaque requête que je lance, chaque fichier que j'ouvre doive être visible par une entreprise qui pourrait s'en servir pour entraîner un modèle, vendre des analytics agrégées, ou les remettre en réponse à une injonction dont je n'entendrai jamais parler. Le local-first est une façon de garder ton travail pour toi. Pas parce que tu fais quelque chose de mal, mais parce que c'est à toi.

Performance

Celle-ci est sous-estimée, et elle devient plus importante à mesure que les gens remarquent à quel point les logiciels « modernes » paraissent lents.

Une app cloud fait un aller-retour réseau pour fondamentalement tout. Tu cliques sur un truc, l'app envoie une requête à un serveur, le serveur interroge une base de données, la base répond, le serveur répond, l'app re-render. Ça représente des millisecondes — des dizaines à des centaines, selon l'emplacement du serveur et le nombre de sauts impliqués. Ajoute une connexion à froid, un handshake TLS, une lookup DNS, et tu te retrouves à compter en secondes. On a tous utilisé des apps où cliquer sur un onglet prend une seconde entière. Ce n'est pas parce que l'app est complexe. C'est parce que l'app est loin.

Une app local-first fait ses opérations en microsecondes. Les données sont juste là. Le disque est juste là. Le CPU est juste là. Il n'y a pas d'aller-retour parce qu'il n'y a pas de trajet. C'est pourquoi les apps local-first paraissent rapides d'une façon que les apps cloud, aussi bien optimisées soient-elles, ne peuvent pas égaler. Ce n'est pas une question d'effort d'ingénierie. C'est une question de physique. La lumière est rapide, mais ton bus mémoire local est plus rapide.

Ça compte plus que les gens ne l'admettent. La vitesse est une fonctionnalité. La différence entre une app qui répond en 10 ms et une qui répond en 200 ms, c'est la différence entre une app qui semble être une extension de tes mains et une où tu as l'impression d'envoyer des requêtes et d'attendre des réponses. Le local-first te donne la première par défaut.

Les compromis (soyons honnêtes)

Je ne vais pas prétendre que le local-first est gratuit. Ça ne l'est pas. Si le cloud-first a gagné pendant une décennie, c'est parce qu'il est plus facile à construire, plus facile à monétiser et plus facile à scaler. Le local-first te demande de résoudre des problèmes vraiment difficiles.

La collaboration est plus difficile. Dans une app cloud-first, la collaboration est facile parce qu'il y a un seul serveur et une seule source de vérité. Deux personnes modifient un document, le serveur fusionne les modifications, c'est réglé. Dans une app local-first, deux personnes ont deux copies locales, et ces copies doivent converger. C'est un problème de systèmes distribués, et les problèmes de systèmes distribués sont notoirement pas simples. Il te faut de la résolution de conflits. Il te faut un moyen de fusionner des modifications concurrentes sans perdre de données ni corrompre l'état. C'est là qu'interviennent les CRDT (Conflict-free Replicated Data Types), et les CRDT sont un véritable domaine de recherche, pas une librairie drop-in que tu peux utiliser sans comprendre.

Le multi-appareils nécessite de la sync. Si tu veux tes données sur ton laptop, ton téléphone et ton desktop, quelque chose doit les déplacer entre eux. Ce quelque chose est une couche de sync, et la sync est de ces choses qui paraissent simples jusqu'à ce que tu essaies de la construire. Que se passe-t-il quand deux appareils modifient le même enregistrement hors ligne ? Que se passe-t-il quand un appareil revient en ligne après une semaine ? Que se passe-t-il quand le serveur de sync est down ? Ce sont des problèmes résolubles — des outils comme Automerge et Yjs existent précisément pour les résoudre — mais ce sont des problèmes que tu dois résoudre, pas des problèmes que l'architecture résout pour toi.

Pas d'édition multi-utilisateurs en temps réel par défaut. Sans couche de sync, deux personnes ne peuvent pas modifier les mêmes données simultanément. Elles peuvent chacune avoir leur propre copie, mais elles ne peuvent pas voir les modifications de l'autre en temps réel. Si tu veux de l'édition concurrente à la Google Docs, tu dois la construire (ou utiliser une librairie qui le fait). Les apps cloud-first l'obtiennent gratuitement parce que le serveur est la vue partagée. Les apps local-first doivent la construire.

Les mises à jour sont ta responsabilité. Dans une app cloud-first, le fournisseur met à jour le serveur et tout le monde obtient la nouvelle version instantanément. Dans une app local-first, la mise à jour doit aller vers chaque client. Les auto-updaters gèrent ça, mais c'est encore une chose à construire et à maintenir, et les utilisateurs peuvent refuser les mises à jour (ce qui est bien pour la propriété mais mauvais pour le fournisseur qui veut tout le monde sur la dernière version). Il y a aussi le problème de la longue traîne : si tu ships une migration de données dans la version 3, tu peux avoir des utilisateurs sur la version 1 pendant des années, et tu dois gérer leurs données quand ils finissent par upgrader.

Ce sont de vrais compromis. C'est pourquoi toutes les apps ne devraient pas être local-first, et pourquoi le cloud-first ne va pas disparaître. Mais ce sont aussi des compromis que l'écosystème apprend de mieux en mieux à gérer. Les librairies CRDT mûrissent. L'infrastructure de sync se banalise. Le coût de construire du local-first baisse, tandis que le coût du cloud-first (tant en dollars qu'en dépendances) devient plus visible.

Le local-first en pratique : qui le fait

Ce n'est pas un mouvement théorique. Il existe de vrais produits construits sur des principes local-first, et certains sont largement utilisés. En voici quelques-uns que je suis de près.

Obsidian est probablement le succès local-first le plus visible. C'est une app de prise de notes qui stocke tout en fichiers Markdown bruts dans un dossier sur ta machine. Tu peux ouvrir ce dossier dans n'importe quel éditeur de texte. Tu peux le synchroniser avec Dropbox, iCloud, git, ou le service de sync payant d'Obsidian. L'app fonctionne entièrement hors ligne. Si l'entreprise Obsidian disparaissait demain, tes notes seraient toujours là, en Markdown, lisibles par tout. C'est le local-first dans sa forme la plus pure, et c'est pourquoi beaucoup de gens qui ont quitté Evernote et Notion ont atterri là. Les données sont à toi d'une façon qu'elles ne le sont jamais dans un wiki hébergé.

Linear est un exemple partiel, et intéressant. Linear est un outil de gestion de projet — du suivi de tickets, fondamentalement — et il est soutenu par le cloud. Mais il est ingéniéré pour paraître local-first. L'app cache agressivement, les opérations sont optimistes, et l'UI répond avant que le serveur ne confirme. Ce n'est pas vraiment local-first (si leur serveur est down, tu ne peux pas faire grand-chose), mais ça démontre qu'on peut appliquer les principes local-first à l'expérience même dans une architecture cloud. La vitesse et la réactivité sont le résultat direct de traiter l'état local comme primaire et le serveur comme cible de sync.

Reflect est une app de notes construite sur une couche de sync CRDT. Elle est local-first avec sync multi-appareils intégrée. Tes notes sont sur ta machine, elles se synchronisent entre appareils, et la sync gère les conflits automatiquement. C'est un bon exemple du modèle « local-first plus sync » — tu récupères la propriété du local et le confort du cloud, et la partie difficile (la résolution de conflits) est prise en charge par l'infrastructure de sync.

BaseVolt est celui que je connais le mieux, puisque c'est moi qui le développe. C'est un panneau d'administration de base de données desktop — vois-le comme une alternative local-first aux outils de base de données web. Tu le connectes à ta base de données (qui peut être un fichier SQLite local ou un serveur Postgres distant), et il tourne sur ta machine, hors ligne, avec tes requêtes et tes détails de connexion qui ne transitent jamais par un serveur tiers. Il y a une sync cloud optionnelle pour des choses comme les requêtes sauvegardées et les configurations de connexion entre appareils, mais l'outil principal fonctionne sans. J'en parle non pas parce que cet essai parle de BaseVolt — ce n'est pas le cas — mais parce que c'est un exemple de local-first appliqué à une catégorie (les outils de base de données) qui est presque entièrement passée au cloud-first, et où je pense que ce virage était une erreur.

L'écosystème CRDT au sens large est la couche qui rend tout ça possible. Automerge, Yjs et des librairies similaires rendent praticable la construction d'apps local-first avec de la collaboration en temps réel. Il y a quelques années, si tu voulais que deux personnes modifient les mêmes données hors ligne et fusionnent proprement, tu devais fondamentalement faire de la recherche originale. Maintenant, tu peux utiliser une librairie. C'est le changement d'infrastructure qui rend le local-first viable pour plus que des outils mono-utilisateur, et c'est pourquoi je pense que les prochaines années verront plus de produits local-first dans des catégories qui semblent actuellement exiger un backend cloud.

Pourquoi ça compte particulièrement pour les outils de base de données

Laisse-moi zoomer sur la catégorie que je connais le mieux, parce que je pense qu'elle illustre le propos général.

Les panneaux d'administration de base de données — les outils que tu utilises pour regarder ta base de données, lancer des requêtes, parcourir des tables, gérer des schémas — ont presque tous migré vers le cloud. Tu te connectes à une web app, tu la relies à ta base de données, et tu travailles via un navigateur. La web app parle à ta base de données. Tes requêtes vont de ton navigateur vers leur serveur, puis vers ta base de données, et reviennent.

Réfléchis à ce que ça signifie. Tu viens d'ajouter un tiers à un chemin qui ne devrait concerner que deux parties : toi et ta base de données. Chaque requête que tu lances passe par le serveur de quelqu'un d'autre. Tes identifiants de connexion sont peut-être stockés sur ce serveur. Ton historique de requêtes vit sur ce serveur. Les résultats de tes requêtes — qui peuvent contenir des données clients, des enregistrements financiers, des informations de santé, n'importe quoi — transitent par ce serveur avant de revenir vers toi.

C'est l'architecture contre laquelle le local-first s'insurge, et dans le cas des bases de données, l'argument est particulièrement limpide. Ta base de données peut être locale (un fichier SQLite sur ta machine) ou distante (une instance Postgres sur AWS), mais l'interface — ce que tu utilises pour interagir avec la base de données — n'a pas besoin d'être aussi un service hébergé. Une app desktop qui se connecte directement à ta base de données, exécute les requêtes localement et affiche les résultats localement est plus simple, plus rapide, plus privée et plus robuste qu'une web app qui fait tout transiter par un backend SaaS.

Il y a aussi un argument de sécurité ici. Chaque outil SaaS de base de données est un point d'exfiltration potentiel. Si l'outil est compromis, l'attaquant peut obtenir l'accès à toutes les bases de données que ses clients y ont connectées. On a déjà vu ce schéma dans d'autres catégories SaaS. Un outil desktop local-first qui stocke les détails de connexion localement et se connecte directement à la base de données élimine entièrement cette surface. Il n'y a pas d'intermédiaire à compromettre parce qu'il n'y a pas d'intermédiaire.

Je ne dis pas que les outils de base de données web sont mauvais ou inutiles. Ils existent pour de bonnes raisons — zéro installation, partage facile, multi-plateforme par défaut. Mais je pense que l'hypothèse par défaut selon laquelle « outil de base de données = web app » est erronée, et je pense qu'elle va évoluer. Le confort d'une web app ne vaut pas le fait de faire transiter ton trafic de base de données par un tiers, et une fois que tu as utilisé un outil de base de données local-first qui se connecte directement et répond instantanément, la version web app donne l'impression de travailler à travers une paille.

Comment évaluer si un outil est vraiment local-first

« Local-first » est en train de devenir un terme marketing, ce qui signifie qu'il va se diluer. Des produits qui mettent un peu de données en cache localement vont se qualifier de local-first. Des produits qui ont un mode hors ligne pour la lecture vont se qualifier de local-first. Voici donc une checklist que j'utilise, et que je te suggère d'utiliser aussi, quand quelqu'un revendique l'étiquette.

Ça fonctionne sans internet ? Pas « peux-tu lire les données en cache ». Peux-tu faire ce que l'outil fait fondamentalement — créer, modifier, sauvegarder — avec le réseau complètement coupé ? Si la réponse est « tu peux voir mais pas modifier » ou « tu peux modifier mais ça ne sauvegarde pas tant que tu n'es pas en ligne », ce n'est pas du local-first. C'est du cloud-first tolérant au hors ligne, ce qui est mieux que rien mais pas la même chose.

Tes données sont-elles stockées dans un format accessible sans l'app ? Les fichiers bruts (Markdown, JSON, SQLite) sont l'idéal. Une base de données locale propriétaire que seule l'app peut lire est mieux qu'un serveur distant, mais ce n'est pas pleinement local-first — si l'app casse et que le format n'est pas documenté, tu es coincé. Le gold standard, c'est des données dans un format que n'importe quel outil raisonnable peut ouvrir. Markdown, CSV, SQLite, JSON. Des formats qui survivent à n'importe quelle app.

Si l'entreprise disparaît demain, peux-tu toujours utiliser l'outil ? C'est le test de l'abandon. Si l'entreprise ferme, supprime ses serveurs et cesse d'exister, as-tu toujours une app fonctionnelle et tes données ? Pour une vraie app local-first, la réponse est oui — tu perds les mises à jour et la sync, mais l'app et les données persistent. Pour une app cloud-first avec cache hors ligne, la réponse est non — l'app est un client pour un serveur qui n'existe plus.

Le cloud est-il optionnel ou obligatoire ? Plus précisément : le cloud est-il utilisé pour la sync et la collaboration (optionnel, additif) ou pour l'authentification et le stockage des données (obligatoire, fondateur) ? Si tu dois te connecter pour utiliser l'app, le cloud est obligatoire — l'auth est une dépendance cloud. Si tes données sont stockées sur un serveur et que la copie locale n'est qu'un cache, le cloud est obligatoire. Si l'app fonctionne entièrement sans compte et sans connexion, le cloud est optionnel.

Un outil n'a pas besoin de réussir les quatre pour être utile. Mais un outil qui réussit les quatre est local-first au sens où je l'entends ici, et un outil qui se qualifie de local-first mais rate le test de l'abandon utilise le terme comme marketing.

L'avenir

Je ne pense pas que le local-first va remplacer le SaaS cloud. Ce n'est pas ça, l'enjeu. Le cloud-first est la bonne architecture pour beaucoup de choses — tout ce où les données sont fondamentalement partagées et en temps réel (un jeu multijoueur, un dashboard en direct, une file de support client), tout ce où le calcul est plus lourd que ce qu'un client peut faire (analytics à grande échelle, inférence ML), tout ce où la valeur est dans le réseau (marketplaces, plateformes sociales). Pour ces choses-là, le cloud est le produit, pas une fonctionnalité.

Mais pour une large catégorie d'outils sous-desservis — notes, éditeurs de code, gestion de bases de données, gestion de fichiers, bases de connaissances personnelles, outils de design, outils d'écriture — le local-first est la meilleure architecture. Ce sont des outils où les données sont principalement les tiennes, où le travail est principalement en solo ou en petite équipe, où l'opération principale est locale par nature (éditer du texte, lancer une requête, organiser des fichiers), et où le cloud ajoute du confort sans ajouter de capacité fondamentale. Pour ces outils, tout faire transiter par un serveur est un impôt que tu paies pour rien, et le local-first supprime cet impôt.

La principale objection historique au local-first était la sync. « Le local-first c'est génial pour un seul utilisateur, mais dès qu'il te faut de la collaboration ou du multi-appareils, ça s'effondre. » Cette objection était valable en 2015. Elle l'est moins aujourd'hui. L'écosystème CRDT — Automerge, Yjs, et le corpus croissant de patterns autour d'eux — fait de la sync un problème suffisamment résolu pour qu'une petite équipe puisse construire une app local-first avec collaboration en temps réel sans faire de la recherche originale en systèmes distribués. L'infrastructure se banalise. La courbe des coûts s'infléchit.

Je pense que nous verrons le local-first passer d'une philosophie de niche à un choix d'architecture mainstream dans les prochaines années, comme le « offline-first » l'a fait pour les apps mobiles il y a une décennie. Pas partout, mais dans les catégories où il colle. Et je pense que les utilisateurs qui adoptent les outils local-first maintenant seront ceux qui, cinq ans plus tard, auront toujours leurs données — parce qu'elles étaient sur leur machine, dans un format qu'ils possèdent, dans une app qui n'avait pas besoin de la permission d'un serveur pour fonctionner.

C'est le pari, en tout cas. Le cloud ne va pas disparaître. Mais l'idée que chaque outil a besoin d'un serveur pour fonctionner — ça, ça va disparaître, et pas un jour trop tôt.

En résumé

Tu devrais te soucier du local-first parce que ça change qui possède ton travail. Les logiciels cloud-first te louent l'accès à tes propres données, et le propriétaire peut augmenter le loyer, t'expulser ou démolir l'immeuble. Les logiciels local-first mettent tes données sur ta machine, dans un format que tu contrôles, dans une app qui fonctionne que le serveur de quelqu'un soit en ligne ou non. Tu paies l'outil, pas l'accès à toi-même.

Ce n'est pas une préoccupation de niche. C'est la différence entre louer et posséder, appliquée aux outils que tu utilises tous les jours. Et ça devient praticable — l'infrastructure de sync mûrit, les outils s'améliorent, et le coût de la dépendance au cloud devient de plus en plus difficile à ignorer.

Si tu travailles avec des bases de données, ça compte doublement. Ton outil de base de données ne devrait pas être un tiers entre toi et tes données. Il devrait être une connexion directe — locale, rapide, privée, et à toi.

Essayez-le sur basevolt.app — pas d'inscription, pas de carte bancaire.

Si tu veux débattre de tout ça, ou si tu construis quelque chose de local-first et que tu veux comparer tes notes, retrouvez-moi sur X.