Rapport PFE Haikel BelHaj Fraj PDF

Dédicace
C’est avec grande émotion que je dédie ce travail :
À ceux qui sont toujours mon meilleur exemple dans la vie : mon cher père et ma mère
pour les sacrifices qu’ils ont consentis pour mon éducation, pour leur amour et affection.
Au symbole de douceur et de tendresse : mes frères Zied et Tarek, je vous dédie ce

travail en témoignage des liens forts et intimes qui nous unissent, pour votre soutien et vos
encouragements.
À tous mes amis qui n’ont cessé de me réconforter tout au long de ce projet et mes
collègues de promotion avec lesquels, j’ai passé mes meilleurs années d’études.
À mes chers encadrants et enseignants, qui m’ont aidé à réaliser ce travail, je présente
mes vifs remerciements et les expressions respectueuses de ma profonde gratitude.
Haikel BEL HAJ FRAJ
i
Remerciements
Ceci est un hommage à toutes les personnes qui, d’une manière ou d’une autre,
ont contribué à l’achèvement de ce projet de fin d’études. Avant tout, je voudrais
remercier Dieu pour m’avoir donné la force, les connaissances et les capacités.
J’ai l’honneur de présenter mes vifs remerciements à Mm.Imen BEN CHEIKH,

mon encadrante académique. J’ai eu beaucoup de chance qu’elle a consacré son
temps à répondre à mes questions et à être toujours présente avec son support
moral et ses conseils.
Des remerciements spéciaux à M. Firas JLASSI, mon encadrant chez INIR.

Grâce à sa supervision et ses conseils, malgrè les conditions exceptionnelles du
travail à distance imposées par la situation sanitaire, ce travail a vu le jour.
Je suis également reconnaissant à tous les membres du pôle Intégration chez INIR,
leur accueil était chaleureux et leur remarques étaient très appréciés.
Enfin, je suis profondément reconnaissant à tous les membres du jury d’avoir

accepté d’évaluer et d’apprécier la soutenance de mon travail tout au long de mon
stage.
ii
Table des matières
Dédicace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Introduction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1 Cadre général 4
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Présentation de l’organisme d’accueil : INIR . . . . . . . . . . . . . 5
1.2 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Aperçu sur l’existant . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Les clients cibles . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . 8
1.2.5 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . 9
1.2.6 Exigences et contraintes . . . . . . . . . . . . . . . . . . . . 9
1.3 Démarche de travail et méthodologies . . . . . . . . . . . . . . . . 10
1.3.1 Découverte de connaissances dans les bases de données (Know-

ledge Discovery in Databases : KDD) . . . . . . . . . . . . 10
iii
1.3.2 SEMMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.3 CRISP-DM . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.4 Comparaison et méthodologie adoptée . . . . . . . . . . . . 14
1.3.5 Méthodologie choisie : CRISP-DM . . . . . . . . . . . . . . 15
1.4 Plannification du projet . . . . . . . . . . . . . . . . . . . . . . . . 16
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 Etat de l’art 18
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1 Notions théoriques . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.1 Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.2 L’apprentissage Automatique . . . . . . . . . . . . . . . . 24
2.1.3 Le Cloud Computing . . . . . . . . . . . . . . . . . . . . . 25
2.2 Compréhension du logique métier . . . . . . . . . . . . . . . . . . 28
2.2.1 Les assurances médicales . . . . . . . . . . . . . . . . . . . 28
2.2.2 Le système médicale aux états-unis . . . . . . . . . . . . . . 29
2.3 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.1 La plateforme Solon . . . . . . . . . . . . . . . . . . . . . . 30
2.3.2 SAS Healthcare . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.3 Système de prevention des fraudes . . . . . . . . . . . . . . 32
2.3.4 OSP Healthcare . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.5 La critique . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
iv
3 Etude et traitement des données 35
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1 Compréhension des données . . . . . . . . . . . . . . . . . . . . . . 36
3.1.1 Les services et les paiements des fournisseurs de textbfMe-

dicare : Médecins et autres fournisseurs (partie B) . . . . . 37
3.1.2 L’utilisation et le paiement des fournisseurs de Medicare :

Prescripteur (Partie D) . . . . . . . . . . . . . . . . . . . . 38
3.1.3 Liste des individus et entités exclues : LEIE . . . . . . . . . 40
3.2 Préparation des données . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.1 Séléction des caractéristiques . . . . . . . . . . . . . . . . . 41
3.2.2 Nettoyage des données . . . . . . . . . . . . . . . . . . . . 41
3.2.3 Construction de l’ensemble de données . . . . . . . . . . . . 42
3.2.4 Préparation du module temps réel . . . . . . . . . . . . . . 43
3.3 Modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.1 Les algorithmes d’apprentissage automatique . . . . . . . . 44
3.3.2 Métriques d’évaluation . . . . . . . . . . . . . . . . . . . . 48
3.3.3 Apprentissage continu . . . . . . . . . . . . . . . . . . . . . 49
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4 Réalisation et implémentation 52
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
v
4.2.1 Architecture logique . . . . . . . . . . . . . . . . . . . . . . 57
4.2.2 Cadre technique du travail . . . . . . . . . . . . . . . . . . 59
4.2.3 Déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2.4 Présentation des résultats . . . . . . . . . . . . . . . . . . . 75
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Conclusion 81
Nétographie 83
Annexes 87
Annexe : Glossaire des données 87
vi
Liste des figures
1.1 INIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Processus KDD [1] . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Processus SEMMA [2] . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Le processus CRISP-DM illustré [4] . . . . . . . . . . . . . . . . . 13
1.5 Etude de la popularité des méthodes de travail [5] . . . . . . . . . 15
1.6 Diagramme de Gantt. . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1 L’architecture Lambda [7] . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 IT traditionnel vs. IaaS vs. PaaS vs. SaaS [10] . . . . . . . . . . . . 26
2.3 Application Traditionnelle vs. Application Serverless [11] . . . . . . 27
2.4 L’interface de la solution SAS Detection and Investigation for Health

