Dans ce cours, je suis dans la peau d’un consultant freelance contacté par un nouveau client, un réseau d’agences bancaires historique, spécialisé en banque de détail : le Crédit Breton.
Les collaborateurs du Crédit Breton constatent que :
La qualité des dossiers de prêts immobiliers accordés diverge au sein du réseau.
Les délais de prise de décision sur l’accord ou le rejet des prêts sont beaucoup trop longs.
Mon interlocutrice, récemment nommée cheffe de projet, s’appelle Jeanne ; elle souhaite me proposer une mission, mais ne sait pas comment démarrer.
Découvrez le cadrage de mon projet avec Jeanne
Jeanne m’appelle pour me parler de son projet…
Voici notre conversation, prenez des notes pour essayer d'analyser sa demande ! 😉
En bref, l’objectif de Jeanne est double :
Réduire les délais de prise de décision sur l’accord des prêts.
Améliorer la qualité des dossiers de prêt validés.
Elle décrit plusieurs acteurs sur la chaîne de décision des prêts :
les conseillers bancaires en agence qui n’ont pas d’outils pour prendre des décisions à l’heure actuelle, et se basent sur leur expérience ;
le directeur d’agence qui peut confirmer ou infirmer une décision de l’un de ses conseillers ;
la cellule centrale d’étude des prêts immobiliers, qui a le dernier mot mais croule sous les demandes.
Jeanne évoque que la cause racine du délai de prise de décision est la multiplicité des données à étudier pour accorder ou refuser un prêt immobilier :
la situation professionnelle des emprunteurs (catégorie socioprofessionnelle, statut d’emploi, régularité des revenus, et montants) ;
la situation familiale des emprunteurs (leur âge, le nombre de personnes à charge) ;
le montant de l’apport personnel ;
le niveau d’endettement (de sorte à ne pas excéder 33 % des revenus) ;
la capacité d’épargne des emprunteurs (le reste à vivre).
Toutes ces données sont dans des bases de données « qui ne se parlent pas », et tout le travail est fait dans la tête des conseillers bancaires, et à la main par la cellule centrale.
Après ce premier échange téléphonique, j'ai validé avec Jeanne que le développement d’un dashboard pourrait être une solution intéressante. Celui-ci permettrait aux conseillers bancaires de consulter un « score de crédit immobilier » de leurs clients, et ainsi de savoir en quelques clics si le prêt immobilier est envisageable. Cela permettrait de gagner un temps précieux dans l’évaluation des dossiers, et de ne transmettre que des dossiers de qualité à la cellule centrale d’étude des prêts.
Pourquoi est-ce un cas d’application des outils de Business Intelligence ?
La problématique soulevée par Jeanne fait écho à celles évoquées précédemment.
Rappelez-vous :
Réconcilier des données : Pour résoudre l’enjeu du Crédit Breton, il va me falloir réconcilier toutes les informations du processus de décision évoquées par Jeanne (situation professionnelle, situation familiale, montant de l’apport…) dans un tableau de bord pour calculer un score de prêt immobilier ; c’est la force principale des outils de Business Intelligence.
Travailler à l’échelle : On imagine qu’un réseau bancaire comme le Crédit Breton gère plus d’un million de clients (les vingt premières banques de détail en France gèrent entre 1 et plus de 30 millions de clients chacune). Il nous faudra travailler avec un volume de données conséquent pour fournir un score de prêt immobilier à chacun.
Nettoyer des données : Jeanne évoque des enjeux de nettoyage de données à automatiser pour faire le lien entre les tables distinctes.
Ces 3 conditions réunies font de notre problématique un excellent cas d’application pour utiliser Microsoft Power BI.
Méfiez-vous des solutions toutes faites
Il y a des pièges dans lesquels on tombe rapidement, il s'agit d'y faire attention, et d'éviter de passer par les pratiques suivantes :
Appliquez les bonnes pratiques pour cadrer votre projet
Avant de se lancer dans un projet de développement du dashboard, voici quelques bonnes pratiques incontournables que j’utilise. Elles sont applicables quelle que soit la méthode projet utilisée (PMI, SCRUM, Design Thinking).
Bonne pratique n° 1 : Rencontrer les utilisateurs finaux
Prenez le temps d’aller auprès des utilisateurs finaux pour comprendre :
La façon dont ils travaillent au quotidien.
Comment votre projet peut servir leur besoin.
Ainsi, on est sûr de partir du bon pied !
Bonne pratique n° 2 : Réunir les parties prenantes
Organisez un atelier de cadrage avec les représentants de chacun des groupes d‘utilisateurs et votre client, pour cadrer les travaux avant de les démarrer.
Lors de cet atelier, vous pourrez partager la synthèse des entretiens avec les utilisateurs finaux, et les éléments du cadrage initial du client.
L’objectif est de s’assurer que l’ensemble du groupe est aligné sur :
le périmètre du projet ;
les critères de succès ;
l’organisation du projet ;
et le planning.
Bonne pratique n° 3 : Réaliser des User Stories
Voici la User Story que j’ai réalisée dans le cadre de mon projet de prêt bancaire avec Jeanne :
Il y a plusieurs façons de répondre à un même besoin, et nous souhaitons garder le champ libre à ce stade. Aussi, il est impossible de :
raccrocher le besoin au groupe d’utilisateurs lorsqu’il est formulé ainsi ;
prioriser le développement de cette fonction par rapport à une autre qui apporte peut-être davantage de valeur.
Bonne pratique n° 4 : Aider le groupe à se projeter via des illustrations
Profitez de l’atelier de cadrage pour montrer des illustrations de dashboards similaires.
Le plus dur pour vos futurs utilisateurs dans la phase de cadrage est de projeter ce qu’ils feront avec votre dashboard, alors qu’ils n’en ont jamais vu !
Bonne pratique n° 5 : Prototyper la solution avec un wireframe
Dans cette dernière étape de l’atelier de cadrage, que j’affectionne particulièrement, on propose au groupe de dessiner avec votre aide les éléments du tableau de bord idéal, avec un feutre et un papier format A1 ou A0.
Suite à l’atelier de cadrage réalisé avec le Crédit Breton, nous avons listé les User Stories qui correspondent aux besoins identifiés :
Conseiller bancaire (CB) | User Story 1 : En tant que CB, je veux pouvoir visualiser les demandes de prêts non traitées sur mon agence, pour prioriser mon activité. | User Story 2 : En tant que CB, je veux visualiser toutes les caractéristiques du client (situation familiale, professionnelle, apport…), pour me faire mon avis sur le potentiel de l’emprunteur. | User Story 3 : En tant que CB, je veux disposer d’une aide à la décision rapide, pour savoir si je dois accepter ou refuser la demande de prêt immobilier. |
Directeur d’agence (DA) | User Story 4 : En tant que DA, je veux pouvoir être alerté des opérations immobilières de plus de 250 000 €, pour analyser les dossiers. | User Story 5 : En tant que DA, je veux voir l’historique des opérations immobilières reçues et acceptées par mon agence, pour suivre si l’activité réalisée est conforme au prévisionnel. | User Story 6 : En tant que DA, je veux pouvoir analyser la composition de mon portefeuille de prêts par catégorie socioprofessionnelle, pour suivre si notre positionnement est le bon. |
Cellule centrale d’accord des prêts (CC) | User Story 7 : En tant que CC, je veux la performance du réseau (montant moyen des opérations, taux de demandes de prêts acceptés), pour suivre si l’activité est conforme au prévisionnel. | User Story 8 : En tant que CC, je veux suivre l’historique des opérations immobilières reçues, pour piloter l’activité au quotidien vis-à-vis des agences. | User Story 9 : En tant que CC, je veux voir la performance des agences (taux de demandes de prêts acceptées, nombre de dossiers), pour intervenir auprès des agences qui sont sous-performantes en quantité et en qualité des dossiers. |
Cela nous a permis de dessiner ensuite une représentation basique du futur tableau de bord (wireframe).
Dans le cadre du projet pour le Crédit Breton, nous aurons une page d'accueil qui contient les consignes d'utilisation, et à partir de laquelle on pourra consulter 3 pages :
La page des indicateurs globaux.
La page de performance des agences.
La page des indicateurs et de recherches.
Bonne pratique n° 6 : Fixer des points d’étapes réguliers
Cela vous permettra de :
valider étape par étape la réalisation du dashboard ;
ne pas perdre des semaines de développement en vous apercevant trop tard qu’une hypothèse de départ était erronée.
En résumé
Prenez le temps d’aller auprès des utilisateurs finaux pour comprendre et collecter leur besoin.
Documentez les fonctionnalités attendues en utilisant les User Stories.
Organisez un atelier de cadrage pour aligner vos commanditaires sur le périmètre du projet et les critères de succès.
Montrez des illustrations de dashboards pour permettre à vos commanditaires de se projeter sur le résultat final.
C'est la fin de cette première partie, je vous propose un quiz avant de passer à la suite !
