Maquettes UI — application complète (spec ingénierie A→Z)

Objectif : cette page référence la maquette unique haute-fidélité qui couvre tous les écrans de l’application VitaKYC, tous personas confondus, en respectant l’ordre du workflow. Elle sert de spec visuelle d’ingénierie A→Z — chaque écran est annoté (trigger, données consommées, états alternatifs, transitions). Les designers Figma l’utilisent comme source, les développeurs comme cahier de charges UI.

Accès à la maquette

Ouvrir la maquette interactive dans un nouvel onglet :

→ /mockups/app.html

La page inclut un sélecteur thème clair / sombre et un bascule LTR / RTL (arabe) pour valider la structure bidirectionnelle.

Pré-visualisation intégrée

Personas couverts

#	Persona	Workflow couvert	Nb écrans
1	Client final (runtime KYC)	Onboarding complet : consentement → identité → documents → selfie/liveness → adresse → FATCA → e-signature → confirmation	8
2	Agent back-office banque / PSP	Login SSO, dashboard, queue, detail case (timeline + docs + AML), decision modal, AML alerts	6
3	Admin tenant — Form Designer	Liste formulaires, canvas éditeur, règles DSL, traductions FR/AR/EN, publication versionnée	5
4	Admin tenant — Configuration	Users/rôles (RBAC), API keys/webhooks, licence/modules, branding/résidence données	4
5	Compliance officer	Dashboard AML, batch screening (create + résultats), STR goAML draft, FATCA declarations (list + détail avec chaînage 1→2→3→4)	6
6	Supervisor (chef d’équipe)	Dashboard équipe + SLA, workload & réassignement	2
7	Auditor (interne / BCT / DGI)	Piste d’audit en lecture seule, vérification chaîne de hash	2
8	Developer (intégration)	API explorer (Swagger-style), webhooks logs + replay	2
9	Mobile SDK bootstrap	SaaS embarqué (SDK dans app banque), On-premise (gateway banque), PWA SMS/QR fallback, VitaKYC Agent Mobile (standalone)	4
10	Admin Risk Matrix	Liste policies versionnées, éditeur dimensions + pondérations + thresholds, overrides + model cards, shadow mode + backtest, publication avec dual control Vault	5
11	Compliance officer — Review Queue	File d’attente skill-based + filtres SLA, détail case avec timeline audit + commentaires + pièces jointes, modal de décision avec 4-eyes (proposer + confirmer), KPIs SLA + throughput	4
12	Admin Sanctions	Sources status (7 listes free + DJ), cron calendar hebdo, configuration policy (thresholds + weights + flags) avec dual-control, audit search avec rejeu de screening, KPIs + monitoring cluster OpenSearch	5
13	AML Tx Monitoring — alerts	File alertes streaming (filtres typology + severity + account + window), détail alert avec timeline tx + drill-down compte + alertes liées, investigation panel avec disposition (FP/suspicious/SAR) + 4-eyes, gestion règles (list, shadow vs active, backtest results, publish dual-control)	4
Total			57

Conventions d’annotation

Chaque écran comporte 4 annotations standard pour être actionnable par un développeur sans contexte supplémentaire :

Annotation	Rôle
Trigger	Ce qui déclenche l’affichage de l’écran (navigation, event, deep-link, webhook, CRON…)
API / Inputs	Endpoints consommés, payloads, schemas, sources de données
Alternative states	États vides, loading, erreur, succès, edge cases (offline, timeout, rejet)
Transitions	Écrans suivants possibles et leurs conditions (règles métier, scoring)

Design tokens

La maquette importe /mockups/tokens.css qui centralise :

• Palette complète (primaires, sémantiques, neutres) + variante dark
• Typographie (Inter + IBM Plex Sans Arabic pour le RTL)
• Spacing, radius, shadows
• Composants réutilisables (.vk-card, .vk-btn, .vk-badge, .vk-table, .vk-kpi, .vk-phone…)

