TABLE DES MATIÈRES

1 CADRE GÉNÉRAL DU PROJET 2

1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Présentation de A15 . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Présentation de ArpuPlus . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Description et critique de l’existant . . . . . . . . . . . . . . . . . . 4
1.2.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.4 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Choix de la méthodologie du travail . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Approche Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 La méthode SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3 Élaboration du Backlog Produit . . . . . . . . . . . . . . . . . . . . 7
1.4 Architecture décisionnelle de notre solution . . . . . . . . . . . . . . . . . . 9
1.5 Concepts fondamentaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5.1 L’informatique décisionnelle . . . . . . . . . . . . . . . . . . . . . . 10
1.5.2 Les Composants d’une chaîne décisionnelle . . . . . . . . . . . . . . 10
1.5.3 Zone de stockage des données . . . . . . . . . . . . . . . . . . . . . 11
1.5.4 La modélisation multidimensionnelle des données . . . . . . . . . . 12
1.5.5 Concepts du développement . . . . . . . . . . . . . . . . . . . . . . 16
1.5.6 Bibliothèques Python . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS 18

2.1 Backlog du Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Environnement logiciel et technologies utilisées . . . . . . . . . . . . . . . . 20
2.3 Sprint 1 : Identification des KPIs clés . . . . . . . . . . . . . . . . . . . . 21
2.3.1 Les indicateurs de performance de Revenue . . . . . . . . . . . . . . 21
2.3.2 Les indicateurs de performance de Marketing . . . . . . . . . . . . . 22
2.3.3 Les indicateurs de performance de l’activité des abonnés . . . . . . 22
2.4 Sprint 2 : Conception du schéma conceptuel des données . . . . . . . . . . 23
2.4.1 Identification de tables de faits . . . . . . . . . . . . . . . . . . . . 23
2.4.2 Identification des tables de dimensions . . . . . . . . . . . . . . . . 26
2.4.3 Schéma conceptuel de données . . . . . . . . . . . . . . . . . . . . . 30
2.5 Sprint 3 : Développement du système ETL . . . . . . . . . . . . . . . . . . 31

i
TABLE DES MATIÈRES

2.5.1 Phase d’extraction de données . . . . . . . . . . . . . . . . . . . . 31

2.5.2 phase d’intégration de données . . . . . . . . . . . . . . . . . . . . . 33
2.5.3 Phase d’alimentation des datamarts . . . . . . . . . . . . . . . . . . 40
2.5.4 Table de la table de dimension Date . . . . . . . . . . . . . . . . . . 42
2.6 Sprint 4 : Automatisation de processus ETL . . . . . . . . . . . . . . . . . 47
2.6.1 Automatisation du script Python . . . . . . . . . . . . . . . . . . . 47
2.6.2 Automatisation du package MasterDatamart . . . . . . . . . . . . . 48

3 Release 2 : ANALYSE ET VISUALISATION DE DONNÉES 50

3.1 Backlog du Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2 Environnement logiciel et technologies utilisées . . . . . . . . . . . . . . . 51
3.3 Sprint 1 : Phase de restitution des données . . . . . . . . . . . . . . . . . . 52
3.3.1 Connexion avec SQL Server Database . . . . . . . . . . . . . . . . . 52
3.3.2 Création des mesures avec DAX . . . . . . . . . . . . . . . . . . . . 52
3.3.3 Présentation de la page d’accueil . . . . . . . . . . . . . . . . . . . 54
3.3.4 Tableau de bord "Analyse des Revenus" . . . . . . . . . . . . . . . . 55
3.3.5 Tableau de bord "Analyse des Revenus en Dollars" . . . . . . . . . . 56
3.3.6 Tableau de bord "Analyse Financière des Coûts Marketing" . . . . . 57
3.3.7 Tableau de bord "Analyse de l’Activité des Abonnés" . . . . . . . . 58
3.3.8 Publication sur Power Bi Report Server . . . . . . . . . . . . . . . . 59
3.4 Sprint 2 : Construction du cube OLAP multidimensionnel . . . . . . . . . 60
3.4.1 Étapes de construction du cube OLAP . . . . . . . . . . . . . . . . 60
3.4.2 Optimisation des analyses avec le Cube OLAP . . . . . . . . . . . . 63
3.4.3 Cas d’illustration : Exploration des données de finance . . . . . . . 63

Conclusion Générale et perspectives 64

Biblioghraphie 66

ii
 TABLE DES FIGURES

