DEA1833

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université de Carthage
Faculté des Sciences Economiques et de Gestion de Nabeul
MEMOIRE DE MASTER
Master professionnel Ingénierie des Systèmes d’Information et des

Connaissances
Elaboré par
EYA TOUNSY
Conception et mise en place d’une solution décisionnelle pour le suivi des flux
des factures électroniques et des clients pour la société QWEEBY
Réalisé au sein de
Encadré par
Encadrante universitaire Encadrant(s) professionnel(s)

Mme Zouhour Ben Salem Mr Eric Wanscoor
Année universitaire
2020 - 2021
Dédicaces
A ma chère famille
A mes chers amis
A tous ceux qui comptent pour moi
A tous ceux pour qui je compte
Je dédie ce travail
Eya TOUNSY
i
Remerciements
Avec beaucoup de plaisir, je voudrais avant tout adresser mon
gratitude et ma profonde reconnaissance à tous ceux qui, de près ou
de loin, ont contribué à l’élaboration de ce travail.
Je tenais à exprimer mes vifs remerciements à M. Eric Wanscoor le
président de la société française Qweeby pour son accueil
chaleureux au sein de l’entreprise, la confiance qu’il m’accordé tout
au long de mon stage ainsi que pour sa disponibilité et sa
coopération.
Je remercie également Mme Zouhour Ben Salem, enseignante à la
Faculté des Sciences Economiques et de Gestion, pour avoir bien
voulu encadrer ce travail, pour ses précieux conseils, son soutien, sa
disponibilité et ses propositions d’amélioration.
Mes sincères gratitudes à l’équipe de Qweeby, notamment MM.
Aymen Ben Abdallah, et Nadhir Chamkhi qui m’ont fait part de
leur temps et de leur énergie pour aider à élaborer ce travail.
Par la même occasion, j’exprime mes sincères reconnaissances à
l’égard de tous ceux qui ont contribué à notre formation,
particulièrement les enseignants de la Faculté des Sciences
Economiques et de Gestion de Nabeul.
Finalement, je tenais aussi à remercier vivement les membres du
jury qui m’ont fait l’honneur de bien vouloir évaluer ce travail.
ii
Table des matières
Dédicaces ................................................................................................................................ i
Remerciements ...................................................................................................................... ii
Table des matières ................................................................................................................ iii
Liste des figures .................................................................................................................... vi
Liste des tableaux ............................................................................................................... viii
Liste des abréviations ........................................................................................................... ix
Introduction générale ............................................................................................................. 1
Chapitre I. L’informatique décisionnelle ......................................................................... 3
I.1 INTRODUCTION ................................................................................................................................... 3
I.2 DEFINITION DE LA BI ......................................................................................................................... 3
I.3 OBJECTIFS ET ENJEUX DU DECISIONNEL ........................................................................................... 4
I.4 LES ETAPES D’UN PROCESSUS BI ....................................................................................................... 5
I.4.1 La phase de collecte : ..................................................................................................................... 5
I.4.2 La phase d’intégration : .................................................................................................................. 5
I.4.3 La phase d’organisation : ............................................................................................................... 5
I.4.4 La phase de restitution .................................................................................................................... 6
I.5 LES CONCEPTS DE BASE DE LA BUSINESS INTELLIGENCE ................................................................. 7
I.5.1 ETL ................................................................................................................................................ 7
I.5.1.1 Définition d’un ETL ............................................................................................................. 7
I.5.1.2 Fonctionnement d’un ETL .................................................................................................... 7
I.5.1.2.1 Phase d’extraction des données............................................................................................. 7
I.5.1.2.2 Phase de transformation des données .................................................................................... 7
I.5.1.2.3 Phase de chargement des données ........................................................................................ 8
I.5.2 Datawarehouse ............................................................................................................................... 8
I.5.2.1 Définition .............................................................................................................................. 8
I.5.2.2 Caractéristiques des données d'un DWH .............................................................................. 9
I.5.2.3 Les différents types de Datawarehouse ................................................................................. 9
I.5.3 La modélisation multidimensionnelle .......................................................................................... 11
I.5.4 Architectures dimensionnelles ...................................................................................................... 12
I.5.4.1 Schéma en étoile ................................................................................................................. 12
I.5.4.2 Schéma en flocon ................................................................................................................ 13
I.5.4.3 Schéma en constellation ...................................................................................................... 14
I.5.5 Les outils d’accès aux données..................................................................................................... 14
I.5.5.1 Reporting ............................................................................................................................ 15
I.5.5.2 Data mining ........................................................................................................................ 16
I.5.5.2.1 Définition ............................................................................................................................ 16
I.5.5.2.2 Processus............................................................................................................................. 16
I.5.5.3 L’analyse OLAP ................................................................................................................. 17
I.5.5.3.1 Définition ............................................................................................................................ 17
iii
I.5.5.3.2 Cube OLAP ........................................................................................................................ 17
I.5.5.3.3 Les opérations multidimensionnelles OLAP ...................................................................... 18
I.5.5.3.4 Les différents types de systèmes ......................................................................................... 19
I.5.5.4 Tableaux de bord ................................................................................................................ 20
I.5.5.4.1 Définition ............................................................................................................................ 20
I.5.5.4.2 Types de tableau de bord .................................................................................................... 20
I.5.5.4.3 Les fonctions de tableau de bord......................................................................................... 22
I.6 CONCLUSION .................................................................................................................................... 22
Chapitre II. Cadre général du projet................................................................................ 23
II.1 INTRODUCTION ............................................................................................................................ 23
II.2 PRESENTATION DE L’ORGANISME D’ACCUEIL ............................................................................ 23
II.2.1 Présentation de la société ............................................................................................................. 23
II.2.2 L’approche Qweeby ..................................................................................................................... 23
II.2.3 Les atouts de l’entreprise .............................................................................................................. 25
II.2.4 Les clients de Qweeby .................................................................................................................. 26
II.3 ETUDE DE L’EXISTANT................................................................................................................. 26
II.3.1 QweebyNet ................................................................................................................................... 27
II.3.2 Odoo ............................................................................................................................................. 29
II.3.3 Problématique ............................................................................................................................... 30
II.4 SOLUTION PROPOSEE................................................................................................................... 31
II.5 SPECIFICATION DES BESOINS....................................................................................................... 31
II.5.1 Les besoins fonctionnels .............................................................................................................. 32
II.5.2 Les besoins non fonctionnels........................................................................................................ 32
II.6 CONCLUSION................................................................................................................................ 32
Chapitre III. Modélisation multidimensionnelle .............................................................. 33
III.1 INTRODUCTION ............................................................................................................................ 33
III.2 PROCESSUS DE LA MODELISATION MULTIDIMENSIONNELLE ..................................................... 33
III.3 MODELISATION DU NOTRE DATAWAREHOUSE ........................................................................... 33
III.3.1 Datamart Flux ..................................................................................................................... 33
III.3.1.1 Description .......................................................................................................................... 33
III.3.1.2 Les dimensions ................................................................................................................... 34
III.3.1.3 La table de fait .................................................................................................................... 38
III.3.1.4 Le modèle multidimensionnel du datamart Suivi Flux ....................................................... 40
III.3.2 Datamart Reminders ........................................................................................................... 41
III.3.2.1 Description .......................................................................................................................... 41
III.3.2.4 Le modèle multidimensionnel du datamart Reminders....................................................... 43
III.3.3 Datamart Assistance ........................................................................................................... 44
III.3.3.1 Description .......................................................................................................................... 44
III.3.3.4 Le modèle multidimensionnel du datamart Assistance ....................................................... 45
III.3.4 Datamart Evènements ......................................................................................................... 46
III.3.4.1 Description .......................................................................................................................... 46
iv
III.3.4.4 Le modèle multidimensionnel du datamart Suivi Evénements ........................................... 48
III.4 CONCLUSION................................................................................................................................ 48
Chapitre IV. Réalisation ................................................................................................... 49
IV.1 INTRODUCTION ............................................................................................................................ 49
IV.2 ENVIRONNEMENT DE TRAVAIL.................................................................................................... 49
IV.2.1 Environnement matériel ...................................................................................................... 49
IV.2.2 Environnement logiciel ....................................................................................................... 49
IV.3 REALISATION DE NOTRE SOLUTION ............................................................................................ 50
IV.3.1 Processus ETL .................................................................................................................... 50
IV.3.1.1 Extraction des données ....................................................................................................... 50
IV.3.1.2 Transformation des données ............................................................................................... 53
IV.3.1.3 Chargement des données..................................................................................................... 55
IV.3.2 Reporting ............................................................................................................................ 57
IV.3.2.1 Structure physique du tableau de bord ................................................................................ 57
IV.3.2.2 Page D’accueil .................................................................................................................... 58
IV.3.2.3 Rapport FLUX .................................................................................................................... 59
IV.3.2.3.1 Feuille 1 du tableau de bord flux .................................................................................... 59
IV.3.2.3.2 Feuille 2 du tableau de bord Flux ................................................................................... 62
IV.3.2.3.3 Feuille pourcentage anomalie ........................................................................................ 62
IV.3.2.3.4 Tableau de bord Client Consommateur .......................................................................... 64
IV.3.2.3.5 Tableau de bord pour autres entités................................................................................ 69
IV.3.2.4 Rapport Reminders ............................................................................................................. 69
IV.3.2.5 Rapport Assistance ............................................................................................................. 70
IV.3.2.6 Rapport Evénements ........................................................................................................... 71
IV.4 CONCLUSION................................................................................................................................ 75
Conclusion générale ............................................................................................................ 76
Bibliographie ....................................................................................................................... 77
Netographie ......................................................................................................................... 78
v
Liste des figures
Figure 1 – Le modèle DIKW.............................................................................................................. 4

Figure 2 – Processus global de traitement des données d’un système décisionnel ............................ 5
Figure 3 – Processus détaillé de traitement des données d’un système décisionnel .......................... 7
Figure 4 – Fonctionnement d’un ETL ................................................................................................ 8
Figure 5 – Types de datawarehouse ................................................................................................. 10
Figure 6 – Relation entre un datamart, un ODS et un datawarehouse ............................................. 11
Figure 7 – Modèle en étoile.............................................................................................................. 13
Figure 8 – Modèle en flocon ............................................................................................................ 13
Figure 9 – Modèle en constellation .................................................................................................. 14
Figure 10 – Les outils d’exploitation ............................................................................................... 15
Figure 11 – Processus du Data mining ............................................................................................. 16
Figure 12 – Représentation d'un cube OLAP ................................................................................... 18
Figure 13 – Les opérations OLAP.................................................................................................... 19
Figure 14 – Les fonctions du tableau de bord .................................................................................. 22
Figure 15 – Le principe de fonctionnement du dispositif de Qweeby ............................................. 24
Figure 16 – Les avantages de la transmission via Qweeby .............................................................. 26
Figure 17 – Les clients de Qweeby .................................................................................................. 26
Figure 18 – Interface de connexion à l’application QweebyNet ...................................................... 28
Figure 19 – Volet Factures Emis sur l’application QweebyNet ....................................................... 28
Figure 20 – Architecture du Système d’information de Qweeby ..................................................... 30
Figure 21 – Fait Suivi Flux .............................................................................................................. 41
Figure 22 – Fait Suivi Reminders .................................................................................................... 43
Figure 23 – Fait Suivi Assistance .................................................................................................... 46
Figure 24 – Fait Suivi Evénements .................................................................................................. 48
Figure 25 – Volet base de données sur plesk ................................................................................... 51
Figure 26 – La base de données QweebyNet ................................................................................... 51
Figure 27 – Connexion à la base source de QweebyNet via Talend ................................................ 52
Figure 28 – Extraction des tables utiles pour l’analyse .................................................................... 52
Figure 29 – Transformation de la table i_invoice ............................................................................ 54
Figure 30 – tMap effectuée sur la table i_invoice ............................................................................ 55
Figure 31 – Construction du Job Talend .......................................................................................... 55
Figure 32 – Transfert des Job Talend vers la machine Linux via Filezilla ...................................... 56
Figure 33 – Planification de l'exécution du Job Talend via Plesk ................................................... 56
Figure 34 – Connexion Power BI à notre entrepôt ........................................................................... 57
Figure 35 – Page d'accueil................................................................................................................ 58
Figure 36 – Tableau de bord Flux 1/2 .............................................................................................. 59
Figure 37 – Flux par branche ........................................................................................................... 60
Figure 38 – Flux par format de transmission ................................................................................... 60
Figure 39 – Flux & Entités par pays ................................................................................................ 61
Figure 40 – Flux par type de document............................................................................................ 61
Figure 41 – Tableau de bord Flux 2/2 .............................................................................................. 62
Figure 42 – Pourcentage anomalie ................................................................................................... 63
Figure 43 – Pourcentage anomalie par branche ............................................................................... 63
Figure 44 – Pourcentage anomalie par entité ................................................................................... 64
Figure 45 – 1ère feuille du rapport des clients consommateurs ....................................................... 64
Figure 46 – Flux par client consommateur ....................................................................................... 65
Figure 47 – Suivi Flux du client Anett et Cie SARL ....................................................................... 66
Figure 48 – Top 3 points de consommation ..................................................................................... 66
Figure 49 – Volume émis et reçu par branche.................................................................................. 67
Figure 50 – Dépassement par rapport au volume annuel cible ........................................................ 67
Figure 51 – Flux par Type de document ......................................................................................... 68
vi
Figure 52 – Evolution des flux au fils du temps.............................................................................. 68
Figure 53– Tableau de bord autres entités........................................................................................ 69
Figure 54 – Tableau de bord Reminders .......................................................................................... 70
Figure 55 – Tableau de bord Assistance .......................................................................................... 71
Figure 56 – Tableau de bord Evénements ........................................................................................ 72
Figure 57 – Suivi événements par entité ....................................................................................... 72
Figure 58 – Page des clients consommateurs ................................................................................... 73
Figure 59 – Suivi flux du client Champion Entreprises ................................................................... 73
Figure 60 – Suivi événements du client Champion Entreprises ...................................................... 74
Figure 61 – Suivi Tickets de client Champion Entreprises .............................................................. 74
Figure 62 – Suivi Reminders envoyés à Cherrier............................................................................. 75
vii
Liste des tableaux
Tableau 1 – Comparaison entre la table de faits et la table de dimension....................................... 12

