5.2 Diagrammes de Séquence - REWAPP Documentation

1

INTRODUCTION

1.1 Objectif du Document

Ce document présente les diagrammes de séquence des principaux flux métier de l'application REWAPP. Ces diagrammes décrivent les interactions temporelles entre les différents composants du système pour chaque processus critique.

1.2 Portée

Les diagrammes couvrent les cinq flux fondamentaux :

Inscription d'un nouveau client
Liaison de compte OpenBanking via Plaid
Détection automatique des transactions et crédit de points
Génération de QR code pour paiement commerçant
Scan du QR code et débit des points

1.3 Public Cible

Équipe de développement
Architectes techniques
Équipe QA pour validation des scénarios
Product Owners pour compréhension des flux

2

CONVENTIONS ET NOTATION

2.1 Notation PlantUML

Tous les diagrammes de ce document utilisent la notation PlantUML standard pour les diagrammes de séquence.

2.2 Symboles Utilisés

Légende des symboles

Symbole	Signification
`actor`	Utilisateur humain (Client, Partenaire, Admin)
`participant`	Composant système (Service, API, Base de données)
`->`	Message synchrone
`-->`	Réponse
`alt/else`	Cas alternatifs
`opt`	Bloc optionnel
`loop`	Boucle
`note`	Annotation explicative

2.3 Conventions de Nommage

Acteurs et Composants

Acteur/Composant	Description
Client	Utilisateur final de l'application mobile
Partenaire	Commerçant utilisant le dashboard partenaire
App Mobile	Application Angular + Ionic iOS/Android
API Gateway	Point d'entrée Kong/CapRover reverse proxy
Auth Service	Service NestJS d'authentification
User Service	Service de gestion des utilisateurs
Banking Service	Service d'intégration OpenBanking (Plaid)
Transaction Service	Service de gestion des transactions
Points Service	Service de gestion des points de fidélité
QR Service	Service de génération et validation QR codes
Notification Service	Service d'envoi de notifications (FCM)
PostgreSQL	Base de données principale
Redis	Cache et gestion des sessions

3

DIAGRAMME 5.2.1 - INSCRIPTION CLIENT

3.1 Acteurs et Composants

Participants au flux

Acteur/Composant	Rôle
Client	Nouvel utilisateur souhaitant s'inscrire
App Mobile	Interface de saisie des informations
API Gateway	Validation et routage des requêtes
Auth Service	Gestion authentification et création compte
User Service	Persistance des données utilisateur
PostgreSQL	Stockage des informations
Redis	Gestion des sessions et tokens
Notification Service	Envoi email de bienvenue

3.2 Flux Nominal (PlantUML)

Diagramme de Séquence - Inscription Client

PlantUML


  BackgroundColor8F5E9
  BorderColor
}

  BackgroundColor3E0
  BorderColor9800
}

  BackgroundColor3F2FD
  BorderColor
}

title Inscription Client - REWAPP

actor C as "Client"
participant APP as "App Mobile"
participant GW as "API Gateway"
participant AUTH as "Auth Service"
participant USER as "User Service"
database DB as "PostgreSQL"
database REDIS as "Redis"
participant NOTIF as "Notification"

== Saisie des Informations ==
C -> APP : Ouvre ecran inscription
APP -> C : Affiche formulaire
C -> APP : Saisit informations + CGU

== Validation ==
APP -> APP : Validation locale

== Envoi Backend ==
APP -> GW : POST /api/v1/auth/register
GW -> GW : Rate limiting check
GW -> AUTH : Route vers Auth Service

== Verification Unicite ==
AUTH -> USER : Verifie email existant
USER -> DB : SELECT FROM users
DB --> USER : Resultat
USER --> AUTH : Email disponible

alt Email disponible
    AUTH -> AUTH : Hash password Bcrypt
    AUTH -> USER : Creer utilisateur
    USER -> DB : INSERT INTO users
    DB --> USER : User cree
    USER --> AUTH : User cree

    AUTH -> AUTH : Genere JWT Access Token
    AUTH -> AUTH : Genere Refresh Token
    AUTH -> REDIS : Stocke refresh token
    REDIS --> AUTH : OK

    AUTH --> GW : 201 Created
    GW --> APP : Reponse succes
    APP -> APP : Stocke tokens
    APP --> C : Ecran bienvenue

    AUTH ->> NOTIF : Email bienvenue
    NOTIF ->> C : Email Bienvenue REWAPP

else Email deja utilise
    AUTH --> GW : 409 Conflict
    GW --> APP : Erreur 409
    APP --> C : Email deja utilise
