Université de Jendouba

Faculté des Sciences Juridiques, Economiques et de Gestion de Jendouba

(FSJEGJ)

Projet de Fin D’Etudes

Informatique Appliquée A la Gestion

Spécialité : Business Intelligence
Présentée par :
Jouini Wiem

Mise en place d’un outil d’aide a la décicsion et d’analyse

prédictive Sous la supervision de :
Encadrante : Dr. Ghazouani Wided

Membres du Jury :
Dr Soudani Nedia
Dr Hannachi Refka

2021 - 2022
REMERCIEMENTS
 C’est avec un grand plaisir que je réserve cette page en signe de gratitude et de profonde
connaissance à tous ceux qui m’ont aidée à la réalisation de ce travail.

Je remercie tout d’abord l’ensemble de l’équipe pédagogique de FSJEGJ pour ces trois
années de formation durant lesquelles j’ai énormément appris et vécu d’excellents moments.

J’adresse tout particulièrement ma gratitude à Madame GHAZOUANI Wided, mon

encadrante à FSJEG Jendouba pour sa disponibilité, ses directives et ses conseils si
enrichissants.

Je remercie notamment Monsieur TISSAOUI Atef, pour m’avoir accueillie au sein de son
équipe et de m’avoir fait confiance, afin de me permettre de vivre une expérience riche et
passionnante.

Je remercie aussi toutes les personnes qui de près ou de loin m’ont suivie et aidée afin de
concrétiser ce projet dans les meilleures conditions et les meilleurs délais.

Je dis merci à tous

Jouini Wiem
2
TABLE DES MATIÈRES

1 Contexte général du projet 8 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 1.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1 Présentation du Centre Laitière du Nord . . . . . . . . . . . . . . . . . . . . 8 1.2.2
Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2.3
Activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.4
Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.5 Solution
 proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.6 Méthodologie
adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6.1 Méthodologie de Ralph Kimball . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.6.2 Méthodologie
de Gimsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.6.3 Choix de la méthodologie . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 13 1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14

2 L’informatique Décisionnelle 15 2.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Business
Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3 Les objectifs de BI . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4 L’architecture du BI . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 16
2.4.1 L’entrepôt de données (DataWarehouse) . . . . . . . . . . . . . . . . . . . . 16 2.4.2 Le
magasin de données (DataMart) . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.3 Extraction des
données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Modélisation DataMart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.5.1 Comparaison
des modèles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.6 La consolidation financière, le
’reporting’ et le tableau de bord . . . . . . . . . . . . 19 2.7 Le système d’information décisionnel en
entreprise . . . . . . . . . . . . . . . . . . . 19 2.8 L’évolution des systèmes
décisionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.9 Comparaison entre les systèmes
transactionnels et les systèmes décisionnels . . . . . 20 2.10
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1
3 Planification et Spécification des besoins 22 3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2 Planification . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3 Spécification des
besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3.1 Identification des
acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4 Identification des besoins . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 24 3.4.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24 3.4.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.4.3 Diagramme
de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . 25 3.5 Architecture globale . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . 25 3.6 Choix des indicateurs et collecte des informations . . . . . .
. . . . . . . . . . . . . 26 3.7 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27 3.7.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.7.2 Environnement
logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.7.2.1 SQL SERVER . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 28 3.7.2.2 Jupyter NoteBook . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.7.2.3
Superset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.7.2.4 Docker . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 29 3.8 Approche de conception du modèle dimensionnel . . . . . . . . . . . . . . . .
. . . . 30 3.8.1 Approche de Bill Inmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.8.2 Approche
de Ralph Kimball . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.8.3 Choix de l’approche . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 31 3.9
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Conception de l’entrepôt de donnée 33 4.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2 Conception du modèle
dimensionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.1 Modèle en étoile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.2 Modèle en
flocon de neige . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2.3 Modèle en constellation . . . .
 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2.4 Choix du modèle dimensionnel . . . . . . . . . . . . .
. . . . . . . . . . . . . 34
4.3 Identification des faits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.3.1 Table de fait
Vente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.4 Identification des dimensions . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 36 4.4.1 Les axes d’analyse du fait Vente . . . . . . . . . . . . . . . . . . . . .
. . . . 36 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Mise en place de l’application 38 5.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2 Préparation de
l’infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.1 Installation Docker Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2.2 L’image
Superset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.2.2.1 Téléchargement de l’image
Superset . . . . . . . . . . . . . . . . . 39
5.2.2.2 Modification de l’image Superset . . . . . . . . . . . . . . . . . . . 40 5.2.3 L’image SQL Server
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2.3.1 Téléchargement de
l’image . . . . . . . . . . . . . . . . . . . . . . . 41 5.2.4 Création du fichier Docker-
Compose . . . . . . . . . . . . . . . . . . . . . . 42 5.2.5 Connexion entre les
services . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2.5.1 Connexion entre SQL Management
Studio et Microsoft SQL Server 42 5.2.5.2 Connexion entre Superset et SQL
Server . . . . . . . . . . . . . . . 43 5.3 Développement de la phase
ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 47

6 Restitution des données 48 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48 6.2 Développement de l’application utilisateur . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.1 Interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.2.2 Suivi des
transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.2.3 Suivi des
clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3 Analyse Prédictive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.3.1 Apprentissage
supervisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.3.2 Apprentissage non
supervisé . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.3.3
Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3.3.1 Analyse du comportement du client . . . . . . . . . . . . . . . . . . 53 6.3.3.2 Prédiction de
l’état financière de l’entreprise . . . . . . . . . . . . . 53 6.4 Méthodes et résultats . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 53 6.4.1 Analyse du comportement du client . . . . . . . . . . . . . . . . . . . .
. . 53 6.4.1.1 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.4.1.2
Résultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.4.2 Prédiction de l’état financière de
l’entreprise . . . . . . . . . . . . . . . . . . 55 6.4.2.1 Entrainement et test . . . . . . . . . . . . . . . . . . . . . . .
. . . 55 6.4.2.2 Résultats et choix du modèle . . . . . . . . . . . . . . . . . . . . . 58 6.4.2.3 Déploiement
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.5
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7 Conclusion Générale 61
TABLE DES FIGURES
 1.1 Logo CLN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2 Cycle de vie
dimensionnel de Ralph Kimball . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Architecture globale du BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2 Diagramme de

cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3 Architecture globale du
projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.4 Spécification de la
machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5 SQL
SERVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.6 Logo Jupyter . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.7 Logo Superset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 29 3.8 Logo Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.9 La
représentation schématique de l’approche de Bill Inmon . . . . . . . . . . . . . . 30 3.10 La
représentation schématique de l’approche de Ralph Kimball . . . . . . . . . . . . 31

4.1 Modèle en étoile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2 Modèle en flocon

de neige . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.3 Modèle en constellation . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . 34 4.4 Modèle physique de magasin de données . . . . . . . . . . . . .
. . . . . . . . . . . 36

5.1 Interface Docker Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.2 Téléchargement

de l’image superset sur Docker . . . . . . . . . . . . . . . . . . . . . 40 5.3 Création d’une nouvelle
image Superset . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.4 Affichage de conteneur en cours
d’exécution . . . . . . . . . . . . . . . . . . . . . . 42 5.5 Connection à SQL
Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.6 Création de la base de données
ventes . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.7 choisir la base de données dans Superset . . . .
. . . . . . . . . . . . . . . . . . . . 44 5.8 Copier la chaîne de connexion pour SQL Server . . . . . . . . . . .
. . . . . . . . . 44 5.9 Connexion à Superset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.10
Implémentation des fichiers CSV dans la base de données . . . . . . . . . . . . . . 46 5.11
Remplissage du formulaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4
5.12 Alimentation de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.1 Page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.2 Suivi des

transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.3 Suivi des
clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.4 Résultat des règles
s’association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.5 Résultat des modèles Régression
Linéaire, SGDRregressor, Lasso et ElasticNet . . . 58 6.6 Résultat du modèle
ARIMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.7 Interface de
prédiction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
LISTE DES TABLEAUX

1.1 Cycle de vie de la méthodologie Ralph Kimball . . . . . . . . . . . . . . . . . . . . 12 1.2 Cycle de vie de la

méthodologie Gimsi . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1 Comparaison entre le schéma en étoile et le schéma en flacon de neige. . . . . . . . . 18 2.2
Comparaison entre le schéma en étoile et le schéma en constellation . . . . . . . . . 19 2.3 Comparaison
entre les systèmes transactionnels et les systèmes décisionnels . . . . . 20
3.1 Tableau comparatif des approches Kimball et Inmon . . . . . . . . . . . . . . . . . 31

4.1 Présentation des colonnes du fait Vente . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.2 Présentation des

dimensions relatives au fait Vente . . . . . . . . . . . . . . . . . . 37

6.1 Comparaison des modéles linear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6

INTRODUCTION GÉNÉRALE

Chaque jour de nouvelles données sont produites dans l’entreprise qui à son tour cherche tou jours à
prendre les meilleures décisions, tant pour accroitre leur productivité, que pour répondre aux besoins des
clients. Et pour atteindre ses objectifs, elle a besoin d’analyser les données qui la proviennent des
marchés.Grâce à cette analyse, elle pourra mener des actions intelligentes. C’est là que la business
intelligence prend tout son sens. Afin de maintenir l’avantage compétitif, mieux cibler sa clientèle,
examiner les grandes tendances du marché et faciliter la prise de décisions, le Central Laitière du Nord
vise à exploiter ses données grâce à des outils performants.
C’est dans ce contexte que s’inscrit mon projet de fin d’études réalisé au sein de la direction du système
d’information au Central Laitière du Nord, qui aura pour but la mise en place d’un système d’aide à la
décision et d’analyse prédictive dédié principalement au suivi les évolutions de ventes et les activités des
clients et des commandes. Cela permettra aux décideurs d’avoir une vue globale et synthétique sur
l’ensemble des données en assurant leur centralisation et historisation.
Ce présent rapport s’articule autour de six chapitres. Le premier chapitre consiste en une pré sentation du
cadre général du projet incluant une présentation de l’entreprise d’accueil, le contexte du projet dans un
premier lieu. Nous définissons la méthodologie adoptée pour mettre en place notre solution dans un
deuxième lieu. Le deuxième chapitre consiste à définir toutes les notions sur lesquels ce projet est basé
tel que la définition du Business Intelligence, ses objectifs et l’ar chitecture associé et d’autres. Le
troisième chapitre définit la planification des tâches, les acteurs, les besoins fonctionnels et non
fonctionnels et étale aussi une étude technique de la solution pro posée tout en spécifiant l’architecture
suivie et l’environnement technique. Le quatrième chapitre sera consacré pour l’identification du modèle
dimensionnel et la conception du modèle physique de magasin de données. Le cinquième chapitre
détaillera toutes les étapes de la mise en place et le développement de l’application de la préparation de
l’infrastructure jusqu’au la phase ETL. Le sixième chapitre englobe l’étape de restitution de d’analyse de
données qui représente les différents tableaux de bord et le déploiement de notre solution.
Enfin, une conclusion synthétisera notre travail et présentera les perspectives futures. 7

