unionflow-server-api/unionflow/specs/001-mutuelles-anti-blanchiment/plan.md

Plan d'implémentation : Gestion des mutuelles orientée anti-blanchiment (LCB-FT)

Branche : 001-mutuelles-anti-blanchiment | Date : 2026-03-08 | Spec : spec.md
Entrée : Spécification dans specs/001-mutuelles-anti-blanchiment/spec.md

Résumé

Mise en conformité LCB-FT/BCEAO/OHADA des flux mutuelles (épargne, crédit, paiements) : traçabilité (origine des fonds, justification), seuils configurables, niveau KYC membre, audit et alertes. Livrables dans l’ordre : API → Migrations → Impl Quarkus → Mobile (écrans mutuelles + affichage KYC fiche membre).

Contexte technique

Langage/Version : Java 17 (backend), Dart 3 / Flutter ^3.5.3 (mobile)
Dépendances principales : Quarkus 3.15.1, Panache, MapStruct (backend) ; go_router, flutter_bloc, get_it, dio (mobile)
Stockage : PostgreSQL 15+ (prod), H2 (dev/test) ; Flyway pour les migrations
Tests : JUnit/QuarkusTest (backend, 100 % JaCoCo), bloc_test/mockito (mobile)
Plateforme cible : Serveur Linux (backend), Android / iOS (mobile)
Type de projet : Backend API + Impl Quarkus + App mobile Flutter
Contraintes : Pas de données fictives ; seuils LCB-FT configurables (organisation/plateforme)
Échelle / périmètre : Extension du module mutuelles existant (API, BDD, services, écrans mobile épargne/crédit et fiche membre)

Contrôle constitution

• DDD : Resources → Services → Repositories ; pas d’accès direct aux repositories depuis les resources.
• API/Impl : Nouveaux champs et DTOs dans unionflow-server-api ; impl dans unionflow-server-impl-quarkus.
• Sécurité : Keycloak OIDC ; rôles existants ; pas de contournement des contrôles LCB-FT.
• RGPD / Audit : Audit trail (creePar, modifiePar, dates) ; conservation 10 ans pour audit_logs ; extension aux opérations mutuelles.
• Mobile : Données uniquement via API ; pas de listes en dur ; seuil LCB-FT fourni par API/config.

Structure du projet

Documentation (cette feature)

specs/001-mutuelles-anti-blanchiment/
├── spec.md           # Spécification fonctionnelle (existant)
├── plan.md           # Ce fichier
├── tasks.md          # À générer via /speckit.tasks
└── contracts/        # (optionnel) Endpoints impactés

Code source (monorepo unionflow)

unionflow/
├── unionflow-server-api/                    # DTOs, enums LCB-FT (origineFonds, KYC, seuils)
├── unionflow-server-impl-quarkus/           # Migrations, services, resources, validation seuils
│   └── src/main/resources/db/migration/    # V3.4+ LCB-FT si non présent
├── unionflow-mobile-apps/                   # Flutter
│   └── lib/
│       ├── core/constants/                 # lcb_ft_constants (seuil par défaut, à compléter par API)
│       └── features/
│           ├── epargne/                    # Dépôt/retrait/transfert + origine + pièce justificative si seuil
│           └── members/                    # Fiche membre : statut KYC, date vérification identité (lecture)

Décision de structure : On s’appuie sur la structure existante (inventaire .specify/memory/inventaire-code.md). La feature epargne mobile existe déjà ; on complète les champs LCB-FT et l’affichage KYC dans la fiche membre.

Ordre des livrables (aligné spec §5)

Ordre	Livrable	Contenu principal
1	Spec + inventaire	Fait (spec.md)
2	API (unionflow-server-api)	Champs origineFonds, pieceJustificativeId (transaction épargne) ; enums NiveauVigilanceKyc, StatutKyc ; champs membre dateVerificationIdentite ; DTOs paramètres LCB-FT / seuils ; extension intentions paiement (EPARGNE_DEPOT, etc. + origineFonds, justificationLcbFt)
3	Migrations Flyway	Colonnes membres/KYC ; transaction_epargne (origine_fonds, piece_justificative_id) ; intentions_paiement (origine_fonds, justification_lcb_ft) ; table paramètres LCB-FT (seuils)
4	Impl Quarkus	Règles de validation (seuil → exiger origineFonds) ; audit des opérations mutuelles ; ressource/config pour seuils ; éventuelle ressource « alertes LCB-FT »
5	Mobile	Écrans mutuelles : origine des fonds + pièce justificative (upload) si montant ≥ seuil (seuil depuis API/config) ; fiche membre : affichage statut KYC et date vérification identité (lecture seule)

Phases d’implémentation proposées

Phase 1 – API et contrat

• Ajout/extension des DTOs et enums dans unionflow-server-api (spec §3.1).
• Mise à jour de l’inventaire après chaque ajout.

Phase 2 – Persistance

• Création ou complément des migrations Flyway (spec §3.2) ; pas de modification de migrations existantes.

Phase 3 – Règles métier backend

• Services : validation seuil, obligation origineFonds / pièce si montant ≥ seuil ; audit ; optionnel : alertes LCB-FT (spec §3.3).

Phase 4 – Mobile

• Épargne : S’assurer que dépôt/retrait/transfert utilisent bien l’API (origine des fonds, pièce justificative si seuil) ; seuil de préférence fourni par l’API/config plutôt qu’en dur.
• Fiche membre : Affichage en lecture seule du statut KYC et de la date de vérification d’identité (données provenant de l’API membre).

Références

• Constitution : .specify/memory/constitution.md (sections 1–4, 8, 13).
• Inventaire : .specify/memory/inventaire-code.md (packages API, migrations, features mobile).
• Baseline : specs/000-unionflow-baseline/spec.md.

Suivi des écarts à la constitution

Aucun écart identifié ; le plan reste aligné avec la constitution et le baseline.