end

3.3 Cas Alternatifs et Erreurs

Gestion des erreurs

Code Erreur	Condition	Message Utilisateur	Action
400	Format email invalide	"Adresse email invalide"	Correction formulaire
400	MDP < 8 caractères	"Mot de passe trop faible (min. 8 caractères)"	Saisir MDP plus fort
409	Email déjà enregistré	"Cette adresse email est déjà utilisée"	Connexion ou récupération MDP
429	Rate limit atteint	"Trop de tentatives, réessayez dans 5 min"	Attendre
500	Erreur interne	"Une erreur est survenue, réessayez"	Retry avec backoff

3.4 Règles de Validation

Email : format RFC 5322, domaines jetables bloqués
Mot de passe : minimum 8 caractères, 1 majuscule, 1 chiffre
Nom/Prénom : 2-50 caractères, lettres et accents uniquement
CGU : acceptation obligatoire (checkbox)
Âge minimum : 18 ans (date de naissance optionnelle)

4

DIAGRAMME 5.2.2 - LIAISON COMPTE OPENBANKING

4.1 Acteurs et Composants

Participants au flux OpenBanking

Acteur/Composant	Rôle
Client	Utilisateur souhaitant lier son compte OpenBanking
App Mobile	Interface d'initiation
API Gateway	Routage sécurisé
Banking Service	Orchestration flux OpenBanking
Plaid API	Fournisseur OpenBanking (agrégateur)
Banque Client	Établissement bancaire de l'utilisateur
PostgreSQL	Stockage tokens chiffrés
Notification Service	Confirmation liaison

4.2 Flux Nominal (PlantUML)

Liaison Compte OpenBanking


title Liaison Compte OpenBanking - REWAPP

actor C as "Client"
participant APP as "App Mobile"
participant GW as "API Gateway"
participant BANK as "Banking Service"
participant BI as "Plaid"
participant BANQUE as "Banque Client"
database DB as "PostgreSQL"
participant NOTIF as "Notification"

== Initiation Liaison ==
C -> APP : Clic Lier mon compte OpenBanking
APP -> GW : POST /api/v1/banking/connect/init
GW -> BANK : Initialise connexion

== Generation URL Auth ==
BANK -> BI : POST /connect/init
BI --> BANK : connectUrl connectionId
BANK -> DB : INSERT banking_connections
DB --> BANK : OK
BANK --> GW : connectUrl
GW --> APP : URL de connexion

== Redirection Banque ==
APP -> C : Ouvre WebView securisee
C -> BI : Navigue vers connectUrl
BI -> C : Affiche selection banque
C -> BI : Selectionne sa banque
BI -> BANQUE : Redirige vers auth banque

== Auth Bancaire ==
BANQUE -> C : Formulaire connexion
C -> BANQUE : Saisit identifiants
BANQUE -> BANQUE : Valide credentials
BANQUE -> C : Demande autorisation
C -> BANQUE : Autorise consentement PSD2

== Callback Token ==
BANQUE --> BI : Code autorisation
BI -> BI : Echange code vs token
BI --> APP : Callback SUCCESS
APP -> GW : POST callback
GW -> BANK : Finalise connexion

== Stockage Securise ==
BANK -> BI : GET connections
BI --> BANK : accessToken accountId
BANK -> BANK : Chiffre token AES-256
BANK -> DB : UPDATE banking_connections ACTIVE
DB --> BANK : OK

== Config Webhooks ==
BANK -> BI : POST webhooks subscribe
BI --> BANK : Webhook configure

== Confirmation ==
BANK --> GW : 200 OK CONNECTED
GW --> APP : Confirmation
APP --> C : Compte OpenBanking lie avec succes

BANK ->> NOTIF : Notification async
NOTIF ->> C : Push Compte OpenBanking maintenant lie

4.3 Cas Alternatifs et Erreurs

Scénarios d'erreur OpenBanking

Scénario	Code	Description	Action
Auth banque échouée	401	Identifiants bancaires incorrects	Réessayer avec bons identifiants
Consentement refusé	403	Client refuse l'autorisation	Expliquer les bénéfices, reproposer
Banque non supportée	422	Établissement non couvert	Afficher liste banques compatibles
Session expirée	408	Timeout WebView (5 min)	Relancer le processus
Token invalide	502	Erreur côté Plaid	Support + retry automatique
Connexion déjà active	409	Compte OpenBanking déjà lié	Proposer déliaison/remplacement

4.4 Conformité et Sécurité

EXIGENCES RÉGLEMENTAIRES