Tableau 2 – Comparaison entre les systèmes OLAP ....................................................................... 19
Tableau 3 – Les types des tableaux de bord ..................................................................................... 21
Tableau 4 – Dimension Flux ............................................................................................................ 34
Tableau 5 – Dimension Erreurs........................................................................................................ 34
Tableau 6 – Dimension Entité .......................................................................................................... 35
Tableau 7 – Dimension Branche ...................................................................................................... 35
Tableau 8 – Dimension client consommateur .................................................................................. 36
Tableau 9 – Dimension Abonnement ............................................................................................... 36
Tableau 10 – Dimension Groupement ............................................................................................. 36
Tableau 11 – Dimension Revendeur ................................................................................................ 37
Tableau 12 – Dimension pays .......................................................................................................... 37
Tableau 13 – Dimension Heure........................................................................................................ 37
Tableau 14 – Dimension Date .......................................................................................................... 38
Tableau 15 – Les mesures du fait Flux ............................................................................................ 39
Tableau 16 – Fait Suivi Flux ............................................................................................................ 40
Tableau 17 – Dimension Reminder .................................................................................................. 42
Tableau 18 – Dimension Utilisateur................................................................................................ 42
Tableau 19 – Fait Suivi Reminders ................................................................................................. 43
Tableau 20 – Dimension Assistance ............................................................................................... 44
Tableau 21 – Dimension Equipe Helpdesk ...................................................................................... 44
Tableau 22 – Fait Suivi Assistance ................................................................................................. 45
Tableau 23 – Dimension Evénements .............................................................................................. 47
Tableau 24 – Dimension Statut ........................................................................................................ 47
Tableau 25 – Dimension Participants............................................................................................... 47
Tableau 26 – Fait Suivi Evénements ................................................................................................ 47
viii
Liste des abréviations
API Application Programming Interface

B2B Business to Business
CRM Customer Relationship Management
DIKW Data, Information, Knowledge, Wisdom
DWH Datawarehouse
EDI Echange de données Informatisé
ERP Entreprise Resource Planning
ETL Extract, Tranfsorm and Load
FTP File Transfer Protocol
FTPS File Transfer Protocol Secure
HOLAP Hybrid Online Analytical Processing
JAR Java Archive
JDBC Java Database Connectivity
JDK Java Development Kit
MDX Multidimensional Expressions
MOLAP Multidimensional Online Analytical Processing
ODS Operational Data Store
OLAP Online Analytical Processing
OLTP Online Transaction Processing
PDF Portable Document Format
PME Petite et moyenne entreprise
ROLAP Relational Online Analytical Processing
SAS Société par Actions Simplifiée
SGBD Système de Gestion de Base de Données
SFTP SSH File Transfer Protocol
SSH Secure Shell
XML Extensible Markup Language
ix
INTRODUCTION GENERALE
Introduction générale
De nos jours, les entreprises évoluent dans un environnement concurrentiel de plus

en plus marqués et en pleine mutation. Cet environnement oblige, en effet, ces entreprises à
s’orienter vers des stratégies innovantes pour assurer leur pérennité et leur croissance afin
de conquérir le marché et répondre aux besoins de ses clients.
De ce fait, pour améliorer leur compétitivité, les entreprises mettent en place des
systèmes décisionnels en support à la performance de l’entreprise offrant aux décideurs les
informations sur lesquelles ils pourront s’appuyer pour mener leurs décisions avec rapidité
et efficacité.
Dans ce contexte, la compétitivité de Qweeby dépend aujourd'hui plus que jamais de

sa capacité à développer une stratégie lui permettant de faire face à cette concurrence. Elle
vise à se différencier grâce à l’informatique décisionnelle en proposant des solutions plus
innovantes pour les aider à optimiser leur processus de facturation. En effet, l’informatique
décisionnel permettra d’exploiter leurs données de transmission afin de répondre à des
besoins métiers réels non satisfaits par les flux actuels.
Notre projet de fin d’études vise à en place d’une solution décisionnelle qui s’aligne
avec la stratégie de l’entreprise Qweeby. Elle lui permet d’avoir une vue d’ensemble sur la
quantité et le flux des factures électroniques de ses différents clients offrant ainsi un outil
qui aide à établir une stratégie pour ce processus.
Le présent rapport est structuré autour de quatre chapitres :
Le premier chapitre intitulé « L’informatique décisionnelle » traite les aspects

théoriques des systèmes d’information décisionnels, en indiquant leurs définitions et les
concepts de bases relatifs à l’architecture d’un entrepôt de données, les différents modèles
multidimensionnels pour sa conception ainsi que les étapes de mise en place de la solution
BI. (Business Intelligence)
Dans le deuxième chapitre, intitulé « Cadre général du projet », nous

commencerons par une description de l’organisme d’accueil et une présentation du cadre
général de notre projet. Nous analyserons, par la suite, l’existant afin de le critiquer dans
l’objectif d’en proposer une solution. Nous terminerons ce deuxième chapitre par la
1
INTRODUCTION GENERALE
définition des besoins d’affaire à savoir les besoins fonctionnels et les besoins non
fonctionnels.
Le troisième chapitre intitulé « Modélisation multidimensionnelle » sera consacré

à la conception de notre application. En effet, nous présenterons la liste des dimensions, les
tables de fait et le modèle conceptuel adopté dans notre projet.
Le quatrième chapitre intitulé « Réalisation » détaille les différentes étapes de notre

application. En fait, nous y présenterons l’environnement logiciel et matériel que nous avons
utilisés, ainsi que les étapes de réalisation pour arriver au résultat final.
Nous clôturons ce rapport par une conclusion générale relative aux travaux menés
dans le cadre de ce projet et des perspectives.
2
CHAPITRE I L’INFORMATIQUE DECISIONNELLE
Chapitre I. L’informatique décisionnelle
I.1 Introduction
Avec l’avènement de la quatrième révolution industrielle, les données deviennent la
plaque tournante de la gestion d’entreprise. Aujourd’hui, la plupart des entreprises, y
compris les petite et moyenne entreprise (PME), génère aisément une masse d’informations
de plus en plus importante dans les divers aspects de ses opérations (leurs clients, leurs
ventes, leurs produits, leurs fournisseurs leurs concurrents etc.) dont elles ne font rien !
Pour créer de la valeur ajoutée à partir de ces données, Les tendances montrent que
les entreprises se tournent vers le Business Intelligence pour relever ce défi. Croisées,
analysées, filtrées, ces informations pourraient pourtant devenir un formidable tremplin pour
se différencier de la concurrence, améliorer les résultats de l’entreprise, suivre avec précision
ses activités ou fidéliser les clients à l’aide des synthèses rapides, des tableaux de bord clairs
pour ne plus piloter son entreprise à l’intuition. C’est là que réside tout l’intérêt du Business
Intelligence.
Dans ce premier chapitre, nous allons expliquer les différentes notions théoriques
liées à notre projet.
I.2 Définition de la BI
La Business Intelligence ou informatique décisionnelle désigne les méthodes, les
outils et les moyens qui permettent de collecter, consolider d’analyser et restituer l’ensemble
des données de l’entreprise sous forme d’informations pertinentes afin d’aider l’entreprise à
prendre des décisions stratégiques nécessaires à son développement et sa compétitivité, avec
une visualisation sous forme de rapports, tableaux de bord ou graphiques. [1]
Le Business Intelligence repose sur le modèle Data, Information, Knowledge,

Wisdom (DIKW) représenté par la figure suivante :
3
Figure 1 – Le modèle DIKW
Pour simplifier, une donnée doit être traitée et transformée en une information, qui
sera ensuite présentée de manière claire pour pouvoir identifier des modèles, et ainsi en
générer une idée exploitable.
I.3 Objectifs et enjeux du décisionnel

L’objectif d’un système décisionnel est de :
• Connaître les objectifs;
• Mesurer les données;
• Prévoir l’information;
• Agir afin d’aligner l’information aux objectifs.
Les moyens pour y parvenir sont :
• Une information riche, pertinente, détaillée, historisée, fiable;
• Des outils d’analyse et de restitution puissants et adaptés;
• Des indicateurs qui favorisent le pilotage et favorisent l’action.
Le cycle du projet comprend plusieurs étapes :
• Sélectionner les axes de progrès.
• Sélectionner le ou les processus à analyse.
• Définir les objectifs.
• Définir les indicateurs.
• Bâtir le portail décisionnel.
4
I.4 Les étapes d’un processus BI

Un projet décisionnel est composé de 4 phases clés comme le montre la figure
suivante :
Figure 2 – Processus global de traitement des données d’un système décisionnel
I.4.1 La phase de collecte :

La collecte s’effectue à partir de données sources. Il peut s’agir de fichiers "plats"
(fichiers CSV avec séparateurs, fichiers XML, fichiers ASCII...) mais aussi de systèmes de
bases de données (export de base MySQL, PostgreSQL, DB2, ORACLE...). Ces sources de
données sont donc en général hétérogènes c’est pourquoi il va falloir passer par une phase
dites d’intégration pour pouvoir les manipuler avant de les stocker dans notre système d’aide
à la décision. [2]
I.4.2 La phase d’intégration :

La première couche logicielle de l'environnement décisionnel se situe à ce niveau,
c'est-à-dire ETL (Extract, Transform and Load). Elle offre plusieurs fonctions pour extraire
des données de différents systèmes (internes ou externes), transformer des données
(homogénéiser, filtrer, calculer) et les charger dans un Operational data store (ODS)
intermédiaire ou directement dans un datawarehouse (DWH). Elle garantit une
délocalisation de la charge de calcul et une meilleure disponibilité des sources.
I.4.3 La phase d’organisation :

Elle permet de stocker les données dans un entrepôt de données nommé :
Datawarehouse. L'entrepôt contient des données documentées, non volatiles orientées métier
et historisées. Il se compose des dimensions ou des axes d'analyse (la chronologie la
5
géographie sont des exemples courants) et de faits ou des indicateurs (comme le chiffre
d'affaires). Un facteur important vient du fait que les données stockées dans le DWH ne
peuvent pas être modifiées une fois à l'intérieur. Ce sont des données consolidées et figées
qui nous permettent d'effectuer diverses analyses et statistiques.
I.4.4 La phase de restitution

La dernière phase concerne la restitution des résultats afin de diffuser et de faciliter
l’accessibilité des informations selon les fonctions et les types d’utilisation. Il existe
plusieurs et différents types d’outils à ce niveau : les outils d’analyse, la phase de
Datamining, les outils de reporting et de requêtes permettant de fournir des rapports
périodiques et paramétrables ainsi que de produire des tableaux de bord avec des indicateurs
synthétisant différents critères de performance.
Les outils de reporting et de requêtes permettent la mise à disposition de rapports

périodiques, pré formatés et paramétrables par les opérationnels. Ils permettent également la
production de tableaux de bord avec des indicateurs de haut niveau pour les managers,
synthétisant différents critères de performance. [3]
Les outils d’analyse OLAP (Online Analytical Processing) permettent de traiter des
données et de les afficher sous forme de cubes multidimensionnels et de naviguer dans les
différentes dimensions. Cet agencement des données permet d’obtenir immédiatement
plusieurs représentations d’un même résultat, en une seule requête sous une approche
descendante des niveaux agrégés vers les niveaux détaillés (Drill-down, Roll-up). [4]
Les outils d'exploration de données effectuent une analyse plus approfondie des
données historisées pour découvrir des connaissances cachées dans les données, telles que
la détection de corrélations et de tendances, l'établissement de segmentations et de typologies
et même la prévision. L'exploration de données est basée sur des algorithmes statistiques et
mathématiques et des hypothèses métier.
6
Figure 3 – Processus détaillé de traitement des données d’un système décisionnel
I.5 Les concepts de base de la Business Intelligence

I.5.1 ETL
I.5.1.1 Définition d’un ETL
Un ETL est un ensemble d’outils et de méthodes qui combinent trois fonctions :

l’extraction de données de sources diverses (bases de données, fichiers, etc…), la
transformation des données extraites en un format cible selon des règles définies et enfin le
chargement de ces données transformées dans un Datawarehouse. [5]
I.5.1.2 Fonctionnement d’un ETL
Comme son nom l'indique, l'ETL se décompose en trois phases : l'extraction, la

transformation et le chargement.
I.5.1.2.1 Phase d’extraction des données
Cette étape consiste à collecter et extraire toutes sortes de données brutes en

provenance des différentes sources du système d’information de l’entreprise (ERP, SGBD
ou fichiers à plat) et les copier dans la zone de préparation en vue de manipulations
ultérieures.
I.5.1.2.2 Phase de transformation des données
Cette étape garantit la qualité des données qui seront intégrées dans le datawarehouse.
Pour chaque nature de donnée et origine de donnée, des règles précises sont définies pour :
 La vérification des données,
7
 L’élimination des doublons,
 Le nettoyage des données,
 La normalisation des données selon les règles métiers.
L’objectif est de générer des données propres prêtes à être chargées dans un entrepôt
de données et à servir de source pour les solutions d’analyse et de Business Intelligence.
I.5.1.2.3 Phase de chargement des données
Nous terminons par l’alimentation du Datawarehouse, où les données sont

accessibles et utilisables pour des :
 Analyses avec des outils OLAP
 Recherches de corrélation avec le Data Mining,
 Partages avec les outils de Reporting,
 Exploitations par les Outils Business Intelligence.
Figure 4 – Fonctionnement d’un ETL
I.5.2 Datawarehouse
I.5.2.1 Définition
Le Datawarehouse, ou entrepôt de données, est une base de données dédiée au

stockage d’un large volume de données utilisées dans le cadre de la prise de décision et de
8
l'analyse décisionnelle. Il est alimenté en données depuis les bases de production grâce
notamment aux outils d'ETL. Il occupe une place centrale au sein d’un système de Business
Intelligence. [6]
I.5.2.2 Caractéristiques des données d'un DWH
Un entrepôt de données n'est pas une simple copie des données de production. Un
DWH doit être bien organisé et structuré.
Selon l’inventeur du terme, Bill Inmon, un entrepôt de données a quatre

caractéristiques spécifiques. Il doit être :
a) Orienté sujet
Le DWH est structuré autour des sujets majeurs de l'entreprise. Les données sont
donc organisées par thèmes. Par exemple, un Datawarehouse peut être déployée pour une
analyse des données liées aux ventes de l’entreprise. Cet Datawarehouse servira à répondre
à des questions comme « quels ont été les meilleurs clients pour tel produit au cours de
l’année précédente ».
b) Intégré
Le DWH doit être en mesure d’assembler des données en provenance de sources

