Flutter hors ligne en 2026 : Drift, Isar ou Hive, que choisir ?

Flutter hors ligne en 2026 : Drift, Isar ou Hive, que choisir ?

Un mode hors ligne ne se résume pas au choix d'une base locale : c'est une base, une file d'envoi et une règle pour les conflits.

Réponse courte. À la lecture de pub.dev et GitHub du 7 novembre 2026, Drift (au-dessus de SQLite) est mis à jour régulièrement, avec des outils de migration documentés. Isar d'origine n'a pas de version stable depuis avril 2023 ; un fork communautaire, isar_community, publie des versions 3.x. Hive d'origine n'a pas de version stable depuis juin 2022 ; hive_ce, une continuation communautaire, est publié activement. Pour des données reliées, des requêtes et des migrations à tester, nous recommandons de partir de Drift. Pour un petit cache de type clé-valeur, hive_ce est défendable. Et dans tous les cas, la partie difficile est la synchronisation avec le serveur, pas la base.

Transparence. BOVO Digital est une agence basée au Bénin qui développe des applications Flutter : nous avons un intérêt dans le sujet. Cet article ne repose sur aucune donnée, aucun client et aucun résultat de BOVO. Il lit des pages publiques (pub.dev, GitHub, documentations officielles, ARCEP Bénin) ; ce qui relève de notre raisonnement est écrit comme tel. Nous n'avons exécuté aucun de ces paquets pour cet article : nous n'avons pas mesuré de performance sur un téléphone.

Pourquoi le hors ligne compte au Bénin

L'observatoire de la téléphonie mobile de l'ARCEP Bénin pour le quatrième trimestre 2025, relu le 7 novembre 2026, donne 18 178 786 abonnements mobiles actifs, dont 7 936 967 en 2G, 3 379 322 en 3G et 6 862 497 en 4G. Notre calcul sur ces chiffres : la 4G représente environ 38 % des abonnements, la 2G environ 44 %.

Ce que ce tableau ne dit pas : un abonnement n'est pas une personne, il ne dit rien de la couverture là où votre client se trouve, ni de la stabilité d'une connexion. Notre lecture, qui reste un raisonnement : une application qui ne fonctionne qu'avec une bonne connexion s'adresse à une partie seulement du public, et une coupure en pleine saisie arrive aussi sur un réseau 4G. Le mode hors ligne sert d'abord à ne pas perdre ce que l'utilisateur vient de saisir.

Ce que contient « hors ligne »

La page officielle de Flutter sur l'offline-first (mise à jour affichée : 5 mai 2026, pour Flutter 3.47) distingue plusieurs niveaux, qui n'ont pas le même coût :

• Lecture avec repli local : on tente le réseau, et si l'appel échoue, on lit la copie locale.
• Lecture locale d'abord : on affiche la copie locale, puis on la rafraîchit depuis le serveur, par exemple avec un Stream qui émet deux fois.
• Écriture en ligne seulement : l'utilisateur ne peut modifier que connecté. La page signale que le hors ligne ne vaut alors que pour la lecture.
• Écriture locale d'abord : on enregistre en local, puis on tente d'envoyer. La page précise que si l'envoi échoue, la base locale et le serveur ne sont plus synchronisés.