PSD2 : Consentement explicite obligatoire, durée max 90 jours
RGPD : Données bancaires non stockées, uniquement tokens
Chiffrement : Tokens AES-256, clés en clés de chiffrement serveur
Révocation : Client peut révoquer à tout moment depuis l'app
Renouvellement : Refresh automatique avant expiration

5

DIAGRAMME 5.2.3 - DÉTECTION TRANSACTION

5.1 Acteurs et Composants

Participants au flux de détection

Acteur/Composant	Rôle
Plaid	Émetteur des webhooks transactions
Webhook Handler	Réception et validation des webhooks
Transaction Service	Traitement et enrichissement
Points Service	Calcul et crédit des points
Partner Service	Vérification éligibilité partenaire
Notification Service	Notification utilisateur
Redis	Cache taux cashback partenaires
Bull Queue	File d'attente traitement async

5.2 Flux Nominal (PlantUML)

Detection Transactions


title Detection Transactions - REWAPP

participant BI as "Plaid"
participant WH as "Webhook Handler"
queue "Bull Queue" as QUEUE
participant TXN as "Transaction Service"
participant PARTNER as "Partner Service"
participant POINTS as "Points Service"
database DB as "PostgreSQL"
database REDIS as "Redis"
participant NOTIF as "Notification"
actor C as "Client"

== Reception Webhook ==
BI -> WH : POST /webhooks/transactions
WH -> WH : Valide signature HMAC
WH -> WH : Verifie timestamp
WH --> BI : 200 OK

== Mise en Queue ==
WH -> QUEUE : Enqueue transaction

== Traitement Async ==
QUEUE -> TXN : Dequeue transaction
TXN -> TXN : Parse transaction

== Identification Partenaire ==
TXN -> PARTNER : Identifie partenaire
PARTNER -> REDIS : GET partner merchantId
REDIS --> PARTNER : Cache hit miss

alt Cache miss
    PARTNER -> DB : SELECT FROM partners
    DB --> PARTNER : Partenaire trouve
    PARTNER -> REDIS : SET partner EX 3600
end

PARTNER --> TXN : partnerId cashbackRate

== Verification Eligibilite ==
alt Partenaire actif eligible
    TXN -> TXN : Calcule montant cashback
    TXN -> POINTS : Credite points
    POINTS -> DB : BEGIN TRANSACTION
    POINTS -> DB : INSERT point_lots
    POINTS -> DB : UPDATE user_balances
    POINTS -> DB : COMMIT
    DB --> POINTS : OK
    POINTS --> TXN : Points credites

    TXN ->> NOTIF : Notification async
    NOTIF ->> C : Push notification FCM

else Partenaire non eligible
    TXN -> DB : INSERT transactions INELIGIBLE
end

5.3 Règles de Calcul des Points

RÈGLE FONDAMENTALE

1 point = 0,20€ — Points = Cashback ÷ 0.20

Paramètres de calcul

Paramètre	Valeur	Formule
Ratio de base	1 point = 0,20€	`points = cashback ÷ 0.20`
Taux commerçant	Variable (2-10%)	`cashback = montant × taux`
Taux Bronze	1% (bancaire, défaut)	`cashback × 0.01`
Taux Silver	2% (bancaire, défaut)	`cashback × 0.02`
Taux Gold	3% (bancaire, défaut)	`cashback × 0.03`
Taux Diamant	5% bancaire (défaut)	`cashback × 0.05`
Arrondi	Inférieur	`floor(points)`
Expiration	Désactivée (0 = jamais, configurable)	`—`

5.4 Cas d'Erreur et Retry

Stratégie de retry

Erreur	Action	Retry	Délai
Webhook invalide	Log + ignore	Non	-
Partenaire inconnu	Stocke en pending	Oui (1x)	24h
Erreur DB	Retry automatique	Oui (3x)	Backoff exponentiel
Points Service down	Requeue	Oui (5x)	1min, 5min, 15min, 1h, 6h

6

DIAGRAMME 5.2.4 - GÉNÉRATION QR CODE

6.1 Acteurs et Composants

Participants au flux QR

Acteur/Composant	Rôle
Client	Utilisateur générant le QR code
App Mobile	Interface de génération
API Gateway	Validation requête
QR Service	Génération et signature du QR code
Points Service	Vérification et blocage des points
Redis	Stockage temporaire QR code (15 min TTL)

6.2 Flux Nominal (PlantUML)

Generation QR Code


title Generation QR Code - REWAPP

actor C as "Client"
participant APP as "App Mobile"
participant GW as "API Gateway"
participant QR as "QR Service"
participant POINTS as "Points Service"
database DB as "PostgreSQL"
database REDIS as "Redis"