Care [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.5 Le processus de fonctionnement de la solution de OSP [16] . . . . 33
3.1 Distribution des paiements versées par domaine de spécialité . . . . 38
3.2 La distribution des 10 médicaments les plus demandés . . . . . . . 39
3.3 Nombre de fraudes par état . . . . . . . . . . . . . . . . . . . . . . 40
vii
3.4 Illustration de la procédure de construction du jeu de données . . . 43
3.5 Matrice de confusion [27] . . . . . . . . . . . . . . . . . . . . . . . 49
3.6 Cycle d’entraînement continu . . . . . . . . . . . . . . . . . . . . . 50
4.1 Matrice de confusion de l’algorithme Logistic Regression . . . . . . 54
4.2 Matrice de confusion de l’algorithme GaussianNB . . . . . . . . . . 54
4.3 Matrice de confusion de l’algorithme RandomForestClassifier . . . . 55
4.4 Matrice de confusion de l’algorithme ExtraTreesClassifier . . . . . . 55
4.5 Matrice de confusion de l’algorithme GradientBoostingClassifier . . 56
4.6 Matrice de confusion de l’algorithme XGBoost . . . . . . . . . . . 56
4.7 Matrice de confusion de l’algorithme SVC avec Kernel RBF . . . . 57
4.8 Architecture logique de la solution . . . . . . . . . . . . . . . . . . 58
4.9 Le flux de Spark Streaming [29] . . . . . . . . . . . . . . . . . . . 60
4.10 Scikit Learn [30] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.11 Pandas [31] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.12 L’interface de Microsoft Azure . . . . . . . . . . . . . . . . . . . . 63
4.13 L’interface de Azure Event Hub . . . . . . . . . . . . . . . . . . . 64
4.14 L’architecture de Azure Event Hub [33] . . . . . . . . . . . . . . . 64
4.15 L’interface de Azure Databricks . . . . . . . . . . . . . . . . . . . 66
4.16 Le processus du module Ingestion des données [35] . . . . . . . . . 66
4.17 L’écosystème de Azure Databricks [35] . . . . . . . . . . . . . . . . 67
4.18 Cluster utilisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.19 Structure de fichier du Data Lake [36] . . . . . . . . . . . . . . . . 70
viii
4.20 L’interface d’Azure Storage Explorer . . . . . . . . . . . . . . . . . 71
4.21 Architecture Logicielle . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.22 Gestion du cycle de vie du modèle . . . . . . . . . . . . . . . . . . 75
4.23 Exposition de l’API du modèle . . . . . . . . . . . . . . . . . . . . 75
4.24 Rapport en vue d’ensemble . . . . . . . . . . . . . . . . . . . . . . 76
4.25 Rapport de suivi de demande par fournisseur . . . . . . . . . . . . 77
4.26 Rapport de suivi par fraud identifié . . . . . . . . . . . . . . . . . 78
4.27 Rapport de suivi en temps réel . . . . . . . . . . . . . . . . . . . . 79
ix
Liste des tableaux
1.1 Tableau comparatif des méthodologies de travail . . . . . . . . . . 14
4.1 Tableau détaillant les dépenses sur les outils Azure par semaine . . 72
x
Liste des abbréviations
ML Machine Learning
IA Intélligence Artificielle
CRISP-DM CRoss-Industry Standard Process for Data Mining
CMS Center for Medicare Services
LEIE List of Excluded Individuals and Entities
CRUD Create Read Update Delete
AUC Area Under Curve
SVC Support Vector Classifier
RBF Radial Basis Function
HDFS Hadoop Distributed File System
API Application Programming Interface
xi
Introduction générale
L’augmentation des frais médicaux et l’accès à de bonnes ressourceS

médicales peuvent être difficiles à supporter financièrement. C’est pourquoi une
couverture d’assurance maladie pour assurer la protection dont on a besoin est
une nécessité. En fait, elle s’agit d’un accord par lequel la compagnie d’assurance
accepte de s’engager à garantir l’indemnisation des frais médicaux à la personne.
Cependant, certains individus détournent le processus de remboursement

pour des raisons malveillantes. En effet, les assurances médicales partout dans le
monde ont subi une croissance exponentielle dans les tentatives d’arnaque. Ce
qui a engendré des pertes en terme de montantS versés aux avis des demandes
frauduleuses. Ces montants ont atteint des milliards de dollars comme le cas des
états unis. Ainsi, les assurances, privées et publiques, ont dû prendre différentes
décisions pour remedier cette problématique.
Dans la plupart des assurances, la fraude n’est identifiée qu’après avoir

eu lieu. Les méthodes classiques de détection des demandes suspectes nécessitent
du temps ainsi que des ressources humaines. Ce qui a rendu l’étude de chaque
dossier entrant exhaustive. Des mesures devaient alors être prises pour surmonter
ce problème.
La réponse la plus évidente qui se présente dans ce cas, est l’informatique.
1
Avec son developpement rapide et continu, migrer vers une solution informatique
qui automatise les processus et transforme les fonctionnements axials vers le digital
est devenue un atout pour toute entreprise comme les assurances maladie.
Dans ce cadre, pour résoudre leurs problématiques, les assurances mé-

dicales peuvent mettre en oeuvre une telle solution informatique intélligente qui
détecte les fraudes. Toutefois, avec l’evolution démographique mondiale et vu le
nombre très important de demandes de remboursements que reçoit une assurance
maladie par jour, les deux autres contraintes à prendre en considération lors de
la définition d’une solution informatique sont l’aspect Big Data et l’espect temps
réel.
C’est dans ce contexte que se situe notre travail. Notre projet consiste en la mise
en place d’un système Big Data qui permet la détection des fraudes pour une assu-
rance médicale. Ce système sera capable de récuperer le flux entrant des demandes
et de détecter celles frauduleuses. En outre, il doit être autonome en minimisant
les interventions humaines.
Nous devons implémenter l’architecture de ce système sur le cloud pour garantir
une meilleurE performance et profiter de l’infrastructure disponible et hautement
sécurisé.
Ce rapport est une synthèse de notre travail éffectué dans le cadre du

projet de fin d’étude en vue de l’obtention du diplôme national d’ingénieur infor-
matique réalisé au sein de INIR.
Dans le premier chapitre, nous allons présenter le cadre de notre travail

et la méthodologie suivi tout au long de ce projet.
Dans le deuxième chapitre, nous élaborons l’état de l’art, les concepts clés de
notre travail, ainsi qu’une compréhension du métier suivi par une étude de
l’existant.
2
Ensuite, dans la troisème partie, nous allons entamer l’exploration des données
et la modélisation.
Finalement, nous allons présenter dans le dernier chapitre la réalisation et
implémentation de notre solution tout en présentant son cadre technologique.
3
CHAPITRE 1
Cadre général
Sommaire
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Présentation de l’organisme d’accueil : INIR . . . . . . . . . . . . . 5
1.2 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Aperçu sur l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Les clients cibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.5 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.6 Exigences et contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Démarche de travail et méthodologies . . . . . . . . . . . . . . . . . 10
1.3.1 Découverte de connaissances dans les bases de données (Knowledge

Discovery in Databases : KDD) . . . . . . . . . . . . . . . . . . . . . . 10
1.3.2 SEMMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.3 CRISP-DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.4 Comparaison et méthodologie adoptée . . . . . . . . . . . . . . . . . . 14
1.3.5 Méthodologie choisie : CRISP-DM . . . . . . . . . . . . . . . . . . . . 15
1.4 Plannification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4
CHAPITRE 1 Cadre général
Introduction
Au cours de ce chapitre, nous allons aborder le contexte général du pro-

jet. Ainsi, nous présenterons, en premier lieu, l’organisme d’accueil. Nous expli-
querons, par la suite, le projet en le mettant dans son contexte et en exposant la
problématique à résoudre ainsi que notre contribution dans la solution proposée.
Enfin, nous allons décrire la méthodologie de développement adoptée tout au long
de notre travail.
1.1 Présentation de l’organisme d’accueil : INIR
INIR Tunisie est une société de services informatiques , basée à Tunis,

expert dans l’accompagnement de la transformation agile. Les expertises de ce
centre se répartissent sur 3 axes :
- Développement Java EE, Open source et .Net.
- Développement des applications Mobile.
- Intégration de progiciels de Billing et CRM
Figure 1.1 – INIR
5
1.2 Cadre du projet
Dans cette partie, nous allons présenter gloablement le projet. En pre-

mier lieux, nous fournissons un aperçu sur l’existant. Par la suite, nous détaillons
la problématique, et nous clotûrons par la solution proposée.
1.2.1 Aperçu sur l’existant
Les assurancesxmédicalesxpartout dansxle monde étaient toujours à l’en-

contre du problème des demandes frauduleuses. Que ce soit unexfausse déclaration
ou une demandexavec un montant exagérée. Ainsi, pour détecter toute éventuelle
fraudes ces assurances ont dù étudierxet suivre chaque demandes. Ce qui est
une perte dextemps vu l’insuffisance des ressourcesxhumaines et la croissance
du fluxxentrant des demandes. De meme la base desxdemandes historisées est
toujours en train de s’élargir, du coup, sa gestion en terme de stockagexet ex-
traction des informations est devenue encore plus difficile. D’ici, implémenter une
solutionxinformatique s’est présenté comme la solution indispensable qui pourra
automatiser tout le processus et allèger la charge de gestion des demandes.
1.2.2 Les clients cibles
Dans ce projet lesxclients cibles sont les assurances médicales avec les-
quels INIR travaille. Ces assurances là ont besoin de détecter en premier les lieux
les fraudes sur le gros flux des demandes entrantes.
Pour se conformer à leur obligation KYC (Know Your Customer) 1 , les assurances
médicales doivent implémenter un système capable d’être en récepetion continu
1. Connaissez votre client
6
des demandes tout en identifiant celles qui sont frauduleuses.

Automatiser le processus d’étude des demandes pourra faire gagner l’assurance
des millions de dollars à travers les fraudes détectées, temps gagné et même dans
la prise des décisions.
1.2.3 Problématique
La plupart des prestataires médicaux sont intègres et travaillent avec

acharnement pour améliorer la qualité des services sanitaires fournies. Cepen-
dant, quelques-uns exploitent les moyens et l’opportunité et en profitent pleine-
ment pour faire des bénéfices illégitimes.
En fait, il est impossible de quantifier avec précision le coût de la fraude à l’assu-
rance maladie mais, avec une croissance importante et continue des primes et du
nombre de vies couvertes, le problème est toujours en train de s’aggraver.
Ces fraudes entraînent des pertes importantes pour les prestataires de services
d’assurance, mais elles peuvent aussi avoir un impact sur les bénéfices de l’assu-
rance maladie pour les clients authentiques. Prenons l’exemple des Etats-Unis,
l’agence gouvernementale qui fournit les assurances maladies aux personnes les
plus âgées ou les plus pauvres de la communauté, appelée la CMS : Center for
Medical Services a été exposé à des fraudes atteignant 367 millions de dollars sur
les paiements inexacts représentant 10% des dépenses globales de santé vu que
cette agence est financée par le gouvernement.
De même, les assurances privées sont toujours à l’encontre du même problème.
Les mesures déjà prises par la majorité de ces entités ont été prouvées inefficaces
et non-fiables, et l’étude dossier par dossier est devenue presques impossible vue
l’insiffisance des ressources humaines et la perte du temps.
Cela étant dit, il est également primordiale d’implémenter une solution infor-
7
matique qui sera capable d’automatiser le processus d’étude des demandes de

remboursement des assurances ce qui nous ramène aux objectifs de ce projet.
1.2.4 Besoins fonctionnels
Identifier les besoins à satisfaire est une étape primordiale qu’on doit
mettre en oeuvre pour qu’on puisse aboutir à un projet qui sera à l’encontre des
attentes du client en lui fournissant un ensemble de fonctionalités :
- Ingestion des demandes en temps réels : La solution doit être capable

de recevoir des millions de demandes de remboursement et les traiter
- Prédiction en temps réels sur le flux entrant : Le système doit détecter

les demandes suspectes d’être frauduleuses qui viennent d’être reçu par le
système. Un modèle d’apprentissage automatique doit être déployé et en
production pour qu’il traite la totalité des demandes ingérées.
- Stockage des demandes : Les demandes de remboursement entrantes

doivent être stockées dans leurs formes brûtes ainsi que traitées et accessibles
à l’utilisateur.
- Rapport et dashboard : L’assurance peut accéder à tout moment à un

rapport détaillé sur les demandes de remboursements historisées, ainsi qu’un
dashboard temps réels lui permettant de visualiser les informations realtives
à la demande entrante et si elle est suspecte fraude ou pas.
- Automatisation des tâches : l’ensemble des traitements éffectués sur la

masse des données ainsi que le flux des demandes dans le système doit être
automatisé et planifié par l’assurance pour qu’il s’éxecute avec le déclenche-
ment des triggers temporels.
8
1.2.5 Besoins non fonctionnels
- Rapidité : Notre solution doit être capable de répondre rapidement au flux

des demandes entrantes
- Sécurité : Le flux des données dans le système et le stockage doivent être

réalisés en toute sécurité.
- Scalabilité : Les ressources de stockage et d’ingestion de données doivent

être capable à s’adapter à l’ampleur du flux
- Performance : Le modèle doit prédire correctement et détécter les éven-

tuelles fraudes et le taux de perte doit être minimsé
1.2.6 Exigences et contraintes
Ce projet a pour but d’assister les assurances médicales à minimiser les

pertes dans les paiements aux avis des demandes frauduleuses. Pour implémenter
une telle solution, on doit positionner le système conçu dans un contexte de gestion
des demandes des dfférents aspects. Ainsi, il s’agit d’une solution Big Data qui
consiste en :
• Concevoir et mettre en production un modèle capable de détecter les tenta-

tives des fraudes.
• Créer une architecture capable de gérer le grand flux des demandes entrantes
d’où une manipulation en temps réels.
• Créer un dashboard pour servir les résultats du temps réels ainsi que les
données historiques.
9
1.3 Démarche de travail et méthodologies
Le fait de suivre une méthodologie bien définie permet à un projet de

fournir de meilleures évaluations, de livrer des systèmes fiables, de tenir le client au
courant, de créer une compréhension claire de la tâche à accomplir et d’identifier
les obstacles plus en avance, ce qui laisse suffisamment de temps pour faire des
ajustements. Ainsi, cette section présente différentes méthodologies de travail avec
leurs avantages et leurs limites et explique pour finir avec la motivation derrière
l’approche choisie.
1.3.1 Découverte de connaissances dans les bases de données (Know-

ledge Discovery in Databases : KDD)
Le processus KDD [1], tel qu’il est présenté dans (Fayyad et al, 1996),
consiste à utiliser des méthodes d’exploration de données pour extraire ce qui
est considéré comme de la connaissance selon les mesures et les critères spécifiées
en utilisant une base de données ainsi que tout prétraitement, échantillonnage
et transformation effectuées sur cette base de données. Ce processus comprend
également les spécifications de tout prétraitement, échantillonnage et projection
des données mise en œuvre avant l’étape d’exploration de données. Le processus
est itératif, évoluant autour de l’application des étapes de la Figure 1.2
• Sélection : Création d’un ensemble de données cible, ou d’un sous-ensemble

d’échantillons, sur lequel la découverte doit être effectuée
• Pré-traitement : Activités de nettoyage et de prétraitement des données vi-

sant à fournir des données consistantes.
• Transformation : La transformation des données à l’aide de méthodes telles

que la réduction de la dimension, la sélection de caractéristiques, etc.
10
Figure 1.2 – Processus KDD [1]
• Data Mining : Recherche de modèles significatifs sous une forme particu-

lière, en fonction de l’objectif de l’exploration de données (par exemple, la
prédiction).
• Interprétation/Evaluation : Interprétation et évaluation des résultats de l’ex-

ploration
1.3.2 SEMMA
SEMMA (Sample, Explore, Modify, Model, Assess) [2] désigne le proces-

sus de réalisation d’un projet d’exploration de données. Le centre SAS Institute
considère qu’un cycle de réalisation d’un projet suivant la méthode SEMMA passe
par 5 étapes :
• Échantillonage : cette étape consiste à échantillonner les données en prélevant

une partie d’un grand jeu de données, suffisamment importante pour contenir
les informations pertinentes, mais suffisamment petite pour être manipulable.
• Explorer : cette étape consiste à explorer les données en recherchant des

anomalies et des comportement inattendues afin d’en tirer des conclusions
11
Figure 1.3 – Processus SEMMA [2]
• Modifier : cette étape consiste à modifier les données en créant, sélectionnant

et transformant les variables afin de cibler le processus de sélection du modèle.
• Modélisation : cette étape consiste à modéliser les données en permettant au

programme de rechercher automatiquement une combinaison de données qui
prédit de manière fiable le résultat souhaité.
• Évaluer : cette étape consiste à évaluer les données en appréciant l’utilité et

la fiabilité des résultats du processus d’extraction de données et d’estimer
ses performances.
1.3.3 CRISP-DM
CRISP-DM, qui signifie Cross-Industry Standard Process for Data Mi-

ning [3], a été initialement conçu par IBM dans les années 1960 dans le but de
guider et exécuter des projets Data Mining. En tant que méthodologie, elle com-
prend les descriptions des phases typiques d’un projet, les tâches impliquées dans
chaque phase et une explication les relations entre ces tâches. En tant que modèle
de processus, CRISP-DM fournit un aperçu sur le cycle de vie de l’exploration
de données. Le modèle de cycle de vie se compose de six phases avec indications
12
sur les dépendances les plus importantes et les plus fréquentes entre les phases.
L’ordre des phases n’est pas strict. En fait, la plupart des projets passent d’une
phase à l’autre selon les besoins. Le modèle CRISP-DM est souple et peut être
facilement adapté.
Figure 1.4 – Le processus CRISP-DM illustré [4]
Les 6 étapes de la méthodologie consistent en :
- La compréhension du métier : Il s’agit de la première étape durant

laquelle on fixe les objectifs de l’entreprise à travers ce projet accompagné
d’une évaluation de la situation où on identifie l’inventaire des ressources, les
exigences, hyptohèses et contraintes ainsi que les couts et avantages. Suivi par
une identification des buts de l’extraction des données en fixant les critères de
réussite de l’éxploration des données pour finalement aboutir à la production
du plan initiale du projet.
- La compréhension des données : Durant cette étape, on collecte les

données et on effectue une exploration initales en fournissant une description.
- La préparation des données : Cette étape se caractérise par tout traite-

ment qui va être effectué sur l’ensemble des données. Ces traitements sont
principalement la sélection, nettoyage, construction et intégration. Les don-
nées doivent être pretes pour les modéliser.
13
- La modélisation : C’est la phase qui concerne la construction du modèle.

Durant laquelle on paramètre différents modèles, les tester et évaluer leurs
résultats pour en choisir.
- L’évaluation : On vérifie si les résultats et connaissances obtenues satisfont

les critères et objectifs fixés au debut du cycle. Des tests spécifiques peuvent
être menés sur la fiabilité et qualité du modèle pour enfin l’approuver.
- Le déploiement : C’est la phase finale du cycle où un plan de déploiement

est fixé et réalisé et le modèle est mis en production et intégré dans le procesus
décisionnel.
1.3.4 Comparaison et méthodologie adoptée
Dans cette partie, nous allons faire une étude comparative entre les dif-
férentes méthodologies de travail susmentionnées, pour aboutir à faire notre choix
pour ce projet.
En première phase, on s’interresse à une mise en oeuvre des correspondances entre
les différentes méthodes.
Méthodologie KDD SEMMA CRISP-DM

Nombre d’etape 7 5 6
Développemet d’une connaissance Compréhension du
------
du domaine d’application métier
Sélection des données Échantillonnage Compréhension des
Prétraitement des données Exploration données
Nom de l’étape Transformation des données Modification Préparation des données

Fouille des données Modèle Modélisation
Interprétation/Evaluation Evaluation Evaluation
Application des connaissances
------ Déploiement
découvertes
Table 1.1 – Tableau comparatif des méthodologies de travail
14
A travers ce tableau, nous pouvons constater que ces trois méthodologies

se ressemblent dans le séquencement d’étapes et les tâches impliquées dans chaque
étapes. De plus, il est evident que CRISP-DM se distingue par la présence et
importance de la phase initiale la compréhension du métier.
Une différence importante entre CRISP-DM et les deux autres méthodologies est
que les transitions entre les étapes dans CRISP-DM peuvent être inversées. Ceci
est très utile lorsqu’on travaille avec des données réelles : tout faux pas peut être
corrigé sans avoir à terminer le cycle complet si vous comprenez que les données
cibles choisies ne mèneront à aucune connaissance.
En terme de popularité, une étude menée par la plateforme datascience-pm en
2020 [5], sur leur communauté de data scientists, a montré que la majorité choisit
CRISP-DM comme leurs méthode de travail préfèré. La Figure 1.5 montre la
réaprtition des choix des méthodes sur l’échantillion étudié
Figure 1.5 – Etude de la popularité des méthodes de travail [5]
1.3.5 Méthodologie choisie : CRISP-DM
La méthode choisie à suivre au tcours de ce projet est CRISP-DM.

En fait, la première étape de cette méthodologie, la compréhension de l’activité,
permet d’aligner le travail technique sur les besoins de l’entreprise et d’éviter que
les spécialistes des données ne se lancent dans un problème sans avoir bien com-
15
pris les objectifs de l’entreprise. Aussi,la phase du déploiement, aborde également

des considérations importantes pour la clôture du projet et la transition vers la
maintenance et l’exploitation.
Une mise en œuvre souple de CRISP-DM peut être flexible afin de fournir un
grand nombre des avantages des principes et pratiques agiles. En acceptant qu’un
projet démarre avec des inconnues importantes, l’utilisateur peut passer d’une
étape à l’autre, en acquérant à chaque fois une compréhension plus approfondie
des données et du problème. Les connaissances acquises lors des cycles précédents
peuvent alors alimenter les cycles suivants.
1.4 Plannification du projet
Le diagramme de Gantt (figure 1.6) présente le déroulement de notre

travail le long de notre projet.
Figure 1.6 – Diagramme de Gantt.
Conclusion
Tout au long de ce chapitre, on a mis en place le projet dans son cadre

général. Le cadre professionel en premier lieu où on a présenté l’organisme d’ac-
cueil INIR, suivi par l’exposition de la problématique. De mème, on a mis l’accent
sur les exigences qui doivent être satisfaits à travers notre solution et la méthodo-
16
logie de travail adopté. Dans le chapitre qui suit, nous allons exposer les concepts
clés abordé durant le projet ainsi qu’une exploration sur l’état de l’art.
17
CHAPITRE 2
Etat de l’art
Sommaire
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1 Notions théoriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.1 Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.2 L’apprentissage Automatique . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.3 Le Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 Compréhension du logique métier . . . . . . . . . . . . . . . . . . . 28
2.2.1 Les assurances médicales . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.2 Le système médicale aux états-unis . . . . . . . . . . . . . . . . . . . . 29
2.3 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.1 La plateforme Solon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.2 SAS Healthcare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.3 Système de prevention des fraudes . . . . . . . . . . . . . . . . . . . . 32
2.3.4 OSP Healthcare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.5 La critique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
18
CHAPITRE 2 Etat de l’art
Introduction
Dans ce chapitre, nous allons présenter en premier lieu les notions théo-
riques du Big Data tout en expliquant les bases et les principes qui lui sont rat-
tachées, suivi par une étude du processus métier et les solutions existantes déjà
dans le marché.
2.1 Notions théoriques
2.1.1 Big Data
— Concept :
Le terme "big data" [6] désigne des données si volumineuses, rapides ou com-
plexes qu’il est difficile, voire impossible, de les traiter à l’aide des méthodes
traditionnelles. Le fait d’accéder à de grandes quantités d’informations et de
les stocker à des fins d’analyse ne date pas d’hier. Mais le concept de "big
data" a pris de l’ampleur au début des années 2000, lorsque Doug Laney,
analyste industriel, a formulé la définition désormais courante du "big data"
sous la forme des trois "V" :
1. Volume : Les organisations collectent des données provenant de di-

verses sources, notamment des transactions commerciales, des appareils
intelligents (IoT), des équipements industriels, des vidéos, des réseaux
sociaux, etc. Auparavant, le stockage de ces données aurait été un pro-
blème - mais le stockage moins cher sur des plateformes comme les lacs
de données et Hadoop a permis de faciliter la tâche.
2. La vélocité : Avec la croissance de l’Internet des objets, les données
19
parviennent aux entreprises à une vitesse sans précédent et doivent être

traitées en temps voulu. Les tags RFID, les capteurs et les compteurs
intelligents sont à l’origine de la nécessité de traiter ces flux de données
en temps quasi réel.
3. Variété : Les données se présentent sous toutes sortes de formats -

que ce soit des données structurées et numériques dans des bases de
données traditionnelles ou des documents textuels non structurés, des
courriels, des vidéos, des audios, des données de téléscripteur boursier et
des transactions financières.
— Processus d’un projet Big Data Avant de mettre le big data à leur
service, les entreprises doivent examiner comment le flux des données cir-
cule entre les lieux, les sources ou les systèmes. Pour prendre le contrôle
de ce "tissu de données" massif, qui contient à la fois des données struc-
turées et non structurées, il y a cinq procédures essentielles à suivre.
1. Définir une stratégie big data :

À un haut niveau, une stratégie big data est un plan conçu pour
aider à superviser et à améliorer la façon dont on acquiert, stocke,
gére, partage et utilise les données au sein et en dehors de l’organisa-
tion. Une stratégie big data fixe le cadre de la réussite de l’entreprise
dans un contexte où les données sont abondantes. Lors de l’élabora-
tion d’une stratégie, il est important de tenir compte des objectifs
commerciales et technologiques existants et à venir.
2. Identifier les sources de Big Data :
• Des données en streaming : peuvent provenir de l’Internet

des objets (IoT) et d’autres appareils connectés, des voitures in-
telligentes, des appareils médicaux, des équipements industriels
20
et plus encore, ou des données streaming provenantes des diffé-

rentes sources. On peut analyser ces big data à mesure qu’elles
arrivent, en décidant des données à conserver ou non, et de celles
qui nécessitent une analyse plus approfondie.
• Réseau sociaux : Les interactions sur Facebook, YouTube, Ins-

tagram et d’autres plateformes de médias sociaux fournissent des
données. Il s’agit notamment de volumes massifs de big data sous
forme de photos, de vidéos, de paroles, de textes et de sons - qui
peuvent tous être utiles pour le marketing, les ventes et le service
client. Parce que ce contenu est fréquemment dans des formats
non structurés ou semi-structurés, il présente des difficultés dis-
tinctes de consommation et d’analyse.
• Les données publiquement disponibles : proviennent de

quantités massives de sources de données ouvertes comme
data.gov du gouvernement américain, ou le portail de données
ouvertes de l’Union européenne.
• Autres sources : D’autres big data peuvent provenir de lacs de

données, de sources de données en nuage, de fournisseurs et de
clients.
3. Accès, gestion et stockage des données volumineuses :

Les systèmes informatiques modernes offrent la vitesse, la puissance
et la flexibilité nécessaires pour accéder rapidement à des quanti-
tés massives et à des différents types de données volumineuses. En
plus d’un accès fiable, les entreprises ont également besoin de mé-
thodes pour intégrer les données, garantir leur qualité, assurer leur
gouvernance et leur stockage, et préparer les données pour l’analyse.
Certaines données peuvent être stockées dans un entrepôt de don-
21
nées traditionnel, mais il existe également des options flexibles et peu

coûteuses pour le stockage et la gestion des big data via des solutions
en nuage, des lacs de données et Hadoop.
4. Analyse des Big Data :

Les organisations peuvent exploiter l’ensemble de leurs big data à
des fins analytiques en utilisant des technologies à haute performance
comme le grid computing ou l’analyse en mémoire. Une autre tech-
nique consiste à décider à l’avance si les données sont pertinentes,
puis de les analyser. Quoi qu’il en soit, l’analyse des big data permet
aux entreprises d’extraire de la valeur et des informations à partir des
données. Les big data sont de plus en plus utilisées pour alimenter
les projets d’analyse sophistiqués d’aujourd’hui, comme l’IA.
— Les architectures des systèmes Big Data :
Pour réaliser des analyses, il faut préalablement être capable de récupé-

rer des données et d’ingérer un flux massif de milliers de messages par
seconde afin de créer un ensemble de données manipulable.
1. L’architecture Lambda : Nathan Marz a défini l’architecture

Lambda [7] comme un modèle d’architecture logicielle (Marz, 2011).
Cette conception permet de traiter de grandes quantités de données
en temps réel et par lots en même temps.
22
Figure 2.1 – L’architecture Lambda [7]
L’architecture, illustré ci-dessus, se compose de trois couches (ou

Layers) :
- La Batch Layer : Cette couche est responsable de réaliser des
calculs, des transformations de modèles sur les données stockées.
Ainsi que stocker les nouvelles données entrantes dans leurs for-
mat brute dans un entrepôt indépendant et permanent de don-
nées brutes dans la master dataset. Puis, tout calcul et traitement
sera mené à partir de cet entrepôt, souvent de manière distribuée,
pour garder l’aspect du passage à l’échelle et l’éfficacité.
- La Speed Layer : Elle opère sur le niveau du flux entrant

en temps réel. En faisant appel à des algorithmes ou un modèle
d’appprentissage automatique, cette couche traite tout nouvelle
information reçue, extrait les connaissances désirées, et les sert à
l’utilisateur.
- La Serving Layer : A ce niveau, on récupère les résultats

des couches susmentionnées et on les met à la disposition des
utilisateurs.
2. L’architecture Kappa : L’architecture Kappa [8] est un modèle qui
diffère de l’architecture Lambda au niveau l’approche qu’il adopte.
23
Elle peut être considérée comme une simplification de cette dernière

car elle suppose que tous les traitements fonctionnent sur des flux
(everything is a stream). On suppose au niveau de ce type de patron,
que la couche Batch peut être
3. Comparaison des architectures Lambda et Kappa Pour un

comparatif généralisé, l’architecture Lambda présente les avantages
suivants : des données brutes pouvant être retraitées si nécessaire, une
solution flexible et indépendante des technologies, et une adaptation
optimale des techniques d’analyse aux besoins du client. Cependant,
il s’agit d’une architecture qui présente de difficultés à être mise en
place par rapport à l’achitecture Kappa.
La simplicité et la quasi-indépendance par rapport à la technologie
sont les points forts de l’architecture Kappa. Cependant, en termes
d’organisation des données, l’architecture Kappa est moins évoluée
que l’architecture Lambda.
2.1.2 L’apprentissage Automatique
L’apprentissage automatique [9], est une forme d’intelligence artificielle

qui permet à un système d’apprendre à partir des données et non à l’aide d’une
programmation explicite. Au fur et à mesure que les algorithmes ingèrent les
données de formation, il devient possible de créer des modèles plus précis basés
sur ces données. Un modèle de machine learning est le résultat généré lorsque
vous entraînez votre algorithme d’apprentissage automatique avec des données.
Après la formation, lorsque vous fournissez des données en entrée à un modèle,
vous recevez un résultat en sortie.[IBM]
1. Apprentissage supervisé : Le système apprend à partir de données éti-
24
quetées sous supervision. Ce sont généralement les humains qui étiquettent

les données.
2. Apprentissage non supervisé : On parle d’apprentissage non supervisé

lorsqu’une machine apprend à partir de données qui n’ont pas été catégori-
sées. En d’autres termes, il n’y a pas de réponse "correcte" à apprendre pour
la machine ; au lieu de cela, la machine doit essayer de découvrir des modèles
dans les données pour trouver une réponse.
3. Apprentissage par Renforcement : L’apprentissage par renforcement

consiste à ce qu’une machine apprenne en étant récompensée.
2.1.3 Le Cloud Computing
— Définition :
Le cloud computing est la fourniture de services informatiques (notamment
des serveurs, du stockage, des bases de données, la gestion réseau, des lo-
giciels, des outils d’analyse, l’intelligence artificielle) via Internet (le cloud)
dans le but d’offrir une innovation plus rapide, des ressources flexibles et des
économies d’échelle. En règle générale, vous payez uniquement les services
cloud que vous utilisez (réduisant ainsi vos coûts d’exploitation), gérez votre
infrastructure plus efficacement et adaptez l’échelle des services en fonction
des besoins de votre entreprise". [10]
— Modèles de services du Cloud Computing : Le cloud computing offre

trois principaux modèles de services, qui sont :
• Infrastructure as a Service (IaaS) : Fournit aux entreprises l’infra-

structure nécessaire à l’exécution de leurs applications, des serveurs aux
réseaux et au stockage, sans avoir à acheter du matériel ou des environ-
nements physiques pour les exploiter.
25
• Platform as a Service (PaaS) : Offre aux développeurs des outils

et des environnements complets pour développer et déployer des appli-
cations dans le nuage. Comme IaaS, PaaS fournit l’infrastructure, mais
aussi des logiciels intermédiaires, des systèmes de gestion de base de
données, etc.
• Software as a Service (SaaS) : Fournit aux utilisateurs des applica-

tions en tant que service d’un fournisseur à la demande. Les applications
SaaS n’ont pas besoin d’être installées plutôt déployées chez le fournis-
seur de nuages et consommées même par les navigateurs Web.
La figure 2.2 ci-dessous illustre la séparation entre les responsabilités de l’uti-

lisateur et celles d’un fournisseur de services en nuage pour chacune des mo-
dalités de service.
Figure 2.2 – IT traditionnel vs. IaaS vs. PaaS vs. SaaS [10]
— Architecture Serverless :
Les architectures Serverless [11] redéfinissent la manière dont on construit
les applications basées sur le cloud et orientées sur les événements. Ce
paradigme informatique, également connu sous le nom de Functions as
a Service (FaaS), permet de de développer des applications reposant
uniquement sur une combinaison de services tiers, de logique côté client et
26
d’appels de procédures à distance hébergés dans le cloud, ce qui revient

à dire qu’il n’y a pas d’autre solution. logiques côté client et d’appels de
procédures à distance hébergés dans le nuage, ce qui élimine le besoin d’un
serveur backend de façon classique, comme l’illustre la figure 2.3 ci-dessous.
Figure 2.3 – Application Traditionnelle vs. Application Serverless [11]
Functions as a Service possède les principales propriétés suivantes :
1. Fonctions logiques indépendantes, côté serveur : Les FaaS sont

de petits blocs de code séparés qui traitent les entrées et les paramètres
et renvoient le résultat.
2. Stateless : Deux invocations de la même fonction peuvent potentielle-

ment s’exécuter sur des serveurs complètement différents.
3. Éphémère : Les FaaS démarrent rapidement, exécutent leur code puis

s’éteignent à nouveau. Les entreprises ne sont facturées qu’à la millise-
conde d’exécution.
27
4. Déclenché par des événements : Les FaaS sont généralement dé-

clenchés par des événements provenant d’autres services en nuage.
5. Évolutif : Les FaaS permettent d’exécuter autant de fonctions que né-

cessaires pour répondre en permanence à toutes les demandes entrantes.
Les développeurs peuvent ainsi consacrer leur temps à la réalisation des
objectifs métier de leurs applications, au lieu de mettre en œuvre, main-
tenir, débugger et surveiller l’infrastructure correspondante.
— Microsoft Azure : Microsoft Azure [10], est la plateforme de cloud com-

puting public de Microsoft. Elle fournit une gamme de services en cloud,
notamment des services de calcul, d’analyse, de stockage et de mise en ré-
seau. Les utilisateurs peuvent choisir parmi ces services pour développer et
mettre à l’échelle de nouvelles applications, ou exécuter des applications exis-
tantes sur le cloud public. Ainsi, ils ne paient que ce qu’ils ont besoin et ne
mettent à leur disposition que le type et la taille des ressources informatiques
nécessaires.
2.2 Compréhension du logique métier
2.2.1 Les assurances médicales
L’assurance maladie est un type d’assurance qui couvre les dépenses

de santé et les frais médicaux. L’assurance maladie couvre les coûts des soins
courants, des soins d’urgence et du traitement des maladies chroniques. Les com-
pagnies d’assurance maladie demandent à leurs clients une prime mensuelle pour
la couverture, et en échange, la compagnie accepte de payer la totalité ou la plu-
part des frais médicaux de la personne. Même dans le cadre des plans les plus
généreux, les assurés doivent payer diverses dépenses pour les soins médicaux.
28
Ces dépenses comprennent principalement les paiements directs et les marges, qui
sont des coûts initiaux payés par l’assuré aux professionnels de la santé avant qu’il
ne reçoive des services.
Comme notre cas d’étude tout au long de ce projet, on a choisi de travailler avec
les données fournies par les assurances médicales américaines.
2.2.2 Le système médicale aux états-unis
Le système de santé américain n’est pas un système accessible à tout

le monde.En fait, il s’agit d’un mélange de systèmes et de programmes distincts,
financés par des fonds soient publics ou privés. Les Américains qui veulent être
assurés, doivent avoir une couverture par des assurances maladie publiques ou
privées, la majorité d’entre eux étant couverts par des assurances privées par le
biais de leur employeur. Les programmes financés par le gouvernement, tels que
Medicaid et Medicare, sont menées à travers le Center for Medicare & Medicaid
Services [12]. C’est une agence fédérale responsable de la gestion de l’assurance
médicale gouvernementale. Cette agence fournit une couverture de soins de santé
à certains groupes de la communauté américaine qui remplissent les conditions
requises. Le premier programme est appelée Medicare où l’état apporte un soutien
financier aux personnes agées dépassant 65 ans comme âge. Le deuxième appelée
Medicaid, consacré aux citoyens les plus pauvres.
2.3 Etude de l’existant
On consacre cette partie pour l’étude et la critique des solutions de dé-

téction des fraudes dans les assurances médicales qui existent déjà dans le marché
dans le but d’exposer les contraintes que notre solution doit respecter.
29
2.3.1 La plateforme Solon
Face aux menaces des fraudes et abus dont les prestataires de service de
santé dans le marché frainçais rencontrent, IBM, Almerys et Pro BTP ont signé
un partenariat en 2018 pour implémenter une solution qui détecte et prévoit ces
fraudes . Cette solution, nommé Solon [13], est un service d’analyse prédictive
déployé en mode Cloud et qui possède 2 aspects : le premier déterministe avec une
configuration de règles métiers bien définies et le profilage, et un autre statistique
qui analyse les comportements qui s’écartent de la norme. Solon s’appuie sur deux
composants :
- IBM Counter Fraud Management (CFM), une solution industrielle de pré-

vention et d’interception des paiement frauduleux.
- IBM Fraud and Abuse Management system (FAMS), ressource comprenant

10 000 indicateurs métier.
Les Avantages :
• Analyses détaillées des demandes
• Déployé sur le Cloud
• Prend en considération toutes les régles métier définies
Les Inconvénients :
• Domaines limités à l’optique et le dentaire
2.3.2 SAS Healthcare
Le module d’analyse des fraudes de la solution SAS [14] utilise de

multiples techniques, mettant en jeu les règles métier appliquées, analyse des
30
valeurs aberrantes, modélisation prédictive et fouille de données pour découvrir

la probabilité de fraudes, d’abus et d’autres paiements abusifs qui causent des
pertes et compromettent l’intégrité des remboursements.
Les alertes classées par ordre de priorité sont ensuite transmises aux aux
investigateurs, et aux autres unités opérationnelles, où les analystes peuvent
enquêter ces alertes.
Figure 2.4 – L’interface de la solution SAS Detection and Investigation for Health Care [14]
Les Avantages :
• Facile à mettre en oeuvre
• Dashboard de surveillance des évènements ergonomique
• Statistiques d’activités
• La définition des règles métier est limité
• Faible performance selon les réclamantions de ses utilisateurs
31
2.3.3 Système de prevention des fraudes
En 2011, le Center for Medicare and Medicaid Services a mis en place

le Fraud Prevention System [15], un système conçu pour analyser les données
des demandes de remboursement de Medicare afin de prédire les comportements
potentiellement frauduleux et de communiquer les résultats aux analystes, qui
peuvent utiliser ces informations pour prioriser les enquêtes.
Les Avantages :
• Un système conçu sur mesure.
• Règles métier bien définis par la CMS.
• S’éxecutent sur un lot massive de demandes.
• Solution obsolète : dernier renouvellement en 2017.
• Pas d’execution temps réel.
2.3.4 OSP Healthcare
OSP Healthcare [16] est une solution crée par OSP Labs pour la dé-
tection des fraudes dans le domaine de santé. Elle s’agit d’un système basé sur
l’apprentissage automatique non supervisé avec une approche automatisé dans
l’identification des valeurs aberrantes. Elle est basé sur la vérification des iden-
tités des personnes, l’analyse prédictive des données et les règles métier définies
par l’utilisateur. OSP Healthcare est crée sur mesure des besoins de l’assurance
en construisant leur modèle sur les données du client. La solution fournit de plus
un tableau de bord pour les résultats des analytiques.
32
Figure 2.5 – Le processus de fonctionnement de la solution de OSP [16]
Les Avantages :
• La solution est conçue sur mesure du client.
• Couvre une panoplie de domaines sanitaires.
• Haute performance et précision de détection de fraudes.
• Solution coûteuse.
• Pas d’execution temps réel.
2.3.5 La critique
Après avoir fourni un descriptif de quelques solutions existantes sur le

marché de détection de fraude en citant les avantages et les inconvénients de
chacune, on peut se baser sur cette critique pour répondre à certaines exigences
à travers notre solution, pour la distinguer sur ce marché.
En premier lieu, on constate que la majorité de ces solutions ne s’éxecutent pas en
temps réel. De plus, il faut garantir une solution qui est mis à jour régulièrment
pour garantir une meilleur performance. En outre, certaines des solutions sont
33
accompagnées des problèmes de mis en oeuvre.
Conclusion
Dans ce chapitre, nous avons fourni les notions théoriques et les concepts
clés que nous avons abordé à travers notre travail ainsi qu’un aperçu de l’archite-
cure adopté que nous allons spécifier par la suite. De plus, une compréhension de
la logique métier et de l’écosystème de notre projet a été éxposé pour finir avec
une étude des solutions existantes déja dans le marché de détection des fraudes
médicales qui nous a permis d’identifier les problèmes et les lacunes que nous
devons éviter ou y remedier lors de notre travail. Ainsi, dans le chapitre qui suit,
nous allons présenter les différentes aspects de la solution que nous proposons.
34
CHAPITRE 3
Etude et traitement des données
Sommaire
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1 Notions théoriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.1 Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.2 L’apprentissage Automatique . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.3 Le Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 Compréhension du logique métier . . . . . . . . . . . . . . . . . . . 28
2.2.1 Les assurances médicales . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.2 Le système médicale aux états-unis . . . . . . . . . . . . . . . . . . . . 29
2.3 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.1 La plateforme Solon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.2 SAS Healthcare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.3 Système de prevention des fraudes . . . . . . . . . . . . . . . . . . . . 32
2.3.4 OSP Healthcare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.5 La critique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
35
CHAPITRE 3 Etude et traitement des données
Introduction
La réussite de tout projet dépend de la qualité de son départ. Une fois le

métier a été exposé, nous entamons la phase de l’étude des données. Nous allons
commencer par les comprendre à travers les descriptions fournies, suivi par une
exploration et la préparation de ces données pour les fournir à notre modèle en
entrée. Cette phase est critique pour tout projet d’apprentissage automatique vu
que le succés des prédictions dépend du succès de nettoyage des données. Nous
avons ajouté en annexe une description fourni par le CMS [12] des attributs des
jeux de données mis en jeu.
3.1 Compréhension des données
Comme indiqué dans la présentation de la méthodologie CRISP-DM, la

phase de compréhension des données comprend la collecte et l’exploration des
données. Cette phase concerne l’identification de notre sources de données ainsi
que le processus de choix et sélection des données. Le CMS fournit chaque année
un jeu de données concernant chaque aspect de services de remboursement versés
à travers les programmes d’assurance médicales dans le but d’améliorer la qualité
des programmes de soins de santé et d’assurance médicale pour que les patients
reçoivent des soins médicaux de qualité d’où minimiser les pertes dans les fraudes.
Ces données sont mis à disposition publique pour des buts d’étude statistique, re-
cherche et investigation des différentes parties indépendantes. Les programmes
fournis par l’agence sont Medicare et Medicaid. Tout au long de ce travail, on
s’intérresse par le premier. En intégrant les trois volets du programme Medicare
pour la détection des fraudes, cette étude offre une vision globale de la fraude
36
dans le programme Medicare. Les informations fournies dans ces données com-
prennent le montant moyen payé pour ces services et d’autres de données liés aux
procédures effectuées, aux médicaments administrés. Ces jeux de données sont de
larges tailles d’où la difficulté de leurs manipulation ainsi le cadre Volume du
Big Data.
3.1.1 Les services et les paiements des fournisseurs de textbfMedi-

care : Médecins et autres fournisseurs (partie B)
Ce jeu de données fournit des informations sur les services et procédures

fournis aux bénéficiaires de Medicare par des médecins et autres professionnels
de santé. Il contient des informations sur la consommation, le paiement (mon-
tant autorisé et paiement Medicare) et les frais facturés, organisés par identifiant
national du fournisseur (NPI), code HCPCS ( système de codage des procédures
communes de santé) et lieu de service et basée sur des informations provenant
des données de réclamations administratives de la CMS pour les bénéficiaires de
Medicare inscrits dans le programme de paiement. Les données couvrent l’année
2018 et contiennent les médecins/fournisseurs ayant fait l’objet d’une décision fi-
nale pour les membres de Medicare rémunérée.
Bien que l’ensemble des données contient une multitude d’informations sur le
paiement et l’utilisation des services de la partie B de Medicare, Il présente un
certain nombre de limites. Il est important de noter que les données peuvent ne
pas être représentatives de l’ensemble de la pratique d’un médecin car elles ne
comprennent que des informations sur les bénéficiaires de Medicare payés. En
outre, les données ne sont pas destinées à indiquer la qualité des soins fournis et
ne sont pas ajustées au risque pour tenir compte des différences dans des maladies
des patients.
37
Figure 3.1 – Distribution des paiements versées par domaine de spécialité
Après avoir chargé le jeu de données, on procède à la visualisation de

certaines attributs pour avoir un aperçu sur le comportement des fournisseurs
de services. Illustré dans la Figure 3.1, on constate que les spécialité les plus
demandées sont la médecine interne, la médecine de famille et la neurolgie. Ce
comportement sera mis en jeu dans la prédiciton des fraudes.
3.1.2 L’utilisation et le paiement des fournisseurs de Medicare : Pres-

cripteur (Partie D)
Dans un effort pour rendre leur système de soins de santé plus transpa-
rent, les CMS ont préparé un ensemble de données publiques, la partie D, conte-
nant des informations sur les prescriptions liés aux médicaments sur ordonnance
38
subis par les patients de Medicare. La partie D est organisée par identifiant natio-
nal de fournisseur (NPI) et par nom de médicament et contient des informations
sur l’utilisation des médicaments (nombre de demandes et nombre de jours d’ap-
provisionnement) et le coût total des médicaments. Les données couvrent l’année
2018.
Figure 3.2 – La distribution des 10 médicaments les plus demandés
L’axe d’analyse de ce jeu de données est principalement les médicaments demandés

et leurs principales association dans les fraudes. Ainsi, une première exploration
nous a permis d’exposer les 10 médicaments les plus demandés et remboursés, la
Figure 3.2 les illustre. Intuitivement, les médicaments susmentionnés auront une
présence importante dans les transactions frauduleuses d’où ils auront des poids
plus élevée. On va étudier cet aspect dans la suite du travail.
39
3.1.3 Liste des individus et entités exclues : LEIE
Afin d’aboutir à implémenter un modèle de détection de fraudes avec

l’apprentissage automatique supervisé, on a besoin de labeliser notre jeu de don-
nées finale. Les 2 ensembles de données susmentionnés ne fournissent que les
informations relatives à la transaction sans l’étiquette de fraude.
Nous utilisons donc la liste des individus et entités exclus (LEIE), qui contient
les informations suivantes : motif d’exclusion, date d’exclusion et date de réinté-
gration/renonciation pour tous les médecins exclus de la pratique aux États-Unis
pendant une période donnée. Cet ensemble de données a été créé et est mis à jour
mensuellement par l’Office of Inspector General (OIG), une entité de la ministère
de santé américaine responsable de l’exclusion des entités et individus suspects de
mener des fraudes dans les programmes d’assurances gouvernementale. Comme
premier aperçu, la Figure 3.3 ci-dessous met en exposition le nombre des fraudes
par état.
Figure 3.3 – Nombre de fraudes par état
40
3.2 Préparation des données
On est encore dans la phase d’éxploration des données selon la métho-

dologie CRISP-DM. Ainsi, après avoir identifié nos sources de données obtenues,
on doit les nettoyer et faire les taitements nécessaires dans le but d’aboutir à un
ensemble de données qu’on peut le fournir comme input pour le modèle d’appren-
tissage automatique supervisé.
3.2.1 Séléction des caractéristiques
Pour cette étude, nous nous intéressons uniquement à des attributs par-
ticuliers de chaque ensemble de données afin de fournir une base solide pour nos
expériences et analyses. Les attributs exclus ne fournissent pas d’informations
spécifiques sur les demandes de remboursement, les médicaments administrés ou
les références, mais englobent plutôt des informations liées au fournisseur. De
plus, la réduction des attributs représente une étape importante dans le cas de
la manipulation des Big Data. Elle réduit le temps d’éxecution et les ressources
utilisées lorsqu’on n’importe que les données avec les attributs dont on a besoin.
3.2.2 Nettoyage des données
La phase du nettoyage des données est primordiale dans l’ananlyse des

données. Elle tente d’identifier et d’imputer les valeurs manquantes et de stabiliser
les données en éliminant les valeurs aberrantes. Elle améliore donc la cohérence
et la fiabilité des données.
— Les valeurs manquantes :
41
La présence de valeurs manquantes dans un ensemble de données peut avoir

un impact particulier sur les déductions et les connaissances qui peuvent être
extraites des données.
Par conséquent, on fait recours à différentes méthodes d’imputation pour la
remidiation de ce problème.
1. Imputation par la moyenne : La méthode d’imputation à la moyenne

consiste à remplacer les valeurs manquantes par la moyenne des valeurs
non manquantes dans une variable ou un vecteur.
2. Imputation par la médiane : Le principe de la méthode d’imputation

médiane est de remplacer les valeurs manquantes dans une caractéris-
tique par la valeur de la médiane des observations non manquantes dans
cette caractéristique
3. Imputation par la valeur la plus fréquente : L’imputation par la

valeur la plus fréquente est une méthode dans laquelle les valeurs man-
quantes sont remplacées par les valeurs les plus fréquentes dans chaque
colonne d’un ensemble de données.
3.2.3 Construction de l’ensemble de données
Comme on a déjà mentionné, le but de ce rassemblement des 3 jeux de

données est de créer un seul dont une de ses colonnes représentera la cible pour
l’algorithme de l’apprentissage automatique. Cette colonne indiquera si la tran-
saction est frauduleuse ou pas.Ce rassemblement est en fait une jointure sur les
colonnes NPI et Type du Fournisseur.
En combinant ces ensembles de données, nous sommes limités aux médecins qui
ont participé aux trois parties de Medicare. Malgré cela, cet ensemble de données
combiné possède une base d’attributs plus large et plus englobante pour l’appli-
42
cation d’algorithmes d’exploration de données afin de détecter les comportements

frauduleux, comme le démontre notre étude.
Dans une deuxième phase, et pour ajouter encore plus des comportements sus-
pectes pour que le système apprenne mieux, on a généré une liste des médicaments
qui étaient présents dans les transactions frauduleuses, les donner des poids selon
leurs occurences, extraire les plus récurrentes dans les fraudes et revenir à l’en-
semble de données qui résultant de la jointure pour annoter les lignes dont ces
médicaments sont présentes. Cette procédure a été fait pour remedier le problème
du désequilibre des données étiquetées, vu qu’on est présent dans un contexte de
détection de fraudes. La Figure 3.4 illustre cette procédure de construction :
Figure 3.4 – Illustration de la procédure de construction du jeu de données
3.2.4 Préparation du module temps réel
Les demandes de remboursement arrivent avec une format basique qui

ne contient que les informations basiques fournies par les agences de l’assurance.
Alors, pour que le système d’apprentissage automatique soit capable de les traiter,
En effet, lors de ses arrivées dans leur format brûte, les demandes sont regroupées,
43
aggrégés puis on extrait les médicaments demandés pour finalement aboutir aux
schéma de données dont le modèle accepte.
3.3 Modélisation
Dans cette partie de la méthodologie CRISP-DM, on va fournir un aperçu

sur le fonctionnement des différents algorithmes d’apprentissage automatique su-
pervisé abordé dans ce travail, ainsi qu’une présentation des métriques d’évalua-
tion des performances de ces algorithmes. Pour passer à présenter le processus de
la re-apprentissage du modèle qu’on a conçu.
3.3.1 Les algorithmes d’apprentissage automatique
— Logistic Regression : En statistique, le modèle logistique [17] est utilisé

pour simuler la probabilité de réalisation d’une certaine classe ou d’un certain
événement. Bien qu’il existe de nombreuses extensions plus complexes, la ré-
gression logistique qui est un algorithme d’apprentissage supervisé recourt
à une fonction logistique pour modéliser une variable binaire dépendante. Il
existe plusieurs types de régressions logistiques, comme la régression logis-
tique binaire, qui est jusqu’à présent le type le plus simple et le plus utilisé,
la régression logistique multinomiale qui inclut trois catégories ou plus mais
n’utilise pas la fonction d’ordonnancement, et enfin la régression logistique
ordinale qui est la même que la régression logistique mutinomiale mais utilise
la fonction d’ordonnancement.
— GaussianNB : Les méthodes de Bayes naïves [18] sont un type d’algorithme

d’apprentissage supervisé fondé sur l’application du théorème de Bayes avec
l’hypothèse "naïve" qui fait référence à l’indépendance conditionnelle entre
44
chaque couple de caractéristiques étant donné la valeur de la variable de

classe. Cet algorithme est basé sur le théorème de Bayes pour la probabilité
conditionnelle traduit par la formule ci-dessous :
P (B|A)∗P (A)
P (A, B) = P (B) Avec :
- P(A,B) : Probabilité de l’événement A et B
- P(A|B) : Probabilité de l’évènement A sachant su’on a l’évènement B
- P(A) : Probabilité de l’évènement A
- P(B) : Probabilité de l’évènement B
Les algorithmes d’apprentissage et les classificateurs Naive Bayes peuvent

être extrêmement rapides par rapport à des méthodes plus sophistiquées. Le
dissociation des distributions de caractéristiques conditionnelles de classe fait
en sorte que chaque distribution peut être estimée indépendamment comme
une distribution unidimensionnelle, ce qui permet de pallier les problèmes
liés à la malédiction de la dimensionnalité.
— Random Forest Classifier : Random Forest Classifier [19] est un esti-

mateur qui compare un certain nombre d’arbres de décision sur différents
sous-échantillons de données et utilise la moyenne pour optimiser la préci-
sion de la prédiction et contrôler le phénomène de l’overfitting. Le nombre
optimal d’arbres est un paramètre très important. Ce nombre peut aller jus-
qu’à plusieurs centaines ou plus tout en étant très variable et dépendant du
problème. Plus précisément, chaque arbre de la forêt aléatoire est appris sur
un sous-ensemble aléatoire de données selon le principe du bagging, avec un
sous-ensemble aléatoire de caractéristiques (features) selon le principe des
" random projections ". Les prédictions sont moyennées lorsque les données
sont de nature quantitative ou utilisées pour un vote dans le cadre de données
qualitatives, dans le cas des arbres de classification.
45
— XGBoost : XGBoost [20] est une librairie décentralisée optimisée de "gra-

dient boosting" conçue pour être hautement efficace, flexible et portable.
Elle déploie des algorithmes d’apprentissage automatique dans le cadre du
Gradient Boosting. Cet algorithme fournit un boosting d’arbre parallèle qui
résout de plus en plus de problèmes de science des données de manière ra-
pide et précise. Le même code fonctionne sur les principaux environnements
distribués (Kubernetes, Hadoop, SGE, MPI, Dask) et peut répondre à des
problèmes Des problèmes très sophistiqués. Concrètement, XGBoost traite
les données en différents blocs compressés, ce qui rend le tri et le traitement
parallèle encore plus rapides.
Les particularités de XGBoost ne sont pas seulement liées à l’implémentation

de l’algorithme, et donc à ses performances, mais aussi aux différents para-
mètres qu’il propose. En effet, XGBoost offre un large spectre d’hyperpara-
mètres, il est ainsi possible d’avoir un véritable contrôle sur l’implémentation
du Gradient Boosting grâce à cette diversité de paramètres. Il est notamment
possible d’ajouter différentes régularisations dans la fonction de perte, limi-
tant ainsi un phénomène assez répandu lors de l’utilisation des algorithmes
de Gradient Boosting : l’overfitting.
— Extra Trees Classifier : Extra Trees Classifier [21] est un type de tech-
nique d’apprentissage ensembliste qui agrège les résultats de plusieurs arbres
de décision décorrélés rassemblés dans une "forêt" pour produire son propre
résultat de classification. Dans son approche, il est très similaire à un clas-
sificateur Random Forest et ne diffère de celui-ci que par la méthode de
construction des arbres de décision dans la forêt. Chaque arbre de décision
de la Extra Trees forest est construit à partir de l’échantillon de formation
original. Ensuite, à chaque nœud de test, chaque arbre est muni d’un échan-
tillon aléatoire de k caractères de l’ensemble de critères à partir duquel chaque
46
arbre de décision doit choisir le meilleur caractère pour diviser les données
en fonction de certains paramètres mathématiques (généralement l’indice de
Gini). Cet échantillon aléatoire de caractéristiques conduit à la création de
nombreux arbres de décision décorrélés.
— Gradient Boosting Classifier : Le Gradient Boosting [22] est une tech-

nique d’apprentissage automatique utilisée pour plusieurs tâches tels que
la régression et la classification, qui produit un modèle de prédiction sous la
forme d’un groupe de modèles de prédiction fragiles, généralement des arbres
de décision. Lorsqu’un arbre de décision est l’apprenant fragile, l’algorithme
obtenu est appelé arbre boosté par le gradient, qui surclasse généralement
l’algorithme Random Forest. Cette méthode établit le modèle par étapes,
comme le font les autres techniques de boosting, et elle les étend en per-
mettant l’optimisation d’une fonction de perte différentiable. Il existe des
méthodes utilisées pour améliorer le boosting de gradient de base, telles que
Tree Constraints, Rétrécissement, Echantillonnage aléatoire et l’apprentis-
sage pénalisé.
— Support Vector Machine : Support vector machine (SVM) [23] sont un

ensemble de techniques d’apprentissage supervisé destinées à la résolution de
problèmes de classification et de régression. cette technique est une généra-
lisation des classificateurs linéaires et a été développée dans les années 1990
à partir des études théoriques de Vladimir Vapnik sur le développement de
la théorie statistique de l’apprentissage : la théorie de Vapnik-Chervonenkis.
Concretement, une machine à vecteurs de support construit un hyperplan
ou un ensemble d’hyperplans dans un espace à haute ou meme à une infi-
nité de dimensions, qui peut être utilisé pour la classification, la régression,
ou d’autres tâches telles que la détection des aberrations. Intuitivement, une
bonne séparation est obtenue par l’hyperplan qui a la plus grande distance au
47
point de données d’entraînement le plus proche de n’importe quelle classe et

ça ce qu’on appelle la marge fonctionnelle, puisqu’en général, plus la marge
est importante, plus l’erreur de généralisation du classifieur est faible. Pour
que la charge de calcul reste raisonnable, les mappings utilisés par les mo-
dèles SVM sont conçus pour garantir que les produits scalaires de paires de
vecteurs de données d’entrée puissent être calculés simplement en termes de
variables dans l’espace d’origine, en les définissant en utilisant une fonction
noyau choisie en adéquation avec le problème.
3.3.2 Métriques d’évaluation
Le choix des métriques d’évaluation est de grande importance dans notre

cas. L’évaluation des résultats sur des données fortement déséquilibrées nécessite
plus de critères que seulement l’exactitude. Dans cette partie, on va présenter les
différentes métriques qu’on a suivi.
— Recall score : Le rappel [24] est le rapport entre les observations positives
correctement prédites et l’ensemble des observations de la classe réelle.
— Accuracy : L’exactitude [25] est une métrique utilisée pour le calcul de

la fréquence à laquelle les prédictions correspondent aux labels. En fait, elle
crée deux variables locales, total et count, qui sont utilisées pour calculer la
fréquence à laquelle y_pred correspond à y_true. Cette fréquence est finale-
ment retournée sous forme de précision binaire : une opération idempotente
qui divise simplement total par count. La mesure de l’exactitude est géné-
ralement utilisée pour décrire des erreurs systématiques ou une mesure du
biais statistique.
— L’aire sous la courbe : La courbe ROC (Receiver Operator Characteristic)

[26] est une métrique d’évaluation pour les problèmes de classification binaire.
48
Il s’agit d’une courbe de probabilité qui trace le taux des vrais positives
par rapport au taux des fausses négatives à différentes valeurs de seuil et
sépare essentiellement le "signal" du "bruit". L’aire sous la courbe (AUC)
est la mesure de la capacité d’un classificateur à distinguer les classes et
est utilisée comme synthèse de la courbe ROC. Plus l’AUC est élevée, plus
la performance du modèle à distinguer les classes positives et négatives est
bonne.
— Matrice de confusion : La matrice de confusion [27] est une matrice N

x N utilisée pour évaluer les performances d’un modèle de classification, où
N est le nombre de classes cibles. La matrice compare les valeurs réelles de
la cible avec celles prédites par le modèle d’apprentissage automatique. La
figure 3.5 illustre la matrice de confusion.
Figure 3.5 – Matrice de confusion [27]
3.3.3 Apprentissage continu
Après la phase du construction du modèle et sa mise en production, les

demandes de remboursement reçues, traitées par l’instance du modèle et validées
par l’expert métier sont stockées dans l’archive. D’ici, on a décidé de les exploiter
pour améliorer les performances du modèle prédictif.
En effet, lorsque le système détecte une potentielle tentative de fraudes, l’expert
49
métier vérifiera cette demande et valide le label de cette demande dans l’espace
de stockage à travers un accès CRUD. Ensuite, le modèle sera mis à jour périodi-
quement en mélangeant les nouvelles données avec la base d’apprentissage pour
construire une nouvelle version. Cette version sera mise en Staging, c’est une phase
de test par le développeur d’apprentissage automatique qui à son tour décide de
la méttre en production. L’ancienne version peut être archivée ou supprimée. La
Figure 3.6 illsutre ce processus de réapprrentissage
Figure 3.6 – Cycle d’entraînement continu
Conclusion
Dans ce chapitre, nous avons traité l’aspect étude des données et mo-
délisation de notre solution. Nous avons commencé par les présenter. Puis, nous
sommes passés à la phase de préparation qui constitue tous les prétraitements.
Ce qui nous a rendu à la phase de modélisation au cours de laquelle nous avons
présenté les algorithmes ML, les métriques que nous avons utilisé pour évaluer
50
nos résultats. Enfin, nous sommes arrivés à la phase de l’entraînement continu du

modèle.
51
CHAPITRE 4
Réalisation et implémentation
Sommaire
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.1 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.2 Cadre technique du travail . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.3 Déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2.4 Présentation des résultats . . . . . . . . . . . . . . . . . . . . . . . . . 75
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
52
CHAPITRE 4 Réalisation et implémentation
Introduction
Ce chapitre représente le dernier volet de ce rapport et a pour objectif

d’exposer le travail achevé. Dans un premier temps, nous commençons par la
présentation des résultats des algorithmes testés et le choix du modèle. Ensuite,
nous allons présenter l’architecture logique de notre solution et le cadre technique
du travail. Nous terminons par la présentation de l’architecture logicielle et la
présentation des résultats.
4.1 Evaluation
Après avoir préparé les données et modèlisé le système de prédiction des

fraudes à travers différents algorithmes de ML, nous allons aborder la prochaine
phase du projet selon la méthodologie CRISP-DM que nous avons adopté. Elle
s’agit de la phase de l’évaluation des performances des algorithmes que nous avons
présenté dans le chapitre 3.
Cette évaluation est menée dans le but de choisir le modèle que nous allons mettre
en production.
Nous commeçons par présenter les résultats de chacun de ces algorithmes après
une série de tests ainsi que les métriques de performance correspondantes que
nous avons choisi.
— Logistic Regression :
- Exactitude : 0.71876
- Rappel : 0.54902
- AUC : 0.67929
53
Figure 4.1 – Matrice de confusion de l’algorithme Logistic Regression
— GaussianNB :
- Rappel : 0.09804
- AUC : 0.62055
Figure 4.2 – Matrice de confusion de l’algorithme GaussianNB
— RandomForestClassifier :
- Rappel : 0.05882
- AUC : 0.68548
54
Figure 4.3 – Matrice de confusion de l’algorithme RandomForestClassifier
— ExtraTreesClassifier :
- Rappel : 0.31373
- AUC : 0.670.68707
Figure 4.4 – Matrice de confusion de l’algorithme ExtraTreesClassifier
— GradientBoostingClassifier :
- Rappel : 0.03922
- AUC : 0.68898
55
Figure 4.5 – Matrice de confusion de l’algorithme GradientBoostingClassifier
— XGBoost :
- Rappel : 0.42156
- AUC : 0.63214
Figure 4.6 – Matrice de confusion de l’algorithme XGBoost
— SVC avec Kernel RBF :
- Rappel : 0.61258
- AUC : 0.71589
56
Figure 4.7 – Matrice de confusion de l’algorithme SVC avec Kernel RBF
A partir de ces résultats, nous avons décidé de choisir l’algorithme SVC avec
le Kernel RBF. En effet, notre choix est basé sur l’ensemble des trois métriques
choisies. Ce modèle a montré dans les expéreinces qu’il possède non seulement une
bonne performance en terme de détection des fraudes, mais aussi une tendance à
caractériser quelques demandes légitime comme frauduleuses ce qui est interpreté
par le taux des faux négatives. Cette tendance est éxigé par les contraintes métier
vu que l’assurance médicale ne tolère pas rater les fraudes.
4.2 Réalisation
4.2.1 Architecture logique
L’architecture est la base de l’analyse big data. Il s’agit du système global

utilisé pour gérer de grandes quantités de données afin qu’elles puissent être analy-
sées. Il faut donc diriger cet analyse des données et fournir un environnement dans
lequel les outils big data peuvent extraire des informations métier essentielles.
Dans cette étape, on s’intérresse à cet environnement logique qui peut garantir
un bon fonctionnement du notre solution. Dans le chapitre 2, nous avons déjà
décrit les types d’architectures Big Data et leurs principales différences. Après
avoir étudier ces architectures et exposer leurs principales cas d’utilisation, on a
57
choisi d’adopter l’architecture Lambda pour notre solution. La figure 4.8 illustre
cette adoption.
Figure 4.8 – Architecture logique de la solution
En effet, l’assurance médicale, comme organisation, reçoit des millions de de-

mandes de remboursement chaque jour, provenant par le biais de ses différentes
agences réparti dans le pays. Ce qui justifie l’utilité de la couche Speed de notre
architecture. Cette couche va tout d’abord recevoir ces demandes, à travers le
pipeline des données élaboré dans le module Ingestion Temps Réel. Ce pipeline
garantie la disponibilité du système pour que le traitement ne sera pas submergé
par l’entrée des demandes, ce qui pourra causer un potentiel plantage.
Ce module passera les demandes dans leurs format brütes pour le stockage en
masse, et au module Stream Processing qui va les traiter en faisant appel à une
instance du modèle d’apprentissage automatique.
Pour la partie Batch, elle sera consacré à tout traitements qui pourra s’éxecuter
en arrière plan. Pour notre cas, les données doivent être ingérées de façon régulière
pour la création et amélioration continue du modèle. Cette phase est importante
non pas seulement pour garantir une haute performance du modèle, mais aussi
58
d’avoir un l’espace temporelle pour éxecuter une grande masse de données vu

qu’on est présent dans un cadre Big Data. Cette masse est accessible pour les
opérations de lecture, écriture, misé à jour et suppression par le responsable mé-
tier.
Finalement, notre architecture garantit un accès aisé à l’analyste du métier à
travers la couche Serving, qui fournira des tableau de bord pour la visualisation
en temps réel des résultats et consulter un historique statistique détaillé sur les
données.
4.2.2 Cadre technique du travail
— Bibliothèques et Frameworks utilisées :
1. Apache Spark :
Apache Spark [28] est un moteur d’analyse unifié pour le traitement des
données à grande échelle. Il permet d’éxecuter des calculs distribués à
l’aide d’un cluster regroupant des machines. Les composantes de Spark
qu’on a utilisées sont :
- Spark Streaming : Spark Streaming [29] est une extension de

Spark dédié pour l’analyse de flux en temps réel an tirant parti des
capacités de planification rapide de Spark Core. Elle ingère les don-
nées par mini-batchs et effectue des analyses sur ces données en uti-
lisant le même traitement d’analyse par batch. La Figure 4.9 illustre
le prcessus de traitement du flux avec Spark Streaming
- Spark SQL : Spark SQL est un moteur de requêtes distribué qui

fournit des requêtes interactives à faible latence, jusqu’à 100 fois plus
rapides que MapReduce. Il comprend un optimiseur basé sur les coûts
et Il s’adapte à la distribution de la manipulation des données sur
59
Figure 4.9 – Le flux de Spark Streaming [29]
les différents nœuds.
2. Scikit Learn : Scikit-learn [30] est une bibliothèque qui fournit une
gamme d’algorithmes d’apprentissage supervisé et non supervisé via une
interface cohérente en Python. Scikit-learn a été initialement développé
par David Cournapeau dans le cadre du projet Google Summer of Code
en 2007.
Figure 4.10 – Scikit Learn [30]
Les fonctionalités qu’on peut mettre en oeuvre à travers cette bibilio-

thèque sont :
- Clustering : Pour regrouper des données non étiquetées, comme

KMeans.
- Validation croisée : Pour évaluer les performances des modèles

supervisés sur des données non observées.
- Jeux de données : Pour les jeux de données de test et pour générer

des jeux de données avec des paramètres spécifiques pour étudier le
comportement du modèle.
60
- Réduction de la dimensionnalité : Pour réduire le nombre d’at-

tributs dans les données à des fins de résumé, de visualisation et
de sélection des caractéristiques, comme l’analyse en composantes
principales.
- Méthodes d’ensemble : Pour combiner les prédictions de plusieurs

modèles supervisés.
- Extraction de caractéristiques : Pour définir les attributs dans

les données d’image et de texte.
- Sélection des caractéristiques : Pour identifier les attributs si-

gnificatifs à partir desquels créer des modèles supervisés.
- Réglage des paramètres : pour optimiser les modèles supervisés.
- Apprentissage multidimensionnel : Pour résumer et représenter

des données multidimensionnelles complexes.
- Modèles supervisés : une panoplie d’algorithmes d’apprentissage

supérvisés
3. Pandas : Pandas [31] est un outil d’analyse et de manipulation de don-

nées open source rapide, puissant, flexible et facile à utiliser, construit
à partir du langage de programmation Python sous la forme d’une bi-
bliothèque qui nous a permis d’explorer plus aisement le jeu de données.
Figure 4.11 – Pandas [31]
4. Mlflow : MLflow [32] est une plateforme open source permettant de

gérer le cycle de vie d’un algorithme ML, notamment l’expérimentation,
61
la reproductibilité, le déploiement et le registre des modèles. La partie de

la création et gestion du modèle a été mené sur la plateforme Databricks.
En fait, Databricks fournit une version entièrement gérée et hébergée de
MLflow, intégrée avec des fonctions de sécurité de l’entreprise, une haute
disponibilité et d’autres fonctions de l’espace de travail Databricks telles
que la gestion des expériences et des exécutions. MLflow sur Databricks
offre une expérience intégrée pour le suivi et la sécurisation des cycles de
formation des modèles d’apprentissage automatique et l’exécution des
projets ML.
MLflow offre quatre composants :
- MLflow Tracking : Pour l’enregistrez et l’interrogation des expé-

riences.
- Projets MLflow : Empaquetage du code dans un format permet-

tant de reproduire les exécutions sur n’importe quelle plateforme.
- Modèles MLflow : Déploiement des modèles d’apprentissage au-

tomatique dans les divers environnements de service
- Registre de modèles : Stockage, annotation, découverte et géstion

les modèles dans un cadre centralisé.
— Environnement logicel :
Les entreprises du monde entier ont connu un grand succès grâce aux solu-
tions basées sur le cloud. Elles redéfinissent la manière dont elles exercent
leurs activités grâce à des applications évolutives et sécurisées basées sur le
cloud. D’où on a choisi de mettre en oeuvre les outils disponible sur le cloud.
On a choisi de travailler avec Microsoft Azure.
En fait, grâce aux services cloud Azure intégrés, les entreprises peuvent ra-
pidement créer, déployer et gérer des applications simples et complexes en
62
Figure 4.12 – L’interface de Microsoft Azure
toute simplicité. Azure prend en charge un large éventail de langages de pro-

grammation, de cadres, de systèmes d’exploitation, de bases de données et
de périphériques, ce qui permet aux entreprises de tirer parti de la panoplie
des outils et des technologies offertes.
Dans la suite, on va présenter chacune des outils du cloud Azure qu’on a
utilisé.
1. Event Hub :
Azure Event Hubs [33] est une plateforme de streaming de big data et un
service d’ingestion d’événements. Il peut recevoir et traiter des millions
d’événements par seconde. Les données envoyées à un hub d’événements
peuvent être transformées et stockées en utilisant n’importe quel four-
nisseur d’analyse en temps réel ou adaptateur de mise en lots/stockage.
Event Hubs est une plateforme entièrement gérée en tant que service
(PaaS) avec peu de configuration ou de gestion. La Figure 4.14 illustre
les composantes clés de cet outil.
63
Figure 4.13 – L’interface de Azure Event Hub
Figure 4.14 – L’architecture de Azure Event Hub [33]
- Producteurs d’événements : Tout ce qui envoie des données à un

hub d’événements peut compter comme un producteur d’événements.
Les événements peuvent être publiés à l’aide des protocoles HTTPS
ou AMQP ou Kafka.
- Partitions : Les événements sont diffusés vers une partition spéci-

fique et chaque consommateur ne lit qu’un sous-ensemble spécifique,
ou partition. Le nombre de partitions est spécifié à la création.
64
- Clés de partition : La clé de partition est la valeur permettant de

mapper les données d’événement entrantes à une partition spécifique.
- Consommateur : Le consommateur est n’importe quelle applica-

tion qui lit les données d’événement d’un Event Hub.
- Groupes de consommateurs : Il n’est pas possible d’accéder

directement aux partitions pour récupérer les données, mais les don-
nées ne sont accessibles qu’à travers un groupe de consommateurs.
Comme chaque application consommatrice peut avoir une manière
différente de lire le flux, les groupes de consommateurs donnent la
possibilité aux entités consommatrices d’avoir une vue séparée du
flux d’événements.
2. Azure Stream Analytics :

Azure Stream Analytics [34] est un service d’analyse en temps réel, en-
tièrement géré, conçu pour analyser et traiter des flux de données en
mouvement rapide pour obtenir des informations, créer des rapports ou
déclencher des alertes et des actions.
3. Azure Databricks :
Databricks [35] est la mise en œuvre d’Apache Spark sur Azure. Avec
des clusters Spark entièrement gérés, il est utilisé pour traiter de grandes
charges de travail de données et aide également à la modélisation, à
l’exploration et à la visualisation des données à l’aide de l’apprentissage
automatique.
Les fonctionalités d’Azure Databricks qu’on a utilisé :
- Ingérer des données collectées depuis Azure Event Hubs.
- Les stocker via le service de stockage Azure Data Lake Storage.
65
Figure 4.15 – L’interface de Azure Databricks
- Les transformer et les préparer notamment pour concevoir un modèle

de Machine Learning à l’aide du Databricks Runtime qui permet
d’éxecuter différentes langages de programmation.
- Déployer le modèle en production par le biais de la gestion des mo-

dèles et des instances de machine virtuelles fournie.
Pour le module d’ingestion des données depuis Event Hubs, la Figure

4.16 expose le workflow des données du flux entrant des demandes :
Figure 4.16 – Le processus du module Ingestion des données [35]
66
L’écosystème d’Azure Databricks nous a permis de garantir la sécurité

à travers le control d’accès offert par la plateforme. Ainsi que la commu-
nication avec les différents services d’Azure.
Figure 4.17 – L’écosystème de Azure Databricks [35]
La Figure 4.17 expose les fonctionalités offertes par la plateforme. En

fait, le panneau de contrôle permet de superviser les instances virtuelles
lancées et leurs réseau, ainsi que la gestion de l’espace de travail et le
contrôle d’accès des notebooks. En outre, Azure Databricks nous a faci-
lité le processus de gestion des clusters.
D’ici on passe à l’architecture d’Azure Databricks et ses cadres de tra-
vails.
Pour la gestion des données :
- Système de fichiers Databricks (DBFS) : Une couche d’abstrac-

tion de système de fichiers. Il contient des répertoires, qui peuvent
contenir des fichiers.
- Base de données : La plateforme offre une collection d’informations

qui est organisée de manière à pouvoir être facilement accessible,
gérée et mise à jour.
67
- Table : Une représentation de données structurées manipulable par

Apache Spark SQL et les autres API Spark.
- Métastore C’est un composant qui contenant toutes les informa-

tions de structure des différentes tables et partitions des bases de
données ainsi que le métastore Hive central accessible par tous les
clusters.
Pour la gestion de calcul :
— Cluster : Un ensemble de ressources et de configurations de calcul

sur lesquelles on a exécuté les notebooks et les jobs. Ces ressources
sont administrés et gérés par la plateforme ce qui nous a fait gagné
de temps pour le calcul distribué. Pour notre cas, on a mis en place
un cluster à noeud unique avec les descriptions représente dans la
figure 4.18
Figure 4.18 – Cluster utilisé
- Pool : Un ensemble d’instances, prêtes à l’emploi, qui réduisent les

temps de démarrage et de mise à l’échelle automatique des clusters.
Lorsqu’il est rattaché à un pool, un cluster alloue son pilote et ses
68
nœuds de travail à partir du pool.

Pour la gestion des modèles d’apprentissage automatique :
- Expériences : La principale unité d’organisation pour le suivi du
développement des modèles d’apprentissage automatique. Les expé-
riences organisent, affichent et contrôlent l’accès aux exécutions en-
registrées du modèle à travers le framework mlflow.
- Modèle : Après l’avoir entrainé, on gére le cycle de vie d’un modèle

à travers ce module. La gestion des versions des modèles en pro-
duction dans ce module a été mis en oeuvre dans ce travail pour le
reentrainement avec les nouvelles données stockées.
4. Azure Data Lake Storage :
Microsoft Azure Data Lake Storage (ADLS) [36] est un système de fi-
chiers, évolutif et sécurisé qui prend en charge HDFS et fonctionne avec
l’écosystème Apache Hadoop. Il offre une fiabilité élevée, une sécurité de
niveau entreprise et un stockage illimité. Il est conçu pour exécuter des
systèmes d’analyse à grande échelle qui nécessitent une grande capacité
de calcul pour traiter et analyser de grandes quantités de données. Les
données stockées dans ADLS peuvent être analysées à l’aide de cadres
Hadoop tels que MapReduce et Hive. On l’a choisi comme étant l’espace
de stockage en masse. En particulier, on a utilisé la dernière version dis-
ponible Azure Data Lake la 2ème génération.
Les principales de notre choix sont :
- Structure hierarchique
- Une échelle illimitée et une durabilité des données
- Sécurité élevée
- Plateforme de stockage unique pour l’ingestion, le traitement et la

visualisation
69
- Optimisation des coûts grâce à la mise à l’échelle indépendante du

stockage
Azure Data Lake Storage Gen2 [36] repose sur le stockage Azure Blob.
Azure Data Lake Gen 2 contient des fonctionnalités d’Azure Data Lake
Storage Gen1, telles que la logique des systèmes de fichiers, les réper-
toires, la sécurité au niveau des fichiers et l’évolutivité, combinées à des
fonctionnalités de stockage à faible coût et à plusieurs niveaux, ainsi qu’à
la haute disponibilité et à la reprise après incident du stockage Azure
Blob. La Figure suivante illustre le système de fichier du Data Lake gen
2:
Figure 4.19 – Structure de fichier du Data Lake [36]
5. Power BI :
À la base, Power BI [37] est une suite de solutions de business intelli-
gence, fournie par Microsoft, qui offre des renseignements et des analyses
illustrés dans des tableaux de bord interactifs et ergonomiques. Cet ou-
til nous a permit également de créer une visualisation instantanée des
données depuis le Data Lake.
6. Azure Storage Explorer :
70
Azure Storage Explorer [38] est une application autonome qui nous a
permis d’accéder facilement au compte de stockage Azure, ainsi le Data
lake, via n’importe quel appareil. Nous nous sommes connectés à l’abon-
nement et manipuler les tables et blobs. Un grand atout de ce logiciel est
le fait d’avoir une interface utilisateur ergonomique et facile à parcourir.
D’où l’expert métier de l’assurance n’aura pas de difficultés lors de son
accès. La Figure suivante présente son interface :
Figure 4.20 – L’interface d’Azure Storage Explorer
— Coût et description matérielle : Le tableau suivant présente une des-

cription détaillée des outils Azure que nous avons éxploité pour la réalisation
du travail ainsi que leurs coûts de consommation par semaine correspondant.
71
Consommation
Type de service Region Description
par semaine
Type Standard, 1 unité(s) de streaming

Stream Analytics East US x 168 Heures ; Stream Analytics sur $18,48
0 appareil(s) avec IoT Edge
Basic niveau : 0 million

Event Hubs East US d’événements d’entrée, $2,52
1 unités de débit x 168 Heures
Charge de travail Calcul à usage général,

Niveau Standard, 1 D12V2 (4 vCPU(s),
Azure Databricks East US $129,528
28 GO DE RAM) x 168 Heures,
À l’utilisation, 1 DBU x 168 Heures
Redondance Data Lake Storage Gen2,

Standard, LRS, Niveau d’accès À chaud,
Structure de fichiers Espace de noms plat,
1000 Go Capacité
À l’utilisation, opérations d’écriture :
Storage Accounts East US $71,88
4 Mo x 100000 opérations,
-opérations de lecture :
4 100000 x Mo opérations,
1000 Go extraction de données,
1000 Go écriture de données
Licensing Program : Microsoft Online Services Agreement
Total : $222,408
Table 4.1 – Tableau détaillant les dépenses sur les outils Azure par semaine
1. Architecture logicielle : Après avoir présenté le cadre technologique

de notre travail, on va aborder la partie de l’implémentation et construc-
tion de notre système Big Data. Nous allons nous intérresser à adapter
les outils Microsoft Azure dans la mise en place de l’architecture Lambda
choisi.
72
La Figure 4.21 ci-dessous présente cette adaptation et valorise la com-

munication entre les différents services
Figure 4.21 – Architecture Logicielle
2. Simulation : Après avoir configuré tous les outils de Microsoft Azure,

mettre en production le modèle prédictif, préparer les dashboards de
présentation des résultats, on va simuler le fonctionnement du système
de détection des fraudes pour une assurance médicale en référant à la
figure illustré dans la partie précedente.
La première étape, est l’accès au lac de données Azure par le module
Batch Processing géré par Spark et développé dans l’espace de travail
Databricks. Cet accès a pour but dans un premier lieu l’ingestion des
données initiales. On rappel que la base de la construction du modèle
est l’enemble des jeux de données publié par les CMS.
Ensuite, c’est la phase d’évaluation et mise en production du modèle à
travers le module Machine Learning.
Passons à la simulation de l’entrée d’un flux énorme de demandes, assuré
par un script python qui publie ces données dans un Event Hub configuré
73
et mis en ligne et qui à son tour va assurer le stockage des demandes

dans leurs format brute dans le lac des données. Dans la contre partie,
Spark Streaming, mis à l’écoute continue de l’Event Hub configuré, va
consommer les données en attente et les traiter en première phase en
reproduisant une partie du prétraitement pour mettre ces données dans
le meme schéma de données d’entrée du modèle, puis il fait appel à l’ins-
tance de la dérnière version du modèle en production, pour identifier les
demandes frauduleuse et finalement stocker toute donnée traitée dans le
lac de données et les passer au module de Serving par le biais de Stream
Analytics.
Pour la partie d’exposition des résultats, Power BI nous a permis de
créer un rapport détaillé sur l’archive des données traitées et non ttrai-
tées dans le lac de données ainsi qu’un tableau de bord en temps direct
dont l’expert peut facilement l’explorer et valider les résultats du mo-
dèle prédictif. S’il y a une demande prédite comme frauduleuse mais ce
n’est pas le cas, ce dernier accède à l’espace de stokage pour changer le
label de cette données dans le but de fournir des données validées pour
la prochaine mise à jour du modèle.
Les mises à jour du la version de l’algorithme ainsi que les traitements
en Batch sont gérées par le processus de planification des traitements
dont ses dates sont fixés par l’expert métier et le developpeur ML.
4.2.3 Déploiement
La phase de déploiement est la dérnière étape dans le cycle de la métho-

dologie CRISP-DM. Dans cette partie, on va vous présenter la mise en production
et l’exposition de l’API du modèle choisi. La figure 4.22 présente l’interface de
74
gestion de l’état de cycle de vie du modèle sur la plateforme Databricks
Figure 4.22 – Gestion du cycle de vie du modèle
La figure ci-dessous illustre l’exposition de l’API du modèle et sa mise

en service.
Figure 4.23 – Exposition de l’API du modèle
4.2.4 Présentation des résultats
Cette section va être consacrée pour mettre en valeur les résultats servies
par notre solution.
— Rapports sur les données historiques
1. Vue d’ensemble :
La première page du rapport regroupe les statistiques et informations né-
cessaires que l’analyste métier en a besoin. Illustrés dans la figure 4.24, la
page contient des filtres par état, par ville et d’autres axe d’exploration.
75
Figure 4.24 – Rapport en vue d’ensemble
Les componsantes principales de la page sont :
(a) Taux des demandes par médicament.
(b) Coût par médicament demandé.
(c) Nombre des demandes par ville.
(d) Carte explorable contenant la distribution des demandes par ville.
(e) Mantant remboursé comparé au mantant demandé.
2. Suivi par fournisseur de service :

Cette page du rapport présente l’exploration des statistiques par four-
nisseur de service. L’analyste peut trouver les informations nécessaires
en parcourant la liste des fournisseur ou plus simplement par écrire son
nom et prénom dans la case de recherche et qui représente un filtre sur
les autres composantes.
76
Figure 4.25 – Rapport de suivi de demande par fournisseur
— Barre de recherche par nom et prénom.
— Liste déroulante de tous les fournisseurs.
— Total de remboursement et mantont demandé par médicament par

fournisseur.
— Carte permettant parcours par ville.
— Nombre totale historique des fraudes.
3. Suivi par fraud identifié :

Il est indispensable pour un expert métier d’une assurance médicale d’ex-
plorer toute information relative à une fraude identifié. Ainsi, on lui four-
nit cette page consacrée à la suivi de toute demande marqué frauduleuse.
77
Figure 4.26 – Rapport de suivi par fraud identifié
(a) Barre de recherche par nom et prénom.
(b) Liste déroulante de tous les fournisseurs impliqués dans des fraudes.
(c) Coût des médicaments dans la demande frauduleuse
(d) Carte permettant parcours par ville où il y a eu des des fraudes.
(e) Liste des médicaments demandés dans une demande frauduleurse.
(f) Somme des transactions frauduleuses par fournisseur.
— Tableau de bord temps réel : Une partie fondamentale dans la

couche Serving de notre système est l’exposition des résultats obtenus
dès l’entrée de la demande de remboursement. Ceci est élaboré à travers
un tableau de bord mis en place sur Power BI dans sa version application
web. La figure 4.27 ci-dessous représente ce tableau de bord.
78
Figure 4.27 – Rapport de suivi en temps réel
Conclusion
Dans ce chapitre, nous avons exposé en détails la réalisation de notre

travail. Nous avons tout d’abord commencé par les résultats des algorithmes que
nous avons testé pour arriver à notre choix du SVC comme modèle déployé. Par
la suite, nous avons présenté le cadre logiciel où nous avons adapté notre archi-
tecture logique avec les outils cloud Azure pour arriver à l’architecture logicielle
implémenté.
79
Pour clôturer, nous avons présenté les resultats de tous les traitements à travers
des captures d’écran des dashboards réalisés.
80
Conclusion
L’intégrationx d’unxaspect informatique est devenue vitalexxpour une

entreprise. L’évolution technologique xa permis de changer fondamentalement son
mode de fonctionnement, améliorer son avantage concurrentiel et renforcer sa stra-
tégie etxcroissance. Ce travail se situe dans le cadre du projet de fin d’études. En
effet, c’est une élaboration d’une tranformation digitale du processus de gestion
desxdemandes de remboursement pour une assurance médicale. Cette transforma-
tion a comme aspect principal d’implémenter un système de prédiction dexfraudes
tout en tenant compte du grand volume dexdonnées que nous devrons analyser.
Nous avons fait recours aux technologies de Big Data et de Machine Learning
pourximplémenter un tel système.
Ce projet s’est déroulé sur quatre étapes principales. Dans un premier

lieu on a présenté l’organisme d’accueil et le cadre du travail pour passer au choix
de la méthodologie adoptée CRISP-DM. Dans un second lieu, nousxavons présenté
les concepts clés abordés et la logique du métier avec une étude des solutions
existantes sur le marché. Ensuite, nous avons élaboré les phases du travail selon
la démarche CRISP-DM où nous avons commencé par comprendre l’ensemble des
données collecté et son exploration qui nous a ramené à la phase suivante du
construction du modèle de prédiction. Nous avons présenté à la fin, l’évaluation
81
Conclusion
des différents algorithmes testés et l’implémentation de l’architecture générale qui

met le modèle dans un evironnement autonome gérant le flux des données.
Tout au long de ce travail, nous avons fait face à différentes difficul-

tés qui se situent principalement dans la collecte des données et la construction
d’un ensemble étiqueté, ainsi que la modélisation en se basant sur des données
non équilibrées et aussi la mise en place de l’architecture sur Azure. Mais, nous
avons surmonté ces obstacles et fini par implémenter notre système fonctionnel et
performant tout en répondant aux besoins et aux exigences.
Cependant, notrextravail peut toujours être amélioré. Une étude encore

plus profonde dans la phase du modélisation peut être menée où nousxpouvons
explorer les techniques d’apprentissage profond pour renforcer la performance du
modèle prédicitif. Nous pouvons aussi exploiter encore plus les données collectées
et même tester la généralisation de notrexsolution avec d’autre sources de données.
Ce projet était une expérience enrichissante et l’intégration de l’équipe

de INIR était une excellente opportunité d’initiationxà la vie professionelle.
82
Nétographie
[1] https ://www.datascience-pm.com/kdd-and-data-mining/. Consulté le : 29-03-2022.
[2] https ://www.datascience-pm.com/semma/. Consulté le : 29-03-2022.
[3] https ://www.ibm.com/support/knowledgecenter/SS3RA7s ub/modelerc rispdmd dita/clementine/cris

Consulté le : 29-03-2022.
[4] https ://fr.blog.businessdecision.com/methode-crisp-la-cle-de-la-reussite-en-data-

science/. Consulté le : 29-03-2022.
[5] https ://www.datascience-pm.com/crisp-dm-still-most-popular/. Consulté le : 02-04-2022.
[6] https ://www.lebigdata.fr/definition-big-data. Consulté le : 03-04-2022.
[7] http ://lambda-architecture.net. Consulté le : 05-04-2022.
[8] https ://hazelcast.com/glossary/kappa-architecture/. Consulté le : 05-04-2022.
[9] https ://www.ibm.com/fr-fr/analytics/machine-learning. Consulté le : 08-04-2022.
[10] https ://azure.microsoft.com/en-us/. Consulté le : 10-04-2022.
[11] https ://hackernoon.com/what-is-serverless-architecture-what-are-its-pros-and-cons-

cc4b804022e9. Consulté le : 11-04-2022.
[12] https ://www.cms.gov. Consulté le : 15-04-2022.
[13] https ://www.silicon.fr/ibm-almerys-probtp-traquent-fraude-soins-sante-162817.html.

[14] https ://www.sas.com/content/dam/SAS/enu s/doc/productbrief /sas − detection −

investigation − health − care − 104106.pdf . Consulté le : 18-04-2022.
[15] https ://www.gao.gov/products/gao-17-710. Consulté le : 18-04-2022.
83
Nétographie
[16] https ://www.osplabs.com/healthcare-payer-software-solutions/fraud-waste-abuse-system-

solution/. Consulté le : 18-04-2022.
[17] http ://faculty.cas.usf.edu/mbrannick/regression/Logistic.html. Consulté le : 23-04-2022.
[18] https ://dataaspirant.com/gaussian-naive-bayes-classifier-implementation-python/.

[19] https ://builtin.com/data-science/random-forest-algorithm. Consulté le : 23-04-2022.
[20] https ://xgboost.readthedocs.io/en/latest/. Consulté le : 23-04-2022.
[21] https ://machinelearningmastery.com/extra-trees-ensemble-with-python. Consulté le : 24-

04-2022.
[22] https ://machinelearningmastery.com/gentle-introduction-gradient-boosting-algorithm-

machine-learning/. Consulté le : 24-04-2022.
[23] https ://www.analyticsvidhya.com/blog/2017/09/understaing-support-vector-machine-

example-code/. Consulté le : 25-04-2022.
[24] https ://machinelearningmastery.com/precision-recall-and-f-measure-for-imbalanced-

classification/. Consulté le : 28-04-2022.
[25] https ://keras.io/api/metrics/accuracym etrics/. Consulté le : 28-04-2022.
[26] https ://developers.google.com/machine-learning/crash-course/classification/roc-and-

auc. Consulté le : 28-04-2022.
[27] https ://in2techs.com/confusion-matrix/. Consulté le : 28-04-2022.
[28] http ://spark.apache.org/docs/latest/. Consulté le : 03-05-2022.
[29] http ://spark.apache.org/docs/latest/streaming-programming-guide.html. Consulté le : 03-

05-2022.
[30] https ://scikit-learn.org/stable/. Consulté le : 07-05-2022.
[31] https ://pandas.pydata.org. Consulté le : 07-05-2022.
[32] https ://mlflow.org. Consulté le : 12-05-2022.
[33] https ://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-about. Consulté le : 15-

05-2022.
[34] https ://docs.microsoft.com/en-us/azure/stream-analytics/. Consulté le : 12-05-2022.
[35] https ://docs.databricks.com. Consulté le : 18-05-2022.
84
Nétographie
[36] https ://docs.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-introduction.

[37] https ://docs.microsoft.com/en-us/power-bi/. Consulté le : 18-05-2022.
[38] https ://azure.microsoft.com/en-us/features/storage-explorer/. Consulté le : 18-05-2022.
85
Annexes
86
Annexe : Glossaire des données
Glossaire de données du jeu de données Partie B :
87
Nétographie
Attribut Format Longueur Description

npi Char 10 Identificateur National
nppes_provider_last_org_name Char 70 nom/organisation du fournisseur
nppes_provider_first_name Char 20 First Name of the Provider
nppes_provider_mi Char 1 Middle Initial of the Provider
nppes_credentials Char 20 Credentials of the Provider
nppes_provider_gender Char 1 Gender of the Provider
nppes_entity_code Char 1 Entity Type of the Provider
nppes_provider_street1 Char 55 Street Address 1 of the Provider
nppes_provider_street2 Char 55 Street Address 2 of the Provider
nppes_provider_city Char 40 City of the Provider
nppes_provider_zip Char 20 Zip Code of the Provider
nppes_provider_state Char 2 State Code of the Provider
nppes_provider_country Char 2 Country Code of the Provider
provider_type Char 55 Provider Type of the Provider
medicare_participation_indicator Char 1 Medicare Participation Indicator
place_of_Service Char 1 Place of Service
hcpcs_code Char 5 HCPCS Code
hcpcs_description Char 256 HCPCS Description
hcpcs_drug_indicator Char 1 Drug Included in the Drug List
line_srvc_cnt Num 8 Number of Services
bene_unique_cnt Num 8 Number of Medicare Beneficiaries
bene_day_srvc_cnt Num 8 Number of Distinct Medicare
88
Nétographie
Glossaire de données du jeu de données Partie D :
Attribut Format Longueur Description

npi Char 10 National Provider Identifier
nppes_provider_last_org_name Char 70 Last Name/Organization
nppes_provider_first_name Char 20 First Name of the Provider
nppes_provider_city Char 40 City of the Provider
nppes_provider_state Char 2 State Code of the Provider
specialty_description Char 75 Provider Specialty Type
description_flag Char 1 Source of Provider Specialty
drug_name Char 30 Brand Name
generic_name Char 30 USAN Generic Name
bene_count Num 8 Number of Medicare Beneficiaries
total_claim_count Num 8 Number of Medicare Part D Claims
total_30_day_fill_count Num 8 Number of Standardized Fills
total_day_supply Num 8 Number of Day’s Supply
total_drug_cost Num 8 Aggregate Cost Paid
bene_count_ge65 Num 8 Number of Medicare Beneficiaries
bene_count_ge65_suppress_flag Char 1 Reason for Suppression
89
Résumé :
Ce projet intitulé «Implémentation d’un système de détection de fraudes dans
le secteur des assurances médicales» a été élaboré en vue d’obtenir le diplôme
d’ingénieur en informatique et multimédia.
Le travail consiste à mettre en place une architecture Big Data capable d’analyser
un flux entrant en temps réel des demende de remboursement dans une assurance
médicale et identifier celles qui sont frauduleuses en exploitant les technologies
d’apprentissage automatique. La réalisation de ce travail était menée sur la pla-
teforme cloud de Microsoft.
Mots-clés : Big Data, Cloud, Détection de fraudes, Spark, assurance

médicale, Apprentissage automatique
Abstract :
This project entitled "Implementation of a fraud detection system in the medical
insurance sector" was developed in order to obtain the degree of computer engi-
neer. The work consists in setting up a Big Data architecture capable of analyzing
a stream of real-time incoming claims in a medical insurance and identifying those
that are fraudulent by exploiting machine learning technologies. This work was
carried out on the Microsoft cloud platform.
Keywords : Big Data, Cloud, Fraud Detection, Spark, Healthcare

insurance, Machine Learning .

Rapport PFE Haikel BelHaj Fraj PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport PFE Haikel BelHaj Fraj PDF

Transféré par

Droits d'auteur :

Formats disponibles

Dédicace

C’est avec grande émotion que je dédie ce travail :

Au symbole de douceur et de tendresse : mes frères Zied et Tarek, je vous dédie ce

Haikel BEL HAJ FRAJ

J’ai l’honneur de présenter mes vifs remerciements à Mm.Imen BEN CHEIKH,

Des remerciements spéciaux à M. Firas JLASSI, mon encadrant chez INIR.

Enfin, je suis profondément reconnaissant à tous les membres du jury d’avoir

1.1 Présentation de l’organisme d’accueil : INIR . . . . . . . . . . . . . 5

1.2 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.1 Aperçu sur l’existant . . . . . . . . . . . . . . . . . . . . . 6

1.2.2 Les clients cibles . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.4 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . 8

1.2.5 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . 9

1.2.6 Exigences et contraintes . . . . . . . . . . . . . . . . . . . . 9

1.3 Démarche de travail et méthodologies . . . . . . . . . . . . . . . . 10

1.3.1 Découverte de connaissances dans les bases de données (Know-

1.3.4 Comparaison et méthodologie adoptée . . . . . . . . . . . . 14

1.3.5 Méthodologie choisie : CRISP-DM . . . . . . . . . . . . . . 15

1.4 Plannification du projet . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1 Notions théoriques . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1.1 Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1.2 L’apprentissage Automatique . . . . . . . . . . . . . . . . 24

2.1.3 Le Cloud Computing . . . . . . . . . . . . . . . . . . . . . 25

2.2 Compréhension du logique métier . . . . . . . . . . . . . . . . . . 28

2.2.1 Les assurances médicales . . . . . . . . . . . . . . . . . . . 28

2.2.2 Le système médicale aux états-unis . . . . . . . . . . . . . . 29

2.3 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.3.1 La plateforme Solon . . . . . . . . . . . . . . . . . . . . . . 30

2.3.2 SAS Healthcare . . . . . . . . . . . . . . . . . . . . . . . . 30

2.3.3 Système de prevention des fraudes . . . . . . . . . . . . . . 32

2.3.4 OSP Healthcare . . . . . . . . . . . . . . . . . . . . . . . . 32

3.1 Compréhension des données . . . . . . . . . . . . . . . . . . . . . . 36

3.1.1 Les services et les paiements des fournisseurs de textbfMe-

3.1.2 L’utilisation et le paiement des fournisseurs de Medicare :

3.1.3 Liste des individus et entités exclues : LEIE . . . . . . . . . 40

3.2 Préparation des données . . . . . . . . . . . . . . . . . . . . . . . 41

3.2.1 Séléction des caractéristiques . . . . . . . . . . . . . . . . . 41

3.2.2 Nettoyage des données . . . . . . . . . . . . . . . . . . . . 41

3.2.3 Construction de l’ensemble de données . . . . . . . . . . . . 42

3.2.4 Préparation du module temps réel . . . . . . . . . . . . . . 43

3.3.1 Les algorithmes d’apprentissage automatique . . . . . . . . 44

3.3.2 Métriques d’évaluation . . . . . . . . . . . . . . . . . . . . 48

3.3.3 Apprentissage continu . . . . . . . . . . . . . . . . . . . . . 49

4.2.2 Cadre technique du travail . . . . . . . . . . . . . . . . . . 59

4.2.4 Présentation des résultats . . . . . . . . . . . . . . . . . . . 75

Annexe : Glossaire des données 87

1.2 Processus KDD [1] . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3 Processus SEMMA [2] . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4 Le processus CRISP-DM illustré [4] . . . . . . . . . . . . . . . . . 13

1.5 Etude de la popularité des méthodes de travail [5] . . . . . . . . . 15

1.6 Diagramme de Gantt. . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1 L’architecture Lambda [7] . . . . . . . . . . . . . . . . . . . . . . . 23

2.2 IT traditionnel vs. IaaS vs. PaaS vs. SaaS [10] . . . . . . . . . . . . 26

2.3 Application Traditionnelle vs. Application Serverless [11] . . . . . . 27

2.4 L’interface de la solution SAS Detection and Investigation for Health

2.5 Le processus de fonctionnement de la solution de OSP [16] . . . . 33

3.1 Distribution des paiements versées par domaine de spécialité . . . . 38

3.2 La distribution des 10 médicaments les plus demandés . . . . . . . 39

3.3 Nombre de fraudes par état . . . . . . . . . . . . . . . . . . . . . . 40

3.5 Matrice de confusion [27] . . . . . . . . . . . . . . . . . . . . . . . 49

3.6 Cycle d’entraînement continu . . . . . . . . . . . . . . . . . . . . . 50

4.1 Matrice de confusion de l’algorithme Logistic Regression . . . . . . 54

4.2 Matrice de confusion de l’algorithme GaussianNB . . . . . . . . . . 54