Dédicace

Dédicace
d
 5

Remerciement
 6

Acronymes

EARDEEP :

DevOps : Développement Opérationnel

BI : Business Intelligence

DW : Data Warehouse

ETL : Extract-Transform-Load

KPI : Key Performance Indicator

UML : Unified Modeling Language

SQL : Structured Query Language

DM : Data Mart

SSIS : Sql Server Integration Services

SGBDR : Système de Gestion de Base de Données Relationnelles

AMQ : Advanced Message Queuing Protocol

API : Application Programming Interface

HTTP : HyperText Transfer Protocol

 TABLE DES MATIÈRES

1 Contexte Générale du Projet 15

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Cadre générale du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 16
1.3.1 Mission de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . 16
1.3.2 Principes fondamentaux de l’entreprise . . . . . . . . . . . . . . . . 17
1.4 L’application "FoodSafety" . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.6 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.7 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.8 Solutions envisagées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.9 Planification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.10 Choix de l’outil de planification . . . . . . . . . . . . . . . . . . . . . . . . 20
1.11 Méthodologies de gestion du projet . . . . . . . . . . . . . . . . . . . . . . 21
1.11.1 Principes de la méthode SCRUM . . . . . . . . . . . . . . . . . . . 21
1.11.2 Étude comparative entre les approches de l’informatique décisionnelle 22
1.11.2.1 L’approche TOP-DOWN . . . . . . . . . . . . . . . . . . 23
1.11.2.2 L’approche BOTTOM-UP . . . . . . . . . . . . . . . . . . 23
1.11.3 Choix de la méthode adéquate avec SCRUM . . . . . . . . . . . . . 23
1.12 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2 Sprint 0 : Analyse, spécification des exigences et choix technique 24

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.2.1 Environnement de développement . . . . . . . . . . . . . . 25

7
TABLE DES MATIÈRES 8

2.2.2.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.2.3 Outil de modélisation UML . . . . . . . . . . . . . . . . . 26
2.3 Spécification des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.2 Exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . 27
2.4 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6 Analyse globale des exigences . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.7 Analyse de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.8 Conception globale de data mart . . . . . . . . . . . . . . . . . . . . . . . 34
2.9 Étude du modèle conceptuel . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.9.1 Schéma global de la conception . . . . . . . . . . . . . . . . . . . . 37
2.9.2 Dimensions dégagées . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.10 Choix des outils Business Intelligence . . . . . . . . . . . . . . . . . . . . . 38
2.10.1 Étude comparative des outils ETL . . . . . . . . . . . . . . . . . . 38
2.10.2 Étude comparative des outils de visualisation . . . . . . . . . . . . 40
2.11 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3 Développement de scripts de génération de données 42

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2 Backlog de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 Keycloak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.3 Processus de communication . . . . . . . . . . . . . . . . . . . . . 45
3.4 Utilisation de Faker pour la génération de données . . . . . . . . . . . . . . 45
3.5 Scripting pour la partie user service (Keycloak) . . . . . . . . . . . . . . . 46
3.5.1 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5.2 Vérification de l’existence d’un realm et création . . . . . . . . . . . 46
3.5.3 Génération des utilisateurs et création dans Keycloak . . . . . . . . 47
3.5.4 Attribution de rôles spécifiques aux utilisateurs . . . . . . . . . . . 48
3.5.5 Validation des modifications . . . . . . . . . . . . . . . . . . . . . . 48
3.5.5.1 Validation des modifications dans Keycloak . . . . . . . . 48
3.5.5.2 Validation des modifications dans l’interface Keycloak . . 48
3.6 Intégration des données dans PostgreSQL . . . . . . . . . . . . . . . . . . . 49
3.6.1 Configuration de la base de données PostgreSQL . . . . . . . . . . . 50
3.6.2 Intégration des utilisateurs . . . . . . . . . . . . . . . . . . . . . . 50
3.6.3 Insertion des utilisateurs dans PostgreSQL . . . . . . . . . . . . . . 51
3.6.4 Validation des modifications dans PostgreSQL . . . . . . . . . . . . 52
TABLE DES MATIÈRES 9

3.7 Scripting pour la partie food service . . . . . . . . . . . . . . . . . . . . . . 53

3.7.1 Optimisation des attributs pour une analyse pertinente . . . . . . . 53
3.7.2 Insertion des demandes spécifiques . . . . . . . . . . . . . . . . . . 53
3.7.3 Insertion des demandes de campagnes . . . . . . . . . . . . . . . . . 54
3.7.4 Insertion des transactions . . . . . . . . . . . . . . . . . . . . . . . 55
3.7.5 Insertion des fonds . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.7.6 Validation des modifications dans PostgreSQL . . . . . . . . . . . . 56
3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4 Conception du data mart et implémentation de l’ETL 57

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2 Backlog de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3 Implémentation de data mart . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.1 Connexion à la base de données. . . . . . . . . . . . . . . . . . . . . 58
4.3.2 Création des jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.3 Création des dimensions . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.3.1 Optimisation des requêtes SQL pour l’extraction des données 61
4.3.3.2 Transformation des données . . . . . . . . . . . . . . . . 61
4.3.3.3 Chargement des données . . . . . . . . . . . . . . . . . . . 62
4.3.4 Alimentation de la Table de Jointure . . . . . . . . . . . . . . . . . 63
4.3.5 Alimentation de la table de faits . . . . . . . . . . . . . . . . . . . . 64
4.4 Gestion de la planification des tâches . . . . . . . . . . . . . . . . . . . . . 65
4.5 Communication automatique pour la maintenance système . . . . . . . . . 65
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5 Restitution des données 67

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Conclusion Générale 70
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
 TABLE DES FIGURES

1.1 Logo du Société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.2 Le tableau de bord de l’application "FoodSafety" . . . . . . . . . . . . . . 18
1.3 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4 Gestion des tâches avec Jira . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.5 Cycle de vie de l’approche SCRUM . . . . . . . . . . . . . . . . . . . . . . 22
1.6 L’équipe SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1 L’architecture en micro-services . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2 Diagramme de cas d’utilisation globale . . . . . . . . . . . . . . . . . . . . 31
2.3 Diagramme de classe globale . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4 Modèle relationnelle du base de donnée . . . . . . . . . . . . . . . . . . . . 33
2.5 Schéma du modèle en étoile . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.6 Schéma du modèle en flacon de neige . . . . . . . . . . . . . . . . . . . . . 36
2.7 Schéma du modèle en Constellation . . . . . . . . . . . . . . . . . . . . . . 37
2.8 Conception du modèle en étoile . . . . . . . . . . . . . . . . . . . . . . . . 37
2.9 Le processus ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.10 Logo Talend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.11 Logo PowerBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.1 Exemple d’utilisation de Faker pour la génération de données fictives . . . 45

3.2 Processus d’authentification avec Keycloak . . . . . . . . . . . . . . . . . . 46
3.3 Vérification de l’existence d’un realm et création . . . . . . . . . . . . . . . 47
3.4 Processus de génération et d’intégration d’utilisateurs avec Keycloak . . . . 47
3.5 Exécution du script python dans le terminal . . . . . . . . . . . . . . . . . 48
3.6 Résultats de la création d’utilisateurs et d’attribution de rôles dans Keycloak 49
3.7 Connexion à la base de données PostgreSQL . . . . . . . . . . . . . . . . . 50
3.8 Insertion des utilisateurs dans PostgreSQL . . . . . . . . . . . . . . . . . . 51
3.9 Visualisation des utilisateurs dans PG admin . . . . . . . . . . . . . . . . . 52

10
TABLE DES FIGURES 11

3.10 Processus d’insertion des demandes spécifiques . . . . . . . . . . . . . . . . 54

3.11 Insertion des demandes de campagnes dans PostgreSQL . . . . . . . . . . . 54
3.12 Processus d’insertion aléatoire de transactions . . . . . . . . . . . . . . . . 55
3.13 Insertion aléatoire de transactions de fonds . . . . . . . . . . . . . . . . . . 55
3.14 Validation des données après insertion . . . . . . . . . . . . . . . . . . . . 56

4.1 Connexion de Talend à la base de données PostgreSQL . . . . . . . . . . . 59

4.2 Création de jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3 Chargement automatisé de la dimension funds . . . . . . . . . . . . . . . . 60
4.4 Enregistrement des erreurs dans postgreSQL avec tFlowMeter . . . . . . . 61
4.5 Requête SQL pour sélectionner les données de la table campaign request . 61
4.6 Transformation de la Dimension Campaign Request . . . . . . . . . . . . . 62
4.7 Configuration du Chargement des Données PostgreSQL . . . . . . . . . . . 62
4.8 Processus de jointure des tables de dimension . . . . . . . . . . . . . . . . 63
4.9 Processus de jointure des tables de dimension avec tMap . . . . . . . . . . 63
4.10 Alimentation de la table de faits avec tMap dans talend . . . . . . . . . . . 64
4.11 Configuration du Composant tMap . . . . . . . . . . . . . . . . . . . . . . 64
4.12 Orchestration et Séquence des Jobs dans Talend . . . . . . . . . . . . . . . 65
4.13 Processus automatisé d’alerte par e-mail pour la maintenance . . . . . . . 65
 LISTE DES TABLEAUX

