Le train entre dans un tunnel et un document cesse de s’ouvrir. Vous le modifiiez un instant plus tôt. Les mots sont les vôtres, l’ordinateur est sur vos genoux et le fichier est petit. Pourtant, continuer le travail dépend désormais de la réponse d’un système lointain.
C’est un choix de conception, pas une propriété inévitable de l’informatique moderne. Ce choix est parfois raisonnable. La collaboration en direct, l’administration centralisée et l’accès depuis un appareil inhabituel sont utiles. Mais il faut voir quand ils transforment une connexion en permission d’utiliser son propre travail.
Commencez là où le travail s’effectue
Notions de base · Ce que « local » et « cloud » signifient ici
« Local » signifie que le travail est stocké ou traité sur un appareil que vous pouvez utiliser directement, comme votre ordinateur portable. « Cloud » désigne un service exécuté sur les ordinateurs de quelqu’un d’autre, joignable par un réseau. Une application peut faire les deux.
La distinction utile porte sur ce que vous pouvez encore faire lorsque cette connexion distante est indisponible, et non sur l’étiquette affichée par l’application.
Une organisation locale d’abord laisse l’activité essentielle se dérouler sur l’appareil devant vous. Le réseau peut synchroniser, publier, relier des collaborateurs. Quand la connexion disparaît, l’activité de base reste possible.
Cette description est une intention, pas une garantie collée sur un produit. Une application peut mettre certains documents en cache, pas d’autres. Elle peut n’autoriser le hors-ligne qu’après une première connexion. Elle peut stocker des fichiers dans un format qu’aucun autre outil ne lit.
Posez des questions concrètes. Pouvez-vous ouvrir le travail d’hier sans réseau ? Créer quelque chose de nouveau ? Récupérer les originaux sans l’application ? Que se passe-t-il si deux appareils déconnectés éditent la même chose ?
Pour le texte auquel je tiens, la copie de travail est un répertoire Markdown sur le disque, git, Syncthing ou git push vers un distant que je peux cloner si le compte SaaS meurt. Le cloud a le droit de détenir une copie. Pas la seule.
git -C ~/src/notes status
test -f ~/src/notes/index.md && $EDITOR ~/src/notes/index.mdSi cette séquence exige un login navigateur, ce n’est pas du local-first, quel que soit le marketing.
Le local n’est pas automatiquement durable
Un portable est un système local. Il peut aussi tomber, être volé, ou mourir. Quitter un service hébergé sans stratégie de reprise réduit parfois la résilience tout en augmentant le sentiment de contrôle.
La synchronisation n’est pas une sauvegarde. Une suppression synchronisée se propage. La reprise exige une copie qui survit à l’erreur.
Syncthing répliquera volontiers un rm -rf. restic ou Borg sur une autre machine, avec un mot de passe qui ne vit pas seulement sur le portable, est la couche qui survit à cet après-midi.
Laissez le cloud gagner sa place
Un service distant peut être un excellent hors-site, un moyen de partager, ou la façon la plus simple de travailler à plusieurs. Séparez les fonctions : qui distribue, quelle copie restaure-t-on, quel format, quelle identité.
rclone vers un compartiment S3 est un bon hors-site si vous tenez les clés et avez restauré. iCloud Drive est une commodité si vous avez aussi un répertoire qui s’ouvre dans un tunnel.
Rendez la frontière visible
Un petit inventaire rend l’arrangement explicable. Notez la copie de travail, le format, la copie de reprise, et la date du dernier test de restauration.
Intermédiaire · Un inventaire en YAML
Ceci est un enregistrement illustratif, pas une commande de sauvegarde :
collection: household-notes
working_copy: laptop/Documents/household
format: markdown-and-pdf
sync: syncthing
recovery_copy: restic:sftp:backup-host:/restic/laptop
last_restore_test: 2026-09-15
tested_by: second-household-memberLa ligne précieuse est le test de restauration. Un emplacement dit où cela devrait être. Une répétition dit si vous pouvez l’utiliser. La seconde personne compte : un système qui survit à une panne réseau mais dépend de la mémoire de son auteur a encore un point étroit.
Gardez l’inventaire sans mots de passe. Les secrets ont un plan d’accès distinct.
Expert · La synchro n’est pas un CRDT, et git n’est pas une base
Si deux portables éditent le même fichier hors ligne, Syncthing produira une copie de conflit. git refusera de fusionner sans vous. Ni l’un ni l’autre n’est Automerge. Traiter « local-first » comme « multi-maître automatique », c’est ainsi qu’on perd un paragraphe.
Pour des données structurées, préférez SQLite que vous pouvez sauvegarder. Pour des secrets, age ou OpenPGP plutôt qu’une appli de notes qui rappelle encore le serveur pour la clé. Le test expert : cloner l’arbre sur une Debian live USB, sans profil navigateur, et finir une vraie tâche.
Une expérience de vingt minutes
Choisissez un travail non critique. Enregistrez, déconnectez le réseau. Ouvrez le fichier. Modifiez. Cherchez une référence. Sauvez une nouvelle copie. Notez ce qui continue et ce qui s’arrête.
Reconnectez et inspectez. Les changements sont-ils arrivés ? Un conflit ? Pourriez-vous l’expliquer ? Si l’application offre un export, ouvrez-le dans un autre outil.
Le but n’est pas de bannir le réseau. C’est de le laisser agrandir ce que vous pouvez faire tout en gardant une part utile de la vie de travail à portée de main.
