Remerciements

Je présente mes vifs remerciements à madame Jihen Chedli, qui a assuré

l’encadrement de ce travail. Je tiens à la remercier très spécialement pour
sa disponibilité, ses conseils constructifs, ses encouragements qui m’ont
toujours réconforté.
Ma profonde sincère gratitude s’adresse également à madame Leila
Sammoud mon encadrante professionnelle au sein de BMC (business and
management consulting) de m’avoir fait partager son expérience et pour
le temps qu’elle m’a consacré pour répondre à toutes mes interrogations,
ainsi que pour ses suivis et ses conseils.
Enfin j’adresse mes remerciements aux membres de jury pour l’intérêt qui
ont accordé à mon travail en acceptant à son évaluation.

Imene Mbarki.
 Dédicaces

Je dédie ce travail à . . . Mon adorable mère, la femme qui a souffert sans

me laisser souffrir, qui n’a jamais dit non et qui n’a épargné aucun effort
pour me rendre heureuse. Aucune dédicace très chère maman, ne pourrait
exprimer la profondeur des sentiments que j’éprouve pour vous, vos
sacrifices innombrables et votre dévouement firent pour moi un
encouragement
Mon cher père, mon précieux offre du dieu, qui doit ma vie, ma réussite
et tout mon respect, qui n’a jamais cessé de me soutenir et de m’épauler
pour que je puisse atteindre mes objectifs.
Mon frère, Je vous dédie ce travail en témoignage de ma profonde
affection et de mon attachement indéfectible.
Mes très chers amis et tous ceux qui m’ont soutenu tout au long de la
période du stage.

Imene Mbarki.
Table des matières

Table des figures vi

Liste des tableaux ix

1 Cadre général du projet 3

1.1 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Présentation de l’organisation . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Présentation de BMC . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1.1 Les services de BMC . . . . . . . . . . . . . . . . . . . . . 4
1.2.1.2 Les technologies de BMC . . . . . . . . . . . . . . . . . . 5
1.2.2 Présentation de l’organisme client . . . . . . . . . . . . . . . . . . . 5
1.2.2.1 Les produits de Tunisie Câbles . . . . . . . . . . . . . . . 6
1.3 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Méthodologie adoptée de conduite de projet . . . . . . . . . . . . . . . . . 8
1.4.1 Approches agiles vs. Classiques . . . . . . . . . . . . . . . . . . . . 8
1.4.2 Choix de la méthodologie . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . 10
1.5.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 État de l’art et Étude de l’existant 14

2.1 L’état de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Le concept décisionnel . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1.1 Définition d’un système décisionnel . . . . . . . . . . . . . 15
2.1.1.2 Architecture d’un système décisionnel . . . . . . . . . . . 15
2.1.2 ETL “ Extract - Transform - Load “ . . . . . . . . . . . . . . . . . 16
2.1.3 Entrepôt de données “ Data Warehouse “ . . . . . . . . . . . . . . . 16
2.1.3.1 Caractéristiques d’un entrepôt de données . . . . . . . . . 17
2.1.3.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

iii
 TABLE DES MATIÈRES

2.1.3.3 Magasin de données ”DATAMART” . . . . . . . . . . . . 17

2.1.4 Modélisation multidimensionnelle . . . . . . . . . . . . . . . . . . . 18
2.1.4.1 Types de modèles dimensionnels . . . . . . . . . . . . . . 19
2.1.5 Restitution des données . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.5.1 Le reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.5.2 Tableau de bord (Dashboard) . . . . . . . . . . . . . . . . 21
2.2 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.1 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.2 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Analyse et Spécification des Besoins 23

3.1 Capture de besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.2 Identification des besoins non fonctionnels . . . . . . . . . . . . . . 24
3.1.2.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . 24
3.1.2.2 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . 25
3.2 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Identification de cas d’utilisation . . . . . . . . . . . . . . . . . . . 26

4 Conception 27
4.1 Conception du Data Warehouse . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.1 Présentation de l’activité ≪ Vente ≫ . . . . . . . . . . . . . . . . . . 28
4.1.2 Choix des dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.2.1 Dimension Item . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.2.2 Dimension Currency . . . . . . . . . . . . . . . . . . . . . 30
4.1.2.3 Dimension Activity . . . . . . . . . . . . . . . . . . . . . . 31
4.1.2.4 Dimension Customer . . . . . . . . . . . . . . . . . . . . . 31
4.1.2.5 Dimension Site . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.2.6 Dimension Sales Person Purchaser . . . . . . . . . . . . . 33
4.1.2.7 Dimension Date . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.2.8 Dimension Document Sales . . . . . . . . . . . . . . . . . 34
4.1.3 Choix des indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.4 Tables de faits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.4.1 Fait Sales Value Entry . . . . . . . . . . . . . . . . . . . . 36
4.1.4.2 Fait Sales Order State . . . . . . . . . . . . . . . . . . . . 38
4.1.4.3 Fait Sales Delivery . . . . . . . . . . . . . . . . . . . . . . 41
4.1.5 Structure du DataWarehouse . . . . . . . . . . . . . . . . . . . . . 42
4.2 Conception ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1 Etude de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.1.1 Fichiers Sources . . . . . . . . . . . . . . . . . . . . . . . . 43

page iv
 TABLE DES MATIÈRES

4.2.1.2 Fichiers de Mapping . . . . . . . . . . . . . . . . . . . . . 44

4.2.2 Extraction de données . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.3 Chargement des données SA . . . . . . . . . . . . . . . . . . . . . . 45
4.2.4 Transformation des données . . . . . . . . . . . . . . . . . . . . . . 46
4.2.5 Chargement des données DWH . . . . . . . . . . . . . . . . . . . . 46
4.3 Conception du tableau de bord . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.1 Shéma du tableau du bord ≪Suivi des ventes≫ . . . . . . . . . . . . 46
4.3.2 Tables des agrégations . . . . . . . . . . . . . . . . . . . . . . . . . 47

5 Réalisation 48
5.1 Architecture globale de l’application . . . . . . . . . . . . . . . . . . . . . . 49
5.2 Réalisation de la phase ETL . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.1 Composants SSIS utilisés . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.2 Préparation de l’environnement de l’ETL . . . . . . . . . . . . . . . 52
5.2.3 Alimentation de Staging Area . . . . . . . . . . . . . . . . . . . . . 53
5.2.4 Alimentation de l’entrepôt de données . . . . . . . . . . . . . . . . 56
5.2.4.1 Chargement des dimensions . . . . . . . . . . . . . . . . . 56
5.2.4.2 Chargement des faits . . . . . . . . . . . . . . . . . . . . . 62
5.2.4.3 Processus global du package Main . . . . . . . . . . . . . 68
5.3 Réalisation du tableau de bord . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3.1 Les interfaces du tableau de bord . . . . . . . . . . . . . . . . . . . 71

Conclusion et perspectives 80

Bibliographie 82

page v
Table des figures

1.1 Logo BMC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Logo Tunisie Câbles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Fiche d’identité de la société Tunisie Câbles. . . . . . . . . . . . . . . . . . 6
1.4 Méthode classique vs Méthode Agile. . . . . . . . . . . . . . . . . . . . . . 9
1.5 Méthodologie 2TUP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Logo Diagram.net. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7 Logo Overleaf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8 Logo Microsoft Visual studio . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.9 Logo SQL Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.10 Logo SQL Server Integration Services. . . . . . . . . . . . . . . . . . . . . 12
1.11 Logo SQL Server Management Studio. . . . . . . . . . . . . . . . . . . . . 13
1.12 Logo Microsoft Power BI. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 Les phases d’un système décisionnel. . . . . . . . . . . . . . . . . . . . . . 15

2.2 Processus ETL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Différence entre un Datamart et un Datawarehouse. . . . . . . . . . . . . . 17
2.4 Modèle en étoile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Modèle en flocon de neige. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6 Modèle en constellation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Diagramme de cas d’utilisation global. . . . . . . . . . . . . . . . . . . . . 25

4.1 Dimension Item. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 Dimension Currency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 Dimension Activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Dimension Customer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5 Dimension Site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.6 Dimension Site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.7 Dimension Date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.8 Dimension Document Sales. . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.9 Modèle physique de la table de fait Vente. . . . . . . . . . . . . . . . . . . 37
4.10 Modèle physique de la table de fait Commande. . . . . . . . . . . . . . . . 40

vi
 TABLE DES FIGURES

4.11 Modèle physique de la table de fait Livraison. . . . . . . . . . . . . . . . . 42

4.12 Dossier ≪Ventes≫. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.13 Description du fichier ≪BPARTNER≫. . . . . . . . . . . . . . . . . . . . . 44
4.14 Dossier des fichiers de Mapping. . . . . . . . . . . . . . . . . . . . . . . . . 44
4.15 Figure démonstrative du fichier de Mapping nommé ≪BPARTNER≫. . . . 45
4.16 Shéma du tableau de bord de l’activité Ventes. . . . . . . . . . . . . . . . . 46

5.1 Architecture globale de l’application. . . . . . . . . . . . . . . . . . . . . . 49

5.2 Bases de données créées. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3 Pachages SSIS créées pour l’ETL. . . . . . . . . . . . . . . . . . . . . . . . 52
5.4 Les gestionnaires de connexions créés. . . . . . . . . . . . . . . . . . . . . . 53
5.5 Package STG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.6 Exctraction de données d’un fichier CSV vers STG. . . . . . . . . . . . . . 54
5.7 Exctraction de données d’un fichier EXCEL vers STG. . . . . . . . . . . . 55
5.8 Tâche d’exécution de requête SQL. . . . . . . . . . . . . . . . . . . . . . . 55
5.9 Le package DimDWH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.10 Le chargement de la dimension Document Sales. . . . . . . . . . . . . . . . 57
5.11 Requêtes Sources de la dimension Document Sales. . . . . . . . . . . . . . 57
5.12 Unir tout de la dimension Document Sales. . . . . . . . . . . . . . . . . . . 58
5.13 Dimension à variation lente de la dimension Document Sales. . . . . . . . . 58
5.14 Le chargement de la dimension Customer. . . . . . . . . . . . . . . . . . . 59
5.15 La requête source de la dimension customer. . . . . . . . . . . . . . . . . . 59
5.16 La colonne dérivée de la dimension Customer. . . . . . . . . . . . . . . . . 60
5.17 Dimension à variation lente de la dimension Customer. . . . . . . . . . . . 60
5.18 Le chargement de la dimension Item. . . . . . . . . . . . . . . . . . . . . . 61
5.19 La requête source de la dimension Item. . . . . . . . . . . . . . . . . . . . 61
5.20 Dimension à variation lente de la dimension Item. . . . . . . . . . . . . . . 62
5.21 Package FactDWH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.22 Chargement de la table fait Sales Value Entry. . . . . . . . . . . . . . . . . 63
5.23 Requête source de la table fait SVE partie 1. . . . . . . . . . . . . . . . . . 63
5.24 Requête source de la table fait Sales Value Entry partie 2. . . . . . . . . . 64
5.25 Colonne dérivée de la table fait Sales Value Entry. . . . . . . . . . . . . . . 64
5.26 Conversion de données de la table fait Sales Value Entry. . . . . . . . . . . 65
5.27 Recherche de la clé primaire ItemID. . . . . . . . . . . . . . . . . . . . . . 65
5.28 Chargement de la table fait Sales Delivery. . . . . . . . . . . . . . . . . . . 66
5.29 Colonne dérivée de la table fait Sales Delivery. . . . . . . . . . . . . . . . . 66
5.30 Chargement de la table fait Sales Order State. . . . . . . . . . . . . . . . . 67
5.31 Colonne dérivée de la table fait Sales Order State. . . . . . . . . . . . . . . 67
5.32 Le package Main. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

page vii
 TABLE DES FIGURES

5.33 Architecture globale de notre application Power BI. . . . . . . . . . . . . . 69

5.34 Exemple d’un tableau de bord. . . . . . . . . . . . . . . . . . . . . . . . . 69
5.35 L’obtention des tables de la base DWH. . . . . . . . . . . . . . . . . . . . . 70
5.36 Gestion des relations dans PowerBI. . . . . . . . . . . . . . . . . . . . . . . 71
5.37 Ecran d’accueil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.38 Ecran de la performance du produit. . . . . . . . . . . . . . . . . . . . . . 72
5.39 Ecran de la performance du produit filtré. . . . . . . . . . . . . . . . . . . 73
5.40 Ecran Détails Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.41 Ecran Détails Client filtré. . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.42 Ecran Fiche Commandes/Livraisons. . . . . . . . . . . . . . . . . . . . . . 76
5.43 Ecran Retour produit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.44 Ecran Retour produit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.45 Ecran Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.46 Ecran Overview filtré. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

page viii
Liste des tableaux

2.1 Processus ETL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Différence entre une table de fait et une table de dimension. . . . . . . . . 18

3.1 Identification de cas d’utilisation. . . . . . . . . . . . . . . . . . . . . . . . 26