CHAPITRE 1

CONTEXTE GÉNÉRAL DU PROJET

1.1 Introduction
Dans ce chapitre, nous allons présenter l’organisme d’accueil : Centre Laitière du Nord
«CLN», l’établissement au sein duquel s’est déroulé notre projet de fin d’études ainsi son
historique et ses différentes activités. Ensuite, nous procéderons à la présentation du cadre du
projet qui nous permettre de mieux comprendre le problème étudié et en déduire des solutions.
Enfin, nous allons présenter la méthodologie du travail adoptée.

1.2 Présentation du projet

1.2.1 Présentation du Centre Laitière du Nord
 Figure 1.1 – Logo CLN

La société Centrale Laitière Du Nord « CLN »[7]est une société anonyme spécialisée dans la
production des produits laitiers et ses dérivés. C’est l’une parmi les dix sociétés de Groupe

8
DELICE, le leader du secteur de l’industrie agroalimentaire sur le marché tunisien. Elle a toujours
fait de la qualité de ses produits une priorité absolue et a su construire un fort capital confiance
avec ses consommateurs, alors elle est classée la deuxième, au prix national de la qualité en
2020.

1.2.2 Historique
En Mai 1986, le Centrale Laitière du Nord a été créer, il a poursuivi son développement par la
création des produits laitiers sous la marque locale LAINO. En 2005, saisissant de l’opportunité
d’agrandir sa part de marché dans le secteur du lait longue conservation, le Groupe Délice a
investi 9,5 millions de dinars pour l’acquisition de la Centrale Laitière du Nord « CLN » profitant
ainsi d’une capacité de production supplémentaire et d’une présence consolidée dans le bassin
laitier du nord-ouest du pays.

1.2.3 Activités
La société Centrale Laitière Du Nord « CLN » est spécialisée dans la transformation du lait, la
production et la commercialisation des produits laitiers et ses dérivés (Yaourt, Beurre, Fromage
Frais, Crème Dessert...), ainsi tous produits agroalimentaires.

1.3 Contexte du projet

Dans le cadre de la préparation du projet de fin d’étude en vue de l’obtention du diplôme de
licence d’Informatique appliqué à la gestion, spécialité Business Intelligence. J’ai choisi
d’effectuer un stage d’une durée de 4 mois au sein du Centrale Laitière Du Nord (CLN). Le stage
a débuté la première semaine de Février et s’est achevé fin du Mai. L’objectif principale est la
mise en place d’un outil d’aide à la décision et d’analyse prédictive.

1.4 Problématique
 D’une année à une autre, la demande sur les produits Délice augmente et les besoins des
clients se changent. Face à cette surcharge de travail, le groupe Délice a remarqué
l’augmentation de la masse des données et la vitesse de leur évolution, ce qui rend la gestion, le
contrôle et la prise de décision dans l’entreprise plus difficile. Cette situation a amené le groupe à
revisiter et améliorer leur processus de prise de décision et de reporting financier afin de pouvoir
prendre les bonnes décisions au bon moment. Dans le cadre de renforcer le système de prise de
décision, les propriétaires de Délice espèrent se tourner vers l’avenir et trouver les meilleures
façons d’investir du capital et des ressources tout en travaillant au succès à long terme de leur
entreprise. Il faut donc un moyen permettant de recueillir facilement les données, les analyser, les
visualiser et prédire le comportement futur en fonction des comportements passés.

9
1.5 Solution proposée
La solution envisagée, est un système d’aide la décision et d’analyse prédictive permettant de
mettre à la disposition des décideurs les moyens nécessaires pour qu’ils puissent prendre les
décisions stratégiques et opérationnelles les plus adéquates. En effet, ce système pourrait aider à
anticiper les besoins des clients, permet aussi la flexibilité de réagir face à des changements
majeurs sur le marché, à prévoir les tendances plus larges du marché ou à gérer les risques, ce
qui offre un avantage concurrentiel et, en fin de compte, augmente les revenus. Notre système va
assurer la possibilité de :
— Maximiser la productivité
— Réagir rapidement à l’évolution de marché et aux attentes des clients.
— Accélérer la commercialisation de nouveaux produits.
— Identifier les produits les plus rentables.
— Maîtriser la chaine d’approvisionnement.
— Améliorer la planification et la programmation.
— Prédire la quantité de vente
— Optimiser les flux d’information.

1.6 Méthodologie adoptée

Dans le domaine Business Intelligence, un projet BI n’est pas un projet informatique tradition
nel, il est particulièrement délicat puisqu’il concerne l’épineuse question de la prise de décision
dans l’entreprise. Alors il nécessite impérativement une parfaite définition des rôles et
responsabilités. De ce fait, nous avons effectué une recherche qui nous aidera à faire notre choix
entre les deux méthodologies de Ralph Kimball et Gimsi expliquées ci-dessous.

1.6.1 Méthodologie de Ralph Kimball

La méthodologie Kimball [4] a été conçue au milieu des années 1980 par des membres du
Groupe Kimball. Cette méthodologie a été utilisée avec succès pour la réalisation des projets
d’entrepôt de données et de business intelligence dans pratiquement tous les domaines et les
secteurs d’activité. La figure suivante décrit le cycle de vie d’un projet BI, son avancement ainsi
que le séquencement des différentes tâches.

10

Figure 1.2 – Cycle de vie dimensionnel de Ralph Kimball

Dans ce qui suit, nous allons détailler les différentes étapes pour une meilleure
compréhension du cycle de vie dimensionnel .
 11
Étape Objectif

Planification du Pro — Définir l’étendue du projet ainsi que sa planification qui dépend des
jet besoins comme l’indique la flèche en double sens de la figure ci-
dessus (figure 1.2).
— Étudier les ressources et l’affectation des tâches.

Définition des Cette phase permet d’identifier les utilisateurs de l’application et leurs
Besoins BI besoins. Une fois les besoins définis , trois trajectoires parallèles
seront lancés qui sont la technologie, les données et les interfaces
utilisateur.

Gestion du projet — Garantir que les activités du cycle de vie restent sur la bonne voie
et sont bien synchronisées.
— Détecter et résoudre les problèmes.

Définition de l’archi — Définir la vue globale de l’architecture technique à mettre en

tecture technique œuvre. — Étudier les outils de conception de la zone de préparation
des données et de restitution des résultats.

Sélection et Installa En se basant sur l’architecture technique, et en répondant aux

tion des produits besoins de notre projet, nous avons choisi de définir l’outil sur lequel
se base notre projet.

Modélisation Dimen — Définir les données requises pour répondre aux besoin des
sionnelle utilisateurs. — Construire la matrice qui représente les processus
métier clés et leurs dimensionnalités.
— Réaliser le modèle dimensionnel (La granularité de la table de faits
ainsi que les dimensions associées).

Conception du La conception physique comporte la définition du modèle élaboré de

modèle physique l’en trepôt de données(DW).

Conception et déve — Concevoir l’ODS ou la Staging Area (SA).

loppement de la — Effectuer le processus ETL
zone de préparation
des données

Spécification de Cette phase englobe la préparation des maquettes à réaliser dans la

l’ap plication phase qui suit.
utilisateur

Développement de Après la réalisation des différentes phases précédentes, cette phase

l’application BI nous permettra la réalisation des différents tableaux de bord
nécessaires pour répondre aux besoins client.

Déploiement — Converger la technologie, les données, et les applications

décisionnelles aux utilisateurs accessibles.
— Assurer une formation, pour les utilisateurs, des processus de
commu nication et un support utilisateur.
 Maintenance et Après la mise en place de la solution, l’entrepôt va donc évoluer et
crois sance croître et le changement doit être perçu comme un facteur de succès
et non d’échec. Il faut donc assurer le fonctionnement optimal du
système et prévoir l’ajout de nouvelles fonctionnalités

Table 1.1 – Cycle de vie de la méthodologie Ralph Kimball

12
1.6.2 Méthodologie de Gimsi
Gimsi [2] définit un cadre méthodologique afin de mieux formaliser les conditions de réussite
du projet Business Intelligence centré sur la problématique du "tableau de bord". La méthode a
pour ambition de dynamiser l’originalité et la créativité des concepteurs et utilisateurs. C’est ainsi
que l’on réussit l’intégration du système de tableaux de bord au cœur de la culture d’entreprise
sans perdre de vue la question du pilotage de la performance. Cette méthode se compose de 4
phases principales découpées en 10 étapes.
Phase Étape et objectif

1-Identification - Identification de l’entreprise dans son contexte (marché, straté gie).

(Etape 1)
- Identification de l’entreprise dans ses structure (métiers, proces
sus).(Etape 2)

2-Conception - Choisir les indicateurs pertinents en fonction de la stratégie, des pro

cessus et des hommes. (méthodologie complète de choix des
objectifs et des indicateurs) (Etape 3 et Etape 4).
- Construire les indicateurs et Collecter les données.(Etape 5 et Etape
6) - Construire le système de tableau de bord.(Etape 7)

3-Mise en œuvre - Choisir les progiciels les mieux adaptés à la mesure de la

performance dans l’entreprise. (Etape 8)
- Intégrer et déployer le système décisionnel dans l’entreprise.(Etape 9)

4-Amélioration per - Contrôler en permanence l’adéquation entre le système

manente décisionnelet les besoins des décideurs. (Etape 10)

Table 1.2 – Cycle de vie de la méthodologie Gimsi

1.6.3 Choix de la méthodologie

