431 lines
10 KiB
Markdown
431 lines
10 KiB
Markdown
# Cahier des Charges — Application Utilisateur Mobile & Web
|
|
## Projet : Laverie Connectée — App Flutter
|
|
**Version :** 2.0
|
|
**Stack principale :** Flutter 3.x (Android / iOS / Web)
|
|
**Positionnement :** V1 démontrable, centrée sur les parcours critiques
|
|
|
|
---
|
|
|
|
## 1. Contexte & Objectifs
|
|
|
|
### 1.1 Objectif produit
|
|
Application grand public permettant aux utilisateurs de :
|
|
- localiser les laveries disponibles,
|
|
- consulter l'état des machines,
|
|
- recharger leur porte-monnaie,
|
|
- réserver un créneau,
|
|
- lancer un lavage,
|
|
- suivre l'historique de leurs opérations.
|
|
|
|
### 1.2 Objectif projet V1
|
|
La V1 doit être :
|
|
- démontrable rapidement,
|
|
- cohérente côté métier,
|
|
- simple à maintenir,
|
|
- compatible avec une future montée en version sans refonte majeure.
|
|
|
|
### 1.3 Contraintes
|
|
- support Android / iOS en priorité,
|
|
- support Web utilitaire possible, sans promesse d'expérience équivalente à une app web dédiée,
|
|
- mode hors-ligne limité aux consultations simples,
|
|
- conformité RGPD minimale dès la V1,
|
|
- intégration machine pouvant être simulée pour la démo.
|
|
|
|
---
|
|
|
|
## 2. Périmètre fonctionnel
|
|
|
|
### 2.1 MVP V1
|
|
- inscription / connexion,
|
|
- maintien de session,
|
|
- liste des laveries,
|
|
- détail d'une laverie,
|
|
- consultation des machines et de leur statut,
|
|
- wallet avec solde et historique simple,
|
|
- rechargement wallet,
|
|
- réservation d'un créneau,
|
|
- affichage des réservations,
|
|
- lancement d'un lavage,
|
|
- écran de lavage en cours,
|
|
- notifications transactionnelles,
|
|
- profil utilisateur,
|
|
- gestion simple des consentements.
|
|
|
|
### 2.2 V2 prévue
|
|
- fidélité,
|
|
- parrainage,
|
|
- abonnements,
|
|
- promotions marketing avancées,
|
|
- export de données,
|
|
- statistiques utilisateur plus poussées,
|
|
- expérience offline enrichie,
|
|
- recommandations de cycles.
|
|
|
|
### 2.3 Hors périmètre V1
|
|
- chat,
|
|
- avis,
|
|
- FAQ dynamique,
|
|
- IA / photo d'étiquette,
|
|
- moteur prédictif,
|
|
- marketing automation complexe.
|
|
|
|
---
|
|
|
|
## 3. Stack Technique
|
|
|
|
| Composant | Technologie | Version | Commentaire |
|
|
|-----------|-------------|---------|-------------|
|
|
| Framework UI | Flutter | 3.x | Base unique mobile + web |
|
|
| Langage | Dart | 3.x | Null-safety |
|
|
| State management | Riverpod | 2.x | Testable, clair |
|
|
| Navigation | GoRouter | 13.x | Routing déclaratif |
|
|
| HTTP | Dio | 5.x | Intercepteurs auth |
|
|
| Stockage sécurisé | flutter_secure_storage | 9.x | Tokens |
|
|
| Cache local | Hive | 2.x | Suffisant pour V1 |
|
|
| Push | firebase_messaging | 15.x | Android / iOS / Web |
|
|
| QR scan | mobile_scanner | 5.x | Scan machine |
|
|
| Paiement | flutter_stripe | 10.x | Si Stripe retenu en V1 |
|
|
| Géolocalisation | geolocator | 13.x | Recherche proximité |
|
|
| Cartographie | flutter_map + OSM | — | Coût faible |
|
|
| Crash reporting | Firebase Crashlytics | — | Monitoring mobile |
|
|
| Tests | flutter_test + integration_test | — | Couverture critique |
|
|
|
|
### 3.1 Remarque Web
|
|
Le support Flutter Web est accepté comme **surface utilitaire** pour V1. Il ne doit pas être présenté comme un site web marketing riche ou fortement orienté SEO.
|
|
|
|
---
|
|
|
|
## 4. Architecture applicative
|
|
|
|
### 4.1 Organisation recommandée
|
|
|
|
```
|
|
lib/
|
|
├── core/
|
|
│ ├── api/
|
|
│ ├── auth/
|
|
│ ├── cache/
|
|
│ ├── router/
|
|
│ ├── theme/
|
|
│ └── utils/
|
|
├── features/
|
|
│ ├── auth/
|
|
│ ├── establishments/
|
|
│ ├── machines/
|
|
│ ├── wallet/
|
|
│ ├── booking/
|
|
│ ├── wash/
|
|
│ ├── notifications/
|
|
│ └── profile/
|
|
└── main.dart
|
|
```
|
|
|
|
### 4.2 Principes
|
|
- séparation claire data / state / presentation,
|
|
- providers Riverpod par domaine,
|
|
- toute logique réseau centralisée,
|
|
- aucune règle métier critique uniquement côté client,
|
|
- compatibilité avec un mode démonstration si l'intégration machine n'est pas prête.
|
|
|
|
---
|
|
|
|
## 5. Authentification
|
|
|
|
### 5.1 Flux attendu
|
|
```text
|
|
Lancement app
|
|
→ lecture des tokens
|
|
→ si access token valide : accès direct
|
|
→ sinon tentative refresh
|
|
→ sinon retour login
|
|
```
|
|
|
|
### 5.2 Règles
|
|
- access token court,
|
|
- refresh token persistant,
|
|
- déconnexion complète si refresh invalide,
|
|
- aucun stockage de token sensible dans SharedPreferences.
|
|
|
|
### 5.3 Web
|
|
Sur Web, éviter `localStorage` pour les tokens. Si le backend le permet, privilégier une stratégie plus sûre à long terme. Pour V1, une stratégie simple et limitée peut être tolérée, mais elle doit être documentée comme compromis technique.
|
|
|
|
---
|
|
|
|
## 6. Parcours utilisateur V1
|
|
|
|
## 6.1 Onboarding / inscription
|
|
|
|
### Écrans
|
|
- Bienvenue
|
|
- Connexion
|
|
- Inscription
|
|
- Vérification email si activée en V1
|
|
|
|
### Champs d'inscription
|
|
- prénom
|
|
- nom
|
|
- email
|
|
- téléphone
|
|
- mot de passe
|
|
- date de naissance
|
|
- consentements RGPD
|
|
|
|
### Règles
|
|
- consentement traitement données obligatoire,
|
|
- consentements marketing et analytics séparés,
|
|
- validations simples mais strictes.
|
|
|
|
---
|
|
|
|
## 6.2 Laveries et machines
|
|
|
|
### Écran liste / carte
|
|
- liste des établissements,
|
|
- carte facultative si le délai est tendu,
|
|
- indicateur de disponibilité globale.
|
|
|
|
### Écran détail établissement
|
|
- nom, adresse, horaires,
|
|
- liste des machines,
|
|
- statut de chaque machine,
|
|
- prochain créneau disponible,
|
|
- CTA réservation,
|
|
- CTA lancement lavage.
|
|
|
|
### Statuts V1 affichés
|
|
- disponible,
|
|
- réservée,
|
|
- en cours,
|
|
- maintenance,
|
|
- hors ligne,
|
|
- erreur.
|
|
|
|
---
|
|
|
|
## 6.3 Wallet
|
|
|
|
### Écran wallet
|
|
- solde actuel,
|
|
- bouton recharger,
|
|
- dernières transactions,
|
|
- message si données en cache.
|
|
|
|
### Historique
|
|
- liste simple paginée,
|
|
- type,
|
|
- montant,
|
|
- date,
|
|
- libellé métier.
|
|
|
|
### Rechargement V1
|
|
Parcours recommandé :
|
|
1. saisie montant,
|
|
2. lancement du paiement,
|
|
3. retour app,
|
|
4. confirmation backend,
|
|
5. mise à jour solde.
|
|
|
|
### Contraintes V1
|
|
- montant min et max configurables,
|
|
- aucune confiance dans le seul retour client,
|
|
- affichage clair des états : en cours / confirmé / échoué.
|
|
|
|
---
|
|
|
|
## 6.4 Réservation
|
|
|
|
### Écran sélection de créneau
|
|
- choix date,
|
|
- créneaux disponibles,
|
|
- prix total,
|
|
- supplément réservation si applicable,
|
|
- indication pénalité no-show.
|
|
|
|
### Écran confirmation
|
|
- récapitulatif machine,
|
|
- créneau,
|
|
- prix,
|
|
- solde avant / après,
|
|
- bouton de confirmation.
|
|
|
|
### Écran mes réservations
|
|
- onglets à venir / passées,
|
|
- statut,
|
|
- actions : annuler, déplacer si autorisé.
|
|
|
|
### Règles UI
|
|
- si solde insuffisant, proposer rechargement,
|
|
- si réservation non déplaçable, expliquer pourquoi,
|
|
- afficher clairement les règles d'annulation.
|
|
|
|
---
|
|
|
|
## 6.5 Lavage
|
|
|
|
### Démarrage
|
|
Deux modes possibles selon intégration :
|
|
- scan QR,
|
|
- démarrage depuis une réservation active.
|
|
|
|
### Flux V1
|
|
1. identification machine,
|
|
2. vérification disponibilité,
|
|
3. affichage prix / programme si nécessaire,
|
|
4. confirmation utilisateur,
|
|
5. demande de démarrage,
|
|
6. affichage de l'état `en cours`.
|
|
|
|
### Écran lavage actif
|
|
- machine,
|
|
- laverie,
|
|
- heure de début,
|
|
- temps estimé restant si disponible,
|
|
- statut actualisé.
|
|
|
|
### Mode démo
|
|
Si aucune vraie intégration machine n'est disponible, un mode simulation doit permettre d'afficher un cycle complet crédible.
|
|
|
|
---
|
|
|
|
## 6.6 Notifications
|
|
|
|
### Notifications V1
|
|
- rechargement confirmé,
|
|
- réservation confirmée,
|
|
- rappel de créneau,
|
|
- lavage terminé,
|
|
- no-show détecté si applicable.
|
|
|
|
### Deep links
|
|
Les notifications doivent pouvoir ouvrir l'écran concerné :
|
|
- wallet,
|
|
- réservation,
|
|
- lavage,
|
|
- établissement.
|
|
|
|
---
|
|
|
|
## 6.7 Profil
|
|
|
|
### Écran profil
|
|
- informations personnelles,
|
|
- préférences de notification,
|
|
- consentements,
|
|
- déconnexion,
|
|
- suppression de compte si disponible en V1, sinon message préparant la V2.
|
|
|
|
---
|
|
|
|
## 7. Gestion d'état
|
|
|
|
### Providers principaux
|
|
```dart
|
|
final authProvider = StateNotifierProvider<AuthNotifier, AuthState>(...);
|
|
final establishmentsProvider = FutureProvider<List<Establishment>>(...);
|
|
final establishmentDetailProvider = FutureProvider.family<EstablishmentDetail, String>(...);
|
|
final walletProvider = FutureProvider<WalletView>(...);
|
|
final bookingsProvider = StateNotifierProvider<BookingsNotifier, BookingsState>(...);
|
|
final washProvider = StateNotifierProvider<WashNotifier, WashState>(...);
|
|
```
|
|
|
|
### Stratégie V1
|
|
- refresh manuel sur les écrans critiques,
|
|
- polling simple si nécessaire pour le lavage actif,
|
|
- éviter une architecture temps réel trop complexe pour la V1 si elle met en risque le planning.
|
|
|
|
---
|
|
|
|
## 8. Offline-first
|
|
|
|
### Ce qui est caché localement en V1
|
|
| Donnée | Cache |
|
|
|---|---|
|
|
| Solde wallet | Oui |
|
|
| Dernières transactions | Oui |
|
|
| Liste établissements | Oui |
|
|
| Réservations récentes | Oui |
|
|
| Disponibilité machine temps réel | Non |
|
|
|
|
### Règle
|
|
Le hors-ligne V1 est **consultatif**, pas transactionnel.
|
|
|
|
---
|
|
|
|
## 9. Sécurité
|
|
|
|
### 9.1 Stockage
|
|
- tokens en stockage sécurisé,
|
|
- aucune donnée sensible en clair,
|
|
- purge des tokens en déconnexion.
|
|
|
|
### 9.2 Réseau
|
|
- HTTPS obligatoire,
|
|
- timeouts définis,
|
|
- retry mesuré,
|
|
- certificate pinning seulement si tu es sûr de pouvoir l'opérer correctement, sinon à repousser plutôt que mal implémenter.
|
|
|
|
### 9.3 QR code
|
|
- le QR seul ne déclenche jamais directement un lavage,
|
|
- validation serveur obligatoire,
|
|
- contrôle de cohérence utilisateur / machine / statut.
|
|
|
|
---
|
|
|
|
## 10. UX / performance
|
|
|
|
### Priorités V1
|
|
- écrans rapides,
|
|
- états de chargement propres,
|
|
- erreurs compréhensibles,
|
|
- navigation simple,
|
|
- pas d'animations complexes non essentielles.
|
|
|
|
### À éviter en V1 si délai serré
|
|
- sur-optimisation visuelle,
|
|
- offline avancé,
|
|
- temps réel sophistiqué,
|
|
- effets UI coûteux sans valeur métier.
|
|
|
|
---
|
|
|
|
## 11. Mode démonstration
|
|
|
|
L'application doit pouvoir être connectée à un environnement de démonstration permettant :
|
|
- données multi-laveries fictives,
|
|
- wallet de test,
|
|
- réservations simulées,
|
|
- cycles machine simulés,
|
|
- notifications de test.
|
|
|
|
Ce mode doit être suffisamment crédible pour une démonstration client de fin de mois.
|
|
|
|
---
|
|
|
|
## 12. Tests
|
|
|
|
| Type | Outil | Portée |
|
|
|------|-------|--------|
|
|
| Unitaires | flutter_test | Providers, validateurs, formatters |
|
|
| Widgets | flutter_test | Écrans clés |
|
|
| Intégration | integration_test | Connexion, wallet, réservation, lavage |
|
|
|
|
### Parcours critiques à couvrir
|
|
1. connexion utilisateur,
|
|
2. affichage des laveries,
|
|
3. rechargement wallet,
|
|
4. réservation d'un créneau,
|
|
5. démarrage d'un lavage en mode simulation,
|
|
6. réception d'une notification.
|
|
|
|
---
|
|
|
|
## 13. Livrables attendus
|
|
|
|
- code source Flutter,
|
|
- configuration dev / staging / prod,
|
|
- README d'installation,
|
|
- configuration push,
|
|
- build de démonstration,
|
|
- dataset ou compte de démo,
|
|
- couverture de tests sur les flux critiques.
|