Rapport Meriem MOUSTAJAB Final

Ecole Nationale Supérieure d’Informatique
et d’Analyse des Systèmes
Mémoire de Projet de Fin d’Études
Pour l’Obtention du Titre
D’Ingénieur d’État en Informatique

Option
Business Intelligence
Sujet
Mise en œuvre d’un système décisionnel pour les

processus RH d’Outsourcia
Soutenu par : Sous la direction de :
Mme. Meriem MOUSTAJAB M. M. A. JANATI IDRISSI (ENSIAS)

M. M. Ali STOUKY (OUTSOURCIA)
M. Didier TOULOUSE (OUTSOURCIA)
Année Universitaire 2010-2011

Dédicaces
A mes très chers parents
Je ne saurai exprimer assez ma gratitude pour tout votre amour

et soutien, et tous vos sacrifices. J’espère que vous serez
toujours fiers de moi,
A mon très cher mari
Mon âme sœur, sans ton aide, tes conseils et tes encouragements
ce travail n’aurait vu le jour, que ce travail soit le témoignage de
ma reconnaissance,
A ma très chère sœur Zineb,
A mon très cher frère Chafik
Les mots ne suffisent guère pour exprimer l’amour,

l’attachement et l’affection que je porte pour vous,
A tous les membres de ma famille,
A toutes mes amies,
A tous ceux qui m’aiment
Je dédie
ce travail
Meriem
Remerciements
Ce travail, réalisé au sein d’Outsourcia, n’aurait pu être mené à bien sans l’aide précieuse de
plusieurs personnes auxquelles j’adresse, ici, mes profonds remerciements.
Je tiens ainsi à remercier tout le corps professoral de l’ENSIAS pour la formation qu’il nous a
offerte durant mes trois années d’études.
J’exprime aussi mon ample reconnaissance et ma considération envers mes encadrants, M.

Mohamed Abdou JANATI IDRISSI de l’ENSIAS, ainsi que M. Mohamed Ali STOUKY et
M. Didier TOULOUSE d’Outsourcia, qui n’ont ménagé aucun effort pour m’orienter, m’aider
et m’encourager tout au long du projet.
Mes remerciements les plus sincères vont également à M. Morad BELLOT pour ses directives
et conseils qui m’ont été d’une grande utilité pour l’accomplissement de ce projet. Merci
également à Mlle Karima NARJIS et Mme Wassila CHRAIBI qui ont fait preuve de
disponibilité tout au long de ma période de stage.
Que les membres du jury, trouvent ici l’expression de ma reconnaissance pour avoir accepté
de juger mon travail.
Que tous ceux et celles qui ont contribué de près ou de loin à l’accomplissement de ce travail
trouvent également l’expression de mes remerciements les plus sincères.
Résumé
Ce mémoire constitue une synthèse de mon projet de fin d’études effectué au sein
d’Outsourcia. Ce projet a pour objectif de mettre en œuvre une solution décisionnelle pour la
fonction RH d’Outsourcia. Il s’inscrit dans le cadre de l’enrichissement du Système
d’Information Ressources Humaines (SIRH) de la société.
Pour une meilleure conduite du projet, nous avons suivi le cycle de vie dimensionnel. Après
avoir mis le projet dans son contexte, nous avons en premier lieu étudié le système existant
ainsi que les sources de données. Les différents besoins des utilisateurs ont été ensuite relevés,
ce qui a permis d’aboutir à un dossier des spécifications fonctionnelles et un autre des
spécifications techniques pour la solution. Nous avons alors enchainé par la conception des
différents datamarts constituant notre datawarehouse et les tableaux de bord qui constitueront
notre système de reporting. La réalisation de l’alimentation du datawarehouse a été faite grâce
à l’outil Talend, celle des cubes OLAP avec Pentaho Analysis et enfin les rapports statiques à
l’aide de BIRT.
Le résultat final de notre travail est une plateforme décisionnelle destinée à la DRH
d’Outsourcia et axée autour des thèmes emploi, rémunération et conditions de travail. Elle
offre aux utilisateurs la possibilité d’accéder aux informations synthétisées et utiles, en
consultant les rapports statiques mis à leur disposition ou en générant des rapports spécifiques
selon leurs choix grâce aux cubes OLAP.
Mots-clés :
Outsourcia, RH, DRH, SIRH, emploi, rémunération, conditions de travail
Datawarehouse, datamart, cube OLAP, reporting, tableau de bord, Talend, Pentaho, BIRT
Abstract
This document is a summary of my graduation project that I accomplished at Outsourcia. This

project aims to establish a business intelligence solution for the Human Resources function. It
is part of the enrichment of the Humaines Resources Information System of the company. My
mission is to create a datawarehouse centered on the themes employment, remuneration, work
conditions and a reporting system based on them.
To better conduct the project, we followed the dimensional life cycle. So, after putting the
project in context, we first studied the existing system and the datas source. Then, we
gathered the requirements of different users in order to guide their activities. Therefore, we
were able to phrase functional and technical specifications for our solution. Then, we
designed dimensional models of our datamarts. we also designed the dashboards that
constitute our reporting system.
Finally, we created and loaded the datawarehouse with Talend and OLAP cubes thanks to
Pentaho Analysis. We also created the static reports using BIRT.
The final result of our work is a business intelligence solution for the HR function of
Outsourcia that enables users to access synthesized and useful information, by consulting the
dashboards at their disposal or by generating reports according to their choices thanks to
OLAP cubes.
Keywords:
Outsourcia, HR, HRD, HRIS, employment, remuneration, work conditions
Datawarehouse, datamart, OLAP cubes, reporting, dashbord, Talend, Pentaho, BIRT
Liste des abréviations
Abréviation Désignation
BI Business Intelligence
BIRT Business Intelligence Reporting Tools
BPO Business Process Outsourcing
CNSS Caisse Nationale de Sécurité Sociale
DRH Direction des Ressources humaines
ETL Extraction Transformation Loading
HTML HyperText Markup Language
ITO Information Technology Outsourcing
OLAP On Line Analytical Processing
PAQ Plan Assurance Qualité
RH Ressources Humaines
ROLAP Relational On Line Analytical Processing
SCD Slowly Changing Dimension
SGBD Système de Gestion des Bases de Données
SIRH Système d’Information Ressources Humaines
SQL Structred Query Language
Table des figures
Figure 1: Ecran d’accueil du SIRH d’Outsourcia.....................................................................18

Figure 2: Schéma du cycle de vie dimensionnel.......................................................................19
Figure 3: Diagramme GANTT du projet..................................................................................21
Figure 4: Exemple de rapport élaboré avec Excel....................................................................25
Figure 5: Architecture applicative............................................................................................34
Figure 6: Datamart effectifs......................................................................................................39
Figure 7: Datamart embauches.................................................................................................39
Figure 8: Datamart sorties.........................................................................................................40
Figure 9: Datamart absentéisme................................................................................................40
Figure 10: Datamart rémunération............................................................................................41
Figure 11: Datamart heures supplémentaires............................................................................42
Figure 12: Datamart congés......................................................................................................42
Figure 13: Jobs du projet...........................................................................................................47
Figure 14: Job dimensions........................................................................................................48
Figure 15: Flux d’alimentation de la dimension opération.......................................................48
Figure 16: Mapping dimension opération.................................................................................49
Figure 17: Editeur SCD............................................................................................................50
Figure 18: Job TF_absentéisme................................................................................................51
Figure 19: Transformations du job TF_absentéisme................................................................51
Figure 20: Vidage des tables de dimensions.............................................................................52
Figure 21: Alimentation de la table de fait TF_absenteisme....................................................52
Figure 22: Connexion du tELTMapper.....................................................................................53
Figure 23: tELTMapper du job TF_absentéisme......................................................................53
Figure 24: Connexion à la base de données (Schema Workbench)..........................................54
Figure 25: Schéma Mondrian du thème emploi........................................................................55
Figure 26: Cube absences (Schema Workbench).....................................................................56
Figure 27: Cube virtuel Flux (Schema Workbench).................................................................56
Figure 28: Cube absences 1......................................................................................................57
Figure 29: Cube absences 2......................................................................................................58
Figure 30: Cube Entrées 1.........................................................................................................59
Figure 31: Cube Entrées 2.........................................................................................................59
Figure 32: Cube Effectifs..........................................................................................................60
Figure 33: Connexion base de données (Birt)...........................................................................60
Figure 34: Cube de données (Birt)............................................................................................61
Figure 35: Création rapport rémunération par métier et sexe...................................................62
Figure 36: Rapport répartition par sexe et par âge de l’effectif 1.............................................62
Figure 39: Rapport répartition par sexe et par âge de l’effectif................................................64
Figure 40: Rapport prime moyenne 1.......................................................................................65
Figure 41: Rapport prime moyenne 2.......................................................................................65
Liste des tableaux
Tableau 1: Chiffres d’affaires d’Outsourcia.............................................................................16

Tableau 2: Livrables du projet..................................................................................................22
Tableau 3: Indicateurs "effectifs".............................................................................................28
Tableau 4: Indicateurs "flux"....................................................................................................28
Tableau 5: Indicateurs "absentéisme".......................................................................................29
Tableau 6: Indicateurs "rémunération".....................................................................................30
Tableau 7: Indicateurs "congés"...............................................................................................30
Tableau 8: Indicateurs "heures supplémentaires".....................................................................31
Tableau 9: Axes d’analyse........................................................................................................32
Tableau 10: Matrice d’expression des besoins.........................................................................37
Tableau 11: Tableau de bord "effectifs"...................................................................................44
Tableau 12: Tableaux de bord "rémunération".........................................................................44
Tableau 13: Tableaux de bord "conditions de travail"..............................................................45
Table des matières
Table des matières
Introduction générale.............................................................................................................13
Chapitre I: Contexte général du projet................................................................................15
1. Présentation d’Outsourcia.............................................................................................16
2. SIRH d’Outsourcia.......................................................................................................17
3. Motivation et objectifs du projet...................................................................................18
4. Conduite du projet.........................................................................................................19
4.1. Démarche..................................................................................................................19
4.2. Planning....................................................................................................................20
4.3. Livrables...................................................................................................................22
4.4. Plan Assurance qualité..............................................................................................22
Conclusion................................................................................................................................23
Chapitre II: Analyse et spécifications...................................................................................24
1. Étude de l’existant.........................................................................................................25
1.1. Description de l’existant...........................................................................................25
1.2. Critique de l’existant.................................................................................................26
2. Recueil des besoins.......................................................................................................26
2.1. Besoins principaux....................................................................................................26
2.2. Besoins secondaires..................................................................................................27
3. Cadrage fonctionnel du projet.......................................................................................27
3.1. Description des indicateurs.......................................................................................27
3.1.1. Indicateurs "emploi".........................................................................................27
3.1.2. Indicateurs "rémunération"...............................................................................29
3.1.3. Indicateurs "conditions de travail"...................................................................30
3.2. Description des axes d’analyse.................................................................................31
4. Cadrage technique.........................................................................................................32
4.1. Macro Architecture...................................................................................................32
4.2. Architecture applicative............................................................................................32
Conclusion................................................................................................................................34
Chapitre III: Conception........................................................................................................35
1. Généralités sur le Datawarehouse.................................................................................36
2. Modélisation du datawarehouse....................................................................................36
Table des matières
2.1. Matrice d’expression des besoins.............................................................................36

2.2. Schéma dimensionnel...............................................................................................38
2.3. Modélisation des datamarts.......................................................................................38
2.3.1. Thème Emploi...................................................................................................38
2.3.2. Thème rémunération.........................................................................................41
2.3.3. Thème conditions de travail..............................................................................41
3. Conception des tableaux de bord..................................................................................43
3.1. Tableaux de bord "effectifs".....................................................................................43
3.2. Tableaux de bord "rémunération".............................................................................44
3.3. Tableaux de bord "conditions de travail"..................................................................45
Conclusion................................................................................................................................45
Chapitre IV : Mise en oeuvre.................................................................................................46
1. Réalisation de l’ETL.....................................................................................................47
1.1. Alimentation des tables de dimension......................................................................47
1.2. Alimentation des tables de faits................................................................................50
2. Cubes OLAP.................................................................................................................54
2.1. Création des cubes OLAP.........................................................................................54
2.2. Exemples de cubes OLAP créés...............................................................................57
3. Rapports........................................................................................................................60
3.1. Création des rapports................................................................................................60
3.2. Exemples de rapports statiques.................................................................................62
Conclusion................................................................................................................................66
Conclusion générale................................................................................................................67
Bibligraphie/Webographie.....................................................................................................68
Glossaire...................................................................................................................................69
Index.........................................................................................................................................73
Annexes....................................................................................................................................75
Annexe A : Plan Assurance Qualité......................................................................................77
Annexe B : Manuel de l’utilisateur........................................................................................84
Introduction générale
Le Système d’Information Ressources Humaines (SIRH) est devenu un outil incontournable

