Rapport Pfe Vneuron-Scrum

République Tunisienne
Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
Université de Tunis El Manar
Institut Supérieur d’Informatique d’El Manar
Rapport de Projet de Fin d’Études
Présenté en vue de l’obtention du
Master Profissionnel
Spécialité : Sécurité des Systèmes Informatiques Communicants et embarqués
Par
Brahim BAHAIDA
Conception et Développement d’une Plate-forme de

Management de la Qualité des Données
Encadrant professionnel : Monsieur Ghassen HAMROUNI Directeur Associé

Encadrant académique : Madame Rim KAABI Maître Assistante
Réalisé au sein de Vneuron
Année Universitaire 2018 - 2019

République Tunisienne
Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
Université de Tunis El Manar
Institut Supérieur d’Informatique d’El Manar
Rapport de Projet de Fin d’Études
Présenté en vue de l’obtention du
Master Profissionnel
Spécialité : Sécurité des Systèmes Informatiques Communicants et embarqués
Par
Brahim BAHAIDA
Conception et Développement d’une Plate-forme de

Management de la Qualité des Données
Encadrant professionnel : Monsieur Ghassen HAMROUNI Directeur Associé

Encadrant académique : Madame Rim KAABI Maître Assistante
Réalisé au sein de Vneuron
Année Universitaire 2018 - 2019

J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.
Encadrant professionnel, Monsieur Ghassen HAMROUNI
Signature et cachet
J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.
Encadrant académique, Madame Rim KAABI
Signature
Dédicaces
Je dédie ce travail à :
À la personne que je ne peux pas vivre sans elle, la personne qui m’a prodigué sa vie. son
soutien, son amour, son temps. à la raison de ma vie, ma mère Khady.
À mon cher père Mohamed, à mes chères sœurs Mariem, Mina, Tbeira et Cherifa et à
toute ma chère famille.
À tous mes ami(e)s, en hommage à tous les instants que nous avons vécus ensemble.
À tous les personnes qui m’ont donné un coup de pouce, de près ou de loin.
Je dédie ce travail, en signe de ma profonde gratitude et de mon admiration.
Brahim BAHAIDA
ii
Remerciements
Tout d’abord, je tiens à remercier Dieu le Tout-Puissant, qui m’a donné la
force et la patience pour accomplir ce travail.

Je tiens également à exprimer la reconnaissance de tous mes professeurs de
l’Institut Supérieur d’Informatique qui n’ont cessé de m’aider.

Je tiens également à exprimer mes sincères remerciements et toute ma
reconnaissance à Madame Rim KAABI pour son inspiration et son soutien

tout au long de la mission mentionnée dans ce rapport, qu’elle m’a apporté
lors des différents suivis.

Je remercie en particulier Monsieur Ghassen HAMROUNI de m’avoir
intégré si rapidement dans l’entreprise et de m’avoir pleinement soutenu, pour

le temps qu’il m’a consacré tout au long de cette période, en répondant à
toutes mes questions.

Mes remerciements vont également à tous les membres de la société Vneuron
pour leur courtoisie et leur soutien ainsi que pour leur hospitalité. Finalement,
je profite de cette occasion pour remercier les membres du jury dans l’espoir
qu’ils trouveront dans ce rapport les qualités de clarté et de motivation qu’ils

attendent.
Brahim BAHAIDA
iii
Table des matières
Introduction générale 1
1 Présentation Générale du Projet 2

1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Étude et critique de l’éxistant . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 Méthode de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.1 Méthode Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.2 Méthode adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.3 Développement guidé par les tests . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.4 Intégration continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.5 Automatisation de la vérification de la qualité du code . . . . . . . . . . . . . 14
1.3.6 Automatisation de la détection des vulnérabilités . . . . . . . . . . . . . . . . 15
2 Analyse et spécification des besoins 16

2.1 Les roles Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Modelisation des besions fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5.1 Diagramme de packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5.2 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . . . . . . 31
2.5.3 Raffinement et description textuelle des cas d’utilisation . . . . . . . . . . . . 32
2.6 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
iv
3 Initialisation du projet 36
3.1 Initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.1 Diagramme de packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.2 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4 Environnements de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.2 Environnement technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.5 Installation et configuration de l’environnement de travail . . . . . . . . . . . . . . 44
4 Mise en œuvre du release 1 Vérifications classiques de la qualité des données 46

4.1 Sprint 1 : Configuration des bases de données . . . . . . . . . . . . . . . . . . . . . . 47
4.1.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1.5 Test et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1.6 Problèmes rencontrés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2 Sprint 2 : Configuration du job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3 Sprint 3 : Effectuer des contrôles simples de qualité . . . . . . . . . . . . . . . . . . . 60
4.3.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
v
4.3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.4 Sprint 4 : Effectuer des contrôles complexes de qualité . . . . . . . . . . . . . . . . . 69
4.4.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5 Mise en oeuvre du release 2 Vérifications de la qualité des données basée sur la

NLP 77
5.1 Sprint 5 : Effectuer des contrôles génériques et basés sur NLP de qualité . . . . . . . 78
5.1.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.1.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.1.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.2 Sprint 6 : Visualisation des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.2.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.3 Sprint 7 : Gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.3.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
vi
5.4 Sprint 8 : Visualisation des graphes d’amélioration . . . . . . . . . . . . . . . . . . . 98
5.4.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Conclusion générale 104
Bibliographie 105
vii
Table des figures
1.1 Logo d’Informatica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Logo d’Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Logo de SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Logo de SAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Logo de Talend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Diagramme de contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7 Diagramme de niveau 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.8 Etapes de développement guidé par les tests . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Diagramme de navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Diagramme de packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 Diagramme des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 Diagramme de packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.5 Processus de validation du code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1 Interface d’autentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2 Interface d’ajout d’une nouvelle base de données . . . . . . . . . . . . . . . . . . . . 49
4.3 Diagramme de séquence «Authentification» . . . . . . . . . . . . . . . . . . . . . . . 50
4.4 Diagramme de séquence «Ajouter une nouvelle base de données» . . . . . . . . . . . 50
4.5 Diagramme de classe «Couche d’accès aux données - Sprint 1» . . . . . . . . . . . . . 51
4.6 Diagramme de classe «Couche logique métier - Sprint 1» . . . . . . . . . . . . . . . . 52
4.7 Diagramme de classe «Couche de présentation - Sprint 1» . . . . . . . . . . . . . . . 52
4.8 Page d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.9 Page de paramètres des jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.10 Page d’ajout d’une nouvelle base de données . . . . . . . . . . . . . . . . . . . . . . . 54
4.11 Page de la liste des bases de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
viii
Table des figures
4.12 Interface d’ajout un nouveau job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.13 Diagramme de séquence «Chargement des tables» . . . . . . . . . . . . . . . . . . . . 58
4.14 Diagramme de séquence «Chargement des colonnes» . . . . . . . . . . . . . . . . . . 58
4.15 Page de sélection des tables et les colonnes . . . . . . . . . . . . . . . . . . . . . . . . 59
4.16 Architecture de NgRX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.17 Interface de planification du programme d’exécution des jobs . . . . . . . . . . . . . 62
4.18 Diagramme de séquence «Execution d’un controle de quality - NOTNULL» . . . . . 63
4.19 Diagramme de séquence «Planification du programme d’exécution des jobs» . . . . . 64
4.20 Diagramme de séquence «Instantiation des contrôleurs de qualité» . . . . . . . . . . 64
4.24 Page de planification du programme d’exécution des jobs . . . . . . . . . . . . . . . . 67
4.25 Architecture de Quartz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.26 Diagramme de séquence «Execution d’un controle de quality - EMAIL» . . . . . . . 71
4.27 Diagramme de séquence «Execution d’un controle de quality - AGE» . . . . . . . . . 72
4.28 Diagramme de séquence «Execution d’un controle de quality - INTERVAL» . . . . . 73
4.30 Page d’ajout d’une liste de configurations . . . . . . . . . . . . . . . . . . . . . . . . 75
4.31 Page d’affichage de la liste de configurations . . . . . . . . . . . . . . . . . . . . . . . 75
5.1 Diagramme de séquence «Execution d’un controle de quality - PATTERN» . . . . . 80

5.2 Diagramme de séquence «Execution d’un controle de quality - NAME» . . . . . . . . 81
5.4 Page d’ajout d’une liste de configurations . . . . . . . . . . . . . . . . . . . . . . . . 83
5.5 Interface d’affichage des resultats de contrôles de qualité . . . . . . . . . . . . . . . . 85
5.6 Diagramme de séquence «Chargement des jobs» . . . . . . . . . . . . . . . . . . . . . 86
5.7 Diagramme de séquence «Chargement des configurations» . . . . . . . . . . . . . . . 86
5.8 Diagramme de séquence «Chargement des contrôles» . . . . . . . . . . . . . . . . . . 87
5.9 Diagramme de séquence «Affichage des résultats» . . . . . . . . . . . . . . . . . . . . 87
ix
5.13 Page d’affichage des résultats des contrôles . . . . . . . . . . . . . . . . . . . . . . . . 90
5.14 Interface d’ajout d’un nouvel utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.15 Interface de modification les informations d’un utilisateur . . . . . . . . . . . . . . . 93
5.16 Interface de consultation de la liste des utilisateurs . . . . . . . . . . . . . . . . . . . 93
5.17 Diagramme de séquence «Ajouter un nouvel utilisateur» . . . . . . . . . . . . . . . . 94
5.18 Diagramme de séquence «Modifier les informations d’un utilisateur» . . . . . . . . . 94
5.19 Diagramme de séquence «Supprimer un utilisateur» . . . . . . . . . . . . . . . . . . 95
5.20 Diagramme de séquence «Consulter la liste des utilisateurs» . . . . . . . . . . . . . . 95
5.21 Page d’ajout d’un nouvel utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.22 Page de consultation de la liste des utilisateurs . . . . . . . . . . . . . . . . . . . . . 97
5.23 Page de modification des informations d’un utilisateur . . . . . . . . . . . . . . . . . 97
5.24 Page de supprission d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.25 Interface de consultation des graphes visualisant l’état de qualité des données . . . . 99
5.26 Diagramme de séquence «Visualisation du Line-Graph» . . . . . . . . . . . . . . . . 100
5.27 Diagramme de séquence «Visualisation du Bar-Graph» . . . . . . . . . . . . . . . . . 100
5.30 Page de consultation des graphes visualisant l’état de qualité des données . . . . . . 103
x
Liste des tableaux
2.1 Baklog produit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.2 Description textuelle du cas d’utilisation « Ajouter la planification des jobs » . . . . 33
2.3 Description textuelle du cas d’utilisation « Ajouter une nouvelle base de données » . 34
2.4 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1 Baklog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2 Tests fonctionnels du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3 Baklog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.5 Baklog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.7 Baklog du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.1 Baklog du sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.3 Baklog du sprint 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.5 Baklog du sprint 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.7 Baklog du sprint 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
xi
Liste des abréviations
— BI = Business Intelligence
— DFD = Data Flow Diagrams
— DQ = Data Quality
— DQM = Data Quality Management
— EF = Exigence Fonctionnelle
— SoD = Separation of Duties
— W3C = World Wide Web Consortium
— WAI = Web Accessibility Initiative
— WCAG = Web Content Accessibility Guidelines
xii
Introduction générale
Travaillant depuis des années avec des données provenant d’institutions financières, Vneuron
a découvert que les données de plusieurs de ces entreprises sont de piètre qualité, même après avoir
utilisé certains outils de qualité des données, ce qui pourrait mener à de mauvaises décisions.
Vneuron nous a accordé donc sa confiance pour mettre en place une solution qui résout les
problèmes de ces entreprises en combinant l’expérience de Vneuron et les capacités des nouvelles
technologies telles que la Machine Learning et NLP.
L’objectif de ce projet est de concevoir et de développer une plateforme de gestion et d’amélioration
de la qualité des données qui permettra aux institutions financières d’améliorer leur conformité
réglementaire.
Ce rapport présentera les différentes phases de la réalisation de ce projet et se répartira en
cinq chapitres :
— chapitre 1 : sera un chapitre introductif dans lequel nous décrirons brièvement l’entreprise.
Ensuite, nous présenterons les grandes lignes du projet et la solution proposée.
— chapitre 2 : décrira comment ce travail sera réalisé en utilisant la méthodologie Scrum.

Nous identifierons également les exigences fonctionnelles dans un backlog de produit et nous
les illustrerons, ensuite, avec des diagrammes de cas d’utilisation et de packages avec une
description plus détaillée de quelques scénarios, suivie par la description des besoins non
fonctionnels de notre application. Ensuite, nous définirons la planification des sprints.
— chapitre 3 : sera consacré à la phase d’initialisation du projet et de mise en place de