hétérogènes utilisant chacune un type de format. Elles doivent permettre de résoudre les
problèmes comme les conflits de noms et les incohérences en termes d’unités de mesure.
c) Non volatile
Le DWH doit être non-volatile. C’est-à-dire, une fois qu’une donnée est chargée dans
l’entrepôt de données, elle ne doit plus changer au fils du temps. L’utilisateur doit ainsi
analyser les données telles qu’elles ont été stockées dans le datawarehouse. (Read-Only).
d) Historisé
Les données non volatiles sont aussi horodatées. On peut ainsi visualiser l'évolution
dans le temps d'une valeur donnée. Le degré de détail de l'archivage est bien entendu relatif
à la nature des données. [7]
I.5.2.3 Les différents types de Datawarehouse
Nous distinguons trois types principaux de Datawarehouses comme le montre la

figure suivante :
9
Figure 5 – Types de datawarehouse
 Datawarehouse d’entreprise:
C’est un Datawarehouse centralisé. Il fournit un service d’aide à la décision dans
toute l’entreprise. Il offre la possibilité de classer les données en fonction du sujet et de
donner accès en fonction de ces divisions.
 Data Stores opérationnels (ODS)

L’ODS n’est rien d’autre qu’un magasin de données requis lorsque ni l’entrepôt de
données ni les systèmes OLTP (Online Transaction Processing) ne prennent en charge les
besoins de déclaration des organisations. Dans un ODS, les données sont mises à jour en
temps réel, ce qui s’avère très utile pour les activités quotidiennes comme l’enregistrement
des rapports et enregistrements des employés.
 Data Mart:
Un Data Mart est un sous-ensemble de l’entrepôt de données. Il est spécialement
conçu pour un secteur d’activité particulier, comme la vente, la finance, etc. Dans un Data
Mart indépendant, les données peuvent être collectées directement à partir des différentes
sources. La figure suivante montre la relation entre un datamart, un ODS et un
datawarehouse :
10
Figure 6 – Relation entre un datamart, un ODS et un datawarehouse
I.5.3 La modélisation multidimensionnelle

La modélisation multidimensionnelle est une technique de conception logique
permettant de structurer les données de manière à les rendre intuitives aux utilisateur
d'affaires et offrir une bonne performance aux requêtes. Chaque modèle multidimensionnel
se compose d’une table contenant une clé multiple, la table des faits, et d’un ensemble de
tables nommées tables dimensionnelles. [8]
 Table de faits :
Une table de fait est la table centrale d’un modèle dimensionnel qui contient les
données observables (les faits) que l’on possède sur un sujet et que l’on veut étudier. Une
ligne de cette table correspond à une mesure. Ces mesures sont normalement numériques,
puisque d’ordre quantitatif. Il peut s’agir du montant en argent des ventes, du nombre
d’unités vendues d’un produit, etc. [9]
 Table de dimensions
La Table de dimension contient les axes d'analyse (les dimensions) selon lesquels on
veut étudier des données observables (les faits) qui, soumises à une analyse
multidimensionnelle, donnent aux utilisateurs des renseignements nécessaires à la prise de
décision. On appelle « dimension » un axe d'analyse. Il peut s'agir des clients ou des produits
d'une entreprise, le temps, la localisation géographique, etc. [10]
Il existe d’autres facteurs qui créent des différences entre la table de faits et la table
de dimension, jetons un coup d’œil au tableau comparatif ci-dessous : [11]
11
Tableau 1 – Comparaison entre la table de faits et la table de dimension
Table de faits Table de dimensions

Clé primaire La table de faits contient une Chaque table de dimension
clé primaire qui est une contient sa clé primaire.
concaténation de clés
primaires de toutes les tables
de dimensions.
Signification La table de faits contient les La table de dimension
mesures avec des attributs contient les attributs avec
d’une table de dimension. lesquels la table de faits
calcule la métrique.
Attributs & records La table de faits contient La table de dimension
moins d’attributs et plus contient plus d’attributs et
d’enregistrements. moins d’enregistrements.
Création La table de faits peut être Les tables de dimension
créée uniquement lorsque doivent être créés en
les tables de dimensions premier.
sont complétées.
Schéma Un schéma contient moins Un schéma contient plus de
de tables de faits. tables de dimension.
I.5.4 Architectures dimensionnelles

Il existe principalement trois modélisations possibles pour structurer les données
stockées dans un Datawarehouse : la modélisation en étoile, en flocon et en constellation.
I.5.4.1 Schéma en étoile
Le modèle de données en étoile doit son nom à sa forme. Il s'agit du schéma le plus
simple et le plus efficace dans un entrepôt de données. Une table de faits au centre entourée
de tables de dimensions multiples ressemble à une étoile dans le modèle Star Schéma. [12]
La figure 7 illustre un exemple d’un modèle en étoile.
12
Figure 7 – Modèle en étoile
Prenons l’exemple présenté par la figure 7, la table de faits Fait vente est composé
des identifiants de toutes ses dimensions : id_magasin, id_produit, etc. Autour de la table de
faits, nous trouverons les dimensions permettant d’analyser les faits.
I.5.4.2 Schéma en flocon
C’est le modèle en étoile avec une normalisation des dimensions. Il peut exister des
hiérarchies des dimensions pour diviser les tables de dimensions lorsqu’elles sont trop
volumineuses. La figure 8 ci-dessous est un exemple d’un modèle en flocon. [13]
Figure 8 – Modèle en flocon
Dans exemple ci-dessus nous constatons l’existence d’une dimension agrégée

« Table dimension pays » qui permet d’atteindre la granularité la plus fine de l’information.
13
I.5.4.3 Schéma en constellation
Une constellation est une série d'étoiles ou de flocons reliés entre eux par des
dimensions. Il s'agit donc d'étoiles avec des dimensions en commun. La figure 9 illustre un
exemple d’un modèle en constellation. [14]
Figure 9 – Modèle en constellation
Dans cet exemple, les deux tables de faits Ventes et Achats partagent les dimensions
Produit et Période.
I.5.5 Les outils d’accès aux données

Les outils d’accès aux données représentent l’ensemble des moyens offerts aux
utilisateurs pour exploiter et analyser les données qui leur sont fournies. Selon les besoins,
différents types d’outils d’extraction et d’exploitation sont disponibles tels que les outils
OLAP pour les analyses multidimensionnelles, les outils de Data mining pour rechercher
des corrélations peu visibles, les tableaux de bord qui présentent les indicateurs clés pour
piloter la performance et les outils de reporting pour communiquer sur la performance.
La figure 10 présente les différents outils d’exploitation des données comme les
outils de reporting, analyse OLAP, les tableaux de bord et le datamining.
14
Figure 10 – Les outils d’exploitation
I.5.5.1 Reporting
Le reporting, traduit en français communication de donnée, permet de mettre en

scène des données récupérées sur une période souhaitée et de les présenter de manière claire
et compréhensible afin qu’elles puissent être analysées et exploitées par une tierce personne.
Il permet de rendre compte périodiquement des indicateurs de performance permettant à
l’entreprise de s’évaluer et de suivre son activité. [15]
Il apporte également une aide à la décision pour les choix stratégiques et

économiques de l’entreprise.
Le reporting est l’outil de l’exploitation de données le plus utilisé, permettant aux

dirigeants de :
 Choisir des données sur une certaine période (production, secteur, etc.)
 Trier, rassembler ou répartir ces données selon des critères de leur choix
 Appliquer divers calculs (écarts, moyennes, totaux, comparatifs sur des périodes de
temps, etc.)
 Fournir une représentation des résultats, synthétique ou détaillée, en fonction des

besoins des dirigeants de l’entreprise.
15
Étant destinées à tous les secteurs d’activités, comme le droit, la communication, le

commerce ou encore la finance, de nombreuses données peuvent être suivies dans une
communication de données. Parmi elles, nous retrouvons par exemple :
 Les économies réalisées par une entreprise ;
 L’ensemble de recettes et dépenses faites par une entreprise ;
 Le trafic réalisé sur un site Internet ;
 Le bilan de vente d’un site web ;
 Le suivi d’activité sur les réseaux sociaux ; [16]
I.5.5.2 Data mining
I.5.5.2.1 Définition
Forage de données, explorations de données ou fouilles de données, ce sont les

traductions possibles du data mining en Français. Le data mining désigne le processus
d’analyse de volumes massifs de données et du Big Data depuis différentes perspectives afin
d’identifier des relations entre les data et de les transformer en informations utiles et
exploitables. Cela a pour but d’aider les entreprises à résoudre des problèmes, à atténuer des
risques, à se rapprocher de leurs objectifs et à prendre de meilleures décisions. [17]
I.5.5.2.2 Processus
La figure suivante résume le processus du Data mining.
Figure 11 – Processus du Data mining
Dans ce qui suit, nous allons détailler ce processus :
16
 Définition du problème : Définir le but de l'analyse et les objectifs ainsi que

les problèmes qu’on peut rencontrer.
 Collecte des données : Collecter, évaluer et sélectionner parmi l'ensemble des

données disponibles, celles qui pourront être utilisées.
 Choix du modèle d’analyse : Sélectionner et paramétrer les techniques de

modélisation à utiliser
 Etude des résultats : Evaluer la qualité et la pertinence des résultats, en

fonction de l'objectif défini.
 Formalisation et diffusion : Les résultats sont formalisés pour être diffuser et

prendre les décisions.
I.5.5.3 L’analyse OLAP
OLAP, est un outil permettant de faciliter la manipulation de grandes quantités de

données à des fins décisionnelles. Elle permet d’effectuer une analyse multidimensionnelle
des données d'entreprise et offre la possibilité de calculs complexes, d'analyses de tendances
et de modélisation de données sophistiquées. Les données OLAP sont stockées dans une
base multidimensionnelle, aussi appelées Cubes OLAP, pour faciliter ce type d’analyses. Un
serveur OLAP est nécessaire.
I.5.5.3.2 Cube OLAP
Un cube OLAP est une base de données multidimensionnelle optimisée pour les
Datawarehouses et les applications OLAP. Il s’agit d’une méthode permettant de stocker les
données sous forme multidimensionnelle, notamment pour le reporting. En général, ces
cubes sont pré-résumés pour accélérer le temps de requête par rapport aux bases de données
relationnelles. Pour effectuer des requêtes au sein des cubes OLAP, on utilise le langage
MDX (Multidimensional Expressions). Les cubes sont conçus pour pouvoir être utilisés par
tous les employés de l’entreprise, et non uniquement par les responsables de division
informatique. Ils sont capables de rapporter des millions d’enregistrements en une seule fois.
[18]
17
Figure 12 – Représentation d'un cube OLAP
Le cube ci-dessus nous permet de visualiser une représentation du chiffre d'affaires

réalisé selon les axes suivants : par article et par lieu et par saison.
I.5.5.3.3 Les opérations multidimensionnelles OLAP
Les systèmes OLAP effectuent les opérations d'analyse OLAP suivantes pour repérer
les intersections entre les multiples dimensions. :
 Roll-up : consiste à remonter dans la hiérarchie de la dimension.
Par exemple : visualiser le chiffre d’affaire par article et par lieu.
 Drill-down : permet d’obtenir plus de détails soit en descendant dans la

hiérarchie de la dimension. Par exemple : visualiser le chiffre d’affaire par
type ou catégorie d’article et par lieu.
 SLICE : permet de sélectionner une dimension particulière à partir d'un cube

donné et fournit un nouveau sous-cube, tel que "les ventes en 2017".
 DICE : permet de faire une sélection sur deux ou plusieurs dimensions du

cube et créer un sous-cube, telles que "les ventes de ballons de plage bleus en
Italie en 2017".
 Pivot/rotation : fait pivoter les axes de données en vue de fournir une

