Architecture Technique Globale

1.1 Introduction

L'architecture technique de REWAPP est conçue selon les principes de scalabilité, haute disponibilité et sécurité. Elle repose sur une architecture microservices déployée sur infrastructure CapRover + Docker, permettant une évolutivité horizontale et une maintenance facilitée.

L'écosystème REWAPP comprend quatre composantes principales :

• Application Mobile : iOS/Android pour les clients finaux
• Site Vitrine : présentation de l'offre et inscription
• Dashboard Admin : gestion globale par l'équipe REWAPP
• Dashboard Partenaire : interface de gestion pour les commerçants

1.2 Principes Architecturaux

1.3 Composants de l'Écosystème

1.3.1 Applications Clientes

1.3.2 Services Backend

2.1 Couche Présentation (Frontend)

2.1.1 Application Mobile (Angular + Ionic)

Architecture :

• Services Angular pour gestion d'état global
• Ionic Router pour la navigation native
• HttpClient Angular pour les appels API avec intercepteurs
• Ionic Storage pour persistance locale
• @capacitor/camera pour scan QR code
• @capacitor/push-notifications pour push notifications

Sécurité Mobile :

• Certificate Pinning pour éviter attaques MITM
• Stockage sécurisé des tokens (Keychain iOS / Keystore Android)
• Obfuscation du code en production

2.1.2 Site Vitrine (Angular 20)

Architecture :

• Single Page Application (SPA) Angular — pas de SSR/SSG
• Tailwind CSS pour styling responsive
• Optimisation images avec Angular CDK / lazy loading
• Integration Google Tag Manager pour analytics

Sections principales (scrollables) :

• Hero : CTA inscription app mobile
• Comment ça marche : 4 étapes du fonctionnement
• Avantages : proposition de valeur pour clients et commerçants
• Offre Pro : CTA inscription partenaire (redirect partner.rewapp.fr)
• Contact : formulaire contact

2.1.3 Dashboard Admin et Partenaire (Angular)

Architecture commune :

• Ionic Components pour composants professionnels
• NgRx Signals Store pour état global
• Chart.js / Recharts pour visualisations données
• WebSocket pour temps réel (scan QR, notifications)
• PWA avec Service Worker pour mode offline (Dashboard Partenaire)

2.2 Couche API Gateway

2.2.1 Traefik (API Gateway CapRover)

2.2.2 Structure des Endpoints API