l’environnement de développement, de l’architecture ainsi que de l’environnement matériel
et logiciel.
— chapitres 4 et 5 : seront dédiés aux deux releases de notre application où nous nous
intéresserons à la réalisation de sprints, chacun composé de quatre parties qui sont l’analyse,
la conception, la réalisation et le test.
Finalement, nous clôturerons ce rapport par une conclusion générale dans laquelle nous
évaluerons les résultats obtenus et décrirons les perspectives possibles pour ce projet.
1
Chapitre 1
Présentation Générale du Projet
Plan
1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . 3
2 Présentation du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Méthode de développement . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Chapitre 1. Présentation Générale du Projet
Introduction
Nous présenterons dans le premier chapitre le travail dans son contexte général. Il se compose
de trois parties. La première vise à présenter l’organisation d’accueil Vneuron, la deuxième à présenter
la problématique et la solution proposée et la dernière partie à expliquer le choix méthodologique.
1.1 Présentation de l’organisme d’accueil
IP-Tech est une société offshore qui a été fondée par Mohamed Ouederni et Feteh Belhaj
Ali, deux anciens élèves de l’Ecole Polytechnique de Tunisie, à la fin de 2007, après s’être "aguerris"
pendant une dizaine d’années sur le marché parisien. Cette startup est spécialisée dans le développement
des solutions IT. Elle compte déjà une trentaine d’ingénieurs, d’expériences et de compétences
différentes[1].
Afin de rassembler sous une même entité l’ensemble des services et solutions indispensables à
la gestion scientifique et la transformation digitale, IPTECH et AYD, deux entreprises actives depuis
10 ans, comptant une centaine de collaborateurs et leader dans leur secteur en Tunisie, en Afrique
du Nord et Subsaharienne se fondent sous une même ombrelle, Vneuron.
Vneuron a développé son approche innovante, le SPARK THINKING basé sur l’écoute active,
l’expertise et la maitrise des nouvelles technologies de pointes comme l’intelligence artificielle et
l’apprentissage automatique. Vneuron développe et implémente ses technologies adéquates les SPARK
SOLUTIONS, pour éditer à la perfection des réponses plus qu’adaptées dans les métiers du Banking,
Finance, Assurance, Santé, Grande distribution, Industrie et Gouvernance.
Vneuron est aussi une GREAT PLACE TO WORK, l’entreprise est génératrice d’emplois et accorde
une attention particulière au bien-être de l’ensemble de ses collaborateurs. [2]
1.2 Présentation du Projet
Ce projet s’inscrit dans le cadre de notre projet de fin d’études à l’Institut Supérieur d’Informatique,
dans le but d’obtenir un master professionnel en Sécurité des Systèmes Informatiques Communicants
et Embarqués. L’application demandée est intitulée "Data Quality Management Platform". Elle a
pour objectif de concevoir et de développer une plate-forme de gestion et d’amélioration de la qualité
des données. Cette application est destinée aux institutions financières pour améliorer leur conformité
réglementaire.
3
1.2.1 Problématique
Afin de maintenir une bonne relation avec les clients et de réaliser des profits, les organisations
doivent assurer un niveau élevé de la qualité de leurs données.
Les données sont-elles complètes ? Sont-elles collectées à temps ? Sont-elles correctes ? Ce sont
des questions qui doivent être posées lors de l’analyse des données. La mauvaise qualité des données
peut prendre de nombreuses formes : non seulement des chiffres incorrects, mais aussi un manque
d’exhaustivité ou des données trop anciennes (pour une utilisation utile).
La qualité des données peut être décrite comme un problème multidisciplinaire concernant,
par exemple, des sujets en informatique, le contrôle de la qualité, la recherche sur les facteurs humains
et les statistiques. Mais, ce sont surtout les institutions financières qui souffrent actuellement parce
que la mauvaise qualité des données a des conséquences importantes pour une entreprise, comme
une mauvaise prise de décision ou le fait de ne pas avoir profité des opportunités du marché [3].
Les mauvaises données font perdre du temps, augmentent les coûts, affaiblissent la prise de décision,
irritent les clients et rendent plus difficile l’exécution de toute stratégie de données. En effet, les
données ont un problème de crédibilité.
Les causes principales des problèmes de qualité des données sont les suivantes [4] :
• Saisie des données par les employés : Rien d’étonnant que la cause principale soit l’erreur
humaine. Au fur et à mesure que les distractions augmentent et que l’attention diminue, il est
très peu probable que les données soient saisies de façon plus précise.
• Projets de migration et de conversion de données : La migration des données vers de

nouveaux systèmes comporte un risque implicite pour la qualité des données.
• Entrées mixtes par plusieurs utilisateurs : Les instructions sur la façon dont les données
doivent être entrées sont sujettes à interprétation, de sorte que des personnes différentes
remplissent parfois un champ de façon incorrecte sans même s’en rendre compte.
• Modifications des systèmes sources : Comme les organisations font, de plus en plus,
appel à des tiers pour gérer les applications développées en interne, cette connaissance associée
de la sémantique de l’application n’est pas communiquée à la tierce partie. Lorsque des tiers
apportent des modifications au fonctionnement d’une application, ils peuvent, par inadvertance,
nuire à l’intégrité des données qu’elle utilise.
• Erreurs de système : Les systèmes traditionnels étaient moins susceptibles de corrompre les
4
données car ils étaient plus simples. Au fur et à mesure que les applications deviennent de plus
en plus complexes et sont distribuées sur un plus grand nombre d’ordinateurs, les corruptions
de données sont devenues plus fréquentes et plus difficiles à isoler et à réparer.
Une seule erreur d’entrée de données peut entraîner une corrélation modérée à zéro et un
résultat significatif d’un TEST-T peut être insignifiant [5]. Une étude récente de Gartner a révélé
que pour les entreprises, la mauvaise qualité des données se traduit par une perte moyenne d’environ
15 millions de dollars [3]. Et une autre étude réalisée par IBM en 2016 a estimé qu’aux États-Unis,
les coûts annuels totaux résultant de la mauvaise qualité des données dépassent les 3 milliards de
dollars américains [3]. Selon une étude de Harvard Business Review, seulement 3% des données des
entreprises satisfont aux normes de qualité de base [6].
Considérant l’importance d’atteindre et de maintenir un niveau élevé de qualité des données,
car la mauvaise qualité des données influence les processus décisionnels au sein d’une organisation et
peut entraîner un risque de non-conformité, il n’est pas surprenant que le domaine de la gestion de
la qualité des données comporte plusieurs outils et méthodes pour évaluer et améliorer cette dernière
[3].
Notre travail se concentrera sur l’amélioration de la qualité des données par l’utilisation
des nouvelles capacités technologiques telles que la Machine Learning pour vérifier si les données
correspondent réellement aux intentions de l’entreprise. Ce travail n’inclura pas l’automatisation
de l’amélioration de la qualité des données, mais il sera utile pour identifier les données de qualité
douteuse et alerter les propriétaires de données afin qu’ils puissent facilement les traiter
1.2.2 Étude et critique de l’éxistant
Comme mentionné ci-dessus, il existe une variété d’outils disponibles pour évaluer et améliorer
la qualité des données. Dans cette section, nous analyserons les meilleurs et les plus célèbres outils
qui existent sur le marché et pour faire une étude raisonnable de tous les outils, nous énumérerons
pour chacun d’entre eux ses points forts et ses limites.
• Informatica : Informatica propose une série de produits d’intégration de données dans le cadre
de sa plate-forme Informatica Intelligent Data Platform. Ces produits sont : PowerCenter,
PowerExchange, Data Replication, B2B Data Transformation, B2B Data Exchange, Data
Integration Hub, Data Services, Integration Cloud Services, Cloud Integration Hub, Big Data
5
Management, Big Data Integration Hub, Big Data Streaming, Enterprise Data Lake, Edge Data
Streaming, Enterprise Data Catalog and Operational Insights. La base de clients d’Informatica
pour cet ensemble de produits est estimée à plus de 9 000 organisations [7].
Figure 1.1: Logo d’Informatica
Informatica Data Quality (IDQ) a été l’un des leaders sur le marché des outils de qualité de
données (DQ). IDQ a 2 variantes [8] :
— Informatica analyst est un outil Web qui peut être utilisé par les analystes et les
développeurs pour analyser, profiler, nettoyer, standardiser les données et les scorescards
dans une entreprise.
— Informatica developer est un outil client permettant aux développeurs de créer des
mappings pour implémenter des transformations/services de qualité des données. Cet
outil offre un éditeur où les objets peuvent être construits avec un large éventail de
transformations de qualité de données telles que Parser, normalisateur, validateur d’adresses,
match-merge, etc.
Points forts [7] [9]
— Informatica continue à mettre en œuvre une stratégie produit forte qui répond bien aux
exigences du marché en matière de gestion des données.
— Informatica propose des services d’appariement, de standardisation, " address doctor "
et de gestion des fichiers d’anomalies.
— la validation du point de livraison d’IDQ est très puissante et de nombreux outils concurrentiels
n’offrent pas ce service.
Limites [7] [9]
— les clients ont de la difficulté pour aligner les cas d’utilisation avec les offres de produits.
— la perception d’un coût élevé est toujours présente.
— l’outil est un outil de profiling complètement déconnecté du flux ETL, donc pas de
traitement en temps réel.
6
— il n’y a pas de gestion d’alertes
— l’outil de planification intégré a de nombreuses contraintes telles que la gestion des scripts
Unix/VB, etc. La plupart des entreprises utilisent pour cela des outils tiers.
— trop lente performance en cas d’utilisateurs multiples.
• Oracle : Enterprise Data Quality (EDQ) est la solution complète d’Oracle pour la gouvernance
et la gestion de la qualité des données. Il fait partie de la gamme de produits Oracle Fusion
Middleware [10].
Figure 1.2: Logo d’Oracle
Oracle propose les produits d’intégration de données suivants : Oracle Data Integration Platform
Cloud, Oracle GoldenGate (OGG), Oracle GoldenGate Cloud, Oracle Data Integrator (ODI),
Oracle Big Data SQL et Oracle Service Bus. Gartner estime à plus de 11 000 le nombre de
clients d’Oracle pour cet ensemble de produits [7].
— nouvelle attractivité pour les métiers de l’entreprise
— restructuration de la tarification en fonction du marché.
— synergies et amélioration de la coordination entre les grandes technologies.
— interface assez facile à utiliser
— règles et ordre assez flexible et facile à régler pour obtenir exactement les données dont
nous avons besoin.
— les résultats sont faciles à comprendre et utiles à d’autres fins,
— les "problèmes" de qualité des données sont résolus rapidement et facilement et les tâches
sont contrôlées dans Oracle Data Integrator (ODI) de manière transparente.
Limites [7] [11]
— modèle de coût soulevé par les utilisateurs.
— difficile à apprendre, donc il faut un plan.
— l’installation initiale est difficile et les fonctions de maintenance sont compliquées par un
manque de personnel qualifié sur le marché.
7
— problèmes d’instabilité
• SAP : SAP Data Quality Management, microservices permet aux développeurs d’intégrer des
services de nettoyage et d’enrichissement des données dans n’importe quel processus métier ou
application à des services basés sur HTTPS/JSON fonctionnant sur SAP Cloud Platform. Les
développeurs peuvent simplement intégrer ces services dans leurs propres applications pour
fournir des capacités de nettoyage et de validation d’adresses, de géocodage et de géocodage
inverse .
Figure 1.3: Logo de SAP
SAP propose les produits d’intégration de données suivants : SAP Data Services, SAP Replication
Server, SAP Landscape Transformation Replication Server, SAP Remote Data Sync, SAP Data
Hub, SAP HANA, SAP Cloud Platform, SAP Cloud Platform Integration et SAP Streaming
Analytics. SAP HANA a SAP Data Integration et SAP Smart Data Access pour la fédération
des données. La base de clients de SAP pour cet ensemble de produits est estimée à plus de
50 000 organisations [7].
— fonctionne facilement dans plus d’un département, ce qui le rend plus rentable.
— nettoyage automatique des données
— un remplacement intelligent pour les outils ETL
— permet la diffusion de données et la planification intelligente des extraits de données
Limites [7] [11]
— l’interface utilisateur pourrait nécessiter un peu de travail pour rendre le système plus
convivial et finalement plus efficace à utiliser.
— ne prend pas en charge les bases de données tridimensionnelles.
— ne permet pas le multi-hébergement du serveur.
8
— ne permet pas l’hébergement de données multiples et la mise en miroir des données pour
la sécurité des données.
— problèmes liés à la mise à jour en temps réel.
• SAS : La solution SAS Data Quality prend en charge diverses opérations liées à la qualité des
données. Les opérations de qualité des données utilisent des règles prédéfinies qui s’appliquent
au contexte spécifique des données (comme les noms ou les adresses postales). Parmi les
exemples d’opérations de qualité des données, mentionnons le cadrage, l’analyse, fuzzy matching
et la normalisation [12].
Figure 1.4: Logo de SAS
SAS propose les produits d’intégration de données suivants : SAS Data Management, SAS
Data Integration Server, SAS Federation Server, SAS/ACCESS, SAS Data Loader for Hadoop
et SAS Event Stream Processing. La clientèle de SAS pour cet ensemble de produits est estimée
à 14 000 organisations [7].
Points forts [7]
— fidélisation de la clientèle et usage persistant.
— alignement sur les tendances de l’innovation.
— intégration avec des offres de données et d’analyse plus larges.
— permet aux utilisateurs de construire rapidement et logiquement des workflows de gestion

