Vous êtes sur la page 1sur 158

Mémoire de fin d’études

En vue d’obtention du

Diplôme de Master professionnel en

Ingénierie des Systèmes d’Information des Entreprises

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

ressources humaines

Encadrants :
Réalisé par :
Mr. Jelassi Nidhal
Ben Mamya Rihab
Mme. Chagra Sonia

Année universitaire 2017/2018


DÉDICACE

Je dédie ce modeste travail à :

A mon cher père Adel, aucune dédicace ne saurait exprimer l’amour,

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

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

dans les meilleurs condition.

A ma chère mére Olfa, ma raison d’être,la source de tendresse et

l’exemple du dévouement qui n’a pas cessé de m’encourager et de prier

pour moi, qui a tant donné, pour qu’on puisse grandir et réussir.Je te dédie

ce travail en témoignage de mon profond amour.

i
A mon cher frère Firas, mon ange gardien et mon fidèle compagnant

dans les moments les plus délicats de cette vie. Je vous dédie ce travail avec

tous mes vœux de bonheur, de santé et de réussite.

A ma très chères soeurs Rihem & Ranim, en témoignage de l’at-

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

ce travail avec tous mes vœux de bonheur, de santé et de réussite.

A tous mes chères ami(e)s , en témoignage de l’amitié qui nous

uni et des souvenirs de tous les moments que nous avons passé ensemble,

je vous dédie ce travail et je vous souhaite une vie pleine de santé et de

bonheur.

A tous ceux qui mes sont chers et toujours dans mes pensées.

Rihab
ii
REMERCIEMENTS

Ce projet de fin d’étude marque une étape importante dans notre vie. Il

correspond à un point de vue sur la vie active.

Nous voudrions remercier toutes les personnes qui nous ont accompagnés

tout au long de notre formation : Nous tenons à adresser nos sincères re-

merciements :

A Monsieur Jelassi Nidhal, notre encadrante à la faculté des sciences

économique et de gestion de Tunis et Madame Chagra Sonia notre en-

cadrant à l’AFH pour avoir bien voulu nous encadrer, pour tout le temps

qu’ils nous ont octroyés et pour tous les conseils qu’ils nous ont prodigués.Ils

nous ont toujours réservé le meilleur accueil, malgré leur obligations profes-

iii
sionnelles. Leur encouragements inlassables, amabilité, gentillesse mé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 aidé à la finalisation de

ce travail. Nous saisissons cette occasion pour vous exprimer notre profonde

gratitude tout en vous témoignant notre respect.


TABLE DES MATIÈRES

Dédicace i

Remerciements ii

Introduction 1

1 Cadre général du projet 4


1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Pré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 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . 10
1.7 Planification du projet . . . . . . . . . . . . . . . . . . . . . 16
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 Spécication et analyse des besoins 17


2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1 Présentation de l’existant . . . . . . . . . . . . . . . 18
2.2.2 Critique de l’existant . . . . . . . . . . . . . . . . . . 18

i
TABLE DES MATIÈRES

2.3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . 19


2.3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . 19
2.3.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . 21
2.4 Modé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 État de l’art 26
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Informatique décisionnelles . . . . . . . . . . . . . . . . . . 27
3.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.2 Architecture de l’Informatique décisionnelles . . . . 28
3.2.3 ETL « Extraction-Transformation-Chargement » . . 29
3.3 Entrepôt de données « Data warehouse » . . . . . . . . . . 32
3.3.1 Caractéristique d’un entrepôt de données . . . . . . . 32
3.3.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.3 Magasin de données « DataMarts » . . . . . . . . . . 35
3.3.4 Modélisation multidimensionnelle . . . . . . . . . . . 38
3.3.5 Type de modèle dimensionnel . . . . . . . . . . . . . 41
3.4 Restitution des données . . . . . . . . . . . . . . . . . . . . 44
3.4.1 Le reporting . . . . . . . . . . . . . . . . . . . . . . 45
3.4.2 Tableau de bord (Dashboard) . . . . . . . . . . . . . 46
3.4.3 Fouille de donné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 Étude détaillée des cas d’utilisation . . . . . . . . . . . . . . 55
4.2.1 Raffinement du cas d’utilisation « Gérer ETL » . . . 55
4.2.2 Raffinement du cas d’utilisation «Créer transforma-
tions» . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.3 Raffinement du cas d’utilisation « Analyser les don-
nées » . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.4 Raffinement du cas d’utilisation « Créer Cube » . . 59

ii
TABLE DES MATIÈRES

4.2.5 Raffinement du cas d’utilisation « Gérer rapports » 60


4.3 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . 61
4.4 Conception de l’entrepôt de données . . . . . . . . . . . . . 62
4.4.1 Les dimensions . . . . . . . . . . . . . . . . . . . . . 63
4.4.2 Les dimensions communes . . . . . . . . . . . . . . . 78
4.4.3 Sujet d’analyse : Gérer effectifs . . . . . . . . . . . . 80
4.4.4 Sujet d’analyse : Gérer Absentéisme . . . . . . . . . 82
4.4.5 Sujet d’analyse : Gérer Retard . . . . . . . . . . . . 84
4.4.6 Sujet d’analyse : Gérer Salaire . . . . . . . . . . . . 86
4.4.7 Sujet d’analyse : Gérer Sanction . . . . . . . . . . . 88
4.4.8 Sujet d’analyse : Gérer Crédit . . . . . . . . . . . . . 90
4.4.9 Sujet d’analyse : Gérer Assurance . . . . . . . . . . 92
4.5 Conception ETL . . . . . . . . . . . . . . . . . . . . . . . . 94
4.5.1 É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 déploiement . . . . . . . . . . . . . . . . . . . 100
4.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5 Présentation des outils utilisées Et Réalisation 103


5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . 104
5.2.1 Environnement matériel . . . . . . . . . . . . . . . . 104
5.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . 104
5.3 Architecture globale d’application . . . . . . . . . . . . . . . 110
5.4 Réalisation du processus ETL . . . . . . . . . . . . . . . . . 111
5.4.1 Composants kettle utilisés . . . . . . . . . . . . . . . 112
5.4.2 Connexions aux bases de données source . . . . . . . 115
5.4.3 Alimentation de l’entrepôt de données . . . . . . . . 115
5.5 Réalisation de la restitution . . . . . . . . . . . . . . . . . . 122
5.5.1 Réalisation du cube OLAP . . . . . . . . . . . . . . . 122
5.5.2 Réalisation des Rapports . . . . . . . . . . . . . . . . 127
5.6 Interfaces de l’application . . . . . . . . . . . . . . . . . . . 129
5.6.1 Interface « Authentification » . . . . . . . . . . . . . 130

iii
TABLE DES MATIÈRES

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 cré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 générale d’un système décisionnel . . . . . . . . 28
3.2 Sché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 modèle en étoile . . . . . . . . . . . . . . . . 42
3.6 Structure d’un modèle en flocon . . . . . . . . . . . . . . . . 43
3.7 Exemple d’opération sur un cube OLAP . . . . . . . . . . . 52
4.1 Raffinement de cas d’utilisation ” Gérer ETL” . . . . . . . . 56
4.2 Raffinement de cas d’utilisation ” créer transformation ” . . . 57
4.3 Raffinement des cas d’utilisation ” Analyser les données ” . . 58
4.4 Raffinement de cas d’utilisation ” Créer cube ” . . . . . . . . 59
4.5 Raffinement de cas d’utilisation ” Gérer rapports ” . . . . . . 60
4.6 Diagramme de séquence ” Authentification ” . . . . . . . . . 61
4.7 Modèle en étoile ” Fait-personnel ” . . . . . . . . . . . . . . 81
4.8 Modèle en étoile ” Fait-Absence ” . . . . . . . . . . . . . . . 83
4.9 Modèle en étoile ” Fait-Retard ” . . . . . . . . . . . . . . . . 85
4.10 Modèle en étoile ” Fait-Paie ” . . . . . . . . . . . . . . . . . 87

v
TABLE DES FIGURES

4.11 Modèle en étoile ” Fait-Sanction ” . . . . . . . . . . . . . . . 89


4.12 Modèle en étoile ” Fait-Crédit ” . . . . . . . . . . . . . . . . 91
4.13 Modèle en étoile ” Fait-Assurance ” . . . . . . . . . . . . . . 93
4.14 Base de données source . . . . . . . . . . . . . . . . . . . . . 96
4.15 Modélisation des cubes dimensionnels . . . . . . . . . . . . . 99
4.16 Diagramme de dé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 dé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 Crédit . . . . . . . . . . . . . . . . . . 121
5.16 Alimentation du Fait Assurance . . . . . . . . . . . . . . . . 121
5.17 Créer cube ”Fait personnel” . . . . . . . . . . . . . . . . . . 123
5.18 Mise en page du tableau de bord ’Suivi personnel’ . . . . . 125
5.19 Personnaliser de la source de donné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 requête MDX . . . . . . . . . . . . . . . . . 126
5.22 Aperç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 crédit » . . . . . . . . . . . . . . . . . . 137
5.33 Interface « Report de Suivi de cré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 synthèse des méthodologies [2] . . . . . . . . . . 13


3.1 Tableau comparatif entre datawarehouse et datamart . . . . 36
3.2 Tableau Comparatif entre les bases de données de l’entreprise 37
3.3 Tableau comparatif entre OLTP et OLAP . . . . . . . . . . 49
3.4 Tableau comparatif des serveurs OLAP . . . . . . . . . . . . 51
4.1 Dé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 ” Ancienneté ” . . . 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 gé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 ” Collége ” . . . . . 72
4.11 Description des colonnes de la dimension ” Fonction ” . . . . 72
4.12 Description des colonnes de la dimension ” Filiére ” . . . . . 73
4.13 Description des colonnes de la dimension ” Diplôme ” . . . . 73
4.14 Description des colonnes de la dimension ” Niveau d’é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 crédit ” . . . 76
4.20 Description des colonnes de la dimension ” indemnité ” . . . 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 Dé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 Crédit . . . . . . . . 90
4.31 Description des mesures de la table fait Assurance . . . . . . 92

ix
INTRODUCTION

Face à la mondialisation, la progression des systèmes et des technolo-

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

trouvent confrontées à des environnements de plus en plus complexes et

compétitifs dans lesquels le pilotage et la prise de décision impliquent des

choix qui doivent être faits dans des temps très courts tout en prenant

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

décision dans les entreprises devient donc une préoccupation de première

importance.

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

bitation(AFH) a besoin de certaines améliorations pour la bonne gestion