4.1 Choix des dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Identification de dimension Item. . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Identification de dimension Currency. . . . . . . . . . . . . . . . . . . . . . 30
4.4 Identification de dimension Activity. . . . . . . . . . . . . . . . . . . . . . 31
4.5 Identification de dimension Customer. . . . . . . . . . . . . . . . . . . . . . 31
4.6 Identification de dimension Site. . . . . . . . . . . . . . . . . . . . . . . . . 32
4.7 Identification de dimension Sales Person Purchaser. . . . . . . . . . . . . . 33
4.8 Identification de dimension Date. . . . . . . . . . . . . . . . . . . . . . . . 33
4.9 Identification de dimension Document Sales. . . . . . . . . . . . . . . . . . 34
4.10 Récapitulatif des indicateurs. . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.11 Identification de fait Ventes. . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.12 Identification de fait Commandes. . . . . . . . . . . . . . . . . . . . . . . . 38
4.13 Identification de fait Livraison. . . . . . . . . . . . . . . . . . . . . . . . . 41
4.14 Table des agrégations du tableau de bord de l’activité Ventes. . . . . . . . 47

ix
Liste des abréviations

IA : Intelligence Artificielle.
CC : Copie Carbone.
CCI : Copie Carbone Invisible.
BI : Business Intelligence.
2TUP : 2 track unified process.
IDE : Environnement de développement integré.
2TUP : 2 track unified process.
SQL : Structured Query Language.
SSIS : SQL Server Integration Services.
ETL : Extract, Transform, Load.
SI : Système d’information.
KPI : Key Performance Indicator.
SA : Staging Area.

x
Introduction générale

Les logiciels de gestion intégré et d’aide à la décision représentent un devis important

pour l’amélioration des performances des entreprises. Cependant les coûts d’acquisition
et de mise en place des solutions commercialisées par les acteurs majeurs du marché
demeurent très élevés.
Le recours à la BI a montré son efficacité d’aider les managers d’entreprises de toute
taille à prendre de meilleures décisions. il a montré sa primordialité dans les stratégies
d’encouragement et de mise à niveau de l’entreprenariat dans plusieurs pays. Pour cela,
l’usage des systèmes d’information et d’aide à la prise de décision est de plus en plus exigé.
Cependant face à la multiplication des sources d’informations, le volume de données col-
lectées croit progressivement et rend difficile d’organiser, d’exploiter ou de comprendre ce
qu’expriment ces informations : des tendances, des faiblesses ou forces cachées.
Dans leurs quêtes de compétitivités , les entreprises essaient de plus en plus d’exploiter
les informations dont elles disposent pour améliorer leurs prise de décision et à moindre
coût.
BMC est le leader sur le marché tunisien et acteur majeur de BI, elle permet aux en-
treprises d’optimiser leurs performances grâce à des solutions BI. Ces solutions assure la
gestion des ventes pour des différentes activités et pour permettre aux clients d’avoir une
vision globale concernant leurs activités commerciales.
C’est dans cette perspective que s’insère notre projet intitulé ≪ Mise en place d’un
tableau de bord pour le suivi des ventes ≫ qui consiste à mettre en place un système
décisionnel dédié principalement pour le suivi des ventes de l’entreprise Tunisie Cables per-
mettant aux décideurs d’avoir une vue globale et synthétique sur l’ensemble des données.
Notre rapport sera subdivisé en 5 chapitres :
Chapitre 1 intitulé Cadre générale du projet : est dédié à la présentation de
l’organisme d’accueil ainsi que la présentation du projet.
Chapitre 2 qui présente l’ État de l’art et l’étude de l’existant
Chapitre 3 qui s’intitule Analyse et spécification des besoins se focalise à définir
la planification des tâches, les acteurs, les besoins fonction- nels et non fonctionnels.
Chapitre 4 sous le nom Conception détaillera la conception générale et le développement
de notre processus d’intégration des données.
Chapitre 5 : Réalisation : englobe la phase de restitution et d’analyse de données

1
 INTRODUCTION GÉNÉRALE

qui représente les différentes interfaces de nos tableaux de bord et le déploiement de notre
solution.
Une conclusion générale récapitulera tout le travail que l’on a réalisé et clôturera le
projet tout en exposant les acquis dont nous avons bénéficié ainsi que les perspectives
envisageables.

page 2
Chapitre 1

Cadre général du projet

Sommaire
1.1 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Présentation de l’organisation . . . . . . . . . . . . . . . . . . . 4
1.2.1 Présentation de BMC . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Présentation de l’organisme client . . . . . . . . . . . . . . . . 5
1.3 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Méthodologie adoptée de conduite de projet . . . . . . . . . . 8
1.4.1 Approches agiles vs. Classiques . . . . . . . . . . . . . . . . . . 8
1.4.2 Choix de la méthodologie . . . . . . . . . . . . . . . . . . . . . 9
1.5 Environnement de développement . . . . . . . . . . . . . . . 10
1.5.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . 10
1.5.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . 11

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

Introduction
Ce chapitre vise à placer le projet dans son environnement organisationnel et contex-
tuel. Nous commençons par présenter l’organisme d’accueil “BMC” et ses différentes acti-
vités. Ensuite, nous exposons le contexte du projet. Puis, la méthodologie qui a conduit à la
réalisation de notre projet. Nous finissons par présenter l’environnement de développement
de ce projet.

1.1 Cadre du projet

Dans le cadre de mon projet de fin d’étude, pour l’obtention de la licence fondamentale
en Informatique de gestion (business intelligence) à faculté des sciences économiques et
de gestion de Tunis j’ai achevé un stage de trois mois au sein de la société Business
and Management Consulting (BMC). Mon projet consiste à conception et développer un
système d’information d’aide à la décision pour la société tunisienne “Tunisie Câbles”.

1.2 Présentation de l’organisation

1.2.1 Présentation de BMC
BMC : Business and Management Consulting est fondée en 2001. Leader sur le marché
tunisien et acteur majeur de Business Intelligence, BMC permet aux entreprises d’opti-
miser leurs performances grâce à ses solutions. De plus, elle offre un service unique en
garantissant l’ensemble des services associés tels que le consulting, le support technique
et la formation. BMC capitalise plus de 20 ans d’expérience dans le domaine de la Busi-
ness Intelligence, elle demeure la première entreprise tunisienne à assurer entièrement la
mise en place de solutions décisionnelles.
La fiGURE 1.1 présente le logo de BMC.

Figure 1.1 – Logo BMC.

1.2.1.1 Les services de BMC

BMC offre une panoplie de services à haute valeur ajouté pour garantir la satisfaction
de ses clients.
• Le consulting : L’implémentation d’une solution BI choisie par le client en assurant
le consulting professionnel avant, pendant et après l’implémentation du logiciel

page 4
 CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

• le support technique face aux problèmes techniques rencontrés.

• Une formation : une gamme complète de formation en Business Intelligence adaptée
le mieux aux besoins pour accompagner dans l’analyse décisionnelle et l’exploration
des données. Deux à cinq jours de formation bien adaptées par des formateurs
hautement qualifiés et expérimentés.

1.2.1.2 Les technologies de BMC

La société BMC utilise plusieurs technologies à noter :

• Qlik
• Geo Qlik
• Tableau Software
• SAP Business Object
• Informatica
• sas
• Pivotal

1.2.2 Présentation de l’organisme client

Tunisie Câbles est Créée en 1978, grâce au joint-venture avec la société Teleco-Cavi
(Pirelli), devenue PRYSMIAN, TUNISIE CABLES est leader dans le secteur des câbles
d’énergie et de Télécommunication en Tunisie. Cette société emploie plus de 500 per-
sonnes, toutes hautement qualifiées, et réalise 65 de son chiffre d’affaires à l’exportation.
Pour réaliser ses objectifs, TUNISIE CABLES s’est dotée d’un système d’assurance qua-
lité, certifié ISO 9001 version 2015.
La FIGURE 1.2 rpésente le logo de Tunisie cables.

Figure 1.2 – Logo Tunisie Câbles.

La FIGURE 1.3 fiche d’identité de Tunisie cables.

page 5
 CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

Figure 1.3 – Fiche d’identité de la société Tunisie Câbles.

1.2.2.1 Les produits de Tunisie Câbles

La gamme de produits de TUNISIE CABLES, axée sur la diversité, respecte ainsi

toutes les normes internationales en vigueur, notamment les normes européennes CEI,
françaises NF, allemandes VDE et anglaises BS.
Gamme énergie :
• Câbles à usage domestique
• Câbles énergies et câbles à usage industriel
Gamme télécom :

• Câbles réseau téléphonique intérieur

• Câbles réseau extérieur
• Câbles de branchement abonnés
• Câbles réseau informatique
• Câbles d’instrumentation
• Câbles coaxiaux

page 6
 CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

1.3 Contexte du projet

Notre projet consiste à mettre en place un système d’information d’aide à la décision
qui couvre les domaines ventes (commandes et livraisons) de la société Tunisie Câbles. Au
sein de ce projet nous allons pratiquer nos connaissances acquises durant notre formation
tout en apprenant à s’intégrer dans la vie professionnelle. Le but de cette application
consiste à réaliser d’une manière complète et sécurisée un ensemble de tâches en faveur
de notre client Tunisie Cables.

1.3.1 Problématique
Tunisie câbles (TC) est un leader dans le secteur des câbles d’énergie et de Télé-
communication en Tunisie mais elle a besoin de certaines améliorations pour assurer le
bon fonctionnement et prendre les décisions les plus opportunes qui influeront grandement
sur la stratégie de la société. Ces décisions sont basées sur des informations fiables et
pertinentes, le problème est de savoir comment les identifier sous une masse considérable
de données.
Actuellement, en TC l’élaboration des rapports fait intervenir plusieurs intermédiaires.
À chaque fois il faudra exploiter des données sous format des fichiers EXCEL, CSV de
grandes tailles et en les traitants en utilisant le logiciel tableur Microsoft Excel. Il s’agit
là d’une procédure lourde et tout en sachant que les données ne sont pas à jour parfois
à cause des retards enregistrés. La procédure du reporting actuelle est manuelle et elle
connait des lenteurs qui n’arrangent pas les décideurs, ceux qui ont besoin d’informations
claires et fiables et dans des délais raisonnables pour assurer la bonne prise de décision.
En effet la gestion de la vente à partir de n’importe quel rapport représente une perte
pour la société. Pour éviter cela on doit palier ces problèmes et moderniser le système
décisionnel de Tunisie Cables.

1.3.2 Objectifs
Ce projet a pour but la mise en place d’un système d’information d’aide à la décision
pour remédier aux difficultés présentées dans la section précédente tout en conférant aux
décideurs un support fiable pour une meilleure prise de décision. Ainsi, ce projet a pour
but de réduire la durée globale de l’élaboration des rapports et de réduire aussi le nombre
d’intervenants lors de la production de rapports. Par conséquent, on offre aux décideurs
la possibilité de faire les analyses adéquates à base des informations fiables, cohérentes et
contiennent la logique business souhaités.

page 7
 CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

1.4 Méthodologie adoptée de conduite de projet

Les méthodologies de conduite de projet informatique désignent l’ensemble des compétences,
des outils et des connaissances appliquées pour atteindre des objectifs précis, il existe
différents types de méthodologies à suivre.
Entre la simplicité des unes et l’efficacité des autres, une étude comparative doit être faite
pour garantir le choix adéquat.

1.4.1 Approches agiles vs. Classiques

Les méthodes traditionnelles, ou dites classiques, se caractérisent par un enchaı̂nement
fixe et précis d’étapes prédéfinies et standards.
En effet, plus le projet avance, plus l’impact des risques augmente car il faut attendre
jusqu’à la fin du développement afin de passer à la phase de test. : il sera plus coûteux et
difficile de revenir en arrière lorsqu’on détecte une anomalie tardivement. Il est si évident
que les méthodes classiques ne conviennent pas aux nécessités évolutives d’un projet BI
car on veut éviter l’impact des risques détectés tardivement.
En revanche, Une méthode Agile est une approche itérative et collaborative, capable de
prendre en compte les besoins initiaux du client et ceux liés aux évolutions. En effet, la
méthode Agile se base sur un cycle de développement qui rend le client impliqué dans la
réalisation du début jusqu’à la fin du projet : le client obtient une meilleure visibilité et
donne un feedback régulier [Har20].
Parmi ces méthodologies :
- Méthodologie lourde / Le processus unifié (UP) : Propose de dérouler les phases de
projet d’une manière séquentielle.
— RUP Rational Unified Process : Le RUP est à la fois une méthodologie et un outil pret
à l’emploi et Cible des projets de plus de 10 personnes.
— 2TUP Two Truck Unified Process : Propose un cycle de développement en Y et Cible
des projets de toutes tailles.
— XP eXtreme Programming : est un ensemble de ≪ bests practices≫ de développement
et Cible des projets de moins de 10 personnes.
— Scrum : Se base sur des itérations dites spirales de développement.

