Laverie/mobile
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
920bed947ee5b0050a328fdc4b9b43e2e77466e1
mobile/documentation/CDC_App_Flutter_v2.md
T
bastien ffa463baf1 Ajout documentation
2026-07-04 22:48:14 +02:00

10 KiB
Raw Blame History

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

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

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.
Reference in New Issue View Git Blame Copy Permalink