# Ce que local-first veut dire dans Prior

> Prior enregistre votre travail d’abord sur votre appareil, puis le synchronise. Comment cela marche, comment chaque type de donnée fusionne, et où cela s’arrête.

Source: https://priortasks.com/fr/blog/local-first/
Last updated: 2026-11-05

Local-first signifie que la copie de votre travail qui compte est celle de votre appareil. Le serveur est le moyen qu’ont vos appareils de se joindre, pas l’endroit où une action doit être approuvée avant de compter. L’idée a été exposée en 2019 par Martin Kleppmann, Adam Wiggins, Peter van Hardenberg et Mark McGranaghan chez Ink & Switch, dans [un essai](https://www.inkandswitch.com/essay/local-first/) qui énumère sept idéaux : rapide, multi-appareil, hors ligne, collaboration, longévité, vie privée et contrôle par l’utilisateur.

L’architecture de Prior suit cette idée. Voici ce que cela donne en pratique, et où cela s’arrête.

## Ce qui se passe quand vous ajoutez une tâche

Vous écrivez une tâche. Prior l’enregistre dans une base de données sur votre appareil : SQLite dans les applications de bureau et Android, le stockage propre au navigateur sur le web. À côté, il écrit une entrée dans une boîte d’envoi, avec un identifiant de mutation unique. La tâche apparaît alors à l’écran. Rien n’a attendu le réseau, ce qui explique que créer une tâche soit instantané.

Quand l’appareil est en ligne, il envoie la boîte d’envoi au serveur. Le serveur tient un journal des modifications en ajout seul, avec un numéro de révision croissant, et n’applique chaque modification qu’une seule fois par identifiant de mutation : une nouvelle tentative après une coupure de connexion ne peut donc pas créer une tâche en double. Vos autres appareils demandent ce qui a changé depuis la dernière révision qu’ils ont vue. Un petit message WebSocket leur dit de demander tout de suite, au lieu d’attendre la prochaine synchronisation périodique. Il ne transporte aucune donnée, seulement la nouvelle que quelque chose a changé.

Hors ligne, l’application le dit : « Tout est enregistré sur cet appareil. La synchronisation reprendra dès votre retour en ligne. » Quand des modifications attendent, elle les compte. Les données créées avant que vous vous connectiez restent sur l’appareil jusqu’à ce qu’elles soient rattachées à votre compte.

## La fusion est un choix par type de donnée

Deux appareils qui modifient la même chose hors ligne ne seront pas d’accord quand ils se retrouveront. Il n’existe pas de solution unique pour tous les types de données : Prior utilise donc celle qui convient à chacun.

- **Tâches et habitudes.** Le serveur applique la dernière modification acceptée, dans l’ordre des révisions. Une tâche dont une modification attend encore sur votre appareil n’est pas écrasée par ce qui arrive d’ailleurs.
- **Calendriers et événements.** Les modifications sont des correctifs champ par champ. Les modifications de champs différents d’un même événement se combinent ; pour un même champ, la dernière reçue l’emporte. Les suppressions laissent un marqueur : une ancienne copie hors ligne ne peut donc pas ramener un événement.
- **Cartes de révision.** Les révisions forment un journal en ajout seul, et le calendrier d’une carte n’est pas stocké : il est calculé en rejouant les révisions de cette carte. Deux appareils qui ont révisé hors ligne obtiennent le même calendrier une fois leurs journaux réunis, sans rien à résoudre.
- **Budgets.** Ils fusionnent ligne par ligne. La version la plus récente de chaque ligne l’emporte, et les lignes supprimées laissent un marqueur.
- **Notes partagées.** Ce sont des documents Yjs, conçus pour que plusieurs personnes écrivent en même temps. Si la connexion tombe, la note indique qu’elle est hors ligne, et les modifications des éditeurs fusionnent à la reconnexion.

Ce que les cinq ont en commun, c’est une fusion choisie selon l’usage de la donnée et un marqueur pour chaque suppression, afin qu’une ancienne copie ne puisse jamais défaire une décision plus récente.

## Où cela s’arrête

Local-first est une promesse sur l’endroit où vit votre travail et sur ce qui continue de fonctionner, pas une promesse sur tout.

- **Les projets partagés nécessitent une connexion.** Prior le dit et garde un projet partagé en lecture seule jusqu’à votre reconnexion.
- **Certaines choses sont en ligne par nature.** La connexion, Prior AI, les e-mails et les ligues ont besoin du réseau.
- **Ce n’est pas du chiffrement de bout en bout.** Vos données sont stockées sur notre serveur pour pouvoir se synchroniser. Local-first n’y change rien.
- **Un navigateur est un endroit fragile.** Sur le web, vos données vivent dans le stockage de ce navigateur. Videz-le avant que les données soient synchronisées et les modifications non synchronisées partent avec. Les applications natives conservent un fichier de base de données.

## Un bug qui nous a appris quelque chose

Une première version de la synchronisation s’exécutait dans un ordre fixe. Une colonne de dates était mal lue pour les tâches planifiées et faisait échouer toute la récupération des tâches, ce qui empêchait aussi les calendriers et l’espace de travail de se synchroniser. Nous avons corrigé la lecture, et nous avons changé la conception : chaque partie de la synchronisation s’exécute désormais seule, et l’échec de l’une ne bloque plus les autres. L’interface dit quelle partie attend encore, et ne signale pas une réussite complète quand une partie a échoué.

C’est aussi du local-first à l’œuvre. Vos données n’ont jamais été perdues, car elles étaient à l’abri sur l’appareil. C’est la synchronisation qui était en retard.

Pour l’utiliser, voir [Utilisation hors ligne et synchronisation](https://priortasks.com/fr/docs/getting-started/offline-and-sync/), et [Résoudre les problèmes de synchronisation](https://priortasks.com/fr/docs/troubleshooting/sync-problems/) explique quoi faire quand quelque chose n’arrive pas.