PFEBI

Mémoire de fin d’études
En vue d’obtention du
Diplôme de Master professionnel en
Ingénierie des Systèmes d’Information des Entreprises
Mise en place d’un tableau de bord pour la gestion des
ressources humaines
Encadrants :
Réalisé par :
Mr. Jelassi Nidhal
Ben Mamya Rihab
Mme. Chagra Sonia
Année universitaire 2017/2018

DÉDICACE
Je dédie ce modeste travail à :
A mon cher père Adel, aucune dédicace ne saurait exprimer l’amour,
l’estime, le dévouement et le respect que j’ai toujours eu pour vous.Ce travail
est le fruit de tes encouragement et sacrifices pour assurer mon éducation
dans les meilleurs condition.
A ma chère mére Olfa, ma raison d’être,la source de tendresse et
l’exemple du dévouement qui n’a pas cessé de m’encourager et de prier
pour moi, qui a tant donné, pour qu’on puisse grandir et réussir.Je te dédie
ce travail en témoignage de mon profond amour.
i
A mon cher frère Firas, mon ange gardien et mon fidèle compagnant
dans les moments les plus délicats de cette vie. Je vous dédie ce travail avec
tous mes vœux de bonheur, de santé et de réussite.
A ma très chères soeurs Rihem & Ranim, en témoignage de l’at-
tachement, de l’amour et de l’affection que je porte pour vous. Je vous dédie
ce travail avec tous mes vœux de bonheur, de santé et de réussite.
A tous mes chères ami(e)s , en témoignage de l’amitié qui nous
uni et des souvenirs de tous les moments que nous avons passé ensemble,
je vous dédie ce travail et je vous souhaite une vie pleine de santé et de
bonheur.
A tous ceux qui mes sont chers et toujours dans mes pensées.
Rihab
ii
REMERCIEMENTS
Ce projet de fin d’étude marque une étape importante dans notre vie. Il
correspond à un point de vue sur la vie active.
Nous voudrions remercier toutes les personnes qui nous ont accompagnés
tout au long de notre formation : Nous tenons à adresser nos sincères re-
merciements :
A Monsieur Jelassi Nidhal, notre encadrante à la faculté des sciences
économique et de gestion de Tunis et Madame Chagra Sonia notre en-
cadrant à l’AFH pour avoir bien voulu nous encadrer, pour tout le temps
qu’ils nous ont octroyés et pour tous les conseils qu’ils nous ont prodigués.Ils
nous ont toujours réservé le meilleur accueil, malgré leur obligations profes-
iii
sionnelles. Leur encouragements inlassables, amabilité, gentillesse méritent
toute admiration. Qu’ils trouvent ici l’expression de notre profonde grati-
tude.
A tous les membres du jury.
A tous ceux qui, directement ou indirectement, ont aidé à la finalisation de
ce travail. Nous saisissons cette occasion pour vous exprimer notre profonde
gratitude tout en vous témoignant notre respect.

TABLE DES MATIÈRES
Dédicace i
Remerciements ii
Introduction 1
1 Cadre général du projet 4

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Présentation de l’organisme d’accueil . . . . . . . . . . . . . 5
1.3.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Objectif de l’organisme . . . . . . . . . . . . . . . . . 6
1.3.3 Organisation . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . 10
1.7 Planification du projet . . . . . . . . . . . . . . . . . . . . . 16
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 Spécication et analyse des besoins 17

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1 Présentation de l’existant . . . . . . . . . . . . . . . 18
2.2.2 Critique de l’existant . . . . . . . . . . . . . . . . . . 18
i
2.3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . 19

2.3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . 19
2.3.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . 21
2.4 Modélisation dynamique . . . . . . . . . . . . . . . . . . . . 22
2.4.1 Diagramme de cas d’utilisation global . . . . . . . . . 22
2.4.2 Identification des acteurs : . . . . . . . . . . . . . . . 24
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 État de l’art 26
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Informatique décisionnelles . . . . . . . . . . . . . . . . . . 27
3.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.2 Architecture de l’Informatique décisionnelles . . . . 28
3.2.3 ETL « Extraction-Transformation-Chargement » . . 29
3.3 Entrepôt de données « Data warehouse » . . . . . . . . . . 32
3.3.1 Caractéristique d’un entrepôt de données . . . . . . . 32
3.3.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.3 Magasin de données « DataMarts » . . . . . . . . . . 35
3.3.4 Modélisation multidimensionnelle . . . . . . . . . . . 38
3.3.5 Type de modèle dimensionnel . . . . . . . . . . . . . 41
3.4 Restitution des données . . . . . . . . . . . . . . . . . . . . 44
3.4.1 Le reporting . . . . . . . . . . . . . . . . . . . . . . 45
3.4.2 Tableau de bord (Dashboard) . . . . . . . . . . . . . 46
3.4.3 Fouille de données (Datamining) . . . . . . . . . . . 46
3.4.4 On-Line Analytical Processing OLAP . . . . . . . . 47
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4 Conception 54
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2 Étude détaillée des cas d’utilisation . . . . . . . . . . . . . . 55
4.2.1 Raffinement du cas d’utilisation « Gérer ETL » . . . 55
4.2.2 Raffinement du cas d’utilisation «Créer transforma-
tions» . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.3 Raffinement du cas d’utilisation « Analyser les don-
nées » . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.4 Raffinement du cas d’utilisation « Créer Cube » . . 59
ii
4.2.5 Raffinement du cas d’utilisation « Gérer rapports » 60

4.3 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . 61
4.4 Conception de l’entrepôt de données . . . . . . . . . . . . . 62
4.4.1 Les dimensions . . . . . . . . . . . . . . . . . . . . . 63
4.4.2 Les dimensions communes . . . . . . . . . . . . . . . 78
4.4.3 Sujet d’analyse : Gérer effectifs . . . . . . . . . . . . 80
4.4.4 Sujet d’analyse : Gérer Absentéisme . . . . . . . . . 82
4.4.5 Sujet d’analyse : Gérer Retard . . . . . . . . . . . . 84
4.4.6 Sujet d’analyse : Gérer Salaire . . . . . . . . . . . . 86
4.4.7 Sujet d’analyse : Gérer Sanction . . . . . . . . . . . 88
4.4.8 Sujet d’analyse : Gérer Crédit . . . . . . . . . . . . . 90
4.4.9 Sujet d’analyse : Gérer Assurance . . . . . . . . . . 92
4.5 Conception ETL . . . . . . . . . . . . . . . . . . . . . . . . 94
4.5.1 Étude et planification . . . . . . . . . . . . . . . . . . 94
4.5.2 Processus ETL . . . . . . . . . . . . . . . . . . . . . 97
4.6 Conception de la restitution . . . . . . . . . . . . . . . . . . 98
4.6.1 Conception des cubes OLAP . . . . . . . . . . . . . 98
4.6.2 Conception des tableaux de bord . . . . . . . . . . . 99
4.7 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . 100
4.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5 Présentation des outils utilisées Et Réalisation 103

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . 104
5.2.1 Environnement matériel . . . . . . . . . . . . . . . . 104
5.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . 104
5.3 Architecture globale d’application . . . . . . . . . . . . . . . 110
5.4 Réalisation du processus ETL . . . . . . . . . . . . . . . . . 111
5.4.1 Composants kettle utilisés . . . . . . . . . . . . . . . 112
5.4.2 Connexions aux bases de données source . . . . . . . 115
5.4.3 Alimentation de l’entrepôt de données . . . . . . . . 115
5.5 Réalisation de la restitution . . . . . . . . . . . . . . . . . . 122
5.5.1 Réalisation du cube OLAP . . . . . . . . . . . . . . . 122
5.5.2 Réalisation des Rapports . . . . . . . . . . . . . . . . 127
5.6 Interfaces de l’application . . . . . . . . . . . . . . . . . . . 129
5.6.1 Interface « Authentification » . . . . . . . . . . . . . 130
iii
5.6.2 Interface « Suivi de personnel » . . . . . . . . . . . . 131

5.6.3 Interface « Suivi d’absence » . . . . . . . . . . . . . 132
5.6.4 Interface « Suivi de retard » . . . . . . . . . . . . . . 133
5.6.5 Interface « Suivi de sanction » . . . . . . . . . . . . 134
5.6.6 Interface « Suivi de paie » . . . . . . . . . . . . . . . 136
5.6.7 Interface « Suivi de crédit » . . . . . . . . . . . . . . 137
5.6.8 Interface « Suivi d’assurance » . . . . . . . . . . . . 139
5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Conclusion 140
Netographie 143
iv
TABLE DES FIGURES
1.1 Organigramme de l’AFH . . . . . . . . . . . . . . . . . . . 8

1.2 Organigramme de l’AFH . . . . . . . . . . . . . . . . . . . 14
1.3 Organigramme de Gantt . . . . . . . . . . . . . . . . . . . . 16
2.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . 23
3.1 Architecture générale d’un système décisionnel . . . . . . . . 28
3.2 Schéma de fonctionnement d’un ETL . . . . . . . . . . . . . 30
3.3 Structure de base d’une table Fait . . . . . . . . . . . . . . . 39
3.4 Structure de base d’une table Dimension . . . . . . . . . . . 40
3.5 Structure d’un modèle en étoile . . . . . . . . . . . . . . . . 42
3.6 Structure d’un modèle en flocon . . . . . . . . . . . . . . . . 43
3.7 Exemple d’opération sur un cube OLAP . . . . . . . . . . . 52
4.1 Raffinement de cas d’utilisation ” Gérer ETL” . . . . . . . . 56
4.2 Raffinement de cas d’utilisation ” créer transformation ” . . . 57
4.3 Raffinement des cas d’utilisation ” Analyser les données ” . . 58
4.4 Raffinement de cas d’utilisation ” Créer cube ” . . . . . . . . 59
4.5 Raffinement de cas d’utilisation ” Gérer rapports ” . . . . . . 60
4.6 Diagramme de séquence ” Authentification ” . . . . . . . . . 61
4.7 Modèle en étoile ” Fait-personnel ” . . . . . . . . . . . . . . 81
4.8 Modèle en étoile ” Fait-Absence ” . . . . . . . . . . . . . . . 83
4.9 Modèle en étoile ” Fait-Retard ” . . . . . . . . . . . . . . . . 85
4.10 Modèle en étoile ” Fait-Paie ” . . . . . . . . . . . . . . . . . 87
v
TABLE DES FIGURES
4.11 Modèle en étoile ” Fait-Sanction ” . . . . . . . . . . . . . . . 89

4.12 Modèle en étoile ” Fait-Crédit ” . . . . . . . . . . . . . . . . 91
4.13 Modèle en étoile ” Fait-Assurance ” . . . . . . . . . . . . . . 93
4.14 Base de données source . . . . . . . . . . . . . . . . . . . . . 96
4.15 Modélisation des cubes dimensionnels . . . . . . . . . . . . . 99
4.16 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . 101
5.1 Logo Oracle 10g . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.2 Logo de PDI . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.3 Logo de PUC . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.4 Logo Pentaho design reporting . . . . . . . . . . . . . . . . 107
5.5 Logo Laravel . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.6 Architecture globale de la chaı̂ne décisionnelle . . . . . . . . 111
5.7 connexions aux BD . . . . . . . . . . . . . . . . . . . . . . 115
5.8 ETL dimension date . . . . . . . . . . . . . . . . . . . . . . 116
5.9 Exemple d’alimentation des dimensions . . . . . . . . . . . . 117
5.10 Alimentation du Fait Personnel . . . . . . . . . . . . . . . . 118
5.11 Alimentation du Fait Absence . . . . . . . . . . . . . . . . . 119
5.12 Alimentation du Fait Retard . . . . . . . . . . . . . . . . . . 119
5.13 Alimentation du Fait Paie . . . . . . . . . . . . . . . . . . . 120
5.14 Alimentation du Fait Sanction . . . . . . . . . . . . . . . . . 120
5.15 Alimentation du Fait Crédit . . . . . . . . . . . . . . . . . . 121
5.16 Alimentation du Fait Assurance . . . . . . . . . . . . . . . . 121
5.17 Créer cube ”Fait personnel” . . . . . . . . . . . . . . . . . . 123
5.18 Mise en page du tableau de bord ’Suivi personnel’ . . . . . 125
5.19 Personnaliser de la source de donnée du tableau de bord
’Suivi personnel’ . . . . . . . . . . . . . . . . . . . . . . . . 125
5.20 Personnaliser des composants graphiques du tableau de bord
’Suivi personnel’ . . . . . . . . . . . . . . . . . . . . . . . . 126
5.21 Exemple de la requête MDX . . . . . . . . . . . . . . . . . 126
5.22 Aperçu du tableau de bord ’Suivi personnel’ . . . . . . . . . 127
5.23 Exemple de mise en forme de ”reporting Assurance” . . . . . 128
5.24 Exemple de ”reporting Assurance” . . . . . . . . . . . . . . . 129
5.25 Interface « Authentification » . . . . . . . . . . . . . . . . . 130
5.26 Interface « Suivi de personnel » . . . . . . . . . . . . . . . . 131
5.27 Interface « Suivi d’absence » . . . . . . . . . . . . . . . . . 132
vi
TABLE DES FIGURES
5.28 Interface « Suivi de retard » . . . . . . . . . . . . . . . . . . 133