Le dernier niveau est le plus utile pour un utilisateur, et le plus exigeant pour l'équipe : il faut une synchronisation. La page propose un indicateur synchronized sur chaque enregistrement et une tâche périodique (l'exemple utilise un Timer de cinq minutes), avec le plugin workmanager pour une exécution en arrière-plan. Elle avertit que le travail en arrière-plan peut vider la batterie et que certains appareils le limitent. Elle ne parle ni de conflits (le mot n'y figure pas) ni de doublons : nous y revenons plus bas.

L'état de maintenance, lu le 7 novembre 2026

Les valeurs viennent de l'API publique de pub.dev et de l'API GitHub, lues le 7 novembre 2026. Elles bougent : une version peut sortir le jour même, et c'est le cas pour hive_ce. « Éditeur vérifié » signifie que le paquet est rattaché à un éditeur vérifié sur pub.dev. Les « likes » mesurent la popularité, pas la qualité : hive a le plus grand nombre de likes de ce tableau, avec une dernière version stable de 2022.

Ce que chaque ligne ne dit pas, et que nous avons relu :

• Isar. Le README du paquet décrit une base NoSQL asynchrone avec index composites et recherche plein texte. La liste des versions de pub.dev montre une préversion 4.0.0-dev.14 du 21 août 2023 et pas de 4.0 stable. Le dépôt n'est pas archivé. Nous ne savons pas pourquoi la version 4 n'est pas sortie.
• isar_community. Son README dit que le dépôt est un fork « focusing primarily on bug fixes and small updates for version 3 ». Les paquets ont d'autres noms (isar_community, isar_community_flutter_libs, isar_community_generator) : on ne remplace donc pas Isar par une simple mise à jour de version, il faut changer les dépendances et les imports. Nous n'avons pas testé la migration.
• Hive. Le README GitHub (dépôt isar/hive, ancien hivedb/hive) montre hive: ^4.0.0 dans son exemple, mais la liste des versions de pub.dev ne contient que des préversions 4.0.0-dev (la dernière date du 25 août 2023) en plus de la 2.2.3. Le site de documentation d'origine, docs.hivedb.dev, affichait le 7 novembre 2026 une page « For Sale » de revendeur de domaine, pas de documentation.
• hive_ce. Son README la décrit comme « a spiritual continuation of Hive v2 », avec des adaptateurs générés, IsolatedHive et la prise en charge de Flutter web WASM. Sa documentation est sur docs.hive.isar.community. C'est un projet communautaire récent, avec 574 likes contre 6 263 pour hive : son avenir dépend de ses mainteneurs, comme celui de tout fork.
• sqflite et sembast. Les deux sont publiés par tekartik.com et mis à jour en octobre et novembre 2026. sqflite expose SQLite avec des requêtes écrites à la main ; le README de sembast indique que toute la base tient dans un fichier unique et est « loaded in memory when opened ».

Modèle de données : ce que chacun impose

Drift est une bibliothèque relationnelle. Sa page de présentation dit qu'elle est construite sur des bibliothèques comme sqlite3 et sqflite, avec des requêtes typées, des flux qui se mettent à jour quand les données changent, des transactions. La page d'installation demande drift, drift_flutter, path_provider, plus drift_dev et build_runner en dépendances de développement, et un générateur de code lancé par dart run build_runner build. Une table se déclare ainsi dans la documentation :

class TodoItems extends Table {
  IntColumn get id => integer().autoIncrement()();
  TextColumn get title => text().withLength(min: 6, max: 32)();
  TextColumn get content => text().named('body')();
  DateTimeColumn get createdAt => dateTime().nullable()();
}

(exemple de la page d'installation de Drift, consultée le 7 novembre 2026). Le coût : une étape de génération de code et un apprentissage de SQL. L'avantage : des relations, des index et des requêtes qui s'expriment en une fois.

Isar stocke des objets annotés @collection, sans table à écrire en SQL. Le modèle est plus direct pour des objets autonomes. La page « Limitations » de isar.dev donne des plafonds : sur la machine virtuelle, un objet est limité à 16 Mo, et seuls les 1 024 premiers octets d'une chaîne servent à un préfixe de recherche. Elle liste aussi des limites sur le web, car Isar s'y appuie sur IndexedDB.

Hive est un dictionnaire persistant : des « boxes », des clés, des valeurs. La documentation de Hive CE (« When to use Hive ») dit elle-même que si vos données ont des relations complexes et reposent sur des index et des requêtes complexes, il vaut mieux envisager SQLite. Sa page « Modelling data » indique que le tri et le filtrage se font en Dart, sur la collection chargée. Le README de hive_ce précise que Hive CE garde en mémoire toutes les valeurs d'une box ouverte (les « lazy boxes » ne gardent que les clés). Son tableau de benchmark, réalisé par les auteurs sur un MacBook Pro M3 Max et non sur un téléphone, indique un pic de mémoire de 481 Mo à l'ouverture d'une box d'un million de valeurs, contre environ 1 Mo pour Drift dans le même tableau. Un million de lignes n'est pas le cas d'un carnet de commandes de PME, mais la logique compte : plus la base grossit, plus le choix « tout en mémoire » coûte.

Un détail du README de hive_ce touche directement au hors ligne : une écriture est lisible tout de suite, mais « a write can be lost if the process is killed before its future completes ». Sur la machine virtuelle, flush() attend l'écriture sur le disque. Notre lecture : pour une commande saisie hors ligne, attendez la fin de l'écriture avant de dire à l'utilisateur que c'est enregistré.

Migrations : le point qui fait la différence dans deux ans

Une application hors ligne a des données chez des utilisateurs que vous ne pouvez pas réinitialiser. Chaque changement de modèle exige donc une migration qui marche.

• Drift. La page des migrations décrit la commande dart run drift_dev make-migrations, qui garde un instantané de chaque version du schéma, génère un fichier d'étapes (database.steps.dart) et un fichier de test. Dans la base, on augmente schemaVersion et on écrit chaque étape :

return MigrationStrategy(
  onUpgrade: stepByStep(
    from1To2: (m, schema) async {
      await m.createTable(schema.groups);
    },
  ),
);

(forme tirée de l'exemple de la documentation, abrégée). La page qualifie les migrations manuelles d'« error-prone » et recommande la commande. Elle signale aussi qu'en développement on peut effacer les données de l'application et la réinstaller.

• Isar. La recette « Data migration » dit qu'Isar migre automatiquement le schéma quand on ajoute ou retire des collections, des champs ou des index, mais ne propose pas de solution intégrée pour migrer les données. Son exemple stocke un numéro de version dans shared_preferences et applique soi-même la transformation. La page ne dit pas à quelle version d'Isar elle se rapporte, et son code utilise une API (openAsync) que nous n'avons pas rapprochée du paquet 3.1.0+1 : n'en copiez pas le code sans le vérifier.
• Hive et hive_ce. Il n'y a pas de schéma. La documentation des adaptateurs de types dit que chaque type porte un typeId unique, et que « your changes have to be compatible to previous versions of the box ». Rien dans les pages lues ne décrit d'outil de test de migration. Sur ce point, la discipline est donc entièrement du côté de l'équipe.
• sqflite. Il gère la version à l'ouverture (onCreate, onUpgrade) et fournit un exemple de migration ; les instructions SQL restent à écrire à la main.

Synchroniser avec le serveur : trois mécanismes à décider

La documentation de Flutter donne la forme générale. Le reste est de la conception, et nous l'écrivons comme tel : ce qui suit est notre raisonnement, pas un standard Flutter ni un comportement mesuré.

1. Une file d'envoi (outbox). Quand l'utilisateur valide, l'application écrit dans une seule transaction la donnée métier et une ligne « à envoyer » qui décrit l'opération. La page des transactions de Drift rappelle que toutes les requêtes d'une transaction doivent être attendues (await), sans quoi elles peuvent s'exécuter après la fermeture de la transaction, avec risque de perte de données ou de plantage. Une ligne de file contient en principe : un identifiant d'opération, le type d'opération, les données, un nombre d'essais, la date du dernier essai et un état. Un envoi réussi la marque « envoyée » ; un échec la laisse, avec une attente plus longue au prochain passage.

2. Une clé d'idempotence par opération. Si le réseau coupe après que le serveur a reçu la requête et avant que l'application ait reçu la réponse, l'application ne sait pas si l'opération a eu lieu. Elle renverra donc la même requête, et le serveur doit reconnaître le doublon. L'identifiant d'opération généré sur l'appareil sert de clé. Le brouillon de l'IETF draft-ietf-httpapi-idempotency-key-header-08 (22 octobre 2026, statut de brouillon : ce n'est pas une norme) décrit un en-tête Idempotency-Key : la clé doit être unique et ne pas être réutilisée avec une autre charge utile, il recommande un UUID, et il prévoit une réponse 422 si la clé est réutilisée avec une charge différente et une réponse 409 si la requête d'origine est encore en cours de traitement. Si vous contrôlez le serveur, vous pouvez vous en inspirer ; si vous appelez l'API d'un tiers, vérifiez dans sa documentation s'il prend en charge une telle clé, car nous n'avons pas relu celle des agrégateurs sur ce point. Côté serveur, le même principe de déduplication est détaillé dans notre article sur les webhooks de paiement.

3. Une règle pour les conflits. La page Flutter n'en parle pas. Le conflit se produit quand deux appareils (ou un appareil et le tableau de bord) modifient le même enregistrement pendant que l'un est hors ligne. Les règles possibles, de la plus simple à la plus coûteuse :

• le dernier envoi gagne (simple, mais l'une des deux modifications disparaît en silence) ;
• un numéro de version par enregistrement : le serveur refuse une modification faite sur une version périmée, et l'application doit décider quoi faire (réafficher, fusionner, demander à l'utilisateur) ;
• des champs séparés pour des règles différentes : par exemple additionner des quantités plutôt que d'écraser un total.

Le bon choix dépend de la donnée. Un carnet de visites commerciales saisi par un seul agent n'a presque pas de conflits ; un stock modifié par plusieurs vendeurs en a. Nous ne connaissons pas de bibliothèque Flutter que nous aurions relue pour cet usage : cette logique est à écrire et à tester.

Cas à part : le paiement. Ne mettez pas dans la file hors ligne un ordre de paiement Mobile Money. Un paiement implique l'opérateur, une confirmation côté serveur et le recoupement décrit dans les articles sur les passerelles de paiement et les webhooks. Stockez la commande, lancez le paiement quand la connexion est revenue.

Comparatif honnête

Cette grille résume des pages lues, pas des tests. Elle ne contient aucune mesure de vitesse, car nous n'avons rien mesuré sur un téléphone.

Comment choisir

1. Vos données ont des relations (clients, commandes, lignes de commande) ? Partez d'une base relationnelle : Drift, ou sqflite si vous préférez écrire le SQL vous-même.
2. Vous stockez des réglages, un jeton, un petit cache ? Un dictionnaire persistant suffit. Hive CE est publié activement ; des solutions encore plus simples existent pour quelques réglages, que nous n'avons pas comparées ici.
3. Vous avez déjà une base Isar en production ? Ne réécrivez pas par principe. Évaluez isar_community sur une copie du projet : changement de dépendances, de générateur et d'imports. Prévoyez un test de lecture d'un fichier de base réel avant de promettre quoi que ce soit.
4. Vous attendez des mises à jour de modèle fréquentes ? Choisissez l'outil dont les migrations se testent : c'est aujourd'hui, dans les pages lues, un avantage documenté de Drift.
5. Vous devez synchroniser avec un serveur ? Quel que soit le paquet, prévoyez la file d'envoi, la clé d'idempotence et la règle de conflit avant d'écrire l'interface. Un mauvais choix de base se corrige ; une synchronisation mal pensée se corrige beaucoup plus difficilement une fois que les utilisateurs ont des données locales.

Ce que nous ne savons pas

• La vitesse et la consommation réelles sur des téléphones d'entrée de gamme. Le seul benchmark lu est publié par les auteurs de hive_ce et tourne sur un MacBook Pro M3 Max.
• La suite d'Isar. Nous ne savons pas si la version 4 sortira, ni si isar_community remplacera durablement le paquet d'origine.
• Les autres forks et alternatives. D'autres paquets existent (par exemple isar_plus, 1.3.9 d'août 2026, 48 likes) ; nous n'en avons vu que les métadonnées.
• Une bibliothèque de synchronisation. Nous n'avons pas évalué de moteur de synchronisation clé en main ; la conception décrite plus haut est notre raisonnement.
• Le comportement des API de paiement face à une clé d'idempotence. Non relu pour FedaPay, Kkiapay ou PayDunya dans cet article.
• La connectivité réelle des utilisateurs. L'ARCEP donne des abonnements par technologie, pas une couverture ni une qualité de service.
• Le Bénin à l'échelle d'un projet. Nous n'avons pas trouvé d'étude indépendante sur l'usage du mode hors ligne dans les applications béninoises.

Sources consultées le 7 novembre 2026

• pub.dev : drift, isar, isar_community, hive, hive_ce, sqflite, sembast (versions, dates, éditeurs et likes lus via l'API publique de pub.dev ; ces valeurs changent).
• GitHub : simolus3/drift, isar/isar, isar/hive, IO-Design-Team/hive_ce, isar-community/isar-community, tekartik/sqflite, tekartik/sembast.dart (dates du dernier push lues via l'API GitHub).
• Drift : accueil, installation, migrations, transactions (pages non datées).
• Isar : Data migration, Limitations (pages non datées).
• Hive CE : documentation et README du dépôt ; docs.hivedb.dev : page de revente de domaine observée le 7 novembre 2026.
• Flutter : Offline-first support (mise à jour affichée : 5 mai 2026).
• IETF : draft-ietf-httpapi-idempotency-key-header-08 (22 octobre 2026, brouillon).
• ARCEP Bénin : Observatoire de la téléphonie mobile, T4 2025.

Pour aller plus loin

Pour le budget et le calendrier d'un projet Flutter, voir le prix d'une application Flutter et comment créer une application mobile. Pour comparer Flutter à une autre technologie, Flutter ou React Native, et pour juger un prestataire, comment choisir une agence de développement mobile. Côté serveur, les webhooks de paiement Mobile Money traitent la même question des doublons.

Un projet d'application mobile avec mode hors ligne ? Découvrez notre agence Flutter.