des professionnels de la gestion des ressources humaines. Avec un grand nombre de processus
automatisés, le SIRH permet d'effectuer de très importants gains de productivité. Il est
également une opportunité pour améliorer certains services que la DRH propose à ses clients
internes et ainsi crédibiliser son apport de valeur ajoutée au sein de l’entreprise.
Aujourd'hui, les entreprises sont dans la recherche de l'efficience de leurs RH. Elles ont
besoin de paramètres qui aident à prévenir les climats sociaux et à se prémunir contre
d’éventuels dérapages. D'où la quête incessante des entreprises d’enrichir leurs SIRH de
solutions de Business Intelligence (BI). En effet, mettre en place une plateforme décisionnelle
RH c’est mettre à la disposition de ses gestionnaires les informations pertinentes et précises
afin de leur permettre d’analyser toutes les composantes RH de leur organisation, de
comprendre le présent et d’organiser efficacement l’avenir de leur capital humain. C’est dans
ce cadre que la société Outsourcia qui utilise un SIRH pour la gestion de ses ressources
humaines a lancé notre projet de fin d’études pour s’offrir un outil de pilotage et d’aide à la
décision.
Notre projet consiste donc en la mise en œuvre d’un système décisionnel pour la fonction RH
d’Outsourcia. Notre champ d’implication couvre les trois thèmes : emploi, rémunération et
conditions de travail.
Ce mémoire présente les différentes étapes de réalisation de notre projet. Il se compose de

quatre chapitres dont la description est comme suit.
Le premier chapitre aborde le contexte général du projet. Il présente l’organisme d’accueil et

le SIRH qu’il utilise puis expose la motivation et les objectifs du projet. Ensuite, on passe à la
démarche suivie, le planning et les livrables attendus avant de terminer avec le Plan
Assurance Qualité.
Le deuxième chapitre est dédié à l’analyse et spécifications des besoins. Ce qui se traduit par
une étude de l’existant et ses limites et le recensement des différents besoins de la direction
des ressources humaines d’Outsourcia, pour arriver à un cadrage fonctionnel et technique de
la solution proposée.
Quant au troisième chapitre, il traite la conception du modèle multidimensionnel de notre

Datawarehouse et des tableaux de bord sur lesquels se base le reporting.
Le quatrième chapitre détaille la phase de la mise en œuvre du projet dans ses différentes
étapes à savoir l’alimentation du Datawarehouse et la création des cubes OLAP et des
rapports.
Pour clore ce mémoire, nous résumons les résultats et acquis réalisés lors de notre stage, les
difficultés rencontrées et des perspectives à ce travail.
Chapitre I: Contexte général
du projet
Ce chapitre a comme objectif de décrire le contexte général du projet, qui consiste en la mise
en œuvre d’un système décisionnel pour la fonction RH d’Outsourcia. Ainsi, nous allons en
premier lieu donner un aperçu sur l’organisme d’accueil et le système d’information
ressources humaines actuellement utilisé par la DRH afin d’avoir une idée claire sur les
raisons pour lesquelles ce projet a été choisi. Nous présenterons ensuite notre projet et ses
objectifs. Enfin, nous décrirons la démarche suivie, le planning et le plan assurance qualité
adoptés, et les livrables attendus.
Chapitre I: Contexte général du projet
1. Présentation d’Outsourcia
Outsourcia, pionner de l'offshore haut de gamme depuis 2003, est une société spécialisée dans
la gestion de la relation client, et l'externalisation offshore de processus métiers.
Ayant son siège social à Paris, Outsourcia dispose de plusieurs centres de contacts répartis
entre la France (Evreux et Région parisienne), et Casablanca au Maroc. La société offre des
prestations de service client, de support et de marketing téléphonique à forte valeur ajoutée
pour le compte de sociétés européennes de premier rang. Son offre couvre l'ensemble du cycle
de vie du client et prospect, avec une approche multilingue et multicanale. [Outsourcia]
Le groupe dispose de 600 positions sur ses 3 sites, en onshore et offshore.
Depuis sa création, cette jeune société a réalisé des chiffres d’affaires en augmentation
régulière chaque année comme le montre le tableau suivant :
Année Chiffre d’affaire (M.EURO)
2004 0,6
2005 1
2006 2,1
2007 2,6
2008 4,1
2009 4,5
Tableau 1: Chiffres d’affaires d’Outsourcia

Au sein d’un secteur majoritairement dominé par des acteurs étrangers, Outsourcia se
positionne comme le premier groupe marocain indépendant, disposant d’une offre globale
dans les métiers de l’offshoring :
Outsourcia Contact Center : Outsourcia Contact Center est le métier de base de la société.
A partir de ses centres de contact, Outsourcia Contact Center a développé une offre globale de
services permettant d’accompagner ses partenaires à chaque étape du cycle de vie de leurs
clients : avant-vente, vente, services clients, services après-vente, support technique et
commercial, ainsi que le marketing téléphonique et les études. Outsourcia Contact Center
opère en multilingue (français, anglais, espagnol, italien, néerlandais, allemand et portugais)
et en multicanal (contacts téléphoniques entrants et sortants, gestion des emails, des courriers
et solutions de live chat et de web call back).
Outsourcia BPO (Business Process Outsourcing) : Outsourcia BPO, créé en 2005, couvre
de nombreux domaines fonctionnels relatifs aux traitements administratifs, notamment en
matière de saisie et de conception de documents comptables.
Projet de Fin d’Etudes 17

ENSIAS 2010-2011
Outsourcia ITO (Information Technology Outsourcing) : Outsourcia ITO est une société de
services et développements informatiques offshore couvrant une très large gamme de
technologies actuelles. La société réalise des projets informatiques offshores en mode régie ou
forfait pour le compte de clients internationaux de premier rang, et propose des solutions
Open Sources opérationnelles alliant fiabilité et souplesse. [Outsourcia]
Offshore Academy : Offshore Academy est le premier centre de formation multilingue aux
métiers de l’offshoring et de la relation client au Maroc. Il a pour vocation d’accompagner les
professionnels des métiers de l’externalisation des Centres de contacts, du BPO et de l’ITO
dans l’ensemble de leurs problématiques de formation, tant au niveau de l’analyse des
besoins, de la conception de programmes personnalisés que de l’animation des sessions de
formation.
Mon stage de fin d’étude s’est déroulé au sein d’Outsourcia ITO.
2. SIRH d’Outsourcia
Rappelons qu’un Système d'Information Ressources Humaines (SIRH) est un système gérant
un ensemble de briques logicielles permettant d'automatiser un certain nombre de tâches liées
à la gestion des ressources humaines et d'en assurer un suivi.
Ces briques peuvent être de plusieurs sortes : gestion administrative du personnel, tableaux de
bord sociaux, plate-forme de formation, gestion des compétences et carrières, gestion de la
paie, gestion des temps et des activités... Un portail RH permet généralement aux différents
services concernés de travailler en mode collaboratif, tout en n'ayant accès qu'aux contenus
qui leur sont dédiés. [JNET]
L’adéquation des pratiques RH aux finalités stratégiques et, de fait, l’évaluation des processus
de gestion des ressources humaines prennent forme par l’usage du SIRH.
Les fonctionnalités couvertes sont nombreuses. On peut les classer en différentes familles.
Dans la première sont généralement regroupés les services liés aux tâches les plus
administratives, dans la deuxième sont rassemblés les services liés à la carrière du salarié et la
troisième contient ce qui a trait aux procédures internes, notes de service, entretiens annuels,
convocation médecine du travail, règlement interne, etc.
Outsourcia a démarré, depuis 2008, un projet ambitieux pour la mise en place de son SIRH.
C’est un système dédié à la gestion des ressources humaines, fonctionnant sur les différents
sites, au Maroc et en France pour une gestion optimisée des ressources humaines.
C’est une application web, multi société, composée des modules suivants :
 Administration du personnel : c’est un module qui permet de faire des demandes de
documents administratifs (certificat de travail, attestation de salaire, attestation
CNSS…), de surveiller les présences et les absences, de gérer les congés, de gérer les
arrêts maladie et de déclarer les sanctions.
 Gestion de la paie : elle consiste à faire des dépôts des justificatifs des primes, de
valider les remboursements de la mutuelle et les rappels sur salaire, de gérer les modes
de paiements et de traiter les salaires.

ENSIAS 2010-2011
 Gestion de la communication : ce module se préoccupe de gérer les boites aux lettres

des salariés, de créer et diffuser les notes d’information par les managers et de créer et
mettre en ligne des documents administratifs.
 Gestion des plannings : ce module permet aux managers de gérer leurs plannings de
production et de créer des plannings de congés.
La figure suivante montre l’écran d’accueil du SIRH d’Outsourcia:
Figure 1: Ecran d’accueil du SIRH d’Outsourcia
3. Motivation et objectifs du projet

Le SIRH actuel d’Outsourcia intégre uniquement les modules décrits précédemment. Dans le
but d’étendre et d’améliorer son SIRH, Outsourcia vise réaliser de nouvelles briques qui sont
le module de l’Hygiène Sécurité Qualité et un module décisionnel pour les briques actuelles et
celles en vue. La DRH à travers son Directeur monsieur Didier TOULOUSE, et dans le cadre
de ce projet de fin d’étude, m’a confié la mise en œuvre du lot décisionnel pour les briques
actuelles. Ce travail pourra servir aussi pour les briques décisionnelles futures. En effet vu la
criticité et l’importance des RH pour la société, le besoin de ce lot décisionnel est devenu une
nécessité à laquelle il faut donner de la priorité.
Le SIRH actuel ne fournit aucun outil pour la réalisation de tableaux de bord et la génération
de rapports synthétisés pour les briques RH déjà couvertes. Notre projet vient pour répondre

ENSIAS 2010-2011
à ces besoins. Son but est de définir les indicateurs et de générer les tableaux de bord et les
rapports qui offrent une meilleure visibilité sur la fonction RH et qui mettent à disposition
l’information essentielle pour la prise de décision relativement aux thèmes emploi,
rémunération et conditions de travail.
Les tableaux de bord à générer visent :
 le suivi des états des effectifs et des mouvements du personnel afin de mesurer
l’évolution des effectifs et de déduire le degré de satisfaction professionnelles des
salariés;
 le suivi des absences afin de les diminuer ;
 le suivi des rémunérations et des primes pour savoir combien consomme chaque
service ou chaque opération ;
 le suivi des horaires et des congés.
4. Conduite du projet
1.1. Démarche
Notre projet étant à caractère décisionnel, pour sa conduite, nous allons suivre le cycle de vie
dimensionnel. Ce cycle commence par la planification du projet puis passe à la définition des
besoins qui constituent le point de départ de trois trajectoires parallèles qui sont la
technologie, les données et l’interface utilisateur. Ces trajectoires se rejoignent en phase de
déploiement qui est suivie par la phase de maintenance et croissance.
Le schéma ci-dessous représente la succession des tâches de haut niveau nécessaires à la
conception, au développement et au déploiement d’entrepôts de données efficaces. [Kimball
2001]
Figure 2: Schéma du cycle de vie dimensionnel
Les étapes de la figure ci-dessus sont :

ENSIAS 2010-2011
Planification du projet : aborde la définition et l’étendue du projet. Elle permet l’affectation