5.29 Interface « Suivi de sanction » . . . . . . . . . . . . . . . . . 134
5.30 Interface « Report de Suivi de sanction » . . . . . . . . . . . 135
5.31 Interface « Suivi de paie » . . . . . . . . . . . . . . . . . . . 136
5.32 Interface « Suivi de crédit » . . . . . . . . . . . . . . . . . . 137
5.33 Interface « Report de Suivi de crédit » . . . . . . . . . . . . 138
5.34 Interface « Suivi d’assurance » . . . . . . . . . . . . . . . . 139
5.35 Interface « Report de Suivi d’assurance » . . . . . . . . . . 140
vii
LISTE DES TABLEAUX
1.1 Tableau de synthèse des méthodologies [2] . . . . . . . . . . 13

3.1 Tableau comparatif entre datawarehouse et datamart . . . . 36
3.2 Tableau Comparatif entre les bases de données de l’entreprise 37
3.3 Tableau comparatif entre OLTP et OLAP . . . . . . . . . . 49
3.4 Tableau comparatif des serveurs OLAP . . . . . . . . . . . . 51
4.1 Définition des dimensions . . . . . . . . . . . . . . . . . . . 66
4.2 Description des colonnes de la dimension ” date ” . . . . . . 68
4.3 Description des colonnes de la dimension ” Age ” . . . . . . 68
4.4 Description des colonnes de la dimension ” Ancienneté ” . . . 69
4.5 Description des colonnes de la dimension ” Sexe ” . . . . . . 69
4.6 Description des colonnes de la dimension ” Sexe ” . . . . . . 70
4.7 Description des colonnes de la dimension ” Affectation géo-
graphique ” . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.8 Description des colonnes de la dimension ” UFA ” . . . . . . 71
4.9 Description des colonnes de la dimension ” UFG ” . . . . . . 71
4.10 Description des colonnes de la dimension ” Collége ” . . . . . 72
4.11 Description des colonnes de la dimension ” Fonction ” . . . . 72
4.12 Description des colonnes de la dimension ” Filiére ” . . . . . 73
4.13 Description des colonnes de la dimension ” Diplôme ” . . . . 73
4.14 Description des colonnes de la dimension ” Niveau d’étude ” 74
4.15 Description des colonnes de la dimension ” Qualification ” . . 74
4.16 Description des colonnes de la dimension ” Position ” . . . . 75
viii
LISTE DES TABLEAUX
4.17 Description des colonnes de la dimension ” Position ” . . . . 75