de ressources humaines. La problématique observée dans des diérents diag-

1
nostics est que les dirigeants rencontrent des problèmes de blocage ou de

dysfonctionnement au niveau des départements sous leurs responsabilités

à cause de fausse génération de quelques statistiques. Ajoutons à ceci, la

grande quantité de données traitée régulièrement dans l’entreprise est dicile

d’être utilisée par les décideurs seuls.

Comme l’ensemble de données manipulées par les outils sont très abon-

dantes et éparpillées dans diérents systèmes hétérogènes et non ordonnées

dans un aspect décisionnel adéquat pour les statistiques, il est donc né-

cessaire de fusionner les données et de les arranger dans un entrepôt de

données dans le but de les rendre convenables pour l’analyse et la création

des rapports qui peuvent servir à la prise de décision.

C’est dans ce contexte que s’insère notre projet de n d’études intitulé «

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

» consiste à concevoir et développer une solution décisionnelle pour le dé-

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

des données, de développer des cubes OLAP pour admettre une analyse

2
multidimensionnelle et de créer un portail de reporting.

Ce présent rapport comporte les cinq chapitres suivants :

— Le premier chapitre présente le cadre général du projet en citant les

grandes lignes du travail demandé et le processus de développement

que nous avons adoptés tout au long de la réalisation.

— Le deuxième chapitre est consacré à l’étude de l’existant, la spéciDe-

clareUnicodeCharacterfication et l’analyse des besoins.

— Le troisième vise à présenter et à déDeclareUnicodeCharacterfinir les

différents concepts des technologies décisionnelles servant de support

à nos travaux.

— Le quatrième chapitre est destiné à la conception détaillée de notre

entrepôt de données.

— Le cinquième chapitre présente l’environnement de travail et les dié-

rentes tâches réalisées.

Nous clôturons ce rapport par une conclusion générale qui rappellera le

contexte de notre travail élaboré ainsi que l’approche proposée et de citer

les perspectives du projet.

3
CHAPITRE 1

CADRE GÉNÉRAL DU PROJET

1.1 Introduction

Dans ce chapitre, nous allons présenter le cadre général de noter projet

de fin d’étude, qui s’est déroulé au sein de l’Agence Foncière d’Habitation

« AFH ». Dans un premier temps, nous présentons l’organisme d’accueil

de l’AFH suivie par le contexte, les objectifs et la planification de notre

projet, finalement une étude du systè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 préparation du Projet de Fin

d’Etudes (PFE) au sein de la faculté des sciences économiques et de gestion

de Tunis El-Manar (FSEGT). Il consiste à concevoir et mettre en place un

système d’information décisionnel qui met en pratique les connaissances

acquises durant notre formation tout en apprenant à s’intégrer dans la vie

professionnelle, de faire face aux diérentes situations et problématiques tout

en inspirant les solutions les plus adéquates. Le secteur de notre projet est

la direction des ressources humaines de de l’Agence Foncière d’Habitation

« AFH ».

1.3 Présentation de l’organisme d’accueil

1.3.1 Historique

L’Agence Foncière d’Habitation « AFH » est une entreprise publique,

dotée de la personnalité civile et de l’autonomie financière.

Elle est chargée de produire des lotissements aménagés et de contribuer à

la création d’un environnement urbain sain et harmonieux. Elle participe

5
aussi, par son approche globale, à la création de villes modernes, adaptées

aux mutations culturelles et économiques vécues en Tunisie et à travers le

monde [1]

Par son engagement, l’A.F.H a réussi à :

— Mettre en œuvre les orientations nationales en matière d’habitat et

d’urbanisme.

— Créer les conditions les plus favorables pour améliorer l’état du secteur

du logement et favoriser l’essor des activités économiques qui lui sont

directement ou indirectement attachées.

1.3.2 Objectif de l’organisme

En cré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’aménagement du territoire tournée vers l’avenir.

D’une manière concrète, l’Agence vise à réussir les missions suivantes :

— Fournir aux secteurs de l’habitat et de l’urbanisme les terrains aména-

6
gés dont ils ont besoin pour faire face à la demande publique et privée,

en veillant particulièrement à la réduction des coûts de production.

— Assurer un environnement urbain de qualité qui répond au souci des

pouvoirs publics de moderniser les villes tunisiennes et de les adap-

ter aux mutations économiques, culturelles et sociales que connaı̂t le

monde actuellement.

— Favoriser l’accès au logement à toutes les catégories de la population

et particulièrement aux ménages à faibles et moyens revenus.

— Soutenir l’effort des municipalités dans la réalisation de leurs projets

urbains en mettant en place les infrastructures primaires et secon-

daires nécessaires.

— Participer à l’effort national de maintien des populations dans leur

zone d’origine par la réalisation de projets décentralisés au moindre

coût.

— Compléter l’action publique de lutte contre l’habitat anarchique en

mettant en œuvre des programmes de relogement approprié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 Problématique

Ces dernières années étaient marqué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 accélérer du travail.

Pour résoudre ce problème, l’AFH voit nécessaire de la modernisation de

son système d’information.

En fait, l’agence doit être capable de transformer et de collecter ses don-

nées éparpillées dans les différents systèmes opérationnels, en informations

susceptibles de fournir une idée claire aux gestionnaires sur la performance

des ressources humaines. Ces informations bien structurées facilitent la prise

des décisions adéquates pour corriger les faiblesses constatées.

1.5 Motivations

Ce projet a pour but la mise en place d’un système d’information d’aide

à la décision qui permet de pallier les insuffisances dues à l’exploitation

des bases de données opérationnelle an d’avoir une vue globale sur la per-

9
formance des ressources humaines de l’entreprise et de permettre aux déci-

deurs de prendre de bonnes décisions aux bons moments. Pour cette raison,

l’entreprise doit disposer d’un entrepôt de données qui centralise les infor-

mations de qualité et des outils des restitutions pour présenter les données

d’une façon able et cohérente an de minimiser le coût d’élaboration de rap-

port en termes de temps et d’argent.

1.6 Méthodologie adoptée

Une méthodologie de développement est un cadre utilisé pour structurer,

planifier et contrôler le développement d’une application.

Parmi ces méthodologies :

— Méthodologie lourde / Le processus unifié (UP) :

— RUP : Rational Unified Process

— 2TUP : Two Truck Unified Process

— Méthodologie agile

— XP : eXtreme Programming

— SCrum

10
Nous présentons dans le tableau suivant une comparaison entre les diffé-

rentes méthodes existantes, les points forts et les points faibles de chacune.

Méthodologie Description Points forts Points faibles

Cascade -Propose de dérou- -Distingue claire- -Non itératif.

ler les phases de ment les phases du -Pas de modèles

projet d’une ma- projet. pour les docu-

nière séquentielle. ments.

RUP -Le RUP est à la -Itératif. -Vision non évi-

(Rational fois une méthodolo- -Propose des mo- dente ni immé-

Unified gie et un outil prêt dèles de docu- diate.

Process) à l’emploi. ments, et des -Très axé processus

-Cible des projets canevas pour des -Coûteux à person-

de plus de 10 per- projets types. naliser.

sonnes. -une évolution -Assez flou dans sa

n’impacte qu’une mise en œuvre.

itération et non

forcément tout le

logiciel.

11
2TUP -Propose un cycle -Itératif. -Ne propose pas

(Two Truck de développement -Définit les profils des documents

Unified en Y des intervenants, types.

Process) -Cible des projets les plannings, les -Plutôt superficiel

de toutes tailles. prototypes. sur les phases si-

-S’articule autour -Consacre une tuées en amont

de l’architecture. large place à la et en aval du

technologie et à la développement.

gestion des risques.

Scrum -Se base sur des -Donne toute -La mise en oeuvre

itérations dites spi- confiance aux dé- du développement

rales de développe- veloppeurs et les n’est pas précisée.

ment. laisser faire leur -Le développement

travail. rapide et répétitif

-Chaque itération se traduit par une

a un objectif bien forte pression.

précis et fournit

une fonctionnalité

testée.

12
XP -Ensemble de « -Itératif. -Assez flou dans sa

(eXtreme bests practices» de -Donne une impor- mise en œuvre.

Programming) développement. tance aux aspects

-Cible des projets techniques.

de moins de 10

personnes.

Table 1.1 – Tableau de synthèse des méthodologies [2]

Le processus de développement utilisé dans notre travail est le proces-

sus 2TUP. En effet, 2TUP donne une grande importance à la technologie

technique, ce qui est important pour notre projet.

13
Figure 1.2 – Organigramme de l’AFH

La méthodologie 2TUP (Two Truck Unified Process) est composée es-

sentiellement de trois étapes :

— La branche fonctionnelle : capitalise la connaissance du métier de

l’entreprise.

Cette branche comporte les étapes suivantes :

— La capture des besoins fonctionnels. Cette étape élimine le risque

14
d’avoir un système inadapté aux besoins des utilisateurs.

— La capture des besoins non fonctionnels.

— L’analyse qui consiste à étudier les besoins fonctionnels de manière

à obtenir une idée de ce que va réaliser le système en terme métier.

— La branche technique : capitalise un savoir-faire technique et/ou

des contraintes techniques.

Cette branche comporte les étapes suivantes :

— La capture des besoins techniques.

— La conception générique.

— La branche réalisation : consiste à réunir les deux branches, per-

mettant de mener une conception applicative et enfin la livraison

d’une solution adaptée aux besoins.

Cette branche comporte les étapes suivantes :

— La conception préliminaire

— La conception détaillée

— Le codage

— L’intégration

15
1.7 Planification du projet

Afin de mieux organiser notre projet, nous avons présenté sous forme

de diagramme de Gantt l’ensemble des tâches ainsi leurs durées, tout en

respectant la méthode adoptée pour la réalisation du projet.

Figure 1.3 – Organigramme de Gantt

1.8 Conclusion

A travers ce premier chapitre, nous avons présenté le cadre général du

projet, par la suite nous avons introduit la problématique, et les objectifs

à atteindre et nous terminons par présenter le processus de développement

adapté pour la réalisation de notre projet. Dans le chapitre suivant, nous

passons à l’étude et l’analyse des besoins.

16
CHAPITRE 2

SPÉCICATION ET ANALYSE DES BESOINS

2.1 Introduction

Un système décisionnel est un projet qui demande une étude bien spé-

ciée sur les besoins de l’entreprise. Au niveau de ce chapitre, nous allons

présenter notre étude et critique de l’existant puis nous allons spécier les

besoins fonctionnels, non fonctionnels et les diagrammes nécessaires pour

l’analyse.