Après avoir étudié les deux différentes méthodologies, pouvant être utilisées pour la mise en
place de notre solution, nous remarquons que la méthodologie GIMSI est une méthode
coopérative basée sur la prise de décision répartie ce qui implique la présence d’un très grand
nombre de décideurs, chose que notre client ne détient pas. C’est dans cette optique que nous
avons choisi de travailler avec la méthodologie de Ralph Kimball qui est la plus adéquate pour
notre projet vu qu’elle s’adapte au mieux à nos besoins en termes de compétences, de temps, de
coût et d’exigence en ce qui concerne l’intégration de données.

13
1.7 Conclusion
Ce chapitre introductif nous a permis de détailler le cadre général du système. Après avoir
décrit l’organisme d’accueil d’une part, et la solution que nous allons concevoir et développer
d’autre part, nous avons présenté la méthodologie à adopter pour la réalisation du projet.
 14

CHAPITRE 2

L’INFORMATIQUE DÉCISIONNELLE

2.1 Introduction
Dans ce deuxième chapitre, nous commençons par la définition du Business Intelligence, ses
objectifs et son architecture tel que la DataWarehouse, le DataMart et l’extraction de données.
Par la suite on s’intéresse aux différents modèles du DataMart, et la relation entre la consolida
tion financière, le reporting et le tableau de bord. Enfin nous décrivons le système d’information
décisionnel (SID), son évolution dans le temps et une comparaison avec le système
transactionnel.

2.2 Business Intelligence

Les responsables d’entreprises sont aujourd’hui confrontés à la nécessité de prendre des
décisions toujours plus rapides, toujours plus précises et toujours plus efficaces. Ils deviennent
donc s’appuyer sur les logiciels de Business Intelligence pour identifier et extraire des
informations précieuses.
Le terme Business Intelligence (BI) [10] ou informatique décisionnelle est un ensemble de pro
cessus, des technologies et des pratiques de collecte, d’intégration, d’analyse et de présentation
de l’information dans le but de déceler des informations utilisables pour aider les dirigeants d’en
treprises et autres responsables à prendre des décisions plus informées. Ces données sont
ensuite préparées pour l’analyse afin de créer des rapports, tableaux de bord et d’autres outils de
Data Visualization pour rendre les résultats analytiques disponibles aux décideurs et aux
opérations.

2.3 Les objectifs de BI

Le principal objectif de BI [def:Obejectif] est de faciliter, d’accélérer et d’améliorer la prise de
décision au sein de l’entreprise, d’orienter le développement des futures activités, d’optimiser les
processus internes, d’augmenter l’efficience d’exploitation, de générer de nouveaux revenus, et
de prendre l’avantage sur la concurrence. Concrètement, la BI a pour but de transmettre la bonne
information aux bonnes personnes. Cela permet aux organisations de mieux comprendre

15
leur environnement, identifier les tendances de marché, générer des comptes rendus
personnalisés pour chaque pôle et chaque activité et ainsi d’adopter des stratégies pertinentes.
2.4 L’architecture du BI

Figure 2.1 – Architecture globale du BI

L’architecture du système d’information décisionnel [5] va permettre à l’ensemble de la chaîne

décisionnelle de fonctionner efficacement. Les données vont être collectées, nettoyées et consoli
dées via un ETL (Extract, Transform, Load), puis stockées dans un entrepôt de données ou des
magasins de données. Ces données structurées seront ensuite distribuées via un portail décision
nel puis analysées. Différentes technologies d’analyse de données existent : datamining, analyse
multi-dimensionnelle. . .

2.4.1 L’entrepôt de données (DataWarehouse)

Une Data Warehouse est une base de données relationnelle pensée et conçue pour les
requêtes et les analyses de données, la prise de décision et les activités de type Business
Intelligence davantage que pour le traitement de transactions ou autres usages traditionnels des
bases de données.[9]
Les données stockées dans une Data Warehouse présentent plusieurs spécificités. Ces
données sont orientées sujet, et intégrées. Elles sont aussi nommées et définies de façon
consistante. Par ailleurs, ces données sont associées à des périodes de temps définies. Enfin,
elles sont statiques (non volatiles), ce qui signifie qu’aucune mise à jour n’est effectuée sur ces
données.

16
2.4.2 Le magasin de données (DataMart)
Un datamart (ou magasin de données) [3] est une vue partielle du datawarehouse mais
orientée métier. C’est un sous-ensemble du datawarehouse contenant des informations se
rapportant à un secteur d’activité particulier de l’entreprise ou à un métier qui y est exercé. On
peut donc créer plusieurs datamart correspondant au différent besoin des utilisateurs. Cela
permet de réduire le nombre d’opération sur les bases de production. De plus cela permet d’offrir
aux utilisateurs un outil spécifiquement adapté à leurs besoins. Cet outil sera plus petit et
permettra donc un accès plus rapide à l’information.

2.4.3 Extraction des données

L’extraction de données est un processus de collecte ou récupération de types disparates de
données à partir de différentes sources, dont certaines peuvent être non structurées ou mal struc
turées. L’extraction des données permet de consolider, traiter et affiner les données, puis de les
stocker dans un emplacement centralisé avant de les transformer. L’extraction des données est la
première étape des processus ETL (extraction, transformation, chargement) et ELT (extraction,
chargement, transformation).

2.5 Modélisation DataMart

Dans un DataMart, les données et leurs relations sont organisées suivant un modèle de
données spécifique. Le choix du modèle de données structure et définit le design du DataMart.
Nous avons vu qu’il existait trois modélisations possibles :
— La modélisation en étoile.
— La modélisation en flocons.
— La modélisation en constellation.

17
2.5.1 Comparaison des modèles
Schéma en étoile Schéma en flocon de neige

Structure du Contient des tables de faits et Contient des tables de sous

schéma de dimensions. dimension comprenant des
tables de faits et de
dimensions.
 Modèle de données Top-down Bottom-up

Complexité de re Faible Haute

quête

Jointure utilisée Moins Grand nombre de jointure

Utilisation de l’es Plus Moins

pace

Temps consommé Prend moins de temps Prend plus en raison de

lors de l’exécution l’utilisa tion excessive de la
de la requête jointure.

Utilisation de la N’utilise pas la normalisation. Utilise la normalisation et la dé

normalisation normalisation.

Table 2.1 – Comparaison entre le schéma en étoile et le schéma en flacon de neige.

Le schéma en étoile et en flocon est utilisé pour concevoir l’entrepôt de données. Les deux
ont certains avantages et inconvénients. Cependant, l’utilisation du schéma en flocon minimise la
redondance, mais ce n’est pas populaire en tant que schéma en étoile qui est utilisé la plupart du
temps dans la conception de l’entrepôt de données. [13]

18
Schéma en étoile Schéma en constellation
 Un schéma en étoile représente chaque Les tables de dimension sont partagées
fait avec une seule table de dimension. par de nombreuses tables de faits. Le
schéma en constellation se compose de
plusieurs sché mas d’étoiles à la fois

Dans le schéma en étoile, les tables Dans un schéma en constellation, les

peuvent être maintenues facilement tables ne peuvent pas être maintenus
facilement comparativement.

Le schéma en étoile n’utilise pas la Une forme normalisée de schéma d’étoile

normali sation. et de flocon de neige.

Dans le schéma en étoile, des requêtes Des requêtes très complexes sont
simples sont utilisées pour accéder aux utilisées pour accéder aux données de la
don nées de la base de données. base de don nées.

Le schéma en étoile est facile à utiliser Le schéma en constellation n’est pas

car il a moins de jointures entre les tables. facile à utiliser car il comporte de
nombreuses join tures entre les tables.

Le schéma en étoile utilise moins Alors que le schéma de constellation de

d’espace que le schéma en constellation. faits utilise plus d’espace
comparativement.

Il est très simple à comprendre en raison Bien qu’il soit très difficile à comprendre
de sa simplicité. en raison de sa complexité.

Table 2.2 – Comparaison entre le schéma en étoile et le schéma en constellation

2.6 La consolidation financière, le ’reporting’ et le tableau de bord

Avoir une vision complète et proactive des données économiques de l’entreprise pour mieux
analyser, contrôler, anticiper et décider est parmi les défis les plus importants que l’entreprise
aspire à atteindre.
La consolidation des comptes permet d’avoir une visibilité globale sur les finances de
l’entreprise et de partager ces informations financières aux parties prenantes. Le reporting
financier consolidé est une synthèse des comptes des entreprises du groupe comprenant
notamment des états financiers et des tableaux de bords pour avoir une vision des performances
financières du groupe, avec des axes d’analyse spécifique (par exemple : zone géographique,
ligne de produit . . .). Ce reporting consolidé permet de maîtriser l’information financière et d’avoir
une vue d’ensemble concrète du groupe et de ses filiales, à intervalle régulier. Le but étant, pour
les directions, d’optimiser le pilotage de l’activité.

2.7 Le système d’information décisionnel en entreprise

Un système d’information décisionnel (SID) est un système dédié avant tout à des fins
décision nelles. Ce type de système s’adresse aux dirigeants ou chefs d’entreprises, et repose
sur l’utilisation

19
de l’informatique décisionnelle. En effet, le système d’information décisionnel (SID) désigne l’en
semble des moyens, outils et méthodes qui permettent à l’entreprise de collecter, renforcer,
stocker, agréger et restituer les données importantes afin de fournir une véritable aide à la
décision.

2.8 L’évolution des systèmes décisionnels

Le concept du système décisionnel (SID) est né de recherches menées au Carnegie Institute
of Technology dans les années 1950 et 1960, mais il a réellement pris racine dans les entreprises
dans les années 1980 sous la forme de systèmes d’information exécutifs (EIS), de systèmes
d’aide à la décision collective (GDSS) et de systèmes d’aide à la décision organisationnelle
(ODSS).
Cela dit, les entreprises étant de plus en plus axées sur la prise de décision basée sur des
données, la Business Intelligence a pris de plus en plus de place, et les scientifiques décisionnels
sont devenus de plus en plus indispensables pour débloquer le potentiel des systèmes de
science décisionnelle.

2.9 Comparaison entre les systèmes transactionnels et les

systèmes décisionnels
Les systèmes transactionnels, opérationnels ou encore appelés le système OLTP sont faits
pour assister les tâches quotidiennes, répétitives et atomique (c’est à dire l’insertion, modification
et suppression) au sein d’une entreprise. Alors que les systèmes décisionnels encore appelés
OLAP sont dédiés à la gestion d’une entreprise afin d’aider les décideurs pour la prise de
décision.
OLTP OLAP

