Contentieux & Recouvrement

Donner à la banque un seul endroit pour lire son risque de défaut et le défendre.

Designer produit senior : architecture de l'information, hiérarchie des indicateurs, design de données et livraison des écrans du module Reporting.

Explorer les décisions ↓

Module Reporting — bandeau d'ouverture : encours, encours en défaut, clients en défaut et validations en attente — Bandeau d'ouverture du module Reporting · Build de recette · écrans réels · données de recette

Problème: Le pilotage du défaut vivait dans des exports mensuels : chaque direction arrivait en comité avec sa propre version du portefeuille.
Ma part: Architecture de l'information du module Reporting, hiérarchie des indicateurs, design de données, livraison des écrans.
Décision centrale: Faire du reporting une tour de contrôle : un écran d'ouverture qui répond d'abord à « où ça brûle aujourd'hui ».
Niveau de preuve: Build de recette, écrans réels, données de recette. Le traitement de dossier reste réservé à une présentation en direct.

Résultats proposés

Détaillés dans les trois décisions ci-dessous

Le comité part d'un écran d'ouverture commun au lieu d'exports recollés à la main.
Le risque se lit par agence et par région, face au seuil réglementaire.
L'activité et la conformité sont séparées : chaque lecteur trouve sa réponse.

Décisions

03 décisions · preuve annotée pour chacune

Décision 01Tour de contrôle

Le pilotage du défaut vivait dans des exports mensuels. Chacun arrivait en comité avec sa propre version du portefeuille, et la première demi-heure servait à réconcilier les chiffres.

Faire du reporting une tour de contrôle plutôt qu'un recueil de tableaux

Direction écartée

Une galerie de graphiques exhaustive, juste pour montrer que la donnée existe.

Effet dans le prototype

Le comité part du même écran et discute des dossiers, plus des chiffrages.

Dashboard 360 — vue agence · Build de recette · écrans réels · données de recette
Indicateurs d'ouverture · Encours, encours en défaut, clients en défaut et validations en attente sont posés en premier, dans cet ordre : la question « où ça brûle » passe avant le détail.

Décision 02Lecture territoriale

Un taux de défaut national ne dit pas où agir. Le risque est concentré sur quelques agences et quelques régions, et la moyenne le masque.

Doubler chaque indicateur d'une lecture territoriale

Direction écartée

Une carte illustrative, sans seuil ni classement actionnable.

Effet dans le prototype

L'arbitrage porte sur des agences nommées, pas sur une moyenne.

Vue territoriale — carte du risque · Build de recette · écrans réels · données de recette
Criticité par agence · Chaque agence porte son niveau de criticité : la carte sert à décider où intervenir, pas à décorer le rapport.

Décision 03Conformité et activité

Un rapport de défaut est lu par la ligne métier, les risques et l'audit. Ils ne cherchent pas la même chose, et un score unique ne satisfait aucun des trois.

Séparer l'activité de la conformité, dans le même rapport

Direction écartée

Un score de conformité unique, impossible à défendre en revue.

Effet dans le prototype

Chaque lecteur trouve sa vue, et chaque chiffre reste traçable.

Conformité & activité · Build de recette · écrans réels · données de recette
Couverture par segment · La couverture BAM est lue par segment : c'est la partie qui rend le reporting défendable en revue interne.

Niveau de preuve et confidentialité

Build de recette · écrans réels · données de recette

Ce qui est montré ici est le module Reporting, tel qu'il existe dans le build de recette : écrans réels, valeurs de recette.

Les écrans de traitement de dossier ne sont pas publiés : ils contiennent des données de débiteurs et restent réservés à une présentation en direct, en entretien. Les agences, régions et montants visibles sont anonymisés ou remplacés par des données de recette, pour que la logique de lecture puisse être discutée sans exposer un portefeuille réel. Aucun chiffre de cette page ne doit être lu comme un résultat de production : la plateforme est en développement.

Ouvrir le module Reporting ↗

Ma part, et celle des autres

Design, ligne métier recouvrement, risques, juridique, ingénierie

Ce que j'ai porté

Architecture de l'information du module Reporting
Hiérarchie des indicateurs et règles de lecture
Design de données : cartes, classements, seuils
Livraison des écrans jusqu'au build de recette

Ce qui ne venait pas de moi

Risques: Seuils réglementaires, règles de provisionnement, définition du défaut.
Juridique: Motifs de rejet, formulation d'escalade, exigences de piste d'audit.
Ligne métier recouvrement: Priorités de traitement, réalité terrain des agences, quorum du comité.
Ingénierie: Modèle de données, agrégations, performance des vues consolidées.

Chaîne de livraison

Découverte → build de recette

01DécouverteObservation des agents de recouvrement sur le tableur, l'écran principal et la messagerie.Cartographie des lectures réellement utilisées avant décision.Ligne métier recouvrement
02StructureUn dossier par compte en défaut : historique, promesses, prochaine action, responsable.Architecture de l'information du module.Design
03LogiqueRecouvrabilité et délai classés avec une raison énoncée, jamais un score opaque.Règles de classement écrites, lisibles hors interface.Risques
04RevueClassement revu par les risques, formulation d'escalade revue par le juridique.Motifs de rejet et quorum consignés.Risques / juridique
05PassationÉtats de workflow, seuils d'escalade et exigences de piste d'audit documentés.Spécifications d'états remises à l'ingénierie.Ingénierie
06Build de recetteÉcrans du module Reporting assemblés sur données de recette.Écrans réels — en développement

Projet suivant03 / Voyage en Banque ↗

Rendre la réservation de vol compréhensible au sein d'un produit financier réglementé.

Ouvert aux postes senior product / UX-UI designer en télétravail

hello@badrbenali.com ↗LinkedIn ↗

← Tous les travauxBadr Benali — Product design