5.2.1
Diagramme de Séquence
Inscription Client
La solution de cashback nouvelle génération
1
OBJECTIF DU DOCUMENT
Ce document présente les diagrammes de séquence détaillés du processus d'inscription d'un nouveau client sur l'application mobile REWAPP. Il couvre les trois méthodes d'inscription disponibles :
- Inscription par Email/Mot de passe avec validation email
- Inscription via Google OAuth2
- Inscription via Apple Sign In (iOS uniquement)
Chaque diagramme illustre les interactions temporelles entre les différents composants du système, incluant les cas nominaux et les cas d'erreur.
2
ACTEURS DU SYSTÈME
2.1 Acteurs Principaux
Acteurs du Processus d'Inscription
| Acteur | Type | Description |
|---|---|---|
| Client | Utilisateur | Personne souhaitant créer un compte REWAPP (18 ans minimum) |
| Application Mobile | Frontend | Application Angular + Ionic (iOS/Android) interfaçant avec l'utilisateur |
| API Gateway | Infrastructure | Point d'entrée sécurisé des requêtes (Kong / AWS API Gateway) |
| Service Authentification | Backend | Microservice NestJS gérant l'authentification et les utilisateurs |
| Service Email | Externe | SendGrid/Brevo pour l'envoi des emails de validation |
| Base de Données | Stockage | PostgreSQL stockant les données utilisateurs |
| Redis Cache | Cache | Redis pour le stockage temporaire des tokens de validation |
| Google OAuth | Externe | Service d'authentification Google |
| Apple Sign In | Externe | Service d'authentification Apple (iOS) |
3
PRÉ-REQUIS
3.1 Pré-requis Fonctionnels
- L'application mobile est installée sur le terminal de l'utilisateur
- L'utilisateur a une connexion internet active
- L'utilisateur possède une adresse email valide
- L'utilisateur a 18 ans ou plus
3.2 Pré-requis Techniques
- L'API Gateway est opérationnel
- Le Service Authentification est disponible
- La Base de Données PostgreSQL est accessible
- Le service d'envoi d'emails est fonctionnel
- Les services OAuth (Google/Apple) sont accessibles
4
DIAGRAMME DE SÉQUENCE - INSCRIPTION EMAIL/MOT DE PASSE
4.1 Cas Nominal
Diagramme de Séquence - Inscription Email/Mot de Passe
@startuml
title Inscription Client - Email/Mot de Passe (Cas Nominal)
actor Client
participant "Application
Mobile" as App
participant "API
Gateway" as Gateway
participant "Service
Authentification" as Auth
database "PostgreSQL" as DB
participant "Redis
Cache" as Redis
participant "Service
Email" as Email
== Phase 1 : Saisie du Formulaire ==
Client -> App : Accède à l'écran d'inscription
App -> Client : Affiche formulaire
(Prénom, Nom, Email, MDP, CGU)
Client -> App : Remplit le formulaire
App -> App : Validation temps réel
(format email, force MDP)
App -> Client : Indicateur de force MDP
(Rouge/Orange/Vert)
Client -> App : Coche acceptation CGU
Client -> App : Clique "Créer mon compte"
== Phase 2 : Validation et Création ==
App -> App : Validation côté client
(champs obligatoires, formats)
App -> Gateway : POST /api/auth/register
{prénom, nom, email, password, cgu: true}
Gateway -> Gateway : Rate limiting check
Gateway -> Auth : Forward request
Auth -> DB : SELECT * FROM users
WHERE email = ?
DB -> Auth : Résultat (vide = email disponible)
Auth -> Auth : Hash password (bcrypt)
Auth -> Auth : Génère token validation
(UUID, expire 24h)
Auth -> DB : INSERT INTO users
(status: 'pending_validation')
DB -> Auth : Confirmation création
Auth -> Redis : SET validation_token:{token}
{user_id, email} TTL 24h
Redis -> Auth : OK
Auth -> Email : Envoi email validation
(lien avec token)
Email -> Auth : Confirmation envoi
Auth -> Gateway : 201 Created
{message: "Vérifiez votre email"}
Gateway -> App : Response 201
App -> Client : Affiche écran
"Vérifiez votre email"
== Phase 3 : Validation Email ==
Client -> Client : Ouvre email
Client -> Email : Clique sur lien validation
Email -> App : Deep link avec token
App -> Gateway : POST /api/auth/validate-email
{token}
Gateway -> Auth : Forward request
Auth -> Redis : GET validation_token:{token}
Redis -> Auth : {user_id, email}
Auth -> DB : UPDATE users
SET status = 'active'
WHERE id = ?
DB -> Auth : Confirmation
Auth -> Redis : DEL validation_token:{token}
Auth -> Auth : Génère JWT Access Token (15min)
+ Refresh Token (30 jours)
Auth -> Gateway : 200 OK
{accessToken, refreshToken, user}
Gateway -> App : Response 200
App -> App : Stocke tokens
(Keychain/Keystore)
App -> Client : Redirection vers
onboarding liaison carte
@enduml
5
DIAGRAMME DE SÉQUENCE - INSCRIPTION GOOGLE OAUTH2
5.1 Cas Nominal
Diagramme de Séquence - Google OAuth2
@startuml
title Inscription Client - Google OAuth2 (Cas Nominal)
actor Client
participant "Application
Mobile" as App
participant "Google
OAuth" as Google
participant "API
Gateway" as Gateway
participant "Service
Authentification" as Auth
database "PostgreSQL" as DB
== Phase 1 : Authentification Google ==
Client -> App : Clique "Continuer avec Google"
App -> Google : Ouvre popup OAuth2
Google -> Client : Affiche écran connexion Google
Client -> Google : Saisit identifiants Google
Google -> Google : Authentification
Google -> Client : Demande autorisation
(email, profil)
Client -> Google : Accepte
Google -> App : Retourne authorization code
== Phase 2 : Échange et Vérification ==
App -> Gateway : POST /api/auth/google
{authorizationCode}
Gateway -> Auth : Forward request
Auth -> Google : Échange code contre tokens
POST /oauth2/token
Google -> Auth : {access_token, id_token}
Auth -> Auth : Décode id_token
(email, prénom, nom, photo)
Auth -> DB : SELECT * FROM users
WHERE email = ? OR google_id = ?
DB -> Auth : Résultat
alt Utilisateur n'existe pas
Auth -> DB : INSERT INTO users
(status: 'active', google_id, email_verified: true)
DB -> Auth : Confirmation création
Auth -> Auth : is_new_user = true
else Utilisateur existe déjà
Auth -> DB : UPDATE users
SET google_id = ?
WHERE email = ?
DB -> Auth : Confirmation
Auth -> Auth : is_new_user = false
end
== Phase 3 : Acceptation CGU (si nouveau) ==
Auth -> Gateway : 200 OK
{needsCguAcceptance: true/false, tempToken}
Gateway -> App : Response 200
opt Nouveau utilisateur
App -> Client : Affiche popup CGU
Client -> App : Accepte CGU
App -> Gateway : POST /api/auth/accept-cgu
{tempToken}
Gateway -> Auth : Forward request
Auth -> DB : UPDATE users
SET cgu_accepted_at = NOW()
DB -> Auth : Confirmation
end
== Phase 4 : Finalisation ==
Auth -> Auth : Génère JWT Access Token (15min)
+ Refresh Token (30 jours)
Auth -> Gateway : 200 OK
{accessToken, refreshToken, user, isNewUser}
Gateway -> App : Response 200
App -> App : Stocke tokens
(Keychain/Keystore)
alt Nouvel utilisateur
App -> Client : Redirection vers
onboarding liaison carte
else Utilisateur existant
App -> Client : Redirection vers Dashboard
end
@endumlFLUX GOOGLE OAUTH2
L'authentification Google permet une inscription rapide en récupérant automatiquement l'email, le prénom et le nom depuis le compte Google. L'email est considéré comme vérifié.
6
DIAGRAMME DE SÉQUENCE - INSCRIPTION APPLE SIGN IN
6.1 Cas Nominal (iOS uniquement)
IMPORTANT - APPLE SIGN IN
Apple ne renvoie les informations utilisateur (prénom, nom, email) QU'À LA PREMIÈRE CONNEXION. Le stockage de ces données est obligatoire lors de la première authentification.
Diagramme de Séquence - Apple Sign In
@startuml
title Inscription Client - Apple Sign In (Cas Nominal - iOS)
actor Client
participant "Application
Mobile" as App
participant "Apple
Sign In" as Apple
participant "API
Gateway" as Gateway
participant "Service
Authentification" as Auth
database "PostgreSQL" as DB
== Phase 1 : Authentification Apple ==
Client -> App : Clique "Continuer avec Apple"
App -> Apple : Ouvre popup Sign In with Apple
Apple -> Client : Affiche écran Apple ID
Client -> Apple : Authentification Face ID/Touch ID/Password
Apple -> Client : Option "Masquer mon email" ?
Client -> Apple : Choix (email réel ou relay)
Apple -> App : Retourne identityToken + authorizationCode
+ user info (prénom, nom, email)
== Phase 2 : Vérification Backend ==
App -> Gateway : POST /api/auth/apple
{identityToken, authorizationCode, user}
Gateway -> Auth : Forward request
Auth -> Apple : Vérifie identityToken
via Apple Public Keys
Apple -> Auth : Token valide
Auth -> Auth : Décode identityToken
(sub = apple_id unique)
Auth -> DB : SELECT * FROM users
WHERE apple_id = ?
DB -> Auth : Résultat
alt Utilisateur n'existe pas
alt Prénom/Nom fournis par Apple
Auth -> DB : INSERT INTO users
(apple_id, email, prénom, nom, status: 'active')
DB -> Auth : Confirmation
else Prénom/Nom non fournis
Auth -> Gateway : 200 OK
{needsProfileCompletion: true, tempToken}
Gateway -> App : Response 200
App -> Client : Affiche écran
complétion profil
Client -> App : Saisit prénom et nom
App -> Gateway : POST /api/auth/complete-profile
{tempToken, prénom, nom}
Gateway -> Auth : Forward request
Auth -> DB : INSERT INTO users
(apple_id, email, prénom, nom, status: 'active')
DB -> Auth : Confirmation
end
Auth -> Auth : is_new_user = true
else Utilisateur existe
Auth -> Auth : is_new_user = false
end
== Phase 3 : Acceptation CGU (si nouveau) ==
opt Nouveau utilisateur
Auth -> Gateway : 200 OK
{needsCguAcceptance: true, tempToken}
Gateway -> App : Response 200
App -> Client : Affiche popup CGU
Client -> App : Accepte CGU
App -> Gateway : POST /api/auth/accept-cgu
{tempToken}
Gateway -> Auth : Forward request
Auth -> DB : UPDATE users
SET cgu_accepted_at = NOW()
DB -> Auth : Confirmation
end
== Phase 4 : Finalisation ==
Auth -> Auth : Génère JWT Access Token (15min)
+ Refresh Token (30 jours)
Auth -> Gateway : 200 OK
{accessToken, refreshToken, user, isNewUser}
Gateway -> App : Response 200
App -> App : Stocke tokens
(Keychain/Keystore)
alt Nouvel utilisateur
App -> Client : Redirection vers
onboarding liaison carte
else Utilisateur existant
App -> Client : Redirection vers Dashboard
end
@enduml
7
DESCRIPTION DÉTAILLÉE DES ÉTAPES
7.1 Inscription Email/Mot de Passe
Étapes du Processus Email/MDP
| # | Composant | Action | Description |
|---|---|---|---|
| 1 | Client | Accès formulaire | L'utilisateur accède à l'écran d'inscription depuis l'onboarding ou l'écran de connexion |
| 2 | Application | Affichage formulaire | Présentation des champs : Prénom, Nom, Email, Mot de passe, Confirmation MDP, Checkbox CGU |
| 3 | Client | Saisie données | L'utilisateur remplit tous les champs du formulaire |
| 4 | Application | Validation temps réel | Vérification du format email (RFC 5322), affichage indicateur force mot de passe |
| 5 | Client | Acceptation CGU | L'utilisateur coche obligatoirement les CGU pour continuer |
| 6 | Client | Soumission | Clic sur le bouton "Créer mon compte" |
| 7 | Application | Validation client | Vérification de tous les champs obligatoires et formats avant envoi |
| 8 | API Gateway | Rate limiting | Vérification du nombre de requêtes pour éviter les abus |
| 9 | Service Auth | Vérification unicité | Requête en base pour vérifier si l'email existe déjà |
| 10 | Service Auth | Hashage MDP | Hashage du mot de passe avec bcrypt (cost factor: 12) |
| 11 | Service Auth | Création token | Génération d'un UUID pour la validation email (validité 24h) |
| 12 | Service Auth | Création compte | Insertion en base avec statut 'pending_validation' |
| 13 | Redis | Stockage token | Sauvegarde du token de validation avec TTL de 24h |
| 14 | Service Email | Envoi email | Email de validation avec lien contenant le token |
| 15 | Application | Écran confirmation | Affichage "Vérifiez votre email" avec possibilité de renvoyer |
| 16 | Client | Validation | Clic sur le lien dans l'email reçu |
| 17 | Service Auth | Vérification token | Récupération et validation du token depuis Redis |
| 18 | Service Auth | Activation compte | Mise à jour du statut utilisateur vers 'active' |
| 19 | Service Auth | Génération JWT | Création des tokens d'accès (15min) et de rafraîchissement (30j) |
| 20 | Application | Stockage sécurisé | Sauvegarde des tokens dans Keychain (iOS) / Keystore (Android) |
| 21 | Application | Redirection | Navigation vers l'onboarding de liaison de carte bancaire |
7.2 Inscription Google OAuth2
Étapes du Processus Google OAuth2
| # | Composant | Action | Description |
|---|---|---|---|
| 1 | Client | Initiation | Clic sur le bouton "Continuer avec Google" |
| 2 | Application | Ouverture OAuth | Lancement de la popup native Google Sign-In |
| 3 | Authentification | L'utilisateur s'authentifie avec son compte Google | |
| 4 | Autorisation | Demande d'accès aux informations (email, profil) | |
| 5 | Retour code | Renvoi du code d'autorisation à l'application | |
| 6 | Service Auth | Échange tokens | Échange du code contre des tokens Google |
| 7 | Service Auth | Décodage | Extraction des informations du id_token (email, nom, photo) |
| 8 | Service Auth | Vérification compte | Recherche d'un compte existant avec cet email ou google_id |
| 9 | Service Auth | Création/Liaison | Création du compte ou liaison avec compte existant |
| 10 | Application | CGU (si nouveau) | Affichage popup d'acceptation des CGU pour les nouveaux |
| 11 | Service Auth | Génération JWT | Création des tokens d'authentification REWAPP |
| 12 | Application | Finalisation | Stockage tokens et redirection appropriée |
7.3 Inscription Apple Sign In
Étapes du Processus Apple Sign In
| # | Composant | Action | Description |
|---|---|---|---|
| 1 | Client | Initiation | Clic sur le bouton "Continuer avec Apple" (iOS uniquement) |
| 2 | Application | Ouverture popup | Lancement de Sign In with Apple native |
| 3 | Apple | Authentification | Authentification via Face ID, Touch ID ou mot de passe |
| 4 | Apple | Option email | Proposition de masquer l'email (relay Apple) |
| 5 | Apple | Retour données | Renvoi identityToken + infos utilisateur (première connexion uniquement) |
| 6 | Service Auth | Vérification token | Validation du identityToken via les clés publiques Apple |
| 7 | Service Auth | Recherche compte | Vérification si un compte existe avec cet apple_id |
| 8 | Application | Complétion profil | Si prénom/nom non fournis, écran de saisie complémentaire |
| 9 | Service Auth | Création compte | Création avec email (réel ou relay Apple) |
| 10 | Application | CGU | Acceptation obligatoire des CGU pour les nouveaux |
| 11 | Service Auth | Génération JWT | Création des tokens d'authentification REWAPP |
| 12 | Application | Finalisation | Stockage tokens et redirection vers onboarding |
8
CAS ALTERNATIFS ET EXCEPTIONS
8.1 Cas Alternatifs - Inscription Email
Diagramme de Séquence - Cas d'Erreurs Email/MDP
@startuml
title Inscription Client - Cas d'Erreurs Email/MDP
actor Client
participant "Application
Mobile" as App
participant "API
Gateway" as Gateway
participant "Service
Authentification" as Auth
database "PostgreSQL" as DB
== Cas A : Email déjà utilisé ==
Client -> App : Soumet formulaire
App -> Gateway : POST /api/auth/register
Gateway -> Auth : Forward request
Auth -> DB : SELECT * FROM users WHERE email = ?
DB -> Auth : Utilisateur trouvé
Auth -> Gateway : 409 Conflict
{error: "EMAIL_ALREADY_EXISTS"}
Gateway -> App : Response 409
App -> Client : "Cette adresse email est déjà utilisée"
+ Lien "Se connecter"
== Cas B : Mot de passe trop faible ==
Client -> App : Saisit mot de passe "abc123"
App -> App : Validation regex
App -> Client : Indicateur ROUGE "Faible"
"Ajoutez une majuscule"
note right: Bouton "Créer" reste désactivé
== Cas C : Token validation expiré ==
Client -> App : Clique lien email (après 24h)
App -> Gateway : POST /api/auth/validate-email
{token}
Gateway -> Auth : Forward request
Auth -> Redis : GET validation_token:{token}
Redis -> Auth : null (expiré/supprimé)
Auth -> Gateway : 410 Gone
{error: "TOKEN_EXPIRED"}
Gateway -> App : Response 410
App -> Client : "Le lien a expiré"
+ Bouton "Renvoyer l'email"
== Cas D : Rate limiting déclenché ==
Client -> App : 6ème tentative en 1 minute
App -> Gateway : POST /api/auth/register
Gateway -> Gateway : Check rate limit
(5 req/min dépassé)
Gateway -> App : 429 Too Many Requests
{retryAfter: 60}
App -> Client : "Trop de tentatives.
Réessayez dans 1 minute."
== Cas E : Erreur serveur ==
Client -> App : Soumet formulaire
App -> Gateway : POST /api/auth/register
Gateway -> Auth : Forward request
Auth -> DB : INSERT INTO users...
DB -> Auth : Connection timeout
Auth -> Gateway : 500 Internal Server Error
Gateway -> App : Response 500
App -> Client : "Une erreur est survenue.
Veuillez réessayer."
@enduml8.2 Cas Alternatifs - Inscription OAuth
Cas d'Erreurs OAuth
| Cas | Déclencheur | Comportement | Message Utilisateur |
|---|---|---|---|
| OAuth annulé | L'utilisateur ferme la popup Google/Apple | Retour à l'écran d'inscription | Aucun message, retour silencieux |
| Compte Google suspendu | Compte Google désactivé | Échec authentification côté Google | "Authentification Google échouée" |
| Email Google déjà lié | Compte REWAPP existe avec cet email | Connexion automatique (si social login) ou erreur | "Un compte existe déjà avec cet email" |
| Token Google invalide | Token expiré ou falsifié | Rejet côté backend | "Authentification échouée. Réessayez." |
| Apple email masqué | Utilisateur choisit relay Apple | Création avec email relay @privaterelay.appleid.com | Fonctionnement normal |
| Apple infos manquantes | Première connexion sans nom | Écran complémentaire obligatoire | "Complétez votre profil" |
| Réseau indisponible | Perte connexion pendant OAuth | Timeout et annulation | "Vérifiez votre connexion internet" |
9
RÈGLES DE VALIDATION
9.1 Validation des Champs
Règles de Validation
| Champ | Type | Obligatoire | Règles | Regex / Format |
|---|---|---|---|---|
| Prénom | Texte | ✅ Oui | 2-50 caractères, lettres et accents uniquement | ^[a-zA-ZÀ-ÿs'-]{2,50}$ |
| Nom | Texte | ✅ Oui | 2-50 caractères, lettres et accents uniquement | ^[a-zA-ZÀ-ÿs'-]{2,50}$ |
| ✅ Oui | Format email valide selon RFC 5322, max 254 caractères | Validation RFC 5322 | ||
| Mot de passe | Password | ✅ Oui | 8+ caractères, 1 majuscule, 1 minuscule, 1 chiffre | ^(?=.*[a-z])(?=.*[A-Z])(?=.*d).{8,}$ |
| Confirmation MDP | Password | ✅ Oui | Identique au mot de passe | Égalité stricte |
| CGU | Checkbox | ✅ Oui | Doit être coché | true |
9.2 Indicateur de Force du Mot de Passe
Niveaux de Force
| Niveau | Couleur | Conditions | Message |
|---|---|---|---|
| Faible | 🔴 Rouge | < 8 caractères OU manque un critère (maj/min/chiffre) | "Mot de passe faible" |
| Moyen | 🟠 Orange | 8-12 caractères ET tous les critères de base respectés | "Mot de passe moyen" |
| Fort | 🟢 Vert | 12+ caractères ET tous les critères + caractère spécial | "Mot de passe fort" |
9.3 Contraintes Techniques
- Email : Unicité en base de données (index unique)
- Mot de passe : Hashage bcrypt avec cost factor 12
- Token validation : UUID v4, stockage Redis avec TTL 24h
- Rate limiting : 5 requêtes/minute par IP pour l'inscription
- Taille requête : Maximum 1 Mo
10
MESSAGES D'ERREUR
10.1 Messages d'Erreur Côté Client
Erreurs de Validation Client
| Code Erreur | Message Affiché | Contexte |
|---|---|---|
FIELD_REQUIRED | "Ce champ est obligatoire" | Champ vide à la soumission |
INVALID_EMAIL_FORMAT | "Format d'adresse email invalide" | Email ne respectant pas le format RFC 5322 |
PASSWORD_TOO_SHORT | "Le mot de passe doit contenir au moins 8 caractères" | Mot de passe < 8 caractères |
PASSWORD_NO_UPPERCASE | "Ajoutez au moins une majuscule" | Mot de passe sans majuscule |
PASSWORD_NO_LOWERCASE | "Ajoutez au moins une minuscule" | Mot de passe sans minuscule |
PASSWORD_NO_DIGIT | "Ajoutez au moins un chiffre" | Mot de passe sans chiffre |
PASSWORD_MISMATCH | "Les mots de passe ne correspondent pas" | Confirmation différente du MDP |
CGU_NOT_ACCEPTED | "Vous devez accepter les Conditions Générales d'Utilisation" | Checkbox CGU non cochée |
NAME_TOO_SHORT | "Ce champ doit contenir au moins 2 caractères" | Prénom ou nom < 2 caractères |
NAME_INVALID_CHARS | "Ce champ ne peut contenir que des lettres" | Caractères non autorisés |
10.2 Messages d'Erreur Côté Serveur
Erreurs HTTP
| HTTP | Code Erreur | Message Affiché | Cause |
|---|---|---|---|
| 409 | EMAIL_ALREADY_EXISTS | "Cette adresse email est déjà utilisée" | Email déjà enregistré en base |
| 410 | TOKEN_EXPIRED | "Le lien de validation a expiré. Demandez un nouvel email." | Token de validation expiré (>24h) |
| 410 | TOKEN_INVALID | "Lien de validation invalide" | Token non trouvé ou déjà utilisé |
| 429 | TOO_MANY_REQUESTS | "Trop de tentatives. Réessayez dans X minutes." | Rate limiting déclenché |
| 400 | INVALID_REQUEST | "Requête invalide" | Données malformées |
| 401 | OAUTH_FAILED | "Authentification échouée. Réessayez." | Échec OAuth Google/Apple |
| 500 | SERVER_ERROR | "Une erreur est survenue. Veuillez réessayer." | Erreur interne serveur |
| 503 | SERVICE_UNAVAILABLE | "Service temporairement indisponible" | Maintenance ou surcharge |
11
POST-CONDITIONS
11.1 État du Système Après Inscription Réussie
État des Composants
| Composant | État | Détails |
|---|---|---|
| Base de Données | Nouvel utilisateur créé | Statut 'active', email_verified_at renseigné, cgu_accepted_at renseigné |
| Redis | Token validation supprimé | Nettoyage automatique après validation |
| Application | Tokens stockés | Access Token (15min) + Refresh Token (30j) dans Keychain/Keystore |
| Session | Utilisateur connecté | Navigation vers onboarding liaison carte |
| Email de bienvenue envoyé | Confirmation d'inscription envoyée |
11.2 Données Utilisateur Créées
Structure des Données
| Champ | Source | Valeur |
|---|---|---|
id | Système | UUID v4 généré |
email | Formulaire/OAuth | Email fourni ou relay Apple |
email_verified_at | Système | Timestamp de validation |
password_hash | Système | Hash bcrypt (null si OAuth) |
first_name | Formulaire/OAuth | Prénom fourni |
last_name | Formulaire/OAuth | Nom fourni |
google_id | Google OAuth | ID unique Google (nullable) |
apple_id | Apple Sign In | ID unique Apple (nullable) |
cgu_accepted_at | Système | Timestamp d'acceptation CGU |
status | Système | 'active' |
created_at | Système | Timestamp de création |
loyalty_tier | Système | 'bronze' (défaut) |
total_points | Système | 0 (défaut) |
12
RÈGLES MÉTIER APPLICABLES
12.1 Règles Générales
RÈGLES IMPORTANTES
- L'inscription est 100% GRATUITE pour tous les utilisateurs
- L'utilisateur doit avoir 18 ans ou plus
- L'acceptation des CGU est OBLIGATOIRE
- Un seul compte par adresse email
- La validation email est obligatoire pour l'inscription Email/MDP
- Les inscriptions OAuth (Google/Apple) sont pré-validées
12.2 Sécurité
- Mot de passe : Hashage bcrypt (cost factor 12)
- Tokens JWT : Signés RS256, Access Token 15 min, Refresh Token 30 jours
- Rate limiting : 5 requêtes/minute par IP pour éviter les abus
- Token validation : Usage unique, validité 24h
- Stockage sécurisé : Keychain (iOS) / Keystore (Android)
12.3 RGPD et Conformité
- Consentement explicite via checkbox CGU
- Données minimales collectées (prénom, nom, email)
- Droit d'accès, de rectification et de suppression
- Chiffrement des données en transit (TLS 1.3) et au repos (AES-256)
FIN DU DOCUMENT
Document rédigé conformément au Guide de Rédaction REWAPP v1.0
Source de vérité : Section 1 - Documents de Cadrage
Référence : 2.1 Spécifications App Mobile - Module d'Authentification