Objectifs Le traitement des données L’analyse des données

Données - Détaillées, relationnelles, -Résumées, agrégées,

Actua lisées, mises à jour Historiées, recalculées
- La source : l’OLTP et ses tran Multidimensionnelles - La
saction source : les différentes bases
de données d’OLTP

Caractéristique Grand nombre de transactions Grand nombre de données

courtes

Utilité Le contrôle et l’exécution des - La planification et la

tâches commerciales réalisation de problèmes
- L’aide à la décision

Traitement Fournir un résultat rapide pour Garantir un temps de réponse

les données utilisées à la requête plus rapide et
 quotidienne ment cohérent

Opération Lecture/écriture Lecture

Type de requêtes Standardisées et simples Complexes

Utilisateur L’agent opérationnel Les analystes et les décideurs

Table 2.3 – Comparaison entre les systèmes transactionnels et les systèmes

décisionnels 20

2.10 Conclusion
Dans ce chapitre, nous avons détaillé toutes les notions relatives au Business Intelligence,
puis nous nous concentrons sur les systèmes de l’information décisionnel et leur importance dans
l’en treprise. Nous pouvons ainsi entamer la prochaine étape qui consiste à présenter la phase de
planification et spécification des besoins
 21

CHAPITRE 3

PLANIFICATION ET SPÉCIFICATION DES BESOINS

3.1 Introduction
Dans ce chapitre, nous présentons tout d’abord la planification de notre projet en identifiant
les tâches et l’équipe de réalisation. Par la suite, nous donnons une identité à notre projet en
définissant les besoins fonctionnels et non fonctionnels, l’architecture global et les étapes de
notre méthodologie. Enfin, nous décrivons l’environnement technique et les outils nécessaires
ainsi que l’approche de conception pour notre projet.

3.2 Planification
Établir un planning projet précis s’avère indispensable pour une gestion de projet efficace.
Alors afin de bien organiser et planifier les tâches à mener pour réussir le projet pendant une
période bien définie au préalable, nous avons choisi d’utiliser un outil d’ordonnancement et de
gestion de projet qui permet de représenter visuellement l’état d’avancement et la succession des
différentes tâches.

3.2.1 Diagramme de GANTT

L’outil utilisé est le digramme de GANTT qui est un outil très pratique et simple pour la plani
fication des projets. La figure ci-dessous présente les différentes étapes à suivre pour la
réalisation de notre projet.

22
 Figure 3.1 – Diagramme de GANTT

3.3 Spécification des besoins

Afin de répondre aux points précis de notre solution, et bien comprendre les fonctionnalités de
notre système, nous allons présenter dans cette partie, les besoins fonctionnels nécessaires aux
acteurs pour interagir avec le système et les besoins non fonctionnels qui améliorent la qualité
logicielle du système.

3.3.1 Identification des acteurs

Un acteur est une entité extérieure au système modélisé qui interagie directement avec lui.
Dans notre cas, il existe trois acteurs qui peuvent interagir avec notre système.

Administrateur : L’administrateur joue un rôle primordial et fondamental, c’est une per sonne
responsable de tous les paramétrages de l’application, il a le droit de gérer les comptes et les
permissions des utilisateurs et accorder les rôles.

Directeur général : Le directeur général peut faire :

— - Le suivi des transactions.
— - Le suivi des clients.
— - Prédire les future attentes.

Responsable commercial : C’est un acteur principal, il a l’accès à toutes les fonctions du

directeur général avec la création des tableaux de bord et l’ajout des nouvelles données.

23
3.4 Identification des besoins
3.4.1 Besoins fonctionnels
 La solution à réaliser doit offrir un ensemble de fonctionnalités qui doivent être mises en
relation avec un ensemble de besoins des utilisateurs. Afin de satisfaire nos utilisateurs et leurs
fournir des moyens nécessaires pour qu’ils puissent prendre les décisions stratégiques et
opérationnelles, notre solution doit donc assurer un tableau de bord bien ciblé avec des données
filtrées afin de fournir au décideur la possibilité de prendre les meilleures décisions.

Les besoins fonctionnels de notre application sont :

- S’authentifier : Le système permet aux utilisateurs (Responsable commercial ou Directeur

général) et à l’administrateur de s’authentifier afin d’optimiser la sécurité de l’application.

- Gérer comptes utilisateurs : Le système permet à l’administrateur d’ajouter, supprimer,

bloquer, débloquer et de consultes compte utilisateur.

- Gérer les permissions et accorder les rôles aux utilisateurs : Le système permet à
l’administrateur d’accorder l’accès à des utilisateurs spécifiques (le directeur général ne peut pas
créer des nouveaux tableaux de bord) et attribuer un rôle à chaque utilisateur.

- Faire le suivi des clients : Le système permet au responsable commercial et au directeur

général de visualiser tous les statistiques à propos les clients tel que l’évolution du nombre des
clients, nombre des clients par région, taux de rétention clients et d’autres.

- Faire le suivi des transactions : Le système permet au responsable commercial et au

directeur général de consulter les statistiques des transactions, nombre totale des factures, l’évo
lution des pertes et des profits...

- Prédire les prévisions : Le système permet au responsable commercial de prédire l’avenir et

l’état future des ventes à partir des anciennes données et tableaux de bord.

- Créer des tableaux de bord : Le système permet au responsable commercial de créer des
nouveaux tableaux de bord à partir des nouvelles données.

- Ajouter des données : le système permet au responsable commercial d’ajouter des nouvelles
données afin de rafraîchir les tableaux de bord pour prendre des nouvelles décisions.

3.4.2 Besoins non fonctionnels

Quand les besoins fonctionnels expriment les fonctionnalités concrètes du système, les
besoins non fonctionnels sont des indicateurs de qualité de l’exécution de ces besoins
fonctionnels. Alors notre système doit satisfaire les besoins non fonctionnels suivants : La
sécurité : Notre système

24
doit être hautement sécurisée, les informations et les tableaux de bord ne devront pas être ac
cessibles et autorisés à tout le monde, c’est-à-dire que tous les accès des utilisateurs doivent être
protégés par un login et un mot de passe pour parvenir à la sécurité du système.

La performance : Notre système doit être performant, agile et rapide, il doit être agir rapi
dement et répond à toutes les exigences des utilisateurs d’une manière optimale.

La fiabilité : Les données fournies doivent êtres fiables et le système doit rendre des résultats
corrects, pertinents et significatifs.

3.4.3 Diagramme de cas d’utilisation global

Figure 3.2 – Diagramme de cas d’utilisation

3.5 Architecture globale

Un système d’information décisionnel est composé de trois principaux composants, chacun
est destiné à traiter une phase du processus décisionnel, depuis la collecte de données au sein
même des unités de production jusqu’à la facilitation de l’aide à la décision.

25
- La première phase est la phase de la collecte des données, alors pour mettre en place notre sys
tème, une source de données d’entreprise nous a été fournie en entrée, cette source est un
fichier Excel qui contient des données hétérogènes et non standardisées.
- La deuxième phase est la phase ETL (Extract, Transform et Load) par lequel vont passer toutes
les données des systèmes opérationnels avant d’arriver à la forme souhaitée dans le datamart.
D’abord, nous avons effectués une identification des données à partir de la source, lire,
comprendre la source de données puis extraire les données dont on a besoin et les orienter vers
le système décisionnel. Après l’extraction des données, ces dernières subissent un travail de
transformation, de nettoyage et de filtrage. Une fois les données extraites et transformées, nous
allons les intégrer dans notre magasin de données (DataMart). En effet, les données qui seront
présentes dans cette base dimensionnelle sont des données figées et consolidées.
- La troisième phase est la phase d’analyse et restitution, pour faciliter l’accès à l’information,
pour tous les utilisateurs selon leurs profils métiers et afin d’extraire les éléments de décision pour
dynamiser la réactivité globale dans l’entreprise, ces données sont mises à la disposition sous
forme de tableaux de bord.
La figure ci-dessous illustre l’architecture globale de notre projet.

Figure 3.3 – Architecture globale du projet

3.6 Choix des indicateurs et collecte des informations

Après l’étude et l’indentification de l’entreprise et son environnement, définition des objectifs et
avant de réaliser les rapports il faut définir des indicateurs clés permettant d’extraire des rapports
qui ont pour but d’aider l’entreprise de comprendre leur système et prendre les bonnes décisions.
Chaque indicateur sera caractérisé, évalué et sélectionné selon 5 critères suivants :

— Un indicateur doit être utilisable en temps réel.

— L’indicateur doit mesurer un ou plusieurs objectifs.
— L’indicateur doit induire l’action.

26
— L’indicateur doit être constructible
— L’indicateur doit pouvoir être présenté sur le poste de travail
Les responsables de la société d’accueil, et grâce à leur expérience dans le métier du conseil,
ont rectifié et validé la liste d’indicateurs relatifs aux ventes que nous avons élaborée. Les
indicateurs choisis pour répondre aux besoins prédéfinis dans le secteur des ventes sont les
suivants :
— Profits et pertes totals.
— Perte par produit.
— Quantité vendue pour chaque produit et dans chaque région.
— Total des factures.
— Taux de commandes.
 — Nombre totale de client.
— Nombre de clients par région.
— Taux de clients par année
— Taux de rétention client.
— Taux de rétention par client.
Une fois les indicateurs choisis, nous allons les construire avec les informations à notre
disposition. Alors dès que l’information est disponible physiquement, elle sera nettoyée, vérifiée
et consolidée.

3.7 Environnement de développement

Un bon environnement matériel et logiciel assure le bon déroulement du travail et garantit de
bons résultats. Cette partie est consacrée pour la présentation des langages et d’outils de
programmation utilisés pour la réalisation de notre projet.

3.7.1 Environnement matériel

Pour le développement de notre projet, nous avons utilisé une machine DELL possédant les
caractéristiques suivantes :

— Système d’exploitation : Windows10 64-bits.

— Processeur : 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz 2.42 GHz.
— Mémoire RAM : 16Go.
— Disque dur : 1 To.

27
 Figure 3.4 – Spécification de la machine

3.7.2 Environnement logiciel

Pour la réalisation de notre projet, nous avons choisi ces outils :
— Source de données : Fichier EXCEL.
— Le stockage de données : Microsoft SQL SERVER.
— ETL : Jupyter NoteBook.
— Le reporting : Superset.
— L’infrastructure logiciel : Docker.