complexes.
Limites [7]
— polyvalence des cas d’utilisation
— modèle de prix et échelles de prix.
— participation à l’élargissement de l’écosystème du marché
• Talend :
Talend offre une solution complète de qualité des données (Talend Data Quality), incluant
9
des fonctionnalités de profilage, de nettoyage, de mise en correspondance et de “monitoring“

pour répondre à tous besoins de qualité et de gouvernance de données. Les fonctionnalités
de qualité des données peuvent évoluer afin de gérer toutes les données, du fichier plat aux
données d’entreprise dans Hadoop. Talend permet de tirer parti des meilleures fonctionnalités
de la plateforme pour fournir une qualité des données continue à travers différents types de
données et quel que soit le volume de données [13].
Figure 1.5: Logo de Talend
— cloud, containers et exploitation de l’open source
— capacités d’adaptation dans un ensemble de produits alignés
— maintien de prix avantageux.
— différents types d’analyse de profiling de données. Talend DQ dispose d’un grand nombre
de rapports d’analyse qui peuvent être utilisés dans le profiling.
Limites [7] [14]
— problèmes de stabilité et de nouvelles mises à jour.
— défaut de workflows faciles à créer pour des tâches qui peuvent être répétées.
— les fonctionnalités d’impression et d’exportation sont absentes dans la version Community.
— Support de connecteur
— la courbe d’apprentissage est très raide pour tous les produits Talend, y compris DQ.
Les produits de qualité des données fournis par les entreprises susmentionnées offrent des
fonctionnalités de base pour la déduplication des données, les exigences de formatage standard (tels
que les numéros de téléphone et les adresses) et la validation des adresses.
1.2.3 Solution proposée
Face aux différents problèmes que nous avons évoqués précédemment, ce projet de plate-forme
de gestion de la qualité des données doit répondre à plusieurs objectifs, qui sont :
10
• la simplicité de la solution en assurant la sécurité et la confidentialité des différentes données.
• conception d’interfaces claires et conviviales.
• optimiser autant que possible les temps d’accès et de traitement des données.
• fournir divers services de gestion.
• rapidité, capacité et facilité de traitement.
La solution que nous avons proposée consiste à créer une plate-forme Web de gestion de la
qualité des données qui sera, ensuite, hébergée dans le réseau local d’une institution financière. Cette
plate-forme traitera de manière périodique -selon la configuration- la vérification de la qualité des
données, respecte-t-elle le format et at-elle du sens en utilisant les capacités des nouvelles technologies
telles que la Machine learning et NLP, ainsi que la gestion des rôles utilisateurs, et nous permet aussi
de consulter des statistiques concernant les vérifications et améliorations dans la qualité des données
Les figures 1.6 et 1.7 illustrent respectivement le diagrammes de contexte et le diagrammes
de niveau 1 de la technique DFD (Data Flow Diagrams) que nous utiliserons pour illustrer les
fonctionnalités de la plate-forme.
Figure 1.6: Diagramme de contexte
11
Figure 1.7: Diagramme de niveau 1
1.3 Méthode de développement
"Quelle méthodologie de développement devrions-nous utiliser ?" Cette question est très
fréquente au début des projets les plus récents. Et c’est aussi un sujet qui suscite beaucoup de
discussions.
La méthodologie de développement n’est pas un style de gestion de projet ou une approche
technique spécifique, il s’agit d’une manière générale d’organiser le travail de développement logiciel.
Les modèles de développement traditionnels nécessitent généralement beaucoup de temps et
d’efforts pour diverses procédures de développement, comme l’analyse des besoins, la planification
de la conception, le développement de prototypes et de produits, les tests, et les tests d’acceptation
par le client final.
Dans le but d’éviter ce genre de situations critiques, nous adoptons la méthodologie agile
pour la gestion de notre projet.
1.3.1 Méthode Agile
Contrairement aux modèles de développement traditionnels, la méthode Agile propose une

approche incrémentale et itérative de la conception logicielle. Il a été essentiellement développé en
réponse aux limites de Waterfall, comme un moyen de donner plus de liberté aux concepteurs et
12
aux développeurs et de rendre leur travail plus orienté client. Au lieu d’un processus de conception
séquentielle, la méthodologie Agile suit une approche incrémentale. Habituellement, les spécialistes
appellent Agile une approche innovante.
1.3.2 Méthode adoptée
Le développement agile a de nombreux frameworks. Tous ces frameworks suivent la même

philosophie agile, les mêmes caractéristiques et les mêmes procédures. Et parmi ces différents frameworks
Agiles, nous citons Scrum que nous avons choisi pour les raisons suivantes :
• développement et livraison rapides de logiciels.
• processus de développement transparent.
• l’implication et la rétroaction continues des clients/utilisateurs.
• anticiper et intégrer facilement les changements à n’importe quel stade de développement.
1.3.3 Développement guidé par les tests
Le développement guidé par les tests (" Test-Driven Development ", TDD) est une pratique
de développement qui utilise des tests unitaires pour spécifier, concevoir et vérifier le code que
nous sommes en train d’écrire. Avant d’implémenter une fonctionnalité, les développeurs écrivent
un test unitaire défaillant qui démontre comment cette fonctionnalité devrait fonctionner. En même
temps, cet échec prouve également que l’implémentation actuelle ne supporte pas encore la nouvelle
fonctionnalité. Ce n’est qu’ensuite que les développeurs écrivent le code de l’application. Une fois le
test unitaire réussi, les développeurs savent que la fonctionnalité a été implémentée avec succès. À
ce stade, ils peuvent revoir leur code pour mettre de l’ordre et perfectionner le design. Les règles, ou
étapes, que nous devrions suivre lors de la réalisation avec le TDD sont simples à lire et à comprendre,
même si elles ne sont généralement pas aussi faciles à appliquer. Elles le sont :
1. Écrire un test sur une seule unité pour vérifier que certains critères sont respectés.
2. Exécuter le test qui échoue.
3. Ecriver juste assez de code pour que le test réussisse.
4. Refactoriser le code en nous assurant que le test réussit toujours.
5. Recommencer, tester et développer progressivement notre application.
La figure 1.8 représente les étapes de développement guidé par les tests.
13
Figure 1.8: Etapes de développement guidé par les tests
1.3.4 Intégration continue
L’intégration continue a été créée pour le développement agile. Il organise le développement

en récits d’utilisateurs fonctionnels. Ces récits d’utilisateurs sont mis en petits groupes de travail, des
sprints. L’idée de l’intégration continue est de trouver rapidement les problèmes, de donner à chaque
développeur une rétroaction sur son travail et TDD évalue ce travail rapidement. Avec TDD, nous
construisons le test et développons ensuite les fonctionnalités jusqu’à ce que le code passe le test.
Chaque fois que nous ajoutons du nouveau code, son test peut être ajouté à la série de tests qui sont
exécutés lors de la construction de la partie intégrée de notre travail. Cela permet de s’assurer que
les nouveaux ajouts ne brisent pas le travail de fonctionnement qui les a précédés, et les développeurs
dont le code " casse la compilation " peuvent être notifiés rapidement.
1.3.5 Automatisation de la vérification de la qualité du code
La vérification automatisée du code vérifie la conformité du code source à un ensemble

prédéfini de règles ou de meilleures pratiques. L’utilisation de méthodes analytiques pour inspecter
et réviser le code source afin de détecter les bogues a été une pratique de développement standard.
Ce processus peut être effectué manuellement ou de façon automatisée. Grâce à l’automatisation,
des outils logiciels facilitent le processus de révision et d’inspection du code.
14
1.3.6 Automatisation de la détection des vulnérabilités
Les études populaires sur la sécurité de l’information soulignent l’importance de l’automatisation

des tests de vulnérabilité. Année après année, ces recherches font ressortir les mêmes causes sous-jacentes
de risques liés à l’information, comme l’insuffisance des ressources, le manque de visibilité et une
gestion mal informée. Chacun de ces éléments peut être traité en automatisant les processus de test
de sécurité.
Conclusion
Au cours de ce chapitre, nous avons présenté l’organisation d’accueil Vneuron et ses principales
activités. De plus, nous avons pu établir le contexte général du projet et expliquer le choix de la
méthodologie de développement. Une analyse et spécification des besoins fera l’objet du prochain
chapitre.
15
Chapitre 2
Analyse et spécification des besoins
Plan
1 Les roles Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5 Modelisation des besions fonctionnels . . . . . . . . . . . . . . . . . . . . 30
6 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Chapitre 2. Analyse et spécification des besoins
Introduction
Ce chapitre est consacré à la phase d’analyse des besoins du projet. Nous présenterons,
d’abord, l’équipe SCRUM et les principaux acteurs de la plate-forme. Ensuite, nous présenterons le
backlog de produits et la planification du sprint. Nous identifierons, ensuite, les exigences fonctionnelles
et non fonctionnelles de la plate-forme. Enfin, nous clôturerons le chapitre en modélisant le diagramme
du cas d’utilisation global du projet et en le raffinant par une description textuelle des cas d’utilisation
les plus importants
2.1 Les roles Scrum
Une équipe Scrum est un ensemble d’individus travaillant ensemble pour fournir les incréments
de produits demandés et engagés. L’équipe Scrum est composée du Product Owner, de l’équipe de
développement et du Scrum Master. Le modèle d’équipe de Scrum est conçu pour optimiser la
flexibilité, la créativité et la productivité.
Pour bénéficier des artefacts de Scrum afin de mieux organiser le projet, nous adapterons
l’équipe Scrum à notre situation. Et pour cela, nous identifierons les membres de notre équipe
Scrum et leur rôle :
• Product Owner (PO) : Ghassan HAMROUNI
• Scrum Master (SM) : Hatem BOUCHRIHA
• L’équipe de développement : Brahim BAHAIDA
2.2 Identification des acteurs
Cette plate-forme sera réalisée non pas pour un usage public via Internet mais au sein du
réseau d’un client et pour cela elle aura trois types d’utilisateurs.
• Manager : il est chargé d’ajouter et d’éditer les configurations des bases de données et des
paramètres, il peut générer le rapport de qualité des données.
• Simple-user : il est un simple utilisateur qui peut accéder aux fonctionnalités de la plateforme
mais il ne peut pas ajouter ni modifier les configurations.
• Super-user : Il est chargé d’ajouter de nouveaux utilisateurs et de modifier leurs rôles, mais
il n’aura pas accès aux autres fonctionnalités de la plateforme pour respecter au mieux le
principe du SoD.
17
2.3 Identification des besoins
Cette section sert à identifier les besoins fonctionnels et non fonctionnels de la plate-forme
afin d’enrichir la connaissance du client et ses attentes et d’améliorer la qualité de la plate-forme et
de ses services.
2.3.1 Besoins fonctionnels
Les besoins fonctionnels servent à présenter les actions que doit effectuer le Système en réponse
à une demande présentée par un utilisateur. La figure 2.1 illustre le diagramme de navigation proposé.
Figure 2.1: Diagramme de navigation
A ce niveau, nous devons spécifier nos exigences en langage naturel, en utilisant les fiches
GABARIT-VOLERE [15].
18
Numero d’exigence : EF1 Type d’exigence : Exigence fonctionnelle
Cas d’utilisation : S’authentifier
Description : le système doit fournir une interface pour l’authentification
Acteur : Tous les utilisateurs
Contentement du maître d’ouvrage : 3
Mécontentement du maître d’ouvrage : 5
Exigences dépendantes :
Cas d’utilisation : Ajouter un utilisateur
Description : le système doit permettre au Super-user d’ajouter de nouveaux utilisateurs
Acteur : Super-user
Exigences dépendantes : EF1
19
Cas d’utilisation : Modifier un utilisateur
Description : le système doit permettre au Super-user de modifier les rôles des utilisateurs
Acteur : Super-user
Cas d’utilisation : Supprimer un utilisateur
Description : le système doit permettre au Super-user de supprimer un utilisateurs
Acteur : Super-user
20
Cas d’utilisation : Consulter la liste des utilisateurs
Description : le système doit permettre au Super-user de consulter la liste des utilisateurs
Acteur : Super-user
Cas d’utilisation : Ajouter une nouvelle base de donnees
Description : le système doit permettre au Manager d’ajouter de nouvelles configurations

de base de données
Acteur : Manager
21
Cas d’utilisation : Supprimer une base de donnees
Description : le système doit permettre au Manager de supprimer des configurations de