des tâches à leurs durées et à leur séquencement.
Définition des besoins : permet d’identifier les besoins de l’entreprise et détermine les
données requises pour répondre aux besoins d’analyse des utilisateurs.
Modélisation dimensionnelle : commence par la construction d’une matrice qui représente
les processus métiers clé et leurs dimensionnalités. A partir de cette matrice, on élabore une
analyse plus détaillée des données des systèmes sources, puis on développe le modèle
dimensionnel.
Conception du modèle physique : définit les structures nécessaires pour l’implémentation du
modèle dimensionnel. Cette étape nécessite la détermination des règles de nommage des
objets et la mise en place de l’environnement de la base de données.
Conception et le développement de la zone de préparation des données : se déroule en
trois phases majeures : Extraction, Transformation et Chargement.
Définition de l’architecture technique : permet d’avoir une vision globale de l’architecture
technique à mettre en œuvre. Dans cette phase, trois facteurs doivent être pris en compte : les
besoins, l’environnement existant et les orientations techniques stratégiques planifiées.
Sélection des produits et l’installation : permet la sélection des composants spécifiques tels
que la plateforme matérielle, le SGBD (Système de Gestion de Bases de Données), et les
outils de préparation et d’accès aux données. Une fois évalués et sélectionnés, ceux-ci devront
être installés et testés minutieusement.
Spécifications de l’application utilisateur : décrit les maquettes d'états, les critères de
sélection laissés à l'utilisateur et les calculs nécessaires.
Développement de l’application utilisateur : commence par une compréhension commune
par l’équipe de développement et les utilisateurs finaux des spécifications établies.
Déploiement : est le point de convergence de la technologie, des données et des applications
utilisateur. Une formation des utilisateurs est nécessaire. Elle intègre tous les aspects de cette
convergence avant de permettre à ceux-ci d’accéder à l’application. La prise en compte des
demandes d’évolution et de correction est également indispensable.
Maintenance et croissance : permet de s’occuper des utilisateurs en leur procurant un service
de support et une formation continue.
Gestion du projet : garantit que les activités du cycle de vie dimensionnel restent sur la
bonne voie et sont bien synchronisées.
1.2. Planning
La planification du projet découle du cycle de vie dimensionnel, décrit auparavant, afin de
placer les éléments du projet dans le bon ordre au bon moment.
Le projet est découpé en phases chronologiques et organisationnelles, qui elles aussi sont
découpées en tâches pour faciliter l’estimation du temps de réalisation du projet.

ENSIAS 2010-2011
La répartition des tâches à accomplir, leurs durées et leur succession sont décrites dans le diagramme de GANTT présenté ci-dessous.
Figure 3: Diagramme GANTT du projet
Projet de Fin d’Etudes 22 ENSIAS

2010-2011
1.3. Livrables
Pour chaque étape du diagramme de GANTT, une remise de livrables est nécessaire, afin
d’assurer la traçabilité du projet et de bien mener la communication avec les utilisateurs pour
pouvoir valider chaque étape. Le tableau ci-dessous montre les livrables de chaque phase.
Phase Livrables
Planification du projet Planning et méthodologie de conduite du projet
Etude et définitions des besoins Cahier des charges

Dossiers des spécifications fonctionnelles
détaillées
PAQ (Plan Assurance Qualité)
Architecture technique Dossier des spécifications techniques détaillées

PAQ mis à jour
Modélisation multidimensionnelle Dossier conceptuel

Matrice mesure/dimension
Modèle logique du Datawarehouse
Modèle physique du Datawarehouse
PAQ mis à jour
Conception de l’application utilisateur Dossier de description des cubes OLAP

Dossier de description des rapports
Test et déploiement Rapports et scénarii des tests

Manuel d’utilisation
Maintenance et croissance Manuel d’utilisation mis à jour
Tableau 2: Livrables du projet
1.4. Plan Assurance qualité

Le PAQ définit les méthodes, l'organisation et les activités d'assurance et de contrôle de la
qualité spécifique au projet.
L'utilisation du PAQ doit permettre d'atteindre les objectifs suivants :
 Constituer une référence commune à tous les intervenants du projet. Il permettra
d'assurer une bonne cohérence et une homogénéité dans les méthodes de travail.
Projet de Fin d’Etudes ENSIAS

2010-2011 23
 Garantir la qualité du produit. Cette qualité s'exprime par des critères à respecter dans
le cadre de ce projet.
 Définir les procédures à suivre, les outils à utiliser, les normes à respecter, la
méthodologie de développement du produit et les contrôles prévues pour chaque
activité.
Le PAQ est utilisé tout au long du projet. Il est donc destiné à être constamment ajusté en
fonction des circonstances, selon une procédure d’actions correctrices définies dans ce
document.
Ce document est élaboré dans la phase d’étude et recueil des besoins et il est mis à jour par la
suite à la fin de chaque phase du projet.
Conclusion
Dans ce chapitre nous avons donné une présentation générale de notre projet de fin d’étude
qui consiste en la mise en œuvre d’un système décisionnel concernant les fonctions RH
couvertes par le SIRH actuel d’Outsourcia. Il s’agit précisément de définir les indicateurs et
de générer les tableaux de bord et les rapports qui offrent une meilleure visibilité sur la
fonction RH et qui mettent à disposition de la DRH l’information essentielle pour la prise de
décision relativement aux thèmes emploi, rémunération et conditions de travail. Vu le
caractère décisionnel du projet, nous avons aussi expliqué dans ce chapitre la démarche à
suivre qui respecte les différentes étapes du cycle dimensionnel, depuis l’analyse et
spécifications des besoins jusqu’au déploiement en passant par l’alimentation du
Datawarehouse. Enfin nous avons proposé un planning pour le déroulement de notre projet,
ainsi qu’un plan assurance qualité.
Il convient maintenant d’attaquer le premier volet cité dans notre démarche à savoir l’analyse
et spécifications des besoins ce qui est l’objet du chapitre suivant.

2010-2011 24
Chapitre II: Analyse et
spécifications
Le but de ce chapitre est d’aboutir à un cadrage fonctionnel et technique de notre projet.

Ainsi, nous allons d’abord commencer par une description de l’existant en termes de sources
de données et de reporting utilisé. Une critique de cet existant permettra de situer les
problématiques et limites relativement à ces deux derniers volets. Nous passerons ensuite au
recueil des besoins afin de remédier à ces défaillances et de garantir la couverture de
l’ensemble des processus métiers inclus dans le périmètre de notre projet notamment en
matière d’indicateurs et d’axes d’analyse de la solution décisionnelle envisagée. Nous
terminerons ce chapitre en précisant une architecture applicative adéquate à notre solution.

2010-2011 25
Chapitre II: Analyse et spécifications
1. Étude de l’existant
1.1. Description de l’existant
Dans cette section, nous décrivons l'existant en termes de sources de données ainsi que l'outil
de reporting utilisé auparavant par la DRH.
 Sources de données :
L’étude des différentes sources de données est une phase très importante afin de choisir les
tables qui contiennent les données nécessaires à la conception de notre système décisionnel.
Les sources de données sont :
 La base de données SIRHV1 du SIRH qui contient plus de 200 tables. Cette base
est gérée par le SGBD MySQL.
 Le grand livre de la paie qui est un fichier Excel généré, à la fin de chaque mois, à
partir de Sage paie qui est un logiciel permettant la gestion de la paie des salariés.
 Reporting utilisé :
Pour avoir une visibilité sur la fonction RH, la direction des ressources humaines utilise
actuellement des rapports. Pour chaque rapport, l’utilisateur cherche les données nécessaires
dans les différentes sources de données. Il les exporte ensuite vers un fichier Excel où il
indique les calculs à faire. La figure ci-dessous montre un exemple de rapport élaboré avec
Excel.
Figure 4: Exemple de rapport élaboré avec Excel

2010-2011 26
1.2. Critique de l’existant

La phase de l’étude de l’existent a permis d’examiner de près les données manipulées par la
DRH d’Outsourcia, Ces données sont multiples, éparpillées et non consolidées. Elles
présentent aussi une certaine incohérence due à la redondance de certains enregistrements. Par
conséquent, on peut dire que la direction des ressources humaines ne dispose pas d’une base
de données fiable, contenant toute l’information nécessaire à la production de rapports d’aide
à la décision pour la DRH.
Le reporting utilisé n’est pas automatisé. Il est très coûteux en termes de temps et suit une
démarche basique et manuelle. Ce qui peut être la source de plusieurs erreurs de saisie ou de
calcul. En outre, ce reporting ne permet pas d’effectuer des analyses permettant de faciliter la
prise de décision par la DRH. Il offre seulement des rapports statiques. Enfin ce reporting ne
répond pas aux besoins des utilisateurs en termes de fiabilité, d’analyse et de pertinence des
données.
Notre travail vient pour remédier à ces problèmes en proposant une solution décisionnelle
adéquate que nous détaillerons dans ce qui suit.
2. Recueil des besoins

Le but de la phase de recueil des besoins est de garantir la couverture fonctionnelle de
l’ensemble des processus métiers inclus dans le périmètre du projet. Il importe donc de faire
un balayage global des besoins définis dans le cahier des charges. En effet, ces besoins ont été
complétés et modifiés tout au long des réunions effectuées avec les gens du métier.
2.1. Besoins principaux

 Centralisation des sources de données dans un Data Warehouse :
Puisque les données sont stockées dans différents emplacements, leur consolidation dans un
Data Warehouse s’avère primordiale. Ce qui permettra de répondre aux besoins de facilité et
de rapidité d’accès aux informations. Ce Data Warehouse constituera une archive riche des
données de la direction des ressources humaines.
 Génération des tableaux de bord selon les critères des utilisateurs :
Une fois les données stockées dans le Data Warehouse et les indicateurs sont chargés, les
données seront ensuite publiées sous forme de tableaux de bord. Afin d’avoir des
informations précises, les utilisateurs demandent la génération de rapports en précisant la
distribution des indicateurs et des axes d’analyse sur les tableaux de bord.
 Facilité d’accès aux données :
Les tableaux de bord seront générés dans le même serveur utilisé par le SIRH. Ainsi, les
utilisateurs auront un environnement auquel ils sont habitués.

2010-2011 27
2.2. Besoins secondaires

 Diffusion et partage des informations
La diffusion et le partage des rapports seront assurés grâce à la suite logicielle décisionnelle
open source Pentaho via une interface Web.
 Génération des états pour impression
Les utilisateurs ont besoin d’imprimer les rapports sous des formats prédéfinis pour simplifier
l’échange (Word, PDF, Excel…).
3. Cadrage fonctionnel du projet

En décisionnel, Le but du cadrage fonctionnel est de combler les besoins fonctionnels de notre
projet en termes d’indicateurs et d’axes d’analyse. Il s’agit de décrire les indicateurs et axes
d’analyse fixés par la DRH relativement aux thèmes emploi, rémunération et conditions de
travail.
3.1. Description des indicateurs

Suite aux réunions avec les gens du métier, nous avons pu fixer les principaux indicateurs
ayant un enjeu relatif à la prise de décision.
3.1.1. Indicateurs "emploi"
Les indicateurs relatifs à l’emploi peuvent être divisés en trois classes :

 Indicateurs "effectifs"
Ces indicateurs permettent de mesurer l’évolution des effectifs d’Outsourcia et d’avoir une
vue globale sur les ressources que la société possède. Le tableau 3 présente les différentes
propriétés des trois indicateurs "effectifs".
Indicateurs Effectif % Effectif Effectif moyen

Propriétés
Définition Le nombre de salariés de Le pourcentage des La moyenne des effectifs

l’entreprise salariés de l’entreprise de deux périodes (mois,
selon l’axe d’analyse année) successives
Enjeu Mesurer l’évolution de Mesurer la répartition des Mesurer l’évolution des

l’effectif de l’entreprise salariés de l’entreprise effectifs moyens de
selon chaque axe l’entreprise
d’analyse
Périodicité Mensuel, annuel

2010-2011 28
Règle de gestion Calculer le nombre des Diviser un effectif Diviser la somme des
salariés correspondant à un ou effectifs de deux périodes
plusieurs axes d’analyse (mois, année) successives
par l’effectif total par deux
Source Base de données : SIRHV1

Tables : Agents, fonction, nationalité
Axes d’analyse Temps, sexe, statut marital, niveau d’étude, ancienneté, tranche d’âge, métier,
nationalité
Tableau 3: Indicateurs "effectifs"

 Indicateurs "flux"
Le tableau 4 présente en détail les indicateurs des flux qui permettent de suivre l’évolution des
embauches et des départs au sein d’Outsourcia.
Indicateurs Nombre des Nombre des Taux de Taux de Turn over

embauches départs départs subis départs
Propriétés
voulus
Définition Le nombre des Le nombre des Le taux des Le taux des Le renouvellement du
personnes salariés qui ont démissions et des licenciements et personnel de
embauchées quitté l’entreprise abandons de poste des ruptures de l’entreprise
période d’essai
Enjeu Suivre l’évolution Mesurer le nombre Connaitre le Connaitre le Suivre le rythme du

