Concéption et réalisation d'un processus décisionnel, tableau de bord social.

Année Universitaire
2019/2020
ÉCOLE SUPÉRIEURE PRIVÉE DES TECHNOLOGIES DE
L'INFORMATION ET DE MANAGEMENT DE NABEUL
Mémoire de Fin d'Etudes
CONCEPTION ET RÉALISATION D’UN PROCESSUS
DÉCISIONNEL, TABLEAU DE BORD SOCIAL
Présenté en vue de l'obtention de :
DIPLÔME D'INGÉNIEUR EN INFORMATIQUE
Spécialité : Informatique décisionnelle
Elaboré par :
Rim ENNOUR
Encadré par :
Encadrant Académique Encadrant Professionnel
Mr. Saber JAFFEL Mr. Raouf RIHANI

Dédicaces
Avec l’expression de ma reconnaissance et mon amour,
Je dédie ce modeste travail
À l’homme, ma précieuse offre de Dieu, mon cher papa Rafik,
À la femme, qui a souffert sans me laisser souffrir, la plus douce des mamans Nejla,
les fruits de l’arbre que vous avez planté et n’avez jamais cessé d’arroser, commencent à mûrir,
j’espère que ce mémoire constitue pour vous un signe de fierté. Que Dieu, le tout puissant vous
garde, vous procure santé et bonheur et vous accorde une longue vie.
À mon cher frère Amir, à tous les moments d’enfance passés avec toi, en gage de ma profonde
estime pour l’aide que tu m’as apporté. Tu m’as soutenu, réconforté et encouragé. Puissent nos liens
fraternels se consolider et se pérenniser encore plus.
À mon cher mari Hamda, tes sacrifices, ton soutien moral et matériel, ta gentillesse sans égal, ton
profond attachement m’ont permis de réussir mes études. Sans ton aide, tes conseils et tes
encouragements ce travail n’aurait pas vu le jour. Que Dieu réunisse nos chemins pour un long
commun serein et que ce travail soit le témoignage de ma reconnaissance et de mon amour sincère et
fidèle.
À mon bébé fœtus, dans quelques mois, tu seras parmi nous, Inchallah, je suis très reconnaissante
et ravie de partager ce moment si précieux avec toi mon ange. Puisse Dieu te protéger, te procurer
santé et longue vie.
À ma belle mère Sonia, tes efforts m’ont permis de garder un bon équilibre entre ma vie
professionnelle et ma vie privée. Que Dieu te garde et te protège de tous mal.
À la mémoire de ma grand-mère Naziha, mon combat pour la réussite demeure pour moi la
meilleure façon d’honorer ta mémoire. Que ton âme repose en paix.
À mes tantes Sana & Safa , vous m’avez toujours soutenu et vous continuez à le faire. Je vous
considère beaucoup plus comme mes grandes sœurs que comme des tantes pour moi et je ne
trouverais pas les mots pour vous exprimer mon affection et mon estime envers vous. Je vous
souhaite tous bonheur et santé.
À tous les membres de ma famille, petits et grands.
i

À mes plus chères Rahma & Asma & Amal & Raouia, je ne peux pas trouver les mots justes et
sincères pour vous exprimer mon affection, vous êtes pour moi des sœurs et des amies sur qui je
peux compter.
À tous mes amis, précisément Mejd & Mejdi & Rayen & Mouhamed merci pour vos soutiens et
vos conseils.
En témoignage de l’amitié qui nous unit et des souvenirs de tous les moments que nous avons passés
ensemble, je vous dédie ce travail et je vous souhaite une vie pleine de réussite.
À tous ceux que j’aime et à toutes les personnes qui m’ont prodigué des encouragements et ont
donné la peine de me soutenir durant cette formation.
Aucun hommage ne pourrait être à la hauteur de ses sacrifices.
Mille Mercis...
ii

Remerciements
Après avoir rendu grâce à Dieu le tout puissant et le miséricordieux, qui m’a donné la force et la
persévérance d’accomplir ce modeste travail. Je tiens à exprimer ma gratitude et mes vifs
remerciements à tous ceux qui m’ont aidé à réaliser ce stage dans des conditions favorables, à tous
ceux qui n’ont cessé de me prodiguer leurs conseils et encouragements à travers ces lignes :
Ce travail n’aurait pu aboutir à un résultat sans une réelle collaboration et un échange d’idées
entre tous ceux qui y ont participé. Ma grande gratitude s’adresse à mon encadrant universitaire Mr
Saber Jaffel qui a accepté de m’encadrer durant cette période de stage, pour sa disponibilité, son
orientation, ses conseils et son œil critique m’ont été très précieux pour structurer le travail. Sans
oublier leur encouragement, leur soutien moral et la charge des ondes positives qu’ils m’ont fournies
et servies pour le bon déroulement du projet.
Je tiens à remercier vivement Mme Manel Jrad, VP Exécutif Global Talent Manager, pour
l’opportunité et la confiance qu’elle m’a accordé pour être parmi les Win(Futures) , mon encadrant
professionnel Mr Raouf Rihani pour ses efforts, le temps qu’il m’a consacré et pour les précieuses
informations qu’il m’a accomplis avec intérêt et compréhension. Ainsi que toute l’équipe de
Wimbee Tech sans oublier l’équipe de Marketing Image&actions, plus précisément Mme Rim
Benzina, pour la chaleureuse ambiance de travail, le temps qu’ils m’ont consacré, leurs directives, et
pour la qualité de leurs suivis durant toute la période de mon stage.
Je remercie également mes collègues, Olfa, Zied, Ons, Aymen, Jihene, Yassine, Rihab, Youssef
et Nour pour leurs esprits d’équipe, la collaboration de travail, leurs soutiens et les bons moments
partagés.
Mes vifs remerciements vont également aux membres du jury pour son grand honneur en
acceptant de juger ce travail. Je tiens également à remercier tous mes enseignants de l’IT Business
School de Nabeul plus précisément Mme Safa Fennia, Mr Ahmed Ben Taleb et Mr Mouhamed
Najeh Issaoui de leurs connaissances, leurs encouragements et leurs orientations si précieuses tout
au long de ma formation.
Je voudrais exprimer ma reconnaissance envers à mes camarades de la promotion 2019-2020 que j’ai
servis avec humilité et avec lesquels j’ai passé une scolarité exceptionnelle, riche d’enseignements,
et d’expériences de rencontres. Je veux ici dire ma sincère amitié.
Mes remerciements vont enfin à toute personne qui a contribué de près ou de loin à l’élaboration
de ce projet.
iii