1.1 Logo A15 [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Filiales de A15 [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Logo ArpuPlus [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Cycle de vie de la méthode SCRUM [4] . . . . . . . . . . . . . . . . . . . . 7
1.5 Architecture de notre solution décisionnelle . . . . . . . . . . . . . . . . . . 9
1.6 Architecture de chaine décisionnelle [5] . . . . . . . . . . . . . . . . . . . . 11
1.7 Zones de stockage des données [6] . . . . . . . . . . . . . . . . . . . . . . . 12
1.8 Modèle d’exemple en Drill-Down [7] . . . . . . . . . . . . . . . . . . . . . . 13
1.9 Modèle d’exemple en Roll-up [7] . . . . . . . . . . . . . . . . . . . . . . . . 14
1.10 Modèle en étoile [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.11 Modèle snowflake [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.12 Modèle en constellation [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1 Table de faits Fact_Revenue . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2 Table de faits Fact_MarketingCost . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Table de faits Fact_UserActivity . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Dimension Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5 Dimension Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.6 Dimension Country . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.7 Dimension Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.8 Dimension Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.9 Modèle conceptuel complet . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.10 Capture de données dans l’API JSON . . . . . . . . . . . . . . . . . . . . 31
2.11 Capture de données transformées en dataframe . . . . . . . . . . . . . . . 32
2.12 Le scénario de l’extraction des données à partir de l’API Json . . . . . . . 32
2.13 Extraction de données brutes sous format CSV . . . . . . . . . . . . . . . . 33
2.14 Créer une connexion du type Flat File . . . . . . . . . . . . . . . . . . . . 33
2.15 Configurer des colonnes du fichier CSV . . . . . . . . . . . . . . . . . . . . 34
2.16 Configuration de l’étape "agrégation" . . . . . . . . . . . . . . . . . . . . . 34
2.17 Connexion OLE DB avec la base de données StagingArea . . . . . . . . . . 35
2.18 Choix de colonnes utiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.19 Flux de chargement de la zone STG . . . . . . . . . . . . . . . . . . . . . . 36
2.20 Flux de chargement de la zone ODS . . . . . . . . . . . . . . . . . . . . . . 36
2.21 Colonne dérivée de la table ODS Country . . . . . . . . . . . . . . . . . . . 37

iii
Table des figures

2.22 Flux de chargement de la table ODS Country . . . . . . . . . . . . . . . . 37

2.23 Flux de chargement de la table ODS Country . . . . . . . . . . . . . . . . 38
2.24 Flux de chargement de la table ODS Operator . . . . . . . . . . . . . . . . 38
2.25 Flux de chargement de la table ODS Product . . . . . . . . . . . . . . . . 39
2.26 Flux de chargement de la table de ODS Currency . . . . . . . . . . . . . . 39
2.27 Flux de chargement de la table de dimension Country . . . . . . . . . . . . 40
2.28 Flux de chargement de la table de dimension Operator . . . . . . . . . . . 41
2.29 Flux de chargement de la table de dimension Product . . . . . . . . . . . . 41
2.30 Flux de chargement de la table de dimension Currency . . . . . . . . . . . 42
2.31 Création des colonnes de la table date . . . . . . . . . . . . . . . . . . . . . 42
2.32 Sélection des attributs de la table de fait Revenue . . . . . . . . . . . . . . 43
2.33 Flux de chargement de la table Fact_Revenue . . . . . . . . . . . . . . . . 43
2.34 Flux de chargement de la table Fact_MarketingCost . . . . . . . . . . . . 44
2.35 Flux de chargement de la table Fact_UserActivity . . . . . . . . . . . . . 44
2.36 Flux du package MasterDatamart Revenue . . . . . . . . . . . . . . . . . . 45
2.37 Test réussi du flux de données . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.38 Flux du package MasterDatamart Marketing . . . . . . . . . . . . . . . . . 46
2.39 Flux du package MasterDatamart UserActivity . . . . . . . . . . . . . . . 46
2.40 Sélection du fichier .py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.41 Horaire de l’automatisation . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.42 Mention du temps de l’automatisation du script python . . . . . . . . . . . 47
2.43 Configuration de job SQL agent . . . . . . . . . . . . . . . . . . . . . . . . 48
2.44 Mention du temps de l’automatisation du package MasterDatamart . . . . 48
2.45 Exécuter Job Sql Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.1 Connexion du Power Bi avec la base de données dans SSMS . . . . . . . . 52

3.2 Création de l’indicateur clé ARPU en DAX . . . . . . . . . . . . . . . . . . 52
3.3 Création de l’indicateur clé CA en DAX . . . . . . . . . . . . . . . . . . . 53
3.4 Création de l’indicateur clé Revenue par transaction en DAX . . . . . . . . 53
3.5 Création de l’indicateur clé ROI en DAX . . . . . . . . . . . . . . . . . . . 53
3.6 Création de l’indicateur clé CPA en DAX . . . . . . . . . . . . . . . . . . . 53
3.7 Création de l’indicateur clé CAC en DAX . . . . . . . . . . . . . . . . . . 53
3.8 Création de l’indicateur clé Churn Rate en DAX . . . . . . . . . . . . . . . 53
3.9 Création de l’indicateur clé Growth Rate en DAX . . . . . . . . . . . . . . 53
3.10 Création de l’indicateur clé Success Rate en DAX . . . . . . . . . . . . . . 54
3.11 Page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.12 Tableau de bord Analyse des Revenus . . . . . . . . . . . . . . . . . . . . . 55
3.13 Tableau de Bord Analyse des Revenus en Dollars . . . . . . . . . . . . . . 56
3.14 Tableau de bord Analyse Financière des Coûts Marketing . . . . . . . . . . 57
3.15 Tableau de bord Analyse de l’Activité des Abonnés . . . . . . . . . . . . . 58
3.16 Première étape de publication de notre solution sur Power Bi Report Server 59
3.17 Deuxième étape de publication de notre solution sur Power Bi Report Server 59
3.18 Troisième étape de publication de notre solution sur Power Bi Report Server 60
3.19 Dernière étape de publication de notre solution sur Power Bi Report Server 60
3.20 Création du nouveau projet multidimensionnel . . . . . . . . . . . . . . . . 61
3.21 Test de connexion avec la base de données . . . . . . . . . . . . . . . . . . 61
3.22 Étapes de configuration du cube . . . . . . . . . . . . . . . . . . . . . . . . 62
3.23 Test du déploiement du cube réussit . . . . . . . . . . . . . . . . . . . . . . 62

iv
 LISTE DES TABLEAUX

1.1 Backlog du Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 Backlog Produit - Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Tableau descriptif du fait Fact_Revenue . . . . . . . . . . . . . . . . . . . 24
2.3 Tableau descriptif du fait Fact_MarketingCost . . . . . . . . . . . . . . . . 25
2.4 Tableau descriptif du fait Fact_UserActivity . . . . . . . . . . . . . . . . . 26
2.5 Tableau descriptif du fait Revenue . . . . . . . . . . . . . . . . . . . . . . 27
2.6 Tableau descriptif de la dimension Operator . . . . . . . . . . . . . . . . . 27
2.7 Tableau descriptif de la dimension Country . . . . . . . . . . . . . . . . . . 28
2.8 Tableau descriptif de la dimension product . . . . . . . . . . . . . . . . . 29
2.9 Tableau descriptif de la dimension Currency . . . . . . . . . . . . . . . . . 29

3.1 Backlog Produit - Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 51

v
 LISTE DES ACRONYMES

BI : Business Intelligence
MENA : Middle East and North Africa
OLAP : Online Analytical Processing
DW : Data Warehouse
KPI : Key Performance Indicators
STG : Staging Area
ODS : Operational data store
ETL : Extract-Transform-Load
SQL : Structured Query Language
SSIS : SQL Server Integration Services
CPA : Cost per action
PY : Python
JSON : JavaScript Object Notation
CSV : Comma-separated values
API : Application Programming Interface
HTTP : Hypertext Transfer Protocol
DAX : Data Analysis Expressions

1
CHAPITRE 1
CADRE GÉNÉRAL DU PROJET

Introduction
ans ce premier chapitre, nous présentons l’organisme d’accueil au sein duquel ce projet
D a été réalisé. Ensuite, nous détaillons la présentation du projet, la critique de l’existant,
puis la solution proposée. Nous passons par l’identification des exigences et l’exposition
de la méthodologie de gestion du projet que nous allons adopter et son application durant
la période de réalisation. Puis, nous élaborons le Backlog Produit du projet et l’archi-
tecture de notre solution. Enfin, nous clôturons ce chapitre par l’exploration de concepts
fondamentaux qui sous-tendent le domaine de l’informatique décisionnelle.

1.1 Présentation de l’organisme d’accueil

1.1.1 Présentation de A15
Fondé en 2014, le groupe A15 est une entreprise de capital-risque en phase de démar-
rage. Elle se spécialise dans le financement des jeunes entreprises qui ont un fort potentiel
de croissance. Elle soutient les fondateurs audacieux de la région du Moyen-Orient et de
l’Afrique du Nord dès le début de leur parcours pour construire leur avenir. Cette société
joue un rôle crucial dans l’écosystème entrepreneurial en soutenant ces jeunes entreprises
à un stade précoce de leur développement.[1]

Figure 1.1 – Logo A15 [1]

2
Chapitre 1. CADRE GÉNÉRAL DU PROJET

A15 comprend plusieurs filiales, comme le montre la figure 1.2 :

Figure 1.2 – Filiales de A15 [2]

1.1.2 Présentation de ArpuPlus

ArpuPlus est une filiale de A15 fondée en 2003 dont le siège social au Caire en Égypte.
Elle s’opère avec plus de 200 employés qui sont répartis dans 12 bureaux et trois centres
de recherche et développement pour répondre aux besoins de plus de 40 opérateurs de ré-
seaux mobiles en touchant plus de 75% des abonnés mobiles de la région Moyen-Orient et
Afrique du Nord. Elle présente plusieurs services numériques tels que : gestion de contenu,
marketing, arts et divertissements.[3]

Figure 1.3 – Logo ArpuPlus [3]

Les bureaux sont situés en Égypte et au Maroc, couvrant ainsi l’Afrique du Nord.
Ils sont également présents en Côte d’Ivoire pour la région de l’Afrique de l’Ouest, ainsi
qu’au Pakistan et au Bangladesh pour l’Asie du Sud et de l’Ouest.

3
Chapitre 1. CADRE GÉNÉRAL DU PROJET

1.2 Présentation du projet

Cette section présente le cadre général du projet, la critique de l’existant ainsi que la
solution proposée.

1.2.1 Cadre du projet

Notre projet s’inscrit dans le cadre de notre stage de fin d’études au sein de l’entreprise
en vue de l’obtention de notre diplôme en mastère professionnel XXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXX.

1.2.2 Description et critique de l’existant

Actuellement, Mobizone Tunisia fournit plusieurs produits web qu’elle propose à des
opérateurs téléphoniques tenons l’exemple de Orange, qui jouent un rôle clé dans la ges-
tion des abonnements pour ces services : Lorsqu’un utilisateur souhaite s’abonner à un
service proposé par Mobizone, il le fait via son opérateur téléphonique. En plus de la four-
niture de ces produits, Mobizone Tunisia assure un suivi constant des bugs et problèmes
techniques dans ses systèmes.
Les données sur les produits web, utilisateurs, et performances financières sont stockées
au format JSON et accessibles via une API centralisée. Bien que cette dernière regroupe
toutes les informations nécessaires, Mobizone ne dispose pas d’un système efficace pour
analyser ou exploiter ces données en temps réel.
En conséquence, l’entreprise ne peut pas suivre facilement les indicateurs de performance
clés (KPI) ni extraire des informations exploitables. En fait, sans solution automatisée,
les rapports de performance doivent être générés manuellement, ce qui ralentit la prise de
décision et réduit la capacité de l’entreprise à anticiper et réagir rapidement aux évolu-
tions du marché.
Ainsi, Mobizone Tunisia souhaite mettre en place un suivi continu des performances fi-
nancières et de l’activité des abonnés. D’autant plus, Mobizone doit optimiser ses stra-
tégies commerciales, et ce en surveillant de près les revenus, les coûts de marketing, les
abonnements, les nouvelles souscriptions et les taux de désabonnement, afin de mieux
comprendre le comportement des utilisateurs et les tendances du marché. Sans ce suivi, il
devient difficile de prendre des décisions éclairées pour optimiser ses services et maximi-
ser les revenus. Un des problèmes majeurs de l’infrastructure actuelle est l’absence d’un
système décisionnel automatisé permettant de suivre les performances en temps réel.

1.2.3 Solution proposée

Afin de pallier les limitations exposées dans la section précédente, la solution proposée
vise à déployer un système décisionnel intégré. Ce système permettra à Mobizone Tunisia
d’analyser en temps réel les performances financières et l’activité des abonnés grâce à des
tableaux de bord interactifs, offrant un suivi précis des indicateurs clés de performance
(KPIs).
Le projet à réaliser doit suivre les étapes suivantes :
- Analyse des besoins métiers pour comprendre les processus des produits web de Mobi-
zone Tunisia.
- Définition des indicateurs clés de performance (KPIs) à suivre.

4
Chapitre 1. CADRE GÉNÉRAL DU PROJET

- Collecte des données via l’API JSON.

- Réalisation des flux ETL (Extraction, Transformation, Chargement) en convertissant
les données brutes issues de l’API en informations exploitables.
- Conception et mise en place des datamarts pour centraliser les données.
- Développement de tableaux de bord interactifs pour générer des rapports décisionnels
clairs et pertinents.
- Validation des résultats obtenus et optimisation des performances du système.
- Construction d’un cube OLAP pour l’analyse multidimensionnelle des données.

1.2.4 Identification des besoins

En effet, la réalisation d’une solution décisionnelle nécessite de considérer des exigences
fonctionnelles et non fonctionnelles.

Exigences fonctionnelles
Nous allons spécifier les besoins fonctionnels de la solution. Ces besoins représentent
ce que nos futurs systèmes doivent être capables de réaliser. Notre projet devra répondre
aux objectifs fonctionnels suivants :

— Le système doit générer des indicateurs clés de performance (KPI) adaptés aux dif-
férents secteurs de l’entreprise (finance, marketing, activité des abonnés), des filtres et des
analyses multi-axes permettant aux utilisateurs de suivre et d’évaluer les performances
en temps réel.

— La solution doit avoir une architecture BI comprend le Staging Area Operational

Data Store et enfin des Datamarts pour stocker les données efficacement.

— Les datamarts doivent être créés de sorte que les données doivent être efficacement
intégrées et non volatiles.

— Le système doit intégrer des processus automatisés pour l’extraction et le traite-

ment des données afin de faciliter l’analyse.

— Réalisation des tableaux de bords suivant les indicateurs des besoins pour faciliter
la prise de décision et l’optimisation des performances.

Exigences non fonctionnelles

Ce sont des propriétés internes et essentielles pour améliorer la productivité et le bon
fonctionnement du système.
Les exigences non fonctionnelles de notre solution décisionnelle sont définies par :

5
Chapitre 1. CADRE GÉNÉRAL DU PROJET

- Ergonomie : Pour assurer une expérience utilisateur optimal, l’ergonomie de nos

tableaux de bord est primordiale. Il faut garantir une interface captivante, facile à lire,
intuitive et compréhensible par l’utilisateur.

- Fiabilité et exactitude : Il est essentiel que la solution soit fiable et accessible en

permanence, ce qui réduit les interruptions et facilite la prise de décision.

- Évolutivité : Il est primordial que la solution soit évolutive, dans le but de répondre
aux besoins changeants de l’entreprise et s’adapter aux nouvelles exigences fonctionnelles
au fur et à mesure de son développement.

- Performance : La solution doit être efficace et en mesure de traiter de grandes

quantités de données, offrant ainsi des analyses rapides et en temps réel.

1.3 Choix de la méthodologie du travail

Nous allons adopter la méthodologie Agile Scrum pour ce projet, car elle est déjà bien
ancrée dans les pratiques de gestion de projets de l’entreprise Mobizone Tunisia. Cette
approche permettra de diviser le travail en cycles itératifs, ou sprints, afin de livrer des
fonctionnalités de manière progressive et d’ajuster les priorités en fonction des besoins
évolutifs.

1.3.1 Approche Agile

Selon Véronique Messager, la méthode agile «c’est une approche itérative et incré-
mentale,qui est menée avec un minimum de formalisme, dans un esprit collaboratif. Elle
présente un produit de haute qualité toute en prenant compte l’évolution des besoins des
clients.»[9]
La méthode agile est une méthode de gestion de projet. L’idée, lorsque nous utilisons
cette approche, est d’apporter souplesse et performance à la gestion de projet. Centrée
sur l’humain et la communication, elle permet aux clients de participer au développement
d’un produit tout au long de l’avancement du projet.[10] Il s’agit d’un cycle de dévelop-
pement qui implique le client au centre. Le client est présent dans la réalisation du début
à la fin du projet. Ce qui permet au demandeur d’avoir une meilleure visibilité. Le prin-
cipe de base consiste à proposer une version simplifiée du programme puis à intégrer des
fonctionnalités supplémentaires, par processus itératif. Ce denier, regroupe une séquence
d’instructions à répéter autant de fois que possible, selon le besoin.

Après avoir définir l’approche adoptée, il est important maintenant de choisir la mé-
thodologie de gestion du projet de type Agile qui est "la méthode scrum".

1.3.2 La méthode SCRUM

Scrum est l’une des méthodologies Agiles, qui fait une partie des plus répandues et des
plus structurées. Elle permet une conduite de projet, qui vise à améliorer la productivité
d’un côté et le produit, via des retours réguliers et fréquents. Le client ou l’utilisateur est
au noyau du processus agile de la méthode Scrum, car il est le pilote de l’équipe projet.

6
Chapitre 1. CADRE GÉNÉRAL DU PROJET

Ce mécanisme est pratiqué en cycles appelés sprints. Chaque sprint dure entre 2 jours à
4 semaines. [4] C’est ce qui est représenté sur la figure 1.5.

Figure 1.4 – Cycle de vie de la méthode SCRUM [4]

Le Product Owner se réunit avec les équipes du travail pour planifier des tâches appelant
Product Backlog. Et pour obtenir de bons résultats, il faut bien détailler le processus de
développement. Après avoir achevé un sprint, toutes les équipes se réunissent pour évaluer
le travail et puis planifient le sprint suivant jusqu’au effectué le produit final.
Scrum implique 3 rôles importants pour assurer une bonne collaboration d’équipes :
- Product Owner : définit les caractéristiques du produit à mettre en œuvre suite aux
feedbacks des clients et fixe le contenu et la durée des sprints.
- Scrum Master : contrôle l’avancement de l’équipe de développement et assure le bon
fonctionnement en veillant à ce que les pratiques de Scrum soient respectées pour garantir
le succès du produit final.
- Development team : ce sont les responsables de la mise en œuvre du produit talque la
conception, le développement et le test en respectant les caractéristiques présentes dans le
Product Backlog pour transformer les besoins de Product owner. La figure 1.5 qui illustre
le cycle de vie de la méthode SCRUM.

1.3.3 Élaboration du Backlog Produit

Le backlog produit joue un rôle principal pour assurer une meilleure qualité du produit.
Il est présenté sous forme d’une liste priorisée et hiérarchisée de tâches et de fonctionna-
lités.
Le backlog produit contient ces éléments suivants :
- Story ou User story : c’est une fonctionnalité.
- Fonctionnalité : il s’agit d’un service qui contient plusieurs user stories.
- Priorité : réalisée en fonction de la valeur du métier, des besoins du client et ses attentes.
Son échelle a la priorité allant de 1 (la plus forte) à 4 (la plus faible).
Voici le tableau 1.1 qui présente le "Backlog Produit" :

7
Chapitre 1. CADRE GÉNÉRAL DU PROJET

Table 1.1 – Backlog du Produit

Release Sprint
Release 1 User Story Fonctionnalité Priorité

Sprint 1 Définir les KPIs clés -Identifier les KPIs nécessaires en 1

fonction des objectifs métiers

Sprint 2 Concevoir le schéma - Identifier les tables de faits et 1

conceptuel des données dimensions.
- Créer et valider des diagrammes
de relations
Sprint 3 Extraire les données de - Développer un script Python 1
l’API JSON - Tester le script.
Intégrer les données dans - Créer les zones ODS et STG 1
ODS et STG - Développer le processus ETL
- Tester les données transformées
Charger les données dans les - Créer les tables des Datamarts 1
Datamarts. - Charger les données.
Sprint 4 Automatiser le script Py- - Développer le processus d’auto- 1
thon matisation
Automatiser les packages - Configurer un schedule pour 1
MasterDatamarts faire la mise à jour
Release 2

Sprint 1 Créer les tableaux de bord - Utiliser Power BI 1

- Création de rapports interactifs

Publier les rapports sur Po- - Configurer le processus de pu- 1

wer BI Report Server blication.
Sprint 2 Construire un cube OLAP - Créer le cube avec SSAS 2
- Tester le cube

8
Chapitre 1. CADRE GÉNÉRAL DU PROJET

1.4 Architecture décisionnelle de notre solution

Dans cette section, nous allons présenter une description détaillée du fonctionnement
de la solution à réaliser :

Figure 1.5 – Architecture de notre solution décisionnelle

1. Extraction des Données (API JSON en utilisant le Script Python)

Développer un script Python pour récupérer les données en temps réel depuis l’API JSON
de l’entreprise. Ce script devra établir la connexion à l’API, extraire les données brutes
et les mettre à jour automatiquement à chaque nouvelle réception de données.
2. Intégration des données (de Python et le fichier Excel à SSIS)
Les données extraites par le script Python et le fichier Excel (contenant des données sur
la devise pour alimenter la table de dimension Currency) sont transmises à SQL Server
Integration Services (SSIS) pour traitement et nettoyage. Deux zones de stockage sont
utilisées dans cette architecture :
STG (Staging Area) : Zone de transit où les données brutes sont déposées en vue de
leur transformation.
ODS (Operational Data Store) : Zone de stockage opérationnelle où les données sont
nettoyées et transformées avant d’être chargées dans les Datamarts. Dans ces deux zones,
les données subissent des processus d’extraction, de transformation et de nettoyage (ETL)
pour garantir qu’elles soient prêtes pour les étapes suivantes.
3. Chargement des Datamarts
Une fois que les données sont prêtes, elles sont chargées dans les Datamarts. A ce stade,
deux types de traitement sont à prévoir :
4. Reporting et Visualisation avec Power BI (du Datamarts vers Power BI
Desktop et Report Server)
L’exploitation des données chargées via Power BI Desktop, où des tableaux de bord inter-
actifs sont élaborés pour visualiser les performances de l’entreprise. Les rapports générés
dans Power BI Desktop sont ensuite publiés sur Power BI Report Server, garantissant
ainsi leur diffusion et publication en ligne.
5. Analyse OLAP avec SSAS (du Datamarts vers OLAP SSAS)
L’utilisation des données chargées se poursuit avec SQL Server Analysis Services (SSAS),
où un cube OLAP est créé. Ce cube permet d’effectuer une analyse multidimensionnelle
des données.

9
Chapitre 1. CADRE GÉNÉRAL DU PROJET

1.5 Concepts fondamentaux

1.5.1 L’informatique décisionnelle
Encore appelée business intelligence (BI), l’informatique décisionnelle regroupe l’en-
semble des processus qui permettent la collecte, l’analyse et le traitement de données
brutes et qui a l’objectif de la prise de décisions bien éclairées. Son fonctionnement est
basé sur un ensemble d’outils, de méthodes et de techniques, dont la synergie offre le
résultat attendu.[11] Ceci, a été théorisée en 1958 par Peter LUHN qui a défini les bases.
Ce rêve s’est concrétisé dans les années 90, époque à laquelle la business intelligence est
devenue standardisée, grâce à l’aide de personnes comme Howard DRESNER. À partir
des années 2000, qui sont caractérisées par la démocratisation des ordinateurs et de l’in-
ternet, l’informatique décisionnelle est devenue répandue.
C’est en raison de la quantité massive de données utilisateurs qui était maintenant ac-
cessible et de la nécessité pour les responsables d’obtenir des informations précises sur le
fonctionnement de leur entreprise. À partir de 2010, l’informatique décisionnelle a éga-
lement connu une croissance exceptionnelle. Cela est le résultat de l’intérêt des grandes
entreprises pour le big data et les possibilités qu’il offre en exploitant les informations
disponibles. [12]

1.5.2 Les Composants d’une chaîne décisionnelle

La chaîne décisionnelle est une chaîne qui permet le traitement de l’information.
Elle transforme les données collectées et extraites en informations claires et précises qui
peuvent être exploitées à des fins décisionnelles. L’ensemble de cette chaîne est composé
d’outils et d’éléments que l’on regroupe généralement en quatre catégories :

Première étape : Collecte de données

Cette première phase permet d’extraire les données en provenance des différentes
sources de l’entreprise soit internes ou externes. On appelle ce processus : Extraction
de données. Ensuite, ces données sont traitées et transformées en données structurées
et normalisées. Ceci, s’appelle le processus "ETL" : Maintenant on a des données bien
adaptées à des fins décisionnelles. [13]

Deuxième étape : Stockage des données

Il s’agit de centraliser les données structurées et traitées afin de les rendre accessibles
à des objectifs de décisions. Cela, nécessite la modélisation des données, qui implique le
stockage des informations dans un Data Warehouse ou un Data Mart (l’ensemble forme
un Data Warehouse), où les données sont stockées. Il s’agit d’une base de données spécia-
lement développée pour répondre aux besoins et analyser les décisions. [13]

Troisième étape : Restitution des données

Cette phase implique l’utilisation de différents outils tels que les tableaux de bord, les
outils de reporting, les statistiques et les portails d’accès aux tableaux de bord. L’objectif
principal est de fournir à toutes les parties prenantes impliquées dans la prise de décision
une vision claire des informations. [13]

10
Chapitre 1. CADRE GÉNÉRAL DU PROJET

Quatrième étape : Exploitation des données

Maintenant, on a des données bien traitées et centralisées dans Le Datamart, elles sont
disponibles pour l’analyse par les utilisateurs finaux ou les analystes. Divers outils sont
utilisés pour effectuer cette phase tels que les cubes OLAP (pour les analyses multidimen-
sionnelles), le Data Mining (pour rechercher des corrélations), ou encore des tableaux de
bord qui présentent les indicateurs clés. [13]
La figure 1.7 illustre les divers composants de chaine décisionnelle :

Figure 1.6 – Architecture de chaine décisionnelle [5]

1.5.3 Zone de stockage des données

Les données brutes extraites des diverses sources de l’entreprise passent par plusieurs
zones de stockage pour assurer le bon fonctionnement du système de base de données et
garantissent la fiabilité de traitement de données. Il s’agit de 2 zones principales pendant
la phase de l’intégration de données

Staging Area
STG (Staging Area) : est une base de données qui représentent une copie conforme de
la source de données et qui sont vidées à chaque exécution de l’ETL et sont actualisées en
temps quasi réel : Il s’agit d’une zone d’attente ou nommée aussi une « salle d’embarque-
ment » avant la phase ODS. C’est dans ces tables qu’on peut trouver des données dans
des formats non structurés. [14]

Operating Data Store

ODS (Operational Data Store) : est un ensemble de tables où les données brutes sont
chargées, transformées, et préparées avant leur intégration dans le Data Warehouse. Du-
rant cette phase, les données subissent diverses transformations telles que le nettoyage,
l’enrichissement, et l’agrégation avant l’alimentation du datamart et qui utilise comme
source le STG pour les rendre cohérentes et prêtes à être utilisées pour des analyses ap-
profondies. [15]

11
Chapitre 1. CADRE GÉNÉRAL DU PROJET

La figure 1.8 illustre le passage des données brutes dans les diverses zones de stockage
des données :

Figure 1.7 – Zones de stockage des données [6]

1.5.4 La modélisation multidimensionnelle des données

Data Warehouse
Data Warehouse ou appelé entrepôt de données est un système de gestion de données
conçu afin de prendre en charge la veille stratégique et l’analyse de l’ensemble d’une orga-
nisation. Il centralise souvent des volumes importants de données, notamment des données
historiques, provenant de diverses sources telles que des fichiers journaux d’applications
et des systèmes transactionnels. Les données, principalement structurées, sont stockées
avec un objectif bien défini. [16]

Datamart
Un datamart est une structure simple d’entrepôt de données qui est axée sur un seul
secteur d’activité spécifique dans l’entreprise comme les ventes, la finance ou le marketing.
Grâce à un datamart, les équipes peuvent accéder aux données et obtenir des informations
plus rapidement, car elles ne doivent pas consacrer beaucoup du temps à effectuer des
recherches dans le Data Wrehouse ou à regrouper manuellement des données provenant
de différentes sources.[16]

Concepts clés de la modélisation multidimensionnelle

La table de fait : Les tables de faits contiennent les mesures quantitatives ou
métriques qui découlent d’une transaction ou d’un événement. Les principales caracté-
ristiques qu’elles présentent sont qu’elles incluent des indicateurs tels que le chiffre d’af-
faires, la quantité, le coût et sont connectées aux tables de dimensions grâce à des clés
étrangères.[17]
La table de dimension : Les dimensions des tables renferment les caractéristiques des-
criptives des données. Ces tables de faits offrent le contexte requis pour saisir et interpréter
les mesures quantitatives présentes. Les principales caractéristiques sont les attributs tex-
tuels et descriptifs, souvent modifiés pour améliorer les performances des requêtes et la
simplicité, et peuvent inclure des hiérarchies pour faciliter des analyses à différents ni-
veaux de précision. [17]
Les indicateurs clés de performances : Indicateurs clés de performance (ICP) ou ap-
pelés aussi Key Performance Indicator (KPI) ce sont un ensemble de mesures quantifiables
qui sont utilisées afin d’évaluer la performance globale à long terme d’une entreprise. Ce

12
Chapitre 1. CADRE GÉNÉRAL DU PROJET

qui permet de suivre l’évolution de l’équipe ou l’organisation au regard des objectifs com-
merciaux clés. [18]

Cube OLAP multidimensionnel : Les données d’une entreprise sont organisées et

liées à plusieurs dimensions. Par exemple, le chiffre d’affaires d’une entreprise peut avoir
diverses dimensions et liées au titre d’exemple de table de dimensions :
Lieu (région, pays, état, dépôt), à la période (année, semestre, mois, semaine, jour), au
produit (vêtements, sexe, marque, catégorie, et plus encore. On veut visualiser le chiffre
d’affaires au niveau de plusieurs dimensions. Le cube OLAP est l’élément central de ce
concept. C’est une base de données multidimensionnelle organisée sous forme de tables.
Il est beaucoup plus rapide et efficace de traiter et d’analyser plusieurs dimensions de
données qu’une base de données relationnelle.[19]

Drill-down & Roll-up : Ces méthodes, appelées aussi forage vers le bas/vers le haut,
sont les méthodes les plus répandues pour une navigation dans un entrepôt de données.
Elles consistent à représenter les données du cube à un niveau de granularité inférieur.
Ces opérations ne sont pas aussi faciles à implémenter, car basées sur la notion d’une
bonne hiérarchisation des attributs d’une dimension et la différenciation entre tous les
niveaux de hiérarchie disponibles dans les différentes dimensions. [7]

Figure 1.8 – Modèle d’exemple en Drill-Down [7]

13
Chapitre 1. CADRE GÉNÉRAL DU PROJET

Figure 1.9 – Modèle d’exemple en Roll-up [7]

Les schémas dimensionnels

La modélisation dimensionnelle est une méthode de conception de bases de données qui
est utilisée pour centraliser les données dans un Data Warehouse dans le but d’optimiser
les performances de requêtes analytiques.
Nous distinguons 3 types : en étoile, en flacon, en constellation

- Modèle en étoile
Le modèle en étoile est une structure de base de la modélisation dimensionnelle où
une table de fait centrale est connectée à plusieurs tables de dimensions. Cette structure
a l’apparence en étoile de son schéma. La figure 1.11 un exemple du modèle en étoile.

Figure 1.10 – Modèle en étoile [8]

14
Chapitre 1. CADRE GÉNÉRAL DU PROJET

- Modèle en flocon
Le modèle en flocon ou appelé aussi snowflake est une extension du modèle en étoile.
Il est caractérisé par la normalisation des tables de dimensions, c’est-à-dire que les di-
mensions sont divisées en sous-tables supplémentaires qui représentent une hiérarchie. La
figure 1.12 un exemple du modèle en étoile.

Figure 1.11 – Modèle snowflake [8]

- Modèle en constellation
Le modèle en constellation est une approche plus avancée qui combine plusieurs mo-
dèles en étoile pour représenter un ensemble de faits interconnectés. Il est souvent utilisé
pour des systèmes analytiques très vastes ou multidimensionnels où plusieurs tables de
faits qui partagent les mêmes tables de dimensions comme l’illustre la figure 1.13.

Figure 1.12 – Modèle en constellation [8]

15
Chapitre 1. CADRE GÉNÉRAL DU PROJET

1.5.5 Concepts du développement

API
un ensemble de définitions et de protocoles qui facilite le développement et l’intégration
des applications. Elle permet à votre produit ou service de communiquer avec d’autres,
sans avoir à connaître les détails techniques de leur fonctionnement. Les API simplifient
ainsi la création d’applications, vous faisant gagner du temps et des ressources. Que vous
développiez de nouveaux outils ou gériez ceux existants, elles offrent plus de flexibilité,
simplifient la conception, l’administration et l’utilisation, tout en favorisant l’innovation.
[20]

JSON
JavaScript Object Notation est un format léger de texte utilisé pour échanger des
données. Il est facilement généré et interprété par les ordinateurs, tout en étant simple à
lire et à écrire pour les humains grâce à sa syntaxe claire et sa structure en arborescence.
Il permet de représenter des données structurées, similaire à XML. [21]

CSV
Valeurs séparées par des virgules est un format spécial que l’on peut créer ou modifier
avec Excel. Contrairement aux colonnes traditionnelles, les données sont séparées par
des points-virgules dans les fichiers CSV. Ce format permet de transférer facilement des
informations, comme du texte et des nombres, entre différents programmes. Par exemple,
vous pouvez exporter vos contacts de Google dans un fichier CSV, puis les importer dans
Outlook. [22]

1.5.6 Bibliothèques Python

Pandas
La bibliothèque open source Pandas est spécialement conçue pour la manipulation
et l’analyse de données en Python. Elle se distingue par sa performance, sa flexibilité et
sa simplicité d’utilisation. Pandas permet de charger, aligner, manipuler et fusionner des
données de manière efficace. Ses performances sont remarquables, notamment grâce à son
code back-end écrit en C ou Python. Cette bibliothèque permet également d’importer et
d’exporter des données qui sont en premier lieu transformées en dataframe, dans divers
formats tels que CSV et JSON et et propose des outils de nettoyage des données (Data
Cleaning).[23]

Dataframe Pandas : C’est une structure bidimensionnelle, où les données sont organisées
de manière tabulaire en lignes et colonnes. Cette structure est comparable aux diction-
naires en Python, où les colonnes sont représentées par des clés et les valeurs par des
Séries. Un data frame ressemble généralement à une feuille de calcul Excel ou à une table
SQL .

16
Chapitre 1. CADRE GÉNÉRAL DU PROJET

La syntaxe pour créer un data frame est la suivante : [Link](data, in-

dex, columns). Il peut être généré de différentes manières : à partir d’une matrice, d’un
dictionnaire, d’une liste (ou tuple), ou encore d’un fichier ASCII. Pour débuter, il est
nécessaire d’importer la bibliothèque Pandas sous l’alias pd, puis d’assigner les données
à des listes.[24]

Requests
La bibliothèque open source Pandas est spécialement conçue pour la manipulation
et l’analyse de données en Python. Elle se distingue par sa performance, sa flexibilité et
sa simplicité d’utilisation. Pandas permet de charger, aligner, manipuler et fusionner des
données de manière efficace. Ses performances sont remarquables, notamment grâce à son
code back-end écrit en C ou Python. Cette bibliothèque permet également d’importer et
d’exporter des données dans divers formats, tels que CSV et JSON, et propose des outils
de nettoyage des données (Data Cleaning).[25]

Conclusion
Ce chapitre a porté sur le cadre général du projet avec une présentation de l’entreprise
"Mobizone Tunisia" et une exposition des limitations identifiées et de la solution proposée
pour y remédier. Nous avons exposé, l’identification des exigences, le backlog produit,
l’architecture de notre solution, et notre choix de méthodologie du travail ainsi que les
principaux éléments de l’informatique décisionnelle qui constitueront le fondement de
notre modèle conceptuel.
Dans notre prochain chapitre, nous allons nous concentrer sur la réalisation du premier
release qui est la conception et mise en place des datamarts.

17
CHAPITRE 2
RELEASE 1 : CONCEPTION ET MISE EN PLACE DES
DATAMARTS

Introduction
ans cette section, nous allons faire le backlog du premier release en détail pour bien com-
D prendre les étapes, l’étude approximative des KPIs. Ensuite, la conception du modèle
de données de notre solution décisionnelle. Enfin, nous allons achever le développement
du système ETL et la phase de l’automatisation du processus de traitement des données.

2.1 Backlog du Release 1

La table 2.1 présente le backlog du premier release :

18
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Table 2.1 – Backlog Produit - Release 1

Release Sprint
Release 1 User Story Fonctionnalité Priorité

Sprint 1 En tant que informaticien, Identifier les KPIs clés nécessaires 1

je dois définir les KPIs
Sprint 2 En tant que informaticien, - Illustrer les relations entre les 1
je dois concevoir le schéma tables de faits et les dimensions.
conceptuel des données - Développer le schéma concep-
pour structurer les données. tuel des données.
Sprint 3 En tant que informaticien, Créer un script Python pour ré- 1
je dois extraire les données cupérer les données depuis l’API
de l’entreprise à partir d’une JSON.
API JSON - Tester le fonctionnement du
script pour s’assurer qu’il récu-
père correctement les données ac-
tualisées.
En tant que informaticien, - Créer une structure pour les 1
je dois intégrer les données zones de stockage ODS et STG.
dans les zones ODS et STG - Charger les données dans STG.
pour les stocker et les trans- - Développer un flux ETL pour
former. effectuer des transformations des
données dans ODS.
- Valider la qualité des données
après chaque étape de transfor-
mation.
En tant que informaticien, - Concevoir et établir les tables 1
je dois concevoir et intégrer nécessaires dans les datamarts.
les données dans les data- - Transférer les données transfor-
marts. mées depuis l’ODS vers les data-
marts.
- Assurer l’intégrité et la cohé-
rence des données chargées.
Sprint 4 En tant que informaticien, - Planifier avec Task Schedu- 1
je dois automatiser le script ler pour automatiser le processus
Python avec Task Schedu- d’extraction de données à partir
ler pour charger des données de l’API Json.
et garantir des mises à jour
continues.
En tant que informaticien, - Planifier avec SQL agent pour 1
je dois automatiser le char- automatiser le package "master-
gement de données dans le Datamart"
datamart chaque jour

19
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

2.2 Environnement logiciel et technologies utilisées

Dans cette section, nous allons présenter l’environnement logiciel et toutes les techno-
logies utilisées pour le premier sprint :

Visual Studio Code : c’est un éditeur de code source et un environne-

ment de développement intégré (IDE) créé par Microsoft. Cet IDE est open
source et multiplateforme, ce qui le rend compatible avec plusieurs systèmes
d’exploitation, tels que Mac, Windows et Linux. Bien qu’il ait été conçu à l’ori-
gine pour les développeurs web, il prend en charge de nombreux langages de
programmation, y compris C++, C, Python, Java, et bien d’autres.[26]

Python : est un langage de programmation largement utilisée et en évo-

lution constante dans le domaine des applications Web, le développement des
logiciels, Data science et Machine Learning. Les programmeurs optent pour
Python en raison de son efficacité et de sa facilité d’apprentissage, ainsi que
de sa compatibilité avec de multiples plateformes. Il est facile à utiliser et à
apprendre aussi.[27]

Visual Studio : c’est un éditeur le plus complet et le plus connu par les
développeurs .NET et C++ sur Windows. Grâce à un ensemble complet d’ou-
tils et de fonctionnalités, il est possible d’élever et d’améliorer chaque étape du
développement de logiciels.[28]

SQL Server Integration Services : est une plateforme open source

permettant de générer et traiter des solutions d’intégration et de trans-
formation de données dans une entreprise. Cette plate-forme est en évo-
lution constante. Les équipes de business intelligence optent pour cette
solution pour la génération fiable de quantités massives de données.
[29]

Task Scheduler : Il s’agit d’un outil intégré à Windows qui per-

met d’exécuter automatiquement des actions prédéfinies lorsque certaines
conditions sont remplies. Donnons un exemple : on peut programmer
une tâche pour exécuter un script de sauvegarde chaque nuit ou en-
voyer un e-mail chaque fois qu’un événement système spécifique se
produit.[30]

SQL Server Agent : SQL Server Agent est un service de Microsoft

Windows, existe dans SSMS et qui permet d’exécuter des tâches d’admi-
nistration planifiées, connues sous le nom de travaux dans SQL Server.
[31]

20
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

2.3 Sprint 1 : Identification des KPIs clés

Cette partie a pour objectif de sélectionner les indicateurs clés de performance les plus
pertinents pour atteindre à l’objectif de réaliser notre solution. Chaque indicateur fournit
des informations précises permettant d’évaluer la situation présente de l’entreprise et de
prendre des décisions éclairées en conséquence. Nous avons divisé les indicateurs clés de
performance en deux catégories : les KPI attributs, qui reflètent des valeurs fixes, et les
KPI métriques, qui mesurent des performances.

2.3.1 Les indicateurs de performance de Revenue

KPI Attributs

— Somme de Revenue Net : Ce KPI correspond au profit réel réalisé après avoir
pris en considération les dépenses directes. Ceci permet d’évaluer la rentabilité de
l’entreprise.
— Somme de Transaction à réussite unique : Ce KPI mesure le nombre total de
transactions qui ont été réussies sans annulation et sans problèmes ultérieurs c’est-
à-dire une seule fois. Ceci sert à évaluer l’efficacité des opérations de transaction et
à identifier les opportunités d’amélioration pour augmenter le taux de conversion.
KPI Métriques

— ARPU (Average Revenue Per User) : Mesure le revenu moyen généré par abon-
née. Cet indicateur est crucial pour suivre la performance financière moyenne par
abonné et permet d’évaluer la rentabilité de chaque utilisateur en fonction des
produits web.
— CA (Chiffre d’Affaires) : Le chiffre d’affaires indique le revenu total généré par
les abonnements aux produits web. Il est essentiel pour suivre la croissance et la
rentabilité des services proposés.
— Revenue par transaction : Cet indicateur mesure le montant moyen généré par
chaque transaction unique. Il est utile pour évaluer la valeur des inscriptions indi-
viduelles et leur impact sur le chiffre d’affaires total.

21
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

2.3.2 Les indicateurs de performance de Marketing

KPI Attributs

— Total Marketing Cost (Coût Total de Marketing) : Ce KPI mesure le total des
dépenses effectuées aux campagnes marketing, y compris les coûts des publicités. Ce
KPI permet de superviser et de gérer les budgets marketing et d’évaluer l’efficacité
des dépenses marketing par rapport aux revenus générés.
KPI Métriques

— CAC (Coût d’Acquisition Client) : Le Coût d’Acquisition Client représente le mon-

tant total dépensé pour acquérir un nouvel abonné. Il est utile pour évaluer l’effi-
cacité des campagnes marketing et des stratégies commerciales en termes de coûts
d’acquisition.
— ROI (Retour sur Investissement) : mesure le rendement généré pour chaque inves-
tissement réalisé dans les campagnes marketing ou les initiatives commerciales. Il
est utilisé pour évaluer la rentabilité des dépenses marketing.
— CPA (Coût par Action) : mesure le coût moyen par action, généralement par abon-
nement ou par souscription. Il permet de voir combien coûte chaque nouvelle sous-
cription ou action réussie sur les produits Mobizone.

2.3.3 Les indicateurs de performance de l’activité des abonnés

KPI Attributs

— Total des abonnées : Cet indicateur indique le nombre total d’abonnés actifs à un
moment donné. Il est essentiel pour surveiller la croissance ou la décroissance de
la clientèle, et pour évaluer l’efficacité des initiatives visant à fidéliser les clients.
KPI Métriques

— Churn Rate (Taux de Désabonnement) : Le taux de churn mesure le pourcen-

tage d’abonnés qui annulent leur abonnement à un produit Mobizone. Ce KPI est
crucial pour comprendre la fidélité des utilisateurs et identifier les opportunités
d’amélioration pour réduire les désabonnements.
— Growth Rate (Taux de Croissance des Abonnés) : Ce KPI mesure la croissance
du nombre d’abonnés sur une période donnée. Il aide à suivre la dynamique de la
clientèle et à évaluer l’efficacité des efforts d’acquisition et de fidélisation.
— Success Rate (Taux de Réussite des Transactions) : Le taux de réussite indique
la proportion des transactions réussies sur l’ensemble des tentatives effectuées. Il
est important pour surveiller la performance technique et commerciale des services
Mobizone, notamment en termes de souscriptions.

22
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

2.4 Sprint 2 : Conception du schéma conceptuel des

données
Dans notre solution et d’après l’étude des besoins, le choix des indicateurs clés de
performance et la diversité des domaines fonctionnels, nous avons défini 3 tables de faits
(Fact_Revenue, Fact_MarketingCost, Fact_UserActivity) qui partagent entre elles plu-
sieurs tables de dimensions. Par conséquent, le Modèle en constellation est le plus adapté
à notre projet.

2.4.1 Identification de tables de faits

Dans notre projet, nous avons besoin de trois tables de faits relatives à la revenue, le
marketing et l’activité des abonnées comme détaillées ci-dessous dans cette section.

La table de fait Fact_Revenue

La première table des faits contient l’ensemble des mesures relatives aux activités fi-
nancières de l’entreprise, accompagnées des références des clés primaires des tables de
dimensions utilisées pour l’analyse.

Figure 2.1 – Table de faits Fact_Revenue

23
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Pour décrire les attributs de la table de faits "Revenue", voici le tableau 2.2 qui inclut
les types et les significations :

Table 2.2 – Tableau descriptif du fait Fact_Revenue

Noms Types Significations
RevenueLCL décimal revenue en monnaie locale
RevenueUSD décimal revenue en dollars américains
GMRevenue décimal la marge brute
RevenueID integer Identifiant unique pour la table de faits
Nombre total de transactions réussies uniques pour
SuccessUniqueTransaction integer
une date donnée
OperatorID integer Clé étrangère de la dimension Operator (Opérateur)
CountryID integer Clé étrangère de la dimension Country (Pays)
ProductID integer Clé étrangère de la dimension Product (Produit)
DateKey integer Clé étrangère de la dimension Date
CurrencyID integer Clé étrangère de la dimension Currency (Devise)

La table de fait Fact_MarketingCost

Cette table contient les informations de Marketing de l’entreprise, accompagnées des
références des clés primaires des tables de dimensions utilisées pour l’analyse.

Figure 2.2 – Table de faits Fact_MarketingCost

24
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Pour présenter les attributs de la table de faits "MarketingCost", voici le tableau 2.3
qui décrit les types et leurs significations :

Table 2.3 – Tableau descriptif du fait Fact_MarketingCost

Noms Types Significations
CPAPerDay décimal Coût par acquisition par jour
MarketingCost décimal Coût de marketing pour la période donnée
MarketingCostID integer Identifiant unique pour la table de faits MarketingCost
OperatorID integer Clé étrangère de la dimension Operator (Opérateur)
CountryID integer Clé étrangère de la dimension Country (Pays)
ProductID integer Clé étrangère de la dimension Product (Produit)
DateKey integer Clé étrangère de la dimension Date

La table de fait Fact_UserActivity

Cette table contient les informations de l’activité des utilisateurs des produits Web
de l’entreprise, accompagnées des références des clés primaires des tables de dimensions
utilisées pour l’analyse.

Figure 2.3 – Table de faits Fact_UserActivity

25
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Pour expliquer les attributs de la table de faits "UserActivity", voici le tableau 2.4 qui
présente les différents types et leurs significations :

Table 2.4 – Tableau descriptif du fait Fact_UserActivity

Noms Types Significations
Nombre de nouveaux désabonnements pour la période
NewChurn integer
donnée
Nombre de nouveaux abonnements pour la période don-
NewSubscribers integer
née
Nombre de désabonnements le jour même de l’inscrip-
SameDayChurn integer
tion
TotalSubscriber integer Total des abonnés pour la période donnée
UserActivityID integer Identifiant unique pour la table de faits UserActivity
CountryID integer Clé étrangère de la dimension Country (Pays)
DateKey integer Clé étrangère de la dimension Date
OperatorID integer Clé étrangère de la dimension Operator (Opérateur)
ProductID integer Clé étrangère de la dimension Product (Produit)

2.4.2 Identification des tables de dimensions

Nous avons besoin de quatre tables de dimensions dans notre modèle.

Dimension Date
La dimension Date joue un rôle crucial dans un projet décisionnel, puisqu’elle per-
met l’analyse temporelle des données. Elle facilite la segmentation des informations par
période (jours, semaines, mois, trimestres, années) et assure la suivie de l’évolution des
KPIs dans le temps.

Figure 2.4 – Dimension Date

26
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

La table 2.5 décrit les attributs de la dimension product et définit leurs types et signifi-
cations.

Table 2.5 – Tableau descriptif du fait Revenue

Noms Types Significations
DateKey Integer Clé unique pour la dimension Date
Date Date Date complète au format YYYY-MM-DD
FirstDayOfMonth Date Premier jour du mois correspondant à la date.
LastDayOfMonth Date Dernier jour du mois correspondant à la date.
FirstDayOfQuarter Date Premier jour du trimestre correspondant à la date.
LastDayOfQuarter Date Dernier jour du trimestre correspondant à la date.
FirstDayOfYear Date Premier jour de l’année correspondant à la date.
LastDayOfYear Date Dernier jour de l’année correspondant à la date.
Year Integer Année extraite de la date
Quarter Integer Trimestre de l’année
Month Integer Mois de l’année
DayOfWeek Integer Jour de la semaine
DayOfYear Integer Jour de l’année

Dimension Operator
La dimension Operator contient toutes les informations relatives aux opérateurs. Ce
qui permet de suivre et d’analyser les performances des services en fonction de chaque
opérateur.

Figure 2.5 – Dimension Operator

La table 2.6 décrit les attributs de la dimension Operator et définit leurs types et leurs
significations.

Table 2.6 – Tableau descriptif de la dimension Operator

Noms Types Significations
OperatorID Integer Identifiant unique de l’opérateur
OperatorName Varchar Nom de l’opérateur

27
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Dimension Country
La dimension Country contient les noms des pays ainsi que leurs identifiants ce qui
facilite l’analyse géographique des performances et l’identification des tendances locales
dans un projet décisionnel.

Figure 2.6 – Dimension Country

La table 2.7 suivante décrit les attributs de la dimension product et définit leurs types et
leurs significations.

Table 2.7 – Tableau descriptif de la dimension Country

Noms Types Significations
CountryID integer Identifiant unique pour chaque pays
CountryName Varchar Nom complet du pays

Dimension Product
La dimension Product contient les noms des produits web ainsi que leurs identifiants.
Ceci facilite ainsi l’analyse de la performance et de l’adoption de chaque produit.

Figure 2.7 – Dimension Product

28
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Le tableau 2.8 suivant décrit les attributs de la dimension product et définit leurs
types et leurs significations.

Table 2.8 – Tableau descriptif de la dimension product

Noms Types Significations
ProductID integer Identifiant unique pour chaque produit
ProductName Varchar Nom complet du produit

Dimension Currency
La dimension Currency qui se relie avec la table de fait "Revenue", contient les infor-
mations relatives aux devises.

Figure 2.8 – Dimension Product

Le tableau 2.9 suivant décrit les attributs de la dimension currency (devise) et définit
leurs types et leurs significations.

Table 2.9 – Tableau descriptif de la dimension Currency

Noms Types Significations
CurrencyID integer Identifiant unique pour chaque devise
Country varchar Nom du pays associé à la devise
CurrencyNumber integer Numéro de la devise selon le standard ISO
Code à trois lettres représentant la devise
CurrencyCode varchar
(par exemple : USD)

29
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

2.4.3 Schéma conceptuel de données

Une fois que tous les composants ont été définis, le modèle conceptuel de données de
notre projet est illustré sous la forme d’un schéma en constellation, comme le montre la
figure suivante (Figure 2.9). Ce choix de représentation s’explique par le fait que les tables
de faits partagent des tables de dimensions communes.

Figure 2.9 – Modèle conceptuel complet

30
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

2.5 Sprint 3 : Développement du système ETL

Cette partie de notre solution décisionnelle est une étape essentielle qui nous permet de
traiter et transformer les données brutes provenant de notre source principal qui est : API
Json. Pour atteindre notre objectif, nous avons établi une série d’étapes systématiques.

2.5.1 Phase d’extraction de données

L’objectif principal au cours de cette phase est d’extraire les données à partir de l’API
JSON.
Pour réaliser cette tâche, le langage Python a été choisi, principalement pour sa flexibilité
et la richesse de ses bibliothèques dédiées à la manipulation de données et aux requêtes
http. Le développement du script s’est fait dans Visual Studio Code.
Python est particulièrement adapté pour interagir avec des APIs via les bibliothèques
requests et pandas.
- La bibliothèque requests est utilisée pour envoyer des requêtes http.
- La bibliothèque pandas est utilisée pour transformer et manipuler les données avant de
les exporter dans un fichier CSV.

Étapes de Développement du script python pour la récupération des données

via l’API JSON
Tout d’abord, on va utiliser Visual studio code pour développer un script Python.

1. Connexion à l’API JSON :

- Le script commence par établir une connexion avec l’API JSON en utilisant une requête
GET. Cette requête permet de récupérer les données stockées sur le serveur et les renvoyer
sous forme de JSON.
- Entrée : URL de l’API
- Processus : Le script Python utilise [Link](url) pour envoyer une requête GET à
l’API.
- Sortie : Réponse JSON (données reçues de l’API).

Figure 2.10 – Capture de données dans l’API JSON

2. Vérification de la Réponse
- Si la requête est réussie et que le code de statut HTTP est 200, cela signifie que les
données ont été récupérées avec succès. Sinon, un message d’erreur est affiché.
- Entrée : Code de statut HTTP de la requête GET.
- Processus : Si le code est 200, cela signifie que les données ont été récupérées avec succès.

31
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Sinon, un message d’erreur est affiché.

- Sortie : Soit les données JSON, soit une erreur.

3. Transformation des Données JSON en DataFrame

- Après avoir récupérer les données JSON, elles sont ensuite transformées en - DataFrame
à l’aide de la bibliothèque pandas pour faciliter leur manipulation.
- Entrée : Données JSON
- Processus : Les données récupérées sont transformées en un DataFrame à l’aide de la
bibliothèque pandas.
- Sortie : Un DataFrame pandas contenant les données JSON sous forme tabulaire.
Ceci illustré dans la figure 2.11 :

Figure 2.11 – Capture de données transformées en dataframe

4. Stockage local des Données

- La dernière étape est le stockage local des données sous format de CSV, c’est à dire
après la transformation en DataFrame, les données sont stockées localement dans un fi-
chier CSV pour être utilisées dans les étapes suivantes du processus ETL.
- Entrée : DataFrame pandas
- Processus : Le DataFrame est converti en fichier CSV via la méthode df.to_csv().
- Sortie : Fichier CSV stocké localement, contenant les données. Voici l’illustration 2.12
du scénario qui présente l’extraction de données à partir d’un API JSon.

Figure 2.12 – Le scénario de l’extraction des données à partir de l’API Json

32
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Ensuite, après avoir extraire les données, la figure 2.13 présente le format CSV de
données brutes.

Figure 2.13 – Extraction de données brutes sous format CSV

2.5.2 phase d’intégration de données

Chargement de la zone Staging Area « STG »
Extraction des fichiers CSV (Flat Files) : Les données sont d’abord extraites de
l’API au format JSON, puis elle est convertie en fichier csv appelé fichier plat ("flat file").
Voici ci-dessous les étapes d’intégration du fichier local csv dans le flux de chargement
de données dans STG. Tout d’abord, on ajoute une nouvelle connexion de type Flat File
à partir du "Connection manager" puis on la configurer pour faire intégrer le fichier csv
de données. Ces deux figures 2.14 et 2.15 illustrent la configuration du fichier CSV :

Figure 2.14 – Créer une connexion du type Flat File

33
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Figure 2.15 – Configurer des colonnes du fichier CSV

Une fois ce fichier est bien configuré, on effectue, ensuite, une "agrégation" des don-
nées afin de consolider et capter les informations similaires, pour éviter les doublons. On
coche nos colonnes dont lesquelles on veut seulement avoir des données uniques. Comme
l’illustre la figure 2.16 :

Figure 2.16 – Configuration de l’étape "agrégation"

34
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Après cette "opération d’agrégation", une autre opération suivante appelée "lookup"
est effectuée. Cette dernière a pour but de comparer les nouvelles données chargées dans
la zone STG avec celles déjà existantes. Tout d’abord, on assure la connexion avec la base
de données Staging Area nommée "StagingArea" et on choisit la table "DataSA" dans la
figure 2.17.

Figure 2.17 – Connexion OLE DB avec la base de données StagingArea

Ensuite, on coche les colonnes dont lesquelles on veut effectuer l’opération comme la
montre la figure 2.18 :

Figure 2.18 – Choix de colonnes utiles

Cette comparaison est utile pour la détection des différences, la recherche des doublons
et la mise à jour des informations déjà existantes. Enfin, les données sont prêtes à être

35
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

chargées dans la zone "STG". Cette phase a pour but de transférer les données transformées
depuis le fichier plat csv vers la table de Staging appropriée et c’est dans la figure 2.19 :

Figure 2.19 – Flux de chargement de la zone STG

Alimentation de la zone Operational Data Store « ODS »

L’alimentation de la zone Operational Data Store consiste à transférer les données de
STG vers ODS. Les principales étapes de cette phase telle que : le tri des données avec
l’outil "Sort" qui élimine les dupliqués, l’utilisation d’une opération de "Lookup" pour
comparer les nouveaux enregistrements avec ceux déjà existants, le split conditionnel qui
sert à séparer les enregistrements à mettre à jour de ceux à insérer, et l’exécution des
commandes d’insertion et de mise à jour dans l’ODS. Enfin, un test est effectué dans
la figure 2.20 pour garantir l’intégrité des données. Cette étape nous prépare à la phase
d’alimentation des datamarts.

Figure 2.20 – Flux de chargement de la zone ODS

Après avoir effectué le chargement de toutes les données dans la zone de stockage ODS,
on passe maintenant à alimenter les tables ODS_Country, ODS_Operator, ODS_Product,
ODS_Currency au cours desquelles on va effectuer diverses transformations.

36
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Alimentation de la table ODS_Country

Durant cette phase, il s’agit d’un transfert de données de la table principale de la base
de données ODS vers les tables secondaires crées pourqu’on puisse après transformer les
données et les charger dans les tables de dimensions d’une manière flexible et rapide. Après
avoir séléctionné la table Ods_Country dans la base de données ODS, une application
de transformation sur les données pour avoir une colonne dérivée effectuée par l’outil
"Derived Column" sous le nom du "CountryName", donc il s’agit d’une transformation au
niveau du Nom. Comme-ci le montre la figure 2.21 :

Figure 2.21 – Colonne dérivée de la table ODS Country

On passe, maintenant, à l’agrégation de données pour filtrer et éliminer toutes les

répétitions des enregistrements comme le montre la figure 2.22 :

Figure 2.22 – Flux de chargement de la table ODS Country

37
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Enfin, nous avons ce flux final qui était exécuté avec succès. Comme le montre la figure
2.23. Ainsi, qu’on obtient en total 4 pays.

Figure 2.23 – Flux de chargement de la table ODS Country

Alimentation de la table ODS_Operator

La table ODS_Operator passe par les mêmes étapes de celles de la table ODS_Country.
On peut conclure qu’après ces étapes de traitement, il s’agit d’un seul opérateur et ceci
le montre la figure 2.24 :

Figure 2.24 – Flux de chargement de la table ODS Operator

38
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Alimentation de la table ODS_Product

La table ODS_Product passe par les mêmes étapes de celles de la table ODS_Operator.
Et, on obtient 8 produits web dont laquelle l’entreprise produisent dans la figure 2.25.

Figure 2.25 – Flux de chargement de la table ODS Product

Alimentation de la table ODS_Currency

Le processus d’alimentation de la table ODS_Currency commence par l’importation
des données à partir d’un fichier plat qui est à la base un fichier Excel. Ce fichier contient
les informations nécessaires sur les devises, y compris les champs tels que CurrencyID,
Country, CurrencyNumber et CurrencyCode.

Figure 2.26 – Flux de chargement de la table de ODS Currency

39
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

2.5.3 Phase d’alimentation des datamarts

Après avoir effectué des transformations et des traitements sur les données de l’entre-
prise, nous passons à l’étape cruciale dans notre solution décisionnelle qui est la phase d’ali-
mentation des datamarts. Commençons par alimenter les tables de dimensions, concevoir
une table Date et enfin passons aux tables de faits (Fact_Revenue, Fact_MarketingCost,
Fact_UserActivity)

Alimentation de la table Dim_Country

La première étape dans la figure 2.27 consiste à extraire les données provenant depuis
la table ODS_Country. Mais tout d’abord, il faut éliminer les répétitions pour que les
résultats soient bien précis et pour garantir l’intégrité des données. Dans les tables de
dimensions, il est important de supprimer tous les doublons afin de garantir que chaque
donnée est représentée de manière unique. Maintenant, on passe par la deuxième étape :
Gestion des Dimensions à Évolution Lente "Slowly Changing Dimension". Une fois les
doublons sont éliminés, arrive le rôle de dimension à évolution lente permettant de suivre
les changements historiques dans les données dimensionnelles. Il apparait 3 états :
- New output : permettant de traiter les enregistrements qui n’existent pas déjà dans
la table de dimensions.
- Inferred Member Update Output : permettant de gérer les données qui sont incom-
plètes ou créées d’une manière provisoire lors de leur chargement. Une fois les données
sont complètes, il effectue une mise à jour.
- Changing Attribute Update Output : permettant la mise à jour des enregistrements
existants déjà dans la dimension une fois qu’il détecte une modification.

Figure 2.27 – Flux de chargement de la table de dimension Country

40
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Alimentation de la table Dim_Operator

Voici la figure 2.28 qui représente le flux d’alimentation de table Dim_Operator et qui
passe par les mêmes étapes précedentes :

Figure 2.28 – Flux de chargement de la table de dimension Operator

Alimentation de la table Dim_Product

Le flux d’alimentation de table Dim_Product est illustré dans la figure 2.29.

Figure 2.29 – Flux de chargement de la table de dimension Product

41
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Alimentation de la table Dim_Currency

Une fois que les données sont présentes dans ODS_Currency, elles sont ensuite trans-
formées et transférées vers la table de dimension Dim_Currency.

Figure 2.30 – Flux de chargement de la table de dimension Currency

2.5.4 Table de la table de dimension Date

La table de dimension temporelle est un élément essentiel dans la conception des
datamarts contenant des informations relatives au temps. Elle permet de réaliser divers
types d’analyses et de rapports basés sur des attributs temporels tels qu’ année, semestre,
trimestre, mois, semaine, jour, heure. Nous avons commencé par créer la dimension de
date, qui est fondamentale. La création de cette dimension a été réalisée à l’aide d’une
requête SQL intégrée dans SSMS qui est dans la figure suivante :

Figure 2.31 – Création des colonnes de la table date

42
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Alimentation de la table Fact_Revenue

Après le chargement des dimensions, nous passons à la phase de chargement des tables
de faits. Pour charger une table de faits, nous utilisons la base de données ODS pour
sélectionner les attributs spécifiques à la table de fait Revenue. Comme le montre la
figure 2.32 :

Figure 2.32 – Sélection des attributs de la table de fait Revenue

Nous utilisons, ensuite, les dimensions déjà actualisées afin de référencer les données à
charger. Ce processus est assuré par le composant de "Look up", qui effectue une opération
pour retrouver les clés primaires de toutes les dimensions.

Figure 2.33 – Flux de chargement de la table Fact_Revenue

43
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Alimentation de la table Fact_MarketingCost

La figure 2.34 illustre l’alimentation du fait Fact_MarketingCost.

Figure 2.34 – Flux de chargement de la table Fact_MarketingCost

Alimentation de la table Fact_UserActivity

La figure 2.35 illustre l’alimentation du fait Fact_UserActivity.

Figure 2.35 – Flux de chargement de la table Fact_UserActivity

44
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Organisation des Packages MasterDatamarts

Pour garantir une bonne organisation de notre solution décisionnelle, nous avons struc-
turé notre package MasterDatamart de manière à ce que les tables de l’ODS soient ali-
mentées en premier. Ensuite, l’alimentation de tables de dimensions et enfin, la table du
fait. Voici la figure 2.36 qui présente le flux du package MasterDatamart Revenue :

Figure 2.36 – Flux du package MasterDatamart Revenue

Cette figure 2.37 dont laquelle on teste le flux de datamart Revenue :

Figure 2.37 – Test réussi du flux de données

45
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Voici la figure 2.38 qui présente le flux du package MasterDatamart Marketing :

Figure 2.38 – Flux du package MasterDatamart Marketing

Voici la figure 2.39 qui présente le flux du package MasterDatamart UserActivity :

Figure 2.39 – Flux du package MasterDatamart UserActivity

46
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

2.6 Sprint 4 : Automatisation de processus ETL

2.6.1 Automatisation du script Python
Grâce à l’utilisation du "Task Scheduler" qui a pour objectif d’automatiser le script
Python pour l’extraction de données à partir de l’API Json, nous pouvons effectuer des
mises à jour régulières et précises des données sans exécuter le script python développé.
En mettant en place "Task Scheduler" afin d’exécuter automatiquement le script à des
intervalles prédéfinis, nous garantissons une bonne exécution du processus de l’extraction.
Cela assure la continuité des opérations et améliore l’efficacité de la gestion des données.
Tout d’abord, on commence par la configuration du processus tout en sélectionnant le
fichier ".Py" pour faire l’exécuter comme dans la figure 2.40.

Figure 2.40 – Sélection du fichier .py

Ensuite, dans la figure 2.41, on configure à quelle heure on veut l’exécution s’effectue.
Pour notre solution, nous voulons à 10 :00 AM.

Figure 2.41 – Horaire de l’automatisation

Enfin, on applique l’exécution du task configuré. On obtient le message : "opération réus-

sie" comme le montre la figure 2.42 :

Figure 2.42 – Mention du temps de l’automatisation du script python

47
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

2.6.2 Automatisation du package MasterDatamart

Il est crucial de mettre en place une automatisation du package "MasterDatamart"
avec "SQL Server Agent" afin de garantir une gestion efficace et continue des données.
Grâce à "SQL Agent", il est possible de prévoir et automatiser les tâches de mise à jour
des datamarts, en assurant ainsi que les données sont à jour et prêtes à être analysées.
Grâce à ce processus, elle permet de réduire les interventions humaines et minimiser les
erreurs manuelles. Tout d’abord, on configure le "Job SQL Agent" en mentionnant le pa-
ckage qu’on veut l’exécuter comme la montre la figure 2.43 :

Figure 2.43 – Configuration de job SQL agent

Ensuite, dans la partie "Schedules" illustrée dans la figure 2.44, nous mentionnons le temps
à quelle heure le package va être exécuter après l’automatisation du "Script Python".

Figure 2.44 – Mention du temps de l’automatisation du package MasterDatamart

On exécute, enfin, le Job SQL Agent comme illustré dans la figure 2.45 :

Figure 2.45 – Exécuter Job Sql Agent

48
Chapitre 2. Release 1 : CONCEPTION ET MISE EN PLACE DES DATAMARTS

Conclusion
Dans ce chapitre, nous avons détaillé le Backlog du premier release afin de clarifier
les étapes clés, y compris l’étude des indicateurs de performance (KPI). Ensuite, nous
avons conçu le modèle conceptuel des données pour notre solution décisionnelle, avant de
finaliser le développement du système ETL. Lors de notre prochain release, nous nous
concentrerons sur la génération de rapports et la construction du cube OLAP.

49
CHAPITRE 3
RELEASE 2 : ANALYSE ET VISUALISATION DE DONNÉES

Introduction
Dans ce dernier chapitre, nous allons traiter le deuxième release de notre solution dé-
cisionnelle. Nous allons commencer, tout d’abord, par présenter le Backlog du release
2, puis définir notre environnement logiciel et les technologies utilisées. Puis, nous nous
concentrerons sur la création des tableaux de bord et la construction d’un cube OLAP.

3.1 Backlog du Release 2

Voici le Backlog du deuxième release sous forme de table 3.1 :

50
Chapitre 3. Release 2 : ANALYSE ET VISUALISATION DE DONNÉES

Table 3.1 – Backlog Produit - Release 2

Release
Release 2 Sprint User Story Fonctionnalité Priorité

Sprint 1 En tant que informaticien, - Utiliser Power BI Report Desk- 1

je dois créer des rapports et top pour concevoir des rapports
des tableaux de bord pour la interactifs.
visualisation des données. - Créer des mesures DAX
- Configurer des tableaux de bord
pour différentes analyses.
En tant que informaticien, - Configurer le processus de pu- 1
je dois publier des rap- blication des rapports dans Power
ports pour garantir qu’ils BI report Server.
soient toujours en collabora-
tion avec les utilisateurs.
Sprint 2 En tant que informaticien, - Utiliser SSAS pour créer le cube 2
je dois construire un cube OLAP.
OLAP pour permettre des - Définir les dimensions et me-
analyses multidimension- sures nécessaires pour le cube.
nelles. - Charger les données du Data-
mart dans le cube OLAP.

3.2 Environnement logiciel et technologies utilisées

SQL Server Analysis Services : est un serveur de traitement analy-
tique de données. Il s’agit d’un moteur d’analyse conçu pour l’exploration de
données. Ceci, permet aux analystes de données de diviser de grandes quan-
tités de données en segments claires qui peuvent être analysables rapidement.
[32]

Power Bi RS Desktop : C’est une application bureau open source, qui

présente une installation très rapide et simple, vise à collecter et analyser des
chiffres d’une manière précise. Elle offre la possibilité de se connecter à di-
verses sources de données, de les transformer et de créer des rapports détaillés.
Sa force principale réside dans sa capacité à réaliser des analyses complexes et
à produire des visualisations interactives, ce qui en fait un outil indispensable
pour les analystes de données.[33]

Power Bi Report Server : également connu sous le nom de Power BI

Online, est conçu pour le partage et la collaboration. Il permet aux utilisateurs
de publier, partager et collaborer sur des rapports et tableaux de bord créés
avec Power BI Desktop. Ce service est idéal pour diffuser des informations au
sein des organisations, car il facilite l’accès aux données en temps réel et amé-
liore la prise de décision collective.[34]

51
Chapitre 3. Release 2 : ANALYSE ET VISUALISATION DE DONNÉES

3.3 Sprint 1 : Phase de restitution des données

Dans cette section, et après avoir chargé les données, nous élaborerons l’étape la plus
importante dans l’informatique décisionnelle qui est la restitution des données : la création
des tableaux de bord et leur publication. Nous allons utiliser comme logiciels dans ce
sprint : Power Bi RS Desktop et Power Bi Report Server.

3.3.1 Connexion avec SQL Server Database

Tout d’abord, on commence par assurer la connexion du Power BI avec la base de
données dans SSMS. La figure 3.1 illustre cette phase.

Figure 3.1 – Connexion du Power Bi avec la base de données dans SSMS

3.3.2 Création des mesures avec DAX

Nous abordons une phase importante dans le projet : création des mesures en utili-
sant le langage "DAX" dans Power BI. L’objectif est de transformer les données brutes en
métriques exploitables pour l’analyse.
Nous présentons dans cette partie nos métriques clés calculées à l’aide de DAX des diffé-
rents domaines fonctionnels.

Les indicateurs clés de performance de Revenue

Figure 3.2 – Création de l’indicateur clé ARPU en DAX

52
Chapitre 3. Release 2 : ANALYSE ET VISUALISATION DE DONNÉES

Figure 3.3 – Création de l’indicateur clé CA en DAX

Figure 3.4 – Création de l’indicateur clé Revenue par transaction en DAX

Les indicateurs clés de performance de Marketing

Figure 3.5 – Création de l’indicateur clé ROI en DAX

Figure 3.6 – Création de l’indicateur clé CPA en DAX

Figure 3.7 – Création de l’indicateur clé CAC en DAX

Les indicateurs clés de performance d’Activité des abonnés

Figure 3.8 – Création de l’indicateur clé Churn Rate en DAX

Figure 3.9 – Création de l’indicateur clé Growth Rate en DAX

53
Chapitre 3. Release 2 : ANALYSE ET VISUALISATION DE DONNÉES

Figure 3.10 – Création de l’indicateur clé Success Rate en DAX

3.3.3 Présentation de la page d’accueil

Tout d’abord, voici l’écran d’accueil dans la figure 3.11 de notre solution décisionnelle,
nous avons rassemblé les indicateurs clés de performance (KPI) pour présenter une vue
d’ensemble complète.
Ainsi, nous citons les clés de performance : CA , Revenue Net, Le total du coût Marketing,
ARPU, CPA, Growth Rate, Revenue per transaction et le ROI.
Les filtres interactifs ou aussi "Slicers" qui sont disponibles sur notre page d’accueil per-
mettent aux utilisateurs d’affiner l’analyse en fonction des dimensions existants tel que :
la date, du produit, de l’opérateur, et du pays. Ainsi, les décideurs peuvent avoir des
résultats en fonction des besoins spécifiques.
Nous observons aussi, un graphique en camembert "pie chart" qui illustre une répartition
de Chiffre d’affaire par produit, et un graphique en anneau ou "donut chart" qui présente le
nombre de nouveaux abonnés par produit. Ces graphes permettent d’explorer l’ensemble
de données d’une manière rapide.

Figure 3.11 – Page d’accueil

54
Chapitre 3. Release 2 : ANALYSE ET VISUALISATION DE DONNÉES

3.3.4 Tableau de bord "Analyse des Revenus"

En cliquant sur Le KPI "CA" ou "Net Revenue" dans la page d’accueil, on accède
directement au tableau de bord "Revenue" dans la figure 3.12 qui offre une analyse sur les
performances financières de l’entreprise en présentant deux bilans.

- Le premier bilan : est conçu selon une hiérarchie composée de nos dimensions
telles que country, product, et operator, et affiche les colonnes suivantes : Sum of revenue
USD, Sum of unique transactions et le Revenue LCL. Cette hiérarchie donne une vue
granulaire des revenus par pays, opérateur et produit.
- Le deuxième bilan : présente le Gross Margin Revenue, en utilisant les mêmes di-
mensions précédentes pour offrir une analyse bénéfice brut dans les 2 années 2023 et 2024.
- Un graphique en aire : illustre offrant une vue temporelle des tendances mensuelles
des revenus et des marges brutes (USD).

Figure 3.12 – Tableau de bord Analyse des Revenus

55
Chapitre 3. Release 2 : ANALYSE ET VISUALISATION DE DONNÉES

3.3.5 Tableau de bord "Analyse des Revenus en Dollars"

Après avoir conçu le tableau de bord "Revenue" qui présente les bilans, on fournit un
autre tableau de bord dans la figure 3.13 qui présente une analyse détaillée les chiffres
d’affaires et les marges brutes (GMRevenue) par produit/pays/date.

- Histogramme empilé : "CA by Product" : ce graphique fournit une répartition des

chiffres d’affaires Grâce à cette visualisation, les décideurs peuvent rapidement capturer
les produits qui génèrent les plus hauts revenus.
- Graphique en colonnes empilées : On présente le "GM Revenue by Product" : ce
visuel illustre la marge brute par produit sous la forme de colonnes empilées. Cela permet
d’analyser le total des marges pour chaque produit tout en visualisant la contribution de
chaque composant à la marge brute totale, facilitant ainsi l’évaluation des performances
de chaque produit.
- Arbre de décomposition : On présente " CA by product and country decompo-
sition" : ce visuel offre une vue hiérarchique des revenus générés, décomposée par pays et
par produit. Chaque niveau de l’arbre permet d’explorer comment les revenus se répar-
tissent à travers différentes régions et catégories de produits. Cela facilite l’identification
des marchés les plus rentables et des produits qui contribuent le plus au chiffre d’affaires
global.
- Graphique en donut : "Success Unique Transaction by Product" : ce graphique
illustre lune répartition des Success Unique Transaction par produits pour savoir lesquelles
la plus réussie .

Figure 3.13 – Tableau de Bord Analyse des Revenus en Dollars

56
Chapitre 3. Release 2 : ANALYSE ET VISUALISATION DE DONNÉES

3.3.6 Tableau de bord "Analyse Financière des Coûts Marke-

ting"
Le tableau de bord "Analyse Financière des Coûts Marketing" illustré dans la figure
3.14 offre une vue complète et détaillée des coûts de marketing. En premier lieu, il présente
un bilan qui détaille le "CPA per Day" et le "Sum of Marketing Cost" à travers une
hiérarchie de pays, opérateurs et produits. Ces informations permettent d’analyser la
performance des dépenses marketing de manière granulaire.
- Premier graphique combiné : montre la somme des coûts marketing par rapport
aux souscriptions totales, facilitant ainsi la visualisation de la relation entre les investis-
sements marketing et les résultats en termes d’abonnements.
- Deuxième graphique combiné : présente la somme des nouvelles souscriptions en
parallèle avec le ROI, fournissant une perspective complète sur la rentabilité des actions
marketing.
- Graphique en secteurs : permet de visualiser rapidement la proportion des inves-
tissements alloués à chaque produit. Ce type de graphique facilite l’identification des
produits qui absorbent la majorité des coûts marketing, mettant en lumière les priorités
stratégiques de l’entreprise.

Figure 3.14 – Tableau de bord Analyse Financière des Coûts Marketing

57
Chapitre 3. Release 2 : ANALYSE ET VISUALISATION DE DONNÉES

3.3.7 Tableau de bord "Analyse de l’Activité des Abonnés"

Le tableau de bord "Analyse de l’Activité des Abonnés" illustré dans la figure 3.15
fournit une visualisation complète de l’activité des abonnés à travers plusieurs KPI et
visuels. En premier lieu, voici un bilan qui inclut : le nombre total de nouveaux abonnés,
le nombre total d’abonnés et le nombre de nouveaux désabonnements. Les indicateurs
mentionnés précédemment permettent de suivre les tendances d’acquisition et de résilia-
tion des abonnés.

- Un graphique en secteurs :présente la répartition totale des abonnés par pro-

duit. Il permet d’identifier les produits les plus populaires d’une manière rapide.
- Graphique à colonnes empilées : Montre la distribution des nouveaux abonnés et
des résiliations le jour même (same day churn) par produit. Ce graphique met en lumière
les produits qui attirent de nouveaux abonnés ainsi que ceux qui présentent des taux de
résiliation précoces.
- Graphique en courbes : Illustre l’évolution des nouvelles résiliations (New Churn),
des nouveaux abonnés et du nombre total d’abonnés au cours du temps. En ajoutant un
filtre (slicer) pour sélectionner un produit spécifique, l’utilisateur peut analyser de manière
détaillée l’activité et les tendances de chaque produit individuellement. Cette visualisa-
tion permet de suivre les changements dans les abonnements et d’évaluer les tendances
de fidélisation pour chaque service.
- Taux de croissance par mois (Growth Rate by Month) : Affiche l’évolution
du taux de croissance mensuel des abonnés, permettant de détecter les périodes de forte
croissance. Ce graphique est essentiel pour anticiper les fluctuations de l’activité des abon-
nés et pour adapter les stratégies de marketing et de rétention en fonction des périodes
de variation.

Figure 3.15 – Tableau de bord Analyse de l’Activité des Abonnés

58
Chapitre 3. Release 2 : ANALYSE ET VISUALISATION DE DONNÉES

3.3.8 Publication sur Power Bi Report Server

L’objectif de cette section, c’est d’assurer que les tableaux de bord s’affichent dans
l’environnement collaboratif "Power Bi Report Server" et offrent aux utilisateurs des in-
formations précises. En publiant les rapports, nous garantissons une distribution efficace
et continue des informations aux parties prenantes, ce qui facilite une prise de décision
bien informée au sein de l’entreprise.
Pour publier notre solution décisionnelle dans Power Bi Report Server, on enregistre notre
projet dans Power BI Desktop en cliquant sur "Save As" et on choisit "Power Bi Report
Server" comme la montre la figure 3.16 :

Figure 3.16 – Première étape de publication de notre solution sur Power Bi Report
Server

Ensuite, on configure l’accès au Power Bi report server en choisissant notre serveur avec
le lien comme le montre ci-dessous dans la figure 3.17 :

Figure 3.17 – Deuxième étape de publication de notre solution sur Power Bi Report
Server

59
Chapitre 3. Release 2 : ANALYSE ET VISUALISATION DE DONNÉES

Ensuite, comme l’illustre la figure 3.18 , l’opération de publication du dashboard est

réussite.

Figure 3.18 – Troisième étape de publication de notre solution sur Power Bi Report
Server

Enfin, on accède à notre serveur sur le navigateur, et on obtient notre dashboard décision-
nelle qui sera partagée avec les adresses des parties prenantes comme le montre la figure
3.19 .

Figure 3.19 – Dernière étape de publication de notre solution sur Power Bi Report
Server

3.4 Sprint 2 : Construction du cube OLAP multidi-

mensionnel
3.4.1 Étapes de construction du cube OLAP
Dans cette section, nous abordons les étapes utiles à la création du cube OLAP, sa
configuration et son déploiement pour préparer à une analyse multidimensionnelle.

60
Chapitre 3. Release 2 : ANALYSE ET VISUALISATION DE DONNÉES

Au cours de cette phase, nous allons créer le cube en utilisant SQL Server Analysis
Services (SSAS), comme présentés dans la figure 3.20 :

Figure 3.20 – Création du nouveau projet multidimensionnel

Ensuite, on assure la connexion de base de données avec SSMS dans la figure 3.21 :

Figure 3.21 – Test de connexion avec la base de données

61
Chapitre 3. Release 2 : ANALYSE ET VISUALISATION DE DONNÉES

Ensuite, nous procédons à la configuration du cube OLAP et à son déploiement afin

d’obtenir une vue globale. La figure 3.22 ci-dessous illustre les étapes, telles que le choix
de la table de faits, des mesures et des dimensions.

Figure 3.22 – Étapes de configuration du cube

Enfin, on clique sur "Process" et on effectue le déploiement du cube pour le préparer

à l’analyse multidimensionnelle comme ci-dessous présentée dans la figure 3.23 :

Figure 3.23 – Test du déploiement du cube réussit

62
Chapitre 3. Release 2 : ANALYSE ET VISUALISATION DE DONNÉES

3.4.2 Optimisation des analyses avec le Cube OLAP

La construction du cube OLAP représente une avancée significative dans notre ap-
proche d’analyse des données. Il offre une exploration interactive et flexible des données
à travers plusieurs dimensions, permet des analyses complexes et ad hoc, et offre des
fonctionnalités avancées comme le drill-down, le roll-up, et les comparaisons multidimen-
sionnelles. Les KPI, en revanche, sont des indicateurs simples et statiques qui fournissent
une vue instantanée d’une performance ou d’un objectif spécifique sans permettre une
analyse détaillée ou une exploration flexible des données sous-jacentes. Les deux outils se
complètent souvent dans les systèmes de business intelligence (BI) : les KPI fournissent
des mesures rapides, tandis que l’OLAP permet une analyse détaillée.

3.4.3 Cas d’illustration : Exploration des données de finance

Nous avons déployé ce cube OLAP de base pour des analyses multidimensionnelles,
structuré autour de quatre dimensions clés : currency (devise), operator (opérateur), pro-
duct (produit) et country (pays). Aussi, la table de faits Revenue associée contient les
mesures essentielles. Cependant, pour tirer pleinement parti de ce cube, il est crucial
d’enrichir notre modèle en ajoutant d’autres dimensions et en augmentant la quantité de
données.
L’intégration d’une dimension Type de dépense permettrait d’analyser les coûts liés à
différentes catégories, comme le coût marketing, Coût technologique, Coût de recherche
et développement. Grâce aux capacités de drill-down offertes par l’OLAP, nous pourrions
examiner ces dépenses en profondeur, passant d’une vue d’ensemble des coûts à une ana-
lyse détaillée par catégorie. De plus, en introduisant une dimension périodes budgétaire et
avec OLAP, il est possible de naviguer facilement dans des dimensions temporelles avan-
cées, comme des périodes budgétaires personnalisées ou des comparaisons de plusieurs
niveaux (année, trimestre, mois, jour) en un seul clic, ce qui facilite des analyses plus
approfondies sur des tendances saisonnières.

Conclusion
Au cours de ce chapitre, nous avons présenté notre deuxième release. Nous avons mis
en lumière la création de rapports interactifs et dynamiques, et nous avons conclu par
leur publication dans le Power BI Report Server. Enfin, nous avons examiné les étapes de
construction du cube OLAP, ainsi que la sélection des mesures et des dimensions pour le
préparer à une analyse multidimensionnelle des données de l’entreprise.

63
 CONCLUSION GÉNÉRALE ET PERSPECTIVES

Ce projet de fin d’études a été réalisé au sein de Mobizone Tunisia dont l’objectif
est de présenter une solution décisionnelle automatisée qui permet de suivre les perfor-
mances de l’entreprise : La finance, l’activité des abonnées, le marketing et qui a pour but
d’optimiser ses activités. C’était une expérience riche et bénéfique et qui nous a permis
d’approfondir nos connaissances et nos compétences ainsi que le savoir-faire technique et
interpersonnel qui sont acquis le long de toutes les années de notre formation académique.

Au terme de ce projet, nous avons mis en place un système décisionnel complet qui
était déployé sur le système de l’entreprise Mobizone comme une première version. Cette
solution permet de centraliser, traiter et analyser les données issues de ses produits web en
partenariat avec les opérateurs téléphoniques. Ce système repose sur des processus auto-
matisés d’extraction et de transformation des données, ainsi que sur la construction d’un
Datamart, d’un cube OLAP et de tableaux de bord interactifs. Ces derniers permettent
de suivre les performances financières, l’activité des abonnés, en utilisant les indicateurs
clés de performance essentiels à la prise de décision stratégique.

Bien que notre solution décisionnelle actuelle réponde aux besoins de l’entreprise, il
est essentiel d’apporter des améliorations. Nous avons déployé un cube OLAP de base
pour des analyses multidimensionnelles, mais nous devons l’exploiter en ajoutant d’autres
dimensions et augmentant la quantité des données pour pouvoir effectuer des analyses
complexes. Par exemple, dans le domaine de la finance, nous pourrions intégrer des di-
mensions comme les types de dépenses et les périodes budgétaires. Cela nous permettrait
d’effectuer des analyses approfondies, comme la comparaison des dépenses sur plusieurs
années ou l’évaluation de la rentabilité des produits web en production. Parallèlement,
l’ajout d’un système d’archivage de données dans SSIS lors du traitement de l’ETL est
une étape importante pour optimiser la gestion des données. Ce système permettra d’ar-
chiver automatiquement toutes les sources de données, garantissant ainsi une conservation
efficace des informations historiques. En configurant SSIS pour déplacer les données vers
ce système d’archivage, nous libérerons de l’espace dans nos bases de données actives, ce
qui améliorera les performances des requêtes.

64
 BIBLIOGHRAPHIE

[1] https ://[Link]/about. Présentation du groupe A15 (date de consultation :

25/03/2024).
[2] https ://[Link]/portfolio. A15 filiales (date de consultation : 19/09/2024).
[3] https ://[Link]/. ArpuPlus et les domaines d’activités (date de consul-
tation : 25/03/2024).
[4] https ://[Link]/pedagogie-projet/methode-scrum. SCRUM Agile (date de
consultation : 06/08/2024).
[5] https ://[Link]/systeme-information-decisionnel/. Etapes de
chaine décisionnelle (date de consultation : 02/10/2024).
[6] https ://[Link]/intellyticssolutions/what-why-how-data-warehouse-and-etl-
9ebd198d36c7. figure zone de stockages (date de consultation : 19/09/2024).
[7] https ://[Link]/olap-operations. Drill-dow et Rol (date de consl-
upultation : 20/10/2024).
[8] https ://[Link]/fr/resources/key-performance-indicator-kpi. Les schémas dimen-
sionnels (date de consultation : 17/09/2024).
[9] https ://[Link]/dumas-01212068/document. Définition littéraire de
Agile (date de consultation : 12/04/2024).
[10] https ://[Link]/intl/fr-fr/blog/collaboration/methode-agile. Définition de Agile
(date de consultation : 12/04/2024).
[11] https ://[Link]/fr/blog/quest-ce-que-linformatique-decisionnelle. Défi-
nition de l’infomatique décisionnelle (date de consultation : 16/08/2024).
[12] https ://[Link]/fr/blog/quest-ce-que-linformatique-decisionnelle. Hiso-
trique de l’infomatique décisionnelle (date de consultation : 16/08/2024).
[13] https ://[Link]/business-intelligence-definition : :text=La Composants de
chaine décisionelle (date de consultation : 19/08/2024).
[14] http ://[Link]/stg-et-ods/ : :text= STG (date de consultation :
19/08/2024).
[15] http ://[Link]/stg-et-ods/ : :text= ODS (date de consultation :
19/08/2024).
[16] https ://[Link]/in/autonomous-database/what-is-data-mart/. Datamart
(date de consultation : 22/08/2024).

65
[17] https ://[Link]/methode-de-kimball-tout-savoir. Approches et tables
(date de consultation : 22/08/2024).
[18] https ://[Link]/fr/resources/key-performance-indicator-kpi. CPI (date de
consultation : 17/09/2024).
[19] https ://[Link]/fr-fr/topics/olap. Cube OLAP (date de consultation :
23/08/2024).
[20] https ://[Link]/fr/topics/api/what-are-application-programming-
interfaces. API (date de consultation : 10/09/2024).
[21] https ://[Link]/web-tech/dictionnaire-du-webmastering/1445308-
json-definition-et-presentation-de-ce-format-de-donnees/. JSON (date de consulta-
tion : 10/09/2024).
[22] https ://[Link]/fr-fr/office/cr CSV (date de consultation :
10/09/2024).
[23] https ://[Link]/formation-analyse-donnee/pandas-bibliotheques-
python : :text=Un Pandas (date de consultation : 10/09/2024).
[24] https ://[Link]/formation-analyse-donnee/pandas-bibliotheques-
python : :text=Un DataFrame Pandas (date de consultation : 10/09/2024).
[25] https ://[Link]/requests. Requests (date de consultation : 10/09/2024).
[26] https ://[Link]/definition-visual-studio-code/. Visual studio code (date de consul-
tation : 26/08/2024).
[27] https ://[Link]/fr/what-is/python/ : :text=Python Python (date de
consultation : 26/08/2024).
[28] https ://[Link]/fr/. Visual studio (date de consultation :
26/08/2024).
[29] https ://[Link]/fr-fr/sql/integration-services/sql-server-integration-
services ?view=sql-server-ver16. SSIS (date de consultation : 26/08/2024).
[30] https ://[Link]/jargon/t/[Link]. Task scheduler (date de
consultation : 29/08/2024).
[31] https ://[Link]/fr-fr/sql/ssms/agent/sql-server-agent ?view=sql-
server-ver16. SQL Server Agent (date de consultation : 29/08/2024).
[32] https ://[Link]/resources/it-glossary/ssas. SSAS (date de consulta-
tion : 29/08/2024).
[33] https ://[Link]/power-bi-desktop/. Power Bi RS Desktop (date de consul-
tation : 29/08/2024).
[34] https ://[Link]/power-bi-desktop/. Power Bi Report Server (date de consul-
tation : 29/08/2024).