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

Introduction Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

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

1
 2.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

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
Conclusion et Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 [5] 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 Besoins Cette phase permet d’identifier les utilisateurs de l’application et leurs
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 œuvre.
tecture technique — É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 besoins de
tion des produits 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 utilisateurs.
sionnelle — 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 modèle La conception physique comporte la définition du modèle élaboré de l’en-
physique trepôt de données(DW).
Conception et déve- — Concevoir l’ODS ou la Staging Area (SA).
loppement de la zone — Effectuer le processus ETL
de préparation des
données
Spécification de l’ap- Cette phase englobe la préparation des maquettes à réaliser dans la phase
plication utilisateur qui suit.
Développement de Après la réalisation des différentes phases précédentes, cette phase nous
l’application BI 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 crois- Après la mise en place de la solution, l’entrepôt va donc évoluer et croître
sance 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 [3] 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 décisionnelet les

manente 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 [2] 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) [4] 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 de Contient des tables de sous-
schéma 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 l’utilisa-
lors de l’exécution tion excessive de la jointure.
de la requête
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
Un schéma en étoile représente chaque fait
avec une seule table de dimension.
Dans le schéma en étoile, les tables peuvent
être maintenues facilement
Le schéma en étoile n’utilise pas la normali-
sation.
Dans le schéma en étoile, des requêtes
simples sont utilisées pour accéder aux don-
nées de la base de données.
Le schéma en étoile est facile à utiliser car il
a moins de jointures entre les tables.
Le schéma en étoile utilise moins d’espace
que le schéma en constellation.
Il est très simple à comprendre en raison de
sa simplicité.
Schéma en constellation
Les tables de dimension sont partagées par
de nombreuses tables de faits. Le schéma en
constellation se compose de plusieurs sché-
mas d’étoiles à la fois
Dans un schéma en constellation, les tables
ne peuvent pas être maintenus facilement
comparativement.
Une forme normalisée de schéma d’étoile et
de flocon de neige.
Des requêtes très complexes sont utilisées
pour accéder aux données de la base de don-
nées.
Le schéma en constellation n’est pas facile à
utiliser car il comporte de nombreuses join-
tures entre les tables.
Alors que le schéma de constellation de faits
utilise plus d’espace comparativement.
Bien qu’il soit très difficile à comprendre 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, Actua- -Résumées, agrégées, Historiées,
lisées, mises à jour recalculées Multidimensionnelles
- La source : l’OLTP et ses tran- - La source : les différentes bases
saction 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 réalisation
tâches commerciales 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 quotidienne- la requête plus rapide et cohérent
ment
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 domaines Il se concentre sur les domaines à
données d’activité individuels. l’échelle de l’entreprise.
Méthode de Commence par la conception du Commence par la conception du
conception data Warehouse. modèle dimensionnel pour les da-
tamarts.
Temps de C’est efficace et prend moins de C’est complexe et prend beau-
construction temps. coup de temps.
Coût Il comporte des étapes itératives Le coût initial est énorme et le
et est rentable. coût de développement est faible.
Compétences re- Il n’a pas besoin de telles compé- Il a besoin de compétences spécia-
quises tences mais une équipe générique lisées pour fonctionner.
fera le travail.
Maintenance Difficil.e redondance à gérer. Facile.
Modèle de don- Les données sont dans un modèle Les données sont dans un modèle
nées dénormalisé. 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 par Mesure additive
region
Nombre de client Nombre de client totale Mesure additive
Nombre de clients par Nombre de client dans chaque re- Mesure additive
région 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 an- Mesure non-additive
année née
Taux de rétention Le nombre de clients qui recom- Mesure non-additive
client mandent d’une année sur l’autre
Taux de rétention par Taux de retentions de chaque Mesure non-additive
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 correspond code-client, code-region
aux clients.
Magasin Cette dimension correspond code-magasin
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 correspond code-region, region
au gouvernorat de chaque
client.
Commande Cette dimension correspond num-cmd, type-cmd, date-cmd,
aux commandes passées par quantite, somme, code-article
chaque client.
Produit Cette dimension correspond Code-article, dsc-article, prix-unt
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
 CONCLUSION ET PERSPECTIVES

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’obten-
tion 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 uni-
versitaire 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] Architecture BI. url : https://solutions-business-intelligence.fr/notre-expertise/
architecture-bi/.
[3] Alain Fernandez. La méthode GIMSI, les fondamentaux. url : https://www.piloter.
org/mesurer/methode/fondamentaux_gimsi.htm.
[4] Université Joseph Fournier. Datamart. url : http : / / www - igm . univ - mlv . fr / ~dr /
XPOSE2005/entrepot/datamart.html.
[5] Kimball Group. Méthode Kimball. url : https : / / www . kimballgroup . com / about -
kimball-group/.
[6] journaldunet. 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 les schémas. url : https://waytolearnx.com/2018/08/
difference-entre-le-schema-en-etoile-et-en-flocon.htmll.

62