Table des matières
INTRODUCTION GÉNÉRALE 1
1 CONTEXT GÉNÉRAL DU PROJET 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Présentation générale de Wimbee Tech . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Pôle RH et Organigramme . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Analyse SWOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.4 Prototypage (Maquettes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Analyse et spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5 Les tableaux de bords au sein du pilotage RH . . . . . . . . . . . . . . . . . . . . . 11
1.5.1 Définition d’un tableau de bord RH . . . . . . . . . . . . . . . . . . . . . . 11
1.5.2 Les principaux avantages et objectifs d’un tableau de bord RH . . . . . . . . 12
1.5.3 Les étapes d’élaboration d’un tableau de bord RH . . . . . . . . . . . . . . . 12
1.6 Gestion du projet au cœur de la BI . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6.1 Étude comparatif entre les approches de gestion de projet . . . . . . . . . . . 12
1.6.2 Étude comparatif entre les méthodes de gestion de projet . . . . . . . . . . . 14
1.6.3 La méthode GIMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.7 Planification prévisionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 CONCEPTS THÉORIQUES & ÉTAT DE L’ART 17
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Concepts généraux de la BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1 Historique de l’informatique décisionnelle . . . . . . . . . . . . . . . . . . . 17
2.2.2 Définition de l’informatique décisionnelle . . . . . . . . . . . . . . . . . . . 18
2.2.3 Principes de l’informatique décisionnel (pourquoi la BI?) . . . . . . . . . . 18
2.2.4 Objectif de l’informatique décisionnel . . . . . . . . . . . . . . . . . . . . . 18
2.3 Architecture d’un système décisionnel . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 Sources de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.2 Processus ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.3 Entrepôt de données (Data warehouse) . . . . . . . . . . . . . . . . . . . . . 20
iv

2.3.4 Magasin de données (Data Marts) . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Théories d’entrepôt de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.1 Objectif d’un entrepôt de données . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.2 Démarche de construction d’un entrepôt de donné . . . . . . . . . . . . . . . 21
2.4.2.1 Conception d’un entrepôt de données . . . . . . . . . . . . . . . . 21
2.4.2.2 Modélisation d’un entrepôt de données . . . . . . . . . . . . . . . 21
2.4.2.3 Alimentation de l’entrepôt de données . . . . . . . . . . . . . . . 23
2.4.2.4 Restitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 CONCEPTION & MODÉLISATION 26
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Architecture fonctionnelle du système . . . . . . . . . . . . . . . . . . . . . 26
3.2.2 Architecture logique des données . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Identification des indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.1 Identification des données sources . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.2 Conception de l’ODS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.2.1 Operational data staging ”ODS” . . . . . . . . . . . . . . . . . . 29
3.4.2.2 Identification des tables . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.2.3 Vue d’ensemble de la conception . . . . . . . . . . . . . . . . . . 31
3.4.3 Conception de l’entrepôt de données . . . . . . . . . . . . . . . . . . . . . 31
3.4.3.1 Identification des tables de dimensions . . . . . . . . . . . . . . . 31
3.4.3.2 Identification de la table des faits . . . . . . . . . . . . . . . . . . 33
3.4.3.3 Vue d’ensemble de la conception . . . . . . . . . . . . . . . . . . 34
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 MISE EN OEUVRE 35
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Comparatif des outils ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.2 Comparatif des outils de visualisation . . . . . . . . . . . . . . . . . . . . . 36
4.2.3 SQL Server 2012 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.4 SQL Server Management Studio . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.5 Visual Studio 2015 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.6 SQL Server Integration Services . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.7 Microsoft Power BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.1 Phase d’alimentation(ETL) . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.1.1 Chargement de l’ODS . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.1.2 Chargement de l’entrepôt de données . . . . . . . . . . . . . . . 45
4.3.2 Phase de restitution de données . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
CONCLUSION GÉNÉRALE 56
Bibliographie 58
v

Table des figures
1.1 Logo de Wimbee Tech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Spécialités et domaines d’intervention de Wimbee Tech . . . . . . . . . . . . . . . . 4
1.3 Perspectives des ressources humaines . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Organigramme de Wimbee Tech . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Analyse SWOT de Wimbee Tech . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Fichier de gestion de congés de Wimbee . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7 Fichier de gestion des employés de Wimbee . . . . . . . . . . . . . . . . . . . . . . 8
1.8 Logo du site Clicdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.9 Maquettes du tableau de bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.10 Planification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1 Historique de l’informatique décisionnelle . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Architecture d’un système décisionel . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Modèle en étoile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Modèle en flocon de neige . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Modèle en constellation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6 Processus ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7 Outils de restitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8 Différence entre rapports & tableaux de bord . . . . . . . . . . . . . . . . . . . . . . 25
3.1 Architecture fonctionnelle du système . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Architecture logique des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Principes des KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Fichiers sourcess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5 Modèle de l’ODS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6 Modèle d’entrepôt de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1 Logo du SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Logo du SQL Server Management Studio . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Logo du Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Logo du SSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5 Logo du Power BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.6 Les outils majeurs de Power BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.7 Les fonctionnalités de Power BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.8 Tables de journalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.9 Chargement de la table employé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.10 Fichiers source pour la table employé . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.11 Chargement de la table projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.12 Fichiers source pour la table projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.13 Chargement de la table département . . . . . . . . . . . . . . . . . . . . . . . . . . 44
vi

4.14 Fichiers source pour la table département . . . . . . . . . . . . . . . . . . . . . . . 44
4.15 Chargement de la table imputation . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.16 Fichiers source pour la table imputation . . . . . . . . . . . . . . . . . . . . . . . . 45
4.17 Chargement de la dimension agence . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.18 Chargement de la dimension employé . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.19 Chargement de la dimension projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.20 Chargement de la dimension tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.21 Chargement de la table des faits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.22 Colonnes ajoutées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.23 Tableau de bord suivi des effectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.24 Tableau de bord suivi d’ancienneté . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.25 Tableau de bord suivi de turnover . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.26 Tableau de bord suivi absentéisme . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.27 Tableau de bord suivi des formations . . . . . . . . . . . . . . . . . . . . . . . . . . 56
vii

Liste des tableaux
1.1 Différences entre tableau de bord RH & rapport RH . . . . . . . . . . . . . . . . . . 11
1.2 Comparatif entre les approches agile & classique . . . . . . . . . . . . . . . . . . . 13
1.3 Comparatif entre les méthodes SCRUM & GIMSI . . . . . . . . . . . . . . . . . . . 14
3.1 KPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Description des fichiers sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Détails des tables de l’ODS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Description des dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5 Table des faits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1 Comparatif des outils ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Comparatif des outils de visualisation . . . . . . . . . . . . . . . . . . . . . . . . . 37
viii

Acronymes
BI Business Intelligence.
DAX Data Analysis Expressions.
DRH Direction Ressources Humaines.
DW Data Warehouse.
ETL Extract Transform Load.
GIMSI Généralisation Information Système Initiative.
KPI Key Performance Indicator.
ODS Operating Data Staging.
RH Ressources Humaines.
SID Système d’Information Décisionnelle.
SQL Structured Query Language.
SSIS SQL Server Integration Services.
SSMS SQL Server Management Studio.
SWOT Strengths Weaknesses Opportunities Threats.
ix

INTRODUCTION GÉNÉRALE
Pour une entreprise, les décisions ne peuvent pas se faire au hasard.
Suivre les évolutions, mieux comprendre le déroulement de l’activité, visualiser rapidement les fluc-
tuations du marché et bien d’autres objectifs se font au cœur de la Business Intelligence.
La BI est un outil faveur pour les décideurs et les dirigeants des entreprises. Elle désigne les moyens
et les méthodes qui permettent de collecter, consolider, modéliser et restituer les données d’une en-
treprise en vue d’offrir une aide à la décision.
Timidement initiée dans les années 1980, la BI était, au départ, centrée sur le domaine comptable et
financier. Ces dernières années, elle s’est progressivement étendue à d’autres domaines pouvant le
mieux exploiter ses informations pour guider leurs décisions : gestion de la relation client, logistique,
marketing, Ressources Humaines, commercial, etc.
Aujourd’hui, dans un environnement de plus en plus compétitif où les évolutions technologiques
et la modélisation guident les stratégies, la fonction de RH devient, en effet, primordiale.
Le capital humain, véritable ressource vivante, impose aujourd’hui aux Direction Ressources Hu-
maines de passer d’une gestion du personnel classique à une gestion globale, dynamique et innovante
pour mieux gérer, anticiper, choisir, accueillir, former, rémunérer et développer l’efficacité collective
des personnes qui travaillent pour l’entreprise.
Les gestionnaires ressources humaines ont ainsi besoin d’instrument qui leur donnent des informa-
tions sur l’environnement interne et la performance des processus RH, et qui les aident à mettre le cap
sur l’excellence.
D’où l’intérêt à se lancer dans l’aventure de la BI. Pour ce faire, un outil de pilotage se distingue : le
tableau de bord RH.
Il est encore très fort peu utilisé, en dehors des traditionnelles statistiques d’effectifs, de rotation
du personnel et d’absentéisme, cet instrument est pourtant appelé à un très rapide développement,
appliqué au domaine des RH.
Il représente un outil de pilotage nécessaire à la gestion de la fonction RH, qui se fonde sur un en-
semble de données stratégiques dérivant d’une comparaison entre la situation espérée et la situation
réelle. Il fournit aux responsables RH une visibilité simple et claire sur les différents mouvements de
la situation, des résultats obtenus et des améliorations à apporter, aussi bien envisagés à effectuer.
Le tableau de bord RH est l’un des outils incontournables pour la prise de décision permettant de :
se positionner, coordonner les activités, mesurer la performance et se projeter dans le futur, grâce aux
informations qu’il est capable de produire en terme de statistiques d’effectifs, formation, rotation du
personnel, etc.
Vu l’importance du tableau de bord RH pour la fonction RH, nous allons réaliser cet outil décisionnel
1

2
pour Wimbee Tech, savoir les indicateurs les plus représentatifs et illustrer les méthodes utilisées pour
son élaboration. Nous allons ainsi essayer de donner une interprétation du tableau de bord tout en es-
sayant de fournir au maximum des améliorations aux responsables sur son contenu en cas d’exigence.
Notre projet englobe la modélisation de l’entrepôt de données, l’extraction, la transformation, le char-
gement et la restitution des informations, et ceux, afin de générer des tableaux de bord interactifs et
des indicateurs de performance.
Nous avons scindé notre rapport en 4 chapitres :
— Le premier présent l’organisme d’accueil, introduit le cadre du projet et ses objectifs en
définissant la problématique, l’étude de l’existant et la solution dégagée ainsi que ses spécificités
et la méthodologie adoptée pour ce projet.
— Le deuxième fera l’objet d’une étude sur les concepts généraux de l’informatique décisionnelle.
— Le troisième se focalise sur la présentation de l’architecture de la solution, le choix des indi-
cateurs et la modélisation de l’entrepôt de données.
— Le dernier se résume en trois parties la description de notre environnement de réalisation, le
développement du processus ETL et l’illustration d’un aperçu sur les tableaux de bord que
nous avons réalisé.

Chapitre 1
CONTEXT GÉNÉRAL DU PROJET
1.1 Introduction
Ce chapitre introductif a pour vocation de mettre le projet dans son contexte, à commencer par
présenter l’organisme d’accueil Wimbee Tech, puis présenter la problématique avec une étude de
l’existant et la solution proposée.
Par la suite, nous passerons à l’analyse des besoins qui est une phase critique dans la conduite du
projet puisqu’elle définit les besoins réels des personnes qui vont exploiter le résultat final suivi
d’une présentation de quelques notions des tableaux de bord sociaux avec une présentation de la
méthodologie de travail adoptée et la planification prévisionnelle.
1.2 Présentation de l’organisme d’accueil
1.2.1 Présentation générale de Wimbee Tech
Wimbee Tech, un cabinet privé et multi-spécialiste de conseil et d’intégration de systèmes, fondé
en France et implémenté en Tunisie. Ce cabinet a démarré ses activités en Tunisie en 2019.
Figure 1.1 – Logo de Wimbee Tech
Fort d’une expertise fonctionnelle et technologique dans ses domaines de spécialisation, de la data et
du digital, ce groupe a déjà contribué à la réussite de plus de 90 projets en offrant à ses clients des
solutions innovantes établies par une équipe ayant une expérience de plus de 20 ans et des références
majeures dans le secteur des Technologies et services de l’information.
3

CHAPITRE 1. CONTEXT GÉNÉRAL DU PROJET 4
Figure 1.2 – Spécialités et domaines d’intervention de Wimbee Tech
1.2.2 Pôle RH et Organigramme
Les directeurs ressources humaines doivent favoriser une dynamique RH porteuse et flexible. De
la gestion du stress à l’impulsion d’une nouvelle culture, du recrutement au suivi des talents, de la
revue des conditions de travail au remodelage de l’organisation, les changements (contraints) peuvent
dégager des impacts positifs.
Afin de gérer ses employés, les entreprises ont mis en place un service des ressources humaines
qui prend en charge des différents aspects, comme le montre la figure 1.3 :
Figure 1.3 – Perspectives des ressources humaines

Ce service est animé par le global talent manager qui a pour mission de :
— Suivre les réalisations et les écarts aux prévisions.
— Anticiper et simuler les évolutions de variables afin de décider des orientations à prendre.
— Communiquer auprès de chaque ” Client ” de la fonction RH le statut de leurs attentes.
Son rôle est capital, car la gestion du personnel est une clef essentielle du succès et du développement
d’une entreprise.
C’est sur cette mission du pôle RH que j’interviens.
Le schéma 1.4 illustre l’organigramme de Wimbee :
Figure 1.4 – Organigramme de Wimbee Tech
1.2.3 Analyse SWOT
Le SWOT (Strengths - Weaknesses - Opportunities - Threats) pour les Francophones (Menaces -
Opportunités - Forces - Faiblesses,) est un outil très pratique et populaire lors de la phase de diagnos-
tic stratégique parce qu’il est rapide et facile à utiliser.
L’analyse SWOT consiste à présenter l’avantage de synthétiser les forces et les faiblesses d’une en-
treprise au regard des opportunités et menaces générées par son environnement.
La figure 1.5 représente l’analyse SWOT de Wimbee Tech :

Figure 1.5 – Analyse SWOT de Wimbee Tech
1.3 Cadre du projet
Les responsables RH ne sont pas toujours les mieux ”outillés” alors qu’il existe bel et bien des
logiciels à forte valeur ajoutés. Ces logiciels recèlent une vraie richesse en matière de données à ex-
ploiter : la base des salariés avec leurs informations personnelles représente un pilier fondamental sur
lequel s’appuient nombre de déclarations et d’indicateurs de pilotage pour les managers.
Côté Gestion des Ressources Humaines, les entreprises ne sont pas dotées d’un système qui leur
permet de suivre l’évolution de ses effectifs, d’organiser le recrutement, d’anticiper les évolutions
métiers, d’établir un suivi de formation et de montée en compétences, de dégager des prévisions ou
de gérer le planning des congés, etc.
Par conséquent, l’information, lorsqu’elle est formalisée, se trouve éparpillée dans différents fichiers
Excel ou différentes bases de données, non synchronisées, hétérogènes et complexes à utiliser.
Partant de cette analyse, un constat s’impose. Chaque département RH d’une entreprise a besoin
de mettre en place des méthodologies d’analyse décisionnelle afin d’optimiser l’exploitation de ses
données.
Les solutions de Business Intelligence répondent à cet enjeu métier avec le décisionnel RH.
1.3.1 Problématique
Les directeurs RH sont submergés par des données relatives aux salariés qui ne cessent d’augmen-
ter.

Autant des sources de données, qui à défaut d’être regroupées au sein d’un système unique, réclament
beaucoup de temps de manipulation et de traitement pour pouvoir être valorisées.
Suivi des effectifs, de recrutement, suivi de Turn-Over, d’absentéisme, gestion des compétences et
évaluation d’efficacité, ces coûts humains sont un défi à gérer au quotidien, et forment la matière
première de ce qui déterminera l’ensemble des actions et des prévisions.
Ce qui rend la direction des ressources humaines confrontée à deux problématiques majeures :
- Comment fiabiliser des données sociales issues de sources diverses?
- Comment établir et évaluer des tableaux de bord RH pour des utilisateurs multiples?
Ces problématiques ont amené le département RH à être un des premiers à devoir maı̂triser ses
données et donc à se tourner vers la Business Intelligence.
1.3.2 Analyse de l’existant
À mon arrivée chez Wimbee Tech, j’ai constaté que la direction des ressources humaines ne dis-
pose pas d’un tableau de bord regroupant des indicateurs de performance.
Ce qui est raisonnable pour une nouvelle entreprise, qui a récemment lancé ses activités sur le marché,
d’utiliser Excel pour gérer ses données.
Dès que l’activité augmente, se diversifie et les nouveaux collaborateurs intègrent l’entreprise, les
tableurs d’Excel deviennent vite contraignants.
La DRH utilise encore ce logiciel et fait face à certaines limites :
— Saisie et ressaisie : La ressaisie rime avec perte de temps, une erreur ou une mauvaise donnée
se glisse dans une feuille Excel, c’est tout un ensemble de rapports qui peut être impacté ou
faussé.
— Erreurs de calculs : Une inexactitude des données ou des calculs est un vrai risque pour
l’entreprise.
— Manque de souplesse : Excel présente vite des limites pour suivre et générer des tableaux de
bords précis et fiables.
— Extraction des rapports et tableaux de bord RH peu vident.
Ces limites peuvent conduire à de mauvaises estimations et des décisions à risque.
Ci dessous quelques captures de l’exsistant :

Figure 1.6 – Fichier de gestion de congés de Wimbee
Figure 1.7 – Fichier de gestion des employés de Wimbee
1.3.3 Solution proposée
Partant de ces contraintes, Wimbee Tech propose alors de mettre en place un système d’informa-
tion décisionnel permettant d’accompagner le ”Global Talent Manager” dans son exercice quotidien.
À partir de ses données rationalisées, on tient à créer des tableaux de bord qui correspondent à leurs
besoins spécifiques.
Ces tableaux de bord sociaux, présentent alors une solution de dashboarding à destination de la direc-
tion RH, intelligible et lisible, contenant des indicateurs RH pertinents ainsi que des axes d’analyses
(absentéisme, temps, carrière, etc) permettant d’analyser rapidement les tendances.

En effet, elle apporte un suivi et un pilotage efficace, une vision synthétique du présent et de l’ave-
nir permettant d’enrichir les décisions stratégiques de l’entreprise et d’avoir des réponses claires aux
problématiques de la direction :
— Pilotage des effectifs.
— Anticipation des départs.
— Recrutement des nouveaux talents.
— Gestion des formations.
— Mesure d’efficacité et des performances.
— Gestion des plannings (temps de travail, absentéisme, congés, etc).
Pour aboutir à cette solution, nous avons divisé notre travail en trois grands volets :
— Un premier volet vise à identifier les indicateurs de performance.
— Un second volet qui a pour but de récupérer les données sources passant par toute la chaı̂ne
ETL livrant à la fin un data warehouse contenant des données pertinentes prêtes à être évaluées.
— Un dernier volet qui consiste à exploiter ces données provenant de l’ETL et élaborer des
tableaux de bord riches.
1.3.4 Prototypage (Maquettes)
Pour donner du réalisme à notre projet, nous avons investi du temps dans la conception d’un pro-
totype, un tableau de bord représentative et simple adapté à notre projet.
Étant donné l’importance de la phase de modélisation avant la réalisation concret du projet et en
vue d’intégrer les nouveautés dans celle-ci, nous avons utilisé le site clicdata.com dans l’élaboration
du tableau de bord.
Figure 1.8 – Logo du site Clicdata
La figure 1.10 représente un aperçu de l’ensemble des maquettes du tableau de bord social réalisées
sur Clicdata :

Figure 1.9 – Maquettes du tableau de bord
1.4 Analyse et spécification des besoins
1.4.1 Besoins fonctionnels
Les spécifications de l’entrepôt
L’entrepôt doit être conçu de manière qu’il permet de :
— Construire une source de données unique et non volatile.
— Mieux contrôler les données.
— Rendre la base plus évolutive et plus adaptée à nos futurs besoins.
— Garder la traçabilité de chaque donnée.
— Avoir une modélisation multidimensionnelle des données.
Les spécifications du tableau de bord
Afin de répondre aux besoins du service RH et de leur garantir des analyses exactes et une prise
de bonnes décisions nous nous sommes concentrés sur les tableaux de bord sociaux.
Notre solution a pour objectif de faire bénéficier son utilisateur de tous ces volets en se basant sur
plusieurs filtres (sexe, situation familiale, département, mois, année) :

— Visualisation d’un tableau de bord pour le suivi d’évolution et de répartition des effectifs.
— Visualisation d’un tableau de bord pour le suivi d’ancienneté.
— Visualisation d’un tableau de bord pour le suivi des mouvements du personnel (turnover).
— Visualisation d’un tableau de bord pour le suivi d’absentéisme et des congés.
— Visualisation d’un tableau de bord pour le suivi des formations.
1.4.2 Besoins non fonctionnels
Les besoins non-fonctionnels représentent les exigences implicites qui décrivent les critères de
qualité auxquels le tableau de bord doit répondre.
— Fournir des interfaces interactives et faciles à manipuler par les décideurs afin d’explorer leurs
données en temps réel.
— Fournir des tableaux de bord clairs et facilement analysables.
— Fournir un entrepôt de donnée fiable et performant.
— Fournir un tableau de bord avec des analyses exactes et bien précises en présentant les princi-
paux indicateurs de performance.
1.5 Les tableaux de bords au sein du pilotage RH
Le pilotage RH permet à la DRH de valoriser son action, de démontrer sa contribution à la per-
formance globale de l’entreprise. Un de ses enjeux est donc la reconnaissance de la valeur ajoutée
apportée par les ressources humaines.
On site parmi les principaux outils de pilotage RH :
— Le tableau de bord RH (Dashboarding) , l’outil d’aide à la décision.
— Le rapport RH (Reporting) , l’outil de contrôle.
Critères Tableau de bord RH Rapport RH
Destinataires Le service RH, La direction La direction
Indicateurs Indicateurs de performance,
Indicateurs de leviers
Indicateurs de résultats
Objectifs Pilotage de la performance,
Management du service,
Gestion du changement
Évaluation de la performance du
service RH
Table 1.1 – Différences entre tableau de bord RH & rapport RH
[1]
1.5.1 Définition d’un tableau de bord RH
Le tableau de bord RH est un outil de pilotage nécessaire à la fonction RH qui aide la direction des
ressources humaines à évoluer la réalisation des objectifs fixés en amont, garantir un meilleur suivi

et prendre les bonnes décisions à partir des analyses et de l’ensemble des indicateurs de performance
mesurés et axés sur les facteurs clés de succès.
IL se réuni sur un ensemble de données stratégiques dérivant d’une comparaison entre la situation
espérée et la situation réelle. [1]
1.5.2 Les principaux avantages et objectifs d’un tableau de bord RH
À l’aide des informations recueillies, les responsables des ressources humaines pourraient plus
facilement :
— Établir une aide à la décision et à la stratégie du service grâce à une analyse bien déterminée
grâce à des données chiffrées et précises.
— Avoir une visualisation rapide et synthétique des principales clés de performance de la GRH.
— Calculer les performances de son département et leurs incidences sur l’activité.
— Identifier des actions correctives sur les points qui pèsent sur l’organisation.
— Mesurer les résultats selon les objectifs définis.
— Analyser et comprendre :
• L’évolution, la répartition et la variation des effectifs.
• Les taux d’absentéisme.
• La gestion de la rémunération.
• Le processus de recrutement et de formation.
• La gestion des compétences et des talents.
• Les taux du Staffing.
• L’efficacité des effectifs.
• Le climat organisationnel de l’entreprise. [1]
1.5.3 Les étapes d’élaboration d’un tableau de bord RH
1. Définition d’une stratégie de gestion des ressources humaines claire, en tenant compte du
contexte de l’entreprise et en accord avec tous ses acteurs.
2. Définition d’objectifs de progrès et de performance.
3. Choix des indicateurs clés de performance.
4. Collecte des informations.
5. Conception d’un tableau de bord clair et lisible. [1]
1.6 Gestion du projet au cœur de la BI
Durant l’implémentation d’une solution décisionnelle, il reste essentiel de suivre et gérer le projet
dans le but de garantir le bon déroulement et l’aboutissement au résultat escompté.
1.6.1 Étude comparatif entre les approches de gestion de projet
Approches classiques
Une approche dite aussi ”traditionnelle” nécessite généralement un cahier des charges très précis,
des tâches décrivant les besoins en entrée de réalisation laissant peu de place au changement.

Chaque tache dépend de celle qui la précède, elle ne peut pas commencer tant que l’ancienne n’est
pas achevée.
La réalisation dure le temps qu’il faut avec peu d’interaction client ou extérieurs. Cet effet tunnel peut-
être néfaste et conflictuel, on constate souvent un déphasage entre le besoin et l’application réalisée.
Cette approche a rapidement dévoilé ses limites avec la complexité croissante des projets liés à 3
principes qui sont : le travail d’équipe, la technologie vu cette grande évolution et prévenir les besoins
de l’utilisateur.
Approches agiles
Une approche beaucoup plus flexible que l’approche classique. Elle propose de réduire considérablement
voire complètement l’effet tunnel en donnant d’avantage de visibilité, à laquelle le client final et
l’utilisateur seront intégrés et participant de façon active tout en adoptant un processus itératif et
incrémentale.
Elle considère que le besoin ne peut pas être figé et qu’il va sans doute évoluer au fil du projet en
s’adaptant aux changements.
Un projet BI n’est jamais simple à implémenter du fait même de son objectif premier à savoir
mettre à la disposition de ses différents destinataires les bonnes informations à temps à travers des
solutions qui leur permettent de rendre des décisions stratégiques pour l’entreprise, et cela, le plus
rapidement possible dans un univers en éternel changement.
Le tableau 1.2 dévoile les principales différences entre les approches traditionnelles et les ap-
proches agiles.
Approche Agile Classique
Cycle de vie Itératif et incrémental Séquentiel
Planification Adaptative Prédictive
Objectif Satisfaire le client Respecter les engagements et
les besoins initiaux
Changement Adaptée au changement Inadéquate au changement
Équipe Travail en synergie Chacun à sa tâche
Communication Communication permanent,
implication du client tout au
long de la réalisation du projet
Peu d’interaction avec le client
Livraison Livrer fréquemment Livrer en fin de cycle une seule
fois
Amélioration Ouverte à l’innovation et
l’amélioration au fil du projet
Amélioration possible à la fin de
projet
Table 1.2 – Comparatif entre les approches agile & classique
[2]
Nous retiendrons donc quelle application d’une approche agile à notre projet BI ne peut être que
profitable tant elle contribue à l’évolutivité des besoins fonctionnels d’une part et à la réduction des
coûts de réalisation. Par conséquent, nous continuerons d’appliquer l’approche agile à notre projet
d’enquête qui ne peut être rentable que parce qu’elle contribue à augmenter les besoins de l’emploi

en termes de réduction des coûts de mise en œuvre.
1.6.2 Étude comparatif entre les méthodes de gestion de projet
Nous avons choisi d’adopter une approche agile, il reste encore à choisir la méthode la plus
adaptée à notre projet.
Cependant, le tableau 1.3 représente un comparatif entre SCRUM qui figure comme la méthodologie
la plus utilisée et GIMSI une méthode pour concevoir et réaliser le système décisionnel.
Méthode SCRUM GIMSI
Planification Au début de chaque sprint Flux continu
Estimation de l’effort Au début de chaque sprint Optionnel,
prédictibilité
Changement de périmètre Doit attendre le sprint suivant Selon le besoin
Rôles Scrum Master,
product owner,
développeur(s)
Equipe
Top 3 bénéfices Productivité,
Scalabilité,
Engagement des équipes
Mise en place rapide sans chan-
gement des processus existants,
Pilotage visuel
Table 1.3 – Comparatif entre les méthodes SCRUM & GIMSI
D’une façon générale, même si les deux méthodes sont différentes, elles ne s’opposent pas réellement.
Suite à notre étude comparative, nous avons choisi de suivre la méthode GIMSI qui est destinée à la
construction des tableaux de bord et qui prend en considération les étapes de développement d’un
projet décisionnel avec une application de l’approche agile.
1.6.3 La méthode GIMSI
GIMSI s’inscrit comme une méthode agile qui met en évidence la nouvelle informatique décisionnelle
orientée par l’utilisateur final, guidée par l’aperçu.
La méthode GIMSI définit un cadre méthodologique permettant d’indiquer les contraintes de la
réussite d’un projet décisionnel.
En effet, cette méthode est utilisée pour conduire et déployer le projet afin d’intégrer un système
de tableaux de bord au cœur de l’entreprise sans perdre de vue l’interrogation de l’amélioration de la
performance.
La méthode GIMSI est composée de 10 étapes, chacune traitant un fait précis du projet. Chaque
étape présente une limite dans l’avancement du système. Un peu plus, ces étapes peuvent être ras-
semblées en quatre phases principales. [3]

Identification
— Etude de l’environnement de l’entreprise : Identification de l’environnement économique
et la stratégie de l’entreprise dans le but de déterminer les périmètres et le contexte du projet.
— Identification de l’entreprise : Etude de la structure organisationnelle et fonctionnelle de
l’entreprise et les acteurs concernés.
Conception
— Définition des objectifs : Recherche des objectifs tactiques de chaque équipe de travail.
— Construction du tableau de bord : Définition du tableau de bord de chaque équipe qui est
un outil d’aide à la décision à travers des indicateurs de performance.
— Choix des indicateurs : Choix des indicateurs de performance est l’étape la plus importante,
ces indicateurs sont choisis en fonction des objectifs bien choisis, du contexte et des acteurs
concernés.
— Collecte des informations : Identification des informations à la construction des indicateurs.
— Le système de tableau de bord : Construction du système de tableau de bord, contrôle de la
cohérence globale.
Mise en œuvre
— Choix des progiciels : Sélection des progiciels adéquats pour la mise en œuvre du tableau de
bord.
— Intégration et déploiement : Implémentation du progiciel et son intégration à l’existant et le
déploiement à l’entreprise.
Amélioration permanente
— Audit : Suivi de la certitude de l’adéquation entre le système et les nouveaux besoins des
utilisateurs.
1.7 Planification prévisionnelle
La planification est une étape importante dans le déroulement du projet parce qu’elle traduit l’or-
ganisation du projet et l’estimation du temps nécessaire à la réalisation des différentes tâches. Pour
cela, nous décomposons le projet en plusieurs tâches et nous prévoyons à chaque tâche le temps
nécessaire pour sa finalisation.
Le diagramme ci-dessous présente les différentes étapes à suivre pour la réalisation de notre projet.

Figure 1.10 – Planification du projet
1.8 Conclusion
Ce chapitre nous a permis de mettre le projet à son cadre général dans le but de fixer les ob-
jectifs à atteindre et les améliorations à ajouter. Ce contexte nous a aussi permis d’organiser notre
méthodologie de travail et de donner un aperçu sur les différentes phases à suivre.
Le chapitre suivant est consacré à la présentation des concepts théoriques de base en rapport avec
la réalisation de notre solution.

Chapitre 2
CONCEPTS THÉORIQUES & ÉTAT DE
L’ART
2.1 Introduction
Après avoir exposer le contexte du projet, nous expliquerons via ce chapitre, les différentes notions
de l’informatique décisionnelle.
2.2 Concepts généraux de la BI
L’informatique décisionnelle a un poids, un sens défini, et apporte une réelle valeur ajoutée à
l’entreprise.
2.2.1 Historique de l’informatique décisionnelle
Les données au sein des entreprises ne cessent d’augmenter et la charge de travail ainsi que la
complexité des structures de données devient trop importante. Devant cette problématique, des appli-
cations de collecte des données ont été mis en place à la fin des années 60 et les années 70 respecti-
vement les bases de données et les 1 ers tableurs minimalistes : Excel.
Dans les années 80, les entrepôts de données sont apparus pour répondre aux besoins des utilisa-
teurs de faire des analyses multidimensionnelles en leur permettant à la fois un meilleur accès et une
meilleure gestion des bases de données.
Les besoins d’analyse ne cessent d’évoluer et les technologies continuent à se progresser, ce qui
exige la naissance de la Business intelligence en 1989 par l’informaticien Howard Dresner.
17

CHAPITRE 2. CONCEPTS THÉORIQUES & ÉTAT DE L’ART 18
Figure 2.1 – Historique de l’informatique décisionnelle
2.2.2 Définition de l’informatique décisionnelle
Un système d’information décisionnel est défini comme étant ” un regroupement de données
orientées vers certains sujets, intégrées, dépendantes du temps, non volatiles, ayant pour but d’ai-
der les gestionnaires dans leurs prises de décision.” Inmon,1996]
En effet, les SIDs ont pour mission de supporter la prise de décision et d’avoir une vue d’ensemble sur
l’activité d’une entreprise à l’aide des tableaux de bord et des outils de pilotages qu’ils produisent. [4]
2.2.3 Principes de l’informatique décisionnel (pourquoi la BI?)
— Les systèmes transactionnels ne sont pas adaptés.
— Répondre aux questions des décideurs.
— Comprendre et analyser les données stockées.
— Centraliser et normaliser les données.
— Source unique d’information pour les décideurs.
— Disposer de données déjà consolidées pour prendre des décisions.
— Mesurer le résultat d’une activité ou d’une prise de décision.
— Mettre à disposition des utilisateurs finaux des données facilement exploitables.
2.2.4 Objectif de l’informatique décisionnel
La plupart des entreprises disposent d’un volume important de données réparties à travers des
bases de données et des systèmes transactionnels distribués. Ces bases de données et systèmes sont
généralement conçus pour des opérations spécifiques ou pour des opérations de traitement.
Cependant, ce que ces bases de données et systèmes ne sont pas conçus pour faire, c’est de communi-
quer entre eux, et de permettre aux utilisateurs de consulter des données d’une manière non-usuelle,
ou de fournir des analyses de données de haut niveau à des instants précis.
Les objectifs principaux de l’informatique décisionnelle sont, en fait, de combler ce vide et de fournir
ces capacités :
— La facilité de consulter en une seule vue des données provenant de diverses sources.
— La facilité d’obtenir rapidement des analyses de données provenant de différents systèmes.
— La facilité d’examiner des données réparties sur le temps.