page 8
 CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

Figure 1.4 – Méthode classique vs Méthode Agile.

1.4.2 Choix de la méthodologie

Suite à l’étude et à la comparaison des principaux processus de développement et afin
de contrôler les risques et de mener à bon terme notre projet, nous avons opté pour le
processus 2TUP.
En effet, 2TUP donne une grande importance à la technologie technique ce qui est
important pour notre projet.

Figure 1.5 – Méthodologie 2TUP.

la méthodologie 2TUP est composée essentiellement de trois étapes :

page 9
 CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

• - La branche fonctionnelle :
Cette branche comporte les étapes suivantes :
— - La capture des besoins fonctionnels. Cette étape élimine le risque d’avoir un
système inadapté aux besoins des utilisateurs.
— - La capture des besoins non fonctionnels.
— - L’analyse qui consiste à étudier les besoins fonctionnels de manière à obtenir
une idée de ce que va réaliser le système en terme métier.
• La branche technique :
Cette branche comporte les étapes suivantes :
— - La capture des besoins techniques.
— - La conception générique.
• La branche réalisation :
A l’issue des évolutions du modèle fonctionnel et de l’architecture technique, la
réalisation du système consiste à fusionner les résultats de deux branches. Cette
fusion conduit à l’obtention d’un processus en forme Y.
Cette branche comporte les étapes suivantes :
— - La conception préliminaire.
— - La conception détaillée.
— - Le codage.
— - L’intégration.

1.5 Environnement de développement

Pour bien réaliser un projet, il faut utiliser des outils matériaux et des logiciels
adéquats.

1.5.1 Environnement matériel

Nous avons utilisé un ordinateur portable Acer Extensa 5535G ayant les caractéristiques
suivantes :
• Processeur : Intel(R) Core(TM)2 Duo CPU T6570 @ 2.10GHz 2.10 GHz
• Système d’exploitation : Windows 10 professionnelle
• Mémoire vive : 4 GO RAM

page 10
 CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

1.5.2 Environnement logiciel

Après avoir présenté les moyens matériels mis à notre disposition dans le cadre de
réalisation de ce projet, nous abordons dans cette sous-section l’environnement logiciel
utilisé.
Diagram.net : Diagram.net est un logiciel de dessin graphique gratuit et open source
développée en HTML5 et JavaScript. Son interface peut être utilisée pour créer des
différents diagrammes.
La FIGURE 1.6 présente le logo de Diagram.net.

Figure 1.6 – Logo Diagram.net.

Overleaf : c’est une plateforme en ligne gratuite permettant d’éditer du texte en

LATEX sans aucun téléchargement d’application. En outre, elle offre la possibilité de
rédiger des documents de manière collaborative, de proposer ses documents directement
à différents éditeurs (IEEE Journal, Springer, etc.) ou plateformes d’archives ouvertes
(arXiv, engrxiv, etc.) pour une éventuelle publication.
Cette plateforme est très compatible avec différents supports tels que tablettes et
smartphones [Bas16].
La FIGURE 1.7 présente le logo d’overleaf.

Figure 1.7 – Logo Overleaf.

Microsoft Visual studio 2019 : Microsoft Visual Studio 2019 Professional Edition
est environnement de développement intégré (IDE) qui permettent aux développeurs de
développer des programmes informatiques, ainsi que des sites Web, des applications Web,
des services Web et des applications mobiles[Ja22a].
La FIGURE 1.8 présente le logo Microsoft Visual studio.

page 11
 CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

Figure 1.8 – Logo Microsoft Visual studio .

SQL Server 2019 : Microsoft SQL Server est un système de gestion de base de
données relationnelle Développé par Microsoft. Son rôle est de stocker et de récupérer des
données à la demande d’autres applications logicielles[MM14].
La FIGURE 1.9 présente le logo SQL Server.

Figure 1.9 – Logo SQL Server.

SQL Server Integration Services : SSIS est un composent (package) du logiciel

Microsoft SQL server utilisé pour effectuer un large éventail de tâches d’intégration des
données et les applications de flux de travail. Cet outil est utilisé également pour l’ex-
traction, la transformation et le chargement des données (ETL) et les mises à jour des
données de cube multidimensionnelles [Ja22b].
La FIGURE 1.10 présente le logo de SQL Server Integration Services.

Figure 1.10 – Logo SQL Server Integration Services.

SQL Server Management Studio : SSMS est une application utilisée pour confi-
gurer, gérer via des bases de données et des entrepôts de données et administrer tous les
composants de Microsoft SQL Server [Gab06].
La FIGURE 1.11 présente le logo de SQL Server Management Studio.

page 12
 CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

Figure 1.11 – Logo SQL Server Management Studio.

Microsoft Power BI : Power BI est un logiciel de visualisation de données interactif

qui transforme des sources de données non liées en informations cohérentes, visuellement
immersives et interactives pour aider à la prise de la décision [San21].
La FIGURE 1.12 présente le logo de Microsoft Power BI.

Figure 1.12 – Logo Microsoft Power BI.

Conclusion
Ce chapitre, nous a permis d’avoir une vision plus claire sur notre projet. Nous avons
présenté l’organisme accueillant et l’organisme client. Nous avons mis l’accent sur le
contexte général sur lequel se déroule ce projet et révélé la méthodologie de conception
qui sera utilisée. Enfin, nous avons exposé l’environnement du développement qui nous a
servi pour la réalisation de notre système d’aide à la décision.

page 13
Chapitre 2

État de l’art et Étude de l’existant

Sommaire
2.1 L’état de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Le concept décisionnel . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.2 ETL “ Extract - Transform - Load “ . . . . . . . . . . . . . . . 16
2.1.3 Entrepôt de données “ Data Warehouse “ . . . . . . . . . . . . 16
2.1.4 Modélisation multidimensionnelle . . . . . . . . . . . . . . . . 18
2.1.5 Restitution des données . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.1 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.2 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . 22

14
 CHAPITRE 2. ÉTAT DE L’ART ET ÉTUDE DE L’EXISTANT

Introduction
Dans ce chapitre, nous allons commencer par une étude préalable du système décisionnel,
son processus, son architecture et ses différents concepts de base, ainsi que les diverses no-
tions relatives à la BI. Ensuite, nous allons aborder les phases de spécification des besoins
en définissant les acteurs de notre système, les besoins fonctionnels et non fonctionnels.
Enfin nous allos présenter le backlog product et la planification en sprints des user stories.

2.1 L’état de l’art

2.1.1 Le concept décisionnel
2.1.1.1 Définition d’un système décisionnel

Les systèmes décisionnels représentent l’ensemble des outils et méthodes qui per-
mettent à l’entreprise d’analyser, collecter, stocker et restituer les nombreuses données
qui proviennent de diverses sources afin de fournir une véritable aide à la prise de décision.
La mise en place d’un système décisionnelle informatisé au sein de l’entreprise est nécessaire
pour définir les concepts clés autour du décisionnel.
Les décideurs peuvent disposer des informations appropriées, effectuer les analyses utiles
de leurs entreprises et prendre des décisions adaptées grâce aux outils de l’informatique
décisionnelle[Guy21].

2.1.1.2 Architecture d’un système décisionnel

Le processus de l’architecture du système décisionnel comprend 4 phases présentées

dans la FIGURE ...

Figure 2.1 – Les phases d’un système décisionnel.

page 15
 CHAPITRE 2. ÉTAT DE L’ART ET ÉTUDE DE L’EXISTANT

2.1.2 ETL “ Extract - Transform - Load “

Chaque projet décisionnel commence par La collecte des données, ces données sont
hétérogènes et peuvent être de différentes sources tels que les fichiers plats (TXT, CSV,
EXCEL, XML) ou des bases de données SQL.
Le processus ETL (Extract, Transform, Load) ou extraire, transformer, charger est La
première phase des projets décisionnels où on effectue l’extraction et les traitements sur
les données. Les données en sortie seront nettoyées, harmonisées et transformées sous une
forme adaptée aux analyses, et prêtes à être chargées dans l’entrepôt.

Table 2.1 – Processus ETL.

Extraction Transformation Chargement

Identification des données - Le nettoyage des données Chargement initial (charge-
de différentes sources. non pertinentes : filtrage et ment de toutes les données
triage des données, suppres- pour ne pas les perdre)
sion des informations dou-
blons...
Extraction des données - Le reformatage et la Chargement incrémentiel
nécessaires et les orienter standardisation des données (ajout des nouvelles
vers le système décisionnel. converties. données à l’entrepôt
existant).

ETL est plus qu’un simple flux de données. Il a le pouvoir d’automatiser le processus
de la conversion, le reformatage et l’intégration des données provenant de plusieurs sources
opérationnelles en informations utilisables.

Figure 2.2 – Processus ETL.

2.1.3 Entrepôt de données “ Data Warehouse “

Les sources des données d’une entreprise proviennent essentiellement des différentes
bases de production. Les données sont éparpillées dans des systèmes multiples, pas nécessair-
ement compatible entre eux, ces bases sont conçues d’être efficaces pour les fonctions sur
lesquelles elles sont spécialisées. Ces sources de données sont peu adaptées pour une ana-
lyse de prise à a décision. Le Data Warehouse va avoir pour objectif d’agréger ces données
provenant de différentes sources, elle va permettre à l’utilisateur d’y accéder de manière
simple et ergonomique. Une base de données utilisée pour collecter et stocker des informa-
tions provenant d’autres bases de données dans le cadre de prise de décisions .Les bases de

page 16
 CHAPITRE 2. ÉTAT DE L’ART ET ÉTUDE DE L’EXISTANT

données opérationnelles sont collectées , transformées et chargées dans la Data Warehouse

via l’outil ETL (Extract Transform Load)[MUS11].

2.1.3.1 Caractéristiques d’un entrepôt de données

“ le Data Warehouse est une collection de données orientées sujet, intégrées, non
volatiles et évolutives dans le temps, organisées pour le support d’un processus d’aide à
la décision. “ Inmon 2002 – ” Building the Data Warehouse “
• Orienté sujet : Ce qui signifie qu’il doit être organisé et déployé spécialement pour
analyser les données liées à un sujet spécifié pour l’entreprise tels que : ventes, achats,
produits . . .
• Intégré : L’intégration des données de différentes sources dans un format consistant
(gestion des noms et des incohérences).
• Non-Volatiles : Une fois qu’une donnée est entrée dans l’entrepôt de données ne peut
pas être mise à jour ou supprimée, elle est traitée telle qu’elle a été stockée.
• Évolutive dans le temps (time-variant) : Le suivi de l’évolution et les changements
des valeurs dans le temps.
• Organisé pour le support d’un processus d’aide à la décision.

2.1.3.2 Objectifs

- Centraliser et faire converger les données.

- Faciliter l’accès à l’information.
- Prendre les décisions à partir des données cohérentes.

2.1.3.3 Magasin de données ”DATAMART”

Figure 2.3 – Différence entre un Datamart et un Datawarehouse.

page 17
 CHAPITRE 2. ÉTAT DE L’ART ET ÉTUDE DE L’EXISTANT

Appelé aussi “ magasin de données ”, c’est un extrait d’un Data Warehouse mais
orienté métier qui se focalise sur les données d’un seul département spécifique dans l’en-
treprise. Selon Ralph Kimball : “ Le DataMart est un sous-ensemble du Data Warehouse,
constitué de tables au niveau détail et à des niveaux plus agrégés, permettant de restituer
tout le spectre d’une activité métier. L’ensemble des DataMarts de l’entreprise constitue
le Data Warehouse “.

2.1.4 Modélisation multidimensionnelle

La modélisation multidimensionnelle consiste à considérer les données à analyser comme
un point dans un espace à plusieurs dimensions. Ces données sont organisées en mettant en
évidence le sujet et les différentes perspectives de l’analyse. Un Modèle multidimensionnel
se compose d’une table centrale appelée table de faits et d’autres tables auxiliaires ap-
pelées tables de dimensions. Pour bien comprendre la modélisation multidimensionnelle,
on va définir ses composants :
• Table des faits : une table qui contient les mesures d’un sujet que l’on veut étudier,
qui sont associées aux divers axes d’analyse (les dimensions). Une table de faits as-
sure les liens plusieurs à plusieurs entre les dimensions et comporte les clés étrangères,
elles peuvent aussi contenir aucun attribut que les liaisons entre les dimensions.
• Table de dimensions : une table de dimensions contient les attributs qui représentent
les dimensions selon lesquels on veut étudier les faits. Une table de dimension doit
contenir une clé primaire et d’autres attributs.

Table 2.2 – Différence entre une table de fait et une table de dimension.

Table de fait Table de dimension