base de données
Acteur : Manager
Cas d’utilisation : Consulter une liste des bases de donnees
Description : le système doit permettre au Manager de consulter la liste des bases de donnees
Acteur : Manager
22
Cas d’utilisation : Créer un job
Description : le système doit permettre au Manger de créer un job
Acteur : Manager
Exigences dépendantes : EF1, EF6
Cas d’utilisation : Ajouter des configurations pour un job
Description : le système doit permettre au Manager d’ajouter des configurations pour un

job
Acteur : Manager
Exigences dépendantes : EF1, EF6, EF9
23
Cas d’utilisation : Ajouter des contrôles de qualité
Description : le système doit permettre au Manager d’ajouter des contrôles de qualité. Ces
contrôles peuvent être simples, complexes, génériques ou basés sur la ML
Acteur : Manager
Exigences dépendantes : EF1, EF6, EF9, EF10
Cas d’utilisation : Modifier les configurations des jobs
Description : le système doit permettre au Manger de modifier les configurations des jobs
Acteur : Manager
24
Cas d’utilisation : Consulter la liste des jobs
Description : le système doit permettre au Manager de consulter la liste des jobs
Acteur : Manager
Cas d’utilisation : Recevoir des notifications sur les jobs
Description : le système doit permettre au Manager de recevoir des notifications sur les
jobs
Acteur : Manager
25
Cas d’utilisation : Consulter les resultats de l’execution d’un job
Description : le système doit permettre au Manager de consulter les resultats de l’execution d’un job
Acteur : Manager
Cas d’utilisation : Consulter la liste des configurations de chaque job
Description : le système doit fournir au Manager de consulter la liste des configurations de

chaque job
Acteur : Manager
26
Cas d’utilisation : Consulter des graphes de l’amelioration de la qualité
Description : le système doit fournir au Manager et Simple-user de consulter des graphes

de l’amelioration de la qualité
Acteur : Manager, Simple-user
2.3.2 Besoins non fonctionnels
Les besions non fonctionnelles présentent des exigences internes pour le système et qui sont
invisibles vis-à-vis de nos clients.
• Accessibilité : le système vise à atteindre au moins le niveau minimum d’accessibilité du

Web (A) selon les niveaux d’accessibilité WCAG 2.0 établis par la WAI (Web Accessibility
Initiative) du World Wide Web Consortium (W3C).
• Responsive design : pour rendre la plateforme conviviale, la plate-forme doit respecter les
points suivants :
— Paramétrage HTML
— Mise en page flexible
— Type flexible
— Images flexibles
• Sécurité : pour être conforme aux principes de sécurité, la plate-forme doit être protégée
contre les 10 principales vulnérabilités Web publiées par l’OWASP. Et pour cela, nous allons
utiliser une approche automatisée pour vérifier le code afin de détecter toute vulnérabilité juste
27
après que le code ait été poussé vers les repos github, en utilisant un service cloud pour la
vérification.
2.4 Backlog de produit
Le Backlog de produits correspond à une liste priorisée des besoins et des exigences des clients.
Les éléments du carnet de commandes du produit, également appelés témoignages d’utilisateurs, sont
formulés en une ou deux phrases décrivant clairement et précisément les fonctionnalités souhaitées
par le client, généralement écrites sous la forme suivante En tant que X, je veux Y, afin que je puisse
Z. Le backlog de produits présenté dans le tableau 2.1 comprend les champs suivants :
• ID : c’est un nombre unique et auto-incrémenté pour chaque histoire utilisateur
• Feature : une désignation décrit le récit de l’utilisateur
• User Story : c’est une phrase décrivant la fonctionnalité désirée par le client.
• Priorité : nous utilisons la technique MoSCoW pour nous aider à comprendre et à gérer les
priorités. Les lettres signifient :
— M(Must Have) Doit avoir
— S(Sould Have) Fallait avoir
— C(Could Have) Pourrait avoir
— W(Won’t Have) N’aura pas
• Story point : est l’effort requis pour créer une récit d’utilisateur. la technique utilisée est celle
de la suite de Leonardo Fibonacci.
ID Feature User Story Priorité Story

point
#1 S’authentifier En tant qu’utilisateur, je peux Must 3

m’authentifier à l’application
#2 Ajouter une base de En tant que Manager, je peux ajouter les Must 21
données configurations de connexion des bases de
données
#3 Sélectioner une table En tant que Manager, je peux choisir Must 13

une table afin d’y appliquer un contrôle
qualité.
28
#4 Sélectioner une colonne En tant que Manager, je peux choisir des Must 8
colonnes pour y appliquer un contrôle de
qualité.
#5 Sélectioner le contrôle En tant que Manager, je peux choisir Must 13

de qualité NOTNULL un contrôle qualité NOTNULL pour
l’appliquer.
#6 Planification des jobs En tant que Manager, je peux configurer Must 8

la planification des jobs.
#7 Sélectioner le contrôle En tant que Manager, je peux choisir un Must 5

de qualité EMAIL contrôle qualité EMAIL pour l’appliquer.
#9 Sélectioner le contrôle En tant que Manager, je peux choisir Must 13

de qualité INTERVAL un contrôle qualité INTERVAL pour
l’appliquer.
#10 Sélectioner le contrôle En tant que Manager, je peux choisir un Must 13

de qualité NAME contrôle qualité NAME pour l’appliquer.
#12 Afficher les resultats de En tant que Manager, je peux consulter les Must 8
contrôles de qualité résultats de l’exécution d’un job.
#13 Ajouter un utilisateur En tant que Super-user, je peux ajouter Must 8

un nouvel utilisateur.
#14 Consulter la liste de En tant que Superuser, je peux consulter Must 8

tous les utilisateurs la liste de tous les utilisateurs.
#11 Sélectioner le contrôle En tant que Manager, je peux choisir Should 13

de qualité PATTERN un contrôle qualité PATTERN pour
l’appliquer.
#15 Modifier un utilisateur En tant que Superuser, je peux modifier Should 5

les informations d’un utilisateur.
#16 Supprimer un En tant que Superuser, je peux supprimer Should 5

utilisateur un utilisateur.
29
#17 Line graph En tant que Simple-user ou Manager, Should 21

je peux visualiser les statistiques
d’amélioration de la qualité des données
via un Line-graph.
#18 Bar graph En tant que Simple-user ou Manager, Should 21

je peux visualiser les statistiques
d’amélioration de la qualité des données
via un Bar-graph.
#8 Sélectioner le contrôle En tant que Manager, je peux choisir un Could 5

de qualité AGE contrôle qualité AGE pour l’appliquer.
#19 Rapport En tant que SimpleUser, je peux Could 13

télécharger le rapport d’amélioration
de la qualité des données.
Tableau 2.1: Baklog produit.
2.5 Modelisation des besions fonctionnels
Nous commençons par présenter les fonctionnalités de notre application à l’aide d’un diagramme
de package et d’un diagramme de cas d’utilisation global puis nous détaillons les cas d’utilisation les
plus prioritaires.
2.5.1 Diagramme de packages
Nous constatons souvent que les besoins très différents des acteurs et le nombre de fonctionnalités
que le futur système nécessitera sont très souvent complexes. Pour rendre cela plus clair et plus
facile pour nous, nous pouvons diviser le futur système en parties séparées, selon les "familles" de
fonctionnalités et de telle manière qu’elles puissent être analysées séparément. Chacune de ces parties
correspond à un domaine fonctionnel ou à un package.
La figure 2.2 représente le diagramme de packages de la solution
30
Figure 2.2: Diagramme de packages
2.5.2 Diagramme de cas d’utilisation général
Le diagramme de cas d’utilisation décrit comment les acteurs vont utiliser la plate-forme,
c’est la réponse à la question suivante : QUI devrait pouvoir faire quoi ?
La figure 2.3 regroupe les exigences de la plate-forme à l’aide du diagramme de cas d’utilisation
du langage UML,
31
Figure 2.3: Diagramme des cas d’utilisation
2.5.3 Raffinement et description textuelle des cas d’utilisation
Dans cette section, nous allons raffiner les cas d’utilisation les plus importants en utilisant
soit une description textuelle, soit un diagramme d’activité.
Le tableau 2.2 illustre la description textuelle du cas d’utilisation « Ajouter la planification
des jobs »
SOMMAIRE D’IDENTIFICATION
Titre : Ajouter la planification des jobs
But : Permettre à l’utilisateur de planifier l’exécution périodique des

configurations de jobs.
Résumé : le système doit permettre au Manager de planifier l’exécution des jobs
Acteur : Manager
Pré-conditions : L’utilisateur doit être authentifié en tant que Manager
DESCRIPTION D’ENCHAÎNEMENT
Scénario nominal
32
1. l’utilisateur accède à la page de configuration des jobs.
2. l’utilisateur renseigne les différents champs de configuration
3. l’utilisateur peut ajouter plusieurs configurations
4. le système affiche un calendrier pour choisir le temps d’exécution du

job.
5. l’utilisateur choisit une date.
6. le système sauvegarde la planification des jobs.
Scénario alternatif
2a. L’utilisateur décide de quitter la page de configuration des jobs.
4a. L’utilisateur décide de quitter la page de configuration des jobs.
Tableau 2.2: Description textuelle du cas d’utilisation « Ajouter la planification des jobs »
Le tableau 2.3 illustre la description textuelle du cas d’utilisation « Ajouter une nouvelle base
de données »
SOMMAIRE D’IDENTIFICATION
Titre : Ajouter la configuration de datastores
But : Permettre à l’utilisateur d’ajouter le setup pour accéder à ses bases

de données.
Résumé : Le système doit permettre au Manager d’ajouter des configurations

de datastores
Acteur : Manager
Pré-conditions : L’utilisateur doit être authentifié en tant que Manager
DESCRIPTION D’ENCHAÎNEMENT
Scénario nominal
33
1. le système affiche un formulaire contenant les champs suivants : Type de base de

données, nom de base de données, hôte, port, nom d’utilisateur et mot de passe
2. l’utilisateur renseigne les différents champs de configuration
3. l’utilisateur doit tester la configuration avant de la soumettre
4. le système doit permettre à l’utilisateur de soumettre le formulaire si le test de

configuration a réussi
5. l’utilisateur soumet le formulaire
6. le système sauvegarde la configuration.
Scénario alternatif
2a. L’utilisateur décide de quitter la page de configuration.
Tableau 2.3: Description textuelle du cas d’utilisation « Ajouter une nouvelle base de données »
2.6 Planification des sprints
Les "User stories" précédemment dénoncées dans le Backlog du produit sont classées par
ordre de priorité et par des valeurs métiers. L’objectif est de réaliser d’abord ce qui est le plus
profitable. Le travail sera planifié en fonction des sprints que nous avons dénoncés et chacun dure
deux semaines. Après une première réunion avec l’équipe, 8 sprints et deux releases ont été décidés.
Dans le tableau 2.4, nous présentons la planification des sprints.
Realease Sprint Nom du Sprint Periode
Sprint 1 Configuration des bases de données 01 févr.-14 févr.

Sprint 2 Chargement des données du client 14 févr.-28 févr.
Release 1
Sprint 3 Effectuer des simples contrôles de qualité 28 févr.-14 mars
Sprint 4 Effectuer des complexes contrôles de qualité 14 mars-28 mars
Sprint 5 Effectuer des contrôles de qualité génériques et 28 mars-11 avr.

basés sur NLP
Release 2
Sprint 6 Visualisation des résultats 11 avr.-25 avr.
34
Sprint 7 Gestion des utilisateurs 25 avr.-09 mai

Sprint 8 Visualisation des graphes d’amélioration 09 mai-23 mai
Tableau 2.4: Planification des sprints
Conclusion
Ce chapitre nous a permis d’établir une délimitation précise du projet et d’avoir une vision
plus claire du sujet. Nous avons décrit les besoins fonctionnels et non fonctionnels, les acteurs et le
Backlog produit. Cela nous a permis, par la suite, de planifier et d’organiser le temps consacré au
projet en identifiant les sprints. Ensuite, nous avons décrit les cas d’utilisation nécessaires et leurs
descriptions textuelles. Dans le chapitre suivant, nous commencerons la phase d’initialisation du
projet.
35
Chapitre 3
Initialisation du projet
Plan
1 Initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4 Environnements de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5 Installation et configuration de l’environnement de travail . . . . . . . 44

Chapitre 3. Initialisation du projet
Introduction
Nous consacrons ce chapitre à l’initialisation du projet et à la mise en place de l’environnement

de développement. Ensuite, nous présenterons l’architecture ainsi que l’environnement matériel et
logiciel qui seront expliqués. Ce chapitre pourrait être considéré comme le sprint 0 du projet.
3.1 Initialisation
Etant donné que nous allons travailler avec une solution complexe dans le domaine du Batch
Processing et du Machine Learning, nous avons consacré la première période à nous documenter.
Ensuite, nous avons suivi une formation d’introduction avant de démarrer le projet pour être en
mesure d’utiliser les bons outils pour exploiter ces technologies.
Ces formations se déroulent autour de :
• Batch Processing,
• Machine Learning,
• Natural Language Processing.
3.2 Architecture de la solution
Pour avoir une bonne vue d’ensemble de l’architecture de la solution, nous devons présenter
son architecture logique et logicielle.
3.2.1 Architecture logique
Au stade de l’architecture logique, nous nous concentrons sur le système en tant que boîte
blanche et définissons comment le système fonctionnera de manière à répondre aux attentes.
L’architecture que nous avons adaptée pour la réalisation de notre solution est l’architecture
N-tiers. Elle est composée de 3 couches principales suivant les bons principes de conception.
Ces couches sont comme suit :
• Couche de présentation : qui correspond à la visualisation, la restitution sur le poste de

