feat: WebSocket temps réel + Finance Workflow + corrections

- Task #6: WebSocket /ws/dashboard + Kafka events (5 topics) * Backend: KafkaEventProducer, KafkaEventConsumer * Mobile: WebSocketService (reconnection, heartbeat, typed events) * DashboardBloc: Auto-refresh depuis WebSocket events - Finance Workflow: approbations + budgets (backend + mobile) * Backend: entities, services, resources, migrations Flyway V6 * Mobile: features finance_workflow complète avec BLoC - Corrections DI: interfaces IRepository partout * IProfileRepository, IOrganizationRepository, IMembreRepository * GetIt configuré avec @injectable - Spec-Kit: constitution + templates mis à jour * .specify/memory/constitution.md enrichie * Templates agent, plan, spec, tasks, checklist - Nettoyage: fichiers temporaires supprimés Signed-off-by: lions dev Team
2026-03-15 02:12:17 +00:00
parent bbc409de9d
commit e8ad874015
635 changed files with 58160 additions and 20674 deletions
--- a/unionflow/specs/001-mutuelles-anti-blanchiment/plan.md
+++ b/unionflow/specs/001-mutuelles-anti-blanchiment/plan.md
@@ -0,0 +1,96 @@
+# 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](./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)
+
+```text
+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)
+
+```text
+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.
--- a/unionflow/specs/001-mutuelles-anti-blanchiment/spec.md
+++ b/unionflow/specs/001-mutuelles-anti-blanchiment/spec.md
@@ -0,0 +1,151 @@
+# Spécification : Gestion des mutuelles orientée anti-blanchiment (LCB-FT)
+
+**Feature Branch** : `001-mutuelles-anti-blanchiment`  
+**Créé** : 2026-02-28  
+**Statut** : Spécification  
+**Type** : Extension métier (alignement LCB-FT / BCEAO/OHADA)
+
+## Contexte
+
+UnionFlow gère des mutuelles d'épargne et de crédit. Les flux de fonds (dépôts, retraits, transferts, crédits) doivent être traçables et conformes aux exigences de **lutte contre le blanchiment des capitaux et le financement du terrorisme (LCB-FT)** et aux bonnes pratiques BCEAO/OHADA.
+
+Ce document décrit l’état actuel du backend (API + impl) pour les mutuelles, puis les extensions proposées pour une gestion orientée anti-blanchiment, **sans données fictives**.
+
+---
+
+## 1. État actuel (inventaire)
+
+### 1.1 API – unionflow-server-api
+
+**Mutuelles épargne**
+
+- **dto.mutuelle.epargne**
+  - `CompteEpargneRequest` : membreId, organisationId, typeCompte, notesOuverture
+  - `CompteEpargneResponse` : id, membreId, organisationId, numeroCompte, typeCompte, soldeActuel, soldeBloque, statut, dateOuverture, dateDerniereTransaction, description
+  - `TransactionEpargneRequest` : compteId, typeTransaction, montant, compteDestinationId, **motif**
+  - `TransactionEpargneResponse` : compteId, type, montant, soldeAvant/Apres, motif, dateTransaction, operateurId, referenceExterne, statutExecution
+- **enums.mutuelle.epargne** : TypeTransactionEpargne (DEPOT, RETRAIT, TRANSFERT_ENTRANT/SORTANT, PAIEMENT_INTERETS, etc.), StatutCompteEpargne, TypeCompteEpargne
+
+**Mutuelles crédit**
+
+- **dto.mutuelle.credit**
+  - `DemandeCreditRequest` : membreId, typeCredit, montantDemande, dureeMois, compteLieId, **justificationDetaillee**, documentIds, garantiesProposees
+  - `DemandeCreditResponse` : numeroDossier, membreId, montantDemande/Approuve, echeancier, statut, notesComite, etc.
+  - `GarantieDemandeDTO`, `EcheanceCreditDTO`
+- **enums.mutuelle.credit** : StatutDemandeCredit, TypeCredit, TypeGarantie, StatutEcheanceCredit
+
+**Paiements / intentions**
+
+- **dto.paiement** : CreatePaiementRequest (numeroReference, montant, codeDevise, methodePaiement, commentaire, membreId), Wave DTOs
+- **intentions_paiement** (V2.3) : utilisateur_id, organisation_id, montant_total, code_devise, type_objet, statut, objets_cibles, wave_* — pas de champ dédié « origine des fonds » ou « justification LCB-FT »
+
+**Membres (KYC)**
+
+- `CreateMembreRequest` : **typeIdentite**, **numeroIdentite** (déjà présents), nom, prénom, email, téléphone, dateNaissance, profession, nationalite, statutMatrimonial
+
+**Audit**
+
+- V2.9 : audit_logs avec organisation_id, portee (ORGANISATION | PLATEFORME), conservation 10 ans (BCEAO/OHADA/Fiscalité)
+
+### 1.2 Base de données (migrations)
+
+- **paiements** : reference, montant, devise, methode_paiement, statut, membre_id, organisation_id — pas d’origine des fonds ni de seuil LCB-FT
+- **intentions_paiement** : type_objet (COTISATION, ADHESION, EVENEMENT, ABONNEMENT_UNIONFLOW) — pas d’EPARGNE ni CREDIT ni champs LCB-FT
+- **membres** : pas de niveau de vigilance (KYC simplifié / renforcé) ni de date de vérification d’identité
+- **audit_logs** : portee, organisation_id — adapté pour traçabilité
+
+### 1.3 Mobile (unionflow-mobile-apps)
+
+- Pas de feature dédiée « mutuelles » (épargne/crédit) dans les écrans listés ; contributions, adhesions, solidarité, dashboard existent.
+- Les écrans mutuelles (s’ils sont ajoutés) devront afficher uniquement des données réelles (API), avec champs obligatoires pour origine des fonds / justification lorsque le backend les exigera.
+
+---
+
+## 2. Objectifs orientés anti-blanchiment
+
+1. **Traçabilité** : chaque opération significative (dépôt, retrait, transfert, déblocage crédit) liée à un membre identifié, avec origine des fonds ou motif explicite.
+2. **Seuils** : au-dessus d’un montant configurable (ex. 500 000 XOF / 1 000 000 XOF), renforcement des contrôles (justification obligatoire, validation, éventuelle déclaration).
+3. **Vigilance** : niveau KYC membre (simplifié / renforcé), date de vérification d’identité, lien avec éligibilité aux opérations.
+4. **Alertes** : transactions inhabituelles (montant, fréquence, motif) et dépassement de seuil en vue d’un contrôle manuel ou déclaration.
+5. **Conservation** : conservation des justificatifs et journaux conforme aux exigences (déjà 10 ans pour audit_logs ; à étendre aux pièces et champs LCB-FT).
+
+---
+
+## 3. Propositions d’extension (sans données fictives)
+
+### 3.1 API – Nouveaux champs et contrats
+
+**TransactionEpargneRequest (extension)**
+
+- `origineFonds` (String, optionnel) : libellé court de l’origine des fonds (ex. « Salaire », « Vente », « Héritage ») — obligatoire au-dessus du seuil configuré.
+- `pieceJustificativeId` (UUID, optionnel) : référence vers une pièce jointe (document) pour les opérations au-dessus du seuil.
+
+**TransactionEpargneResponse (extension)**
+
+- Conserver les champs existants ; ajouter éventuellement `origineFonds`, `pieceJustificativeId` en lecture pour traçabilité.
+
+**DemandeCreditRequest (déjà bien orienté)**
+
+- Déjà : justificationDetaillee, documentIds, garantiesProposees.
+- Optionnel : `origineFondsRemboursement` (String) pour indiquer la source prévue du remboursement (cohérence LCB-FT).
+
+**Intentions de paiement / Paiements**
+
+- Étendre `type_objet` (ou équivalent API) pour inclure **EPARGNE_DEPOT**, **EPARGNE_RETRAIT**, **CREDIT_REMBOURSEMENT** si les flux passent par le hub Wave.
+- Ajouter dans le DTO d’intention ou de paiement : `origineFonds` (String, optionnel), `justificationLcbFt` (String, optionnel) — obligatoires au-dessus du seuil.
+
+**Membre / KYC**
+
+- Ajouter en API (et en base) :
+  - `niveauVigilanceKyc` : enum (SIMPLIFIE | RENFORCE).
+  - `dateVerificationIdentite` (LocalDate, optionnel).
+  - `statutKyc` : enum (NON_VERIFIE | EN_COURS | VERIFIE | REFUSE) pour piloter l’éligibilité aux opérations.
+
+**Configuration organisation / plateforme**
+
+- Seuils LCB-FT configurables (par organisation ou globaux) : montant au-dessus duquel justification obligatoire, montant au-dessus duquel validation manuelle obligatoire (ex. 500k / 1M XOF). À exposer via config ou table `parametres_organisation` / `parametres_plateforme`.
+
+### 3.2 Base de données
+
+- **membres** (ou table dédiée `membre_kyc`) : colonnes `niveau_vigilance_kyc`, `date_verification_identite`, `statut_kyc`.
+- **transaction_epargne** (si table dédiée) ou table des mouvements : colonnes `origine_fonds`, `piece_justificative_id`, `seuil_lcb_ft_atteint` (booléen).
+- **intentions_paiement** : colonnes `origine_fonds`, `justification_lcb_ft` (TEXT).
+- **parametres** : table ou colonnes pour seuils LCB-FT (montant_seuil_justification, montant_seuil_validation_manuelle, code_devise).
+
+### 3.3 Règles métier (impl Quarkus)
+
+- Lors de la création d’une transaction épargne (dépôt, retrait, transfert) : si montant >= seuil configuré, exiger `origineFonds` (et éventuellement `pieceJustificativeId`) ; sinon rejet (400) avec message clair.
+- Crédit : conserver justification détaillée + documents ; optionnellement exiger `dateVerificationIdentite` à jour pour le membre avant déblocage.
+- Enregistrement systématique dans `audit_logs` des opérations mutuelles (épargne/crédit) avec portee ORGANISATION et détails (montant, type, membre, seuil franchi).
+- Alertes : création d’événements ou entrées « alerte LCB-FT » (table dédiée ou type d’audit) pour dépassement de seuil, motif vide au-dessus du seuil, ou éventuellement pattern inhabituel (à définir en phase 2).
+
+### 3.4 Mobile
+
+- Formulaires de dépôt/retrait/transfert épargne : champs **Origine des fonds** et **Pièce justificative** (upload) rendus obligatoires lorsque le montant saisi dépasse le seuil (seuil fourni par l’API ou la config).
+- Pas d’affichage de données fictives : listes et détails mutuelles = appels API uniquement.
+- Fiche membre : affichage du statut KYC et de la date de vérification d’identité (lecture seule si pas de droit de modification).
+
+---
+
+## 4. Conformité et références
+
+- **BCEAO** : directives sur les systèmes financiers décentralisés et la lutte contre le blanchiment.
+- **OHADA** : conservation des preuves et traçabilité des opérations.
+- **LCB-FT** : identification, vigilance, traçabilité, déclaration des opérations suspectes (la déclaration aux autorités reste hors scope applicatif direct ; le système prépare les données et alertes).
+
+---
+
+## 5. Livrables proposés (ordre recommandé)
+
+1. **Spec + inventaire** (ce document) — fait.
+2. **API (unionflow-server-api)** : ajout des champs et enums (origineFonds, niveauVigilanceKyc, statutKyc, dateVerificationIdentite, seuils) dans les DTOs existants ; nouveaux DTOs ou champs pour paramètres LCB-FT.
+3. **Migrations Flyway** : nouvelles colonnes membres/KYC, transaction_epargne/intentions_paiement, table paramètres LCB-FT.
+4. **Impl Quarkus** : règles de validation (seuils), enregistrement audit, éventuelle table/ressource « alertes LCB-FT ».
+5. **Mobile** : écrans mutuelles (épargne/crédit) avec champs obligatoires selon seuil, sans données fictives.
+
+---
+
+## 6. Règle anti-hallucination
+
+- Toute nouvelle classe, colonne ou endpoint doit être ajoutée d’abord dans **unionflow-server-api** (ou dans ce spec avec référence explicite au fichier), puis reflétée dans l’inventaire `.specify/memory/inventaire-code.md`.
+- Aucune donnée fictive en production : pas de listes en dur, pas de mock de données métier dans les écrans ou les réponses API.
--- a/unionflow/specs/001-mutuelles-anti-blanchiment/tasks.md
+++ b/unionflow/specs/001-mutuelles-anti-blanchiment/tasks.md
@@ -0,0 +1,100 @@
+# Tâches : Gestion des mutuelles orientée anti-blanchiment (LCB-FT)
+
+**Entrée** : `specs/001-mutuelles-anti-blanchiment/spec.md`, `plan.md`  
+**Prérequis** : plan.md, spec.md
+
+**Ordre d’exécution** : Respecter strictement l’ordre des phases (API → Migrations → Impl → Mobile). Les tâches mobile ne doivent être traitées qu’après les tâches backend correspondantes (ou en parallèle si l’API est déjà disponible).
+
+---
+
+## Format : `[ID] [P?] Description`
+
+- **[P]** : Peut s’exécuter en parallèle (fichiers différents, pas de dépendances).
+- Les chemins sont relatifs à la racine du dépôt `unionflow/`.
+
+---
+
+## Phase 1 : API (unionflow-server-api)
+
+**Objectif** : Ajouter les champs et enums LCB-FT dans l’API (spec §3.1).
+
+- [ ] T001 [P] Étendre `TransactionEpargneRequest` (ou équivalent) avec `origineFonds` (String, optionnel), `pieceJustificativeId` (UUID, optionnel) si ce n’est pas déjà fait — `unionflow-server-api/.../dto/mutuelle/epargne/`
+- [ ] T002 [P] Étendre `TransactionEpargneResponse` avec `origineFonds`, `pieceJustificativeId` en lecture si nécessaire
+- [ ] T003 [P] Ajouter en API les enums `NiveauVigilanceKyc`, `StatutKyc` (ex. `enums.membre`) et champs membre : `niveauVigilanceKyc`, `dateVerificationIdentite`, `statutKyc` (DTOs membre)
+- [ ] T004 [P] Étendre les DTOs d’intentions de paiement / paiement avec `origineFonds`, `justificationLcbFt` et étendre `type_objet` pour EPARGNE_DEPOT, EPARGNE_RETRAIT, CREDIT_REMBOURSEMENT si prévu par la spec
+- [ ] T005 [P] Ajouter ou étendre le contrat (DTO / config) pour les paramètres LCB-FT (seuils : montant justification, montant validation manuelle, devise) — ex. `parametres_organisation` / `parametres_plateforme`
+- [ ] T006 Mettre à jour `.specify/memory/inventaire-code.md` avec les nouveaux DTOs/enums/champs API
+
+**Jalon** : API prête pour impl et mobile (contrats stables).
+
+---
+
+## Phase 2 : Migrations Flyway (unionflow-server-impl-quarkus)
+
+**Objectif** : Schéma BDD aligné avec la spec §3.2 (sans modifier les migrations existantes).
+
+- [ ] T007 Vérifier ou créer la migration LCB-FT : colonnes membres (ou table membre_kyc) `niveau_vigilance_kyc`, `date_verification_identite`, `statut_kyc`
+- [ ] T008 Vérifier ou créer les colonnes `origine_fonds`, `piece_justificative_id` (et si besoin `seuil_lcb_ft_atteint`) sur la table des transactions épargne
+- [ ] T009 Vérifier ou créer les colonnes `origine_fonds`, `justification_lcb_ft` sur la table intentions_paiement
+- [ ] T010 Vérifier ou créer la table ou colonnes pour les paramètres LCB-FT (seuils : montant_seuil_justification, montant_seuil_validation_manuelle, code_devise)
+- [ ] T011 Mettre à jour l’inventaire avec le numéro et le contenu de la migration LCB-FT
+
+**Jalon** : Schéma BDD prêt pour l’impl des services.
+
+---
+
+## Phase 3 : Implémentation Quarkus (unionflow-server-impl-quarkus)
+
+**Objectif** : Règles métier, validation des seuils, audit (spec §3.3).
+
+- [ ] T012 Implémenter la lecture des paramètres LCB-FT (seuils) depuis la BDD ou la config (organisation / plateforme)
+- [ ] T013 Dans le service de transaction épargne : si montant ≥ seuil configuré, exiger `origineFonds` (et éventuellement `pieceJustificativeId`) ; sinon rejet 400 avec message clair
+- [ ] T014 Enregistrer dans `audit_logs` les opérations mutuelles (épargne/crédit) avec portee ORGANISATION et détails (montant, type, membre, seuil franchi)
+- [ ] T015 (Optionnel) Crédit : exiger ou vérifier `dateVerificationIdentite` à jour pour le membre avant déblocage selon la spec
+- [ ] T016 (Optionnel) Créer la ressource ou le type d’événement « alertes LCB-FT » pour dépassement de seuil / motif vide (spec §3.3)
+- [ ] T017 Exposer un endpoint ou une config (ex. paramètres organisation) pour que le mobile récupère le seuil LCB-FT (montant au-dessus duquel origine des fonds obligatoire)
+
+**Jalon** : Backend LCB-FT opérationnel et consommable par le mobile.
+
+---
+
+## Phase 4 : Mobile (unionflow-mobile-apps)
+
+**Objectif** : Écrans mutuelles conformes LCB-FT (origine des fonds, pièce justificative si seuil) ; fiche membre avec statut KYC et date de vérification d’identité (spec §3.4).
+
+### 4.1 Épargne – Seuil et champs LCB-FT
+
+- [ ] T018 Récupérer le seuil LCB-FT depuis l’API (paramètres organisation) ou la config ; utiliser ce seuil dans les dialogs (dépôt/retrait/transfert) au lieu ou en complément de `lcb_ft_constants.dart`
+- [ ] T019 S’assurer que les formulaires de dépôt, retrait et transfert épargne affichent et envoient `origineFonds` (obligatoire si montant ≥ seuil) — `lib/features/epargne/presentation/widgets/` (ex. `DepotEpargneDialog`, retrait, transfert)
+- [ ] T020 Ajouter la saisie et l’upload de la pièce justificative dans les dialogs épargne lorsque le montant ≥ seuil ; envoyer `pieceJustificativeId` dans `TransactionEpargneRequest` après upload
+- [ ] T021 Afficher un message d’erreur clair côté mobile si l’API retourne 400 (ex. origine des fonds manquante au-dessus du seuil)
+
+**Jalon** : Flux épargne mobile conformes LCB-FT (sans données fictives).
+
+### 4.2 Fiche membre – Affichage KYC
+
+- [ ] T022 Étendre le modèle membre (ex. `MembreModel` ou DTO détail) avec `niveauVigilanceKyc`, `statutKyc`, `dateVerificationIdentite` selon l’API — `lib/features/members/data/models/`
+- [ ] T023 Sur la fiche membre (détail membre ou écran équivalent), afficher en lecture seule le statut KYC et la date de vérification d’identité — `lib/features/members/presentation/` et/ou `lib/features/profile/`
+- [ ] T024 S’assurer que les données KYC proviennent uniquement de l’API (pas de valeurs en dur)
+
+**Jalon** : Fiche membre affiche les informations KYC conformément à la spec.
+
+---
+
+## Phase 5 : Finition et transversal
+
+- [ ] T025 Mettre à jour `.specify/memory/inventaire-code.md` avec les changements mobile (modèles, écrans, constantes)
+- [ ] T026 Vérifier qu’aucune donnée fictive n’est utilisée en production (listes en dur, mocks métier) pour les flux mutuelles et KYC
+- [ ] T027 Exécuter les tests backend et mobile ; corriger les régressions
+
+---
+
+## Dépendances et ordre d’exécution
+
+- **Phase 1 (API)** : Peut démarrer immédiatement.
+- **Phase 2 (Migrations)** : Dépend de la stabilité des champs API (Phase 1).
+- **Phase 3 (Impl)** : Dépend des Phases 1 et 2.
+- **Phase 4 (Mobile)** : Dépend des contrats API (Phase 1) et de préférence de l’endpoint/config de seuil (T017). Les tâches 4.1 et 4.2 peuvent être traitées en parallèle une fois les modèles API disponibles.
+- **Phase 5** : Après les Phases 1–4.
+
+Pour **continuer strictement l’ordre sur la version mobile** : exécuter d’abord T018 → T019 → T020 → T021 (épargne), puis T022 → T023 → T024 (fiche membre), puis T025–T027.