Vue 1 / 5 · Architecture Business
Capacités, acteurs et processus du parcours client cible
Décline la stratégie « parcours digital de bout-en-bout » en 4 macro-capacités, identifie les acteurs concernés et trace le processus d'onboarding cible avec ses points de friction résolus.
Cartographie
capacités & processus
capacités & processus
TOGAF · BDA
Carte des capacités métier Strategy → Capability mapping
Capacité cible (build projet)
Touché partiellement (phase 2)
Hors périmètre projet
Étape processus cible
Lecture stratégique. Le projet refonde deux capacités cœur (Onboarding, Selfcare) qui concentrent 78 % du coût de service hors crédit. Les capacités amont (Acquisition) et aval (Engagement) sont touchées par HYP ricochet mais ne sont pas livrées dans le périmètre TMA. Le rail compliance/risque reste sous responsabilité métier (RACI inchangé) avec une remontée plus structurée par events vers le moteur LCB-FT.
Acteurs & responsabilités
| Acteur | Rôle dans le parcours |
|---|---|
| Client mobile | Bénéficiaire primaire ; cible UX 95 % de complétion sans assistance |
| Conseiller agence | Mode hybride : reprend la main si KYC ambigu ou client préfère un humain |
| Conseiller à distance | Visio 24/7, queue intelligente, accès dossier en temps réel |
| Compliance | Revue LCB-FT, suspicions n2/n3, gel de comptes, contrôle ex-post |
| Risque | Scoring fraude temps réel, gestion seuils, déclenchement strong auth |
| Partenaires TPP | AISP/PISP DSP2, accès consentement explicite, SLA 99,9 % |
KPI business — état cible
| KPI | Avant | Cible T+18 |
|---|---|---|
| Délai ouverture compte | 27 min | < 10 min |
| Drop onboarding | 41 % | < 18 % |
| NPS post-onboarding | 22 | ≥ 55 |
| Coût/compte ouvert | 78 € | ≤ 22 € |
| Appels selfcare évitables/an | 2,1 M | -3,5 M (-65 %) |
| Fraude pré-débit | 38 % | ≥ 70 % |
Lien descendant → Les deux capacités cibles s'incarnent dans 6 domaines fonctionnels couverts par 12-15 composants applicatifs (vues 2 et 3). La gouvernance RACI est À CONFIRMER en CoPil sécurité courant juin.
Vue 2 / 5 · Architecture Fonctionnelle
Domaines fonctionnels cibles et flux inter-domaines
Décompose les capacités Onboarding et Selfcare en 6 domaines fonctionnels alignés DDD, avec leur composition modulaire et leurs interactions normalisées.
Bounded contexts
+ contrats fonctionnels
+ contrats fonctionnels
DDD · Capability map
Carte des domaines fonctionnels 6 bounded contexts
Lecture fonctionnelle. La frontière entre Compte courant (existant adapté) et Selfcare (nouveau) est volontairement nette : tout le pilotage UX migre dans Selfcare, le core banking redevient un service contractuel exposé via API. Le bus événementiel est le pivot — il découpe les responsabilités, isole les défaillances et autorise la consommation en aval (fraude, notification, analytics) sans coupler les domaines. VALIDÉ par le CoPil arch du 2026-04-22.
Statut par module fonctionnel
| Module | Statut |
|---|---|
| OCR pièce + liveness | Nouveau |
| eSignature eIDAS qualifiée | Nouveau |
| SCT-Inst < 10 s | Nouveau |
| Vue 360° patrimoine | Nouveau |
| Carte virtuelle J+0 | Nouveau |
| Ouverture IBAN | Modifié |
| 3DS v2 + step-up | Modifié |
| SCT classique SEPA | Existant |
| Souscription LDDS/LEP | Existant |
| Assurance-vie (renvoi) | Existant |
| Mandat SEPA prélèvement | Existant |
Contrats inter-domaines clés
| Source | Cible | Contrat |
|---|---|---|
| Identité & KYC | Compte courant | customer.verified.v1 |
| Compte courant | Selfcare | account.balance.changed.v1 |
| Carte | Fraud ML | card.txn.requested.v1 |
| Selfcare | Notif hub | user.alert.requested.v1 |
| Virement | Open Banking | payment.executed.v1 |
Point de vigilance. La duplication potentielle Notif hub ↔ messagerie sécurisée Selfcare est À CONFIRMER. Le nudge architecture : la messagerie reste un canal humain authentifié (réponse conseiller), Notif hub porte les notifications transactionnelles non-conversationnelles.
Vue 3 / 5 · Architecture Applicative
Composants applicatifs cibles et intégrations
14 composants applicatifs distribués sur 4 couches (front, API gateway, services métier, legacy/data), reliés par un Event Bus Kafka central. Statut nouveau / modifié / existant explicité par couleur.
Composants applicatifs
+ flux d'intégration
+ flux d'intégration
ArchiMate · ASA
Composants applicatifs cibles 14 composants · 4 couches
Lecture applicative. 10 composants nouveaux, 4 modifiés, le cœur DB2/COBOL est encapsulé sans modification via une couche de façade API. Cette stratégie « strangler pattern » VAL protège le core bancaire (risque réglementaire fort) tout en débloquant la couche client. Le pivot Kafka isole les défaillances : un crash Fraud ML ne bloque pas l'onboarding (mode dégradé via règles synchrones).
Inventaire composants (synthèse)
| Composant | Statut |
|---|---|
| Selfcare Mobile (RN) | Nouveau |
| Selfcare Web (Next.js) | Nouveau |
| Onboarding SPA | Nouveau |
| API Gateway Kong | Nouveau |
| Open Banking Gateway | Nouveau |
| KYC Service | Nouveau |
| eSignature Service | Nouveau |
| Onboarding Orchestrator | Nouveau |
| Card Mgmt API | Nouveau |
| Fraud ML Service | Nouveau |
| MDM Client | Nouveau |
| Notif Hub | Nouveau |
| Event Bus Kafka | Nouveau |
| Lakehouse Snowflake | Nouveau |
| Poste conseiller | Modifié |
| IAM Keycloak | Modifié |
| Payment API | Modifié |
| Consent Manager | Modifié |
| CRM Salesforce | Modifié |
| Core Banking DB2 | Existant |
| Référentiels tarifaires | Existant |
Risque clé. La latence aller-retour API Façade → Core DB2 est de 250-400 ms À CONFIRMER en charge. Si le SLA UX impose < 200 ms (cas Selfcare temps réel), un cache distribué Redis devra être inséré devant les lectures non-critiques (solde + 20 derniers mouvements).
Vue 4 / 5 · Architecture Technique
Stack, infrastructure et zones de sécurité
Vue d'infrastructure cible : hybride on-prem / cloud, segmentation par zones de confiance (DMZ, AppZone, DataZone, LegacyZone), avec stack technique par couche et chaîne CI/CD industrialisée.
Infrastructure cible
+ stack & sécurité
+ stack & sécurité
Cloud · Zoning
Stack par couche & zones de sécurité Hybrid on-prem + AWS · WAF + zoning
Lecture technique. Architecture hybride volontaire : tout le « front-of-house » (UX, services métier, ML, data) part en cloud AWS Paris ; le « back-of-house » (core banking, référentiels critiques, CRM) reste on-prem ou SaaS dédié. Le couplage repose sur 2 liens Direct Connect redondants VAL. La zoning DMZ→AppZone→DataZone applique le principe « never trust, always verify » HYP avec mTLS interne systématique.
Stack technique par couche
| Couche | Stack |
|---|---|
| Mobile | React Native + native modules biométrie |
| Web | Next.js 15 + TypeScript + Tailwind |
| API Gateway | Kong + Keycloak (OIDC, OAuth 2.1) |
| Microservices | Spring Boot 3 + JVM 21 + GraalVM (cold-start) |
| Orchestration | Camunda 8 (BPMN) sur Spring |
| ML Fraud | Python + FastAPI + XGBoost + Triton GPU |
| Event bus | Kafka MSK (3 AZ) + Schema Registry Avro |
| Cache | Redis ElastiCache (cluster mode) |
| Bases ops. | PostgreSQL Aurora (multi-AZ) |
| Lakehouse | Snowflake + Kafka Connect Sink |
| Object store | S3 + KMS + Glacier (archives) |
| Identité | Keycloak + HSM Vault (clés eIDAS) |
| Conteneurs | Kubernetes EKS + Argo CD (GitOps) |
| CI/CD | GitLab CI + Harbor + Trivy (scan) |
| Observabilité | OpenTelemetry → Datadog (SLO) |
| Legacy | z/OS · DB2 · WebSphere (inchangés) |
Cybersécurité. MFA adaptive (step-up risk-based) sur 100 % des opérations sensibles, fraud detection ML inline < 80 ms, zoning réseau strict (Calico Network Policies), À CONFIRMER intégration DORA + tests d'intrusion trimestriels obligatoires (ACPR).
Vue 5 / 5 · Architecture Données
Modèle conceptuel, MDM consolidé et flux de données
8 entités cœur du domaine bancaire, consolidation MDM contre fragmentation actuelle, flux opérationnels et analytiques séparés, gouvernance RGPD / DSP2 / DORA tracée par lineage.
Modèle & flux
+ gouvernance
+ gouvernance
DMA · Data lineage
Modèle conceptuel & flux MDM 8 entités · 4 sources · 4 consommateurs
Lecture données. Le MDM client devient le golden record obligatoire — fini les 4 versions divergentes du même client entre core banking, CRM, KYC et Selfcare. Les flux opérationnels (sync, < 100 ms) restent sur Kafka + Postgres ; les flux analytiques (Snowflake) sont alimentés par CDC + Kafka Connect avec un lag < 5 min HYP. La gouvernance est tracée bout-en-bout par Collibra À CONFIRMER sur stack Collibra cloud vs on-prem.
Entités cœur (8) — propriétaire métier
| Entité | Owner | SoT |
|---|---|---|
| Client | MDM Client | Nouveau |
| Identité KYC | Compliance | Nouveau |
| Compte | Core Banking | Existant |
| Carte | Cartes | Modifié |
| Transaction | Core Banking | Existant |
| Consent | Consent Mgr | Nouveau |
| Notification | Notif Hub | Nouveau |
| Audit log | Cyber / SOC | Nouveau |
Politique de rétention
| Donnée | Rétention |
|---|---|
| Données client actives | Vie compte + 5 ans |
| Pièces KYC | 5 ans après clôture |
| Transactions | 10 ans (LCB-FT) |
| Logs audit | 10 ans (WORM) |
| Logs techniques | 12 mois |
| Consentements | Durée + 3 ans |
Bénéfice clé. La consolidation MDM élimine le coût caché des resynchronisations manuelles (estimé à 1,8 ETP/an back-office) et permet à 4 consommateurs de partager un référentiel unique de qualité — précondition à la vraie vue 360° côté Selfcare.
Vue 1 / 5 · Business