# 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(...); final establishmentsProvider = FutureProvider>(...); final establishmentDetailProvider = FutureProvider.family(...); final walletProvider = FutureProvider(...); final bookingsProvider = StateNotifierProvider(...); final washProvider = StateNotifierProvider(...); ``` ### 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.