Clé primaire Elle contient une clé primaire qui Elle contient sa clé primaire.
est une concaténation de clés pri-
maires de toutes les tables de di-
mensions.
Description Elle contient les attributs d’une Elle contient les attributs avec
table de dimension. lesquels la table de faits calcule
la métrique.
Taille Elle se développe verticalement. Elle se développe horizontale-
ment.
Attributs Elle contient moins d’attributs et Elle contient plus d’attributs et
plus d’enregistrements. Ces at- moins d’enregistrements. Ces at-
tributs peuvent être au format tributs peuvent être des attributs
numérique et au format textuel. au format textuel.
Création Elle peut être créée uniquement Elle doit être crée en premier.
lorsque les tables de dimensions
sont complétées.

page 18
 CHAPITRE 2. ÉTAT DE L’ART ET ÉTUDE DE L’EXISTANT

2.1.4.1 Types de modèles dimensionnels

La modélisation dimensionnelle est une technique de conception logique d’entrepôts

des données qui consiste à organiser les données sous la forme d’une structure divisée en
table de fait et de dimensions. Il existe 3 types de modèles dimensionnels très connus qui
sont :
a. Modèle en étoile :
Initié par Ralph Kimball, ce modèle se représente en une table de fait qui représente le
processus métier et reliée aux tables de dimensions qui symbolisent les axes d’analyse du
processus.

Figure 2.4 – Modèle en étoile.

Avantages :
• Simplicité et performances des requêtes.
• Performances et administration du chargement.
• Parcours efficace des données.
• Intégrité référentielle intégrée.
• Jointures faciles.
Inconvénients :
• Redondances dans les dimensions.
• Alimentation complexe.
b. Modèle en flocon de neige :
Le schéma en flocons de neige est une variante du schéma en étoile, mais il existe une plus
grande hiérarchisation des dimensions. Il est utilisé lorsque l’on a besoin d’une plus grande
flexibilité dans la corrélation à travers les niveaux et les composantes d’une dimension.

page 19
 CHAPITRE 2. ÉTAT DE L’ART ET ÉTUDE DE L’EXISTANT

Figure 2.5 – Modèle en flocon de neige.

Avantages :
• Flexibilité dans les données.
• Réduction du volume.
• Maintenance simplifiée des tables de dimensions.
Inconvénients :
• Plusieurs jointures.
• Navigation difficile.
c. Modèle en constellations :
Ce modèle est un ensemble de schémas en étoile et /ou en flocons. Il contient plusieurs
tables de faits qui partagent de nombreuses tables de dimension.

Figure 2.6 – Modèle en constellation.

Avantages :
• Meilleure gestion des données.
Inconvénients :
• Complexité du modèle.
Dans le cadre de notre projet, on a choisi comme type de modèle décisionnel le schéma
en étoile et ceci grâce à la faible complexité de ses requêtes et le nombre réduit de ses
jointures engendrant un temps d’exécution des requêtes réduit et une compréhension
simple et rapide.

page 20
 CHAPITRE 2. ÉTAT DE L’ART ET ÉTUDE DE L’EXISTANT

2.1.5 Restitution des données

Une fois que les données sont chargées au niveau de la Data Warehouse et affinées selon
différentes vues, l’étape suivante est la restitution. La restitution des données couvre tous
les outils, mis à la disposition des décideurs, se chargent de présenter les informations de
la façon la plus lisible afin de générer des rapports ou des tableaux de bord.

2.1.5.1 Le reporting

Après la collecte et l’analyse des données importantes et qui proviennent de différentes

sources de qualité, on les rassemble en un seul et même rapport bien défini et simple
d’analyse, suite à lui la décision adéquate va être prise[Rot12].
Le reporting permet de :
• Trier, regrouper ou répartir les données selon les critères de choix du gestionnaire.
• Sélectionner les données relatives à telle période, tel secteur . . .
• Réaliser divers calculs (totaux, moyennes, écarts...).
• Présenter les résultats d’une manière synthétique ou détaillée, le plus souvent gra-
phique selon les besoins du gestionnaire.

2.1.5.2 Tableau de bord (Dashboard)

Un tableau de bord est un outil d’aide à la décision qui présente les activités et les
résultats de l’entreprise par processus, sous forme d’indicateurs afin de contrôler et réaliser
les buts fixés et de prendre des décisions fiables selon des critères et des délais choisis par
les responsables. Un Dashboard permet aux décideurs d’identifier les écarts, il constitue
un outil de motivation dans l’entreprise puisque son but est de réaliser les objectifs de la
démarche stratégique et réduire l’incertitude et les risques.

2.2 Analyse de l’existant

Aujourd’hui, il est devenu de plus en plus crucial d’accompagner l’activité de base
d’une entreprise par l’informatique décisionnelle qui l’aidera à mieux analyser ses données
et prendre des décisions stratégiques. Pour cela, la direction des systèmes d’information
de Tunisie Câbles a voulu de mettre en place un système d‘aide à la décision pour bien
gérer les activités métiers de l’entreprise : la vente (commandes et livraisons). Les produits
achetés,fabriqués et vendus, les fournisseurs, les clients, les commandes, les livraisons et les
chiffres réalisés et bien d’autres informations permettant d’apporter l’aide et l’assistance
lors du processus de prise de décision. Cette grande masse de données est stockée dans
des documents Excel afin de les traduire en des tableaux de bord permettant de tracer
les indicateurs relatifs à une activité précise et pour des périodes différentes.

page 21
 CHAPITRE 2. ÉTAT DE L’ART ET ÉTUDE DE L’EXISTANT

2.2.1 Critique de l’existant

Cependant, en Tunisie câbles, on peut seulement que créer, modifier et enregistrer
les mouvements des ventes et d’achat de la société. Puisqu’il n’y en a pas d’un système
décisionnel qui collecte les données sources nécessaires pour le reporting, la société est
pourvue d’un climat décisionnel sain et les décideurs se trouvent dans l’incapacité de faire
des analyses fiables et efficaces aux moments opportuns. En conséquence, l’élaboration
des rapports fait intervenir plusieurs intermédiaires et l’extraction manuelle des données
tout en se basant sur des fichiers Excel est une procédure lourde et contient une marge
élevée d’erreurs.

2.2.2 Solution proposée

En réponse à toutes ces complications et dans le but de renforcer la présence du BI au
sein de notre client Tunisie Câbles, nous nous proposons de mettre en place un système
d’aide à la décision en réalisant un rapport qui récapitule l’ensemble de l’activité de l’achat
et de la vente. Pour le faire nous allons :
• Collecter les données nécessaires depuis les systèmes sources.
• Stocker ces données dans une base de données intermédiaire .
• Effectuer les opérations d’extraction, de transformation et de chargement dans l’en-
trepot de données.
• Analyser les résultats obtenus et les KPI.
• Mettre en place les rapports souhaités.

Conclusion
Dans ce chapitre nous avons nous avons mis un projet décisionnel dans son contexte :
sa définition, ses notions et ses concepts de base. Puis, nous avons abordé l’étude de
l’existant où on a acquis une idée englobante grâce à une analyse et une critique de
l’existant, ce qui nous a permis, au final, d’introduire une solution proposée.

page 22
Chapitre 3

Analyse et Spécification des Besoins

Sommaire
3.1 Capture de besoins . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . 24
3.1.2 Identification des besoins non fonctionnels . . . . . . . . . . . . 24
3.2 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . 25
3.2.1 Identification de cas d’utilisation . . . . . . . . . . . . . . . . . 26

23
 CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS

Introduction

3.1 Capture de besoins

Cette étape présente l’identification des acteurs et l’identification des besoins fonction-
nels et non fonctionnels identifiés par notre client pour mettre en avant les contraintes,
les risques et tout autre élément pertinent afin d’assurer le bon déroulement du projet et
garantir les besoins du client.

3.1.1 Identification des acteurs

Notre projet comporte 2 acteurs principales qui vont interagir directement avec le
système qui sont : le décideur et l’administrateur.
• Le décideur : qui peut gérer les tableaux de bord et consulter les rapports après
qu’il s’authentifie.
• L’administrateur : qui, en plus les mêmes fonctionnalités que le décideur, il gère les
utilisateurs et les droits d’accès.

3.1.2 Identification des besoins non fonctionnels

3.1.2.1 Les besoins fonctionnels

Les besoins fonctionnels ou les besoins métiers sont les tâches que notre système doit
exécuter. Le besoin principal de notre client est l’intégration du BI au sein de l’entreprise
pour bien gérer les ventes et les achats de Tunisie Câbles.
Ce projet BI nécessite la mise en place d’un entrepôt de données qui stocke automati-
quement et les données relatives aux ventes. Ensuite, la création des tableaux de bord
qui vont permettre aux décideurs de la société Tunisie Câbles d’avoir une vue globale sur
l’activité de vente.
les axes d’analyse de notre tableau de bord et sur lesquels nos besoins sont axés sont les
suivants : (Les produits, les clients, la vente, le temps, les commandes et les livraisons).
Ci-dessous nous illustrons les besoins fonctionnels de notre application :
— Le total des ventes nettes.
— Le total des ventes brutes.
— Le profit total.
— Le total des commandes.
— Les quantités commandées et livrées et le taux de retour du produit.
— Capturer Les produits les plus vendus.
— Déterminer Les top 5 catégories vendus.

page 24
 CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS

— Déterminer le nombre total des clients et des nouveaux clients.

— La variation temporelle des coûts et des profits.

3.1.2.2 Les besoins non fonctionnels

Les besoins non fonctionnels décrivent toutes les contraintes que notre application doit
respecter. Ils sont généralement des contraintes de performance, de sécurité, de fiabilité,
d’utilisabilité ou encore de maintenance :
— Besoins de performance : La solution doit répondre à toutes les exigences des
décideurs d’une façon optimale.
— Besoins de fiabilité : Le contenu exploité doit être soumis à des transformations et
des vérifications garantissant leur fiabilité et qualité.
— Besoins d’utilisabilité : la nécessité d’offrir une architecture BI aux entreprises qui
le manquent (un datawarehouse et des tableaux de bord compréhensible).
— Besoins de maintenance : L’application doit être facile au niveau du maintien et
assure la rapidité du processus pour qu’il s’approche le plus possible du temps réel.

3.2 Diagramme de cas d’utilisation global

Après avoir présenté les besoins fonctionnels et non fonctionnels et les acteurs on
va décrire le comportement de notre solution ainsi que les principales fonctionnalités du
système.

Figure 3.1 – Diagramme de cas d’utilisation global.

page 25
 CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS

3.2.1 Identification de cas d’utilisation

Nous allons identifier les différents cas d’utilisation réalisés par le système :

Table 3.1 – Identification de cas d’utilisation.

Cas d’utilisation Acteur(s) Description

Consulter les tableaux Décideur et administrateur Créer, modifier ou suppri-
de bord. mer les tableaux de bord.
visualiser et consulter Décideur et administrateur Consulter les tableaux de
les rapports. bord créés.
Gérer les utilisateurs Administrateur Filtrer les utilisateurs et at-
et les droits d’accès. tribuer les droits d’accès à
ces derniers.
S’authentifier Décideur et administrateur Tous les acteurs doivent
s’authentifier pour qu’ils
peuvent accéder au système
et exécuter leurs rôles.

Conclusion
Dans ce chapitre nous avons nous avons mis un projet décisionnel dans son contexte :
sa définition, ses notions et ses concepts de base.
Ainsi, nous avons identifié les acteurs, spécifier les besoins de notre système et présenté
le diagramme de cas d’utilisation global.

page 26
Chapitre 4

Conception

Sommaire
4.1 Conception du Data Warehouse . . . . . . . . . . . . . . . . . . 28
4.1.1 Présentation de l’activité ≪ Vente ≫ . . . . . . . . . . . . . . . 28
4.1.2 Choix des dimensions . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.3 Choix des indicateurs . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.4 Tables de faits . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.5 Structure du DataWarehouse . . . . . . . . . . . . . . . . . . . 42
4.2 Conception ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1 Etude de données . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.2 Extraction de données . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.3 Chargement des données SA . . . . . . . . . . . . . . . . . . . 45
4.2.4 Transformation des données . . . . . . . . . . . . . . . . . . . . 46
4.2.5 Chargement des données DWH . . . . . . . . . . . . . . . . . . 46
4.3 Conception du tableau de bord . . . . . . . . . . . . . . . . . . 46
4.3.1 Shéma du tableau du bord ≪ Suivi des ventes≫ . . . . . . . . . 46
4.3.2 Tables des agrégations . . . . . . . . . . . . . . . . . . . . . . . 47

27
 CHAPITRE 4. CONCEPTION

Introduction
Dans ce chapitre nous allons décrire en premier lieu les diverses étapes de la réalisation
d’un projet décisionnel en se basant sur le cycle de vie dimensionnel de Ralph Kimball,
nous nous concentrons durant ce chapitre définir une vision globale sur l’architecture
technique

4.1 Conception du Data Warehouse

La modélisation constitue la phase la plus importante pour la réussite d’un système
décisionnel. La conception d’un modèle dimensionnel passe par quatre étapes essentielles :
- Définition de l’activité à analyser.
- Choix des dimensions qui décrivent une ligne de table de faits.
- Choix des mesures ou des indicateurs.
- Choix du modèle dimensionnel.