travail, le dialogue avec l’utilisateur.
• Couche logique métier : qui correspond à la mise en œuvre de l’ensemble des règles métier
et de la logique applicative.
37
• Couche d’accès aux données : qui correspond aux données qui sont destinées à être
conservées sur la durée, voire de manière définitive.
La figure 3.1 représente l’architecture logique de l’application.
Figure 3.1: Architecture logique
3.2.2 Architecture logicielle
Dans le processus de conception, une étape importante consiste à définir l’architecture de

l’application. Elle dépend d’un certain nombre de facteurs, notamment les exigences de performance,
les perspectives, l’évolutivité, la modularité et l’extensibilité. La figure 3.2 illustre une représentation
de l’architecture logicielle de l’application.
• Front-end : afin de s’assurer que l’utilisateur a l’expérience la plus efficace possible, nous
avons choisi l’Angular 7 comme cadre frontal avec un tas d’autres outils pour améliorer
l’application côté client comme Ngrx l’implémentation du pattern Redux avec Angular, le
fameux Framework CSS Bootstrap 4 pour améliorer l’interface utilisateur.
• Back-end : Dans la partie Back-end, nous choisissons le framework Spring, le framework le

plus populaire et le plus efficace dans le monde Java. Le back-end sera divisé en 4 couches :
— DAO : sa responsabilité est d’enregistrer et de récupérer les données relatives aux

fonctionnalités de l’application.
38
— Batch : sa responsabilité est de lire les données du client, puis d’utiliser la couche
logique métier pour traiter les données avec un contrôleur qualité, et enfin de transmettre
le résultat du contrôle qualité à la couche DAO.
— Metier : sa responsabilité est de fournir les services nécessaires pour assurer la logique
métier de l’application.
— Web : a responsabilité est de fournir des services Web pour communiquer avec le
front-end via HTTP et JSON.
Figure 3.2: Architecture logicielle
3.3 Conception détaillée
Dans cette section, nous aborderons la partie conception au cours de laquelle nous illustrerons
notre conception avec la présentation du diagramme de packages et du diagramme de déploiement.
3.3.1 Diagramme de packages
Le diagramme de packages fournit une représentation graphique de haut niveau de la structure

de l’application et il est utile pour identifier les liens de généralisation et de dépendance entre les
packages, comme le montre la Figure 3.3.
Ce diagramme contient huit packages qui sont les suivants :
39
• Web : contient les classes qui gèrent la couche web ces classes sont les points d’entrée de la
plate-forme, ce package contient deux autres packages qui sont :
— Controllers : contient des classes qui sont chargées de répondre à l’application côté client
par un protocole HTTP en utilisant les services Restful.
— DTO : contient des classes avec le format requis par l’application côté client et pour se
protéger contre la fuite d’information.
• Security : contient les classes qui gèrent la couche de sécurité basée sur Spring Security, ce
package contient une autre package qui est :
— JWT : contient les classes qui gèrent le processus d’authentification et d’autorisation en

utilisant une stratégie de session sans état
• Services : contient les classes qui gèrent la couche métier de la plate-forme, ce package contient
une autre package qui est :
— Checkers : contient les classes qui implémentent les contrôles de qualité en utilisant le
design pattern strategy.
• Batch : contient les classes qui se chargeront du traitement batch, ce package contient trois
autres packages qui sont :
— Items : contient les classes héritées des classes de Spring Batch Core pour la lecture, le
traitement et l’écriture des données.
— Configurations : contient les classes qui configurent les beans nécessaires au traitement
batch et à la planification des jobs.
— Listeners : contient les classes impliquées dans le cycle de vie de l’exécution des jobs.
• Configurations : contient les classes qui configurent les beans nécessaires au fonctionnement
de la plate-forme.
• Datasources : contient des classes qui gèrent les types de sources de données des clients afin
de charger le bon pilote JDBC en utilisant le design pattern abstract factory.
• Repositories : contient les interfaces des repositories JPA qui gèrent l’accès aux bases de
données
• Entities : contient les classes représentant les entités de base de la plate-forme.
40
Figure 3.3: Diagramme de packages
3.3.2 Diagramme de déploiement
Les diagrammes de déploiement permettent de décrire l’architecture physique d’un système.

Ils illustrent la répartition des composants logiciels sur la base d’une unité d’exécution. La figure 3.4
présente le diagramme de déploiement de l’application.
Figure 3.4: Diagramme de déploiement
3.4 Environnements de travail
Cette section présente l’environnement matériel et technique nécessaire à la réalisation de

l’application.
41
3.4.1 Environnement matériel
Au cours de la réalisation de ce travail, nous disposons d’un ordinateur HP Pavilion Notebook

avec un système d’exploitation Windows 10 et les fonctionnalités suivantes :
• Processeur : Intel(R) Core(TM) i7-6500U CPU @2.50GHz, 2592 MHz, 2 cœurs, 4 processeurs
logiques,
• Mémoire physique (RAM) : 12,0 Go,
• Système : 64 bits.
3.4.2 Environnement technique
Cette section présente les différents outils et langages de développement que nous avons
utilisés pour réaliser notre application.
3.4.2.1 Environnement logiciel
Ci-dessous se trouvent les différents outils que nous avons utilisés pour développer l’application :
• Visual Paradigm : est un outil UML supportant UML 2, SysML et BPMN du Object
Management Group (OMG).
• IntelliJ IDEA Ultimate : fournit une bonne interface utilisateur conviviale et intuitive.
Facile à utiliser et à coder et il a un compilateur très rapide. Utilisable pour Java, Kotlin,
Groovy, Scala.
• Postman : est un bon outil pour tester les API, en envoyant la requête au serveur web et en
récupérant la réponse. Ceci est utilisé comme un outil principal dans les plus grandes sociétés
de test de logiciels.
• Mysql 8 : est un système de gestion de base de données relationnelle open-source (SGBDR).

MySQL Server 8.0 a été annoncé en avril 2018, incluant NoSQL Document Store, les phrases
DDL atomiques et sécurisées et la syntaxe JSON Extended, de nouvelles fonctions, telles que
les fonctions de table JSON, un meilleur tri et des mises à jour partielles[16].
• PostgreSQL : est un système de gestion de base de données relationnelle open-source

(SGBDR) mettant l’accent sur l’extensibilité et la conformité aux normes. Il peut gérer des
charges de travail allant des applications mono-machine aux services Web ou à l’entreposage
de données avec de nombreux utilisateurs simultanés.
42
• Maven : est un outil de gestion de projet logiciel pour Java maintenu par l’Apache Software
Foundation.
• Git : est un système de contrôle de version distribué permettant de suivre les changements
dans le code source pendant le développement du logiciel.
• Travis CI : est un service d’intégration continue hébergé utilisé pour construire et tester des
projets logiciels hébergés chez GitHub.
• Codacy : est un outil automatisé d’examen du code qui permet aux développeurs d’améliorer
la qualité du code et de surveiller la dette technique. Codacy automatise les révisions de code
et surveille la qualité du code à chaque requête de validation et d’extraction. Il rend compte
de l’impact de chaque demande de commit ou de pull dans les nouvelles questions concernant
le style de code, les meilleures pratiques, la sécurité et bien d’autres.
• Taiga.io : est un système de gestion de projet gratuit et open-source pour les startups, les
développeurs Agile et les designers. Taiga est une application de gestion de projet qui peut gérer
des projets simples et complexes pour des startups, des développeurs de logiciels et d’autres
équipes cibles. Il permet aussi de suivre l’avancement d’un projet.
• snyk.io : est une solution de sécurité qui aide les entreprises à utiliser l’open source et à
rester sécurisées. Snyk est la seule solution qui trouve et corrige de manière transparente et
proactive les vulnérabilités et les violations de licence dans les dépendances open source et les
images Docker.
• Axure RP : est un outil logiciel de wireframing, de prototypage rapide, de documentation

et de spécification destiné aux applications web, mobiles et de bureau.
3.4.2.2 Langages et outils de développement utilisés
Ci-dessous, les choix techniques concernant les langages de développement sont imposés par
le Product Owner dès le début du projet, et qui sont :
• Java : est un langage de programmation dans la tradition du C et du C++. Java diffère des
autres langages de programmation de plusieurs façons importantes comme son indépendance
par rapport à la plate-forme, son orientation objet inhérente et le fait qu’il est accompagné
d’une bibliothèque de classes qui fournissent les fonctions utilitaires les plus utilisées.
• Spring Framework : est un framework open source d’application et un conteneur d’inversion

de contrôle pour la plate-forme Java. Les fonctionnalités de base du framework peuvent être
43
utilisées par n’importe quelle application Java, mais il existe des extensions pour construire
des applications web sur la plate-forme Java EE (Enterprise Edition). Bien que le framework
n’impose aucun modèle de programmation spécifique, il est devenu populaire dans la communauté
Java en tant que complément, voire en remplacement du modèle Enterprise JavaBeans (EJB).
• OpenNLP : est une toolkit basée sur la machine learning pour le traitement des textes en
langage naturel. Il prend en charge les tâches NLP les plus courantes, telles que la détection
de la langue, la tokenisation, la segmentation des phrases, le marquage partiel de la parole,
l’extraction des entités nommées, l’extraction des blocs, l’analyse et la résolution de coreference.
Ces tâches sont habituellement nécessaires pour créer des services de traitement de texte plus
avancés.
• Angular 7 : est un framework d’application web open-source basé sur TypeScript, dirigé par
l’équipe Angular de Google et par une communauté de particuliers et d’entreprises. Angular
est une réécriture complète de la même équipe qui a construit AngularJS.
• Typescript : est un langage de programmation open-source développé et maintenu par

Microsoft. Il s’agit d’un surensemble syntaxique strict de JavaScript, qui ajoute une saisie de
type statique optionnelle à ce langage.
3.5 Installation et configuration de l’environnement de travail
Pour être en mesure de débuter la réalisation du projet, nous avons téléchargé et installé les
logiciels suivants :
• JDK 1.8,
• Intellij IDEA Ultimate,
• Postman,
• PostgreSQL,
• Mysql 8.
Afin d’assurer une vue d’ensemble complète de l’avancement du projet tout en assurant une
intégration continue, l’automatisation de la vérification de la qualité du code et l’automatisation de
la détection des vulnérabilités du code. Nous avons configuré notre projet pour utiliser les projets
en ligne open-source suivants :
• Travis CI,
44
• Codacy,
• Snyk.
La figure 3.5 illustre une représentation du processus de validation du code.
Figure 3.5: Processus de validation du code
Conclusion
Dans ce chapitre, nous avons décrit l’architecture physique et logique de notre solution,
l’environnement de travail et la conception des quelques diagrammes.
Le chapitre suivant sera une illustration de la réalisation du premier release et nous entamerons par
la conception de ses différents sprints.
45
Chapitre 4
Mise en œuvre du release 1

Vérifications classiques de la
qualité des données
Plan
1 Sprint 1 : Configuration des bases de données . . . . . . . . . . . . . . . 47
2 Sprint 2 : Configuration du job . . . . . . . . . . . . . . . . . . . . . . . . 56
3 Sprint 3 : Effectuer des contrôles simples de qualité . . . . . . . . . . . 60
4 Sprint 4 : Effectuer des contrôles complexes de qualité . . . . . . . . . . 69

Chapitre 4. Mise en œuvre du release 1 Vérifications classiques de la qualité des données
Introduction
Ce chapitre fait l’objet d’une présentation du premier release du projet, soit la réalisation du
module de mise en œuvre de vérifications classiques de la qualité des données. Il est composé de 4
sprints, à savoir le sprint 1, 2, 3 et 4. L’étude de chaque sprint comprend l’analyse, la conception, la
réalisation et les tests fonctionnels ainsi que les problèmes rencontrés.
4.1 Sprint 1 : Configuration des bases de données
Ce sprint a pour but de développer la première partie de notre projet qui permettra au client
d’ajouter de nouvelles configurations de bases de données.
4.1.1 Backlog du sprint 1
Le Backlog du sprint contient une liste des tâches identifiées par l’équipe Scrum qui doivent
être accomplies avant la fin du sprint. Le tableau 4.1 représente le Backlog du sprint 1.
ID User Story ID Tache Estimation

tache (J)
1.1 Ajouter un service 1