— la facilité de générer des scénarios de simulation et d’obtenir des réponses basées sur des
données historiques.
Une conception bien étudiée et une mise en œuvre réussie d’une solution d’informatique décisionnelle
peuvent rapidement générer un retour sur investissement fort intéressant qui est sans aucun doute un
facteur que les dirigeants d’entreprise apprécient.
2.3 Architecture d’un système décisionnel
Un système décisionnel est composé de différentes phases que nous pouvons également les modéliser
de la manière suivante :
— Plusieurs sources de données en lecture.
— Un entrepôt de données fusionnant les données requises.
— Un ETL permettant d’alimenter l’entrepôt de données à partir des données existantes.
— Des magasins de données permettant de simplifier l’entrepôt de données.
— Des outils de visualisations données pour présenter l’étude aux utilisateurs finaux et décideurs.
La figure ci-dessous permet de connaı̂tre le positionnement de chacun de ces éléments :
Figure 2.2 – Architecture d’un système décisionel
[5]
Après avoir exposer l’architecture globale d’un système décisionnel, il serait intéressant de mieux
expliquer ses composants :
2.3.1 Sources de données
Afin d’alimenter l’entrepôt, les informations doivent être identifiées et extraites de leurs empla-
cements originels. Il s’agit des sources de données hétérogènes qui peuvent comporter des données
internes à l’entreprise, stockées dans les bases de données de production des différents services. Elles
peuvent être aussi des sources externes, récupérées via des services distants et des web services ou
des sources qui peuvent être sous format de fichiers plats.