3.7.2.1 SQL SERVER

Le SQL server[6] désigne couramment un système de gestion de base de données (SGBD)
commercialisé par Microsoft. Concrètement, il est un outil qui possède toutes les caractéristiques
pour pouvoir accompagner l’utilisateur dans la manipulation, le contrôle, le tri, la mise à jour, et
bien d’autres actions encore, de bases de données grâce au langage SQL(Structured Query
Language) qui est ), un langage informatique permettant d’exploiter des bases de données.

Figure 3.5 – SQL SERVER

28
3.7.2.2 Jupyter NoteBook
 Jupyter[11] est une application web utilisée pour programmer dans plus de 40 langages de
programmation, dont Python, Julia, Ruby et R , dont l’objectif est de développer des logiciels
libres, des formats ouverts et des services pour l’informatique interactive. Jupyter permet de
réaliser des calepins ou notebooks, c’est-à-dire des programmes contenant à la fois du texte en
markdown et du code. Ces calepins sont utilisés en science des données pour explorer et
analyser des données.

Figure 3.6 – Logo Jupyter

3.7.2.3 Superset
Apache Superset[12] est une application Web d’intelligence d’affaires moderne et prête pour
l’entreprise. Il est rapide, léger, intuitif et doté d’options qui permettent aux utilisateurs de toutes
compétences d’explorer et de visualiser facilement leurs données, des simples graphiques
circulaires aux graphiques géospatiaux très détaillés.

Figure 3.7 – Logo Superset

3.7.2.4 Docker
Docker est un outil qui peut empaqueter une application et ses dépendances dans un
conteneur isolé, qui pourra être exécuté sur n’importe quel serveur machine, qu’il soit physique
ou virtuel. C’est une technologie qui a pour but de faciliter les déploiements d’application, et la
gestion du dimensionnement de l’infrastructure sous-jacente. Il ne s’agit pas de virtualisation,
mais de conteneurisation, une forme plus légère qui s’appuie sur certaines parties de la machine
hôte pour son fonctionnement. Cette approche permet d’accroître la flexibilité et la portabilité
d’exécution d’une application, laquelle va pouvoir tourner de façon fiable et prévisible sur une
grande variété de machines hôtes, que ce soit sur la machine locale, un cloud privé ou public...

29
 Figure 3.8 – Logo Docker

3.8 Approche de conception du modèle dimensionnel

En termes d’architecture de modèle dimensionnel et d’entrepôt de données, il existe deux mé
thodes de pensées distinctes : la méthode Inmon et la méthode Kimball. Ils considèrent tous deux
l’entrepôt de données comme le référentiel de données central de l’entreprise, répondent principa
lement aux besoins de reporting de l’entreprise, et ils utilisent tous les deux ETL pour charger
l’entrepôt de données. La principale distinction est la manière dont les structures de données sont
modélisées, chargées et stockées dans l’entrepôt de données.

3.8.1 Approche de Bill Inmon

Bill Inmon considérait lui le Data Warehouse comme le dépôt centralisé de toutes les données
de l’entreprise. Dans cette approche, une organisation crée d’abord un modèle de Data
Warehouse normalisé. Les Data Marts des différents secteurs sont ensuite créés sur la base du
modèle de l’entrepôt. C’est ce qu’on appelle une approche descendante (ou « top-down ») de
l’entreposage des données.

Figure 3.9 – La représentation schématique de l’approche de Bill Inmon

3.8.2 Approche de Ralph Kimball

Ralph Kimball propose une vision radicalement différente, ascendante, de la structuration de
la donnée, dite "Bottom-up". Les besoins de l’entreprise sont modélisés dans les magasins de
données, l’entrepôt de données n’est par la suite qu’une simple union de ses magasins de
données. Dans ce

30
qui suit, nous allons effectuer une définition à chacune de ces deux approches et une
comparaison entre elles.

Figure 3.10 – La représentation schématique de l’approche de Ralph Kimball

3.8.3 Choix de l’approche

Le tableau suivant résumera les deux approches :
Kimball Inmon

Approcher Il a une approche ascendante Il a une approche descendante

pour la mise en œuvre. pour la mise en œuvre.

Intégration de Il se concentre sur les Il se concentre sur les

données domaines d’activité individuels. domaines à l’échelle de
l’entreprise.

Méthode de Commence par la conception Commence par la conception

conception du data Warehouse. du modèle dimensionnel pour
les da tamarts.

Temps de C’est efficace et prend moins C’est complexe et prend beau

construction de temps. coup de temps.

Coût Il comporte des étapes Le coût initial est énorme et le

itératives et est rentable. coût de développement est
faible.

Compétences Il n’a pas besoin de telles Il a besoin de compétences

re quises compé tences mais une équipe spécia lisées pour fonctionner.
générique fera le travail.

Maintenance Difficil.e redondance à gérer. Facile.

Modèle de Les données sont dans un Les données sont dans un

don nées modèle dénormalisé. modèle normalisé.

Table 3.1 – Tableau comparatif des approches Kimball et Inmon

 Malgré l’opposition effective des deux modèles, aucun d’entre eux n’est à privilégier et le
choix de la meilleure approche dépend du projet à réaliser. Alors dans notre cas, nous avons
opté pour

31
l’approche de Kimball (Bottom-Up) dans plusieurs raisons, d’une part cette approche est carac
térisée par sa simplicité, sa rapidité et d’autre part notre solution est orientée vers un secteur
d’activité particulier.

3.9 Conclusion
Ce chapitre a été consacré à la planification du projet et à la spécification des besoins fonction
nels et non fonctionnels pour mieux identifier les objectifs attendus de notre solution et l’approche
de conception du modèle dimensionnel et de citer les technologies ainsi que les outils utilisés lors
du projet. Nous pouvons ainsi entamer la prochaine étape qui consiste à présenter la conception
de notre entrepôt de données.
 32

CHAPITRE 4

CONCEPTION DE L’ENTREPÔT DE DONNÉE

4.1 Introduction
Au cours du ce chapitre, nous entamons la phase de modélisation dimensionnelle et la
conception du modèle physique du magasin de données.

4.2 Conception du modèle dimensionnel

Le modèle dimensionnel est la structure de données la plus utilisée et la plus appropriée aux
requêtes et analyses des utilisateurs d’entrepôts de données. Les magasins de données sont la
version la plus petite de l’entrepôt de données, elles sont classées en trois types principaux.

4.2.1 Modèle en étoile

C’est une manière de relier une dimension à un fait dans un entrepôt de données. Dans le
modèle en étoile, on a une table de faits centrale qui est liée aux tables de dimensions.

Figure 4.1 – Modèle en étoile

33
4.2.2 Modèle en flocon de neige
C’est une manière de relier une dimension à un fait dans un entrepôt de données. C’est le
modèle en étoile avec une relation entre les dimensions. Il peut exister des hiérarchies des
dimensions pour diviser les tables de dimensions lorsqu’elles sont trop volumineuses.
 Figure 4.2 – Modèle en flocon de neige

4.2.3 Modèle en constellation

Le schéma en constellation représente plusieurs relations de faits qui partagent des
dimensions communes. Ces différentes relations de faits composent une famille qui partage les
dimensions mais où chaque relation de faits à ses propres dimensions.

Figure 4.3 – Modèle en constellation

4.2.4 Choix du modèle dimensionnel

L’analyse de données a démontré que ces derniers pouvaient être regroupées dans une seule
table de fait avec des tables de dimensions. C’est pour cette raison que nous avons choisi de
modéliser notre magasin de données en utilisant l’approche de modélisation en Flacon de neige.

34
4.3 Identification des faits
Les tables de faits contiennent les données que l’on souhaite voir apparaître dans les rapports
d’analyse, sous forme de métriques. Les données des tables de faits sont agrégées à partir des
tables de dimensions qui leur sont associées.
Reprenons la table de fait Vente dont l’objectif est de rassembler les informations concernant les
ventes des produits. Le grain de cette table de fait est en fait une ligne de commande et des
ventes : chaque ligne concerne un ou plusieurs produits commandés par un client donné à une
date donnée. La facture réunissant l’ensemble d’une ou plusieurs commandes pour un seul client.

4.3.1 Table de fait Vente

La table de fait Vente représente les ventes des produits laitières. Le Tableau ci-dessous
repré sente les mesures de la table de fait Vente de notre modèle.
Colonne Description Type

Code-client Identifiant du client Clé primaire et clé étrangère

qui fait référence à la
dimension client

Code-magasin Identifiant du magasin Clé primaire et clé étrangère

qui fait référence à la
dimension ma gasin

Num-fact Identifiant facture Clé primaire et clé étrangère

qui fait référence à la
dimension fac ture

Profit/perte totale Le gain et la perte total e Mesure additive

Perte par produit La perte de chaque produit Mesure additive

Quantité vendue Quantité vendue des produits Mesure additive

par region

Nombre de client Nombre de client totale Mesure additive

Nombre de clients Nombre de client dans chaque Mesure additive

par région re gion

Total des factures Total des factures par mois Mesure additive

Taux de commandes Taux de commandes. Mesure non-additive

Taux de clients par Taux de clients dans chaque Mesure non-additive

année an née

Taux de rétention Le nombre de clients qui Mesure non-additive

client recom mandent d’une année
sur l’autre

Taux de rétention Taux de retentions de chaque Mesure non-additive

par client client

Table 4.1 – Présentation des colonnes du fait Vente

 35
4.4 Identification des dimensions
Une dimension est une table qui contient les axes d’analyse (les dimensions) selon lesquels
on veut étudier des données observables qui, soumises à une analyse multidimensionnelle,
donnent aux utilisateurs des renseignements nécessaires à la prise de décision.

4.4.1 Les axes d’analyse du fait Vente

Dans notre cas, nous avons juste une seule table de fait Vente alors le schéma global de
notre DataMart est comme suit.

Figure 4.4 – Modèle physique de magasin de données

Le tableau ci-dessous représente les dimensions relatives à l’analyse du fait Vente. Les clés
primaires sont en gras.

36
Dimension Description Attribut
 Client Cette dimension code-client, code-region
correspond aux clients.

Magasin Cette dimension code-magasin

correspond aux
magasins disponibles
pour la vente des
produits Délice.

Facture Cette dimension corres num-fact, type-fact, date-fact,

pond aux factures des num-cmd
commandes des clients.