2.1 Tableau d’environnement matériel . . . . . . . . . . . . . . . . . . . . . . . 25

2.2 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3 Avantages et inconvénients du modèle en étoile . . . . . . . . . . . . . . . . 34
2.4 Avantages et inconvénients du modèle en flocon de neige . . . . . . . . . . 35
2.5 Avantages et inconvénients du modèle en constellation . . . . . . . . . . . . 36
2.6 Avantages et inconvénients de Talend et SSIS . . . . . . . . . . . . . . . . 39
2.7 Les avantages et les inconvénients de Power BI . . . . . . . . . . . . . . . . 40
2.8 Les avantages et les inconvénients de Tableau . . . . . . . . . . . . . . . . 40

3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

 INTRODUCTION GÉNÉRALE

Actuellement, de nombreuses entreprises, y compris les organisations caritatives, cherchent

à analyser les vastes quantités de données à leur disposition, qu’elles soient structurées ou
non structurées. Pour prendre les meilleures décisions et augmenter leur efficacité, l’une
des solutions efficaces est la Business Intelligence ou informatique décisionnelle. Cette
discipline, en plein essor depuis plusieurs années, est devenue un acteur clé, offrant une
vision globale de la situation des organisations.
Dans le cadre de notre application caritative, nous mettrons en place un tableau de
bord BI qui aidera les propriétaires et les utilisateurs à comprendre et à suivre le processus
de charité. La charité a toujours été un moyen vital de rassembler les gens pour aider les
plus vulnérables et construire des communautés plus fortes et plus unies. Grâce à ce
tableau de bord, nous visons à renforcer cet esprit de solidarité en fournissant des outils
d’analyse avancés pour une gestion plus efficace et transparente des activités caritatives.

13
CHAPITRE 1
CONTEXTE GÉNÉRALE DU PROJET

Sommaire
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Cadre générale du projet . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . 16
1.3.1 Mission de l’organisme d’accueil . . . . . . . . . . . . . . . . . . 16
1.3.2 Principes fondamentaux de l’entreprise . . . . . . . . . . . . . . 17
1.4 L’application "FoodSafety" . . . . . . . . . . . . . . . . . . . . . 17
1.5 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.6 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.7 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 19
1.8 Solutions envisagées . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.9 Planification du projet . . . . . . . . . . . . . . . . . . . . . . . 19
1.10 Choix de l’outil de planification . . . . . . . . . . . . . . . . . . 20
1.11 Méthodologies de gestion du projet . . . . . . . . . . . . . . . 21
1.11.1 Principes de la méthode SCRUM . . . . . . . . . . . . . . . . . 21
1.11.2 Étude comparative entre les approches de l’informatique déci-
sionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.11.3 Choix de la méthode adéquate avec SCRUM . . . . . . . . . . . 23
1.12 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

15
 1.1. INTRODUCTION

1.1 Introduction
Au sein de ce chapitre, nous réalisons une évaluation complète du projet. Nous dé-
butons en exposant tout d’abord l’entité d’accueil où s’est déroulé notre stage de fin
d’études. Ensuite, nous décrivons le contexte de notre projet ainsi que la méthodologie
adoptée pour parvenir aux résultats anticipés.

1.2 Cadre générale du projet

Ce projet est associé à la finalisation des études menant à l’obtention d’une licence
en "Business Computing", spécialité "Business Intelligence" et "Electronic Business", à
l’Institut supérieur d’informatique de Mahdia et à la Faculté des sciences économiques et
de gestion de Mahdia. Il a été effectué au sein de l’entreprise EARDEEP sur une période
de quatre mois.

1.3 Présentation de l’organisme d’accueil

EARDEEP, une société par actions simplifiée, enregistrée sous le numéro SIREN
913458204 et située en France à BONDY (de code postal 93140). Cette dernière est fondée
en 2022 par l’entrepreneur ingénieur Majed DAMMAK. Son domaine d’expertise réside
dans le conseil en systèmes et logiciels informatiques. Les sections ci-dessous fournissent
une description approfondie de ses activités et de ses principes fondamentaux.

Figure 1.1 – Logo du Société

1.3.1 Mission de l’organisme d’accueil

L’entreprise propose une gamme étendue de services axés sur le domaine de l’ingénierie
logicielle. Parmi eux, les plus significatifs sont les suivants :

• Conseil et consultation : Cette prestation consiste à intervenir chez le client

en apportant une expertise technique dans le domaine du DevOps (Développement
Opérationnel), contribuant ainsi au développement de projets.

• Recherche et développement : Cette activité implique l’acquisition de projets

en forfait, où une équipe est constituée pour prendre en charge l’intégralité du

16
 1.4. L’APPLICATION "FOODSAFETY"

projet localement (par exemple, la création d’une application web à architecture

distribuée). Elle englobe également la conception de solutions novatrices destinées
à être proposées sur le marché.

1.3.2 Principes fondamentaux de l’entreprise

L’objectif d’EARDEEP est de promouvoir un environnement de travail accueillant,
d’établir une communication professionnelle claire et de garantir à ses employés une au-
tonomie et une polyvalence. En adoptant l’approche agile SCRUM pour la réalisation de
ses projets, l’entreprise est en mesure de respecter les échéances tout en maintenant la
qualité de ses produits. Cela se traduit par la mise en place de réunions régulières, telles
que des réunions de sprint, afin de permettre à l’équipe de suivre l’avancement du projet,
ainsi que par l’utilisation d’outils de communication comme les applications de messagerie
instantanée (Slack) et les outils de gestion de projets en ligne (JIRA Software).
EARDEEP favorise également une interaction étroite avec ses clients, les impliquant
dès les premières étapes du processus de développement à travers des réunions et des
échanges réguliers. Cette approche vise à redéfinir en continu les besoins et les attentes
de chacun, réduisant ainsi les risques, favorisant le développement de produits efficaces et
optimisant le temps en évitant les ajustements ultérieurs.

1.4 L’application "FoodSafety"

"FoodSafety" représente une solution innovante pour renforcer la sécurité alimentaire.
Elle permet de digitaliser le processus de gestion des dons pour les administrations locales
ou gouvernementales, tout en servant de plateforme de communication entre les donateurs
et les organisations chargées de la gestion des dons. Cette application est développée en
utilisant une architecture microservices, garantissant ainsi une flexibilité et une évolutivité
optimales. Elle regroupe trois services :
Service "Food" : qui gére l’ensemble du processus de dons alimentaires.
Service "User" : qui gére pour les divers utilisateurs de l’application et leurs droits
d’accès.
Service "Analytic" : Analyse les données pour offrir une solution de Business Intel-
ligence, améliorant ainsi la gestion des activités caritatives et facilitant la prise de décision
pour une meilleure gestion des dons.
Cette dernière est proposée par l’UN-Habitat pour améliorer la gestion des activités
caritatives en Tunisie, son objectif est de faciliter et d’optimiser les opérations caritatives
en offrant transparence, anonymat, distribution équitable et impact durable. Les agents
de l’État peuvent utiliser cette plateforme pour gérer efficacement les dons, tandis que les
donateurs peuvent contribuer en toute confiance

17
 1.5. PROBLÉMATIQUE

1.5 Problématique
Nous sommes pleinement conscients de l’importance capitale des données dans divers
secteurs et de leur potentiel lorsqu’elles sont correctement exploitées. Cependant, dans
le contexte actuel de notre application "FoodSafety", l’affectation des dons ne garantit
pas de manière claire, transparente et prioritaire, ce qui entraîne un risque de mauvaise
gestion des dons. De plus, l’absence de rapports détaillés compromet notre capacité à
évaluer l’efficacité de nos activités caritatives et à prendre des décisions éclairées pour une
distribution équitable et prioritaire des dons.

1.6 Étude de l’existant

À ce jour, notre application "FoodSafety" présente un tableau de bord simple pour
tous les acteurs, comprenant :

• Le nombre de bénéficiaires

• Le nombre de donateurs

• Un diagramme illustrant le nombre de dons enregistrés sur "FoodSafety" au cours

des années précédentes.

De plus, un historique des dons est disponible, fournissant des informations détaillées pour
chaque transaction. Cependant, l’agent prend toutes ses décisions en se basant uniquement
sur ces informations limitées, ce qui peut restreindre sa capacité à prendre des décisions
éclairées et à répondre efficacement aux besoins des bénéficiaires.

Figure 1.2 – Le tableau de bord de l’application "FoodSafety"

18
 1.7. CRITIQUE DE L’EXISTANT

1.7 Critique de l’existant

L’insuffisance d’une solution BI performante se répercute négativement sur les per-
formances de notre application de gestion des dons, "FoodSafety". Cette lacune entrave
notre capacité à exploiter efficacement les données, à prendre des décisions éclairées, à ré-
pondre de manière agile aux besoins des bénéficiaires, ainsi qu’à organiser une distribution
transparente, ciblée et prioritaire des dons. Le tableau de bord actuel de "FoodSafety",
caractérisé par sa simplicité rudimentaire, son aspect statique et sa fonctionnalité sim-
pliste, s’avère être un obstacle majeur. En effet, cette simplicité entrave sa capacité à
soutenir l’expansion de nos activités et ne satisfait pas pleinement nos exigences.