4.18 Description des colonnes de la dimension ” type absence ” . . 76
4.19 Description des colonnes de la dimension ” type crédit ” . . . 76
4.20 Description des colonnes de la dimension ” indemnité ” . . . 77
4.21 Description des colonnes de la dimension ” type sanction ” . 77
4.22 Description des colonnes de la dimension ” mois ” . . . . . . 78
4.23 Description des colonnes de la dimension ” type assurance ” . 78
4.24 Détection des dimensions communes . . . . . . . . . . . . . 80
4.25 Description des mesures de la table fait personnel . . . . . . 80
4.26 Description des mesures de la table fait absence . . . . . . . 82
4.27 Description des mesures de la table fait retard . . . . . . . . 84
4.28 Description des mesures de la table fait paie . . . . . . . . . 86
4.29 Description des mesures de la table fait Sanction . . . . . . . 88
4.30 Description des mesures de la table fait Crédit . . . . . . . . 90
4.31 Description des mesures de la table fait Assurance . . . . . . 92
ix
INTRODUCTION
Face à la mondialisation, la progression des systèmes et des technolo-
gies d’information, les entreprises et plus globalement les organisations, se
trouvent confrontées à des environnements de plus en plus complexes et
compétitifs dans lesquels le pilotage et la prise de décision impliquent des
choix qui doivent être faits dans des temps très courts tout en prenant
en compte un volume d’information toujours plus important, la prise de
décision dans les entreprises devient donc une préoccupation de première
importance.
De ce fait, la direction de ressources humaines de l’Agence foncière d’ha-
bitation(AFH) a besoin de certaines améliorations pour la bonne gestion
de ressources humaines. La problématique observée dans des diérents diag-
1
nostics est que les dirigeants rencontrent des problèmes de blocage ou de
dysfonctionnement au niveau des départements sous leurs responsabilités
à cause de fausse génération de quelques statistiques. Ajoutons à ceci, la
grande quantité de données traitée régulièrement dans l’entreprise est dicile
d’être utilisée par les décideurs seuls.
Comme l’ensemble de données manipulées par les outils sont très abon-
dantes et éparpillées dans diérents systèmes hétérogènes et non ordonnées
dans un aspect décisionnel adéquat pour les statistiques, il est donc né-
cessaire de fusionner les données et de les arranger dans un entrepôt de
données dans le but de les rendre convenables pour l’analyse et la création
des rapports qui peuvent servir à la prise de décision.
C’est dans ce contexte que s’insère notre projet de n d’études intitulé «
Mise en place d’un tableau de bord pour la gestion des ressources humaines
» consiste à concevoir et développer une solution décisionnelle pour le dé-
partement ressource humaine de l’AFH. Cette solution permet d’importer
des données, de développer des cubes OLAP pour admettre une analyse
2
multidimensionnelle et de créer un portail de reporting.
Ce présent rapport comporte les cinq chapitres suivants :
— Le premier chapitre présente le cadre général du projet en citant les
grandes lignes du travail demandé et le processus de développement
que nous avons adoptés tout au long de la réalisation.
— Le deuxième chapitre est consacré à l’étude de l’existant, la spéciDe-
clareUnicodeCharacterfication et l’analyse des besoins.
— Le troisième vise à présenter et à déDeclareUnicodeCharacterfinir les
différents concepts des technologies décisionnelles servant de support
à nos travaux.
— Le quatrième chapitre est destiné à la conception détaillée de notre
entrepôt de données.
— Le cinquième chapitre présente l’environnement de travail et les dié-
rentes tâches réalisées.
Nous clôturons ce rapport par une conclusion générale qui rappellera le
contexte de notre travail élaboré ainsi que l’approche proposée et de citer
les perspectives du projet.
3
CHAPITRE 1
CADRE GÉNÉRAL DU PROJET
1.1 Introduction
Dans ce chapitre, nous allons présenter le cadre général de noter projet
de fin d’étude, qui s’est déroulé au sein de l’Agence Foncière d’Habitation
« AFH ». Dans un premier temps, nous présentons l’organisme d’accueil
de l’AFH suivie par le contexte, les objectifs et la planification de notre
projet, finalement une étude du système d’information de l’environnement
dans lequel s’inscrit notre projet.
4
1.2 Contexte du projet
Ce projet se situe dans le cadre de la préparation du Projet de Fin
d’Etudes (PFE) au sein de la faculté des sciences économiques et de gestion
de Tunis El-Manar (FSEGT). Il consiste à concevoir et mettre en place un
système d’information décisionnel qui met en pratique les connaissances
acquises durant notre formation tout en apprenant à s’intégrer dans la vie
professionnelle, de faire face aux diérentes situations et problématiques tout
en inspirant les solutions les plus adéquates. Le secteur de notre projet est
la direction des ressources humaines de de l’Agence Foncière d’Habitation
« AFH ».
1.3 Présentation de l’organisme d’accueil
1.3.1 Historique
L’Agence Foncière d’Habitation « AFH » est une entreprise publique,
dotée de la personnalité civile et de l’autonomie financière.
Elle est chargée de produire des lotissements aménagés et de contribuer à
la création d’un environnement urbain sain et harmonieux. Elle participe
5
aussi, par son approche globale, à la création de villes modernes, adaptées
aux mutations culturelles et économiques vécues en Tunisie et à travers le
monde [1]
Par son engagement, l’A.F.H a réussi à :
— Mettre en œuvre les orientations nationales en matière d’habitat et
d’urbanisme.
— Créer les conditions les plus favorables pour améliorer l’état du secteur
du logement et favoriser l’essor des activités économiques qui lui sont
directement ou indirectement attachées.
1.3.2 Objectif de l’organisme
En créant l’A.F.H. par la Loi n 73-21 du 14 avril 1973, les pouvoirs pu-
blics entendaient mettre en œuvre une nouvelle politique d’urbanisme et
d’aménagement du territoire tournée vers l’avenir.
D’une manière concrète, l’Agence vise à réussir les missions suivantes :
— Fournir aux secteurs de l’habitat et de l’urbanisme les terrains aména-
6
gés dont ils ont besoin pour faire face à la demande publique et privée,
en veillant particulièrement à la réduction des coûts de production.
— Assurer un environnement urbain de qualité qui répond au souci des
pouvoirs publics de moderniser les villes tunisiennes et de les adap-
ter aux mutations économiques, culturelles et sociales que connaı̂t le
monde actuellement.
— Favoriser l’accès au logement à toutes les catégories de la population
et particulièrement aux ménages à faibles et moyens revenus.
— Soutenir l’effort des municipalités dans la réalisation de leurs projets
urbains en mettant en place les infrastructures primaires et secon-
daires nécessaires.
— Participer à l’effort national de maintien des populations dans leur
zone d’origine par la réalisation de projets décentralisés au moindre
coût.
— Compléter l’action publique de lutte contre l’habitat anarchique en
mettant en œuvre des programmes de relogement appropriés.
7
1.3.3 Organisation
L’organigramme suivant donne une vision de la structure de l’entreprise
et de son administration :
Figure 1.1 – Organigramme de l’AFH
8
1.4 Problématique
Ces dernières années étaient marquées par la croissance du nombre du
personnel et surtout des informations prises en charges qui les concernent.
C’est la raison pour laquelle les dirigeants des ressources humaines sont
devenus incapables de suivre le rythme quotidien et accélérer du travail.
Pour résoudre ce problème, l’AFH voit nécessaire de la modernisation de
son système d’information.
En fait, l’agence doit être capable de transformer et de collecter ses don-
nées éparpillées dans les différents systèmes opérationnels, en informations
susceptibles de fournir une idée claire aux gestionnaires sur la performance
des ressources humaines. Ces informations bien structurées facilitent la prise
des décisions adéquates pour corriger les faiblesses constatées.
1.5 Motivations
Ce projet a pour but la mise en place d’un système d’information d’aide
à la décision qui permet de pallier les insuffisances dues à l’exploitation
des bases de données opérationnelle an d’avoir une vue globale sur la per-
9
formance des ressources humaines de l’entreprise et de permettre aux déci-
deurs de prendre de bonnes décisions aux bons moments. Pour cette raison,
l’entreprise doit disposer d’un entrepôt de données qui centralise les infor-
mations de qualité et des outils des restitutions pour présenter les données
d’une façon able et cohérente an de minimiser le coût d’élaboration de rap-
port en termes de temps et d’argent.
1.6 Méthodologie adoptée
Une méthodologie de développement est un cadre utilisé pour structurer,
planifier et contrôler le développement d’une application.
Parmi ces méthodologies :
— Méthodologie lourde / Le processus unifié (UP) :
— RUP : Rational Unified Process
— 2TUP : Two Truck Unified Process
— Méthodologie agile
— XP : eXtreme Programming
— SCrum
10
Nous présentons dans le tableau suivant une comparaison entre les diffé-
rentes méthodes existantes, les points forts et les points faibles de chacune.
Méthodologie Description Points forts Points faibles
Cascade -Propose de dérou- -Distingue claire- -Non itératif.
ler les phases de ment les phases du -Pas de modèles
projet d’une ma- projet. pour les docu-
nière séquentielle. ments.
RUP -Le RUP est à la -Itératif. -Vision non évi-
(Rational fois une méthodolo- -Propose des mo- dente ni immé-
Unified gie et un outil prêt dèles de docu- diate.
Process) à l’emploi. ments, et des -Très axé processus
-Cible des projets canevas pour des -Coûteux à person-
de plus de 10 per- projets types. naliser.
sonnes. -une évolution -Assez flou dans sa
n’impacte qu’une mise en œuvre.
itération et non
forcément tout le
logiciel.
11
2TUP -Propose un cycle -Itératif. -Ne propose pas
(Two Truck de développement -Définit les profils des documents
Unified en Y des intervenants, types.
Process) -Cible des projets les plannings, les -Plutôt superficiel
de toutes tailles. prototypes. sur les phases si-
-S’articule autour -Consacre une tuées en amont
de l’architecture. large place à la et en aval du
technologie et à la développement.
gestion des risques.
Scrum -Se base sur des -Donne toute -La mise en oeuvre
itérations dites spi- confiance aux dé- du développement
rales de développe- veloppeurs et les n’est pas précisée.
ment. laisser faire leur -Le développement
travail. rapide et répétitif
-Chaque itération se traduit par une
a un objectif bien forte pression.
précis et fournit
une fonctionnalité
testée.
12
XP -Ensemble de « -Itératif. -Assez flou dans sa
(eXtreme bests practices» de -Donne une impor- mise en œuvre.
Programming) développement. tance aux aspects
-Cible des projets techniques.
de moins de 10
personnes.
Table 1.1 – Tableau de synthèse des méthodologies [2]
Le processus de développement utilisé dans notre travail est le proces-
sus 2TUP. En effet, 2TUP donne une grande importance à la technologie
technique, ce qui est important pour notre projet.
13
Figure 1.2 – Organigramme de l’AFH
La méthodologie 2TUP (Two Truck Unified Process) est composée es-
sentiellement de trois étapes :
— La branche fonctionnelle : capitalise la connaissance du métier de
l’entreprise.
Cette branche comporte les étapes suivantes :
— La capture des besoins fonctionnels. Cette étape élimine le risque
14
d’avoir un système inadapté aux besoins des utilisateurs.
— La capture des besoins non fonctionnels.
— L’analyse qui consiste à étudier les besoins fonctionnels de manière
à obtenir une idée de ce que va réaliser le système en terme métier.
— La branche technique : capitalise un savoir-faire technique et/ou
des contraintes techniques.
— La capture des besoins techniques.
— La conception générique.
— La branche réalisation : consiste à réunir les deux branches, per-
mettant de mener une conception applicative et enfin la livraison
d’une solution adaptée aux besoins.
— La conception préliminaire
— La conception détaillée
— Le codage
— L’intégration
15
1.7 Planification du projet
Afin de mieux organiser notre projet, nous avons présenté sous forme
de diagramme de Gantt l’ensemble des tâches ainsi leurs durées, tout en
respectant la méthode adoptée pour la réalisation du projet.
Figure 1.3 – Organigramme de Gantt
1.8 Conclusion
A travers ce premier chapitre, nous avons présenté le cadre général du
projet, par la suite nous avons introduit la problématique, et les objectifs
à atteindre et nous terminons par présenter le processus de développement
adapté pour la réalisation de notre projet. Dans le chapitre suivant, nous
passons à l’étude et l’analyse des besoins.
16
CHAPITRE 2
SPÉCICATION ET ANALYSE DES BESOINS
2.1 Introduction
Un système décisionnel est un projet qui demande une étude bien spé-
ciée sur les besoins de l’entreprise. Au niveau de ce chapitre, nous allons
présenter notre étude et critique de l’existant puis nous allons spécier les
besoins fonctionnels, non fonctionnels et les diagrammes nécessaires pour
l’analyse.
17
2.2 Etude de l’existant
L’étude de l’existant consiste à comprendre et à analyser la situation
actuelle de l’entreprise afin des dégager ses insuffisances.
2.2.1 Présentation de l’existant
Afin de bien comprendre les besoins fonctionnels de notre application, on
a besoin de l’exploration des tables de la base de données GRH existante.
Dans l’AFH, l’ensemble des données liées à la gestion des métiers sont
stockées dans une base de données relationnelle qui permet la collecte et
l’exploitation de ces données.
2.2.2 Critique de l’existant
Il est important de mentionner que l’AFH ne dispose d’aucun système
d’aide à la décision automatique ou semi-automatique. En plus, tout pro-
cessus d’analyse et de prise de décision est basé nécessairement sur des
rapports créés manuellement dans des chiers Excel dont les données sont
extraites de façon manuelle, c’est pourquoi la prise de décision exige une
durée très longue dans la collecte des informations et leur sélection à chaque
18
prise de décision.
Un autre problème se présente lors de la phase d’analyse est la complexité
les requêtes utilisées qui contiennent plusieurs jointures et fonctions d’agré-
gations, donc l’exécution dans un système transactionnel peut engendrer
un temps considérable dans le serveur de données.
2.3 Spécification des besoins
Pour bien répondre aux exigences des utilisateurs, le système devra pou-
voir assurer les besoins fonctionnels et non fonctionnels de notre application.
2.3.1 Besoins fonctionnels
Les besoins fonctionnels de notre projet consistent à mettre en place
un système d’information décisionnel permettant d’analyser la gestion res-
sources humaines. En d’autres termes les principaux besoins sont les sui-
vant :
— Analyse des données
— Gestion d’un entrepôt de données uniforme :
— Extraction des données : Les données vont alimenter notre DA-
19
TAWERHOUSE sont d’origine diverses. En effet, les données pro-
viennent à partir de bases de données différentes.
— Transformation des données extraites.
— Chargement des informations dans un entrepôt des données qui se
lance périodiquement.
— Gestion des utilisateurs
— Génération d’un tableau de bord qui permet de visualiser :
— Avoir la répartition de personnels selon des critères différents (par
affectation géographique, par fonction, par collège, par filière, par
niveau, par genre . . . ).
— La répartition de l’absence par affectation géographique, par genre,
par nature d’absence, par nombre de jours, par collège, par genre. . .
— L’évolution de la paie selon des critères différents (affectation géo-
graphique, par année, par mois, par collège, par type indem . . . ).
— Le suivie de sanction selon des critères différents (affectation géo-
graphique, par année, par mois, par collège, . . . ).
— Le suivie d’assurance selon des critères différents (type assurance,
affectation géographique, par année, par mois, par collège, . . . ).
20
— Le suivie de crédit selon des critères différents (type crédit, affec-
tation géographique, par année, par mois, par collège, . . . ).
2.3.2 Besoins non fonctionnels
Outre les fonctionnalités essentielles, notre application doit respecter
certaines contraintes et répondre à certains besoins non fonctionnels :
— Sécurité : L’accès au tableau de bord ainsi que le chargement de
l’entrepôt de données bien sécurisé.
— Rapidité : L’accès à la base de données doit être souple et rapide. Il
est impérativement nécessaire que la durée d’extraction et du charge-
ment des données s’approche le plus possible du temps réel.
— Fiabilité : les rapports générés doivent être bien précis et basés sur
des données exactes.
— Performance : Le tableau de bord doit être fournir des indicateurs
essentiels et pertinentes pour une prise de décision.
— Aptitude à la maintenance : L’application doit être facile à main-
tenir, ainsi que le code de l’application doit être lisible et compréhen-
sible.
21
— Ergonomie : le système doit être adapté aux standards d’ergonomie
telle que la densité modérée sur l’écran.
— Qualité : Facilitation de l’accès aux données et de la diffusion de
l’information. Interaction homme machine la plus intuitive possible.
2.4 Modélisation dynamique
La modélisation dynamique d’un système consiste à décrire son compor-
tement lors-consiste à décrire son comportement lors de sa réaction à son
environnement.
2.4.1 Diagramme de cas d’utilisation global
Le diagramme de cas d’utilisation nous permet de collecter, analyser et
organiser les besoins et dénombrer les grandes fonctionnalités du système.
22
Figure 2.1 – Diagramme de cas d’utilisation global
23
2.4.2 Identification des acteurs :
Elle consiste à déterminer les différents acteurs qui vont interagir de près
ou de loin avec le système.
Un acteur : est toute entité qui interagit avec notre système dans le but
de réaliser une plus value et qui a toujours le même comportement.
— Administrateur : C’est l’administrateur de la base de production :
permet de gérer le processus d’extraction, transformation et charge-
ment des données, la création des rapports et la gestion des accès au
serveur de reporting.
— Utilisateur / Décideur : Interagit directement avec le tableau de
bord ainsi que la consultation des rapports précédemment crées par
l’administrateur.
24
2.5 Conclusion
Dans ce chapitre, nous avons étudié les différents besoins fonctionnels
et non fonctionnels exprimés par l’AFH. Cela nous a permis de découvrir
le diagramme des cas d’utilisation global. Cette étude sera la base de la
conception que nous allons entamer dans le chapitre suivant.
Enfin, il nous reste à élaborer une bonne conception afin d’assurer le bon
fonctionnement du système.
25
CHAPITRE 3
ÉTAT DE L’ART
3.1 Introduction
Avec la généralisation de l’informatique, qui touche sans exception, toutes
les activités et les secteurs, les entreprises manipulent une masse colossale
de données stockées dans différentes sources. La difficulté n’est plus de la
recueillir, mais de la rendre disponible sous la bonne forme, au bon moment
et à la bonne personne, qui saura l’exploiter et en tirer de la valeur ajoutée.
Pour cette raison, un système d’information décisionnel s’avère indispen-
sable dans les entreprises.
26
Dans ce chapitre, l’objet est de définir les concepts fondamentaux relatifs
aux systèmes décisionnels.
3.2 Informatique décisionnelles
L’informatique décisionnelle (en anglais : business intelligence ou BI) est
l’informatique à l’usage des décideurs et des dirigeants d’entreprises.
3.2.1 Définition
L’informatique décisionnelle exploite les données d’une entreprise à l’aide
des moyens, des outils et des méthodes qui permettent de les collecter,
consolider, modéliser et restituer dans le but d’offrir une vue d’ensemble de
l’activité traitée pour faciliter la prise de décision.
Parmi les différentes définitions du décisionnel, données on trouve :
« Le Décisionnel est le processus visant à transformer les données en in-
formations et, par l’intermédiaire d’interrogations successives, transformer
ces informations en connaissances. » [ Dresner, 2001] 1
1. H. Dresner ; « BI : Making the Data Make Sens » ; Gartner Group 2001
27
3.2.2 Architecture de l’Informatique décisionnelles
La chaine décisionnelle peut être représentée en trois processus général :
ETL, organisation des données et restitution.
Figure 3.1 – Architecture générale d’un système décisionnel
— ETL entre les sources de données et l’entrepôt. Ce processus est res-
ponsable la récupération des données des diverses sources et l’extrac-
tion de l’information qui nous intéresse, la transformation (nettoyage,
filtrage,...), puis l’alimentation d’un entrepôt de données.
— L’entrepôt de données, c’est le processus de stockage, il est res-
28
ponsable de structurer les données par rapport à leur niveau de gra-
nularité (agrégats). Les datamarts, considérés comme des bases de
données métier, sont en fait extraites des entrepôts de données.
— La restitution et dernier niveau fournit à l’utilisateur afin d’arriver
à l’analyse des données selon des outils décisionnels variés comme
des outils de Reporting, des outils de tableau de bord, des outils des
balanced Scorecard ou des outils de fouille de données (data mining).
3.2.3 ETL « Extraction-Transformation-Chargement »
La première phase des projets décisionnels, collecte et prépare les don-
nées pour alimenter la Datawarehouse.
« You get the data out of its original source location (E), you do something
to it (T), and then you load it (L) into a final set of tables for the users to
query ».[Kimball et al., 2008] 2
Le processus ETL est un outil fondamental de l’entrepôt de données, basé
sur le principe de méta base permettent d’effectuer des synchronisations
massives d’information d’une source de données, le nettoyer et de le charger
2. The Data Warehouse Lifecycle Toolkit,Practical Techniques for Building Data Warehouse and Bu-
siness Intelligence Systems ;Wiley Publishing, INC ; Janvier 2008.
29
dans un entrepôt de données, qui représente une part majeure des traite-
ments et nécessite une attention régulière tout au long de cycle de vie du
système.
Selon Kimball :70% de l’effort consacré à un projet de business intelligence
est dépensé dans l’ETL. [Kimball, 2004] 3
Figure 3.2 – Schéma de fonctionnement d’un ETL
Cette alimentation se déroule en 3 phases :
— Extraction des données (Extract) :Assure la connexion à la ma-
jorité des systèmes de stockage de données afin de récupérer et inter-

