Thibault BRÉGAL

Mots-clés : Big Data, Microsoft Azure Cloud, Scoring, Scikit-learn, Data Viz

Ce dossier a pour objet la mise en place d’une architecture d’acheminement

et de traitement de la donnée de bout en bout, dans le Cloud. Les données
exploitées et valorisées tout au long de cette chaîne de valeur concernent la
détection de transactions frauduleuses, et sont constituées de 750 000
observations au total : un jeu de calibration de 500 000 lignes, et un jeu de
validation qui en compte 250 000.

Nous les avons chronologiquement extraites, stockées, nettoyées,

transformées, modélisées puis visualisées grâce à une variété d’outils dans le
Cloud. Nous avons également mis l’accent sur la mise en place d’une solution
prédictive de détection de fraudes.

Ce document résume les principaux résultats et étapes qui ont abouti à nos
différentes conclusions, dans le cadre du mémoire / rapport de stage de
validation de Master 2 d’Économétrie & Statistiques Appliquées de l’IAE de
Nantes.

Les dernières décennies ont été marquées par une explosion du nombre de
sources de données, et des volumes dont elles font l’objet. La mise à l’échelle
nécessaire aux solutions et machines sur site vis-à-vis de cet essor est très difficile
à atteindre pour la plupart des entreprises.

C’est pour cette raison que nous avons décidé d’étudier la problématique de
la mise en place d’une architecture de valorisation de la donnée dans le
cloud, et par extension de l’optimisation de ses coûts engrangés.

Page 1 sur 4
Résumé quatre-pages, rapport de stage - BRÉGAL Thibault
 1. Extraction & stockage

Dans un premier temps, nos données bancaires nous ont été transmises
par la partie Data ingénierie de notre pôle, qui a rempli un lac de données
Azure Blob Storage. Les données sont stockées en format parquet afin
d’optimiser leur taille, et plusieurs vues métiers sont créées selon les demandes
des scientifiques des données. Nous nous sommes chargés de récupérer,
nettoyer, puis transformer ces données, avant de les charger dans un entrepôt
analytique.

2. Chargement et transformation des données dans l’entrepôt

La poussée des données vers l’entrepôt Snowflake s’est effectué via un outil dit
« ETL » : Matillion. C’est grâce à ce dernier que nous avons pu extraire les
données du Data Lake, alors compressées en format colonnes parquet, pour
les aplatir puis les héberger et les exploiter au sein de Snowflake.

Tâche
d’orchestration

Tâche de
transformation

Dans Snowflake, l’aspect T, pour Transformation, du processus ETL est assuré par
dbt. C’est cet outil qui nous a permis de modéliser différentes tables
relationnelles à partir de notre base de données. Nous avons ainsi pu nous

Page 2 sur 4
Résumé quatre-pages, rapport de stage - BRÉGAL Thibault
adapter à un besoin métier fictif et mettre en place les tables de
dimension et le linéage suivant :

→ transactions_dim donne les informations générales de chaque transaction :

ID des transactions, date, montant, type de transaction, et si elles sont
frauduleuses ou non.

→ parties_transactions_dim concerne les parties prenantes aux transactions :

ID émetteur & destinataire, date, et soldes avant et après transaction.

→ date_transactions_dim comporte la date de transaction et tous les attributs

créés à partir de celle-ci : mois, jour de la semaine, week-end, heure, et nuit.

3. Création de variables et d’une solution prédictive ML

À l’image de l’intégration assurée entre les outils détaillés jusqu’à présent, nous
avons connecté une instance de calcul Jupyter Notebook du service Azure ML
à notre entrepôt de données. Les 21 variables obtenues suivant l’étape de
création ont pour objectif de prédire au mieux l’appartenance à la classe
fraude des transactions du jeu de validation.

Nombre de transactions par type Nombre de fraudes par types

Page 3 sur 4
Résumé quatre-pages, rapport de stage - BRÉGAL Thibault
Les types de transaction les plus récurrents sont les paiements, les cash out
et les cash in ; et les transactions frauduleuses appartiennent uniquement
aux classes cash out et transfer.

Après analyse des corrélations entre nos variables explicatives, et de leur

significativité statistique au sein de modèles d’arbres de décision, de forêts
aléatoires, et de descentes de gradient, nous avons retenu le modèle qui suit.

Min
Modèle Criterion Max F1-score Matrice de
samples
depth confusion
split
Arbre de Entropie 2 0,1 0,979654
décision

Le modèle ci-dessus possède 7 variables explicatives qui permettent de

détecter 214 fraudes sur les 215 présentes au sein des 250 000 observations du
jeu de données de validation :

newbalanceorig Solde post transaction de l’émetteur

DIFF_SOLDE_ORIG Différence des soldes ex-post et ex-ante de l’émetteur
DIFF_SOLDE_DEST Différence des soldes ex-post et ex-ante du destinataire
type_cash_out L’appartenance au type de transaction « cash_out »
Vérification d’égalité entre la différence des soldes ex-post
VERIF_SOLDE_ORIG et ex-ante de l’émetteur et le montant de la transaction
« amount »
newbalancedest Le solde post transaction du destinataire
amount Montant de la transaction

L’intégration de tous les outils présentés au cours de ce document ont rendu

possible la mise en place d’une architecture cohérente de valorisation de la
donnée, de son ingestion jusqu’à sa consommation finale. L’assimilation des
problématiques de scalabilité et de parallélisation des tâches m’a permis de
me familiariser avec l’optimisation des coûts et des ressources mobilisées, de
même qu’avec de nombreux outils. La finalité de cette chaîne de valeur a été
la production d’un modèle de détection de fraude de très bonne qualité.

Page 4 sur 4
Résumé quatre-pages, rapport de stage - BRÉGAL Thibault