La Bête est un projet d’application narrative interactive, amorcé comme une exploration créative autour du récit, du jeu et de l’expérience utilisateur.
L’objectif initial était de concevoir une plateforme permettant de créer et de vivre des histoires interactives, où le lecteur devient acteur du récit. Le projet m’a permis d’expérimenter différentes idées liées à la structure narrative, à la progression, à la persistance des choix et à la conception d’outils de création. Le projet est actuellement inachevé et en pause. Il demeure toutefois un terrain d’expérimentation important, tant sur le plan technique que conceptuel, et a influencé ma façon d’aborder la conception d’applications plus concrètes et orientées métier. Certaines idées explorées dans La Bête trouvent aujourd’hui un écho plus pragmatique dans d’autres projets, notamment dans la manière de concevoir des interfaces simples, évolutives et centrées sur l’utilisateur.
Pour essayer La Bête, rendez-vous sur le site (non sécurisé…), créez un compte et allez vers le bois. Le village n’est pas encore créé mais vous pourrez quand même tester le petit moteur de combat.
Quand j’ai commencé à travailler sur le mode hors ligne de Farmitrax, une application web de gestion de ferme laitière, j’ai rapidement compris que le choix de la couche de stockage locale allait être critique.
Connexion instable, utilisateurs peu techniques, données sensibles, besoin de fiabilité : ce n’était pas un “offline sympa”, mais une vraie contrainte métier.
Dans cet article, je partage mon retour d’expérience avec Dexie : pourquoi je l’ai choisi, ce que ça m’a apporté, les pièges que j’ai rencontrés, et dans quels cas je le recommanderais (ou pas).
Le contexte : pourquoi le offline était non négociable
Producteurs en zone rurale
Connexion cellulaire intermittente
Saisie de données sur le terrain (étable, pâturage, déplacements)
Impossible de dire à un utilisateur : « reviens quand tu auras du réseau »
Le offline n’était pas un bonus, c’était une condition de survie de l’application.
Pourquoi Dexie plutôt que l’IndexedDB “pure”
IndexedDB est puissante mais pénible
API verbeuse
Callbacks / promesses difficiles à lire
Risque d’erreurs silencieuses
Schéma déclaratif
Syntaxe fluide
Gestion des versions de base
Performance très correcte pour des volumes raisonnables
Dexie apporte une couche d’abstraction très propre : schémas clairs, requêtes lisibles, transactions compréhensibles. Pour un développeur solo, ça compte énormément.
Ce que Dexie fait très bien en pratique
Cache structuré des données métier
Lecture instantanée hors ligne
Réactivité de l’interface
Développement plus rapide qu’avec IndexedDB natif
Pour le CRUD local pur, Dexie est un vrai plaisir.
Là où Dexie commence à montrer ses limites
Synchronisation
Dexie ne résout pas la sync serveur
File d’attente, conflits, retries → à faire soi-même
🔹 Logique métier
Le offline force à repousser de la logique côté client
Risque de divergence si mal conçu
🔹 Debugging
IndexedDB reste opaque
Debug plus lent que du SQL classique
Dexie simplifie IndexedDB, mais ne supprime pas la complexité conceptuelle du offline.
Ce que j’ai appris (et referais différemment)
Définir le périmètre offline exact dès le départ
Séparer clairement :
données locales
état de synchronisation
source de vérité
Ne pas sous-estimer le coût mental du offline
Le offline, ce n’est pas une feature. C’est une architecture.
À qui je recommande Dexie (et à qui non)
✅ Je recommande Dexie si :
Application métier
Développeur solo ou petite équipe
Besoin offline réel
Données structurées
❌ Je serais plus prudent si :
Synchronisation complexe multi-utilisateurs
Besoin temps réel strict
Équipe backend très lourde
Conclusion
Dexie.js a été un excellent choix pour mon cas d’usage, mais ce n’est pas une solution magique.
Il faut accepter que le offline impose des compromis architecturaux, et Dexie rend ces compromis plus lisibles, pas inexistants.
Si vous construisez une application web sérieuse avec de vraies contraintes terrain, Dexie mérite clairement sa place dans votre boîte à outils.