1.8 Solutions envisagées

Pour pallier les lacunes identifiées dans notre étude de l’existant, EARDEEP propose
le développement d’une solution de Business Intelligence (BI) adaptée à notre application
"FoodSafety". Cette solution nous permettra :

• D’avoir une compréhension approfondie de nos données.

• De prendre des décisions éclairées basées sur des analyses approfondies.

• D’adapter nos actions de manière agile en fonction des besoins des bénéficiaires.

• D’organiser une distribution transparente, ciblée et prioritaire des dons.

• La mise en place des KPIs pour mesurer la performance et le progrès de l’activité afin
d’améliorer la prise de décision chez le décideur. Ce processus implique l’extraction
des données nécessaires à partir des données brutes par le processus ETL, puis leur
transformation en informations utiles, cohérentes et pertinentes.

• L’exploitation et l’analyse des données en créant des tableaux de bord contenant les
différentes KPIs pour faciliter la prise de décision.

De plus, EARDEEP envisage d’intégrer un modèle de Machine Learning afin

de réaliser des prédictions sur les dons, permettant ainsi une meilleure anticipation
des besoins et une gestion plus proactive des activités caritatives.

1.9 Planification du projet

Pour optimiser la planification et l’organisation des tâches de notre projet dans un délai
déterminé, nous avons élaboré ce diagramme de Gantt présentant les tâches suivantes dans
la figure 1.2

19
 1.10. CHOIX DE L’OUTIL DE PLANIFICATION

Figure 1.3 – Diagramme de GANTT

1.10 Choix de l’outil de planification

Dans le cadre de notre travail au sein de l’équipe EARDEEP, nous avons choisi d’uti-
liser Jira comme outil de planification pour plusieurs raisons. Tout d’abord, Jira offre
une interface conviviale et intuitive, ce qui facilite la gestion de notre backlog et de nos
tâches. De plus, la fonctionnalité de backlog de Jira nous permet de hiérarchiser et de
suivre efficacement nos différentes user stories, bugs et tâches, nous permettant ainsi de
rester organisés et de concentrer nos efforts sur les éléments les plus importants. En uti-
lisant Jira, nous avons pu rationaliser notre processus de planification et de suivi, ce qui
nous permet de travailler de manière plus efficace et collaborative comme illustré dans la
figure 1.4 ci-dessous :

20
 1.11. MÉTHODOLOGIES DE GESTION DU PROJET

Figure 1.4 – Gestion des tâches avec Jira

1.11 Méthodologies de gestion du projet

Étant donné que notre projet de fin d’études est mené au sein de l’entreprise EAR-
DEEP, nous avons mis en œuvre la méthodologie de travail agile SCRUM, adoptée par
notre entreprise. SCRUM BI est une approche agile spécifiquement conçue pour la gestion
des projets BI. Elle repose sur le concept d’itérations ou de sprints quotidiens, favorisant
ainsi une livraison rapide des projets d’informatique décisionnelle tout en minimisant les
coûts.

1.11.1 Principes de la méthode SCRUM

La méthodologie SCRUM BI repose sur le principe de sprints d’une durée variant de 7
à 30 jours. Le Product Owner se réunit avec l’équipe pour identifier et planifier les tâches
clés, constituées du Backlog de produit (liste des exigences fonctionnelles). Pour garantir
un bon déroulement, il est essentiel de détailler le processus de développement dans le
Backlog de sprints, lequel est évalué quotidiennement par l’équipe. À la fin de chaque
sprint, toutes les équipes se rassemblent pour évaluer le travail accompli et planifier le
prochain sprint, et cela se répète jusqu’à l’achèvement du produit final. Le Scrum Master
supervise le processus de travail afin détecter tout obstacle éventuel rencontré par l’équipe.

21
 1.11. MÉTHODOLOGIES DE GESTION DU PROJET

Figure 1.5 – Cycle de vie de l’approche SCRUM

Dans la méthode SCRUM BI, trois rôles principaux sont identifiés :

*Le propriétaire du produit (Product Owner) : il représente le client, celui à
qui le produit final sera livré.
*Le maître Scrum (Scrum Master) : ce dernier agit en tant que chef de projet et
coordonne l’équipe agile.
*L’équipe de développement (Development Team) : composée des personnes
impliquées dans le projet (les techniciens, les ingénieurs...). Leur responsabilité est de
traduire les besoins définis par le client (Product Owner) en fonctionnalités utilisables.

Figure 1.6 – L’équipe SCRUM

1.11.2 Étude comparative entre les approches de l’informatique

décisionnelle
Plusieurs approches peuvent être utilisées pour assurer le succès de la planification des
projets. Parmi les approches les plus couramment employées, on trouve :

22
 1.12. CONCLUSION

1.11.2.1 L’approche TOP-DOWN

L’approche de Bill Inmon met en avant que le Data Warehouse (DW) constitue un
dépôt centralisé de données d’entreprise détaillées. À partir de ce DW, des datamarts sont
créés selon des schémas en étoile. La conception du Data Warehouse est une étape cruciale
dans un projet décisionnel. Le projet comprend les étapes suivantes : lors du premier
sprint, les données nécessaires à la conception du DW sont extraites. Une fois le DW conçu,
les domaines spécifiques pour construire les datamarts destinés aux analyses et rapports
des sprints suivants sont identifiés. Tout au long du processus, l’équipe présente une
version fonctionnelle au Product Owner en utilisant des données réelles afin de recueillir
ses retours.

1.11.2.2 L’approche BOTTOM-UP

L’informaticien Ralph Kimball, dans son approche décrit « Le data Warehouse peut
être vu comme l’union des Data Marts cohérents entre eux grâce aux dimensions conformes
». En d’autres termes, cette approche peut être alignée avec la méthode SCRUM, où nous
nous concentrons sur un processus métier pour chaque sprint.Nous couvrirons l’ensemble
du processus d’un projet de prise de décision, du processus d’extraction, de transforma-
tion et de chargement (ETL) à la génération de rapports. Cette approche garantit une
séquence cohérente de sprints où le processus et la complexité restent relativement les
mêmes, adaptés au sujet traité. Cela permet d’atteindre des résultats satisfaisants pour
les utilisateurs finaux.

1.11.3 Choix de la méthode adéquate avec SCRUM

Après avoir identifié les diverses approches possibles pour l’application de la méthode
Scrum, nous avons opté pour l’approche BOTTOM-UP. En conséquence, notre décision
est conforme aux exigences de notre projet visant à établir un data mart.

1.12 Conclusion
Au sein de ce premier chapitre introductif, nous avons introduit le contexte de l’orga-
nisme d’accueil ainsi que le cadre du projet. Après une présentation générale, nous avons
procédé à une analyse approfondie de la situation actuelle, nous permettant ainsi d’acqué-
rir une vision globale du projet. Ces aspects sont considérés comme des besoins initiaux
que nous nous efforcerons d’élucider dans les chapitres à venir.

23
CHAPITRE 2
SPRINT 0 : ANALYSE, SPÉCIFICATION DES EXIGENCES
ET CHOIX TECHNIQUE

Sommaire
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . 25
2.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . 25
2.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Spécification des exigences . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . 27
2.3.2 Exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . 27
2.4 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6 Analyse globale des exigences . . . . . . . . . . . . . . . . . . . 31
2.7 Analyse de données . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.8 Conception globale de data mart . . . . . . . . . . . . . . . . . 34
2.9 Étude du modèle conceptuel . . . . . . . . . . . . . . . . . . . . 34
2.9.1 Schéma global de la conception . . . . . . . . . . . . . . . . . . 37
2.9.2 Dimensions dégagées . . . . . . . . . . . . . . . . . . . . . . . . 38
2.10 Choix des outils Business Intelligence . . . . . . . . . . . . . . 38
2.10.1 Étude comparative des outils ETL . . . . . . . . . . . . . . . . 38
2.10.2 Étude comparative des outils de visualisation . . . . . . . . . . 40
2.11 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

24
 2.1. INTRODUCTION

2.1 Introduction
Ce chapitre marque le début du sprint 0 selon la méthodologie adoptée. Durant cette
étape initiale, notre objectif est de reconnaître les environnements de réalisation ainsi que
les intervenants impliqués, tout en approfondissant l’analyse de leurs besoins. Nous visons
également à définir les exigences fonctionnelles et non fonctionnelles de notre système
décisionnel afin de favoriser une conception claire et précise. En suite, nous nous penchons
sur les détails de la conception du datamart et sélectionnons les outils les plus appropriés
pour l’analyse et la visualisation des données.

2.2 Environnement de travail

Dans cette section, nous détaillons l’environnement matériel et logiciel de notre projet,
en mettant en avant les équipements utilisés ainsi que les outils logiciels essentiels.

2.2.1 Environnement matériel

Nous utilisons le tableau 2.1 pour explorer l’infrastructure matérielle qui a été indis-
pensable à la concrétisation de notre projet.