présentation alternative des données.
18
La figure 13 expose avec des exemples les différentes opérations sur les cubes.
Figure 13 – Les opérations OLAP
I.5.5.3.4 Les différents types de systèmes
Ils existent différents types de systèmes. Une étude comparative est présentée par le
tableau 2 qui décrit les trois systèmes selon un ensemble de critères tel que stockage,
agrégation, etc.
Tableau 2 – Comparaison entre les systèmes OLAP
ROLAP (Relational MOLAP HOLAP (Hybrid

Online Analytical (Multidimensional Online Analytical
Processing) Online Analytical Processing)
Processing)
Stockage des BD relationnelle BD BD relationnelle
données multidimensionnelle
(cube)
Stockage des BD relationnelle BD BD
agrégations multidimensionnelle multidimensionnelle
(cube) (cube)
19
Structure de la Modèle particulier Structure Croisement des

base de données (étoile, flocon, propriétaire au architectures
constellation) logiciel utilisé ROLAP et MOLAP
Fonctionnement Le serveur extrait les Le serveur MOLAP Accède aux deux BD
données par des extrait les données On se sert du
requêtes SQL et crée du cube et les MOLAP lorsque
de manière présente directement l’on veut accéder
dynamique une vue au module client. aux données
multidimensionnelle agrégées. Pour
des données pour atteindre un niveau
l'utilisateur. de détail plus
important, on peut
utiliser le ROLAP.
Les volumes de ROLAP traite de gros MOLAP traite une HOLAP traite
données volumes de données. quantité de données de gros volumes de
limitée à gérer données.
Performance Le moins performant Le plus performant Performance
des requêtes moyenne
I.5.5.4 Tableaux de bord
Un tableau de bord est un instrument de communication et de décision très efficace

qui met en lumière des indicateurs clé de performances permettant d’apporter une vision
synthétique sur les points essentiels au fonctionnement de la société afin de permettre le chef
d’entreprise de prendre des décisions stratégiques.
I.5.5.4.2 Types de tableau de bord
On dénombre 3 types de tableaux de bord : Tableau de bord de gestion, tableau de

bord opérationnel, tableaux de bord stratégique. Le tableau ci-dessous représente les
caractéristiques de chaque type :
20
Tableau 3 – Les types des tableaux de bord
Tableau de bord Tableau de bord Tableau de bord

de gestion opérationnel stratégique
Type Tableau de bord Tableau de bord de Tableau de bord
financier performance orientés stratégie
Audience Responsables Les managers, les l’équipe
d’équipes, analystes de données , les dirigeante, la
responsable de membres d’équipe direction
départements, opérationnelles ,l’équipe
l’équipe responsable de la
administrative production ,à destination
des différents métiers
Objectif Suivre et évaluer Suivre et évaluer la Donner une vision
les performances performance des synthétique des
financières de processus opérationnels performances de
l’entreprise pour au sein d’une entreprise. l’entreprise par
les comparer aux rapport à l’atteinte
prévisions. des objectifs
Fréquence de Hebdomadaire, Journalière, Annuelle,

réalisation mensuelle hebdomadaire ou semestrielle,
mensuelle trimestrielle ou
mensuelle.
Vision Moyen terme Court terme Moyen et long
terme
Exemple Les volumes des Nombre de nouveaux Progression du
ventes, le carnet de clients pour les vendeurs, chiffre d'affaires,
commandes, les taux de rupture de stock nombre de clients,
revenus, etc. pour le service parts de marché,
approvisionnement, taux évolution de la
de décroché pour un call- rentabilité…
center, etc.
21
I.5.5.4.3 Les fonctions de tableau de bord
Pour assurer efficacement son rôle d’assistant du décideur, le tableau de bord prend
en charge de multiples fonctions illustrés par la figure 14. Orienté dès sa conception selon
un objectif précis, le tableau de bord mesure la performance et signale les
dysfonctionnements susceptibles de gêner le parcours d’une entreprise. Lorsqu’il est bien
conçu, il contribue à développer une capacité d’anticipation, pour voir plus loin que les faits
présents.
Figure 14 – Les fonctions du tableau de bord
Dans tous les cas, le tableau de bord est un instrument personnel. L’utilisateur doit
être en mesure de l’adapter à ses besoins précis. Véritable référentiel de la performance, le
tableau de bord est aussi un outil de communication. [Bib1]
I.6 Conclusion
En guise de conclusion nous constatons que de nos jours, la Business Intelligence est
devenue une nécessité pour le système de pilotage de l’entreprise. Ainsi, tout au long de ce
chapitre, nous avons présenté la business intelligence et ses différences concepts de base.
Dans le chapitre suivant, nous introduisons le cadre général du projet en présentant
l’organisme d’accueil, en détaillant l’existant et en montrant ses limite
22
CHAPITRE II CADRE GENERAL DU PROJET
Chapitre II. Cadre général du projet
II.1 Introduction
Le présent chapitre a pour but de situer le projet dans son cadre général et d’exposer
le contexte et les objectifs à atteindre durant ce stage de fin d’études. Nous allons débuter
par une présentation de l’organisme d’accueil, suivie par la suite d’une analyse approfondie
de l’existant décisionnel pour aboutir à une synthèse et à des critiques. La méthode de
conduite du projet adoptée ainsi que l’expression des besoins fonctionnels et non
fonctionnels concernant notre projet seront exposées à la fin de ce chapitre.
II.2 Présentation de l’organisme d’accueil

II.2.1 Présentation de la société
Qweeby, SAS au capital de 348 920 €, a été fondée en Janvier 2009 par Eric
WANSCOOR à Saint Etienne, France. Elle est spécialisée dans le secteur d'activité des
Technologies et services de l’information. Son effectif est compris entre 11 et 50 salariés.
Qweeby est un pure-player sur le marché du B to B et B to G. Elle conçoit et opère

des solutions de dématérialisation dynamique des factures permettant une transmission
tracée et sécurisée de la facture au client destinataire sous la forme de données exploitables
directement dans ses outils. La facture électronique devient ainsi le point de départ de
nombreuses opportunités au service de la performance financière de l’entreprise.
II.2.2 L’approche Qweeby

Le principe est simple, la facture client est générée par l'outil de gestion de l'émetteur
(ERP) au format PDF, quel qu'il soit. Les factures PDF sont traitées par le composant logiciel
Qweeby installé chez l'émetteur (sur son poste ou son serveur). Elle est ensuite signée avec
un certificat électronique prouvant son authenticité et son intégrité, puis cryptée et transmise
à la plateforme technique Qweeby, où les données sont extraites et converties au format
attendu par chaque client destinataire (PDF signé, Echange de données Informatisé (EDI),
Chorus, Factur-X, SdI, interopérabilité ou papier...) et transmis au destinataire. L'expéditeur
dispose d’informations détaillées sur la transmission de chaque facture, ainsi que de
fonctionnalités d’automatisation, de suivi, de relance, etc. Des données sont récupérées
23
également sur les actions effectuées par les utilisateurs du destinataire sur chaque facture
reçue.
La solution Qweeby est une plateforme multimodale de transmission des factures

clients, assurant de manière transparente et fluide l’inévitable cohabitation des modalités de
transmission et de formats hétérogènes au sein du portefeuille client de toute entreprise.
Toutefois, cette approche est complètement nouvelle et part de zéro, car les flux de
facturation papier ne fournissent aucune traçabilité ni informations de ce genre.
L’identification et l’extraction des informations réellement exploitables et significatives
présentent une grande complexité car elles se déroulent en mode itératif : identification d’une
piste, extraction puis analyse des données, discussion avec des clients pour valider l’intérêt
des informations, nouvelle extraction de données, analyses intégrant les commentaires ou
suggestions des clients, discussion avec les clients, et ainsi de suite.
La figure 15 montre le fonctionnement du dispositif de Qweeby.
Figure 15 – Le principe de fonctionnement du dispositif de Qweeby
24
II.2.3 Les atouts de l’entreprise

Qweeby répond à trois enjeux liés à la facturation client :
 Gagner en productivité par l’élimination des tâches manuelles chronophages

ou énergivore.
 Répondre aux attentes des clients notamment grands comptes ou utilisateurs

d’outils de e-procurement.
 Améliorer et optimiser le suivi du flux de facturation pour sécuriser dès

l’envoi le paiement à échéance par la mise sous contrôle des risques ou aléas
générateurs de retards (factures non reçues, perdues, oubliées…).
Qweeby élimine l’effet tunnel qui accompagne la facturation dans le B2B :

mobilisation des équipes sur l’envoi des factures selon les attentes (exigences) des
destinataires et absence de visibilité entre l’envoi et l’échéance. Cet effet tunnel détourne les
équipes de leur priorité : faire rentrer les règlements à échéance et gérer les réels problèmes.
En 2020, Qweeby a opéré près de 2,5 millions de factures de vente pour une valeur
d’environ 3 milliards d’euros.
La transmission via Qweeby apporte de nombreux avantages :
 Conformité avec les attentes des destinataires quelles qu’elles soient : EDI,
plateformes de e-procurement (Ariba, Coupa, Cegedim…) ou Chorus Portail
Pro, ou simple notification e-mail avec la facture en pièce jointe ou sous
forme de lien tracé (groupements quotidien ou hebdomadaires possible) ;
 Gains de productivité dans l’envoi des factures : génération automatique des

notifications e-mail, envoi à plusieurs destinataires d’un coup (gestion des
filières avec les validations ou informations), automatisation d’actions
chronophages, relances…
 Traçabilité totale des envois : suivi des détaillé des consultations, alertes ou
rappels, duplicatas d’un clic…
 Conformité fiscale dans la transmission et la conservation des pièces (art.

289-VII du CGI) ;
 Embarquement de services associés à la facturation : services de paiement en

ligne, scénarios de suivi ou de relances, informations clients…
25
Bref, les e-factures de vente opérées par Qweeby développent de superpouvoirs :
Figure 16 – Les avantages de la transmission via Qweeby
II.2.4 Les clients de Qweeby

Parmi les clients de Qweeby, on peut citer, dans le domaine de la distribution E.
Leclerc. Dans le domaine de l’industrie Ophtalmic et enfin dans le domaine des services
Topnet (le premier client tunisien de Qweeby). Plus de clients par domaine sont montrés par
la figure 17.
Figure 17 – Les clients de Qweeby
II.3 Etude de l’existant

L’activité de Qweeby se structure autour :
 Des entités émettrices et réceptrices quel que soit le type : client

consommateur, point de consommation, fournisseur ou récepteur.
 Des flux de facturation entre ces entités ;
 Les branches par lesquels passent les flux de facturation.
26
 Des utilisateurs liés aux entités et réalisant des actions.
II.3.1 QweebyNet
QweebyNet est un élément opérationnel central dans la prestation de services de
Qweeby. Il s’agit d’une plateforme internet sécurisée pour le traitement de facturation
Qweeby et sur laquelle les émetteurs peuvent suivre leurs envois et, pour certains
destinataires, consulter les flux qui leur sont adressés. QweebyNet regroupe de nombreuses
fonctionnalités clés (notifications de flux, alertes, rappels, consultations, recherche, etc.).
La base de données QweebyNet comporte plusieurs tables qui contiennent un

ensemble d’informations, à savoir :
 Les émetteurs de flux et les destinataires.
 Les différentes relations entre émetteurs et récepteurs de facture.
 Les détails des flux envoyés.
 Les types d’anomalies reconnues.
 Les différents statuts par lesquelles passe le flux.
 Les branches par lesquelles passe le flux pour la conversion dans un format
prédéfini.
 Les relances et les alertes envoyés aux clients pour payer les flux consommés.
 Les actions effectuées sur les flux.
 Les utilisateurs de la plateforme QweebyNet.
La connexion à l’application QweebyNet se fait moyennant une interface

d’authentification donnée par la figure suivante.
27
Figure 18 – Interface de connexion à l’application QweebyNet
Les factures émises peuvent être visualisées sur l’application qui offre en plus un
suivi de ces factures
Figure 19 – Volet Factures Emis sur l’application QweebyNet
28
II.3.2 Odoo
Qweeby dispose d’un ERP Odoo. C’est un progiciel open source de
gestion intégrée comprenant de très nombreux modules permettant de simplifier la gestion
d’entreprise dans son ensemble. [19]
Odoo permet à Qweeby de gérer des différents modules, parmi lesquels on peut citer :
 Le module Contact : ce module permet de gérer les informations sur les

clients de Qweeby (contact, pays, volume flux cible, etc.), les formules
tarifaires, les chaînes commerciales des clients (distributeur, revendeur,
groupement) etc.
 Le module Assistance technique : Ce module permet d’organiser la gestion

des tickets de support provenant de la part des clients Qweeby afin de
résoudre leurs problèmes et ce qui permet aux équipes d’identifier la cause
première d'un incident et ainsi l'éviter à l'avenir.
 Le module événement : Les événements présentent un moyen de

communication indispensable pour Qweeby, et permettent en un temps record
de présenter et promouvoir son service, et de prendre contact directe avec les
prospects et clients intéressés par les activités de l’entreprise.
Outre ces modules, il y en a beaucoup d’autres tels que la gestion de la relation client
(CRM), la gestion de vente, la gestion de la comptabilité etc.
De ce fait, on remarque que les données sont éparpillées entre les systèmes de
production du service de dématérialisation (QweebyNet) où les flux réalisés par les clients
sont traités et les outils métier (Odoo) où on peut trouver tous les informations sur les clients
de Qweeby (contact, donneurs d’ordres destinataires, les abonnements, les tickets etc.). La
séparation entre les flux de données de Odoo et celle de QweebyNet est illustrée par la figure
20 ci-dessous :
29
Figure 20 – Architecture du Système d’information de Qweeby
Fait intéressant, Qweeby ne dispose d’aucun système d’aide à la décision. De plus,