3. R. Kimball et J. Caserta ; « The Data warehouse ETL Toolkit» ;Wiley Publishing, INC 2004
30
préter les données, identifier, sélectionnées et copier dans la zone de
préparation afin de la manipulations ultérieures .
— Transformation des données (Transform) : C’est la deuxième
étape du processus ETL, elle est très important de consolider et assu-
rer la fiabilité des données et leurs granularités. Après l’extraction, les
données doivent être vérifiées, reformatées et nettoyées afin d’élimi-
ner les valeurs incohérents, compléter et renseigner les valeurs man-
quantes pour garantir leurs abélites et leur qualités.
— Chargement des données (Load) : Chargement des données
(Load) : c’est la dernière phase et la plus délicate surtout lorsque
les volumes sont importants, dans lequel se déroule le stockage de
données dans l’entrepôt afin d’être utilisable par les autres outils du
système BI.
C’est 3 processus assurent l’alimentation de notre Datawarehouse en don-
nées homogènes, propres et fiables.
31
3.3 Entrepôt de données « Data warehouse »
Le Data warehouse est le point de stockage de toutes les données utili-
sées par le système pour analyser les informations. Il assure dans un premier
temps une étanchéité entre le système opérationnel et le système décision-
nel.
3.3.1 Caractéristique d’un entrepôt de données
« Une collection des données orientées sujet, intégrées, non volatiles et
historiées, organisées pour le support d’un processus d’aide à la décision ».
[Inmon 1992] 4
Selon Bill Inmon la collection de données doit être intégrées, orientées
sujet, non volatiles, historiées, résumées et disponibles pour la prise de dé-
cisions.
— Données orientées sujet «métiers» : Les données stockées doivent
être réorganisées autour de thèmes par activités majeures à l’inverse
des systèmes sources où les données sont plutôt structurées par pro-
4. Developing the Data Warehouse. With Chuck Kelley, QED, 1992
32
cessus fonctionnel.
Un sujet pourra ensuite être utilisé dans différentes analyses.
— Données intégrées : Les données proviennent de différentes sources
hétérogènes. L’intégration consiste à résoudre les problèmes d’hété-
rogénéité des systèmes de stockage, des modèles de données, de sé-
mantique de données, l’intégration permet d’avoir la cohérence de
l’information, c’est-à-dire stockées sous le même format, au travers
d’un référentiel d’entreprise.
— Données non volatiles : À la différence des données opérationnelles,
celles de l’entrepôt sont permanentes le rafraı̂chissement de l’entrepôt
consiste à ajouter de nouvelles données, sans modifier ou perdre celles
qui existent.
— historiées : La prise en compte de l’évolution des données est essen-
tielle pour la prise de décision qui utilise des techniques de prédiction
en s’appuyant sur les évolutions passées pour prévoir les évolutions
futures.
Dans un Data Warehouse chaque valeur est associée à un moment.
« Every key structure in the data warehouse contains - implicitly or
33
explicitly -an element of time ». [Inmon, 2000] 5
— Résumées : Les informations issues des sources de données doivent
être agrégées et réorganisées afin de faciliter le processus de prise de
décision.
— Organisées pour le support d’un processus d’aide à la déci-
sion : Les données sont organisées de manière à permettre l’exécution
des processus d’aide à la décision (Reporting, Data Mining. . . ).
5. B. Inmon ; What is a Data Warehouse ; [Document électronique] ; 2000
34
3.3.2 Objectifs
— Accès aux informations de l’entreprise.
— Les informations d’un entrepôt de données sont cohérentes.
— Les outils de présentation d’informations font partie du Data ware-
house.
— Les données publiées sont stockées dans le Data warehouse.
— Qualité de l’information d’un Data warehouse.
3.3.3 Magasin de données « DataMarts »
Un datamart (magasin de données ou comptoir de données) est une vue
partielle du data warehouse mais orientée métier. De ce fait ils suivent les
mêmes principes que celui-ci, leur différence se situe sur le fait qu’un Data-
mart va répondre à un besoin métier plus spécifique que le Data warehouse.
« Le DataMart est un sous-ensemble du Data Warehouse, constitué de
tables au niveau détail et à des niveaux plus agrégés, permettant de res-
tituer tout le spectre d’une activité métier. L’ensemble des DataMarts de
l’entreprise constitue le Data Warehouse. » [Kimball]
35
Datawarehouse Datamart
Contient plusieurs domaines. Ne contient souvent qu’un seul do-
maine, par exemple Finance ou
Ventes.
Détient des informations très dé- Peut contenir plus de données
taillées. résumées (bien que beaucoup
contiennent des détails complets).
Fonctionne pour intégrer toutes les Se concentre sur l’intégration d’in-
sources de données. formations provenant d’un domaine
donné ou d’un ensemble de systèmes
sources.
N’utilise pas nécessairement un mo- Est construit centré sur un modèle
dèle dimensionnel mais nourrit des dimensionnel utilisant un schéma en
modèles dimensionnels. étoile.
Table 3.1 – Tableau comparatif entre datawarehouse et datamart
36
Caractéristique BD de production Datawarehouse DataMart
Opération Gestion courante, Référentiel, ana- Analyse récur-
production lyse ponctuelle rente, outil de
pilotage, support à
la décision
Modèle de Entité/relation Etoile, flocon, Etoile, flocon
données constellation
Normalisation fréquente maximum Rare (redondance
d’information)
Données Actuelles, brutes, Historisées, dé- Historisées, agré-
détaillées taillées gées
Mise à jour Immédiate, temps Souvent différée, Souvent différée,
réel périodique périodique
Niveau de faible faible élevé
consolidation
Perception verticale transverse Horizontale
Operations Lecture, insertion, Lecture, insertion, Lecture, insertion,
mise à jour, sup- mise à jour mise à jour, sup-
pressions pressions
Taille En gigaoctet En téraoctets En gigaoctet
Table 3.2 – Tableau Comparatif entre les bases de données de l’entreprise
37
3.3.4 Modélisation multidimensionnelle
La modélisation dimensionnelle est la méthode de conception logique
qui vise à présenter les données sous une forme standardisée intuitive et qui
permet des accès hautement performants. Elle structure les données d’une
façon très différente de la structure en 3FN (3ème forme normale) fréquem-
ment utilisée par les modélisateurs des systèmes OLTP. La modélisation
dimensionnelle produit ce qu’on appelle le Modèle multidimensionnel, qui
se compose d’une table contenant une clé multiple, la table des faits, et
d’un ensemble de tables nommées tables dimensionnelles.
a. Table des faits
Les « faits », sont les données observables que l’on possède sur un sujet
et que l’on veut étudier, sont ce sur quoi va porter l’analyse. Ce sont des
tables qui contiennent des informations opérationnelles et qui relatent la
vie de l’entreprise. Un fait est tout ce qu’on voudra analyser.
Les« faits » dans un entrepôt de données sont généralement des valeurs nu-
mériques, additives. Une table de faits assure les liens plusieurs à plusieurs
entre les dimensions. Elle comporte des clés étrangères, qui ne sont autres
38
que les clés primaires des tables de dimension et l’ensemble des mesures cor-
respondant aux informations de l’activité à analyser. Mais rappelons que
certaines tables de faits peuvent contenir aucun attribut et représentent
que des liaisons entre tables dimensionnelles.
Figure 3.3 – Structure de base d’une table Fait
b. Table de dimension
Une « dimension » est une table qui raccompagnent une table de faits
contient les axes d’analyse selon lesquels on veut étudier des données ob-
servables qui, soumises à une analyse multidimensionnelle, donnent aux
utilisateurs des renseignements nécessaires à la prise de décision. On ap-
39
pelle donc dimension un axe d’analyse.
Une dimension est généralement constituée : d’une clé artificielle, une clé
naturelle et des attributs.
Figure 3.4 – Structure de base d’une table Dimension
c. Les mesures
Une mesure est un hyper cube, le plus souvent entier ou décimal, structuré
par des dimensions.
d. Les attributs
Les attributs sont généralement des champs textuels qui décrivent une ca-
ractéristique d’un élément tangible. Par exemple, les descriptions d’un pro-
duit.
40
3.3.5 Type de modèle dimensionnel
Il existe 3 modèles dimensionnels : modèle en étoile, modèle en flocon et
modèle en constellation.
a. Modèle en Etoile
Ce type de modèle, initié par Ralph Kimball, est traditionnellement repré-
senté par une table de faits centrale autour de laquelle gravitent les dimen-
sions permettant d’analyser les faits qui y sont contenus. Chaque dimension
est décrite par une seule table dont les attributs peuvent représenter toutes
les granularités possibles.
La table située au centre de l’étoile est la table des faits ou mesures (ou
encore métriques) : ce sont les éléments mesurés dans l’analyse, les tables
situées aux extrémités de l’étoile sont les tables de dimensions (ou encore
axes d’analyse) ou niveaux de suivi. Ce sont les dimensions explorées dans
l’analyse.
41
Figure 3.5 – Structure d’un modèle en étoile
— Avantages :
— Facilité de navigation.
— Performances : nombre de jointures limité, gestion des données
creuses.
— Inconvénients :
— Toutes les dimensions ne concernent pas les mesures.
— Redondances dans les dimensions.
— Alimentation complexe.
42
b. Modèle en flocon
Le modèle en flocon est de même principe que le modèle en étoile, mais de
plus en plus les dimensions sont décomposées, une plus grande hiérarchisa-
tion de ces dimensions.
Dans ce modèle, uniquement le premier niveau de granularité est directe-
ment en lien avec la table de faits.
Figure 3.6 – Structure d’un modèle en flocon
— Avantages :
— Réduction de volume.
— Formaliser une hiérarchie au sein d’une dimension.
— maintenance des tables de dimensions simplifiée
43
— Evite les redondances.
— Inconvénients :
— Navigation difficiles.
— Nombreuses jointures.
— Une plus grande complexité en termes de lisibilité et de gestion.
— Schéma moins intuitif aux utilisateurs d’affaires.
c. Modèle en constellation
Ce modèle est un ensemble de schémas en étoile et /ou en flocons. Il s’agit
du fusionner plusieurs modèle qui utilisent des dimensions communes.
— Avantage :
— Meilleure gestion des donnés creuses.
— Inconvénient :
— Complexité du modèle.
3.4 Restitution des données
Cette dernière étape, dernier niveau fournit à l’utilisateur, également
appelée «outils end-users», se charge de présenter les informations à valeur
ajoutée de telle sorte qu’elles apparaissent de la façon la plus lisible possible
44
dans le cadre de l’aide à la décision.
Les données sont principalement modélisées par des représentations à base
de requêtes afin de constituer des tableaux de bord, des rapports ou des
fouilles de données via des outils d’analyse décisionnelle.
3.4.1 Le reporting
Le reporting, une famille d’outils de Business intelligence, est l’opéra-
tion consistant, pour une entreprise, à faire rapport de son activité. C’est
la présentation périodique destinée à assurer la réalisation, la publication
et la diffusion de rapports et bilans analytiques sur les activités et résultats
d’une organisation, d’une unité de travail ou du responsable d’une fonction,
selon un format prédéterminé. Ils sont essentiellement destinés à faciliter la
communication de résultats chiffrés ou d’un suivi d’avancement.
Les bases de données sont interrogées selon les requêtes SQL préparées lors
de l’élaboration du modèle. Le rapport peut ensuite être diffusé sur l’In-
tranet, périodiquement en automatique ou ponctuellement à la demande.
L’outil d’élaboration du modèle du rapport offre bien entendu des fonctions
spécifiques de calcul et de présentation (graphiques) afin de concevoir des
45
comptes rendus particulièrement seyants et pertinents.
3.4.2 Tableau de bord (Dashboard)
Le tableau de bord est le cœur du projet business intelligence, c’est un
instrument de mesure de la performance facilitant le pilotage ”pro-actif”
d’une ou plusieurs activités dans le cadre d’une démarche de progrès. Cet
instrument contribue à réduire l’incertitude et facilite la prise de risque
inhérente à toutes décisions.
« Le tableau de bord correspond à un système d’information permettant
de connaı̂tre, le plus rapidement possible, les données indispensables pour
contrôler la marché de l’entreprise à court terme et faciliter dans celle-ci
l’exercice des responsabilités ». [Michel Gervais, 2005] 6
3.4.3 Fouille de données (Datamining)
Data Mining forage de données, explorations de données ou fouilles de
données regroupe des méthodes d’intelligence artificielle, d’apprentissage
mécanique et statistique permet d’explorer et d’analyser une masse impor-
tante de données depuis différentes perspectives et le fait de transformer
6. Contrôle de Gestion ;8ème Edition ; 2005
46
ces données en informations utiles, en établissant des relations entre les
données ou en repérant des patterns. Le Data Mining permet donc, grâce à
un certain nombre de techniques, de découvrir ces connaissances en faisant
apparaı̂tre des corrélations entre ces données.
« Data Mining est le processus non trivial permettant d’identifier des mo-
dèles valides, nouveaux, potentiellement utiles et finalement compréhen-
sibles dans les données ». [U.M.Fayyad, G.Piatetski-Shapiro ] 7
3.4.4 On-Line Analytical Processing OLAP
a. Définition
Les Cubes OLAP (On-Line Analytical Processing) c’est une technologie
permettent une représentation multidimensionnelle de l’information et le
calcul de mesures agrégées pour offrir un accès rapide aux données en vue
d’une analyse, dans le but de répondre aux besoins de Reporting et d’ana-
lyse.
Chaque dimension a la possibilité d’être hiérarchisée en fonction des besoins
de l’utilisateur.
«Activité globale de requêtage et de présentation de données textuelles et nu-