Ordinateur ASUS HP
Intel(R) Core(TM) i7-
Core(TM) i5-11300H @
Processeur 6700HQ CPU @ 2.60GHz
2.40GHz 3.11 GHz
2.11 GHz
RAM 8 GO 8 GO
Disque dur 512 SSD 1To
Système d’ex-
Windows 10 Professionnel Windows 10 Professionnel
ploitation

Table 2.1 – Tableau d’environnement matériel

2.2.2 Environnement logiciel

2.2.2.1 Environnement de développement
Visual Studio Code
«Visual Studio Code est un éditeur de code source léger mais
puissant qui s’exécute sur votre bureau et est disponible pour
Windows, macOS et Linux. Il est livré avec un support intégré
pour JavaScript, TypeScript et Node.js, il dispose d’un riche
écosystème d’extensions pour d’autres langages et environne-
ments d’exécution.» [Cod]

25
 2.2. ENVIRONNEMENT DE TRAVAIL

IntelliJ IDEA
« IntelliJ IDEA est l’IDE de premier plan pour le développe-
ment Java et Kotlin. Il vous aide à rester productif avec une
suite de fonctionnalités d’amélioration de l’efficacité telles que
l’assistance au codage intelligente, les refactoring fiables, la na-
vigation instantanée dans le code, les outils de développement
intégrés, le support du développement web et d’entreprise, et
bien plus encore. » [2]
Python
«Python est un langage de programmation interprété, orienté
objet, de haut niveau avec une sémantique dynamique. Ses
structures de données intégrées de haut niveau, combinées à
un typage dynamique et à un liage dynamique, le rendent très
attrayant pour le développement d’applications rapides, ainsi
que pour une utilisation en tant que langage de script ou de
liaison pour connecter des composants existants entre eux.» [4]

Keycloak
«Keycloak est un logiciel open source permettant l’authentifi-
cation unique avec gestion des identités et des accès pour les
applications et services modernes.» [?]

2.2.2.2 Design
Canva
«Canva est une plateforme de conception graphique multina-
tionale mondiale australienne utilisée pour créer des graphiques
pour les médias sociaux et des présentations. L’application
comprend des modèles prêts à l’emploi que les utilisateurs
peuvent utiliser.» [6]

2.2.2.3 Outil de modélisation UML

Lucidchart
«Lucidchart est une application de diagramme basée sur le
web qui permet aux utilisateurs de collaborer visuellement sur
le dessin, la révision et le partage de graphiques et de dia-
grammes, et d’améliorer les processus, les systèmes et les struc-
tures organisationnelles.» [7]

26
 2.3. SPÉCIFICATION DES EXIGENCES

2.3 Spécification des exigences

Pour garantir l’efficacité de notre système décisionnel, il est essentiel de définir préci-
sément les exigences fonctionnelles et non fonctionnelles.
Cette démarche nous permettra d’identifier clairement les modules à développer et de
concevoir un système qui réponde parfaitement aux attentes de nos clients.

2.3.1 Exigences fonctionnelles

Les besoins fonctionnels représentent la raison d’être de notre système décisionnel, car
ils sont indispensables pour répondre aux attentes de nos clients. Parmi ces besoins, nous
pouvons citer :

• La modélisation et la structuration centralisée des données à travers l’extraction, la

transformation et le chargement (ETL) sont essentielles pour l’analyse et la visua-
lisation claire des données.

• La solution doit être capable de gérer de grandes quantités de données de manière

efficace.

• La réalisation de tableaux de bord joue un rôle essentiel dans la gestion et la prise de

décisions efficaces. De plus, ils permettent aux décideurs de mieux gérer le processus
de collecte de dons et les transactions réalisées.

2.3.2 Exigences non fonctionnelles

Afin de garantir le bon fonctionnement du système décisionnel et de prévenir toute
anomalie, la solution déployée doit répondre à plusieurs exigences non fonctionnelles no-
tamment :
Ergonomie : Les tableaux de bord doivent présenter une conception visuelle simple
et attrayante.
Performance : La solution doit garantir des temps de réponse optimaux, même avec
un traitement de données volumineux, afin de maintenir des performances élevées et une
efficacité opérationnelle.
Sécurité : Il est essentiel de protéger les données sensibles, en particulier celles des
bénéficiaires et des opérations financières.

27
 2.4. ARCHITECTURE LOGIQUE

2.4 Architecture logique

Notre application Food Safety utilise une architecture en micro-services, composée de
trois services distincts : "Service Food", "Service Users" et "Service Analytic". Ces ser-
vices communiquent entre eux en utilisant un message broker AMQ (Advanced Message
Queuing Protocol) ou Protocole de File d’Attente de Messages Avancé. Il s’agit d’un pro-
tocole de messagerie standard ouvert qui permet une communication fiable et asynchrone
entre des systèmes distribués. La figure ci-dessous met en évidence cette architecture.

Figure 2.1 – L’architecture en micro-services

28
 2.5. BACKLOG DE PRODUIT

Service Food : Ce service est connecté à une base de données spécifique, qui est
une base de données PostgreSQL. Il dispose d’un “Éditeur d’événement” qui publie des
événements à un "Message Broker (AMQ)".
Service Users : Ce service est également connecté à une base de données spécifique. Il
dispose également d’un "Éditeur d’événement" qui publie des événements à un "Message
Broker (AMQ)".
Service Analytic : Ce service est connecté à une base de données spécifique. Contrai-
rement aux deux autres services, il utilise un "Gestionnaire d’événement" pour gérer les
événements provenant du "Message Broker (AMQ)".
Message Broker (AMQ) : Il s’agit du hub central pour la gestion des messages entre
les bases de données et les services. Il reçoit les messages des éditeurs d’événements des
services Food et Users, et les transmet au gestionnaire d’événements du service Analytic.

2.5 Backlog de produit

Nous commençons par établir le backlog de produit, qui oriente l’équipe de dévelop-
pement. Il s’agit d’une liste de fonctionnalités exprimées sous forme de besoins, classées
par ordre de priorité par le propriétaire de produit.Cela nous permet de dresser une liste
ordonnée des tâches à accomplir.
Le tableau 2.2 ci-dessous présente le backlog de produit que nous avons élaboré :

29
 2.5. BACKLOG DE PRODUIT

Table 2.2 – Backlog de produit

30
 2.6. ANALYSE GLOBALE DES EXIGENCES

2.6 Analyse globale des exigences

Dans cette section, nous réalisons une analyse globale à l’aide d’un diagramme de cas
d’utilisation pour détailler les principales fonctionnalités accessibles aux acteurs, ainsi,
on se base sur un diagramme de classe pour détailler les principales entités et leurs re-
lations dans l’application FoodSafety. Nous avons opté pour l’utilisation du langage de
modélisation UML en raison de sa polyvalence et de sa souplesse.
Diagramme de cas d’utilisation
La Figure 2.2 expose un diagramme de cas d’utilisation général, fournissant une repré-
sentation claire et organisée des liens entre les acteurs et les différents cas d’utilisation.

Figure 2.2 – Diagramme de cas d’utilisation globale

• L’ingénieur en Business Intelligence est responsable de la gestion des KPI et du

processus ETL.

• L’ingénieur en Business Intelligence est responsable de la gestion du data mart via

Talend.

• Après la maintenance du data mart, l’ingénieur en Business Intelligence (BI) est

chargé de le planifier ainsi que de créer de nouvelles dimensions et mesures.

31
 2.7. ANALYSE DE DONNÉES

• L’ingénieur est responsable de la gestion des tableaux de bord, ce qui peut inclure
l’ajout, la modification ou la suppression de tableaux de bord en fonction des besoins.

• L’ingénieur est chargé de développer un modèle de machine learning, ce qui com-

prend le déploiement, l’entraînement et l’évaluation du modèle.

• Le décideur a la possibilité d’examiner les KPI.

• A l’aide de cette solution décisionnelle, le décideur peut facilement consulter et

accéder aux différents tableaux de bord ainsi qu’aux prédictions réalisées par le
modèle ML.

Diagramme de classe
De même, la Figure 2.3 présente un diagramme de classe général, offrant une repré-
sentation claire et organisée des relations entre les classes et les différents attributs et
méthodes.

Figure 2.3 – Diagramme de classe globale

2.7 Analyse de données

Notre première étape dans la modélisation de notre data mart consiste à se connecter
à la base de données PostgreSQL afin d’analyser les données de nos acteurs, en utilisant le

32
 2.7. ANALYSE DE DONNÉES

langage SQL (Structured Query Language) pour la manipulation des données. Au cours
de cette étape, nous avons découvert que notre base de données contient plusieurs tables.
Nous nous sommes concentrés sur des tables spécifiques qui sont pertinentes pour les
besoins des acteurs.
Pour mieux comprendre les données, nous avons extrait le modèle relationnel de la
base afin de comprendre les connexions et les relations entre les tables, comme illustré
dans la figure.

Figure 2.4 – Modèle relationnelle du base de donnée

33
 2.8. CONCEPTION GLOBALE DE DATA MART

2.8 Conception globale de data mart