d’authentification et des
#1 S’authentifier
filtres d’autorisation en
utilisant Spring Security
1.2 Ajouter un service 1/2
d’authentification en Angular
1.3 Ajouter un formulaire de 1/2
connexion
1.4 Rediriger l’utilisateur vers la 1
page d’accueil Si le token
existe déjà et n’a pas encore
expiré.
2.1 Affichage d’un formulaire si 1

#2 Ajouter une base de données aucune configuration existe
47
2.2 Formulaire pour ajouter les 3

informations de la base de
données
2.3 Bouton pour le test de la 1/2
connexion
3.1 Affichage de la liste des bases 1

#3 Liste des bases de données
de données
3.2 L’utilisateur peut sélectionner 1/2
une base de données
Tableau 4.1: Baklog du sprint 1
4.1.2 Analyse
Afin de concrétiser rapidement les exigences et les attentes du client, nous avons élaboré des
maquettes. Cela nous a permis d’avoir une idée plus précise de l’ergonomie du module, une bonne
compréhension du processus et, avant tout, une amélioration dans le processus de conception.
Les figures 4.1 et 4.2 représentent respectivement l’interface permettant à l’utilisateur de
s’authentifier à l’application et l’interface permettant à l’utilisateur d’ajouter une nouvelle configuration
de base de données.
Figure 4.1: Interface d’autentification
48
Figure 4.2: Interface d’ajout d’une nouvelle base de données
4.1.3 Conception
Cette partie est consacrée à la conception du sprint, désignant les composants de chaque
couche comme les packages et les classes. La conception vise à nous permettre de vérifier les prévisions
et de réajuster les récits des utilisateurs en cas d’erreurs.
4.1.3.1 Diagrammes de séquences
Le diagramme de séquence est un diagramme d’interaction qui détaille comment les opérations
sont exécutées, quels messages sont envoyés et quand. Les diagrammes de séquence sont organisés
en fonction du temps. Le temps passe au fur et à mesure que nous descendons la page. Les objets
impliqués dans l’opération sont répertoriés de gauche à droite en fonction du moment où ils participent
à la séquence de messages [17].
Les figures 4.3 et 4.4 illustrent respectivement le diagramme de séquence pour se connecter
à l’application et le diagramme de séquence pour ajouter une nouvelle base de données.
49
Figure 4.3: Diagramme de séquence «Authentification»
Figure 4.4: Diagramme de séquence «Ajouter une nouvelle base de données»
50
4.1.3.2 Diagrammes de classes
Dans cette section, nous allons présenter la structure statique de l’application via un diagramme
de classes pour chaque couche. Afin de clarifier le diagramme de classes et de le rendre plus lisible,
nous avons procédé à une schématisation simplifiée des interfaces, des classes métier et des entités.
Les figures 4.5, 4.6 et 4.7 illustrent respectivement le diagramme de classe de la couche d’accès
aux données, le diagramme de classe de la couche logique métier et le diagramme de classe de la
couche de présentation.
Figure 4.5: Diagramme de classe «Couche d’accès aux données - Sprint 1»
51
Figure 4.6: Diagramme de classe «Couche logique métier - Sprint 1»
Figure 4.7: Diagramme de classe «Couche de présentation - Sprint 1»
52
4.1.4 Réalisation
Afin de montrer les résultats de ce sprint, nous allons vous présenter quelques captures
d’écran.
Les figures 4.8, 4.9, 4.10 et 4.11 représentent respectivement la page permettant à l’utilisateur
de s’authentifier à l’application, la page d’affichage des paramètres des jobs, la page permettant
d’ajouter une nouvelle base de données et la page d’affichage de la liste des bases de données.
Figure 4.8: Page d’authentification
53
Figure 4.9: Page de paramètres des jobs
Figure 4.10: Page d’ajout d’une nouvelle base de données
54
Figure 4.11: Page de la liste des bases de données
4.1.5 Test et validation
Le test d’un produit logiciel est un processus qui vise à assurer le bon fonctionnement
du système par une comparaison des comportements attendus et des résultats obtenus[18]. C’est
pourquoi nous utilisons la méthode TDD pour assurer une couverture de code maximale pour les tests
unitaires et d’intégration. De plus, pour plus de précision, nous avons validé toutes les fonctionnalités
avec le Product Owner avant la fin de chaque Sprint. Le tableau 4.2 représente les tests fonctionnels
du sprint 1.
Cas de test Démarche Comportement attendu Résultat
Test d’ouverture Introduire les informations de Redirection vers la page du Conforme

de session l’utilisateur tableau de bord
Test de l’ajout Introduire les informations de Affichage de la nouvelle base Conforme

d’une nouvelle la base de données de données dans la liste des
base de données bases de données
Tableau 4.2: Tests fonctionnels du sprint 1
55
Suite à la vérification de la conformité du code et des fonctionnalités, le premier livrable a été

testé par le Product Owner. Il nous a, donc transmis la liste des améliorations, des fonctionnalités
à ajouter et des bugs à signaler.
4.1.6 Problèmes rencontrés
Lors de la réalisation de ce sprint nous n’avons pas rencontré de problèmes notables à

mentionner.
4.2 Sprint 2 : Configuration du job
Ce sprint vise à développer la partie de notre projet qui permettra au client de choisir les
tables et les colonnes dont la qualité est à vérifier.

tache (J)
4.1 Une fois la base de données 1

#4 Sélectioner une table sélectionnée, l’application doit
charger ses tables
4.2 Affichage de la liste des 1
tables de la base de données
sélectionnée
4.3 L’utilisateur peut sélectionner 1
une table
5.1 En sélectionnant une table, 1

#5 Sélectioner une colonne l’application doit charger ses
colonnes
5.2 Affichage d’une liste des noms 2
des colonnes et de leurs types
de la table sélectionnée
56

une colonne
4.2.2 Analyse
Après avoir étudié les différentes tâches du sprint 2, nous avons établi une maquette pour
la valider avec le Product Owner. La figure 4.12 représente l’interface permettant à l’utilisateur
d’ajouter un nouveau job.
Figure 4.12: Interface d’ajout un nouveau job
4.2.3 Conception
Étant donné que les diagrammes de classes du sprint précédent n’ont pas changé, nous ne
présenterons que les diagrammes de séquence pour ce sprint. Les figures 4.13 et 4.14 illustrent
respectivement le diagramme de séquence pour le chargement des tables et le diagramme de séquence
pour le chargement des colonnes.
57
Figure 4.13: Diagramme de séquence «Chargement des tables»
Figure 4.14: Diagramme de séquence «Chargement des colonnes»
58
4.2.4 Réalisation
Afin de montrer les résultats de ce sprint, nous présenterons quelques captures d’écran.
La figure 4.15 représente la page permettant à l’utilisateur de choisir les tables et colonnes pour
configurer un job.
Figure 4.15: Page de sélection des tables et les colonnes
Le tableau 4.4 représente les tests fonctionnels du sprint 2.
Test de Sélectionner une base de Charger les tables de la base Conforme

chargement données de données dans une liste
des tables
Test de Sélectionner une table Charger les colonnes de la Conforme

chargement table dans une liste
des colonnes
59
Pour ce sprint, les problèmes que nous avons rencontrés, notamment le fait que nous lisons
des données à partir de structures de bases de données inconnues et variables, ainsi que l’état du
front-end est instable à cause des nombreuses interactions des utilisateurs. Par conséquent, pour
résoudre ce problème, nous allons utiliser pour la gestion des états NgRX l’implémentation dans
Angular du pattern Redux. La figure 4.16 représente l’architecture de NgRX.
Figure 4.16: Architecture de NgRX
4.3 Sprint 3 : Effectuer des contrôles simples de qualité
Ce sprint a pour but de développer la partie de notre projet qui mettra en place un simple
contrôle de qualité pour la vérification de la base de données clients.
60

tache (J)
Sélectioner le contrôle de 6.1 En sélectionnant une colonne, 1

#6
qualité NOTNULL l’application doit afficher
les contrôles de qualité en
fonction du type de colonne
le contrôle de qualité
NOTNULL
7.1 Planifier le programme 1

d’exécution des jobs
#7 Planification des jobs
7.2 Sauvegarder les configurations 2
de job
7.3 Au moment de la planification 1
des jobs, l’application doit
charger les données utilisateur
et effectuer les contrôles de
qualité
7.4 Une fois le job sauvegardé, 1
l’application doit l’afficher
dans les listes de jobs
4.3.2 Analyse
la valider avec le Product Owner. La figure 4.17 représente l’interface permettant à l’utilisateur de
planifier le programme d’exécution des jobs.
61
Figure 4.17: Interface de planification du programme d’exécution des jobs
4.3.3 Conception
Pour ce sprint, nous présenterons les diagrammes de séquences et les diagrammes de classes.
Nous décrirons mieux cette interaction en présentant les diagrammes de séquences ci-dessous
pour les cas d’utilisation «Sélectioner le contrôle de qualité NOTNULL» et «Planifier le programme
d’exécution des jobs». Les figures 4.18, 4.20 et 4.19 représentent respectivement les diagrammes de
sequences de l’execution d’un controle de quality, de planification du programme d’exécution des
jobs et d’instantiation des contrôleurs de qualité.
62
Figure 4.18: Diagramme de séquence «Execution d’un controle de quality - NOTNULL»
63
Figure 4.19: Diagramme de séquence «Planification du programme d’exécution des jobs»
Figure 4.20: Diagramme de séquence «Instantiation des contrôleurs de qualité»
64
Pour ce sprint, afin de produire des diagrammes plus lisibles, nous ne montrerons que les
classes qui ont été ajoutées ou modifiées et nous colorerons les nouvelles classes ou méthodes de la
même manière que les sprints précédents et les classes qui ne les ont pas modifiées nous les colorerons
en gris Les figures 4.21, 4.22 et 4.23 illustrent respectivement le diagramme de classe de la couche
d’accès aux données, le diagramme de classe de la couche logique métier et le diagramme de classe
de la couche de présentation.
65
66
4.3.4 Réalisation
Afin de montrer les résultats de ce sprint, nous présenterons quelques captures d’écran. La
figure 4.19 représente la page de planification le programme d’exécution des jobs.
Figure 4.24: Page de planification du programme d’exécution des jobs
Test d’ajout Cliquer sur le bouton Ajouter Conserver les configurations Conforme
de plusieurs une configuartion précédentes et ajouter une
configurations nouvelle configuration.
Test de Cliquer sur le bouton de Suppression de la Conforme

suppression suppression configuration des listes de
des configuration configurations
67
Test de Terminer les configurations Affichage d’un sélecteur de Conforme

planification date et d’heure pour choisir le
de job planning d’exécution du job
Pour ce sprint, les problèmes que nous avons rencontrés, en particulier le fait que les jobs
doivent être exécutés sur des plannings spécifiques, pour résoudre ce problème nous avons utilisé
Quartz pour gérer l’exécution avec les expressions Cron.
Quartz est un framework open source de planification de tâches entièrement écrit en Java et
conçu pour être utilisé dans les applications Java SE et Java EE. Il offre une grande flexibilité sans
sacrifier la simplicité[19]. La figure 4.25 représente l’architecture de Quartz.
Figure 4.25: Architecture de Quartz
68
4.4 Sprint 4 : Effectuer des contrôles complexes de qualité
Ce sprint vise à développer la partie de notre projet qui mettra en place des contrôleurs de
qualité plus complexes pour vérifier la base de données clients.
ID User Story ID tache Tache Estimation

(J)

#8
qualité EMAIL l’application doit afficher
le contrôle de qualité EMAIL

#9
qualité AGE l’application doit afficher
le contrôle de qualité AGE

#10
qualité INTERVAL l’application doit afficher
INTERVAL
69
4.4.2 Analyse
Pour ce sprint, nous garderons la maquette du dernier sprint, car rien ne changera dans la
partie front et tout le travail sera fait dans la partie back end.
4.4.3 Conception
pour les cas d’utilisation «Sélectioner le contrôle de qualité EMAIL», «Sélectioner le contrôle de
qualité AGE» et «Sélectioner le contrôle de qualité INTERVAL».
70
Figure 4.26: Diagramme de séquence «Execution d’un controle de quality - EMAIL»
71
Figure 4.27: Diagramme de séquence «Execution d’un controle de quality - AGE»
72
Figure 4.28: Diagramme de séquence «Execution d’un controle de quality - INTERVAL»
73
en gris La figure 4.29 illustre le diagramme de classe de la couche logique métier.
4.4.4 Réalisation
Afin de montrer les résultats de ce sprint, nous présenterons quelques captures d’écran. Les
figures 4.19 et 4.31 représentent respectivement la page d’ajouter des multiples configurations et la
page d’affichage des configurations.
74
Figure 4.30: Page d’ajout d’une liste de configurations
Figure 4.31: Page d’affichage de la liste de configurations
75
Test de sélection Sélectionner une colonne En choisissant une colonne, Conforme