tout processus d’analyse et de prise de décision à tous les niveaux est essentiellement basé
sur des rapports dont les données sont extraites et consolidées manuellement à partir des
systèmes transactionnels.
II.3.3 Problématique
Après avoir analysé le système existant, nous avons pu dresser les insuffisances qui
le marquent actuellement.
Nous citons les difficultés les plus importantes :
 Dans la base de production QweebyNet et la base de données Odoo, un même

client n’a pas le même identifiant. Donc il est très difficile d’établir une
relation entre les deux systèmes et visualiser, par exemple, les flux réalisés
par un client consommateur qui appartient à un tel groupement.
 De plus, nous avons constaté que pour certains clients, nous avons la TVA et
la SIRET mais pour d'autres non, ce qui rend la fusion de la table entité de
QweebyNet et la table des clients de Odoo difficile. De même, la table entité
regroupe tous les points de consommations, les clients consommateurs et les
30
fournisseurs ainsi que les entités réceptrices alors que la base Odoo ne
contient que les clients et les points de consommations.
 Manque d’une solution décisionnelle pour analyser les activités de

l’entreprise : flux opérés, volume de consommation par rapport à
l’abonnement, etc.
 La difficulté de la gestion et l’organisation des données pertinentes et

stratégiques qui se trouvent au niveau de la base de données opérationnelle.
 Les rapports générés à partir des bases de données de production ne

permettent pas le stockage, la restitution et la modification des données de
diverses applications hébergées sur des différents serveurs.
 Afin d’élaborer des rapports, les décideurs sont obligés d’avoir recours à des
outils externes tel que Excel. Ce traitement manuel entraîne des retards
considérables dans la réalisation des rapports.
Notre problématique couvre donc la mise en œuvre d’une solution pour l’aide à la
décision et l’analyse de données concernant l’activité principale de QweebyNet ainsi que ses
clients.
II.4 Solution proposée

D’après l’étude précédente, nous avons remarqué que le système informatique actuel
ne répond pas aux besoins des décideurs.
De ce fait, Dans le cadre de notre projet, nous proposons une solution pour la société
QWEEBY qui consiste à assurer la liaison entre les deux systèmes différents, automatiser le
processus de la collecte des données pour l’alimentation du DWH et à mettre en place un
tableau de bord pour analyser les données clients, les flux de facturation ainsi que d’autres
données de l’entreprise ce qui permet de répondre aux besoins des utilisateurs finaux en leur
facilitant l’accès aux données importantes et en leur permettant de naviguer dans
l’information en fonction de leurs besoins.
II.5 Spécification des besoins

Nous présentons dans cette partie, les différents besoins fonctionnels et non
fonctionnels requis pour l’implémentation de la solution envisagée.
31
II.5.1 Les besoins fonctionnels
La solution BI à implémenter doit offrir les fonctionnalités suivantes :
 Appliquer le processus ETL pour traiter les données qui sont parvenus des
sources différentes.
 Modéliser un datawarehouse contenant les données utiles et pertinentes pour

assurer une analyse efficace.
 Produire une vue claire sous forme de tableau de bord pour les décideurs de
l’entreprise.
II.5.2 Les besoins non fonctionnels

Pour le bon fonctionnement de notre solution BI, nous proposons les besoins non
fonctionnels suivants :
 La disponibilité : Le système doit être disponible à tout moment pour

l'utilisateur.
 La fiabilité : L’application doit répondre à tous les besoins de l’utilisateur.
 La sécurité : Il faut assurer une sécurité totale sur les données.
 La performance : la solution doit répondre de manière optimale, à travers

ses fonctionnalités, aux besoins des utilisateurs.
 La rapidité : : la solution doit permettre un accès rapide aux informations.
 L’ergonomie : Il faut que les rapports et les tableaux de bord soient bien
clairs en choisissant des meilleurs styles (couleur, forme, etc.).
II.6 Conclusion
Dans ce chapitre, nous avons procédé à l’étude du cadre général de notre projet par
la présentation de l’organisme d’accueil, en détaillant l’existant et en montrant ses limites.
Nous avons également souligné les objectifs de la solution proposée et identifie ses besoins
fonctionnels et non fonctionnels.
Dans le chapitre qui suit, nous allons aborder la modélisation multidimensionnelle

de notre solution.
32
CHAPITRE III MODELISATION MULTIDIMENSIONNELLE
Chapitre III. Modélisation multidimensionnelle
III.1 Introduction
Une fois les besoins des utilisateurs sont bien définis, nous avons eu recours à la
modélisation multidimensionnelle pour concevoir notre DWH. Les détails de la conception
font l’objet du présent. Ils couvrent les tables des faits, les dimensions associées ainsi que le
schéma conceptuel des différents datamarts de notre entrepôt.
III.2 Processus de la modélisation multidimensionnelle

Pour concevoir le modèle multidimensionnel, on doit passer par quatre étapes
importantes :
 Choisir l’activité à modéliser.
 Définir les dimensions décrivant une ligne de la table de fait.
 Bien choisir les indicateurs clé de performances permettant de répondre aux

besoins des décideurs.
 Construire le modèle multidimensionnel relatif à l’activité choisie.
III.3 Modélisation du notre datawarehouse

Pour simplifier et faciliter la lisibilité de notre datawarehouse, nous l’avons découpé
en plusieurs datamarts. Ces datamarts partagent les dimensions suivantes: entités, date et
Heure.
III.3.1 Datamart Flux

III.3.1.1 Description
Les flux de facturation sont au cœur de l’activité quotidienne de Qweeby, c’est

pourquoi il est nécessaire pour les décideurs d’avoir une visibilité globale en temps réel des
informations sur ces flux. Ainsi, dans ce datamart nous allons regrouper les informations
décrivant le déroulement des flux de facturation en présentant les caractéristiques (type
document, format, etc.), les entités émettrices et réceptrices du flux ainsi que les branches
par lesquelles passent les flux.
33
III.3.1.2 Les dimensions
Les dimensions qui constituent notre datamart flux sont :
 Dimension flux : contient les informations utiles sur le flux de facturation.

Le tableau 4 présente les différents attributs de cette dimension.
Tableau 4 – Dimension Flux
Attribut Type Signification

Id_flux Int Clé primaire de la dimension flux
Id_erreur Int Clé étrangère de l’erreur rencontrée
Numéro_flux Varchar Le numéro unique de flux
Type_document Varchar Type de flux (facture, document,
compte rendu …)
Format_transmission Varchar Format de flux (PDF, Edi, DOD,
XML…)
Type_transmission Varchar Type de transmission de flux
(FTP,MAIL, WEB SERVICE…)
Anomalie Varchar « Document en anomalie » si le flux est
défectueux, sinon « document correct »
 Dimension Erreurs : Lors de la transmission des flux, différentes erreurs

peuvent survenir. Le tableau suivant présente les différents attributs de la
dimension :
Tableau 5 – Dimension Erreurs

Id_erreur Int Clé primaire de la dimension erreur
Label Varchar Label de l’erreur
Description Varchar Description de l’erreur
34
 Dimension entité : contient toutes les informations importantes à savoir sur

les entités qu’elles soient émettrices ou réceptrices. Le tableau 6 présente les
attributs de l’entité.
Tableau 6 – Dimension Entité

Id_entite Int Clé primaire de la dimension Entité
Id_pays Int Identifiant de la dimension pays
Id_client_consommateur Int Identifiant de client consommateur
auquel appartient le point de
consommation
Id_odoo Int Clé de l’entité dans Odoo
TVA_intra Varchar Identifiant de l’entreprise au sein de
l’union européenne
Siret Varchar Numéro permettant d’identifier
chaque entité auprès des
administrations
Nom_entité Varchar Nom de l’entité
Active Boolean 1 si l’entité est active sinon 0
Type Varchar Type de l’entité (Client
Consommateur, point de
consommation ou autre…)
 Dimension Branche : contient les caractéristiques principales des branches

par lesquelles passent les flux pour savoir le type de dématérialisation. Nous
présentons les attributs dans le tableau suivant pour cette dimension.
Tableau 7 – Dimension Branche

Id_Branche Int Clé primaire de la dimension Branche
Ref_Branche Int Référence de la branche
Nom_Branche Varchar Nom de la branche
Type Varchar Type de la dématérialisation
Transmission Varchar Format de transmission
 Dimension Client Consommateur : Cette dimension regroupe tous les

clients consommateurs avec leurs caractéristiques. Le tableau 8 illustre la
dimensions client.
35
Tableau 8 – Dimension client consommateur

Id_client_consommateur Int Clé primaire de la dimension client
Id_groupement Int Id de groupement auquel appartient
le client
Id_revendeur Int Id de revendeur de client s’il en y a
Id_abonnement Int Clé étrangère de l’abonnement de
client
Id_odoo Int Clé de client dans Odoo
Tva_intra Varchar Identifiant de l’entreprise au sein de
l’union européenne
Siret Varchar Numéro permettant d’identifier
chaque client auprès des
administrations
Nom_client_consommateur Varchar Nom du client consommateur
Active Boolean 1 si le client est active sinon 0
Formule Varchar Formule choisit par le client pour
bénéficier de services commerciaux
(Express, Access,Success)
Condition_paiement Varchar Condition de paiement de client
Volume_annuel_cible Int Volume annuel de flux cible fixé par
client
 Dimension Abonnement : Présente la liste des abonnements offertes par
Qweeby. Les différents attributs de la dimension sont présentés dans le
tableau suivant :
Tableau 9 – Dimension Abonnement

Id_abonnement Int Clé primaire de la dimension abonnement
Nom_abonnement Varchar Nom de l’abonnement
Référence Varchar Référence de l’abonnement
Modèle_abonnement Varchar Modèle de l’abonnement (mensuel, annuel)
Nom_vendeur Varchar Nom de vendeur de l’abonnement
 Dimension groupement : présente les groupements des clients que Qweeby
dispose. Les attributs de la dimension sont présentés dans le tableau suivant :
Tableau 10 – Dimension Groupement

Id_groupement Int Clé primaire de la dimension groupement
Nom_groupement Varchar Nom du groupement
36
 Dimension revendeur : présente les revendeurs que Qweeby dispose. Les

attributs de la dimension sont présentés dans le tableau suivant :
Tableau 11 – Dimension Revendeur

Id_revendeur Int Clé primaire de la dimension revendeur
Nom_revendeur Varchar Nom du revendeur
 Dimension pays : cette dimension contient la liste des pays. Le tableau 12

illustre ces attributs.
Tableau 12 – Dimension pays
Attribut Type
Id_pays Int
Code_pays Varchar
Nom_pays Varchar
 Dimension heure : c’est une dimension statique contenant toutes les heures
du jour (heure, minute, seconde). Les attributs de cette dimension sont dans
le tableau suivant.
Tableau 13 – Dimension Heure
Attribut Type
Id_heure Int
Heure_complete Time
Heure Int
Minute Int
Seconde Int
 Dimension Date : Contient toutes les dates avec plusieurs hiérarchies. Le

jour de la semaine est le niveau le plus détaillé de cette dimension. Le tableau
14 présente les différents attributs.
37
Tableau 14 – Dimension Date
Attribut Type
Id_date Int
Date Date
Jour_mois Int
Jour_semaine Varchar
Semaine Varchar
Mois Varchar
Année Int
III.3.1.3 La table de fait
Tout sujet d’analyse est représenté par un fait. Après avoir identifié les tables de
dimension, il est possible maintenant de présenter la table de faits qui contient les différentes
clés étrangères des dimensions adjacentes et les mesures. Dans notre cas nous avons la table
de fait: Fait Suivi Flux.
Fait Suivi Flux : permet de suivre les mesures et les différentes opérations effectuées
sur le flux. Une mesure est un indicateur permettant d’évaluer une quantité par rapport aux
croisements de dimensions d’analyse. Ces mesures se trouvent dans la table de fait.
Pour notre Datamart, nous avons les indicateurs décrits dans le tableau suivant
38
Tableau 15 – Les mesures du fait Flux
Table de faits Mesures Description
Fait Suivi Flux Volume Flux total Volume de flux total réalisé
Volume Flux par branche Volume des flux passant par

chaque branche.
Volume Flux émis Volume des flux émis pour

chaque entité.
Volume Flux reçu Volume des flux reçus par

chaque entité.
Volume Flux par type de Volume Flux par chaque

document type de flux (facture, avoir,
etc.)
Volume Flux annuel réel Volume de flux annuel réel

pour chaque client d’un client.
Dépassement Le dépassement s’il existe

fait par le client en calculant
le volume réel réalisé par
rapport au volume annuel
cible fixé par le client.
Taux d’anomalie des flux La pourcentage des flux

défectueux
Délai moyen de traitement Délai moyen de traitement

de flux
Ainsi notre fait flux contient outre les clés étrangères, les mesures susmentionnées.
Il est présenté par le tableau 16.
39
Tableau 16 – Fait Suivi Flux
Attribut Type
Id_flux Int
Id_emetteur Int
Id_recepteur Int
Id_branche Int
Id_heure_constitution Int
Id_date_constitution Int
Total_Flux Int
Volume_emis Int
Volume_reçus Int
Taux anomalie Float
dépassement Int
Délai moyen de traitement Int
Le schéma suivant donne la représentation conceptuelle de notre datamart relative au