des nombres des démissions, niveau du taux de niveau du taux de renouvellement des
d’embauches abandons de poste, départs subis afin départs voulus en effectifs de
licenciements et d’en analyser les vue de le l’entreprise
ruptures des causes diminuer
périodes d’essai en
vue de le diminuer
Règle de gestion Calculer le nombre Calculer le nombre Diviser la somme Diviser la somme i. Diviser la somme
des salariés dont la des salariés dont la des démissions et des licenciements du nombre des
date d’entrée date de sortie des abandons de et des ruptures de embauches et des
correspond à la correspond à la poste par l’effectif période d’essai départs de la période
période choisie période choisie de la période par l’effectif de la choisie par 2
choisie période choisie
ii. Diviser le premier
résultat par l’effectif
de la période choisie
Source Base de données : SIRHV1

Table : Agents, nationalité, fonction, opération, tranche d’ancienneté
Axes d’analyse Temps, métier, Temps, métier, sexe, tranche d’ancienneté Temps, métier, sexe
sexe, nationalité,
opération
Tableau 4: Indicateurs "flux"

2010-2011 29
 Indicateurs "absentéisme"
Cette série d’indicateurs, concernant l’absentéisme, permet de le diminuer et d’en analyser les
causes.
Indicateurs Nombre des jours Taux d’absentéisme Taux d’assiduité

d’absence
Propriétés
Définition Le nombre des jours Le rapport du nombre de Le taux d’assiduité du

d’absence des salariés jours d’absence et du personnel
nombre de jours travaillés
Enjeu Mesurer le nombre de Evaluer l’absentéisme du Mesurer l’assiduité du

jours d’absence et en personnel par rapport au personnel
analyser les motifs nombre de jours travaillés
afin de le diminuer
Règle de gestion Calculer la somme des Diviser le nombre de Diviser la différence du

nombres de jours jours d’absence par le nombre de jours travaillés
d’absence des salariés nombre de jours travaillés et le nombre de jours
de la période choisie d’absence par le nombre
de jours travaillés de la
période choisie
Source Base de données: SIRHV1

Tables : absence, motif_absence, retour_absence, agent, fonction
Axes d’analyse Temps, décision Temps, métier, salarié

d’absence, motif
d’absence, métier, salarié
Tableau 5: Indicateurs "absentéisme"
3.1.2. Indicateurs "rémunération"

Ces indicateurs permettent d’évaluer et d’améliorer l’efficacité de la gestion de la
rémunération.
Indicateurs Masse salariale Rémunération Prime moyenne Ratio salaire

moyenne
Propriétés
Définition L’ensemble de La moyenne des La moyenne des Rapport entre la

toutes les charges se rémunérations des montants par type de moyenne des salaires
rattachant à la salariés primes les plus élevés et des
rémunération des salaires les plus
salariés faibles
Enjeu Mesurer l’évolution Evaluer la Evaluer le montant de Mesurer le rapport

de la masse salariale rémunération la prime moyenne entre les salaires les
pour concourir à sa moyenne plus élevés et les plus
maîtrise faibles

2010-2011 30
Règle de gestion Calculer la somme Diviser la somme des Diviser la somme des Diviser la moyenne
des coûts totaux nets à payer par montants de chaque des salaires les plus
entreprise de tous l’effectif de la type de prime par élevés par la moyenne
les salariés de la période choisie l’effectif de la période des salaires les plus
période choisie choisie faibles de la période
choisie
Source Fichier Excel: Le grand livre de la paie

Base de données : SIRHV1
Tables : agent, fonction, opération
Axes d’analyse Temps, métier, sexe, opération Temps, prime Temps, métier
Tableau 6: Indicateurs "rémunération"
3.1.3. Indicateurs "conditions de travail"

Les indicateurs des conditions de travail sont également divisés en deux séries :
 Indicateurs "congés"
Cette série d’indicateurs a comme objectif d’évaluer les coûts des congés. Ils sont décrts dans
le tableau ci-dessous.
Indicateurs Coût des congés payés Coût des jours fériés travaillés
Propriétés
Définition Montant d’indemnisation des congés Montant d’indemnisation des jours fériés
payés travaillés
Enjeu Mesurer les coûts des congés payés Evaluer les coûts des jours fériés travaillés
Règle de gestion Sommer les montants d’indemnisation Sommer les montants d’indemnisation des
des congés payés de la période choisie jours fériés travaillés

Axes d’analyse Temps, métier, opération
Tableau 7: Indicateurs "congés"

2010-2011 31
 Indicateurs "heures supplémentaires"
Ces indicateurs permettent de connaitre le coût des heures supplémentaires.
Indicateurs Coût des heures Coût des heures supplémentaires

supplémentaires à 25% à 100%
Propriétés
Définition Montant d’indemnisation des heures Montant d’indemnisation des heures

supplémentaires à 25% supplémentaires à 100%
Enjeu Mesurer les coûts des heures Evaluer les coûts des heures
supplémentaires à 25% supplémentaires à 100%
Règle de gestion Sommer les montants d’indemnisation Sommer les montants d’indemnisation des
des heures supplémentaires à 25% heures supplémentaires à 100%

Axes d’analyse Temps, métier, opération
Tableau 8: Indicateurs "heures supplémentaires"
3.2. Description des axes d’analyse

Chacun des indicateurs relevés est analysé selon un certain nombre d’axes. Le tableau ci-
dessous définit l’ensemble de ces axes d’analyse en précisant pour chacun les différents
niveaux d’hiérarchie.
Axe Description Niveaux

Temps La dimension temps Année
Mois
Jour
Sexe Le sexe d’un salarié Homme/Femme Sexe
Statut marital Célibataire, marié, divorcé Statut marital
Niveau d’étude Niveau BAC, BAC&BAC+1, Niveau d’étude
BAC+2&BAC+3, BAC+4&BAC+5, PLUS
BAC+5
Tranche Moins de 6 mois, De 6 mois à 12 mois, De Ancienneté
d’ancienneté 12 mois à 18 mois, De 18 mois et plus
Tranche d’âge Moins de 20 ans, DE 20 ans à 25ans, DE Tranche d’âge

25 ans à 30ans, DE 30 ans à 40ans, DE 40
ans et plus

2010-2011 32
Métier Le métier du salarié Service

Catégorie
Métier
Nationalité La nationalité du salarié Nationalité
Décision Absence justifiée ou non justifiée Décision
d’absence
Motif Le motif de l’absence Motif d’absence
d’absence
Opération Une opération d’un client Client
Opération
Prime Le type de la prime Prime
Salarié Le nom du salarié Manager
Salarié
Tableau 9: Axes d’analyse
4. Cadrage technique
4.1. Macro Architecture
Cette architecture respecte la décomposition habituelle de l’architecture constitutive d’un
système décisionnel, qui comporte :
 la phase d'extraction et de transformation des données :
Périodiquement et sur la base des flux de données reçus, des extractions seront réalisées par
l'ETL (Extract Transform Load). Ces données extraites subiront par la suite un ensemble de
transformations (nettoyage, unification, mise en forme, etc.).
 la phase de chargement et stockage des données :
Après avoir effectué les traitements nécessaires, les données manipulées seront ensuite
chargées grâce à l’ETL pour être stockées dans notre Data Warehouse.
 La phase de restitution et d'analyse :
C’est à ce point que sont calculés les indicateurs, fournissant ainsi des informations de valeur.
Ces informations sont ensuite restituées sous forme de tableaux de bord.
4.2. Architecture applicative

 Alimentation
Pour la préparation de données, nous avons choisi comme outil ETL le logiciel Talend qui est
un ETL de type « générateur de code ». En fait, il permet de créer graphiquement des
processus de manipulation et de transformation de données puis de générer l’exécutable
correspondant sous forme de programme Java ou Perl. [Smile]

2010-2011 33
Périodiquement, des scripts ETL sont exécutés afin d’alimenter notre Data Warehouse à partir
des sources de données.
 Stockage
Les données seront stockées dans le SGBD relationnel MySQL selon le mode de stockage
ROLAP. Le principe de ROLAP est de conserver toutes les données brutes dans une base de
données relationnelles et de calculer les agrégats par des requêtes SQL. ROLAP permet le
stockage d’un grand volume de données.
 Analyse
Une fois notre Data Warehouse alimenté par l’outil ETL, on peut créer des cubes OLAP qui
permettent de faire des analyses multidimensionnelles et dynamiques. Pour la création des
cubes, nous allons utiliser le composant Pentaho Analysis de la suite Pentaho BI. Ce dernier
est composé d’un serveur OLAP connu sous le nom de Mondrian et d’un client permettant
l’accès à ce moteur connu sous le nom de JPivot.
Les dimensions et mesures gérées par Mondrian sont stockées uniquement dans la base de
données relationnelle. Mondrian lit ces informations au moment où une première requête lui
parvient afin de les charger en mémoire. Il va ensuite servir les autres requêtes uniquement
depuis ces informations stockées en mémoire. Une fois le serveur déconnecté les données se
trouvant dans la mémoire Mondrian disparaissent pour se retrouver uniquement dans la base
de données relationnelle.
 Restitution
L’outil de restitution utilisé dans notre projet est le logiciel BIRT (Business Intelligence and
Reporting Tool). Nous avons choisi cet outil car la majorité des rapports à réaliser sont sous
forme de tableaux croisés dynamiques. En effet, BIRT permet la création de ce genre de
rapports, contrairement au Report Designer de Pentaho.
BIRT est un projet de la communauté Eclipse comprenant un générateur de graphiques, un
générateur de rapports et un environnement de conception. [LBSMILE]
L’intégration des rapports de BIRT dans la plateforme de Pentaho se fait grâce au BIRT
Viewer. C’est un lecteur de rapports qui permet d’interpréter un fichier dont l’extension est
.rptdesign, et de le restituer sous format HTML.
 Publication
La publication des rapports et des tableaux de bord se fait grâce à la console Utilisateur de
Pentaho qui est une interface web qui permet à un utilisateur métier d'accéder à l'ensemble des
ressources décisionnelles : rapports, tableaux de bords, indicateurs, analyses
multidimensionnelles.
La figure 5 suivante résume l’architecture applicative adoptée pour notre solution.

2010-2011 34
Figure 5: Architecture applicative
Conclusion
Dans ce chapitre, nous avons pu voir que la direction des ressources humaines d’Outsourcia
ne dispose pas d’une base de données fiable, contenant toute l’information nécessaire à la
production de rapports d’aide à la décision. Les rapports actuels utilisés au sein de la DRH
d’Outsourcia sous le tableur Excel, exigent une longue démarche très coûteuse en termes de
temps et ne répondent pas aux besoins des utilisateurs en termes d’analyse et de pertinence
des données.
Suite à plusieurs réunions avec le DRH et des responsables métier, nous avons pu recueillir
les besoins de l’entreprise en termes de données et de reporting. Nous avons ensuite arrêté en
particulier les indicateurs ayant un certain enjeu décisionnel relativement aux thèmes emploi,
rémunération et conditions de travail, tout en précisant leurs axes d’analyse. Enfin, nous
avons défini la macro architecture de notre solution empreinte du cycle dimensionnel et
précisé les outils décisionnels adoptés.
Les tâches précisées précédemment constituent l’étape d’analyse et de collecte des besoins,
étape cruciale pour le bon déroulement du projet. La définition précise, la collecte fidèle des
données lors de ces tâches nous a facilité grandement la phase de conception présentée dans le
chapitre suivant.

2010-2011 35
Chapitre III : Conception
Chapitre III: Conception
Une fois les besoins définis et analysés, la phase de conception est l’étape suivante dans le
cycle dimensionnel. Le but de cette phase est de modéliser les différentes couches du système
décisionnel cible. Ainsi, dans ce chapitre, nous présenterons des généralités sur le Data
Warehouse et la démarche suivie pour le concevoir. Nous détaillerons ensuite les différents
Datamarts conçus. Nous y décrirons enfin la conception de nos tableaux de bord en spécifiant
pour chacun les indicateurs et les axes d’analyse mis en jeu.

2010-2011 36
1. Généralités sur le Datawarehouse