2.3.2 Processus ETL
ETL, acronyme d’Extraction Transformation et Chargement, est un processus automatisé d’intégration
des données, qui extrait l’information nécessaire à l’analyse à partir des données brutes, la transforme
en un format qui peut répondre aux besoins opérationnels et la charge dans un entrepôt de données.
Cependant, la réalisation de l’ETL est une étape très importante et très complexe parce qu’il constitue
70% d’un projet décisionnel en moyenne.
2.3.3 Entrepôt de données (Data warehouse)
Est le lieu de stockage et de centralisation des données, alimentées grâce au processus ETL, il est
structuré pour contenir une volumétrie importante de données, les données sont :
— Orientées sujet : les données des entrepôts sont organisées par sujet et donc triées par thème.
— Intégrées : les données provenant des différentes sources doivent être intégrées avant leur
stockage dans l’entrepôt de données. Un nettoyage préalable des données est nécessaire afin
d’avoir une cohérence et une normalisation de l’information.
— Non-volatiles : à la différence des données opérationnelles, celles de l’entrepôt sont perma-
nentes et ne peuvent pas être modifiées. Le rafraı̂chissement de l’entrepôt, consiste à ajouter
de nouvelles données sans perdre celles qui existent.
— Historiées : les données doivent être datées.
2.3.4 Magasin de données (Data Marts)
Les magasins de données ou Datamarts sont un sous-ensemble complet et naturel de l’entrepôt
de données. Ils sont structurés, ciblés, regroupés et agrégés pour répondre rapidement aux besoins
spécifiques des utilisateurs.
2.4 Théories d’entrepôt de données
2.4.1 Objectif d’un entrepôt de données
L’objectif principal des entrepôts de données est de supporter la prise de décision en permettant
une meilleure exploitation des informations des systèmes opérationnels des entreprises.
— L’entrepôt de données doit rendre les données de l’organisation accessible facilement : le
contenu de l’entrepôt de données doit être facile à comprendre pour le simple utilisateur et pas
uniquement pour le développeur.
— L’entrepôt de données doit présenter l’information de l’organisation de manière cohérente : les
données de l’entrepôt doivent être assemblées à partir de différentes sources de l’organisation
et nettoyées et leurs qualités soient contrôlées. La cohérence implique une haute qualité, elle
suppose aussi que l’on a tenu compte que toutes les données soient complètes.