suivi des flux.
III.3.1.4 Le modèle multidimensionnel du datamart Suivi Flux
Dans la figure ci-dessous, nous allons présenter le modèle en flocon de notre

datamart suivi Flux.
40
Figure 21 – Fait Suivi Flux
III.3.2 Datamart Reminders

Le suivi des clients en retard de paiement est un travail qui présente de nombreux
défis pour l'entreprise, notamment en termes de trésorerie. De ce fait, notre datamart
Reminders vise à une gestion du suivi client permettant à Qweeby de réduire les retards de
paiement et éviter les impayés sur les clients à risque.
41
Pour permettre aux décideurs d’avoir une vue d’ensemble sur les rappels, nous avons
dégagé les dimensions suivantes.
 Dimension Reminder : contient les caractéristiques principales des rappels

lancés aux clients. Ils peuvent être relatives soit à une relance de la facture
soit une alerte de paiement. Nous présentons les attributs dans le tableau
suivant pour cette dimension.
Tableau 17 – Dimension Reminder

Id_Reminder Int Clé primaire de la dimension
Reminder
Name_reminder Varchar Titre du reminder
R_type Varchar Type du reminder (alerte, relance
ou autres)
R_active Boolean 0 : reminder supprimé
1 : reminder active
 Dimension Utilisateurs : contient les caractéristiques principales des
utilisateurs qui ont lancés les Reminders. Nous présentons les attributs dans
le tableau suivant pour cette dimension.
Tableau 18 – Dimension Utilisateur

Id_Utilisateur Int Clé primaire de la dimension
utilisateur
U_email Varchar Email utilisateur
U_language Varchar Language utilisé par l’utilisateur
La table de fait Reminders permet d’évaluer le volume des rappels par type et par
entité. Il est décrit par le tableau suivant.
42
 Fait Suivi Reminders :
Tableau 19 – Fait Suivi Reminders

Id_Reminder Int Clé étrangère de la dimension
Reminder
Id_entité Int Clé étrangère de la dimension
Entité
Id_utilisateur Int Clé étrangère de la dimension
Utilisateur
Id_Date_envoi Int Clé étrangère de la dimension
date, présentant ici la date d’envoi
du reminder
Nombre rappels total Int Nombre des rappels total
Nombre relances Int Nombre des relances lancés
Nombre alerte Int Nombre des alertes lancés
III.3.2.4 Le modèle multidimensionnel du datamart Reminders
Dans la figure ci-dessous, nous allons présenter le modèle en étoile de notre datamart
suivi Reminders.
Figure 22 – Fait Suivi Reminders
43
III.3.3 Datamart Assistance

Les entreprises gèrent aujourd'hui plus de données clients que jamais auparavant, y
compris les tickets. Et pour améliorer considérablement la satisfaction client et maintenir la
fidélité à la marque, il est important de fournir un support client de qualité et apporter une
réponse rapide et efficace aux problèmes rencontrés. D’ailleurs, l’objectif de notre datamart
Assistance est d’offrir un suivi de l’assistance technique de Qweeby pour aider à évaluer les
performances globales des opérations de support et identifier les points à améliorer.
Les listes de dimensions qui représentent nos axes d’analyse dans le datamart
Assistance sont :
 Dimension assistance : contient les informations utiles sur les tickets, le

tableau suivant donne plus de détails sur cette dimension :
Tableau 20 – Dimension Assistance
Attribut Type
Id_ticket Int
Nom_ticket Varchar
Sujet_ticket Varchar
Etape_ticket Varchar
 Equipe Helpdesk : présente les équipes qui fournit les solutions techniques
aux clients.
Tableau 21 – Dimension Equipe Helpdesk
Attribut Type
Id_equipe Int
Nom_equipe Varchar
 Fait Suivi Assistance :
44
Tableau 22 – Fait Suivi Assistance

Id_Ticket Int Clé étrangère de la dimension
Assistance
Id_entité Int Clé étrangère de la dimension
Entité
Id_equipe_technique Int Clé étrangère de la dimension
Equipe Helpdesk
Id_Date_creation Int Clé étrangère de la dimension
date, présentant ici la date d’envoi
du ticket
Id_Heure_creation Int Clé étrangère de la dimension
date, présentant ici l’heure d’envoi
du ticket
Id_Date_cloture Int Clé étrangère de la dimension
date, présentant ici la date de
clôture du ticket
Id_Heure_cloture Int Clé étrangère de la dimension
date, présentant ici l’heure de
clôture du ticket
Nombre tickets Int Le volume des tickets reçus
Nombre tickets résolus Int Le volume des tickets clôturés
Nombre tickets en attente Int Nombre tickets en attente
Temps de résolution moyen Int Délai moyen de clôture des tickets
III.3.3.4 Le modèle multidimensionnel du datamart Assistance
Dans la figure ci-dessous, nous allons présenter le modèle en étoile de notre

datamart suivi Assistance.
45
Figure 23 – Fait Suivi Assistance
III.3.4 Datamart Evènements

Aujourd’hui, il est très important pour une entreprise de mettre en place une bonne
communication et diffuser du contenu dans le but d’attirer des clients potentiels et
promouvoir son service. De ce fait, Qweeby a fait recours à la communication digitale
événementielle, ce qui a abouti à un engagement plus large et plus de productivité. Ainsi
dans ce datamart, nous allons regrouper les informations décrivant les évènements et les
participants pour permettre aux décideurs d’avoir une vision synthétique sur la participation
de leurs clients et des clients prospects. Ce datamart permet également d’identifier les
évènements marquants de Qweeby.
Les dimensions qui constituent notre datamart Evènements sont :
 Dimension Evènements : contient les informations utiles sur les

évènements. Le tableau 23 présente les différents attributs de cette dimension.
46
Tableau 23 – Dimension Evénements
Attribut Type
Id_événement Int
Id_statut Int
Titre_événement Varchar
Catégorie_évènement Varchar
Nom_responsable Varchar
 Dimension Statut : contient les statuts possibles pour les évènements.
Tableau 24 – Dimension Statut
Attribut Type
Id_Statut Int
Nom_statut Varchar
 Dimension Participants : contient les informations sur les participants. Le

tableau 25 présente les différents attributs de cette dimension.
Tableau 25 – Dimension Participants
Attribut Type
Id_participant Int
Nom_participant Varchar
Id_entité Int
Notre table de fait est : Fait Suivi Evènements. Elle permet de suivre les événements
organisés et leurs participants. Le tableau suivant illustre les attributs de cette table :
Tableau 26 – Fait Suivi Evénements
Attribut Type
Id_événement Int
Id_participant Int
Id_date_événement Int
Id_deure_événements Int
Total évènements Int
Total participants Int
Pourcentage_clients Float
Nombre d’inscriptions Int
47
III.3.4.4 Le modèle multidimensionnel du datamart Suivi Evénements
Dans la figure ci-dessous, nous allons présenter le modèle en flocon de notre

datamart suivi Evénements.
Figure 24 – Fait Suivi Evénements
III.4 Conclusion
Dans ce chapitre, nous avons détaillé la conception multidimensionnelle de notre
solution décisionnelle en passant par la description des axes d’analyses et nos faits. Dans ce
qui suit, nous allons définir l’environnement de travail que nous allons utiliser pour réaliser
notre solution, en précisant les outils matériels et logiciels ainsi que les étapes de la
réalisation.
48
CHAPITRE IV REALISATION
Chapitre IV. Réalisation
IV.1 Introduction
Après avoir expliqué la modélisation conceptuelle, nous allons expliciter notre
solution décisionnelle. Nous allons présenter le cadre de réalisation de notre solution, à
savoir l’environnement matériel et logiciel utilisé. Nous allons également illustrer quelques
pages de notre solution décisionnelle.
IV.2 Environnement de travail

IV.2.1 Environnement matériel
Nous avons utilisé pour la réalisation de notre solution :
 Un ordinateur dont les capacités sont les suivantes :
 Modèle : HP Notebook 15-ay005nk
 Mémoire vive (RAM): 8 Go
 Processeur : Intel® Core™ i3-5005CPU @ 2.00 GHz
 Système d’exploitation: Windows 10 Professionnel 64 bit
 Disque Dur : 1 To
IV.2.2 Environnement logiciel

Afin de réaliser le travail souhaité, nous nous sommes concentrés dans cette section
sur le choix de logiciels et d’outils nécessaires.
Dans ce qui suit, nous allons présenter ces outils avec plus de détails.
 Wampserver : (anciennement WAMP5) est une plateforme de

développement Web de type WAMP, permettant de faire fonctionner
localement sans se connecter à un serveur externe des scripts PHP.
WampServer n'est pas en soi un logiciel, mais un environnement comprenant
deux serveurs (Apache et MySQL), un interpréteur de script (PHP), ainsi que
phpMyAdmin pour l'administration Web des bases MySQL [20].
49
 JDK 14 : est un ensemble d'outils dont les développeurs ont besoin pour
développer des logiciels basés sur Java. [21]
 Talend : est un ETL qui permet d’extraire des données d’une source, de
modifier ces données, puis de les recharger vers une destination. [22]
 Power BI est une solution de Business Intelligence développée par Microsoft

pour permettre aux entreprises d’agréger, d’analyser et de visualiser les
données en provenance de sources multiples sous forme des tableaux de bord
et de les diffuser au sein d’une entreprise. [23]
 Plesk : est une interface de gestion de serveur payante. Elle permet aux clients
d’hébergement Web d’exécuter de nombreuses tâches depuis une interface
robuste et simple d’utilisation. Cette solution inclut tous les outils de création
et de gestion des sites Web, boîtes mail, bases de données, etc. La capture
d’écran suivante nous permet de découvrir la structure de l’interface et
l’organisation des différents outils. [24]
 FileZilla : est un client FTP, FTPS et SFTP, gratuit, rapide et sécurisé. Il

Permet l'échange de fichiers entre un ordinateur et un serveur ou vice-versa.
[25]
IV.3 Réalisation de notre solution

Dans cette partie nous détaillons les différentes étapes effectuées pour
l’implémentation de notre solution afin de présenter le reporting.
IV.3.1 Processus ETL

IV.3.1.1 Extraction des données
Pour extraire seulement les données utiles destinées à l’exploitation pour l’analyse,
l’outil d’ETL Talend va se connecter aux différentes sources à disposition, qu’il s’agisse
d’applications ou des bases en production qui sont hébergées sur un serveur Linux distant.
Dans notre cas, nous avons une base de données MySQL intitulée
« dwh_qweebynet » composée de 109 tables liées entre elles. Après avoir fait une étude
détaillée de la base, nous sommes arrivés à extraire 15 tables qui peuvent répondre à nos
besoins.
50
Nous pouvons visualiser les tables de notre base de données distante en utilisant
l’interface plesk comme il est montré sur la figure suivante :
Figure 25 – Volet base de données sur plesk
Une vue de la base QweebyNet est donnée par la figure ci-dessous.
Figure 26 – La base de données QweebyNet
Pour que nous puissions extraire les données utiles par l’ETL Talend, nous devons,
en premier lieu, établir la connexion à la base de donnée source comme l’illustre la figure
27 suivante.
51
Figure 27 – Connexion à la base source de QweebyNet via Talend
Ensuite, nous devons sélectionner et récupérer les tables spécifiques indispensables

pour notre projet, comme montré par la figure 28 ci-dessous.
Figure 28 – Extraction des tables utiles pour l’analyse
52
Outre la base de QweebyNet, nous avons également besoins de la base de l’ERP

Odoo où toutes les données concernant les clients sont centralisées.
Pour pouvoir extraire ces données, nous devons établir une connexion. L’API utilisé
pour cette connexion est le JDBC. Sachant que JDBC est une API qui permet un accès aux
bases de données avec Java. Malheureusement la version gratuite de cet outil est une version
de test d’un mois. De ce fait, nous étions obligés de travailler sur des extractions Excel de la
base odoo.
Parmi les 314 tables de Odoo, nous avons récupérer des extractions des tables Clients
Consommateurs, points de consommation, abonnements, assistance et événements.
IV.3.1.2 Transformation des données
Cette phase consiste à mettre en place un Job Talend regroupant les opérations de
manipulation et les fonctions de mise au format nécessaires des données extraites de la
source pour obtenir les données à charger notre entrepôt de données distant intitulé
« dwh_bi ».
Pour certaines sources de données, il faudra une manipulation très légère voire
aucune, des données. Dans d'autres cas, un ou plusieurs des types de transformations
suivantes peuvent être nécessaires pour répondre aux besoins des exigences techniques de
l’entreprise :
 Choisir uniquement des colonnes spécifiques à charger.
 Joindre les données provenant de plusieurs sources hétérogènes.
 Générer les substitutions de valeurs de clé.
 Fractionner une colonne en plusieurs colonnes.
 Répartir des colonnes dans des tables séparées
Prenons, à titre d’exemple, un Job Talend pour illustrer la transformation de la

table i_invoice (table des flux) dans la dimension dim_flux présentée par les figures
suivantes :
53
Figure 29 – Transformation de la table i_invoice
Dans ce Job nous avons les composants suivants :
 TFilterColumns : permet d'homogénéiser des schémas, soit en fonction de l'ordre

des colonnes, soit en supprimant ou en ajoutant des colonnes. [26]
 TMap est un élément qui permet d’effectuer différentes jointures entre les différents
composants des sources de données, réaliser des transformations sur des flux de
données, les rendre homogènes et les diriger vers les tables cibles.
Moyennant le composant tMap, nous avons pu effectuer les transformations