7. From Data mining to Knowledge Discovery in Databases
47
mériques contenues dans l’entrepôt de données ; Style d’interrogation spé-
cifiquement dimensionnel.» [Kimball, 2005] 8
b. Différence entre OLAP et OLTP
L’OLTP (On-Line Transaction Processing) est un traitement transactionnel
en ligne qui sert à insérer, modifier et interroger d’informations en temps
réel alors qu’OLAP est caractérise par un volume relativement petit de
transactions, mais sur un volume très important de données. Les requêtes
sont très complexes et impliquent de nombreuses agrégations.
Les SGBD au sein de l’AFH permettent de contrôler et d’exécuter les tâches
métier fondamentales et fréquentes via leurs données sources opération-
nelles, alors que ce modèle(OLTP) est incapable d’aider à planifier prendre
des décisions d’ordre stratégiques qui touches des axes hétérogènes, d’où la
nécessité d’un modèle OLAP.
8. Guide de conduite de projet , 1ère Edition ;Paris, France ;Eyrolles ;Mars 2005.
48
Caractéristiques Processus OLAP Processus OLTP
Objectifs Interrogation Mise à jour
Nature de données Individuelles Multidimensionnelles,
agrégées, orientées
utilisateur)
Fraı̂cheur de données Récentes, dynamique Historiques, statique
Traitement Simple Complexe, semi-
automatique
Utilisateurs Tout type Décideurs
Temps de réponse rapide Moins rapide
Table 3.3 – Tableau comparatif entre OLTP et OLAP
c. Architecture des serveurs OLAP
Le noyau d’un système OLAP est son serveur. Ces serveurs sont classés
selon la politique régissant l’architecture du serveur. Ainsi, ces architectures
peuvent être distinguées comme suit :
— Les systèmes à architecture MOLAP : Ces systèmes MOLAP
« Multidimentional On-line Analytical Processing » sont conçus ex-
ceptionnellement pour l’analyse multidimensionnelle.
« Ensemble d’interfaces utilisateur, d’applications et de technologies
49
de bases de données propriétaire dont l’aspect dimensionnel est pré-
pondérant. »[Kimball, 2005]
MOLAP offre des temps d’accès optimisés et cela en prédéfinissant
les opérations de manipulation et de chemin d’accès prédéfinis. Autre
caractéristique du agrège tout par défaut, pénalisant du couple sys-
tème lorsque la quantité de données à traiter augmente. On parle
généralement de volume de l’ordre du giga-octet pas plus.
— Les systèmes à architecture ROLAP : Ces systèmes MOLAP
Les systèmes ROLAP « Relationnel On-line Analytical Processing»
sont en mesure de simuler le comportement d’un SGBD multidimen-
sionnel en exploitant un SGBD relationnel.
« Ensemble d’interfaces utilisateurs et d’applications qui donnent une
vision dimensionnelle à des bases de données relationnelles». [Kim-
ball, 2005] 9
— Les systèmes à architecture HOLAP : Les systèmes HOLAP «
Hybride On-line Analytical Processing » sont une sorte de compromis
entre les différents systèmes précités. Cette combinaison donne à ce
9. Guide de conduite de projet , 1ère Edition ;Paris, France ;Eyrolles ;Mars 2005.
50
type de système les avantages du ROLAP et du MOLAP en utilisant
tour à tour l’un ou l’autre selon le type de données.
Serveur Stockage des données Traitement des données
MOLAP BD dimensionnelle Serveur de traitement OLAP
ROLAP BD relationnelle SQL avancé)
HOLAP MOLAP pour données som- & ROLAP pour données dé-
maire taillées
Table 3.4 – Tableau comparatif des serveurs OLAP
d. Les opérations sur un cube OLAP
— Vue synthétique / vue détaillée.
— Drill Up (forage vers le haut) : représente les données du cube à
un niveau de granularité supérieur (agrégation).
— Drill Down (forage vers le bas) : représente les données du cube
à un niveau de granularité inférieur (détail).
— Drill-out/Split : ajouter une ou plusieurs dimensions.
— Drill-in/Merge : réduire le cube d’une ou plusieurs dimensions.
— Rotate : Rotation d’une face.
51
— Slicing : Sélection de tranches du cube par prédicats selon une di-
mension.
— Scoping : Extraction d’un sous-ensemble du cube.
Figure 3.7 – Exemple d’opération sur un cube OLAP
e. Langage de requêtes
Comme SQL pour les bases de données relationnelles, il existe des langages
de requêtes pour l’utilisation des OLAP. Il s’agit de MDX « Multidimentio-
nal Expressions » qui possède une syntaxe appropriée à l’interrogation et
manipulation des données multidimensionnelles mémorisées dans un cube
OLAP.
52
3.5 Conclusion
Dans ce chapitre nous avons consacré à définir les notions et les concepts
de base du système décisionnel.
Dont le concept « Data Warehouse » est apparu comme une réponse à
des besoins grandissants dans le domaine décisionnel. Son adaptabilité et
sa capacité de fournir par la souplesse, la rapidité et l’intégrité les données
nécessaires à une bonne analyse, ont fait de lui un atout majeur et incon-
tournable pour toute entreprise soucieuse du suivi de ces performances.
Au cours des chapitres suivants, nous allons utiliser les concepts présentés
dans l’état de l’art, et cela afin de mettre en œuvre notre système, aussi
nous pourrons entamer le prochain chapitre sur la conception à pas sûrs.
53
CHAPITRE 4
CONCEPTION
4.1 Introduction
Après la présentation des besoins et la présentation de l’état de l’art,
nous nous intéressons à l’aspect conceptuel de notre système décisionnel
qui est une phase importante dans le processus de développement puis-
qu’elle prépare la réalisation. Dans ce chapitre, nous allons exposer une
étude détaillée des différents cas d’utilisation du système en utilisant les
diagrammes des cas d’utilisation et les diagrammes de séquence ensuite
la conception de l’entrepôt de données avec leurs indicateurs ainsi que les
différentes faits et dimensions.
54
4.2 Étude détaillée des cas d’utilisation
L’étude détaillée des cas d’utilisation concerne les besoins relatifs à l’en-
trepôt de données. Dans cette section nous allons expliquer chaque cas.
4.2.1 Raffinement du cas d’utilisation « Gérer ETL »
La figure 4.1 représente le raffinement du cas d’utilisation ”Gérer intégra-
tion”, l’administrateur informatique peut générer l’intégration avec Pentaho
Data Intégration (PDI). D’abord il va créer des packages PDI, extraire,
transformer et charger les données par le biais d’un outil ETL.
C’est l’étape la plus importante, elle constitue de 70% à 80% du temps dans
un projet décisionnel.
55
Figure 4.1 – Raffinement de cas d’utilisation ” Gérer ETL”
56
4.2.2 Raffinement du cas d’utilisation «Créer transformations»
La figure 4.2 représente le raffinement de cas d’utilisation ” Créer pa-
ckages ”, l’administrateur informatique doit gérer des nouveaux packages
PDI et créer les dimensions et les faits, charger les données sources. Il peut
aussi créer des mesures si nécessaire.
Figure 4.2 – Raffinement de cas d’utilisation ” créer transformation ”
57
4.2.3 Raffinement du cas d’utilisation « Analyser les données »
La figure 4.3 représente le raffinement de cas d’utilisation ” Analyser
les données ”, l’administrateur informatique peut analyser les données avec
Pentaho BI Server qui nous permet de créer des cubes OLAP. En premier
lieu, il faut charger les données dans l’entrepôt de données qu’on a créé
dans l’étape précédente.
Figure 4.3 – Raffinement des cas d’utilisation ” Analyser les données ”
58
4.2.4 Raffinement du cas d’utilisation « Créer Cube »
La figure 4.4 représente le raffinement de cas d’utilisation ”Créer cube”.
Pour créer un cube il faut définir les tables de faits, les mesures, et les
dimensions l’administrateur informatique peut définir des hiérarchies pour
les dimensions.
Figure 4.4 – Raffinement de cas d’utilisation ” Créer cube ”
59
4.2.5 Raffinement du cas d’utilisation « Gérer rapports »
La figure 4.5 représente le raffinement de cas d’utilisation ” Analyser
les données ”, l’administrateur informatique peut analyser les données avec
Pentaho BI Server qui nous permet de créer, modifier et supprimer des
rapports.
Figure 4.5 – Raffinement de cas d’utilisation ” Gérer rapports ”
60
4.3 Diagramme de séquence
— Diagramme de séquence « Authentification »
La figure 4.6 représente le scénario du cas d’utilisation ”Authentification”.
L’utilisateur saisit son login et son mot de passe, il clique sur le bouton «
login ». Le système vérifie la combinaison login et mot de passe. Si le Login
et le mot de passe sont correcte, l’authentification est réussite.
Figure 4.6 – Diagramme de séquence ” Authentification ”
61
4.4 Conception de l’entrepôt de données
La conception de l’entrepôt de données représente le lé de réussite de
tout projet BI.
Elle constitue la phase la plus important dans le déroulement du projet et
passe par 4 étapes essentielles :
— Définition de sujet à analyser : Il s’agit de répondre à la question :
que représente un enregistrement de la table de fait ?
Il s’agit de l’étape la plus critique lors de la création du modèle parce
qu’il faut comprendre et analyser de manière détaille les besoin finale
de client.
— Choix des dimensions : Dans cette étape on doit choisir les diffé-
rentes dimensions qui représentent le contexte dans lequel le fait a eu
lieu.
— Choix des indicateurs/mesures : Dans cette étape on peut iden-
tifier s’il existe des mesures ou non pour ce sujet.
— Choix du modèle dimensionnel : Il s’agit d’identifier le modèle
conceptuel multidimensionnel (étoile, flocon ou constellation).
62
4.4.1 Les dimensions
Une dimension correspond à un axe d’analyse de la problématique du
projet, elle est nécessairement un facteur dont dépend l’aspect que l’objectif
du projet essaye de mesurer.
Les dimensions ont pour objectif de définir le fait, donc on essaye de recen-
ser toutes les informations qui décrivent l’effectif et qui peuvent intéresser
les décideurs.
63
Dimensions Définition
dim date Elle contient les dates dès 1998.
dim fonction Elle contient les fonctions de l’AFH
(PDG, PDA, Directeur, chef ser-
vice,. . . ).
dim college Elle contient les différents collèges
de l’AFH (cadre supérieur, cadre
moyen, maitrise, exécution).
dim qualification Elle contient les différentes qualifica-
tions de l’AFH (administrateur gé-
néral, ingénieur général, urbaniste
général,. . . ).
dim sexe Elle définir le sexe du personnel.
dim age Elle contient la date de naissance du
personnel.
dim anciennete Elle contient la date de recrutement
de chaque personnel.
dim affect geo Elle contient les différentes affecta-
tions géographiques de l’AFH (Tu-
nis, Sousse, Bizerte, Béja,. . . ).
dim ufg Elle contient les différentes ufg de
l’AFH (Tunis, Sousse, Sfax).
64
dim ufa Elle contient les différentes ufa de
l’AFH (Direction régionale du nord,
DGA, D.des ressources humaines et
du matériel,. . . ).
dim diplome Elle contient le diplôme de chaque
personnel.
dim profil Elle contient les profile de chaque
personnel (Gestion, Génie civil,
Droit, Architecture,. . . ).
dim situation Elle contient l’information sur la si-
tuation familiale de chaque person-
nel.
dim niveau etude Elle contient le niveau d’étude de
chaque personnel.
dim position Elle contient les différents positions
de l’AFH (Détache à AFH, Dé-
tache hors AFH, Contractuel, Statu-
taire,. . . ).
dim sous position Elle contient les différents sous-
positions de l’AFH (Actif, bloqué,
Mi-temps,. . . ).
65
dim typeAbs Elle contient les différents types
d’absence (Absence irrégulière,
Mi temps 12 du salaire, congé
maladie,. . . ).
dim indem Elle contient les différents types d’in-
demnités (salaire net, frais déplace-
ment, avance scolaire, amicale,...).
dim mois Elle contient les différents mois de
salaire (janvier, février, avance sco-
laire, 13eme mois, prix de rende-
ment,...).
dim sanction Elle contient les différents types de la
sanction (mutation, avertissement,
blâme, mise à pied,. . . ).
dim typecred Elle contient les différents types du
crédit (don décès, Dons Mariage,
soins, prêt opération,. . . ).
dim assurance Elle contient les différents types
d’assurance (pharmacie, consulta-
tion spécialiste, soins, hospitalisation
clinique,. . . ).
Table 4.1 – Définition des dimensions
66
Ci-dessous la description détaillée de chaque dimension :
— Dimension Date :
« La dimension temps est la seule dimension qui figure systématiquement
dans tout entrepôt de données, car en pratique tout entrepôt de données est
une série temporelle. Le temps est le plus souvent la première dimension
dans le classement sous-jacent de la base de données.» [Kimball, 2011] 1
Il est intéressant de signaler que la finalité du bilan social est d’informé
toutes les instances légales et représentatives sur l’état des ressources hu-
maines de l’entreprise au 31 décembre de chaque année, pour cela les utili-
sateurs ont exprimé avec insistance leur besoin d’un suivi annuelle de leurs
activités. La dimension temps se décrit comme suit :
1. The Moicrosoft Data Warehouse Toolkit ;Second Edition ; 2011
67
Désignation Type Détail
Id Numeric Identifiant de la dimension
dim date
Lib Date DateTime La date au format complet
Année Numeric Année de la date
Mois Numeric Mois de la date
Jour Numeric Jour de la date
Table 4.2 – Description des colonnes de la dimension ” date ”
— Dimension Age :
Id Age Numeric Identifiant de la dimension
dim age
DATENAIS Date La date de la naissance au format
complet
ANNEE AGE Numeric Année de la date naissance
MOIIS AGE Numeric Mois de la date naissance
JOUR AGE Numeric Jour de la date naissance
Table 4.3 – Description des colonnes de la dimension ” Age ”
68
— Dimension Ancienneté :
Id REC Numeric Identifiant de la dimension
dim Ancienneté
DATEREC Date La date de recrutement au format
complet
ANNEE REC Numeric Année de la date de recrutement
MOIIS REC Numeric Mois de la date de recrutement
JOUR REC Numeric Jour de la date de recrutement
Table 4.4 – Description des colonnes de la dimension ” Ancienneté ”
— Dimension Sexe :
Id SEXE Numeric Identifiant de la dimension
dim Sexe
LIB SEXE Varchar Nom complet du sexe du person-
nel dans l’AFH
Table 4.5 – Description des colonnes de la dimension ” Sexe ”
69
— Dimension Situation Familiale :
Id SITUATION Numeric Identifiant de la dimension
dim Situation
LIB SITUATION Varchar Nom complet de la situation du
personnel en Français
LIBAR SITUATION Varchar Nom complet de la situation du
personnel en Arabe
Table 4.6 – Description des colonnes de la dimension ” Sexe ”
— Dimension affectation géographique :
Id GEO Numeric Identifiant de la dimension
dim Affect geo
LIB GEO Varchar Nom complet de l’affectation géo-
graphique en français
LIBAR GEO Varchar Nom complet de l’affectation géo-
graphique en Arabe
Table 4.7 – Description des colonnes de la dimension ” Affectation géographique ”
70
— Dimension UFA :
Id UFA Numeric Identifiant de la dimension
dim UFA
LIB UFA Varchar Nom complet de l’UFA en français
LIBAR UFA Varchar Nom complet de l’UFA en Arabe
Table 4.8 – Description des colonnes de la dimension ” UFA ”
— Dimension UFG :
Id UFG Numeric Identifiant de la dimension
dim UFG
LIB UFG Varchar Nom complet de l’UFG en fran-
çais
LIBAR UFG Varchar Nom complet de l’UFG en Arabe
Table 4.9 – Description des colonnes de la dimension ” UFG ”
71
— Dimension Collége :
Id COLLEGE Numeric Identifiant de la dimension
dim College
LIB COLLEGE Varchar Nom complet dU Collége en fran-
çais
LIBAR COLLEGE Varchar Nom complet dU Collége en
Arabe
Table 4.10 – Description des colonnes de la dimension ” Collége ”
— Dimension Fonction :
Id FONCTION Numeric Identifiant de la dimension
dim Fonction
LIB FONCTION Varchar Nom complet de la Fonction en
français
LIBAR FONCTION Varchar Nom complet de la Fonction en
Arabe
Table 4.11 – Description des colonnes de la dimension ” Fonction ”
72
— Dimension Filiére :
Id FILIERE Numeric Identifiant de la dimension
dim Filiere
LIB FILIERE Varchar Nom complet de la Filiére en fran-
çais
LIBAR FILIERE Varchar Nom complet de la Filiére en
Arabe
Table 4.12 – Description des colonnes de la dimension ” Filiére ”
— Dimension Diplôme :
Id DIPLOME Numeric Identifiant de la dimension
dim diplome
LIB DIPLOME Varchar Nom complet du Diplôme en fran-
çais
LIBAR DIPLOME Varchar Nom complet du Diplôme en
Arabe
Table 4.13 – Description des colonnes de la dimension ” Diplôme ”
73
— Dimension Niveau d’étude :
Id NIVEAU Numeric Identifiant de la dimension
dim diplome
LIB NIVEAU Varchar Nom complet du Niveau d’étude
en français
LIBAR NIVEAU Varchar Nom complet du Niveau d’étude
en Arabe
Table 4.14 – Description des colonnes de la dimension ” Niveau d’étude ”
— Dimension Qualification :
Id QUALIFICATION Numeric Identifiant de la dimension
dim Qualification
LIB QUALIFICATION Varchar Nom complet du Qualification en
français
LIBAR QUALIFICATION Varchar Nom complet du Qualification en
Arabe
Table 4.15 – Description des colonnes de la dimension ” Qualification ”
74
— Dimension Position :
Id POSITION Numeric Identifiant de la dimension
dim Position
LIB POSITION Varchar Nom complet de la Position en
français
LIBAR POSITION Varchar Nom complet de la Position en
Arabe
Table 4.16 – Description des colonnes de la dimension ” Position ”
— Dimension Sous Position :
Id SOUS POSITION Numeric Identifiant de la dimension
dim Sous Position
LIB SOUS POSITION Varchar Nom complet de la Sous Position
en français
LIBAR SOUS POSITION Varchar Nom complet de la Sous Position
en Arabe
Table 4.17 – Description des colonnes de la dimension ” Position ”
75
— Dimension type absence :
Id TYPEABS Numeric Identifiant de la dimension
dim typeAbs
LIB TYPEABS Varchar Nom complet du type d’absence
en français
LIBAR TYPEABS Varchar Nom complet du type d’absence
en Arabe
Table 4.18 – Description des colonnes de la dimension ” type absence ”
— Dimension type crédit :
Id TYPECRED Numeric Identifiant de la dimension
dim typeCred
LIB TYPECRED Varchar Nom complet du type de cédit en
français
LIBAR TYPECRED Varchar Nom complet du type de crédit en
Arabe
Table 4.19 – Description des colonnes de la dimension ” type crédit ”
76
— Dimension indemnité :
Id INDEM Numeric Identifiant de la dimension
dim indem
LIB INDEM Varchar Nom complet de l’indemnité en
français
LIBAR INDEM Varchar Nom complet de l’indemnité en
Arabe
Table 4.20 – Description des colonnes de la dimension ” indemnité ”
— Dimension type sanction :
Id TYPESANC Numeric Identifiant de la dimension
dim tupeSanc
LIB TYPESANC Varchar Nom complet du type de la sanc-
tion en français
LIBAR TYPESANC Varchar Nom complet du type de la sanc-
tion en Arabe
Table 4.21 – Description des colonnes de la dimension ” type sanction ”
77
— Dimension mois :
Id MOIS Numeric Identifiant de la dimension
dim mois
LIB MOIS Varchar Nom complet du mois en français
LIBAR MOIS Varchar Nom complet du mois en Arabe
Table 4.22 – Description des colonnes de la dimension ” mois ”
— Dimension type assurance :
Id TYPEASSUR Numeric Identifiant de la dimension
dim tupeAssurance
LIB TYPEASSUR Varchar Nom complet du type d’assurance
en français
LIBAR TYPEASSUR Varchar Nom complet du type d’assurance
en Arabe
Table 4.23 – Description des colonnes de la dimension ” type assurance ”
4.4.2 Les dimensions communes
Le tableau suivant nous donne la liste des dimensions communes entre
toutes les étoiles, Ces dimensions sont indispensables pour répondre au
78
besoin de l’application.
Dimensions Fait- Fait- Fait- Fait- Fait- Fait- Fait-
Personnel Absence Retard Paie Sanction Crédit Assurance
dim date * * * * * * *
dim fonction * * * * * *
dim college * * * * * * *
dim * *
qualification
dim sexe * * * * * * *
dim *
anciennite
dim * * * * * * *
affect geo
dim ufg * * * * * * *
dim ufa * * * * * * *
dim diplome * *
dim profil *
dim filiere * * * * * * *
dim situation * * * * * *
79
dim niveau *
etude
dim position * *
dim typeAbs *
dim indem *
dim mois *
dim sanction *
dim typecred *
dim sanction *
Table 4.24 – Détection des dimensions communes
4.4.3 Sujet d’analyse : Gérer effectifs
Gérer effectifs permet d’analyser les informations concernant les person-
nels de l’AFH selon plusieurs mesures et indicateurs.
a. Choix d’indicateur
Indicateurs Description Formule Propriété
d’agrégation d’additivité
NBR EFFECTIFS TOT Le nombre total Somme Additifs
d’effectifs.
Table 4.25 – Description des mesures de la table fait personnel
80
b. Datamart Fait-Personnel
Le Datamart personnel est représenté par un schéma en étoile ayant le
nombre des personnels comme mesure dans la table de faits « fait personnel
».
Figure 4.7 – Modèle en étoile ” Fait-personnel ”
81
4.4.4 Sujet d’analyse : Gérer Absentéisme
Gérer Absentéisme permet d’analyser les informations concernant le
suivi d’absence d’effectifs de l’AFH selon plusieurs mesures et indicateurs.
NBR EFFECTIFSABS Le nombre total Somme Additifs
d’effectifs en ab-
sence.
NBR JOURABS Le nombre total Somme Additifs
de jours d’une per-
sonne en absence.
Table 4.26 – Description des mesures de la table fait absence
b. Datamart Fait-Absence
Le Datamart absence est représenté par un schéma en étoile ayant le nombre
du jour d’Absence et le nombre d’effectives absences comme mesure dans
la table de faits « fait absence ».
82
Figure 4.8 – Modèle en étoile ” Fait-Absence ”
83
4.4.5 Sujet d’analyse : Gérer Retard
Gérer Retard permet d’analyser les informations concernant le retard
d’effectifs de l’AFH selon plusieurs mesures et indicateurs.
NBR Le nombre total Somme Additifs
EFFECTIFSRETARD d’effectifs en
retard.
Table 4.27 – Description des mesures de la table fait retard
b. Datamart Fait-Retard
Le Datamart retard est représenté par un schéma en étoile ayant le nombre
du minute de retard et le nombre d’effectives retards comme mesure dans
la table de faits « fait retard ».
84
Figure 4.9 – Modèle en étoile ” Fait-Retard ”
85
4.4.6 Sujet d’analyse : Gérer Salaire
Gérer Salaire permet d’analyser les informations concernant le suivi de
paie d’effectifs de l’AFH selon plusieurs mesures et indicateurs.
MONTANT Le montant total de Somme Additifs
salaire d’effectifs.
Table 4.28 – Description des mesures de la table fait paie
b. Datamart Fait-Paie
Le Datamart paie est représenté par un schéma en étoile ayant le montant
total du paie comme mesure dans la table de faits « fait paie ».
86
Figure 4.10 – Modèle en étoile ” Fait-Paie ”
87
4.4.7 Sujet d’analyse : Gérer Sanction
Gérer Sanction permet d’analyser les informations concernant le suivi
des sanctions d’effectifs de l’AFH selon plusieurs mesures et indicateurs.
NBR EFFECTIF Le nombre total Somme Additifs
d’effectifs sanction-
nés.
NBR JOUR Le nombre total de Somme Additifs
jours de sanction
d’une personne.
Table 4.29 – Description des mesures de la table fait Sanction
b. Datamart Fait-Sanction
Le Datamart sanction est représenté par un schéma en étoile ayant le
nombre du jour du sanction et le nombre d’effectives sanctionnées comme
mesure dans la table de faits « fait sanction ».
88
Figure 4.11 – Modèle en étoile ” Fait-Sanction ”
89
4.4.8 Sujet d’analyse : Gérer Crédit
Gérer Crédit permet d’analyser les informations concernant le suivi de
crédit d’effectifs selon plusieurs mesures et indicateurs.
NBR PERS Le nombre total de Somme Additifs
personne.
MONTANT Le montant total de Somme Additifs
crédit d’effectifs.
Table 4.30 – Description des mesures de la table fait Crédit
b. Datamart Fait-Crédit
Le Datamart crédit est représenté par un schéma en étoile ayant le nombre
total d’effectif et le montant de crédit comme mesure dans la table de faits
« fait crédit ».
90
Figure 4.12 – Modèle en étoile ” Fait-Crédit ”
91
4.4.9 Sujet d’analyse : Gérer Assurance
Gérer Assurance permet d’analyser les informations concernant le suivi
d’assurance d’effectifs selon plusieurs mesures et indicateurs.
NBR PERS Le nombre total de Somme Additifs
personne.
MONTANT Le montant total Somme Additifs
d’assurance d’effec-
tifs.
Table 4.31 – Description des mesures de la table fait Assurance
b. Datamart Fait-Assurance
Le Datamart crédit est représenté par un schéma en étoile ayant le nombre
total d’effectif et le montant de crédit comme mesure dans la table de faits
« fait crédit ».
92
Figure 4.13 – Modèle en étoile ” Fait-Assurance ”
93
4.5 Conception ETL
Dans un projet décisionnel, l’ETL ou l’alimentation du Data Warehouse
est une étape des plus importantes elle représente 70% de la charge de tra-
vail. Cette étape a pour objectif l’acheminement des données des systèmes
sources jusqu’à l’entrepôt de données, en passant par les différentes phases
de nettoyage et de transformations nécessaires.
Le processus d’alimentation nécessite les étapes suivantes :
— Étude et planification
— Processus ETL
4.5.1 Étude et planification
Avant de commencer l’alimentation, on doit étudier les données sources,
la détection de leur contenue et leur emplacement.
a. L’étude des sources de données
Les sources de données de notre entrepôt est la base transactionnelle conte-
nant les informations reliée à la gestion de ressource humaine de l’AFH.
94
b. La Détection des contenues et des emplacements des données
sources
Le processus d’alimentation a débuté par l’extraction des données qui est
sans doute la tâche la plus vaste du projet décisionnel. Le plus souvent, sa
difficulté réside dans le choix des données à extraire et des filtres à appliquer.
— Bases de données sources
95
Figure 4.14 – Base de données source
96
4.5.2 Processus ETL
Le Processus ETl se déroule selon 3 étapes l’extraction du données à
partir de BD source, la transformation et enfin la chargement dans le data
warehouse.
a. Extraction des données
A partir de base de données source on va extraire les données nécessaires
pour répondre au besoin du client.
Cette phase est considérée comme une étape difficile car il faut établir
des connexions vers les systèmes ou exporter des volumes important des
données sous plusieurs formes.
b. Transformation des données
La phase de transformation des données est la plus importante d’ETL ou
la présence des outils permet de contrôler les données entrantes, traiter
et nettoyer les informations inappropriées, puis les transformer en données
validées et intégrées.
En général, l’objectif de la phase de transformation consiste à charger des
données fiables et pertinentes pour l’alimenter dans la datawarehouse.
97
c. Chargement des données
C’est la dernière phase d’alimenter l’entrepôt de données. Il s’agit de sto-
cker les données dans le dataWarehouse.
Le processus d’alimentation commence par le chargement des tables dimen-
sions, une fois les données sont bien stockées, les chargements des tables
faits se lancent.
4.6 Conception de la restitution
La restitution des données est la dernière étape d’un projet décisionnel.
Cette phase consiste à charger les informations d’une façon plus lisible dans
la cadre de l’aide à prendre des décisions pour bien piloter l’entreprise.
4.6.1 Conception des cubes OLAP
La Modélisation de notre entrepôt de données nécessite d’une struc-
ture de stockage adoptée à l’OLAP (on-line analytical processing), qui per-
mettent, à partir des entrepôts de données, d’analyser l’activité de l’entre-
prise grâce à des statistiques précis. L’élément principal de l’infrastructure
OLAP est le cube. C’est en fait une base de données multidimensionnelle,
98
qui permet l’analyse de ces données en reprend les mesures de la table de
faits et s’en sert pour effectuer des calculs, les mesures étant des données
quantitatives.
Figure 4.15 – Modélisation des cubes dimensionnels
4.6.2 Conception des tableaux de bord
Dans le cadre de notre projet, nous avons eu l’idée de créer des tableaux
de bords destinés aux décideurs pour les aider à avoir une vue globale sur
la situation de leurs personnels.
Nous avons réalisé pour ce projet 7 tableaux de bord consacré chacune un
axe pour la gestion du ressource humaine.
99
4.7 Diagramme de déploiement
Le diagramme de déploiement représente la disposition physique des res-
sources matérielles qui composent le système et montre la répartition des
composants sur ces matériels. Il est intéressant donc de le concevoir pour
une meilleure orientation de la réalisation du système. La figure 24 repré-
sente l’architecture physique de notre système et la méthode de répartition
des composantes logicielles sur ce dernier.
100
Figure 4.16 – Diagramme de déploiement
101
4.8 Conclusion
Dans ce chapitre nous avons présenté la conception du système par la pré-
sentation de différents diagrammes que nous avons établis ainsi la concep-
tion de la zone d’entreposage. La conception de cette zone se fait grâce à la
modélisation dimensionnelle qui offre aux utilisateurs des modèles compré-
hensibles permettant de naviguer et de manipuler les données sans difficulté
afin de satisfaire leurs besoins en analyse.
Nous avons réservons le chapitre suivant pour la présentation de l’environ-
nement du travail et les outils utilisés pour réalisation de notre système.
102
CHAPITRE 5
PRÉSENTATION DES OUTILS UTILISÉES ET
RÉALISATION
5.1 Introduction
Après l’étude conceptuelle du système, nous passons à l’étape de réa-
lisation. Celle-ci commence par présenter l’environnement de travail. Puis
la définition des choix technologiques nécessaire au développement. Enfin
nous mettons en évidence l’implémentation de notre système via quelques
interfaces.
103
5.2 Environnement de travail
Nous présentons dans cette section l’environnement matériel et logiciel
utilisé pour le développement de notre application.
5.2.1 Environnement matériel
Pour l’implémentation de cette application nous avons utilisé deux ordi-
nateurs qui présentent les caractéristiques suivantes :
— Modèle : Asus
— Processeur : Intel(R) Core(TM) i5-5200U CPU 2.20 GHz.
— RAM : 8.00 GO
— Type du système : Windows10 64bits
5.2.2 Environnement logiciel
— Oracle Database 10g
Figure 5.1 – Logo Oracle 10g
104
Oraclea Database est un système de gestion de base de données relationnel
(SGBDR) qui depuis l’implémentation du support du modèle objet dans sa
version 8 peut être aussi qualié de système de gestion de base de données
relationnel-objet (SGBDRO). Il est fourni par Oracle-Corporation. Il ac-
cord de meilleurs résultats grâce notamment à l’automatisation des tâches
administratives et à des fonctionnalités de sécurité et de conformité régle-
mentaire sans équivalent sur le marché.
— Pentaho data Integration (PDI)
Figure 5.2 – Logo de PDI
Le PDI (Pentaho Data Integration), anciennement connu sous le nom de
Kettle, est un logiciel d’ETL (Extract, Transform, Load) Open Source qui
permet la conception ainsi que l’exécution des opérations de manipulation et
de transformation de données très complexes. Son objectif est de récupérer
diverses sources dans différents formats, de les traiter, les transformer, et
établir un résultat puis finalement exporter dans le format souhaité vers
une destination souhaitée. De plus l’intégration de données de Pentaho
105
est ouverte ; elle repose sur une architecture normalisée et est ajustable à
n’importe quel environnement ou solution de BI[3].
L’outil Pentaho Data Integration offre des fonctionnalités
— L’extraction,
— La transformation,
— le chargement des données.
— Pentaho Console utilisateur (PUC)
Figure 5.3 – Logo de PUC
La Pentaho Console utilisateur (PUC) est un environnement de conception
Web où vous pouvez analyser les données, créer des rapports interactifs,
des rapports de tableau de bord, et de construire des tableaux de bord
intégrés pour partager des solutions de business intelligence avec les autres
dans votre organisation et sur Internet. En plus de ses caractéristiques de
conception, le PUC offre une grande variété de fonctions d’administration
système pour la configuration du serveur Pentaho.
— L’extraction,
106
— La transformation,
— le chargement des données.
— Pentaho design reporting
Figure 5.4 – Logo Pentaho design reporting
Le Pentaho Report Designer (PRD) est une application de bureau qui offre
un environnement de conception visuelle pour créer des rapports. Les rap-
ports peuvent être exécutés et enregistrés localement par l’intermédiaire
du PRD ou publiés sur un serveur Pentaho BI pour permettre à de nom-
breuses personnes d’accéder et de planifier l’exécution du rapport. Le PRD
est orienté vers les utilisateurs expérimentés, qui sont familiers avec les
concepts et les données-sources utilisées.
— Laravel
Figure 5.5 – Logo Laravel
107
Laravel est un framework open-source web PHP, créé par Taylor Otwell
basé sur Symfony et destiné au développement d’applications web suivant
le modèle architectural MVC (model-view-controller). Certaines des fonc-
tionnalités de Laravel sont un système d’empaquetage modulaire avec un
gestionnaire de dépendances dédié, différentes manières d’accéder aux bases
de données relationnelles, des utilitaires qui facilitent le déploiement et la
maintenance des apps. Le code source de Laravel est hébergé sur GitHub
et sous licence selon les termes de la licence MIT.
— MySQL
MySQL est un système de gestion de bases de données relationnelles (SGBDR).
Il est distribué sous une double licence GPL et propriétaire. Il fait partie des
logiciels de gestion de base de données les plus utilisés au monde3, autant
par le grand public (applications web principalement) que par des profes-
sionnels, en concurrence avec Oracle, Informix et Microsoft SQL Server.
— PhpStorm
PhpStorm est un éditeur pour PHP, HTML, CSS et JavaScript, édité par
JetBrains. Il permet d’éditer du code PHP 5.3, 5.4, 5.5, 5.6 et 7.0, 7.1, 7.2
Il possède :
108
- Une coloration syntaxique
- Affichage des erreurs à la volée
- Auto-complétion intelligente du code
- Réusinage de code.
Il intègre :
- L’envoi des fichiers via FTP
- Un logiciel de gestion de versions, compatible Git, Mercurial et Subversion.
Il permet aussi de visualiser l’architecture de bases de données de différentes
sources (MySQL, SQLite, ...).
— Xampp
XAMPP est un ensemble de logiciels permettant de mettre en place faci-
lement un serveur Web local, un serveur FTP et un serveur de messagerie
électronique. Il s’agit d’une distribution de logiciels libres (X (cross) Apache
MariaDB Perl PHP) offrant une bonne souplesse d’utilisation, réputée pour
son installation simple et rapide. Ainsi, il est à la portée d’un grand nombre
de personnes puisqu’il ne requiert pas de connaissances particulières et fonc-
tionne, de plus, sur les systèmes d’exploitation les plus répandus.
109
— ShareLatex
ShareLaTeX est un éditeur LaTeX en ligne, collaboratif, en temps réel et
compileur PDF. Par ailleurs, ShareLaTeX fut libéré en février 2014. Le 20
Juillet 2017, ShareLatex a été racheté par Overleaf qui prévoie de réunir les
services d’Overleaf et de Sharelatex sur une seule plateforme, actuellement
en période de test.
En comparaison avec les autres éditeurs LaTeX, ShareLaTeX est une appli-
cation basée sur un serveur web, qui est donc accessible via un navigateur
internet.
5.3 Architecture globale d’application
Pour réaliser une solution Business Intelligence complète, fiable et per-
formante, il faut passer par deux phases principales.
Elles s’agissent de la phase d’extraction, de transformation et de chargement
de l’entrepôt de données à travers l’ETL Pentaho Data Integration choisi et
défini dans le paragraphe précédent et la phase de restitution effectuée par
l’outil décisionnel Pentaho Console utilisateur défini précédemment pour
les cubes Olap et les dashboard, aussi Pentaho design reporing pour les
110
reportings.
Figure 5.6 – Architecture globale de la chaı̂ne décisionnelle
5.4 Réalisation du processus ETL
La première phase au niveau de l’alimentation est la phase d’intégra-
tion. C’est la phase la plus importante car elle contient le processus ETL
qui va nous permettre de se connecter à toute source de données, collecter,
transformer et charger les données nécessaire dans notre entrepôt de don-
née. Après avoir chargé toutes les données nécessaires nous allons passer
à travers un cube vers le reporting pour faciliter notre tâche et éviter les
111
requêtes longues et donc minimiser le temps d’exécution. Dans cette partie
nous allons illustrer les diérentes étapes de l’alimentation de notre entrepôt
de données.
5.4.1 Composants kettle utilisés
— Extraction
— Extraction depuis fichier CSV : Lire les informations depuis fichier
CSV.
— Extraction depuis Table : Lire les informations depuis table BDD.
— Transformation
— Ajout séquence : Récupère la prochaine valeur d’une séquence.
— Altération structure flux : Sélectionner ou retirer des champs dans
une ligne. Possibilité de modifier le type, longueur, et précision du
champ.
— Création d’opération de calcul : Créer de nouveaux champs à partir
de calcul simple.
— Dédoublonnage : Permet d’effectuer une dédoublonnage unique-
ment si les lignes sont triées. Sinon les lignes identiques consécu-
112
tives sont prises en compte.
— Tri lignes : Trier lignes suivant certains champs (ascendant et des-
cendant).
— Jointure
— Jointure Comparaison ligne : Effectuer une jointure de deus flux
suivant une clé. Les flux d’entrés doit être triés sur la clé du join-
ture.
— Produit Cartésien : Le résultat de cette étape est le produit carté-
sien des flux d’entrés.
— Contrôle de flux
— Annotate Stream : Permet d’affiner le table de données pour la raf-
finerie de données rationalisée en créant une mesure ou un attribut
sur les colonnes que vous spécifiez.
— Filtrage lignes : Filtrer des lignes grâce à de simple équation.
— Exécution de scripts
— Modified Java Script value : Plugiciel permettant décrire des scripts
Java.
— Calculateur : Calcul en utilisant la librairie de pentaho.
113
— Exécution Script SQL : Exécuter un script SQL, éventuellement
paramétré à l’aide de lignes d’entrée.
— Recherche
— Recherche dans base de données : Rechercher des valeurs dans une
base de données à l’aide des valeurs de champ.
— Entrepôt de données
— Mise à jour dimension junk : Mettre à jour une dimension Junk
dans un entrepôt de données. La clé primaire d’une dimension Junk
représente tous les champs.
— Alimentation
— Insertion dans table : Écrire informations dans table BDD.
114
5.4.2 Connexions aux bases de données source
Figure 5.7 – connexions aux BD
5.4.3 Alimentation de l’entrepôt de données
Pour alimenter de l’entrepôt de données, on doit commencer par l’ali-
mentation des dimensions et par la suite les faits.
a. Alimentation des dimensions
Cette phase consiste à créer des transformations, sous PDI, qui comprend
des composants d’extraction, de transformation et de chargement, il faut
115
tout d’abord se connecter à la source de données, extraire les données néces-
saire par requête sql, convertir les données puis les stocker dans l’entrepôt
de données.
— Alimenter de dimension date
Figure 5.8 – ETL dimension date
116
Figure 5.9 – Exemple d’alimentation des dimensions
117
b. Alimentation des Faits
— Alimentation du Fait Personnel
Pour l’alimentation du fait personnel nous avons fait tout d’abord l’extrac-
tion des données source nécessite à partir de la table de données Idtagent
puis via l’outil recherche des tables nous avons ajouté les dimensions associé
et les faire jointure avec le table de données source à l’aide des valeurs de
champ spécifie.
Figure 5.10 – Alimentation du Fait Personnel
Pour l’alimentation des autre faits, nous avons refaire presque le même
travail.
118
— Alimentation du Fait Absence
Figure 5.11 – Alimentation du Fait Absence
— Alimentation du Fait Retard
Figure 5.12 – Alimentation du Fait Retard
119
— Alimentation du Fait Paie
Figure 5.13 – Alimentation du Fait Paie
— Alimentation du Fait Sanction
Figure 5.14 – Alimentation du Fait Sanction
120
— Alimentation du Fait Crédit
Figure 5.15 – Alimentation du Fait Crédit
— Alimentation du Fait Assurance
Figure 5.16 – Alimentation du Fait Assurance
121
5.5 Réalisation de la restitution
La réalisation de la restitution concernant la réalisation des cubes OLAP
et des tableaux de bords.
5.5.1 Réalisation du cube OLAP
Après l’alimentation de l’entrepôt de donnée et la validation des données,
on peut lancer la phase de restitution en débutant par la création des cubes
OLAP nécessaire pour réaliser notre projet.
Étape de création du cube OLAP a l’aide de CPU en prenant l’exemple du
cube « Fait Personnel » :
— Gérer la source des données
— Sélectionner type source
— Définir les tables dimensions et la table Fait.
— Créer des jointures
— Définir les mesures et les dimensions en spécifiant leurs hiérarchies
122
Figure 5.17 – Créer cube ”Fait personnel”
Le cube qui a été construit à partir de la base de données est représenté
par une structure XML. Elle comporte les dimensions, hiérarchies ainsi que
les indicateurs (« Measures »).
Une fois la Datawarehouse est alimenté et les cubes OLAP sont créés,
nous passons à la création des tableaux de bord.
Pour créer un tableau de bord nous avons utilisées le Community Dash-
board Editor (CDE) comme outils, c’est un éditeur de tableau de bord
graphique qui permet d’accéder aux composants du tableau de bord dans
Community Dashboard Framework (CDF) de la console Pentaho. Cet outil
123
utilise une grille pour la mise en page qui vous permet de créer vos propres
tableaux de bord sans avoir besoin de beaucoup d’expertise JavaScript ou
HTML.
Dans le suit, nous présentons les étapes suivi pour réaliser un tableau de
bord, en présentant comme exemple le tableau de bord « Suivi des person-
nels ».
Tout d’abord nous avons commencé par la mise en page du tableau de
bord en ajoutant des lignes et des colonnes pour la création du structure
de page, la sélection du source du donnée et la personnaliser à l’aide des
requête MDX et en terminant par la développement graphiques ou le choix
du type de chart à besoin.
— Mise en page pour le tableau de bord
124
Figure 5.18 – Mise en page du tableau de bord ’Suivi personnel’
— Personnaliser la perspective de la source de données
Figure 5.19 – Personnaliser de la source de donnée du tableau de bord ’Suivi personnel’
125
— Personnaliser la perspective des composants
Figure 5.20 – Personnaliser des composants graphiques du tableau de bord ’Suivi