des contrôleurs l’application doit afficher une
qualité liste de contrôles basée sur le
EMAIL, AGE, type de colonne
INTERVALLE
Pour ce sprint, nous n’avons pas rencontré de problèmes notables à mentionner en raison
de l’utilisation du design pattern Strategie, l’ajout de nouvelles classes de contrôles est devenu plus
facile et plus rapide.
Conclusion
Au cours de ce release, nous avons réalisé la conception et la mise en œuvre du contrôle

qualité en utilisant des contrôles simples et complexes de qualité. Le release a été présenté lors d’une
réunion durant laquelle a participé l’équipe du projet.
Après avoir été enrichi par leurs remarques et suggestions de perspectives, nous commençons
dans la prochaine release la mise en place d’un contrôle qualité générique et l’utilisation des techniques
NLP pour vérifier la qualité de la base de données du client.
76
Chapitre 5
Mise en oeuvre du release 2

Vérifications de la qualité des
données basée sur la NLP
Plan
1 Sprint 5 : Effectuer des contrôles génériques et basés sur NLP de qualité 78
2 Sprint 6 : Visualisation des résultats . . . . . . . . . . . . . . . . . . . . . 84
3 Sprint 7 : Gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . . . 91
4 Sprint 8 : Visualisation des graphes d’amélioration . . . . . . . . . . . . 98

Chapitre 5. Mise en oeuvre du release 2 Vérifications de la qualité des données basée sur la NLP
Introduction
Ce chapitre fait l’objet d’une présentation du deuxième release du projet, soit la réalisation
du module de vérifications de la qualité des données basée sur la NLP. Il est composé de 4 sprints, à
savoir le sprint 5, 6, 7 et 8. L’étude de chaque sprint comprend l’analyse, la conception, la réalisation
et les tests fonctionnels ainsi que les problèmes rencontrés.
5.1 Sprint 5 : Effectuer des contrôles génériques et basés sur NLP
de qualité
Ce sprint vise à développer la partie la plus importante du projet, celle de la vérification de la

qualité des données à l’aide de la technique NLP, qui est le sous-domaine de I’intelligence artificielle
qui vise à permettre aux ordinateurs de comprendre et de traiter les langues humaines [20]. en raison
de la contrainte de temps, nous nous concentrerons sur un modèle qui prédira la probabilité qu’une
entrée soit un nom propre pour une personne, et grâce à l’architecture de l’application il sera de plus
facile à étendre aux autres modèles dans l’avenir, NLP a beaucoup de techniques à utiliser, nous
allons utiliser la technique N-gram pour ce projet.
Fondamentalement, un modèle N-gramme prédit l’occurrence d’un mot à partir de l’occurrence
de ses N - 1 mots précédents. Nous voici donc en train de répondre à la question : jusqu’où, dans
l’histoire d’une séquence de mots, devrions-nous aller pour prédire le mot suivant ? Par exemple, un
modèle bigram (N = 2) prédit l’occurrence d’un mot donné seulement son mot précédent (comme N
- 1 = 1 dans ce cas). De même, un modèle trigramme (N = 3) prédit l’occurrence d’un mot à partir
de ses deux mots précédents (comme N - 1 = 2 dans ce cas) [21]. Une des façons de le faire est de
décomposer cette probabilité en utilisant la règle de probabilité en chaîne, comme suit :
n
Y
P(cn1 ) = P(ck |ck−1
k−N+1 ) (5.1)
k=0
N-gram est utilisé principalement pour prédire les mots d’une phrase, mais dans notre
situation en raison de la similitude entre les noms à travers les caractères utilisés pour la construction
des noms dans chaque culture ou zone géographique, nous allons utiliser le N-Gram pour prédire
la probabilité des caractères suivants. Cette probabilité sera calculée par l’utilisation d’un modèle
linguistique entraîné puis enregistré dans l’application sous la forme d’un bean.
78

tache (J)

#11
qualité NAME l’application doit afficher
le contrôle de qualité NAME

#12
qualité PATTERN l’application doit afficher
PATTERN
5.1.2 Analyse
Pour ce sprint, nous garderons la maquette du dernier sprint, car rien ne changera dans la
partie front et tout le travail sera fait dans la partie back end.
5.1.3 Conception
pour les cas d’utilisation «Sélectioner le contrôle de qualité PATTERN» et «Sélectioner le contrôle
de qualité NAME».
79
Figure 5.1: Diagramme de séquence «Execution d’un controle de quality - PATTERN»

70
80
Figure 5.2: Diagramme de séquence «Execution d’un controle de quality - NAME»
81
en gris La figure 5.3 illustre le diagramme de classe de la couche logique métier.
5.1.4 Réalisation
figure 5.4 représentent respectivement la page d’ajouter des multiples configurations et la page
d’affichage des configurations.
82
Figure 5.4: Page d’ajout d’une liste de configurations

qualité liste de contrôles basée sur le
PATTERN type de colonne
Test d’ajout de Sélectionner le controle En choisissant le controle Conforme

regex PATTERN PATTERN, l’application doit
afficher une zone de texte pour
ajouter un regex

qualité NAME liste de contrôles basée sur le
type de colonne
83
Pour ce sprint, les problèmes que nous avons rencontrés, en particulier le fait que nous devons
choisir entre une variété de techniques NLP et la nécessité de les étudier attentivement pour faire
le bon choix était si frustrant. mais pour gagner du temps, nous avons choisi la technique N-grams
combinée avec le calcul de fréquence de terme pour prédire la probabilité d’un nom donné.
5.2 Sprint 6 : Visualisation des résultats

tache (J)
13.1 En sélectionnant une date, 1

l’application doit afficher les
Afficher les resultats de
#13 jobs dans une liste de sélection
contrôles de qualité
13.2 En sélectionnant un job, 1
l’application doit afficher ses
configurations dans une liste
de sélection
13.3 En sélectionnant une 1
configuration, l’application
doit afficher ses contrôles dans
une liste de sélection
13.4 En sélectionnant un contrôle, 1
l’application doit afficher les
résultats dans une table
13.5 La table doit permettre à 2
l’utilisateur de paginer les
résultats
84
5.2.2 Analyse
Après avoir étudié les différentes tâches du sprint 6, nous avons établi une maquette pour la
valider avec le Product Owner. La figure 5.5 représente l’interface permettant à l’utilisateur d’ajouter
un nouveau job.
Figure 5.5: Interface d’affichage des resultats de contrôles de qualité
5.2.3 Conception
pour la cas d’utilisation «Afficher les resultats de contrôles de qualité». Les figures 5.6, 5.7, 5.8 et 5.9
représentent respectivement les diagrammes de sequences de chargement des jobs, de chargement
des configurations, de chargement des contrôles et d’affichage des résultats.
85
Figure 5.6: Diagramme de séquence «Chargement des jobs»
Figure 5.7: Diagramme de séquence «Chargement des configurations»
86
Figure 5.8: Diagramme de séquence «Chargement des contrôles»
Figure 5.9: Diagramme de séquence «Affichage des résultats»
87
en gris Les figures 5.10, 5.11 et 5.12 illustrent respectivement le diagramme de classe de la couche
d’accès aux données, le diagramme de classe de la couche logique métier et le diagramme de classe
de la couche de présentation.
88
89
5.2.4 Réalisation
figure 5.13 représentent la page d’affichage des résultats des contrôles.
Figure 5.13: Page d’affichage des résultats des contrôles
Test de Sélectionner une date Charger tous les jobs dans une Conforme
chargement liste
des jobs
Test de Sélectionner un job Charger toutes les Conforme

chargement configurations du job
des configurations sélectionné dans une liste
90
Test de Sélectionner une configuration Charger tous les contrôles de Conforme

chargement la configuration sélectionnée
des contrôles dans une liste
Test d’affichage Sélectionner un contrôle et Affichage des résultats sous Conforme

des résultats cliquer sur le bouton de forme d’une table avec la
recherche possibilité de pagination

mentionner.
5.3 Sprint 7 : Gestion des utilisateurs

tache (J)
Gestion des utilisateurs - 14.1 Formulaire pour ajouter les 2

#14
Ajouter un utilisateur informations de l’utilisateur
14.2 Afficher le nouveau utilisateur 2
dans la liste des utilisateurs
Gestion des utilisateurs - 15.1 Formulaire pour modifier les 2

#15
Modifier un utilisateur informations de l’utilisateur
15.2 Afficher les nouveau 1
informations de l’utilisateur
dans la liste des utilisateurs
Gestion des utilisateurs - 16.1 Afficher un modal de 1

#16
Supprimer un utilisateur confirmation
91
16.2 Supprimer l’utilisateur de la 1

liste des utilisateurs
17 Gestion des utilisateurs - Liste 17.1 Afficher une table des 1

des utilisateurs ustilisateurs avec la possibilité
de pagination
5.3.2 Analyse
Après avoir étudié les différentes tâches du sprint 7, nous avons établi une maquette pour la
valider avec le Product Owner. Les figures 5.14, 5.15 et 5.16 représentent respectivement l’interface
permettant au super-user d’ajouter un nouvel utilisateur, l’interface permettant au super-user de
modifier les informations d’un utilisateur et l’interface permettant au super-user de consulter la liste
des utilisateurs.
Figure 5.14: Interface d’ajout d’un nouvel utilisateur
92
Figure 5.15: Interface de modification les informations d’un utilisateur
Figure 5.16: Interface de consultation de la liste des utilisateurs
5.3.3 Conception
Étant donné que les diagrammes de classes du sprint précédent n’ont pas changé, nous ne
présenterons que les diagrammes de séquence pour ce sprint. Les figures 5.17, 5.18, 5.19 et 5.20
illustrent respectivement le diagramme de séquence d’ajouter un nouvel utilisateur, le diagramme
de séquence de modifier les informations d’un utilisateur, le diagramme de séquence de supprimer
un utilisateur et le diagramme de séquence de consulter la liste des utilisateurs.
93
Figure 5.17: Diagramme de séquence «Ajouter un nouvel utilisateur»
Figure 5.18: Diagramme de séquence «Modifier les informations d’un utilisateur»
94
Figure 5.19: Diagramme de séquence «Supprimer un utilisateur»
Figure 5.20: Diagramme de séquence «Consulter la liste des utilisateurs»
95
5.3.4 Réalisation
Afin de montrer les résultats de ce sprint, nous présenterons quelques captures d’écran. Les
figures 5.21, 5.23, 5.24 et 5.22 représentent respectivement la page d’ajout d’un nouvel utilisateur,
la page de consultation de la liste des utilisateurs, la page de modification des informations d’un
utilisateur et la page de supprission d’un utilisateur.
Figure 5.21: Page d’ajout d’un nouvel utilisateur
96
Figure 5.22: Page de consultation de la liste des utilisateurs
Figure 5.23: Page de modification des informations d’un utilisateur
97
Figure 5.24: Page de supprission d’un utilisateur
Test de l’ajout Introduire les informations de Affichage du nouvel utilisateur Conforme

d’un nouvel l’utilisateur dans la liste des utilisateur
utilisateur
Test de la Sélectionner l’utilisateur à Remplacer les informations Conforme

modification modifier utilisateur par les nouvelles
d’un utilisateur informations
Test de la Sélectionner l’utilisateur à Suppression de l’utilisateur de Conforme

supprission de supprimer la liste des utilisateur
l’utilisateur
Pour ce sprint, les problèmes que nous avons rencontrés, en particulier le fait que ces pages ne
doivent être accessibles qu’aux super-utilisateurs,98afin d’atteindre cet objectif, nous avons utilisé le
contrôle d’accès par rôle (RBAC) en combinant les capacités de Spring Security et Angular Guards
Services.
18.2 Regrouper les résultats par le 2

mois
19.1 Affichage d’un bargraphe 4

#19 Bar graph
représentant le nombre
d’erreurs
19.2 Regrouper les résultats par 1
contrôle
5.4.2 Analyse
la valider avec le Product Owner. La figure 5.25 représente l’interface permettant à l’utilisateur de
consulter les graphes visualisant l’état de qualité des données.
Figure 5.25: Interface de consultation des graphes visualisant l’état de qualité des données
5.4.3 Conception
pour la cas d’utilisation «Consulter les graphes visualisant l’état de qualité des données». Les figures
99
5.26 et 5.27 représentent respectivement les diagrammes de sequences de visualisation du Line-Graph

et de visualisation du Bar-Graph.
Figure 5.26: Diagramme de séquence «Visualisation du Line-Graph»
Figure 5.27: Diagramme de séquence «Visualisation du Bar-Graph»
100
en gris Les figures 5.28 et 5.29 illustrent respectivement le diagramme de classe de la couche logique
métier et le diagramme de classe de la couche de présentation.
101
5.4.4 Réalisation
figure 5.30 représentent la page de consultation des graphes visualisant l’état de qualité des données.
102
Figure 5.30: Page de consultation des graphes visualisant l’état de qualité des données
Test de l’affichage Accéder à la page du tableau L’application doit afficher Conforme

d’un line-graph de bord un line-graph illustrant
l’amélioration de la qualité
des données
Test de l’affichage Accéder à la page du tableau L’application doit afficher un Conforme