== Consultation Solde ==
C -> APP : Ouvre ecran Utiliser points
APP -> GW : GET /api/v1/points/balance
GW -> POINTS : Recupere solde
POINTS -> DB : SELECT balance
DB --> POINTS : balance 850
POINTS --> GW : balance 850 value 89 EUR
GW --> APP : Solde affiche
APP --> C : 850 points valeur 89 EUR

== Saisie Montant ==
C -> APP : Saisit montant 200 points
APP -> APP : Validation locale

== Demande Generation ==
APP -> GW : POST /api/v1/qr/generate
GW -> GW : Auth JWT
GW -> QR : Route vers QR Service

== Verification Solde ==
QR -> POINTS : Verifie disponibilite
POINTS -> DB : SELECT balance FOR UPDATE
DB --> POINTS : balance 850

alt Solde suffisant
    POINTS -> DB : UPDATE user_balances blocked
    DB --> POINTS : OK
    POINTS --> QR : Points bloques

    QR -> QR : Genere UUID unique
    QR -> QR : Calcule timestamp expiry
    QR -> QR : Construit payload JSON
    QR -> QR : Signe payload HMAC
    QR -> QR : Encode en QR code

    QR -> REDIS : SET qr EX 900
    REDIS --> QR : OK

    QR --> GW : 201 Created
    GW --> APP : QR code genere
    APP --> C : QR code plein ecran compteur 15 min

else Solde insuffisant
    POINTS --> QR : INSUFFICIENT_BALANCE
    QR --> GW : 400 Bad Request
    GW --> APP : Erreur
    APP --> C : Solde insuffisant
end

6.3 Structure du QR Code

Payload JSON du QR Code

Champ	Type	Description
`qr_id`	UUID v4	Identifiant unique du QR code
`user_id`	String (chiffré)	ID utilisateur (AES-256)
`points`	Integer	Nombre de points
`value`	Decimal	Valeur en euros (points × 0,200)
`created_at`	Timestamp	Date/heure génération
`expires_at`	Timestamp	Date/heure expiration (+15 min)
`signature`	String	HMAC-SHA256 du payload

6.4 Comportement Visuel du Compteur

Animation du compteur

