Ajout documentation
This commit is contained in:
bastien
@@ -0,0 +1,191 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user