Un data mart, est une composante spécifique d’un entrepôt de données. Contrairement
à l’entrepôt de données, qui rassemble des données à l’échelle de l’entreprise, le data mart
se concentre sur des domaines ou des départements spécifiques de l’organisation. Il est
conçu pour répondre aux besoins analytiques particuliers de ces domaines en fournissant
un accès à des données précises et pertinentes. Cette approche permet aux utilisateurs
de bénéficier d’une vision approfondie et personnalisée des données qui les concernent,
favorisant ainsi une prise de décision plus efficace et stratégique au sein de l’entreprise.
Étant donné que la conception globale est une étape essentielle de la préparation de
data mart, nous débuterons par la présentation de la table des faits, suivie des dimensions.
Cette approche permettra d’obtenir une modélisation répondant de manière appropriée
aux besoins de l’entreprise.

• Fait : La table centrale du modèle dimensionnel, elle comprend des mesures et des
clés de dimensions définies pour assurer leur liaison. En d’autres termes, tout ce que
vous souhaitez analyser.

• Dimensions : Sont utilisées pour analyser les données de faits en fournissant une
structure permettant une analyse détaillée et pertinente. Chaque dimension com-
prend un ou plusieurs attributs.

2.9 Étude du modèle conceptuel

Le modèle conceptuel est une organisation de données conçue pour regrouper les don-
nées nécessaires à l’analyse d’un processus métier. Chaque activité possède sa propre
structure distincte en fonction des données requises.
Il existe trois modèles de conception d’entrepôt de données :
Modèle en étoile : Ce schéma illustre les liens entre les dimensions et les faits dans
un entrepôt de données sous forme d’étoile, où chaque dimension est directement reliée
à un fait.Une caractéristique avantageuse de ce modèle est sa réduction du nombre de
jointures nécessaires, ce qui simplifie l’analyse des données.

Avantages Inconvénients
Un schéma facile à représenter et à Occupe plus d’espace car il n’utilise
saisir. pas la normalisation
Les requêtes SQL sont simples et Schéma complexe et n’est pas faciles
s’exécutent rapidement. à modéliser
Complexité d’exécution des requêtes
SQL

Table 2.3 – Avantages et inconvénients du modèle en étoile

34
 2.9. ÉTUDE DU MODÈLE CONCEPTUEL

Figure 2.5 – Schéma du modèle en étoile

Modèle en flocon de neige : Le modèle en flocon de neige ressemble presque au

modèle en étoile, avec une table de fait centrale entourée de dimensions. La principale
différence réside dans une hiérarchisation plus complexe des dimensions. Ces dernières sont
organisées en fonction de la granularité des informations, avec des niveaux de relations
successifs jusqu’à atteindre la granularité la plus fine. Seul le premier niveau de granularité
est directement connecté à la table de fait, permettant ainsi une exploration plus détaillée
des données. Cependant, en raison du nombre de jointures, les requêtes sont plus lourdes
lors de l’interrogation.

Avantages Inconvénients
Les requêtes SQL deviennent
La normalisation permet d’éliminer
complexes en raison du nombre élevé de
toute redondance de données.
jointures entre les dimensions.
Grâce à la normalisation, il occupe Un schéma complexe peut être difficile
moins d’espace. à modéliser.
L’exécution des requêtes SQL peut être
complexe.

Table 2.4 – Avantages et inconvénients du modèle en flocon de neige

35
 2.9. ÉTUDE DU MODÈLE CONCEPTUEL

Figure 2.6 – Schéma du modèle en flacon de neige

Modèle en constellation : Il s’agit d’un modèle hybride combinant des schémas en

étoile et/ou en flocon de neige. Cette particularité se manifeste lorsque les tables de faits
partagent certaines tables de dimension.

Avantages Inconvénients
Les sous-modèles peuvent être modi- Comprendre et gérer les relations entre
fiés, intégrés ou supprimés sans affecter les différents sous-modèles peut être
les autres éléments de la base de difficile, ce qui complique la conception
données. et la maintenance.
L’intégration de la base de données
Les requêtes peuvent s’exécuter plus
avec d’autres systèmes peut devenir
rapidement en réduisant le nombre de
difficile en raison de sa complexité
tables jointes requis.
structurelle.
Fournit des avantages en termes de L’intégration avec d’autres modèles
performances. peut être complexe.

Table 2.5 – Avantages et inconvénients du modèle en constellation

36
 2.9. ÉTUDE DU MODÈLE CONCEPTUEL

Figure 2.7 – Schéma du modèle en Constellation

2.9.1 Schéma global de la conception

Nous avons choisi le modèle en étoile comme modèle conceptuel car il offre une
performance optimale tout en permettant une analyse approfondie de nos besoins.
La modélisation de DM est décrite dans la figure 2.4 :

Figure 2.8 – Conception du modèle en étoile

37
 2.10. CHOIX DES OUTILS BUSINESS INTELLIGENCE

2.9.2 Dimensions dégagées

Notre DM se compose de plusieurs dimensions, selon les axes d’analyse traités :
Donor : contient des informations relatives aux donateurs tels que le nom, adresse,
email, cin...
Beneficiary : contient des informations relatives aux bénéficiaires tels que le nom,
adresse, age...
Beneficiary-request : comprend des informations concernant les demandes spéci-
fiques des bénéficiaires, en vue de leur affectation à un donateur.
Campaign-request : contient des informations sur les événements lors desquels des
groupes de donateurs font des contributions à des groupes de bénéficiaires.
Funds : contient des informations concernant les fonds, notamment le montant actuel,
la date du dernier versement...
Transaction : comprend des détails sur les transactions monétaires, tels que l’affec-
tation des fonds, les ajouts d’argent, la date des transactions...

2.10 Choix des outils Business Intelligence

Pour assurer le succès d’un projet décisionnel, il est essentiel de sélectionner avec soin
les outils adaptés à son développement. De nos jours, ainsi que des outils spécialisés pour
des tâches spécifiques du processus de décision.Nous étudions attentivement certains de
ces outils afin d’identifier ceux qui conviendront le mieux à notre projet.

2.10.1 Étude comparative des outils ETL

La phase Extract-Transform-Load (ETL) englobe l’extraction, la transformation et le
chargement des données dans un entrepôt. À ce stade, les anomalies dans les données sont
identifiées, ce qui garantit la production d’informations fiables et compréhensibles pour
une prise de décision efficace.

Figure 2.9 – Le processus ETL

38
 2.10. CHOIX DES OUTILS BUSINESS INTELLIGENCE

Dans notre étude, nous avons focalisé notre attention sur SSIS et Talend :

• Talend Open Studio : Talend Open Studio est un outil open source développé
par la société Talend, reconnu comme un leader dans le domaine de l’intégration de
données. Il offre la possibilité de se connecter à diverses sources de données afin de
simplifier les processus ETL d’extraction, de transformation et de chargement. En
outre, il propose une variété de fonctionnalités telles que la migration et l’améliora-
tion de la qualité des données.

• Sql Server Integration Services : SSIS est un outil de migration de données

inclus dans la suite Microsoft. Il dispose d’un entrepôt de données qui facilite l’exé-
cution des processus de nettoyage et de chargement des données.

Outil
Avantages Inconvénients
ETL
-Pour utiliser des fonctionnalités
avancées, une maîtrise du langage
-Open source
Talend Java est requise.
-Outil puissant
-La structure présente une cer-
taine complexité.
-Absence de copier/coller des an-
-Développement rapide et perfor-
notations.
SSIS mant
-Difficultés lors de conversion de
-Support disponible
type de donnée

Table 2.6 – Avantages et inconvénients de Talend et SSIS

39
 2.10. CHOIX DES OUTILS BUSINESS INTELLIGENCE

–> D’après les résultats de l’étude présentés dans le tableau 2.5, nous avons opté pour
Talend, en raison de son interface intuitive et de ses fonctionnalités avancées d’intégration
et de gestion des données, ce qui en fait l’outil idéal pour la création efficace d’un data
mart.

Figure 2.10 – Logo Talend

2.10.2 Étude comparative des outils de visualisation

Pour analyser et visualiser nos données, il existe une variété d’outils disponibles sur
le marché. Parmi les plus populaires dans le domaine de l’informatique décisionnelle, on
retrouve notamment "Tableau", conçu par Tableau Software, et "Power BI", développé
par Microsoft.
Afin de sélectionner l’outil de visualisation le plus adapté, nous allons faire une re-
cherche sur chaque outil. Les tableaux 2.6 et 2.7 présentent une comparaison détaillée
entre "Power BI" et "Tableau". Cette démarche nous permet d’examiner les principaux
avantages et inconvénients de chaque solution, en vue de déterminer celle qui répond le
mieux à nos besoins spécifiques. Notre décision finale sera basée sur différents critères,
tels que la facilité d’utilisation, la connectivité avec les sources de données, les capacités
de visualisation, ainsi que la collaboration et le partage des rapports.

Avantages Inconvénients
Une quantité considérable de documen-
Partage des données limité
tation accessible
Une diversité étendue d’options gra- La version gratuite offre un espace de
phiques pour la visualisation stockage de données limité.
Mises à jour fréquentes et assistance
communautaire disponible

Table 2.7 – Les avantages et les inconvénients de Power BI