4.1.1 Présentation de l’activité ≪ Vente ≫

Notre client Tunisie Câbles, fabriquant des Câbles éléctriques et téléphoniques, sou-
haite de mettre en place une solution récapitulant l’ensemble de l’activité de la ventes, les
commandes et les livraisons.

4.1.2 Choix des dimensions

Les dimensions correspondent aux axes d’analyse selon lesquels on veut étudier des
données qui donnent aux utilisateurs des renseignements nécessaires à la prise de décision.

Table 4.1 – Choix des dimensions .

Nom dimension Description dimension

Dimension Item Dimension Article
Dimension Currency Dimension Devise
Dimension Activity Dimension Activité
Dimension Customer Dimension Client
Dimension Site Dimension Site de ventes,
expédition
Dimension Sales Person Dimension Commercial,
Purchaser acheteur
Dimension Date Dimension Date
Dimension Document Sales Dimension des documents

page 28
 CHAPITRE 4. CONCEPTION

4.1.2.1 Dimension Item

Table 4.2 – Identification de dimension Item.

Attribut Description attribut

ItemID Identifiant Article(clé primaire auto-
incrément)
No Réference Article
Description Nom Article
NoDesc N° Article et Nom
CreationDate Date de Création Article
StartDate Date de début de vie
EndDate Date de Fin de vie
StatisticalFamily Famille Statistique
Status Statut Article
Type Type Article
PurchasePrice Prix d’Achat
StockUOM Unité de Mesure Stock
PurchaseUOM Unité de Mesure Achat
SalesUOM Unité de Mesure Vente
StatisticUOM Unité Statistique
WeightUOM Poids
VolumeUOM Volume
StandardCost Coût Standard
ItemCategoryCode Code Catégorie
ItemCategoryDesc Description Catégorie
ItemSubCategoryCode Code Sous Catégorie Article
ItemSubCategoryDesc Description sous Catégorie Article..

page 29
 CHAPITRE 4. CONCEPTION

Figure 4.1 – Dimension Item.

4.1.2.2 Dimension Currency

Table 4.3 – Identification de dimension Currency.

Attribut Description attribut

CurrencyID Identifiant Devise(clé pri-
maire auto-incrément)
Code Code Devise
Description Description Devise.

Figure 4.2 – Dimension Currency.

page 30
 CHAPITRE 4. CONCEPTION

4.1.2.3 Dimension Activity

Table 4.4 – Identification de dimension Activity.

Attribut Description attribut

ActivityID Identifiant de l’activité(clé
primaire auto-incrément)
Code Code de l’activité
ActivityName Nom de l’activité.

Figure 4.3 – Dimension Activity.

4.1.2.4 Dimension Customer

Table 4.5 – Identification de dimension Customer.

Attribut Description attribut

CustomerID Identifiant Client(clé primaire
auto-incrément)
No Numéro client
ParentCustomerNo No client parent(holding)
PayerCustomerNo Client Payeur
Name Nom Client
ShortName Abréviation Client
CustomerCategoryCode Code Catégorie
CustomerCategoryName Nom Catégorie
CustomerGroupCode Code Group Client
CustomerGroupName Nom Group Client
CustomerType Type Client
CustomerSinceDate Date Client Active
CreationDate Date Création Client
CurrencyCode Code Devise Client
CustomerCountry Pays Client
CustomerRegion Région Client
SalesPersonCode Code Représentant
SalesPersonName Nom Représentant
AccountBalanceAmountLCY Solde comptable
AuthorizedOutstandingAmountLCY En-cours autorisé
CreditInsuranceAmountLCY Assurance-crédit
CustomerPortfolioAmount Portefeuille
OutstandingAmountLCY En-cours client
UnpostedInvoicesAmountLCY Factures non comptabilisées.

page 31
 CHAPITRE 4. CONCEPTION

Figure 4.4 – Dimension Customer.

4.1.2.5 Dimension Site

Table 4.6 – Identification de dimension Site.

Attribut Description attribut

SiteID Identifiant Site de
Ventes(clé primaire auto-
incrément)
SiteCode Code Site
SiteName Nom Site

Figure 4.5 – Dimension Site.

page 32
 CHAPITRE 4. CONCEPTION

4.1.2.6 Dimension Sales Person Purchaser

Table 4.7 – Identification de dimension Sales Person Purchaser.

Attribut Description attribut

SalesPersonPurchaseID Identifiant du
représentant(clé primaire
auto-incrément)
Code Code du représentant
Name Nom du représentant

Figure 4.6 – Dimension Site.

4.1.2.7 Dimension Date

La dimension date est essentielle dans chaque modèle dimensionnelle qui contient une
date ou qui requiert les informations sur la date dans le cadre de l’analyse, elle permet
d’analyser plus efficacement les performances sur différentes périodes de temps. Cette
table est créé à l’aide d’un script sur sql server management studio.

Table 4.8 – Identification de dimension Date.

Attribut Description attribut

DateID Identifiant de la date(sous
forme aaaammjj)
Date date
NumJoursemaine numéro de jours (se-
maine/mois/année)
Trimestre trimestre
Semestre semestre
Annee année
Weekend weekend..

page 33
 CHAPITRE 4. CONCEPTION

Figure 4.7 – Dimension Date.

4.1.2.8 Dimension Document Sales

Table 4.9 – Identification de dimension Document Sales.

Attribut Description attribut

DocumentSalesID Identifiant document(clé primaire
auto-incrément)
DocumentNo Numéro du document
PostingDate Date comptable du document
DocumentType Type de document
(Avoir/Vente/Livraison/Commandes)
DocumentTypeDesc Description du document (Document
de vente/Document avoir/Document
Livraison/Document de commandes )

Figure 4.8 – Dimension Document Sales.

page 34
 CHAPITRE 4. CONCEPTION

4.1.3 Choix des indicateurs

un KPI, pour ’Key Performance Indicator’, indicateur de performance en français,
est une valeur mesurable nécessaire permet de piloter une activité, démontrer l’efficacité
avec laquelle une entreprise atteint les objectifs commerciaux clés et prendre la meilleure
décision stratégique. Dans le cadre de notre projet, nous avons dégagés ces indicateurs
lors de la phase de capture des besoins exprimés par notre clients Tunisie Câbles.
Ces KPIs se présentent comme suit :

Table 4.10 – Récapitulatif des indicateurs.

Indicateurs Description Régle technique

Chiffre d’affaire Net Le montant total des ventes Somme(Montant Net des ventes)
Net
Chiffre d’affaire Brut Le montant total des ventes Somme(Montant Brut des ventes)
Brut
Montant profit le montant du profit final Somme (ventes nettes) - somme
(coûts)
Montant commandé le montant total net des somme(Montant Net des ventes
ventes facturés Commandes)
Montant livré le montant total net des somme(Montant Net des ventes
ventes livrés Livraisons)
Quantité commandée le montant total net des somme(Quantité Commandée en
ventes facturés Tonne)
Quantité Facturés le montant total net des somme(Montant Net des ventes)
ventes facturés
Quantité livré le montant total net des somme(Quantité Livrée en
ventes livrés Tonne)
Remises les remuses effectués somme(le montant de ventes brut
- le montant de vente net)

4.1.4 Tables de faits

La table de faits sert à stocker les mesures de l’activité. Chacune de ces mesures
est prise à l’intersection de toutes les dimensions c’est-à-dire la table de fait contient
l’ensemble des mesures correspondant aux informations de l’activité à analyser. Dans
notre cas, on a 3 tables de fait :
— Sales Value Entry : Fait vente
— Sales Order State : Fait commandes
— Sales Delivery : Fait livraisons

page 35
 CHAPITRE 4. CONCEPTION

4.1.4.1 Fait Sales Value Entry

Table 4.11 – Identification de fait Ventes.

Attributs Nature attribut Description attribut

InvoiceDateID Clé étrangère Identifiant Date facture
ItemID Clé étrangère Identifiant article
PostingDateID Clé étrangère Identifiant Date Livraison
SalespersonPurchaser Clé étrangère Identifiant Représentant
ID
ActivityID Clé étrangère Identifiant Activité
CurrencyID Clé étrangère Identifiant Devise
CustomerID Clé étrangère Identifiant Client
SellSiteID Clé étrangère Identifiant Site de vente
ShippmentSiteID Clé étrangère Identifiant Site d’expédition
InvoiceType Type facture
InvoicedQuantityT Quantité facturée en Tonne
InvoicedQuantityKm Quantité facturée en Km
GrossSalesAmount Montant vente Brut
GrossSalesAmount Montant vente Brut LCY (Devise
LCY locale)
NetSalesAmount Montant vente Net
NetSalesAmount LCY Montant vente Net LCY (Devise
locale)
DiscountAmount Montant Remise
DiscountAmountLCY Montant Remise LCY (Devise lo-
cale)
CostAmount Montant Cout
ProfitOrig Montant Profit
ConsignationAmount Montant consignation
LCY
DaysSalesOutstanding Délai moyen Paiement Client

page 36
 CHAPITRE 4. CONCEPTION

Figure 4.9 – Modèle physique de la table de fait Vente.

page 37
 CHAPITRE 4. CONCEPTION

4.1.4.2 Fait Sales Order State

Table 4.12 – Identification de fait Commandes.

Attributs Nature attribut Description attribut

SalesOrderDateID Clé étrangère Identifiant Date commande
ItemID Clé étrangère Identifiant article
DocumentSalesOrder Clé étrangère Identifiant document de com-
ID mande
SalespersonPurchaser Clé étrangère Identifiant Représentant
ID
ActivityID Clé étrangère Identifiant Activité
CurrencyID Clé étrangère Identifiant Devise
BillToCustomerID Clé étrangère Identifiant commandé à Client
OrderedByToCustomer Clé étrangère Identifiant commandé par client
ID
PayerCustomerID Clé étrangère Identifiant Client payant
SellSiteID Clé étrangère Identifiant Site de vente
ShippmentSiteID Clé étrangère Identifiant Site d’expédition
OrderLineNo Numéro Ligne de Commande
SequenceLineNo Numéro Séquence
RequestedDeliveryDate Date livraison demandée
PromisedDeliveryDate Date livraison prévue
DeliveryDate Date Livraison
ShippmentDate Date Expédition
LineStatus Statut ligne
OrderStauts Statut ligne commande
IsInvoiced Si la ligne est facturée
IsValidated Si la ligne est validée
LastInvoiceNo Numéro dernière Facture
LastInvoiceDate Date dernière Facture
LastDeliveryNo Numéro Dernière Livraison
LastDeliveryDate Date dernière Livraison
DeliveryNo Numéro document Livraison
DeliveryLineNo Numéro Ligne Livraison
SalesOrderQuantity Quantité Commandée en Tonne
SalesOrderQuantity Quantité Commandée Livrée en
Shipped Tonne
SalesOrderQuantity Quantité Commandée Facturée
Invoiced en Tonne
SalesOrderQuantity Quantité à Livrer en Tonne
ToShip
SalesOrderQuantity Quantiré à Facturer en Tonne
ToInvoice
SalesOrder Allocated- Quantité Allouée en Tonne
Quantity

page 38
 CHAPITRE 4. CONCEPTION

OnTimeRequested Nombre Livraison à Temps par

DeliveryDate rapport à la date de livraison de-
mandée
OnTimePromised De- Nombre Livraison à Temps par
liveryDate rapport à la date de livraison
Prévue
LateLineRequested Nombre Livraison en retard par
DeliveryDate rapport à la date de livraison de-
mandée
LateLinePromised Nombre Livraison en retard par
DeliveryDate rapport à la date de livraison
Prévue
DaysLateRequested Nombre jours de retard livraison
DeliveryDate par rapport à la date de livraison
demandée
DaysLatePromised Nombre jours de retard livraison
DeliveryDate par rapport à la date de livraison
Prévue
QtyOnTimeRequested Quantité livrée en Tonne à Temps
DeliveryDate par rapport à la date de livraison
demandée
QtyOnTimePromised Quantité livrée en Tonne à Temps
DeliveryDate par rapport à la date de livraison
Prévue
QtyLateRequested Quantité livrée en Tonne en re-
DeliveryDate tard par rapport à la date de li-
vraison demandée
QtyLatePromised De- Quantité livrée en Tonne en re-
liveryDate tard par rapport à la date de li-
vraison Prévue

page 39
 CHAPITRE 4. CONCEPTION

Figure 4.10 – Modèle physique de la table de fait Commande.

page 40
 CHAPITRE 4. CONCEPTION

4.1.4.3 Fait Sales Delivery

Table 4.13 – Identification de fait Livraison.

Attributs Nature attribut Description attribut