17
2.2 Etude de l’existant

L’étude de l’existant consiste à comprendre et à analyser la situation

actuelle de l’entreprise afin des dégager ses insuffisances.

2.2.1 Pré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 données GRH existante.

Dans l’AFH, l’ensemble des données liées à la gestion des métiers sont

stockées dans une base de données relationnelle qui permet la collecte et

l’exploitation de ces données.

2.2.2 Critique de l’existant

Il est important de mentionner que l’AFH ne dispose d’aucun système

d’aide à la décision automatique ou semi-automatique. En plus, tout pro-

cessus d’analyse et de prise de décision est basé nécessairement sur des

rapports créés manuellement dans des chiers Excel dont les données sont

extraites de façon manuelle, c’est pourquoi la prise de décision exige une

durée très longue dans la collecte des informations et leur sélection à chaque

18
prise de décision.

Un autre problème se présente lors de la phase d’analyse est la complexité

les requêtes utilisées qui contiennent plusieurs jointures et fonctions d’agré-

gations, donc l’exécution dans un système transactionnel peut engendrer

un temps considérable dans le serveur de données.

2.3 Spécification des besoins

Pour bien répondre aux exigences des utilisateurs, le systè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 à mettre en place

un système d’information décisionnel permettant d’analyser la gestion res-

sources humaines. En d’autres termes les principaux besoins sont les sui-

vant :

— Analyse des données

— Gestion d’un entrepôt de données uniforme :

— Extraction des données : Les données vont alimenter notre DA-

19
TAWERHOUSE sont d’origine diverses. En effet, les données pro-

viennent à partir de bases de données différentes.

— Transformation des données extraites.

— Chargement des informations dans un entrepôt des données qui se

lance périodiquement.

— Gestion des utilisateurs

— Génération d’un tableau de bord qui permet de visualiser :

— Avoir la répartition de personnels selon des critères différents (par

affectation géographique, par fonction, par collège, par filière, par

niveau, par genre . . . ).

— La répartition de l’absence par affectation géographique, par genre,

par nature d’absence, par nombre de jours, par collège, par genre. . .

— L’évolution de la paie selon des critères différents (affectation géo-

graphique, par année, par mois, par collège, par type indem . . . ).

— Le suivie de sanction selon des critères différents (affectation géo-

graphique, par année, par mois, par collège, . . . ).

— Le suivie d’assurance selon des critères différents (type assurance,

affectation géographique, par année, par mois, par collège, . . . ).

20
— Le suivie de crédit selon des critères différents (type crédit, affec-

tation géographique, par année, par mois, par collège, . . . ).

2.3.2 Besoins non fonctionnels

Outre les fonctionnalités essentielles, notre application doit respecter

certaines contraintes et répondre à certains besoins non fonctionnels :

— Sécurité : L’accès au tableau de bord ainsi que le chargement de

l’entrepôt de données bien sécurisé.

— Rapidité : L’accès à la base de données doit être souple et rapide. Il

est impérativement nécessaire que la durée d’extraction et du charge-

ment des données s’approche le plus possible du temps réel.

— Fiabilité : les rapports générés doivent être bien précis et basés sur

des données exactes.

— Performance : Le tableau de bord doit être fournir des indicateurs

essentiels et pertinentes pour une prise de décision.

— Aptitude à la maintenance : L’application doit être facile à main-

tenir, ainsi que le code de l’application doit être lisible et compréhen-

sible.

21
— Ergonomie : le système doit être adapté aux standards d’ergonomie

telle que la densité modérée sur l’écran.

— Qualité : Facilitation de l’accès aux données et de la diffusion de

l’information. Interaction homme machine la plus intuitive possible.

2.4 Modélisation dynamique

La modélisation dynamique d’un système consiste à décrire son compor-

tement lors-consiste à décrire son comportement lors de sa réaction à 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 dénombrer les grandes fonctionnalités du système.

22
Figure 2.1 – Diagramme de cas d’utilisation global

23
2.4.2 Identification des acteurs :

Elle consiste à déterminer les différents acteurs qui vont interagir de près

ou de loin avec le système.

Un acteur : est toute entité qui interagit avec notre système dans le but

de réaliser une plus value et qui a toujours le même comportement.

— Administrateur : C’est l’administrateur de la base de production :

permet de gérer le processus d’extraction, transformation et charge-

ment des données, la création des rapports et la gestion des accès au

serveur de reporting.

— Utilisateur / Décideur : Interagit directement avec le tableau de

bord ainsi que la consultation des rapports précédemment crées par

l’administrateur.

24
2.5 Conclusion

Dans ce chapitre, nous avons étudié les différents besoins fonctionnels

et non fonctionnels exprimés par l’AFH. Cela nous a permis de découvrir

le diagramme des cas d’utilisation global. Cette étude sera la base de la

conception que nous allons entamer dans le chapitre suivant.

Enfin, il nous reste à élaborer une bonne conception afin d’assurer le bon

fonctionnement du système.

25
CHAPITRE 3

ÉTAT DE L’ART

3.1 Introduction

Avec la généralisation de l’informatique, qui touche sans exception, toutes

les activités et les secteurs, les entreprises manipulent une masse colossale

de données stockées dans différentes sources. La difficulté n’est plus de la

recueillir, mais de la rendre disponible sous la bonne forme, au bon moment

et à la bonne personne, qui saura l’exploiter et en tirer de la valeur ajoutée.

Pour cette raison, un système d’information décisionnel s’avère indispen-

sable dans les entreprises.

26
Dans ce chapitre, l’objet est de définir les concepts fondamentaux relatifs

aux systèmes décisionnels.

3.2 Informatique décisionnelles

L’informatique décisionnelle (en anglais : business intelligence ou BI) est

l’informatique à l’usage des décideurs et des dirigeants d’entreprises.

3.2.1 Définition

L’informatique décisionnelle exploite les données d’une entreprise à l’aide

des moyens, des outils et des méthodes qui permettent de les collecter,

consolider, modéliser et restituer dans le but d’offrir une vue d’ensemble de

l’activité traitée pour faciliter la prise de décision.

Parmi les différentes définitions du décisionnel, données on trouve :

« Le Décisionnel est le processus visant à transformer les données en in-

formations et, par l’intermé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 décisionnelles

La chaine décisionnelle peut être représentée en trois processus général :

ETL, organisation des données et restitution.

Figure 3.1 – Architecture générale d’un système décisionnel

— ETL entre les sources de données et l’entrepôt. Ce processus est res-

ponsable la récupération des données des diverses sources et l’extrac-

tion de l’information qui nous intéresse, la transformation (nettoyage,

filtrage,...), puis l’alimentation d’un entrepôt de données.

— L’entrepôt de données, c’est le processus de stockage, il est res-

28
ponsable de structurer les données par rapport à leur niveau de gra-

nularité (agrégats). Les datamarts, considérés comme des bases de

données métier, sont en fait extraites des entrepôts de données.

— La restitution et dernier niveau fournit à l’utilisateur afin d’arriver

à l’analyse des données selon des outils décisionnels variés comme

des outils de Reporting, des outils de tableau de bord, des outils des

balanced Scorecard ou des outils de fouille de données (data mining).

3.2.3 ETL « Extraction-Transformation-Chargement »

La première phase des projets décisionnels, collecte et prépare les don-

né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’entrepôt de données, basé

sur le principe de méta base permettent d’effectuer des synchronisations

massives d’information d’une source de donné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 entrepôt de données, qui représente une part majeure des traite-

ments et nécessite une attention régulière tout au long de cycle de vie du

système.

Selon Kimball :70% de l’effort consacré à un projet de business intelligence

est dépensé dans l’ETL. [Kimball, 2004] 3

Figure 3.2 – Schéma de fonctionnement d’un ETL

Cette alimentation se déroule en 3 phases :

— Extraction des données (Extract) :Assure la connexion à la ma-

jorité des systèmes de stockage de données afin de récupérer et inter-


3. R. Kimball et J. Caserta ; « The Data warehouse ETL Toolkit» ;Wiley Publishing, INC 2004

30
préter les données, identifier, sélectionnées et copier dans la zone de

préparation afin de la manipulations ultérieures .

— Transformation des données (Transform) : C’est la deuxième

étape du processus ETL, elle est très important de consolider et assu-

rer la fiabilité des données et leurs granularités. Après l’extraction, les

données doivent être vérifiées, reformatées et nettoyées afin d’élimi-

ner les valeurs incohérents, compléter et renseigner les valeurs man-

quantes pour garantir leurs abélites et leur qualités.

— Chargement des données (Load) : Chargement des données

(Load) : c’est la dernière phase et la plus délicate surtout lorsque

les volumes sont importants, dans lequel se déroule le stockage de

données dans l’entrepôt afin d’être utilisable par les autres outils du

système BI.

C’est 3 processus assurent l’alimentation de notre Datawarehouse en don-

nées homogènes, propres et fiables.

31
3.3 Entrepôt de données « Data warehouse »

Le Data warehouse est le point de stockage de toutes les données utili-

sées par le système pour analyser les informations. Il assure dans un premier

temps une étanchéité entre le système opérationnel et le système décision-

nel.

3.3.1 Caractéristique d’un entrepôt de données

« Une collection des données orientées sujet, intégrées, non volatiles et

historiées, organisées pour le support d’un processus d’aide à la décision ».

[Inmon 1992] 4

Selon Bill Inmon la collection de données doit être intégrées, orientées

sujet, non volatiles, historiées, résumées et disponibles pour la prise de dé-

cisions.

— Données orientées sujet «métiers» : Les données stockées doivent

être réorganisées autour de thèmes par activités majeures à l’inverse

des systèmes sources où les données sont plutôt structurées par pro-

4. Developing the Data Warehouse. With Chuck Kelley, QED, 1992

32
cessus fonctionnel.

Un sujet pourra ensuite être utilisé dans différentes analyses.

— Données intégrées : Les données proviennent de différentes sources

hétérogènes. L’intégration consiste à résoudre les problèmes d’hété-

rogénéité des systèmes de stockage, des modèles de données, de sé-

mantique de données, l’intégration permet d’avoir la cohérence de

l’information, c’est-à-dire stockées sous le même format, au travers

d’un référentiel d’entreprise.

— Données non volatiles : À la différence des données opérationnelles,

celles de l’entrepôt sont permanentes le rafraı̂chissement de l’entrepôt

consiste à ajouter de nouvelles données, sans modifier ou perdre celles

qui existent.

— historiées : La prise en compte de l’évolution des données est essen-

tielle pour la prise de décision qui utilise des techniques de prédiction