Le Data Warehouse est une collection de données intégrées, orientées sujet, non volatiles,
historisées, résumées et disponibles pour l’interrogation et l’analyse. [INMO]
Il permet de stocker des données nécessaires à la prise de décision. Les données d’un Entrepôt
de données respectent donc les caractéristiques suivantes:
-Intégrées: Les données de l’entrepôt proviennent de différentes sources de données et
peuvent exister sous différentes formes. Ainsi, il faut les intégrer afin de les homogénéiser.
-Orientées sujet: Les données de l’entrepôt sont structurées par thèmes (les sujets majeurs de
l’entreprise).
-Historisées: Le Data Warehouse stocke l’historique des valeurs que la donnée aura prises au
cours du temps.
-Non volatiles: Les données de l’entrepôt sont très rarement modifiées, la non volatilité des
données est en quelque sorte une conséquence de l’historisation.
-Résumées: Les informations qui proviennent des sources de données doivent être agrégées
(ou résumées) afin de faciliter le processus de prise de décision.
 Approche de conception du Datawarehouse
Les deux approches les plus connues en conception de Data Warehouse sont :
 L’approche basée sur les besoins d’analyse
 L’approche basée sur les sources des données
L’approche la plus convenable à notre projet est celle basée sur les besoins d’analyse. Elle est
aussi appelée « approche descendante » (Top-Down Approach) et est proposée par Ralph
KIMBALL.
Pour Ralph KIMBALL, le data warehouse est constitué de l’agrégation des différents
Datamarts. Les Datamarts sont les subdivisions logiques du Data Warehouse. KIMBALL met
en avant le développement itératif et incrémental du Data Warehouse, chaque itération devant
correspondre au traitement d’un sujet particulier et donc à la création d’un nouveau Datamart.
Les datamarts sont placés au centre de l’architecture. Le reste sera composé d’un staging area
temporaire. Ce dernier est la zone où la plupart des opérations de nettoyage et de préparation
des données ont lieu avant leur chargement dans le Datawarehouse. Le staging area est dit
temporaire car les données sont détruites une fois le chargement des datamarts terminé.
2. Modélisation du datawarehouse
2.1. Matrice d’expression des besoins
A partir des besoins répertoriés dans le deuxième chapitre, nous avons lié chaque indicateur à
un certain nombre d’axes d’analyse recensés. Le tableau 10 présente la matrice des liaisons
relevées. Cette matrice permet de faciliter la conception du Datawarehouse.

2010-2011 37
Axes d’analyse Sexe Statut Niveau Tranche Tranche Métier Nationalité Décision Motif Opération Salarié Prime Temps
marital d’étude d’ancienneté d’âge absence d’absence
Indicateurs
Effectif X X X X X X X X
% Effectif X X X X X X X X
Effectif moyen X X X X X X X X
Nombre d’embauches X X X X X
Nombres de départs X X X X
Taux de départs subis X X X X
Taux de départs voulus X X X X
Turn over X X X X
Nombre de jours X X X X X
d’absence
Taux d’absentéisme X X X
Taux d’assiduité X X X
Masse salariale X X X X
Rémunération moyenne X X X X
Prime moyenne X X
Ratio salaire X X
Coût heures X X X
supplémentaires à 25%
Coût heures X X X
supplémentaires à 100%
Coût congés payés X X X
Coût jours fériés X X X
travaillés
Tableau 10: Matrice d’expression des besoins

38
2010-2011
2.2. Schéma dimensionnel

Un datamart, ou magasin de données, permet de stocker toute l’information utile, relative à un
thème précis. Avant d’être intégrée dans le magasin de données, l’information est tout d’abord
extraite des bases sources et nettoyée. Puis, elle est mise en forme de manière à l’adapter aux
besoins de l’utilisateur final. Cette mise en forme passe par la modélisation des données en
schémas dimensionnels plus proches des utilisateurs finaux et adaptés à leurs besoins.
Pour cela, nous passons par une modélisation des données en un schéma dimensionnel, car
elle est la plus appropriée aux requêtes et analyses effectuées sur les entrepôts de données.
Elle est simple à créer, stable et intuitivement compréhensible par les utilisateurs finaux. Un
schéma dimensionnel consiste en une ou plusieurs « tables de faits » qui contiennent les faits
ou les mesures à calculer. Ces mesures serviront plus tard à calculer les indicateurs dont nous
avons besoin. Ces tables de faits sont entourées par d’autres tables, appelées « dimensions »,
qui contiennent les éléments descriptifs des faits. En effet, le modèle ressemble à une étoile.
2.3. Modélisation des datamarts

Toutes les mesures de nos tables de faits sont calculées par rapport aux axes d’analyse
recensés dans la phase d’étude des besoins et qui sont modélisés sous forme de tables de
dimension. Pour chaque table de dimension, nous avons créé une clé primaire, appelée clé
technique, différente de celle de la table source, appelée clé fonctionnelle. La clé technique est
une séquence qui s’auto-incrémente et sert à indexer les enregistrements de la dimension et à
améliorer la performance de la recherche. Nous avons toutefois gardé la clé fonctionnelle
pour permettre les futures jointures.
On va présenter dans ce qui suit les datamarts conçus dans notre projet.
2.3.1. Thème Emploi
1.1.1.1 Sous-thème effectifs

Le schéma en étoile des effectifs a comme mesures : effectif, % effectif et effectif moyen.

2010-2011 39
Figure 6: Datamart effectifs
1.1.1.2 Sous-thèmes flux

Le sous thèmes flux comporte les datamarts embauches et sorties. Le datamart embauches a
comme mesure le nombre d’embauches.
Figure 7: Datamart embauches

2010-2011 40
Le datamart sorties a 3 mesures : Le nombre de départ, le taux de départs subis, le taux de

départs voulus et le turnover.
1.1.1.3
Figure 8: Datamart sorties
1.1.1.4 Sous thème absentéisme

Le datamart de l’absentéisme est présenté dans la figure suivante. Ce datamart contient les
mesures : nombre de jours d’absence, taux d’absentéisme et taux d’assiduité.
Figure 9: Datamart absentéisme

2010-2011 41
2.3.2. Thème rémunération

Le thème rémunération est modélisé avec un schéma dimensionnel composé de deux tables
de faits : TF_rémunération et TF_prime
TF_rémunération contient les mesures : coût total, net à payer, masse salariale, rémunération
moyenne et ratio salaire. TF_prime contient les mesures : montant prime et prime moyenne.
Figure 10: Datamart rémunération
2.3.3. Thème conditions de travail
1.1.1.5 Sous thème heures supplémentaires

Le datamart heures supplémentaires a comme mesures : coût des heures supplémentaires à
25% et coût des heures supplémentaires à 100%. Ce datamart est illustré dans la figure
suivante

2010-2011 42
Figure 11: Datamart heures supplémentaires
1.1.1.6 Sous thème congés

Le dernier datamart est celui des congés. Il contient les mesures :
Figure 12: Datamart congés

2010-2011 43
3. Conception des tableaux de bord

Le modèle du datamart établi ne suffit pas pour clôturer la phase de conception et passer à la
réalisation. En effet, il nous faut décider de la meilleure manière de présenter les indicateurs
relevés à l’utilisateur final. Cette présentation doit se faire de la façon la plus simple et la plus
expressive possible [BEN]. Ainsi, nous avons conçu plusieurs tableaux de bord dont chacun a
un objectif précis. Les données, relatives à un indicateur, sont affichées dans la plupart du
temps sous forme de tableaux croisés, mais nous avons également introduit des graphiques.
Les tableaux ci-dessous résument la conception des tableaux de bord à réaliser. Pour chaque
tableau de bord, nous avons indiqué l’indicateur et les axes d’analyse concernés. Nous avons
également explicité l’objectif et les résultats attendus de chacun.
3.1. Tableaux de bord "effectifs"

Le tableau ci-dessous présente le tableau de bord des effectifs.
N° du Intitulé du tableau Indicateurs Axes d’analyse Objectifs et résultats

de bord attendus
tableau
de bord
 Connaitre le nombre et la
Effectif Temps
répartition des salariés
Sexe pour avoir une vue
Statut marital globale sur les ressources
que la société possèdent
1 Ventilation des % Effectif Niveau d’études  Suivre le comportement
effectifs des effectifs
Tranche
d’ancienneté
Tranche d’âge
Effectif moyen
Métier
Nationalité
 Suivre les embauches par
Nombre Temps
métier, sexe et nationalité
d’embauches
2 Embauches Métier
Sexe
Nationalité
 Connaitre le nombre de
Nombre des départs Temps
départs subis et des
Métier départs voulus.
Taux de départs
Nombre et taux de Sexe  Evaluer les taux de
3 subis
départs départs subis et voulus
Motif de sortie afin de les diminuer
Taux de départs
voulus Tranche
d’ancienneté

2010-2011 44
 Connaitre et suivre le
Temps
niveau de stabilité des
4 Turn over Turn over Métier salariés
Sexe
 Connaitre le nombre de
Temps
jours d’absence et en
5 Nombres des absences Nombre des absences Décision absence analyser les motifs
Motif d’absence
Métier
 Evaluer l’absentéisme du
6 Taux d’absentéisme Taux d’absentéisme Temps
personnel par rapport au
Métier nombre de jours travaillés
Tableau 11: Tableaux de bord "effectifs"
3.2. Tableaux de bord "rémunération"

Le tableau 5 liste les trois tableaux de bord de la rémunération, en présentant les indicateurs
traités par chacun et les axes d’analyses utilisés.
N° du Intitulé du tableau Indicateurs Axes d’analyse Objectifs et résultats

de bord attendus
tableau
de bord
 Mesurer l’évolution de la
Evaluation de la Masse salariale Temps
masse salariale et la
rémunération moyenne rémunération moyenne
7 Métier
et la masse salariale
Rémunération Sexe
moyenne Client
 Suivre la prime moyenne
8 Prime moyenne Prime moyenne Temps
Prime
 Connaitre et suivre le
9 Ratios salaires Ratio salaire Temps
rapport des salaires élevés
Métier et des plus faibles
Tableau 12: Tableaux de bord "rémunération"

2010-2011 45
3.3. Tableaux de bord "conditions de travail"

Le tableau 6 présente les tableaux de bord traitant la partie conditions de travail.
N° du Intitulé du Indicateurs Axes d’analyse Objectifs et résultats

tableau de bord attendus
tableau
de bord
 Suivre le montant des
10 Suivi des coûts des Coût des congés
salaires perçus durant la
congés payés période d’acquisition des
congés
Coût des jours fériés  Connaitre l’indemnisation
travaillés des jours fériés travaillés
Temps
Métier  Analyser les coûts des
11 Suivi des heures Coût des heures
heures supplémentaires
supplémentaires supplémentaires à Client
25%
Coût des heures

supplémentaires à
100%
Tableau 13: Tableaux de bord "conditions de travail"
Conclusion
Grâce aux indicateurs et axes d’analyse identifiés dans le chapitre précédent, nous avons pu
ressortir la matrice d’expression des besoins et modéliser par la suite notre datawarehouse
selon la démarche descendante de Kimball. Nous avons détaillé les différents datamarts
conçus dans notre projet : effectifs, embauches, départs, rémunération, absentéisme, heures
supplémentaires et congés. Nous avons également abordé la conception de différents tableaux
de bord (statiques et dynamiques) relativement aux thèmes emploi, rémunération et conditions
de travail en précisant l’objectif, les indicateurs et les axes d’analyse pour chacun d’entre eux.
Après cette phase de conception, nous passons à la phase de mise en œuvre, exposée en détail
dans le chapitre suivant.

2010-2011 46
Chapitre IV : Mise en oeuvre
Dans ce chapitre, nous présentons la phase de la réalisation qui concrétise la conception

exposée lors du chapitre précédant. Nous décrivons la mise en œuvre du datawarehouse, en
explicitant les étapes suivies pour notre processus ETL. Nous illustrons également la
réalisation de nos cubes OLAP et nos rapports.

2010-2011 47
Chapitre IV : Réalisation et mise en œuvre
1. Réalisation de l’ETL
Comme déjà expliqué, l’ETL est le processus qui nous permet d’extraire les données depuis
les sources, les transformer et les charger dans le datawarehouse. Avant de s’y attaquer, nous
avons créé la base de données sur le serveur de test dédié. L’ETL est un processus qui sera
lancé plusieurs fois, de façon périodique, pour que les nouvelles données issues des sources
soient incluses dans notre datawarehouse.
Sous l’outil Talend que nous utilisons pour l’ETL, la solution est organisée sous forme de
jobs. Un job est un concept graphique, composé d’un ou plusieurs composants reliés entre eux
Chacun contient un nombre de flux et chaque flux est une succession de tâches.
La figure ci-dessous montre les différents jobs de notre projet.
Figure 13: Jobs du projet