DeliveryDateID Clé étrangère Identifiant Date livraison
ShippmentDateID Clé étrangère Identifiant Date expédition
ItemID Clé étrangère Identifiant article
DocumentDeliveryID Clé étrangère Identifiant document de livraison
SalespersonPurchaser Clé étrangère Identifiant Représentant
ID
ActivityID Clé étrangère Identifiant Activité
CurrencyID Clé étrangère Identifiant Devise
BillToCustomerID Clé étrangère Identifiant commandé à Client
OrderedByToCustomer Clé étrangère Identifiant commandé par client
ID
PayerCustomerID Clé étrangère Identifiant Client payant
SellSiteID Clé étrangère Identifiant Site de vente
ShippmentSiteID Clé étrangère Identifiant Site d’expédition
InvoiceNo Numéro de Facture
OrderNo Numéro de Commande
IsInvoiced Si la livraison est facturée
IsValidated Si la livraison est Validée
DeliveryLineNo Numéro ligne de Livraison
OrderLineNo Numéro ligne de Commande
SequenceLineNo Numéro Séquence
DelivredQuantity Quantité Livrée en Tonne
ReturnedQuantity Quantité Retournée en Tonne
WeightUOM Unité de mesure Poids
VolumeUOM Unité de mesure Volume
GrossSalesAmount Montant des ventes brutes Devise
Facture
GrossSalesAmountLCY Montant des ventes brutes Devise
Locale
NetSalesAmount Montant des ventes Nette Devise
Facture
NetSalesAmountLCY Montant des ventes Nette Devise
Locale
DiscountAmount Remise Devise Facture
DiscountAmountLCY Remise Devise Locale

page 41
 CHAPITRE 4. CONCEPTION

Figure 4.11 – Modèle physique de la table de fait Livraison.

4.1.5 Structure du DataWarehouse

Nous avons choisi pour la réalisation du DataWarehouse le modèle en étoile, constitué
de la table de fait qui contient les clés primaires de tables de dimensions(générés automa-
tiquement par SSMS) et les mesures nécessaires pour la création des tableaux de bord et
les tables de dimensions.

4.2 Conception ETL

L’ETL, ou l’alimentation du Data Warehouse, est l’étape la plus importante, elle
représente 80% de la charge de la réalisation du projet. Cette étape a pour objectif de
recueiller les informations auprés de sources distantes en passant par les différentes phases
de nettoyage et de transformations nécessaires puis les charger dans l’entrepôt de données.
les étapes du processus d’alimentation sont les suivants :
• Etude des données sources en se basant sur les fichiers de Mapping.
• Extraction des données nécessaires.
• Chargement des données dans la zone de stockage intermédiaire de données (Staging
Area).
• Appliquer les transformations nécessaires.
• Chargement des données dans le DataWarehouse.

page 42
 CHAPITRE 4. CONCEPTION

4.2.1 Etude de données

Cette première étape consiste à étudier les données sources qui seront ensuite utilisées
pour alimenter le Data Warehouse. En effet, avant d’effectuer l’extraction de données, il
est nécessaire de bien connaitre leur contenu à l’aide des fichiers de Mapping.

4.2.1.1 Fichiers Sources

Nos données sources sont de type EXCEL et CSV. Ils sont enregistrés sous un dossier
nommé ≪ Data Source/Ventes ≫

Figure 4.12 – Dossier ≪ Ventes≫.

Chaque fichier est composé des colonnes, contenant les informations de chaque table
et des lignes contenant leurs valeurs correspondantes .Pour les fichiers de type CSV les

page 43
 CHAPITRE 4. CONCEPTION

colonnes sont séparées par un point-virgule ( ;) .

Figure 4.13 – Description du fichier BPARTNER≫.

≪

4.2.1.2 Fichiers de Mapping

Les fichiers de Mapping sont de type PDF contenant une description détaillée des
colonnes de chaque fichier sous le dossier ≪Description des tables TC≫.

Figure 4.14 – Dossier des fichiers de Mapping.

La figure 4.15 montre le fichier de mapping du fichier ≪BPARTNER≫.

page 44
 CHAPITRE 4. CONCEPTION

Figure 4.15 – Figure démonstrative du fichier de Mapping nommé ≪ BPARTNER≫.

4.2.2 Extraction de données

L’extraction des données est effectuée à partir des diverses sources de données décrites
dans l’étape précédente pour satisfaire le besoin du client. L’objectif de cette phase consiste
à récupérer les données pour appliquer les transformations nécessaires.

4.2.3 Chargement des données SA

C’est la phase d’alimenter la zone de stockage intermédiaire de données (Staging Area)
qui est une zone de stockage temporaire entre les sources de données et l’entrepôt de
données. Une fois les données chargées dans la SA, cette dernière est utilisée pour les
combiner afin de les transformer, les valider et les nettoyer avant de les charger dans le
DataWarehouse en un Shéma en étoile.

page 45
 CHAPITRE 4. CONCEPTION

4.2.4 Transformation des données

Cette étape est la plus importante elle permet de contrôler les données entrantes,
de les traiter, puis les transformer en des données fiables et pertinentes en vue de leur
intégration dans l’entrepôt de données. La partie de nettoyage consiste généralement à
remplacer les valeurs NULL par 0 ou d’appliquer des calculs sur des colonnes pour créer
d’autres nouvelles.

4.2.5 Chargement des données DWH

C’est la dernière phase d’alimentation de l’entrepôt de données. Le processus d’ali-
mentation commence par le chargement des dimensions, une fois les dimensions sont bien
chargées, on commence par charger les tables de faits. Ce processus se répéte quotidien-
nement chaque jour à minuit suite au déclenchement automatique du Main package.

4.3 Conception du tableau de bord

La restitution des données est la dernière étape de la chaı̂ne décisionnelle. Cette étape
consiste à présenter les informations à valeur ajoutée pour qu’elles s’apparaissent de la
façon la plus lisible possible dans le cadre de l’aide à la décision.
Dans notre cas, la création des tableaux de bord va aider les décideurs du Tunisie
Câbles à avoir une vue globale sur l’activité de la ventes et suivre également les commandes
et les livraisons au sein de la société.

4.3.1 Shéma du tableau du bord ≪Suivi des ventes≫

Notre tableau de bord est basé sur les principaux axes suivants : Produit, Client,Commandes,
Livraisons, Ventes et Temps comme le montre la Figure 4.16.

Figure 4.16 – Shéma du tableau de bord de l’activité Ventes.

page 46
 CHAPITRE 4. CONCEPTION

Nous pouvons utiliser un ou plusieurs axes qui seront représentés sous forme des ta-
bleaux et des graphiques, pour rendre facile aux décideurs le processus de la prise des
décisions.

4.3.2 Tables des agrégations

Table 4.14 – Table des agrégations du tableau de bord de l’activité Ventes.

Nom Description Formule

Profit total Le profit total des ventes de somme
tous les produits.
Total ventes brutes Le montant brut total de somme
vente de tous les produits.
Total remises Le montant total des re- somme
mises de tous les produits.
Total ventes nettes Le montant net total de somme(ventes brutes) -
vente de tous les produits. somme(remises)
Nombre de com- Le nombre total de com- somme
mandes par article mandes selon le nom d’ar-
ticle.
Nombre de com- Le nombre total de com- somme
mandes par client mandes selon le client.
Total crédit par client Le montant total des crédits somme
selon le client.
Taux de retour par Le nombre total de produits somme
produit retournée selon le produit.
Montant recu par ar- Le montant final recu par somme(ventes nettes) -
ticle commandé chaque article commandé. somme (montant produit
retourné)

La table des agrégations du tableau de bord du suivi des ventes a pour but d’agréger
les différentes mesures que l’on peut créer pour pouvoir juger les mouvements des ventes
selon quel client, quelle période du temps, quel produit et quelle catégorie du produit.

Conclusion
Nous avons consacré ce chapitre à la conception de l’entrepôt de données en présentant
l’activité principale puis en identifiant les diffirentes tables de dimensions et de faits grâce
à la modélisation dimensionnelle. Cette manière offre aux utilisateurs une représentation
compréhensible pour bien manipuler les données détaillées ou agrégées sans difficultés
selon leurs besoins d’analyse.

page 47
Chapitre 5

Réalisation

Sommaire
5.1 Architecture globale de l’application . . . . . . . . . . . . . . . 49
5.2 Réalisation de la phase ETL . . . . . . . . . . . . . . . . . . . . 49
5.2.1 Composants SSIS utilisés . . . . . . . . . . . . . . . . . . . . . 50
5.2.2 Préparation de l’environnement de l’ETL . . . . . . . . . . . . 52
5.2.3 Alimentation de Staging Area . . . . . . . . . . . . . . . . . . . 53
5.2.4 Alimentation de l’entrepôt de données . . . . . . . . . . . . . . 56
5.3 Réalisation du tableau de bord . . . . . . . . . . . . . . . . . . 69
5.3.1 Les interfaces du tableau de bord . . . . . . . . . . . . . . . . . 71

48
 CHAPITRE 5. RÉALISATION

Introduction
La dernière branche de la méthodologie suivie a pour objectif d’exposer la phase de
réalisation. Cette phase présente la concrétisation finale de toute la méthode de conception
tout en présentant la mise en place pratique de notre travail.

5.1 Architecture globale de l’application

Afin de réaliser un système décisionnel fiable et performant, il faut passer par deux
phases principales.
La première est la phase de l’extraction, la transformation et le chargement des données
dans le DataWarehouse à travers l’outil ETL VisualStudio et le package SSIS (Sql Server
Integration Services) instalée avec lui.
La deuxième et la dernière phase est la restitution (reporting), la plus visible par
l’utilisateur, se charge à la création des rapports et des tableaux de bord afin de présenter
le résultat synthétique ou détaillée et affiner l’analyse des données [Jos22].
Pour mieux comprendre le processus décisionnel suivi pour la mise en place de notre
solution, nous avons créé le schéma démonstratif suivant :

Figure 5.1 – Architecture globale de l’application.

5.2 Réalisation de la phase ETL

Dans cette partie nous allons présenter les composants SSIS utilisés dans Visual Studio
puis nous élaborons les étapes suivies pour l’implémentation ETL.

page 49
 CHAPITRE 5. RÉALISATION

5.2.1 Composants SSIS utilisés

- Package
le package SSIS est le composant central du code SQL Server Integration Services, et c’est
le canevas sur lequel vous passerez la majeure partie de votre temps de développement. Un
package SSIS est une collection d’une ou plusieurs opérations qui sont appelées ensemble
[kea20].
La premiére étape de tout projet SSIS est la création des packages qui est le milieu de
notre travail.
- Tâche de flux de données ou Data Flow Task
Une tâche permet d’encapsuler tout un traitement de données de la source, en passant par
la transformation jusqu’à la destination. Il est intéressant de diviser chaque traitement en
tâches pour une question d’organisation, de rapidité d’exécution et pour éviter le blocage
de l’exécution des autres tâches si une erreur survient lors de l’éxécution d’une tâche
spécifique.
- Exécuter une tâche SQL ou Execute SQL Task
La tâche Exécuter SQL exécute des instructions SQL ou des procédures stockées à partir
d’un package. La tâche peut contenir une seule instruction SQL ou plusieurs instructions
SQL qui s’exécutent séquentiellement. Vous pouvez utiliser la tâche Exécuter SQL aux
fins suivantes :
• Tronquez une table ou une vue en vue de l’insertion de données.
• Créez, modifiez et supprimez des objets de base de données tels que des tables et
des vues.
• Recréez des tables de faits et de dimensions avant d’y charger des données.
• Exécutez des procédures stockées. Si l’instruction SQL appelle une procédure stockée
qui renvoie les résultats d’une table temporaire, utilisez l’option WITH RESULT SETS
pour définir les métadonnées du jeu de résultats.
• Enregistrez l’ensemble de lignes renvoyé par une requête dans une variable.[MSF22]
- Fichier plat ou Flat file
Une source de fichier plat est un composant de flux de données qui utilise les métadonnées
définies par un gestionnaire de connexions de fichier plat pour spécifier le format et la
structure des données à extraire du fichier plat par un processus de transformation.
- Fichier Excel ou Excel file
Une source de fichier excel est un composant de flux de données qui utilise les métadonnées
définies par un gestionnaire de connexions de fichier excel pour spécifier le type et la
structure des données à extraire du fichier excel par un processus de transformation.
- Source OLE DB ou OLE DB source
La source OLE DB extrait les données d’une variété de bases de données relationnelles
compatibles OLE DB en utilisant une table de base de données, une vue ou une commande

page 50
 CHAPITRE 5. RÉALISATION