Avantages Inconvénients
Compétences de visualisation excep- La modélisation de schémas complexes
tionnelles n’est pas aisée.
Aucune option pour la planification
Connexion à différentes sources de don-
et l’actualisation automatique des rap-
nées
ports/Tableaux de bords

Table 2.8 – Les avantages et les inconvénients de Tableau

40
 2.11. CONCLUSION

-> Nous avons opté pour l’utilisation de Power BI, une suite d’outils d’informatique
décisionnelle intégrée à Microsoft Office 365. Cette solution nous permet de connecter
facilement nos sources de données, de traiter et d’analyser des données provenant de
diverses sources, ainsi que de créer des tableaux de bord et des rapports visuellement
immersifs et interactifs. De plus, elle nous offre la possibilité de visualiser ces données
sous forme de rapports et de tableaux de bord interactifs, répondant à nos besoins, qu’ils
soient descriptifs ou prédictifs.

Figure 2.11 – Logo PowerBI

2.11 Conclusion
Dans ce chapitre, nous avons recensé les exigences fonctionnelles et non fonctionnelles
de notre projet, ainsi que le backlog produit et les indicateurs clés de performance (KPI)
qui seront au centre de notre analyse. De plus, nous avons exposé le modèle conceptuel
de notre data mart et son architecture globale. Enfin, nous avons examiné la sélection
des outils de Business Intelligence, que ce soit pour la partie ETL ou pour la phase de
reporting.

41
CHAPITRE 3
DÉVELOPPEMENT DE SCRIPTS DE GÉNÉRATION DE
DONNÉES

Sommaire
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2 Backlog de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 Keycloak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.3 Processus de communication . . . . . . . . . . . . . . . . . . . 45
3.4 Utilisation de Faker pour la génération de données . . . . . . 45
3.5 Scripting pour la partie user service (Keycloak) . . . . . . . . 46
3.5.1 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5.2 Vérification de l’existence d’un realm et création . . . . . . . . 46
3.5.3 Génération des utilisateurs et création dans Keycloak . . . . . . 47
3.5.4 Attribution de rôles spécifiques aux utilisateurs . . . . . . . . . 48
3.5.5 Validation des modifications . . . . . . . . . . . . . . . . . . . . 48
3.6 Intégration des données dans PostgreSQL . . . . . . . . . . . . 49
3.6.1 Configuration de la base de données PostgreSQL . . . . . . . . 50
3.6.2 Intégration des utilisateurs . . . . . . . . . . . . . . . . . . . . 50
3.6.3 Insertion des utilisateurs dans PostgreSQL . . . . . . . . . . . . 51
3.6.4 Validation des modifications dans PostgreSQL . . . . . . . . . . 52
3.7 Scripting pour la partie food service . . . . . . . . . . . . . . . 53
3.7.1 Optimisation des attributs pour une analyse pertinente . . . . . 53

42
 3.7.2 Insertion des demandes spécifiques . . . . . . . . . . . . . . . . 53
3.7.3 Insertion des demandes de campagnes . . . . . . . . . . . . . . 54
3.7.4 Insertion des transactions . . . . . . . . . . . . . . . . . . . . . 55
3.7.5 Insertion des fonds . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.7.6 Validation des modifications dans PostgreSQL . . . . . . . . . . 56
3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

43
 3.1. INTRODUCTION

3.1 Introduction
Selon la méthodologie Scrum BI, ce chapitre représente le sprint 1. Ce sprint sera
spécifiquement dédié à la création de scripts visant à alimenter les bases de données des
services "food" et "user" avec des données fictives, étant donné que l’application est en
cours de maintenance. Ces données serviront au développement du datamart.

3.2 Backlog de sprint

Id user
User story Priorité
story
En tant qu’ingénieur BI, je veux comprendre
1 1
le fonctionnement de Keycloak.
En tant qu’ingénieur BI, je veux créer un
2 script pour alimenter la partie "User" de la 1
base de données.
En tant qu’ingénieur BI, je veux développer
3 un script pour transférer les utilisateurs vers 1
la base de données PostgreSQL.
En tant qu’ingénieur BI, je veux comprendre
4 les attributs de la table sélectionnée dans le 2
service "Food".
En tant qu’ingénieur BI, je veux développer
5 un script pour alimenter la partie "Food" de 1
la base de données PostgreSQL.
En tant qu’ingénieur BI, je veux tester et va-
6 1
lider les fonctionnalités développées.

Table 3.1 – Backlog du sprint 1

3.3 Keycloak
3.3.1 Présentation
Keycloak est un produit logiciel open source permettant une connexion unique avec la
gestion des identités et des accès, destiné aux applications et services modernes. Depuis
mars 2018, ce projet de la communauté WildFly est sous la direction de Red Hat, qui
l’utilise comme projet amont pour leur distribution Red Hat de Keycloak.
Keycloak prend en charge divers protocoles tels que OpenID, OAuth version 2.0 et
SAML, et propose des fonctionnalités telles que la gestion des utilisateurs, l’authentifica-
tion à deux facteurs, la gestion des autorisations et des rôles, la création de services de
jetons, etc.

44
 3.4. UTILISATION DE FAKER POUR LA GÉNÉRATION DE DONNÉES

3.3.2 Fonctionnement
Le fonctionnement de Keycloak repose sur un modèle basé sur les standards OAuth
2.0 et OpenID Connect. Il permet d’externaliser la gestion des utilisateurs, des rôles et des
autorisations, ce qui simplifie le développement d’applications sécurisées. Keycloak utilise
des tokens pour l’authentification et l’autorisation des utilisateurs, permettant ainsi de
sécuriser les API et les applications. Grâce à son interface utilisateur intuitive et à sa do-
cumentation complète, Keycloak facilite la mise en place d’un système d’authentification
robuste et sécurisé pour les applications web et mobiles.

3.3.3 Processus de communication

Keycloak offre la possibilité de communiquer à travers une interface, mais en raison de
la nécessité d’automatiser le processus d’alimentation de la base de données, nous avons
opté pour des requêtes HTTP directes via son API. Cela nous a permis d’automatiser
efficacement le processus d’alimentation de la base de données avec des données fictives.
À l’aide de scripts Python, nous avons pu interagir avec l’API de Keycloak pour récupérer
les utilisateurs, les rôles, ainsi que leurs attributs, et les transférer directement vers notre
base de données PostgreSQL.

3.4 Utilisation de Faker pour la génération de données

L’utilisation de Faker pour la génération de données consiste à exploiter une biblio-
thèque Python spécialisée dans la création automatique de données fictives réalistes. Faker
offre une large gamme de générateurs de données prédéfinis, permettant de produire des
valeurs aléatoires et cohérentes pour différents types de données, tels que des noms, des
adresses, des numéros de téléphone, des dates, des adjectifs, des professions, etc... Cette
approche facilite la création de jeux de données de test ou de simulation sans avoir besoin
de données réelles.
Un exemple concret de l’utilisation de Faker est illustré ci-dessous :

Figure 3.1 – Exemple d’utilisation de Faker pour la génération de données fictives

45
 3.5. SCRIPTING POUR LA PARTIE USER SERVICE (KEYCLOAK)

3.5 Scripting pour la partie user service (Keycloak)

3.5.1 Authentification
L’authentification avec Keycloak consiste à obtenir un jeton d’accès (access token) via
le protocole OAuth 2.0. Ce jeton d’accès est ensuite utilisé pour autoriser les requêtes
ultérieures à l’API Keycloak. Une fois que le jeton d’accès est obtenu, il est inclus dans
l’en-tête Authorization de chaque requête API envoyée à Keycloak pour autoriser l’accès
aux ressources protégées.
Le processus est illustré dans la figure 3.1 ci-dessous :

Figure 3.2 – Processus d’authentification avec Keycloak

3.5.2 Vérification de l’existence d’un realm et création

Le script commence par vérifier si un realm spécifique, tel que "food", existe déjà dans
Keycloak. Pour cela, il envoie une requête GET pour interroger l’API de Keycloak. Si
la réponse est un code 404 (non trouvé), cela signifie que le realm n’existe pas encore.
Dans ce cas, le script envoie une requête POST pour créer ce realm avec les paramètres
nécessaires, tels que le nom du realm et son état activé.

46
 3.5. SCRIPTING POUR LA PARTIE USER SERVICE (KEYCLOAK)

Figure 3.3 – Vérification de l’existence d’un realm et création

3.5.3 Génération des utilisateurs et création dans Keycloak

La génération des utilisateurs se fait de manière aléatoire à l’aide de la bibliothèque
Faker. Des profils uniques sont créés pour chaque utilisateur, notamment un nom d’utili-
sateur, un email, un prénom, un nom, un mot de passe et une profession aléatoire parmi
une liste prédéfinie. Ces utilisateurs sont ensuite créés dans Keycloak via des requêtes
POST à l’API admin de Keycloak, en utilisant le jeton d’accès obtenu précédemment.

Figure 3.4 – Processus de génération et d’intégration d’utilisateurs avec Keycloak

47
 3.5. SCRIPTING POUR LA PARTIE USER SERVICE (KEYCLOAK)

3.5.4 Attribution de rôles spécifiques aux utilisateurs