en s’appuyant sur les évolutions passées pour prévoir les évolutions

futures.

Dans un Data Warehouse chaque valeur est associée à un moment.

« Every key structure in the data warehouse contains - implicitly or

33
explicitly -an element of time ». [Inmon, 2000] 5

— Résumées : Les informations issues des sources de données doivent

être agrégées et réorganisées afin de faciliter le processus de prise de

décision.

— Organisées pour le support d’un processus d’aide à la déci-

sion : Les données sont organisées de manière à permettre l’exécution

des processus d’aide à la décision (Reporting, Data Mining. . . ).

5. B. Inmon ; What is a Data Warehouse ; [Document électronique] ; 2000

34
3.3.2 Objectifs

— Accès aux informations de l’entreprise.

— Les informations d’un entrepôt de données sont cohérentes.

— Les outils de présentation d’informations font partie du Data ware-

house.

— Les données publiées sont stockées dans le Data warehouse.

— Qualité de l’information d’un Data warehouse.

3.3.3 Magasin de données « DataMarts »

Un datamart (magasin de données ou comptoir de données) est une vue

partielle du data warehouse mais orientée métier. De ce fait ils suivent les

mêmes principes que celui-ci, leur différence se situe sur le fait qu’un Data-

mart va répondre à un besoin métier plus spécifique que le Data warehouse.

« Le DataMart est un sous-ensemble du Data Warehouse, constitué de

tables au niveau détail et à des niveaux plus agrégés, permettant de res-

tituer tout le spectre d’une activité mé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.

Détient des informations très dé- Peut contenir plus de données

taillées. résumées (bien que beaucoup

contiennent des détails complets).

Fonctionne pour intégrer toutes les Se concentre sur l’intégration d’in-

sources de données. formations provenant d’un domaine

donné ou d’un ensemble de systèmes

sources.

N’utilise pas nécessairement un mo- Est construit centré sur un modèle

dèle dimensionnel mais nourrit des dimensionnel utilisant un schéma en

modèles dimensionnels. étoile.

Table 3.1 – Tableau comparatif entre datawarehouse et datamart

36
Caractéristique BD de production Datawarehouse DataMart

Opération Gestion courante, Référentiel, ana- Analyse récur-

production lyse ponctuelle rente, outil de

pilotage, support à

la décision

Modèle de Entité/relation Etoile, flocon, Etoile, flocon

données constellation

Normalisation fréquente maximum Rare (redondance

d’information)

Données Actuelles, brutes, Historisées, dé- Historisées, agré-

détaillées taillées gées

Mise à jour Immédiate, temps Souvent différée, Souvent différée,

réel périodique périodique

Niveau de faible faible élevé

consolidation

Perception verticale transverse Horizontale

Operations Lecture, insertion, Lecture, insertion, Lecture, insertion,

mise à jour, sup- mise à jour mise à jour, sup-

pressions pressions

Taille En gigaoctet En téraoctets En gigaoctet

Table 3.2 – Tableau Comparatif entre les bases de données de l’entreprise

37
3.3.4 Modélisation multidimensionnelle

La modélisation dimensionnelle est la méthode de conception logique

qui vise à présenter les données sous une forme standardisée intuitive et qui

permet des accès hautement performants. Elle structure les données d’une

façon très différente de la structure en 3FN (3ème forme normale) fréquem-

ment utilisée par les modélisateurs des systèmes OLTP. La modélisation

dimensionnelle produit ce qu’on appelle le Modèle multidimensionnel, qui

se compose d’une table contenant une clé multiple, la table des faits, et

d’un ensemble de tables nommées tables dimensionnelles.

a. Table des faits

Les « faits », sont les données observables que l’on possède sur un sujet

et que l’on veut étudier, sont ce sur quoi va porter l’analyse. Ce sont des

tables qui contiennent des informations opérationnelles et qui relatent la

vie de l’entreprise. Un fait est tout ce qu’on voudra analyser.

Les« faits » dans un entrepôt de données sont généralement des valeurs nu-

mériques, additives. Une table de faits assure les liens plusieurs à plusieurs

entre les dimensions. Elle comporte des clés étrangères, qui ne sont autres

38
que les clés primaires des tables de dimension et l’ensemble des mesures cor-

respondant aux informations de l’activité à analyser. Mais rappelons que

certaines tables de faits peuvent contenir aucun attribut et repré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 étudier des données ob-

servables qui, soumises à une analyse multidimensionnelle, donnent aux

utilisateurs des renseignements nécessaires à la prise de décision. On ap-

39
pelle donc dimension un axe d’analyse.

Une dimension est généralement constituée : d’une clé artificielle, une clé

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 décimal, structuré

par des dimensions.

d. Les attributs

Les attributs sont généralement des champs textuels qui décrivent une ca-

ractéristique d’un élément tangible. Par exemple, les descriptions d’un pro-

duit.

40
3.3.5 Type de modèle dimensionnel

Il existe 3 modèles dimensionnels : modèle en étoile, modèle en flocon et

modèle en constellation.

a. Modèle en Etoile

Ce type de modèle, initié par Ralph Kimball, est traditionnellement repré-

senté 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 décrite par une seule table dont les attributs peuvent représenter toutes

les granularités possibles.

La table située au centre de l’étoile est la table des faits ou mesures (ou

encore métriques) : ce sont les éléments mesurés dans l’analyse, les tables

situées aux extrémités de l’étoile sont les tables de dimensions (ou encore

axes d’analyse) ou niveaux de suivi. Ce sont les dimensions explorées dans

l’analyse.

41
Figure 3.5 – Structure d’un modèle en étoile

— Avantages :

— Facilité de navigation.

— Performances : nombre de jointures limité, gestion des données

creuses.

— Inconvénients :

— Toutes les dimensions ne concernent pas les mesures.

— Redondances dans les dimensions.

— Alimentation complexe.

42
b. Modèle en flocon

Le modèle en flocon est de même principe que le modèle en étoile, mais de

plus en plus les dimensions sont décomposées, une plus grande hiérarchisa-

tion de ces dimensions.

Dans ce modèle, uniquement le premier niveau de granularité est directe-

ment en lien avec la table de faits.

Figure 3.6 – Structure d’un modèle en flocon

— Avantages :

— Réduction de volume.

— Formaliser une hiérarchie au sein d’une dimension.

— maintenance des tables de dimensions simplifiée

43
— Evite les redondances.

— Inconvénients :

— Navigation difficiles.

— Nombreuses jointures.

— Une plus grande complexité en termes de lisibilité et de gestion.

— Schéma moins intuitif aux utilisateurs d’affaires.

c. Modèle en constellation

Ce modèle est un ensemble de schémas en étoile et /ou en flocons. Il s’agit

du fusionner plusieurs modèle qui utilisent des dimensions communes.

— Avantage :

— Meilleure gestion des donnés creuses.

— Inconvénient :

— Complexité du modèle.

3.4 Restitution des données

Cette dernière étape, dernier niveau fournit à l’utilisateur, également

appelée «outils end-users», se charge de présenter les informations à valeur

ajoutée de telle sorte qu’elles apparaissent de la façon la plus lisible possible

44
dans le cadre de l’aide à la décision.

Les données sont principalement modélisées par des représentations à base

de requêtes afin de constituer des tableaux de bord, des rapports ou des

fouilles de données via des outils d’analyse décisionnelle.

3.4.1 Le reporting

Le reporting, une famille d’outils de Business intelligence, est l’opéra-

tion consistant, pour une entreprise, à faire rapport de son activité. C’est

la présentation périodique destinée à assurer la réalisation, la publication

et la diffusion de rapports et bilans analytiques sur les activités et résultats

d’une organisation, d’une unité de travail ou du responsable d’une fonction,

selon un format prédéterminé. Ils sont essentiellement destinés à faciliter la

communication de résultats chiffrés ou d’un suivi d’avancement.

Les bases de données sont interrogées selon les requêtes SQL préparées lors

de l’élaboration du modèle. Le rapport peut ensuite être diffusé sur l’In-

tranet, périodiquement en automatique ou ponctuellement à la demande.

L’outil d’élaboration du modèle du rapport offre bien entendu des fonctions

spécifiques de calcul et de présentation (graphiques) afin de concevoir des

45
comptes rendus particuliè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 activités dans le cadre d’une démarche de progrès. Cet

instrument contribue à réduire l’incertitude et facilite la prise de risque

inhérente à toutes décisions.

« Le tableau de bord correspond à un système d’information permettant

de connaı̂tre, le plus rapidement possible, les données indispensables pour

contrôler la marché de l’entreprise à court terme et faciliter dans celle-ci

l’exercice des responsabilités ». [Michel Gervais, 2005] 6

3.4.3 Fouille de données (Datamining)

Data Mining forage de données, explorations de données ou fouilles de

données regroupe des méthodes d’intelligence artificielle, d’apprentissage

mécanique et statistique permet d’explorer et d’analyser une masse impor-

tante de données depuis différentes perspectives et le fait de transformer

6. Contrôle de Gestion ;8ème Edition ; 2005

46
ces données en informations utiles, en établissant des relations entre les

données ou en repérant des patterns. Le Data Mining permet donc, grâce à

un certain nombre de techniques, de découvrir ces connaissances en faisant

apparaı̂tre des corrélations entre ces données.

« Data Mining est le processus non trivial permettant d’identifier des mo-

dèles valides, nouveaux, potentiellement utiles et finalement compréhen-

sibles dans les données ». [U.M.Fayyad, G.Piatetski-Shapiro ] 7

3.4.4 On-Line Analytical Processing OLAP

a. Définition

Les Cubes OLAP (On-Line Analytical Processing) c’est une technologie

permettent une représentation multidimensionnelle de l’information et le

calcul de mesures agrégées pour offrir un accès rapide aux données en vue

d’une analyse, dans le but de répondre aux besoins de Reporting et d’ana-

lyse.

Chaque dimension a la possibilité d’être hiérarchisée en fonction des besoins

de l’utilisateur.

«Activité globale de requêtage et de présentation de données textuelles et nu-


7. From Data mining to Knowledge Discovery in Databases

47
mériques contenues dans l’entrepôt de données ; Style d’interrogation spé-

cifiquement dimensionnel.» [Kimball, 2005] 8

b. Différence entre OLAP et OLTP

L’OLTP (On-Line Transaction Processing) est un traitement transactionnel

en ligne qui sert à insérer, modifier et interroger d’informations en temps

réel alors qu’OLAP est caractérise par un volume relativement petit de

transactions, mais sur un volume très important de données. Les requêtes

