192 lines
4.2 KiB
Markdown
192 lines
4.2 KiB
Markdown
# Cadrage global — Laverie Connectée
|
|
|
|
## 1. Vision produit
|
|
|
|
Le produit vise à centraliser la gestion de plusieurs laveries dans une même plateforme, avec deux populations principales :
|
|
|
|
- **les utilisateurs finaux**, qui consultent les laveries, rechargent leur wallet, réservent un créneau et lancent des lavages ;
|
|
- **les exploitants**, qui pilotent uniquement leurs propres établissements, leurs machines et leurs indicateurs.
|
|
|
|
La première version doit être **démontrable rapidement**, avec une base technique suffisamment propre pour permettre une V2 sans refonte majeure.
|
|
|
|
---
|
|
|
|
## 2. Périmètre
|
|
|
|
### MVP V1
|
|
|
|
- authentification utilisateur
|
|
- authentification exploitant
|
|
- multi-laveries
|
|
- cloisonnement des exploitants par organization
|
|
- consultation des établissements et machines
|
|
- wallet + rechargement
|
|
- réservation de créneau
|
|
- lancement d'un lavage
|
|
- historique simple des transactions, réservations et lavages
|
|
- dashboard exploitant simple
|
|
- tarification simple
|
|
- intégration machine simulable
|
|
- audit minimal
|
|
- statistiques journalières simples
|
|
|
|
### V2
|
|
|
|
- fidélité
|
|
- parrainage
|
|
- abonnements
|
|
- promotions avancées
|
|
- campagnes marketing
|
|
- exports avancés
|
|
- analytics détaillées
|
|
- RGPD enrichi
|
|
- modes d'intégration machine plus complets
|
|
|
|
### Hors périmètre V1
|
|
|
|
- chat
|
|
- avis
|
|
- FAQ dynamique
|
|
- IA / lecture photo étiquette
|
|
- moteur prédictif
|
|
- interfaçage matériel bas niveau
|
|
|
|
---
|
|
|
|
## 3. Architecture métier cible
|
|
|
|
### Entités principales
|
|
|
|
- `organizations`
|
|
- `establishments`
|
|
- `supervisors`
|
|
- `users`
|
|
- `machines`
|
|
- `machine_integrations`
|
|
- `machine_commands`
|
|
- `machine_events`
|
|
- `wallets`
|
|
- `payment_transactions`
|
|
- `wallet_transactions`
|
|
- `bookings`
|
|
- `washes`
|
|
- `pricing_rules`
|
|
- `promotions`
|
|
- `push_notifications`
|
|
- `audit_logs`
|
|
- `daily_establishment_stats`
|
|
|
|
### Cloisonnement
|
|
|
|
- un exploitant ne voit que les données de son `organization_id`
|
|
- un manager peut être limité à un seul établissement
|
|
- un `platform_admin` peut avoir une vue globale
|
|
|
|
---
|
|
|
|
## 4. Stratégie d'intégration machine
|
|
|
|
Le système doit être pensé comme une **couche d'intégration** entre le métier laverie et un fournisseur technique externe.
|
|
|
|
### Modes supportés
|
|
|
|
- **push** : le partenaire envoie des événements à notre API
|
|
- **pull** : notre backend appelle son API
|
|
- **hybrid** : combinaison des deux
|
|
- **simulated** : mode démo
|
|
|
|
### Principe recommandé
|
|
|
|
Pour la V1 et la démo, implémenter d'abord un **provider simulé**.
|
|
|
|
Cela permet de démontrer :
|
|
- le lancement d'un lavage,
|
|
- le passage machine en cours,
|
|
- la fin de cycle,
|
|
- les mises à jour du dashboard,
|
|
- les notifications,
|
|
|
|
sans dépendre du matériel réel.
|
|
|
|
---
|
|
|
|
## 5. Démo de fin de mois
|
|
|
|
### Parcours utilisateur
|
|
|
|
1. connexion
|
|
2. affichage des laveries
|
|
3. consultation des machines
|
|
4. rechargement wallet
|
|
5. réservation d'un créneau
|
|
6. lancement d'un lavage
|
|
7. cycle simulé
|
|
8. notification de fin
|
|
9. historique mis à jour
|
|
|
|
### Parcours exploitant
|
|
|
|
1. connexion exploitant
|
|
2. dashboard limité à ses laveries
|
|
3. visualisation d'une machine qui passe en `running`
|
|
4. évolution d'un KPI
|
|
5. modification d'un tarif
|
|
|
|
---
|
|
|
|
## 6. Backlog priorisé
|
|
|
|
### Sprint 1 — Fondations
|
|
|
|
- modèle organizations / establishments / supervisors
|
|
- auth utilisateur
|
|
- auth exploitant
|
|
- seeders de démo
|
|
- policies de cloisonnement
|
|
|
|
### Sprint 2 — Coeur métier
|
|
|
|
- machines
|
|
- wallet
|
|
- rechargement
|
|
- réservation
|
|
- lavages
|
|
- provider machine simulé
|
|
|
|
### Sprint 3 — Interfaces
|
|
|
|
- écrans Flutter MVP
|
|
- back-office MVP
|
|
- dashboard simple
|
|
- historique simple
|
|
|
|
### Sprint 4 — Démo et stabilisation
|
|
|
|
- audit minimal
|
|
- notifications
|
|
- agrégats journaliers
|
|
- nettoyage UX
|
|
- dataset final de démonstration
|
|
|
|
---
|
|
|
|
## 7. Risques à surveiller
|
|
|
|
- dérive de périmètre côté client
|
|
- ambiguïté sur l'intégration machine réelle
|
|
- sous-estimation de la partie paiement
|
|
- dette technique si trop d'optimisation UI inutile en V1
|
|
|
|
---
|
|
|
|
## 8. Règle de pilotage recommandée
|
|
|
|
Toute fonctionnalité V1 doit répondre à au moins un de ces critères :
|
|
|
|
- utile à la démonstration,
|
|
- nécessaire au fonctionnement métier minimal,
|
|
- nécessaire à la sécurité / traçabilité,
|
|
- nécessaire pour éviter une refonte en V2.
|
|
|
|
Si elle ne remplit aucun de ces critères, elle doit être repoussée.
|