Dedalia
Vos courses, sans tourner en rond
Liste de courses local-first en monorepo TypeScript, avec ajout intelligent par IA côté serveur et repli manuel toujours disponible.
Statut
V1 fonctionnelle, build Android en test fermé
Le périmètre V1 est couvert et le site vitrine est en ligne. Une build Android de test fermé a été préparée ; l'application n'est pas encore publiée sur les magasins.
Voir en ligne
Le problème
Une liste de courses est utilisée debout, dans un magasin, souvent avec un réseau instable. Elle doit donc fonctionner hors ligne sans discussion. Elle est aussi pénible à remplir : taper vingt produits un par un décourage l'usage. Dedalia répond aux deux : une base locale d'abord, et un ajout assisté pour peupler une liste en une phrase.
Mon rôle
Conception produit, architecture du monorepo, développement mobile et serveur, mise en place de la CI et des profils de build.
Captures
01 écransLes décisions qui ont façonné le produit.
L'IA assiste, elle ne bloque jamais
Si la fonction serveur n'est pas configurée ou indisponible, l'écran affiche l'IA comme indisponible et garde l'ajout manuel opérationnel. La fonctionnalité assistée ne devient jamais un point de panne.
Le résultat est groupé par rayon
L'objectif n'est pas d'avoir une liste, c'est de ne pas revenir sur ses pas dans le magasin.
Navigation allégée
Barre d'onglets réduite et hub « Plus » pour le reste, avec un accueil orienté action plutôt qu'un tableau de bord.
Premium sur la synchronisation, pas sur l’usage
L'application de base reste utilisable seule et hors ligne ; l'abonnement porte sur le cloud et les fonctions avancées.
Monorepo à logique métier isolée
Espaces de travail pnpm et Turborepo, avec un package `core` de logique pure — sans React Native ni backend — et un package `shared` de types et de contrats Zod portables.
Local-first via des repositories SQLite
La base locale SQLite est la source de vérité de l'usage courant ; la synchronisation cloud vient par-dessus, elle ne conditionne pas le fonctionnement.
Les clés de modèle restent côté serveur
L'appel au fournisseur d'IA passe par une fonction Supabase. L'application mobile ne détient qu'une clé publique, jamais une clé de fournisseur.
Une preview web pour valider visuellement
Un export web statique de l'application mobile, servi en local sur des gabarits de téléphone, permet une revue d'interface sans appareil ni simulateur.
Tests de base sur fichier SQLite réel
Les tests de repositories s'exécutent sur un fichier SQLite temporaire afin de vérifier réellement les contraintes relationnelles, plutôt que de simuler la base.
Contraintes
- Usage debout, en magasin, avec un réseau qui peut disparaître.
- Aucune clé de fournisseur d’IA embarquée dans l’application.
- Achats natifs impossibles à tester en preview web : ils exigent une build de développement.
- Une CI qui vérifie install, lint, typage, tests, build et format, sans déclencher de build magasin.
Stack
- React Native
- Expo Router
- TypeScript strict
- monorepo pnpm
- Turborepo
- SQLite
- Zod
- Supabase
- RevenueCat
- Vitest
- EAS Build
Ce que ce projet démontre
Structuration d’un monorepo où la logique métier ne dépend ni du framework, ni du backend.
Conception local-first assumée jusque dans la couche de persistance.
Intégration d’une fonctionnalité IA avec dégradation gracieuse plutôt que dépendance dure.
Chaîne de distribution mobile complète : SSO, abonnements, profils de build.