suivantes sur nos tables :
 Remplacer les champs vides.
 Eliminer les données redondantes.
 Changer les types de quelques attributs pour répondre aux besoins

analytiques.
 Éliminer les colonnes vides.
 Éliminer les colonnes dont on n’a pas besoin via tFilterColumns.
54
Figure 30 – tMap effectuée sur la table i_invoice
Toutes les autres dimensions ont été construites de la même manière. Une fois que
les dimensions sont chargées, il faudra charger les tables de fait.
IV.3.1.3 Chargement des données
Pendant la phase de chargement, nous chargerons les données dans le DWH en

exécutant les jobs Talend. Les figures suivantes illustrent le chargement de la dimension
Branche dans le DWH. La première étape consiste à exporter le job Talend.
Figure 31 – Construction du Job Talend
55
Ensuite, nous transférons les jobs exportés sur la machine Linux distante à l’aide de
Filezilla.
Figure 32 – Transfert des Job Talend vers la machine Linux via Filezilla
Après, nous utilisons le planificateur des tâches sur plesk pour créer des tâches
planifiées en précisant la fréquence de l’exécution, l’heure exacte de l’exécution de nos jobs.
Figure 33 – Planification de l'exécution du Job Talend via Plesk
Après avoir terminé le processus ETL et obtenu des données nettoyées et de valeurs,
nous pouvons passer à la phase de Reporting
56
IV.3.2 Reporting
Avec la quantité gigantesque de données générées aujourd'hui, l'échange
d'informations devient difficile. De ce fait, la visualisation des données semble le moyen le
plus efficace et le plus rapide pour transmettre des informations utiles et significatives, toute
en capturant notre attention et attirant notre regard sur le message communiqué avec les
graphiques et ceci dans le but d’identifier rapidement les tendances et les valeurs
inhabituelles et prendre des meilleurs décisions en s'appuyant sur ces visuels.
Pour commencer, nous allons établir la connexion entre Power BI Desktop et la base
de données comme illustré par la figure suivante :
Figure 34 – Connexion Power BI à notre entrepôt
Ensuite, nous allons commencer à construire nos rapports.
IV.3.2.1 Structure physique du tableau de bord
La présentation du nos rapports est un élément primordial. En effet, outre le contenu,

la présentation détermine le degré d’utilisation des tableaux de bord, d’où sa réussite. Pour
cela nous avons choisi soigneusement les différents types de graphes pour bien illustrer les
indicateurs, ainsi que les couleurs utilisées qui doivent respecter la charte graphique de
Qweeby. D’ailleurs, pour assurer l’ergonomie de nos rapports, nous avons respecté certaines
règles de base :
57
 Navigation simple entre les différentes pages : permettre de basculer d’une

page à une autre en cliquant sur les boutons disponibles.
 La mise en page similaire pour toutes les feuille, couleur et police de

caractères.
 La cohérence entre les éléments graphiques et ergonomique.
IV.3.2.2 Page D’accueil
La figure 35 suivante présente la page d’accueil de notre travail.
Figure 35 – Page d'accueil
Dans cette page, nous présentons des indicateurs clé de performance globaux pour
que l’utilisateur ait une vision synthétique sur les différents sujets :
 Nombre des entités par type (Clients consommateurs, points de consommation, les
récepteurs et les fournisseurs).
 Nombre des branches par lesquels nous envoyons les flux.
 Nombre total des flux que l’entreprise a effectué depuis le début de son activité.
 Nombre total des tickets que Qweeby a reçu.
 Nombre total des évènements que Qweeby a organisé.
 Nombre total des rappels que l’entreprise a lancés.
58
Nous trouvons également dans cette page des boutons pour les différents rapports de notre
projet : Rapport Flux, Rapport Reminders, Rapport Assistance et enfin Rapport Evénements.
IV.3.2.3 Rapport FLUX
IV.3.2.3.1 Feuille 1 du tableau de bord flux
La figure 36 ci-dessous présente un aperçu de la première feuille de notre tableau de

bord dédié pour le suivi des flux de l’entreprise.
Figure 36 – Tableau de bord Flux 1/2
Dans ce tableau de bord, nous pouvons analyser et suivre les flux facilement en
sélectionnant les différents filtres disponibles :
 Type : Filtrer par type d’entité de Qweeby.
 Anomalie : Sélectionner les flux soient en anomalie soient corrects.
 Année et Mois, Semaine et Jour du traitement, pour filtrer les flux traités
sur une période de temps spécifique.
 Un autre filtre est mis sur la date du flux de facturation.
Voici une vision approfondie sur les statistiques présentes sur la figure ci-dessus.
59
Figure 37 – Flux par branche
L’histogramme illustré par la figure 37 ci-dessus présente le volume des flux réalisé
par chaque branche toute en indiquant si le volume de flux est défectueux (en rouge) ou sain
(en vert). En effet, nous remarquons que la branche IF_QWEEBYNET c’est celle qui réalise
le plus grand volume des flux : 3 077 472 flux.
Figure 38 – Flux par format de transmission
Dans la figure 38 ci-dessus, l’histogramme permet de suivre le volume total des flux
par format de transmission, d’où nous remarquons que les formats PDF et DOD sont les plus
utilisés avec 104 000 flux en anomalie et 3 103 236 flux sain pour le format PDF et 19 317
flux en anomalie et 3 118 181 flux corrects pour le format DOD.
60
Figure 39 – Flux & Entités par pays
La figure 39 représente une carte qui permet de visualiser le nombre des entités et le
volume des flux par pays. La majorité des entités de Qweeby sont en France avec un Volume
des flux réalisé est égale à presque 6 570K Flux.
Figure 40 – Flux par type de document
Le camembert présenté par la figure 40 illustre la répartition de volumes des flux

réalisé en fonction du type de document. D’ailleurs 93% des flux de Qweeby sont des
factures, 5% sont des avoirs, et le 2% qui reste est divisé entre les relevés, les documents et
autres types.
61
Dans la première page de notre tableau de bord, nous trouvons également des boutons
pour pouvoir basculer vers les différentes feuilles.
IV.3.2.3.2 Feuille 2 du tableau de bord Flux
En cliquant sur le bouton Suivant, nous nous trouvons sur la deuxième feuille du
rapport Flux, présentée par la figure suivante.
Figure 41 – Tableau de bord Flux 2/2
Nous avons filtré ce tableau de bord en fonction de la branche CARREFOUR et

l’année 2021, ce qui nous donne un volume des flux égale à 39848 avec un pourcentage
d’anomalie de 0.1% pour la branche indiquée ci-dessus.
Nous avons présenté également les 5 top clients consommateurs en fonction de

volume des flux réalisé par la branche carrefour en 2021 qui sont Lou Légumes, Alain
Masse, Promaree Surgel, L2G et enfin Vita Coco France.
Nous avons inséré un camembert pour afficher les 5 premiers erreurs fréquents pour
la branche indiquée.
Et enfin, nous avons suivi l’évolution des flux totaux et des flux erronés au fil du
temps.
IV.3.2.3.3 Feuille pourcentage anomalie
En cliquant sur le bouton Anomalie, cette page illustrée par la figure suivante
s’ouvre.
62
Figure 42 – Pourcentage anomalie
Afin de mieux expliquer l’interface nous allons la détailler sur 2 figures.
Figure 43 – Pourcentage anomalie par branche
La figure 43 présente les pourcentages d’anomalie pour chaque branche. Cette

analyse est très importante pour détecter les branches qui produisent un volume énorme de
flux défectueux par rapport au volume total qu’elles réalisent afin de prendre les mesures
nécessaires pour la correction de ces anomalies. Par exemple, la branche ITM produit un
volume des flux 100% en anomalie, la branche IF produit un volume 56,23% en anomalie
etc.
63
Figure 44 – Pourcentage anomalie par entité
Cet Histogramme présenté par la figure 44, illustre les pourcentages d’anomalie filtré
par le type d’entité clients consommateurs et par l’année 2021. Par exemple, nous détectons
que le volume des flux réalisé par l’entité TOOD SRL unipers en 2021 est 100% en
anomalie.
IV.3.2.3.4 Tableau de bord Client Consommateur
Depuis le rapport Flux, nous pouvons également obtenir un rapport spécifique au

client consommateur qui représente l’entité la plus importante et le centre d’intérêt de
l’entreprise Qweeby, et ceci en cliquant sur le bouton Flux/Client. La figure suivante
présente la 1ère feuille du rapport des clients consommateurs.
Figure 45 – 1ère feuille du rapport des clients consommateurs
Dans cette page, nous avons différents filtres qui peuvent être appliqués :
64
 Le statut du client: soit active ou inactive.
 Le groupement du client
 Le revendeur du client
 Le modèle d’abonnement du client
 La formule choisie par le client.
Nous avons 452 clients consommateurs qui sont présentés dans le tableau intitulé
Overview clients consommateurs en indiquant leurs formules à lesquelles ils sont inscrits,
leurs modèles d’abonnement, etc…
Vers la droite, nous présentons le nombre des clients consommateurs par modèle
d’abonnement, d’où la majorité des clients ont opté pour l’abonnement mensuel. Et pour
ceux qui n’ont pas d’abonnement, ils paient ce qu’ils consomment.
Le camembert affiche la répartition de nombre des clients pour chaque formule

offerte par Qweeby. La formule Express a été choisie par la majorité des clients.
Au-dessous, nous avons quatre boutons désactivés. Il suffit de choisir un client parmi
les clients consommateurs pour pouvoir accéder à ses différents rapports.
Dans la figure suivante, nous avons sélectionné le client Anett et Cie SARL qui a 12
points de consommation, a part lui-même, d’où il envoie ses flux.
Figure 46 – Flux par client consommateur
En cliquant sur le bouton Consulter les flux du Anett et Cie SARL, le tableau de
bord spécifique à ce client est affiché. Il est présenté par la figure ci-dessous.
65
Figure 47 – Suivi Flux du client Anett et Cie SARL
Dans ce tableau de bord, nous présentons des différentes analyses. Prenons

l’exemple du client Anett et Cie SARL, avec 12 points de consommation listés au-dessous,
il est abonné au service Qweeby depuis 31 décembre 2017.
Donc, pour pouvoir suivre les flux de ce client pour l’année 2021, nous avons filtrer
la date allons du 31 décembre 2020 jusqu’au 31 décembre 2021.
Durant cette période, ce client a envoyé 12 810 flux en total à partir de ses différents
points de consommations, dont 160 flux est défectueux. Il a reçu 17 flux dont aucun flux
n’est erroné.
Figure 48 – Top 3 points de consommation
66
Dans la figure ci-dessus, nous illustrons les top 3 points de consommations de ce

client Anett et Cie SARL, qui ont réalisés les plus grands volumes de flux et qui sont :
ANETT PAYS-DE-LOIRE avec 2661 flux, ANETT BRETAGNE avec 2401 flux et ANETT
MIDI-PYRENEES avec 1650 flux.
Figure 49 – Volume émis et reçu par branche
Dans la figure 49 ci-dessus, nous présentons le volume émis et le volume reçu par
le client Anett et Cie SARL par branche. Nous remarquons que ce client utilise les branches
QWEEBYNET, CHORUS, IF_QWEEBYNET et QNETFACX pour la transmission et la
réception de ses flux. Avec QWEEBYNET la branche la plus utilisée avec 7672 flux émis
et 16 flux reçu.
Figure 50 – Dépassement par rapport au volume annuel cible
67
Certains clients consommateur ont fixé au début de leurs abonnement un volume

annuel cible de flux. De ce fait, le jauge ci-dessus sert à indiquer si un tel client a fait un
dépassement de volume de flux par rapport à son volume annuel cible ou non. S’il y a un
dépassement elle devient rouge, sinon verte.
Dans notre exemple, le client Anett et Cie SARL a fixé 12000 comme étant un
volume annuel cible, et il a consommé durant l’année 2021, 12810 flux. Donc il a fait un
dépassement de 810 flux.
Figure 51 – Flux par Type de document
La figure 51 illustre le volume des flux par type. D’où 96% des flux réalisés par
Anett et Cie SARL durant l’année 2021 sont des factures.
Figure 52 – Evolution des flux au fils du temps
68
La figure 52 montre l’évolution des flux émis, des flux reçus, des flux erronés émis
ainsi que les flux erronés reçus pendant l’année 2021 pour notre exemple.
Nous pouvons également suivre les flux de chaque point de consommation du client
choisi simplement en sélectionnant le point souhaité dans le segment de filtre et tout le
tableau de bord va être filtré en fonction de notre sélection.
IV.3.2.3.5 Tableau de bord pour autres entités
Le bouton Flux/Autres nous permet de suivre les flux réalisés par autres entités
comme les récepteurs & fournisseurs et les points de consommations.
Dans la figure suivante, nous présentons un suivi détaillé de flux pour chaque entité.
Il suffit de choisir le type d’entité souhaité et ensuite sélectionner le nom de l’entité.
Prenons l’exemple de l’entité réceptrice AMAZON France, elle a uniquement reçu

11133 flux avec un 1% anomalie.
Nous présentons également le volume des flux reçu par cette entité en fonction des
branches, par type de flux ainsi que l’évolution des flux au fil du temps.
Figure 53– Tableau de bord autres entités
IV.3.2.4 Rapport Reminders
La figure suivante illustre le tableau de bord Reminders, dans lequel nous avons
présenté une analyse concernant les rappels de paiement lancés avec la possibilité de filtrer
par type d’entité et par année. Nous avons 420 Reminders en totalité, dont 55% sont des
69
alertes, 44% sont des relances et 2% sont d’autre type de rappels. Nous avons présenté les
Reminders par statut, la majorité sont actives et les autres sont annulés. Nous pouvons
également consulter les entités et le nombre de rappels qu’elles ont reçus.
Figure 54 – Tableau de bord Reminders
IV.3.2.5 Rapport Assistance
Le tableau de bord Assistance, nous permet de suivre les tickets d’assistance reçus
par les entités de Qweeby. Prenons l’exemple présenté par la figure suivante pour l’année
actuelle 2022, nous avons :
 652 tickets reçus
 44 tickets en attente
 114 clients différents qui ont lancés des tickets, 96% d’entre eux sont des