personnel’
— Requête MDX
Figure 5.21 – Exemple de la requête MDX
126
— Aperçu du tableau de bord
Figure 5.22 – Aperçu du tableau de bord ’Suivi personnel’
5.5.2 Réalisation des Rapports
La reporting est une autre partie de restitution, nécessite aussi l’alimen-
tation du datawarehouse.
Pour créer un ”reporting”nous avons utilisées Pentaho Report Design comme
outils, en passant par les étapes suivants :
— Connectez-vous à une source de données.
— Filtrer les données avec une requête.
127
— Organiser les éléments de données dans l’espace de travail Report
Designer.
— Appliquer la mise en forme pour signaler les éléments.
— Créez des formules ou des champs calculés à l’aide de données ex-
traites de votre requête.
— Publiez le rapport sur le serveur Pentaho ou localement sous la forme
d’un fichier PDF ou d’un autre format de fichier pris en charge.
Figure 5.23 – Exemple de mise en forme de ”reporting Assurance”
128
Figure 5.24 – Exemple de ”reporting Assurance”
5.6 Interfaces de l’application
Une fois les tableaux de bord sont réalisés ainsi que les rapports en
passant à la dernière étape de notre projet la génération des rapports.
Dans la suite, nous présentons, l’ensemble des interfaces de notre tableau
de bord.
129
5.6.1 Interface « Authentification »
Au lancement de l’application, l’utilisateur est invité à s’authentifier
pour pouvoir accéder à leur session.
Lors de l’authentification deux cas seront possibles :
— Si l’E-mail d’utilisateur et le mot de passe sont valides : La page
d’accueil d’utilisateur correspond sera affiché.
— Sinon : un message d’erreur sera affiché. L’utilisateur doit spécifier
son nom et son mot de passe puis cliquer sur « Login ».
Figure 5.25 – Interface « Authentification »
130
5.6.2 Interface « Suivi de personnel »
L’interface Suivi de personnel, permet de consulter le tableau de bord
décrire les effectifs selon plusieurs axe d’analyse et selon quelque filtre .Par
exemple la répartition de personnel par nombre de recrutement et par an-
née, selon le filtre type de college.
Figure 5.26 – Interface « Suivi de personnel »
131
5.6.3 Interface « Suivi d’absence »
L’interface Suivi d’absence, permet de consulter le tableau de bord dé-
crire l’absentéisme selon différent axe d’analyse et quelque filtre .Par exemple
la répartition d’absence par nombre de jour, nombre d’effectifs et par année,
selon le filtre affectation géographique.
Figure 5.27 – Interface « Suivi d’absence »
132
5.6.4 Interface « Suivi de retard »
L’interface Suivi de retard, permet de consulter le tableau de bord dé-
crire les retards d’effectifs au sein de l’AFH selon différent axe d’analyse et
quelque filtre par exemple l’affectation géographique.
Figure 5.28 – Interface « Suivi de retard »
133
5.6.5 Interface « Suivi de sanction »
L’interface Suivi de sanction, permet de consulter le tableau de bord
décrire les sanctions d’effectifs au sein de l’AFH selon différent axe d’analyse
et quelque filtre par exemple le collège.
Figure 5.29 – Interface « Suivi de sanction »
134
Figure 5.30 – Interface « Report de Suivi de sanction »
135
5.6.6 Interface « Suivi de paie »
L’interface Suivi de paie, permet de consulter le tableau de bord repré-
senté le salaire d’effectifs au sein de l’AFH selon différent axe d’analyse et
quelque filtre par exemple le mois .
Figure 5.31 – Interface « Suivi de paie »
136
5.6.7 Interface « Suivi de crédit »
L’interface Suivi de crédit, permet de consulter le tableau de bord re-
présenté le crédit d’effectifs au sein de l’AFH selon différent axe d’analyse
et quelque filtre .
Figure 5.32 – Interface « Suivi de crédit »
137
Figure 5.33 – Interface « Report de Suivi de crédit »
138
5.6.8 Interface « Suivi d’assurance »
L’interface Suivi d’assurance, permet de consulter le tableau de bord
représenté l’assurance au sein de l’AFH selon différent axe d’analyse et
quelque filtre .
Figure 5.34 – Interface « Suivi d’assurance »
139
Figure 5.35 – Interface « Report de Suivi d’assurance »
5.7 Conclusion
Au niveau de ce chapitre, nous avons présenté en détails la projection de
la conception du plan théorique sur le plan pratique. En effet, Nous avons
décrit l’environnement et les outils utilisées afin de construire notre appli-
cation. Nous avons par la suite élaboré les étapes du processus ETL ainsi
que les interfaces graphiques de l’application permet à prendre décisions
concernent la situation de ressource humaine de l’AFH.
140
CONCLUSION
Ce rapport porte sur le travail réalisé au cours de notre projet de fin
d’études au sein de l’agence foncière d’habitation AFH portant sur la mise
en place d’un système d’aide à la décision.
L’objectif de ce projet BI réside donc à analyser les données sources de l’en-
treprise et concevoir un entrepôt de données afin de recomposer les données
disponibles de la GRH (Gestion de Ressource Humaine), et ce pour obte-
nir une vision intégrée et transversale sur le personnel, une vision métier à
travers des différents axes d’analyse et une vision agrégée ou détaillée selon
le besoin. Ce système data warehouse nous a permis de mettre en place un
tableau de bord qui présentent l’information suivant les critères que choi-
sissent par les décideurs.
141
Ce projet comprend plusieurs étapes successives, d’abord, après l’étude
complète pour comprendre le métier de l’entreprise, leur environnement de
travail et leur besoin et les objectifs attendus, nous avons commencé par
l’étude des données existent afin de réaliser l’entrepôt de données. Ensuite,
nous nous sommes tournés à la modélisation de la zone de stockage des
données s’est faite grâce aux principes de la modélisation dimensionnelle.
Cette modélisation ore une vision claire et une compréhension intuitive des
modelés proposés. La partie d’alimentation de la zone de stockage a été
sans doute la partie de projet la plus complexe et consommatrice en temps.
Cette étape nous a permis de concevoir et de réaliser, grâce a des outils BI
de pentaho. Une fois les données sont chargées dans l’entrepôt de données,
nous avons procédé à l’étape finale du processus BI, qui est la restitution
des données.
La valeur ajoutée que peut apporter ce projet, une fois la solution dévelop-
pée mise en production, est à notre sens considérable. En eet, les rapports
et tableaux de bord générés grâce à notre solution BI orent aux décideurs
de la direction de ressources humaines de l’AFH une vision globale de leurs
activités et pourra les aider à prendre plus ecacement et plus rapidement
142
les décisions stratégiques de gestion.
Comme un projet système d’aide à la décision n’est jamais complètement
terminé, nous proposons d’étendre notre travail. Pour cela nous pouvons
citer les perspectives suivantes :
— Utilisation des méthodes et d’algorithmes de Data Mining pour une
meilleure exploitation des données.
— Enrichissement de l’entrepôt de données à d’autres domaines notam-
ment dans la finance. En effet nous n’avons pas travaillé sur la totalité
de la base source.
— La migration vers les bases de données NoSQL et le Big Data.
143
NETOGRAPHIE
[1] http ://www.afh.nat.tn
[2] https ://fr.slideshare.net/ericmaxime5/rapport-final-pfe-38212938
[3] http ://www.hitachivantara.com
144