Gouvernorat Cette dimension code-region, region

correspond au
gouvernorat de chaque
client.

Commande Cette dimension num-cmd, type-cmd, date-cmd,

correspond aux quantite, somme, code-article
commandes passées par
chaque client.

Produit Cette dimension Code-article, dsc-article, prix-unt

correspond aux produits
vendus.

Table 4.2 – Présentation des dimensions relatives au fait Vente

4.5 Conclusion
Ce chapitre a été consacré à définir la conception du modèle physique du DataMart (magasin
de données) pour que nous puissions passer à la partie de préparation et alimentation des
données dans le chapitre qui suit.
 37

CHAPITRE 5

MISE EN PLACE DE L’APPLICATION

5.1 Introduction
Ce chapitre fait le tour de toutes les étapes d’implémentation et de développement de notre
application. Il introduit la phase essentielle, celle de la préparation de l’infrastructure et les outils
nécessaires à cette phase. De plus, sera introduit le développement de ETL tel que l’extraction,
transformation et le chargement des données.

5.2 Préparation de l’infrastructure

5.2.1 Installation Docker Desktop
Docker est une plateforme ouverte pour le développement, la livraison et l’exécution des
applica tions. Après l’installation de cette technologie, nous pouvons installer même séparer les
applications de l’infrastructure afin que nous puissions livrer rapidement les logiciels. Le
processus d’installation est très simple et facile. Dès que le processus d’installation est terminé
avec succès, et pour as surer que la plateforme à conteneurs fonctionne correctement. L’équipe
de développement fournit un simple conteneur hello-world à cet effet. Après l’installation, nous
devons redémarrer le PC et installer WSL 2, qui signifie Windows Setup for LINUX. Il s’agit d’une
couche de compatibilité pour l’exécution native des exécutables binaires Linux sur Windows. A la
fin nous allons créer un compte sur Docker Hub et mettre nos informations de connexion. La
figure ci-dessus montre l’interface de docker après l’installation.

38
 Figure 5.1 – Interface Docker Desktop

5.2.2 L’image Superset

Afin que nous puissions créer des différents graphes et tableaux de bord personnalisés,
Superset est le meilleur outil pour répondre à nos besoins. C’est un outil tellement flexible que
nous avons pu le personnaliser en modifiant certaines de ses fonctions selon nos choix. De
même, il possède un large panel de visuels disponibles pour mettre en valeur nos données. En
matière de sécurité, ce logiciel nous a offert une protection à nos données et une confidentialité à
notre projet par extension. De plus, Superset nous a permis d’interroger les données de n’importe
quel magasin de données ou moteur de données.

5.2.2.1 Téléchargement de l’image Superset

Une image de conteneur est un package logiciel léger, autonome et exécutable qui inclut tout
ce qui est nécessaire pour exécuter une application : code, environnement d’exécution... L’image
Superset est stockée sur Docker Hub (Docker Hub est un dépôt en ligne où les images Docker
peuvent être publiées et utilisées par les utilisateurs de la communauté Docker) et elle peut être
téléchargée à l’aide de la commande Docker pull et exécuter avec la commande Docker run.

39
 Figure 5.2 – Téléchargement de l’image superset sur Docker

5.2.2.2 Modification de l’image Superset

Pour la nouvelle image ou plutôt l’image modifiée ou personnalisée nous avons créé un fichier
Dockerfile. Un Dockerfile est simplement un script d’instruction basé sur texte qui est utilisé pour
créer une image de conteneur. Le script ci-dessous représente le Dockerfile.
FROM apache/superset:latest

USER root

RUN pip install pymssql

USER superset

RUN superset fab create-admin --username admin --firstname Wiem --lastname Jouini \ --email
admin@superset.com\
--password admin

RUN superset db upgrade

RUN superset init

40
Une fois l’image téléchargée et si nous jetons un coup d’œil au tableau de bord Docker, nous
allons voir notre nouvelle image modifiée.
 Figure 5.3 – Création d’une nouvelle image Superset

5.2.3 L’image SQL Server

5.2.3.1 Téléchargement de l’image
Pour télécharger l’image officielle SQL Server Docker à partir de Docker Hub, nous avons
com mencé par le choix de la version. L’étape suivante consiste à extraire l’image docker du
référentiel vers notre ordinateur local, alors, nous avons utilisé le terminal pour exécuter la
commande Docker pull. Une fois l’image SQL Server Docker extraite, nous pouvons démarrer le
conteneur Docker pour cette image (Un conteneur dans Docker est une instance en cours
d’exécution de l’image Docker). Pour démarrer le conteneur nous avons exécuté la commande
comme suit.

docker run -e "ACCEPT_ EULA=Y" -e

"SA_PASSWORD=SAQLSERVER2019,"\ -p 1433:1433 -d\
mcr.microsoft.com/mssql/server:2019-latest

De plus, nous pouvons également vérifier les conteneurs en cours d’exécution en utilisant la
commande : conteneur docker ls. Et comme vous pouvez le voir dans la figure ci-dessus, le
conteneur SQL Server Docker a été créé à partir de l’image et il est maintenant opérationnel

41

Figure 5.4 – Affichage de conteneur en cours d’exécution

5.2.4 Création du fichier Docker-Compose
Docker Compose est un outil permettant de définir et d’exécuter des applications Docker multi
conteneurs. Avec cet outil, nous avons utilisez un fichier YAML pour configurer les services de
notre application. Ensuite, nous avons défini les services qui composent notre application avec
docker compose.yml afin qu’ils puissent être exécutés ensemble dans un environnement isolé.
Enfin, nous avons exécuté docker-compose up, cette commande Docker compose démarre et
exécute l’intégralité de notre application. Ci-dessous, notre fichier docker-compose qui lie nos
deux services le SQL Server et Superset.

version: "2.7"
services:
database:
image: mcr.microsoft.com/mssql/server:2019-latest
environment:
ACCEPT_EULA: "Y"
SA_PASSWORD: "SQLSERVER2019,"
ports:
- "1433:1433"

superset:
build: "./docker/superset"
ports:
- "8088:8088"

5.2.5 Connexion entre les services

5.2.5.1 Connexion entre SQL Management Studio et Microsoft SQL Server
Pour cette étape, tout d’abord nous allons installer SSMS (SQL Server Management Studio)
ce qui nous permet de gérer et d’exploiter notre base de données avec SQL Server. Ensuite, une
fois l’installation est terminée, nous sommes prêts à ouvrir SQL Server Management Studio.
Après le démarrage de SSMS, une boite de dialogue s’affiche, nous allons sélectionner le type, le
nom du serveur, le mode d’authentification et le mot de passe pour nous connecter à notre
serveur.

42
 Figure 5.5 – Connection à SQL Server

Après quelques instants, SSMS se connecte à notre instance de base de données. Enfin,
pour pouvoir stocker nos données, nous allons créer notre base de données qui sera appelé
“ventes.

Figure 5.6 – Création de la base de données ventes

5.2.5.2 Connexion entre Superset et SQL Server

Après le téléchargement, la définition et la liaison entre SQL Server et Superset, nous
pouvons maintenant établir une connexion à notre base de données. En premier lieu, nous avons
accédé à Superset d’après le port 8088, s’authentifier puis choisir à quel moteur nous souhaitons
se connecter.

43
 Figure 5.7 – choisir la base de données dans Superset

Ensuite, après avoir choisi Microsoft SQL Server, nous allons créer un URl avec la
spécification du mot de passe, du port et le nom de la base de données (ventes) que nous avons
déjà créé où nous pourrons par la suite transférer les données.

Figure 5.8 – Copier la chaîne de connexion pour SQL Server

Maintenant, la connexion a été effectué, nous pouvons donc charger nos données après les
avoir transformés et traités.

5.3 Développement de la phase ETL

L’ETL (Extraction, Transformation et Chargement) est une phase très importante dans notre
processus. Comme son nom l’indique, cette phase permettra l’extraction des données à partir de
leur source (Le fichier Excel). Pour ce faire, nous allons créer un code python comme suit.

44
import pandas as pd
import matplotlib.pyplot as plt
df = pd.read_excel('./data/ventes.xlsx')
df.head()

Par la suite, nous allons pouvoir effectuer les différents changements nécessaires en
éliminant les redondances, en modifiant les noms des colonnes pour homogénéiser et unifier les
données afin de les rendre exploitables dans la phase de l’exportation des données qui suit, puis
nous allons extraire les tables de dimensions et les tables de fait.

facture_df = df[['N° Fact','Type_Fact','Date_Facture', 'N° Cmd']].drop_duplicates() facture_df.head()

commande_df = df[['N° Cmd','Type_CMD','Date_CMD', 'Qté2', 'somme', 'Code_Article']].

drop_duplicates()
commande_df.head()

ventes_df = df [['N° Fact','code_client','Magasin']]

ventes_df.head()

Une fois les tables sont extraites, nous allons les exporter dans des fichiers CSV pour pouvoir
les charger dans la base de données. Pour l’exportation, nous allons créer ce code python.

ventes_df.to_csv('./data/ventes.csv', index=False)
facture_df.to_csv('./data/facture.csv', index=False)
commande_df.to_csv('./data/commande.csv', index=False)
produit_df.to_csv('./data/produit.csv', index=False)
client_df.to_csv('./data/client.csv', index=False)
magasin_df.to_csv('./data/magasin.csv', index=False)
region_df.to_csv('./data/region.csv', index=False)

Finalement, nous allons alimenter la base de données à travers Superset. Pour cette étape,
nous allons premièrement se connecter à superset avec un nom d’utilisateur et un mot de passe
que nous les avons déjà identifiés dans le Dockerfile.

45
 Figure 5.9 – Connexion à Superset

Ensuite, nous allons charger les fichiers CSV dans la base de données.

Figure 5.10 – Implémentation des fichiers CSV dans la base de données

Enfin, nous allons remplir le formulaire et importer les fichiers que nous avons besoins et les
stocker dans la base de données.

46
 Figure 5.11 – Remplissage du formulaire

Une fois les fichiers sont chargés et enregistrés, nous pouvons commencer à créer les
graphes et les tableaux de bords.

Figure 5.12 – Alimentation de la base de données

5.4 Conclusion
Après avoir préparé la partie modélisation dimensionnelle afin de bien identifier les grandes
lignes de notre solution, nous avons effectué, durant ce chapitre, les différentes étapes depuis la
préparation de l’infrastructure jusqu’à alimentation de la base de données. Dans le chapitre
suivant, nous allons décrire la phase de restitution des données.