sont très complexes et impliquent de nombreuses agrégations.

Les SGBD au sein de l’AFH permettent de contrôler et d’exécuter les tâches

métier fondamentales et fréquentes via leurs données sources opération-

nelles, alors que ce modèle(OLTP) est incapable d’aider à planifier prendre

des décisions d’ordre stratégiques qui touches des axes hétérogènes, d’où la

nécessité d’un modèle OLAP.

8. Guide de conduite de projet , 1ère Edition ;Paris, France ;Eyrolles ;Mars 2005.

48
Caractéristiques Processus OLAP Processus OLTP

Objectifs Interrogation Mise à jour

Nature de données Individuelles Multidimensionnelles,

agrégées, orientées

utilisateur)

Fraı̂cheur de données Récentes, dynamique Historiques, statique

Traitement Simple Complexe, semi-

automatique

Utilisateurs Tout type Décideurs

Temps de réponse rapide Moins rapide

Table 3.3 – Tableau comparatif entre OLTP et OLAP

c. Architecture des serveurs OLAP

Le noyau d’un système OLAP est son serveur. Ces serveurs sont classés

selon la politique régissant l’architecture du serveur. Ainsi, ces architectures

peuvent être distinguées comme suit :

— Les systèmes à architecture MOLAP : Ces systèmes MOLAP

« Multidimentional On-line Analytical Processing » sont conçus ex-

ceptionnellement pour l’analyse multidimensionnelle.

« Ensemble d’interfaces utilisateur, d’applications et de technologies

49
de bases de données propriétaire dont l’aspect dimensionnel est pré-

pondérant. »[Kimball, 2005]

MOLAP offre des temps d’accès optimisés et cela en prédéfinissant

les opérations de manipulation et de chemin d’accès prédéfinis. Autre

caractéristique du agrège tout par défaut, pénalisant du couple sys-

tème lorsque la quantité de données à traiter augmente. On parle

généralement de volume de l’ordre du giga-octet pas plus.

— Les systèmes à architecture ROLAP : Ces systèmes MOLAP

Les systè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 à des bases de données relationnelles». [Kim-

ball, 2005] 9

— Les systèmes à architecture HOLAP : Les systèmes HOLAP «

Hybride On-line Analytical Processing » sont une sorte de compromis

entre les différents systèmes précités. Cette combinaison donne à ce

9. Guide de conduite de projet , 1ère Edition ;Paris, France ;Eyrolles ;Mars 2005.

50
type de système les avantages du ROLAP et du MOLAP en utilisant

tour à tour l’un ou l’autre selon le type de données.

Serveur Stockage des données Traitement des données

MOLAP BD dimensionnelle Serveur de traitement OLAP

ROLAP BD relationnelle SQL avancé)

HOLAP MOLAP pour données som- & ROLAP pour données dé-

maire taillées

Table 3.4 – Tableau comparatif des serveurs OLAP

d. Les opérations sur un cube OLAP

— Vue synthétique / vue détaillée.

— Drill Up (forage vers le haut) : représente les données du cube à

un niveau de granularité supérieur (agrégation).

— Drill Down (forage vers le bas) : représente les données du cube

à un niveau de granularité inférieur (détail).

— Drill-out/Split : ajouter une ou plusieurs dimensions.

— Drill-in/Merge : réduire le cube d’une ou plusieurs dimensions.

— Rotate : Rotation d’une face.

51
— Slicing : Sélection de tranches du cube par prédicats selon une di-

mension.

— Scoping : Extraction d’un sous-ensemble du cube.

Figure 3.7 – Exemple d’opération sur un cube OLAP

e. Langage de requêtes

Comme SQL pour les bases de données relationnelles, il existe des langages

de requêtes pour l’utilisation des OLAP. Il s’agit de MDX « Multidimentio-

nal Expressions » qui possède une syntaxe appropriée à l’interrogation et

manipulation des données multidimensionnelles mémorisées dans un cube

OLAP.

52
3.5 Conclusion

Dans ce chapitre nous avons consacré à définir les notions et les concepts

de base du système décisionnel.

Dont le concept « Data Warehouse » est apparu comme une réponse à

des besoins grandissants dans le domaine décisionnel. Son adaptabilité et

sa capacité de fournir par la souplesse, la rapidité et l’intégrité les données

nécessaires à 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 présentés

dans l’état de l’art, et cela afin de mettre en œuvre notre système, aussi

nous pourrons entamer le prochain chapitre sur la conception à pas sûrs.

53
CHAPITRE 4

CONCEPTION

4.1 Introduction

Après la présentation des besoins et la présentation de l’état de l’art,

nous nous intéressons à l’aspect conceptuel de notre système décisionnel

qui est une phase importante dans le processus de développement puis-

qu’elle prépare la réalisation. Dans ce chapitre, nous allons exposer une

étude détaillée des différents cas d’utilisation du système en utilisant les

diagrammes des cas d’utilisation et les diagrammes de séquence ensuite

la conception de l’entrepôt de données avec leurs indicateurs ainsi que les

différentes faits et dimensions.

54
4.2 Étude détaillée des cas d’utilisation

L’étude détaillée des cas d’utilisation concerne les besoins relatifs à l’en-

trepôt de données. Dans cette section nous allons expliquer chaque cas.

4.2.1 Raffinement du cas d’utilisation « Gérer ETL »

La figure 4.1 représente le raffinement du cas d’utilisation ”Gérer intégra-

tion”, l’administrateur informatique peut générer l’intégration avec Pentaho

Data Intégration (PDI). D’abord il va créer des packages PDI, extraire,

transformer et charger les données par le biais d’un outil ETL.

C’est l’étape la plus importante, elle constitue de 70% à 80% du temps dans

un projet décisionnel.

55
Figure 4.1 – Raffinement de cas d’utilisation ” Gérer ETL”

56
4.2.2 Raffinement du cas d’utilisation «Créer transformations»

La figure 4.2 représente le raffinement de cas d’utilisation ” Créer pa-

ckages ”, l’administrateur informatique doit gérer des nouveaux packages

PDI et créer les dimensions et les faits, charger les données sources. Il peut

aussi créer des mesures si nécessaire.

Figure 4.2 – Raffinement de cas d’utilisation ” créer transformation ”

57
4.2.3 Raffinement du cas d’utilisation « Analyser les données »

La figure 4.3 représente le raffinement de cas d’utilisation ” Analyser

les données ”, l’administrateur informatique peut analyser les données avec

Pentaho BI Server qui nous permet de créer des cubes OLAP. En premier

lieu, il faut charger les données dans l’entrepôt de données qu’on a créé

dans l’étape précédente.

Figure 4.3 – Raffinement des cas d’utilisation ” Analyser les données ”

58
4.2.4 Raffinement du cas d’utilisation « Créer Cube »

La figure 4.4 représente le raffinement de cas d’utilisation ”Créer cube”.

Pour créer un cube il faut définir les tables de faits, les mesures, et les

dimensions l’administrateur informatique peut définir des hiérarchies pour

les dimensions.

Figure 4.4 – Raffinement de cas d’utilisation ” Créer cube ”

59
4.2.5 Raffinement du cas d’utilisation « Gérer rapports »

La figure 4.5 représente le raffinement de cas d’utilisation ” Analyser

les données ”, l’administrateur informatique peut analyser les données avec

Pentaho BI Server qui nous permet de créer, modifier et supprimer des

rapports.

Figure 4.5 – Raffinement de cas d’utilisation ” Gérer rapports ”

60
4.3 Diagramme de séquence

— Diagramme de séquence « Authentification »

La figure 4.6 représente le scénario du cas d’utilisation ”Authentification”.

L’utilisateur saisit son login et son mot de passe, il clique sur le bouton «

login ». Le système vérifie la combinaison login et mot de passe. Si le Login

et le mot de passe sont correcte, l’authentification est réussite.

Figure 4.6 – Diagramme de séquence ” Authentification ”

61
4.4 Conception de l’entrepôt de données

La conception de l’entrepôt de données représente le lé de réussite de

tout projet BI.

Elle constitue la phase la plus important dans le déroulement du projet et

passe par 4 étapes essentielles :

— Définition de sujet à analyser : Il s’agit de répondre à la question :

que représente un enregistrement de la table de fait ?

Il s’agit de l’étape la plus critique lors de la création du modèle parce

qu’il faut comprendre et analyser de manière détaille les besoin finale

de client.

— Choix des dimensions : Dans cette étape on doit choisir les diffé-

rentes dimensions qui représentent le contexte dans lequel le fait a eu

lieu.

— Choix des indicateurs/mesures : Dans cette étape on peut iden-

tifier s’il existe des mesures ou non pour ce sujet.

— Choix du modèle dimensionnel : Il s’agit d’identifier le modèle

conceptuel multidimensionnel (étoile, flocon ou constellation).

62
4.4.1 Les dimensions

Une dimension correspond à un axe d’analyse de la problématique du

projet, elle est nécessairement un facteur dont dépend l’aspect que l’objectif

du projet essaye de mesurer.

Les dimensions ont pour objectif de définir le fait, donc on essaye de recen-

ser toutes les informations qui décrivent l’effectif et qui peuvent intéresser

les décideurs.

63
Dimensions Définition

dim date Elle contient les dates dès 1998.

dim fonction Elle contient les fonctions de l’AFH

(PDG, PDA, Directeur, chef ser-

vice,. . . ).

dim college Elle contient les différents collèges

de l’AFH (cadre supérieur, cadre

moyen, maitrise, exécution).

dim qualification Elle contient les différentes qualifica-

tions de l’AFH (administrateur gé-

néral, ingénieur général, urbaniste

général,. . . ).

dim sexe Elle dé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 différentes affecta-

tions géographiques de l’AFH (Tu-

nis, Sousse, Bizerte, Béja,. . . ).

dim ufg Elle contient les différentes ufg de

l’AFH (Tunis, Sousse, Sfax).

64
dim ufa Elle contient les différentes ufa de

l’AFH (Direction régionale du nord,

DGA, D.des ressources humaines et

du matériel,. . . ).

dim diplome Elle contient le diplôme de chaque

personnel.

dim profil Elle contient les profile de chaque