/api/v1/auth/*            → Auth Module (inscription, connexion, 2FA, social, tokens)
/api/v1/clients/me/*     → Client Module (profil, points, QR codes, transactions, transfers, referrals)
/api/v1/partners/*       → Partner Module (inscription, dashboard, scan QR, team, KYB)
/api/v1/admin/*          → Admin Module (gestion partenaires, billing, stats, security, tiers)
/api/v1/notifications/*  → Notifications Module (push, email)
/api/v1/webhooks/*       → Webhooks Module (Plaid, Stripe)
/api/v1/siret            → Siret Module (vérification SIRET/UAI)

2.3 Couche Services Métier (Backend)

2.3.1 Modules NestJS (Monolithe Modulaire)

2.3.2 Communication Inter-Modules

Communication Synchrone (Appels directs) :

• Tous les modules partagent la même base PostgreSQL
• Appels de services via injection de dépendances NestJS (même process)
• Timeout applicatif : 5 secondes par défaut

Communication Asynchrone (Bull Queue / Redis) :

• Events : transaction.created, points.credited, user.registered, kyb.approved
• Queues durables avec acknowledgment
• Dead Letter Queue pour messages en échec
• Webhooks : Plaid (transactions), Stripe (paiements)

2.4 Couche Données

2.4.1 PostgreSQL 15+ (Base Principale)

Configuration :

• Extensions activées : UUID-OSSP, pg_trgm (recherche texte)
• Master-Replica replication pour haute disponibilité
• Backup automatique quotidien avec rétention 30 jours
• Connection pooling avec PgBouncer

Tables Principales :

• users : profils utilisateurs
• merchants : informations commerçants
• transactions : historique achats détectés
• points_ledger : journal des mouvements de points
• accounts : comptes OpenBanking liés (tokens Plaid uniquement)
• withdrawals : demandes de virement bancaire
• loyalty_tiers : configuration paliers par commerçant
• qr_codes : QR codes générés (TTL 15 minutes)
• notifications : historique notifications

2.4.2 Redis 7+ (Cache et Sessions)

3.1 Services Infrastructure CapRover

3.2 Architecture Réseau (réseau interne serveur)

3.2.1 Configuration réseau interne serveur

réseau interne serveur CIDR           : 10.0.0.0/16
Réseaux publics    : 10.0.1.0/24, 10.0.2.0/24 (redondant a et b)
Réseaux privés App : 10.0.10.0/24, 10.0.11.0/24 (redondant)
Réseaux privés Data: 10.0.20.0/24, 10.0.21.0/24 (redondant)
NAT Gateway        : Accès internet sortant pour réseaux internes privés
Docker Network     : Réseau interne containers CapRover

3.2.2 Security Groups

3.3 Configuration par Environnement

4.1 Chiffrement des Données

4.1.1 Chiffrement au Repos

• PostgreSQL : Encryption via volumes Docker (AES-256)
• MinIO/Stockage : Encryption des volumes (AES-256)
• Docker Volumes : Encrypted by default
• Redis Container : Encryption at-rest activé

4.1.2 Chiffrement en Transit

• TLS 1.3 minimum pour toutes les communications
• Certificate Pinning sur application mobile
• OpenBanking OAuth : intégration via Plaid OAuth (pas de partage credentials)
• HTTPS obligatoire (HTTP redirection 301)

4.2 Authentification et Autorisation

4.2.1 Stratégie JWT (RS256)

Claims JWT :

• sub : userId unique
• role : user, merchant, admin, superadmin
• permissions : tableau de permissions granulaires
• deviceId : identifiant device pour détection fraude
• exp : timestamp expiration

4.2.2 RBAC (Role-Based Access Control)

4.2.3 2FA (Authentification à Deux Facteurs)

4.3 Protection contre les Attaques

4.3.1 Protection OWASP Top 10

4.3.2 Protection DDoS et Rate Limiting

• Cloudflare/Traefik : Protection DDoS layer 3/4
• Traefik Middleware : Filtrage requêtes malveillantes layer 7
• Rate Limiting API Gateway :

100 requêtes/minute par utilisateur authentifié
1000 requêtes/minute par IP
5 tentatives de login/heure par compte

4.3.3 Sécurité QR Code

• Signature HMAC-SHA256 avec clé secrète
• Points BLOQUÉS dès génération du QR code
• Validation côté serveur obligatoire avant débit
• Détection tentatives de replay (code déjà utilisé)

5.1 Stratégies de Cache

5.1.1 Cache Multi-Niveaux

5.1.2 Stratégies d'Invalidation

• TTL adaptatif : court pour données volatiles, long pour données stables
• Event-driven invalidation : invalidation cache lors de mise à jour données
• Cache warming : pré-chargement données fréquentes au démarrage

5.2 Scaling Docker containers

5.2.1 Scaling Horizontal (Docker CapRover)

5.2.2 Scaling Database

• Read Replicas : Répartition charge lectures sur replicas
• Connection Pooling : PgBouncer pour optimiser connexions
• Partitioning : Tables volumineuses partitionnées par date (transactions)

5.3 Optimisations

5.3.1 Optimisations Backend

• Pagination curseur pour grandes listes (évite OFFSET)
• DataLoader pattern pour éviter N+1 queries
• Batch processing pour opérations lourdes (Bull Queue)
• Lazy loading des relations TypeORM

5.3.2 Optimisations Frontend

• Code splitting et lazy loading des routes
• Optimisation images : WebP, compression, responsive
• Service Worker pour cache offline (Dashboard Partenaire PWA)
• Bundle size cible : < 200KB gzipped

5.3.3 Objectifs de Performance

6.1 Stack de Monitoring

6.1.1 Métriques (Prometheus + Grafana)

• Métriques système : CPU, RAM, Disk, Network
• Métriques application : Requêtes/s, Latence, Taux d'erreur
• Métriques business : Transactions/jour, Points crédités, Conversions QR
• Dashboards personnalisés par équipe (Dev, Ops, Business)

6.1.2 Logs Centralisés (Loki / CapRover Logs)

Structure des logs (JSON) :

{
  "timestamp": "2025-11-24T10:30:00.000Z",    // Horodatage ISO 8601
  "level": "INFO",                             // INFO, WARN, ERROR, DEBUG
  "service": "rewapp-api",                   // Nom du service backend (monolithe modulaire)
  "requestId": "req_abc123xyz",                // Identifiant unique de requête
  "userId": "usr_456def",                      // Utilisateur concerné (si applicable)
  "message": "User authenticated successfully",// Description de l'événement
  "metadata": {                                // Données contextuelles
    "ip": "192.168.1.1",
    "userAgent": "REWAPP-Mobile/1.0"
  }
}

6.1.3 APM (Application Performance Monitoring)

• Request tracing : Suivi requêtes via intercepteurs NestJS
• Real User Monitoring (RUM) : Performance côté client
• Profiling : Identification goulots d'étranglement
• Error tracking : Sentry pour capture et analyse erreurs

6.2 Alerting

7.1 Pipeline de Déploiement

7.1.1 Outils

7.1.2 Workflow CI/CD

7.2 Environnements

8.1 Solution Bancaire (Card Linking)

8.1.1 Fournisseur Recommandé : Plaid

8.1.2 Webhooks Bancaires (Plaid)

• ITEM : Item Plaid lié (nouveau compte OpenBanking)
• ITEM_USER_PERMISSION_REVOKED : Permissions révoquées par l'utilisateur
• TRANSACTIONS_SYNC : Nouvelles transactions détectées via Plaid
• TRANSACTIONS_REMOVED : Transactions supprimées/mises à jour

8.1.3 Virements Bancaires

• API Stripe pour initiation virements SEPA
• Réconciliation automatique via webhooks Stripe
• Délai standard SEPA : 1-2 jours ouvrés

8.2 Services de Communication

8.2.1 Notifications Push (Firebase Cloud Messaging)

8.2.2 Email (SendGrid)

• Templates transactionnels : Confirmation inscription, réinitialisation mot de passe
• Templates marketing : Newsletter, promotions (opt-in)
• Bounce handling et suppression automatique
• Suivi delivery et open rates

8.2.3 SMS (Twilio)

• Usage : Alertes transactionnelles, notifications partenaires
• Opt-out management RGPD compliant
• Fallback si échec push notification

8.3 Analytics et Tracking

8.3.1 Google Analytics 4

Événements trackés :

• signup_started, signup_completed
• card_linked
• transaction_detected
• qr_generated, qr_scanned
• withdrawal_requested, withdrawal_completed

8.3.2 Mixpanel

• Funnel analysis : Inscription → Liaison carte → 1ère transaction
• Cohort retention analysis : Rétention J7, J30, J90
• A/B testing framework pour optimisation UX

8.3.3 Sentry (Error Tracking)

• Capture automatique des erreurs frontend et backend
• Stack traces avec contexte utilisateur
• Alertes temps réel sur nouvelles erreurs
• Release tracking pour corrélation erreurs/déploiements

9.1 Récapitulatif de l'Architecture

L'architecture technique de REWAPP a été conçue pour répondre aux exigences de scalabilité, performance et sécurité d'une plateforme de cashback moderne.

9.2 Points Clés

• Architecture cloud-native sur CapRover + Docker
• Microservices découplés avec NestJS
• Base PostgreSQL avec TypeORM
• Cache Redis pour performance et sessions
• Bull Queue pour traitement asynchrone
• Sécurité intégrée (Security by Design)
• CI/CD automatisé avec GitHub Actions
• Monitoring complet avec alerting

9.3 Évolutions Futures Prévues

L'architecture est conçue pour supporter les évolutions suivantes :

• Migration Kubernetes : Orchestration avancée pour phase de scale
• GraphQL API : Flexibilité accrue pour les clients
• Machine Learning : Détection fraude et recommandations personnalisées
• Multi-région : Expansion européenne (Belgique, Suisse)