République Tunisienne

Ministère de l’Enseignement Supérieur

images/logos/Logo [Link] et de la Recherche Scientifique images/logos/Logo_Univers

Université de Tunis

Institut Supérieur de Gestion de Tunis

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du Diplôme de :

Licence Nationale en Business Computing

Spécialité : Business Intelligence

Par

Mohamed Ali JMAL

Optimisation de la Conformité Réglementaire en

Assurance : Approche IA et Automatisée

Encadrant professionnel : M. Mohamed Ismail MAIZA

Encadrant académique : Mme. Henda AJROUD

Réalisé au sein de BH Assurance

images/logos/LOGO BH_LE_auto_x2_light_ai.jpg

Année universitaire 2023-2024

Dédicaces

Je dédie ce travail

À mes précieux parents

Ce travail est dédié à mes chers parents, Belgacem et Aicha, la lumière de mes

yeux. Pour votre soutien sans faille, votre tendresse infinie et vos
innombrables sacrifices, je vous en suis éternellement reconnaissant. Que Dieu

le Tout-Puissant vous comble de bonheur, de longue vie et de santé.

À mes frères et sœurs

Votre amour, votre soutien constant et votre présence réconfortante ont été
des piliers dans ma vie.

À ma bien-aimée,
Pour ton amour inconditionnel, ta patience et ton soutien indéfectible. Tu es

une source précieuse d’inspiration et de joie dans ma vie.

À mes amis chers

À tous mes amis, et spécialement à Khayreddine, Yassine, Ala, Ahmed, et

Hedi, qui ont toujours espéré le meilleur pour [Link] leur désire la réussite

dans leur vie

À ma communauté du Croissant Rouge Tunisien, comité local de

Boumhal,
Votre dévouement, votre solidarité sont une véritable source d’inspiration.

Merci pour tout ce que vous faites.

i
 À mes amis de BH Assurance
Rencontrer et travailler avec vous a été un véritable plaisir. Merci pour votre

camaraderie.
Enfin, un message pour les personnes souffrant en Palestine,

Je sais que ce travail ne peut pas vous aider directement, mais j’espère qu’un
jour, je pourrai réaliser quelque chose qui vous sera vraiment utile. Vous êtes

dans mes pensées et mes prières, et je souhaite de tout mon cœur que la paix
et la justice vous soient accordées bientôt.

À tous ceux qui ont contribué de près ou de loin à la réalisation de ce travail,

Merci infiniment pour votre aide et votre soutien.

Mohamed Ali JMAL

ii
Remerciements

C’est avec un grand plaisir que je réserve ces lignes en signe de gratitude et de
reconnaissance à tous ceux qui ont contribué de près ou de loin à l’élaboration

de ce travail.

Je tiens tout d’abord à remercier tous les responsables et toute l’équipe de BH

Assurance pour leur accueil et leur aide. Je remercie particulièrement

Monsieur Mohamed Ismail MAIZA pour le temps qu’il a voulu me

consacrer à l’encadrement et le suivi de ce travail, les conseils qu’il m’a

prodigués et pour les réunions qui ont rythmé les différentes étapes de la

réalisation de ce projet.
J’adresse aussi mes sincères remerciements à mon encadrante à l’ISG,

Madame Henda AJROUD pour avoir accepté de me diriger patiemment,

pour son soutien constant et pour sa présence et sa disponibilité tout au long

de ce stage.

Je tiens à remercier les membres de jury d’avoir accepté d’évaluer notre

travail.

Enfin, il ne conviendrait pas de terminer sans exprimer ma reconnaissance à

tous les responsables et les enseignants de l’ISG pour la formation qu’ils

m’ont prodiguée durant mon cursus universitaire.

iii
iv
Table des matières

Introduction Générale 1

1 Contextualisation du Projet 3
1.1 Cadre général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 BH GROUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 BH Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 La Fusion client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 KYC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.1 Étude comparative des méthodologies . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.2 Étude comparative des méthodologies agile . . . . . . . . . . . . . . . . . . . . 11
1.5.3 Méthodologie retenue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Préparation du Projet 15
2.1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Analyse globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Élaboration Du Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.2 Répartition du Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

v
Table des matières

2.4 Conception architecturale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4.1 Architecture physique de l’application . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.2 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Choix et exigences technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Release 1 28
3.1 Backlog de la Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Analyse globale de la Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Conception globale de la Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Sprint 1.1 : Gestion des comptes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.1 Backlog du Sprint 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.2 Analyse détaillée du Sprint 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.3 Conception du Sprint 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.4 Réalisation du Sprint 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5 Sprint 1.2 : Vérification KYC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.1 Backlog du Sprint 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.2 Conception du Sprint 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.5.3 Réalisation du Sprint 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.6 Test et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4 Release 2 49
4.1 Backlog de la Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2 Analyse globale de la Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 Conception globale de la Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4 Sprint 2.1 : Gestion client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.1 Backlog du Sprint 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.2 Analyse détaillée du Sprint 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.3 Conception du Sprint 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.4 Réalisation du Sprint 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5 Sprint 2.2 : Gestion de balayage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.5.1 Backlog du Sprint 2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.5.2 Analyse détaillée du Sprint 2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5.3 Conception du Sprint 2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

vi
 4.5.4 Réalisation du Sprint 2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.6 Sprint 2.3 : Identification du classe de risque . . . . . . . . . . . . . . . . . . . . . . . . 65
4.6.1 Backlog du Sprint 2.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.6.2 Analyse détaillée du Sprint 2.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.6.3 Conception du Sprint 2.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.7 Description de l’identification de la classe de risque . . . . . . . . . . . . . . . . . . . . 68
4.7.1 Visualisations et Interprétations . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.7.2 Interprétation des clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.7.3 Prédiction d’un nouvel individu à un cluster . . . . . . . . . . . . . . . . . . . . 77

5 Release 3 79
5.1 Backlog de la Release 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2 Analyse globale de la Release 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.3 Conception globale de la Release 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.4 Sprint 3.1 : Fusion client automatisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.4.1 Backlog du Sprint 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.4.2 Analyse détaillée du Sprint 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.4.3 Conception du Sprint 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.4.4 Réalisation du Sprint 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.5 Sprint 3.2 : Dashbording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.5.1 Backlog du Sprint 3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.5.2 Analyse détaillée du Sprint 3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.5.3 Conception du Sprint 3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.5.4 Réalisation du Sprint 3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.6 Test et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Conclusion générale et perspectives 94

Netographie 96

vii
Table des figures

1.1 Historique de l’évolution de l’engagement de BH ASSURANCE en assurance [2] . . . . 5