SQL. Par exemple, la source OLE DB peut extraire des données de tables dans des bases
de données Microsoft Office Access ou SQL Server [Olp21].
- Destination OLE DB ou OLE DB Destination
La destination OLE DB charge les données dans diverses bases de données compatibles
OLE DB à l’aide d’une table ou d’une vue de base de données ou d’une commande SQL.
Par exemple, la source OLE DB peut charger des données dans des tables de bases de
données Microsoft Office Access et SQL Server.
- Conversion de données ou Data conversion
La transformation synchrone est utilisée pour la conversion de données. Il s’agit d’une
fonction similaire aux fonctions Convert ou Cast de SQL. C’est une transformation très
utile si nous extrayons les mêmes données de plusieurs sources.
- Colonne dérivée ou Derived Column
Transformation synchrone, cette transformation crée une nouvelle colonne dérivée de la
sortie d’une autre colonne. Cette transformation vous offre deux options. Soit vous pouvez
créer une nouvelle colonne en tant que colonne dérivée ou remplacer la colonne existante
par une nouvelle colonne dérivée.
- Recherche ou Lookup
La transformation synchrone vous permet d’effectuer une équi-jointure entre les valeurs de
l’entrée de transformation et les valeurs de l’ensemble de données de référence, similaires
à SQL. Cette transformation est utilisée pour joindre deux jeux de données à la fois.
Pour joindre plus de deux jeux de données, nous devons placer plusieurs transformations
Lookup, similaires à une condition de jointure SQL [G21].
- Unir tout ou Union all
Une transformation de blocage partiel asynchrone vous permet de combiner plusieurs
entrées (plus de deux) et de générer une sortie. Il ajoute des entrées à la transformation
les unes après les autres et ne trie pas les données.
- Commande OLE DB ou OLE DB Command
La transformation de commande OLE DB exécute une instruction SQL pour chaque
ligne d’un flux de données. Par exemple, vous pouvez exécuter une instruction SQL qui
insère, met à jour ou supprime des lignes dans une table de base de données. Vous pouvez
configurer la transformation de commande OLE DB des manières suivantes :
• Fournissez l’instruction SQL que la transformation exécute pour chaque ligne.
• Spécifiez le nombre de secondes avant l’expiration de l’instruction SQL.
• Spécifiez la page de code par défaut.
- Dimension à variation lente ou Slowly changing dimension
Ce composant est utilisé pour insérer ou mettre à jour des enregistrements de données
dans des tables de dimension. Il compare les données source entrantes aux données de
table de dimension de destination existantes à l’aide d’une clé commerciale (clé unique).
Si aucun enregistrement ne correspond, il sera traité comme un nouvel enregistrement ou

page 51
 CHAPITRE 5. RÉALISATION

Si l’enregistrement des correspondances, il compare les attributs des attributs modifiés si

les données semblent actualisées, puis met à jour l’enregistrement ou, dans le cas contraire,
il reste tel quel.

5.2.2 Préparation de l’environnement de l’ETL

Avant de commencer l’ETL, il faut d’abord créer les bases de données à utiliser STG
(Staging Area) et DWH (DataWarehouse).
La Figure 5.2 montre les bases de données créées dans SQL Server Management Studio
(SSMS).

Figure 5.2 – Bases de données créées.

La premiére étape de l’ETL est de créer les packages SSIS.

La Figure 5.3 montre les packages SSIS créées dans Visual Studio.

Figure 5.3 – Pachages SSIS créées pour l’ETL.

page 52
 CHAPITRE 5. RÉALISATION

nous avons 4 packages :

- Main : le package qui assure l’exécution de tous les packages.
- STG : le package qui assure d’alimenter la base de donnée intermédiaire par les données
des fichiers sources.
- DimDWH : c’est le package où on va extraire les données de la base STG, les transformer,
et charger les dimensions de notre entrepôt de données.
- FactDWH : le package qui va charger les tables de faits de notre entrepôt de données.
La dernière étape de la préparation de notre environnement ETL est la création des
gestionnaires de connexions qui sera disponible pour tous les packages du projet.
Ces gestionnaire de connexion sont de type OLE DB et il vont établir la connexion à les
bases de données STG et DWH.
La Figure 5.4 montre les gestionnaires de connexions créées dans Visual Studio.

Figure 5.4 – Les gestionnaires de connexions créés.

5.2.3 Alimentation de Staging Area

Cette étape consiste à charger la base de données STG par les fichiers EXCEL et CSV
sources sans aucune transformation dans le package STG.
La Figure 5.5 montre le package STG.

page 53
 CHAPITRE 5. RÉALISATION

Figure 5.5 – Package STG.

Chaque tâche de flux de données présente le chargement d’un fichier source vers une
table dans la base de données STG.
La Figure 5.6 présente Le passage de données entre le fichier source de type CSV et
table BPARTNER dans STG.

Figure 5.6 – Exctraction de données d’un fichier CSV vers STG.

page 54
 CHAPITRE 5. RÉALISATION

La Figure 5.7 présente Le passage de données entre le fichier source de type EXCEL
et table BPCUSTMVT dans STG.

Figure 5.7 – Exctraction de données d’un fichier EXCEL vers STG.

Toutes les tâches de flux de données sont reliées entre elles à une tâche SQL qui
permet d’exécuter une requête SQL TRUNCATE TABLE qui va assurer la suppression
du contenu de toutes les tables lors de chaque exécution de ce package afin d’éviter la
redondonce et mettre à jour les données comme le montre la Figure 5.8.

Figure 5.8 – Tâche d’exécution de requête SQL.

page 55
 CHAPITRE 5. RÉALISATION

5.2.4 Alimentation de l’entrepôt de données

Cette phase consiste à extraire les données de la source STG, de faire les conversions
et les transformations des données nécessaires, de charger les tables de dimensions et de
faits et de faire des jointures entre les tables lorsque cela est nécessaire. Cette phase est
la plus critique de l’ETL.
Avant tout, il faut créer les tables de dimensions et de faits dans la base de données DWH
à l’aide de SQL Server Management Studio.

5.2.4.1 Chargement des dimensions

Les dimensions doivent être chargées avant les tables de fait (pour respecter l’intégration
des clés étrangères).
La Figure 5.9 montre Le package DimDWH qui assure le chargement des dimensions.

Figure 5.9 – Le package DimDWH.

Toutes les tâches servent à charger une dimension et elles sont reliées à une tâche
d’exécution d’une requête SQL qui va vider toutes les tables de dimensions dans la base
DWH aprés chaque exécution du package.
Prenant l’exemple de 3 tables de dimensions qui se charge de manière différente.

page 56
 CHAPITRE 5. RÉALISATION

•Chargement de la dimension Document Sales

Figure 5.10 – Le chargement de la dimension Document Sales.

Pour charger cette dimension nous avons uni 3 sources de données puis nous avons uti-
lisé le composant SSIS ’Dimension à variation lente’ qui est utilisé pour insérer un nouvel
(si aucun enregistrement ne correspond) ou mettre à jour les données des enregistrements
de données modifiés dans la table de dimension.
La Figure 5.11 suivante présente les requêtes SQL sources de Document Sales .

Figure 5.11 – Requêtes Sources de la dimension Document Sales.

page 57
 CHAPITRE 5. RÉALISATION

Maintenant on va présenter l’outil SSIS ≪UNIR TOUT≫ dans la Figure 5.12.

Figure 5.12 – Unir tout de la dimension Document Sales.

la dernière étape est le composant Dimension à variation lente, on va le montrer par

la Figure 5.13.

Figure 5.13 – Dimension à variation lente de la dimension Document Sales.

page 58
 CHAPITRE 5. RÉALISATION

• Chargement de la dimension Customer

Figure 5.14 – Le chargement de la dimension Customer.

La source OLE DB de la dimension Customer est une requête SQL comme le montre
Figure 5.15

Figure 5.15 – La requête source de la dimension customer.

on va appliquer des transformations sur quelques colonnes à l’aide du composant Co-

lonne dérivée.

page 59
 CHAPITRE 5. RÉALISATION

La Figure 5.16 pésente les transformations appliquées dans la dimension Customer.

Ces transformations consiste à remplacer les Nulls par zéro

Figure 5.16 – La colonne dérivée de la dimension Customer.

la dernière étape est le composant Dimension à variation lente, on va le montrer par

la Figure 5.17.

Figure 5.17 – Dimension à variation lente de la dimension Customer.

page 60
 CHAPITRE 5. RÉALISATION

• Chargement de la dimension Item

La dimension Item se charge d’une manière simple. Comme il est le cas avec les autres
Dimensions.

Figure 5.18 – Le chargement de la dimension Item.

La source OLE DB de la dimension Item est une requête SQL comme le montre Figure
5.19

Figure 5.19 – La requête source de la dimension Item.

la dernière étape est le composant Dimension à variation lente, on va le montrer par

la Figure 5.20.

page 61
 CHAPITRE 5. RÉALISATION

Figure 5.20 – Dimension à variation lente de la dimension Item.

• Chargement de la dimension Date

L’alimentation des dimensions relatives au temps se fait en utilisant un script SQL sur
SSMS, qui permet de charger un large intervalle de dates qui s’incrémentent régulièrement.

5.2.4.2 Chargement des faits

L’étape d’alimentation des tables de faits est la dernière étape du processus ETL.
Aprés avoir chargé les dimensions, passons maintenant au package FactDWH et aux faits.

Figure 5.21 – Package FactDWH.

Nous avons utilisé le composant SSIS Recherche pour trouver les colonnes associées à
chaque clé étrangère issue des tables de dimensions.
• Chargement de la fait Sales Value Entry

page 62
 CHAPITRE 5. RÉALISATION

La Figure 5.22 pésente le chargement de la fait Sales Value Entry.

Figure 5.22 – Chargement de la table fait Sales Value Entry.

La source de la table de fait Sales Value Entry est une table dans la base STG sous
le même nom qui contient toutes les colonnes nécessaires pour la table fait SVE sans
transformation.
Nous allons présenter par la Figure 5.23 et la Figure 5.24 la requête source de la table
fait Sales Value Entry.

Figure 5.23 – Requête source de la table fait SVE partie 1.

page 63
 CHAPITRE 5. RÉALISATION

Figure 5.24 – Requête source de la table fait Sales Value Entry partie 2.

La colonne dérivée pour la table fait SVE consiste à appliquer quelques calculs et
transformations sur quelques colonnes sources afin de créer d’autres nouvelles comme le
montre la Figure 5.25.

Figure 5.25 – Colonne dérivée de la table fait Sales Value Entry.

Pour la conversion des données, nous avons eu besoin de convertir le type de quelques
colonnes sources pour assurer leur mappage avec les clés primaires des tables de dimensions
vu la différence de types entre elles. Nous le montrons par la Figure 5.26.

page 64
 CHAPITRE 5. RÉALISATION

Figure 5.26 – Conversion de données de la table fait Sales Value Entry.

Pour le composant de Recherche ou Lookup, il est utilisé pour comparer les données
source aux clés primaires des tables de dimensions et trouver celles qui correspondent.
Pour les lignes non correspondantes, on les redirige vers la sortie sans correspodance.
la Figure 5.27 présente l’exemple de recherche de la clé primaire ItemID de la dimension
Item.

Figure 5.27 – Recherche de la clé primaire ItemID.

page 65
 CHAPITRE 5. RÉALISATION

• Chargement de la fait Sales Delivery

La Figure 5.28 pésente le chargement de la fait Sales Delivery.

Figure 5.28 – Chargement de la table fait Sales Delivery.

La Figure 5.29 présente les transformations appliqués dans la table Sales Delivery
par la colonne dérivée.

Figure 5.29 – Colonne dérivée de la table fait Sales Delivery.

page 66
 CHAPITRE 5. RÉALISATION

• Chargement de la fait Sales Order State

La Figure 5.30 pésente le chargement de la fait Sales Order State.

Figure 5.30 – Chargement de la table fait Sales Order State.

La Figure 5.31 présente les transformations appliqués dans la table Sales Order State
par la colonne dérivée.

Figure 5.31 – Colonne dérivée de la table fait Sales Order State.

page 67
 CHAPITRE 5. RÉALISATION

5.2.4.3 Processus global du package Main

Le package main a pour but d’exécuter tous les packages à la fois. le package main
contient un conteneur de séquence qui regroupe de son tour les 3 packages STG, DimDWH
et FactDWH qui s’exécutent dans le flux de contrôle global du package.
La Figure 5.32 pésente le package Main.

Figure 5.32 – Le package Main.

Passons maintenat au Déploiement et planification du package Main.

Le déploiement d’un package SSIS est une étape primordiale , en effet à travers cette
opération nous assurons l’automatisation de l’exécution des packages SSIS.
Nous planifions le déclenchement automatique du package Main par l’agent SQL Server.
La première étape consiste à créer un catalogue de services d’intégration (Integration
Services Catalogs) ≪ SSISDB ≫ au niveau de SQL Server Management Studio par la suite
nous déployions notre projet SSIS.
Après le déploiement de notre projet SSIS dans SQL server, l’étape suivante consiste
à créer une tâche de planification périodique dont le rôle est d’exécuter le flux SSIS
précédemment réalisé.
Pour cela nous avons besoins d’un agent SQL server, en effet l’agent SQL Server est le
service installé par SQL Server qui nous a permis d’automatiser et de planifier des tâches
en exécutant ses travaux (jobs).
La planification du job nécessite de préciser le type de planification, la fréquence et
la date de début et de fin de la planification. Notre choix est de lancer ce processus
quotidiennement à minuit d’une façon automatique.