d’un barre-graphe de bord barre-graphe illustrant les
erreurs les plus fréquentes.

mentionner.
Conclusion
103
Dans ce release, nous avons conçu et mis en place des contrôles qualité basés sur la technique
NLP et permettant à l’utilisateur de consulter l’état de qualité des données via un tableau de bord
Conclusion générale
L’objectif de ce projet de fin d’étude était de concevoir et de développer une plate-forme de

management de la qualité des données.
Nous avons dû faire face à des contraintes techniques pendant la phase de développement.
En effet, nous avons passé plus de temps sur la plate-forme afin de pouvoir lire les données des
clients, extraire leurs métadonnées et les traiter en temps réel. Ainsi, nous n’avons utilisé que la
technique NLP pour prédire la qualité des données, ce qui nous a obligés à nous auto-former avant
de commencer cette phase.
Puisque tous les objectifs et fonctionnalités mentionnés dans la partie spécification ne sont pas
atteints, d’autres améliorations peuvent être apportées au projet. Du côté de la Machine Learning,
des réseaux de neurones ou d’autres algorithmes peuvent être utilisés pour vérifier la qualité des
données.
Ce projet nous a permis de découvrir de nouvelles approches de développement, d’approfondir
nos connaissances des technologies java, et notamment de Spring et de Spring Batch, de découvrir le
monde de l’intelligence artificielle notamment la NLP et comment utiliser ses concepts pour résoudre
un problème donné.
En ce qui concerne les perspectives, considérant la croissance des moteurs de base de données
NoSQL, la plate-forme pourrait avoir la capacité de traiter des données non seulement à partir de
SGBDR traditionnels, mais aussi à partir de NoSQL ou de fichiers plats.
L’expérience dans un environnement professionnel nous a été bénéfique. Ce stage nous a
permis de nous familiariser avec la vie professionnelle, de mettre en pratique les notions fondamentales
du traitement des langues naturelles et d’approfondir nos connaissances théoriques, acquises à
l’Institut Supérieur d’informatique, par la pratique de la science informatique. Nous souhaitons
que l’entreprise adoptera bien notre application et essaiera de la commercialiser.
104
Bibliographie
[1] Leaders. (). IP-Tech, élue meilleure startup par Microsoft Tunisie. [Accès le 18-Juin-2019],
Leaders, adresse : https://www.leaders.com.tn/article/2141-ip-tech-elue-meilleure-
startup-par-microsoft-tunisie.
[2] Vneuron. (2018). Presentation. [Accès le 13-Mars-2019], Vneuron, adresse : https://www.

linkedin.com/company/vneuron/about/.
[3] C. C. et Stefan Rass, « An Overview of Data Quality Frameworks », IEEE Access, [Accès
le 23-Mars-2019].
[4] P. Bhanot. (27 octobre 2016). Top 5 Causes of poor data quality. [Accès le 20-Mars-2019],
Blazent, adresse : https://www.blazent.com/top-5-causes-poor-data-quality/.
[5] K. A. B. et Larry A. Pace, « Preventing human error : The impact of data entry methods on
data accuracy and statistical results », Computers in Human Behavior, [Accès le 20-Mars-2019].
[6] D. S. Tadhg Nagle Thomas C. Redman. (). Only 3% of Companies’ Data Meets Basic
Quality Standards. [Accès le 24-Mars-2019], Harvard Business Review, adresse : https : / /
www.blazent.com/top-5-causes-poor-data-quality/.
[7] E. Z. Mark Beyer Eric Thoo. (). Magic Quadrant for Data Integration Tools. [Accès le
23-Mars-2019], Gartner, adresse : https://www.gartner.com/doc/reprints?id=1-50UZP37&
ct=180524&st=sb&mkt_tok=eyJpIjoiWWpnNU9USXlOakl6TnpSaiIsInQiOiIyN1JSODJFMCtZcHZlcWlTdUt3RE
3D.
[8] A. Qian. (). Informatica Data Quality – A Peek Inside – Part 1. [Accès le 20-Mars-2019],
Perficient, adresse : https : / / blogs . perficient . com / 2017 / 02 / 05 / informatica - data -
quality-a-peek-inside-part-1/.
[9] R. du Trust Radius. (). Informatica Data Quality Reviews. [Accès le 13-Mars-2019], Trust
Radius, adresse : https://www.trustradius.com/products/informatica-data-quality/
reviews.
[10] N. R. (). DATA QUALITY WITH EDQ – PART 1 : DATA PROFILING. [Accès le 25-Mars-2019],
Clear Peaks, adresse : https : / / www . clearpeaks . com / data - quality - series - data -
profiling/.
105
Bibliographie
[11] R. du Trust Radius. (). Oracle Data Quality Reviews. [Accès le 23-Mars-2019], Trust Radius,
adresse : https://www.trustradius.com/products/oracle- enterprise- data- quality/
reviews.
[12] H. Fadlallah. (). An introduction to Data Quality. [Accès le 25-Mars-2019], Medium, adresse :
https://medium.com/@hadi.fadlullah/an-introduction-to-data-quality-951cc6fe0274.
[13] A. B. SALEM, « Qualité contextuelle des données : Détection et nettoyage guidés par la
sémantique des données », [Accès le 10-Avril-2019], thèse de doct., Université Paris 13.
[14] R. du Trust Radius. (). Talend Data Integration Reviews. [Accès le 10-Avril-2019], Trust
Radius, adresse : https://www.trustradius.com/products/talend- data- integration/
reviews.
[15] H. Tudor. (). Plan de cahier des charges et spécification des exigences non fonctionnelles
avec Volere. [Accès le 16-Janvier-2019], adresse : http://www.volere.co.uk/pdf%20files/
template_fr.pdf.
[16] A. Ernst. (). MySQL 8.0 : Steaming Into Production ? [Accès le 29-Mai-2019], Medium,
adresse : https : / / medium . com / @ernstae / mysql - 8 - 0 - steaming - into - production -
b4b06db11263.
[17] Creately. (). The Ultimate Guide to Sequence Diagrams. [Accès le 30-Mars-2019], Medium,
adresse : https://medium.com/thousand-words-by-creately/the-ultimate-guide-to-
sequence-diagrams-a78e0e516886.
[18] A. Bachuk. (). Understanding software testing. [Accès le 02-Avril-2019], Medium, adresse :
https://medium.com/@netxm/how-to-get-started-with-software-testing-9fa1ce4f2a64.
[19] Baeldung. (). Introduction to Quartz. [Accès le 15-Juin-2019], Baeldung, adresse : https:
//www.baeldung.com/quartz.
[20] A. Geitgey. (). Natural Language Processing is Fun ! [Accès le 30-Avril-2019], Medium,
adresse : https : / / medium . com / @ageitgey / natural - language - processing - is - fun -
9a0bff37854e.
[21] P. Kumar. (). An Introduction to N-grams : What Are They and Why Do We Need Them ?
[Accès le 30-Avril-2019], XRDS, adresse : https://blog.xrds.acm.org/2017/10/introduction-
n-grams-need/.
106
PÌl
Rw§ ...An¡ Tyr` TlA Plm Rw§ ...An¡ Tyr` TlA Plm Rw§ ...An¡ Tyr` TlA Plm Rw§
Rw§ ...rWF rK` ¤d ¨ wk§ ºAr ...An¡ Tyr` TlA Plm Rw§ ...An¡ Tyr` TlA Plm
ºAr ...An¡ Tyr` TlA Plm Rw§ ...rWF rK` ¤d ¨ wk§ ºAr ...An¡ Tyr` TlA Plm
Rw§ ...rWF rK` ¤d ¨ wk§ ºAr ...An¡ Tyr` TlA Plm Rw§ ...rWF rK` ¤d ¨ wk§
ºAr ...An¡ Tyr` TlA Plm Rw§ ...rWF rK` ¤d ¨ wk§ ºAr ...An¡ Tyr` TlA Plm
nkm§ ...rWF rK` ¤d ¨ wk§ ºAr ...An¡ Tyr` TlA Plm Rw§ ...rWF rK` ¤d ¨ wk§
...An¡ Tyr` TlA Plm Rw§ Exemple ici A Plm XF¤ ¨ Tyny ¯ ¤r Aml tk
Aml Hm E¤A d ºAr : y Af Aml
Résumé
Mettez le resumé en français ici... Mettez le resumé en français ici... Mettez le resumé en français
ici... Mettez le resumé en français ici... Merci de ne pas dépasser les dix lignes. Mettez le resumé
en français ici, merci de ne pas dépasser les dix lignes. Mettez le resumé en français ici, merci de
ne pas dépasser les dix lignes. Mettez le resumé en français ici, merci de ne pas dépasser les dix
lignes. Mettez le resumé en français ici, merci de ne pas dépasser les dix lignes. Mettez le resumé
en français ici, merci de ne pas dépasser les dix lignes. Mettez le resumé en français ici, merci de
ne pas dépasser les dix lignes. Mettez le resumé en français ici, merci de ne pas dépasser les dix
lignes. Mettez le resumé en français ici, merci de ne pas dépasser les dix lignes.
Mots clés : Merci de ne pas dépasser les cinq mots
Abstract
Put the English abstract here, put the English abstract here, put the English abstract here, put
the English abstract here, put the English abstract here, put the English abstract here... Please
don’t exceed ten lines, Please don’t exceed ten lines, Please don’t exceed ten lines, Please don’t
exceed ten lines. Put the English abstract here, please don’t exceed ten lines. Put the English
abstract here, please don’t exceed ten lines. Put the English abstract here, please don’t exceed
ten lines. Put the English abstract here, please don’t exceed ten lines. Put the English abstract
here, please don’t exceed ten lines. Put the English abstract here, please don’t exceed ten lines.
Put the English abstract here, please don’t exceed ten lines. Put the English abstract here,
please don’t exceed ten lines.
Keywords : Please don’t use more than five keywords
isi@isim.rnu.tn : ¨¤rtk¯ d§rb 71 706 698 : HAf 71 706 164 : Ah TA§C 2080 ¨¤CAb A§r w h 2
2, Abou Raihane Bayrouni 2080 l’Ariana Tél : 71 706 164 Fax : 71 706 698 Email : isi@isim.rnu.tn

Rapport Pfe Vneuron-Scrum

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Pfe Vneuron-Scrum

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

Ministère de l’Enseignement Supérieur

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Conception et Développement d’une Plate-forme de

Encadrant professionnel : Monsieur Ghassen HAMROUNI Directeur Associé

Réalisé au sein de Vneuron

Année Universitaire 2018 - 2019

Ministère de l’Enseignement Supérieur

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Conception et Développement d’une Plate-forme de

Encadrant professionnel : Monsieur Ghassen HAMROUNI Directeur Associé

Réalisé au sein de Vneuron

Année Universitaire 2018 - 2019

Encadrant professionnel, Monsieur Ghassen HAMROUNI

Encadrant académique, Madame Rim KAABI

Je dédie ce travail, en signe de ma profonde gratitude et de mon admiration.

Tout d’abord, je tiens à remercier Dieu le Tout-Puissant, qui m’a donné la

force et la patience pour accomplir ce travail.

l’Institut Supérieur d’Informatique qui n’ont cessé de m’aider.

reconnaissance à Madame Rim KAABI pour son inspiration et son soutien

lors des différents suivis.

intégré si rapidement dans l’entreprise et de m’avoir pleinement soutenu, pour

toutes mes questions.

qu’ils trouveront dans ce rapport les qualités de clarté et de motivation qu’ils

1 Présentation Générale du Projet 2

2 Analyse et spécification des besoins 16

4 Mise en œuvre du release 1 Vérifications classiques de la qualité des données 46

5 Mise en oeuvre du release 2 Vérifications de la qualité des données basée sur la

Conclusion générale 104

1.1 Logo d’Informatica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Diagramme de navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1 Interface d’autentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.12 Interface d’ajout un nouveau job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.1 Diagramme de séquence «Execution d’un controle de quality - PATTERN» . . . . . 80

2.1 Baklog produit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1 Baklog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.1 Baklog du sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

— DFD = Data Flow Diagrams

— DQM = Data Quality Management

— SoD = Separation of Duties

— W3C = World Wide Web Consortium

— WAI = Web Accessibility Initiative

— WCAG = Web Content Accessibility Guidelines

— chapitre 2 : décrira comment ce travail sera réalisé en utilisant la méthodologie Scrum.

— chapitre 3 : sera consacré à la phase d’initialisation du projet et de mise en place de

Présentation Générale du Projet

1.1 Présentation de l’organisme d’accueil

1.2 Présentation du Projet

• Projets de migration et de conversion de données : La migration des données vers de

1.2.2 Étude et critique de l’éxistant

Figure 1.1: Logo d’Informatica

Points forts [7] [9]

Limites [7] [9]

— la perception d’un coût élevé est toujours présente.

— il n’y a pas de gestion d’alertes

— trop lente performance en cas d’utilisateurs multiples.

Figure 1.2: Logo d’Oracle