Données

Appliquer la méthodologie adéquate pour les cas d’usage du secteur financier

Créé le

29.08.2022

-

Mis à jour le

06.10.2022

Dans un contexte économique plus qu’incertain, avoir un avantage comparatif dans l’utilisation de données-clients pour orienter la stratégie-produits et les marchés potentiels n’a jamais été aussi important pour le secteur financier. Malheureusement, un nombre encore trop élevé d’investissements est réalisé sous un angle « espérance de retour sur investissement » plutôt qu’en « ROI garanti ».

Optimisation de la relation client via l’ultra-personnalisation, segmentation de la clientèle plus fine et reflétant davantage la réalité, prédiction des besoins et optimisation des ventes, amélioration des calculs de probabilités de défaut, prédiction et lutte contre l’attrition des clients, fidélisation des collaborateurs, identification en temps réel des comportements atypiques pour lutter contre la fraude, aide à la décision sur les marchés financiers, audit en continu... Le champ applicatif d’une bonne utilisation des données (data) est colossal et les conséquences non moindres : celui du déploiement de cas d’usage pertinents en retour sur investissement (ROI) garanti.

Si certains cas d’usage sont devenus classiques, la plupart relèvent encore de l’expérimentation sans garantie de résultat. Les raisons des échecs sur ces projets sont diverses : cas d’usage insuffisamment décrits, quantité ou qualité des données insuffisante, complexité de l’industrialisation, etc. Aussi, les banques et les assurances n’ont tout simplement pas encore l’organisation et la culture adéquates pour tirer parti d’une valorisation optimale de leurs données.

Pour exploiter ses données de masse, une organisation financière dispose généralement d’un outil Data Lake, centralisant les données de différents systèmes sources mais aussi d’une solution de gestion des données, garantissant que tous les collaborateurs aient accès à des données fiables à tout moment, ainsi qu’éventuellement d’une solution de data virtualization pour rendre accessible plus facilement les données sous forme de reportings prédéfinis.

Pourtant, le Data Lake, espace de stockage global et complet, ne permet pas d’inscrire les données au sein d’un modèle métier et de servir un cas d’usage spécifique en phase avec les enjeux de sécurité, de qualité, de gouvernance et de traçabilité des données de l’organisation. Il en est de même pour un simple outil de gestion des données.

Optimiser l’utilisation des cas d’usage data

Quelles optimisations mettre en place pour garantir le ROI d’un cas d’usage data ? Tout d’abord, outre la nécessaire sensibilisation des collaborateurs à la data, l’adoption d’une philosophie essai/erreur avec le droit à l’échec (try fast/fail fast), l’acceptation d’arbitrages et de renoncements sont des prérequis indispensables au pilotage des cas d’usage data. Oui, la garantie de résultat, c’est aussi le droit à l’échec dans l’expérimentation. Le métier doit être particulièrement conscient des risques inhérents à ce type de projets : en effet, pas de ROI « à coup sûr ». L’acceptation, culturellement et budgétairement, d’un certain taux d’échec s’avère indispensable et l’intérêt économique à arrêter le plus tôt possible les projets sans avenir se démontre de plus en plus. Il est possible de capitaliser d’un point de vue méthodologique sur les échecs et les réussites. En parallèle, un backlog alimenté d’idées de cas d’usage doit être maintenu en temps réel.

Une fois cette marche culturelle franchie, la première étape est sans doute la prise de recul nécessaire à la maturation de l’usage recherché. En plus de l’identification habituelle du besoin métier avec des indicateurs clés de performance (KPI) business et estimation du ROI s’ajoute une phase d’« idéation data », assez nouvelle pour une institution financière. En effet, avant même de réfléchir aux premiers algorithmes, un cadrage du datalab s’impose : cycle « collecte de données, mise en forme et qualité, data mining, conformité et sécurité de la donnée » en méthode agile pour identifier au plus tôt les problèmes ou les impossibilités en amont (problème de qualité des données, récupération des consentements à l’utilisation de données à caractères personnelles, etc.).

C’est seulement une fois cette large phase de cadrage effectuée que la recherche d’algorithmes proprement dite peut démarrer, avec la réalisation du modèle par itérations jusqu’à performance souhaitée. Les KPIs algorithmiques adaptés en fonction des modèles choisis (matrice de confusion pour modèles de classification, MSE pour courbes de régression...) auront été préalablement définis.

La phase délicate de l’industrialisation

Avant d’envisager un déploiement à grande échelle, un test du modèle en condition réelle d’utilisation avec retour d’expérience devra être réalisé via un ou plusieurs pilotes. Si cette mise en situation de production est validée, la phase d’industrialisation pourra alors s’ouvrir.

Cette phase d’industrialisation est très certainement la plus délicate pour les institutions financières. En effet, comment faire cohabiter au sein du legacy traditionnel des lignes de codes source qui entraînent et réentraînent le modèle en temps réel ? Outre les recettes IT et métier éprouvées sur des données de production, une méthodologie du développement du processus industrialisé de bout en bout doit être déployée (data preparation, feature engineering, écriture du code, refactoring production du score, exposition et IHM, sécurité du modèle et monitoring).

Enfin, la mise en marché du modèle s’accompagnera d’un packaging robuste autour de contrôles qualité, suivi de la performance, réentrainement régulier du modèle et gestion des évolutions du modèle.

L’intérêt sera donc de construire ce modèle de pilotage des cas d’usage data suivant une méthodologie éprouvée et structurée entre Business Owners, Product Owners et Data Scientists.

Au-delà de ces points managériaux et organisationnels, il ne faut jamais oublier les aspects humains. Cela vaut pour la technologie de manière plus générale et en particulier pour la data. Il est rare qu’un Data Scientist puisse à la fois poser les bonnes questions, puis traiter les données pertinentes, en tirer les enseignements, et enfin comprendre et communiquer ce que cela signifie pour la banque ou l’assurance. Pour qu’un projet use case data crée de la valeur, il doit se structurer autour d’un trinôme business owner, product owner et Data Scientist et se traiter en mode projet agile, avec un delivery à six mois maximum.

Le contexte économique et réglementaire mondial, le besoin de personnaliser l’expérience-client et l’innovation véloce des fintechs imposent au secteur financier une transformation structurelle.

À ces défis s’ajoute la capacité à exploiter intelligemment un volume de données d’entreprise disparates mais de façon granulaire et sécurisée pour répondre aux besoins de l’ensemble des métiers.

Développer une méthodologie de pilotage des cas d’usage data innovants et agiles, tenant compte des réalités de l’organisation, et capable de suivre l’évolution des besoins métiers, permettra à chaque utilisateur de s’approprier rapidement son propre modèle métier pour à la fois observer et exécuter rapidement des données en se basant sur une approche itérative. Une agilité conçue autour du « besoin », indispensable au dynamisme et à la transformation du secteur financier.

À retrouver dans la revue
Revue Banque Nº871