— L’entrepôt de données doit être adaptable et résistant aux changements : les modifications de
l’entrepôt de données ne doivent pas invalider les données existantes ou les applications.
— L’entrepôt de données doit protéger notre richesse informationnelle : l’entrepôt de données
doit efficacement contrôler l’accessibilité aux informations confidentielles de l’organisation.
— L’entrepôt de données doit être le socle sur lequel repose l’amélioration des prises de décision :
Il doit contenir les données permettant à étayer les décisions. En fait, ces dernières sont la
valeur ajoutée de l’entrepôt de données.
— L’acceptation de l’entrepôt de données par la communauté des utilisateurs est l’une des condi-
tions de sa réussite : l’acceptation des utilisateurs à l’entrepôt de données est avant tout liée à
sa simplicité d’utilisation.
2.4.2 Démarche de construction d’un entrepôt de donné
2.4.2.1 Conception d’un entrepôt de données
Les approches les plus connues dans la conception des entrepôts sont :
— L’approche descendante qui est basée sur les besoins d’analyse.
— L’approche ascendante qui est basée sur les sources de données.
— L’approche mixte qui est une combinaison des deux approches.
A. Approche descendante
Dans cette approche le contenu de l’entrepôt sera déterminé selon les besoins de l’utilisa-
teur final. Ainsi, les instructions sont données en amont et les objectifs du projet sont fixés
par la direction. Toutes les attentes du chef de projet sont communiquées clairement à chaque
participant au projet.
B. Approche ascendante
C’est une approche dont le contenu de l’entrepôt est déterminé selon les sources de données.
C’est un processus analytique qui examine des données de base pour en tirer un schéma mul-
tidimensionnel offrant une vision analytique des données.
C. Approche mixte
C’est une approche hybride qui combine les approches ascendante et descendante. Elle prend
en considération les sources de données et les besoins des utilisateurs.
2.4.2.2 Modélisation d’un entrepôt de données
Les composants d’un schéma décisionnel :
Les entrepôts dde données sont destinés à la mise en place des systèmes décisionnels. Ces systèmes,
devant répondre aux différents objectifs des systèmes transactionnels, ce qui met en évidence la
nécessité de s’adresser à un modèle de données simplifié et compréhensible : c’est la modélisation
dimensionnelle.

Elle consiste à considérer un sujet d’analyse comme un cube à plusieurs dimensions, mettant à sa
disposition des vues en tranches ou des analyses selon différents axes.
Dans la modélisation dimensionnelle, chaque modèle se compose d’une grande table centrale et un
jeu de petites tables auxiliaires disposées autour de la table centrale.
Celle-ci est appelée table de faits et les autres tables sont appelées tables de dimensions.
— Table de faits : est la table centrale du modèle dimensionnel, regroupant des clés étrangères,
qui ne sont autres que les clés primaires des tables de dimension. Elle contient les informations
observables (les mesures) sur ce qu’on veut analyser. Chaque ligne de la table correspond à
une mesure qui modélise le sujet de l’analyse.
— Tables de dimensions : sont des compagnons de la table de faits, chaque table représente un
axe d’analyse. Elles contiennent le contexte associé à un événement de mesure du processus
métier. modélise un axe d’analyse.
Modélisation logique des données :
Les tables de faits et les dimensions sont organisées suivant un modèle de données spécifique et
simple qui correspond au besoin de la modélisation dimensionnelle. Nous distinguons trois modèles
possibles :
— Le modèle en étoile : ce modèle se présente comme une étoile dont le centre est la table des
faits et les branches sont les tables de dimensions.
La force de cette modélisation est sa lisibilité et sa performance, elle utilise moins de join-
tures et de requêtes simples mais présente des problèmes tels que la redondance et l’intégrité
des données.
Ce modèle est décrit dans la figure 2.3
Figure 2.3 – Modèle en étoile
— Le modèle en flocon de neige : identique au modèle en étoile, sauf que ses dimensions sont
décomposées en hiérarchies (chaque niveau est représenté dans une table différente).
Cette modélisation est plus facile à maintenir permettant de réduire la redondance des données
et de prévenir les pertes de mémoire, par contre, elle est plus lente lors de l’interrogation suite

à l’augmentation du nombre de jointures.
La figure 2.4 illustre le schéma en flocon :
Figure 2.4 – Modèle en flocon de neige
— Le modèle en constellation : Ce modèle est une fusion de plusieurs modèles en étoile liés
entre eux par des dimensions. En effet, un modèle en constellation comprend plusieurs rela-
tions de faits et des dimensions quelque soient communes ou non.
Ce modèle est figuré dans le schéma 2.5 :
Figure 2.5 – Modèle en constellation
2.4.2.3 Alimentation de l’entrepôt de données
La notion d’ETL (Extract Transform Loading), recouvre à la fois des outils et des processus d’ali-
mentation d’un entrepôt de données. Il s’agit d’un élément clé qui permet de réaliser un passage en
masse d’information d’une base de données vers une autre.
Il est utilisé pour alimenter le datawarehouse à partir de base de données opérationnelles. Ainsi, il
permet l’extraction, le nettoyage et l’importation des données de multiples et différentes sources et il
les charge dans un entrepôt de données périodiquement sous une forme adaptée pour les analyses que
nous souhaitons effectuer par la suite.

La figure 2.6 qui modélise le processus ETL :
Figure 2.6 – Processus ETL
En effet, un système ETL permet de :
— Offrir un point de vue unique, en combinant des bases de données et diverses formes de
données en une seule vue unifiée.
— Rassembler les données, maintenir l’exactitude et fournir l’audit généralement requis pour
l’entreposage de données, le reporting et l’analyse.
— Faciliter l’analyse, la visualisation et la compréhension de grands ensembles de données.
— Nettoyer et standardiser les données selon des règles établies par l’entreprise.
— Charger les données dans un entrepôt de données et les propager vers data-marts.
— Fournir un contexte historique profond lorsqu’il est utilisé avec un entrepôt de données d’en-
treprise.
2.4.2.4 Restitution
C’est la dernière étape d’un projet d’entreposage de données, soit son exploitation. L’exploitation
de l’entrepôt se fait par le biais d’un ensemble d’outils analytiques développés autour de ce dernier.
Le principe de la restitution, donc, est d’agréger et de synthétiser des données nombreuses et com-
plexes sous forme d’indicateurs, de tableaux, de graphiques ainsi avoir une visualisation d’interfaces
interactives et fonctionnelles qui sont facile à comprendre et à analyser.
A. Les outils de restitution
La figure 2.7 présente les outils les plus connus :
Figure 2.7 – Outils de restitution

B. Les modes de présentation
— Tableaux de bords (Dashboards)
Les tableaux de bord fournissent à l’utilisateur une représentation visuelle interactive des
performances en temps réel mettant en évidence des écarts entre une situation prévue et
une situation réelle. Ils présentent une solution idéale pour une quantité de données énorme
grâce à leurs facilités de compréhension, leurs efficacités et leurs rapidités de générer des
plans d’action concrets et mesurables.
— Rapports (Reports)
Les rapports sont généralement statiques, permettent aux utilisateurs d’avoir des infor-
mations plus détaillées.
Le figure 2.8 illustre la différence entre les rapports et les tableaux de bord :
Figure 2.8 – Différence entre rapports & tableaux de bord
2.5 Conclusion
Ce chapitre nous a permis d’aborder les principes généraux de l’informatique décisionnelle.
Dans le chapitre suivant, nous traiterons la phase modélisation et conception qui modélise les be-
soins exprimés dans cette section.