Pour notre réalisation, nous avons procédé par étapes. En effet, nous avons alimenté d’abord
les tables de dimension, puis les tables intermédiaires et les tables de faits. Ces étapes sont
détaillées dans ce qui suit.
1.1. Alimentation des tables de dimension

Il s’agit de remplir nos tables de dimensions à partir des sources de données. Dans cette étape,
nous effectuons en même temps et les transformations nécessaires à nos dimensions et leur
chargement. Pour le rafraichissement des données de ces tables, tout en insérant que les
données non existantes dans les tables de dimensions, nous utilisons le composant
tMysqlSCD. Ce composant lie régulièrement une source de données et répertorie les
modifications dans la table dédiée. [TOS]
Toutes les tables de dimensions sont alimentées dans un seul job, illustré dans la figure 14.

2010-2011 48
Figure 14: Job dimensions
Prenons l’exemple d’alimentation de la table de dimension opération illustré dans la figure

15.
Figure 15: Flux d’alimentation de la dimension opération
Pour alimenter la dimension opération, on commence par récupérer les schémas des tables
« operation » et « prod_client » à partir de la base de données du SIRH. Pour ce faire, on
utilise le composant tMysqlInput. Puis, on utilise le composant tMap pour faire une jointure
entre les tables « operation » et « prod_client » et pour lier les données en entrées avec les
données que l’on veut avoir en sortie comme illustré dans la figure 16.

2010-2011 49
Figure 16: Mapping dimension opération
Dans cette figure, on peut remarquer qu’on a laissé l’expression de la colonne

« cle_operation » vide puisque c’est une clé technique qui s’auto-incrémente
automatiquement dès l’ajout d’un nouvel enregistrement.
Enfin, on dépose un composant tMysqlSCD et on le connecte au tMap. On spécifie dans

l’éditeur SCD la clé techniques (clé de substitution) et les clés fonctionnelles (clés sources),
comme illustré dans la figure suivante.

2010-2011 50
Figure 17: Editeur SCD
1.2. Alimentation des tables de faits

Les noms des jobs d’alimentation des tables de faits commencent tous par « TF ». En outre,
on a suivi la même démarche pour alimenter toutes les tables de faits.
Pour ce faire, on commence par alimenter les tables intermédiaires. Ces dernières servent à
stocker toutes les données nécessaires à l’alimentation des tables de faits.
Prenons comme exemple le job d’alimentation de la table de faits tf_absenteisme. La figure
ci-dessous illustre ce job.

2010-2011 51
Figure 18: Job TF_absentéisme
Le nom des tables intermédiaires commence toujours par «stage». Pour les alimenter, on
utilise le composant tMysqlInput pour récupérer les données. Ces dernières subissent les
transformations nécessaires grâce au composant tReplace. La figure suivante montre les
transformations effectuées dans notre exemple.
Figure 19: Transformations du job TF_absentéisme
On utilise ensuite le tMap pour lier les données en entrées avec les données que l’on veut
avoir en sortie.
Les tables intermédiaires sont configurées à être vidées avant chaque chargement des
données.

2010-2011 52
Figure 20: Vidage des tables de dimensions
Après le chargement de la table intermédiaire, on peut alimenter la table de faits grâce aux
composants ELT qui permettent d’améliorer les performances lors des gros traitements. Ces
composants utilisent les capacités de traitement des bases de données qu’ils exploitent. La
figure ci-dessous illustre cette phase.
Figure 21: Alimentation de la table de fait TF_absenteisme
En effet, on commence par glisser déposer les composants tELTMysqlInput. Ces composants
représentent les différentes tables de dimension et la table intermédiaire. Puis, on glisse le
composant tELTMysqlMap et on fait une liaison entre ce dernier et les composants
tELTMysqlInput. On doit ensuite spécifier la connexion dans le tELTMysqlMap.

2010-2011 53
Figure 22: Connexion du tELTMapper

Le lien du composant de sortie qui est le tELTMysqlOutput et du tELTMap doit absolument
correspondre au nom de la table de fait. En fait, le tELTMysqlOutput effectue l’action sur la
table telle que spécifiée dans le lien et insère les données selon le schéma de sortie défini dans
le Mapper ELT.
La dernière étape est le mapping des données en entrées avec ceux de la table de faits. Le
tELTMysqlMap permet de construire la commande SQL graphiquement en utilisant les tables
fournies en entrée pour alimenter la table de sortie.
Dans la figure ci-dessous, on peut voir les différents mapping effectués et la requête SQL
générée.
Figure 23: tELTMapper du job TF_absentéisme

2010-2011 54
2. Cubes OLAP
Dans Pentaho, un cube OLAP est un rapport dynamique basé sur les croisements des axes. Il
permet de naviguer au sein de grands volumes de données des plus agrégées au plus
détaillées.
2.1. Création des cubes OLAP

La création d’un cube au sens Mondrian est tout simplement la rédaction d’un fichier XML.
Ce fichier permet de lier les informations du cube que nous souhaitons faire apparaitre au
datawarehouse. Pour faciliter la création de ce fichier, nous utilisons l’outil Pentaho Schema
Workbench qui offre une interface graphique pour effectuer cette tâche.
Tout d’abord, nous commençons par configurer la connexion à la base de données.
Figure 24: Connexion à la base de données (Schema Workbench)
Ensuite, on crée un nouveau schéma. Un schéma peut contenir plusieurs cubes. Dans la figure
25, on peut voir les différents cubes, créés pour le thème emploi, encadrés en rouge.
Les dimensions partagées entre les différents cubes sont encadrées en bleu. Pour créer une
dimension, on doit spécifier sa clé étrangère dans la table de faits du cube et on doit ajouter
les niveaux de la hiérarchie de la dimension qu’on veut afficher.

2010-2011 55
Figure 25: Schéma Mondrian du thème emploi
Pour créer un cube, on doit d’abord indiquer sa table de faits et les dimensions partagées qu’il
contient. On doit également créer ses propres dimensions, c.-à-d. les dimensions non
existantes dans les autres cubes. Enfin, il ne nous reste plus qu’à insérer la mesure que nous
souhaitons calculer.
Prenons l’exemple du cube Absences. Il contient sa table de faits « TF_absenteisme », deux
dimensions partagées, trois autres dimensions et la mesure nombre de jours d’absences.
Comme on peut voir dans la figure 26, on doit spécifier la méthode de calcul de la mesure qui
est dans ce cas « Sum » et la colonne qui la représente dans la table de faits.

2010-2011 56
Figure 26: Cube absences (Schema Workbench)
Figure 27: Cube virtuel Flux (Schema Workbench)

2010-2011 57
On peut également créer des cubes virtuels qui permettent le calcul des mesures à partir des
différents cubes. Le Turn Over constitue un exemple de ce cas puisqu’il est la moyenne du
nombre d’embauches et du nombre de sorties divisée par l’effectif. Par conséquent, on a
besoin de trois cubes : entrées, sorties et effectif pour calculer le Turn Over. Pour ce faire, on
indique les mesures dont on a besoin dans le cube virtuel et leurs dimensions. On spécifie
également la formule de calcul de la mesure du cube virtuel comme illustré dans la figure 27.
Après la création des différents cubes dans le schéma Mondrian, on doit publier ce schéma
dans le serveur Pentaho.
2.2. Exemples de cubes OLAP créés

Les cubes OLAP étant conçus et déployés sur le serveur, on va donner quelques captures
d’écran de ces cubes.
Prenons comme premier exemple le cube Absences. Il a comme mesure le nombre de jours
d’absence.
Figure 28: Cube absences 1
Dès l’ouverture du cube, on peut voir les différents axes d’analyse et la mesure. L’appui sur
un + permet de faire du drill-down (zoomer sur les données pour découvrir de nouvelles sous
catégorie). Comme illustré dans la figure ci dessous.

2010-2011 58
Figure 29: Cube absences 2
L’appui sur un – permet de faire du drill-up (d’agréger les informations sur une catégorie
commune).
Comme deuxième exemple de cube, nous proposons le nombre d’entrées de l’année 2010 par
client comme illustré dans la figure 30. Ici, on peut choisir les axes d’analyse à afficher dans
le cube et filtrer les données pour les axes d’analyse. Il y a également une possibilité
d’afficher un graphique qui illustre les données du tableau croisé.

2010-2011 59
Figure 30: Cube Entrées 1
Figure 31: Cube Entrées 2

2010-2011 60
Comme troisième exemple de cube, nous proposons celui de la figure suivante qui montre les
effectifs et les effectifs moyens des années 2009, 2010 et 2011 et le graphe d’évolution de ces
effectifs.
Figure 32: Cube Effectifs
3. Rapports
3.1. Création des rapports
Les rapports statiques sont des rapports clairs et précis. Ils sont destinés à des utilisateurs qui
n’ont pas besoin de faire des analyses en navigant dans le cube.
La création de ce genre de rapports est faite via l’outil BIRT.
Figure 33: Connexion base de données (Birt)

2010-2011 61
Comme dans Pentaho Schema Workbench, on doit d’abord créer la connexion à la base de
données.
La plupart de nos rapports statiques sont sous forme de tableau croisé. La création d’un
tableau croisé dans Birt se fait grâce au composant Cross tab. Ce dernier nécessite la création
d’un cube de données.
Prenons l’exemple du rapport rémunération par métier et sexe. Ce rapport est sous forme d’un
tableau croisé ayant comme mesures la masse salariale et la rémunération moyenne. Dans le
cube de données, on spécifie les groupes de données et les mesures. Pour cet exemple, on a un
groupe de données qui a comme premier niveau le service et comme deuxième niveau la
catégorie. L’autre groupe représente le sexe.
Figure 34: Cube de données (Birt)
Dès la création du cube de données, on peut créer notre rapport avec le composant Cross Tab,
en déposant chaque groupe de données soit dans les lignes ou les colonnes du tableau croisé.
On a également d’autres rapports qui sont sous forme de simple tableau ou bien des
graphiques. Dès la création d’un rapport, il suffit de l’enregistrer dans le dossier du serveur
Pentaho et il sera affiché dans la plateforme grâce au Web Viewer.

2010-2011 62
Figure 35: Création rapport rémunération par métier et sexe
3.2. Exemples de rapports statiques

Dans cette partie, on va donner quelques exemples de rapports statiques créés dans notre
projet. Commençons par le rapport répartition par sexe et par âge de l’effectif. Pour afficher
ce rapport, on doit choisir le mois de paie. Dans cet exemple, on a choisit le mois Avril 2011.

2010-2011 63
Figure 36: Rapport répartition par sexe et par âge de l’effectif 1

2010-2011 64
Ce rapport contient la pyramide des âges qui représente la répartition par sexe et par âge des
salariés d’Outsourcia. Il contient également un tableau croisé contenant le pourcentage des
effectifs par métier, sexe et âge.
L’effectif d’une année est celui du dernier mois de cette dernière. Ainsi, il suffit de toujours
choisir le mois de décembre d’une année pour consulter son effectif.
Les autres rapports du sous thème effectifs sont tous sous forme de tableaux croisés à part
celui de la répartition par sexe et par statut marital des effectifs. Il est sous forme de
graphiques à barres croissantes.

2010-2011 65
Figure 39: Rapport répartition par sexe et par âge de l’effectif
Pour les autres rapports à part ceux des effectifs, on peut choisir la période que l’on veut
afficher. Prenons l’exemple du rapport prime moyenne. On choisit la date de début et la date
de fin de la période comme illustré dans la figure 40.
On a choisit d’afficher la prime moyenne de l’année 2010.

2010-2011 66
Figure 40: Rapport prime moyenne 1

2010-2011 67
Figure 41: Rapport prime moyenne 2
Conclusion
Ce chapitre a concerné l’aboutissement au résultat attendu de notre projet à savoir la création
d’un système décisionnel pour la fonction RH d’Outsourcia. Il a détaillé d’abord le processus
ETL que nous avons élaboré avec l’outil Talend. Ce processus est une composante clé de
notre plateforme vu qu’il assure l’alimentation du datawarehouse conçu et qu’il prévoie son
évolutivité. Ce datawarehouse a été ensuite exploité pour la création et le déploiement de nos
cubes OLAP et nos rapports statiques. Les cubes OLAP présentent un outil de pilotage et
d'aide à la décision dans la mesure où ils permettent selon des techniques appropriées de
navigation un filtre sur les données à générer, donc une information précise, et offrent des
tableaux croisés dynamiques pour d’éventuels besoins avancés d’analyse. Les rapports
statiques comportent des graphes et des tableaux croisés qui permettent à l’utilisateur une vue
globale mais aussi synthétique des données. Dans ce cadre, Nous avons donné, dans ce
chapitre, quelques exemples de cubes OLAP et de rapports générés.