Une fois les utilisateurs créés, le script attribue des rôles spécifiques à chaque utilisa-
teur. Il envoie une requête GET pour obtenir l’ID du rôle à attribuer, puis une requête
POST pour associer ce rôle à l’utilisateur dans le realm.

3.5.5 Validation des modifications

À la fin de cette étape, la validation des modifications effectuées dans Keycloak se fait
à travers l’exécution du script Python. Cela inclut la création d’utilisateurs fictifs avec
l’attribution de rôles spécifiques via le script, suivie de la vérification des résultats dans
l’interface utilisateur de Keycloak.

3.5.5.1 Validation des modifications dans Keycloak

La figure ci-dessous illustre l’exécution du script Python pour la création d’utilisateurs

fictifs dans Keycloak et l’attribution de rôles spécifiques à ces utilisateurs. Le terminal af-
fiche les messages de succès pour chaque utilisateur créé, identifié par un nom d’utilisateur
généré aléatoirement.

Figure 3.5 – Exécution du script python dans le terminal

3.5.5.2 Validation des modifications dans l’interface Keycloak

Cette partie se concentre spécifiquement sur la validation des modifications effectuées

dans l’interface utilisateur de Keycloak après l’exécution du script Python. Vous pourrez

48
 3.6. INTÉGRATION DES DONNÉES DANS POSTGRESQL

détailler les étapes de vérification et de validation visuelle des utilisateurs créés et des
rôles attribués dans Keycloak. La figure 3.6 illustre le succès de l’ajout :

Figure 3.6 – Résultats de la création d’utilisateurs et d’attribution de rôles dans Key-

cloak

3.6 Intégration des données dans PostgreSQL

Dans cette partie, nous décrivons le processus d’intégration des données récupérées
depuis Keycloak vers une base de données PostgreSQL. L’objectif principal est de trans-
férer les utilisateurs du royaume "food" de Keycloak vers la base de données PostgreSQL
afin de faciliter le processus d’ETL pour une utilisation ultérieure dans le traitement des
données.

49
 3.6. INTÉGRATION DES DONNÉES DANS POSTGRESQL

3.6.1 Configuration de la base de données PostgreSQL

Avant de procéder à l’intégration des données, il est essentiel d’effectuer une confi-
guration initiale de la base de données PostgreSQL pour garantir que les paramètres de
connexion sont corrects et que la base de données est accessible depuis le script Python.

Figure 3.7 – Connexion à la base de données PostgreSQL

3.6.2 Intégration des utilisateurs

Dans cette intégration de données, plusieurs étapes cruciales sont réalisées pour facili-
ter le transfert des utilisateurs du royaume "food" de Keycloak vers une base de données
PostgreSQL. Tout d’abord, le script commence par obtenir un jeton d’accès à l’aide de
l’authentification par client, qui est essentiel pour interagir avec l’API Keycloak. Ensuite,
une connexion est établie avec la base de données PostgreSQL en utilisant les informa-
tions d’identification appropriées. Une fois connecté, le script récupère les utilisateurs du
royaume "food" de Keycloak par lots pour éviter les limitations de pagination. Ces utilisa-
teurs sont ensuite traités et insérés un par un dans la base de données PostgreSQL, où des
vérifications sont effectuées pour garantir l’intégrité des données et éviter les doublons.

50
 3.6. INTÉGRATION DES DONNÉES DANS POSTGRESQL

3.6.3 Insertion des utilisateurs dans PostgreSQL

Chaque utilisateur récupéré depuis Keycloak est inséré dans la base de données Post-
greSQL à l’aide de requêtes SQL. Des vérifications sont effectuées pour garantir l’intégrité
des données et éviter les doublons.

Figure 3.8 – Insertion des utilisateurs dans PostgreSQL

En cas d’erreur lors de l’insertion, des exceptions sont gérées pour afficher des messages
d’erreur appropriés :
UniqueViolation :Cette exception est levée lorsqu’une violation de contrainte d’uni-
cité se produit, par exemple, si un utilisateur avec le même nom d’utilisateur existe déjà
dans la base de données.
DataError :Cette exception est levée lorsqu’il y a une erreur de format de données,
par exemple, si une valeur ne correspond pas au type de données attendu dans la base de
données.
.Error :Cette exception est utilisée pour capturer toute autre erreur PostgreSQL qui
pourrait se produire lors de l’insertion.

51
 3.6. INTÉGRATION DES DONNÉES DANS POSTGRESQL

3.6.4 Validation des modifications dans PostgreSQL

Une fois la validation des modifications effectuée dans PostgreSQL après l’intégration
des données depuis Keycloak, on peut observer dans l’outil PG Admin la base de données
alimentée avec les utilisateurs provenant du royaume "food". Cela confirme le succès du
processus d’intégration et permet de visualiser les données ajoutées à la base de données,
comme le montre la figure ci-dessous :

Figure 3.9 – Visualisation des utilisateurs dans PG admin

52
 3.7. SCRIPTING POUR LA PARTIE FOOD SERVICE

3.7 Scripting pour la partie food service

Cette phase implique l’utilisation de scripts Python pour automatiser les processus
liés aux services alimentaires.

3.7.1 Optimisation des attributs pour une analyse pertinente

Chaque étape du script met en œuvre des calculs spécifiques pour valoriser les at-
tributs des données insérées, en tenant compte des besoins spécifiques pour obtenir des
données efficaces et représentatives. Par exemple, lors de l’insertion des utilisateurs, cer-
tains attributs comme l’âge, le sexe, l’adresse, ou l’état actuel sont valorisés en fonction
des informations disponibles dans le dictionnaire représentant chaque utilisateur. Ces va-
leurs conditionnelles sont dérivées des attributs supplémentaires stockés dans Keycloak,
tels que l’âge, le sexe, l’adresse et l’état actuel, s’ils sont disponibles. En ce qui concerne
les demandes de bénéficiaires et les campagnes, des valeurs aléatoires sont générées pour
des attributs tels que la date de création, le statut détaillé, le statut de la demande, le
montant total, le nom de la campagne, la collecte, la récupération, etc. Ces valeurs sont
déterminées de manière aléatoire à l’aide de générateurs de nombres et de listes prédé-
finies, garantissant ainsi une diversité et une représentativité des données insérées. De
même, les transactions sont générées avec des dates, des montants et des types aléatoires
pour refléter diverses interactions financières au sein du système. Ces calculs et valeurs
conditionnelles visent à enrichir les données insérées dans la base de données PostgreSQL,
fournissant ainsi un ensemble de données varié et utile pour les processus ultérieurs d’ana-
lyse et de traitement des informations.

3.7.2 Insertion des demandes spécifiques

Cette partie du code insère des Demandes Spécifiques dans la table "beneficiary re-
quest" de la base de données PostgreSQL. Chaque demande est associée à un bénéficiaire
et à un donateur, avec des détails tels que la date de création, le statut détaillé, le groupe
auquel elle appartient, le statut de la demande, et le montant total.
La figure 3.10 détaille l’insertion des demandes spécifiques :

53
 3.7. SCRIPTING POUR LA PARTIE FOOD SERVICE

Figure 3.10 – Processus d’insertion des demandes spécifiques

3.7.3 Insertion des demandes de campagnes

Ce bloc de code insère des Demandes de Campagnes dans la table "campaign request"
de la base de données PostgreSQL. Chaque Demande est définie par un numéro de de-
mande, une date de début et de fin, un statut détaillé, un groupe, des bénéficiaires, des
donateurs, un nom de campagne, des lieux de collecte et de récupération, une nomencla-
ture et un montant total.

Figure 3.11 – Insertion des demandes de campagnes dans PostgreSQL

54
 3.7. SCRIPTING POUR LA PARTIE FOOD SERVICE

3.7.4 Insertion des transactions

Cette partie du script crée des ’transactions’ et les insère dans une table transaction.
Chaque transaction est associée à un fonds spécifique et enregistre des détails tels que le
montant de la transaction, la date de la transaction et le type de transaction.

Figure 3.12 – Processus d’insertion aléatoire de transactions

3.7.5 Insertion des fonds

Ce bloc de code effectue des requêtes SQL pour récupérer des identifiants spécifiques
à partir de différentes tables de la base de données PostgreSQL, puis génère aléatoirement
et insère des transactions dans la table transaction en utilisant ces identifiants.

Figure 3.13 – Insertion aléatoire de transactions de fonds

55
 3.8. CONCLUSION

3.7.6 Validation des modifications dans PostgreSQL

Après l’insertion des données dans PostgreSQL, il est recommandé d’exécuter des
requêtes de validation pour vérifier l’intégrité des données et détecter toute violation
éventuelle de contrainte. Cela assure que la base de données reste cohérente et fiable,
prête à être utilisée pour les opérations ultérieures.

Figure 3.14 – Validation des données après insertion

3.8 Conclusion
À la fin de ce chapitre, nous pouvons dire que les objectifs que nous avions définis
pour le premier sprint ont été atteints et notre base de données est alimentée grâce à
l’utilisation de la bibliothèque Faker pour créer des scripts qui génèrent un ensemble de
données pour les deux parties, "user" et "food". Cela nous permettra d’appliquer l’ETL
lors du prochain sprint.