Chapitre 3
CONCEPTION & MODÉLISATION
3.1 Introduction
Après avoir étudier les concepts théoriques de l’informatique décisionnelle, nous abordons la
phase de conception et de modélisation. Nous présentons dans cette rubrique l’architecture du système
ainsi que le modèle de données conçu.
3.2 Architecture de la solution
Notre solution couvre toute la chaı̂ne décisionnelle, depuis l’extraction des données jusqu’au
déploiement des états.
3.2.1 Architecture fonctionnelle du système
L’architecture fonctionnelle de notre système peut être représentée comme suite :
— Extraire, transformer et charger les données depuis les systèmes opérationnels de la société
vers une base de données provisoire (appelée ODS).
— Extraire, transformer et charger les données collectées dans un entrepôt de données afin de
capter les informations servant à la prise de décision.
— Assurer la restitution des différentes données et déterminer la manière avec laquelle les ta-
bleaux de bord seront présentés à l’utilisateur final en fonction de ses besoins.
Figure 3.1 – Architecture fonctionnelle du système
26

CHAPITRE 3. CONCEPTION & MODÉLISATION 27
3.2.2 Architecture logique des données
Trois zones logiques de données sont définies et leur organisation est décrite dans le schéma 3.2 :
Figure 3.2 – Architecture logique des données
— Sources de données : les sources de données représentent tous les systèmes externes et qui
lui fournissent des données brutes.
— ODS : base de données provisoire pour toutes les données qui sont sur le point d’intégrer
l’entrepôt de données.
— Data warehouse : c’est la zone de stockage principale. Les données consolidées y sont
stockées.
3.3 Identification des indicateurs
Les indicateurs clés de performance, ou KPI sont des mesures utilisées pour évaluer les facteurs
de la réussite d’une entreprise ou d’un projet. Dans le cadre de l’informatique décisionnelle, les KPI
sont composés de données, de mesures et d’information afin d’évaluer les tendances métiers et de
conseiller des orientations tactiques.
Ces mesures intègrent des tableaux de bord, des outils pour faciliter le suivi et l’aide à la décision.
Ainsi, chaque personne accède aux données essentielles de gestion pour piloter son activité.
La figure 3.3 illustre les principes des indicateurs de performance :
Figure 3.3 – Principes des KPIs

Dans notre contexte, les KPI permettent à la DRH de savoir si elle est sur la bonne voie.
Voici quelques principaux KPI à surveiller en continu :
Indicateurs Description
Taux de croissance des effectifs Connaı̂tre l’évolution des effectifs de la collec-
tivité.
Age moyen - Repérer les phénomènes de vieillissement.
- Anticiper les départs en retraite.
Ancienneté moyenne Disposer d’un indicateur de ”fidélisation” des
agents.
Taux de turn-over
Taux de rotation
Taux de départ
Taux d’entrée
Rendre compte des mouvements du personnel.
Taux d’absentéisme Connaı̂tre la part du temps de travail “perdu“.
Indicateurs de maladie Connaı̂tre la part du temps de travail “perdu“ en
raison de maladie.
Taux de départ en formation - Déterminer la part des agents ayant accédé à
la formation.
- Contribuer à l’évaluation de la politique de
formation de la collectivité.
Table 3.1 – KPI
3.4 Conception
Dans cette partie, nous présenterons la description des données sources et les deux modèle phy-
siques de l’ODS et entrepôt de données.
3.4.1 Identification des données sources
La mise en place du processus de pilotage et le calcul des indicateurs, s’appuieront d’abord sur
les données existantes dans l’entreprise. Les sources de données sociales concernant le personnel de
l’entreprise sont issues des systèmes d’information de gestion des ressources humaines qu’utilise la
DRH pour gérer et suivi ses ressources humaines de l’entreprise.
Dans ce qui suit une brève description sur les différents fichiers utilisés de la base de données sources.
3.4.2 Conception de l’ODS
Dans cette section, nous exposons notre modèle ODS. Nous allons commencer par la définition
du concept de l’ODS, puis nous allons présenter les différentes tables et enfin nous donnerons une
vue globale de sa modélisation.

Figure 3.4 – Fichiers sourcess
Nom fichier Description
Départements Fichiers contenant les informations liées aux
départements de la société.
Départs Fichiers de suivi des départs.
Employés Fichiers listant les employés et leurs coor-
données.
Imputations Fichiers contenant des extraits des feuilles de
temps des employés.
Projets Fichier contenant les projets sur lesquels travail
les employés de société.
Table 3.2 – Description des fichiers sources
3.4.2.1 Operational data staging ”ODS”
Une ODS (operational data staging) est conçue pour stocker, centraliser les données issues de
différentes sources de données qui arrivent à des moments différents, les homogénéiser et vérifier la
qualité à fin d’avoir un ”full database”.
C’est un infocentre, zone d’attente et lieu où les transformations, le croisement vont être effectuées
afin d’alimenter le data warehouse.
L’ODS est purgée à chaque lancement de l’ETL.
3.4.2.2 Identification des tables
Notre projet comporte plusieurs fichiers chacun représente une table dans la base ”ODS”.
Ci-dessous le tableau descriptif des tables de notre modèle ODS :
Tables Champs Description
ODS BU Code BU
Description BU
Attributs de la table
département
Log Id
Insert Date
Update Date
Clés techniques pour la gestion
de journalisation

ODS Départ Employé
Date Départ
Motif Départ
Commentaire
Attributs de la table départ
Log Id
Insert Date
Update Date
de journalisation
ODS Employé Identifiant Clé fonctionnelle
Agence
Département
Poste
Date Naissance
Sexe
Situation Familiale
Niveau Etude
Diplôme
Date Embauche
Date Début Poste
Haut Potentiel
Flag Actif
Attributs de la table employé
Log Id
Insert Date
Update Date
de journalisation
ODS Projet Projet
Tâche
Type Tâche
Employé
Rapporteur
Etat
Date Creation
Date MAJ
Date Debut
Date Fin
Charge
Attributs de la table projet
Log Id
Insert Date
Update Date
de journalisation
ODS Imputation Date
Date Validation
Projet
Tâche
Employé
Heure
Facture
Attributs de la table imputation

Log Id
Insert Date
Update Date
de journalisation
Table 3.3 – Détails des tables de l’ODS
3.4.2.3 Vue d’ensemble de la conception
Notre base ”ODS ” est composée de 5 tables de base, figurées ci-dessous :
Figure 3.5 – Modèle de l’ODS
3.4.3 Conception de l’entrepôt de données
Dans cette partie, nous présenterons en détails notre modèle d’entrepôt de données en expliquant
les différentes tables de dimensions et pour finir nous déposons une vue global de la modélisation.
3.4.3.1 Identification des tables de dimensions
Notre projet enferme plusieurs dimensions dont chacune représente un axe d’analyse qui a sa
propre clé et qui une fois croisées avec les mesures donnent aux décideurs des renseignements
nécessaires à la prise de décision.
Ci-dessous le tableau descriptif qui présente les dimensions de notre modèle de données :

Dimension Attributs Description de la dimension
Dim Agence Id Agence
Nom Agence
Adresse Agence
Log Id
Insert Date
Update Date
Cette dimension correspond aux
agences de la société.
Dim Département Id Département
Code Département
Description
Log Id
Insert Date
Update Date
départements de la société.
Dim Poste Id Poste
Nom Poste
Log Id
Insert Date
Update Date
postes de travail de la société.
Dim Employé Id Employé
Fk Agence
Fk Poste
Identifiant
Date Naissance
Sexe
Situation Familiale
Niveau Etude
Diplome
Date Embauche
Date Debut Poste
Date Fin Poste
Type Sortie
Flag Haut Potentiel
Flag Actif
Date MAJ Employe
Log Id
Insert Date
Update Date
employés de la société.
Dim Projet Id Projet
Nom Projet
Date Creation
Date debut
Date Fin
Log Id
Insert Date
Update Date
projets de la société.

Dim Tâche Id Tache
Fk Projet
Nom Tache
Type Tache
Date Creation
Date Debut
Date Fin
Duree
Log Id
Insert Date
Update Date
tâches liées à chaque projet.
Dim Temps Id Jours
Nombre Jours
Nom Jours
Id Mois
Nombre Mois
Nom Mois
Trimestre
Cette dimension correspond à
l’axe temporel.
Table 3.4 – Description des dimensions
3.4.3.2 Identification de la table des faits
Nous avons dans notre projet une seule table des faits (Fait Imputation) contenant un ensemble
des mesures correspondant aux informations du domaine des ressources humaines qu’on veut analy-
ser selon plusieurs axes (les dimensions).
La clé primaire de cette table est la combinaison des clés primaires de toutes les tables de dimensions.
Le tableau suivant décrit ses composants :
Champs Description
FK Employe
FK Departement
FK Tache
FK Temps
- Clé étrangère de la dimension employé
- Clé étrangère de la dimension département
- Clé étrangère de la dimension tâche
- Clé étrangère de la dimension temps
Temps passé Mesure
Log Id
Insert Date
Update Date
Clés techniques pour la gestion de journalisa-
tion
Table 3.5 – Table des faits

3.4.3.3 Vue d’ensemble de la conception
Notre modèle d’entrepôt de données complet est un modèle en étoile présenté dans la figure sui-
vante :
Figure 3.6 – Modèle d’entrepôt de données
3.5 Conclusion
Dans ce chapitre, nous avons exposé l’architecture de notre solution. Ainsi, nous avons présenté la
conception des modèles de données relatifs à l’ODS et au data warehouse selon notre besoin et nous
avons décrit en détail les tables qui les composent.
Les différentes phases de réalisation seront détaillées dans le chapitre qui suit.