clients consommateurs.
 Le délai moyen de la résolution d’un ticket est de 6 jours.
Nous présentons également le nombre des tickets par état, nous remarquons que 63%
des tickets sont clôturés, 29% sont nouvelles, etc.
Nous illustrons le nombre des tickets par équipe helpdesk, la majorité des tickets sont
destinés à l’équipe exploitation.
70
Et enfin, nous présentons un tableau où nous pouvons consulter tous les tickets reçus
avec le nom du l’émetteur, la date d’envoi et la durée de résolution si elle est clôturée.
Figure 55 – Tableau de bord Assistance
IV.3.2.6 Rapport Evénements
Le tableau de bord Evénements est très utile pour pouvoir suivre les évènements
organisés par l’entreprise Qweeby avec la possibilité de filtrer en fonction des statuts des
évènements et l’année. Comme présenté sur la figure ci-dessous, nous avons 53 évènements
en totalité avec 436 participants dont 23% d’entre eux sont des clients consommateurs de
Qweeby et 711 inscriptions.
L’histogramme illustre le nombre des évènements par catégorie, la majorité sont des
évènements en ligne avec 13 évènements déjà faits, 18 évènements confirmés, et 1
évènement annulé.
Le camembert présente les évènements par responsable, où nous remarquons que

87% des évènements sont organisés par Mr Eric Wanscoor.
Nous montrons également l’évolution des évènements au fils du temps par un

graphique de zone empilé.
En outre, nous affichons les top 3 évènements marquants pour Qweeby, la liste de
tous les évènements déjà terminés et la liste des évènements à venir.
71
Figure 56 – Tableau de bord Evénements
Nous pouvons également consulter tous les participants qui font partis de nos entités
et les évènements auxquels ils ont participé avec la possibilité d’utiliser des filtres divers
comme montré dans la figure suivante.
Figure 57 – Suivi événements par entité
Un autre point important, c’est qu’à partir de feuille de client consommateur, nous
pouvons consulter ses flux, ses tickets, ses évènements et les rappels qu’il a reçus. Cette
agrégation est représentée par les figures suivantes :
72
Figure 58 – Page des clients consommateurs
Prenons l’exemple du client consommateurs Champion Entreprises, qui appartient

au groupement COFAC, nous remarquons que le bouton Consulter Reminders est désactivé
et ce qui relève que ce client n’a reçu aucun rappel de Qweeby.
Nous pouvons consulter les flux de Champion Entreprises, en cliquant sur le bouton
consulter les flux.
Figure 59 – Suivi flux du client Champion Entreprises
La figure ci-dessus présente le tableau de bord de Suivi flux destiné pour le suivi des
flux de champion Entreprises.
73
Figure 60 – Suivi événements du client Champion Entreprises
La figure ci-dessus présente un Suivi des évènements pour le client champion

Entreprises.
Figure 61 – Suivi Tickets de client Champion Entreprises
La figure ci-dessus présente un Suivi des tickets lancés par le client champion
Entreprises.
74
Figure 62 – Suivi Reminders envoyés à Cherrier
La figure 62 illustre les rappels que le client Cherrier a reçu, en cliquant sur le bouton
Consulter Reminders.
IV.4 Conclusion
Ce dernier chapitre a été consacré pour la présentation de la solution réalisée. Nous
avons défini l’environnement matériel et logiciel du projet et nous avons illustré des
différentes interfaces pour les différentes phases de la mise en place pratique de notre
solution BI.
75
CONCLUSION GENERALE
Conclusion générale
Ce travail a été réalisé dans le cadre de mon projet de fin d’études. Il a pour objectif
la conception et la réalisation d’une solution BI pour le suivi des flux des factures
électroniques pour la société QWEEBY.
Notre projet a été bénéfique dans la mesure où il nous a permis d’exploiter les
données à disposition de l’entreprise et de constituer une vision complète et claire sur
l’ensemble des activités dans le but d’améliorer le processus de prise de décisions.
Tout d’abord, nous avons analyser le processus de flux de facturation existant et nous
avons dégager un certain nombre de défaillance venant essentiellement de la séparation des
données entre deux systèmes différents et non liés. Dans ce cadre, nous avons proposé une
modélisation multidimensionnelle du système de flux permettant l’agrégation des données
entre les deux bases QweebyNet et Odoo.
Puis, nous avons appliqué le processus ETL. Cette étape a été la partie la plus longue
du projet. Elle nous a permis de concevoir et de réaliser les différents jobs d’extraction,
transformation et chargement des données sous Talend Open Studio.
Enfin, nous avons mis en place nos tableaux de bord qui ont été créés avec Power BI,
permettant de naviguer et d’exploiter les données de l’entrepôt.
Ce stage nous a permis d’acquérir une expérience professionnelle dans le domaine
de l’informatique décisionnelle., A titre de perspectives, nous pouvons fouiller encore dans
les APIs de connexion de Odoo afin d’offrir aux décideurs des tableaux de bord en temps
réelle.
76
Bibliographie
[Bib1] Alain Fernandez, « L’essentiel du tableau de bord », Quatrième Edition, Eyrolles,

2005 255 p.
77
Netographie
[1] https://www.ama-business.com/business-intelligence-bi-tableau-de-bord-repoting-
tunisie/
[2] https://fr.slideshare.net/AzizDarouichi/partie1bidw2019
[3] https://fr.slideshare.net/blamal1/business-intelligence-au-coeur-de-la-dcision-
56297377
[4] https://perso.univ-lyon1.fr/haytham.elghazel/BI/presentation.html
[5] https://www.ediservices.com/fr/qu-est-ce-que-etl/
[6] https://www.piloter.org/business-intelligence/datawarehouse.htm
[7] https://www.lebigdata.fr/data-warehouse-entrepot-donnees-definition
[8] MTI820-Acetates-ModelisationDimensionnelle (etsmtl.ca)
[9] https://decizia.com/blog/2010/04/17/quest-ce-quune-table-de-faits/
[10] https://decizia.com/blog/2010/04/17/quest-ce-quune-dimension/
[11] https://waytolearnx.com/2018/08/difference-entre-table-des-faits-et-table-de-
dimension.html
[12] https://fr.myservername.com/schema-types-data-warehouse-modeling-star-
snowflake-schema
[13] https://jafwin.com/2019/02/14/difference-entre-le-modele-en-etoile-et-flocon-de-
neige-pour-la-conception-dun-entrepot-de-donnees/
[14] https://www.memoireonline.com/03/20/11676/m_Conception-d-un-datamart-
pour-le-pilotage-du-systeme-de-gestion-des-impts-Cas-de-la-direction-g21.html
[15] https://www.cadremploi.fr/editorial/conseils/conseils-
carriere/detail/article/reporting-definition-et-interet.html
[16] https://infonet.fr/lexique/definitions/reporting/
[17] https://www.bercynumerique.finances.gouv.fr/l-information-en-continu/quest-ce-
que-le-data-mining
78
[18] https://www.lebigdata.fr/olap-online-analytical-processing
[19] https://pragmatic-system.ma/blog/notre-blog-1/post/c-est-quoi-odoo-2
[20] http://www.encyclopedie.fr/definition/WampServer
[21] https://www.lemondeinformatique.fr/actualites/lire-jvm-jdk-jre-quelle-difference-
74633.html
[22] https://www.axopen.com/blog/2016/11/talend-etl-definition
[23] https://www.codage.biz/en/blog/our-blog-1/post/power-bi-la-solution-business-
intelligence-cloud-de-microsoft-31
[24] https://docs.plesk.com/fr-FR/obsidian/customer-guide/d%C3%A9marrer-
rapidement-avec-plesk/pr%C3%A9sentation-de-l%E2%80%99interface-de-
plesk.74282/
[25] https://windows.developpez.com/tutoriels/filezilla/
[26]https://help.talend.com/r/AsV4_TX51DXfRElBkPQ4Qw/Hiz8lHujc6qGJDLT0ORyT
A
79
Conception et mise en place d’une solution décisionnelle pour le suivi des flux des factures
électroniques et des clients pour la société QWEEBY
Mémoire de Master FSEG, Nabeul 2022
_________________________________________________________________
RESUME
Ce travail s’inscrit dans le cadre du mémoire de master à la Faculté des Sciences Economiques
et de Gestion de Nabeul (FSEGN). Le stage a eu lieu dans l’entreprise Qweeby, ayant comme
objectif la conception et la mise en place d’une solution décisionnelle pour le suivi des flux
des factures électroniques et des clients. Notre solution consiste à construire un entrepôt de
données en collectant les informations pertinentes et utiles de différentes sources afin d’élaborer
des tableaux de bord et des rapports facilitant la prise de décision.
Mots clés : Informatique décisionnelle, Entrepôt de données, Magasin de données, Modélisation

multidimensionnelle, ETL, Talend, Tableaux de bord, Power Bi
_________________________________________________________________
SUMMARY
This work is part of the master's thesis at the Faculty of Economics and Management of
Nabeul (FSEGN). The internship took place in the company Qweeby, It aims to design and
implement a BI solution for monitoring the flow of electronic invoices and customers. Our
solution consists of building a datawarehouse by collecting relevant and useful information
from different sources in order to develop dashboards and reports that facilitate decision-
making.
Key words: Business Intelligence, Datawarehouse, datamart, Multidimensional modeling, ETL,

Talend, Dashboards, Power Bi.
80

DEA1833

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

DEA1833

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Master professionnel Ingénierie des Systèmes d’Information et des

Encadrante universitaire Encadrant(s) professionnel(s)

A mes chers amis

A tous ceux qui comptent pour moi

A tous ceux pour qui je compte

Avec beaucoup de plaisir, je voudrais avant tout adresser mon

gratitude et ma profonde reconnaissance à tous ceux qui, de près ou

de loin, ont contribué à l’élaboration de ce travail.

Je tenais à exprimer mes vifs remerciements à M. Eric Wanscoor le

président de la société française Qweeby pour son accueil

chaleureux au sein de l’entreprise, la confiance qu’il m’accordé tout

au long de mon stage ainsi que pour sa disponibilité et sa

Je remercie également Mme Zouhour Ben Salem, enseignante à la

Faculté des Sciences Economiques et de Gestion, pour avoir bien

voulu encadrer ce travail, pour ses précieux conseils, son soutien, sa

disponibilité et ses propositions d’amélioration.

Mes sincères gratitudes à l’équipe de Qweeby, notamment MM.

Aymen Ben Abdallah, et Nadhir Chamkhi qui m’ont fait part de

leur temps et de leur énergie pour aider à élaborer ce travail.

Par la même occasion, j’exprime mes sincères reconnaissances à

l’égard de tous ceux qui ont contribué à notre formation,

particulièrement les enseignants de la Faculté des Sciences

Economiques et de Gestion de Nabeul.

Finalement, je tenais aussi à remercier vivement les membres du

jury qui m’ont fait l’honneur de bien vouloir évaluer ce travail.

Figure 1 – Le modèle DIKW.............................................................................................................. 4

Tableau 1 – Comparaison entre la table de faits et la table de dimension....................................... 12

API Application Programming Interface

De nos jours, les entreprises évoluent dans un environnement concurrentiel de plus

Dans ce contexte, la compétitivité de Qweeby dépend aujourd'hui plus que jamais de

Le présent rapport est structuré autour de quatre chapitres :

Le premier chapitre intitulé « L’informatique décisionnelle » traite les aspects

Dans le deuxième chapitre, intitulé « Cadre général du projet », nous

Le troisième chapitre intitulé « Modélisation multidimensionnelle » sera consacré

Le quatrième chapitre intitulé « Réalisation » détaille les différentes étapes de notre

Chapitre I. L’informatique décisionnelle

Le Business Intelligence repose sur le modèle Data, Information, Knowledge,

Figure 1 – Le modèle DIKW

I.3 Objectifs et enjeux du décisionnel

• Connaître les objectifs;

• Mesurer les données;

• Agir afin d’aligner l’information aux objectifs.

Les moyens pour y parvenir sont :

• Une information riche, pertinente, détaillée, historisée, fiable;

• Des outils d’analyse et de restitution puissants et adaptés;

• Des indicateurs qui favorisent le pilotage et favorisent l’action.

Le cycle du projet comprend plusieurs étapes :

• Sélectionner les axes de progrès.

• Sélectionner le ou les processus à analyse.

• Définir les objectifs.

• Définir les indicateurs.

• Bâtir le portail décisionnel.

I.4 Les étapes d’un processus BI

Figure 2 – Processus global de traitement des données d’un système décisionnel

I.4.1 La phase de collecte :

I.4.2 La phase d’intégration :

I.4.3 La phase d’organisation :

I.4.4 La phase de restitution

Les outils de reporting et de requêtes permettent la mise à disposition de rapports

Figure 3 – Processus détaillé de traitement des données d’un système décisionnel

I.5 Les concepts de base de la Business Intelligence

Un ETL est un ensemble d’outils et de méthodes qui combinent trois fonctions :

I.5.1.2 Fonctionnement d’un ETL