47

CHAPITRE 6

RESTITUTION DES DONNÉES

6.1 Introduction
Dans le chapitre précédent, nous avons détaillé toutes les étapes de notre processus. Selon
l’approche inventée par Ralph Kimball, nous entrons dans la dernière phase de notre solution qui
consiste au développement de nos tableaux de bord et notre application. Dans un second temps,
nous entamons l’analyse prédictive avec l’évaluation de quelques modèles.

6.2 Développement de l’application utilisateur

Après avoir réalisé l’étude de l’existant, nous commençons désormais le développement de
l’application utilisateur qui sera déployée par la suite et qui est dédiée aux décideurs. Dans cette
partie, nous allons utiliser les données nettoyées, consolidées et accessibles depuis l’entrepôt de
données. Dans ce qui suit, nous allons présenter les différentes interfaces graphiques de notre
solution.

6.2.1 Interface d’accueil

A l’ouverture de l’application, l’utilisateur reçoit une interface d’accueil contenant le nom de
l’application «Plateforme d’analyse de données et d’aide à la décidion», l’utilisateur dispose une
bouton «Login» pour le redériger vers l’ensemble des tableaux de bords représentant les
restitutions des données, une autre bouton «Test» pour l’analyse des données avec des boutons
qui représentent les services et les contacts de l’entreprise.

48
Figure 6.1 – Page d’accueil 49
6.2.2 Suivi des transactions

Figure 6.2 – Suivi des transactions

Le tableau de bord ci-dessous nous procure une vue globale sur toutes les informations
concer nant les transactions effectuées. Ce tableau de bord contient les visualisations suivantes :
— Un graphique en secteur pour visualiser le taux de commandes.
— Un graphique en anneau qui représente le taux de profit et de perte.
— Un graphique en courbe ou nous pouvons visualiser le nombre total des facteurs par mois
avec un curseur pour zoomer sur une période précise.
— Un histogramme empilé pour pouvoir visualiser la quantité vendue de chaque produit par
région.

50
— Un graphique en courbe qui représente le montant de perte par produit. Par le biais de ce
tableau de bord, le décideur a la possibilité d’analyser les données par produit.

6.2.3 Suivi des clients

Figure 6.3 – Suivi des clients

Ce tableau de bord illustre une vue détaillée sur les informations des clients. Il permet de
visualiser le nombre total des clients et le taux de rétention clients. Le tableau de bord affiche
également :
— Un histogramme empilé pour visualiser le taux des clients par années.

51

— Graphique circulaire qui représente nombre totale des clients dans chaque région. — Un
histogramme empilé pour la visualisation du taux de rétention pour chaque client Afin de mieux
visualiser les données, un filtre temporaire sera assuré. Le décideur pourra également analyser
par client.

6.3 Analyse Prédictive

L’analyse prédictive [8] est une méthode qui permet d’interpréter des données actuelles et his
toriques, permettant de créer des hypothèses et des prédictions sur des événements futurs. Elle
utilise des techniques telles que l’apprentissage automatique (Machine Learning) pour aider les
organisations à identifier des tendances, des comportements, des résultats futurs et des opportu
nités commerciales. Parmi les techniques qui permettent aux experts de concevoir des machines
apprenantes, on distingue deux types d’apprentissage automatique : l’apprentissage supervisé et
l’apprentissage non supervisé.

6.3.1 Apprentissage supervisé

L’apprentissage supervisé [1], c’est une récupération des données dites annotées de leurs
sorties pour l’entraînement du modèle, c’est-à-dire que les associé un label ou une classe cible,
une fois le modèle sera entraîné, il devient capable de prédire cette cible sur de nouvelles
données non annotées.
En apprentissage supervisé, on distingue entre deux types de tâches : Des tâches de
régression : n’attribue pas une classe mais une valeur mathématique. Des tâches de
classification : Ces tâches consistent à attribuer une classe à des objets.

6.3.2 Apprentissage non supervisé

En apprentissage non supervisé [defr2:analyse non supervisÃľ], les données d’entrées ne
sont pas annotées. Dans ce cas l’algorithme d’entraînement s’applique à trouver seul les
similarités et distinctions au sein de ces données, et à regrouper ensemble celles qui partagent
des caractéris tiques communes. Parmi les tâches réalisables grâce à cette méthode. Des tâches
de clustering : La machine groupe d’ objets dans des ensembles de données les plus homogènes
possible.
Des tâches d’association : Autre forme d’apprentissage non supervisé, qui identifie une
relation entre les points de données. En d’autres termes, ces algorithmes trouvent les points qui
apparaissent ensemble dans les données.

6.3.3 Expérimentations
Nous entamons maintenant la phase des expériences où nous allons tester quelques modèles
et algorithmes de machine learning pour nos prédictions.
Les principaux objectifs de notre solution, avoir une visibilité sur le comportement d’achat des
clients en connaissant les quels des produits ont achetés ou commandés ensemble avec une
prédiction de l’état financières de l’entreprise.

52
6.3.3.1 Analyse du comportement du client
Pour mieux comprendre les comportements de nos clients, nous avons choisi la méthode de
l’analyse des associations qui est utilisée pour découvrir des associations ou des relations
cachées entre nos données. Les relations découvertes peuvent être représentées sous forme de
règles d’as sociation ou d’ensemble d’items fréquents. Ces informations servent à bien mener les
campagnes marketing, mieux gérer les inventaires ou améliorer les relations clients.

6.3.3.2 Prédiction de l’état financière de l’entreprise

Cette phase de notre projet exige l’utilisation des algorithmes et des techniques
d’apprentissage automatique et de les tester afin que nous choisissons le meilleur pour une
prédiction optimale de l’état financier de l’entreprise en se basant sur les flux de données des
transactions antérieures. L’objectif du prévisionnel consiste à
— Mesurer la rentabilité de l’entreprise et de vérifier son équilibre financier.
— Obtenir une estimation des futurs revenus professionnels.
— Estimer les besoins de financement de l’entreprise.
— Evaluer la performance opérationnelle actuelle, étudier l’état de l’économie et déterminer la
performance future.
Prévisualiser l’impact des décisions sur le résultat et explorer les facteurs influant sur la renta
bilité de l’organisation grâce à la planification de nouvelle génération.

6.4 Méthodes et résultats

Après avoir défini les objectifs et les concepts qui seront discutés dans cette partie. Nous
allons chercher à tester la capacité de quelques algorithmes d’apprentissage automatique pour
répondre aux points définis. L’objectif de cette phase est d’utiliser des données historiques réelles
pour expérimenter les algorithmes d’apprentissage automatique et voir si on arrive à des résultats
concluants.

6.4.1 Analyse du comportement du client

L’objectif d’étudier le comportement du client est donc d’anticiper ses besoins dans le pro
cessus d’avant-vente mais aussi dans le processus d’après-vente, et ainsi de fidéliser la clientèle.
Premièrement, nous allons définir les règles d’association, qui permettent d’identifier les relations
sous-jacentes entre différents produits existant dans notre base de données, et l’algorithme
associé. Ensuite, nous nous intéressons au résultat de ces règles.

6.4.1.1 Implémentation
Dans cette partie, nous allons implémenter l’algorithme a priori pour l’extraction des règles
d’association. La première étape consiste à importer les bibliothèques requises. Nous avons
utilisé le script ci-dessous pour l’implémentation.

53
import pandas as pd
from apyori import apriori

NON_RELEVANT = ['TRS', 'TF', 'LOCATION', 'EM08T', 'F19900003']

df = pd.read_csv('data/facture.csv')
data = df.groupby('num_fact').agg(list)
commandes = pd.read_csv('data/commande.csv')

items = []

for idx, row in data.iterrows():

res = commandes[commandes['num_cmd'].isin(row['num_cmd'])]['code_article'].tolist() for i, x in
enumerate(res):
if x in NON_RELEVANT:
del res[i]
items.append(res)

rules = apriori(items, min_support=0.2, min_confidence=0.5)

association = inspect(rules)

association.to_csv('data/association.csv', index=False)

L’étape suivante, sert à charger les données à partir du fichier facture.csv et les grouper par le
numéro de factures. Et enfin, nous allons appliquer l’algorithme Apriori sur l’ensemble des
données. Pour l’utiliser, nous allons fixer un support et une confiance minimale, cela signifie que
nous ne sommes intéressés que par la recherche de règles pour les éléments qui ont une
certaine existence par défaut (le support) et ont une valeur minimale de cooccurrence avec
d’autres éléments (confiance). Le script suivant affiche ces étapes

6.4.1.2 Résultat
Après avoir appliqué et exécuté l’algorithme, finalement, nous avons le résultat qui lui est
associé.

54
 Figure 6.4 – Résultat des règles s’association

À partir de la figure ci-dessus, on peut voir que les produits qui apparaissent toujours
ensemble dans la plupart des commandes des clients.

6.4.2 Prédiction de l’état financière de l’entreprise

Cette partie de la solution a pour objectif de définir le meilleur des modèles de machine
learning. Dans la première, nous allons choisir quelques modèles et tester leurs performances à
prédire. La seconde est consacrée au résultat de ces modèles et finalement, la troisième est
dédiée pour notre choix d’après les tests que nous avons fait.

6.4.2.1 Entrainement et test

Dans cette section, nous allons présenter les modèles que nous avons déjà choisi, les tester,
mesurer et surveiller leurs performances avant et après l’avoir les déployer en production. Notre
choix est basé sur la nature des données utilisées qui sont des séries temporelles représentant
les sommes des commandes faites par les clients. Les modèles que nous avons sélectionnés
sont la Régression Linéaire, SGDRregressor, Lasso, ElasticNet et finalement ARIMA.
Premièrement, nous sommes dans la phase de préparation des données, nous avons utilisé
les données collectées et placées dans notre base de données pour créer des échantillons. Nous
avons aussi les validés pour s’assurer qu’il n’y a pas des données manquantes ou des valeurs
aberrantes. Nous avons aussi normalisé la structure des fichiers contenant ces données pour
qu’ils soient tous structurés de la même façon. Pour l’échantillonnage nous avons fractionné les
données en deux parties, la première partie égale à 75% des données totales pour l’entraînement
et le reste qui sont d’autres ensembles indépendants qui vont être utilisés seulement pour
l’évaluation de la qualité des prédictions générées par nos modèles prédictifs. Après nous allons
les charger dans des fichiers CSV.