Chapitre 4
MISE EN OEUVRE
4.1 Introduction
Ce chapitre est destiné à la présentation du travail réalisé. D’abord, nous allons commencer par
présenter l’environnement de développement du projet.
Ensuite, nous allons disposer quelques aperçus sur les étapes réalisées pour le chargement et la
construction de l’entrepôt de données et son exploitation sous forme de tableau de bord.
4.2 Environnement de développement
4.2.1 Comparatif des outils ETL
L’objectif de cette comparaison est de distinguer les points forts et les points faibles des outils
SSIS et Talend, les deux outils les plus utilisés.
Le tableau 4.1 montre les principales bases de comparaison de chaque outil :
Base de comparaison SSIS Talend
Développeur Microsoft Talend
Objectif Extraction, transformation et
chargement des données à partir
de plusieurs et différents source
de données
ETL permet d’extraire des
données à partir de plusieurs
sources, de les transformer
puis les recharger en une seule
destination centralisée.
Avantages SSIS permet d’exécuter un
grand nombre de processus en
parallèle.
Il fournit de nombreux outils
pour transformer les données au
cours du processus de migration
Interfaces rapides et simple à
utiliser.
La conception des jobs est très
simple.
35

CHAPITRE 4. MISE EN OEUVRE 36
Inconvénients Il est impossible de dupliquer un
flux existant, donc si on a plu-
sieurs similaires, on doit toutes
les saisir de zéro
La synchronisation avec Git de-
vrait être facilitée.
Retour sur investissement Une fois développés, les pa-
ckages sont très stables et
nécessitent peu de maintenance,
ce qui permet d’économiser le
temps de travail.
Talend Data Integration a ratio-
nalisé la gestion de son entrepôt
de données, ce qui permet de
réduire les coûts et les délais.
Marge d’amélioration SSIS peut améliorer la gestion
des différents types de données.
La connectivité avec différentes
sources de données telles que
la connectivité de la force de
vente, la connectivité d’Oracle
Cloud ,etc.
La version open-source doit in-
clure des fonctionnalités telles
que la gestion des versions de
code source et l’exécution en
parallèle.
Problème d’évolutivité Aucun. Cela nécessite un peu de réglage
avant d’atteindre les perfor-
mances optimales.
Table 4.1 – Comparatif des outils ETL
[6]
Il est clairement visible que SSIS fonctionne mieux que Talend sur certaines transformations
simples. Mais cela ne signifie pas que SSIS surclassera Talend dans tous les domaines. Nous pou-
vons affirmer que ces deux outils ont leurs propres avantages et inconvénients et qu’en fonction de
nos besoins, nous avons choisi de travailler avec SSIS.
4.2.2 Comparatif des outils de visualisation
Le tableau 4.2 sert à représenter une étude comparative sur les caractéristiques des trois concur-
rents Power BI, Tableau et Qlick.
Base de comparaison Power BI Tableau Qlick
Développeur Microsoft Tableau Qlick
Performance - Il peut gérer un
volume limité de
données.
- Facile à utiliser.
- Il permet aux utili-
sateurs de générer des
analyses avancées ainsi
que des visualisations.
- Il peut gérer un
énorme volume de
données avec de
meilleures perfor-
mances.
- Offre un mécanisme
facile à utiliser.
- Qlick a besoin d’un
développeur pour tra-
vailler avec des rap-
ports et des tableaux de
bord.
- Ils ont de bonnes vi-
sualisations.

Interface utilisateur - Les tableaux de bord
sont la fonctionnalité
clé de PowerBI lors-
qu’il dispose d’une
bonne interface utili-
sateur pour publier le
rapport.
- L’interface utilisateur
est meilleure.
- L’interface utilisateur
est assez faible par rap-
port à Tableau.
Facilité d’apprentis-
sage
- Convivialité.
- La connaissance
d’Excel est suffisante.
- L’interface Power
BI est très facile à
apprendre.
- La connaissance de
Microsoft Excel et
DAX est requise pour
une utilisation efficace.
- Ils ne nécessitent au-
cune compétence tech-
nique ou de program-
mation pour travailler
avec.
- Il offre une interface
glisser-déposer simple
à utiliser.
- Facile à ap-
prendre,nécessite
une formation en
science des données.
- Difficile à utiliser
sans connaissance des
scripts et des modèles
de données
Pertinence - C’est le meilleur outil
pour le développement
de tableaux de bord.
- Il convient le mieux
aux utilisateurs pro-
fessionnels, aux cher-
cheurs et aux universi-
taires.
- QlickView est ex-
cellent pour les équipes
d’analyse internes.
Rentabilité - Moins cher. - Très cher car il
charge un entrepôt de
données.
- Plusieurs options
dans Tableau rendent
la tarification com-
plexe.
- Cher.
Vitesse - Ils ont une
récupération intel-
ligente.
- La vitesse dépend de
la RAM et des jeux de
données.
- Ils ont une meilleure
vitesse car ils stockent
les données dans la
RAM du serveur (sto-
ckage en mémoire).
Avantage - Les solutions Power
BI sont économiques
et évolutives pour les
grands projets.
- Il permet la mani-
pulation des données
avant d’importer des
données.
- Ils sont les mieux
classés dans les
visualisations d’intelli-
gence.
- Ils fournissent une
large gamme d’ana-
lyses approfondies
et ils possèdent une
communauté bien
développée.
Table 4.2 – Comparatif des outils de visualisation
[7]

Tableau, Power BI et QlickView sont des outils de Business Intelligence tout-puissants. Chacun
d’eux excelle dans certains paramètres. Les capacités de glisser-déposer ainsi que les connexions de
données sécurisées font de tableau un précurseur sur le marché. Les points forts de Qlick incluent les
capacités du moteur en mémoire de visualisation des modèles. La création des tableaux de bord via
Power BI peut être partagée entre les équipes et accessible sur n’importe quel appareil. Globalement,
Power BI apparaı̂t comme l’outil concurrent parmi les trois outils.
4.2.3 SQL Server 2012
Figure 4.1 – Logo du SQL Server
SQL Server est un outil qui possède toutes les caractéristiques pour pouvoir accompagner l’utili-
sateur dans la manipulation, le contrôle, le tri, la mise à jour et bien d’autres actions encore de bases
de données grâce au langage SQL.
Les avantages de SQL Server sont les suivants :
— Gestion avancée de la sécurité en offrant deux modes d’authentification (Authentification Win-
dows et Authentification SQLServer).
— SQL Server intègre par défaut des outils de gestion, d’administration et de développement de
bases de données.
— Déploiement par un setup, mise en œuvre et administration par des interfaces graphiques in-
tuitives.
4.2.4 SQL Server Management Studio
Figure 4.2 – Logo du SQL Server Management Studio
SSMS est un moteur de base de données relationnelles, créé par Microsoft, qui permet de créer,
d’administrer des bases de données de n’importe quelle taille, de stocker et de manipuler des données
structurées sur un serveur et d’y accéder avec n’importe quel langage de programmation.
Il offre à la fois une interface conviviale et un panel d’outil pour mettre en œuvre et administrer
les bases de données et les serveurs.

4.2.5 Visual Studio 2015
Figure 4.3 – Logo du Visual Studio
C’est un environnement de développement intégré qui facilite les tâches de création, débogage et
déploiement d’applications faisant appel à plusieurs langages.
4.2.6 SQL Server Integration Services
Figure 4.4 – Logo du SSIS
Comme son nom l’indique, SSIS est un outil d’intégration des différentes données nécessaires à
l’outil décisionnel. Son principal objectif est de faire l’ETL (Extract-Transform-Load) tout en ayant
une gestion des différentes erreurs.
L’ETL est le service clé, au sein de cette solution Microsoft, qui permet la centralisation des données.
Il sert en premier lieu à extraire des données de n’importe quelle source (base de données, fichiers
plats, etc.), les transformer en second lieu en données exploitables et en dernier lieu les charger vers
une ou plusieurs destinations.
4.2.7 Microsoft Power BI
Figure 4.5 – Logo du Power BI
Power BI est un outil qui est créé et commercialisé par Microsoft et qui est définit comme étant
un outil décisionnel de visualisation interactive des données.

Il se traduit en un ensemble de 3 outils majeurs :
Figure 4.6 – Les outils majeurs de Power BI
Les grandes fonctionnalités de Power BI :
La figure ci-dessous représente les fonctionnalités de Power BI :
Figure 4.7 – Les fonctionnalités de Power BI
Les points forts stratégiques de Power BI :
— Être efficient
• Disposer des bonnes informations en temps réel pour agir rapidement.
• Gagner du temps, donc de l’argent et se concentrer sur les tâches à valeurs ajoutées.
— Être professionnel
• Renvoyer une bonne image.
• Faciliter la transmission d’information entre les équipes.

Les points forts pratiques de Power BI :
— Utilisation des fonctions innovantes (Calculate, xfunctions,etc).
— Rapidité de calcul.
— Sources d’importations nombreuses (+67 possibilités).
— Visualisation dynamique.
— Partage entre utilisateurs très facile.
— Licence standard gratuite et complète, licence pro à faible coût.
4.3 Implémentation
Après avoir terminer la conception de notre module et définir notre environnement de développement,
nous passons à l’implémentation de notre module BI passant par la préparation des données sources
tout en détaillant les différentes phases.
4.3.1 Phase d’alimentation(ETL)
L’objectif d’ETL est de produire des données propres, faciles d’accès et qui peuvent être exploitées
efficacement par l’analytique et la Business Intelligence afin de récupérer les données identifiées et
sélectionnées.
La première partie du processus ETL consiste à extraire les données depuis les systèmes opérationnels
de la société.
L’objectif de cette étape consiste à convertir les données dans un format unique qui est approprié
pour un traitement de transformation. Ce format de stockage est très similaire à la source.
Nous avons appliqué un système de journalisation pour savoir quelles données sont arrivées et quand,
ce qui permet de reprendre des chargements et gérer les erreurs de transfert de données depuis les
systèmes sources, les tables de journalisation sont représentées dans la figure 4.8 :
Figure 4.8 – Tables de journalisation
Ensuite les charger dans un ODS tout en utilisant SSIS :
4.3.1.1 Chargement de l’ODS
Cette couche ODS fait office de structure intermédiaire destinée à stocker les données issues
des systèmes de production opérationnelle. Ce sont en quelque sorte des zones de préparation avant

l’intégration des données dans le DW.
Les figures suivantes représentent quelques exemples du chargement des tables dans l’ODS à tra-
vers SSIS :
A. Table Employé :
Figure 4.9 – Chargement de la table employé
Le chargement de la table employé se réalise en trois étapes :
— Extraction de données : à partir des fichiers employés (.csv).
Figure 4.10 – Fichiers source pour la table employé
— Transformation de données : conversion des types de données, récupération des événements
activés par le journal qui se produisent au moment de l’exécution et ajout de date d’inser-
tion des données.
— Chargement de données : les données sont chargées dans la base de l’ODS (table em-
ployé) et du même pas les données de journalisation sont chargées dans les tables de Log.