Temps Restant	Couleur	Animation
15 min - 8 min	● Vert (#22C55E)	Statique
8 min - 1 min	● Orange (#F59E0B)	Clignotement lent
1 min - 0s	● Rouge (#EF4444)	Clignotement rapide + vibration

IMPORTANT

QR Code valide 15 minutes, usage UNIQUE. À l'expiration, les points sont automatiquement débloqués.

6.5 Cas d'Erreur

Gestion des erreurs QR

Code	Erreur	Message	Solution
400	INSUFFICIENT_BALANCE	"Solde insuffisant"	Réduire montant
400	BELOW_MINIMUM	"Minimum 10 points requis"	Augmenter montant
409	QR_ALREADY_ACTIVE	"Un QR code est déjà actif"	Attendre expiration
429	RATE_LIMITED	"Trop de QR générés"	Attendre 1 minute
500	GENERATION_ERROR	"Erreur de génération"	Réessayer

7

DIAGRAMME 5.2.5 - SCAN QR ET DÉBIT POINTS

7.1 Acteurs et Composants

Participants au flux de scan

Acteur/Composant	Rôle
Partenaire	Commerçant effectuant le scan
Client	Utilisateur dont les points sont débités
Dashboard Partenaire	Interface PWA de scan
API Gateway	Routage et authentification
QR Service	Validation et décodage QR
Points Service	Débit effectif des points
Transaction Service	Enregistrement transaction
Notification Service	Notification client et partenaire

7.2 Flux Nominal (PlantUML)

Scan QR et Debit Points


title Scan QR et Debit Points - REWAPP

actor P as "Partenaire"
actor C as "Client"
participant DASH as "Dashboard"
participant GW as "API Gateway"
participant QR as "QR Service"
participant POINTS as "Points Service"
participant TXN as "Transaction Service"
database REDIS as "Redis"
database DB as "PostgreSQL"
participant NOTIF as "Notification"

== Initiation Scan ==
P -> DASH : Clic Scanner QR
DASH -> DASH : Active camera
P -> DASH : Scanne QR code client

== Envoi Validation ==
DASH -> GW : POST /api/v1/qr/validate
GW -> GW : Auth partenaire JWT
GW -> QR : Route vers QR Service

== Decodage Verification ==
QR -> QR : Decode QR data
QR -> QR : Parse JSON payload
QR -> QR : Recalcule HMAC
QR -> QR : Compare signatures

alt Signature valide
    QR -> QR : Verifie expires_at

    alt QR valide non expire
        QR -> REDIS : GET qr
        REDIS --> QR : Donnees QR

        alt QR disponible
            QR -> POINTS : Debite points
            POINTS -> DB : BEGIN TRANSACTION
            POINTS -> DB : UPDATE point_lots
            POINTS -> DB : UPDATE user_balances
            POINTS -> DB : COMMIT
            DB --> POINTS : OK
            POINTS --> QR : Points debites

            QR -> REDIS : DEL qr
            REDIS --> QR : OK

            QR -> TXN : Enregistre transaction
            TXN -> DB : INSERT transactions
            DB --> TXN : Transaction creee
            TXN --> QR : OK

            QR --> GW : 200 OK SUCCESS
            GW --> DASH : Validation reussie
            DASH --> P : Paiement valide 200 pts

            QR ->> NOTIF : Notifie client async
            NOTIF ->> C : Push Paiement valide
            NOTIF ->> P : Push Paiement recu
        else QR deja utilise
            QR --> GW : 409 QR_ALREADY_USED
            DASH --> P : QR deja scanne
        end
    else QR expire
        QR --> GW : 410 QR_EXPIRED
        DASH --> P : QR expire
    end
else Signature invalide
    QR --> GW : 400 INVALID_SIGNATURE
    DASH --> P : Erreur QR invalide
end

7.3 Codes de Réponse

Codes HTTP de validation

Code HTTP	Code Erreur	Description	Action Partenaire
200	SUCCESS	Paiement validé	Confirmer au client
400	INVALID_SIGNATURE	QR falsifié/corrompu	Refuser, demander nouveau QR
400	INVALID_FORMAT	Format QR incorrect	Vérifier scan correct
400	BALANCE_CHANGED	Solde client insuffisant	Demander autre moyen paiement
409	QR_ALREADY_USED	Double scan	Informer client (déjà débité)
410	QR_EXPIRED	Délai 15 min dépassé	Demander génération nouveau QR
403	PARTNER_MISMATCH	Mauvais partenaire	QR pour autre commerce
500	PROCESSING_ERROR	Erreur système	Réessayer ou support

7.4 Logs et Traçabilité

Toutes les tentatives de scan sont enregistrées :

qr_id : Identifiant du QR code
partner_id : Commerçant ayant scanné
timestamp : Date/heure exacte
result : SUCCESS / ERROR + code
ip_address : IP du dashboard
device_info : Infos appareil scan

8

RÉCAPITULATIF DES FLUX

8.1 Vue d'Ensemble

Synthèse des 5 flux

Flux	Déclencheur	Acteur Principal	Durée Typique	Criticité
Inscription	Action utilisateur	Client	30-60 secondes	Haute
Liaison compte OpenBanking	Action utilisateur	Client	2-5 minutes	Critique
Détection transaction	Webhook automatique	Système	5-30 secondes	Haute
Génération QR	Action utilisateur	Client	< 2 secondes	Haute
Scan QR	Action partenaire	Partenaire	< 3 secondes	Critique

8.2 Dépendances entre Flux

Pré-requis et post-conditions

Flux	Pré-requis	Post-condition
Inscription	Aucun	Compte créé, accès app
Liaison compte OpenBanking	Inscription	Détection transactions activée
Détection transaction	Liaison compte OpenBanking + Achat partenaire	Points crédités
Génération QR	Points disponibles (min 10)	QR actif 15 min, points bloqués
Scan QR	QR valide + non expiré	Points débités, transaction enregistrée

8.3 Points de Sécurité Critiques

⚠️ POINTS D'ATTENTION SÉCURITÉ

Rate limiting sur tous les endpoints sensibles
Validation signature HMAC-SHA256 pour webhooks et QR codes
Chiffrement AES-256 pour tokens bancaires
JWT RS256 avec rotation des clés
Audit logs sur toutes les transactions financières
Anti-replay avec vérification timestamp (±5 min)

8.4 Métriques de Performance Cibles

< 200ms Temps réponse API (p95)

> 99% Taux succès scan QR

< 30s Délai crédit points

99.9% Disponibilité globale

Seuils d'alerte

Métrique	Objectif	Seuil Alerte
Temps réponse API	< 200ms (p95)	> 500ms
Taux de succès scan QR	> 99%	< 95%
Délai crédit points	< 30 secondes	> 2 minutes
Disponibilité globale	99.9%	< 99.5%