1.2 Agilité du bout en bout [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 La méthode Agile Scrum [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Découpage des releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Architecture 3-tiers [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Architecture trois tiers [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 Diagramme de déploiement du système . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6 Architecture MVC [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1 Diagramme de cas d’utilisation global de la release 1 . . . . . . . . . . . . . . . . . . . 29

3.2 Diagramme de classes global de la release 1 . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Diagramme de cas d’utilisation raffiné du sprint 1.1 . . . . . . . . . . . . . . . . . . . . 33
3.4 Diagramme de classes de conception du sprint 1.1 . . . . . . . . . . . . . . . . . . . . 35
3.5 Diagramme de séquences détaillé du cas d’utilisation "S’authentifier" . . . . . . . . . . 35
3.6 Interface de "Login" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7 Interface de "Scanner QR code et OTP " . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.8 Interface de "creation utilsateur" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.9 Interface de "assigner role" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.10 Interface de "asssigner un role" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.11 Interface de "Modifer Mot de passe" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.12 Flux de l’Algorithme de Similarité basé sur la Distance de Levenshtein. . . . . . . . . 41
3.13 Diagramme de cas d’utilisation raffiné du sprint 1.2 . . . . . . . . . . . . . . . . . . . . 43
3.14 Diagramme d’activité pour l’implémentation de l’algorithme de distance de Levenshtein. 45
3.15 Diagramme de classes de conception du sprint 1.2 . . . . . . . . . . . . . . . . . . . . 45
3.16 Diagramme de séquences détaillé du cas d’utilisation "modifier régle de filtrage" . . . . 46

viii
Table des figures

3.17 Iterface "Accepter ou rejeter client" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.18 Interface"Ajouter régle de filtrage" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.19 Interface "modifier régle de filtrage" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.1 Diagramme de classes global de la Release 2 . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2 Diagramme de classes global de la Release 2 . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3 Diagramme de cas d’utilisation raffiné du Sprint 2.1 . . . . . . . . . . . . . . . . . . . 55
4.4 Diagramme de classes de conception du sprint 2.1 . . . . . . . . . . . . . . . . . . . . . 58
4.5 Diagramme de séquences détaillé du cas d’utilisation "Consulter liste des clients" . . . 58
4.6 Diagramme de séquences détaillé du cas d’utilisation "Consulter fiche client" . . . . . . 59
4.7 Iterface"Recherche client si blacklistée" . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.8 Iterface "Créer fiche clinet" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.9 Iterface"Consulter fiche client" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.10 Diagramme de cas d’utilisation raffiné du Sprint 2.2 . . . . . . . . . . . . . . . . . . . 63
4.11 Diagramme de classes de conception du sprint 2.3 . . . . . . . . . . . . . . . . . . . . . 64
4.12 Diagramme de séquences détaillé du cas d’utilisation "Planifier les tâches de balayage
(fréquence)" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.13 Interface "Balayage Manuel" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.14 Diagramme de cas d’utilisation raffiné du Sprint 2.3 . . . . . . . . . . . . . . . . . . . 67
4.15 Diagramme de séquences détaillé du cas d’utilisation "classe de risque de client" . . . . 68
4.16 Étapes du preprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.17 Comparaison des modèles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.18 Visualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.19 Visualisation t-SNE des Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.20 Distribution des Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.21 Pair Plot des variables Clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.22 Distribution des variables par Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.23 Distribution des Caractéristiques par Cluster . . . . . . . . . . . . . . . . . . . . . . . 77

5.1 Diagramme de cas d’utilisation global de la Release 3 . . . . . . . . . . . . . . . . . . 80

5.2 Diagramme de classes global de la Release 3 . . . . . . . . . . . . . . . . . . . . . . . 81
5.3 Diagramme de cas d’utilisation raffiné du Sprint 3.1 . . . . . . . . . . . . . . . . . . . 83
5.4 Diagramme de séquences détaillé du cas d’utilisation "fusion client automatisée" . . . . 85
5.5 Interface"fusion client automatisée" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.6 Interface"fusion client automatisée" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

ix
5.7 Interface"fusion client automatisée" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.8 Interface"fusion client automatisée" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.9 Interface"fusion client automatisée" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.10 Interface"fusion client automatisée" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.11 Interface"fusion client automatisée" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.12 Interface"fusion client automatisée" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.13 Interface"fusion client automatisée" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.14 Interface"fusion client automatisée" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.15 Diagramme de cas d’utilisation raffiné du Sprint 3.2 "Dashboarding" . . . . . . . . . . 91
5.16 Diagramme de séquence Sprint 3.2 "Dashboarding" . . . . . . . . . . . . . . . . . . . . 92
5.17 Interface"Dashboard" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.18 Interface"Dashboard" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.19 Interface"Dashboard" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

x
Liste des tableaux

1.1 Tableau comparatif entre la méthode Lourde et la méthode Agile . . . . . . . . . . . . 10

1.2 Comparaison entre XP et Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Équipe du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1 Backlog de la Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Dictionnaire de données de la Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Backlog du Sprint 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Description textuelle du cas d’utilisation "S’authentifier" . . . . . . . . . . . . . . . . . 34
3.5 Backlog du Sprint 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6 Description textuelle du cas d’utilisation "Chercher personne ou organisme blacklisté" 44

4.1 Backlog de la Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2 Dictionnaire de données de la Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3 Backlog du Sprint 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4 Description textuelle du cas d’utilisation "Créer fiche Client KYC" . . . . . . . . . . . 56
4.5 Description textuelle du cas d’utilisation "Modifier fiche client" . . . . . . . . . . . . . 57
4.6 Backlog du Sprint 2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.7 Description textuelle du cas d’utilisation "Planifier les tâches de balayage (fréquence)" 63
4.8 Backlog du Sprint 2.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.9 Description textuelle du cas d’utilisation "identifier la classe de risque de client" . . . . 67

5.1 Backlog de la Release 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.2 Dictionnaire de données de la Release 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.3 Backlog du Sprint 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

xi
5.4 Description textuelle du cas d’utilisation "Fusion fiche client automatisée" . . . . . . . 84
5.5 Backlog du Sprint 3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

xii
Liste des abréviations

— API = Application Programming Interface

— CIN = Carte d’Identité Nationale

— DB = DataBase

— ERP = Enterprise Resource Planning

— HTTP = HyperText Transfer Protocol

— KYC = Know Your Customer

— MVC = Model View Controller

— OTP = One-Time Passcode verification

— PPE = Personnes Politiquement Exposées

— REST = REpresentational State Transfer

— RPA = Robotic Process Automation

— UI = User Interface

— US = User Story

xiii
Introduction Générale
Le secteur de l’assurance est en constante évolution, avec des défis croissants en matière
de gestion des risques et de conformité réglementaire. BH Assurance, une filiale de BH GROUP,
se distingue comme un acteur majeur dans ce domaine en Tunisie. Face à l’importance accrue de
l’efficacité opérationnelle et de la précision des analyses, il est devenu impératif d’adopter des technologies
innovantes comme la Robotic Process Automation (RPA) et le Machine Learning.
C’est dans ce contexte que s’inscrit notre projet de fin d’études, réalisé au sein de BH Assurance,
dans lequel nous sommes amenés à moderniser les processus de gestion des clients et de conformité.
L’objectif principal de ce projet est de développer une solution intégrée qui utilise la RPA pour
automatiser la fusion des fiches clients et le Machine Learning pour évaluer les classes de risque KYC
(Know Your Customer). Cette solution vise à optimiser l’efficacité opérationnelle, réduire les erreurs
humaines et améliorer la satisfaction des clients.
Ce rapport résume notre travail et est organisé en cinq chapitres, détaillant les différentes
étapes du projet :
— Le premier chapitre,"Contextualisation du projet", place le projet dans son contexte en
présentant l’organisme d’accueil, BH Assurance, et le projet qui nous a été confié. Nous analysons
également l’existant en matière de fusion client et de vérification KYC, avant de proposer une solution
innovante et la méthodologie de travail adoptée.
— Le deuxième chapitre,"Préparation du projet", est consacré à la phase de spécification des
besoins. Nous y identifions les acteurs impliqués, ainsi que les besoins fonctionnels et non fonctionnels.
Ce chapitre comprend également une analyse globale du projet, l’élaboration du backlog produit, et
la présentation de la conception architecturale et des choix technologiques retenus.
— Le troisième chapitre,"Release 1", détaille les fonctionnalités implémentées et livrées
dans cette première phase du projet, centrée sur la gestion des comptes et la vérification KYC. Nous
y présentons le backlog, l’analyse détaillée, la conception et la réalisation des sprints correspondants.
— Le quatrième chapitre, "Release 2", se concentre sur le développement du modèle de
machine learning pour identifier le classe de risque des clients. Nous y décrivons le backlog du sprint,
l’analyse des données, la sélection des variables, la conception du modèle, son implémentation, et les

1
Introduction Générale

interfaces développées pour visualiser les résultats.

- Le cinquième chapitre, "Release 3", est dédié à l’automatisation de la fusion des fiches
clients via un robot RPA développé avec UiPath Studio. Ce chapitre comprend le backlog du sprint,
l’analyse détaillée, la conception et la réalisation du robot RPA, ainsi que les tableaux de bord
développés pour le suivi des opérations.
Nous clôturerons ce rapport en concluant le travail réalisé et en offrant quelques perspectives
pour l’avenir, visant à enrichir et à améliorer davantage les solutions mises en place.

2
Chapitre 1

Contextualisation du Projet

Introduction

Le but de ce chapitre est de présenter de manière complète le cadre général de mon projet.
Je commence par fournir des informations détaillées sur l’entité d’accueil, "BH Assurance", où j’ai
accompli mon stage de fin d’études. Par la suite, je procède à une analyse approfondie du contexte
actuel, suivie de la proposition d’une solution recommandée, ainsi que de la méthodologie que j’ai
déployée pour atteindre les objectifs fixés au préalable et obtenir les résultats prévus.

1.1 Cadre général du projet

Mon stage a été réalisé au sein de BH Assurance. À l’aube de l’évolution technologique accélérée,
BH Assurance se distingue en mariant l’expertise humaine aux innovations numériques. L’entreprise
opte pour l’automatisation des processus, le remplacement de l’outil KYC, et l’intégration du machine
learning pour évaluer les risques clients. Cette approche avant-gardiste vise à redéfinir la sécurité
et l’efficacité opérationnelle, hissant BH Assurance au rang de leader visionnaire dans l’industrie de
l’assurance grâce à une défense avancée contre le blanchiment d’argent, le financement du terrorisme, et
les fraudes. En libérant les collaborateurs des tâches répétitives, cette synergie permet de se concentrer
sur des missions à forte valeur ajoutée, renforçant ainsi la confiance des clients. C’est dans ce cadre
que se déroule mon projet dont l’objetctif est d’améliorer les processus opérationnels et la gestion des
[Link] projet implique le développement de solutions innovantes, notamment l’automatisation de la
fusion des clients pour optimiser la base de données et le développement d’un outil KYC personnalisé,
adapté à des exigences particulières, et doté d’une intégration avancée du machine learning pour
évaluer le risque des clients. L’ensemble du projet vise à moderniser et optimiser la gestion des clients,
renforçant ainsi la capacité de l’entreprise à prendre des décisions éclairées grâce à l’utilisation de
technologies avancées.

3
Chapitre 1. Contextualisation du Projet

1.2 Présentation de l’organisme d’accueil

Nous commençons par présenter BH GROUP, puis nous passons à la présentation du BH

Assurance.

1.2.1 BH GROUP

Le BH GROUP s’épanouit avec la BH BANK à sa tête, accompagnée de diverses filiales

spécialisées. BH Assurances dans le domaine des assurance, BH IMMO construit des demeures, BH
Leasing facilite les acquisitions, BH Invest navigue sur les marchés boursiers, tandis que d’autres
entreprises du groupe impriment des chèques et gèrent des portefeuilles,etc. Forte de son engagement
envers le développement immobilier tunisien, la BH Bank est le pilier financier du logement dans le
pays, facilitant l’accès à la propriété pour de nombreux Tunisiens. Ensemble, la BH Bank et ses filiales
forment un éventail de services garantissant la prospérité et la solidité du groupe.[1].

1.2.2 BH Assurance

Fondée le 15 septembre 1995 à l’initiative de la Banque de l’Habitat, BH ASSURANCE a vu

le jour en tant que société anonyme spécialisée en assurance vie sous le nom de "SALIM", avec un
capital initial de 1 000 000 [Link] tant que membre intégré du Groupe BH et dans le cadre de
la proposition financière commune, l’entreprise SALIM d’assurances a lancé un projet de rebranding.
Dans le but de maintenir une cohérence et de satisfaire les besoins grandissants du grand public, il y
a eu un changement significatif et Assurances SALIM a été transformée en BH Assurance.
La figure 1.1 illustre l’historique de L’évolution de l’engagement de BH ASSURANCE dans le secteur
de l’assurance.

4
Chapitre 1. Contextualisation du Projet

images/chap1/bh [Link]

Figure 1.1 : Historique de l’évolution de l’engagement de BH ASSURANCE en assurance [2]

Afin d’assurer une satisfaction client constante, BH Assurance poursuit son engagement dans
la transformation numérique tout au long de l’année 2019. Actuellement, elle se prépare à déployer
ses solutions omnicanales, comprenant des sites web et des applications mobiles, pour une intégration
plus étroite dans la vie quotidienne de ses clients. Cette approche vise à maintenir un contact régulier,
à comprendre leurs besoins et à leur proposer des solutions d’assurance personnalisées.

1.3 Étude de l’existant

BH Assurance a positionné son progiciel de gestion d’assurance (GIAS) au cœur de toutes

ses activités. GIAS est un ERP complet, intégrant une large palette d’interfaces pour répondre à
tous les besoins opérationnels de l’entreprise et assure une intégration transparente des processus
métier, favorisant ainsi une gestion cohérente et une prise de décision éclairée à tous les niveaux de
l’organisation.
Au cœur de cet écosystème de gestion se trouve une fonctionnalité essentielle : la Fusion
Clients. Cette fonctionnalité permet au responsable conformité de détecter et de fusionner efficacement

5
Chapitre 1. Contextualisation du Projet

les fiches clients doublons, assurant ainsi l’intégrité et la fiabilité des données clients.
BH Assurance utilise également le logiciel Reis™, une plateforme complète conçue pour prévenir,
détecter et répondre aux risques de non-conformité réglementaire. Cette solution globale intègre
plusieurs composantes essentielles, notamment la connaissance client (Know Your Customer -
KYC),cette fonctionnalité joue un rôle crucial dans la gestion des risques de non-conformité réglementaire
en permettant à l’entreprise de collecter, de vérifier et de mettre à jour les informations relatives à ses
clients de manière rigoureuse et régulière.

1.3.1 La Fusion client

Le logiciel GIAS intègre une fonction de fusion des clients pour traiter les doublons dans la
base de données client, optimisant ainsi la gestion des données en identifiant et consolidant les fiches
client doublons.
Lorsque des doublons sont détectés, que ce soit par une intervention manuelle des agents à la
demande ou automatiquement par le système selon des critères prédéfinis, la fonction de fusion entre
en action. Les agents ont ainsi la possibilité de demander au responsable conformité de fusionner le
doublon. Le responsable conformité examine attentivement les fiches clients en double et décide si la
fusion doit être effectuée ou non.
La fusion des clients est un processus méticuleux qui assure la cohérence et l’intégrité des
données client dans la base de données. Les informations provenant de différentes fiches client sont
fusionnées de manière transparente, éliminant ainsi les redondances et les incohérences. Cette approche
permet aux agents de bénéficier d’une vue d’ensemble unifiée de chaque client, facilitant ainsi une
gestion optimale des relations client.

1.3.2 KYC

Le KYC constitue un élément clé dans la lutte contre le blanchiment d’argent et le financement
du terrorisme, ainsi que dans le maintien de la réputation et de la crédibilité de l’entreprise. Avec l’outil
Reis™, BH Assurance peut mener des vérifications approfondies sur l’identité et les antécédents de
ses clients, garantissant qu’ils se conforment aux réglementations en vigueur.
Dans ce cadre, trois points clés se dégagent concernant la plateforme KYC de BH Assurance :

— Filtrage client et recherche : La plateforme KYC de BH Assurance intègre des fonctionnalités

avancées de filtrage client et de recherche. Elle permet de vérifier les nouveaux clients par rapport
à des listes de sanctions officielles, nationales et internationales et de personnes politiquement
exposées (PPE), assurant ainsi que seuls les clients répondant aux critères de conformité soient
acceptés.

6
Chapitre 1. Contextualisation du Projet

— Fiche KYC et calcul de score de risque :La plateforme KYC de BH Assurance génère des fiches
client détaillées, contenant des informations complètes sur l’identité et les activités du client. De
plus, elle utilise des algorithmes pour calculer un score de risque pour chaque client, basé sur
divers facteurs tels que l’adresse, la profession, le produit, etc.

— Balayage : La plateforme KYC de BH Assurance effectue un balayage régulier de son portefeuille

client vu que les listes de sanctions sont dynamiques .Cela permet de s’assurer que les clients
existants ne sont pas devenus des personnes ou des entités désignées sur les listes de sanctions
ou de PPE, et de prendre les mesures nécessaires en cas de détection de risques potentiels.

1.3.3 Critique de l’existant

Une critique importante du processus de fusion des clients dans le logiciel GIAS réside dans
le niveau élevé d’attention nécessaire pour déterminer quelle fiche client est à garder et laquelle est à
remplacer. Cette exigence d’attention peut conduire à des erreurs humaines et à des résultats incorrects
ou incohérents. De plus, ce processus peut être source de fatigue et de monotonicité, surtout lorsqu’il
implique la gestion de plusieurs fiches clients doublons, entraînant ainsi une perte de temps significative.
Cette fatigue potentielle peut impacter la précision et la qualité de la fusion des clients, mettant ainsi
en péril l’intégrité des données client. Dans la base de données de BH Assurance, il existe environ
11000 fiche client en doublon.
La composante KYC du logiciel Reis™ est critiquée pour ses nombreux problèmes de bugs,
compromettant la capacité de l’entreprise à mener des vérifications précises sur ses clients. La vérification
KYC actuelle du logiciel Reis™ retourne plusieurs résultats avec une très faible précision pour la
détection des personnes sanctionnées LAB-FT (Lutte Anti Blanchiement d’Argent et Financement du
Terrorisme).La génération de plusieurs résultats imprécis par l’outil pousse les utilisateurs à devenir de
plus en plus négligents. D’un autre coté, l’existance de plusieurs Bugs implique l’arrêt de l’aplication
a plusieurs reprises, ce qui empêche la continuité de la vérification KYC pour tous les clients.
Le calcul du score de risque dans le logiciel Reis™ est remis en question en raison de la formule
de calcul utilisée et de son manque de sophistication. L’algorithme utilisé pour générer ce score est
très basique, ne prenant pas en compte un large éventail de facteurs pertinents. Par exemple, le score
de risque est principalement basé sur des critères tels que l’adresse, la nationnalité, la profession, etc.
sans tenir compte de nuances plus subtiles telles que les schémas de comportement inhabituels ou
les relations avec des entités à haut risque. Cette approche peut conduire à des évaluations inexactes
du niveau de risque associé à chaque client, ce qui compromet l’efficacité de la gestion des risques
de l’entreprise et ce qui peut exposer l’entreprise à de lourdes sanctions reglementaires nationales et
internationales.

7
Chapitre 1. Contextualisation du Projet

De même, le balayage des clients présente plusieurs problèmes de performance, ce qui entraîne
des retards dans l’identification des profils à risque. Le processus de balayage est souvent interrompu
en raison de lourdeurs techniques ou de limitations de capacité du système, ce qui empêche une
analyse rapide des données client. Cette inefficacité peut augmenter le risque pour l’entreprise en
retardant la détection des activités suspectes ou des clients à haut risque de conformité, permettant
ainsi à ces risques de passer inaperçus pendant une période prolongée. Au niveau national, le manque
d’alternatives en matière de logiciels KYC crée une dépendance à un fournisseur monopole, limitant
les options de l’entreprise. En revanche, sur le marché international, une variété de solutions plus
avancées sont disponibles, bien que leur coût élevé puisse être prohibitif pour BH Assurance. Cette
disparité crée un déséquilibre dans l’accès aux technologies et place les entreprises nationales dans une
position concurrentielle défavorable. BH Assurance est donc confrontée au dilemme de choisir entre
un logiciel KYC limité localement ou des solutions plus avancées mais très coûteuses.

1.4 Solution proposée

Pour amorcer une révolution dans le processus de fusion des clients, nous projetons d’adopter
une approche avant-gardiste en intégrant la Robotic Process Automation (RPA). La RPA est une
technologie innovante qui permet d’automatiser les tâches répétitives.
Concrètement, en intégrant la RPA dans le processus de fusion des clients, nous envisageons
de mettre en place des robots logiciels capables d’identifier et de fusionner les fiches clients doublons
de manière autonome. Ces robots suivront un flux de travail prédéfini, en identifiant les doublons et
en choisissant quelle fiche est à garder et laquelle est à remplacer, tout comme le feraient les agents
humains, mais de manière plus rapide, continue et précise.
Cette approche vise à optimiser l’efficacité opérationnelle en réduisant les erreurs humaines et
en accélérant le processus de fusion des clients. De plus, elle permettra de décharger les agents de
tâches fastidieuses et répétitives, leur permettant ainsi de se concentrer sur des tâches à plus forte
valeur ajoutée nécessitant leur expertise humaine.
Ainsi,l’intégration de la RPA dans le processus de fusion des clients représente une avancée
significative dans la modernisation des opérations de BH Assurance, lui permettant ainsi de rester à la
pointe de l’innovation technologique tout en améliorant la satisfaction de ses clients et en renforçant
sa compétitivité sur le marché.
Face aux défis croissants en matière de gestion des risques et de conformité réglementaire, BH
Assurance se trouve confrontée à plusieurs problèmes avec la solution KYC existante, et pour répondre
à ces défis, une solution innovante émerge : le développement d’une plateforme KYC personnalisée en

8
Chapitre 1. Contextualisation du Projet

intégrant le Machine Learning. Cette solution sur mesure serait spécifiquement adaptée aux besoins
de BH Assurance, avec des algorithmes d’identification de classe de risque soigneusement étudiés et
des fonctionnalités de balayage programmables. Elle permettrait de minimiser les bugs et d’améliorer
l’efficacité du processus KYC. Cet outil serait capable d’évaluer de manière plus précise le risque associé
à chaque client, en prenant en compte une gamme plus large de facteurs pertinents. La programmation
du balayage permettrait également de lancer automatiquement des analyses selon les besoins, assurant
ainsi une surveillance continue et régulière des profils clients. Un autre aspect crucial à considérer est
l’amélioration de l’algorithme de recherche des personnes sanctionnées dans les listes de sanctions
nationales et internationales. Étant donné que l’efficacité de l’algorithme actuel diminue en termes de
précision, nous envisageons d’adopter un nouvel algorithme axé sur la recherche de similarités parmi
les individus sanctionnés.
La solution proposée comporte aussi une partie Dashboarding qui permettra de suivre en détails
les chiffres des recherches KYC, des vérifications clients, des balayages et la segmentation des risques
des clients.

1.5 Méthodologie de travail

Afin d’assurer le succès de tout projet, il est impératif d’adopter une approche convenable,
permettant une planification et une mise en œuvre efficaces et rentables. Cependant, dans le domaine
de la Business Intelligence, où la variété des projets défie toute prétention à l’universalité des méthodes
de gestion, la sélection de l’approche appropriée nécessite une délicate pondération de multiples
paramètres, incluant la nature du projet, ses caractéristiques, ses contraintes et ses objectifs. La
gestion de projet joue un rôle crucial en coordonnant les intervenants et les tâches pour garantir
le succès global. Il est donc capital d’examiner minutieusement toutes les options disponibles avant
de trancher. Ainsi, avant d’entamer la réalisation de notre projet, nous entreprendrons un examen
approfondi et une évaluation méticuleuse des méthodes de gestion de projet, afin de déterminer celle
qui conviendra le mieux à une conduite optimale du projet.

1.5.1 Étude comparative des méthodologies

Nous procéderons à l’élaboration d’un tableau comparatif exhaustif, mettant en lumière les
divers aspects du cycle de vie, de la planification, de la documentation, de la constitution de l’équipe,
de la qualité, du changement, de la gestion des risques et de la mesure du succès, dans les méthodologies
traditionnelles ("Lourdes") et Agiles. Cette analyse détaillée constituera un outil précieux dans le
processus de sélection de la méthodologie la plus adaptée à notre projet.

9
Chapitre 1. Contextualisation du Projet

Tableau 1.1 : Tableau comparatif entre la méthode Lourde et la méthode Agile

Thème Approche Lourde Approche Agile

en Cascade ou en V, phase
Cycle de vie Itérative et incrémentale
séquentielle

Productive, caractérisée par des

Adaptative avec plusieurs niveaux de
plans plus ou moins détaillés sur la
planification (macro et micro-planification)
Planification base d’un périmètre et d’exigences
avec ajustements nécessaires au fil de l’eau
définies et stables au début du
en fonction des changements survenus.
projet.

Documentation : produite en
Documentation Réduite au strict nécessaire
quantité importante

Une équipe avec des ressources

Une équipe responsabilisée où l’initiative et
Équipe spécialisées, dirigée par un chef de
la communication est privilégiée.
projet

Contrôle de qualité à la fin du cycle Un contrôle qualité précoce et permanent, au

Qualité de développement ;le client découvre niveau du produit et du processus ; le client a
le produit fini. un aperçu régulier de l’avancement.

Changement Non favorable aux changements Favorable aux changements

Gestion des risques intégrée dans le processus

Processus distinct, rigoureux, de global, avec responsabilisation de chacun
Gestion des risques
gestion des risques dans l’identification et la résolution des
risques. Pilotage par les risques.

Planifiez des sessions de revue de sécurité à

Respect des engagements initiaux
des intervalles réguliers tout au long du cycle
Mesure de succès en termes de coûts, de budget et de
de développement agile, par exemple, à la fin
qualité.
de chaque itération ou sprint.

Suite à cette étude comparative entre les méthodologies lourdes et les méthodologies agiles dans
le tableau nous avons opté pour le choix des méthodologies agiles. En effet, la méthodologie agile est
une approche itérative, collaborative et incrémentale capable de prendre en compte les besoins initiaux
du client et ceux liés aux évolutions qui offre une grande capacité d’adaptation aux changements et
aux imprévus. Le but principal d’une méthodologie est de livrer une version fonctionnelle du produit
entre les mains du client aussi vite que possible. Parmi les méthodes d’agile les plus renommées, se

10
Chapitre 1. Contextualisation du Projet

distinguent XP (Extreme Programming) et SCRUM. Ces deux méthodologies ont acquis une renommée
incontestable dans le domaine de la gestion de projet Agile, se positionnant comme des références
indiscutables. Chacune apporte sa propre expertise, ses principes uniques et ses pratiques distinctives,
contribuant ainsi à façonner un environnement propice au développement logiciel efficace et adaptable.

— Principes Agile : La méthode Agile se base sur un cycle de développement qui porte le client
au centre. Le client est impliqué dans la réalisation du début à la fin du projet. Grâce à la
méthode agile le demandeur obtient une meilleure visibilité de la gestion des travaux qu’avec
une méthode classique.

images/chap1/[Link]

Figure 1.2 : Agilité du bout en bout [3]

1.5.2 Étude comparative des méthodologies agile

Dans cette partie, nous commençons par une analyse comparative des méthodologies Agiles
pour bien choisir la méthodologie la plus adaptée parmi celles mentionnées auparavant, Le tableau 1.2
présente une comparaison entre Scrum et XP. On note que la méthodologie XP est adapté aux petits
et moyens projets alors que Scrum peut être adapté aux moyens projets et largement scalable

Critère Scrum XP

Taille du projet Moyen, largement scalable Petit, moyen

Taille de l’équipe <10 et des équipes multiples <10

Style de développement Itératif, rapide Itératif, Rapide

11
Chapitre 1. Contextualisation du Projet

1. Livrables rapides
2. Métaphore
3. Conception simple
1. Équipes Scrum 4. Tests
2. Backlog produit 5. Refactoring
Processus de
3. Sprint 6. Programmation en binôme
développement
4. Rétrospective Sprint 7. Propriété collective
8. Intégration continue
9. Client sur site
10. Standards de codage

1. Scrum master
Processus de gestion du 2. Réunion de planification de Jeux de planification
projet Sprints
3. La mêlée quotidienne

Tableau 1.2 : Comparaison entre XP et Scrum

1.5.3 Méthodologie retenue

Nous avons adopté la méthode SCRUM agile pour la gestion de notre projet. Cette approche
itérative et flexible, largement utilisée et reconnue pour son efficacité, s’appuie sur des cycles de
développement courts appelés "Sprints". Grâce à cette méthodologie, nous produisons rapidement des
résultats tangibles, maximisant ainsi la valeur métier à long terme

• La continuité des itérations dans SCRUM assure un rythme régulier de livraison de fonctionnalités
opérationnelles, permettant au client de suivre étroitement l’avancement du projet et de fournir
un feedback régulier.

• La flexibilité et la réactivité de Scrum permettent de s’adapter efficacement aux changements

et aux évolutions des besoins du projet, grâce à ses itérations courtes et ses mécanismes de
planification ajustables.

• SCRUM favorise une collaboration étroite entre les membres de l’équipe, en encourageant les
échanges réguliers et la communication transparente, créant ainsi un environnement de travail
dynamique et stimulant

• Cette méthodologie combine aspects théoriques et pratiques, offrant une approche réaliste et
pragmatique du développement de logiciels, ce qui en fait un choix idéal pour notre projet.

12
Chapitre 1. Contextualisation du Projet

• Enfin, SCRUM établit des objectifs clairs et réalisables pour chaque période définie, permettant
à l’équipe de rester focalisée sur les priorités du projet et d’atteindre des résultats concrets à
chaque itération. .

Le tableau 1.2 présente l’organisation de l’équipe Scrum.

Rôle Mission Acteur

occupe le rôle de gestionnaire

Product Owner du carnet de produit. Il détient [Link] Ben Mahmoud
l’autorité pour accepter ou rejeter
le travail présenté .

C’est l’intervenant qui assure

Scrum Master l’animation de l’équipe et s’assure Mr. Mohamed Ismail Maiza
du bon avancement du projet et la
bonne application de Scrum.

C’est l’équipe responsable de Jmal Mohamed Ali

Scrum Team l’aspect développement.

Tableau 1.3 : Équipe du projet

La vie d’un projet Scrum est rythmée par un ensemble de réunions clairement définies et
strictement limitées dans le temps :

• Planification du Sprint : Au cours de cette réunion, l’équipe de développement sélectionne

les éléments prioritaires du "Product Backlog" qu’elle pense pouvoir réaliser au cours du sprint,
en accord avec le "Product Owner".

• Revue de Sprint : Au cours de cette réunion qui a lieu à la fin du sprint, l’équipe de
développement présente les fonctionnalités terminées au cours du sprint et recueille les feedbacks
du Product Owner. C’est également en ce moment que le périmètre des prochains sprints est
anticipé.

• Rétrospective de Sprint : La rétrospective qui a lieu, généralement, après la revue de sprint est
l’occasion d’améliorer la productivité, la qualité, et l’efficacité de projet, d’ajuster les conditions
de travail, à la lueur du "vécu" sur le sprint écoulé.

• Mêlée quotidienne : il s’agit d’une réunion de synchronisation de l’équipe de développement

"stand up meeting" qui se fait en 15 minutes maximum au cours de laquelle chacun répond
principalement à des questions :"Qu’est-ce que j’ai terminé depuis la dernière mêlée ? Qu’est-ce
que j’aurai terminé d’ici à la prochaine mêlée ? Quels obstacles me retardent ?"

13
Chapitre 1. Contextualisation du Projet

Pour bien illustrer le cycle de vie de chaque projet scrum, la figure 1.3 représente bien les
différentes étapes évoquées.

images/chap1/[Link]

Figure 1.3 : La méthode Agile Scrum [4]

Conclusion

Ce premier chapitre constitue une étape primordiale pour fixer les notions de bases de notre
projet. Après avoir présenté la société hôte et avoir identifié ses attentes du projet, nous avons
déterminé le contexte général de notre travail ainsi que la méthodologie de projet à suivre. Le chapitre
suivant est consacré à la préparation du projet à réaliser.

14
Chapitre 2

Préparation du Projet

Introduction

Dans ce deuxième chapitre et après avoir établi le cadre global de notre projet, nous entamons
maintenant la première étape de notre méthodologie, baptisée "Sprint 0". Dans cette phase, nous
nous concentrerons sur la planification et la conception de l’architecture de la solutionque nous
[Link] d’abord, nous procéderons à une analyse détaillée des besoins, accompagnée de la
création du diagramme de cas d’utilisation global, du diagramme de classe global et du backlog du
produit. Ensuite, nous répartirons ces besoins en sprints, établissant ainsi un planning prévisionnel.
Enfin, nous finaliserons la spécification de l’architecture pour guider notre développement ultérieur.

2.1 Spécification des besoins

Nous allons identifier dans cette partie les acteurs et leurs rôles. Ensuite, nous allons délimiter
les besoins fonctionnels et non fonctionnels.

2.1.1 Identification des acteurs

Avant de plonger dans les détails du projet, il est primordial d’identifier les intervenants clés qui
façonnent chaque aspect de notre solution. Ces acteurs occupent des rôles spécifiques et interagissent
activement avec les diverses composantes du système pour garantir son efficacité et sa pérennité.Ces
acteurs sont les suivants :

• Agent : un agent est un utilisateur du système qui a des privilèges limités. Les agents peuvent
effectuer des tâches opérationnelles telles que la recherche et la consultation des fiches clients, la
création de fiches clients KYC, le téléchargement et le stockage des documents KYC, et d’autres
actions spécifiques à leur rôle au sein de l’organisation.

15
Chapitre 2. Préparation du Projet

• Agent de conformité : un agent de conformité est un utilisateur du système ayant des

privilèges spécifiques pour garantir que l’entreprise respecte les réglementations et les normes en
vigueur. son rôle principal consiste à vérifier la conformité des clients, à gérer les fiches client
KYC (Know Your Customer), à effectuer des vérifications de conformité et à traiter les alertes
de conformité.

• Administrateur : l’administrateur a un accès complet au système et la capacité de configurer

et de gérer tous les aspects de la plateforme. Il est responsable de la création et de la gestion des
comptes utilisateurs, de la définition des autorisations et des rôles, de la planification des tâches
de balayage, de la configuration des règles de filtrage. L’administrateur a également le pouvoir
de modifier les paramètres du système, y compris la formule de calcul du score de risque client.

2.1.2 Besoins fonctionnels

Les besoins fonctionnels représentent le comportement du système ainsi que les services offerts
aux différents intervenants. Notre application doit obligatoirement répondre aux fonctionnalités suivantes :

• Gérer l’authentification : L’utlisateur peut s’authentifier via un nom d’utilisateur et un

mot de passe,modifier son mot de passe. L’administrateur peut créer des comptes,modifier les
utilisateurs,affecter les autorisations et désactiver les comptes.

• Gestion client : L’utilisateur peut consulter la liste des clients,rechercher un client,consulter

et exporter une fiche client.

• Vérification KYC : L’agent peut filtrer et valider les correspondances, créer et modifier les
fiches client KYC, ainsi que télécharger et stocker les documents des fiches KYC. L’agent de
conformité peut fusionner les fiches client, accepter ou rejeter les clients, et consulter la matrice
de risque client. L’administrateur peut gérer la configuration du système, y compris les résultats
d’affichage et les règles de filtrage, et avoir accès à l’historique des utilisations du filtrage.

• Identification du classe de risque : L’utilisateur peut visualiser le classe de risque des

clients.L’administrateur peut paramétrer ou modifier la formule de calcul du score de risque.

• Gestion balayage : L’utilisateur peut programmer ou lancer un balayge KYC spécifique sur
la liste des clients.

• Fusion client automatisée : L’utilisateur peut lancer un robot pour effectuer la fusion des
fiches clients en doublons.

• Dashboarding : L’utilisateur peut visualiser les clients par région, par spécialité, par note ou
via son historique avec les donneurs de services, etc.

16
Chapitre 2. Préparation du Projet

2.1.3 Besoins non fonctionnels

Les exigences du système ne sont pas nécessaires à son bon fonctionnement, mais qui ont un
impact indirect sur les résultats. Ainsi, ces éléments ne doivent pas être sous-estimés. De cette manière,
notre système doit se conformer aux critères suivants :

• Ergonomie de l’application : Les interfaces de l’application doivent être conçues de manière

simple et en accord avec la charte graphique préétablie par l’entreprise hôte.

• Scalabilité : La capacité à maintenir des performances constantes même en cas d’augmentation

de la charge de travail est une compétence essentielle.

• Performance : Les applications déployées sur notre plateforme de développement doivent

s’exécuter avec des temps de réponse minimaux.

• Sécurité : Les données sont protégées pour garantir leur sécurité, avec des mesures telles que
le chiffrement des informations sensibles et la prévention des accès non autorisés.

• Maintenabilité : La facilité avec laquelle le système peut être maintenu et mis à jour afin
d’assurer sa durabilité et son évolutivité.

2.2 Analyse globale

Dans cette partie, nous structurons les fonctionnalités du système dans un diagramme de cas
d’utilisation global, permettant de donner une vision globale du comportement fonctionnel de notre
système.

2.2.1 Diagramme de cas d’utilisation global

Nous utilisons les diagrammes de cas d’utilisation dans le but de donner une vision globale du
comportement d’un système logiciel.
La figure 2.1 illustre le diagramme de cas d’utilisation global.

17
Chapitre 2. Préparation du Projet

images/annexe/[Link]

Figure 2.1 : Diagramme de cas d’utilisation global

2.3 Backlog du produit

Dans cette section, nous exposons le backlog du produit ainsi que la répartition de ses releases
et de ses sprints.

18
Chapitre 2. Préparation du Projet

2.3.1 Élaboration Du Backlog Produit

Le backlog produit représente l’élément central de Scrum, rassemblant toutes les fonctionnalités
ou aspects techniques définissant le produit final désiré. Les fonctionnalités spécifiques sont souvent
désignées sous le terme de "user stories". Dans le cadre de notre application, le backlog produit est
présenté dans le tableau 2.1. Cependant, il est pertinent de souligner que :

Un utilisateur connecté désigne un agent, un agent de conformité ou un administrateur.

Un utilisateur désigne tous les acteurs de l’application.

Estim-
Fonction-
ID User Story Priorité ation
nalités
(Heures)
US1 En tant que utlisateur, je souhaite me connecter Haute 6
Gestion des US2 En tant que utilisateur connecté je souhaite me déconnecter Haute 4
comptes US3 En tant que utilisateur connecté ,je souhaite modifier mon mot de passe Haute 6
US4 En tant que administrateur, je souhaite créer des comptes Haute 12
US5 En tant que administrateur, je souhaite affecter les autorisations (role) Haute 8
US6 En tant que administrateur, je souhaite modifier les utilisateurs Moyenne 6
US7 En tant que utilisateur, je souhaite chercher une personne si blacklisté Haute 16
US8 En tant qu’agent, je souhaite pouvoir valider ou ignorer une correspondance Haute 12
trouvée en examinant les informations supplémentaires sur le client
Vérification US09 En tant qu’agent de conformité, je souhaite accepter ou rejeter client Haute 10
KYC US10 En tant que utilisateur connecté, je souhaite consulter le rapport de filtrage Basse 12
US11 En tant que agent de conformité connecté, je souhaite imprimer le rapport de Basse 4
filtrage
US2 En tant que administrateur , je souhaite ajouter des règles de filtrage Basse 48
US13 En tant que administrateur , je souhaite modifier des règles de filtrage Basse 16
US14 En tant que administrateur , je souhaite activer et désactiver des règles de Haute 8
filtrage
US15 En tant que utilisateur connecté , je souhaite consulter la liste des clients Haute 8
Gestion client US16 En tant que utilisateur connecté , je souhaite rechercher un client Haute 8
US17 En tant que utilisateur connecté , je souhaite exporter une fiche client Haute 8
US18 en tant que utilisateur connecté , je souhaite consulter la fiche client Moyenne 6
US19 En tant qu’agent, je souhaite créer fiche client KYC Haute 10
US20 En tant qu’agent de conformité, je souhaite modifier fiche client KYC Haute 8
US21 En tant qu’agent de conformité, je souhaite visualiser la classe de risque de Haute 6
client
US22 En tant que administrateur , je souhaite planifier les taches de balayage Haute 14
Gestion
(frequence)
balayage
US23 En tant que administrateur , je souhaite lancer le balayage manuellement via Haute 28
l’interface
US24 En tant que administrateur, je souhaite consulter le rapport de balayage Haute 8
US25 En tant que agent de conformité , je souhaite consulter le rapport de balayage Moyenne 6
Identification US26 En tant que utilisateur connecté je souhaite visualiser la classe de risque d’un Haute 56
du score de client
risque

19
Chapitre 2. Préparation du Projet

US27 En tant que administrateur je souhaite visualiser l’analyse de classe de risque Baisse 24
de client
Fusion client US28 En tant que agent de conformité , je souhaite lancer un robot pour effectuer Haute 40
automatisée la fusion des fiches clients en doublons
US29 En tant que utilisateur connecté , je souhaite visualiser les clients par région, Haute 24
Dashboarding par spécialité, par note ou via son historique avec les donneurs de services,
etc.

Tableau 2.1 : Backlog du produit

2.3.2 Répartition du Backlog Produit

Après avoir réalisé notre Backlog du produit, nous avons organisé une réunion de planification
avec l’équipe Scrum et nous avons divisé le travail en des releases et ce comme suit :

images/chap2/GÃľrer les [Link]

Figure 2.2 : Découpage des releases

2.4 Conception architecturale

Afin d’optimiser le développement d’une application, il est primordial de déterminer avec

précision sa structure globale et la répartition de ses éléments. Dans ce contexte, nous allons établir à
la fois l’architecture physique de l’application et l’architecture logique de notre système.

2.4.1 Architecture physique de l’application

Pour concevoir notre application,nous avons choisi l’architecture à trois-niveaux (3-tiers) pour
la réalisation de notre [Link] architecture est constituée de trois éléments principaux,
comme le montre la figure ci-dessous :

• Le client : C’est l’utilisateur final qui sollicite des ressources ou des services.

20
Chapitre 2. Préparation du Projet

• Le serveur d’applications (middleware) : Chargé de fournir les ressources nécessaires au

client, mais il peut également solliciter un autre serveur pour obtenir ces ressources.

• Le serveur secondaire (habituellement un serveur de base de données) : ce serveur

offre des services au serveur d’applications, en stockant souvent les informations requises pour
satisfaire les besoins des clients.

images/chap2/[Link]

Figure 2.3 : Architecture 3-tiers [5]

Ce choix d’architecture est justifié par les raisons suivantes :

• Flexibilité et adaptabilité : Cette architecture offre une flexibilité exceptionnelle pour l’intégration
de nouvelles technologies, ce qui facilite grandement le processus de développement et d’amélioration
continue de l’application.

• Renforcement de la sécurité : Dans une architecture à trois niveaux, l’accès à la base

de données se fait exclusivement par le biais du serveur applicatif. Ce dernier détient seul les
informations nécessaires pour se connecter à la base de données, préservant ainsi la confidentialité
des informations d’accès. La gestion des utilisateurs, de leurs mots de passe et de leurs autorisations
d’accès se fait au niveau du serveur applicatif, renforçant ainsi la sécurité du système.

• Optimisation des performances : La répartition des tâches entre les différents serveurs dans
cette architecture garantit des performances globales optimales, améliorant ainsi l’expérience
utilisateur et l’efficacité opérationnelle.

• Simplification du déploiement et de l’administration : L’architecture à trois niveaux

simplifie considérablement le déploiement de l’application. Seule la partie serveur (serveur applicatif
et serveur de base de données) nécessite un déploiement, tandis que le client demande une
installation minimale. En effet, un simple navigateur web compatible suffit pour accéder à
l’application, ce qui réduit les coûts de déploiement et facilite les mises à jour régulières du
système.[3-tiers]

21
Chapitre 2. Préparation du Projet

images/chap2/[Link]

Figure 2.4 : Architecture trois tiers [6]

L’architecture à trois niveaux, comme illustré dans la figure 2.4, vise à diviser une application en trois
couches logicielles distinctes. Elle permet de modéliser et de présenter cette application comme un
empilement de trois couches, chacune ayant un rôle clairement défini :

• Présentation des données : Cette couche correspond à l’interface utilisateur, incluant l’affichage
des données, leur restitution sur le poste de travail et le dialogue avec l’utilisateur.

• Traitement métier des données : Cette couche implémente l’ensemble des règles de gestion
et de la logique applicative de l’application.

• Accès aux données persistantes : Cette couche gère l’accès et la manipulation des données
qui sont destinées à être conservées sur le long terme, voire de manière permanente, comme dans
une base de données.

[Link] Modélisation de l’architecture physique

Afin de visualiser le déploiement de notre application, nous avons employé un diagramme

de déploiement comme illustré dans la figure2.5, qui présente la configuration physique des divers
équipements (ou nœuds) et la répartition des composants au sein de ces nœuds :

22
Chapitre 2. Préparation du Projet

images/chap2/[Link]

Figure 2.5 : Diagramme de déploiement du système

La conception de notre diagramme de déploiement comprend trois principaux nœuds :

• Le poste client : qui se compose d’un navigateur web servant d’outil de communication entre
les utilisateurs de notre système et les autres nœuds. Les utilisateurs lancent leurs demandes
sous forme de requêtes HTTP et reçoivent des réponses HTTP [7] en retour.

• Le serveur web : qui comprend deux composants :

— La couche de présentation, rassemblant l’ensemble des formulaires et interfaces à transmettre

au navigateur par flux HTTP suite à une demande de l’utilisateur.

— L’interface de la base de données, qui assure la liaison entre notre application et la base de
données.

• Le serveur de base de données : qui abrite la base de données de notre application.

2.4.2 Architecture logique

Pour élaborer l’architecture logique de notre système, nous choisissons l’architecture MVC
(Model-View-Controller) :
ce modèle MVC est un patron de conception largement utilisé dans le développement de sites web. Il
offre une approche bien établie pour séparer clairement les différentes responsabilités d’une application,
notamment l’affichage des informations, les interactions utilisateur et l’accès aux données.[mvc] La
figure 2.6 représente l’architecture MVC

23
Chapitre 2. Préparation du Projet

images/chap2/[Link]

Figure 2.6 : Architecture MVC [8]

Cette méthode implique la distinction de trois entités distinctes : le modèle, la vue et le

contrôleur, chacun ayant un rôle spécifique dans l’interface. La conception globale d’une interface
graphique peut être [Link] l’architecture MVC, les rôles des trois entités sont définis comme
suit :

• Modèle (Model) : encapsule la logique métier essentielle. Cette composante est chargée de définir
les classes et les méthodes responsables de la manipulation des données, des calculs et de la
logique métier. En général, les entités et les services sont inclus dans cette section pour gérer les
opérations liées à la base de données.

• Vue (View) : interface utilisateur (entrées et sorties) En général, la couche de présentation du

frontend est associée à la vue, tandis que le backend présente des interfaces de programmation
d’application (API) comme des points d’accès REST pour interagir avec le frontend. Dans le
modèle MVC, il est également possible d’inclure des modèles de données qui sont envoyés au
frontend.

• contrôleur(Controller) : gestion des événements et synchronisation Le contrôleur est un élément

responsable de la prise de décisions et de la gestion de la logique du code liée à ces décisions. Il
joue le rôle d’intermédiaire entre le modèle et la vue dans l’architecture MVC.

Nous avons choisi l’architecture MVC pour les raisons suivantes :

— Structuration claire : MVC divise l’application en trois parties distinctes - le modèle, la vue et
le contrôleur - rendant ainsi la structure plus facile à comprendre et à gérer.

— Facilité de maintenance : La séparation des différents aspects de l’application facilite les opérations
de maintenance en permettant des modifications sans perturber le reste de l’application.

24
Chapitre 2. Préparation du Projet

— Flexibilité : MVC permet d’ajouter de nouvelles fonctionnalités ou de modifier l’interface utilisateur

sans perturber le fonctionnement global de l’application, offrant ainsi une adaptabilité accrue.

— Réutilisabilité : La modularité de MVC favorise la réutilisabilité du code, réduisant ainsi la

duplication et facilitant la maintenance à long terme de l’application.

— Séparation des responsabilités : Chaque composant de MVC a un rôle bien défini, simplifiant le
développement, le débogage et la répartition des tâches au sein de l’équipe.

2.5 Choix et exigences technologiques

Cette partie sert à présenter les différents environnements matériels et logiciels ainsi que les
outils de développements et de contrôle à utiliser afin de bien accomplir notre travail.

2.5.1 Environnement matériel

Pour la réalisation de notre application, nous avons utilisé un PC portable doté de la configuration
définie dans le tableau 2.2.

Machine PC portable Lenevo ideapad GAMING

Processeur Intel Core i5 11eme génération

Mémoire Vive 32 Go

Disque Dur 512 Go SSD

SE 64 bits, processeur x64

Tableau 2.2 : Environnement matériel

2.5.2 Environnement logiciel

Leslogiciels utilisés pour la réalisation du projet et qui sont listés dans le tableau 2.3.

Application Logo Description

Angular est un framework de développement conçu

spécifiquement pour élaborer des applications web
images/chap2/[Link]
Angular 17 dynamiques. Son utilisation a été adoptée pour la création
de l’interface utilisateur de l’application, assurant ainsi une
expérience utilisateur fluide et interactive. [9]

25
Chapitre 2. Préparation du Projet

Flask est un framework de développement web open-source

basé sur Python. Il est considéré comme un microframework
Flask images/chap2/[Link]
en raison de sa légèreté. Le but de Flask est de maintenir un
noyau simple mais flexible. [flask]

Microsoft SQL Server est un logiciel de gestion de base de

Microsoft
images/chap2/[Link]
données en langage SQL qui intègre notamment un SGBDR
SQL Server
développé et commercialisé par Microsoft. [sqlserver]

Keycloak est un logiciel open source qui permet de mettre en

place une méthode d’authentification unique en utilisant la
Keycloak images/chap2/[Link]
gestion par identité et par accè[Link] se présente comme
une application qui permet de sécuriser n’importe quelle
application web moderne en utilisant un code minimal.[10]

Docker est une plateforme développée en 2013 qui offre

Docker images/chap2/[Link]
la possibilité de lancer certaines applications dans des
conteneurs logiciels. [docker]

Jenkins est un logiciel libre pour automatiser les serveurs. Il

images/chap2/[Link]
permet d’automatiser les étapes du développement logiciel
Jenkins
telles que la création, les tests et le déploiement, et simplifie
l’intégration continue et la livraison continue.[jenkins]

Microsoft Visual Studio Code est un éditeur de code

Visual extensible. Sa compatibilité avec une multitude de langages
images/chap2/[Link]
Studio de programmation ainsi que ses extensions diversifiées
Code facilitent grandement les tâches de codage, de débogage et
de gestion du code source.[11].

Postman teste les API en simulant les requêtes client et

images/chap2/[Link]
Postman en analysant les réponses pour garantir leur fiabilité avant
intégration.[12].

26
Chapitre 2. Préparation du Projet

GitHub est une infrastructure cloud de développement

logiciel qui propose un espace centralisé pour le stockage,
images/chap2/[Link]
la gestion et la collaboration de projets de code source. Il
GitHub
simplifie le processus de suivi des modifications, encourage
la collaboration entre les développeurs et facilite la gestion
des contributions.[13].

Le logiciel Jira est un outil de gestion de projet agile qui peut

être utilisé avec toutes les méthodes agiles, y compris Scrum.
images/chap2/[Link]
Jira Il offre la possibilité de prévoir, surveiller et superviser tous
les projets de développement logiciel agile à partir d’un
unique outil. [14].

UiPath Studio est un logiciel spécialisé dans

l’automatisation des processus métier. Il offre une interface
UI PATH images/chap2/[Link]
conviviale permettant de concevoir et de déployer des
STUDIO
robots logiciels capables de reproduire des tâches répétitives
dans diverses applications informatiques. [uiath].

Tableau 2.3 : Environnement logiciel

Conclusion

Ce chapitre a été dédié à la reconnaissance des parties prenantes de notre système et à

la définition précise de ses exigences, qu’elles soient fonctionnelles ou [Link] avons également
structuré les fonctionnalités dans un diagramme global d’utilisation et énuméré les éléments du backlog
[Link], nous avons présenté l’architecture de conception et les choix technologiques adoptés
pour ce projet. Dans le prochain chapitre, nous débuterons notre première release.

27
Chapitre 3

Release 1

Introduction

Après avoir structuré les releases dans le chapitre antérieur, nous amorçons désormais la
première release , détaillant les sprints qui y sont associés. Nous plongerons ensuite dans l’analyse
et la conception élaborée pour chaque sprint, en mettant en lumière les interfaces de réalisation.

3.1 Backlog de la Release 1

La première release est composée de deux sprints, Comme indiqué dans le tableau. 3.1

Nom du Sprint Numéro du Sprint

Gestion des comptes Sprint 1

Vérification KYC Sprint 2

Tableau 3.1 : Backlog de la Release 1

3.2 Analyse globale de la Release 1

Dans cette section, nous allons exposer le diagramme de cas d’utilisation global de la release
1, tel que illustré dans la figure. 3.1

28
Chapitre 3. Release 1

images/chap3/Sprint1/[Link]

Figure 3.1 : Diagramme de cas d’utilisation global de la release 1

3.3 Conception globale de la Release 1

Dans cette section, nous allons introduire le diagramme global de classes de la Release 1, illustré
dans la figure 3.2 suivante.

29
Chapitre 3. Release 1

images/chap3/[Link]

Figure 3.2 : Diagramme de classes global de la release 1

30
Chapitre 3. Release 1

Le tableau suivant 3.2 décrit les différents attributs de chaque classe de cette release :

Classes Attributs Type Description

id entier désigne l’identifiant de l’utilisateur

keycloak texte désigne l’identifiant keycloak de l’utilisateur
username texte désigne le nom d’utilisateur
password texte désigne le mot de passe (cripté) de l’utilisateur
User
email texte désigne l’adresse email de l’utilisateur
name texte désigne le nom complet de l’utilisateur
verified booléen désigne l’état de vérification du compte
OTP entier désigne le code otp (One Time Password)

id entier désigne l’identifiant du rôle

Role
name texte désigne le nom du rôle

id entier désigne l’identifiant de la personne

First name texte désigne le prénom de personne
Last name texte désigne le nom de personne
Date of birth texte désigne la date de naissance
Birthplace entier désigne le lieu de naissance
Person
Address réel désigne l’adresse
Nationality réel désigne la nationalité
Justification for insertion réel désigne Justification d’insertion de personne
Registration date réel désigne la Date d’inscription de personne
Last modification réel désigne la derniére modification
Cin réel désigne la carte d’identité nationale

idCorrespondance entier désigne l’identifiant de correspondance

Correspondence
details texte désigne les détails de correspondance

id entier désigne l’identifiant de rapport

ReportFiltering
content texte désigne le contenu du rapport de filtrage.

id entier Identifiant unique de la règle de filtrage.

RuleFilter
state texte désigne l’état de la règle de filtrage (activée ou
désactivée).

id entier désigne l’identifiant du statut

state
label texte désigne le libellé du statut

Tableau 3.2 : Dictionnaire de données de la Release 1

31
Chapitre 3. Release 1

3.4 Sprint 1.1 : Gestion des comptes

Après avoir mené une analyse et une conception globale de la première release, nous amorçons
le premier sprint. Au cours de celui-ci, nous débuterons en exposant le backlog du sprint, déterminant
ainsi les tâches à entreprendre après notre réunion avec le Product Owner. Ensuite, nous aborderons
les diagrammes de conception, avant de présenter quelques interfaces élaborées lors du sprint 1.1.

3.4.1 Backlog du Sprint 1.1

Après avoir analysé le backlog du produit et le backlog de la Release 1, nous avons identifié les
tâches que nous allons effectuer tout au long de ce sprint. Toutes les tâches indiquées dans le tableau
3.3 doivent être effectuées à la fin de cette étape. Il est à noter que :

— Un utilisateur connecté désigne un agent, un agent de conformité ou un administrateur.

Estim-
ID ID
Fonctionnalité User Story Tâche ation
US Tâche
(heure)

1.1 Implémenter la logique de connexion côté

En tant que utlisateur, je souhaite 6
US1 serveur (contrôleur) avec Keycloak
me connecter
1.3 Implémentation de la vue côté web
En tant que utilisateur connecté je 2.1 Mettre en place la déconnexion côté
US2 4
souhaite me déconnecter serveur (contrôleur) avec Keycloak
2.2 Implémentation de la vue côté web
En tant que utilisateur connecté 3.1 Mettre en place la logique de modification
Gestion des 6
US3 ,je souhaite modifier mon mot de du mot de passe côté serveur avec Keycloak
comptes
passe (contrôleur)
3.2 Implémentation de la vue côté web
4.1 Développer la fonctionnalité de création
En tant que administrateur, je 12
US4 de comptes côté serveur avec Keycloak
souhaite créer des comptes
(contrôleur)
4.2 Implémentation de la vue côté web
En tant que administrateur, je 5.1 Implémenter la gestion des rôles côté
8
US5 souhaite affecter les autorisations serveur avec Keycloak (contrôleur)
(role) 5.2 Implémentation de la vue côté web
6.1 Développer la fonctionnalité de
En tant que administrateur, je 6
US6 modification d’utilisateurs côté serveur
souhaite modifier les utilisateurs
avec Keycloak (contrôleur)
6.2 Implémentation de la vue côté mobile

Tableau 3.3 : Backlog du Sprint 1.1

32
Chapitre 3. Release 1

3.4.2 Analyse détaillée du Sprint 1.1

Au cours de cette partie, nous allons d’abord exposer le diagramme de cas d’utilisation raffiné
du sprint 1.1. Par la suite, nous expliquerons en détail la fonctionnalité que nous avons été demandées
de mettre en place tout au long de ce sprint.

[Link] Diagramme de cas d’utilisation raffiné du sprint 1.1

Le diagramme de cas d’utilisation raffiné du sprint 1.1 est illustré dans la figure 3.3.

images/chap3/Sprint1/[Link]

Figure 3.3 : Diagramme de cas d’utilisation raffiné du sprint 1.1

33
Chapitre 3. Release 1

[Link] Description textuelle

À travers le tableau 3.4 nous présentons la description textuelle du cas d’utilisation "S’authentifier".

Cas d’utilisation S’authentifier

Acteur Agent,Agent de Conformité,Administrateur

Pré-conditions L’acteur doit être existant dans la base de données

Post-conditions L’acteur authentifié avec accès à l’interface d’accueil

1-L’acteur consulte l’interface d’authentification

2- L’acteur remplit le formulaire d’authentification avec les informations
convenables.
Scénario nominal
3- Le système vérifie les données envoyées
4- L’acteur doit scanner le qr code avec une application d’authentification dans
son téléphone
5- L’acteur doit entrer le code OTP fournie par l’application aprés le scan
6- L’acteur est redirigé vers une interface d’accueil

1- Le mot de passe ou l’émail saisis sont invalides : un message d’erreur s’affiche

Scénario alternatif
pour notifier l’utilisateur
2- L’utilisateur n’existe pas : un message d’erreur s’affiche pour le notifier

Tableau 3.4 : Description textuelle du cas d’utilisation "S’authentifier"

3.4.3 Conception du Sprint 1.1

Nous passons maintenant à la conception de ce sprint. Afin d’accomplir cela, nous exposons
d’une part le diagramme des classes de conception et d’autre part, une perspective dynamique avec le
diagramme des séquences.

[Link] Diagramme de classes de conception du sprint

Au cours de cette section, nous allons exposer le diagramme de classes de conception du sprint
1.1, tel que illustré dans la figure 3.4.

34
Chapitre 3. Release 1

images/chap3/Sprint1/[Link]

Figure 3.4 : Diagramme de classes de conception du sprint 1.1

[Link] Diagrammes de séquences détaillés

La figure 3.11 représente le diagramme de séquences détaillé du cas d’utilisation "S’authentifier".

images/chap3/Sprint1/[Link]

Figure 3.5 : Diagramme de séquences détaillé du cas d’utilisation "S’authentifier"

35
Chapitre 3. Release 1

3.4.4 Réalisation du Sprint 1.1

Nous allons exposer dans cette section quelques interfaces créées à partir du Sprint 1.1.

images/captures/[Link]

Figure 3.6 : Interface de "Login"

images/captures/[Link]

Figure 3.7 : Interface de "Scanner QR code et OTP "

images/captures/[Link]

Figure 3.8 : Interface de "creation utilsateur"

images/captures/[Link]

Figure 3.9 : Interface de "assigner role"

36
Chapitre 3. Release 1

images/captures/[Link]

Figure 3.10 : Interface de "asssigner un role"

images/captures/[Link]

Figure 3.11 : Interface de "Modifer Mot de passe"

3.5 Sprint 1.2 : Vérification KYC

Comme dans le sprint précédent et en se basant sur le même principe, nous allons commencer
par présenter le Backlog du sprint. Par la suite, nous allons exposer les diagrammes de conception et
enfin nous allons présenter quelques interfaces réalisées du sprint 1.2.

3.5.1 Backlog du Sprint 1.2

À la fin du sprint, toutes les tâches mentionnées dans le tableau 3.5 de backlog du sprint 1.2
oivent être livrées au client.
Notons qu’un utilisateur connecté désigne un agent,agent de conformité ou administrateur
.

Estim-
ID ID
Fonctionnalités User Story Tâche ation
US Tâche
(Heures)
7.1 Créer une interface de recherche permettant
En tant que utilisateur, je souhaite à l’utilisateur de saisir un formulaire de
16
US7 vérifier si une personne est blacklisté recherche.
à travers un algorithme de similarité. 7.2 Intégrer la fonctionnalité de recherche avec
Angular pour interagir avec le backend .
7.3 Mettre en place une API Flask pour gérer
Vérification la recherche des personnes ou d’organismes
KYC blacklistés avec la conception de l’algorithme
de similarité.

37
Chapitre 3. Release 1

7.4 Implémenter la logique de recherche basée sur

l’algorithme de distance de Levenshtein pour
calculer la similarité en utilisant les données
stockées dans la base de données
8.1 Créer une interface pour afficher les
En tant qu’agent, je souhaite pouvoir correspondances trouvées. 12
valider ou ignorer une correspondance 8.2 Ajouter des options de validation ou
US8
trouvée en examinant les informations d’ignorance pour chaque correspondance.
supplémentaires sur le client 8.3 Mettre en place une API Flask pour gérer la
validation ou l’ignorance des correspondances.
8.4 Implémenter la logique de validation ou
d’ignorance en utilisant les données fournies
par l’interface utilisateur.
9.1 Ajouter une interface pour permettre à l’agent
En tant que agent de conformité, je 10
US9 de conformité de visualiser les clients soumis à
souhaite accepter ou rejeter client
vérification KYC.
9.2 Intégrer des options d’acceptation ou de rejet
pour chaque client.
9.3 Mettre en place une API Flask pour gérer
l’acceptation ou le rejet des clients soumis à
vérification KYC
9.4 Implémenter la logique d’acceptation ou de
rejet en utilisant les données fournies par
l’interface utilisateur.
En tant que utilisateur connecté, je 10.1 Créer une interface pour permettre à 12
souhaite consulter le rapport de l’utilisateur connecté de consulter le rapport
US10
filtrage de filtrage généré.
10.2 Mettre en place une API Flask pour récupérer
et fournir le rapport de filtrage au frontend.
10.3 Implémenter la logique pour récupérer le
rapport de filtrage en fonction de l’utilisateur
connecté.
En tant qu’agent de conformité 11.1 Ajouter une option pour imprimer le rapport
US11 connecté, je souhaite imprimer le de filtrage. 4
rapport de filtrage 11.2 Mettre en place une API Flask pour générer
et fournir le rapport de filtrage au format
imprimable.
11.3 Implémenter la logique pour générer le rapport
de filtrage en fonction de l’utilisateur connecté.
12.1 Créer une interface pour permettre à
En tant que administrateur , je
US12 l’administrateur d’ajouter de nouvelles 48
souhaite ajouter des régles de filtrage
règles de filtrage.
12.2 Mettre en place une API Flask pour gérer
l’ajout de nouvelles règles de filtrage.
12.3 Implémenter la logique pour enregistrer les
nouvelles règles de filtrage dans la base de
données.

38
Chapitre 3. Release 1

En tant que administrateur , je 13.1 Ajouter une interface pour permettre à

US13 souhaite modifier des régles de filtrage l’administrateur de modifier les règles de 16
filtrage existantes.
13.2 Mettre en place une API Flask pour gérer la
modification des règles de filtrage existantes.
13.3 Implémenter la logique pour mettre à jour les
règles de filtrage dans la base de données.
En tant que administrateur , je 14.1 Ajouter des options pour activer et désactiver
US14 souhaite activer et desactiver des les règles de filtrage. 8
régles de filtrage 14.2 Mettre en place une API Flask pour gérer
l’activation et la désactivation des règles de
filtrage.
14.3 Implémenter la logique pour mettre à jour
l’état des règles de filtrage dans la base de
données.

Tableau 3.5 : Backlog du Sprint 1.2

Dans cette partie et pour la fonctionnalité de recherche de personnes ou d’organismes blacklistés

(US7), nous avons choisi d’utiliser l’algorithme de distance de Levenshtein pour calculer la similarité
entre les noms et prénoms, optimisant ainsi le traitement des données textuelles et la précision des
résultats aprés nous allons exposer le diagramme de cas d’utilisation raffiné du sprint 1.2. Nous
passerons par la suite à expliquer en détail les différentes fonctionnalités que nous sommes demandées
de réaliser tout au long de ce sprint.

[Link] Conception de l’Algorithme de Similarité pour la recherche personnes

ou d’organismes blacklistés (US7)

L’algorithme de détection de similarité a pour objectif de comparer des informations personnelles

(nom, prénom, date de naissance) avec des listes de sanctions et de surveillance afin d’identifier des
correspondances avec des individus impliqués dans des activités illégales ou politiquement exposés.
Après une étude, nous avons choisi d’utiliser l’algorithme de Levenshtein pour améliorer la précision
en gérant les variations et erreurs courantes dans les données textuelles.

— 1- Présentation : L’algorithme de Levenshtein, ou distance d’édition, est une technique utilisée

pour évaluer la dissimilarité entre deux chaînes de caractères. Il détermine le nombre minimal
d’opérations requises pour convertir une chaîne en une autre, en permettant les opérations
suivantes : insertion, suppression et substitution de caractères.

— 2- Élaboration d’un Modèle de Comparaison : Le modèle de comparaison est élaboré

pour analyser et traiter des données comprenant des noms, prénoms et dates de naissance. Pour
chaque enregistrement, il réalise les opérations suivantes :

39
Chapitre 3. Release 1

a- Prétraitement des inputs :

Uniformisation : Transformer les données en un format standardisé pour assurer la cohérence,

y compris la conversion de toutes les lettres en minuscules et l’élimination des espaces et des
caractères spéciaux. Découpage : Séparer les données en composants distincts (nom, prénom,

date de naissance) pour faciliter une analyse approfondie.

b- Intégration de l’Algorithme de Levenshtein : L’algorithme de Levenshtein calcule

la distance entre deux chaînes de caractères, mesurant le nombre minimal de modifications
(insertions, suppressions, substitutions) nécessaires pour transformer une chaîne en une autre.
Cela est utile pour identifier des correspondances malgré les erreurs de frappe et les variations
orthographiques.

Soient A et B deux chaînes avec |A| et |B| indiquant leur longueur respectivement. La distance
de Levenshtein D(i, j) entre les i premiers caractères de A et les j premiers caractères de B peut
être calculée récursivement comme suit :

- Initialisation : Pour tous les i allant de 0 à |A| et tous les j de 0 à |B|,

D(i, 0) = i
D(0, j) = j

- Calcul de la distance de Levenshtein : Pour i = 1 à |A| et j = 1 à |B|,

- Si A[i] = B[j] alors D(i, j) = D(i − 1, j − 1) (aucune modification nécessaire si les caractères
sont identiques) - Sinon, D(i, j) = 1 + min(D(i − 1, j), D(i, j − 1), D(i − 1, j − 1))

- D(i − 1, j) représente une suppression, - D(i, j − 1) représente une insertion, - D(i − 1, j − 1)

représente une substitution.

La distance de Levenshtein entre A et B est alors donnée par D(|A|, |B|), représentant le nombre
minimum d’opérations nécessaires pour transformer A en B.

c- Similarité date de naissance : Pour les dates de naissance, une approche basée sur la

40
Chapitre 3. Release 1

distance pourrait être moins pertinente, car des différences d’un ou deux jours (ou même quelques
mois ou années) peuvent être sans importance selon le contexte. Nous adoptons une approche
basée sur une comparaison directe du mois de naissance et de l’année de naissance sans prendre
en compte le jour de naissance.

d- Calcul : Pour évaluer la similitude entre des ensembles de données personnelles (nom, prénom,
date de naissance), il est essentiel d’adapter les méthodes. La distance de Levenshtein est efficace
pour les noms et prénoms, tandis qu’une comparaison directe ou un calcul de différence d’âge
convient mieux aux dates de naissance.

A∗LevenDist(F name)+B∗LevenDist(Lname)+C∗Dif f (Y )+D∗Dif f (M )

Score = Sum(A,B,C,D)

— 3- Flux de l’Algorithme de Similarité : La Figure 3.12 illustre le diagramme de séquence du

flux de traitement de l’algorithme de similarité basé sur la distance de Levenshtein. Ce processus
est essentiel au système de vérification de conformité, jouant un rôle crucial dans la comparaison
des noms et prénoms avec les listes de surveillance.

images/chap3/Sprint2/[Link]

Figure 3.12 : Flux de l’Algorithme de Similarité basé sur la Distance de Levenshtein.

Le diagramme illustre la séquence des étapes suivantes :

— Le module de prétraitement reçoit le nom, le prénom et la date de naissance, effectuant un

nettoyage initial pour assurer l’uniformité et la précision des données avant la comparaison. Pour
la date de naissance, cela inclut la séparation de l’année et du mois, ainsi que la suppression du
jour.

— Le module de recherche interroge la base de données pour obtenir les listes de conformité et

41
Chapitre 3. Release 1

reçoit une liste de correspondances à vérifier. Cette liste est ensuite transmise à l’algorithme de
similarité, qui entre en boucle pour calculer la distance de Levenshtein pour chaque nom.

— L’algorithme de similarité calcule un score de similarité pour chaque nom et le transmet au

module de décision.

— Le module de décision applique un seuil de correspondance pour identifier les correspondances

potentielles.

— Enfin, le système renvoie les résultats, indiquant s’il y a une correspondance ou non avec les
entrées des listes de conformité.

[Link] Diagramme de cas d’utilisation raffiné du sprint 1.2

La figure 3.13 représente le diagramme de cas d’utilisation raffiné du sprint 1.2.

42
Chapitre 3. Release 1

images/chap3/Sprint2/[Link]

Figure 3.13 : Diagramme de cas d’utilisation raffiné du sprint 1.2

[Link] Description textuelle

Dans cette partie nous avons présenté une description textuelle de quelques cas d’utilisation.
À travers le tableau 3.6 nous présentons la description textuelle du cas d’utilisation "Chercher
personne si blacklisté".

Cas d’utilisation Chercher personne si blacklisté

Acteur Agent, Agent de conformité
Pré-conditions L’acteur doit être authentifié
Post-conditions Affichage des résultats de la recherche
1- L’utilisateur accède à l’interface de recherche
2- L’utilisateur remplit le formulaire de la personne à rechercher
3- L’utilisateur appuie sur le bouton de recherche
Scénario nominal

43
Chapitre 3. Release 1

4- Le système effectue une recherche dans la base de données pour trouver des correspondances de
personnes blacklistés en fonction des données saisies
5- Le système affiche les résultats de la recherche à l’utilisateur
6- L’utilisateur examine les résultats et prend les mesures appropriées selon les politiques de
l’entreprise (validation, rejet, etc.)
Scénario alternatif 1- Les champs obligatoires ne sont pas tous remplis : un message d’erreur s’affiche pour notifier
l’utilisateur

Tableau 3.6 : Description textuelle du cas d’utilisation "Chercher personne ou organisme blacklisté"

3.5.2 Conception du Sprint 1.2

Nous abordons maintenant la partie conception de ce sprint. Pour ce faire, nous présentons d’un
côté le diagramme de classes de conception et d’un autre côté, une vue dynamique avec le diagramme
de séquences.

[Link] Implémentation de l’Algorithme de Distance de Levenshtein

Cette tâche consiste à développer l’algorithme de distance de Levenshtein pour évaluer les scores
de similarité, La Figure 3.14 illustre le diagramme d’activité pour l’implémentation de l’algorithme de
distance de Levenshtein. .

44
Chapitre 3. Release 1

images/chap3/Sprint2/[Link]

Figure 3.14 : Diagramme d’activité pour l’implémentation de l’algorithme de distance de

Levenshtein.

[Link] Diagramme de classes de conception du sprint 1.2

Dans cette partie, nous allons présenter le diagramme de classes de conception du sprint 1.2.
comme le montre la figure 3.15

images/chap3/Sprint2/[Link]

Figure 3.15 : Diagramme de classes de conception du sprint 1.2

45
Chapitre 3. Release 1

[Link] Diagrammes de séquences détaillés

La figure 3.19 représente le diagramme de séquences détaillé du cas d’utilisation "modifier régle
de filtrage".

images/chap3/Sprint2/[Link]

Figure 3.16 : Diagramme de séquences détaillé du cas d’utilisation "modifier régle de filtrage"

3.5.3 Réalisation du Sprint 1.2

Dans cette partie, nous allons présenter quelques interfaces réalisées du sprint 1.2

46
Chapitre 3. Release 1

images/captures/verifkyc/[Link]

Figure 3.17 : Iterface "Accepter ou rejeter client"

images/captures/verifkyc/ajouterregle .png

Figure 3.18 : Interface"Ajouter régle de filtrage"

47
Chapitre 3. Release 1

images/captures/gestion client/[Link]

Figure 3.19 : Interface "modifier régle de filtrage"

3.6 Test et validation

Avant sa livraison, cette version a subi des tests et a été validée. Effectivement, tous les tests
unitaires, fonctionnels et d’intégration de chaque tâche ont été réalisés. Toutefois, la vérification a été
effectuée à travers des réunions mensuelles avec le product owner et le scrum master. Finalement,
chaque tâche mentionnée dans le backlog de la release 1 est livrée au client avec succès.

Conclusion

Ce chapitre a exposé la Release 1 ainsi qu’une analyse approfondie et une conception de chaque
sprint. Par la suite, nous avons abordé la mise en œuvre et la réalisation. Dans le prochain chapitre,
nous abordons la release 2 qui comporte la gestion de client, la gestion de balayage et l’identification
de score de risque basé sur un modéle de machine learning.

48
Chapitre 4

Release 2

Introduction

En suivant le même principe que dans la Release précédente, nous allons débuter en présentant
le Backlog de la Release pour déterminer les tâches que nous allons effectuer après notre réunion avec
le Product Owner. Ensuite, nous allons décrire en détail chaque sprint ainsi que son analyse et sa
conception. Au terme de chaque sprint, nous allons exposer les interfaces de sa mise en œuvre.

4.1 Backlog de la Release 2

Le tableau 4.1 répertorie les divers sprints de la release 2.

Nom du Sprint Numéro du Sprint

Gestion client Sprint 2.1

Gestion balayage Sprint 2.2

Identification du score de risque Sprint 2.3

Tableau 4.1 : Backlog de la Release 2

4.2 Analyse globale de la Release 2

Dans cette partie, nous exposerons le diagramme des cas d’usage général pour la Release 2, tel
qu’indiqué dans la figure 4.1.

49
Chapitre 4. Release 2

images/chap4/[Link]

Figure 4.1 : Diagramme de classes global de la Release 2

4.3 Conception globale de la Release 2

Dans cette partie, nous allons présenter le diagramme de classes global de la Release 2 comme
le montre la figure 4.2.

50
Chapitre 4. Release 2

images/chap4/[Link]

Figure 4.2 : Diagramme de classes global de la Release 2

Ce diagramme de classes se base sur le diagramme de classes de la Release précédente et y

intègre de nouvelles classes.
Le tableau suivant 4.2 décrit les différents attributs de chaque classe dans cette release :

Classes Attributs Type Description

ClientManagementService serviceUrl String désigne l’URL du point d’accès au
service backend.
ClientProfile clientId Entier désigne l’identifiant unique du client.
name Text Prénom du client.
surname Text Nom de famille du client.
CIN Réel Numéro d’identification civique du
client.
address Réel Adresse résidentielle du client.
phoneNumber Réel Numéro de téléphone du client.

51
Chapitre 4. Release 2

email Réel Adresse email du client.

KYCStatus Réel Statut de la vérification KYC du client.
riskScore Réel Classe de risque calculée basée sur
divers facteurs.
dateOfBirth Date Date de naissance du client.
nationality Réel Nationalité du client.
occupation Réel Occupation actuelle du client.
maritalStatus Réel Statut marital du client.
numberOfDependents Réel Nombre de personnes à charge du
client.
KYCService kycServiceUrl String URL du point d’accès au service KYC.
RiskclassService serviceUrl AlgorithmType Type d’algorithme utilisé pour
visualiser la classe de risque.
ScanningService scanningFrequency String Paramétrage de la fréquence pour les
balayages programmés.
ReportService reportStoragePath String Chemin où les rapports sont stockés ou
accessibles.

Tableau 4.2 : Dictionnaire de données de la Release 2

4.4 Sprint 2.1 : Gestion client

Nous identifierons les tâches de la user story du sprint, estimerons leur durée en heures et
fournirons toutes les tâches énumérées au client à la fin du sprint.

4.4.1 Backlog du Sprint 2.1

Le tableau 4.3 présente le backlog du sprint, répertoriant toutes les tâches à réaliser. Notons
qu’un utilisateur connecté dans ce sprint spécifiquement désigne un agent ou un agent de conformité.

Estim-
ID ID
Fonctionnalité User Story Tâche ation
US Tâche
(Heures)
En tant que utilisateur 15.1 Créer une interface pour afficher la liste
Gestion
US15 connecté, je souhaite consulter des clients. 8
client
la liste des clients 15.2 Mettre en place une API Flask pour
récupérer la liste des clients depuis la
base de données.

52
Chapitre 4. Release 2

15.3 Implémenter la logique pour récupérer

et fournir la liste des clients au
frontend.
En tant que utilisateur 16.1 Ajouter une barre de recherche pour
US16 connecté, je souhaite rechercher permettre à l’utilisateur de rechercher 8
un client un client par nom, prénom ou numéro
de cin
16.2 Mettre en place une API Flask pour
gérer la recherche de clients.
16.3 Implémenter la logique de recherche
pour filtrer les clients en fonction du
nom, prénom ou numéro de cin.
En tant que utilisateur 17.1 Ajouter une option pour exporter une
US17 connecté, je souhaite exporter fiche client au format CSV ou PDF. 8
une fiche client 17.2 Mettre en place une API Flask pour
exporter une fiche client au format
souhaité.
17.3 Implémenter la logique pour générer et
exporter une fiche client dans le format
demandé.
En tant que utilisateur 18.1 Créer une interface pour afficher les
US18 connecté, je souhaite consulter détails d’un client sélectionné. 6
la fiche client 18.2 Mettre en place une API Flask
pour récupérer les détails d’un client
spécifique depuis la base de données.
18.3 Implémenter la logique pour fournir les
détails du client au frontend.
19.1 Développer un formulaire interactif
En tant qu’agent, je souhaite
US19 pour la création de fiches KYC, 10
créer une fiche client KYC
incluant des validations de champ et des
messages d’erreur.
19.2 Mettre en place une API Flask pour
créer une nouvelle fiche client KYC.
19.3 Implémenter la logique pour enregistrer
les informations de la fiche client KYC
dans la base de données.

53
Chapitre 4. Release 2

En tant qu’agent de conformité, 20.1 Ajouter une interface pour permettre à

US20 je souhaite modifier une fiche l’agent de conformité de modifier une 8
client KYC fiche client existante
20.2 Mettre en place une API Flask pour
modifier une fiche client KYC existante.
20.3 Implémenter la logique pour mettre à
jour les informations de la fiche client
KYC dans la base de données.
En tant qu’agent de conformité, 21.1 Créer une interface pour afficher la
US21 je souhaite consulter la classe de matrice de risque des clients. 6
risque de client 21.2 Mettre en place une API Flask pour
récupérer et fournir la classe de risque
des clients au frontend.
21.3 Implémenter la logique pour calculer et
générer la classe de risque des clients.

Tableau 4.3 : Backlog du Sprint 2.1

4.4.2 Analyse détaillée du Sprint 2.1

Dans cette section, nous commencerons par présenter le diagramme de cas d’utilisation détaillé
du Sprint 2.2. Ensuite, nous décrirons en détail la fonctionnalité que nous devons développer durant
ce sprint.

[Link] Diagramme de cas d’utilisation raffiné du Sprint 2.1

La figure 4.3 représente le diagramme de cas d’utilisation raffiné du Sprint 2.2.

54
Chapitre 4. Release 2

images/chap4/[Link]

Figure 4.3 : Diagramme de cas d’utilisation raffiné du Sprint 2.1

[Link] Descriptions textuelles

Dans cette section, nous fournirons une description textuelle de deux cas d’utilisation.
Le tableau 4.4 présente la description du cas d’utilisation "Créer fiche client KYC", tandis que
le tableau 4.5 décrit le cas d’utilisation "Modifier fiche client".

55
Chapitre 4. Release 2

Cas d’utilisation Créer fiche Client KYC

Acteurs Agent

Pré-conditions L’agent est authentifié dans le système.

L’agent doit vérifier si le client est blacklisté dans l’interface de recherche
personne en saisissant son nom, prénom et la date de naissance.
Le client n’existe pas dans la base de données.

Post-conditions La fiche client KYC est créée avec succès.

Scénario nominal 1- L’agent accède à l’interface de création de fiche client KYC.

2- L’agent saisit les informations du client nécessaires pour la fiche KYC (nom,
prénom, adresse, pièce d’identité, etc.).
3- L’agent vérifie les informations saisies et valide la création de la fiche client
KYC.
4- Le système enregistre les informations de la fiche client KYC dans la base
de données.
5- Le système confirme la création réussie de la fiche client KYC à l’agent.

Scénario alternatif 1- Si le client est blacklisté, l’agent est informé de la situation et ne peut pas
procéder à la création de la fiche KYC.
2- Si des champs obligatoires sont manquants ou des informations sont
incorrectes, le système affiche un message d’erreur et demande à l’agent de
corriger les données.
3- Si une erreur survient lors de l’enregistrement (problème technique, conflit
de données, etc.), le système affiche un message d’erreur et informe l’agent de
réessayer ultérieurement.

Tableau 4.4 : Description textuelle du cas d’utilisation "Créer fiche Client KYC"

56
Chapitre 4. Release 2

Cas d’utilisation Modifier fiche client

Acteurs Agent de conformité

Pré-conditions L’agent est authentifié dans le système.

Le client existe dans la base de données.

Post-conditions La fiche client est modifiée avec succès.

Scénario nominal 1- L’agent de conformité accède à l’interface de modification de fiche client

KYC.
2- L’agent de conformité sélectionne la fiche client KYC à modifier.
3- L’agent de conformité modifie les informations de la fiche client KYC selon
les besoins (adresse, statut, informations personnelles, etc.).
4- L’agent de conformité vérifie les modifications apportées et valide la mise à
jour de la fiche client KYC.
5- Le système enregistre les modifications de la fiche client KYC dans la base
de données.
6- Le système confirme la modification réussie de la fiche client KYC à l’agent
de conformité.

Scénario alternatif 1- Si des champs obligatoires sont manquants ou des informations sont
incorrectes, le système affiche un message d’erreur et demande à l’agent de
conformité de corriger les données.
2- Si l’agent de conformité décide d’annuler les modifications, il peut
sélectionner une option d’annulation.
3- Si l’agent de conformité sélectionne l’option d’annulation, le système
abandonne les modifications temporaires et restaure la fiche client KYC à
son état précédent.

Tableau 4.5 : Description textuelle du cas d’utilisation "Modifier fiche client"

4.4.3 Conception du Sprint 2.1

Nous passons maintenant à la phase de conception de ce sprint. Pour cela, nous présenterons à
la fois le diagramme de classes de conception et une vue dynamique avec des diagrammes de séquences.

[Link] Diagramme de classes de conception du sprint 2.1

Dans cette section, nous présenterons le diagramme de classes de conception du sprint 2.1,
comme illustré dans la figure 4.5.

57
Chapitre 4. Release 2

images/chap4/[Link]

Figure 4.4 : Diagramme de classes de conception du sprint 2.1

[Link] Diagrammes de séquences détaillé

La figure 4.5 illustre le diagramme de séquences détaillé du cas d’utilisation "Consulter la liste
des clients".

images/chap4/[Link]

Figure 4.5 : Diagramme de séquences détaillé du cas d’utilisation "Consulter liste des clients"

58
Chapitre 4. Release 2

N.B. Un utilisateur connecté désigne un agent, un agent de conformité ou un administrateur.

La figure 4.6 montre le diagramme de séquences détaillé pour le cas d’utilisation "Consulter
fiche client".

images/chap4/[Link]

Figure 4.6 : Diagramme de séquences détaillé du cas d’utilisation "Consulter fiche client"

4.4.4 Réalisation du Sprint 2.1

Dans cette partie, nous allons présenter quelques interfaces réalisées du sprint 2.1. :

59
Chapitre 4. Release 2

images/captures/gestion client/[Link]

Figure 4.7 : Iterface"Recherche client si blacklistée"

images/captures/gestion client/[Link]

Figure 4.8 : Iterface "Créer fiche clinet"

60
Chapitre 4. Release 2

images/captures/gestion client/[Link]

Figure 4.9 : Iterface"Consulter fiche client"

4.5 Sprint 2.2 : Gestion de balayage

Au début de cette section, nous introduirons le backlog du sprint. Ensuite, nous présenterons
les diagrammes de conception et, enfin, nous montrerons quelques interfaces créées lors du sprint 2.2.

4.5.1 Backlog du Sprint 2.2

Le tableau 4.6, indiquant le backlog, liste toutes les tâches à livrer au client à la fin du sprint.

Estim-
ID ID
Fonctionnalité User Story Tâche ation
US Tâche
(Heures)
22.1 Créer une interface pour permettre à
En tant que administrateur, je l’administrateur de planifier les tâches de
Gestion
US22 souhaite planifier les tâches de balayage (fréquence). 14
balayage
balayage (fréquence) 22.2 Mettre en place une API Flask pour gérer la
planification des tâches de balayage.
22.3 Implémenter la logique pour enregistrer les
tâches de balayage planifiées dans la base de
données.
En tant que administrateur, je 23.1 Ajouter un bouton ou une option dans
US23 souhaite lancer le balayage l’interface pour permettre à l’administrateur 28
manuellement via l’interface de lancer manuellement le balayage.
23.2 Mettre en place une API Flask pour déclencher
manuellement le balayage.
23.3 Implémenter la logique pour démarrer le
balayage en fonction des paramètres définis.
En tant que administrateur, je 24.1 Créer une interface pour permettre à
US24 souhaite consulter le rapport de l’administrateur de consulter les rapports 8
balayage de balayage.

61
Chapitre 4. Release 2

Estim-
ID ID
Fonctionnalité User Story Tâche ation
US Tâche
(Jours)
24.2 Mettre en place une API Flask pour récupérer
les rapports de balayage depuis la base de
données.
24.3 Implémenter la logique pour générer et fournir
les rapports de balayage au frontend.
En tant que agent de conformité, je 25.1 Créer une interface pour permettre à l’agent
US25 souhaite consulter le rapport de de conformité de consulter les rapports de 6
balayage balayage.
25.2 Mettre en place une API Flask pour récupérer
les rapports de balayage depuis la base de
données.
25.3 Implémenter la logique pour générer et
fournir les rapports de balayage à l’agent de
conformité.

Tableau 4.6 : Backlog du Sprint 2.2

4.5.2 Analyse détaillée du Sprint 2.2

Dans cette partie, nous présenterons d’abord le diagramme de cas d’utilisation détaillé du
Sprint 2.3. Ensuite, nous expliquerons en détail la fonctionnalité que nous devons développer tout au
long de ce sprint.

[Link] Diagramme de cas d’utilisation raffiné du Sprint 2.2

La figure 4.10 représente le diagramme de cas d’utilisation raffiné du Sprint 2.2.

62
Chapitre 4. Release 2

images/chap4/Diagrammedecasd’[Link]

Figure 4.10 : Diagramme de cas d’utilisation raffiné du Sprint 2.2

[Link] Description textuelle

Dans cette section, nous fournirons une description textuelle d’un seul cas d’utilisation.
Le tableau 4.7 présente la description textuelle du cas d’utilisation "Planifier les tâches de
balayage (fréquence)".

Cas d’utilisation Planifier les tâches de balayage (fréquence)

Acteurs Administrateur
Pré-conditions L’administrateur est authentifié dans le système.
Post-conditions Les tâches de balayage sont planifiées avec succès.
Scénario nominal 1- L’administrateur accède à l’interface de planification des tâches de balayage.
2- L’administrateur sélectionne la fréquence de balayage (quotidien, hebdomadaire, mensuel, etc.) et
les paramètres associés (heure, jour de la semaine, etc.).
3- L’administrateur valide les paramètres de planification.
4- Le système enregistre les tâches de balayage planifiées dans la base de données.
5- Le système confirme la planification réussie des tâches de balayage à l’administrateur.

Tableau 4.7 : Description textuelle du cas d’utilisation "Planifier les tâches de balayage (fréquence)"

4.5.3 Conception du Sprint 2.2

Nous passons maintenant à la phase de conception de ce sprint. À cet effet, nous présentons,
d’une part, le diagramme de classes de conception et, d’autre part, une vue dynamique illustrée par
le diagramme de séquences.

63
Chapitre 4. Release 2

[Link] Diagramme de classes de conception du sprint 2.2

Dans cette partie, nous allons présenter le diagramme de classes de conception du sprint 2.3
comme le montre la figure 4.11.

images/chap4/[Link]

Figure 4.11 : Diagramme de classes de conception du sprint 2.3

[Link] Diagramme de séquences détaillé

La figure 4.12 représente le diagramme de séquences détaillé du cas d’utilisation "Planifier les
tâches de balayage (fréquence)".

images/chap4/[Link]

Figure 4.12 : Diagramme de séquences détaillé du cas d’utilisation "Planifier les tâches de balayage
(fréquence)"

64
Chapitre 4. Release 2

4.5.4 Réalisation du Sprint 2.2

Dans cette partie, nous allons présenter quelques interfaces réalisées du Sprint 2.2.

images/captures/[Link]

Figure 4.13 : Interface "Balayage Manuel"

4.6 Sprint 2.3 : Identification du classe de risque

Ce sprint est dédié à l’implémentation d’un modèle de machine learning pour évaluer la classe de
risque des clients. La classe de risque KYC, une catégorie assignée au client, est déterminée en analysant
diverses variables liées au client. Cette classification est essentielle pour surveiller le portefeuille client
du point de vue de la conformité
Dans cette section, nous débuterons par la présentation du backlog du sprint. Ensuite, nous
détaillerons les diagrammes de conception pour illustrer l’architecture du système. Enfin, nous mettrons
en avant quelques interfaces développées durant ce sprint 2.3.

4.6.1 Backlog du Sprint 2.3

Le backlog du sprint présente les tâches et user stories nécessaires à l’implémentation du modèle
de machine learning pour le calcul du score de risque, chaque tâche étant estimée en heures et devant
être livrée au client à la fin du sprint. Notons qu’un utilisateur connecté désigne un agent, un agent
de conformité ou un administrateur.

Estim-
ID ID
Fonctionnalités User Story Tâche ation
US Tâche
(Heures)
26.1 Mise en place de l’API Flask et création d’un
Identification Le système calcule automatiquement endpoint RESTful pour récupérer les données
de score de US26 le score de risque KYC des clients à des clients 56
risque travers un modèle de machine learning Suite à la page suivante

65
Chapitre 4. Release 2

Table 4.8 – suite de la page précédente

Estim-
ID ID
Fonctionnalités User Story Tâche ation
US Tâche
(Jours)
26.2 Data cleaning, Entraînement, validation et
déploiement du modèle de machine learning
26.3 Stockage des pondérations et des valeurs de
risque dans la base de données et historisation
des calculs
26.4 Intégration du modèle de machine learning
pour identifier la classe de risque de client
27.1 Création de l’interface de configuration pour
En tant que administrateur, je visualiser les analyses de classification
- US27 souhaite consulter les analyses de 27.2 Mise en place de l’API Flask et création d’un 24
classification endpoint RESTful pour récupérer les analyses
27.3 -
27.4 Stockage et historisation des configurations

Tableau 4.8 : Backlog du Sprint 2.3

4.6.2 Analyse détaillée du Sprint 2.3

Dans cette partie, nous allons présenter, en premier lieu, le diagramme de cas d’utilisation
raffiné du Sprint 2.3. Nous allons exposer par la suite à expliquer en détail la fonctionnalité que nous
sommes demandées de réaliser tout au long de ce sprint.

[Link] Diagramme de cas d’utilisation raffiné du Sprint 2.3

La figure 4.14 représente le diagramme de cas d’utilisation raffiné du Sprint 2.3.

66
Chapitre 4. Release 2

images/chap4/[Link]

Figure 4.14 : Diagramme de cas d’utilisation raffiné du Sprint 2.3

[Link] Description textuelle

À travers le tableau 4.9 nous présentons la description textuelle du cas d’utilisation "Identifier
la classe de risque de client".

Cas d’utilisation identifier la classe de risque de client

Acteurs Système
Pré-conditions Les pondérations et valeurs de risque doivent être définies dans la base de données.
Post-conditions La classe de risque des clients est calculée.
Scénario nominal 1- L’utilisateur se connecte au système.
2- L’utilisateur accède à l’interface de calcul du score de risque.
3- L’utilisateur saisit les informations du client.
4- L’utilisateur soumet le formulaire.
5- Le système envoie les données au backend via l’API Flask.
6- Le backend reçoit les données et les transmet au modèle de machine learning.
7- Le modèle de machine learning identifie la classe de risque.
8- Le backend enregistre la classe de risque et renvoie les résultats au frontend.
9- L’interface affiche la classe de risque et la classification.
Scénario alternatif Si des informations sont manquantes ou invalides dans le formulaire, le système affiche un message
d’erreur demandant de compléter ou corriger les informations.

Tableau 4.9 : Description textuelle du cas d’utilisation "identifier la classe de risque de client"

67
Chapitre 4. Release 2

4.6.3 Conception du Sprint 2.3

Nous passons maintenant à la partie conception de ce sprint, en présentant une vue dynamique
à l’aide du diagramme de séquences.
Diagramme de séquences détaillé La figure 4.15 représente le diagramme de séquences
détaillé du cas d’utilisation "Identifier la classe de risque de client".

images/chap4/[Link]

Figure 4.15 : Diagramme de séquences détaillé du cas d’utilisation "classe de risque de client"

N.B. Un utilisateur désigne un agent, un agent de conformité ou un administrateur.

4.7 Description de l’identification de la classe de risque

Cette section détaille l’analyse de clustering effectuée sur les données KYC (Know Your Customer)
pour identifier des groupes distincts de clients dans le cadre de la lutte contre le blanchiment d’argent
(AML) et le financement du terrorisme (FTF). L’analyse comporte plusieurs étapes :

— Prétraitement des Données

— Encodage des Variables Catégorielles

— Normalisation des variables numériques

— Attribution de l’importance au produit épargne

— Choix du modèle

— Application de K-Means

68
Chapitre 4. Release 2

— Réduction de Dimensionnalité

— Visualisations

— Interprétation des clusters

— Prédiction d’un nouvel individu à un cluster

Nous avons utilisé les bibliothèques suivantes pour la partie Machine Learning : pandas, numpy, sklearn
(StandardScaler, LabelEncoder, KMeans, TSNE), matplotlib, seaborn.

Chargement et Prétraitement des Données

Les données ont été chargées à partir d’un fichier CSV. Les lignes avec des valeurs manquantes
dans des colonnes cruciales comme ID_KYC, State, Product, Activity, Age, Canal, Gender, nation, et
nationality ont été supprimées pour assurer l’intégrité des analyses ultérieures. Une nouvelle variable
a été créée qui représente une copie de la colonne produit avec les valeurs épargne pour donner plus
de poids au produit épargne. L’étape de preprocessing est représentée dans la figure 4.16.

Encodage des Variables Catégorielles

Les variables catégorielles telles que State, Product, Activity, Canal, Gender, nation, et nationality
ont été converties en valeurs numériques à l’aide de l’encodage des étiquettes (Label Encoding). Cette
étape est essentielle pour permettre l’utilisation de ces variables dans le clustering.

Normalisation des variables Numériques

Les variables numériques, y compris une nouvelle variable pour donner plus d’importance
au produit "épargne", ont été normalisées pour avoir une moyenne de 0 et un écart type de 1. La
normalisation garantit que toutes les variables contribuent de manière équitable à l’analyse.

[Link]

Figure 4.16 : Étapes du preprocessing

69
Chapitre 4. Release 2

Choix du modèle

L’apprentissage supervisé et l’apprentissage non supervisé sont deux approches distinctes dans
le domaine de l’apprentissage automatique. L’apprentissage supervisé utilise des données labélisés pour
entraîner les modèles, ce qui signifie que à chaque ligne ou individu est associé à un label connu. Cela
permet au modèle d’apprendre à prédire le label correct pour de nouvelles données. En revanche,
l’apprentissage non supervisé n’utilise pas de labels de données. Il cherche plutôt à identifier des
structures ou des patterns dans les données en les regroupant sous forme de groupes similaires.
Dans ce travail, nous adoptons l’apprentissage non supervisé car nous n’avons pas de labels
connus. La formule existante à BH Assurance calcule le score de risque de manière statique, ce qui
signifie que la classe de risque calculée ne peut pas être utilisée comme un repère pour notre modèle.
Nous allons comparer trois modèles d’apprentissage non supérvisé qui sont K-Means, DBCAN et
Isolation Forest.
K-Means est un algorithme de clustering qui regroupe les données en un nombre prédéfini de
clusters, en minimisant la distance intra-cluster. Chaque cluster est défini par son centre (ou centroid),
qui est la moyenne des points appartenant à ce cluster. La complexité de cet algorithme est linéaire par
rapport au nombre de points, ce qui le rend très scalable pour les grands ensembles de données.[15].
DBSCAN (Density-Based Spatial Clustering of Applications with Noise) est un algorithme de
clustering basé sur la densité qui identifie les clusters selon la densité des points dans l’espace des
données. Il fonctionne en identifiant les régions denses et en les étendant en fonction de la densité
minimale requise. Contrairement à K-Means, DBSCAN n’a pas besoin de prédéfinir le nombre de
clusters et peut identifier des formes de clusters arbitraires. De plus, il peut détecter les points
considérés comme du bruit (outliers) [16].
Isolation Forest est un algorithme utilisé principalement pour la détection d’anomalies. Il
fonctionne en construisant des arbres de décision de manière aléatoire et en mesurant la facilité avec
laquelle les points de données peuvent être isolés. Les points qui sont facilement isolés sont considérés
comme des anomalies. Isolation Forest est efficace pour des jeux de données avec un grand nombre de
dimensions et est basé sur le concept de sous-échantillonnage, ce qui le rend très efficace en termes de
temps de calcul [17]
Nous avons préparé un dataset auquel le département conformité à affécté des labels et nous
avons évalué les trois modèles à l’aide des mesures precision, recall and f-score.
La précision est la proportion des prédictions positives qui sont réellement positives. En d’autres
termes, parmi tous les exemples que le modèle a prédits comme appartenant à une certaine classe,
combien sont effectivement de cette classe. La formule est :

70
Chapitre 4. Release 2

Vrais Positifs
Précision =
Vrais Positifs + Faux Positifs

Une précision élevée indique un faible taux de faux positifs.

Le recall est la proportion des vrais exemples positifs qui sont correctement identifiés par le
modèle. En d’autres termes, parmi tous les exemples qui appartiennent réellement à une certaine
classe, combien ont été correctement prédits comme appartenant à cette classe. La formule est :

Vrais Positifs
Recall =
Vrais Positifs + Faux Négatifs

Un recall élevé indique un faible taux de faux négatifs.

Le F-score est la moyenne harmonique de la précision et du recall. Il fournit une mesure unique
de la performance du modèle en tenant compte à la fois de la précision et du recall. La formule est :

Précision ∗ Recall
F1 = 2
Précision + Recall

Le F-score est particulièrement utile lorsque l’on cherche un équilibre entre la précision et le
recall, surtout lorsque les classes sont déséquilibrées [18].
La figure 4.17 présente les performances des trois algorithmes de clustering : K-Means, DBSCAN
et Isolation Forest, évalués à l’aide des métriques de précision, recall et F-score. K-Means affiche une
précision de 0.788, un recall de 0.824 et un F-score de 0.797, indiquant qu’il est capable de bien
identifier les clusters dans les données.
Le tableau montre que DBSCAN a une précision de 0.727, un recall de 0.241 et un F-score de
0.362. Cela suggère que bien qu’il soit capable de trouver des zones de haute densité, il peut ne pas
être aussi efficace que K-Means pour ce jeu de données particulier.
Les résultats montrent qu’Isolation Forest a une précision de 0.052, un recall de 0.133 et un
F-score de 0.075, ce qui indique qu’il est moins performant pour cette tâche de clustering spécifique
comparé aux deux autres algorithmes.
En conclusion, d’après les résultats du tableau, K-Means semble être le modèle le plus performant
pour ce jeu de données, avec des valeurs élevées de précision, de recall et de F-score.

[Link]

Figure 4.17 : Comparaison des modèles

71
Chapitre 4. Release 2

Application de K-Means Clustering

Le clustering K-Means a été appliqué pour diviser les données en trois clusters distincts (relatifs
aux trois classes de risques).
K-means est une méthode de partitionnement qui divise un ensemble de données en k groupes
(ou clusters) en minimisant la somme des distances au carré entre les points de données et le centre
(centroïde) du cluster auquel ils appartiennent. L’algorithme de K-means [19] peut être décrit par les
étapes suivantes :

— 1- Initialisation : Choisir k centroïdes initiaux, souvent choisis aléatoirement.

— 2- Assignation : Attribuer chaque point de données au cluster dont le centroïde est le plus proche.

— 3- Mise à jour : Calculer le nouveau centroïde de chaque cluster en prenant la moyenne des points
de données attribués à ce cluster.

— 4- Répéter les étapes d’assignation et de mise à jour jusqu’à ce que les centroïdes ne changent
plus significativement.

La formule de K-means pour minimiser la somme des distances au carré est la suivante :

k X
X
Fonction = ∥x − µi ∥2
i=1 x∈Ci

où :

— k est le nombre de clusters.

— Ci est le i-ème cluster.

— x est un point de données.

— µi est le centroïde du i-ème cluster.

Réduction de Dimensionnalité et Visualisation (t-SNE)

La réduction de dimensionnalité avec t-SNE [20] (t-distributed Stochastic Neighbor Embedding)

a été utilisée pour visualiser les clusters en deux dimensions. Cette technique permet de visualiser les
dimensions des données en une représentation bidimensionnelle, facilitant ainsi l’interprétation des
clusters. La figure 4.18 montre la partie visualisation du code.

72
Chapitre 4. Release 2

[Link]

Figure 4.18 : Visualisation

4.7.1 Visualisations et Interprétations

[Link] Visualisation t-SNE des Clusters

La visualisation t-SNE montre la répartition des clusters en deux dimensions. Chaque point
représente un client et les couleurs différentes représentent les clusters.

[Link]

Figure 4.19 : Visualisation t-SNE des Clusters

73
Chapitre 4. Release 2

[Link] Distribution des Clusters

Cette visualisation montre le nombre de clients dans chaque cluster, ce qui aide à comprendre
la taille relative de chaque groupe et ce qui donne une vision primaire sur la représentation des classes
de risques par les clusters comme le montre la figure 4.20. La répartition des données dans chaque
cluster montre que certains clusters sont plus grands, indiquant des profils de clients plus communs.
En général, la classe la plus large est la classe de risque faible et la classe la plus petite en nombre
d’individus est la classe de risque élevé. Mais nous allons visualiser plus de détails sur les clusters pour
décider des classes de risques représentées par chaque cluster.

[Link]

Figure 4.20 : Distribution des Clusters

[Link] Pair Plot des variables Clés

Cette figure 4.21 montre les relations entre différentes variables à travers les clusters. Chaque
point représente un client et les couleurs différentes représentent les clusters. Les axes représentent les
variables.
Dans le Cluster 0, les individus plus âgés ont une forte préférence pour les produits d’épargne,
ce qui renforce l’idée que ce cluster est constitué de clients retraités ou proches de la retraite tandis que
le Cluster 2 est composé d’individus plus jeunes qui sont plus diversifiés dans leurs choix de produits,
utilisant plus de produits transactionnels ou de crédit.
Dans le Cluster 0, on note une concentration notable des activités administratives ou gouvernementales,
corrélée avec une utilisation élevée des produits d’épargne. D’autre part, on note une diversité dans les
activités économiques et les produits utilisés, indiquant une clientèle variée avec des besoins financiers
sophistiqués. Le Cluster 0 présente aussi des individus plus âgés utilisent principalement les agences

74
Chapitre 4. Release 2

[Link]

Figure 4.21 : Pair Plot des variables Clés

physiques pour leurs transactions et le Cluster 2 présente des individus plus jeunes préfèrent les canaux
numériques pour leurs transactions, ce qui est typique des jeunes professionnels et des étudiants.

[Link] Distribution des variables par Cluster

Ces histogrammes dans la figure 4.22 montrent comment les variables individuelles sont réparties
au sein de chaque cluster. Les couleurs différentes représentent les clusters.
L’analyse des distributions montre des différences significatives dans des variables telles que
l’âge, le produit, et le canal, ce qui aide à identifier les profils de risque spécifiques. Par exemple, pour
la distribution de l’Âge par Cluster, le cluster 0 est composé principalement de personnes âgées, ce qui
pourrait représenter des clients retraités ou des individus ayant des comportements financiers stables

75
Chapitre 4. Release 2

[Link]

Figure 4.22 : Distribution des variables par Cluster

alors que le cluster 2 est représenté majoritairement par des individus plus jeunes, probablement des
jeunes professionnels ou des étudiants avec des habitudes financières émergentes.

[Link] Variables dominants par Clusters

— Cluster 0 : Ce groupe peut représenter un certain profil démographique, par exemple, des
individus plus âgés avec des produits d’épargne justifiés.

— Cluster 1 : Ce segment peut inclure des individus plus jeunes avec une variété d’activités et de
produits.

— Cluster 2 : Peut être caractérisé par un canal de transaction particulier ou une distribution
nationale spécifique avec la présence des produits d’épargne non justifiés.

4.7.2 Interprétation des clusters

— Cluster 0 : Si ce cluster accorde une grande importance aux produits d’épargne et contient
des individus plus âgés, ce qui justifie et rend logique l’utilisation du produit épargne, ce cluster
peut représenter la classe de risque faible.

— Cluster 1 : Avec une population diversifiée, ce cluster peut représenter la classe de risque moyen.

— Cluster 2 : Un cluster avec une prédominance d’un certain canal ou nationalité avec la présence

76
Chapitre 4. Release 2

du produit épargne et une population plus jeune peut conduire vers la classe de risque élevé.

4.7.3 Prédiction d’un nouvel individu à un cluster

[Link]

Figure 4.23 : Distribution des Caractéristiques par Cluster

Pour prédire le cluster auquel appartient un nouvel individu, nous avons suivi les étapes
suivantes :

— 1- Encodage des variables catégorielles : Les variables catégorielles du nouvel individu

(telles que State, Product, Activity, Canal, Gender, nation, et nationality) sont encodées en
utilisant les mêmes encodeurs que ceux utilisés lors de l’entraînement du modèle.

— 3- Création de la variable d’importance pour le produit "épargne" : Une nouvelle

variable est ajoutée pour indiquer si le produit utilisé est "épargne".

— 4- Mise à l’échelle des variables : Les variables du nouvel individu sont mises à l’échelle en
utilisant le même scaler que celui utilisé lors de l’entraînement du modèle.

— 5- Prédiction du cluster : Le cluster du nouvel individu est prédit en utilisant le modèle

K-Means entraîné.

Exemple de Prédiction

Prenons l’exemple d’un nouvel individu avec les valeurs suivantes :

— State : Medenine

77
Chapitre 4. Release 2

— Product : épargne

— Activity : CONSTRUCTIONS TRAVAUX D’INSTALLATIONS DE BATIMENT

— Age : 30

— Canal : agence

— Gender : M

— nation : TUN

— nationality : LYB

Après encodage, mise à l’échelle et application du modèle K-Means, ce nouvel individu est
prédit appartenant au Cluster 2.
Cette approche permet de classer efficacement de nouveaux clients en fonction de leurs attributs
et d’adapter les stratégies de lutte contre le blanchiment d’argent et le financement du terrorisme en
conséquence.
Cette section montre comment une analyse de clustering peut aider à identifier et comprendre
les profils de risque dans le cadre de la lutte contre le blanchiment d’argent et le financement du
terrorisme. Les visualisations fournissent des insights clairs sur les caractéristiques des différents
clusters, permettant ainsi d’améliorer les stratégies de conformité et de surveillance du portefeuille
clients.

Conclusion

Dans ce chapitre, nous avons présenté la Release 2 avec une analyse détaillée et la conception
de chacun de ses sprints. Nous avons ensuite procédé à l’implémentation et à la réalisation des tâches
associées. De plus, nous avons décrit l’identification de la classe de risque. Dans le chapitre suivant,
nous aborderons la fusion client automatisée et le dashboarding

78
Chapitre 5

Release 3

Introduction

Comme pour la Release précédente, nous commencerons par présenter le Backlog de la Release
pour définir les tâches à réaliser suite à notre réunion avec le Product Owner. Ensuite, nous expliquerons
l’analyse et la conception détaillées de chaque sprint, suivies des interfaces de réalisation à la fin de
chaque sprint.

5.1 Backlog de la Release 3

Le tableau 5.1 énumère les différents sprints de la Release 3.

Nom du Sprint Numéro du Sprint

Fusion client automatisée Sprint 3.1

Dashboarding Sprint 3.2

Tableau 5.1 : Backlog de la Release 3

5.2 Analyse globale de la Release 3

Nous allons présenter le diagramme de cas d’utilisation global de la Release 3, illustré par la
figure 5.1.

79
Chapitre 5. Release 3

images/chap5/casd’[Link]

Figure 5.1 : Diagramme de cas d’utilisation global de la Release 3

5.3 Conception globale de la Release 3

Nous allons illustrer le diagramme de classes global de la Release 3 dans la figure 5.2.

80
Chapitre 5. Release 3

images/chap5/[Link]

Figure 5.2 : Diagramme de classes global de la Release 3

81
Chapitre 5. Release 3

.
Le tableau suivant 5.2 décrit les différents attributs de chaque classe de cette release :

Classes Attributs type Description

agentId entier désigne l’identifiant unique de l’agent

ComplianceAgent name String désigne le nom de l’agent de conformité
email String désigne l’adresse email de l’agent de conformité

totalClients entier désigne le nombre total de clients.

Statistics sanctionedPersons entier désigne la date de création de la facture
sousTotal réel désigne le nombre de personnes sanctionnées.
matchesFound entier désigne le nombre de correspondances trouvées.

Tableau 5.2 : Dictionnaire de données de la Release 3

5.4 Sprint 3.1 : Fusion client automatisée

Nous allons commencer par présenter le backlog du sprint, puis exposer les diagrammes de
conception, et enfin présenter quelques interfaces réalisées lors du sprint 3.1.

5.4.1 Backlog du Sprint 3.1

Le tableau 5.3 présente notre backlog du sprint 3.1

Estim-
ID ID
Fonctionnalités User Story Tâche ation
US Tâche
(Heures)
28.1 Création de l’interface fusion client avec un
En tant qu’agent de conformité, je
bouton pour lancer le robot de fusion des fiches
Fusion Client souhaite lancer un robot pour
US28 clients 40
Automatisée effectuer la fusion des fiches clients en
28.2 Mise en place de l’API Flask pour déclencher
doublons.
le robot UiPath
28.3 Configuration et développement du robot
UiPath pour la détection et la fusion des
doublons
28.4 Stockage des résultats de la fusion dans la base
de données
28.5 Journalisation des actions du robot de fusion
(log des opérations de fusion, horodatage, etc.)

Tableau 5.3 : Backlog du Sprint 3.1

82
Chapitre 5. Release 3

5.4.2 Analyse détaillée du Sprint 3.1

Dans cette partie, nous allons présenter le diagramme de cas d’utilisation raffiné du Sprint 3.1,
puis expliquer en détail les différentes fonctionnalités à réaliser durant ce sprint.

[Link] Diagramme de cas d’utilisation raffiné du Sprint 3.1

La figure 5.3 représente le diagramme de cas d’utilisation raffiné du Sprint 3.1

images/chap5/[Link]

Figure 5.3 : Diagramme de cas d’utilisation raffiné du Sprint 3.1

[Link] Descriptions textuelles

Dans le tableau 5.4 , nous avons présenté une description textuelle de notre cas d’utilisation.

Cas d’utilisation Modifier fiche client

Acteurs Agent de conformité , robot

Pré-conditions Le robot est authentifié dans CITRIX et GIAS .

Le robot est configuré et prêt à être lancé

83
Chapitre 5. Release 3

Fichier Excel contenant les fiches doublons des clients est accessible.

Post-conditions Les fiches clients doublons sont fusionnées avec succès dans le système GIAS.

Scénario nominal 1- L’agent de conformité lance le robot.

2- Le robot se connecte à Citrix
3- Le robot se connecte à GIAS via Citrix.
4- Le robot recherche les informations du client dans GIAS en utilisant le
numéro CIN.
5- Le robot vérifie le nombre de fiches clients disponibles dans GIAS.
6- Le robot ouvre le fichier Excel contenant les fiches doublons des clients.
7-Le robot vérifie quelle fiche est la plus complète en utilisant le fichier Excel.
8- Le robot envoie un rapport de fusion des fiches clients.

Scénario alternatif 1- Si aucune fiche complète n’est trouvée dans le fichier Excel : - Le robot
alerte l’agent de conformité de l’absence de fiches complètes.
2- Si la fusion des fiches échoue dans GIAS : - Le robot alerte l’agent de
conformité de l’échec de la fusion.

Tableau 5.4 : Description textuelle du cas d’utilisation "Fusion fiche client automatisée"

5.4.3 Conception du Sprint 3.1

[Link] Diagramme de séquence détaillé

Nous passons à la conception de ce sprint avec le diagramme de séquences. La figure 5.16

montre le diagramme détaillé pour ’Fusion client automatisé’.

84
Chapitre 5. Release 3

images/chap5/[Link]

Figure 5.4 : Diagramme de séquences détaillé du cas d’utilisation "fusion client automatisée"

5.4.4 Réalisation du Sprint 3.1

Dans cette partie, nous allons présenter quelques interfaces réalisées du Sprint 3.1.

85
Chapitre 5. Release 3

images/captures/fusion client/[Link]

Figure 5.5 : Interface"fusion client automatisée"

images/captures/fusion client/[Link]

Figure 5.6 : Interface"fusion client automatisée"

images/captures/fusion client/Capture dâĂŹÃľcran (5).png

Figure 5.7 : Interface"fusion client automatisée"

86
Chapitre 5. Release 3

images/captures/fusion client/Capture dâĂŹÃľcran (7).png

Figure 5.8 : Interface"fusion client automatisée"

images/captures/fusion client/Capture dâĂŹÃľcran (9).png

Figure 5.9 : Interface"fusion client automatisée"

87
Chapitre 5. Release 3

images/captures/fusion client/[Link]

Figure 5.10 : Interface"fusion client automatisée"

images/captures/fusion client/Capture dâĂŹÃľcran (10).png

Figure 5.11 : Interface"fusion client automatisée"

88
Chapitre 5. Release 3

images/captures/fusion client/Capture dâĂŹÃľcran (11).png

Figure 5.12 : Interface"fusion client automatisée"

images/captures/fusion client/Capture dâĂŹÃľcran (13).png

Figure 5.13 : Interface"fusion client automatisée"

89
Chapitre 5. Release 3

images/captures/fusion client/Capture dâĂŹÃľcran (9).png

Figure 5.14 : Interface"fusion client automatisée"

5.5 Sprint 3.2 : Dashbording

Nous présenterons d’abord le Backlog du sprint, puis le diagramme de conception, et enfin

quelques interfaces réalisées du sprint 3.2."

5.5.1 Backlog du Sprint 3.2

Le tableau 5.5 décrit le backlog du sprint 3.2 .

Estim-
ID ID
Fonctionnalités User Story Tâche ation
US Tâche
(Heures)
En tant qu’utilisateur connecté, je 29.1 Création de l’interface utilisateur pour
souhaite visualiser le nombre de visualiser le dashboard
Dashboarding US29 clients, le nombre de personnes 29.2 Développement des requêtes pour extraire les 5
sanctionnées, le nombre de données nécessaires à partir de la base de
correspondances trouvées, etc. données
29.3 Développement des widgets pour visualiser
les statistiques (nombre de clients, personnes
sanctionnées, etc.)
29.4 Intégration de graphiques et de tableaux pour
une visualisation claire et interactive des
statistiques
29.5 Mise en place des mécanismes de mise à jour
en temps réel des données affichées sur le
dashboard

Tableau 5.5 : Backlog du Sprint 3.2

90
Chapitre 5. Release 3

5.5.2 Analyse détaillée du Sprint 3.2

Nous allons d’abord présenter le diagramme de cas d’utilisation raffiné du Sprint 3.2, puis
expliquer en détail la fonctionnalité à réaliser pendant ce sprint..

[Link] Diagramme de cas d’utilisation raffiné du Sprint 3.2

images/chap5/[Link]

Figure 5.15 : Diagramme de cas d’utilisation raffiné du Sprint 3.2 "Dashboarding"

5.5.3 Conception du Sprint 3.2

Nous passons maintenant à la conception de ce sprint, en présentant une vue dynamique avec
le diagramme de séquences. La figure 5.16 illustre en détail le diagramme de séquences pour le cas
d’utilisation ’Dashboarding’

91
Chapitre 5. Release 3

images/chap5/[Link]

Figure 5.16 : Diagramme de séquence Sprint 3.2 "Dashboarding"

5.5.4 Réalisation du Sprint 3.2

Dans cette partie, nous allons présenter quelques interfaces réalisées du Sprint 3.2.

images/captures/dash/[Link]

Figure 5.17 : Interface"Dashboard"

92
Chapitre 5. Release 3

images/captures/dash/[Link]

Figure 5.18 : Interface"Dashboard"

images/captures/dash/[Link]

Figure 5.19 : Interface"Dashboard"

5.6 Test et validation

Cette release a été testée et validée avant livraison. La validation a été confirmée lors de réunions
mensuelles avec le product owner et le scrum master.

Conclusion

Dans ce chapitre, nous avons présenté la Release 3 avec une analyse détaillée et la conception
de chacun de ses sprints, suivies de l’implémentation et de la réalisation de toutes les fonctionnalités
demandées.

93
Conclusion Générale et Perspectives

Ce rapport synthétise les efforts et les réalisations de mon projet de fin d’études, dédié à la
conception et à la mise en œuvre d’une application KYC avancée pour le secteur de l’assurance
chez BH Assurance Tunisie. Ce projet a été construit autour de l’utilisation de technologies de
pointe telles qu’Angular pour le frontend, Flask pour le backend, et SQL Server pour la gestion des
données. L’application intègre des fonctionnalités complexes, notamment la vérification des clients,
l’automatisation des processus de fusion des fiches clients à l’aide de la Robotic Process Automation
(RPA) avec UiPath Studio, et le calcul du score de risque à l’aide de techniques de machine learning.
La réalisation de ce projet a été une expérience profondément enrichissante, offrant l’opportunité
d’appliquer concrètement des compétences techniques avancées dans un contexte réel. Grâce à une
approche basée sur la méthodologie Agile Scrum, nous avons pu développer l’application de manière
itérative, permettant une flexibilité et une adaptabilité aux besoins évolutifs du projet.
Parmi les fonctionnalités clés développées, l’application permet la vérification et l’identification
des clients grâce à l’algorithme de similarité de Levenshtein pour rechercher des personnes blacklistées,
l’automatisation des processus de fusion des fiches clients, et un tableau de bord pour suivre les
recherches KYC, les vérifications clients, et la segmentation des risques des clients. Ces éléments
constituent le cœur de l’application .
Sur le plan technique, ce projet a représenté une occasion inestimable d’approfondir ma maîtrise
de frameworks et de technologies modernes. La combinaison d’Angular et de Flask a offert une base
solide pour le développement, tandis que l’utilisation de SQL Server a assuré une gestion des données
fiable et efficace. Ce projet a également été l’occasion de développer des compétences en matière de
collaboration professionnelle, de gestion de projet, et de résolution de problèmes complexes.
L’implémentation du machine learning pour l’identification de la classe de risque a été une
composante clé de ce projet. Cette section a inclus l’analyse de clustering effectuée sur les données
KYC pour identifier des groupes distincts de clients dans le cadre de la lutte contre le blanchiment
d’argent (AML) et le financement du terrorisme (FTF). Les étapes comprenaient le prétraitement des
données, l’encodage des variables catégorielles, la normalisation des variables numériques, l’attribution

94
Conclusion générale et perspectives

de l’importance au produit épargne, la réduction de dimensionnalité, les visualisations, l’interprétation

des clusters, et la prédiction d’un nouvel individu à un cluster. Pour cette analyse, nous avons utilisé
des bibliothèques telles que pandas, numpy, sklearn (StandardScaler, LabelEncoder, KMeans, TSNE),
matplotlib, et seaborn.
En regardant vers l’avenir, plusieurs pistes d’amélioration peuvent être envisagées pour enrichir
encore l’application. L’optimisation des algorithmes de machine learning pour augmenter la précision
et la fiabilité des prédictions de risques, l’extension des capacités de vérification pour une meilleure
conformité, et l’ajout de nouvelles fonctionnalités pour améliorer l’expérience utilisateur sont autant
de domaines prometteurs. De plus, intégrer un système de récompense pour les clients fidèles pourrait
aider à assurer la pérennité de l’application.

95
Netographie

[1] BH Group. [Consulté le 29 Mars 2024]. url : [Link]

[2] Chiffres BH Assurance. [Consulté le 28 Mars 2024]. url : [Link]

chiffres/.

[3] Pratiques DevOps : Etre Agile sans DevOps ne sert à rien ([Link]). consulté le 30/03/2024.
url : [Link] big- data/etre- agile- sans- devops- ne-
sert-a-rien/.

[4] Définition agile Scrum. consulté le 30/03/2024. url : [Link]

[5] Memoire Online - Mise en place d’une architecture 3 tiers avec base de données centralisée
sous SQL SERVER : Cas d’une Gestion immobilière - Abdou Khadre Diop Kane. consulté le
25/03/2024. url : [Link]
architecture- 3- tiers- avec- base- de- donnees- centralisee- sous- SQL- SERVER- Cas-
[Link].

[6] Système de gestion de bases de données (SGBD) : cours de Tle ([Link]). consulté le
22/03/2024. url : [Link]
donnees-sgbd-/fiche-de-cours.

[7] HTTP REST. [Consulté le 05 Avril 2024]. url : [Link]

[8] Memoire Online - Site web de gestion de location et colocation dans le domaine de l’immobilier.
- Chafik Ahmadi. consulté le 20/05/2024. url : [Link]
12799/Site - web- de - gestion - de - location - et - colocation - dans - le - domaine - de - l -
[Link].

[9] Angular. [Consulté le 09 Mai 2024]. url : [Link]

angular.

[10] keycloak. [Consulté le 05 Mai 2024]. url : [Link]

[11] Visual Studio Code. [Consulté le 09 Mai 2024]. url : [Link]

96
Netographie

[12] postman. [Consulté le 02 Mai 2024]. url : [Link]

[13] github. [Consulté le 19 Mai 2024]. url : [Link]

[14] Jira. [Consulté le 06 Mai 2024]. url : [Link]

[15] David Arthur et Sergei Vassilvitskii. “k-means++ : The advantages of careful seeding”. In :
Proceedings of the Eighteenth Annual ACM-SIAM Symposium on Discrete Algorithms. 2007.

[16] Martin Ester et al. “A Density-Based Algorithm for Discovering Clusters in Large Spatial
Databases with Noise”. In : Proceedings of the 2nd International Conference on Knowledge
Discovery and Data Mining (KDD-96). 1996.

[17] Fei Tony Liu, Kai Ming Ting et Zhi-Hua Zhou. “Isolation Forest”. In : 2008 Eighth IEEE
International Conference on Data Mining. 2008.

[18] Christopher M. Bishop. Pattern Recognition and Machine Learning. New York, NY, USA :
Springer, 2006. isbn : 978-0-387-31073-2.

[19] Hans-Hermann Bock. “Origins and extensions of the k-means algorithm in cluster analysis”.
In : Electronic journal for history of probability and statistics 4.2 (2008), p. 1-18.

[20] Laurens Van Der Maaten. “t-SNE”. In : Recuperado de https ://lvdmaaten. github. io/tsne
(2019).

[21] Pentalog. Être agile sans DevOps ne sert à rien. Accessed : 2024-05-18. 2020. url : https:
//[Link]/blog/cloud-big-data/etre-agile-sans-devops-ne-sert-a-rien/.

[22] BH Assurance. [Consulté le 29 Mars 2024]. url : https : / / bh - assurance . com / notre -
compagnie/.

[23] Dharmendra S Modha et W Scott Spangler. “Feature weighting in k-means clustering”. In :

Machine learning 52 (2003), p. 217-237.

[24] MÉTHODE SCRUM. [Consulté le 21 Mars 2024]. url : [Link]

agile-scrum/.

[25] principe de base. [Consulté le 11 Mars 2024]. url : [Link]

2015/01/methodes-agiles-definition/.

[26] Introduction aux méthodes agiles et Scrum. [Consulté le 01 Mars 2024]. url : https : / /
[Link]/introduction-methodes-agiles/.

[27] Définition eXtreme Programming. consulté le 30/04/2024. url : [Link]

97
Netographie

[28] Guide de la méthode Agile scrum : avantages, défis, etc. - Agily. consulté le 30/03/2024. url :
[Link]
business/methode-agile-scrum/.

[29] What is Deployment Diagram ? [Consulté le 01 mars 2024]. url : https : / / www . visual -
[Link]/guide/uml-unified-modeling-language/what-is-deployment-diagram/.

[30] Python. [Consulté le 15 Mai 2024]. url : [Link]

98