PFEBI

Transféré par

Droits d'auteur :

Formats disponibles

PFEBI

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

PFEBI

Transféré par

Droits d'auteur :

Formats disponibles

Mémoire de fin d’études

Diplôme de Master professionnel en

Ingénierie des Systèmes d’Information des Entreprises

Mise en place d’un tableau de bord pour la gestion des

Année universitaire 2017/2018

Je dédie ce modeste travail à :

A mon cher père Adel, aucune dédicace ne saurait exprimer l’amour,

l’estime, le dévouement et le respect que j’ai toujours eu pour vous.Ce travail

est le fruit de tes encouragement et sacrifices pour assurer mon éducation

dans les meilleurs condition.

A ma chère mére Olfa, ma raison d’être,la source de tendresse et

l’exemple du dévouement qui n’a pas cessé de m’encourager et de prier

ce travail en témoignage de mon profond amour.

tous mes vœux de bonheur, de santé et de réussite.

A ma très chères soeurs Rihem & Ranim, en témoignage de l’at-

tachement, de l’amour et de l’affection que je porte pour vous. Je vous dédie

ce travail avec tous mes vœux de bonheur, de santé et de réussite.

A tous mes chères ami(e)s , en témoignage de l’amitié qui nous

je vous dédie ce travail et je vous souhaite une vie pleine de santé et de