2010-2011 68
Conclusion
Conclusion générale
Notre projet consistait à mettre en œuvre un système décisionnel pour la fonction RH

d’Outsourcia. Il s’agit précisément de générer des tableaux de bord qui offrent une meilleure
visibilité sur la fonction RH et qui mettent à disposition de la DRH l’information essentielle
pour la prise de décision relativement aux thèmes emploi, rémunération et conditions de
travail.
Vu le caractère décisionnel du projet, nous avons suivi les différentes étapes du cycle de vie
dimensionnel. Après avoir étudié l’existant et recueilli les besoins des utilisateurs finaux, nous
avons défini les indicateurs et les axes d’analyse et abouti à l’architecture technique de la
solution. Grâce aux indicateurs et axes d’analyse identifiés, nous avons pu dresser une
conception du modèle dimensionnel du datawarehouse et de la présentation des tableaux de
bord. Nous nous sommes ensuite consacrés à la réalisation de la solution en alimentant le
datawarehouse grâce à l’outil Talend et en générant les états de restitution ciblés sous forme
de rapports dynamiques sur la base de cubes OLAP avec Pentaho Analysis ou de rapports
statiques à l’aide de BIRT.
Au terme de ces étapes, nous pouvons affirmer que notre plateforme a satisfait les clauses du
cahier de charges de notre projet et permet des possibilités intéressantes d’analyse et d’accès à
l’information offertes aux utilisateurs finaux.
Par ailleurs, ce projet m’a été bénéfique aussi bien au niveau informatique qu’au niveau
professionnel. Il m’a permis de raffiner mes capacités d’abstraction et de conception en
modélisation décisionnelle et offert l’occasion de découvrir et manipuler plusieurs outils Open
Source de la BI et enfin de m’ouvrir plus sur le métier RH.
En perspective, on peut envisager d’intégrer d’autres thèmes de la fonction RH dans notre
système décisionnel.

69
2010-2011
Bibliographie/Webographie
Bibligraphie/Webographie
Bibliographie
[BEN] L. BENHIBA, cours du reporting de 3ème année ENSIAS, option BI, 2010
[INMO] W.H Inmon, Building the Data Warehouse, second edition, Wiley Computer
Publishing USA, 1996
[KIMBALL 2001] R. Kimball, L. Reeves, M. Ross, W. Thornthwaito, Concevoir et déployer

un Data Warehouse, édition Eyrolles, 2001
[KIMBALL 2002] R. Kimball, M. Ross - The Data Warehouse Toolkit, 2nd edition, 2002
[LBSMILE] Décisionnel Solutions open source, SMILE, 2010
[TOS] Guide référence de Talend open studio
Webographie
[CNAM] Le Datawarehouse et les systèmes multidimensionnels,
http://ww1.cnam.fr/maths/IMG/pdf/wattiau_09-10_3.pdf, Mai 2011
[JNET] Journal du Net, SIRH : l’informatique au service des Ressources Humaines,

http://www.journaldunet.com/solutions/intranet-extranet/sirh/, Avril 2011
[Outsourcia] Outsourcia, site official d’Outsourcia, http://www.outsourcia.com, Avril 2011
[Smile] les composants décisionnels / Talend Open Studio, http://decisionnel-open-

source.smile.fr/Les-composants-decisionnels/Talen-Open-Studio, Juin 2011

70
2010-2011
Glossaire
Glossaire
Concepts métiers
Centre de contact
Structure centralisée dont la vocation est de gérer à distance les relations des entreprises avec
leurs clients et prospects, par une communication directe, basée sur le couplage de la
téléphonie et de l'informatique.
Gestion de la relation client
L'ensemble des outils et techniques destinés à capter, traiter, analyser les informations
relatives aux clients et aux prospects, dans le but de les fidéliser en leur offrant le meilleur
service.
Gestion des ressources humaines
Ensemble de pratiques du management ayant pour objectif de mobiliser et développer les

ressources humaines pour une plus grande performance de l'organisation.
Offshore
La délocalisation des activités de services de production de certaines entreprises vers des pays
à bas salaires.
Onshore
Activité économique se déroulant dans le territoire d’un pays en opposition avec offshore.
Outsourcing
Opération qui consiste pour une entreprise à confier à un tiers la réalisation de certaines tâches
auparavant réalisées directement par les employés de l’entreprise. Les tâches externalisées
peuvent être réalisées dans les locaux du prestataire mais aussi dans ceux de l’entreprise par
des équipes du prestataire dédiées à cet effet.

71
2010-2011
Glossaire
Concepts informatiques et décisionnels

Analyse multidimensionnelle
Analyse des valeurs d’un indicateur selon plusieurs angles. Cela est rendu possible par les
axes d’analyse utilisés par l’indicateur.
Axe d’analyse
Thème fonctionnel regroupant les informations permettant d’analyser les résultats de

l’entreprise. Les axes reflètent la perception que l’entreprise a de son environnement
Business Intelligence (BI)

Concept forgé en 1993 par le Gartner Group pour désigner l’ensemble des moyens et des
méthodes permettant de rassembler, consolider, analyser et rendre accessibles les données
d’une entreprise au plus grand nombre d’acteurs possibles, dans une perspective d’aide à la
décision.
Cahier des charges
Document décrivant les fonctions, les aptitudes et les qualités attendues d’un produit. Il s’agit
d’un document contractuel entre la maîtrise d’ouvrage et maîtrise d’œuvre.
Cube
Structure multidimensionnelle permettant lánalyse dínformations factuelles (mesures ou
faits) en les segmentant sur un ensemble dáxes dánalyses.
Datamart
Sous-ensemble d'un datawarehouse lié à un métier de l'entreprise et conçu pour répondre aux
besoins spécifiques d'un groupe d'utilisateurs spécialisé.
Datawarehouse
Base de données qui archive dans un endroit unique les indicateurs de plusieurs domaines
fonctionnels. Le datawarehouse permet de consolider l’ensemble des informations
potentiellement utiles aux analyses décisionnelles.
Dimension
Concept ou information élémentaire permettant de structurer l’analyse des données
Drill down
Mécanisme de navigation dans une structure multidimensionnelle permettant dáller du plus
global au plus détaillé à láide de requêtes de type hiérarchique.

72
2010-2011
Glossaire
Drill up
Le passage d'une vue détaillée d'une information à une vue résumée de celle-ci. L'opération
inverse se nomme drill down.
ETL (Extract Transform Load)

Logiciel d’alimentation de l’entrepôt de données ou du datamart à partir des extractions
effectuées dans le système d’information.
Fait
Terme technique désignant au sein des données de l’entreprise un concept événementiel
reflétant l’activité de celle-ci (exemple : les ventes, les mouvements de stock). Les tables de
fait sont les tables de l’entrepôt relatives aux faits. Ces tables sont en générale alimentées par
accumulation.
Filtre
Critère d’analyse qui consiste à ne sélectionner qu’un ensemble restreint de données.
Indicateur
Statistique suivie au fil du temps, qui présente les tendances dúne condition ou dún
phénomène, au-delà des propriétés de la statistique elle même. Les indicateurs permettent d
óbtenir de línformation supplémentaire. Ils offrent un moyen d´évaluer les progrès en vue d
ún objectif. On peut concevoir toutes sortes díndicateurs : mesure de la rentabilité, des
ventes, de l´évolution des clients, etc.
Modèle en étoile
Technique de modélisation qui représente l’ensemble des données d’un axe d’analyse dans
une seule table.
La table de faits est placée au centre du modèle, les tables d’axe sont mises en relation autour
d’elle. Ce modèle représente une étoile.
Modélisation dimensionnelle
Technique de modélisation consistant à organiser les données autour de dimensions. Les
dimensions sont communes à plusieurs indicateurs. Ce type de modélisation permet aux outils
de restitution d’effectuer des agrégations sur les données.
OLAP (On Line Analytical Processing)
Précise le concept d’analyse multidimensionnelle dans un contexte de navigation dans un
hyper-cube.

73
2010-2011
Glossaire
Plan d’assurances qualité

Document servant à décrire l'ensemble des dispositions spécifiques prises pour assurer la
qualité du produit fourni dans le cadre d'un projet ainsi que la qualité du processus de
développement.
Portail
Point d’entrée vers les sources d’information et les applications de l’entreprise, à destination
des collaborateurs (portail Intranet), des partenaires (portail Extranet), des internautes (portail
Internet).
SQL (Structured Query Language)
Langage d'interrogation et de manipulation de bases de données relationnelles.
Système décisionnel
Synonyme de la Business Intelligence, le SID ou le Système d’Information Décisionnel
couvre classiquement un cycle de collecte des données, stockage, analyse, restitution.

74
2010-2011
Annexes
Index
A
Ahmkjh
Alimentation 5, 14, 23, 32, 47, 48, 50, 52, 66, 71 73
Architecture technique 20, 71
Axe 25, 26, 27, 28, 29, 30, 31, 34, 35, 36, 37, 38, 43, 44, 45, 54, 59, 61, 74, 75
B
Ahmkjh
Besoins 5, 18, 19, 20, 22, 23, 24, 26, 27, 34, 35, 36, 37, 38, 45, 57, 63, 70, 71, 74
Business Intelligence 6, 7, 13, 33, 74, 76
Cadrage 13, 24, 27, 32

Cahier de charges 22, 26, 74
Conception 14, 16, 17, 19, 20, 22, 25, 33, 34, 35, 36, 43, 45, 71
Conditions de travail 13, 19, 23, 27, 30, 34, 41, 45, 67, 81, 83
Cycle de vie 6, 14
Datamart 5, 6, 36, 38, 39, 40, 41, 45, 74, 75

Datawarehouse 5, 6, 22, 23, 36, 45, 46, 47, 54, 70, 71, 72, 74
Dimension 7, 22, 31, 33, 38, 47, 48, 49, 52, 56, 57, 71, 74, 75
Effectif 27, 28, 30, 37, 38, 43, 44, 45, 57, 60, 62, 63, 64, 82, 92
ETL 7, 32, 33, 46, 47, 70, 71, 75
Emploi 5, 13, 19, 23, 27, 34, 38, 45, 55, 56, 71
Fait 38, 41, 50, 52, 53, 56, 57, 74, 75
Gestion des ressources humaines 13, 17
Indicateur 19, 23, 24, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 43, 44, 45, 74, 75

75
2010-2011
Annexes
M
Maintenance 19, 20, 22
Modélisation 20, 22, 36, 38, 71, 75
O
OLAP 5, 6, 7, 14, 22, 33, 46, 54, 58, 70, 71, 75
Outil 5, 13, 18, 20, 23, 25, 32, 33, 34, 47, 54, 63, 70, 71, 73, 75
P
Plan Assurance Qualité 7, 13, 15, 22, 23
Planning 13, 15, 18, 20, 22, 23
Plateforme décisionnelle 5, 13, 20, 33, 65, 70
Règles de gestion 28, 29, 30, 31

Rémunération 5, 13, 19, 23, 27, 29, 34, 37, 41, 44, 45, 63, 64, 71
Reporting 5, 6, 7, 14, 24, 25, 26, 33, 34, 71, 72
S
SGBD 7, 20, 25, 33, 83
Sources de données 5, 24, 25, 26, 33, 36, 47
SQL 7, 33, 53, 72
T
Tableaux de bord 5, 43, 44, 45

76
2010-2011
Annexes
Annexes
Annexe A : Plan Assurance Qualité

Annexe B : Manuel de l’utilisateur

77
2010-2011
Annexes

78
2010-2011

79
2010-2011
Plan Assurance Qualité

SI DÉCISIONNEL RH
Amélioration des processus RH par la création d’un
système décisionnel performant
OUTSOURCIA ITO
Meriem MOUSTAJAB
Le 01/03/11