Ce fichier sert de source unique pour l’export vers Style Dictionary / Tokens Studio lors du passage en Figma haute-fidélité. Toute modification visuelle doit passer par tokens.css — pas d’override local dans un écran.

Workflows documentés

Workflow 1 · Client runtime (mobile SDK Web)

Onboarding KYC individu — 8 écrans dans l’ordre chronologique :

1. Welcome / consentement RGPD + loi 2004-63 TN — consentement horodaté, langue auto-détectée (FR/AR/EN), PIPL/BCT disclosure
2. Formulaire identité — généré dynamiquement depuis le Form Designer du tenant (champs i18n, validation côté client)
3. Capture document — recto / verso, qualité live (flou, éblouissement), fallback upload fichier
4. Selfie + liveness — ISO/IEC 30107-3 PAD niveau 2, instructions RTL compatibles
5. Justificatif de domicile — OCR adresse, matching avec identité
6. FATCA indicia — questions US person, TIN, auto-détection indicia (lieu de naissance, adresse, téléphone US)
7. E-signature W-8BEN — TunTrust QES ou OTP SMS, PDF horodaté avec hash SHA-256
8. Succès — dossier soumis, référence, délai indicatif de décision

Workflow 2 · Agent back-office

Traitement manuel des dossiers à revue — 6 écrans :

1. Login SSO Keycloak — MFA TOTP obligatoire par ADR
2. Dashboard agent — KPI du jour (SLA, throughput), dossiers assignés
3. Queue — filtres multiples (risque, statut, source, langue), tri SLA
4. Detail case — timeline événements, documents OCR-isés, scoring AML, comparateur photo/selfie
5. Decision modal — approve / reject / request additional info, justification obligatoire, 4-eyes sur high risk
6. AML alerts — hits PEP/sanctions/adverse media, review manuelle, decision propagée

Workflow 3 · Admin Form Designer

Construction des formulaires KYC par tenant — 5 écrans (voir aussi Form Designer — UX pour les wireframes ASCII détaillés) :

1. Forms list — versionning, historique de publication, A/B testing
2. Canvas editor — 3 colonnes (palette champs / canvas WYSIWYG / propriétés champ sélectionné) avec Mapping CPS obligatoire + badge “Utilisé par N règles de risque” (ADR-026)
3. Rules DSL — éditeur règles conditionnelles (show if, required if, compute, score)
4. Translations — grille FR / AR / EN avec validation coverage 100 %, fallback par langue
5. Publish — modal avec diff vs version courante, stratégies (immediate, canary, blue-green) + event form.published émis vers profile-schema-svc

Workflow 4 · Admin Config tenant

Configuration plateforme — 4 écrans :

1. Users & roles — matrice RBAC (roles × permissions), invite email
2. API keys & webhooks — génération clés, rotation, signature HMAC SHA-256, logs événements
3. License & modules — modules activés (KYC, AML, TCR), quotas, facturation
4. Branding & data residency — logo, palette, choix région (Tunis / Paris / Francfort)

Workflow 5 · Compliance officer

Reporting réglementaire et monitoring AML — 6 écrans :

1. Dashboard AML — KPI alertes, SLA régulateur, file d’attente STR
2. Batch screening — create — upload CSV clients, config règles, estimation coût
3. Batch results — progression, hits par catégorie (PEP, sanctions, adverse media), export Excel
4. STR draft editor — formulaire goAML UNODC avec warning anti-tipping-off (interdiction d’informer le client)
5. FATCA declarations list — calendrier DGI→IRS, statuts (draft, submitted, rejected RG1-RG7, accepted)
6. Declaration detail — contenu XML, chaîne logique FATCA 1→2→3→4 (new, corrected, void, amended)

Workflow 6 · Supervisor

Encadrement équipe agents — 2 écrans :

1. Team dashboard — KPI par agent, SLA breach, heatmap
2. Workload — réassignement dossiers, gestion absences, capacité

Workflow 7 · Auditor

