Département
Télécommunications, Réseaux
et Informatique
Ecole Nationale des Sciences
Appliquées d’El Jadida
Université Chouaib Doukkali
Réf : F2-168/2021
PROJET DE FIN D’ETUDES
En vue de l’obtention du diplôme
D’INGENIEUR D’ETAT
En Ingénierie Informatique et Technologies Emergentes (IITE)
Réalisé à : INTERSIG MAROC - Casablanca
Réalisé par :
Oualid KHALIS
Encadré par :
Prof. Hassan OUAHMANE (Encadrant pédagogique)
M. Abdellatif SABIR (Encadrant professionnel)
Membres du jury :
Prof. Hassan OUAHMANE ....................................... Professeur à l'ENSA d'El Jadida
Prof. Mohamed HANINE .......................................... Professeur à l'ENSA d'El Jadida
Prof. Asmaa El HANNANI ........................................ Professeur à l'ENSA d'El Jadida
Année Universitaire 2020/2021
Mise en place d'un système décisionnel pour le
pilotage commercial et la gestion de la chaîne de
vente
iii
Département Télécommunications, Réseaux et Informatique
Ecole Nationale des Sciences Appliquées d’El Jadida
Université Chouaib Doukkali
PROJET DE FIN D’ETUDES
Filière : Ingénierie Informatique et Technologies Emergentes (IITE)
Mise en place d'un système décisionnel pour le pilotage
commercial et la gestion de la chaîne de vente
Réalisé à : INTERSIG MAROC - Casablanca
Par : Oualid KHALIS
Encadré par : M. Abdellatif SABIR et Prof. Hassan OUAHMANE
Année Universitaire : 2020/2021
iv
Résumé
Ce présent rapport résume le travail réalisé dans le cadre de mon projet de fin d’études effectué au
sein de l’entreprise INTERSIG MAROC, leader sur le marché national dans les matériaux de
construction, pour l’obtention du titre d’Ingénieur d’Etat en Ingénierie Informatique et Technologies
Emergentes.
INTERSIG MAROC rencontre dans le cadre de ses activités de vente, quelques problèmes dans sa
politique de reporting. Ces difficultés sont liées notamment à la lenteur et au coût de l’élaboration des
tableaux de bord, ce qui influence négativement la prise de décision et le processus du travail de
l’entreprise. De ce fait, nous avons réalisé un système décisionnel pour diminuer le temps, le coût, et
les intervenants afin d’optimiser la procédure de création des rapports, tout en nettoyant les données
et les centralisant dans un entrepôt de données.
Le but recherché étant d’aller vers la mise en place d’un système décisionnel pour les cinq fonctions
de vente principales (Commande, Livraison, Facture, Echéance et Règlement), qui sera construit
autour d’un datawarehouse afin de diminuer le pourcentage de l’échec des décisions prises pour
l’amélioration de la situation de l’entreprise aussi bien sa compétence de développement.
Pour ce faire, nous avons commencé notre projet par une étude préalable pour définir les
spécifications fonctionnelles et techniques. Par la suite, nous avons étudié ces spécifications afin de
déduire les métriques, et les critères d’analyse nécessaires au pilotage de l’activité, ainsi que les
modèles des rapports et tableaux de bord que nous avons élaboré ultérieurement pour la mise en œuvre
de notre solution.
En somme, ce projet réalisé a réussi à résoudre les problèmes rencontrés par la société au niveau
pilotage commercial en répondant à tous les besoins d’analyse du groupe dans sa fonction de vente.
Mots clés : INTERSIG MAROC, Matériaux de construction, Reporting, Tableaux de bord,
Prise de décision, Système décisionnel, Entrepôt de données, Métrique, Critères d’analyse,
Datawarehouse.
v
Abstract
This report summaries the work carried out as part of my final project at INTERSIG MAROC, the
national market leader in building materials, to obtain the engineering degree in Computer
Engineering and Emerging Technologies.
INTERSIG MAROC has encountered some problems in its reporting policy in the context of its sales
activities. These difficulties are linked in particular to the slowness and the cost of the elaboration of
the dashboards, which influences negatively the decision-making and the process of work of the
company. Therefore, we have developed a decision support system to reduce the time, cost, and
people involved in optimizing the reporting process, while cleaning up the data and centralizing it in
a DWH.
The goal is to move towards the implementation of a decision support system for the five main sales
functions (Order, Delivery, Invoice, Due Date and Settlement), which will be built around a
Datawarehouse in order to decrease the percentage of failure of decisions taken for the improvement
of the company's situation as well as its development competence.
To do this, we started our project with a preliminary study to define the functional and technical
specifications. Subsequently, we studied these specifications in order to deduce the metrics and
analysis criteria necessary for the management of the activity, as well as the models of the reports and
dashboards that we subsequently developed for the implementation of our solution.
In short, this project succeeded in solving the problems encountered by the company in terms of sales
management by meeting all the analysis needs of the group in its sales function.
Keywords: INTERSIG MAROC, Building materials, Reporting, Dashboards, Decision-
making, DWH, Metrics, Analysis criteria, Datawarehouse.
vi
INTERSIG MAROC
.
INTERSIG MAROC
.
.
.
.
C : ORARSIG MEINT
.
vii
Dédicaces
Je dédie ce travail :
À ma très chère mère
La femme patiente et formidable, tu as fait l’impossible pour me rendre
heureux, tu as souffert sans me laisser souffrir, et ta prière à mon égard a
toujours été ma source de force pour affronter les différents obstacles. Quoi
que je fasse ou que je dise, je ne saurai point te remercier comme il se doit.
J’espère que tu continueras à guider mes pas pour longtemps.
À mon très cher père
L’homme fort et merveilleux, tu m’as appris tant de choses, et tu m’as
enseigné d’importantes leçons de vie. Tu as toujours été mon école de
patience, de confiance et surtout d’espoir et d’amour. Grâce à toi j’ai appris
le sens du travail et de la responsabilité. Je voudrais te remercier pour ton
amour, ta générosité, et ton soutien. Et j’implore Dieu, tout puissant, de
t’accorder une bonne santé, une longue vie et beaucoup de bonheur.
À mon petit frère Othmane
Je t’aime mon petit frère, Puisse Dieu vous donne santé, bonheur, courage
et surtout réussite.
À la mémoire de mes grands-pères
Puisse Dieu vous avoir en sa sainte miséricorde et que ce travail soit une
prière pour vos âmes.
À mes chers ami(e)s
En souvenir des moments heureux passés ensemble, avec mes vœux sincères
de réussite, bonheur, santé et de prospérité.
À toute ma grande famille, et tous ceux que j’aime et
ceux qui m’aiment.
Oualid
viii
Remerciements
Premièrement et avant toute chose, nous rendons grâce à « ALLAH » le tout-puissant pour toutes les
vertus qu’il nous offre jour après jour, et pour nous avoir permis de suivre le chemin du savoir.
Ce modeste travail n’aurait pas pu voir le jour sans l’aide, la contribution et le soutien de plusieurs
personnes. Je voudrais leur rendre ici un hommage.
En premier lieu, je tiens à remercier ma très chère famille pour leur amour attentionné, leur support
tout au long de ma vie, ainsi que pour leur aide inestimable, leur patience et leur soutien indéfectible.
Ainsi, je tiens à exprimer ma profonde gratitude à M. Abdellatif SABIR et Mme Loubna SEHB,
pour tout le temps qu’ils m’ont consacré, les directives et les conseils qu’ils m’ont prodigués, et qui
m’ont été d’un fort appui ainsi pour la qualité de suivi durant toute la période de mon stage.
Je tiens à présenter mes remerciements au Prof. Hassan OUAHMANE, mon encadrant interne à
l’ENSAJ, pour avoir accepté d’encadrer mon projet de fin d’études, et pour le temps qu’il m’a
consacré tout au long de cette période de stage, pour ses recommandations, son soutien et ses efforts
afin de réaliser ce travail.
Je présente également mes remerciements, aux Prof. Mohamed HANINE et Prof. Asmaa El
Hannani les membres de jury qui m’ont fait l’honneur d’accepter de juger mon travail.
Je ne saurais oublier mes vifs remerciements pour tout le corps professoral de l’Ecole Nationale des
Sciences Appliquées d’El Jadida pour les cinq ans passés ensemble. Merci pour toutes vos leçons,
vos encadrements, votre soutien et suivis. Je vous serai à jamais reconnaissant.
Mes sincères remerciements et mes profondes reconnaissances aussi à toutes personnes parmi le
personnel d’INTERSIG MAROC qui a participé de près ou de loin à l’élaboration du présent travail.
ix
Liste des abréviations
Abréviation
Désignation
BI
Business Intelligence
CP
Condition de Paiement
CRM
Customer Relationship Management
CSV
Comma Separated Values
DCF
Direction Comptabilité et Finance
DCM
Direction Commercial et Marketing
DM
DataMart
DWH
Data WareHouse
ERP
Enterprise Resource Planning
ETL
Extract, Transform, Load
MC
Montant Commandé
MCAD
Montant Commandé l'Année Dernière
MCMD
Montant Commandé le Mois Dernier
MF
Montant Facturé
MFAD
Montant Facturé l'Année Dernière
ML
Montant Livré
MLAD
Montant Livré l'Année Dernière
OLAP
OnLine Analytical Processing
OLTP
OnLine Transaction Processing
SGBD
Système de Gestion de Base de Données
SGBDR
Système de Gestion de Base de Données Relationnelles
SI
Système d’Information
SID
Système d’Information Décisionnel
SQL
Structured Query Language
SSMS
SQL Server Management Studio
TP
Type de Pièce
x
Table des matières
Introduction Générale ................................................................................ 15
1 Contexte du projet ................................................................................ 17
Introduction ......................................................................................................................... 17
1.2 Etat de l’art sur les systèmes décisionnels .................................................................... 17
1.2.1 Informatique décisionnelle (Business Intelligence) ........................................................... 17
1.2.2 La chaîne décisionnelle ...................................................................................................... 18
1.2.3 Les différences entre le décisionnel et l’opérationnel........................................................ 20
1.3 Organisme d’accueil : INTERSIG MAROC ................................................................ 21
1.3.1 Informations générales ....................................................................................................... 21
1.3.2 Historique ........................................................................................................................... 22
1.3.3 Produits et vision de l’entreprise ....................................................................................... 22
1.3.4 Objectifs du groupe ............................................................................................................ 23
1.3.5 Fournisseurs de l’entreprise ............................................................................................... 23
1.3.6 Clients de l’entreprise ........................................................................................................ 24
1.4 Présentation générale du projet ..................................................................................... 25
1.4.1 Problématique .................................................................................................................... 25
1.4.2 Objectifs du projet ............................................................................................................. 26
1.5 Conduite et planification du projet ............................................................................... 27
1.5.1 Méthodologie adoptée : Scrum .......................................................................................... 27
1.5.2 Raison du choix ................................................................................................................. 28
1.5.3 Planification du projet ........................................................................................................ 28
Conclusion .......................................................................................................................... 30
2 Analyse et Spécifications des besoins .................................................. 31
Introduction ......................................................................................................................... 31
2.2 Etude de l’existant ......................................................................................................... 31
2.3 Critique de l’existant ..................................................................................................... 32
2.4 Analyse des besoins ...................................................................................................... 33
2.4.1 Techniques de recueil des besoins ..................................................................................... 33
2.4.2 Justification de l’approche utilisée .................................................................................... 34
2.4.3 Recueil récapitulatif des besoins ........................................................................................ 35
2.4.4 Besoins non fonctionnels ................................................................................................... 36
2.5 Périmètre fonctionnel du projet .................................................................................... 36
xi
2.5.1 Recensement des dimensions ............................................................................................. 38
2.5.2 Recensement des mesures .................................................................................................. 37
2.6 Périmètre technique du projet ....................................................................................... 39
2.7 Environnement de travail .............................................................................................. 40
2.7.1 Benchmarking des outils BI ............................................................................................... 41
2.7.2 Choix des outils BI ............................................................................................................ 42
Conclusion .......................................................................................................................... 43
3 Modélisation et Conception .................................................................. 44
Introduction ......................................................................................................................... 44
3.2 Modélisation d’un Datawarehouse ............................................................................... 44
3.2.1 Datawarehouse (Entrepôt de données) .............................................................................. 44
3.2.2 Datamart (Magasin de données) ........................................................................................ 45
3.2.3 Objectifs de l’entrepôt de données ..................................................................................... 46
3.2.4 Méthodologie de construction d'un DWH ......................................................................... 46
3.2.5 La modélisation dimensionnelle ........................................................................................ 49
3.2.6 Choix du modèle ................................................................................................................ 51
3.3 Conception de la zone d’entreposage ........................................................................... 52
3.4 Conception de la zone d’alimentation ........................................................................... 58
Conclusion .......................................................................................................................... 59
4 Implémentation et Tests ....................................................................... 60
Introduction ......................................................................................................................... 60
4.2 Réalisation de la phase d’ETL ...................................................................................... 60
4.2.1 Collecte des données .......................................................................................................... 60
4.2.2 Création des tables du Datawarehouse .............................................................................. 61
4.2.3 Alimentation du Datawarehouse ........................................................................................ 63
4.3 Restitution des données ................................................................................................. 69
4.4 Tests et résultats ............................................................................................................ 75
4.4.1 Temps de traitement ........................................................................................................... 75
4.4.2 Intégrité et sécurité des données ........................................................................................ 77
4.4.3 Test d’accès ........................................................................................................................ 77
4.4.4 Résultats ............................................................................................................................. 78
4.4.5 Comparaison ...................................................................................................................... 78
Conclusion .......................................................................................................................... 79
Conclusion Générale ................................................................................. 80
Références ................................................................................................ 82
Annexes .................................................................................................... 83
xii
Table des figures
Figure 1.1 : La chaîne décisionnelle ................................................................................................. 18
Figure 1.2 : Le processus ETL .......................................................................................................... 19
Figure 1.3 : Fournisseurs d'INTERSIG MAROC .............................................................................. 24
Figure 1.4 : Clients d'INTERSIG MAROC ........................................................................................ 25
Figure 1.5 : Processus de la méthode Scrum .................................................................................... 28
Figure 1.6 : Diagramme de Gantt ..................................................................................................... 29
Figure 1.7 : Diagramme de Gantt détaillé ........................................................................................ 30
Figure 2.1 : Processus de l'ancienne solution ................................................................................... 32
Figure 2.2 : Architecture de la solution ............................................................................................ 40
Figure 2.3 : Logo Talend ................................................................................................................... 43
Figure 2.4 : Logo SQL Server ........................................................................................................... 43
Figure 2.5 : Logo Power BI ............................................................................................................... 43
Figure 3.1 : Architecture du DWH selon Inmon ............................................................................... 47
Figure 3.2 : Architecture du DWH selon Kimball ............................................................................. 48
Figure 3.3 : Modélisation en étoile ................................................................................................... 50
Figure 3.4 : Modélisation en flocon .................................................................................................. 50
Figure 3.5 : Modélisation en constellation ........................................................................................ 51
Figure 3.6 : Conception de l'activité « Commande » ........................................................................ 53
Figure 3.7 : Conception de l'activité « Livraison » ........................................................................... 54
Figure 3.8 : Conception de l'activité « Facture ».............................................................................. 55
Figure 3.9 : Conception de l'activité « Echéance » ........................................................................... 56
Figure 3.10 : Conception de l'activité « Règlement » ....................................................................... 57
Figure 3.11 : Diagramme d’activité du processus d’alimentation .................................................... 59
Figure 4.1 : Exemple de la création d'une table de faits ................................................................... 61
Figure 4.2 : Exemple de la création d'une dimension ....................................................................... 62
Figure 4.3 : Les tables de faits et les dimensions du DWH ............................................................... 63
Figure 4.4 : ETL de la dimension « Article » .................................................................................... 65
Figure 4.5 : Vue sur les données de la dimension « Article » ........................................................... 65
Figure 4.6 : ETL de la dimension « Date » ....................................................................................... 66
Figure 4.7 : Vue sur les données de la dimension « Date » .............................................................. 67
xiii
Figure 4.8 : ETL de la table de faits « Commande » ........................................................................ 68
Figure 4.9 : Vue sur les données de la table de faits « Commande » ............................................... 68
Figure 4.10 : Types des graphiques de Power BI ............................................................................. 69
Figure 4.11 : La sélection des champs .............................................................................................. 70
Figure 4.12 : Les différences entre les différentes quantités et montants ......................................... 70
Figure 4.13 : La différence entre le montant commandé et le montant facturé ................................ 71
Figure 4.14 : Analyse des quantités commandés par types et états de commandes .......................... 71
Figure 4.15 : Rapport MC Année-1 / Mois-1 .................................................................................... 72
Figure 4.16 : Rapport ML Année-1 ................................................................................................... 73
Figure 4.17 : Rapport pour l'analyse de la performance des livraisons ........................................... 74
Figure 4.18 : Rapport pour l'analyse de la performance commerciale globale de l’entreprise ....... 75
Figure 4.19 : Test de traitement ETL ................................................................................................ 76
Figure 4.20 : Test de traitement DWH vers Power BI ...................................................................... 76
Figure 4.21 : Visualisation d'un rapport sous Power BI Service ...................................................... 77
Figure 4.22 : Visualisation d'un rapport sous Power BI Mobile ...................................................... 78
Figure A1.1 : Connexion entre l'ETL et la base de données opérationnelle de l'entreprise............. 83
Figure A1.2 : Connexion entre l'ETL et un fichier Excel .................................................................. 84
Figure A2.1 : Connexion entre l'ETL et l'entrepôt de données ......................................................... 85
xiv
Liste des tableaux
Tableau 1.1 : Tableau comparatif entre les SI décisionnels et les SI opérationnels ......................... 20
Tableau 1.2 : Informations générales sur l'organisme d'accueil ...................................................... 21
Tableau 2.1 : Tableau récapitulatif des besoins ................................................................................ 36
Tableau 2.2 : Liste des dimensions .................................................................................................... 39
Tableau 2.3 : Liste des mesures ......................................................................................................... 38
Tableau 2.4 : Comparatif des outils ETL .......................................................................................... 41
Tableau 2.5 : Comparatif des outils de reporting ............................................................................. 42
Tableau 3.1 : Avantages et inconvénients des approches de Kimball et d’Inmon ............................ 49
Tableau 3.2 : Comparaison entre le modèle en étoile et le modèle en flocon ................................... 52
Tableau 4.1 : Comparaison entre l'ancienne approche et la solution réalisée ................................. 79
15
Introduction Générale
Le secteur des matériaux de construction revêt une importance notable dans l’industrie nationale par
les liens qu’il entretient avec le reste des activités économiques, et plus particulièrement avec celles
du bâtiment, du tourisme et des travaux d’infrastructure. Et INTERSIG MAROC est le leader du
domaine sur le marché national.
Dans ce sens INTERSIG MAROC a intégré de nouvelles technologies afin d’augmenter sa
productivité, de faire face à la concurrence nationale, et bien évidement d’accroitre son chiffre
d’affaires. Il est ainsi pertinent de s’intéresser aux nouvelles technologies pour des fonctions en pleine
mutation telles que l’informatique décisionnelle.
Le département système d’information, vise à mettre en disposition aux responsables commerciaux
l’information pertinente, son rôle principal et d’assurer le pilotage commercial de la performance de
vente à travers un ensemble des actions qui mènent à l’élaboration des stratégies de l’entreprise et
donc permettre à l’organisation l’atteinte de son objectif principal.
Devant l’explosion des chiffres et des données qui représentent la matière première de l’activité de la
vente au sein de l’entreprise, les informaticiens doivent fournir aux décideurs commerciaux des bases
de données organisées, facilement exploitable et des visualisations de l’information par des
graphiques afin d’avoir une vue globale sur le fonctionnement de l’entreprise.
Donc, le problème réside dans l’exploitation des données. Autrement dit il faut collecter la bonne
information, la nettoyer, l’analyser afin de l’exploiter au moment opportun pour prendre les meilleures
décisions.
C’est dans cette optique qu’INTERSIG MAROC a exprimé son besoin de mise en place d’un système
décisionnel pour le pilotage commercial et la gestion de la chaîne de vente afin de consolider les
données issues des systèmes transactionnels, et d’offrir des informations de qualité pour les décideurs.
Ces informations, qui influeront grandement sur la stratégie de l’entreprise et donc sur son avenir. Un
tel système nécessite la mise en place d’un entrepôt de données fiable contenant les informations
16
nécessaires à l’accomplissement des processus décisionnels.
C’est dans ce cadre où s’inscrit mon projet de fin d’études qui entend offrir des informations de qualité
pour les décideurs. Il s’agit en fait de mettre à la disposition des décideurs des données à même de
leur éclairer et leur faciliter une prise de décision prompte en connaissance de cause. Ainsi ce présent
rapport qui est le fruit et l’illustration du travail effectué dans ce stage, relate les différentes phases
ainsi que les moyens auxquels on a eu recours pour atteindre les objectifs fixés, et ceci en quatre
principaux chapitres :
LE PREMIER CHAPITRE définit le contexte général du projet à travers une synthèse
bibliographique sur les SIDs, il présente l’organisme d’accueil, un rappel du sujet du stage, la
problématique et les objectifs, et finalement aborde la démarche suivie pour la conduite du projet.
LE DEUXIEME CHAPITRE consacré à l’étude analytique qui permet un critique de l’existant et
un repérage des besoins fonctionnels et non fonctionnels du futur système, afin de cadrer le projet
fonctionnellement et techniquement.
LE TROISIEME CHAPITRE présente la modélisation et la conception de la solution.
LE QUATRIEME CHAPITRE traite la partie d’implémentation de la solution finale ainsi que le
test des résultats obtenus.
17
1
Contexte du projet
Introduction
Ce premier chapitre représente un aperçu global sur le projet. En premier lieu, il contient une petite
synthèse bibliographique des systèmes décisionnels. Il présentera en second lieu l’organisme
d’accueil, INTERSIG MAROC. Et finalement il abordera une présentation générale du projet, la
problématique traitée et les objectifs visés par le projet, ainsi que la démarche suivie pour la conduite
du projet.
1.2 Etat de l’art sur les systèmes décisionnels
1.2.1 Informatique décisionnelle (Business Intelligence)
L’informatique décisionnelle ou la BI est l’ensemble des outils informatiques et des différentes
technologies utilisées qui permettent l’analyse des données de l’entreprise, afin d’en dégager les
informations qui vont offrir une aide à la décision
[1]
.
Les systèmes décisionnels sont utilisés par les décideurs pour obtenir une connaissance approfondie
de l'entreprise et de définir et de soutenir leurs stratégies d'affaires, par exemple :
• Acquérir un avantage concurrentiel.
• Améliorer la performance de l'entreprise.
• Répondre plus rapidement aux changements.
• Augmenter la rentabilité.
• D'une façon générale la création de valeur ajoutée de l'entreprise.
18
1.2.2 La chaîne décisionnelle
La chaîne décisionnelle est la chaîne de traitement de l’information permettant de transformer les
données collectées en informations pouvant être utilisées à des fins décisionnelle
[2]
.
Cette chaîne se compose d’éléments et d’outils que l’on présente souvent en quatre étapes distinctes :
Figure 1.1 : La chaîne décisionnelle
Phase d’alimentation
La première étape est celle d’alimentation qui consiste à détecter, sélectionner, extraire, transformer
et charger dans un entrepôt de données l’ensemble des données brutes issues des différentes sources
hétérogènes (Excel, SGBD, fichier plat, ERP, réseaux sociaux, CRM, logiciel d’emailing, objets
connectés…). Ce processus s’appelle l’ETL « Extract, Transform, Load »
[2]
.
❖ ETL (Extract, Transform, Load) :
Les systèmes de gestion des données de l'entreprise sont hétérogènes autant sur le plan technique que
sur le plan logique. Les données à collecter sont en effet stockées dans des systèmes de natures
différentes, sous des formats différents, selon des structures différentes
[2]
.
Les outils de l’ETL sont des outils et techniques spécialisés et qui répondent à ce besoin grâce à un
processus ETL :
19
Figure 1.2 : Le processus ETL
❖ Extraction « Extract » :
Lors de l'extraction, les données pertinentes sont identifiées et collectées à partir de diverses sources.
Les données provenant de sources d'intégration internes et externes ne sont pas incomplètes et peuvent
être dupliquées. Ainsi, le processus d'extraction est essentiel pour sélectionner des données
significatives qui sont utiles pour la prise de décision.
❖ Transformation « Transform » :
L’étape de transformation du processus ETL est celle des opérations les plus essentielles. L’opération
la plus importante de l’étape de transformation consiste à appliquer aux données brutes les règles
internes de l’entreprise de manière à répondre aux exigences en matière de reporting : les données
brutes sont nettoyées et converties aux formats de rapport qui conviennent. D’un autre côté, les
exigences commerciales et techniques peuvent nécessiter plus d'un type de transformation. Dans cette
étape, les données reçues sont nettoyées pour générer des données uniques précises, exactes,
complètes et cohérentes.
❖ Chargement « Load » :
La dernière étape du processus ETL consiste à charger les données extraites et transformées dans leur
nouvel emplacement. En général, les datawarehouses supportent deux modes pour le chargement des
données : chargement initial et chargement incrémental.
Phase de modélisation
La deuxième étape est celle de modélisation de données. Une fois les données centralisées par un
outil d’ETL, celles-ci doivent être structurées au sein d’un Datawarehouse. La modélisation est la
définition des besoins nécessaires pour spécifier les données requises pour l’analyse et la prise de
décision. En fait c’est un prétraitement ayant pour but de faciliter l’accès aux données centralisées
aux outils d’analyse
[2]
.
20
Phase de restitution
La troisième étape est celle de restitution de données qui vise à mettre les données à la disposition
des utilisateurs en prenant en compte leur profil et leur besoin métier. L’objectif est de diffuser les
données collectées pour qu’elles soient cohérentes par rapport au profil de l’utilisateur et qu’elles
soient simples à exploiter. Lors de cette phase, de nouveaux calculs de données peuvent être effectués
pour répondre aux besoins spécifiques des utilisateurs. Les outils de la phase de restitution sont
multiples. Il peut s’agir d’outils de reporting, de portails d’accès à des tableaux de bords, d’outils de
navigation dans des cubes OLAP (ou hypercubes) ou encore des outils de statistique
[2]
.
Phase d’analyse
La quatrième étape est celle d’analyse, l’objectif de cette phase est d’assister au mieux l’utilisateur
pour qu’il puisse analyser les informations mises à sa disposition et prendre des décisions. Cela passe
notamment par le contrôle d’accès aux rapports, la prise en charge des requêtes et la visualisation des
résultats
[2]
.
1.2.3 Les différences entre le décisionnel et l’opérationnel
Le tableau suivant résume de façon non exhaustive les différences qu’il peut y avoir entre les systèmes
opérationnels et les systèmes décisionnels selon les données et l’usage fait des systèmes
[3]
:
Décisionnel
Opérationnel
Gros volumes de données à gérer
Petits volumes de données à gérer
Petit nombre d'utilisateurs
(décideurs, analystes, etc.)
Utilisé par toute l’entreprise
Orienté thèmes et sujets
Orienté applications
Données en lecture seul
Lecture, écriture et modification
des données
Niveau de granularité très grand
(Historisé)
Niveau de granularité fin
Temps de réponse moins critiques
Temps de réponse immédiats
Centralisé
Décentralisé
Tableau 1.1 : Tableau comparatif entre les SI décisionnels et les SI opérationnels
21
Ces différences font ressortir la nécessité de mettre en place un système répondant aux besoins
décisionnels. Ce système n’est rien d’autre que le datawarehouse.
1.3 Organisme d’accueil : INTERSIG MAROC
Leader sur le marché national, INTERSIG MAROC offre la meilleure innovation dans la
préfabrication des planchers, du treillis soudé et du tréfilage des aciers. Près de 30 ans d'expérience
ont permis au groupe de prendre une sérieuse longueur d'avance pour offrir le meilleur de la
technologie en matière de planchers préfabriqués.
INTERSIG appartient à un groupe d’entreprises constitué de six sociétés, Karkachi&Fath, Intersig
Maroc, Armabeton, Armatures du Maroc, Armafort et Interagregats.
1.3.1 Informations générales
Cette figure contient les informations générales sur l’organisme d’accueil « INTERSIG MAROC » :
Raison sociale
SOCIETE INTERSIG MAROC
Secteur d’activité
Bâtiment et Travaux Publics
Siège social
Douar EL Frafra Ouled Ahmed
Dar Bouazza-CASABLANCA
Forme juridique
Société à responsabilité limitée
Registre de commerce
89807 A CASABLANCA
Identification fiscale
0220074
Patente
32968161
Tableau 1.2 : Informations générales sur l'organisme d'accueil
22
1.3.2 Historique
En 1993, la société INTERSIG a vu le jour sous forme de société anonyme, avec un siège à El
JADIDA, Bd EL Massira El Khadra et un capital de 2.100.000,00 Dh.
Depuis sa création jusqu'à ce jour des millions de dirhams ont été investi pour garantir l’évolution de
l’entreprise, la bonne qualité des produits, Préserver la position de leader dans le marché national et
aussi pour pouvoir répondre à la demande croissante du marché.
1.3.3 Produits et vision de l’entreprise
Produits de l’entreprise :
• Planchers préfabriqués type INTERSIG.
• Poutrelles nues.
• Treillis soude Bobines de l’acier tréfilé lisse et tréfilé cranté.
• Barres de renforts en acier tréfilé et cranté.
• Poutrelles enrobées Hourdis en béton léger (8-12-16-20-25-30).
• Agglos en béton (remplissage/porteur).
La réussite du groupe est due essentiellement à son souci constant d'anticiper les besoins du marché
en réunissant les compétences humaines à la tradition de qualité et surtout à la confiance de ses clients.
• Le client est au cœur des objectifs de l’organisation.
• Un management très « TERRAIN » des équipes commerciales.
• Compétence, formation et motivation des ressources humaines.
• L’approche partenariale.
• Qualité, Sécurité et Environnement.
• Produits conformes aux normes en vigueur.
• Réseau de concessionnaires professionnels à travers le Maroc.
23
1.3.4 Objectifs du groupe
Le groupe INTERSIG s’engage envers la prévention des préjudices relative à la santé du personnel et
également envers la prévention de la pollution, à satisfaire les exigences réglementaires en vigueur,
déployer les moyens nécessaires tant que humains que matériels et veiller à ce que la politique
« Qualité, Hygiène, Sécurité » soit comprise et communiquée au sein de l’entreprise. Des revues de
direction sont organisées afin de permettre l’évaluation de l’efficacité et la révision du processus. Pour
offrir toujours aux clients plus de choix de qualité et de service à des prix les plus compétitifs dans le
marché.
Objectifs qualité
• Satisfaction des attentes du client.
• Consolider et développer le réseau de distribution.
• Développer la prospection de nouveau fournisseur stratégique.
• Maîtriser la qualité des produits.
Objectifs sécurité
• Réduction et maîtrise des accidents de travail.
• Garantie d'un environnement de travail sécurisé.
Objectifs environnement
• Maîtriser les déchets.
• Maîtriser les rejets atmosphériques à savoir les poussières de ciment.
• Maîtriser les fuites.
• Maîtriser la consommation électrique.
1.3.5 Fournisseurs de l’entreprise
Les fournisseurs d’INTERSIG permet de s'assurer à la fois : la bonne conformité de la commande
ainsi qu'améliorer la satisfaction des utilisateurs à courte et long terme.
24
Figure 1.3 : Fournisseurs d'INTERSIG MAROC
1.3.6 Clients de l’entreprise
Aujourd’hui INTERSIG MAROC a gagné un grand nombre de clients ce qui lui a permis de gagner
de multiples projets afin de satisfaire ses clients.
25
Figure 1.4 : Clients d'INTERSIG MAROC
1.4 Présentation générale du projet
1.4.1 Problématique
La société INTERSIG MAROC, est l’opérateur historique et le leader du domaine matériaux de
construction sur le marché marocain, elle est composée d’un siège et quatre usines. Donc elle est
appelée à interagir avec ses clients sur les différentes phases du processus de la vente, et elle nécessite
un traitement exigeant de chacune de ces activités commerciales pour des fins décisionnelles afin de
mettre en place de meilleures stratégies de pilotage.
Après chaque vente il y a une croissance de données qui sont enregistrées et stockées dans la base de
données d'une manière brute et hétérogène et cette croissance va rendre l'élaboration des rapports, et
les tableaux de bord en utilisant des méthodes classiques (Requêtes SQL compliquées, Excel, etc.),
une tache très difficile et couteuse.
En effet, la société se trouve dans l’incapacité de faire des analyses fiables, efficaces et à des moments
opportuns sans engager des moyens considérables sur des périodes plus ou moins longues. Ainsi, les
principales difficultés rencontrées peuvent être résumées en :
❖ Difficultés dans l’élaboration des rapports d’activité : l’élaboration des rapports d’activité
fait intervenir, généralement, plusieurs intermédiaires. En effet, à chaque fois qu’il est
nécessaire d’élaborer un rapport d’activité, il faudra procéder d’abord à l’extraction des
données à partir de la base de données relationnelle à travers des requêtes SQL compliquées,
26
pour les acheminer ensuite manuellement vers un fichier Excel afin de visualiser ces requêtes.
Il s’agit là d’une procédure lourde outre les éventuelles incohérences et erreurs.
❖ La décentralisation et l’hétérogénéité des données : les données sont stockées dans la base
de données d’une manière brute, hétérogène, et non claire. Donc les informaticiens doivent à
chaque fois implémenter des modifications et des transformations au niveau de la requête
SQL, ce qui rend l’exploitation de ces données très difficile, et les rapports proposés ne
donnent plus satisfaction à cause des transformations non complètes.
❖ Lenteur de la procédure de reporting : la politique de reporting actuelle, par ailleurs quasi
manuelle, connait des lenteurs qui n’arrangent pas les décideurs. Ceux-ci ont besoin
d’informations fiables et dans des délais raisonnables. À titre indicatif, l’édition d’un rapport
commercial peut prendre, en moyenne, plus d’une semaine entre le requêtage SQL, et la
visualisation des données sur Excel, ce qui est plus que pénalisant pour une bonne prise de
décision.
❖ Coût de la procédure de reporting : la procédure de reporting est jugée très couteuse pour
l’entreprise, et cela est principalement dû au nombre d’intervenants et des moyens mis en
place pour cette dernière.
1.4.2 Objectifs du projet
Pour résoudre les problèmes de la société mentionnée ci-dessus, nous allons mettre les bases
nécessaires à la mise en place d’un système de prise des décisions. Dans le cadre de ce projet, notre
mission est avant tout la conception et la mise en œuvre d’un DWH qui utilise les données stockées
dans la base de données relationnelle, tout en conférant aux décideurs un support fiable, et en les
éclairant sur les mesures des différents indicateurs stratégiques et opérationnels et permettre la
visualisation et l’extraction des rapports de statistiques en relation avec les différentes activités
commerciales.
Donc les principaux objectifs de ce projet peuvent être résumés comme suit :
• Minimiser la durée globale de l’élaboration des rapports, en essayant de ramener cette durée,
au moins, en dessous de la barre des 48 heures.
• La réduction du nombre d’intervenants lors de la production de rapports.
• L’intégration et la centralisation des données afin de faciliter l’accès aux informations.
27
• Offrir des informations fiables, cohérentes et pertinentes, contenant la logique business
souhaités.
• Faciliter l’exploitation des informations stockées (données organisées selon différentes
dimensions).
• Améliorer la qualité des rapports, et les mettre à la disposition des décideurs, dans des délais
très courts, et des états de sorties multiples et personnalisés (rapport, tableaux de bord,
graphes, etc.).
1.5 Conduite et planification du projet
1.5.1 Méthodologie adoptée : Scrum
Scrum est un processus agile qui nous conduit à produire la plus grande valeur métier dans la durée
la plus courte. Il permet d'inspecter rapidement et régulièrement après chaque sprint un livrable
[4]
.
Notre projet est planifié sur quatre sprints d’une durée de deux semaines pour chaque sprint. Chaque
journée de travail commence par une réunion de 15 minutes maximum appelée mêlée quotidienne ou
« Daily Scrum » en anglais. À la fin du sprint, nous faisant une réunion pour effectuer une revue de
sprint qui dure au maximum 3 heures destinées pour montrer ce qu’on a réalisé pendant le sprint, afin
d’en tirer les conséquences pour la suite du projet.
❖ Sprint : Un sprint est une période de développement qui dure entre une semaine et un mois,
et chaque sprint se décompose en un ensemble de tâches du cahier des charges. Et se termine
par une revue de sprint
[4]
.
❖ Daily Scrum : C’est une petite réunion de 15 mins maximum. Lors de la Daily, chaque
membre de l’équipe va expliquer ce qu’il a fait depuis la dernière Daily, ensuite il va dire ce
qu’il pense faire jusqu’à la prochaine Daily et les obstacles rencontrés
[4]
.
Scrum définit 3 rôles
[4]
:
❖ Le Product Owner : Représente les intérêts du client et il définit les fonctionnalités du produit
final.
❖ Le Scrum Master : Assure le respect de l’exécution du Scrum au sein de l’équipe, assure un
environnement adéquat pour compléter le travail, et il arrange les réunions.
❖ L'équipe de développement : L’équipe qui réalise le produit.
28
Figure 1.5 : Processus de la méthode Scrum
1.5.2 Raison du choix
L’Application de la Méthode Agile-Scrum a plusieurs avantages :
• Une gestion intelligente du travail qui engendre plus d’efficacité et de productivité.
• Une meilleure visibilité et communication des équipes sur les sujets en cours.
• La valorisation et l’autonomie de chaque membre du groupe.
• Une cohésion d’équipe, et une réflexion constante pour dépasser les difficultés.
• Une meilleure performance.
1.5.3 Planification du projet
L’organisation et la planification sont la colonne vertébrale de chaque projet, la planification permet
de structurer les différentes tâches à accomplir et d’estimer la durée de réalisation, ce qui permet
d’évaluer les ressources nécessaires et leurs coûts et donc d’atteindre les objectifs visés. C’est dans
ce sens ou on a utilisé le diagramme de GANTT comme outil de représentation visuelle d’état
d’avancement des différentes activités de chaque projet en outre il permet de visualiser le détail et la
durée de chaque tâche dans chaque phase parmi les phases suivantes :
❖ Phase 1 (Etude préalable) : cette phase consiste à une formation sur les outils de travail pour
se familiariser avec ses derniers toute en réalisant l’analyse de l’environnement économique
et de la stratégie de l’entreprise afin de définir le périmètre et la portée du projet.
29
❖ Phase 2 (Analyse et Architecture technique) : cette phase permet d’analyser la solution
existante, ses inconvénients, et d’analyser les besoins afin de définir les mesures et les
dimensions, et proposer de nouveaux modèles de tableaux de bord plus ergonomiques selon
les besoins exprimés par l’entreprise. Et vers la fin de cette phase, on va définir les éléments
de l’architecture qui répondent aux spécifications initiales du projet (Matériels, Logiciels,
Base de données, etc.).
❖ Phase 3 (Conception du DWH et chargement ETL) : Dans cette partie on s’occupe de la
conception des tables de fait et des dimensions du DWH. Et on va développer le processus
d’intégration de données qui vise l’extraction des données depuis les sources de données, leurs
transformations et leurs chargements sur le DWH.
❖ Phase 4 (Restitution et Tests) : C’est la dernière étape où on va créer des rapports et des
tableaux de bord pour chaque activité de vente (Commande, Livraison, Facture, Echéance,
Règlement). Tester le bon fonctionnement de la chaîne décisionnelle et déployer la solution
finale.
Les figures suivantes représentent le diagramme de GANTT des phases ci-dessus :
Figure 1.6 : Diagramme de Gantt
30
Figure 1.7 : Diagramme de Gantt détaillé
Conclusion
Ce chapitre, nous a permis dans un premier temps, de présenter le contexte général du projet, où on a
mis la lumière sur une synthèse bibliographique concernant les systèmes décisionnels, une
présentation générale de l’organisme d’accueil, puis nous avons identifié la problématique derrière la
réalisation de ce projet, les objectifs visés par ce projet ainsi que la démarche qu’on va adopter pour
réaliser le projet et atteindre les objectifs fixés.
31
2
Analyse et Spécifications des
besoins
Introduction
Ce chapitre porte sur l’analyse de l’existant et la spécification des besoins qui constituent la deuxième
étape dans un projet BI. Il s’agit de dégager les points forts et les points d’amélioration du système
actuel. Aussi nous allons spécifier les besoins fonctionnels et non fonctionnels en matière du
reporting, visualisation des données, et tableaux de bord, de sorte qu’on puisse y répondre dans la
solution proposée.
2.2 Etude de l’existant
L’étude de l’existant représente une étape très importante pour la conduite d’un projet ainsi qu’elle
s’avère une phase primordiale dans la conception et la réalisation des nouveaux systèmes. Elle permet
la détection du dysfonctionnement et le dégagement des pistes d’amélioration afin d’atteindre les
objectifs souhaités.
INTERSIG MAROC contient une très grande masse de données sur toutes les activités commerciales
et qui sont reliées à la fonction de vente au niveau national. Et elle fait le suivi de la clientèle et la
gestion commerciale à partir d’un ERP « Sage X3 » déployé dans le siège et les quatre usines de
l'entreprise en interne. Donc à chaque fois qu’on veut générer des informations ou des rapports pour
prendre des décisions il faut grouper les données depuis les différentes usines et exécuter des requêtes
SQL afin de les restituer dans Excel.
Voici le processus de la solution existante pour générer des rapports ou des tableaux de bord pour les
décideurs au sein de l’entreprise :
32
Figure 2.1 : Processus de l'ancienne solution
Alors l’existant consiste en des requêtes sur la base de données relationnelle liée à l’ERP. Ainsi,
l’extraction et le reporting se font sous Excel. Celui-ci est donc limité et ne propose pas toutes les
fonctionnalités voulues. Nous remarquons donc que le système est non automatisé. Et s’effectue sur
une période d’une à deux semaines.
2.3 Critique de l’existant
Il est intéressant de signaler que la société ne dispose d’aucun système d’aide à la décision
automatique ou semi-automatique. Aussi, tout processus d’analyse et de prise de décision à tous les
niveaux basés essentiellement sur des rapports dont les données sont extraites et consolidées à partir
des systèmes opérationnels d’une manière manuelle, ce qui pose des difficultés au niveau stratégique
de la société. Ces difficultés sont comme suit :
❖ La perte du temps : la perte du temps se trouve dans l’aspect de l’extraction des données à
partir de la base de données relationnelle manuellement, ce qui exige des requêtes compliquées
nécessite une liste de codes pour avoir parfois juste des données simples sous des formats
Excel.
❖ La complexité : en voulant chercher une information donnée pour les décideurs commerciaux,
la procédure commence par une requête qui permet d’extraire les informations nécessaires
depuis la base de données, ces requêtes posent la plupart des fois des complexités. L’aspect
de complexité est déterminé au niveau des requêtes SQL compliquées utilisées qui semblent
difficiles à cause des conditions et des critères de sélection ainsi que la grammaire du langage
adaptée à la structure des données interrogées.
33
❖ Données non historisées : l’ancienne solution ne couvre pas l’historisation des données, cela
ne permet pas de collecter les changements à travers l’axe du temps.
❖ L’efficacité : l’aspect de ce critique se pose dans les difficultés à déterminer la bonne requête
pour avoir les données dont les décideurs ont besoin depuis la base de données.
Ces difficultés entraînent plusieurs problèmes de maintenance et de mise à niveau du système. Cela
crée une action supplémentaire qui vous permet de vérifier manuellement que les données saisies par
l'utilisateur sont correctes. Par conséquent, notre mission est de résoudre ces problèmes en suggérant
les bonnes solutions de décision. Et pour cela et après avoir étudié et compris l’existant, l’étape
suivante est de passer à l’étude des besoins afin de détecter les attentes des intervenants de ce projet.
2.4 Analyse des besoins
L’objectif de cette analyse est de répondre à un ensemble de besoins c’est dans ce sens que cette phase
du recueil des besoins est établie pour spécifier et expliquer la couverture fonctionnelle et non
fonctionnelle de l’ensemble des processus métiers qui définit la structure du projet.
2.4.1 Techniques de recueil des besoins
Il est critique dans la conception et la mise en œuvre des systèmes d'information, d'élaborer et de
suivre une stratégie pour collecter les besoins. La satisfaction des utilisateurs et la réussite des projets
en général sont en effet largement dépendantes d'une bonne définition du périmètre fonctionnel.
Dans cette partie on va examiner les différentes techniques utilisées pour recueillir les informations
nécessaires afin de nous aider à établir un entrepôt de données réussi. Comme il est indiqué ci-
dessous :
❖ Le questionnaire : un questionnaire est un ensemble de questions construit dans le but
d’obtenir l'information correspondante aux questions de l’évaluation. Avantages : Permet de
recueillir une quantité importante d’informations, permet de consulter un grand nombre de
bénéficiaires finaux. Inconvénients : Nécessite des ressources importantes, la formulation
peut influencer les réponses, les réponses ne sont ni complètes ni détaillées
[5]
.
❖ L’entretien : c'est une technique destinée à recueillir des informations à l’aide de questions
posées verbalement par l’analyste. Les entretiens sont menés soit individuellement, ou par
petits groupes. C’est sans doute la technique la plus utilisée et orientée vers un but. Afin de
pouvoir alimenter la recherche d’informations sur un thème fixé. Avantages : Elle ne
nécessite pas beaucoup de ressources ni de personnel, elle permet d’établir un contact plus
34
personnel avec les populations ciblées, elle permet d’obtenir des informations très fines et très
détaillées. Inconvénients : C’est une technique difficile à préparer et à mettre en œuvre, elle
demande souvent du temps, coûteuse en temps et argent
[5]
.
❖ L’observation : c'est un mode de collecte des données précises par lequel le chercheur
observe de lui- même des processus ou des comportements se déroulant dans une organisation,
pendant une période de temps délimité. Avantages : Elle produit des informations sur les
pratiques réelles, elle permet de constater des décalages entre le dire et le faire, elle ne
nécessite pas beaucoup de ressources. Inconvénients : Il y a un risque de passer à côté des
données importantes ou d’orienter les résultats, elle demande souvent du temps, difficultés à
interpréter certains comportements
[5]
.
❖ La documentation : pour connaître le fonctionnement de l’entreprise et tirer des informations
sans interrompre son fonctionnement par des questionnaires ou entretiens, utilisés par les
différents services de l’entreprise. Avantages : Informations complètes, n’interrompt pas le
fonctionnement de l’entreprise, l’information existe déjà. Inconvénients : Coûteuse en temps,
il se peut parfois que l’information soit incomplète par rapport à ce qu’on cherche
[5]
.
2.4.2 Justification de l’approche utilisée
Après l’étude des différentes approches de collecte d’informations, notre choix s’est porté sur
l’approche d’entretien, compte tenu de ses multiples avantages, mais cette approche présente certains
inconvénients dont notamment la difficulté d’entretien un grand nombre de personnes à cause de leur
contrainte d’emploi du temps. Complétée par l’approche documentation qui permet de recueillir des
informations complètes. Pour résumer les démarches que nous avons adoptées :
• Etude des systèmes sources, entretiens avec l’administrateur de la base de données.
• Entretiens avec les utilisateurs de la base de données, et les décideurs commerciaux.
• Récapitulatif des besoins détectés.
Première approche « l’entretien » : à cause de ses avantages précédemment cités. Et en rencontrant
les représentants des utilisateurs, nous avons pu collecter les informations détaillées. Lors de notre
enquête, nous avons pu nous entretenir avec : l’administrateur de la base de données, le directeur
système d’information et le directeur commercial.
35
Deuxième approche « La documentation » : nous avons utilisé cette approche lors de l’étude du
système opérationnel de l’entreprise, et la documentation était disponible sur l’ERP interne « Sage
X3 ».
2.4.3 Recueil récapitulatif des besoins
L’étude des besoins nous a permis de recenser les besoins qu’on peut citer comme suit :
❖ Mise en place d’un DWH dédié au pilotage commercial : concevoir et implémenter un
entrepôt de données centralisé, orienté vente, contient des informations cohérentes, fiables, et
homogènes. Le regroupement de ces données dans un entrepôt de données orienté vente
facilite l’accès aux informations commerciales en identifiant une source commune au
reporting et à l’analyse des données.
❖ Facilité l’accès aux données : l’objectif est de disposer aux décideurs d’un système qui leurs
permet la possibilité d’accès facilement aux données quelle que soit leur forme, leur type, et
leur source. Ce qui leurs donnent les informations précises et concises sans aucune perte de
temps et répond à leurs objectifs pour aider à la prise de décision.
❖ Génération des rapports et des tableaux de bord rapidement : répondre d’une manière
optimisée, précise, et rapide aux requêtes d’outils de reporting et des tableaux de bord
d’indicateurs et la mise en déposition aux décideurs et aux analystes les tableaux de bord et
les rapports analytiques représentent les outils efficaces et dynamiques qui permettent une
évaluation et un suivi des différentes activités de la vente. Alors ceci dispose les décideurs des
informations précises, et des rapports en précisant la distribution des indicateurs et des axes
d’analyse sur les tableaux de bord qui sont exploitables pour la décision. Mis à part une version
Desktop plus dynamique et plus ergonomique des tableaux de bord, une version web et mobile
sera implémentée et permettra aux dirigeants de suivre la performance à travers leurs
smartphones et tablettes.
D’après les besoins spécifiés, le tableau ci-dessous représente un récapitulatif de ces derniers :
Question
Réponse
Qui ?
Les Services commerciaux, la DCM et la DCF
36
Quoi ?
Analyse des activités commerciales (Commande, Livraison,
Facture, Echéance, Règlement) par les différents axes d’analyse
Pourquoi ?
• Être à jour avec les activités de la vente au sein de
l’entreprise
• Définir les axes d’analyse qui affectent directement le
processus de la vente
• Fournir des tableaux et des rapports analytiques exploitables
par les directeurs commerciaux pour la prise de décision
• Améliorer la qualité des informations
• Faciliter l’accès aux données et les centraliser dans un DWH
Comment ?
L’utilisation des technologies de l’informatique décisionnelle
Tableau 2.1 : Tableau récapitulatif des besoins
2.4.4 Besoins non fonctionnels
Un besoin non fonctionnel est un besoin qui spécifie les propriétés du système tel que les contraintes
liées à l’environnement et à l’implémentation. Notre système doit répondre aux besoins suivants :
❖ Besoin de performance : le système doit être performant c'est-à-dire à travers ses
fonctionnalités, répond à toutes les exigences d’une manière optimale.
❖ Besoin de sécurité : l’accès aux informations n’est possible qu’après vérification des
privilèges et des droits d’accès.
❖ La convivialité : le système doit fournir des interfaces conviviales c'est-à-dire simples et
ergonomiques. Il doit présenter un enchainement logique entre les pages.
❖ La rapidité du traitement : vu le nombre important des opérations quotidiennes, il est
impérativement nécessaire que la durée d’exécution des traitements soit la plus courte
possible.
❖ L’accessibilité : plusieurs utilisateurs utilisent notre système simultanément.
❖ La compatibilité : le système doit être compatible avec les différentes machines et
navigateurs.
2.5 Périmètre fonctionnel du projet
Cette partie sert à formuler les besoins du client, au moyen de fonctions détaillant les services rendus
par le nouveau système à mettre en place et les contraintes auxquelles il est soumis. En décisionnel,
le but du cadrage fonctionnel est de combler les besoins fonctionnels de notre projet en termes de
37
mesures et de dimensions.
La conception des dispositifs décisionnels repose sur deux notions fondamentales qui sont : la notion
de mesure et la notion de dimension. On entend par mesure le sujet d’analyse. Il réfère à un ensemble
de mesures qui représentent les différentes valeurs de l’activité analysée. La dimension est une
perspective ou axe d’analyse, elle se compose de paramètres et d’attributs qui peuvent faire varier les
mesures.
2.5.1 Recensement des mesures
Le tableau ci-dessous récapitule l’ensemble des mesures et des indicateurs de performance dégagés
précédemment à partir des besoins :
Table de faits
Mesures
Commande
Quantité Commandée
Quantité Livrée
Quantité Facturée
Montant Commandé
Montant Livré
Montant Facturé
Montant Commandé l'année dernière
Montant Commandé le mois dernier
% Différence entre MC et MCAD
% Différence entre MC et MCMD
Différence entre MC et MF
% Différence entre MC et MF
Prix HT
Prix TTC
Délai de livraison
Délai de production
Livraison
Quantité Livrée
Quantité Retournée
Montant Livré
Montant Retourné
Montant Livré l'année dernière
38
% Différence entre ML et MLAD
Prix HT
Prix TTC
Facture
Quantité Facturée
Commission
Montant Facturé
% Différence entre MF et MFAD
Prix HT
Prix TTC
Délai échéance de la facture
Echéance
Montant
Règlement
Montant
Délai échéance du règlement
Tableau 2.2 : Liste des mesures
2.5.1 Recensement des dimensions
Le tableau ci-dessous récapitule l’ensemble des dimensions dégagés précédemment à partir des
besoins :
Dimension
Description
Date
La dimension temporelle (Années, Mois, Trimestres, Jours)
Article
Les articles commandés par les clients
Client
Les clients qui passent les commandes
Affaire
Une affaire contient plusieurs commandes et liée à un seul client
Site
Indique les sites de vente et d’expédition
Ville
Représente la dimension géographique
CP
Indique la condition de paiement de la commande
Représentant
Indique le représentant de la vente « Commercial »
Transporteur
Le transporteur de la livraison
TP
Représente les types de pièces
39
Tiers
Représente les clients et les fournisseurs de l’entreprise
Transaction
La transaction financière entre les clients ou les fournisseurs
Banque
Les différentes banques en relation avec l'entreprise
DétailsCom
Une dimension contenant des détails sur les commandes
DétailsLiv
Une dimension contenant des détails sur les livraisons
DétailsFac
Une dimension contenant des détails sur les factures
DétailsEch
Une dimension contenant des détails sur les échéances
DétailsReg
Une dimension contenant des détails sur les règlements
Tableau 2.3 : Liste des dimensions
2.6 Périmètre technique du projet
Cette partie est consacré à la boîte à outils utilisée pour la réalisation de ce projet, ceci en spécifiant
les différents outils utilisés et les notions nécessaires pour la bonne compréhension de l’aspect
technique du projet ou on va traduire les besoins fonctionnels en fonctionnalités logicielles.
L'architecture technique de la solution peut être représentée en trois niveaux :
❖ La collecte de donnée : la collecte de données est assurée par des outils nommés ETL,
elle se compose de :
• L’extraction des données : Cette extraction vise à obtenir les données à partir de
la base de données relationnelle « SQL Server » de la société qui réside dans un
serveur distant « 172.16.16.100/sagex3 », des fichiers Excel, ou directement à
partir de l’ERP interne.
• La transformation des données : Comme les données sont de formats différents, le
but de cette phase est de les rendre cohérents et utilisables entre elles, la
transformation aura aussi pour but de commencer à agréger les données pour les
rendre plus facilement exploitables. On va transformer les données au niveau de
l’ETL.
• Le chargement : Il permet l’injection des données dans une base de données
décisionnelle « 172.16.16.100/intersigbi ».
❖ Le stockage : les bases de données utilisées pour le stockage sont différentiées des bases
opérationnelles. En effet, il n’est pas souhaitable de ralentir les outils de production à chaque
fois que l’on veut faire une extraction de données. Ainsi, le stockage des données se fait dans
40
un entrepôt de données. Ce dernier gère aussi l’historisation des données pour permettre
d’avoir des vues évoluant dans le temps.
❖ L’exploitation de données : la finalité des étapes d’extraction, de stockage et de diffusion
est d’apporter à l’utilisateur final des données exploitables de différentes façons.
• Diffusion de rapports.
• Tableaux de bord.
• Analyse décisionnelle.
Figure 2.2 : Architecture de la solution
2.7 Environnement de travail
La réalisation d’une solution décisionnelle est connue par la diversité des outils qui peuvent accomplir
le fonctionnement du processus de traitement de l’information. La meilleure technologie à adopter est
définie par les critères fonctionnels et ergonomiques, la sécurité et la compatibilité avec la pérennité
de la solution.
41
2.7.1 Benchmarking des outils BI
Après avoir représenté l’architecture du projet, il s’avère nécessaire de sélectionner les composants
matérielles, logicielles, SGBD de l’entrepôt de données, Outils ETL, Outil de création des rapports et
tableau de bord.
Chaque jour un nouvel outil apparait dans le marché, il est devenu difficile de choisir quel outil opter.
La meilleure façon pour choisir un outil est d’évaluer ce dernier à travers des critères. Afin d’évaluer
les outils BI on a opté pour un comparatif des produits qui représentent les meilleures solutions,
d’exploration des données, qui existent sur le marché.
Comparatif des outils ETL :
Pour la phase d’alimentation, il existe différents outils ETL, chacun possède des points forts et des
points faibles. Parmi les outils les plus utilisés, on trouve :
Tableau 2.4 : Comparatif des outils ETL
Comparatif des outils de Reporting :
Pour la phase de restitution, il existe différents outils de reporting, chacun possède des points forts et
des points faibles. Parmi les outils les plus utilisés, on trouve :
42
Tableau 2.5 : Comparatif des outils de reporting
2.7.2 Choix des outils BI
D’après le Benshmarking qu’on a réalisé précédemment et en se basant sur les besoins des
responsables, on a opté pour un outil dans chaque phase :
43
L’alimentation : Pour la préparation de données, et après la comparaison qu’on
a fait entre les différents outils ETL on se trouve face à un ensemble d’avantage
présenté par l’outil Talend qui manquent en d’autres outils. C’est un outil facile
et rapide, permet le développement simplifié des ETL, en mettant à la disposition
de l’utilisateur, dans une interface d’édition graphique, un large éventail de
fonctionnalités avec un bon rapport qualité-prix.
Le stockage : Les données seront stockées dans Microsoft SQL Server, qui un
produit de Microsoft servant de système de gestion de bases de données. Pour
la raison que l’entreprise utilise SQL Server comme un SGBDR. De plus, SQL
Server fournit une solution intégrée d’analyse et de gestion de base de données,
chose qui rend les données de l’entreprise facilement gérables et le
développement plus fluide. Cette intégrité de SQL Server fait qu’elle réduit la
complexité en temps et en développement de la création, le déploiement et la gestion des données de
l’entreprise qui proviennent de plusieurs sources hétérogènes.
La restitution : Nous utiliserons pour cette partie un produit de Microsoft : la
composante Microsoft Power BI. Notre choix basé sur les besoins des décideurs
qui consistent en des rapports paginés et des rapports mobiles. Power BI sera
donc l’outil de restitution des rapports mensuels et annuels le plus adapté.
Conclusion
Dans ce chapitre, nous avons commencé par une étude de l’ancienne solution pour la prise de décision
au sein d’INTERSIG MAROC, nous avons pu identifier les limites et les problématiques de cette
dernière. Et après avoir assimilé les besoins recueillis par les décideurs, nous avons pu ressortir les
indicateurs et les axes d’analyse relatifs au suivi des activités de vente. Enfin, nous avons défini
l’architecture de notre système et précisé les outils décisionnels adoptés à savoir les composantes
Talend, SQL Server et Power BI, avant de passer à la partie conception qui fera l’objet du chapitre
suivant.
Figure 2.3 : Logo
Talend
Figure 2.5 : Logo
Power BI
Figure 2.4 : Logo SQL
Server
44
3
Modélisation et Conception
Introduction
Une fois les besoins des utilisateurs connus, nous pouvons commencer à concevoir les volets de notre
datawarehouse. Pour cela, dans ce chapitre nous avons eu recours à la modélisation dimensionnelle
qui est souvent associée aux entrepôts de données compte tenu de ses avantages.
Cependant, avant de se lancer dans la modélisation, il est intéressant de classer les sujets recensés
selon l’intérêt qu’ils représentent pour l’entreprise et les facilités de réalisation. Ce classement nous
aidera à choisir l’activité à modéliser en premier lieu de manière à garantir des résultats satisfaisants
pour l’entreprise.
3.2 Modélisation d’un Datawarehouse
3.2.1 Datawarehouse (Entrepôt de données)
D’après Kimball : un Data Warehouse est l’ensemble des données répertoriées, nettoyées, valides,
complètes et cohérentes d'une entreprise
[7]
.
Et Bill Inmon définit le Data Warehouse, dans son livre considéré comme étant la référence dans le
domaine “Building the Data Warehouse”
[8]
comme suit : « 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. »
Les paragraphes suivants illustrent les caractéristiques citées dans la définition d’Inmon :
❖ Orienté sujet : Le Data Warehouse est organisé autour des sujets majeurs de l’entreprise,
contrairement à l’approche transactionnelle utilisée dans les systèmes opérationnels, qui sont
conçus autour d’applications et de fonctions telles que : cartes bancaires, solvabilité client…,
les Data Warehouse sont organisés autour de sujets majeurs de l’entreprise tels que : clientèle,
ventes, produits…. Cette organisation affecte forcément la conception et l’implémentation des
45
données contenues dans le Data Warehouse. Le contenu en données et en relations entre elles
diffère aussi. Dans un système opérationnel, les données sont essentiellement destinées à
satisfaire un processus fonctionnel et obéit à des règles de gestion, alors que celles d’un Data
Warehouse sont destinées à un processus analytique.
❖ Intégrée : Le Data Warehouse va intégrer des données en provenance de différentes sources.
Cela nécessite la gestion de toute incohérence.
❖ Evolutives dans le temps : Dans un système décisionnel il est important de conserver les
différentes valeurs d’une donnée, cela permet les comparaisons et le suivi de l’évolution des
valeurs dans le temps, alors que dans un système opérationnel la valeur d’une donnée est
simplement mise à jour. Dans un Datawarehouse chaque valeur est associée à un moment «
Every key structure in the data warehouse contains - implicitly or explicitly - an element of
time »
[8]
.
❖ Non volatiles : C’est ce qui est, en quelque sorte la conséquence de l’historisation décrite
précédemment. Une donnée dans un environnement opérationnel peut être mise à jour ou
supprimée, de telles opérations n’existent pas dans un environnement Data Warehouse.
3.2.2 Datamart (Magasin de données)
Les Datamarts ou les Magasin de données sont des sous-ensembles du DWH ou les données sont
organiser selon des domaines ciblés ou selon les besoins métiers de chaque entreprise, c’est dans ce
sens ou les Datamarts ne contient que les données utiles pour l’entreprise.
La différence entre le Datawarehouse et le Datamart a été considéré de deux manières différentes
selon, les deux informaticiens américains et les principaux théoriciens de l’informatique
décisionnelle, Bill Inmon et Ralph Kimball : Selon Bill Inmon, le Magasin de données est un flux de
données fonctionnelles et spécifique pour l’usage métiers, ce flux provient de l’entrepôt de données
[6]
.
En revanche, Ralph Kimball définit le Datamart comme étant un sous-ensemble de l’entrepôt de
données, regroupant des tables avec des données avec un niveau détaillé et d’autres avec niveau plus
agrégé, dans le but est d’augmenter la rapidité d’accès aux données, facilité l’accès aux données et
bien représenter les données métiers d’une entreprise
[6]
.
46
3.2.3 Objectifs de l’entrepôt de données
Parmi les objectifs d’un entrepôt de données, il permet de :
• Regrouper, organiser des données provenant de sources diverses.
• Les intégrer et les stocker pour donner à l’utilisateur une vue orientée métier.
• Retrouver et analyser l’information selon plusieurs critères.
• Transformer un système d’information qui avait une vocation de production en un SI
décisionnel.
• Doit contenir des données cohérentes.
• Les données doivent pouvoir être séparées et combinées au moyen de toutes les mesures
possibles de l’activité.
• Le DW ne contient pas uniquement des données, mais aussi un ensemble d’outils de requêtes,
d’analyse et de présentation de l’information.
3.2.4 Méthodologie de construction d'un DWH
Il y a trois méthodes communément utilisées pour mettre en place un entrepôt de données (Data
Warehouse), haut en bas (Top-Down) et bas en haut (Bottom-up) et hybride (Middle-out) relative aux
deux théoriciens de l’informatique décisionnel Inmon et Kimball.
L’approche « Top-Down »
C’est une approche descendante qui consiste à créer un entrepôt de donnée centrale, normalisé (3FN)
qui regroupe des données atomiques (détaillées) provenant des différents systèmes de production de
l’entreprise. Une fois que l’entrepôt de donnée est conçu, on commence à créer les Datamarts, chaque
Datamart contient les informations nécessaires pour répondre aux besoins analytiques d’un métier
donné.
Cette approche consiste à construire le schéma de l’entrepôt de données qui a été proposé par Inmon
[8]
, qui démarre du fait que les besoins des utilisateurs sont en perpétuelle évolution ce qui rend inutile
de donner une solution basée sur les besoins, il préfère donc se baser sur les sources de données et
d’essayer de centraliser toutes les données venant des différentes sources dans un entrepôt de donnée
47
ou ils seront historiés et intégrés. Une fois que l’entrepôt est conçu, on passe vers une autre étape qui
est la compréhension des besoins d’utilisateurs puis leurs livrer les données qu’ils ont besoins sous
forme des Datamarts, et la figure suivante illustre cette démarche :
Figure 3.1 : Architecture du DWH selon Inmon
L’approche « Bottom-Up »
C’est une approche ascendante qui consiste à créer des DMs avec des faits et des dimensions
conformes qui vont faire l’objet de l’entrepôt de données.
Cette approche consiste à construire le schéma de l’entrepôt de données qui a été proposé par Kimball
[7]
, qui démarre du fait que l’objectif principale d’un entrepôt de données est de répondre aux besoins
analytiques des utilisateurs, pour cela il faut passer par une phase de collecte de besoins afin de bien
les définir, Kimball suppose que le fait d’avoir des DMs, avec des faits et des dimensions conformes,
permet de faire introduire de nouvelles données dont le but de répondre à d’autres besoins non prévus
au départ.
L'avantage de cette méthode est qu'elle est simple à réaliser (une étoile à la fois) par contre
l'inconvénient est le volume de travail d'intégration pour obtenir un entrepôt de données ainsi que la
possibilité de redondances entre les étoiles, et la figure suivante illustre cette démarche :
48
Figure 3.2 : Architecture du DWH selon Kimball
L’approche hybride « Middle-Out »
C’est une combinaison entre les deux autres approches afin de profiter des avantages de chacune.
L’idée dans cette approche réside dans le fait de construire des schémas candidats à partir des données.
Ainsi, le schéma construit constitue une réponse aux besoins réels d’analyse et il est également
possible de le mettre en œuvre avec les sources de données.
Choix de l’approche
Afin de choisir entre ces deux approches il fait présenter les avantages et les inconvénients de chacune
d’elles. Ci-dessous un tableau qui représente les avantages et les inconvénients de chaque approche.
Approche
Critères
Approche « Top-Down »
d’INMON
Approche « Bottom-Up »
de Kimball
Flexibilité a l’évolution des
besoins
Inflexible a l’évolution des
besoins
Puisque cette approche est
orientée domaine, elle est
plus flexible à l’évolution des
besoins
Temps de mise en œuvre
Le temps de mise en œuvre
est long
Grâce aux modèles
dimensionnelles incrémental
49
le temps de mise en œuvre
est court
Coût de mise en œuvre
Coût assez conséquent
Coût faible
Complexité de Modèle
Modèle centraliser et
complexe
Segmenter en un certain
nombre de Datamarts
logiques et cohérents
Tableau 3.1 : Avantages et inconvénients des approches de Kimball et d’Inmon
D’après ce tableau on a constaté que l’approche de Kimball sera plus adaptée à notre projet, puisque
notre solution proposée sera orientée au domaine de vente, de plus parmi les besoins de chaque
entreprise l’optimisation des coûts et de temps.
3.2.5 La modélisation dimensionnelle
Dans les dernières années, pour résoudre les problèmes de performances liés aux requêtes
volumineuses dans l'entrepôt de données, on utilise des modèles dimensionnels. L'approche de la
modélisation dimensionnelle permet d'améliorer les performances des requêtes pour les rapports
récapitulatifs sans affecter l'intégrité des données
[9]
.
Un modèle dimensionnel est très populaire dans l'entreposage de données car il peut fournir de bien
meilleures performances de requête, en particulier sur des requêtes très volumineuses, qu'un modèle
relationnel. D’autre part un modèle dimensionnel distingue entre deux types de présentation des
données, le premier sont les données de la table de fait qui sont des mesures et des indicateurs,
autrement dit celles qu’on voudra analyser sont stockées dans la table de fait. La deuxième structure
est pour les dimensions qui présentent les axes avec lesquels on veut faire l’analyse, c’est-à-dire elles
fournissent le contexte du sujet à analyser
[9]
.
Alors pour la modélisation d’un Datawarehouse il existe trois modèles :
❖ Modèle en étoile :
Un schéma en étoile a pour caractéristique de centrer une table des faits et la relier à chaque table de
dimension, dont les liens entre les clés primaires de la table de faits et les clés étrangères dans les
50
tables de dimension peuvent être visualisés avec la table de faits au milieu. Cela améliore les
performances des requêtes, mais augmente les volumes de données.
Figure 3.3 : Modélisation en étoile
❖ Modèle en flocon :
Le schéma flocon est une extension du schéma en étoile, où chaque point de l'étoile explose en plus
de points. Dans un schéma en étoile, chaque dimension est représentée par une table à une seule
dimension, alors que dans un schéma en flocon, cette table dimensionnelle est normalisée en plusieurs
tables de look up, chacune représentant un niveau dans la hiérarchie dimensionnelle.
Figure 3.4 : Modélisation en flocon
51
❖ Modèle en constellation :
Ce modèle est un ensemble de schémas en étoiles et/ou en flocon dans lesquels les tables de faits se
partagent certaines tables de dimensions. C’est de cette accumulation que découle un modèle en
constellation.
Figure 3.5 : Modélisation en constellation
3.2.6 Choix du modèle
Afin de choisir entre les différents modèles il fait présenter les avantages et les inconvénients de
chacun d’eux. Ci-dessous un tableau qui représente les avantages et les inconvénients de chaque
modèle.
Modèle en étoile
Modèle en flocon
Table de fait
Table centrale regroupant les
mesures
Table centrale regroupant les
mesures
Table de dimension
Dénormalisation des
dimensions (une table par
dimension)
Normalisation des
dimensions (possibilité de
regrouper plusieurs tables par
dimension)
52
Avantages
Facilité de navigation,
nombre de jointures limité,
fiabilité des résultats
Réduction de volumes si les
tables et les dimensions sont
volumineuses
Inconvénients
Redondance dans les
dimensions, alimentation
complexe
Navigation difficile,
nombreuses jointures
Tableau 3.2 : Comparaison entre le modèle en étoile et le modèle en flocon
Le modèle en étoile s’avère le plus adéquat dans notre cas. En effet, le but principal d’un système BI
est de faciliter la navigation dans les données, et répondre rapidement aux requêtes des utilisateurs
sans se soucier de la phase d’alimentation. Et puisqu’on a des tables de faits partagent certaines tables
de dimensions on peut dire que la modélisation globale est une modélisation en constellation.
3.3 Conception de la zone d’entreposage
Après avoir déterminé les axes d’analyse et les indicateurs de performance de notre projet ainsi que
le choix du modèle dimensionnel, il s’avère nécessaire de réaliser une conception détaillée de la
solution BI.
Conceptuellement notre entrepôt de données contient 5 tables de faits et 18 dimensions, et les données
sont représentées avec une modélisation en étoile pour chaque activité parmi les 5 activités
« Commande, Livraison, Facture, Echéance, Règlement ». Les figures ci-dessous représente la
conception de notre projet pour chaque sujet.
53
Le sujet « Commande »
Figure 3.6 : Conception de l'activité « Commande »
Affaire
Affaire_key
Affaire_ID
[Dénomination Affaire]
source_system_code
start_date
end_date
is_current
Date_cre
Article
Article_key
Article_ID
[Famille Statistique]
[Statut Article]
[Gestion de stock]
[Mode de gestion]
[Gestion de lot]
[DA Obligatoire]
Fabriqué
[Sous traité]
Générique
[Unité stock]
[Unité achat]
[Unité vente]
[Code Comptable]
Designation
[Categorie Article]
[Gestion emplacement]
[Mode retrait stock]
[Mode inventaire]
[Mode réapprovisionnement]
[Type suggestion]
source_system_code
start_date
end_date
is_current
Client
Client_key
Client_ID
Client
[Type Client]
[Client actif]
[Client prospect]
Devise
Controle
[Catégorie Client]
source_system_code
start_date
end_date
is_current
Date_cre
Commande
Article_key
Client_key
Ville_key
Affaire_key
CP_key
Rep_key
Junk_key
Site_vente_key
Site_exp_key
Date_commande_key
Date_exp_key
Commande_ID
Nb_ligne
[Quantité Commandée]
[Quantité Livrée]
[Quantité Facturée]
[Prix HT]
[Prix TTC]
[Montant commandé]
[Montant livré]
[Montant facturé]
[Délai Livraison]
[Délai production]
created_at
Date_cre
CP
CP_key
CP_ID
[Condition de paiement]
source_system_code
start_date
end_date
is_current
Date_cre
Date
date_key
Date
JourNum
Jour
MoisNum
Mois
Quarter
Année
DétailsCom
Junk_key
[Categorie Commande]
[Autorisation Solde]
[Mode Facturation]
[ARC Imprimé]
Déblocage
[Etat Commande]
[Etat Livraison]
[Etat Facture]
[Etat Crédit]
Signée
[Transaction]
source_system_code
start_date
end_date
is_current
Représentant
Rep_key
Rep_ID
Commercial
source_system_code
start_date
end_date
is_current
Date_cre
SiteVente
Site_key
Site_ID
Site
source_system_code
start_date
end_date
is_current
Date_cre
Ville
Ville_key
Ville_ID
Ville
source_system_code
start_date
end_date
is_current
Date_cre
54
Le sujet « Livraison »
Figure 3.7 : Conception de l'activité « Livraison »
Affaire
Affaire_key
Affaire_ID
[Dénomination Affaire]
source_system_code
start_date
end_date
is_current
Date_cre
Article
Article_key
Article_ID
[Famille Statistique]
[Statut Article]
[Gestion de stock]
[Mode de gestion]
[Gestion de lot]
[DA Obligatoire]
Fabriqué
[Sous traité]
Générique
[Unité stock]
[Unité achat]
[Unité vente]
[Code Comptable]
Designation
[Categorie Article]
[Gestion emplacement]
[Mode retrait stock]
[Mode inventaire]
[Mode réapprovisionnement]
[Type suggestion]
source_system_code
start_date
end_date
is_current
Date_cre
Client
Client_key
Client_ID
Client
[Type Client]
[Client actif]
[Client prospect]
Devise
Controle
[Catégorie Client]
source_system_code
start_date
end_date
is_current
Date_cre
CP
CP_key
CP_ID
[Condition de paiement]
source_system_code
start_date
end_date
is_current
Date_cre
Date
date_key
Date
JourNum
Jour
MoisNum
Mois
Quarter
Année
DétailsLiv
Junkl_key
Prête
[Régime Taxe]
[Mode Facturation]
[Etat Retour]
Facturée
Validée
source_system_code
start_date
end_date
is_current
Livraison
Article_key
Client_key
Ville_key
Affaire_key
CP_key
Rep_key
Trans_key
Junkl_key
Site_vente_key
Site_exp_key
Date_exp_key
Livraison_ID
Commande_ID
Nb_ligne
[Quantité Livrée]
[Quantité Retournée]
[Prix HT]
[Prix TTC]
[Montant Livré]
[Montant Retourné]
Date_cre
created_at
Représentant
Rep_key
Rep_ID
Commercial
source_system_code
start_date
end_date
is_current
Date_cre
SiteVente
Site_key
Site_ID
Site
source_system_code
start_date
end_date
is_current
Date_cre
Transporteur
Trans_key
Trans_ID
[Nom Transporteur]
source_system_code
start_date
end_date
is_current
Date_cre
Ville
Ville_key
Ville_ID
Ville
source_system_code
start_date
end_date
is_current
Date_cre
55
Le sujet « Facture »
Figure 3.8 : Conception de l'activité « Facture »
Article
Article_key
Article_ID
[Famille Statistique]
[Statut Article]
[Gestion de stock]
[Mode de gestion]
[Gestion de lot]
[DA Obligatoire]
Fabriqué
[Sous traité]
Générique
[Unité stock]
[Unité achat]
[Unité vente]
[Code Comptable]
Designation
[Categorie Article]
[Gestion emplacement]
[Mode retrait stock]
[Mode inventaire]
[Mode réapprovisionnement]
[Type suggestion]
source_system_code
start_date
end_date
is_current
Date_cre
Client
Client_key
Client_ID
Client
[Type Client]
[Client actif]
[Client prospect]
Devise
Controle
[Catégorie Client]
source_system_code
start_date
end_date
is_current
Date_cre
CP
CP_key
CP_ID
[Condition de paiement]
source_system_code
start_date
end_date
is_current
Date_cre
Date
date_key
Date
JourNum
Jour
MoisNum
Mois
Quarter
Année
DétailsFac
Junkf_key
[Catégorie Facture]
[Etat Facture]
[Fac Directe]
Impression
source_system_code
start_date
end_date
is_current
Facture
Article_key
Client_key
CP_key
Rep_key
TP_key
Junkf_key
Site
Date_comptable_key
Facture_ID
ligne_fac
Livraison_ID
ligne_liv
Commande_ID
ligne_com
Quantité
Commission
[Prix HT]
[Prix TTC]
[Montant HT]
[Délai échéance]
Date_cre
created_at
Représenta nt
Rep_key
Rep_ID
Commercial
source_system_code
start_date
end_date
is_current
Date_cre
SiteVente
Site_key
Site_ID
Site
source_system_code
start_date
end_date
is_current
Date_cre
TP
TP_key
TP_ID
[Type de pièce]
source_system_code
start_date
end_date
is_current
Date_cre
56
Le sujet « Echéance »
Figure 3.9 : Conception de l'activité « Echéance »
Date
date_key
Date
JourNum
Jour
MoisNum
Mois
Quarter
Année
DétailsEch
Junke_key
[Mode Réglement]
Relance
[Type échéance]
Collectif
source_system_code
start_date
end_date
is_current
Echeance
Tiers_key
TP_key
Junke_key
Site
Date_echeance_key
Num_piece
ligne
Montant
Date_cre
created_at
SiteVente
Site_key
Site_ID
Site
source_system_code
start_date
end_date
is_current
Date_cre
Tiers
Tiers_key
Tiers_ID
Tier
Client
Fournisseur
Représentant
Transporteur
Prospect
source_system_code
start_date
end_date
is_current
Date_cre
TP
TP_key
TP_ID
[Type de pièce]
source_system_code
start_date
end_date
is_current
Date_cre
57
Le sujet « Règlement »
Figure 3.10 : Conception de l'activité « Règlement »
Banque
Banque_key
Banque_ID
Nature
Désignation
source_system_code
start_date
end_date
is_current
Date_cre
Date
date_key
Date
JourNum
Jour
MoisNum
Mois
Quarter
Année
DétailsReg
Junkr_key
Collectif
[Mode Réglement]
[Type tiers]
Etat
[Type remise]
Destination
source_system_code
start_date
end_date
is_current
Reglement
Tiers_key
Transaction_key
Banque_key
Junkr_key
Site
Date_comptable_key
Num_reglement
ligne
Montant
[Délai échéance]
Date_cre
created_at
SiteVente
Site_key
Site_ID
Site
source_system_code
start_date
end_date
is_current
Date_cre
Tiers
Tiers_key
Tiers_ID
Tier
Client
Fournisseur
Représentant
Transporteur
Prospect
source_system_code
start_date
end_date
is_current
Date_cre
Transaction
Transaction_key
Transaction_ID
Désignation
source_system_code
start_date
end_date
is_current
Date_cre
58
La zone d’entreposage constitue la zone exploitable par les utilisateurs. La modélisation de cette zone
se fait grâce à la modélisation dimensionnelle. Cette manière de représenter les données offre aux
utilisateurs des modèles intuitifs et compréhensibles permettant de naviguer et de manipuler les
données, détaillées ou agrégées, sans difficulté afin de satisfaire leurs besoins en analyse. La
finalisation de la conception d’une étoile de l’entrepôt, nous permet de passer à la construction de la
zone d’alimentation. Cette zone d’alimentation constitue l’objet de la prochaine partie.
3.4 Conception de la zone d’alimentation
L’alimentation du datawarehouse, est une étape des plus importantes dans un projet décisionnel, elle
représente 80% de la charge de travail. Cette étape a pour objectif d’assurer l’acheminement des
données des systèmes sources jusqu’à l’entrepôt de données, en passant par les différentes phases de
nettoyage et de transformations nécessaires.
Le diagramme d’activités suivant décrit le processus général de l’alimentation de l’entrepôt de
données dès sa mise en service :
59
Figure 3.11 : Diagramme d’activité du processus d’alimentation
Deux types de tables dans l’entrepôt de données « faits, dimensions » doivent être distingués, chaque
type de table diffère dans les informations qu’il contient, alors les tables de dimension doivent être
chargées avant les tables de faits, et s’il y a un problème lors de chargement des tables de dimensions,
donc on doit faire appel à un chargement de secours (afficher un avertissement et continuer le
chargement), sinon le chargement doit s’arrêter en affichant l’erreur.
Conclusion
Dans cette partie, le datawarehouse est modélisé pour répondre à tous les besoins utilisateurs et aux
contraintes techniques, ainsi on a défini le diagramme d’activité pour le développement des processus
d’intégration de données. Cette conception est essentielle pour la phase de réalisation qui constitue
l’objet du chapitre suivant.
60
4
Implémentation et Tests
Introduction
Ce chapitre a pour objectif de présenter la phase de réalisation qui concrétise la conception exposée
lors du chapitre précédent. La réalisation des rapports de l’activité de vente commencera par
l’implémentation de la phase d’ETL : son architecture et le chargement des dimensions et des tables
de faits. Par la suite, le traitement et la restitution des rapports et des tableaux de bord de cette activité.
Et vers la fin effectuer les différents tests sur notre solution, afin de vérifier si les objectifs fixés ont
été réalisés ou non.
4.2 Réalisation de la phase d’ETL
Cette partie porte sur l’implémentation du Datawarehouse et le développement de l’ETL, à l’aide de
l’outil de Microsoft SQL Server à savoir SSMS et Talend qui a pour but la réalisation de l’ETL.
4.2.1 Collecte des données
Pour commencer le processus de l’ETL, et vu que la diversité et la difficulté d’avoir toutes les données
nécessaires à la réalisation du projet, il faut bien collecter toutes ces données qui sont disponibles pour
l’atteinte des objectifs fixés auparavant. Les données qui seront chargées d’implémenter la solution
provient du système d’information de l’entreprise, qui résident dans une base de données relationnelle,
et dans des fichiers Excel. Alors après avoir regrouper toutes les données pour la réalisation du
système décisionnel, le développement de l’ETL nécessite la création de la base de données et les
tables au niveau de SQL Server, et ensuite le chargement des différentes bases de données.
61
4.2.2 Création des tables du Datawarehouse
Après avoir intégré les données dans SSMS, l’étape suivante consiste sur la création des tables du
Datawarehouse.
Pour la création des tables Microsoft SQL Server offre une diversité des méthodes de création, la
première est avec l’interface graphique, et la deuxième avec le langage SQL, entre autres la méthode
de requêtes SQL que nous avons opté pour créer les tables, créer les attributs et définir leur type.
Ensuite, on a créé les clés primaires de chaque table et leurs clés étrangères dans la table de fait, puis
insérer les relations entre ces clés.
Les figures suivantes représentent un exemple de la création d’une table de faits et d’une dimension
au niveau de notre entrepôt de données, ainsi que l’ensemble des tables de faits et des dimensions
dans notre DWH « INTERSIG » :
Figure 4.1 : Exemple de la création d'une table de faits
62
Figure 4.2 : Exemple de la création d'une dimension
63
Figure 4.3 : Les tables de faits et les dimensions du DWH
4.2.3 Alimentation du Datawarehouse
Après la collecte des données et la structure du Datawarehouse est définit, l’étape suivante est le
processus ETL (Extraction, Transformation, Load) pour extraire des données de la source et les
charger dans le Datawarehouse, il s'agit simplement d'un processus de copie de données d'une base
de données vers une autre. Ensuite de réaliser des transformations sur les données.
Les transformations qu’on a utilisé dans notre projet sont le filtrage, le tri, La conversion des données,
colonnes dérivés, Jointure de fusion des données.
• Filtrage : filtrer les tables par colonnes et par lignes.
• Tri : la transformation tri sert à supprimer les doublons et les cases vides et également il
permet de trier les données dans un ordre croissant ou décroissant.
• Conversion des données : cette transformation permet de changer le type de données de notre
64
source afin qu’il soit adéquat avec notre destination.
• Colonnes dérivées : cette transformation permet la mise à jour des données en utilisant des
expressions pour calculer des nouvelles données.
• Jointure de fusion : la jointure de fusion permet de réunir des entrés de données et de ressortir
de nouvelles données triées et associés.
L’ETL de notre projet a été réalisée en utilisant l’outil Talend Open Studio for Data Integration.
Premièrement pour utiliser les données au niveau de l’ETL, il faut connecter ce dernier avec les
différentes sources de données [Annexe 1], et le connecter avec l’entrepôt de données pour effectuer
le chargement par la suite [Annexe 2].
Chargement des dimensions
Notre entrepôt de données contient 18 tables de dimensions et qui seront chargées automatiquement
par des jobs reliant les sources de données à l’entrepôt de données « INTERSIG ». Cependant
l'alimentation se fait au moyen des jobs. Le Job Talend est l’implémentation technique d’un business
model. Il traduit les besoins métier en code et programmes et se charge de les exécuter. Et c’est une
représentation graphique d’un ou plusieurs composants reliés entre eux. Les jobs peuvent être
réutilisés, synchronisés entre eux et hiérarchisés en jobs principaux et sous-jobs. Dans chaque job on
peut exécuter plusieurs transformations sur les données sources afin de les charger dans les tables
destination.
• La dimension « Article »
La figure ci-dessous représente un exemple de chargement de la dimension « Article » :
65
Figure 4.4 : ETL de la dimension « Article »
Ci-dessous la structure de la dimension « Article » au niveau de l’entrepôt de données :
Figure 4.5 : Vue sur les données de la dimension « Article »
66
• La dimension « Date »
En ce qui concerne la dimension date on a choisi de réaliser le chargement à partir d’un fichier CSV.
Ceci de la faite que la dimension date est inchangeable, sa création nécessite la fixation d’une période
de temps par exemple : de 2017 jusqu'à 2021, et ensuite on ajoute les attributs qui doivent être en
correspondance avec les objectifs du projet.
La figure ci-dessous représente un exemple de chargement de la dimension « Date » :
Figure 4.6 : ETL de la dimension « Date »
Ci-dessous la structure de la dimension « Date » au niveau de l’entrepôt de données :
67
Figure 4.7 : Vue sur les données de la dimension « Date »
Chargement de la table de faits
Le chargement des données dépend principalement de la situation, du volume des données, et des
types des données sources, etc. Alors plusieurs critères sont à prendre en compte afin de bien choisir
la méthode convenable pour effectuer l’intégration des données. Dans ce cas, on a rassemblé les
données en les collectant à partir de plusieurs sources de différents formats. Notre entrepôt de données
contient 5 tables de faits et qui vont regrouper les données en provenance des tables de dimensions.
Dans ces tables de faits sera chargé également les indicateurs et les mesures fixés pour les objectifs
du projet.
La figure ci-dessous représente un exemple de chargement de la table de faits « Commande » :
68
Figure 4.8 : ETL de la table de faits « Commande »
Ci-dessous la structure de la table de faits « Commande » au niveau de l’entrepôt de données :
Figure 4.9 : Vue sur les données de la table de faits « Commande »
69
4.3 Restitution des données
La phase de restitution constitue la dernière étape dans un projet BI, cette phase offre aux utilisateurs
finaux une analyse poussé des données à travers le datamining, il permet la mise en disposition des
rapports et la production des tableaux de bords afin de synthétiser les différents critères de
performance. En outre la restitution permet de traiter le même résultat tout en naviguant sur les
différentes dimensions.
Power BI est un outil de l’éditeur Microsoft, il est dédié au reporting et qui est destiné essentiellement
à l’usager de Business Intelligence. Il donne la possibilité d’avoir une connexion aux plusieurs sources
de données, peu importe leurs types ou leurs emplacements.
Le reporting permet de présenter l'information nécessaire de manière concise, précise et simple à
analyser par les décideurs et statisticiens. De ce fait, ceux-ci peuvent observer d’une manière continue
l’évolution de leurs indicateurs dans le temps. Or, cet outil est connu par sa simplicité et le but de son
développement est de permettre à un utilisateur de réaliser un reporting de haut niveau.
Tandis qu’on a utilisé SQL Server dans la création du Datawarehouse, alors Microsoft Power BI doit
se connecter pour importer les entrepôts de données. Après le chargement des données depuis SQL
Server, l’étape suivante est celle de la création des tableaux de bord, pour cela Microsoft BI offre une
diversité de type des graphiques.
Figure 4.10 : Types des graphiques de Power BI
Avec la sélection du type de graphiques et de cartes convenables à utiliser sur les rapports pour
présenter les données à travers la rubrique dédiée au type de la visualisation. Et suite, il faut
sélectionner les champs des données pour créer des tableaux de bord et des rapports significatifs.
70
Figure 4.11 : La sélection des champs
Ci-dessous quelques exemples des rapports et tableaux de bord qu’on a réalisé lors du projet :
Tableaux de bord 1 : Ce tableau de bord définit la différence en termes de pourcentage entre les
différents montants et quantités selon le besoin des décideurs commerciaux.
Figure 4.12 : Les différences entre les différentes quantités et montants
71
Tableaux de bord 2 : Ce tableau de bord définit la différence entre le montant commandé et le
montant facturé par désignation produit, par site de vente et par région.
Figure 4.13 : La différence entre le montant commandé et le montant facturé
Tableaux de bord 3 : Ce tableau de bord permet la visualisation des quantités commandées par les
différents types et états des commandes.
Figure 4.14 : Analyse des quantités commandés par types et états de commandes
Rapport 1 : Ce rapport permet de savoir le taux d’évolution d’un commercial, un client, un article,
72
et une affaire en termes de montant commandé par rapport au mois précédent ou par rapport à l’année
dernière.
Figure 4.15 : Rapport MC Année-1 / Mois-1
Rapport 2 : Ce rapport permet de savoir le taux d’évolution d’un client et d’un transporteur en
termes de montant livré par rapport à l’année dernière.
73
Figure 4.16 : Rapport ML Année-1
Rapport 3 : Ce rapport permet d’analyser la performance des livraisons de l’entreprise INTERSIG
MAROC par plusieurs axes d’analyses selon le besoin des décideurs commerciaux.
74
Figure 4.17 : Rapport pour l'analyse de la performance des livraisons
Rapport 4 : Ce rapport permet d’analyser la performance commerciale globale de l’entreprise
INTERSIG MAROC par plusieurs axes d’analyses selon le besoin des décideurs commerciaux.
75
Figure 4.18 : Rapport pour l'analyse de la performance commerciale globale de l’entreprise
4.4 Tests et résultats
Ce chapitre a pour objectif de présenter les différents tests effectués sur la solution réalisée, afin de
vérifier si les objectifs fixés ont été réalisés ou non.
4.4.1 Temps de traitement
Le besoin principal de cette solution est de permettre aux responsables d’avoir une vue sur les données
de façon quotidienne. Vu que le système précédent ne pouvait effectuer les rapports que sur une durée
d’une à deux semaines.
Ce test consiste à lancer le traitement ETL et le traitement nécessaire pour avoir les données visuelles.
Le traitement ETL
Après avoir démarré le processus du traitement ETL. On démarre le chronomètre pour récupérer le
temps d’exécution du processus ETL.
76
Figure 4.19 : Test de traitement ETL
De l’ETL à la restitution
Après avoir restituer les données. On démarre le chronomètre pour récupérer le temps de récupération
des données depuis notre entrepôt de données vers l’outil de restitution.
Figure 4.20 : Test de traitement DWH vers Power BI
77
4.4.2 Intégrité et sécurité des données
Parmi les fonctionnalités qui offre Power BI sont l’administration, la création des utilisateurs et leurs
attribuées les droits d’accès, qui permet la confidentialité, l’integrité et la sécurité des données en
configurant les paramètres de niveau de confidentialité pour le public, l’organisation, ou à aucun.
4.4.3 Test d’accès
Afin de faciliter aux décideurs commerciaux l’accès aux données, on a publié les rapports et les
tableaux de bord sur Power BI Service (PowerBI.com).
Power BI Service s'agit de la solution cloud qui simplifie le partage de rapports et tableaux de bords.
Il donne la possibilité de partager des rapports et des tableaux de bord petits ou grands en interne au
sein de l’entreprise, en externe avec des tiers, et également partager des informations non sensibles
publiquement sur le Web.
Ce composant de Power BI dispose également d'une interface de création de rapports. Le service peut
stocker les données en ligne où il peut se connecter aux données internes via une passerelle Power BI.
En plus ils peuvent aussi accéder aux rapports par mobile, et consulter les tableaux de bord
quotidiennement à partir de l’application Power BI Mobile.
Figure 4.21 : Visualisation d'un rapport sous Power BI Service
78
Figure 4.22 : Visualisation d'un rapport sous Power BI Mobile
4.4.4 Résultats
Finalement on peut dire que ce projet a répondu au besoin général de l'entreprise qui est
l'augmentation de la rentabilité, et on peut justifier cette rentabilité à travers les résultats suivantes :
• Le temps de traitement en environ 2h, il est réduit de 2 semaines à un traitement quotidien.
• On est arrivé à réduire le nombre des intervenants.
• Intégrité des données assurée à 100%.
Ces résultats positifs justifient la conformité de la solution avec les besoins des décideurs.
4.4.5 Comparaison
Le tableau ci-dessous définit la comparaison entre l’ancienne approche et la solution réalisée selon
différents critères :
79
Ancienne approche
Solution réalisée
Collecte de données
Manuelle
Automatique
Stockage de données
Plusieurs sources de données
Un seul DWH organisé
Accès aux données
Demander à l’administrateur
de la base de données
Requête directe sur le DWH
Accès aux informations
Fichier Excel réalisé
manuellement
Tableaux de bord générés
automatiquement
Disponibilité de l’information
Une à deux semaine
Quotidiennement
Intégrité de l’information
Erreurs de saisie
Conforme 100% à la source
Confidentialité de
l’information
- Aucune -
Accès privé via Power BI
Tableau 4.1 : Comparaison entre l'ancienne approche et la solution réalisée
Conclusion
A travers ce chapitre, nous avons implémenté la solution décisionnelle du projet. Il s’agit du
chargement des dimensions et des tables de faits dans le datawarehouse en utilisant le processus ETL,
qui nous a permis d’appliquer plusieurs transformations sur notre base de données, afin qu’elle soit
prête pour le stockage et l’exploration. Ensuite nous avons décrit l’étape de la restitution de données,
qui fait partie de la dernière étape de la mise en place d’une solution décisionnelle. Cette étape met
en évidence les rapports et les tableaux de bords générés par l’outil Power BI afin d’automatiser cette
tâche, détecter les anomalies et aider les dirigeants à prendre les bonnes décisions.
80
Conclusion Générale
De nos jours, l’information est devenue la matière première pour les entreprises, quel que soit leurs
tailles ou leurs chiffres d’affaires. En effet, c’est la maitrise de cette information qui conduit à la
maitrise de la performance et de l’activité de chaque organisation. C’est dans ce sens ou la fonction
de vente est introduite comme étant une fonction transversale d’aide à la prise de décision et à la
recherche des solutions qui mène à augmenter le niveau de l’entreprise.
Au niveau de ce travail réalisé dans le cadre de mon projet de fin d’études, nous avons eu l’opportunité
de mettre en place une solution qui a pour but le pilotage commercial et la gestion de la chaîne de
vente à savoir l’étude, l’analyse, la conception et la mise en place d’une solution BI pour les
statistiques des ventes. On a commencé par définir la problématique et les objectifs du projet afin de
mieux encadrer et délimiter le périmètre et la portée du travail et aussi de définir un planning qui
permet de préciser les étapes nécessaires à la mise en application du projet. Une analyse de l’existant
et des besoins a été effectuée qui a pour objectif de définir les axes d’analyses, les indicateurs clés
suite à une série des entretiens avec les responsables, la conception des modèles dimensionnels, et
finalement la réalisation qui a constitué la dernière étape du travail et a consisté en l’alimentation de
l’entrepôt de données, et la restitution des données. Ceci permis d’approfondir nos connaissances
acquises en matière de l’informatique décisionnelle et aussi d’acquérir une première expérience
professionnelle dans ce domaine.
Les résultats obtenus dans le cadre de ce travail ont montré un bon niveau de précision du
comportement de vente et de pilotage commercial. Ce projet a été d’un apport important pour les
décideurs et les statisticiens dans la mesure où il aide à mieux cerner les dépenses et à apporter des
solutions adéquates en termes de prise de décision et adopter des actes pour mieux suivre les activités
de vente.
Les défis majeurs rencontrés durant le stage sont liés à la difficulté d’accès et de la collecte des
données et la contrainte de gestion du temps. Cependant, l’assistance des encadrants et le soutien de
l’équipe SI a permis le déroulement du PFE dans les bonnes conditions.
81
En guise de perspectives, nous envisageons d’essayer de centraliser les données métiers des autres
activités « Marketing, Achats, Production, Stock, etc. » de l’entreprise, de manière à couvrir, à terme,
l’ensemble des besoins des dirigeants de l’entreprise. Quant au déploiement de la solution
décisionnelle proposée, nous envisageons de recueillir les correctifs et remarques des décideurs afin
d’évaluer la pertinence des indicateurs choisis, et ce dans le cadre des limites rencontrées.
82
Références
Webographie
[1] « Introduction à l'Informatique Décisionnelle » - Disponible sur :
https://www.lebigdata.fr/business-intelligence - Date de consultation : 29/03/2021
[2] « BI : INTRODUCTION À L’INFORMATIQUE DÉCISIONNELLE » - Disponible sur :
https://blogdigital.beijaflore.com/informatique-decisionnelle/ - Date de consultation : 30/03/2021
[3] « Le Système Opérationnel Vs Le Système Décisionnel » - Disponible sur :
http://dihiainfos.blogspot.com/2016/10/OLAPvsOLTP - Date de consultation : 30/03/2021
[4] « Méthode Agile : SCRUM » - Disponible sur : https://prezi.com/da_q4zwj91vm/methode-
agile-scrum/ - Date de consultation : 15/04/2021
[5] « MÉTHODES DE COLLECTE DES DONNÉES » - Disponible sur :
http://www.fao.org/3/X2465F/x2465f08.htm - Date de consultation : 21/03/2021
[6] « Différence entre Data Warehouse et Datamart » - Disponible sur : https://jafwin.com/data-
warehouse-vs-datamart/ - Date de consultation : 15/04/2021
Bibliographie
[7] Kimball, Ralph, and Margy Ross. The data warehouse toolkit: the complete guide to
dimensional modeling. John Wiley & Sons, 2011.
[8] Inmon, William H. Building the data warehouse. John wiley & sons, 2005.
[9] Ballard, Chuck, et al. Dimensional Modeling: In a Business Intelligence Environment. IBM
Redbooks, 2012.
83
Annexes
Annexe 1
Cette annexe présente la connexion entre l’ETL et les différentes sources de données.
Figure A1.1 : Connexion entre l'ETL et la base de données opérationnelle de l'entreprise
84
Figure A1.2 : Connexion entre l'ETL et un fichier Excel
Annexe 2
Cette annexe présente la connexion entre l’ETL et l’entrepôt de données pour effectuer le chargement.
85
Figure A2.1 : Connexion entre l'ETL et l'entrepôt de données
Le présent rapport est une synthèse du travail effectué dans le cadre de mon Projet
de Fin d’Etudes au sein de la société INTERSIG MAROC spécialisée dans la vente
des matériaux de construction. L’objectif de ce projet est la mise en place d'un
système décisionnel pour le pilotage commercial et la gestion de la chaîne de vente.
Mon rôle a consisté en l’intervention à toutes les phases du projet. En commençant
par l’étude préalable du projet, l’analyse des besoins et de l’existant puis en
procédant à l’analyse, la conception et la réalisation de la solution décisionnelle.
Mon projet est articulé autour de la méthodologie Scrum/Agile, et il a été réalisé
en quatre étapes :
La première étape est l’étude préalable : elle porte essentiellement sur l’analyse de
l’environnement économique et stratégique de l’entreprise afin de définir le
périmètre et la portée du projet.
La deuxième étape est la phase d’analyse : elle porte sur les besoins principaux,
l’étude de l’existant, l'architecture générale du système, et l’environnement de
travail.
La troisième étape consiste à la réalisation de la phase de modélisation et
conception décisionnelle et le chargement ETL.
La quatrième étape est la restitution : elle permet de générer des rapports et des
tableaux de bord pour chaque activité de vente (Commande, Livraison, Facture,
Echéance, Règlement). Tester le bon fonctionnement de la chaîne décisionnelle et
déployer la solution finale.
Mots clés : INTERSIG MAROC, système décisionnel, ETL
Oualid Khalis
Filière : Ingénierie informatique et technologies émergentes (IITE)
Option : Ingénierie des données massives (Big Data)