correspond à un point de vue sur la vie active.

A Monsieur Jelassi Nidhal, notre encadrante à la faculté des sciences

économique et de gestion de Tunis et Madame Chagra Sonia notre en-

toute admiration. Qu’ils trouvent ici l’expression de notre profonde grati-

A tous les membres du jury.

A tous ceux qui, directement ou indirectement, ont aidé à la finalisation de

gratitude tout en vous témoignant notre respect.

1 Cadre général du projet 4

2 Spécication et analyse des besoins 17

2.3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . 19

4.2.5 Raffinement du cas d’utilisation « Gérer rapports » 60

5 Présentation des outils utilisées Et Réalisation 103

5.6.2 Interface « Suivi de personnel » . . . . . . . . . . . . 131

1.1 Organigramme de l’AFH . . . . . . . . . . . . . . . . . . . 8

4.11 Modèle en étoile ” Fait-Sanction ” . . . . . . . . . . . . . . . 89

5.28 Interface « Suivi de retard » . . . . . . . . . . . . . . . . . . 133

1.1 Tableau de synthèse des méthodologies [2] . . . . . . . . . . 13

4.17 Description des colonnes de la dimension ” Position ” . . . . 75

Face à la mondialisation, la progression des systèmes et des technolo-

gies d’information, les entreprises et plus globalement les organisations, se

trouvent confrontées à des environnements de plus en plus complexes et

compétitifs dans lesquels le pilotage et la prise de décision impliquent des

en compte un volume d’information toujours plus important, la prise de

décision dans les entreprises devient donc une préoccupation de première

De ce fait, la direction de ressources humaines de l’Agence foncière d’ha-

bitation(AFH) a besoin de certaines améliorations pour la bonne gestion

de ressources humaines. La problématique observée dans des diérents diag-

dysfonctionnement au niveau des départements sous leurs responsabilités

à cause de fausse génération de quelques statistiques. Ajoutons à ceci, la

grande quantité de données traitée régulièrement dans l’entreprise est dicile

d’être utilisée par les décideurs seuls.

dantes et éparpillées dans diérents systèmes hétérogènes et non ordonnées

cessaire de fusionner les données et de les arranger dans un entrepôt de

données dans le but de les rendre convenables pour l’analyse et la création

des rapports qui peuvent servir à la prise de décision.

C’est dans ce contexte que s’insère notre projet de n d’études intitulé «

» consiste à concevoir et développer une solution décisionnelle pour le dé-

partement ressource humaine de l’AFH. Cette solution permet d’importer

Ce présent rapport comporte les cinq chapitres suivants :

— Le premier chapitre présente le cadre général du projet en citant les

grandes lignes du travail demandé et le processus de développement