B. Table Projet :
Figure 4.11 – Chargement de la table projet
Le chargement de la table projet se réalise en trois étapes :
— Extraction de données : à partir des fichiers projets (.csv).
Figure 4.12 – Fichiers source pour la table projet
tion des données.
— Chargement de données : les données sont chargées dans la base de l’ODS (table projet)
et du même pas les données de journalisation sont chargées dans les tables de Log.

C. Table Département :
Figure 4.13 – Chargement de la table département
Le chargement de la table département se réalise en trois étapes :
— Extraction de données : à partir des fichiers BU (.csv)
Figure 4.14 – Fichiers source pour la table département
tion des données.
— Chargement de données : les données sont chargées dans la base de l’ODS (table BU) et
du même pas les données de journalisation sont chargées dans les tables de Log.

D. Table Imputation :
Figure 4.15 – Chargement de la table imputation
Le chargement de la table imputation se réalise en trois étapes :
— Extraction de données : à partir des fichiers imputations (.csv)
Figure 4.16 – Fichiers source pour la table imputation
tion des données.
— Chargement de données : les données sont chargées dans la base de l’ODS (table im-
putation) et du même pas les données de journalisation sont chargées dans les tables de
Log.
4.3.1.2 Chargement de l’entrepôt de données
Notre ODS est destiné à contenir des données de niveau fin en opposition aux données agrégées
qui seront stockées dans notre entrepôt de données.
Le passage de l’ODS a l’entrepôt de données s’est fait par le processus d’intégration des données
ETL. Dans ce cas-là, nous avons extraire les données de la source qui est la base ODS, les transfor-
mer selon nos besoins et les charger dans l’entrepôt de données.

Dans ce qui suit nous allons représenter quelques exemples de chargement des dimensions et de
faits par le processus d’intégration des données ETL.
Chargement des tables de dimensions :
A. Dimension Agence :
Figure 4.17 – Chargement de la dimension agence
Le chargement de la dimension agence s’effectue en trois étapes :
— Extraction de données : à partir la table employé de la base ODS.
— Transformation de données : récupération des événements activés par le journal qui se
produisent au moment de l’exécution et ajout de date d’insertion ou date de mise à jour
des données.
— Chargement de données : les données sont chargées dans la base du DW (Dim Agence)
en utilisant le composant Slowly changing dimension à fin de garantir la mise à jour
des données qui ont changés au fil du temps, à ce suit, les données de journalisation sont
chargées dans les tables de Log.

B. Dimension Employé :
Figure 4.18 – Chargement de la dimension employé
Le chargement de la dimension employé s’effectue en trois étapes :
— Extraction de données : à partir des tables employé de la base ODS et des tables
Dim Agence, Dim Poste de l’entrepôt de données.
produisent au moment de l’exécution, changement de valeur d’un attribut et ajout de date
d’insertion ou date de mise à jour des données.
— Chargement de données : les données sont chargées dans la base du DW (Dim Employé)
en utilisant le composant Slowly changing dimension à fin de garantir d’une part l’his-
torisation des données et d’autre part la mise à jour des données qui ont changés au fil du
temps, à ce suit, les données de journalisation sont chargées dans les tables de Log.

C. Dimension Projet :
Figure 4.19 – Chargement de la dimension projet
Le chargement de la dimension projet s’effectue en trois étapes :
— Extraction de données : à partir la table projet de la base ODS.
des données.
— Chargement de données : les données sont chargées dans la base du DW (Dim Projet)

D. Dimension Tâche :
Figure 4.20 – Chargement de la dimension tâche
Le chargement de la dimension tâche s’effectue en trois étapes :
— Extraction de données : à partir la table projet de la base ODS.
des données.
— Chargement de données : les données sont chargées dans la base du DW (Dim Tâche)

Chargement de la table des faits :
Figure 4.21 – Chargement de la table des faits
Le chargement de la table de faits se fera en deux grandes étapes :
Nous devons tout d’abord préparer notre source de données par laquelle nous allons alimenter notre
table.
Cette source de données est une table de la base ODS (imputation) qui représente une jointure entre
toutes les dimensions, ainsi que les mesures.
Apres avoir préparé notre source, nous appliquons la technique ETL pour compléter le chargement
de la table.
— Extraction de données : à partir de la table imputation et jointure avec les autres tables (clés
étrangers) à l’aide du composant ” Lookup ”.
— Transformation de données : conversion de la date, récupération des événements activés par
le journal qui se produisent au moment de l’exécution et ajout de date d’insertion des données.
— Chargement de données : les données sont chargées dans la table de faits (fait Imputation)
avec la correspondance des dimensions.
4.3.2 Phase de restitution de données
Notre expérience a montré que la visualisation de données est un outil puissant qui permet de
prendre un vaste ensemble de données, de les analyser, de les quantifier et de les présenter de manière
attrayante et facile à comprendre. Il n’est donc pas surprenant que la visualisation des données soit
devenue essentielle.

Dans ce contexte, dans la partie suivante nous présentons les tableaux de bord générés avec PowerBI.
A. Création des membres calculés :
Comme son nom l’indique, un membre calculé est une colonne de calculs, que l’on peut
ajouter à une table source dans un modèle de données tabulaire.
Pour illustrer le concept de membres calculés, nous présentons dans les figures ci-dessous
des exemples de mesures et des colonnes calculées à travers le langage DAX.
Colonnes ajoutées
— Âge : Il s’agit de calculer l’âge des employés à partir de leurs dates de naissance.
— Tranches d’âge : Cette colonne consiste à regrouper le personnel par tranches d’âge. Elle
permet d’avoir une meilleure visibilité de la répartition des âges des employés de l’entre-
prise.
Cette dernière est nécessaire pour tracer la pyramide d’âges.
— Ancienneté : Cette colonne est la différence entre la date courante et la date d’embauche
de l’employé.
Figure 4.22 – Colonnes ajoutées
Mesures ajoutées
— Effectif : Cette mesure présente le nombre des salariés qui travaillent au sein de l’entre-
prise. C’est la plus importante des mesures vu que la plupart des analyses seront basées sur
elle : établir la pyramide d’âges et d’anciennetés, taux d’absentéisme, taux de croissance,
taux de turnover, etc.
B. Dashboarding :
Notre expérience a montré que la visualisation de données est un outil puissant qui permet

de prendre un vaste ensemble de données, de les analyser, de les quantifier et de les présenter
de manière attrayante et facile à comprendre. Il n’est donc pas surprenant que la visualisation
des données soit devenue essentielle.
Dans ce contexte, dans la partie suivante nous présentons les tableaux de bord générés avec
PowerBI.
Tableau de bord ”Suivi effectifs”
Ce premier tableau de bord pour le suivi des effectifs aide à connaı̂tre l’évolution et d’avoir
une vision de la répartition des diverses générations de salariés afin d’en déceler des tendances.
Il dispose comme indicateurs :
- Nombre d’effectifs.
- Ratio des hommes.
- Ratio des femmes.
- Taux de croissance.
Et comme visuels, il représente :
- Une pyramide d’âge répartie par tranches d’âge et sexe des salariés où les effectifs sont
portées horizontalement et les groupement d’âge verticalement.
Son objectif est de vérifier l’équilibre entre les divers générations de la société.
- Une graphique en anneau qui divise les ressources selon leurs situations familiale.
- Une carte géographique afin de répartir les effectifs par emplacement. Cette carte permet
également de filtrer le rapport par lieu souhaité.
- Un histogramme qui regroupe les employés selon leurs niveaux d’études.

Figure 4.23 – Tableau de bord suivi des effectifs
Tableau de bord ”Suivi ancienneté”
Ce tableau de bord permet d’avoir conscience de l’ancienneté présente dans l’entreprise ainsi
de réaliser des prévisions à moyen et long terme.
Il regroupe les indicateurs (âge moyen et ancienneté moyenne) dans la collectivité ainsi que la
pyramide d’ancienneté répartie par sexe et ancienneté.
Figure 4.24 – Tableau de bord suivi d’ancienneté
Tableau de bord ”Suivi turnover”

Ce tableau de bord de suivi du turnover est considéré comme révélateur du climat social,
il permet d’avoir une idée de l’ampleur et du rythme des mouvements du personnel dans l’en-
treprise.
Le taux de turnover et le taux de rotation sont les uns des indicateurs à suivre avec beau-
coup d’attention.
Aussi bien d’autres indicateurs comme le taux de sortie.
En effet, la compréhension, la classification des mouvements du personnel selon différents
axes (ancienneté, tranche d’âge, etc) et l’analyse de ses causes prenant en compte les ruptures
conventionnelles, les démissions, les licenciements, les départs en retraites, permettent d’an-
ticiper les changements. Par conséquent, le maintien de la pérennité sociale de l’organisation
est assurée.
Figure 4.25 – Tableau de bord suivi de turnover
Tableau de bord ”Suivi absentéisme”
L’absentéisme est l’un des principales préoccupations des DRH. Ce tableau de bord de suivi
d’absentéisme est primordial pour en évaluer son taux, comprendre les raisons et essayer
d’agir pour le minimiser.
Pour ce faire, il est nécessaire de mesurer, suivre quelques indicateurs comme (le taux d’ab-
sentéisme, l’indicateur de maladie, etc), de les analyser suivant plusieurs axes (période, sexe,
âge, poste, ancienneté, type d’absence, etc) et de calculer le temps imputé pour chaque ab-
sence.

Figure 4.26 – Tableau de bord suivi absentéisme
Tableau de bord ”Suivi formations”
Ce tableau de bord récapitule les différentes informations sur les formations de l’entreprise, il
permet d’avoir d’un seul coup d’œil les indicateurs mis à disposition :
- Nombre de formations.
- Nombre de participants.
- Taux d’accès aux formations.
- Durée moyenne de formation.
Avec des présentations graphiques sous forme d’histogrammes et des tableaux qui servent à
identifier les employés et les jours imputés dans les formations selon plusieurs axes (département,
poste, type formation, etc).

Concéption et réalisation d'un processus décisionnel, tableau de bord social.

Concéption et réalisation d'un processus décisionnel, tableau de bord social.

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Concéption et réalisation d'un processus décisionnel, tableau de bord social.

Ähnlich wie Concéption et réalisation d'un processus décisionnel, tableau de bord social. (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (7)

Concéption et réalisation d'un processus décisionnel, tableau de bord social.