backend/documentation/Cadrage_global_laverie_V1_V2.md

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.