Le moment où l’on veut simplement noter une tâche
DevFlow Studio part d’un besoin assez ordinaire : garder ensemble les tâches, les projets, les sessions de concentration et le journal technique. Quand une idée arrive ou qu’un travail reprend, je veux retrouver le contexte rapidement. Un outil d’organisation demande déjà un effort ; son premier usage ne devrait pas dépendre d’une étape qui n’aide pas encore à travailler.
Le cœur du workspace utilise donc IndexedDB avec Dexie. Les données principales commencent dans le navigateur, et l’application peut être utile avant la création d’un compte. Ce choix change davantage que le formulaire de connexion : il détermine où le produit lit son état et quelle place les services distants peuvent prendre ensuite.
Donner une adresse claire aux données
Une tâche n’est pas seulement une ligne à afficher. Elle appartient à un projet, possède un état et peut participer à plusieurs vues. Aujourd’hui, les tâches, les projets, le focus, le journal et les revues se croisent dans DevFlow. Si ces écrans ne racontent pas la même chose, la richesse de l’interface finit par produire de la confusion.
Je traite donc le stockage local comme la référence du workspace, plutôt que comme une copie provisoire d’un serveur. Les modèles typés, la validation et les tests m’aident à garder ces relations compréhensibles. Ils obligent à réfléchir aux transitions : qu’est-ce qui doit rester cohérent lorsqu’une tâche change de projet ou de statut, par exemple ?
Le cloud a besoin d’un contrat explicite
Supabase fait partie des fondations pour des capacités optionnelles d’identité et d’espace de travail. Sa présence ne signifie pas que les tâches ou les journaux sont automatiquement synchronisés. Mélanger ces deux idées rendrait le comportement difficile à expliquer : une personne ne devrait pas devoir deviner où ses données se trouvent après une connexion.
Une synchronisation future demanderait des règles précises. Imaginons une même tâche modifiée sur deux appareils : quelle version conserver, comment montrer une divergence et comment éviter une perte silencieuse ? Ce sont des questions de conception encore à traiter, pas des capacités que je présente comme acquises. Ajouter un compte ne répond pas à ces questions.
Conserver en local ne suffit pas à protéger
Les données deviennent importantes dès qu’elles contiennent plusieurs semaines de travail. Il faut alors penser aux changements de structure, à l’import, à l’export et à la récupération. Les outils de récupération font partie du projet, mais je ne veux pas confondre stockage local et garantie de conservation. Un emplacement de données n’est pas, à lui seul, une stratégie de sauvegarde.
Un exemple de vérification utile serait de préparer un workspace représentatif, d’en exporter le contenu, puis de contrôler ce qu’un import restitue. Les relations entre projets et tâches comptent autant que le nombre de lignes. Pour une migration, la question est similaire : retrouver les informations et le sens qu’elles avaient avant le changement.
Limiter ce que le produit promet
DevFlow est encore en développement actif. L’assistant de planification, les analyses locales et les vues quotidiennes doivent servir le même objectif : faciliter la reprise du travail. Une fonction peut sembler intéressante et compliquer ce parcours. Je dois donc regarder le coût qu’elle ajoute aux modèles, aux écrans et aux vérifications, au-delà de sa démonstration isolée.
Pour la suite, je préfère consolider ces parcours et les limites entre stockage local et services optionnels. Le choix local donne une direction claire, avec des obligations très concrètes. Il reste valable si l’application permet de comprendre ce qui est enregistré, ce qui peut être récupéré et ce qui n’est pas encore partagé entre appareils.