page 68
 CHAPITRE 5. RÉALISATION

5.3 Réalisation du tableau de bord

Une fois le Datawarhouse chargé avec les données adéquates ayant subits les transfor-
mations nécessaires, il est temps de passer à la phase d’exploitation de ces dernières. Il
suffit d’entamer le travail requis : la création du tableau de bord de suivi des ventes de la
société Tunisie Câbles. Notre solution permet à l’utilisateur final de disposer d’une vue
unifiée des données et des informations qui importent pour ≪ faire avancer ≫ l’entreprise.

Figure 5.33 – Architecture globale de notre application Power BI.

Les tableaux de bord sont des écrans uniques dans lesquels diverses informations cri-
tiques sont placées sous la forme de graphiques variés. Parmi ces graphiques on retrouve
les Indicateurs de performance clés ou les KPIs qui représentent une notion importante
dans le dashboarding [Val22].

Figure 5.34 – Exemple d’un tableau de bord.

La mise en place du tableau de bord ou ce qu’on appelle le dashboarding est une étape

page 69
 CHAPITRE 5. RÉALISATION

cruciale dans un projet BI car la prise de décision se base sur un ensemble de graphiques
soigneusement réalisés par un outil puissant. Pour cela notre choix s’est orienté vers Power
BI.
En premier lieu, nous avons fait une connexion à notre base de données SQL Server
DWH pour obtenir les tables de dimensions et de faits.

Figure 5.35 – L’obtention des tables de la base DWH.

La constitution de la conception de la base de donnée DWH est nécessaire afin de

réaliser les jointures entre les tables de celles-ci.
La Figure 5.36 présente un exemple de la modélisation et jointures de la table Sales
Value Entry dans PowerBI.

page 70
 CHAPITRE 5. RÉALISATION

Figure 5.36 – Gestion des relations dans PowerBI.

A l’issue de cette étape, il est possible de créér les dashboards souhaités.

5.3.1 Les interfaces du tableau de bord

a. Ecran d’accueil
A l’ouverture de l’application, la première interface qui s’affiche est l’accueil qui contient
le nom de l’application ≪ Tableau de bord pour le suivi des ventes ≫, le logo de la société
≪ Tunisie Câbles ≫, ainsi qu’un menu sous forme des boutons qui facilite la navigation

entre les différentes interfaces.

La Figure 5.37 présente la première interface d’accueil.

page 71
 CHAPITRE 5. RÉALISATION

Figure 5.37 – Ecran d’accueil.

b. Ecran de la peformance du produit

En cliquant sur le bouton Performance produit, l’interface suivante s’affiche.

Figure 5.38 – Ecran de la performance du produit.

Elle contient des analyses relatives au Montants des ventes nettes et brutes et pro-
fit totaux et les coûts pour tous les produits sous forme d’un tableau et d’un comem-
bert et contient des segments qui contrôlent les visuels. L’utilité des segments et plus

page 72
 CHAPITRE 5. RÉALISATION

précisemment des trancheuses facilite la visualisation selon un état filtré.

Dans La Figure 5.39 nous avons présenté les visuels de l’interface mais contrôlés par
les deux segments Code pays en choisissant le code pays FRA ce qui signifie France et la
catégorie produit Consommable.

Figure 5.39 – Ecran de la performance du produit filtré.

Le clic sur le bouton flèche précédent nous emmène à la page précédente qui est la
page d’accueil.
c. Ecran Détails Client
En cliquant sur le bouton Détails Client, l’interface suivante s’affiche.

page 73
 CHAPITRE 5. RÉALISATION

Figure 5.40 – Ecran Détails Client.

Cette interface contient les informations relatives à un client sous forme d’un tableau
tel que son nom, la catégorie de produit et son nom, le type de son document, son vendeur
qui est le représentant de notre société et enfin le montant de la commande.
La sélection d’un client de la liste déroulounte ou par taper le nom à chercher montre son
nom son segment (son groupe) et sa période d’ancienneté.
On peut aussi filtrer les données par le type de document, type client ou famille produit.
La Figure 5.41 présente les visuels de l’interface filtrés par le Client SERMES et la fa-
mille de produit Frais généraux.

page 74
 CHAPITRE 5. RÉALISATION

Figure 5.41 – Ecran Détails Client filtré.

d. Ecran Fiche commandes/Livraisons

Dans cette interface aussi on peut filtrer les visuels par Client comme l’interface précédente.
Le graphique combiné présente le pourcentage de profit et le nombre de commandes par
article, le profit total des commandes et le nombre toatl sont présentés par le visuel
Numéro unique,le Camembert montre le montant total des commandes par produit, Nous
avons aussi un graphique en beignet présentant le montant des commandes livrées à la
date de livraison promise par rapport ceux qui sont livrées à la date de livraison requise
et enfin le graphique en beignet présente les montant de crédits d’un client.

page 75
 CHAPITRE 5. RÉALISATION

Figure 5.42 – Ecran Fiche Commandes/Livraisons.

.
e. Ecran Retour Produit
Cette interface a pour objectif de présenter les retours de produits mensuellement selon
des critères tel que le client, le commercial (le vendeur représentant de notre société) et
la catégorie du produit.

Figure 5.43 – Ecran Retour produit.

page 76
 CHAPITRE 5. RÉALISATION

Nous disposons deux tableaux le premier pour présenter les quantités livrées et quantité
et le taux de retour du produit. Ce tableau est présenté dans le graphique à droite.
le deuxième tableau consiste à présenter les montants des produit facturés, les montants
des produits retournés et le montant recu.
Vu la disposition des données d’une période de temps courte, nous ne trouvons pas des
retours de produit.
Nous allons présenter mainteneant la Figure 5.43 qui présente la même feuille du tableau
de bord mais en filtrant les données selon le client SERMES et la catégorie du produit
Consommable.

Figure 5.44 – Ecran Retour produit.

f. Ecran Overview
Cette interface récapitulative donne un aperçu général de l’activité vente au sein de Tunisie
Câbles.

page 77
 CHAPITRE 5. RÉALISATION

Figure 5.45 – Ecran Overview.

Comme le montre la figure précédente, l’interface du overview présente tout d’abord

le produit le plus vendu et le produit qui a généré plus de profit.
elle présente aussi le nombre total des produits et le nombre de nouveaux clients pendant
l’année précédente. Comme il ya les top 5 produits par rapport leurs ventes nettes. Puis
le total de ventes nettes par rapport la catégorie du produit et la variation temporelle
(trimestrielle) de Coût et de profit et on constate que si le coût augmente le profit diminue
et vice versa.
Comme toutes les autres interfaces, on peut appliquer des filtres de temps (année) et de
catégorie de produits.
La Figure 5.46 nous présente les visuels selon la catégorie du produit Consommable.

page 78
 CHAPITRE 5. RÉALISATION

Figure 5.46 – Ecran Overview filtré.

Nous remarquons les changements dans le résultat d’analyse.

Conclusion
Au cours de ce chapitre, nous avons présenté en détails la projection de la conception
du plan théorique sur le plan pratique. Nous avons élaboré les étapes du processus ETL.
Puis, nous avons illustré l’utilisation de l’application qui a pour but de suivre l’activité
de vente par des interfaces graphique.

page 79
Conclusion et perspectives

Ce rapport porte sur le travail réalisé au cours de notre projet de fin d’études au
sein de la société Business and management Consulting et pour la société Tunisie Câbles
portant sur la mise en place d’un système décisionnel.
L’objectif de ce projet BI réside donc à analyser les données sources de l’entreprise et
concevoir un entrepôt de données pour obtenir une vision agrégée ou détaillée sur les
ventes à travers des différents axes d’analyse selon le besoin.
Ce système nous a permis de mettre en place un tableau de bord présentant les informa-
tions de valeur suivant les critères choisis par le client.
Notre projet comporte plusieurs étapes :
Nous avons tout d’abord étudier le métier de l’entreprise cliente et leur environnement
de travail pour pouvoir rédiger un cahier de charge contenant les besoins et les objectifs
attendus par Tunisie Câbles.
Puis, nous avons élaboré une étude exhaustive de nos sources des données à l’aide des
fichiers de Mapping.
Ensuite, nous nous sommes tournés à la modélisation de l’entrepôt de données. Cette
modélisation offre une vision claire et une compréhension intuitive des modèles proposés.
Nous avons de ce fait proposé de modèle en étoile pour nos activités vente, commande et
livraisons.
Par la suite, nous avons passé à l’étape de l’alimentation de l’entrepôt de données.
L’étape finale de ce processus est la restitution des données. C’est durant cette phase que
nous avons mis en place un tableau de bord qui contribue à minimiser les efforts fournis
par les décideurs dans le processus de la prise des décisions.
Ce stage a été bénéfique puisqu’il nous a donné l’opportunité de découvrir le monde pro-
fessionnel et d’avoir une première expérience de maı̂triser la chaı̂ne d’un projet BI en
utilisant divers outil au sein d’une entreprise. En effet, ce projet nous a permis de nous
projeter dans le monde réel des entreprises et dans le milieu professionnel avec tout ce
qu’il implique en termes de discipline, de responsabilité et de travail en équipe.
Comme notre projet n’est pas complètement terminé, nous pouvons citer les perspectives
et les développements suivants :
— Nous pouvons faire le même projet mais pour le suivi des achats de la société.
— Comme nous pouvons publier notre tableau de bord pour qu’il soit en ligne et

80
 CONCLUSION ET PERSPECTIVES

accessible par tous les utilisateurs selon leurs rôles.

— Enfin, nous pouvons Utiliser des méthodes et des algorithmes de Data Mining pour
une meilleure exploitation des données.

page 81
Bibliographie

[Bas16] Arindam Basu. ≪ How to write using rich text format and markdown in latex
and overleaf ≫. In : Universidad de Canterbury (2016).
[G21] Emilie G. ”Tout comprendre des jointures SQL”. https://datascientest.com/tout-
comprendre-des-jointures-sql. Publié le 04 Mai 2021.
[Gab06] Jérôme Gabillaud. SQL Server 2005: administration d’une base de données
avec SQL Server Management Studio. Editions ENI, 2006.
[Guy21] Martin Guyot. ”informatique-decisionnelle”. https://alter-si.fr/informatique-
decisionnelle/. Publié le 15 mars 2021.
[Har20] Emma Haruka. ”what-is-agile-methodology”. https://www.redhat.com/fr/devops/what-
is-agile-methodology. Publié le 15 janvier 2020.
[Ja22a] Ruth Ja. ”Microsoft Visual Studio”. https://fr.wikipedia.org/wiki/MicrosoftV isualS tudio.
Dernière mise à jour le 17 mars 2022.
[Ja22b] Ruth Ja. ”SQL Server Integration Services”. https://docs.microsoft.com/en-
us/sql/integration-services/sql-server-integration-services?view=sql-server-ver16.
Dernière mise à jour en 2022.
[Jos22] Joseph. ”Rapports et tableaux de bord de Planning Analytics”. https://mediacenter.ibm.com/
Dernière mise à jour en 2022.
[kea20] Tim keary. ”What is Microsoft SSIS?” https://www.comparitech.com/net-
admin/what-is-microsoft-ssis/. Publié le 14 Février 2020.
[MM14] Ross Mistry et Stacia Misner. Introducing Microsoft SQL Server 2014. Mi-
crosoft Press, 2014.
[MSF22] William Assaf MSFT. ”Exécuter une procédure stockée”. https://docs.microsoft.com/fr-
fr/sql/relational-databases/stored-procedures/execute-a-stored-procedure?view=sql-
server-ver15. Dernière mise à jour le 30 avril 2022.
[MUS11] KIAKA MUSITU. ”Conception d’un datamart”. https://www.memoireonline.com/03/20/11
d − un − datamart − pour − le − pilotage − du − systeme − de − gestion −
des − impts − Cas − de − la − direction − g17.html. Publié en 2011.
[Olp21] Chugugrace et Olprod. ”Source OLE DB”. https://docs.microsoft.com/fr-
fr/sql/integration-services/data-flow/ole-db-source?view=sql-server-ver16. Pu-
blié le 14 septembre 2021.
[Rot12] Jason Roth. ”Analyse de données”. https://merval.fr/analyse-des-donnees/comment-
et-ou-collecter-les-donnees/site-header. Publié en 2012.
[San21] Larry Sange. ”Microsoft Power BI”. https://fr.wikipedia.org/wiki/MicrosoftP owerB I.
Dernière mise à jour le 18 novembre 2021.

82
 BIBLIOGRAPHIE

[Val22] Géraldine Valerie. ”Les tableaux de bord”. https://www.maxicours.com/se/cours/les-

tableaux-de-bord/. Dernière mise à jour en 2022.

page 83
BIBLIOGRAPHIE

page 84