56
CHAPITRE 4
CONCEPTION DU DATA MART ET IMPLÉMENTATION
DE L’ETL

Sommaire
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2 Backlog de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3 Implémentation de data mart . . . . . . . . . . . . . . . . . . . 58
4.3.1 Connexion à la base de données. . . . . . . . . . . . . . . . . . 58
4.3.2 Création des jobs . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.3 Création des dimensions . . . . . . . . . . . . . . . . . . . . . . 60
4.3.4 Alimentation de la Table de Jointure . . . . . . . . . . . . . . . 63
4.3.5 Alimentation de la table de faits . . . . . . . . . . . . . . . . . 64
4.4 Gestion de la planification des tâches . . . . . . . . . . . . . . 65
4.5 Communication automatique pour la maintenance système . 65
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

57
 4.1. INTRODUCTION

4.1 Introduction
Ce chapitre présente le sprint 2, consacré spécifiquement au processus de préparation
des données ETL (Extract, Transform, Load) selon le cycle de vie décisionnel, ainsi qu’à
la conception du data mart.

4.2 Backlog de sprint

Id user
User story Priorité
story
En tant qu’ingénieur BI, je veux faire l’ex-
1 1
traction des données.
En tant qu’ingénieur BI, je veux effectuer les
2 1
transformations sur les données.
En tant qu’ingénieur BI, je veux charger les
3 1
tables de faits et les dimensions.
En tant qu’ingénieur BI, je veux planifier les
4 2
jobs pour l’exécution automatisée.
En tant qu’ingénieur BI, je veux automatiser
5 l’envoi des e-mails de notifications de main- 2
tenance.

Table 4.1 – Backlog du sprint 2

4.3 Implémentation de data mart

Nous avons utilisé Talend pour connecter, extraire, transformer et charger les données
dans le datamart, en automatisant le processus pour des mises à jour régulières et fiables.

4.3.1 Connexion à la base de données.

Nous avons d’abord connecté Talend à la base de données PostgreSQL, comme indiqué
dans la figure 4.1 :

58
 4.3. IMPLÉMENTATION DE DATA MART

Figure 4.1 – Connexion de Talend à la base de données PostgreSQL

4.3.2 Création des jobs

Au sein de Talend, la création d’un nouveau "job" constitue le point de départ pour
la réalisation d’un projet. Un "job" représente une unité de travail composée d’une sé-
quence d’étapes visant à extraire, transformer et charger les données vers une destination
spécifique.

Figure 4.2 – Création de jobs

59
 4.3. IMPLÉMENTATION DE DATA MART

4.3.3 Création des dimensions

Pour créer les dimensions, nous avons utilisé un processus ETL. On voit la dimension
"funds" dans l’exemple ci-dessous. Le flux de travail pour la création de la dimension suit
plusieurs composants :
tInput : Extraction des données de la source FoodSafety.
tUniqRow : Élimination des doublons.
tMap : Ce composant redirige et modifie les données provenant de plusieurs sources
vers une ou plusieurs destinations. Il offre des fonctionnalités diverses permettant d’effec-
tuer des opérations telles que les jointures, les transformations et les filtrages.
tOutput : Chargement des données transformées dans la table de dimension dim
funds.
tLogRow : Journalisation des données pour suivre et enregistrer les opérations effec-
tuées.
tDBCommit : Finalisation de la transaction pour garantir que toutes les modifica-
tions sont correctement enregistrées.

Figure 4.3 – Chargement automatisé de la dimension funds

Dans cette section, nous avons mis en place un processus de gestion des erreurs en
utilisant un composant Talend appelé TFlowMeter. Ce composant permet de capturer
et de stocker les flux d’erreurs dans des tables de la base de données, comme illustré par
les figures ci-dessous :

60
 4.3. IMPLÉMENTATION DE DATA MART

Figure 4.4 – Enregistrement des erreurs dans postgreSQL avec tFlowMeter

Ce processus assure l’extraction, la transformation et le chargement corrects des don-

nées, garantissant ainsi l’intégrité et la qualité des informations dans toutes les dimensions
créées.

4.3.3.1 Optimisation des requêtes SQL pour l’extraction des données

Nous avons optimisé les requêtes SQL utilisées pour extraire les données des sources.
La figure ci-dessous décrit une requête pour sélectionner toutes les données de la table
"campaign request".

Figure 4.5 – Requête SQL pour sélectionner les données de la table campaign request

4.3.3.2 Transformation des données

Dans la TMap, nous avons mis en œuvre des transformations complexes pour harmoni-
ser et préparer les données avant leur chargement dans le data mart. La figure ci-dessous
illustre le processus de génération automatique de séquences numériques à l’aide de la
routine Numeric.sequence :

61
 4.3. IMPLÉMENTATION DE DATA MART

Figure 4.6 – Transformation de la Dimension Campaign Request

Numeric.sequence : Nous avons utilisé cette fonctionnalité dans Talend pour générer
des séquences numériques de manière automatique et incrémentielle. Elle a été employée
pour créer des clés primaires dans nos dimensions.

4.3.3.3 Chargement des données

Avec le composant tDBOutput, nous allons charger les données dans une nouvelle base
de données. Ce composant permet d’effectuer des opérations d’insertion, de mise à jour
ou de suppression d’enregistrements dans la base ’foodsafety dim’, comme illustré dans la
figure ci-dessous.

Figure 4.7 – Configuration du Chargement des Données PostgreSQL

62
 4.3. IMPLÉMENTATION DE DATA MART

4.3.4 Alimentation de la Table de Jointure

Dans ce processus, nous avons configuré un job Talend pour alimenter une table de
jointure. L’image ci-dessus illustre l’utilisation du composant tMap pour joindre nos tables
de dimension.

Figure 4.8 – Processus de jointure des tables de dimension

Les données sont extraites de chaque table source et acheminées vers le composant
tMap, où les jointures sont effectuées en fonction des clés de correspondance définies.
Une fois les jointures réalisées, les données consolidées sont dirigées vers la table de sortie
’foodsafety dim’, comme le montre la flèche de sortie (out1). Ce processus assure l’inté-
gration des données de différentes sources en une table de jointure unifiée, prête pour des
analyses et rapports approfondis.

Figure 4.9 – Processus de jointure des tables de dimension avec tMap

63
 4.3. IMPLÉMENTATION DE DATA MART

4.3.5 Alimentation de la table de faits

Dans ce processus, nous avons configuré un job pour alimenter une table de faits
appelée fact donation. La figure ci-dessus montre l’utilisation du composant tMap pour
joindre plusieurs tables de dimension, notamment transaction dim, campaign request dim,
dim funds, donor dim, beneficiary request dim, et beneficiary.

Figure 4.10 – Alimentation de la table de faits avec tMap dans talend

La configuration du composant tMap dans Talend permet d’intégrer et de transformer

les données de plusieurs sources pour alimenter la table de faits ’fact donation’ . Le flux
principal est enrichi par des lookups des tables de dimensions, avec des mappages précis
pour chaque colonne. Une variable de séquence génère des identifiants uniques. Cette
configuration assure une consolidation fluide des données prêtes pour l’analyse.

Figure 4.11 – Configuration du Composant tMap

64
 4.4. GESTION DE LA PLANIFICATION DES TÂCHES

4.4 Gestion de la planification des tâches

Le job d’orchestration de Talend est crucial, car il organise l’ordre d’exécution des
jobs, gère leurs interdépendances et planifie leur lancement. Cela assure une mise à jour
régulière des données, comme montré dans la figure 4.12 .

Figure 4.12 – Orchestration et Séquence des Jobs dans Talend

4.5 Communication automatique pour la maintenance

système
Afin d’assurer la régularité du processus de maintenance et de garantir la disponibilité
continue des données, un système automatisé a été mis en place. Ce système est conçu
pour envoyer des notifications par e-mail à l’équipe de maintenance en cas de détection
d’anomalies dans le système, comme décrit dans le schéma présenté dans la figure 4.13 :

Figure 4.13 – Processus automatisé d’alerte par e-mail pour la maintenance

65
 4.6. CONCLUSION

• tsendmail permet d’envoyer automatiquement des e-mails de notification en cas

d’erreurs système. Intégré aux workflows de maintenance, il assure que les ingénieurs
reçoivent des alertes en temps réel, facilitant ainsi une intervention rapide et efficace
pour minimiser les interruptions.

4.6 Conclusion
Ce chapitre a couvert le sprint 2, centré sur l’ETL et la conception du data mart.
Nous avons expliqué la planification du sprint, la connexion à PostgreSQL, la création de
jobs, et la gestion des dimensions et des tables de faits avec Talend. Nous avons également
mis en place des notifications par e-mail automatisées pour la maintenance. Ces actions
ont assuré l’intégrité et la disponibilité des données, établissant une base solide pour des
analyses décisionnelles précises.

66
CHAPITRE 5
RESTITUTION DES DONNÉES

Sommaire
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

67
 5.1. INTRODUCTION

5.1 Introduction

68
 CONCLUSION GÉNÉRALE

70
 BIBLIOGRAPHIE

[Cod] VS Code. what is vs code ? "https ://code.visualstudio.com".

71