80
2010-2011
Table des matières
1 Suivi du document..............................................................................................................80
2 Introduction........................................................................................................................81
3 Domaines d’application......................................................................................................81
4 Organisation et communication du projet..........................................................................81
4.1 Intervenants du projet..................................................................................................82
4.2 Organisation des réunions...........................................................................................82
5 Les exigences du projet décisionnel RH............................................................................82
5.1 Les exigences fonctionnelles.......................................................................................82
5.2 Les exigences technologiques.....................................................................................83

81
2010-2011
1. Suivi du document
Date Auteur Objet de la mise à jour
01/03/11 Meriem MOUSTAJAB Création

82
2010-2011
2. Introduction
Le plan d'assurance et contrôle qualité (PAQ) vise à décrire les dispositions prises pour
obtenir la qualité du produit définie en accord avec les utilisateurs.
Ce PAQ définit les méthodes, l'organisation et les activités d'assurance et de contrôle de la
qualité spécifique au projet décisionnel RH.
L'utilisation de ce PAQ doit permettre d'atteindre les objectifs suivants :
 constituer une référence commune à tous les membres de l'équipe projet. Il permettra
d'assurer une bonne cohérence et une homogénéité dans les méthodes de travail ;
 garantir la qualité du produit et des prestations. Cette qualité s'exprime par des critères
de qualité à respecter dans le cadre de ce projet : exigences, risques et contraintes du
projet ;
 définir les procédures à suivre, les outils à utiliser, les normes à respecter, la
méthodologie de développement suivie et les contrôles prévus.
3. Domaines d’application
Outsourcia a mis en place un système d’information ressources humaines pour la gestion de
ses RH. Cependant, ce système ne fournit pas des données synthétiques qui aideront à la prise
de la décision.
Ainsi, la DRH a lancé un projet de mise en place d’une solution de datawarehousing et
reporting, dont le but est de pouvoir générer des rapports et des tableaux de bord couvrant les
thèmes emploi, rémunération et conditions de travail.
Les grandes lignes d’action du projet se présentent comme suit :
 étude et analyse du système existant et des résultats obtenus grâce à ce système ;
 analyse et spécifications des besoins, que ce soit des besoins en données ou en
performance ;
 conception de la nouvelle solution notamment un modèle datawarehouse sur lequel se
basera la restitution des données ;
 réalisation de la solution dans le cadre des standards de développement d’Outsourcia,
depuis l’implémentation de la nouvelle base de données jusqu’à l’interface utilisateur.
4. Organisation et communication du projet

Cette section identifie les personnes intervenant sur le projet et précise leurs rôles et
responsabilités dans le projet. Elle décrit également l’organisation et les moyens assurant la
qualité de la communication.

83
2010-2011
1.1. Intervenants du projet

L’équipe du projet décisionnel RH est constituée de plusieurs participants de différents rôles.
Elle est constituée comme suit :
Intervenant Rôle
Cahier des charges et encadrant

Didier TOULOUSE
fonctionnel
Cahier des charges et spécifications

Karima NARJIS
fonctionnelles
Ali STOUKY Chef de projet et encadrant technique
Suivi et assistance technique pour assurer

Ismail AZZARRAA
la maintenance et l’évolution par la suite
Meriem MOUSTAJAB Analyste, concepteur, développeur
1.2. Organisation des réunions

Afin d’assurer un suivi effectif de toutes les étapes, des réunions sont organisées avec les
différents intervenants du projet.
Chaque réunion donnera lieu à la rédaction d’un compte rendu synthétisant l’état
d’avancement du projet et toute décision prise.
Deux types de réunion peuvent être distingués :
 Des réunions avec les utilisateurs : faites avec les représentants des futurs
utilisateurs: elles ont pour but de bien cerner les besoins des utilisateurs ainsi que leur
évolution, et de s’assurer à chaque étape que l’on prend bien en considération la vision
du client.
 Des réunions techniques : réunions effectuées avec les membres de l’équipe
technique du projet, ces réunions permettent de valider les livrables techniques, de
s’assurer qu’ils répondent bien aux besoins et aux normes utilisées dans la société, et
de procéder à l’évaluation de l’état d’avancement pour chacune des ressources, ainsi
que du niveau de réalisation des objectifs prédéfinis.
5. Les exigences du projet décisionnel RH

Les exigences fonctionnelles

84
2010-2011
Les exigences fonctionnelles du projet représentent les informations que les rapports
statistiques doivent générer ainsi que les critères fonctionnels auxquels le système doit
répondre.
Les besoins en informations portent sur les trois thèmes : emploi, rémunération et conditions
de travail.
Le système doit aussi répondre autant que possible aux facteurs qualité suivants:
 Disponibilité : le système doit être en permanence à la disposition de ses utilisateurs ;
 Fiabilité : le système exécute les fonctions attendues avec la précision requise (taux de
défaillance minimal) ;
 Maniabilité : facilité d’utilisation ;
 Rapidité : éviter d'alourdir le système.
Les exigences technologiques

Les outils utilisés dans notre projet sont :
 MySQL : SGBD
 Talend : Outil d’ETL
 Pentaho Analysis: Cube OLAP
 BIRT: Rapports statiques

85
2010-2011

86
2010-2011
Manuel de l’utilisateur
SI DÉCISIONNEL RH
Amélioration des processus RH par la création d’un
système décisionnel performant
OUTSOURCIA ITO
Meriem MOUSTAJAB
Le 06/06/11

87
2010-2011
Table des matières
1 Suivi du document..............................................................................................................87
2 Introduction........................................................................................................................88
3 Scenarii d’utilisation..........................................................................................................88
3.1 Accès...........................................................................................................................88
3.2 Les rapports dynamiques.............................................................................................89
3.3 Les rapports statiques..................................................................................................93

88
2010-2011
1. Suivi du document
Date Auteur Objet de la mise à jour
06/06/11 Meriem MOUSTAJAB Création

89
2010-2011
2. Introduction
Objet du document :
Ce document a pour objectif d’expliquer les scenarii d’utilisation du système décisionnel
ressources humaines.
5. Scenarii d’utilisation
1.1. Accès
Pour accéder au système décisionnel Ressources humaines, il suffit de se connecter à la
plateforme Pentaho via l’adresse : http://10.4.1.8:8080/pentaho/Login
Après, vous devez vous authentifier en saisissant comme Nom d’utilisateur : admin et le mot
de passe est outdec.
Ci-dessous l’écran d’authentification :

90
2010-2011
1.5. Les rapports dynamiques

Après l’authentification, la fenêtre ci-dessous est affichée :
Le dossier DecisionnelRH, encadré dans la figure en rouge, contient les rapports dynamiques
et statiques du système décisionnel RH.
Pour accéder aux rapports dynamiques, il faut double cliquer sur le dossier Analyse. Ce
dossier contient des sous dossiers qui constituent les thèmes et sous thèmes, comme illustré
dans le figure :

91
2010-2011
Par exemple, si on veut voir le rapport dynamique de la rémunération, on doit cliquer sur le
dossier Rémunération. Et on peut voir dans la section Fichiers en bas à gauche de la fenêtre le
rapport.
Il suffit de double cliquer sur le rapport dynamique.

92
2010-2011
L’appui sur un + permet de faire du drill-down (zoomer sur les données pour découvrir de
nouvelles sous catégorie), l’appui sur un – permet de faire du drill-up (d’agréger les
informations sur une catégorie commune).
On peut choisir les axes d’analyse à afficher dans le rapport. Par exemple, si on veut afficher
la masse salariale et la rémunération moyenne par période et par client, on doit cliquer sur le
bouton sous forme de cube. Puis, il suffit de filtrer les autres axes d’analyse en cliquant sur le
bouton encadré en rouge.
On peut également filtrer les données à afficher pour les axes d’analyse choisis en cliquant sur
l’axe. Par exemple, si on veut choisir les périodes à afficher, on doit cliquer sur Période dans
Lignes.

93
2010-2011
Puis, on doit cocher les périodes qu’on veut afficher. Par exemple, on peut cocher les 3 années
et on obtient l’effectif et l’effectif moyen des 3 périodes.
En cliquant sur le bouton on peut voir un graphique des effectifs des 3 années

94
2010-2011
On peut configurer les options du graphique via le bouton .
Le rapport peut être exporté sous format PDF via le bouton . Il peut également être
exporté sous format Excel en appuyant sur .
1.6. Les rapports statiques

Les rapports statiques sont dans le dossier Rapport. Ils sont également organisés par thèmes et
sous thèmes. Et de la même manière que les rapports dynamiques on peut accéder aux
rapports statiques.
Prenant comme exemple le rapport Embauches, vous devez spécifier la date de début de la
période choisie et la date de fin. Affichant les embauches de l’année 2010.
Après avoir choisi la période, on peut visualiser le rapport.

95
2010-2011
Si vous voulez changer la période il suffit de cliquer sur .

Les rapports statiques peuvent être exportés sous format PDF, Excel, Word, PowerPoint ou
PostScript. Ils peuvent également être imprimés directement à partir de la plateforme de
Pentaho grâce au bouton .

96
2010-2011

Rapport Meriem MOUSTAJAB Final

Transféré par

Droits d'auteur :

Formats disponibles

Rapport Meriem MOUSTAJAB Final

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Meriem MOUSTAJAB Final

Transféré par

Droits d'auteur :

Formats disponibles

Ecole Nationale Supérieure d’Informatique

et d’Analyse des Systèmes

Mémoire de Projet de Fin d’Études

Pour l’Obtention du Titre

D’Ingénieur d’État en Informatique

Mise en œuvre d’un système décisionnel pour les

Soutenu par : Sous la direction de :

Mme. Meriem MOUSTAJAB M. M. A. JANATI IDRISSI (ENSIAS)

Année Universitaire 2010-2011

A mes très chers parents

Je ne saurai exprimer assez ma gratitude pour tout votre amour

A mon très cher mari

A ma très chère sœur Zineb,

A mon très cher frère Chafik

Les mots ne suffisent guère pour exprimer l’amour,

A tous les membres de ma famille,

A toutes mes amies,

A tous ceux qui m’aiment

J’exprime aussi mon ample reconnaissance et ma considération envers mes encadrants, M.

This document is a summary of my graduation project that I accomplished at Outsourcia. This

Figure 1: Ecran d’accueil du SIRH d’Outsourcia.....................................................................18

Tableau 1: Chiffres d’affaires d’Outsourcia.............................................................................16

Table des matières

2.1. Matrice d’expression des besoins.............................................................................36

Le Système d’Information Ressources Humaines (SIRH) est devenu un outil incontournable

Ce mémoire présente les différentes étapes de réalisation de notre projet. Il se compose de

Le premier chapitre aborde le contexte général du projet. Il présente l’organisme d’accueil et

Quant au troisième chapitre, il traite la conception du modèle multidimensionnel de notre

Année Chiffre d’affaire (M.EURO)

Tableau 1: Chiffres d’affaires d’Outsourcia

Projet de Fin d’Etudes 17

Projet de Fin d’Etudes 18

 Gestion de la communication : ce module se préoccupe de gérer les boites aux lettres

La figure suivante montre l’écran d’accueil du SIRH d’Outsourcia:

Figure 1: Ecran d’accueil du SIRH d’Outsourcia

3. Motivation et objectifs du projet

Projet de Fin d’Etudes 19

Figure 2: Schéma du cycle de vie dimensionnel

Les étapes de la figure ci-dessus sont :

Projet de Fin d’Etudes 20

Planification du projet : aborde la définition et l’étendue du projet. Elle permet l’affectation

Projet de Fin d’Etudes 21

Figure 3: Diagramme GANTT du projet

Projet de Fin d’Etudes 22 ENSIAS

Planification du projet Planning et méthodologie de conduite du projet

Etude et définitions des besoins Cahier des charges

Architecture technique Dossier des spécifications techniques détaillées

Modélisation multidimensionnelle Dossier conceptuel

Conception de l’application utilisateur Dossier de description des cubes OLAP

Test et déploiement Rapports et scénarii des tests

Maintenance et croissance Manuel d’utilisation mis à jour

Tableau 2: Livrables du projet

1.4. Plan Assurance qualité

Projet de Fin d’Etudes ENSIAS

Projet de Fin d’Etudes ENSIAS

Le but de ce chapitre est d’aboutir à un cadrage fonctionnel et technique de notre projet.

Projet de Fin d’Etudes ENSIAS

Figure 4: Exemple de rapport élaboré avec Excel

Projet de Fin d’Etudes ENSIAS

1.2. Critique de l’existant