Lecture seule pour audits internes et régulateur (BCT, DGI, CNIL/INPDP) — 2 écrans :

1. Audit trail — recherche événements WORM (who, what, when, result)
2. Hash chain verify — vérification intégrité cryptographique séquentielle (SHA-256)

Workflow 8 · Developer

Support technique intégration partenaire — 2 écrans :

1. API explorer — interface Swagger-style, try-it-out sandbox
2. Webhooks logs — historique événements livrés, replay, debug headers + payload

Workflow 9 · Mobile SDK — bootstrap + tenant resolution

Intégration mobile de VitaKYC dans l’app de la banque cliente — 4 variantes (voir Mobile SDK — intégration + ADR-024) :

1. SaaS partagé — SDK natif embarqué dans l’app banque, tenantId baked au build, JWT signé backend banque, cert pinning VitaKYC
2. On-premise — SDK parle au mobile gateway banque (pas à vitakyc.com), cert pinning = cert banque, reverse proxy /kyc/* vers VitaKYC on-prem via mTLS interne, conforme BCT Circulaire 2017-08 §III
3. Fallback PWA — client sans app banque, SMS/QR magic-link, domaine kyc.<banque>.tn (CNAME), tenant résolu via Host header + JWT claim, parcours dégradé iOS sans Web NFC
4. VitaKYC Agent Mobile — app standalone pour agents back-office en mobilité, distribuée App Store + Play public pour tenants SaaS, MDM Jamf/Intune pour tenants BCT tier-1, 4-eyes obligatoire pour décisions high-risk

Workflow 10 · Admin Risk Matrix (matrice de risques client)

Administration de la matrice de risques par tenant — 5 écrans (voir ADR-025, Risk Engine, Playbook BCT) :

1. Liste des policies — versioning immuable, statuts DRAFT/SHADOW/PENDING_APPROVAL/ACTIVE/ARCHIVED, fork pour créer nouvelle version
2. Éditeur dimensions — 5 dimensions (client, geo, product, channel, aml_screening), pondérations (somme = 1.0 enforced), thresholds monotones LOW < STANDARD < HIGH < PROHIBITED, round-trip DSL Kotlin ↔ JSON, autocomplete depuis le Client Profile Schema + vue “Champs consommés” avec alerte si variable dépréciée (ADR-026)
3. Overrides + model cards — mustProhibit (OFAC, pays KP/IR, mineur non autorisé) et mustHigh (PEP OWN, UBO PEP, adverse media sévère), model cards YAML obligatoires pour audit BCT
4. Shadow mode + backtest — évaluation parallèle shadow vs prod (14j), backtest 6 mois sur 5000 dossiers historiques avec confusion matrix, impact dossiers, reproductibilité via listRefs
5. Publication (dual control) — 2 signatures Ed25519 Vault (compliance + DSI), justification obligatoire, rollout big-bang ou canary 5/25/50/100, rollback < 5 min, audit WORM chaîne de hash

Workflow 13 · AML Transaction Monitoring — alertes streaming

Console AML pour traiter les alertes générées par le moteur de streaming temps-réel sur les flux de transactions — 4 écrans (voir AML Streaming Engine, POC AML rules engine, ADR-031) :

1. Alerts queue — file d’alertes streaming avec filtres (typology STRUCTURING/VELOCITY/THRESHOLD/PATTERN/AGGREGATE, severity LOW/MEDIUM/HIGH/URGENT, accountId, time window, ruleId), badges live (count active alerts, lag Kafka), action rapide “Open case” qui crée un case dans Workflow 11
2. Alert detail — header alerte (rule, severity, score, dedup signature), timeline des transactions déclenchantes avec montants/canaux/contreparties, drill-down compte (historique 30j + autres alertes liées même account), graph relations (counterparties, RCA paths via sanctions check)
3. Investigation panel — disposition agent (FALSE_POSITIVE / SUSPICIOUS_REPORT_TO_MLRO / NO_ACTION_DOCUMENTED), justification obligatoire avec checklist conformité, 4-eyes pour SUSPICIOUS_REPORT_TO_MLRO (link vers Case Management), génération automatique draft STR goAML pré-rempli (cf POC poc-goaml-generator)
4. Rules management — liste règles tenant avec statuts DRAFT/SHADOW/ACTIVE/ARCHIVED, badges shadow (alertes parallèles), résultats backtest 6 mois (precision/recall vs prod), publication dual-control Ed25519, traceback des dernières alertes par règle, calibration suggérée

Workflow 12 · Admin Sanctions (supervision + configuration)

Console compliance officer + DSI pour superviser les sources de listes, configurer la policy de matching et auditer les screenings — 5 écrans (voir Sanctions admin UI, Sanctions screening, ADR-030) :

1. Sources status — grille 7 sources free + DJ avec status (healthy/stale/error), lastSyncAt, nb entrées, listVersion, prochaine sync, drawer détail avec snapshots MinIO + Force refresh
2. Cron calendar — grid hebdomadaire 7×24 visualisant les fenêtres full reindex (dimanche 02:00) et delta sync (quotidien 06:00) + détection conflits + historique runs 90 jours
3. Configuration policy — onglets Sources / Thresholds / Re-ranker weights / Feature flags ; sliders avec validation (weights = 1.0, thresholds monotones), calibration suggérée (FP/FN sur 90j), publication exige dual-control Ed25519
4. Audit search & rejeu — filtres période + décision + candidate + screening_id, chain integrity check live, drawer détail avec top-N candidates + scores + signatures, rejeu screening sur snapshot MinIO + export PDF audit
5. KPIs + monitoring — cartes KPI (screenings 24h, latence p95, FP rate, MATCH_DIRECT/PEP/RCA counts), sparklines latence par phase, monitoring cluster OpenSearch (heap, query rate), alertes actionnables avec liens runbook on-call

Workflow 11 · Compliance officer — Review Queue (case management)

Console agent compliance pour traiter les cases déclenchés par bio-svc, risk-matrix-svc et aml-svc — 4 écrans (voir Case Management, ADR-029) :

1. Queue list — file d’attente personnelle avec filtres (state, priority, skill, age vs SLA), tri par échéance, badges priorité (URGENT/HIGH/STANDARD/LOW), indicateur SLA (vert/orange/rouge selon ratio), barre supérieure KPIs (NB ASSIGNED, IN_REVIEW, breach SLA aujourd’hui)
2. Case detail — header (subject, priority, triggers, agent, SLA countdown), 3 onglets : Résumé (verdict bio + score risk + alertes AML), Timeline audit (events append-only signés, hashes vérifiés), Pièces jointes (docs OCR + selfie + uploads agent)
3. Decision modal (4-eyes) — split en 2 panneaux : Proposition (radio APPROVED/REJECTED + commentaire obligatoire + checklist conformité) et Confirmation (visible uniquement par confirmer ≠ proposer, seniority L2+ requise pour cas sensibles, bouton “Confirmer” ou “Renvoyer en review”)
4. Dashboard supervisor — vue agrégée par agent : throughput jour, SLA respect %, cases ouverts, escalades, alertes actionnables (agent saturé, SLA imminents, drift queue)

Référence croisée

• Design tokens + composants : /mockups/tokens.css
• Form Designer wireframes détaillés : Form Designer — UX
• Spec OpenAPI consommée : API / Spec OpenAPI
• Architecture cible : Architecture technique
• ADR-007 Form Designer MVP : Décisions d’architecture

Qualité et itérations

Ces maquettes ne sont pas figées : chaque écran sera itéré en Figma haute-fidélité avec l’équipe design au kickoff. Les changements structurants (nouvelle étape, champ bloquant, règle de rejet) doivent être reportés ici et dans la doc correspondante (architecture, ADR, OpenAPI, Form Designer). La règle de traçabilité de l’ADR-016 s’applique : une modification UI qui impacte un contrat API ou une règle métier déclenche un ADR.