personnel (Gestion, Gé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’étude de

chaque personnel.

dim position Elle contient les différents positions

de l’AFH (Détache à AFH, Dé-

tache hors AFH, Contractuel, Statu-

taire,. . . ).

dim sous position Elle contient les différents sous-

positions de l’AFH (Actif, bloqué,

Mi-temps,. . . ).

65
dim typeAbs Elle contient les différents types

d’absence (Absence irrégulière,

Mi temps 12 du salaire, congé

maladie,. . . ).

dim indem Elle contient les différents types d’in-

demnités (salaire net, frais déplace-

ment, avance scolaire, amicale,...).

dim mois Elle contient les différents mois de

salaire (janvier, février, avance sco-

laire, 13eme mois, prix de rende-

ment,...).

dim sanction Elle contient les différents types de la

sanction (mutation, avertissement,

blâme, mise à pied,. . . ).

dim typecred Elle contient les différents types du

crédit (don décès, Dons Mariage,

soins, prêt opération,. . . ).

dim assurance Elle contient les différents types

d’assurance (pharmacie, consulta-

tion spécialiste, soins, hospitalisation

clinique,. . . ).

Table 4.1 – Définition des dimensions

66
Ci-dessous la description détaillée de chaque dimension :

— Dimension Date :

« La dimension temps est la seule dimension qui figure systématiquement

dans tout entrepôt de données, car en pratique tout entrepôt de données est

une série temporelle. Le temps est le plus souvent la première dimension

dans le classement sous-jacent de la base de données.» [Kimball, 2011] 1

Il est intéressant de signaler que la finalité du bilan social est d’informé

toutes les instances légales et représentatives sur l’état des ressources hu-

maines de l’entreprise au 31 décembre de chaque année, pour cela les utili-

sateurs ont exprimé avec insistance leur besoin d’un suivi annuelle de leurs

activités. La dimension temps se décrit comme suit :

1. The Moicrosoft Data Warehouse Toolkit ;Second Edition ; 2011

67
Désignation Type Détail

Id Numeric Identifiant de la dimension

dim date

Lib Date DateTime La date au format complet

Année Numeric Anné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 :

Désignation Type Détail

Id Age Numeric Identifiant de la dimension

dim age

DATENAIS Date La date de la naissance au format

complet

ANNEE AGE Numeric Anné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 Ancienneté :

Désignation Type Détail

Id REC Numeric Identifiant de la dimension

dim Ancienneté

DATEREC Date La date de recrutement au format

complet

ANNEE REC Numeric Anné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 ” Ancienneté ”

— Dimension Sexe :

Désignation Type Détail

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 :

Désignation Type Détail

Id SITUATION Numeric Identifiant de la dimension

dim Situation

LIB SITUATION Varchar Nom complet de la situation du

personnel en Franç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 géographique :

Désignation Type Détail

Id GEO Numeric Identifiant de la dimension

dim Affect geo

LIB GEO Varchar Nom complet de l’affectation géo-

graphique en français

LIBAR GEO Varchar Nom complet de l’affectation géo-

graphique en Arabe

Table 4.7 – Description des colonnes de la dimension ” Affectation géographique ”

70
— Dimension UFA :

Désignation Type Détail

Id UFA Numeric Identifiant de la dimension

dim UFA

LIB UFA Varchar Nom complet de l’UFA en français

LIBAR UFA Varchar Nom complet de l’UFA en Arabe

Table 4.8 – Description des colonnes de la dimension ” UFA ”

— Dimension UFG :

Désignation Type Détail

Id UFG Numeric Identifiant de la dimension

dim UFG

LIB UFG Varchar Nom complet de l’UFG en fran-

çais

LIBAR UFG Varchar Nom complet de l’UFG en Arabe

Table 4.9 – Description des colonnes de la dimension ” UFG ”

71
— Dimension Collége :

Désignation Type Détail

Id COLLEGE Numeric Identifiant de la dimension

dim College

LIB COLLEGE Varchar Nom complet dU Collége en fran-

çais

LIBAR COLLEGE Varchar Nom complet dU Collége en

Arabe

Table 4.10 – Description des colonnes de la dimension ” Collége ”

— Dimension Fonction :

Désignation Type Détail

Id FONCTION Numeric Identifiant de la dimension

dim Fonction

LIB FONCTION Varchar Nom complet de la Fonction en

français

LIBAR FONCTION Varchar Nom complet de la Fonction en

Arabe

Table 4.11 – Description des colonnes de la dimension ” Fonction ”

72
— Dimension Filiére :

Désignation Type Détail

Id FILIERE Numeric Identifiant de la dimension

dim Filiere

LIB FILIERE Varchar Nom complet de la Filiére en fran-

çais

LIBAR FILIERE Varchar Nom complet de la Filiére en

Arabe

Table 4.12 – Description des colonnes de la dimension ” Filiére ”

— Dimension Diplôme :

Désignation Type Détail

Id DIPLOME Numeric Identifiant de la dimension

dim diplome

LIB DIPLOME Varchar Nom complet du Diplôme en fran-

çais

LIBAR DIPLOME Varchar Nom complet du Diplôme en

Arabe

Table 4.13 – Description des colonnes de la dimension ” Diplôme ”

73
— Dimension Niveau d’étude :

Désignation Type Détail

Id NIVEAU Numeric Identifiant de la dimension

dim diplome

LIB NIVEAU Varchar Nom complet du Niveau d’étude

en français

LIBAR NIVEAU Varchar Nom complet du Niveau d’étude

en Arabe

Table 4.14 – Description des colonnes de la dimension ” Niveau d’étude ”

— Dimension Qualification :

Désignation Type Détail

Id QUALIFICATION Numeric Identifiant de la dimension

dim Qualification

LIB QUALIFICATION Varchar Nom complet du Qualification en

français

LIBAR QUALIFICATION Varchar Nom complet du Qualification en

Arabe

Table 4.15 – Description des colonnes de la dimension ” Qualification ”

74
— Dimension Position :

Désignation Type Détail

Id POSITION Numeric Identifiant de la dimension

dim Position

LIB POSITION Varchar Nom complet de la Position en

français

LIBAR POSITION Varchar Nom complet de la Position en

Arabe

Table 4.16 – Description des colonnes de la dimension ” Position ”

— Dimension Sous Position :

Désignation Type Détail

Id SOUS POSITION Numeric Identifiant de la dimension

dim Sous Position

LIB SOUS POSITION Varchar Nom complet de la Sous Position

en franç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 :

Désignation Type Détail

Id TYPEABS Numeric Identifiant de la dimension

dim typeAbs

LIB TYPEABS Varchar Nom complet du type d’absence

en franç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 crédit :

Désignation Type Détail

Id TYPECRED Numeric Identifiant de la dimension

dim typeCred

LIB TYPECRED Varchar Nom complet du type de cédit en

français

LIBAR TYPECRED Varchar Nom complet du type de crédit en

Arabe

Table 4.19 – Description des colonnes de la dimension ” type crédit ”

76
— Dimension indemnité :

Désignation Type Détail

Id INDEM Numeric Identifiant de la dimension

dim indem

LIB INDEM Varchar Nom complet de l’indemnité en

français

LIBAR INDEM Varchar Nom complet de l’indemnité en

Arabe

Table 4.20 – Description des colonnes de la dimension ” indemnité ”

— Dimension type sanction :

Désignation Type Détail

Id TYPESANC Numeric Identifiant de la dimension

dim tupeSanc

LIB TYPESANC Varchar Nom complet du type de la sanc-

tion en franç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 :

Désignation Type Détail

Id MOIS Numeric Identifiant de la dimension

dim mois

LIB MOIS Varchar Nom complet du mois en français

LIBAR MOIS Varchar Nom complet du mois en Arabe

Table 4.22 – Description des colonnes de la dimension ” mois ”

— Dimension type assurance :

Désignation Type Détail

Id TYPEASSUR Numeric Identifiant de la dimension

dim tupeAssurance

LIB TYPEASSUR Varchar Nom complet du type d’assurance

en franç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 étoiles, Ces dimensions sont indispensables pour répondre au

78
besoin de l’application.

Dimensions Fait- Fait- Fait- Fait- Fait- Fait- Fait-

Personnel Absence Retard Paie Sanction Cré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 – Détection des dimensions communes

4.4.3 Sujet d’analyse : Gérer effectifs

Gé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 Propriété

d’agrégation d’additivité

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 représenté par un schéma en étoile ayant le

nombre des personnels comme mesure dans la table de faits « fait personnel

».

Figure 4.7 – Modèle en étoile ” Fait-personnel ”

81
4.4.4 Sujet d’analyse : Gérer Absentéisme

Gérer Absentéisme permet d’analyser les informations concernant le

suivi d’absence d’effectifs de l’AFH selon plusieurs mesures et indicateurs.

a. Choix d’indicateur

Indicateurs Description Formule Propriété

d’agrégation d’additivité

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 représenté par un schéma en é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 – Modèle en étoile ” Fait-Absence ”

83
4.4.5 Sujet d’analyse : Gérer Retard

Gérer Retard permet d’analyser les informations concernant le retard

d’effectifs de l’AFH selon plusieurs mesures et indicateurs.

a. Choix d’indicateur

Indicateurs Description Formule Propriété

d’agrégation d’additivité

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 représenté par un schéma en é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 – Modèle en étoile ” Fait-Retard ”

85
4.4.6 Sujet d’analyse : Gérer Salaire

Gérer Salaire permet d’analyser les informations concernant le suivi de

paie d’effectifs de l’AFH selon plusieurs mesures et indicateurs.

a. Choix d’indicateur

Indicateurs Description Formule Propriété

d’agrégation d’additivité

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 représenté par un schéma en étoile ayant le montant

total du paie comme mesure dans la table de faits « fait paie ».

86
Figure 4.10 – Modèle en étoile ” Fait-Paie ”

87
4.4.7 Sujet d’analyse : Gérer Sanction

Gérer Sanction permet d’analyser les informations concernant le suivi

des sanctions d’effectifs de l’AFH selon plusieurs mesures et indicateurs.

a. Choix d’indicateur

Indicateurs Description Formule Propriété

d’agrégation d’additivité

NBR EFFECTIF Le nombre total Somme Additifs

d’effectifs sanction-

né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 représenté par un schéma en étoile ayant le

nombre du jour du sanction et le nombre d’effectives sanctionnées comme

mesure dans la table de faits « fait sanction ».

88
Figure 4.11 – Modèle en étoile ” Fait-Sanction ”

89
4.4.8 Sujet d’analyse : Gérer Crédit

Gérer Crédit permet d’analyser les informations concernant le suivi de

crédit d’effectifs selon plusieurs mesures et indicateurs.

a. Choix d’indicateur

Indicateurs Description Formule Propriété

d’agrégation d’additivité

NBR PERS Le nombre total de Somme Additifs

personne.

MONTANT Le montant total de Somme Additifs

crédit d’effectifs.

Table 4.30 – Description des mesures de la table fait Crédit

b. Datamart Fait-Crédit

Le Datamart crédit est représenté par un schéma en étoile ayant le nombre

total d’effectif et le montant de crédit comme mesure dans la table de faits

« fait crédit ».

90
Figure 4.12 – Modèle en étoile ” Fait-Crédit ”

91
4.4.9 Sujet d’analyse : Gérer Assurance

Gérer Assurance permet d’analyser les informations concernant le suivi

d’assurance d’effectifs selon plusieurs mesures et indicateurs.

a. Choix d’indicateur

Indicateurs Description Formule Propriété

d’agrégation d’additivité

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 crédit est représenté par un schéma en étoile ayant le nombre

total d’effectif et le montant de crédit comme mesure dans la table de faits

« fait crédit ».

92
Figure 4.13 – Modèle en étoile ” Fait-Assurance ”

93
4.5 Conception ETL

Dans un projet décisionnel, l’ETL ou l’alimentation du Data Warehouse

est une étape des plus importantes elle représente 70% de la charge de tra-

vail. Cette étape a pour objectif l’acheminement des données des systèmes

sources jusqu’à l’entrepôt de données, en passant par les différentes phases

de nettoyage et de transformations nécessaires.

Le processus d’alimentation nécessite les étapes suivantes :

— Étude et planification

— Processus ETL

4.5.1 Étude et planification

Avant de commencer l’alimentation, on doit étudier les données sources,

la détection de leur contenue et leur emplacement.

a. L’étude des sources de données

Les sources de données de notre entrepôt est la base transactionnelle conte-

nant les informations reliée à la gestion de ressource humaine de l’AFH.

94
b. La Détection des contenues et des emplacements des données

sources

Le processus d’alimentation a débuté par l’extraction des données qui est

sans doute la tâche la plus vaste du projet décisionnel. Le plus souvent, sa

difficulté réside dans le choix des données à extraire et des filtres à appliquer.

— Bases de données sources

95
Figure 4.14 – Base de données source

96
4.5.2 Processus ETL

Le Processus ETl se déroule selon 3 étapes l’extraction du données à

partir de BD source, la transformation et enfin la chargement dans le data

warehouse.

a. Extraction des données

A partir de base de données source on va extraire les données nécessaires

pour répondre au besoin du client.

Cette phase est considérée comme une étape difficile car il faut établir

des connexions vers les systèmes ou exporter des volumes important des

données sous plusieurs formes.

b. Transformation des données

La phase de transformation des données est la plus importante d’ETL ou

la présence des outils permet de contrôler les données entrantes, traiter

et nettoyer les informations inappropriées, puis les transformer en données

validées et intégrées.

En général, l’objectif de la phase de transformation consiste à charger des

données fiables et pertinentes pour l’alimenter dans la datawarehouse.

97
c. Chargement des données

C’est la dernière phase d’alimenter l’entrepôt de données. Il s’agit de sto-

cker les données dans le dataWarehouse.

Le processus d’alimentation commence par le chargement des tables dimen-

sions, une fois les données sont bien stockées, les chargements des tables

faits se lancent.

4.6 Conception de la restitution

La restitution des données est la dernière étape d’un projet décisionnel.

Cette phase consiste à charger les informations d’une façon plus lisible dans

la cadre de l’aide à prendre des décisions pour bien piloter l’entreprise.

4.6.1 Conception des cubes OLAP

La Modélisation de notre entrepôt de données nécessite d’une struc-

ture de stockage adoptée à l’OLAP (on-line analytical processing), qui per-

mettent, à partir des entrepôts de données, d’analyser l’activité de l’entre-

prise grâce à des statistiques précis. L’élément principal de l’infrastructure

OLAP est le cube. C’est en fait une base de données multidimensionnelle,

98
qui permet l’analyse de ces données en reprend les mesures de la table de

faits et s’en sert pour effectuer des calculs, les mesures étant des données

quantitatives.

Figure 4.15 – Modélisation des cubes dimensionnels

4.6.2 Conception des tableaux de bord

Dans le cadre de notre projet, nous avons eu l’idée de créer des tableaux

de bords destinés aux décideurs pour les aider à avoir une vue globale sur

la situation de leurs personnels.

Nous avons réalisé pour ce projet 7 tableaux de bord consacré chacune un

axe pour la gestion du ressource humaine.

99
4.7 Diagramme de déploiement

Le diagramme de déploiement représente la disposition physique des res-

sources matérielles qui composent le système et montre la répartition des

composants sur ces matériels. Il est intéressant donc de le concevoir pour

une meilleure orientation de la réalisation du système. La figure 24 repré-

sente l’architecture physique de notre système et la méthode de répartition

des composantes logicielles sur ce dernier.

100
Figure 4.16 – Diagramme de déploiement

101
4.8 Conclusion

Dans ce chapitre nous avons présenté la conception du système par la pré-

sentation de différents diagrammes que nous avons établis ainsi la concep-

tion de la zone d’entreposage. La conception de cette zone se fait grâce à la

modélisation dimensionnelle qui offre aux utilisateurs des modèles compré-

hensibles permettant de naviguer et de manipuler les données sans difficulté

afin de satisfaire leurs besoins en analyse.

Nous avons réservons le chapitre suivant pour la présentation de l’environ-

nement du travail et les outils utilisés pour réalisation de notre système.

102
CHAPITRE 5

PRÉSENTATION DES OUTILS UTILISÉES ET

RÉALISATION

5.1 Introduction

Après l’étude conceptuelle du système, nous passons à l’étape de réa-

lisation. Celle-ci commence par présenter l’environnement de travail. Puis

la définition des choix technologiques nécessaire au développement. Enfin

nous mettons en évidence l’implémentation de notre système via quelques

interfaces.

103
5.2 Environnement de travail

Nous présentons dans cette section l’environnement matériel et logiciel

utilisé pour le développement de notre application.

5.2.1 Environnement matériel

Pour l’implémentation de cette application nous avons utilisé deux ordi-

nateurs qui présentent les caractéristiques suivantes :

— Modèle : Asus

— Processeur : Intel(R) Core(TM) i5-5200U CPU 2.20 GHz.

— RAM : 8.00 GO

— Type du système : Windows10 64bits

5.2.2 Environnement logiciel

— Oracle Database 10g

Figure 5.1 – Logo Oracle 10g

104
Oraclea Database est un système de gestion de base de données relationnel

(SGBDR) qui depuis l’implémentation du support du modèle objet dans sa

version 8 peut être aussi qualié de système de gestion de base de données

relationnel-objet (SGBDRO). Il est fourni par Oracle-Corporation. Il ac-

cord de meilleurs résultats grâce notamment à l’automatisation des tâches

administratives et à des fonctionnalités de sécurité et de conformité régle-

mentaire sans équivalent sur le marché.

— 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’exécution des opérations de manipulation et

de transformation de données très complexes. Son objectif est de récupérer

diverses sources dans différents formats, de les traiter, les transformer, et

établir un résultat puis finalement exporter dans le format souhaité vers

une destination souhaitée. De plus l’intégration de données de Pentaho

105
est ouverte ; elle repose sur une architecture normalisée et est ajustable à

n’importe quel environnement ou solution de BI[3].

L’outil Pentaho Data Integration offre des fonctionnalités

— L’extraction,

— La transformation,

— le chargement des données.

— Pentaho Console utilisateur (PUC)

Figure 5.3 – Logo de PUC

La Pentaho Console utilisateur (PUC) est un environnement de conception

Web où vous pouvez analyser les données, créer des rapports interactifs,

des rapports de tableau de bord, et de construire des tableaux de bord

intégrés pour partager des solutions de business intelligence avec les autres

dans votre organisation et sur Internet. En plus de ses caractéristiques de

conception, le PUC offre une grande variété de fonctions d’administration

système pour la configuration du serveur Pentaho.

— L’extraction,

106
— La transformation,

— le chargement des donné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 créer des rapports. Les rap-

ports peuvent être exécutés et enregistrés localement par l’intermédiaire

du PRD ou publiés sur un serveur Pentaho BI pour permettre à de nom-

breuses personnes d’accéder et de planifier l’exécution du rapport. Le PRD

est orienté vers les utilisateurs expérimentés, qui sont familiers avec les

concepts et les données-sources utilisées.

— Laravel

Figure 5.5 – Logo Laravel

107
Laravel est un framework open-source web PHP, créé par Taylor Otwell

basé sur Symfony et destiné au développement d’applications web suivant

le modèle architectural MVC (model-view-controller). Certaines des fonc-

tionnalités de Laravel sont un système d’empaquetage modulaire avec un

gestionnaire de dépendances dédié, différentes manières d’accéder aux bases

de données relationnelles, des utilitaires qui facilitent le déploiement et la

maintenance des apps. Le code source de Laravel est hébergé sur GitHub

et sous licence selon les termes de la licence MIT.

— MySQL

MySQL est un système de gestion de bases de données relationnelles (SGBDR).

Il est distribué sous une double licence GPL et propriétaire. Il fait partie des

logiciels de gestion de base de données les plus utilisé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 éditeur pour PHP, HTML, CSS et JavaScript, édité par

JetBrains. Il permet d’éditer du code PHP 5.3, 5.4, 5.5, 5.6 et 7.0, 7.1, 7.2

Il possède :

108
- Une coloration syntaxique

- Affichage des erreurs à la volée

- Auto-complétion intelligente du code

- Réusinage de code.

Il intè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 données de diffé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

électronique. Il s’agit d’une distribution de logiciels libres (X (cross) Apache

MariaDB Perl PHP) offrant une bonne souplesse d’utilisation, réputée pour

son installation simple et rapide. Ainsi, il est à la portée d’un grand nombre

de personnes puisqu’il ne requiert pas de connaissances particulières et fonc-

tionne, de plus, sur les systèmes d’exploitation les plus répandus.

109
— ShareLatex

ShareLaTeX est un éditeur LaTeX en ligne, collaboratif, en temps réel et

compileur PDF. Par ailleurs, ShareLaTeX fut libéré en février 2014. Le 20

Juillet 2017, ShareLatex a été racheté par Overleaf qui prévoie de réunir les

services d’Overleaf et de Sharelatex sur une seule plateforme, actuellement

en période de test.

En comparaison avec les autres éditeurs LaTeX, ShareLaTeX est une appli-

cation basée sur un serveur web, qui est donc accessible via un navigateur

internet.

5.3 Architecture globale d’application

Pour réaliser une solution Business Intelligence complè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’entrepôt de données à travers l’ETL Pentaho Data Integration choisi et

défini dans le paragraphe précédent et la phase de restitution effectuée par

l’outil décisionnel Pentaho Console utilisateur défini précé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 décisionnelle

5.4 Réalisation du processus ETL

La première phase au niveau de l’alimentation est la phase d’intégra-

tion. C’est la phase la plus importante car elle contient le processus ETL

qui va nous permettre de se connecter à toute source de données, collecter,

transformer et charger les données nécessaire dans notre entrepôt de don-

née. Après avoir chargé toutes les données nécessaires nous allons passer

à travers un cube vers le reporting pour faciliter notre tâche et éviter les

111
requêtes longues et donc minimiser le temps d’exécution. Dans cette partie

nous allons illustrer les diérentes étapes de l’alimentation de notre entrepôt

de données.

5.4.1 Composants kettle utilisés

— Extraction

— Extraction depuis fichier CSV : Lire les informations depuis fichier

CSV.

— Extraction depuis Table : Lire les informations depuis table BDD.

— Transformation

— Ajout séquence : Récupère la prochaine valeur d’une séquence.

— Altération structure flux : Sélectionner ou retirer des champs dans

une ligne. Possibilité de modifier le type, longueur, et précision du

champ.

— Création d’opération de calcul : Créer de nouveaux champs à partir

de calcul simple.

— Dédoublonnage : Permet d’effectuer une dédoublonnage unique-

ment si les lignes sont triées. Sinon les lignes identiques consé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 clé. Les flux d’entrés doit être triés sur la clé du join-

ture.

— Produit Cartésien : Le résultat de cette étape est le produit carté-

sien des flux d’entrés.

— Contrôle de flux

— Annotate Stream : Permet d’affiner le table de données pour la raf-

finerie de données rationalisée en créant une mesure ou un attribut

sur les colonnes que vous spécifiez.

— Filtrage lignes : Filtrer des lignes grâce à de simple équation.

— Exécution de scripts

— Modified Java Script value : Plugiciel permettant décrire des scripts

Java.

— Calculateur : Calcul en utilisant la librairie de pentaho.

113
— Exécution Script SQL : Exécuter un script SQL, éventuellement

paramétré à l’aide de lignes d’entrée.

— Recherche

— Recherche dans base de données : Rechercher des valeurs dans une

base de données à l’aide des valeurs de champ.

— Entrepôt de données

— Mise à jour dimension junk : Mettre à jour une dimension Junk

dans un entrepôt de données. La clé primaire d’une dimension Junk

représente tous les champs.

— Alimentation

— Insertion dans table : Écrire informations dans table BDD.

114
5.4.2 Connexions aux bases de données source

Figure 5.7 – connexions aux BD

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

Pour alimenter de l’entrepôt de données, on doit commencer par l’ali-

mentation des dimensions et par la suite les faits.

a. Alimentation des dimensions

Cette phase consiste à créer des transformations, sous PDI, qui comprend

des composants d’extraction, de transformation et de chargement, il faut

115
tout d’abord se connecter à la source de données, extraire les données néces-

saire par requête sql, convertir les données puis les stocker dans l’entrepôt

de donné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 données source nécessite à partir de la table de données Idtagent

puis via l’outil recherche des tables nous avons ajouté les dimensions associé

et les faire jointure avec le table de données source à l’aide des valeurs de

champ spécifie.

Figure 5.10 – Alimentation du Fait Personnel

Pour l’alimentation des autre faits, nous avons refaire presque le mê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 Crédit

Figure 5.15 – Alimentation du Fait Crédit

— Alimentation du Fait Assurance

Figure 5.16 – Alimentation du Fait Assurance

121
5.5 Réalisation de la restitution

La réalisation de la restitution concernant la réalisation des cubes OLAP

et des tableaux de bords.

5.5.1 Réalisation du cube OLAP

Après l’alimentation de l’entrepôt de donnée et la validation des données,

on peut lancer la phase de restitution en débutant par la création des cubes

OLAP nécessaire pour réaliser notre projet.

Étape de création du cube OLAP a l’aide de CPU en prenant l’exemple du

cube « Fait Personnel » :

— Gérer la source des données

— Sélectionner type source

— Définir les tables dimensions et la table Fait.

— Créer des jointures

— Définir les mesures et les dimensions en spécifiant leurs hiérarchies

122
Figure 5.17 – Créer cube ”Fait personnel”

Le cube qui a été construit à partir de la base de données est représenté

par une structure XML. Elle comporte les dimensions, hiérarchies ainsi que

les indicateurs (« Measures »).

Une fois la Datawarehouse est alimenté et les cubes OLAP sont créés,

nous passons à la création des tableaux de bord.

Pour créer un tableau de bord nous avons utilisées le Community Dash-

board Editor (CDE) comme outils, c’est un éditeur de tableau de bord

graphique qui permet d’accé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 créer vos propres

tableaux de bord sans avoir besoin de beaucoup d’expertise JavaScript ou

HTML.

Dans le suit, nous présentons les étapes suivi pour réaliser un tableau de

bord, en présentant comme exemple le tableau de bord « Suivi des person-

nels ».

Tout d’abord nous avons commencé par la mise en page du tableau de

bord en ajoutant des lignes et des colonnes pour la création du structure

de page, la sélection du source du donnée et la personnaliser à l’aide des

requête MDX et en terminant par la développement graphiques ou le choix

du type de chart à 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 données

Figure 5.19 – Personnaliser de la source de donné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’

— Requête MDX

Figure 5.21 – Exemple de la requête MDX

126
— Aperçu du tableau de bord

Figure 5.22 – Aperçu du tableau de bord ’Suivi personnel’

5.5.2 Réalisation des Rapports

La reporting est une autre partie de restitution, nécessite aussi l’alimen-

tation du datawarehouse.

Pour créer un ”reporting”nous avons utilisées Pentaho Report Design comme

outils, en passant par les étapes suivants :

— Connectez-vous à une source de données.

— Filtrer les données avec une requête.

127
— Organiser les éléments de données dans l’espace de travail Report

Designer.

— Appliquer la mise en forme pour signaler les éléments.

— Créez des formules ou des champs calculés à l’aide de données ex-

traites de votre requê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 réalisés ainsi que les rapports en

passant à la dernière étape de notre projet la génération des rapports.

Dans la suite, nous présentons, l’ensemble des interfaces de notre tableau

de bord.

129
5.6.1 Interface « Authentification »

Au lancement de l’application, l’utilisateur est invité à s’authentifier

pour pouvoir accéder à 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 affiché.

— Sinon : un message d’erreur sera affiché. L’utilisateur doit spé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

décrire les effectifs selon plusieurs axe d’analyse et selon quelque filtre .Par

exemple la répartition de personnel par nombre de recrutement et par an-

né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 dé-

crire l’absentéisme selon différent axe d’analyse et quelque filtre .Par exemple

la répartition d’absence par nombre de jour, nombre d’effectifs et par année,

selon le filtre affectation gé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 dé-

crire les retards d’effectifs au sein de l’AFH selon différent axe d’analyse et

quelque filtre par exemple l’affectation gé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

décrire les sanctions d’effectifs au sein de l’AFH selon différent axe d’analyse

et quelque filtre par exemple le collè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 repré-

senté le salaire d’effectifs au sein de l’AFH selon diffé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 crédit »

L’interface Suivi de crédit, permet de consulter le tableau de bord re-

présenté le crédit d’effectifs au sein de l’AFH selon différent axe d’analyse

et quelque filtre .

Figure 5.32 – Interface « Suivi de crédit »

137
Figure 5.33 – Interface « Report de Suivi de crédit »

138
5.6.8 Interface « Suivi d’assurance »

L’interface Suivi d’assurance, permet de consulter le tableau de bord

représenté l’assurance au sein de l’AFH selon diffé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 présenté en détails la projection de

la conception du plan théorique sur le plan pratique. En effet, Nous avons

décrit l’environnement et les outils utilisées afin de construire notre appli-

cation. Nous avons par la suite élaboré les étapes du processus ETL ainsi

que les interfaces graphiques de l’application permet à prendre décisions

concernent la situation de ressource humaine de l’AFH.

140
CONCLUSION

Ce rapport porte sur le travail réalisé au cours de notre projet de fin

d’études au sein de l’agence foncière d’habitation AFH portant sur la mise

en place d’un système d’aide à la décision.

L’objectif de ce projet BI réside donc à analyser les données sources de l’en-

treprise et concevoir un entrepôt de données afin de recomposer les données

disponibles de la GRH (Gestion de Ressource Humaine), et ce pour obte-

nir une vision intégrée et transversale sur le personnel, une vision métier à

travers des différents axes d’analyse et une vision agrégée ou détaillée selon

le besoin. Ce système data warehouse nous a permis de mettre en place un

tableau de bord qui présentent l’information suivant les critères que choi-

sissent par les décideurs.

141
Ce projet comprend plusieurs étapes successives, d’abord, après l’étude

complète pour comprendre le métier de l’entreprise, leur environnement de

travail et leur besoin et les objectifs attendus, nous avons commencé par

l’étude des données existent afin de réaliser l’entrepôt de données. Ensuite,

nous nous sommes tournés à la modélisation de la zone de stockage des

données s’est faite grâce aux principes de la modélisation dimensionnelle.

Cette modélisation ore une vision claire et une compréhension intuitive des

modelés proposés. La partie d’alimentation de la zone de stockage a été

sans doute la partie de projet la plus complexe et consommatrice en temps.

Cette étape nous a permis de concevoir et de réaliser, grâce a des outils BI

de pentaho. Une fois les données sont chargées dans l’entrepôt de données,

nous avons procédé à l’étape finale du processus BI, qui est la restitution

des données.

La valeur ajoutée que peut apporter ce projet, une fois la solution dévelop-

pée mise en production, est à notre sens considérable. En eet, les rapports

et tableaux de bord générés grâce à notre solution BI orent aux décideurs

de la direction de ressources humaines de l’AFH une vision globale de leurs

activités et pourra les aider à prendre plus ecacement et plus rapidement

142
les décisions stratégiques de gestion.

Comme un projet système d’aide à la décision n’est jamais complètement

terminé, nous proposons d’étendre notre travail. Pour cela nous pouvons

citer les perspectives suivantes :

— Utilisation des méthodes et d’algorithmes de Data Mining pour une

meilleure exploitation des données.

— Enrichissement de l’entrepôt de données à d’autres domaines notam-

ment dans la finance. En effet nous n’avons pas travaillé sur la totalité

de la base source.

— La migration vers les bases de donné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

Vous aimerez peut-être aussi