import pandas as pd

df = pd.read_csv('../data/commande.csv')

55
data = df.groupby(['type_cmd']).agg(list)
train_size = int(len(total) * 0.75)
train_df, test_df = total[:train_size], total[train_size:]

train_df.to_csv('../data/train/{}.csv'.format(name))
test_df.to_csv('../data/test/{}.csv'.format(name))

Ensuite, nous allons appliquer les premiers quatre modèles.

import pandas as pd
from sklearn.linear_model import LinearRegression, SGDRegressor, Lasso, ElasticNet from
sklearn.metrics import mean_squared_error

def train_model(model, train_df, test_df, name):

train_df.fillna(0, inplace=True)
test_df.fillna(0, inplace=True)

y_test = test_df['target']
y_train = train_df['target']

x_train = np.arange(len(train_df)).reshape(-1, 1)
x_test = np.arange(len(test_df)).reshape(-1, 1)

model.fit(x_train, y_train)

y_hat = model.predict(x_test)

mse = mean_squared_error(y_test, y_hat)

return model

train_df = pd.read_csv('../data/train/co.csv')
test_df = pd.read_csv('../data/test/co.csv')

train_df.sort_values(by='date', inplace=True)
test_df.sort_values(by='date', inplace=True)

models = [
(SGDRegressor(max_iter=1000), 'SGD Regressor'),
(Lasso(alpha=1.0), 'LASSO'),
(ElasticNet(alpha=1.0, l1_ratio=0.5), 'ElasticNet'),
(LinearRegression(), 'Linear Regression')

56
]

x_test = np.arange(len(test_df)).reshape(-1, 1)
plt.title('Visualisation des résultats de l\'entrainement') plt.plot(x_test,
test_df['target'], 'b', label='target')

for model, name in models:

trained_model = train_model(model, train_df, test_df, name) y_hat =
trained_model.predict(x_test)

Enfin l’application du modèle ARIMA

import pickle
import pandas as pd
from matplotlib import pyplot as plt
from statsmodels.tsa.arima.model import ARIMA

traindf = pd.read_csv('../data/train/{}.csv'.format(args.dataset)) testdf =

pd.read_csv('../data/test/{}.csv'.format(args.dataset))

traindf.fillna(0, inplace=True)
testdf.fillna(0, inplace=True)

traindf.index = pd.to_datetime(traindf['date'])
testdf.index = pd.to_datetime(testdf['date'])

model = ARIMA(traindf['target'], order=(1, 0, 1))

res = model.fit()

y_hat = res.forecast(steps=len(testdf))

plt.figure(figsize=(15, 10))
plt.title('Visualisation du modele ARIMA phase de test')
plt.plot(testdf.index, testdf['target'], 'b', label='test') plt.plot(testdf.index,
y_hat, 'r', label='prediction')
plt.legend()
plt.grid()
plt.show()

with open('../data/model_arima_{}.pkl'.format(args.dataset), 'wb') as f: pickle.dump(res,

f)

57
6.4.2.2 Résultats et choix du modèle
Dans cette étape, nous allons exposer les résultats obtenus des différents modèles décrits pré
cédemment, ensuite nous allons comparer leurs performances et enfin choisir parmi ces modèles
le plus performant.
 Figure

6.5 – Résultat des modèles Régression Linéaire, SGDRregressor, Lasso et ElasticNet

La figure ci-dessus montre que les modèles suivant Régression Linéaire, SGDRregressor,
Lasso et ElasticNet ont la même performance puisqu’ils ont la même courbe, mais si nous les
comparons avec la courbe des données d’entraînement nous remarquons une grande différence
entre les deux courbes.

58
 Figure 6.6 – Résultat du modèle ARIMA

La deuxième figure ci-dessus montre le résultat de prédiction du modèle ARIMA avec une
différence entre la courbe des données de test et celle du modèle ARIMA. D’après ces résultats
nous ne pouvons pas conclure les quels de ces modèles est le plus performant alors nous avons
opté de les comparer en utilisant un autre facteur le RMSE (L’erreur quadratique moyenne) est un
calcul statistique utilisé pour déterminer la différence entre les valeurs prédites dans un modèle et
les valeurs réelles des observations.
Modéle MSE

SGD Regressor 2262964782660.1084

LASSO 1215.8721

ElasticNet 1215.7082

Linear Regression 1215.9081

ARIMA 1193.101

Table 6.1 – Comparaison des modéles linear

Le tableau de comparaison montre les résultats de performance statique de nos modèles en

utilisant un facteur de calcule d’erreur quadratique moyenne pour chaque modèle. Nous pouvons
voir alors que le modèle SGD Regressor a le RMSE le plus elevé tandis que ARIMA a le plus
bas. Alors, d’après ces mesures, on conclure que le modèle ARIMA est le plus performant par
rapport aux autres.

6.4.2.3 Déploiement
Maintenant, nous sommes à l’étape finale, l’étape de déploiement. En effet, une fois le modèle
créé, testé et évalué sur les données de test, celui-ci est mis en production pour les utilisateurs

59
finaux. Cette étape nécessite l’utilisation du processus de sérialisation qui est un moyen permet
de transformer une structure d’objet complexe en un flux d’octets qui peut être enregistré ou
envoyé sur un réseau. Dans notre cas, le but d’utiliser ce moyen à travers le module pickle est
d’enregistrer notre modèle choisi ARIMA après la phase d’entraînement afin que vous puissiez
l’utiliser plus tard sans avoir à refaire l’entraînement. Une fois le modèle est enregistré, nous
avons créé une interface pour faciliter à l’utilisateur de suivre les prédictions et utiliser le modèle.
La figure ci-dessous représente l’interface d’analyse prédictive.

Figure 6.7 – Interface de prédiction

6.5 Conclusion
La phase de restitution et d’analyse de données représente la dernière étape de notre travail.
A travers cette phase, nous avons représenté les différentes interfaces de nos tableaux de bord
ainsi que les résultats des analyses assurés sur les données et enfin les étapes de déploiement
de l’application utilisateur.

60

CHAPITRE 7

CONCLUSION GÉNÉRALE
 Le Business Intelligence est un domaine en évolution utilisé pour soutenir la prise de décision
commerciale. C’est devenu une exigence en capital, car la simple logique de production pour ré
pondre à la demande n’est plus suffisante pour maintenir la continuité de cette activité, ainsi les
entrepôts et les magasins de données ont vu le jour.
C’est dans ce contexte que nous réalisons notre projet de fin d‘études dans le cadre de
l’obtention de la licence fondamentale en informatique de gestion, effectué au sein de Centre
Laitière du Nord « CLN ». Nous soulignons le prévalu acquis suite à la mise en pratique de nos
connaissances théoriques dans un environnement professionnel. L’objectif de notre projet était de
concevoir et mettre en place un système d’aide à la décision et d’analyse prédictive dédiée à
l’analyse et le suivi des activités des clients et des commandes, pour faciliter la prise de décisions
aux décideurs. Dans une première partie, nous avons étudié le cadre général du projet, analysé
et spécifié les besoins qui nous ont permis de distinguer les différents acteurs interagissant avec
l’application et de déterminer les besoins fonctionnels et non fonctionnels du système. Par la
suite, nous avons défini l’architecture de notre solution, ainsi que l’implémention de notre entrepôt
de données. La dernière partie du projet est consacrée à l’explication de toutes les étapes de
mise en place de l’application, au déploiement des tableaux de bord et à l’analyse prédictive.
Cette expérience nous a amenés à découvrir et nous approfondir dans le domaine du Business
Intelligence et ses principales phases en utilisant la méthodologie de Ralph Kimball. Elle nous a
permis d’apprendre à manipuler de nouveaux outils tels que Docker et superset. Finalement,
cette expérience nous a permis d’enrichir nos connaissances, notre formation théorique et
pratique acquise tout au long de notre cursus universitaire et ainsi d’améliorer nos capacités à
nous intégrer dans la vie professionnelle.
En termes de perspectives, nous pouvons améliorer notre système en ajoutant de nouveaux
axes à traiter et des tableaux de bord selon le besoin du client.Nous pouvons aussi implémenter
et essayer d’autres algorithmes et modèles de Machine Learning qui permettront à nos
prédictions d’être plus précises.

61
WEBOGRAPHIE

[1] Apprentissage supervisé ou non supervisé. url : https : / / openclassrooms . com / fr /

courses/4011851- initiez- vous- au- machine- learning/4020611- identifiez- les differents-
types-dapprentissage-automatiques.
[2] Alain Fernandez. La méthode GIMSI, les fondamentaux. url : https://www.piloter.
org/mesurer/methode/fondamentaux_gimsi.htm.
[3] Université Joseph Fournier. Datamart. url : http : / / www - igm . univ - mlv . fr / ~dr /
XPOSE2005/entrepot/datamart.html.
[4] Kimball Group. Méthode Kimball. url : https : / / www . kimballgroup . com / about - kimball-
group/.
 [5] Solution Business Intelligence. Architecture BI. url : https://solutions-business
intelligence.fr/notre-expertise/architecture-bi/.
[6] journaldunet. Définition du mot SQL Server. url : https://debitoor.fr/termes
comptables/consolidation.
[7] Keejob. Société Centrale Laitière Du Nord. url : https://www.keejob.com/offres
emploi/companies/7211/danone-holding/.
[8] L’analyse prédictive, qu’est-ce que c’est. url : https : / / www . redhat . com / fr / topics /
automation/how-predictive-analytics-improve-it-performance.
[9] labigdata. Data Warehouse (entrepôt de données) définition : qu’est-ce que c’est ? url :
https://www.lebigdata.fr/data-warehouse-entrepot-donnees-definition.
[10] Oracle. Quelle est la place de la Business Intelligence dans une entreprise ? url : https:
//www.oracle.com/fr/database/business-intelligence-definition.html.
[11] wikipedia. Jupyter. url : https://fr.wikipedia.org/wiki/Jupyter.
[12] wikipedia. Qu’est-ce qu’Apache Superset. url : https://superset.apache.org/docs/ intro.
[13] Way to lear X. Différence entre le schéma en étoile et en flocon. url : https://waytolearnx.
com/2018/08/difference-entre-le-schema-en-etoile-et-en-flocon.htmll.

62