ADR-010 - Drift pour la persistance locale sur mobile

• Statut : Accepté
• Date : 2026-04-05

Contexte

L’application mobile est utilisée en plein champ, dans des zones sans couverture réseau fiable. Les agriculteurs et pilotes de drone doivent pouvoir consulter leurs parcelles et créer des actions hors ligne, puis synchroniser les données à la reconnexion. Un mécanisme de persistance locale est donc indispensable sur le mobile Flutter.

Décision

Nous utilisons Drift (anciennement Moor) comme ORM SQLite pour la persistance locale sur mobile.

Alternatives considérées

• Hive : base de données clé-valeur NoSQL légère pour Flutter, rapide pour de la lecture simple, mais pas adaptée aux relations et aux requêtes complexes
• Isar : base orientée objet pour Flutter, très performante, mais sans support des transactions relationnelles
• sqflite : accès SQLite bas niveau, contrôle total, mais verbeux et sans typage automatique
• SharedPreferences : uniquement pour des données simples de type clé-valeur, inadapté à un cache structuré

Conséquences

• Schéma SQLite typé et déclaratif en Dart, cohérent avec l’approche Prisma côté serveur
• Support des relations entre tables, des transactions et des requêtes complexes
• Génération de code via drift_dev et build_runner pour les types et les requêtes
• Stratégie de synchronisation par flag needsSync : les entités modifiées hors ligne sont marquées et synchronisées à la reconnexion
• La synchronisation bidirectionnelle (conflits) doit être gérée manuellement — logique non triviale
• Nécessite une étape de génération de code (build_runner) après chaque modification de schéma
• Deux schémas à maintenir en cohérence : Prisma (serveur) et Drift (mobile) — risque de dérive si les entités évoluent