Vous êtes sur la page 1sur 151

Mémoire de fin d’étude

Pour l’obtention du diplôme d’Ingénieur d’Etat en


Informatique

Option : Systèmes d’Information et Technologie

Thème
Conception d’une solution Business Intelligence pour la fonction
RH de SONELGAZ dans un écosystème Big Data

Encadré par Réalisé par


Mme ABDELLAOUI Sabrina, ESI SEDJAL Abdelghani
Mr. SENNAD Belaid, ELIT BOUTOUILI Djillali

Année universitaire 2020 – 2021

i
Remerciements

En tout premier lieu, nous remercions le bon dieu tout-puissant de nous


avoir donné le courage, force et santé pour finir ce modeste travail.

Nous exprimons nos remerciements les plus sincères à notre encadrante


Mme. Sabrina ABDELLAOUI pour ses conseils avisés, sa patience
ainsi que son suivi de qualité tout au long de notre stage. Ses qualités
techniques et de gestionnaire, sa disponibilité et la confiance dont elle a
fait preuve à notre égard nous ont donné la capacité de mener ce
travail à terme.

Nos remerciements les plus sincères aussi à Mr. Sennad Belaid chef
de Département Intégration et Maintenance SI au sein de la Direction
Progiciel de Gestion Intégrée d’ELIT ainsi qu’à Mr. Amara Ayoub
Abdeldjallil ingénieur Business Intelligence à ELIT pour leurs
chaleureux accueil au sein de l’équipe d’ELIT, Leurs implication, leurs
disponibilités, leurs suivis et leurs nombreux conseils tout au long de
notre stage.
Nous adressons nos remerciements les plus sincères à Mr Balla Amar
pour la gestion administrative du stage de fin d’étude ainsi que les
énormes efforts fournis pour son bon déroulement.

Avant de terminer, nous remercions nos respectueux enseignants qui


nous ont enseignée durant nos études et toute personne ayant contribué
de loin ou de près à la réalisation de ce présent travail.

Et finalement, nous adressons nos plus sincères remerciements aux


membres du Jury pour avoir accepté d’évaluer ce modeste travail.

ii
Dédicaces
Avec l’expression de ma gratitude, je dédie ce modeste travail à
tous ceux qui, quels que soient les termes embrassés, je n’arriverais
jamais à leur exprimer mon amour sincère.

A l’homme à qui je dois ma vie, ma réussite et tout mon respect,


j’espère que vous serez toujours fiers de moi : mon cher père.

A la prunelle de mes yeux qui m’a soutenu, encouragé et toujours


épaulé pour atteindre mes objectifs, je vous serais éternellement
reconnaissant : Ma maman bien-aimée.

À mon frère Reda et ma sœur Rania, aucune dédicace ne saurait


exprimer tout l’amour que j’ai pour vous, Que Dieu les protège et
leurs offre la chance et le bonheur.

À mon ami de toujours Lotfi, mon frère à qui ma mère n'a pas
donné naissance, qui m’a toujours aidé et soutenu dans les
moments les plus difficiles.

A tous les cousins, voisins et amis

Sans oublier mon binôme Abdelghani, merci pour ton soutien


moral, patience et compréhension dans les moments les plus
difficiles. Je te souhaite tout le bonheur et réussite du monde.

DJILLALI
iii
Dédicaces

Je remercie dieu le tout puissant, le plus miséricordieux, de m'avoir


donné la patience et la force pour accomplir ce modeste travail.

Je dédie ce modeste travail en reconnaissance de l'amour que vous


m'offrez quotidiennement et votre bonté exceptionnelle

À ma chère mère à qui je dois un immense respect, celle qui m'a élevé,
qui a battu pour moi, qui a fait aux différentes difficultés de la vie juste
pour qu'elle me voit réussir, avec son amour qui donne sens à la vie,
aucun mot ne peut exprimer la profondeur des sentiments que j'éprouve
pour elle,

À ma chère famille
Mon frère, mes tantes, ma grand-mère qui m'ont toujours encouragé
tout au long de mon parcours ainsi mes chères amis et frères et sœurs
que j'ai connues et qui ont toujours été présents à mes côtés, ainsi
qu’une fille qui est spéciale pour moi et que je remercie dieu qui a croisé
nos chemins,

À mon père qui compte énormément pour moi, et pour qui je porte
beaucoup de fierté et de respect.

Je tiens à remercier fortement mon binôme BOUTOUILI Djillali, mon


frère, ma force qui m'a toujours motivé, aidé et a mis sa touche
magique toute au long du projet

ABDELGHANI

iv
Résumé
Sonelgaz, ou Société nationale de l’électricité et du gaz, est le groupe leader de la
production, distribution et du transport de l’électricité et du gaz en Algérie. Le groupe vise à
être parmi les leaders mondiaux dans son domaine, c’est pourquoi il est conscient que la
concurrence est rude et par conséquent l’amélioration continue de son corps sur tous les aspects
s’impose notamment sur un axe très important qu’est la gestion des ressources humaines.

Actuellement, les décideurs de Sonelgaz ne disposent d'aucun système d'aide à la décision sur
la fonction ressources humaines. D’une part, l’élaboration des rapports d’analyse est quasi
manuelle, d'autre part et en raison de l’immense croissance du patrimoine informationnelle de
la fonction ressources humaines, le volume de données de la fonction ressources humaines a
dépassé la barre des deux Térabytes, un chiffre immense pour un traitement manuel ou utilisant
des méthodes classiques, aussi, ces données sont de nature décentralisées et hétérogènes
(structurées, semi-structurées et non structurées). Par conséquent, le processus d’aide à la
décision connaît une lenteur très considérable pouvant aller jusqu’à plusieurs jours, de plus, ce
processus connait un grand nombre d'intervenants, pouvant aller jusqu’à quatre parties
prenantes différentes, causant ainsi un risque d'incohérence et d'insécurité des informations
décisionnelles.

Pour pallier ces problèmes, Sonelgaz veut exploiter ses données sur la RH qui sont à ce jour
mal exploitées pour permettre la prise de la décision la plus appropriées dans les meilleurs
délais en se basant sur des informations fiables.

A ce titre, SONELGAZ a confié à ELIT la mission de mettre en place un système efficace


d’aide à la décision permettant d’améliorer l’intégrité et la transparence des informations
utilisées pour éclairer d’une manière efficace et dans les plus brefs délais le processus
décisionnel du système RH. C’est dans ce contexte, et dans le but de centraliser les données
volumineuses de la fonction RH, automatiser le processus de reporting et résoudre le problème
de lenteur dû aux quantités immenses de données, que nous a été confiée la mission de réaliser
ce système.

Pour atteindre les objectifs fixés, nous avons mis en place un système d’aide à la décision conçu
dans un écosystème Big Data, le volume extrêmement grand de données exige l’adoption d’une
telle approche pour résoudre le problème de lenteur ressenti auparavant.

Nous avons centralisé les données dans un lac de données distribuée dans le data center propre
à ELIT en utilisant un processus ELT, un processus ETL, en parallèle, a été mis en place pour
préparer et stocker des données prêtes pour des fins décisionnelles dans une infrastructure
entrepôt de données à l’intérieur du lac de données, nous avons transformé par la suite ces
données distribuées en cube MOLAP en utilisant la technologie MapReduce. A la fin, nous
avons utilisé ces cubes pour générer des rapports et tableaux de bords dans un portail web
accessible à partir de réseau local « LAN » de Sonelgaz.

MOTS CLÉS : Système d’information décisionnel, Tableau de bord, Ressources


humaines, SIRH, Data Lake, Big data

v
Abstract
SONELGAZ, or National Electricity and Gas Company, is the leading group in the
production, distribution and transport of electricity and gas in Algeria. The group aims to be
among the world leaders in its field, which is why it is aware that the competition is tough and
therefore the continuous improvement of its body in all aspects is essential in particular on a
very important axis that is the management of human resources.

Currently, SONELGAZ decision makers do not have a decision support system on the human
resources function. On the one hand, the preparation of analysis reports is almost manual, on
the other hand and due to the immense growth of the information assets of the human resources
function, the volume of data of the human resources function has exceeded the bar of two
Terabytes, a huge number that manual processing or the conventional methods cannot handle,
also, these data are decentralized and heterogeneous in nature (structured, semi-structured and
unstructured). As a result, the decision support process is very slow, which can take up to
several days, in addition, the reporting process has a large number of stakeholders, up to four
different stakeholders, thus causing a risk of inconsistency and insecurity of decision-making
information.

To meet this need, SONELGAZ wants to use its human resources data, which is currently badly
exploited to provide the necessary and reliable information, thus helping them to take the most
appropriate decisions as quickly as possible.

As such, SONELGAZ entrusted ELIT with the mission of setting up an effective decision
support system to improve the integrity and transparency of the information used to provide
information effectively and as quickly as possible. It is in this context, and with the aim of
centralizing the voluminous data of the HR function, automating the reporting process and
solving the problem of slowness due to the immense amounts of data, that we were entrusted
with the mission of realizing this system.

To achieve the set of objectives, we have implemented a decision support system designed in
a Big Data ecosystem, the extremely large volume of data requires the adoption of such an
approach to solve the problem of slowness felt previously.

We centralized the data in a distributed data lake in ELIT's own data center using an ELT
process, an ETL process, in parallel, was set up to prepare and store data ready for decision
making in an infrastructure data warehouse inside the data lake, we subsequently transformed
this distributed data into a MOLAP cube using MapReduce technology. At the end, we used
these cubes to generate reports and dashboards in a web portal accessible from SONELGAZ's
local network “LAN”.

KEYWORDS: Business Intelligence, Decision, Dashboard, Humans resources,


Datalake, Data lakehouse, Big Data

vi
‫ملخص‬
‫سونلغاز‪ ،‬أو الشركة الوطنية للكهرباء والغاز ‪ ،‬هي المجموعة الرائدة في إنتاج وتوزيع ونقل الكهرباء والغاز في الجزائر‪.‬‬
‫تهدف المجموعة إلى أن تكون من بين رواد العالم في مجالها ‪ ،‬بما أنها تدرك أن المنافسة شديدة وبالتالي فإن التحسين‬
‫المستمر لهيكلتها في جميع المحاور أمر ضروري‪ ،‬بشكل خاص على محور حيوي مهم للغاية وهو إدارة الموارد البشرية‬
‫في الوقت الحالي ‪ ،‬ال يمتلك اإلطارات في سونلغاز نظام مساعد إلتخاذ القرار بشأن وظيفة الموارد البشرية ‪.‬من ناحية‬
‫يعد إعداد التقارير التحليلية يدويًا تقريبًا ‪ ،‬ومن ناحية أخرى ‪ ،‬وبسبب النمو الهائل لموارد البيانات لوظيفة الموارد البشرية‬
‫فقد تجاوز حجم بيانات وظيفة الموارد البشرية شريط اثنين تيرابايت ‪ ،‬وهوعدد ضخم للمعالجة اليدوية أو باستخدام ‪،‬‬
‫(األساليب الكالسيكية ‪ ،‬لذلك فإن هذه البيانات غير مركزية وغير متجانسة بطبيعتها )منظمة وشبه منظمة وغير منظمة‬
‫نتيجة لذلك ‪ ،‬تكون عملية إتخاذ القرار بطيئة للغاية ‪ ،‬وقد تستغرق عدة أيام‬
‫كبيرا من المتدخلين ‪ ،‬يصل إلى أربعة متدخلين مختلفين ‪ ،‬مما‪.‬‬
‫باإلضافة إلى ذلك ‪ ،‬تضم عملية إعداد التقارير عددًا ً‬
‫يتسبب في خطر عدم االتساق وعدم األمان في معلومات صنع القرار‬
‫للتغلب على هذه المشكالت ‪ ،‬تريد سونلغاز استخدام بيانات الموارد البشرية الخاصة بها والتي يتم استغاللها بشكل غير‬
‫كافي حتى اآلن للسماح باتخاذ القرار األنسب في أسرع وقت ممكن بنا ًء على معلومات موثوقة‬
‫على هذا النحو ‪ ،‬كلفت سونلغاز إيليت بمهمة إنشاء نظام فعال لدعم إتخاذ القرار لتحسين نزاهة وشفافية المعلومات‬
‫المستخدمة و توفير المعلومات بشكل فعال وبأسرع ما يمكن عملية صنع القرار في نظام الموارد البشرية‬
‫في هذا السياق ‪ ،‬وبهدف تركيز البيانات الضخمة لوظيفة الموارد البشرية ‪ ،‬وأتمتة عملية إعداد التقارير وحل مشكلة الوقت‬
‫بسبب الكميات الهائلة من البيانات ‪ ،‬تم تكليفنا بمهمة تحقيق هذا النظام‬
‫لتحقيق األهداف المحددة ‪ ،‬قمنا بتنفيذ نظام مساعد إلتخاذ القرار ‪،‬مصمم في نظام بيئي للبيانات الضخمة ‪ ،‬يتطلب الحجم‬
‫الكبير للغاية من البيانات اعتماد مثل هذا النهج لحل مشكلة البطء التي شعرت بها سابقًا‬
‫‪ ،‬قمنا بتركيز البيانات في بحيرة البيانات الموزعة في مركز البيانات الخاص بـ إيليت باستخدام عملية "إستخراج ‪ ،‬شحن‬
‫تحويل "‪ ،‬تم إعداد عملية "إستخراج ‪ ،‬تحويل ‪ ،‬شحن بالتوازي إلعداد وتخزين البيانات الجاهزة التخاذ القرار في مستودع‬
‫بيانات البنية التحتية داخل بحيرة البيانات ‪ ،‬ثم قمنا بعد ذلك بصناعة مكعب موالب إستنادا على هذه البيانات الموزعة‬
‫باستخدام تقنية معالج بيانات موزع ماب رديوس‬
‫في النهاية ‪ ،‬استخدمنا هذه المكعبات إلنشاء التقارير ولوحات البيانات في بوابة ويب يمكن الوصول إليها من شبكة‬
‫الن "المحلية الخاصة بشركة سونلغاز"‬

‫الكلمات الرئيسية‪ :‬نظام معلومات القرار ‪ ،‬القرار ‪ ،‬مستودع البيانات ‪ ،‬لوحة القيادة الموارد البشرية ‪ ،‬نظام‬
‫معلومات الموارد البشرية ‪ ،‬بحيرة البيانات ‪ ،‬البيانات الضخمة‬

‫‪vii‬‬
TABLE DES MATIERES

Table des matières


Résumé v
Abstract vi
‫ملخص‬ vii
Liste des figures xiv
Liste des tableaux xvi
Liste des sigles et abréviations xvi
Introduction générale 1
Contexte 1
Problématique 1
Objectifs 2
Organisation du document 3

I. Synthèses Bibliographiques............................................................... 4
1 La Fonction Ressources Humaines 5
1.1 Définition De La Fonction RH 5
1.2 Evolution De La GRH 5
1.2.1 Époque de la révolution industrielle (19e siècle) 5
1.2.2 Époque du mouvement syndical (proche du XIXe siècle) 6
1.2.3 L'ère de la responsabilité sociale (début du 20e siècle) 6
1.2.4 Ère de la gestion scientifique (1900-1920) 6
1.2.5 L'ère des relations humaines (1930-1950) 7
1.2.6 Ère des sciences du comportement (1950-1960) 7
1.3 Processus Métiers De La Ressources Humaines 7
1.3.1 La gestion des compétences 7
1.3.2 La gestion de la masse salariale 8
1.3.3 Suivi des formations 8
1.3.4 Suivi des recrutements 8
1.3.5 Suivi des conditions de travail 8
1.4 Rôle Stratégique De La GRH En Entreprise 8
1.5 Solutions Informatiques Appliquées A La GRH 11
1.5.1 Les solutions payantes 11
1.5.2 Solutions open sources 12
1.6 Conclusion 12
2 Les Systèmes Décisionnels 13
2.1 Concepts De Base 13
2.2 Objectifs D’un Systeme D’information Décisionnel Dans Une Entreprise 14
2.3 Architecture D’un SID 15
2.3.1 Sources de données 16
2.3.2 ETL 16
2.3.3 Data Warehouse 16

viii
TABLE DES MATIERES

2.3.4 Outils de restitution et analyse de données 16


2.3.4.1 Tableaux de bords 16
2.3.4.1.1 Définition 16
2.3.4.1.2 Objectif des tableaux de bord 16
2.3.4.1.3 Type des tableaux de bord 17
2.3.4.1.4 KPI indicateurs clés de performances 17
L’indicateur de performance, KPI (Key performance Indicator), est parmi les
composantes principales d’un tableau de bord. Il se définit selon Fernandez
comme étant Une mesure ou une liste de mesures dirigées vers un aspect
important de la performance globale de l’organisation [Fernandez, 2013]. Il existe
trois types de KPI selon Alain Fernandez toujours [Fernandez, 2013], classés par
type d’information à transmettre et par l’objectif pour lequel ils ont été utilisés : 17
2.4 La Modélisation Multidimensionnelle 17
2.4.1 Définition 18
2.4.2 Le cube multidimensionnel 18
2.4.3 Niveaux de présentation des données 19
2.4.3.1 Niveau conceptuel 19
2.4.3.1.1 Schémas de modélisation multidimensionnelle 19
2.4.3.2 Niveau logique 21
2.5 Types De Solutions Business Intelligence 22
2.5.1 Business intelligence traditionnelle 22
2.5.1.1 Caractéristiques fondamentales de la BI traditionnelle 22
2.5.2 Self-Service BI 23
2.5.2.1 Caractéristiques fondamentales d’un Self-Service BI 23
2.5.3 Comparaison 23
2.6 Tendances Du Décisionnel A L’ère Du BIG DATA 24
2.6.1 BIG DATA 24
2.6.1.1 Volume 24
2.6.1.2 Variété 24
2.6.1.3 Vélocité 25
2.6.2 Data Mining 25
2.6.3 L’intelligence Artificielle 25
2.6.4 Data Lake 25
2.6.5 Les principales différences entre Data Lake et un Data Warehouse en
environnement BI 26
2.6.6 Outils du Big Data 27
2.6.6.1 Hadoop distributed file system 27
2.6.6.1.1 Définition 27
2.6.6.1.2 Architecture HDFS 28
2.6.7 MAPREDUCE 28
2.6.7.1 Définition 28
2.6.7.2 Fonctionnement de MapReduce 29
2.6.8 Spark Apache Processing Engine 30
2.6.8.1 Définition 30
2.6.8.2 Fonctionnement 30
2.6.9 Combinaison Entrepôt ET Lac De Données : Le Data Lakehouse 30
2.6.10 Architecture D’un Data Lakehouse 31
2.6.11 Avantages et inconvénients d’utilisation du Data Lakehouse 32
3 Conclusion 34

II. Analyse des besoins et étude de l’existant ........................................ 35


ix
TABLE DES MATIERES

Présentation de l’organisme d’accueil 36


1.1 Introduction 36
1.2 Présentation de SONELGAZ 36
1.2.1 Historique 36
1.2.2 Aspect organisationnel du groupe Sonelgaz 38
1.2.2.1 Définition de la Holding 38
1.2.2.2 Organisation 38
1.2.3 Missions 39
1.2.4 L’informatique au sein du groupe SONELGAZ 39
1.3 Présentation D’ELIT 40
1.3.1 Dénomination et statut juridique 40
1.3.2 Missions et attributions 40
1.3.2.1 Le rôle des principales structures métiers est : 41
1.3.3 Clients d’ELIT 42
1.3.4 Structure d’accueil 42
1.4 Conclusion 43
2 Identification Des Besoins 44
2.1 Introduction 44
2.2 Périmètre D’étude Et Intervenants Du Projet 44
2.3 Ressources Utilisées Lors De La Collecte Des Besoins : 44
2.3.1 Documentation consultée : 44
2.3.2 Elaboration des entretiens 45
2.3.2.1 Entretiens avec les concepteurs et développeurs du système opérationnel
NOVA 45
2.3.2.2 Entretiens avec les futurs utilisateurs du système décisionnel 45
2.4 Identification des besoins 45
2.4.1 Les acteurs du système 45
2.4.2 Les besoins techniques 46
2.4.2.1 Outils de développement 46
2.4.2.2 Confidentialité et sécurité 46
2.4.2.3 Accès aux données 46
2.4.3 Les difficultés rencontrées 46
3 Analyse De L’existant 47
3.1 Introduction 47
3.2 Système D’information Opérationnel Existant 47
3.2.1 Etat de déploiement du système opérationnel NOVA 48
3.2.2 Technologies utilisées 49
3.2.3 Architecture physique 49
3.2.4 Etat du décisionnel au sein de Sonelgaz 49
3.2.5 Etude du processus de reporting actuel 49
3.3 Diagnostic De L’existant 52
3.3.1 Limites du système d'information existant Nova 52
3.3.2 Limites du système décisionnel existant 52
3.3.3 Causes engendrant ces limites et lacunes 52
3.3.4 Conséquences 53
3.4 Solutions Proposées 53
3.4.1 Solution 1 53
3.4.2 Solution 2 54
3.4.3 Solution 3 56
3.4.4 Choix 57

x
TABLE DES MATIERES

3.5 Conclusion 57

III. Conception De La Solution .............................................................. 58


1 Architecture Générale De La Solution 59
1.1 Introduction 59
1.2 Architecture Globale De Notre Solution 59
1.3 Sources De Données 60
1.4 Processus EXTRACT LOAD TRANSFORM 60
1.4.1 Présentation 60
1.4.2 Objectifs 60
1.4.3 Fonctionnement 60
1.5 Processus EXTRACT TRANSFORM LOAD 61
1.5.1 Présentation 61
1.5.2 Objectifs 61
1.5.3 Fonctionnement 61
1.6 Serveur Hadoop 61
1.7 Cube Molap 62
1.7.1 Présentation 62
1.7.2 Objectifs 62
1.8 Couche Visualisation de données 62
1.8.1 Présentation 62
1.8.2 Objectifs 62
2 Conception Du Secteur D’entreposage 63
2.1 Introduction 63
2.2 Dimension Conformes 63
2.2.1 La Dimension temps 63
2.2.2 La dimension Classement 63
2.2.3 La dimension Contrat 64
2.2.4 La dimension GSP 64
2.2.5 La dimension Organisation 64
2.2.6 La dimension Sexe 65
2.2.7 La dimension Âge 65
2.3 Volets D’analyses 65
2.3.1 Volet Suivi Effectif 66
2.3.1.1 Présentation du volet 66
2.3.1.2 Granularité 66
2.3.1.3 Dimensions nécessaires pour l’analyse : 66
2.3.1.4 Présentation des Mesures 67
2.3.1.5 Table de fait 67
2.3.1.6 Schéma en étoile du volet « Suivi de l’effectif » 68
2.3.2 Volet Suivi Des Recrutements 69
2.3.2.1 Présentation du volet 69
2.3.2.2 Granularité 69
2.3.2.3 Dimensions nécessaires pour l’analyse 69
2.3.2.4 Présentation des mesures 70
2.3.2.5 Table des faits 70
2.3.2.6 Schéma en étoile du volet 70
2.3.3 Volet Suivi Des Formations 71
2.3.3.1 Présentation du volet 71
2.3.3.2 Granularité 72

xi
TABLE DES MATIERES

2.3.3.3 Dimensions nécessaires pour l’analyse 72


2.3.3.4 Description des attributs des dimensions 73
2.3.3.5 Présentation des Mesures 74
2.3.3.6 Table de fait 74
2.3.3.7 Schéma en étoile du volet « Suivi de formation » 75
2.3.4 Volet Suivi De La Masse Salariale 76
2.3.4.1 Présentation du volet 76
2.3.4.2 Granularité 76
2.3.4.3 Dimensions nécessaires pour l’analyse : 76
2.3.4.4 Description des attributs des dimensions 77
2.3.4.5 Présentation des Mesures 77
2.3.4.6 Table des faits : 77
2.3.4.7 Schéma en étoile du volet : 78
2.3.5 Volet Suivi Des Absences 79
2.3.5.1 Présentation du volet 79
2.3.5.2 Granularité 79
2.3.5.3 Dimensions nécessaires pour l’analyse : 79
2.3.5.4 Description des attributs des dimensions 80
2.3.5.5 La dimension Motif absence 80
2.3.5.6 Présentation des Mesures 81
2.3.5.7 Table de faits : 81
2.3.5.8 Schéma en étoile du volet : 82
2.3.6 Volet Suivi Des Départs 82
2.3.6.1 Présentation du volet 82
2.3.6.2 Granularité 82
2.3.6.3 Dimensions nécessaires pour l’analyse 82
2.3.6.4 Description des attributs des dimensions et table de faits : 83
2.3.6.5 Présentation des Mesures 84
2.3.6.6 Table de faits 84
2.3.6.7 Schéma en étoile du volet : 85
2.4 Conclusion 85
3 Conception Du Secteur D’alimentation 86
3.1 Introduction 86
3.2 Etude des sources de données 86
3.2.1 Présentation des sources de données 86
3.2.2 Qualité des données 86
3.3 Conception de L’ELT 87
3.3.1 Extraction 87
3.3.2 Chargement 87
3.3.3 Transformation 88
3.4 Conception de L’ETL 88
4 Conception De La Zone De Restitution 89
4.1 INTRODUCTION 89
4.2 CONCEPTION DES CUBES 89
4.2.1 Définition des niveaux hiérarchiques des dimensions : 89
4.2.2 Présentation des cubes 91
4.3 Conception Des Rapports 92
4.3.1 Pour les rapports concernant les sociétés : 92
4.3.2 Pour les rapports concernant tout le groupe : 94
4.4 Conclusion 95

xii
TABLE DES MATIERES

IV. Réalisation et mise en œuvre ........................................................... 97


1 Présentation Des Technologies Utilisées 98
1.1 Introduction 98
1.2 Couche logiciel existante 98
1.3 Outils de réalisation de la solution 98
1.3.1 Composant ELT : 98
1.3.2 Couche de stockage : 99
1.3.2.1 Comparaison des outils créant un lac de données 99
1.3.2.2 Présentation de HDFS 100
1.3.3 Transformation des données 100
1.3.3.1 Presentation de Talend Open Studio For Big Data: 101
1.3.4 Infrastructure entrepôt de données 102
1.3.4.1 Comparaison des outils créant une infrastructure Data Warehouse 102
1.3.4.2 Présentation de Apache HIVE 103
1.3.5 Conception de cubes et analyse multidimensionnelle 103
1.3.5.1 Présentation de l’outil Apache Kylin 104
1.3.6 Outil de conception des rapports 105
1.3.6.1 Avantages de APACHE SUPERSET 105
1.3.7 Infrastructure Logicielle De La Solution 105
1.4 Conclusion 106
2 Réalisation Et Déploiement 107
2.1 Introduction 107
2.2 Réalisation de la solution 107
2.2.1 Implémentation du data Lake 107
2.2.2 Implémentation de l'infrastructure entrepôt de données 108
2.2.3 Implémentation de l'ELT / ETL 110
2.2.3.1 Création des connexions 110
2.2.3.2 Extraction 111
2.2.3.3 Transformation et Chargement 112
2.2.3.3.1 Processus de transformation du volet Suivie des formations 112
2.2.4 Développement des cubes 114
2.2.5 Réalisation de la phase Reporting 116
2.3 Sécurité du système 119
2.3.1 Sécurité applicative 119
2.3.2 Sécurité physique 119
2.4 Mesures d'intégration du système 120
2.5 Conclusion 120

Conclusion Générale Et Perspectives ................................................... 121


Conclusion 121
Perspectives 122
Références Bibliographiques 123
WEBOGRAPHIE 126

xiii
LISTE DES FIGURES

Liste des figures

Figure 1 : Gestion des ressources humaines et efficacité organisationnelle : modèle de Tsuiet Gomez-
Mejia (1988) 10
Figure 2 : cartographie des systèmes 14
Figure 3 : Architecture d'un système d'aide à la décision 15
Figure 4 : structure d'un cube multidimensionnel 18
Figure 5 : exemple d'un schéma en étoile 20
Figure 6 : exemple d'un schéma en flocon de neige 20
Figure 7 : exemple d'un schéma en constellation 21
Figure 8 : architecture de HDFS 28
Figure 9 : architecture de la solution lakehouse par databricks 32
Figure 10 : Historique de Sonelgaz 38
Figure 11 : Mission du groupe sonelgaz 39
Figure 12 : Organisation de ELIT 41
Figure 13 : Organisation de la DPGI 43
Figure 14 : Modules de NOVA 45
Figure 15 : Architecture de NOVA 46
Figure 16 : BPMN Génération de rapport de société 47
Figure 17 : BPMN génération de rapport au niveau de la holding 48
Figure 18 : Architecture de la solution d'integration du système sur NOVA 50
Figure 19 : Architecture de la solution de l'intégration sur un ERP back-office 51
Figure 20 : architecture de la solution choisi 58
Figure 21 : schéma de la dimension temps 62
Figure 22: schéma de la dimension classement 63
Figure 23: schéma de la dimension contrat 63
Figure 24: schéma de la dimension GSP 63
Figure 25: schéma de la dimension Organisation 64
Figure 26: schéma de la dimension sexe 64
Figure 27: schéma de la dimension âge 64
Figure 28 : schéma de la table fait suivi effectif 67
Figure 29 : schéma en étoile du volet suivi de l'effectif 67
Figure 30 : schéma de la table fait suivi des recrutements 69
Figure 31 : schéma en étoile du volet suivi des recrutements 70
Figure 32 : schéma de la dimension type de formation 72
Figure 33 : schéma de la dimension spécialité formation 72
Figure 34 : schéma de la dimension thème de formation 72
Figure 35 : schéma de la dimension sous thème de formation 73
Figure 36 : schéma de la dimension moyen de formation 73
Figure 37 : schéma de la table fait suivi des formations 74
Figure 38 : schéma en étoile du volet suivi des formations 74
Figure 39 : schéma de la dimension rubrique paie 76
Figure 40 : schéma de la table fait suivi de la masse salariale 77
Figure 41 : schéma en étoile du volet suivi de la masse salariale 78
Figure 42 : schéma de la dimension motif absence 79

xiv
LISTE DES FIGURES

Figure 43 : schéma de la table fait suivi des heures de travail 80


Figure 44 : schéma en étoile du volet suivi des heures de travail 81
Figure 45 : schéma de la dimension motif du départ 83
Figure 46 : schéma de la table fait suivi des départs 83
Figure 47 : schéma en étoile du volet suivi des départs 84
Figure 48 : BPMN du processus ELT 87
Figure 49 : BPMN ETL 88
Figure 50 : logo de apache HDFS hadoop 100
Figure 51 : logo de l'outil talend open studio 101
Figure 52 : logo de apache hive 103
Figure 53 : logo de apache kylin 104
Figure 54 : logo de l'outil apache superset 105
Figure 55 : schéma représentant les flux entre les composants de l'écosystème 106
Figure 56 : interface graphique de l'outil HDFS 108
Figure 57 : script de la création de la table dimension organisation dans hive qui sera stockée dans
HDFS 109
Figure 58 : script de la création et l'alimentation de la dimension temps 109
Figure 59 : liste des tables créées sous hive et stocké dans HDFS 110
Figure 60 : les métadonnées de connexion sur talend 111
Figure 61 : commande d'importation de toutes les tables de la base de données postgres vers HDFS
112
Figure 62 : job du chargement des données de la paie du fichier excel vers Hive 112
Figure 63 : job du chargement et alimentation de la table fait suivi des formations 113
Figure 64 : le mécanisme qui garantit la mise à jour seulement des tables de fait après le lancement
des job 113
Figure 65 : fenêtre d'authentification de KYLIN 114
Figure 66 : la source de données importée au sein de KYLIN 114
Figure 67 : modèles des différents volets 115
Figure 68 : les cubes conçus pour l'analyse 115
Figure 69 : requête sql sur le cube des formations sur superset 116
Figure 70 : un graphique burnset qui affiche le nombre des participants par type de formation et part
sous thème 117
Figure 71 : tableau de bord pour le suivi des formations 118
Figure 72 : création des comptes utilisateurs et attribution des rôles 119

xv
LISTE DES TABLEAUX

Liste des tableaux


Tableau 1 comparaison entre les solutions SIRH leaders 12
Tableau 2 comparaison entre les solution SIRH open sources 12
Tableau 3 comparaison entre les modèles multidimensionnels 22
Tableau 4 comparaison entre le BI self service et le BI traditionnel 24
Tableau 5 comparaison entre les structures lac de données et entrepôt de données 28
Tableau 6 : avantages et limites de la solution 51
Tableau 7 : avantages et limites de la solution 52
Tableau 8 : avantages et limites de la solution 53
Tableau 9 : description des utilisateurs de notre solution 56
Tableau 10 : tableau contenant les requêtes tirées depuis les besoins du client avec les dimensions
nécessaires 66
Tableau 11 : tableau contenant les requêtes tirées depuis les besoins du client avec les dimensions
nécessaires 69
Tableau 12 : tableau contenant les requêtes tirées depuis les besoins du client sur les formations
avec les dimensions nécessaires 71
Tableau 13 : tableau contenant les requetes tirées sur l'analyse de la masse salariale depuis le besoin
du client 76
Tableau 14 : tableau contenant les requêtes sur le suivi des heures de travail qui comble le besoin du
client 79
Tableau 15 : tableau d'analyse des requetes du suivi des départs avec les dimensions nécessaires 82
Tableau 16 : niveaux hiérarchiques des dimensions 89
Tableau 17 : la structure des cubes MOLAP conçu pour l'analyse 91
Tableau 18 : Contenu des rapports pour chaque société 92
Tableau 19 : contenu des rapports pour tout le groupe 93
Tableau 20 : comparaison entre les outils de création du lac de données 97
Tableau 21 : comparaison entre les outils d'intégration de données 98
Tableau 22 : comparaison entre les outils de création de la structure de données 99
Tableau 23 : comparaison entre les outils de l'analyse MOLAP 101

Liste des sigles et abréviations


RH : Ressources Humaines

GRH : La Gestion de la fonction ressources humaines.

SIRH : Système d'information des Ressources Humaines.

SI : Systèmes d’informations

SIO : Système d’information opérationnel

xvi
LISTE DES SIGLES ET ABREVIATIONS

KPI : indicateurs clé de performance

ETL : Extract Tranform Load

OLAP : ONLINE Analytical Processing

GPEC : Gestion Prévisionnelle des Emplois et des Compétences

MOLAP : Multidimensional Online Analytical Processing

HOLAP: Hybrid Online Analytical Processing

ERP : Entreprise Resource Planning.

BI : Business Intelligence

GoogleFS : Google File System

ELIT : El Djazair Information Technology.

SID : Système d’information décisionnel

HDFS : Système de fichiers distribués de hadoop.

RDD : ensemble de données distribuées résilient

AWS : Services Web d'Amazon.

ACID : Atomicité, Cohérence, Isolation, Durabilité

DCH : Direction du capital humain

BPMN : Business Process Model and Notation.

GSP : Groupe socio-Professionnel

xvii
INTRODUCTION GENERALE

Introduction générale

Contexte
Le Groupe Sonelgaz est l’opérateur historique dans le domaine de la fourniture des
énergies électrique et gazière en Algérie. Ses missions principales sont la distribution, le
transport et la production de l’électricité et du gaz par canalisations. Son nouveau statut de «
Groupe » acquis depuis quelques années et qui a permis la création de nombreuses filiales et
structures fonctionnelles, qui se distinguent par leurs différents métiers et activités
professionnelles.
En janvier 2009, l’application des systèmes d’information confiée à la Direction Générale des
Systèmes d’Information de la Sonelgaz, a été élevé en société par actions, Dénommée «EL
DJAZAIR INFORMATION TECHNOLOGY » aussi appelée "ELIT".
ELIT, filiale du Groupe Sonelgaz, a pour mission de réaliser un système d'information global
pour les sociétés de SONELGAZ, en premier lieu, et pour le marché national, en second lieu.
Aujourd’hui, les entreprises courent vers l’innovation et l’optimisation de leurs activités
quotidiennes, et ce pour atteindre un avantage concurrentiel et créer de la valeur ajoutée.
ELIT fait face à plusieurs défis notamment, l’exploitation et l’analyse de données
opérationnelles qu’elles détiennent dans leurs centres de données pour tirer des informations
utiles et pertinentes servant de base à la prise de décision.
De ce fait, l’activité de prise de décisions est amenée à exploiter l’ensemble des données
collectées par l’entreprise afin de définir les mesures et les indicateurs pour aider les décideurs
dans ce processus.
À ce titre, SONELGAZ veut exploiter les données des ressources humaines qui sont à ce jour
faiblement exploitées dans la prise de décision. La raison pour laquelle SONELGAZ a confié
à ELIT la mission de mettre en place un système efficace d’aide à la décision permettant
d’améliorer la qualité, l’intégrité et la transparence des informations utilisées pour éclairer
d’une manière efficace et optimale le processus décisionnel du système RH.
C’est dans ce contexte que nous a été confiée la mission de réaliser l’environnement d’aide à
la décision.

Problématique
SONELGAZ, ou Société nationale de la distribution, production et transport de
l’électricité et du gaz, est le groupe leader de la distribution, production, et transport de
l’électricité et du gaz en Algérie contant 39 sociétés et plus de 100000 employés.

1
INTRODUCTION GENERALE

Le groupe vise à être parmi les leaders mondiaux dans son domaine, c’est pour cela qu’il œuvre
à l’amélioration continue de son corps sur tous les aspects notamment sur un axe très important
qu’est la gestion des ressources humaines.
De ce fait, Sonelgaz a développé un système d’information nommé NOVA qui couvre les
opérations de gestion des ressources humaines mais dispose d’aucun moyen d’aide à la
décision.
Jour après jour, Le patrimoine informationnel dans toutes les sociétés de Sonelgaz a vu une
immense croissance, générant ainsi un volume colossal de données concernant la fonction
ressources humaines de Sonelgaz.
De ce fait, l’entreprise se retrouve à gérer un très grand volume de données (dépassant la barre
de deux Térabytes) de nature décentralisé et hétérogènes ou on trouve des données structurées,
semi-structurées et non structurées (photos, contrats de travail, demandes de démission …etc.),
ces immenses données volumineuses nécessitent l’utilisation des nouvelles avancées
technologiques du domaine du traitement de données pour permettre de les gérer efficacement.
Par conséquent, les décideurs trouvent de plus en plus de difficulté voire une quasi-
impossibilité de juger la politique de GRH du groupe.
Par conséquent et compte tenu de ce qui précède les décideurs, ne disposant d’aucun
système d’aide à la décision, se trouvent dans l’impossibilité de choisir, d’agir dans le bon
sens et de prendre la bonne décision au bon moment.

Objectifs
Dans le cadre du projet proposé par ELIT, et Afin de surmonter les problèmes posés
précédemment, une solution doit être mise en place en tenant compte des objectifs suivants :
1. Centraliser l’ensemble des données volumineuses dans un système de stockage central et
unique permettant ainsi un accès plus facile et rapide.

2. Automatiser le processus de reporting de façon à diminuer le nombre d’intervenants de


plusieurs parties prenantes à une seul qu’est les décideurs.

3. Diminuer considérablement le temps total de préparation des rapports de plusieurs jours à


quelques minutes ou secondes.

4. Mettre en place une architecture logicielle optimisée pour le traitement des données de très
grands volumes pour résoudre le problème de lenteur dû à la quantité de données.

5. Fournir aux décideurs et aux analystes la possibilité de naviguer dans les données et
d'effectuer des analyses appropriées concernant les processus RH de l’organisation.
6. Déterminer les mesures adéquates afin de permettre d’analyser les volets RH existants
(effectif, départs, embauches, masse salariale, absences et formation)

2
INTRODUCTION GENERALE

Organisation du document
Afin de bien présenter notre travail, nous avons divisé le présent document en quatre
parties principales :
Partie 1 : Synthèse Bibliographique
Cette partie est purement théorique, elle met en lumière les systèmes d’aide à la décision, les
entrepôts de données ainsi que les différents concepts métiers liés aux ressources humaines.
Partie 2 : Etude de l’existant Et Analyse Des Besoins
Le premier chapitre de cette partie présente l’existant organisationnel de l’entreprise à travers
l’étude des différentes structures et évolutions depuis sa création.
Le deuxième chapitre évoque l’ensemble des besoins fonctionnels et non fonctionnels du
nouveau système, les principaux objectifs du système à mettre en œuvre, l’ensemble des axes
à traiter et les acteurs que le système doit être en mesure de couvrir. Enfin, nous exposons les
différentes solutions possibles, leurs comparaisons et à la fin le choix de la solution la plus
adéquate.
Le troisième chapitre présente l’existant fonctionnelle de l’entreprise à travers les différents
processus métiers recensés et les systèmes opérationnels et décisionnels existants.
Partie 3 : Conception
Dans cette partie, nous détaillons la conception de notre solution globale énoncée dans la partie
précédente. Nous présentons en premier lieu l’architecture générale de la solution avant de
passer à la conception détaillée de chaque composant donc la conception de la zone
d’entreposage, la conception de la zone d’alimentation et la conception des cubes
dimensionnels ainsi que la conception de la zone de restitution.
Partie 4 : Réalisation et mise en œuvre
C’est la dernière partie de notre travail dans laquelle nous présentons la mise en œuvre du
projet. Nous l’abordons en présentant les outils et technologies utilisés avant de s’étaler sur la
réalisation et le déploiement de la solution.

Nous Clôturons le mémoire avec une conclusion générale qui présentera le bilan du travail
ainsi que les perspectives de la solution mises en place.

3
Première Partie

I. Synthèses Bibliographiques

4
Chapitre 1
1 La Fonction Ressources Humaines
Le concept d'entreprise en tant que « groupe social » a été introduit et développé au début
du 20e siècle, et comprenait de véritables dirigeants tels que le français Henri Fayol.
Dans cette perspective, la gestion des ressources humaines correspond à une fonction très
importante de l'entreprise.

1.1 Définition De La Fonction RH


Les auteurs [DOLAN et al., 2002], présentent la gestion des ressources humaines d’une
organisation comme une série d'actions ayant pour but de gérer les capacités et l'énergie
individuelle pour promouvoir la mise en œuvre de la tâche, de l’objectif et des buts structurels.

Selon [VALLEMONT, 1999] « La gestion des ressources humaines est une fonction, qui se
base sur plusieurs axes principaux, notamment : le suivi des formations employées, et
l'application des droits au travail, la gestion des carrières, les relations interpersonnelles et la
gestion des paies.

En se basant sur les propos précédents, dans la fonction RH, l’être humain est une source de
valeur et ceci est dû à ses différentes forces intellectuelles et physiques.

[GAUDEN,1994] quant à lui affirme que la gestion des ressources humaines a pour but de
gérer l’effectif humain en mettant l’employé le plus adapté dans l’emploi le plus adapté au
moment le plus adapté,

Et donc d’après GAUDEN, Nous présentons les objectifs principaux de la GRH dans ce qui
suit :
1. La délimitation avec précision de l’effectif de l’organisation.
2. La distribution optimale de l’effectif présent dans les postes organisationnels.

[DA MATHA, 2000] affirme que la gestion des ressources est devenue actuellement, le garant
de l’évolution de l'économie au sein de l’organisation.

1.2 Evolution De La GRH


La gestion des ressources humaines a connu plusieurs évolutions de l'ère industrielle à
l'ère actuelle. Celles-ci sont classées comme suit :
1.2.1 Époque de la révolution industrielle (19e siècle)
Au cours des progrès du secteur industriel en Europe occidentale et aux États-Unis, il
y a eu une croissance systématique de la GRH. La révolution industrielle comprend le
5
développement des machines, l'utilisation de l'énergie mécanique et l'existence du concept
d'usine avec une main-d'œuvre suffisante.
L'ancien système de chalets a été remplacé par le système d'usine. Durant cette période, divers
changements ont été introduits tels que le processus mécanique, la migration des travailleurs
de leur lieu vers d'autres lieux et la communication entre les travailleurs et les propriétaires.
Trois systèmes de GRH ont été introduits dans le cadre de ce système : le recrutement des
travailleurs, leur formation et leur contrôle adéquat. La philosophie maître-serviteur a été
utilisée pour garder le contrôle sur ces travailleurs.
1.2.2 Époque du mouvement syndical (proche du XIXe siècle)
Avec l'émergence du système d'usine, les travailleurs ont commencé à créer leur propre
syndicat sur la base de leur intérêt commun qui a été appelé “syndicats”. L'objectif fondamental
de ces associations était de protéger les intérêts des membres et de traiter les doléances des
travailleurs qui peuvent survenir en raison du travail des enfants, des longues heures de travail
et des conditions de travail pathétiques.
D'autres problèmes de travail sont également devenus courants, tels que les problèmes
économiques, la baisse des salaires, les avantages sociaux des travailleurs et d'autres services.
Pour donner un retour de flamme à ces problèmes, le syndicat a fait des grèves, des
ralentissements, des débrayages, des boycotts et ainsi de suite. Tous ces problèmes reflétaient
la nécessité d'un système de traitement des plaintes des employés et de pratiques disciplinaires,
étendre les avantages des employés, des vacances et une structure défendable pour un salaire.
1.2.3 L'ère de la responsabilité sociale (début du 20e siècle)
Une approche humaniste, ainsi que paternaliste, a été adoptée à l'égard des ouvriers
d'usine dès la première décennie du 20e siècle. En d’autres mots, cela signifie que le travailleur
est comme un enfant pour son propriétaire et que le propriétaire est le père qui s'occupe de tout
le travail.
Certaines facilités et concessions supplémentaires sont accordées à la main-d'œuvre par les
industriels qui travaillaient sur cette politique telle que minimiser les heures de travail,
améliorer les conditions de travail, abriter les travailleurs...etc. Il s'agit d'une approche sociale
qui a été adoptée pour lutter contre le problème des travailleurs et qui est considérée comme
un régime de protection sociale pour contrôler les travailleurs.
1.2.4 Ère de la gestion scientifique (1900-1920)
Taylor a commencé à chercher des approches techniques pour augmenter la
productivité des travailleurs au début du 20e siècle. Il a écrit des techniques scientifiques
pertinentes pour gérer la main-d'œuvre et même un livre sur la gestion. La gestion des
travailleurs est pertinente pour les techniques de gestion scientifique telles que la maîtrise
fonctionnelle, la simplification de la tâche et le système de taux de salaire différentiel. Certains
des principes de la gestion scientifique sont donnés ci-dessous :
1. Remplacement de la règle empirique par la science.
2. Pas de conflits mais seulement d'harmonie.
3. Coopération et dire non à l'individualisme.
4. Croissance de chaque travailleur.

6
1.2.5 L'ère des relations humaines (1930-1950)
L’accent a été mis davantage sur le facteur humain au travail et sur ce qui a affecté le
comportement des gens dans les années 1920. À cette époque, il était fortement recommandé
d'utiliser la psychologie tout en faisant des tests personnels, des entretiens, des mesures
d'attitude ainsi que l'apprentissage.
Fondamentalement, la période a été définie comme « l’ère de la psychologie industrielle » en
1924. Après des recherches approfondies menées par les enseignants de l’université Harvard
Business, on a observé que la productivité des travailleurs dépend des facteurs sociaux au
travail, de la formation et de l'influence des groupes, de la nature du leadership et de la
supervision et enfin, de la communication.
Il a été conclu que la direction doit maintenir les relations humaines au travail ainsi que les
conditions physiques pour augmenter la productivité.
1.2.6 Ère des sciences du comportement (1950-1960)
Suivant la loi qui dit “des ouvriers heureux sont de bons ouvriers”, les scientifiques du
comportement suggèrent que le comportement d'un humain suit l'aspect mis en évidence.
Diverses méthodologies de recherche sont utilisées pour comprendre la nature du travail ainsi
que les personnes dans l'atmosphère de travail.
Voici quelques-unes des principales conclusions tirées par le spécialiste du comportement qui
sont données ci-dessous :
1. Les gens aiment leur travail, mais il est nécessaire d'établir certains objectifs
afin qu'ils puissent travailler correctement pour les atteindre en temps
opportun. Cela augmente également leur satisfaction au travail.
2. Les employés génèrent un maximum de créativité par rapport à ce dont ils ont
besoin. Mais leur potentiel n'est pas utilisé de manière appropriée.
3. L'utilisation du potentiel inexploité d'un employé est le devoir des
gestionnaires.
4. Un environnement doit être créé pour que les gens puissent contribuer de la
meilleure façon possible et cela doit être fait par le gestionnaire.

1.3 Processus Métiers De La Ressources Humaines


Les fonctions de la RH dans les entreprises sont diverses et variées. D’après la norme
iso 9001, elles sont définies comme suit :
1.3.1 La gestion des compétences
La norme qualité ISO 9001 a depuis longtemps mis l'accent sur la gestion des
compétences, elle sert à développer le capital humain, adapter les compétences aux emplois,
recruter des profils pertinents et motiver les collaborateurs. Le processus passe par les états
suivants :
1. Évaluer les compétences.
2. Gérer les talents.
3. Gérer les cadres avec un grand potentiel.
4. Assurer la gestion stratégique des postes et des compétences.
7
5. Mettre un référentiel de compétences.
6. Faire un bilan de compétences.
1.3.2 La gestion de la masse salariale
Pour une bonne période de temps, la GRH avait comme mission principale, que les
paiements des salariés, en effet, la rémunération à une double dimension, c’est un coût pour
l’entreprise (on parle de charges de personnel), mais aussi un facteur d’insatisfaction pour les
salariés selon [HERZBERG,1959] la théorie des deux facteurs.

La paie se résulte après la fusion de deux facteurs qui sont l'augmentation pour l'employé et la
diminution pour l'organisation, pour cela la paie de nos jours et divisée en deux parties l'une
est fixe et l'autres varie selon les compétences des employés, majoritairement les employés
cadres supérieures bénéficient des primes spéciales notons les automobiles de services…etc.
1.3.3 Suivi des formations
En ces temps incertains, la capacité des employés est au cœur de l'évolution. La pression
de l’externe demande un degré considérable en termes d'élasticité. Là, il n'y a plus
d'organisation simple, cryptée, il est possible Pour atteindre cette flexibilité, La solution est
claire. Soit recruter des nouvelles compétences, au risque du mauvais choix et ainsi d’autres
conflits comme l'intégration dans une équipe de projet et le risque de voir les nouveaux
collaborateurs partir quelques mois plus tard, soit opter pour la formation des ressources
existantes.
Les principales missions de la gestion de la formation sont :

1- Suivre un planning de formation régulier.


2- Organiser au besoin des formations en local.
3- Estimation du taux de succès de la formation.
4- Penser à numériser les formations (à distance, webinars).

1.3.4 Suivi des recrutements


Les besoins de l'organisation sont souvent la cause principale qui la pousse à
embaucher, l'accord entre ces besoins et les connaissances d'un candidat génèrent une nouvelle
embauche, pour cela l'organisation doit bien expliciter les connaissances et les valeurs
attendues du candidat, après un entretien bien solide avec un expert de l'équipe qui intégrera le
candidat, un processus de sélection se déclenche afin de choisir le bon candidat pour mieux
répondre aux besoins de l'organisation,
1.3.5 Suivi des conditions de travail
Ce processus avait toujours reposé sur les risques physiques du travail, il a pour but de
minimiser les maladies et les problèmes sanitaires dû au travail, actuellement la notion de
psychologie est rentrée sur le terrain, cet aspect est utilisé pour réduire le stress du travail et
motiver les employés, car d'après une étude, la mentalité de l'employé influence sur sa
production en termes de travail dans l’organisation [BEN HASSAN, 2011]

1.4 Rôle Stratégique De La GRH En Entreprise


Les différents changements intervenus au cours des dernières décennies ont contraint
les entreprises à emprunter le chemin de la performance. En effet, ce nouvel environnement
des affaires oblige plus que jamais les entreprises à trouver des éléments leurs procurant la

8
capacité de se distinguer de leurs principaux concurrents et d'être en mesure de trouver un
avantage concurrentiel durable.
Mais qu'entendons-nous par avantage concurrentiel durable ? Si l'on se réfère à la théorie des
ressources stratégiques [McMahan, Virick et Wright, 1999], Nous pouvons dire que c'est un
avantage concurrentiel durable seulement lorsqu'il représente un atout précieux, difficile à
imiter et irremplaçable.
Selon cette théorie, l'utilisation des avantages traditionnels tels que la technologie, le capital et
les marchés ne peut plus suffire à assurer à l’organisation un avantage d'affaires durable. Au
mieux, ces trois éléments représentent des avantages relatifs qui ne sont pertinents que dans
une logique à court terme.
Les entreprises d'aujourd'hui peuvent facilement obtenir les capitaux dont elles ont besoin pour
se développer sur toutes les grandes places financières du monde, et elles peuvent également
bénéficier de la même technologie que leurs principaux concurrents. Et donc, si le capital, la
technologie et le marché ne peuvent assurer cet avantage concurrentiel durable, alors quelles
stratégies devra adopter l’entreprise qui lui permettrait de rivaliser avec ses principaux
concurrents ? Selon la théorie des ressources stratégiques, « si une entreprise veut obtenir un
réel avantage concurrentiel, elle doit faire un pari stratégique sur sa structure sociale »
[Boudreau et Milkovich, 1999]
Plus précisément, cette théorie considère que, contrairement à d'autres actifs organisationnels,
la gestion des ressources humaines constitue une ressource précieuse, rare, difficile à imiter, et
qui ne peut être remplacée par aucun autre élément de production. Ces quelques propriétés
inhérentes à la GRH semblent dès lors suffisantes pour faire de la GRH une fonction
administrative hautement stratégique de l'entreprise, imputable principalement des grands
objectifs sociaux, économiques, financiers et politiques de l'organisation.
De plus, les adaptations suivantes des modèles Tsui et Gomez-Mejia montrent l'importance de
la gestion de la fonction ressources humaines en tant qu'entrée pour atteindre les objectifs fixés
par l'entreprise.
Conséquemment, la GRH peut être définie comme « système organisationnel conçu pour
obtenir un avantage concurrentiel durable grâce aux personnes » [Snell, Yound et Wright,
1996].

9
Figure 1 : Gestion des ressources humaines et efficacité organisationnelle : modèle
de Tsuiet Gomez-Mejia (1988)

10
1.5 Solutions Informatiques Appliquées A La GRH
De par la grande importance de la gestion de ressources humaines citées auparavant,
plusieurs solutions informatiques ont été créées pour automatiser et optimiser les différents
processus de la GRH. Nous présentons ci-dessous quelques exemples :
1.5.1 Les solutions payantes
Nous présenterons dans ce qui suit les solutions les plus connues du marché d’après
[Gilles Exbrayat et al, 2010], en identifiant les caractéristiques principales d’un SIRH et qui
sont :
1. Les caractéristiques logicielles
2. La taille de l’organisation
3. Le type de l’hébergement
4. Les informations sur le produit
5. La compatibilité avec les plateformes

Nom du produit UKG PRO WORKZOO ORACLE HCM SAP HCM


M Cloud
Caractéristiques logicielles
Gestion des absences Oui Oui Oui oui
Paiement Oui Oui Oui oui
Gestion administrative Oui Oui Oui oui
Réseaux sociales Oui Non Oui oui
Santé et sécurité Oui Oui Oui non
Flux de travail Oui Oui Oui oui
Gestion de la carrière Oui Oui oui oui
Dashboarding Oui Non oui oui
Recrutement Oui Oui oui oui
Gestion des congés Oui Oui oui oui
Formation et suivi des Oui Oui oui oui
compétences
Taille de l’organisation
Entreprise (+1000) Oui oui oui Oui
Moyen (251-1000) Oui oui oui Oui
Petit (-250) Non oui non Non
Type hébergement
Cloud oui oui oui Oui
On Premise non Non non Oui
Information sur le produit
Modulaire oui non oui Non
Multilingue oui oui oui Oui
Multi devise oui oui oui Oui
Personnalisable oui non oui Oui

11
Compatibilité sur les plateformes
Application mobile oui non oui Oui
Site web oui oui oui Oui
Tableau : comparaison entre les solutions SIRH leaders [Gilles Exbrayat et al, 2010]

1.5.2 Solutions open sources


Plusieurs solutions open sources ont été développées pour la fonction RH, on cite les
suivantes ainsi que leurs caractéristiques.
Nom du produit COLLAGE ERP Open Simple HRM
CangourouHR source
Caractéristiques logicielles
Gestion des absences oui oui oui oui
Paiement oui oui oui oui
Gestion administrative oui oui oui oui
Flux de travail oui non oui oui
Gestion de la carrière oui oui oui oui
Rapport et statistique oui oui oui oui
Recrutement oui Oui oui oui
Gestion des congés oui Oui Oui oui
Formation et suivi des oui Non Oui oui
compétences
Temps et présence oui Non Oui oui
Tableau 2 : comparaison entre les solutions SIRH open sources [Gilles Exbrayat et al,
2010]

1.6 Conclusion

Dans cette partie, nous avons mis l’accent sur les principes de base liés à la fonction
RH en définissant en premier lieu cette notion et comment celle-ci a évolué à travers l’histoire.
Ensuite nous avons éclairé les processus métiers de la gestion RH, pour par la suite, figurer
l’impact essentiel de ce domaine sur le plan stratégique d’une entreprise ainsi que sa valeur
pour l’organisation. Et nous avons terminé par une présentation des outils informatiques les
plus connus dans le marché qui traitent de la gestion automatique du capital humain.
Dans le chapitre suivant, Nous allons exposer les systèmes d’informations décisionnels ainsi
que tous les concepts et technologies en relation avec ce domaine.

12
Chapitre 2
2 Les Systèmes Décisionnels
Aujourd'hui, nul ne peut nier l'importance des données en entreprise. Les données sont
devenues de nos jours le moteur de la relation client, de la stratégie commerciale et de tout axe
de travail d’une entreprise.
Et donc, se doter d'un système d'information décisionnel est considéré comme un moyen
important, que nous pouvons même qualifier d’indispensable, pour parvenir à une gestion
efficace, faire face à une concurrence féroce sur le marché, assurer une innovation continue,
fidéliser et écouter les avis des clients et bien plus encore.

2.1 Concepts De Base


Avant d’entamer cette étude, nous allons définir les concepts de base se rapportant au
domaine du décisionnel, il s’agit de système, système d’information, système d’information
opérationnel et système d’information décisionnel.
Un Système est défini comme un « Ensemble d’éléments en interaction dynamique, organisé
en fonction d’un but » [Rivière et al.,2014].
Un Système d’information est la structure de toutes les capacités (logiciels, physique,
informationnelles, procédures, humains…) Structurés pour obtenir, traiter, stocker et fournir
l’information dans et entre les organisations [Rivière et al, 2014].
Le SI d’après [Reix et al, 1995] représente l’ensemble des ressources (humaines, matérielles,
logicielles) organisées pour :
1. Collecter l’information.
2. Mémoriser l’information.
3. Traiter l’information.
4. Diffuser l’information.
Les éléments du système présentés ci-dessus sont eux-mêmes des systèmes (ou sous-systèmes)
et qui sont : Système de décision, Système d’information, Système opérant et
Environnement.
Comme toute organisation, l’entreprise est un système. Et donc l’entreprise est décomposable
en trois sous-systèmes : système de décision, système d’information et système opérant
présentées comme ci-dessous :

13
Figure 2 : cartographie des systèmes
On retrouve comme types de systèmes :
1. Opérationnel qui gère le côté métier de l’entreprise.
2. Pilotage qui contrôle, commande et établit les objectifs à atteindre.
3. Un système d’information qui sert à gérer les informations dans l’entreprise.
Selon Ferragu et al., nous avons aussi deux grandes catégories de système d’information
[Ferragu et al., 2013] :
Système d’information opérationnel (SIO) qui a pour objectif premier de servir de support à
la mise en œuvre des activités d’une série de processus métier.
Système d’information décisionnel (SID) par opposition à un SIO dont l’objectif est
l’exécution d’un processus métier, un SID a pour but l’évaluation de la performance des
processus. Il a pour vocation de faciliter le processus de prise décision en donnant des réponses
à des questions telles que : quelle fut l’évolution du chiffre d’affaires et de la marge brute pour
chaque catégorie de produits entre le premier semestre de cette année et celui de l’année
précédente ?

2.2 Objectifs D’un Systeme D’information Décisionnel Dans


Une Entreprise
Bien que les activités de l'entreprise soient diverses, les raisons pour lesquelles les
entreprises utilisent des systèmes d'intelligence d'affaires sont très courantes.
14
D’après [KIMBALL, 2013] les objectifs du système en question sont :
1. Obtention des statistiques courtement et aisément.
2. Harmonie des informations : les données du SID sont fiables et de bonne qualité.
3. Ajustabilité selon le besoin : dans le cas du changement de la couche logicielle ou des
exigences, les données présentes dans le système doivent être ajustées.
4. Afficher l'information au moment opportun : L'information doit être présente et apte à
être utilisée au moment voulu.
5. Sécurité des données : les données d’une organisation sont un secret qui doit être protégé
par le système décisionnel à travers un contrôle d’accès.
6. Transformer des données massives en valeur commerciale.

2.3 Architecture D’un SID

D'après [LAU et al, 2009] Le processus du système de prise de décision comprend


différentes sources, internes ou externes, pour les transformer en informations afin de diffuser
sous forme de rapports ou de tableaux de bord.
Pour permettre la réalisation de ce processus, l’architecture d’un système décisionnel mise en
place est composée de quatre niveaux qui sont :
1. Les sources de données.
2. L’entrepôt et les magasins de données.
3. La phase ETL.
4. La restitution de données.

Le schéma ci-dessous illustre l’architecture d’un système décisionnel :

Figure 3 : Architecture d'un système d'aide à la décision [Laurent Brisson et


al,2018]

15
2.3.1 Sources de données
Elles sont nombreuses, variées, distribuées et autonomes. Elles peuvent être internes
(bases de production, ERP (Enterprise Resource Planning), Archives, Feuilles de calcul...) ou
externes (Internet, bases des partenaires) à l'entreprise. [TESTE ,2000]
2.3.2 ETL
Il permet l’extraction des données à partir des sources de données. Ces données subissent une
transformation qui peut être un nettoyage, formatage ou standardisation afin de les charger dans
l’entrepôt de données. [ALPHONSE Carlier, 2013]
2.3.3 Data Warehouse
Inmon présente l’entrepôt de données dans son bouquin considéré la référence dans la
discipline “Building the Data Warehouse” de la façon suivante : « L’entrepôt de données est
un ensemble de données stockée d’une façon pour qu’elles soient intégrées, évolutives dans le
temps, orientées sujet et non volatiles structurées pour la base de l’assistance à la décision »
[Inmon et al., 2001].
L'entrepôt de données est aussi un ensemble de méthodes, techniques et outils rassemblant des
données issues de sources multiples au sein d'un modèle cohérent à des fins d'analyse et
d'assistance à la décision. L'architecture et la logistique du système d'information utilisant un
Data Warehouse transforme le flux de données opérationnelles en informations décisionnelles.
Un entrepôt de données est caractérisé par ce qui suit :
● Orienté sujet : l'entrepôt de données est composé des faits les plus consistants de
l'organisation
● Intégrée : la structure sera alimentée par une diversité de sources, pour assurer
l'intégrité, un processus de contrôle d'incohérence est obligatoire.
● Évolutive dans le temps : afin de pouvoir comparer et prendre de bonnes décisions les
systèmes doivent stocker toutes les valeurs d’une donnée et son évolution à travers le
temps.
● Non volatiles : la structure doit toujours garder les données antérieures même dans le
cas d'une actualisation, ainsi la modification sur les données est interdite.

2.3.4 Outils de restitution et analyse de données


Cette partie dans un système décisionnel est la plus exploitable, elle permet aux
décideurs de visualiser l’ensemble des informations et indicateurs de performance afin de
collecter le fruit du SID.
De nos jours, plusieurs technologies permettent de faire cette restitution d’une manière claire
et efficace la plus connus reste le Tableau de bord
2.3.4.1 Tableaux de bords
2.3.4.1.1 Définition
Le tableau de bord « Dashboard en Anglais » est une suite de quelques indices destinés
à permettre aux managers d’estimer la croissance des systèmes qu'ils gèrent et de caractériser
les orientations qui les affectent dans une fourchette naturellement harmonieuse avec leurs
fonctions. [Christophe Legrenzi, 2011]
2.3.4.1.2 Objectif des tableaux de bord
Les tableaux de bord sont des outils utilisés pour évaluer l’état du système, ils ont pour
but de :

16
1. Faciliter l’accès aux données, en rassemblant plusieurs informations et
données, dans une seule interface généralement sous formes de graphiques
analytiques.
2. Mieux distinguer et visualiser l’écart entre l’exigence et le résultat.
3. Prédire les imprévus, les risques et les opportunités de l’entreprise.
4. Accompagner l’état de l’entreprise en temps réel
2.3.4.1.3 Type des tableaux de bord
Selon Christophe Legrenzi, Il existe trois types principaux de tableaux de bords [Christophe
Legrenzi, 2011] :
Tableau de bords stratégiques : Ils permettent de suivre la stratégie à long terme de
l'entreprise à l'aide de facteurs de succès critiques. Ils sont généralement complexes dans leur
création, ont un impact à l’échelle de l’entreprise et sont principalement utilisés par les cadres
supérieurs.

Tableau de bord opérationnel : Un Dashboard opérationnel est un modèle utilisé pour


surveiller et gérer des opérations qui ont un horizon temporel plus court. Puisqu'ils se
concentrent sur le suivi des processus opérationnels, ils sont généralement administrés par des
cadres de niveau inférieur.

Tableau de bord analytique : Un Dashboard analytique est un modèle qui contient des
données massives entretenues par les analystes afin de soutenir les dirigeants. Ils fournissent à
une entreprise une vue d'ensemble complète des données, la direction intermédiaire étant un
élément crucial de son utilisation.
2.3.4.1.4 KPI indicateurs clés de performances
L’indicateur de performance, KPI (Key performance Indicator), est parmi les composantes
principales d’un tableau de bord. Il se définit selon Fernandez comme étant Une mesure ou une
liste de mesures dirigées vers un aspect important de la performance globale de l’organisation
[Fernandez, 2013]. Il existe trois types de KPI selon Alain Fernandez toujours [Fernandez,
2013], classés par type d’information à transmettre et par l’objectif pour lequel ils ont été
utilisés :
1. Indicateurs d'alarme : Ils indiquent des défauts ou un état anormal du
système qui nécessitent des actions correctives basées sur des seuils
prédéfinis.
2. Indicateurs d'efficacité et d'équilibre : ils servent à mesurer l'état actuel du
système en fonction d'objectifs établis et peuvent entraîner des ajustements
des objectifs ou des stratégies.
3. Indicateurs attendus : Ils renseignent sur la demande future et permettent
de prévoir et de réfléchir sur les choix et les décisions.

2.4 La Modélisation Multidimensionnelle


Avec le taux énorme de données des entreprises d’une part et les besoins grandissants
d’analyse et d’exploitation de ces données par les décideurs de l’entreprise d’autre part, la
création d’un nouveau modèle de modélisation s’est imposée pour combler les lacunes et les
17
incapacités des modèles relationnels. En effet, ceci a donné naissance à un nouveau modèle qui
est le modèle multidimensionnel.
2.4.1 Définition
Le modèle était populaire auprès de Ralph Kimball dans les années 90, et maintenant
considéré comme le meilleur modèle d'analyse et d'adoption des exigences décisionnelles
[Adamson, 2012].
La modélisation multidimensionnelle consiste à traiter les données comme points projetés dans
un espace multidimensionnel, représentant différents axes d'analyse. Les données sont
organisées dans le but de mettre en avant le sujet analysé et ses différentes perspectives
d'analyse [Gray et al., 1996].
Par conséquent, la modélisation multidimensionnelle permet aux utilisateurs d'expliquer et de
fournir des données en fonction des sujets d'analyse, ce qui n'est pas faisable dans la
modélisation entités-association. Ce modèle multidimensionnel contient plusieurs concepts de
base, tels que des faits, dimension, dimension de conformité et matrice de bus que nous
définirons dans le reste de ce chapitre.

2.4.2 Le cube multidimensionnel


Le cube multidimensionnel est le concept de base de la modélisation
multidimensionnelle. Il permet de modéliser les informations numériques de la base de données
Multidimensionnel, de sorte que chaque arête du cube représente une dimension, chaque cellule
représente une ou plusieurs mesures. Le cube est utilisé pour l'analyse, l'exploration de données
et la Modélisation d'association d'entités. Par exemple, l'ensemble de données
multidimensionnelles illustré dans la figure suivante permet d'analyser selon les trois
dimensions du temps, du produit et du site. Il vous donne le niveau de détail dont vous avez
besoin En raison de la hiérarchie différente des dimensions. [Bastien L , 2018]

Figure 4 : structure d'un cube multidimensionnel [Bastien L , 2018]


Le cube a les caractéristiques suivantes :
1. Accès rapide et facile.

18
2. Possibilité d'agréger les informations en fonction des besoins des utilisateurs.
3. Procéder des données de synthèse selon différents axes d'analyse.
2.4.3 Niveaux de présentation des données
Selon Teste, deux grands niveaux de présentations de données dans la modélisation
multidimensionnelle sont distingués : [Teste, 2009]
▪ Niveau conceptuel : il s'agit de la description de la base de données quel que soit le
choix de la technologie.
▪ Niveau logique : Il s'agit de la définition de la base de données utilisant la
technologie informatique (objets, relations ...).
2.4.3.1 Niveau conceptuel
À ce niveau, nous allons introduire les concepts multidimensionnels les plus courants dans la
littérature.
Conceptuellement, les cubes de données sont transformés en fonction de faits et de dimensions
[Kimball et Ross, 2008] :
▪ Fait : Il s'agit du concept clé sur lequel repose le processus décisionnel, il représente
le sujet ou sujet analysé et est associé à des valeurs appelées métriques.
▪ Dimensions : Ce sont les données de paramètres utilisées pour analyser l’activité de
prise de décision. Les dimensions peuvent être organisées dans une structure
hiérarchique, qui signifie divisée en plusieurs niveaux. Le niveau de dimension
représente la granularité ou le niveau de détail des mesures agrégées pour chaque
dimension. Cette dimension a également des attributs pour décrire ses instances
(membres).
▪ Dimension conforme : Lorsque plusieurs données sont utilisées par des faits dans
plusieurs magasins de données, nous appelons cela une dimension de conformité ou
partagée. Ses avantages sont : Cohérence entre différentes tables de faits, intégration
ce qui permet à l'entrepôt de données de fonctionner comme un seul bloc unifié, et
productivité en facilitant l'expansion de l'entrepôt d'une itération de développement
à une autre.

▪ Hiérarchie : Les attributs de la dimension sont organisés dans une structure


hiérarchique. Chaque membre (attribut) appartient à un niveau hiérarchique
spécifique. Exemples de dimensions temporelles : jour, mois, trimestre [Bédard et
Rivest, 2001].
▪ Mesure : Dans [Bédard et Rivest, 2001], l'auteur définit une mesure comme « des
éléments de données analysés selon différentes dimensions ».
▪ Granularité : La granularité désigne le niveau de détail des données au niveau de la
table des faits
2.4.3.1.1 Schémas de modélisation multidimensionnelle
Nous présentons dans ce qui suit les différents schémas de modélisation
multidimensionnel du niveau conceptuel :

19
Le schéma en étoile : Chaque dimension est représentée par une table de dimension et les
mesures sont représentées par une table de faits, et la table de faits utilise une clé étrangère
pour faire référence à chaque table de dimension.

Figure 5 : exemple d'un schéma en étoile [Corr et Stagnitto 2013]


Le schéma en flocon de neige : C'est une extension du motif en étoile. Le diagramme en
flocon de neige est le résultat de la décomposition d'une ou plusieurs dimensions en plusieurs
niveaux pour former une structure hiérarchique. Et donc, la table de dimension est divisée en
plusieurs tables.

Figure 6 : exemple d'un schéma en flocon de neige [Corr et Stagnitto 2013]


Le schéma en constellation : Il s'agit d'une solution dans laquelle plusieurs modèles de
tailles partagent la même taille. Les tables de dimension partagées par plusieurs tables de faits
doivent être identiques.

20
Figure 7 : exemple d'un schéma en constellation [Corr et Stagnitto 2013]
2.4.3.2 Niveau logique
Cette description de la fondation multidimensionnelle considère les aspects techniques de la
modélisation. Il existe trois modèles principaux : R-OLAP, M-OLAP et H-OLAP. Avant
d'introduire ces modèles, nous définissons d'abord le concept d'OLAP.
▪ OLAP
Kimball définit OLAP comme « une activité globale pour interroger et présenter du texte et
des données numériques contenues dans un entrepôt de données, en particulier le
questionnement dimensionnel et le style de présentation» [Kimball, 2011]
▪ R-OLAP
Les développeurs d'entrepôts de données utilisent le plus souvent ce type de système. [Khouri,
2008] a déclaré : « Le système ROLAP (Relational Online Analytical Processing) utilise un
SGBD relationnel pour stocker les données du cube. Chaque dimension du cube est figurée
sous la forme d'une table appelée table de dimension. Chaque fait est figuré par une table de
faits. Les mesures sont mémorisées dans la table de faits. La table contient la valeur de la
mesure ainsi que la clé de la table de dimension »
▪ M-OLAP
Le système d'analyse et de traitement multidimensionnel en ligne (MOLAP) met en œuvre des
ensembles de données multidimensionnelles sous la forme de tableaux multidimensionnels
(SGBD multidimensionnel). Chaque dimension du tableau multidimensionnel figure une
dimension du cube. La mesure référence les informations mémorisées dans chaque cellule du
cube. Cette solution de mémorisation assure un temps de réponse très minime" [Khouri, 2008].
▪ H-OLAP
Ce système utilise le système R-OLAP et M-OLAP pour définir un nouveau modèle en
profitant des avantages des deux.
[Khouri, 2008] le présente ainsi : « Le système HOLAP (Hybrid Online Analytical Processing)
est un modèle qui préserve les données couramment dans un SGBD multidimensionnel,
[Khouri, 2008]
Comparaison des modèles
Ce tableau met en évidence les avantages et les inconvénients de chaque modèle. Ce tableau
comparatif est tiré du travail de [Khouri, 2008].

21
Modèle Avantages Inconvénients

1. Enregistrement de données
massives. Coûteux en termes de
2. Exploitation des capacités performance
R-OLAP
analytiques d’un SGBD
relationnel

1. Redondance des
données
M-OLAP Temps d'accès très court
2. Consommation de
l’espace

H-OLAP Accès Rapide aux Impossible si le cas est


données Complexe

Tableau 3 : comparaison entre les modèles multidimensionnels [Khouri, 2008]

2.5 Types De Solutions Business Intelligence


Les solutions Business Intelligence peuvent être groupées en deux grandes catégories
et qui sont :
2.5.1 Business intelligence traditionnelle
Les solutions BI traditionnelles sont puissantes et soutenues par des éditeurs de logiciels bien
établis.
Les plus grands leaders du secteur sont : SAP Business Objects / Crystal Reports, IBM Cognos,
Oracle BI et Qlikview [Alain Fernandez , 2013].
2.5.1.1 Caractéristiques fondamentales de la BI traditionnelle
Conçu pour servir même le plus grand environnement. Il a la capacité d'évoluer pour
gérer une quantité massive de données et servir le plus grand nombre d'utilisateurs [Alain
Fernandez , 2013] . Ses plus grandes caractéristiques sont :
1. Offre un grand nombre de fonctionnalités qui permet aux entreprises de
couvrir plusieurs types de rapports et un éventail de cas d'utilisation.
2. Nécessite un haut niveau d'expertise technique, les utilisateurs comptent
beaucoup sur l'informatique pour exécuter les fonctions les plus élémentaires
telles que la création de rapports. Par conséquent, les taux d'adoption par les
utilisateurs peuvent en souffrir.
3. Coût assez grand pour la majorité des petites et moyennes entreprises, ainsi
que pour de nombreuses grandes organisations.
4. Le service informatique doit avoir des compétences en requêtes SQL ou
apprendre un langage de requête propriétaire afin de l'implémenter, ce qui
augmente les coûts et augmente le temps requis pour déployer la solution.
22
2.5.2 Self-Service BI
Les solutions de BI Agile, aussi appelées solutions de BI axées sur les utilisateurs métier
(Self-Service BI en Anglais ), ont tendance à être des produits de nouvelles entreprises qui
tirent parti de bon nombre d’atouts de la technologie Web.
Comme leur nom l'indique, les solutions agiles sont conçues pour s'adapter rapidement aux
besoins changeants de l'entreprise. L'un des objectifs d'Agile BI est de fournir aux utilisateurs
les données dont ils ont besoin pour prendre rapidement des décisions commerciales éclairées.
[Josh Parenteau , 2017]
Des exemples de solutions agiles incluent Yurbi, Tableau, Sisense et Power BI de Microsoft.
2.5.2.1 Caractéristiques fondamentales d’un Self-Service BI
Ses plus grandes caractéristiques sont [Alain Fernandez , 2013]:
1. Les utilisateurs professionnels ont la possibilité d’accéder aux données en
temps réel et de générer vite des résultats sans nécessité de posséder une
expertise technique. Souvent, aucune compétence en codage n'est requise.
2. Les coûts initiaux, le coût total de possession (TCO) et le coût total du
changement (TCC) de la BI Agile sont inférieurs aux coûts de la BI
traditionnelle.
3. En comparaison avec la BI traditionnelle, la BI Agile fournit un cycle de
développement plus court qui utilise moins de ressources informatiques et est
plus rapide à fournir.
4. L'adoption par les utilisateurs est généralement plus grande avec la BI Agile
qu'avec la BI traditionnelle, car elle est plus facile à comprendre et à exploiter
pour l'utilisateur métier non technique.
2.5.3 Comparaison

Self-Service Business Intelligence Traditional BI

Expertise Les utilisateurs n’ont pas besoin d’être bon en Les utilisateurs doivent avoir un
technique informatique pour générer des rapports et background technique pour
tableau de bord qui peuvent être publié vers un pouvoir générer les rapports
portail web
Les coûts initiaux, le coût total de possession (TCO) et le coût total du changement
(TCC) de la BI Agile sont nettement inférieurs aux coûts de la BI traditionnelle car
Coûts le cycle de développement est plus long et coûteux en termes de ressources humaines
et matérielles.

Temps de Par rapport à la BI traditionnelle, la BI Agile offre un cycle de développement plus


réalisation court qui utilise moins de ressources informatiques et est plus rapide à fournir

Outils La majorité des outils Self-services BI ne sont Majorité des outils sont Open
pas gratuits Source

Tableau 4 : comparaison entre le BI self-service et le BI traditionnel [Rupal


Bhandari, 2020]
23
2.6 Tendances Du Décisionnel A L’ère Du BIG DATA
Depuis le début du 21ème siècle, les données des entreprises sont devenues massives
et volumineuses, de ce fait l’exploitation et l’interprétation de ces données à travers des
rapports est devenue difficile, le concept du big data est apparu justement pour la meilleure
extraction de l’information en temps optimale. [ZHAOHAO, HUASHENG, 2015]
Dans ce qui suit nous présentons les nouvelles tendances de la technologie des traitements de
données :
2.6.1 BIG DATA
Le big data fait référence à des ensembles de données devenus si volumineux qu'ils
dépassent les capacités analytiques des gens et soulèvent des questions sur les capacités des
outils informatiques traditionnels. Ces données peuvent être de nature personnelle,
professionnelle ou institutionnelle et peuvent provenir de différentes sources.
Les données massives ou “Big Data” est un terme relativement nouveau. Il ne se réfère pas
seulement aux données, mais fait également référence à l'analyse et l’utilisation de ces
dernières.
Dans son rapport [James Manyika et al., 2011], McKinsey Global Institute définit le Big Data
comme : “des ensembles de données dont la taille dépasse la capacité des outils informatiques
classiques à capturer, stocker, gérer et analyser les données"
Le Big Data remplit les trois conditions suivantes : volume, variété et vélocité. Plusieurs
entreprises ont ajouté le quatrième V et les interprètent différemment.
Gartner appelle cela la virtualité pour inclure la visualisation dans le Big Data. IBM appelle
cela véracité et qui est la capacité d'identifier l'exactitude de diverses données. Enfin, Oracle a
désigné le quatrième comme la valeur pour identifier le défi de transformer le big data en valeur
économique [Kulin et al., 2015].
2.6.1.1 Volume
Il ne fait aucun doute que les organisations d'aujourd'hui connaissent une expansion de
données très volumineuses. Il est difficile de savoir combien de données sont disponibles et
encore moins estimer la quantité de données disponible dans 4 ans.
En 2012, 2.5 Eo de données ont été créées chaque jour, soit l'équivalent d'une bibliothèque de
25 millions de revues académiques. Bien entendu, toutes ces données ne sont pas utiles à
l'entreprise, mais l'entreprise doit être consciente de l'énorme potentiel dans ce domaine.
Fondamentalement, le Big Data peut-être diviser en deux parties : l'océan de données et le flux
de données. L'océan de données fait référence à une grande quantité de données qui sont
stockées puis analysées. Cependant, les flux de données tels que les réseaux sociaux, les flux
de clics, les données de capteurs et les e-mails ne sont pas toujours stockés. Ces flux peuvent
être analysés en temps réel, puis les données peuvent être ignorées. Même si le nombre est
énorme, nous n'avons pas à tout stocker [Kulin et al., 2015]
2.6.1.2 Variété
L'une des caractéristiques du big data est qu'il absorbe des données structurées, semi-
structurées et non structurées. La multiplicité des formats ne constitue pas un obstacle à une
gestion efficace des données. Le Big Data recouvre plusieurs formes telles que : mises à jour

24
de profils personnels, opinions sur les forums en ligne, tout le contenu des réseaux sociaux,
blogs, tweets, etc. En plus des types de données standard, tous peuvent être inclus dans le Big
Data [Kulin et al., 2015]
2.6.1.3 Vélocité
Pour de nombreuses applications, la vitesse domine le volume. Il est très important
d'avoir des informations en temps réel afin de pouvoir prendre des décisions plus précises et
flexibles. Le streaming de données signifie que les données se déplacent à grande vitesse et en
temps réel. L'enjeu est de récupérer les données en temps réel et de les optimiser jusqu'à
l'extraction des connaissances. Plus les données arrivent rapidement, plus la réponse à la
demande est rapide [Kulin et al., 2015]
2.6.2 Data Mining
L'exploration de données et la BI peuvent sembler différentes mais il y a beaucoup de
chevauchements à la fois dans les résultats et dans la manière dont elles peuvent contribuer au
succès des entreprises. L'exploration de données fait partie intégrante de l'intelligence d'affaires
lorsqu'il s'agit de nettoyer, normaliser et utiliser les données d'entreprise. Cela contribue
également à la capacité d’utiliser ces données pour faire des prédictions précises et fiables qui
peuvent permettre d'opérer à un niveau plus élevé que de simplement se fier aux données
historiques dont l’entreprise dispose et de deviner les résultats futurs.
Les entreprises peuvent utiliser l'exploration de données pour trouver les informations dont
elles ont besoin et utiliser l'intelligence d'affaires et l'analyse pour déterminer pourquoi elles
sont importantes [Parth Wazurkar et al, 2017].
2.6.3 L’intelligence Artificielle
Les applications de Business Intelligence ont été un formidable atout pour les
organisations, leur permettant de mieux comprendre le Big Data. Cependant, les temps
changent et les besoins des organisations évoluent. Ils ont non seulement besoin d'un logiciel
de renseignement capable de traiter et de présenter des données sous forme de résultats visuels,
mais ils ont également besoin d'un logiciel capable de prédire les tendances, d'anticiper des
informations exploitables en temps réel et de traiter une variété de données. C'est là que
l'intelligence artificielle entre en jeu, car l'intelligence artificielle permet aux organisations de
décomposer le Big Data en niveaux granulaires, ce qui permet aux organisations de prendre
plus facilement des décisions plus intelligentes [Parth Wazurkar et al, 2017].
2.6.4 Data Lake
Un Data Lake est un référentiel de données permettant de stocker une très large quantité
de données brutes dans le format natif pour une durée indéterminée. Cette méthode de stockage
permet de faciliter la cohabitation entre les différents schémas et formes structurelles de
données, généralement des blocs d’objets ou des fichiers. Il offre une grande quantité de
données pour augmenter les performances analytiques et l'intégration native.
[MILOSLAVSKAYA, 2016].
Un Data Lake est comme un grand conteneur qui ressemble beaucoup à de vrais lacs et rivières
et c’est d’ici que vient l'appellation “Lac de données “. Tout comme dans un lac, vous avez
plusieurs affluents qui arrivent, un lac de données contient des données structurées, des données
non structurées, de machine à machine, des journaux qui circulent en temps réel.
Au sein d’un seul Data Lake, toutes les données de l’entreprise sont stockées. Les données
brutes, y compris les copies des données système source, côtoient les données transformées.

25
Ces données sont ensuite utilisées pour établir des rapports, pour visualiser les données, pour
l’analyse de données ou pour le Machine Learning. [MILOSLAVSKAYA, 2016].
Cette technologie qu’est les lacs de données est essentiellement basée sur le NoSQL.
2.6.5 Les principales différences entre Data Lake et un Data Warehouse en
environnement BI
Le tableau ci-dessous présente une comparaison entre le lac de données et l'entrepôt de
données [ALEX GORELIK , 2019] :
Data Lake Data Warehouse

Dans le lac de données, toutes les Un entrepôt de données sera composé


données sont conservées de données extraites de systèmes
indépendamment de la source et de sa transactionnels ou de données
structure. Les données sont conservées constituées de mesures quantitatives
sous leur forme brute. Il n'est transformé avec leurs attributs. Les données sont
Stockage
que lorsqu'il est prêt à être utilisé. nettoyées et transformées

Les lac de données utilisent de nouvelles Le concept d'entrepôt de données,


Historique technologies du monde du Big Data contrairement au big data, était utilisé
(Hadoop , Map reduce..etc) depuis des décennies.
Capture toutes sortes de données Capture des informations structurées et
Type de structurées, semi-structurées et non les organise dans des schémas tels que
données structurées dans leur forme originale à définis à des fins d'entrepôt de données
partir de systèmes source.
Les lacs de données peuvent conserver Dans le processus de développement
toutes les données. Cela comprend non de l'entrepôt de données, un temps
Chronologie seulement les données en cours considérable est consacré à l'analyse de
des données d'utilisation, mais également les données diverses sources de données.
qu'il pourrait utiliser à l'avenir. De plus,
les données sont conservées pour
toujours, pour remonter le temps et faire
une analyse.
Data Lake est idéal pour les utilisateurs L'entrepôt de données est idéal pour les
qui se livrent à une analyse approfondie. utilisateurs opérationnels car il est bien
Ces utilisateurs comprennent des structuré, facile à utiliser et à
Utilisateurs spécialistes des données qui ont besoin comprendre.
d'outils analytiques avancés dotés de
capacités telles que la modélisation
prédictive et l'analyse statistique.
Le stockage des données dans les Le stockage des données dans
Coûts de technologies de Big Data est l'entrepôt de données est plus coûteux
stockage relativement peu coûteux que le et prend du temps.
stockage des données dans un entrepôt
de données.
Les ingénieurs de données utilisent des Les entrepôts de données sont
lacs de données pour stocker les données généralement définis en lecture seule
entrantes. Cependant, les lacs de pour les utilisateurs analystes, qui
données ne se limitent pas au stockage. lisent et regroupent principalement des
Les données non structurées sont plus données pour obtenir des informations.
flexibles et évolutives, ce qui est souvent Étant donné que les données sont déjà
26
mieux pour l'analyse de Big Data. propres et archivées, il n'est
L'analyse de Big Data peut être exécutée généralement pas nécessaire d'insérer
Tâches sur des lacs de données à l'aide de ou de mettre à jour les données.
services tels qu'Apache Spark et
Hadoop. Cela est particulièrement vrai
pour l'apprentissage en profondeur, qui
nécessite une évolutivité dans la quantité
croissante de données d'entraînement.
Les lacs de données permettent aux Les entrepôts de données offrent un
utilisateurs d'accéder aux données avant aperçu des questions prédéfinies pour
qu'elles ne soient transformées, des types de données prédéfinis. Ainsi,
Temps de nettoyées et structurées. Ainsi, il permet toute modification de l'entrepôt de
aux utilisateurs d'accéder à leur résultat données nécessitait plus de temps.
traitement
plus rapidement que dans l'entrepôt de
données traditionnel.

En règle générale, le schéma est défini En général, le schéma est défini avant
après le stockage des données. Cela offre le stockage des données. Nécessite du
une grande agilité et une facilité de travail au début du processus, mais
Position du capture des données, mais nécessite un offre des performances, une sécurité et
schéma travail à la fin du processus. une intégration.

Traitement Processus ELT Processus ETL


de
l'information
Les données sont conservées sous leur La principale plainte contre les
forme brute. Il n'est transformé que entrepôts de données est l'incapacité ou
Plainte lorsqu'il est prêt à être utilisé. le problème rencontré lorsque l'on tente
d'y apporter des modifications
Ils intègrent différents types de données La plupart des utilisateurs d'une
pour poser des questions entièrement organisation sont opérationnels. Ces
Avantages nouvelles, car ces utilisateurs ne sont pas types d'utilisateurs ne se soucient que
clés susceptibles d'utiliser des entrepôts de des rapports et des indicateurs de
données car ils peuvent avoir besoin performances clés.
d'aller au-delà de leurs capacités.
Tableau 5 : comparaison entre les structures lac de données et entrepôt de données
[ALEX GORELIK , 2019]

2.6.6 Outils du Big Data


Nous présentons dans ce qui suit les outils et technologies les plus connues et utilisées dans
le monde du Big Data :

2.6.6.1 Hadoop distributed file system


2.6.6.1.1 Définition
Hadoop Distributed File System ou HDFS est un système de fichiers distribué conçu
pour fonctionner sur du matériel à faible coût. Il présente de nombreuses similitudes avec les
systèmes de fichiers distribués existants. Cependant, HDFS est hautement tolérant aux pannes,
il fournit un accès à haut débit aux données d'application et convient aux applications qui ont
de grands ensembles de données. [Dhruba Borthakur , 2007]

27
2.6.6.1.2 Architecture HDFS
Le système de fichier distribué de Hadoop, Alias HDFS, a une architecture maître /
esclave. Un cluster HDFS se compose d'un seul NameNode, un serveur maître qui gère l'espace
de noms du système de fichiers et régule l'accès aux fichiers par les clients. En outre, il existe
un certain nombre de DataNodes, généralement un par nœud dans le cluster, qui gèrent le
stockage attaché aux nœuds sur lesquels ils s'exécutent. HDFS expose un espace de noms de
système de fichiers et permet aux données utilisateur d'être stockées dans des fichiers. En
interne, un fichier est divisé en un ou plusieurs blocs et ces blocs sont stockés dans un ensemble
de DataNodes.
Le NameNode exécute les opérations d'espace de noms du système de fichiers telles que
l'ouverture, la fermeture et le changement de nom des fichiers et des répertoires. Il détermine
également le mappage des blocs aux DataNodes. Les DataNodes sont chargés de traiter les
demandes de lecture et d’écriture des clients du système de fichiers. Les DataNodes effectuent
également la création, la suppression et la réplication de blocs sur instruction du NameNode.
[Dhruba Borthakur, 2007]. La figure ci-dessous montre l’architecture de HDFS [Dhruba
Borthakur, 2007] :

Figure 8 : architecture de HDFS [Dhruba Borthakur, 2007]

2.6.7 MAPREDUCE
2.6.7.1 Définition
MapReduce est un framework logiciel et un modèle de programmation utilisé pour
traiter le big data.
Le programme MapReduce fonctionne en deux phases, à savoir, Map et Reduce. Les tâches de
mappage traitent du fractionnement et du mappage des données tandis que la réduction des
tâches mélange et réduit les données, Hadoop est capable d'exécuter des programmes
MapReduce en multi-langage.

28
Les programmes de MapReduce dans le Cloud Computing sont de nature parallèle, ils sont
donc très utiles pour effectuer une analyse de données à grande échelle en utilisant plusieurs
machines dans le cluster, grâce à HDFS. [J. Dean, et al., 2008]
2.6.7.2 Fonctionnement de MapReduce
Nous présentons ci-dessous selon [Johannes Passing, 2012] les étapes d'exécution d’un job
MapReduce :
1. Une tâche Map est créée pour chaque division, qui exécute ensuite la fonction
Map pour chaque enregistrement de la division.
2. Il est toujours avantageux d'avoir plusieurs fractionnements car le temps
nécessaire pour traiter un fractionnement est petit par rapport au temps
nécessaire pour le traitement de l'ensemble de l'entrée. Lorsque les
fractionnements sont plus petits, il est préférable que le traitement soit
équilibré car nous traitons les fractionnements en parallèle.
3. Cependant, il n'est pas non plus souhaitable d'avoir des fentes de trop petite
taille. Lorsque les fractionnements sont trop petits, la surcharge liée à la
gestion des fractionnements et à la création de tâches de mappage commence
à dominer le temps total d'exécution du travail.
4. Pour la plupart des travaux, il est préférable de créer une taille de division
égale à la taille d'un bloc HDFS (qui est de 64 Mo, par défaut).
5. L'exécution des tâches de mappage entraîne l'écriture de la sortie sur un
disque local sur le nœud respectif et non sur HDFS.
6. La raison du choix du disque local sur HDFS est d'éviter la réplication qui a
lieu en cas d’opération Store de HDFS.
7. La sortie de la carte est une sortie intermédiaire qui est traitée par des taches
de réduction pour produire la sortie finale.
8. Une fois le travail terminé, la sortie de la carte peut être supprimée. Ainsi, le
stocker dans HDFS avec réplication devient excessif.
9. En cas de défaillance d'un nœud, avant que la sortie du Map ne soit
consommée par la tâche de réduction, Hadoop ré exécute la tâche du Map sur
un autre nœud et recrée la sortie du Map.
10. Réduire la tâche ne fonctionne pas sur le concept de localité des données. Une
sortie de chaque tâche de carte est transmise à la tâche de réduction. La sortie
du Map est transférée vers la machine sur laquelle la tâche de réduction est
en cours d'exécution.
11. Sur cette machine, la sortie est fusionnée puis transmise à la fonction de
réduction définie par l'utilisateur.
12. Contrairement à la sortie du Map , la sortie de réduction est stockée dans
HDFS (la première réplique est stockée sur le nœud local et les autres
répliques sont stockées sur des nœuds hors rack). Donc, écrire la sortie de
réduction.

29
2.6.8 Spark Apache Processing Engine
2.6.8.1 Définition
Apache Spark est un environnement de traitement parallèle open source pour exécuter
des applications d'analyse de données à grande échelle sur des ordinateurs en cluster. Il peut
gérer à la fois des analyses par lots et en temps réel et des charges de travail de traitement de
données.
Spark Core, le cœur de l’environnement qui fournit des fonctionnalités de transmission, de
planification et d'E / S de tâches distribuées, offre aux programmeurs une alternative
potentiellement plus rapide et plus flexible à MapReduce, le framework logiciel auquel les
premières versions de Hadoop étaient liées. Les développeurs de Spark affirment qu'il peut
exécuter des travaux 100 fois plus rapidement que MapReduce lorsqu'ils sont traités In Memory
et 10 fois plus rapidement sur disque [James G. Shanahan, et al. 2015]
2.6.8.2 Fonctionnement
Selon [James G. Shanahan, et al. 2015], Apache Spark peut traiter les données de
divers repository de données, y compris le système de fichiers distribués Hadoop (HDFS), les
bases de données NoSQL et les data stores relationnelles, tels qu'Apache Hive.
Spark prend en charge le traitement IN Memory pour améliorer les performances des
applications d'analyse Big Data, mais il peut également effectuer un traitement conventionnel
sur disque lorsque les ensembles de données sont trop volumineux pour tenir dans la mémoire
système disponible.
Le moteur Spark Core utilise l'ensemble de données distribué résilient, ou RDD, comme type
de données de base. Le RDD est conçu de manière à cacher une grande partie de la complexité
de calcul aux utilisateurs. Il agrège les données et les partitionne sur un cluster de serveurs, où
elles peuvent ensuite être calculées et déplacées vers un autre magasin de données ou exécutées
via un modèle analytique. L'utilisateur n'a pas à définir où les fichiers spécifiques sont envoyés
ou quelles ressources de calcul sont utilisées pour stocker ou récupérer des fichiers. Spark se
compose de 4 bibliothèques essentielles qui sont :
1. SparkSQL : pour interroger l’ensemble des données à travers des requêtes.
2. Spark streaming : qui permet de faire une analyse de données en temps réel,
3. MLLib : une librairie qui permet de concevoir des modèles de machine
Learning,
4. GraphX : qui contient un ensemble d’algorithmes du parallèle graph
computing.
2.6.9 Combinaison Entrepôt ET Lac De Données : Le Data Lakehouse
Un data lakehouse est un nouveau paradigme de gestion des données ouvertes conçu
par DATABRICKS qui combine les capacités des lacs de données et des entrepôts de données,
permettant la BI et les algorithmes de machine Learning sur toutes les données.
Les entrepôts de données ont une longue histoire dans les applications d'aide à la décision et
de business intelligence, mais n'étaient pas adaptés ou étaient coûteux pour traiter des données
non structurées, des données semi-structurées et des données avec une grande variété, vitesse
et volume.
Les lacs de données ont ensuite émergé pour gérer les données brutes dans une variété
de formats sur un stockage bon marché pour la science des données et l'apprentissage
30
automatique, bien qu'ils manquaient de fonctionnalités critiques du monde des entrepôts de
données: ils ne prennent pas en charge les transactions, ils n'appliquent pas la qualité des
données et leur manque de cohérence / isolation, il est presque impossible de mélanger des
ajouts et des lectures, et des travaux par lots et en continu.
Les équipes de données assemblent par conséquent ces systèmes pour permettre la BI et le ML
sur les données de ces deux systèmes, ce qui entraîne des données en double, des coûts
d'infrastructure supplémentaires et des problèmes de sécurité.
Les data lakehouses sont activés par une nouvelle conception de système ouvert :
implémentation de structures de données et de fonctionnalités de gestion de données similaires
à celles d'un entrepôt de données, directement sur le type de stockage à faible coût utilisé par
les data Lake. Les fusionner en un seul système signifie que les équipes de données peuvent se
déplacer plus rapidement car elles peuvent utiliser les données sans avoir besoin d'accéder à
plusieurs systèmes. Les data lakehouses garantissent également que les équipes disposent des
données les plus complètes et les plus à jour disponibles pour les projets de science des
données, d'apprentissage automatique et d'analyse commerciale [Michael Armbrust et al.
,2021]
2.6.10 Architecture D’un Data Lakehouse
Un data lake house est un paradigme qui combine le meilleur des deux mondes : le
monde des entrepôts de données et celui des lacs de données.
Son architecture repose sur le Stockage singulier (Single Store) de toutes les données dans un
système consolidée tout en permettant le streaming, la business intelligence , data science et le
machine Learning.
Plus en détails, l’architecture d’un data lakehouse selon son concepteur DATABRICKS
comprend plusieurs couches [Michael Armbrust , et al. ,2021], et qui sont :
1. Lac de donnée :
L’architecture de stockage d’un data lakehouse repose sur l’architecture d’un lac de
donnée qui stocke toutes les données de l’entreprise (donnée structurée, non structurée et semi
structurée).
2. Delta Lake :
Delta Lake est une solution proposée en open source par Databricks. Il s’agit d’un outil
permettant de rendre les données des Data Lakes plus fiables grâce à une épaisseur de stockage
supplémentaire.
Delta Lake est une couche de stockage ajoutée par-dessus le Data Lake afin d’offrir des sources
de données fiables pour le Machine Learning et la science des données et la Business
Intelligence. L’outil passe en revue toutes les données entrantes, et s’assure qu’elles
correspondent au schéma mis en place par l’utilisateur. Ceci permet de s’assurer que les
données soient fiables et correctes. Une transaction ACID est ajoutée à chaque opération
effectuée, afin de s’assurer que les opérations soient toujours correctes. Ainsi, il n’est plus
possible d’être confronté à une erreur ou à des données incomplètes. Ses principales missions
sont d’ajouter des transactions, réguler la qualité des données ainsi que ses versions, ajouter
des indexes et convertir les données brutes stockées dans le data lake vers le format Delta Lake.
3. Delta Engine :

31
C’est un moteur à haute performance qui a pour but de servir les requêtes analytiques
ainsi que les besoins en termes de machine learning du data lake house, Databricks a très
récemment introduit Delta Engine qui englobe les capacite du serveur BIG DATA Spark tout
en offrant un moteur de requêtes à haute performance pour une variété de besoins.
Ce moteur inclut un optimiseur de requêtes et un moteur d’exécution de requêtes vectorisées
pour accélérer le data workload.
Le schéma ci-dessous illustre l’architecture d’un data lakehouse selon DATABRICKS [Ali
Ghodsi et al, 2021] :

Figure SEQ Figure \* ARABIC 9 : Architecture d’un lakehouse selon Data Bricks
Figure 9: architecture de la solution lakehouse par databricks [Ali Ghodsi et al. ,
2021]

2.6.11 Avantages et inconvénients d’utilisation du Data Lakehouse


Les entrepôts de données et les lacs de données sont tous deux extrêmement populaires.
Les deux existent côte à côte dans de nombreuses entreprises, qui ressentent un besoin en
termes de Business Intelligence et Machine learning, en remplissant leur mission parfaitement.
Cependant, Selon Dave Wells l’utilisation du paradigme du data lake house permettrait
d’améliorer les lacunes du système actuel, et présenterait de majeurs avantages tels que [Dave
Wells , 2021]:
1. Plus de duplication de données :

32
Posséder les mêmes données dans le data warehouse et le data lake créerait une redondance et
donc une inefficacité ou même des conflits .Un data lake house unifie toutes les données dans
un seul support.
2. Coûts de stockage réduit :
Le coût de stockage dans un lakehouse est équivalent à celui du stockage dans un data
lake, ce dernier utilise des systèmes de fichiers Big Data tels que Hadoop pour stocker des
données sur du matériel bon marché.
3. Coordination entre équipe BI et analytique :
Les analystes métier utilisent des sources de données intégrées comme un entrepôt ou
un data mart. Les data scientists travaillent avec les lacs, en utilisant des techniques d'analyse
pour parcourir les données non triées. Les deux équipes n'ont pas lieu d'interagir et leur travail
se chevauche souvent, voire se contredit. Avec un data lake house, les deux équipes travaillent
à partir du même référentiel.
4. Bon maintien des données :
la stagnation est un problème majeur dans les lacs de données, qui peuvent rapidement
devenir des marécages de données s'ils ne sont pas entretenus. Les entreprises déversent
souvent leurs données dans un lac sans les cataloguer correctement, ce qui rend difficile de
savoir si les données ont expiré. La structure lakehouse apporte une plus grande organisation
au Big Data et aide à identifier les données excédentaires par rapport aux besoins.
5. Support extensible et maintenable pour le futur :
L'analyse des données est encore une technologie émergente, avec de nouveaux outils
et techniques émergent chaque année. Certains d'entre eux peuvent uniquement être
compatibles avec les lacs de données, tandis que d'autres peuvent uniquement fonctionner avec
des entrepôts. La structure flexible du Lakehouse signifie que les entreprises peuvent se
préparer pour l'avenir de toute façon.
Ce paradigme bien qu’il présente de nombreux points positifs possède son petit côté
obscur, et qui s’illustre principalement dans [Dave Wells, 2021] :
1. Difficile de gérer la structure Monolithe :
L'approche tout-en-un d'un lakehouse présente certains avantages, mais elle pose également
certains problèmes. Les structures monolithiques peuvent être rigides, difficiles à entretenir et
parfois elles peuvent entraîner un service médiocre pour tous les utilisateurs. Les architectes et
les concepteurs préfèrent généralement une approche plus modulaire qu'ils peuvent configurer
pour différents cas d'utilisation.
2. La technologie absente :
La vision ultime implique beaucoup d'apprentissage automatique et d'intelligence
artificielle. Ces technologies devront évoluer davantage avant que les lakehouse n'atteignent
les capacités proposées.

33
3 Conclusion
A travers cette étude documentaire, nous avons parcouru les concepts de base liés à notre
projet.
Nous avons commencé par présenter le métier sur lequel nous travaillons, et qui est la fonction
ressources humaines que nous avons définie, évoqué son historique, les processus métiers qui
la composent ainsi que son importance pour les entreprises d’aujourd’hui, et nous avons
finalisé par une présentation des diverses solutions informatiques qui traitent ce domaine
d’étude.
Nous avons par la suite entamé la deuxième partie de notre recherche bibliographique, et qui
se focalise sur les systèmes décisionnels que nous avons commencé par définir ainsi que tous
les concepts de base en relation avec ces derniers, nous sommes passés ensuite à la description
de l’architecture techniques ainsi qu’au objectifs de ces systèmes , nous avons par la suite
présenter les différents types de systèmes décisionnelles en exposant un comparatif détaillées
de ces derniers avant de finaliser cette partie par une présentation des nouvelles tendances
technologiques dans ce domaine en mettant l’accent sur les nouveaux outils et concepts utilisés
de nos jours.
Aussi et à travers cette étude, nous avons compris que la BI est adaptée aux données structurées
de l’entreprise et que son rôle principal est de répondre à des requetés d’analyse descriptive.
Ces défis associés à la BI classique ont conduit à rechercher des solutions modernes, flexibles
et tournées vers l’avenir, d’où, l’´émergence de la BI moderne.
Les systèmes de Business Intelligence classiques ne répondent malheureusement plus
complètement aux exigences en termes de performance et ceci à cause de la grosse quantité de
données à manipuler, et c’est de là qu’est venu le besoin d’utiliser l’avancée technologique de
la Big Data avec la Business Intelligence , beaucoup de progrès ont été fait dans le monde de
l’intégration des systèmes d’aide a la décision au Big Data , c’est devenu un domaine mature
que de plus en plus d’entreprises adoptent.
Et c’est d’ailleurs l’approche que nous allons adopter pour répondre à la problématique posée
dans ce stage de fin d’étude.

34
Deuxième Partie

II. Analyse des besoins et étude de


l’existant

35
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

Chapitre 1
Présentation de l’organisme d’accueil
1.1 Introduction
Dans ce chapitre, nous présentons le groupe SONELGAZ, son historique, son
organisation, ses activités et ses missions. Nous abordons également la filiale informatique
ELIT, celle qui a encadré le projet tout en mettant l’accent sur le département Intégration et
Maintenance des SI qui nous a accueillis.

1.2 Présentation de SONELGAZ


SONELGAZ, ou Société nationale de l’électricité et du gaz, est le groupe leader de la
production, du transport et de la distribution de l’électricité et du gaz en Algérie.
Née en 1947 sous le nom ‘Électricité et gaz d’Algérie (EGA) et rebaptisée Sonelgaz en 1969,
on lui a donné le monopole de la distribution et de la vente du gaz naturel dans notre pays.
Grâce à sa ressource humaine formée et qualifiée, le Groupe occupe une position privilégiée
dans l’économie du pays en tant que responsable de l’approvisionnement de plus de six millions
de ménages en électricité et de trois millions en gaz naturel, soit une couverture géographique
de près de 99% en taux d’électrification et 52% pour la pénétration gaz.
SONELGAZ vit, depuis quelques années, une phase particulièrement importante de son
histoire. Désormais, la restructuration de Sonelgaz, suite à l’avènement de la loi N◦01.02 du 05
février 2002, s’est achevée avec la création de l’ensemble des filiales.
1.2.1 Historique
SONELGAZ est l’opérateur historique dans le domaine de la fourniture des énergies
électrique et gazière en Algérie. Ses missions principales sont la production, le transport et la
distribution de l’électricité ainsi que le transport et la distribution du gaz par canalisations. Son
nouveau statut lui confère la possibilité d’intervenir dans d’autres segments d’activités
présentant un intérêt pour l’entreprise et notamment dans le domaine de la commercialisation
de l’électricité et du gaz à l’étranger. Durant son existence le groupe a connu des évolutions
majeures qui peuvent être résumées comme suit :
1947, Création d’EGA : C’est le décret du 5 juin 1947 qui a créé l'Établissement Public
National “Electricité et Gaz d'Algérie” (EGA par abréviation). Par décret du 16 août 1947,
seize sociétés qui se partageaient les concessions électriques ont été transférées à EGA. Ces
sociétés détenaient alors 90% des propriétés industrielles électriques et gazières du pays.
1962, Le défi de la relève : Cette année représente la prise en main de l’Algérie
indépendante de la SONELGAZ –alors Electricité et Gaz d’Algérie – et cela en faisant face au
départ massif de cadres et techniciens français.
Période allant de 1962 à 1969 : Cette période a été caractérisée par la baisse de la
consommation (une baisse de près de 33% en deux ans) dû au départ massif des étrangers qui
représentaient plus de 87% de la clientèle.

36
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

1969, création de SONELGAZ : C’est l’ordonnance n° 69-59 du 28 juillet 1969 portant


dissolution de l’EGA et création de la nouvelle Société Nationale de l’Electricité et du GAZ –
SONELGAZ.
1983, naissance des entreprises travaux : six entreprises autonomes voient le jour :
1. KAHRIF pour l’électrification.
2. KAHRAKIB - Infrastructures et installations électriques.
3. KANAGAZ - Réalisation des réseaux gaz.
4. INERGA - Génie civil.
5. ETTERKIB – Montage industriel et l’entreprise AMC - Fabrication des compteurs
et appareils de mesure et de contrôle.
1991, SONELGAZ EPIC : SONELGAZ change de nature juridique et devient
Établissement Public à caractère Industriel et Commercial (EPIC) en vertu du décret exécutif
n° 91-475 du 14 décembre 1991, portant transformation de la nature juridique de la Société
Nationale de l’Electricité et du Gaz.
1998, création de filiales périphériques : Le 1er janvier 1998, neuf filiales périphériques
ont vu le jour.
Juin 2002, SONELGAZ SPA : En vertu du décret présidentiel n° 02-195 du 1er juin 2002
portant statuts de la Société algérienne de l’électricité et du gaz dénommée "SONELGAZ.
Spa", SONELGAZ est passé d'Établissement Public à caractère Industriel et Commercial à une
Société Par Actions dont le capital est détenu par l’Etat.
2004, Le groupe industriel Sonelgaz est né : En 2004 , Sonelgaz adopte une organisation
de Groupe industriel par la transformation en filiales de ses entités en charge des métiers de
base : Production d'Électricité (SPE)Transport d'Electricité (GRTE)Conduite du Système
Electrique (OS)Transport du Gaz (GRTG)Distribution de l'Electricité et du Gaz d'Alger (SDA),
du Centre (SDC), de l’Est (SDE) et enfin de l'Ouest (SDO).
2011 La Holding : Le 02 mai 2011, les statuts de Sonelgaz, adoptés en 2002, sont amendés
par le Conseil des Ministres. Ils deviennent, de ce fait, conformes aux dispositions de la loi
N°02 - 01 du 5 février 2002 relative à l'électricité et la distribution du gaz par canalisations.
Désormais, Sonelgaz. Spa est organisée en « SOCIÉTÉ HOLDING », sans création d’une
personne morale nouvelle. La Holding Sonelgaz et ses sociétés filiales forment alors un
ensemble dénommé « Groupe Sonelgaz ».

37
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

2011 La Holding
2004, Le groupe industriel
Sonelgaz
Juin 2002, SONELGAZ SPA

Création de SONELGAZ 1969

Création d’EGA 1947

Figure 10 : Historique de Sonelgaz

1.2.2 Aspect organisationnel du groupe Sonelgaz


Sonelgaz a opté pour le Holding pour mieux gérer les rôles de chaque entreprise faisant
partie de son groupe. Ces entreprises peuvent également améliorer leurs gestions en confiant
certaines de leurs activités à la société mère notamment pour ce qui est de la gestion de la
trésorerie et la gestion comptable.
1.2.2.1 Définition de la Holding
Issu du verbe anglais « to hold » qui signifie « tenir » en français, le terme holding est
utilisé pour parler d’une société qui détient directement ou indirectement des participations
dans d’autres sociétés qui lui sont soumises. Les sociétés qui sont soumises à la holding sont
ses filiales.
1.2.2.2 Organisation
Sonelgaz est aujourd’hui érigé en groupe industriel composé d’une maison mère, de 39
filiales et de 5 sociétés en participation, réparties en quatre pôles de métiers à savoir : Maison
mère, les filiales métiers de base, les filiales métiers périphériques et les filiales travaux.
Maison Mère : elle est chargée essentiellement de l’élaboration de la stratégie et du
pilotage du Groupe, le contrôle des filiales, l’élaboration et la mise en œuvre de la politique
financière et la définition de la politique de développement de la ressource humaine.
Filiales Métiers de base : Durant ces cinq dernières années, les métiers de base de
SONELGAZ ont été érigés en filiales. Au nombre de huit, ces dernières activent dans les
domaines de la production, la gestion du réseau de transport, la gestion du système production
/ transport, la distribution de l’électricité et du gaz (quatre sociétés).
Filiales Travaux : Les entreprises de réalisation érigées en entreprises autonomes à la
faveur de la restructuration de 1984 ont été réintégrées, depuis janvier 2006, au sein du Groupe
SONELGAZ.
Filiales Périphériques : SONELGAZ a externalisé ses activités périphériques et les a
confiées à des filiales dont elle détient entièrement le capital. Ces filiales sont au nombre de
quatorze et opèrent dans des activités diverses.

38
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

Sociétés en Participation : SONELGAZ s’est investie dans des domaines clés à haute
valeur technologique tels que les télécommunications ou la maintenance de turbines à gaz dans
le but de :
▪ Intégrer la technologie et le savoir-faire ;
▪ Introduire l’expertise managériale dans les domaines de la gestion ;
▪ Réaliser ses investissements grâce à l’apport de capitaux.

1.2.3 Missions
SONELGAZ a pour missions principales la production, le transport et la distribution de
l’électricité ainsi que le transport et la distribution du gaz par canalisations.

Production Transport Distribution

Figure 11 : Missions du groupe Sonelgaz

1.2.4 L’informatique au sein du groupe SONELGAZ


L’informatique occupe une place très importante au sein du groupe SONELGAZ. En
effet, la taille du groupe et son activité l’oblige à se doter des moyens technologiques de pointe
afin d’assurer ses activités métiers et de gestion.
L’informatique au sein du groupe a évolué au fil des années comme suit :
▪ Jusqu’à la fin des années 80, l’informatique était essentiellement présente au niveau
central sur gros systèmes. Cette période a vu le développement de systèmes de
gestion de l’entreprise et l’acquisition de modèles scientifiques de calcul pour la
planification des réseaux Électricité et Gaz (CARAT et APHYRE).
▪ La réorganisation de SONELGAZ en 1991 et l’avènement des mini et micro-
ordinateurs ont précipité la décentralisation de l’informatique.
▪ En 1996, le schéma directeur informatique de l’entreprise a défini la stratégie de
décentralisation de l’informatique vers une informatique distribuée, se basant sur
l’interconnexion des réseaux locaux à travers un réseau de télécommunication
propre.
▪ En 2006, le Groupe centralise l’activité informatique par la création de la Direction
générale des Systèmes d’Information (DGSI), chargée de la maîtrise d’œuvre dans le
domaine de l’informatique.
▪ En 2009, la DGSI s’est érigée au rang de filiale spécialisée dans le domaine des
systèmes d’information et technologies nouvelles sous le nom de « ELIT ».

39
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

1.3 Présentation D’ELIT


1.3.1 Dénomination et statut juridique
Le 1er janvier 2009, l’activité liée aux systèmes d’information, confiée jusque-là à une
direction générale à Sonelgaz, a été érigée en société par actions, dénommée « EL Djazair
Information Technology », par abréviation « ELIT Spa ».
1.3.2 Missions et attributions
Elit « El-Djazaïr Information Technology » élabore et met en œuvre les systèmes
d’information destinés au pilotage et à la gestion des différentes activités du groupe
SONELGAZ, assure l’accès à l’information et aux applications, en garantit la sécurité,
l’intégrité et la fiabilité et met à la disposition de ses clients l’expertise technique indispensable
à la satisfaction de leurs besoins.
Les missions assignées à ELIT se déclinent à deux niveaux, stratégique et opérationnel.
Pour le premier, ELIT contribue à la stratégie du Groupe Sonelgaz par :
1. L’élaboration de la politique des Systèmes d’Information et des technologies de
l’information et de la communication du Groupe Sonelgaz ;
2. La prise en charge des besoins des sociétés du Groupe Sonelgaz en matière
d'informatique et de télécommunications.
Quant au niveau opérationnel, ELIT s’emploie à :
1. Élaborer et mettre en œuvre les Systèmes d’Information destinés au pilotage et à
la gestion des différentes activités des sociétés du Groupe Sonelgaz.
2. Mettre à la disposition des sociétés du Groupe Sonelgaz les moyens informatiques
et de télécommunications (logiciels, matériels, infrastructures, etc.) nécessaires
pour assurer le niveau de service attendu.
3. Assurer la maintenance et l’administration des Systèmes d’Information, des plate-
formes et des équipements mis à la disposition des utilisateurs.
4. Assurer l’accès à l’information et aux applications et en garantir la sécurité,
l’intégrité et la fiabilité.
5. Mettre à la disposition des utilisateurs l’expertise technique indispensable à la
satisfaction de leurs besoins.
6. Proposer à terme, tous les services IT construits pour les sociétés du Groupe aux
clients externes.

40
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

Ci-dessous l’organigramme de ELIT :

Direction
Générale

Structures Structures
Assistant DG Assistant SIE Secrétariat
Métier Support

Direction Planification & Suivie Direction Comptabilité et


des projets Finance

Direction Progiciel de gestion Direction Ressources


intégrée Humaines

Direction SI des activités de


distribution / Gestion des Direction Commerciale
réseaux

Division Administration
Direction exploitation des SI
des marches

Direction Sécurité des SI Service Affaires Générales

Direction Réseaux et
Service Communication
télécommunication
Figure SEQ Figure \* ARABIC 12 : Organisation de ELIT
Figure 12 : Organisation de ELIT

1.3.2.1 Le rôle des principales structures métiers est :

▪ Direction de la Planification et du Suivi des projets :


Cette direction est chargée de
1. L’actualisation du schéma directeur.
2. La planification de projets nouvellement inscrits et celle de la ressource SI.
3. La définition et le contrôle de la qualité de conduite de projets.
4. Le suivi des projets sur le plan des charges et du budget.
▪ Direction Progiciel de gestion intégrée :
Cette direction est chargée de :

41
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

1. L’étude, la conception, le développement et le déploiement des nouveaux périmètres


pour les solutions de gestion existantes (Nova, Hissab et Attad..etc.).
2. L’intégration de nouvelles solutions.
3. L’assistance à l’utilisation de produits déployés et leur maintenance.

▪ Direction de l’exploitation des systèmes d’information :


Cette direction est chargée de :
1. L’exploitation et l’administration des Systèmes, SGBD, Applications et Services
composant le Système d’Information du groupe.
2. La gestion des salles d’hébergement des équipements du Système d’Information du
Groupe.
3. L’acquisition des équipements informatiques pour les Entités du Groupe.
4. Le Support et Assistance des Entités du Groupe.

▪ Direction de la sécurité des systèmes d’information


Cette direction est chargée de :
1. L’élaboration et la mise en application de la politique de sécurité du Groupe.
2. La définition et la mise en œuvre de solutions de sécurité.
3. Le contrôle du respect des règles de sécurité par l’ensemble des Entités du Groupe.
4. L’administration de la solution antivirale du Groupe.
5. La révision et la mise à niveau de l’indicateur de mesure de la sécurité informatique
du Groupe.
▪ Direction SI des activités de distribution et de gestion des réseaux : Cette direction
est chargée de la gestion des réseaux et applicatifs de support aux filiales de distribution
du groupe.
▪ Direction réseau et télécommunications :
Cette direction est chargée de la gestion du réseau informatique en développement, de
l’administration et de la maintenance de l’infrastructure réseau

1.3.3 Clients d’ELIT


L’activité commerciale d’ELIT est régie par des conventions de prestations de services
dans le domaine des systèmes d’information avec les 37 sociétés du Groupe Sonelgaz.

1.3.4 Structure d’accueil


Notre projet de fin d’étude se déroule au niveau du Département Intégration et
Maintenance des Systèmes d’Information rattaché à la Direction des Progiciels de Gestion
Intégrée. Cette direction se charge de :
42
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

▪ Étudier les besoins en systèmes d’information et mettre en œuvre les solutions adaptées
pour l’ensemble des Sociétés du Groupe SONELGAZ
▪ Organiser et planifier la réalisation des projets, depuis leur conception jusqu’à leur
achèvement (Conception, développement, tests, intégration, migration de données,
etc.), en s’appuyant sur des compétences internes ou externes ;
▪ Assurer la maintenance corrective et évolutive des systèmes d’information développés
▪ Préparer la société à placer, à termes, ses produits sur le marché
▪ Assurer la veille technologique.
Cette direction a la macrostructure schématisée dans la figure ci-après :

Direction Progiciel de gestion


intégrée

Département Département Développement


développement des Intégration et
études des SI SI Maintenance des SI

Figure 13 : Organisation de la DPGI

1.4 Conclusion

Avec ses décennies d’activité dans le domaine de l’énergie et une réputation qui dépasse
les frontières du pays, le groupe SONELGAZ représente un acteur majeur et incontournable
de l’économie nationale. Cette brève présentation nous a permis de connaître un peu plus le
groupe SONELGAZ, notamment dans sa nouvelle configuration de holding industriel.
Par ailleurs, cette présentation nous a fait comprendre la structuration et l’organisation de
Sonelgaz et plus particulièrement celle de la DPGI, et nous a permis de nous pencher sur
l’informatique du groupe désormais gérée, au niveau national, par la filiale « ELIT ».
Dans le chapitre suivant, une étude détaillée de l’existant décisionnel du groupe, dans sa
fonction de Ressources humaines, sera présentée.

43
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

Chapitre 2
2 Identification Des Besoins

2.1 Introduction
L’analyse des besoins est une étape cruciale qui consiste à recenser les besoins des
parties prenantes, et ceux en termes de besoins fonctionnels ou bien techniques.
Dans ce chapitre, on présente la démarche suivie pour enfin aboutir aux besoins qui serviront
de guide pour l’étape de conception de la solution retenue et satisfaisante pour les parties
prenantes.

2.2 Périmètre D’étude Et Intervenants Du Projet


Le système décisionnel à réaliser est destiné à tout le groupe Sonelgaz c’est-à-dire
toutes les 37 filiales qui sont éparpillées à travers le pays. En fait, la Direction du Capital
Humain (DCH), qui est la direction mère de la RH du groupe et qui tient à son commandement
les autres direction RH des autres filiales, nous a orienté vers la réalisation d’un seul système
avec les mêmes besoins pour tout le groupe. Pour cela, nous avons procédé comme suit :
1. Capturer les besoins des différentes filiales
2. Réunir tous les besoins afin d’obtenir une liste de besoins unifiés
3. Faire valider la liste obtenue par la DCH
Cette solution nous a parfaitement convenus car le déplacement chez toutes les filiales fut
impossible en plus de la non-disponibilité des parties prenantes à cause de la crise sanitaire.
Nous avons travaillé de près avec la DRH de ELIT et la DCH. Pour chacune des autres filiales,
nous avons procédé par l’envoi d’un formulaire pour recenser les besoins.

2.3 Ressources Utilisées Lors De La Collecte Des Besoins


Afin d’atteindre notre objectif qui consiste à identifier et à couvrir le maximum de
besoins analytiques, nous avons exploré d’autres ressources en plus des interviews. En effet,
ELIT nous a accordé accès aux procédures de travail et sources de données en relation avec les
processus RH.
2.3.1 Documentation consultée
▪ Les procédures de travail
Il s’agit de la documentation des processus de gestion des ressources humaines de l’entreprise.
Un document que nous avons exploité pour étudier les processus de gestion ressources
humaines (Rémunération, Etat sanitaire, Emplois Et Carrières, Formation…Etc.) et aussi pour
l’identification des besoins décisionnels des différents utilisateurs.
▪ Analyse des sources de données
44
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

Cette étude nous permet de voir si c’est possible de répondre aux besoins exprimés par les
utilisateurs ou non, et ceci en termes de disponibilité de données nécessaires pour établir les
analyses en question. Pour cela, nous avons effectué une étude sur la base de données du
système opérationnel NOVA ainsi que des fichiers Excel alimentés manuellement par l’équipe
ressources humaines de chaque société et nous avons identifié les tables nécessaires pour
répondre aux exigences des décideurs. Les sources de données de la fonction RH de Sonelgaz
contiennent aussi énormément de données non structurées et semi-structurées, plus
spécialement :
1. Des photos d’identité sous format Jpeg et Png
2. Des documents administratifs tels que des contrats de travail, demandes de
démission, dossiers maladies...etc. Et qui sont sous un format Docx ou PDF.
Ces données semi et non structurées vont être exploite dans des applications d’apprentissage
automatiques et de Machine Learning, des exemples d’utilisation pourraient être la prédiction du
candidat adéquat au poste à partir des CV.

2.3.2 Elaboration des entretiens


Avant de détailler cette étape, il est nécessaire de justifier notre choix de l’entretien «
interviews » comme méthode de collecte des besoins. Bien qu’il existe d’autres méthodes
d’identification des besoins, les entretiens s’imposent comme étant la valeur sûre dans un tel
projet. En effet, cette méthode a l’avantage d’être, plus ou moins, facilement planifiable et
d’ouvrir le dialogue avec les interviewés, qui sont majoritairement des décideurs et des
analystes.
2.3.2.1 Entretiens avec les concepteurs et développeurs du système opérationnel NOVA
Les développeurs et concepteurs du système opérationnel NOVA ont constitué une
source d’information précieuse dans notre collecte de besoins. En effet, ils ont montré non
seulement une connaissance complète et approfondie du système opérationnel mais aussi une
grande maitrise de la gestion des ressources humaines.
Nous avons eu l’occasion de faire des entretiens formels et informels avec eux pour comprendre
le système opérationnel, ses différentes fonctionnalités et lacunes ainsi que pour avoir des
indications sur les différents types de rapports d’analyse qui sont demandés par les décideurs.
2.3.2.2 Entretiens avec les futurs utilisateurs du système décisionnel
Cette tâche n’était pas des plus facile, en vue de l’agenda chargé des décideurs,
cependant, les entretiens que nous avons réussis à décrocher nous ont bien permis de cerner la
majorité de leurs besoins que nous avons bien sur complété en exploitant la documentation et
les sources de données.

2.4 Identification des besoins


Au cours de cette phase on a identifié les futurs utilisateurs et les besoins des décideurs,
chose indispensable pour suivre l’évolution du patrimoine humain et son impact sur la création
de la richesse et du coup l’avenir de l’entreprise.
2.4.1 Les acteurs du système
L’interaction avec le système diffère d’un utilisateur à un autre, selon le rôle de chacun.
Donc nous avons classé ces acteurs en deux types d’utilisateurs :
▪ Les administrateurs du système décisionnel : le personnel qui gère le système, il
s’occupe essentiellement de l’administration et la configuration du système et de la
gestion des utilisateurs.
45
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

▪ Les utilisateurs finaux : ce sont les décideurs que le système assiste dans leur prise de
décision.
Poste Description

1. PDG du groupe Faire des analyses et consultation des rapports sur toutes les
données des sociétés du groupe.
2. Comité de la Direction du
Capital Humain (DCH)

PDG des sociétés. Faire des analyses spécifiées et consultation des rapports sur la
société pour laquelle il travaille.

Administrateur du système Consultation des rapports.


décisionnel. Gestion des utilisateurs.

Tableau 9 : description des utilisateurs de notre solution

2.4.2 Les besoins techniques


Puisque ELIT dispose actuellement d’une solution de gestion des ressources humaines
et pour des raisons d’intégrations, les exigences suivantes, définies par l’équipe projet NOVA
et les utilisateurs finaux du système décisionnel, sont primordiales pour notre solution :
2.4.2.1 Outils de développement
1. La solution décisionnelle devra être Open Source pour qu’elle soit en adéquation avec
la politique Open Source d’ELIT
2. L’utilisation du SGBD PostgreSQL pour la création de l’entrepôt de données
3. Déploiement au niveau du serveur d’ELIT (CentOS)
4. Le système s’exécute sous Windows.
2.4.2.2 Confidentialité et sécurité
1. Le système doit être sécurisé
2. Les accès au système sont gérés avec les authentifications
3. Le système doit permettre la gestion des utilisateurs et profils
2.4.2.3 Accès aux données
1. Le système doit permettre un accès facile aux données

2.4.3 Les difficultés rencontrées


Lors de cette phase du projet, nous avons rencontré beaucoup de problèmes, parmi eux :
1. La difficulté de s’entretenir avec les parties prenantes à cause de leurs emplois du temps
chargés ou de leurs départs en congé
Le chapitre suivant consacré à l’étude du système RH existant, aidera à détecter les failles ainsi
qu’exposer notre raisonnement d’ingénieur et proposer des solutions répondante à la
problématique.

46
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

Chapitre 3
3 Analyse De L’existant
3.1 Introduction
L’analyse de l’existant représente sans doute l’une des étapes les plus importantes dans
notre projet car elle nous permet de faire les premiers pas pour mieux répondre aux besoins des
décideurs.
Partant de ce constat, nous allons essayer, à travers ce chapitre, de présenter une analyse
aussi complète que possible de l’existant décisionnel du groupe dans le cadre de sa fonction
ressources humaines. Ce chapitre a aussi pour but de faire connaître les procédures et les
méthodes de Reporting et de prise de décision, ainsi que les éventuelles lacunes qui peuvent
exister que nous tenterons de pallier grâce à notre solution.

3.2 Système D’information Opérationnel Existant


Avec le grand développement de Sonelgaz au fil des années, l’entreprise recense de
plus en plus de difficultés à gérer son patrimoine humain, d’où un réel besoin d’évoluer son
système de gestion de ressources humaines a été sentie. Sonelgaz a de ce fait adopté un nouveau
Système d’Information des Ressources Humaines (SIRH) nommé NOVA et qui est devenu
fonctionnel et opérationnel au niveau de certaines sociétés du groupe en 2012.
Le système d’information NOVA a été développé par les propres moyens du groupe et
conçu par une équipe mixte composée de représentants de la DRH qui décrivait les besoins et
les difficultés trouvées à gérer le capital humain de l’entreprise (maître d’ouvrage) et d’ELIT
qui étaient l’actuel réalisateur de la solution (maître d’œuvre).
« NOVA » est un système de gestion conçu pour offrir une gestion efficace de la
fonction Ressources Humaines, le système NOVA à l’heure actuelle répond partiellement aux
besoins opérationnels et attentes des utilisateurs en termes de gestion de la ressources humaines
et ceci est dû aux failles et anomalies qu’il contient. Les principaux modules que comportent
Nova sont :
1. Gestion administrative
2. Gestion des temps et activités
3. Traitement de la paie
4. Production des états post-paie
5. Production d’états comptables relatifs à la paie
6. Traitement des rappels
7. Gestion de la formation
8. Edition des documents administratifs

47
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

9. Gestion des absences et des congés


10. Gestion des évaluations et des promotions
Le système NOVA dispose actuellement de plusieurs modules comme montré dans la
figure ci-dessous :

Figure 14 : Modules de NOVA


Un aperçu détaillé des fonctionnalités de chaque module qu’offrent NOVA peut être
trouvé dans l’annexe
3.2.1 Etat de déploiement du système opérationnel NOVA
Depuis le développement de sa première version en 2012, le système NOVA se
généralise de plus en plus sur toutes les filiales du groupe au fur et à mesure de l’enrichissement
du système par les nouveaux modules et fonctionnalités.
La première version a été testée au niveau de trois sites pilotes choisis pour être
représentatifs de la gestion RH, en l’occurrence, SDA, ELIT et Sonelgaz.
En 2013, La deuxième phase a subi un second test à l’issue duquel Nova est devenu
opérationnel et étendu aux 17 sociétés du périmètre de l’ancien système GIP (gestion
informatisée du personnel) alors que la troisième phase, qui a intégré 173 nouvelles
fonctionnalités relatives à la gestion RH, a été appliquée dans l’ensemble des sociétés
du groupe.

48
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

A l’heure actuelle, NOVA est déployé au niveau de toutes les sociétés du groupe et il
est en état de production.
3.2.2 Technologies utilisées
Le groupe Sonelgaz suit la politique open source pour le développement de ses projets
informatiques.
Pour réaliser le système d’information NOVA, ELIT, la filiale informatique en charge
du développement et de la maintenance de NOVA, a opté pour les outils libres suivants :
1. La plateforme Java EE pour le développement du système NOVA.
2. Le SGBD PostgreSQL pour le stockage de données.
3. Le serveur qui héberge l’application est sous la distribution linux CentOS.

3.2.3 Architecture physique


Le système NOVA repose sur une architecture 3-Tiers qui comprend la couche
présentation, la couche application et la couche données.
La figure ci-après montre l’architecture du système :

Figure 15 : Architecture de NOVA

3.2.4 Etat du décisionnel au sein de Sonelgaz


Il est intéressant de signaler que le groupe, dans sa fonction de ressources humaines ne
dispose d’aucun système d’aide à la décision automatique. Aussi, tout processus d’analyse et
de prise de décision à tous les niveaux se base essentiellement sur des rapports dont les données
sont extraites et intégrées à partir des systèmes opérationnels d’une manière manuelle.
L’équipe qui gère le système opérationnel NOVA a mis en place des requêtes au niveau
du module « Reporting » permettant l’établissement des rapports d’activités. Ces rapports
restent limités et ne répondent malheureusement pas aux besoins croissants des décideurs.
3.2.5 Etude du processus de reporting actuel
Lors de notre étude de l’existant, nous avons pu recenser deux procédés pour
l’élaboration des rapports. Les deux procédés se distinguent par leurs utilisateurs finaux et la
structure chargée de leur élaboration.
Nous détaillons, dans ce qui suit, la procédure de reporting au niveau des sociétés et au
niveau de la holding.
49
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

▪ Reporting au niveau des sociétés


Le processus décisionnel sur la fonction ressources humaines au niveau des sociétés
concerne plusieurs axes d’analyse principaux. (Nous détaillerons plus en détails ces derniers
dans la partie conception).
Chaque société génère ses propres rapports d’activité dans des canevas prédéfinis (Voir
Annexe). Des requêtes ont été créées et établies par l’équipe chargée du développement et
maintenance du système NOVA appartenant à la filiale ELIT, et sauvegardée dans le module
Reporting de ce dernier.
Quand les décideurs font face à une décision et doivent s’appuyer sur les rapports
comme base de décision, Les agents en charge de l’opération exécutent les requêtes déjà
stockées dans le Module Reporting du Système NOVA et remplissent les canevas pré définis
manuellement par les résultats de ces dernières.
Une fois l’opération terminée, les rapports sont bien sûr transmis vers les décideurs.
Dans le cas où les décideurs demandent des rapports dont les requêtes nécessaires n’ont pas été
déjà créées, la demande est transmise à l’équipe chargée du développement de NOVA, cette
dernière cellule fait une étude sur la faisabilité de la demande en termes de disponibilité des
données nécessaires et la possibilité d’exécuter la requête. Si les requêtes sont faisables, elles
sont préparées, sauvegardées et exécutées pour générer les rapports demandés.
Voici ci-dessous un diagramme d’activité qui illustre le processus de génération de rapports
au niveau des sociétés du groupe :

50
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

Figure 16 : BPMN Génération de rapport de société


▪ Reporting au niveau de la HOLDING
La direction du capital humain (DCH) est la direction de l’entreprise chargée de gérer
toutes les directions des ressources humaines de toutes les sociétés du Holding. Les rapports
demandés à ce niveau se font sur toutes les sociétés du groupe et ils contiennent beaucoup plus
d’informations agrégées.
Pour établir ces rapports, la DCH envoie à la fin de chaque période des canevas (Voir
Annexe) à toutes les sociétés en vue de les remplir dans les délais spécifiés. Chaque société
remplit ces canevas par les informations nécessaires en exécutant des rapports prédéfinis et
retransmet ensuite ces canevas à la DCH. Une fois tous les canevas de toutes les sociétés reçus,
la DCH procède à la consolidation et l'intégration de tous ces canevas manuellement pour
établir les rapports voulus. Certains rapports sont trop complexes à réaliser à cause du nombre
d'informations et la complexité des données ce qui pourrait être très coûteux en termes de temps
où ça peut prendre des heures ou même parfois des jours à se charger.
Voici ci-dessous un diagramme d’activité qui illustre le processus de génération de rapports
au niveau de la maison Mère :

Figure 17 : BPMN génération de rapport au niveau de la holding

51
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

3.3 Diagnostic De L’existant


Diagnostiquer les procédures actuelles de travail utilisant le système actuel au niveau
de l’entreprise nous a permis de souligner les lacunes et limites suivantes :
3.3.1 Limites du système d'information existant Nova
▪ Le système existant n’est pas performant, il prend trop de temps à exécuter des tâches
basiques, en moyenne 15 minutes pour des taches transactionnelles.
▪ Nova n’est pas robuste. Les utilisateurs tombent pas mal de fois (environ 3 fois par jour
pour chaque société) durant l’utilisation dans des bug et failles, ces bugs nécessitent
l’intervention de l’équipe en charge de NOVA.
▪ Nova n’est pas facilement maintenable à cause des dépendances entre les modules, et
donc dans le cas de la découverte d’une anomalie ou faille dans un des modules, le
processus de réparation de ce dernier est très couteux en termes de temps.
3.3.2 Limites du système décisionnel existant
▪ Une utilisation massive des supports papier.
▪ Les décideurs sont obligés de passer par l’équipe reporting pour générer leur rapport.
▪ Les rapports ne sont pas flexibles aux demandes des décideurs.
▪ Les rapports générés n’utilisent pas les dernières avancées en termes de visualisation
de données permettant de mieux analyser et présenter les informations.
▪ Plusieurs rapports demandés par les décideurs ne peuvent être conçus.
▪ Utilisation de logiciels de communication (Courrier Électronique spécialement) pour
l'envoi de notification / rapport entre sociétés.
3.3.3 Causes engendrant ces limites et lacunes
Plusieurs causes sont à la source des lacunes que présente le système d’information
actuel qu’utilise Sonelgaz pour la gestion de son patrimoine humain, notamment :
1. L’architecture logicielle actuelle n’est pas adaptée pour les grandes quantités de
données dont dispose le patrimoine humain de Sonelgaz.
2. Nova est délicat à maintenir parce que des dépendances sont présentes entre les
différentes fonctionnalités, par exemple, la déficience du module gestion administrative
entrâmes l’arrêt de tous les autres modules de NOVA.
3. Impossibilité pour les décideurs d’éditer leurs rapports par eux même dans le système
existant.
4. Les rapports générés suivent des canevas prédéfinis auparavant dans le système
5. Trop de procédures (la demande de rapport, la demande d’ajout au système …etc.) ne
sont pas introduites dans le système et se font par papier.
6. Le système ne prend pas en considération tous les côtés de la gestion des ressources
humaines ce qui implique la non-faisabilité de quelques requêtes, la gestion des
recrutements par exemple n’es pas pris en charge dans NOVA.
52
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

3.3.4 Conséquences
1. Augmenter le risque des pertes de données, le taux d’erreur et diminue la fiabilité des
informations.
2. Le procédé d’élaboration des rapports de synthèse prend beaucoup de temps et mobilise
un nombre d’agents considérables (jusqu’à 2jours et quatre parties prenantes comme
expliqué en dessus dans le processus).
3. Dans le cas de non-possibilité de génération des rapports, les décideurs peuvent se
retrouver obligés de prendre des décisions stratégiques sans avoir bonne base
informationnelle sur laquelle s’appuyer.
4. Des décisions stratégiques peuvent être prises en se basant sur de mauvaises bases si
des rapports ne peuvent pas être générés pour soutenir les décideurs.
5. Les rapports générés peuvent ne pas répondre aux besoins des décideurs en termes de
visualisation.

3.4 Solutions Proposées


Après analyse du système d’information opérationnel existant et de l’existant
décisionnel du groupe dans le cadre de sa fonction ressources humaines, nous avons pu
diagnostiquer les lacunes de ces derniers ainsi que les conséquences qu’engendrent ces failles.
Une telle étude nous a permis de proposer différentes approches de concevoir et
implémenter la solution à notre problématique, ci-après une présentation et un comparatif de
ces derniers.
3.4.1 Solution 1
La première proposition stipule la « création d’un module d’aide à la décision et
l’intégrer à NOVA »
La première solution que nous envisageons est bien sûr de tirer profit du système d’information
opérationnel en cours et donc d’intégrer la solution d’aide à la décision NOVA, ceci peut être
possible en créant un module « Aide à la décision et reporting » qui va utiliser les sources de
données utilisées dans NOVA et qui sera ajouter à la liste des modules de NOVA.
Voici ci-après un schéma qui décrit le fonctionnement du système après implémentation de
cette solution :

Modules
existants Aide à la
décision Sources de
dans NOVA
données utilisées
par NOVA

Figure 18: Architecture de la solution d'intégration du 53


système sur NOVA
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

Cette approche présente plusieurs avantages mais aussi des inconvénients ou limites que nous
allons éclaircir dans le tableau suivant :
Avantages Limites
Les utilisateurs sont déjà familiers avec le Le système Nova comporte plusieurs failles et
système Nova bug
Données déjà présentes dans le support de Le système Nova n’est plus aussi performant
stockage de Nova avec évolution du volume de données qu’il traite
Le coût de réalisation du projet n’est pas élevé Nova n’est pas maintenable en cas de
défaillance d’un des modules
La base de données utilisée par Nova n’est pas
adaptée aux requêtes décisionnelles et
analytiques
Tableau 6 : avantages et limites de la solution

▪ Avis du client
Le client n’est pas motivé par la réalisation de cette solution, car l’entreprise envisage de
substituer dans les années à venir le système NOVA par un autre système opérationnel plus
performant et qui ne présente pas les lacunes citées auparavant dans NOVA.
3.4.2 Solution 2
La deuxième proposition stipule la « mise en place d’un système Business intelligence
classique et d’un module reporting qui sera intégré dans un ERP back office »
La deuxième solution que nous proposons est de mettre en place toute la structure du système
Business intelligence dans un système à part que nous appellerons « S1 ». « S1 » comportera
tous les traitements et préparation des données dans la base de données qui comportera un
entrepôt de données alimentées par « S1 ». La partie visualisation de données sera de son côté
gérée dans un module « Reporting » d’un nouveau ERP back office connecté à une base de
données centralisée qui contiendrait toutes les données de l’entreprise et donc la partie
alimentée par « S1 » utile dans le module Reporting.
Voici ci-après un schéma qui décrit le fonctionnement du système après implémentation de
cette solution :

54
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

Figure 19 : Architecture de la solution de l'intégration sur un ERP back-office


Cette approche présente plusieurs avantages mais aussi des inconvénients ou limites que nous
allons éclaircir dans le tableau suivant :
Avantages Limites

Système robuste et fiable L’entreprise est contrainte de mettre en place


tout un ERP back office
Système maintenable Système pas très performant à long terme à
cause de l’évolution du patrimoine humain de
l’entreprise
Réponds parfaitement aux besoins actuels Système de stockage adapté qu’aux requêtes
décisionnelles (Au niveau RH ).
Projet très couteux en termes de temps et
d’argent
Absence de données semi et non structurées
qui sont pertinents (les CV, contrat de
travail…etc.)
Tableau 7 : avantages et limites de la solution

▪ Avis du client
Le client trouve la solution trop coûteuse en termes de temps et d’argent, la mise en place d’un
nouveau ERP back office qui regrouperait toutes les fonctions de l’entreprise est un très grand
projet, que l’entreprise ne peut se permettre de lancer juste pour intégrer un module reporting
dedans.

55
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

3.4.3 Solution 3
La troisième proposition stipule la « mise en place d’un système d’aide à la décision
dans un environnement Big Data avec reporting dans un portail web »
La troisième solution que nous proposons est de mettre en place un système d’aide à la décision
dans un environnement Big Data. Cette proposition est envisageable à cause du volume
massive de données croissant de jour en jour (le nombre total d’employés en 2021 est supérieur
à 100000 employés, le nombre total d’employés inscrit dans les sources de données du système
actuel approximative les 2000000 employés, le volume de données de ces derniers dépasse la
barre des 2 Térabytes)
Les données seront stockées dans un data Lake de façon semi-structurée et distribuées en
utilisant le système de fichier distribuée HDFS dans le data center propre à ELIT. La politique
de sécurité de Sonelgaz empêche de stocker les données dans un cloud payant privé comme
« Amazon Web Services » ou « Microsoft Azure ».
Ces données seront extraites et chargées dans un processus ELT à partir des sources de données
du système d’information Nova dans le Datalake pour des fins propre au machine Learning (
en effet, Sonelgaz envisage de mettre en place des modèles de traitement automatiques et de
prédiction applicables aux volets de la fonction ressources humaines (nombre de démission ,
choix automatique de la nouvelle recrue parmi les candidats ..etc.)), en parallèle , un processus
ETL se chargera d’extraire , transformer et charger Les données prêtes dans une infrastructure
entrepôt de données à l’intérieur du lac de données et qui sera mieux adapté aux requêtes
décisionnelles, ceci se passe au sein d’une couche logicielle au-dessus de la couche de stockage
HDFS dans le serveur Hadoop. Les données seront après traitées de façon parallèle « Parallel
Processing » en utilisant le « Processing Engine » MapReduce pour être transformées en cube
MOLAP à partir du schéma en étoile conçu auparavant.
Les données traitées seront par la suite utilisées dans un portail web hébergé en local qui
contiendra toute la partie visualisation de données et Reporting et qui sera accessible à partir
du réseau local « LAN » de Sonelgaz.
Cette approche présente plusieurs avantages mais aussi des inconvénients ou limites que nous
allons éclaircir dans le tableau suivant :
Avantages Limites

Système très performant Continuer d’utiliser NOVA pour répondre


aux besoins opérationnels, et donc se confronter
aux limites de NOVA
Stockage des données structurée, semi- Projet très coûteux en termes d’argent et de
structurée et non structurée temps
Facilitée d’introduire les techniques de Duplication de données dans la source de
machine learning à l'avenir données de Nova et le data lake
Facilitée d’utilisation de la plateforme de
reporting
Plateforme de reporting accessible sans
nécessité d’Access internet (par réseau local)

56
2 ETUDE DE L’EXISTANT ET ANALYSE DES BESOINS

Tableau 8 : avantages et limites de la solution


▪ Avis du client
Il estime qu’entreprendre une approche big data pour répondre aux besoins pourrait être assez
coûteux pour l’entreprise, cependant il est convaincu que c’est la solution la plus appropriée au
problème grâce aux immenses avantages que cette dernière présente.

3.4.4 Choix
Notre choix en tant qu’ingénieur s’est porté sur la dernière solution et qui stipule « mise en
place d’un système d’aide à la décision dans un environnement BigData avec reporting dans
un portail web back office ». Comme cité auparavant, cette solution fournit plusieurs avantages
qui permettront de répondre par excellence aux besoins des parties prenantes du projet.

3.5 Conclusion
Cette étude nous permet d’avoir une vision générale des procédures d’élaboration de
rapports et de consolidation des données. Elle constitue aussi le point de départ pour définir le
périmètre du projet en général et de l’étude des besoins en particulier. Elle fait ressortir les
insuffisances du système actuel en soulignant les points faibles ou les goulots d’étranglements
de ce dernier.
Nous avons constaté, à travers cette étude, que le système opérationnel actuel répond
majoritairement aux besoins opérationnels du groupe mais reste très limité pour ce qui concerne
l’aide à la décision.

57
Troisième Partie

III. Conception De La Solution

58
3 CONCEPTION DE LA SOLUTION

Chapitre 1
1 Architecture Générale De La Solution
1.1 Introduction
Dans cette partie, nous présentons l’architecture générale du système cible d’aide à la
décision dans l’environnement Big Data qui nous permettra de répondre aux besoins évoqués
auparavant par l’entreprise. Nous procéderons dans ce qui suit à la définition en détails de
chaque composant du système par son architecture, fonctionnement et objectif
d’implémentation ainsi que les relations et flux entre les composants de notre solution.

1.2 Architecture Globale De Notre Solution


Dans le schéma ci-dessous, Nous exposons l’architecture du système cible d’aide à la
décision dans l’environnement big data.

Figure 20 : architecture de la solution


59
3 CONCEPTION DE LA SOLUTION

La figure montre que le système cible de notre solution se compose de plusieurs composants
qui sont installés dans plusieurs nœuds, dans ce qui suit on va décrire chaque composant en
mettant le point sur son objectif ainsi que son fonctionnement.

1.3 Sources De Données


Ce composant représente les différentes sources de données contenant les données que
va manipuler notre système.
Nous allons présenter les différentes bases de données, leurs tables, les champs des tables ainsi
que les relations qui lient ces tables de ces sources de données dans la partie conception de la
zone d’alimentation.

1.4 Processus EXTRACT LOAD TRANSFORM


1.4.1 Présentation
Ce composant représente le premier composant principal permettant de transférer les
données à partir des sources de données existantes vers notre système. Le transfert de données
se passe selon un processus Extraction - Chargement - Transformation “ELT”.
L’ELT extrait les données à partir d’une ou plusieurs sources de données, et les charge ensuite
complètement dans le système de stockage cible sans changement de format. Dans ce
processus, la transformation des données s’effectue au sein du système de stockage cible (et
qui est dans notre cas le système de fichier distribué de Hadoop “HDFS” que nous pouvons
appeler le Data Lake). Nous avons opté pour l’utilisation d’une telle approche car elle est plus
adaptée dans l’environnement Big Data. En effet, le chargement et les
transformations en cas de besoin sont rapides puisqu’ils se font en parallèle sur les nœuds.
1.4.2 Objectifs
L’objectif du processus ELT dans notre système est de charger les données depuis les
sources de données existantes vers le système de stockage de notre solution tout en gardant
l’évolutivité et en normalisant les données afin que le traitement soit le plus performant
possible.
1.4.3 Fonctionnement
▪ Extraction : La première étape, l’extraction, fonctionne de la même manière dans les
deux approches de gestion des données. Flux bruts de données d’une infrastructure
virtuelle, logiciels et applications sont ingérées entièrement ou en fonction de règles
prédéfinies.
▪ Chargement : Dans cette phase l’ELT a ses propres méthodes. Plutôt que de fournir
une telle quantité de données brutes et de les charger sur un serveur de traitement
temporaire avant transformation, l’ELT livre toutes les données dans le serveur
HADOOP (HDFS), Cela réduit le cycle entre extraction et chargement, mais nécessite
un travail bien plus important avant que les données ne deviennent utiles.
▪ Transformation : La base de données ou l’entrepôt trie et normalise les données, en
conservant une partie seulement ou la totalité de sorte qu’elles soient accessibles à des
fins de reporting personnalisé pour répondre aux besoins exprimés par l’entreprise. La
charge de stockage pour une telle quantité de données est plus importante, mais elle
offre davantage d’opportunités d’exploration personnalisée pour des données
décisionnelles pertinentes en temps quasi réel.

60
3 CONCEPTION DE LA SOLUTION

1.5 Processus EXTRACT TRANSFORM LOAD


1.5.1 Présentation
Ce composant représente le deuxième composant principal permettant de transférer les
données à partir des sources de données existantes vers notre système. Le transfert de données
se passe selon un processus Extraction - Transformation – Chargement “ETL”.
L’ETL extrait les données à partir d’une ou plusieurs sources de données en sélectionnant que
les données structurées adaptées au système d’aide à la décision cible, les faits passer par
différentes transformations, Notamment du nettoyage, le traitement des valeurs NULL,
Création des clés artificiels...etc., pour après charger ces données, prêtes à être utiliser pour des
fins décisionnelles, complètement dans le système de stockage.
Nous avons opté pour l’utilisation d’une telle approche aussi car elle est plus adaptée pour
l’infrastructure décisionnelle qui exige des données structurées pouvant être analysée par des
langages de requête structurée tel que SQL.
1.5.2 Objectifs
L’objectif du processus ETL dans notre système est de créer les données pouvant être
exploitées pour des fins décisionnelles et les stocker dans l’infrastructure entrepôt de données
de Hadoop Distributed File System en gardant l’évolutivité et en normalisant les données afin
que le traitement soit le plus performant possible.
1.5.3 Fonctionnement
▪ Extraction : La première étape, l’extraction, fonctionne de la même manière dans les
deux approches de gestion des données.
▪ Transformation : Les données précédemment extraites passent par un processus de
transformation et de normalisation (Nettoyage ...etc.) en conservant une partie
seulement ou la totalité de sorte qu’elles soient accessibles à des fins de reporting
personnalisé pour répondre aux besoins exprimés par l’entreprise.
▪ Chargement : Les données auparavant extraites des sources et transformées pour être
adaptées au format exigé par le systeme décisionnelle sont stockées de manière
distribuée dans l’infrastructure entrepôt de données du data lake.

1.6 Serveur Hadoop


Ce composant est un composant primordial de notre solution, lui-même se découpe en
deux sous-composants :
La couche de stockage distribuée HDFS “Le Data lake” : Elle représente la couche de
stockage de notre système cible, ici seront stockées toutes les données (structurées , semi-
structurées ainsi que non structurées )chargées à partir des sources des données existantes par
le processus ELT. Le Data Lake sera distribué sur plusieurs nœuds “Data Node” et qui
contiendront des données répliquées.
L’infrastructure entrepôt de données : c’est le cœur de notre système décisionnel, Ce
composant est créé à l’intérieur du lac de données afin de stocker les données structurées qui
seront utilisées pour répondre aux besoins décisionnels de l’entreprise. Ce composant reçoit
ses données à partir du processus ETL.

61
3 CONCEPTION DE LA SOLUTION

1.7 Cube Molap


1.7.1 Présentation
Multidimensionnel OLAP est un composant qui facilite l'analyse des données à l'aide
d'un cube de données multidimensionnel. Les données sont précalculées, récapitulées et
stockées dans un MOLAP.
À l'aide d'un MOLAP, un utilisateur peut utiliser des données de vue multidimensionnelles
avec différentes facettes, ces modèles reposent sur les cubes OLAP, dont chaque cellule
représente une intersection de dimensions.
Ce composant a pour objectif de créer des cubes multidimensionnel OLAP à partir de l'entrepôt
de donnes créé auparavant et stocke dans le data lake. Ce composant prend en entrée un schéma
en étoile de l'entrepôt de données et le transforme ainsi que les données appartenant en CUBE
MOLAP.
Le cube étant stockée dans un système distribué sera créé, alimenté et utilisé de façon distribuée
avec le framework MapReduce
1.7.2 Objectifs
L’objectif majeur d’utiliser ce composant est l’optimisation en temps et l’augmentation
des performances dans la prise de décision en Big data, ainsi de faciliter l’analyse sur les
différentes axes et dimensions, il permet aussi d’avoir un bon pourcentage de gain
d’information.

1.8 Couche Visualisation de données


1.8.1 Présentation
Le composant “Visualisation de données” représente le composant le plus important de
notre système, en effet, tout le système œuvre pour que la couche reporting puisse fonctionner
et donner les meilleurs résultats et performances possibles. C’est en quelque sorte le fruit de
tout notre système d’aide à la décision.
Le reporting est un outil qui permet de visualiser des indicateurs de performance. Notre couche
de reporting contient les données réelles qui seront collectées, stockées, traitées et triées à
l'avance dans les composants déjà cités auparavant dans notre solution. Ces dernières seront
utilisées pour générer et créer des tableaux de bord attractifs qui aideront à répondre aux
besoins des décideurs
1.8.2 Objectifs
Le principal objectif du reporting est la visualisation de données. Il permet de
matérialiser les données et de les rendre compréhensibles par tous, et ceux en les affichant sous
forme de tableaux, graphes ou même carte selon le besoin et le type de données qui alimentent
le tableau de bord.
En d’autres mots, l’objectif principal du reporting est de transformer les chiffres et lettres en
éléments visuels sur lesquelles les décideurs pourront s’appuyer pour prendre des décisions.

62
3 CONCEPTION DE LA SOLUTION

Chapitre 2
2 Conception Du Secteur D’entreposage
2.1 Introduction
Dans cette partie, nous présenterons l’architecture de la zone de stockage se trouvant
sur la couche physique du DATA LAKE.
Cette couche étant l'élément central de notre système de prise de décision. A l'issue de cette
étape, nous obtenons les mesures et les dimensions sur lesquelles ces mesures seront analysées.

2.2 Dimension Conformes


Nous allons commencer par présenter les dimensions conformes et qui seront présentes dans
plusieurs volets en tant qu’axe d’analyse.
2.2.1 La Dimension temps
Par définition de Kimball, La dimension temps figure dans tout architecture des entrepôts de
données, car elle permet l’analyse temporelle des faits, il est classé en premier des tables d’une
base de données (KIMBALL).

Figure 21 : schéma de la dimension temps

2.2.2 La dimension Classement


Chaque employé appartient à un classement. Au moment de l’embauche, l’agent est affecté au
Classement 0, avec les années l'employé est promu vers un classement supérieur (Classement
1, Classement 2...etc.)

63
3 CONCEPTION DE LA SOLUTION

Figure 22: schéma de la dimension classement

2.2.3 La dimension Contrat


Cette table contient les détails du contrat d’un employé donnée (Indéterminée, temporaire
…etc.)

Figure 23: schéma de la dimension contrat

2.2.4 La dimension GSP


Cette dimension contient les informations sur le groupe socioprofessionnel auquel appartient
l’agent (Cadre, maîtrise, exécution)

Figure 24: schéma de la dimension GSP

2.2.5 La dimension Organisation


Cette dimension représente l’organisation auquel l’employé appartient, elle permet de faire un
suivi par centre organisationnel. Elle regroupe les différentes hiérarchies de la structure dans
laquelle peut travailler un agent.
En effet, chaque société contient un ou plusieurs centres de paiement. Un centre de paiement
contient un ou plusieurs bureaux gestionnaires et un bureau gestionnaire comprend un ou
plusieurs services de paie, d’où la hiérarchie

64
3 CONCEPTION DE LA SOLUTION

Figure 25: schéma de la dimension Organisation

2.2.6 La dimension Sexe


Il faut que nous introduisions le sexe comme étant un axe pour savoir si le sexe est un facteur
important dans la gestion des ressources humaines.

Figure 26: schéma de la dimension sexe

2.2.7 La dimension Âge


L'âge des employés est un facteur primordial qui agit sur le rendement de ces derniers, ainsi
L'âge représente un axe d’analyse très important pour l’analyse des ressources humaines.
Notre analyse se fera en divisant l'âge en tranche d'âge en 3 catégories et qui sont :
▪ Adulte : de 18 ans à 30 ans.
▪ Monsieur : de 31 ans à 50 ans.
▪ Vétéran : plus de 51 ans.

Figure 27: schéma de la dimension âge

2.3 Volets D’analyses


Nous allons dans ce qui suit étudier les volets d’analyses précédemment extraites depuis les
besoins exprimés par l’entreprise.
65
3 CONCEPTION DE LA SOLUTION

Nous commençons par donner une brève présentation du volet, suivie par la granularité et les
dimensions spécifiques à ce dernier, nous finirons par présenter les mesures ainsi que la table
de fait du volet, pour bien évidemment à la fin présenter le schéma en étoile qui traite les
besoins de ce volet.
2.3.1 Volet Suivi Effectif
2.3.1.1 Présentation du volet
Les décideurs attachent une grande importance à la gestion du personnel car les
ressources représentent l'épine dorsale du groupe Sonelgaz. En effet, la gestion du personnel
est un facteur de compétitivité, qui permet de fournir une information précise sur la main-
d’œuvre pour évaluation. Prendre en compte les besoins du groupe en termes de quantité et de
qualité pour éviter tout déséquilibre Cela peut affecter le fonctionnement normal de diverses
activités. Grâce à l'analyse de cette composante, il est possible de suivre l'évolution de
l'ensemble de l'effectif selon plusieurs axes et de détecter les sureffectifs ou un personnel
insuffisant.
2.3.1.2 Granularité
Le nombre d’agents d’une organisation ayant un contrat, appartenant à un groupe
socioprofessionnel (GSP), classement, d’un certain âge et sexe, actif compté à une date donnée.
2.3.1.3 Dimensions nécessaires pour l’analyse :
En fonction des besoins précédemment définis, nous pouvons déterminer les dimensions qui
participent Dans ce volet. Ces dimensions sont extraites à partir des axes d’analyse exprimés
par les Décideurs.
Requête Axe d’analyse Dimension présente

Suivre l’ensemble des Permanent ou


changements de personnel temporaire : recherche selon Contrat
Actif permanent et temporaire le type de contrat de l’employé
par organisation (Société, (CDD ou CDI)
Bureau gestionnaire et Service Organisation : recherche
Paie ) et par âge dans un délai selon la structure Organisation
défini organisationnelle à laquelle
appartient l’employé
Délais : Recherche selon la
date ou période (information Temps
temporelle)

Suivre l’ensemble des


changements de personnel
Actif permanent et temporaire Groupe socioprofessionnel
par groupe socioprofessionnel (GSP) : Recherche selon le GSP
(GSP) , Classement et groupe socioprofessionnel
organisation (Société , Bureau auquel appartient l’employé

66
3 CONCEPTION DE LA SOLUTION

gestionnaire ou Service Paie )


et par âge dans un délai défini Classement : Analyse selon
le classement ( un Rang ) des Classement
employés .

Suivre le nombre Age : La tranche d'âge à


d’employée par classement, laquelle appartient l'employé Âge
sexe , age , gsp et organisation
dans un délais bien définie
Faire des analyses par
rapport au sexe de la Effectif féminin Sexe
population
Tableau 10 : tableau contenant les requêtes tirées depuis les besoins du client avec
les dimensions nécessaires
D’après notre étude, les dimensions retenues dans ce volet sont les suivantes :
1. Dimension Temps
2. Dimension Organisation
3. Dimension GSP
4. Dimension Classement
5. Dimension Âge
6. Dimension Contrat
7. Dimension Sexe
2.3.1.4 Présentation des Mesures
Nombre Agents : cette mesure additive représente le nombre d’agents compté à la fin d’une
période (mois, trimestre, semestre ou année).
2.3.1.5 Table de fait
Après définition des mesures et dimensions participantes dans le volet suivi de l’effectif, on
peut présenter la table de fait qui juste comme ci-dessous :

67
3 CONCEPTION DE LA SOLUTION

Figure 28 : schéma de la table fait suivi effectif


2.3.1.6 Schéma en étoile du volet « Suivi de l’effectif »
On présente ci-dessous le modèle de données du volet « suivi de l’effectif »

Figure 29 : schéma en étoile du volet suivi de l'effectif


68
3 CONCEPTION DE LA SOLUTION

2.3.2 Volet Suivi Des Recrutements


2.3.2.1 Présentation du volet
L’un des axes les plus importants dans la gestion du personnel est l’analyse des
recrutements, à travers cette analyse
Les décideurs peuvent voir les statistiques sur les embauches, le suivi des embauches doit
prendre en considération les besoins du groupe en termes de quantité et de qualité pour éviter
tout déséquilibre. Cela peut affecter le fonctionnement normal de diverses activités.
2.3.2.2 Granularité
Le nombre d’embauches d’une organisation par type de contrat, affectée à un groupe
socioprofessionnel (GSP), femme ou homme, selon différents intervalles d’âge, compté à une
date donnée.
2.3.2.3 Dimensions nécessaires pour l’analyse
Pour effectuer cette analyse il faut bien choisir les axes principales, d'où d'après les besoins du
groupe les dimensions sont :
▪ Dimension Temps
▪ Dimension Organisation
▪ Dimension GSP
▪ Dimension Sexe
▪ Dimension Âge
▪ Dimension Contrat
Requête Axe d’analyse Dimension présente

Suivre l’ensemble des Permanent ou


embauches par type de contrat temporaire : recherche selon Contrat
permanent et temporaire par le type de contrat de l’employé
organisation (Société , Bureau (CDD ou CDI)
gestionnaire ou Service Paie ) Organisation : recherche
et par âge dans un délai défini selon la structure Organisation
organisationnelle à laquelle
appartient l’employé
Délais : Recherche selon la
date ou période (information Temps
temporelle)

69
3 CONCEPTION DE LA SOLUTION

Suivre le nombre Groupe socioprofessionnel


d’embauche des employées (GSP) : Recherche selon le
par type de contrat permanent groupe socioprofessionnel
et temporaire par groupe auquel appartient l’employé GSP
socioprofessionnel (GSP) et
organisation (Société , Bureau
gestionnaire ou Service Paie )
et par âge dans un délai défini

Suivre le nombre Age : L'âge de l'employé


d’embauche par âge, gsp et embauché Âge
organisation dans un delais
bien définie

Suivre le nombre Effectif féminin Sexe


d’embauche par rapport aux
deux sexes
Tableau 11 : tableau contenant les requêtes tirées depuis les besoins du client avec
les dimensions nécessaires
2.3.2.4 Présentation des mesures
Nombre d’embauches : cette mesure additive représente le nombre de nouvelles recrues
compté à la fin d’une période (mois, trimestre, semestre ou année).
2.3.2.5 Table des faits
La table des faits du suivi des embauches est illustré dans la figure ci-dessous,

Figure 30 : schéma de la table fait suivi des recrutements


2.3.2.6 Schéma en étoile du volet
Nous présentons ci-dessous le modèle de données du volet « suivi des recrutements »

70
3 CONCEPTION DE LA SOLUTION

Figure 31 : schéma en étoile du volet suivi des recrutements

2.3.3 Volet Suivi Des Formations


2.3.3.1 Présentation du volet
Les compétences sont une ressource importante de l'entreprise et donc l'une de ses
priorités stratégiques. En assurant le processus de suivi des compétences des opérateurs et des
techniciens, les organisations ont un vif intérêt à gérer au mieux ces compétences.
Le suivi des compétences vise à garantir que les employés peuvent non seulement intégrer et
appliquer les connaissances liées à leurs emplois et postes respectifs, mais aussi améliorer
continuellement leur niveau de connaissances pour permettre une progression continue de
l'organisation.
Lorsque nous mettons à disposition nos propres moyens pour favoriser l'amélioration des
compétences des collaborateurs, notamment en planifiant des formations adaptées aux besoins
de l'entreprise et aux aspirations des collaborateurs, on peut légitimement prétendre à une
évolution satisfaisante.
Les principaux avantages de cette politique pour l'entreprise sont :
1. L’amélioration de sa compétitivité
2. La fidélisation de ses salariés
3. Le maintien du cap sur ses objectifs.

71
3 CONCEPTION DE LA SOLUTION

2.3.3.2 Granularité
Suivie du nombre d’agents formés et de l’ensemble des formations par type, spécialité,
thème, sous thème et langue de formation ainsi que le fournisseurs des moyens utilisés durant
la formation dans un délai bien défini.
2.3.3.3 Dimensions nécessaires pour l’analyse
En fonction des besoins précédemment définis, nous pouvons déterminer les dimensions qui
participent dans ce volet. Ces dimensions sont extraites à partir des axes d’analyse exprimés
par les Décideurs.
Requête Axe d’analyse Dimension
présente
National ou International : Analyse
selon le type de la formation.
Suivie de l’ensemble des Type
formations nationale ou
internationale par spécialité, Spécialité : Analyse selon la spécialité
moyen de financement , thème dont traite la formation Spécialité
, sous thème, organisation de la
formation dans un délais défini Thème : analyse selon le thème de la
formation
Thème

Sous Thème : Chaque thème contient Sous Thème


plusieurs sous thème.
Moyen de financement : Interne, Moyen de
Externe...etc. Financement

Délais : Recherche selon la date ou


période (information temporelle)
Temps
Organisation : analyse selon la
structure organisationnelle à laquelle
appartient l’employé
Organisation

Tableau XII : tableau contenant les requêtes tirées depuis les besoins du client sur les
formations avec les dimensions nécessaires
D’après notre étude, les dimensions nécessaires pour le bon fonctionnement de ce volet sont :
1. Dimension type formation
2. Dimension Spécialité
3. Dimension thème
4. Dimension sous thème
5. Dimension temps

72
3 CONCEPTION DE LA SOLUTION

6. Dimension organisation
7. Dimension moyen financement

2.3.3.4 Description des attributs des dimensions

Dimension Type formation :


Les différents types de formations sont présents dans cette dimension.

Figure 32 : schéma de la dimension type de formation


Dimension Spécialité :
Cette dimension contient la liste des spécialités :

Figure 33 : schéma de la dimension spécialité formation


Dimension Thème :
Cette dimension contient la liste des thèmes des formations :

Figure 34 : schéma de la dimension thème de formation


Dimension sous Thème :
73
3 CONCEPTION DE LA SOLUTION

Cette dimension contient la liste des sous thèmes des formations :

Figure 35 : schéma de la dimension sous thème de formation


Dimension Moyen :
La dimension “moyen” contient les moyens de la formation ( étrangère, nationale ..)

Figure 36 : schéma de la dimension moyen de formation


2.3.3.5 Présentation des Mesures
Nombre de formations : cette mesure représente le nombre de formations faites comptés à la
fin d’une période (mois, trimestre, semestre ou année).
Nombre d’agents formés : cette mesure représente le nombre d’agents ayant été formée dans
les formations précédentes
2.3.3.6 Table de fait
Après définition des mesures et dimensions participantes dans cette activité, on peut présenter
la table de fait qui juste comme ci-dessous :

74
3 CONCEPTION DE LA SOLUTION

Figure 37 : schéma de la table fait suivi des formations


2.3.3.7 Schéma en étoile du volet « Suivi de formation »

Figure 38 : schéma en étoile du volet suivi des formations

75
3 CONCEPTION DE LA SOLUTION

2.3.4 Volet Suivi De La Masse Salariale


2.3.4.1 Présentation du volet
Ce volet possède une grande importance dans la gestion des RH car le facteur du salaire
contrôle le volet des départs aussi, grâce à l’analyse de ce volet les décideurs vont avoir une
vision sur un des facteurs les plus influençant pour les employés, c’est la masse salariale.
2.3.4.2 Granularité
Suivi du montant la masse salariale net d’un classement d’une organisation, suivant un
Contrat et appartenant à un Groupe socio-professionnel selon une rubrique de paie par
tranche d’âge et sexe dans une durée définie.
2.3.4.3 Dimensions nécessaires pour l’analyse :
En fonction des besoins précédemment définis, nous pouvons déterminer les dimensions qui
participent dans ce volet. Ces dimensions sont extraites à partir des axes d’analyse exprimés
par les Décideurs.
Requête Axe d’analyse Dimension
présente
Permanent ou temporaire : recherche
selon le type de contrat de l’employé
(CDD ou CDI) Contrat

Actif ou Inactif : recherche selon


l’activité d’un employé (Actif avec solde,
Inactif avec solde, Inactif sans solde, Classement
Départ)

Suivre l’évolution de la masse Organisation : recherche selon la


salariale du personnel par type structure organisationnelle à laquelle
de contrat, groupe appartient l’employé Organisation
socioprofessionnel, Classement
et par organisation (Société,
Bureau gestionnaire ou Service Délais : Recherche selon la date ou
Paie ) , Sexe , par rubrique Paie période (information temporelle) Temps
et tranche d'âge dans un délai
défini Groupe socioprofessionnel (GSP) : GSP
Recherche selon le groupe
socioprofessionnel auquel appartient
l’employé
Rubrique : contient les différentes Paie
charges que dépenses l’entreprise sur son
employé (frais de transports, charges,
primes)
Tranche d’âge : cet axe permet Âge
d’analyser la masse salariale selon les
tranches d'âges

76
3 CONCEPTION DE LA SOLUTION

Sexe : Analyse selon le sexe des Sexe


employés.

Tableau 12 : tableau contenant les requêtes tirées sur l'analyse de la masse salariale
depuis le besoin du client
Les dimensions qui permettent de répondre aux requêtes sont :
1. La dimension temps
2. La dimension classement
3. La dimension contrat
4. La dimension GSP
5. La dimension organisation
6. La dimension Paie.
Dans les titres qui suivent nous exposerons les dimensions avec leurs attributs ainsi que la table
des faits.
2.3.4.4 Description des attributs des dimensions
La dimension Paie : Cette dimension est très considérable dans le suivi de la masse salariale,
elle consiste à faire apparaître les différentes rubriques qui apparaissent lors du calcul de la paie
(frais de transports, charges, primes…etc).

Figure 39 : schéma de la dimension rubrique paie


2.3.4.5 Présentation des Mesures
Montant Masse Salariale : Mesure la somme dépensée par l’entreprise sur les salaires des
employés
2.3.4.6 Table des faits :
La table des faits du volet suivi de la masse salariale contiendra les clés des dimensions
d’analyse ainsi les KPI du volet exprimé dans la première partie

77
3 CONCEPTION DE LA SOLUTION

Figure 40 : schéma de la table fait suivi de la masse salariale


2.3.4.7 Schéma en étoile du volet :

78
3 CONCEPTION DE LA SOLUTION

Figure 41 : schéma en étoile du volet suivi de la masse salariale

2.3.5 Volet Suivi Des Absences


2.3.5.1 Présentation du volet
Ce volet permet d’analyser les vides dans les postes des employés (absence, congé) :
les heures d’absence par Employé ainsi que les nombres d’agents absents dans une période.
Cette analyse va permettre aux décideurs de savoir qui on s’absente beaucoup, pourquoi et
quand afin de procéder pour régler ce déséquilibre
2.3.5.2 Granularité
Suivi du nombre d’absences des employés, Il s’agit du suivi du nombre d’agents absents ainsi
que le nombre d’absences dans une organisation selon un type contrat et appartenant à un
GSP pour un motif d’absence bien défini dans une période donnée.
2.3.5.3 Dimensions nécessaires pour l’analyse :
En fonction des besoins précédemment définis, nous pouvons déterminer les dimensions qui
participent dans ce volet. Ces dimensions sont extraites à partir des axes d’analyse exprimés
par les Décideurs.

79
3 CONCEPTION DE LA SOLUTION

Requête Axe d’analyse Dimension


présente
Suivre le nombre Organisation Organisation
d’absences
par organisation, sexe et
par Période Période, Date Temps

Sexe Sexe

Déterminer le nombre Motif : représente la cause


d’agents absents selon un de l’absence. Motif
motif d’absence dans Absence
une période définie

Déterminer le nombre GSP GSP


d’agents absents par
GSP, par type de contrat Type de contrat Contrat
et par période

Tableau 13 : tableau contenant les requêtes sur le suivi des heures de travail qui
comble le besoin du client
2.3.5.4 Description des attributs des dimensions
1. La Dimension temps
2. La dimension Contrat
3. La dimension GSP
4. La dimension Organisation
5. La dimension motif absence
6. La dimension Sexe
2.3.5.5 La dimension Motif absence
Cette dimension est très considérable dans le suivi du temps de travail, elle permet une analyse
selon le motif d’absence.

Figure 42 : schéma de la dimension motif absence

80
3 CONCEPTION DE LA SOLUTION

2.3.5.6 Présentation des Mesures


Nombre d'employés absents : cette mesure additive représente le nombre d'employés absents
comptés à la fin d’une période (mois, trimestre, semestre ou année).
Nombre d’absences : cette mesure additive représente le nombre d'absences comptés à la fin
d’une période (mois, trimestre, semestre ou année).

2.3.5.7 Table de faits :


La table des faits du volet suivi du temps de travail contiendra les clés des dimensions d’analyse
ainsi les KPI du volet exprimé dans la première partie,
La table de faits :

Figure 43 : schéma de la table fait suivi des heures de travail

81
3 CONCEPTION DE LA SOLUTION

2.3.5.8 Schéma en étoile du volet :

Figure 44 : schéma en étoile du volet suivi des heures de travail

2.3.6 Volet Suivi Des Départs


2.3.6.1 Présentation du volet
Ce Volet met en valeur les départs définitifs des employés avec différente axe d’analyse
afin que les décideurs puissent engager vers des recrutements ou d'autres alternatives pour
régler ce problème.
2.3.6.2 Granularité
Suivi du taux de démissions et des départs en retraite, par Organisation, GSP, sexe et Type
de contrat avec un Motif, dans une période définie.

2.3.6.3 Dimensions nécessaires pour l’analyse


En fonction des besoins précédemment définis, nous pouvons déterminer les dimensions qui
participent dans ce volet. Ces dimensions sont extraites à partir des axes d’analyse exprimés
par les Décideurs.

82
3 CONCEPTION DE LA SOLUTION

Requête Axe d’analyse Dimension présente


Permanents/temporaires Contrat

Organisation Organisation

Suivre les départs


définitifs des Groupe socioprofessionnel GSP
Permanents et
temporaires par
organisation, groupe Période Temps
socioprofessionnel
Et par tranche d'âge dans
une période définie.
Tranche d'âge Âge

Suivre les départs des


permanents et Motif Départ
temporaires par motif de Motif : représente le motif
départ et par organisation. de départ

Tableau 14 : tableau d'analyse des requetes du suivi des départs avec les dimensions
nécessaires
1. La Dimension temps
2. La dimension Contrat
3. La dimension GSP
4. La dimension Organisation
5. La dimension Sexe
6. La dimension Motif Départ

2.3.6.4 Description des attributs des dimensions et table de faits :


Dimension motif départ : Cette dimension est très considérable dans le suivi des départs, elle
permet une analyse selon le motif de départ.

83
3 CONCEPTION DE LA SOLUTION

Figure 45 : schéma de la dimension motif du départ

2.3.6.5 Présentation des Mesures


Nombre de démissions : cette mesure additive représente le nombre d'employés ayant
démissionné comptés généralement à la fin d’une période (mois, trimestre, semestre ou année).
2.3.6.6 Table de faits
La table des faits du volet suivi du temps de travail contiendra les clés des dimensions d’analyse
ainsi les KPI du volet exprimé dans la première partie
La table de fait :

Figure 46 : schéma de la table fait suivi des départs

84
3 CONCEPTION DE LA SOLUTION

2.3.6.7 Schéma en étoile du volet :

Figure 47 : schéma en étoile du volet suivi des départs

2.4 Conclusion

Dans ce chapitre, nous avons présenté la conception de la zone de stockage, qui


constitue le référentiel central du système décisionnel. Pour chaque composant d'analyse, nous
avons développé un diagramme en étoile associé, détaillant leur taille et leurs mesures. Notre
entrepôt de données répondra aux besoins des différents utilisateurs, mais avant cela, nous
devons effectuer les étapes récapitulatives de l'entrepôt. Par conséquent, le chapitre suivant se
concentrera sur la conception de la zone d'alimentation ELT.

85
3 CONCEPTION DE LA SOLUTION

Chapitre 3
3 Conception Du Secteur D’alimentation
3.1 Introduction
La zone d’alimentation de notre système cible repose sur un processus ELT (Extraction,
Chargement et Transformation en français).
L’ELT est le processus qui consiste à extraire des données d'une ou plusieurs sources et à les
charger dans un système de stockage cible. Au lieu de transformer les données avant qu'elles
ne soient écrites, L’ELT tire parti du système cible pour effectuer la transformation des données.
C’est-à-dire que les données seront vérifiées, nettoyées et puis agrégées après leur chargement
dans le système de stockage cible. Une telle approche est adoptée Parce qu'elle tire parti des
performances du système de stockage cible (beaucoup plus performant que celui source étant
distribué)
Dans ce chapitre, nous allons présenter notre conception des processus ELT et ETL pour
l’alimentation du DATALAKE ainsi que l'infrastructure entrepôt de données y’appartenant.

3.2 Etude des sources de données


L'étude des sources de données est une étape primordiale de notre projet. Y compris la
connaissance des différentes bases de données, de leurs tableaux, Tables, la relation entre ces
tables et le mécanisme de gestion de l'historique
3.2.1 Présentation des sources de données
Comme cités précédemment, les sources de données qui alimentent notre système cible
proviennent principalement du système d’information existant NOVA, en effet, Nous comptons
plus précisément les deux sources suivantes :
▪ Base de données NOVA de Production : Cette source contient toutes les informations
relatives à la gestion des ressources humaines (recrutement, formation, départ, absence
...etc.) dans SONELGAZ.
▪ Fichier Excel paie : Les informations relatives au processus de paiement de l'employé,
telles que les rubriques de paiement, la paie de chaque agent et son montant sont
stockées dans un fichier Excel alimenté à chaque début du mois.
3.2.2 Qualité des données
Les sources de données fournies par l’entreprise à travers le système d’information
opérationnelle NOVA étaient suffisantes pour répondre aux différents besoins analytiques des
décideurs. Le système opérationnel NOVA est de bonne qualité, en effet, il minimise le taux
d’erreurs commis par les agents via les contrôles de saisie.
Cependant, nous avons pu dégager certaines anomalies :
1. Des données manquantes.
2. Des données erronées.

86
3 CONCEPTION DE LA SOLUTION

3. Des abréviations non significatives.


Ces anomalies seront traitées dans la phase de transformation du processus ETL afin d’assurer
la fiabilité et la pertinence attendues des données.

3.3 Conception de L’ELT


Le processus ELT permet globalement la réconciliation des données et leur transfert des sources
de données vers notre système cible.
Il passe par trois étapes essentielles :
1. L’extraction de toutes les données (structurées et non structurées) depuis leurs sources.
2. Le chargement de ces données dans leur format brute dans le système de stockage cible
3. La transformation et le nettoyage de ces données dans le data lake avant utilisation.
Voici ci-dessous une figure qui présente les étapes suivies dans le processus ELT :

Figure SEQFigure
Figure48
\* :ARABIC 48processus
BPMN du : BPMN du processus ELT
ELT

3.3.1 Extraction
Après une étude approfondie des sources de données qui alimentent notre système cible,
nous passons à l'étape d’extraction des données en relation à la fonction Ressources humaines.
Dans cette étape, toutes les données présentes dans les sources quel que soit leur type
(Structurée, semi-structurées ou non structurées) sont prélevées pour préparer les prochaines
étapes du processus.
3.3.2 Chargement
Cette étape consiste à charger les données extraites précédemment dans le data lake qui
est la couche de stockage physique de notre système cible.
Au lancement du processus, le données extraites sont comparés aux données déjà présentes dans
le DATALAKE , les données qui s'avèrent non existantes dans HDFS seront toutes chargées

87
3 CONCEPTION DE LA SOLUTION

au sein du lac de données , ce qui créera un énorme Dataset pouvant être utilisé dans les
systèmes décisionnelles ainsi que les modèles de traitement de données.
3.3.3 Transformation
Les données, dans le format stocké dans HDFS, ne peuvent être utilisés pour des fin
décisionnelles et ceux pour plusieurs raisons :
▪ Le Data Lake contient des données structurées, semi-structurées ainsi que non
structurées, et seules les données structurées peuvent être utilisées pour des fins
décisionnelles.
▪ Les requêtes analytiques contiennent majoritairement des agrégats, et ce genre de
requêtes n’est possible que sur une couche de stockage relationnelle.
Et c’est pour ces raisons que nous optons pour la création d’une couche de données sous forme
d’un datawarehouse au sein du lac de données contenant des données relationnelles pouvant
être agrégées et utilisées pour des fins analytiques.

3.4 Conception de L’ETL


Le processus ETL permet globalement la réconciliation des données et leur transfert des
sources de données vers notre système cible dans un format adapté aux objectifs décisionnelles.
Il passe par trois étapes essentielles :
1. L’extraction de toutes les données structurées depuis leurs sources.
2. La transformation et le nettoyage de ces données.
3. Le chargement de ces données dans l’infrastructure Data Warehouse de HDFS
Voici ci-dessous une figure qui présente les étapes suivies dans le processus ETL :

Figure 49 : BPMN ETL

88
3 CONCEPTION DE LA SOLUTION

Chapitre 4
4 Conception De La Zone De Restitution

4.1 INTRODUCTION
Dans ce chapitre, nous introduisons la conception de la zone de restitution, la dernière
La hiérarchie constitue l'interface visuelle entre le système décisionnel et l'utilisateur final Et le
système. Cette zone permet aux utilisateurs d'exploiter facilement les données d’une manière
simple Nous avons mis en œuvre des ensembles de cube multidimensionnelles OLAP pour
chaque volet, qui peuvent effectuer une analyse multidimensionnelle et nous avons préparé des
rapports d'activités selon les besoins et les exigences utilisateurs.

4.2 CONCEPTION DES CUBES


Le cube est considéré comme composant principal dans un système décisionnel, il
permet la mise en œuvre des opérations OLAP Ces vues fournissent un environnement
d'analyse de données interactif.
Dans cette partie nous allons définir les dimensions et leurs niveaux hiérarchiques, puis nous
passons à la modélisation des cubes pour chaque volet d’analyse RH.
4.2.1 Définition des niveaux hiérarchiques des dimensions :
Identifier le niveau et la hiérarchie des dimensions est une étape indispensable pour
concevoir un cube dimensionnel. Cela permet aux utilisateurs de profiter des cubes de données
avec le niveau de détail souhaité. Chaque hiérarchie est composée d'un ou plusieurs niveaux, et
chaque niveau est composé d'un ou plusieurs attributs.

Dimension Hiérarchie Niveau Colonnes


N1 Num_day
H1_Temps day
N1->N2->N3->N4->N5->ALL date
Dimension
N2 Month
Temps
N3 term
N4 semester
N5 year
Dimension H2_Organisation N1 remunirationservice
Organisation N1->N2->N3->N4->ALL N2 office

89
3 CONCEPTION DE LA SOLUTION

N3 remunirationcenter
N4 Society
Dimension N1->ALL N1 Libelle_Motif_Inac
Motif_inactivité
Dimension N1->ALL N1 Libelle_Motif_Abs
Motif_absence
Dimension N1->ALL N1 Libelle_theme
theme
Dimension N1->ALL N1 Libelle_sous_theme
Sous_theme
Dimension N1->ALL N1 Libelle_Motif_depart
Motif_depart
Dimension N1->ALL N1 Type_Contrat
Contrat
Dimension N1->ALL N1 Libelle_GSP
GSP
Dimension N1->ALL N1 Sexe
Sexe
Dimension N1->ALL N1 Libelle_paie
Paie
Dimension N1->ALL N1 Age
Âge
Dimension N1->ALL N1 Libelle_classement
Classement
Dimension N1->ALL N1 Libelle_type_formatio
n
Type_formatio
n
Dimension N1->ALL N1 Libelletypebesoin
Type_besoin
Dimension N1->ALL N1 Libellespecialite
Specialite
Tableau 15 : niveaux hiérarchiques des dimensions
90
3 CONCEPTION DE LA SOLUTION

4.2.2 Présentation des cubes

Dans le tableau ci-dessous, les cubes dimensionnels réalisés avec leurs dimensions et
mesures sont représentés :

Cube Mesures Dimensions


Volet suivi de l’effectif
Suivi de l’effectif Nombre d’agents dim_temps
dim_organisation
dim_motif_activite
dim_motif_inac
dim_gsp
dim_classement
dim_sexe
dim_contrat
dim_age
Volet suivi des Recrutements
Suivie des recrutements Nombre d’embauches dim_organisation
dim_gsp
dim_contrat
dim_classement
dim_age
dim_sexe
dim_temps
Volet suivi de la masse salariale
Suivi de la masse salariale Moyenne montant masse dim_temps
salariale
dim_organisation
dim_gsp
dim_sexe
dim_paie
dim_contrat

91
3 CONCEPTION DE LA SOLUTION

dim_classement
Volet suivi des heures de travail
suivi des heures de travail Nombre d'employés dim_temps
absents
dim_organisation
dim_sexe
dim_motif_absence
dim_gsp
dim_contrat
Volet suivi des départs
Suivi des départs Nombre de demissions dim_temps
dim_organisation
dim_motif_depart
dim_age
dim_contrat
dim_gsp
dim_sexe
Volet suivi des formations
Suivi des formations Nombre de formations dim_temps
Nombre d’agents formés dim_organisation
dim_theme
dim_sous_theme
dim_type_formation
dim_type_besoin
dim_specialite
Tableau 16 : la structure des cubes MOLAP conçu pour l'analyse

4.3 Conception Des Rapports


Selon les besoins utilisateurs et d’après notre analyse, nous avons envisagé pour
concevoir deux types de rapports, ce découpage dépends du niveau hiérarchique de l’entreprise
pour l’utilisation du système
4.3.1 Pour les rapports concernant les sociétés :
Les PDG des sociétés ainsi les DRH peuvent consulter ces rapports, mais les utilisateurs
peuvent consulter que pour leurs sociétés, ces rapports sont décrit dans le tableau suivant :

92
3 CONCEPTION DE LA SOLUTION

Volet Rapports
1. Effectif permanent par GSP, Bureau gestionnaire et par période.
2. Effectif inactif par GSP, par Bureau gestionnaire et par période.
3. Effectif inactif par motifs, par Bureau gestionnaire et par
période.
Suivi de
l’effectif 4. Effectif par contrat (permanents et temporaires), par Bureau
5. Effectif par bureaux gestionnaires et par période.

1. Nombre d’embauches par type de contrat et classement par


période.
2. Nombre d’embauches par sexe et âge par période.
Suivi des
recrutements 3. Nombre d’embauches par bureau gestionnaire et service paie
par période.
4. Nombre d’embauches par période.
Suivi de la 1. Masse salariale par Bureau gestionnaire, par contrat et par
masse salariale période.
2. Masse salariale par Bureau gestionnaire, par GSP et par période.
3. Masse salariale par bureau gestionnaire, par sexe et par periode
4. Masse salariale par Rubrique paie, par GSP et par période.

1. Nombre d’absents par Bureau gestionnaire, par GSP et par


période.
2. Nombre d’absents par Bureau gestionnaire, par motif et par
période.
Suivi du
3. Nombre d’heures d’absence par GSP et motif.
temps de travail
4. Nombre d’heures d’absence par Bureau gestionnaire, par GSP
et par période.
5. Nombre d’heures d’absence par Bureau gestionnaire, par
motif et par période.
6. Nombre d’heures d’absence par GSP, motif et période.

1. Nombre d’heures en formation par bureau gestionnaire, par


type formation et par période

93
3 CONCEPTION DE LA SOLUTION

2. Nombre d’heures en formation par gsp, thème et par période


3. Nombre d’heures en formation par spécialité, thème et par
sous thème
Suivi des
formations 4. Nombre d’agent en besoin par bureau gestionnaire, par type
besoin et par spécialité
5. Nombre d’agent en besoin par thème, par sous thème et par
type de besoin
6. Nombre d’agent en besoin par bureau gestionnaire, par type
besoin et par temps.
Suivi des 1. Nombre de départs par Bureau gestionnaire, par GSP et par
départs période.
2. Nombre de départs par Bureau gestionnaire, par motif et par
période.
3. Nombre de départs par GSP, par motif et par période.
Tableau 17 : Contenu des rapports pour chaque société

4.3.2 Pour les rapports concernant tout le groupe :


Ces rapports sont consultés par le directeur opérationnel du capital humain (DOCH).
DOCH a un compte qui lui permet de voir Rapport de chaque filiales et rapport de synthèse sur
toutes les filiales du groupe,
Dans le tableau suivant nous avons exposé les rapports attribués à ce compte :
Volet Rapports
1. Effectif permanent par GSP, société et par période.
2. Effectif inactif par GSP, par société et par période.
Suivi de 3. Effectif inactif par motifs, par société et par période.
l’effectif
4. Effectif permanent par société, sexe et par période
5. Effectif par contrat (permanents et temporaires), par société et
par période.

1. Nombre d’embauches par société, type de contrat et


classement par période.
Suivi des
recrutements 2. Nombre d’embauches par société sexe et âge par période.
3. Nombre d’embauches par société, bureau gestionnaire et
service paie par période.
4. Nombre d’embauches par période.
1. Masse salariale par Société, par contrat et par période.

94
3 CONCEPTION DE LA SOLUTION

Suivi de la 2. Masse salariale par Société, par GSP et par période.


masse salariale
3. Evolution de la masse salariale par Société et par période.
4. Masse salariale par société, par sexe et par période

1. Nombre d’absents par société, par GSP et par période.


2. Nombre d’absents par société par motif et par période.
3. Nombre d’absents par société par sexe et par période.
Suivi du 4. Nombre d’heures d’absence par GSP et motif.
temps de travail
5. Nombre d’heures d’absence par société, par GSP et par
période.
6. Nombre d’heures d’absence par société, par motif et par
période.
7. Nombre d’heures d’absence par GSP, motif et période.

1. Nombre d’heures en formation par société, par type formation


et par période.
2. Nombre d’heures en formation par gsp, thème et par période
Suivi des
formations 3. Nombre d’heures en formation par spécialité, thème et par
sous thème
4. Nombre d’agent en besoin par société, par type besoin et par
spécialité
5. Nombre d’agent en besoin par thème, par sous thème et par
type de besoin
6. Nombre d’agent en besoin par société, par type besoin et par
temps.
Suivi des 1. Nombre de départs par société, par GSP et par période.
départs
2. Nombre de départs par société, par motif et par période.
3. Nombre de départs par GSP, par motif et par période.
Tableau 19 : contenu des rapports pour tout le groupe

4.4 Conclusion
Dans ce chapitre, nous avons détaillé la phase de conception de la solution et ses
différentes étapes, nous avons au début présenter l’architecture globale de la solution en
détaillant le fonctionnement de chaque composant ainsi que les interaction inter-composants,
avant de passer aux détails des étapes de la conception à savoir : la conception des zones
d’entreposage, d’alimentation et de restitution.

95
3 CONCEPTION DE LA SOLUTION

En se basant sur le travail réalisé dans ce chapitre, nous entamerons la phase de mise en œuvre
dans le prochain chapitre.

96
Quatrième Partie

IV. Réalisation et mise en œuvre

97
4 REALISATION ET MISE EN OEUVRE

Chapitre 1
1 Présentation Des Technologies Utilisées
1.1 Introduction
Dans cette partie, nous allons parler des outils utilisés pour mettre en place notre solution
proposée avec les différentes étapes partant de la première phase qu’est le chargement du lac
de données par ELT et ETL à la dernière qu’est le reporting.
Les choix que nous avons faits concernant les outils reposent principalement sur la stratégie
open source de “ELIT” ainsi que les résultats des recherches et comparaison entre outils.

1.2 Couche logiciel existante


1. Nova le système de gestion de ressource humaine est composé de deux bases de données
relationnelles qui sont déployées sous PostgreSQL sur le serveur central.
2. Le système NOVA quant à lui est déployé sur un serveur d’application Glassfish server.
3. Le système source fonctionne sur un data center tournant sous CentOS.
4. Toutes les machines utilisateurs sont sous Windows avec ces différentes versions
7/8/10.

1.3 Outils de réalisation de la solution


Dans cette partie, nous allons présenter tous les outils utilisés dans chacun des
composants de notre solution ainsi que la raison pour laquelle notre choix s’est porté sur ces
outils.
Nous entamerons la présentation des outils composant par composant.
1.3.1 Composant ELT :
Le rôle de ce composant principalement adapté à notre solution est d’alimenter le lac de données
que nous utilisons pour concevoir notre système est d’importer les données ressources humaines
extraient de deux bases de données PostgreSQL relationnel, afin que nous puissions créer notre
entrepôt de données virtuel,
Pour réaliser ce processus plusieurs outils ont été étudié, à travers cette étude nous avons
présenté deux outils adaptés à cette migration qui sont apache sqoop et spark SQL

Dans Apache Sqoop étant donné que chaque table de la base sera
stockée comme un fichier java qui s’appelle “mappers” dans le SGF
puis l’outils assure l'écriture dans hdfs, les mappers seront construit
après avoir utilisé le connecteur JDBC à la base de données, cet outil Figure SEQ Figure \*
offre aussi la possibilité d'exporter les données de “HDFS” a une autreARABIC
source de50
données,
: logo dans
de
apache
ce cas la migration vers le traditionnelle entrepôt de données est facilement sqoop
gérable.

98
4 REALISATION ET MISE EN OEUVRE

Malgré la différence entre le fonctionnement, spark sql peut importer les données vers HDFS,
mais apache sqoop est plus approprié pour la migration car il est spécialement conçu pour
migrer les données entre SGBD et HDFS, notons que le nombre des mappers est spécifié par
l’utilisateur dans sqoop ainsi le parallélisme est géré automatiquement, spark sql est largement
utilisé pour le traitement des requêtes et des données en parallèle.
1.3.2 Couche de stockage :
La couche de stockage physique de notre solution est sous la forme d’un lac de données.
Ici seront stockées toutes les données (structurées, semi-structurées ainsi que non structurées)
chargées à partir des sources des données existantes par le processus ELT. Le Data Lake sera
distribué sur plusieurs nœuds “Data Node” et qui contiendront des données répliquées.
En se basant sur les caractéristiques citées en dessus sur le type de données ainsi que le type du
support de stockage, ainsi que la stratégie open source suivie par ELIT, nous proposons ce
comparatif des meilleurs outils utilisés pour répondre à ce besoin :
1.3.2.1 Comparaison des outils créant un lac de données

Outil Hadoop Amazon Web PostgreSQL


Distributed File Services S3
System “HDFS”
Caractéristiques générales
Editeur Apache fondation Amazon POSTGRESQL
Année de création 2006 2006 1996
Communauté sur Grande Grande TRÈS GRANDE
internet
Facilité Moyenne Facile TRÈS FACILE
d’utilisation
Interface Oui Oui Oui
graphique
Open Source Oui Non Oui
Caractéristiques techniques
Données
distribuées sur
plusieurs clusters et Oui Oui NON
nœuds
Déploiement On premise et Dans le cloud On premise
dans le cloud seulement seulement
Types de données Tous les types Tous les types
pouvant être stockes supportés supportés
(structurées, non (structurées, non Données
structurées et semi- structurées et semi- structurées
structurées) structurées ) seulement

99
4 REALISATION ET MISE EN OEUVRE

Réplication de Oui Oui Non


données
Sécurité Connection SSH Sécurisée dans le
entre les différent cloud d’Amazon
nœuds Sécurisé

Tableau 20 : comparaison entre les outils de création du lac de données


En se basant sur la comparaison ci-dessus, nous avons choisi le système de fichiers
distribués de Hadoop “HDFS” comme technologie qui stockera les données de notre système
dans un lac de données. Il propose la solution la plus adaptée. En effet, il répond à toutes les
exigences de notre solution et en plus de cela fournit des fonctionnalités très intéressantes
1.3.2.2 Présentation de HDFS
Le HDFS est un système de fichiers distribué, extensible et
portable développé par Hadoop à partir du GoogleFS.
Écrit en Java, il a été conçu pour stocker de très gros volumes de
données sur un grand nombre de machines équipées de disques durs
banalisés. Il permet l'abstraction de l'architecture physique de
stockage, afin de manipuler un système de fichiers distribué comme
s'il s'agissait d'un disque dur unique.
Une architecture de machines HDFS (aussi appelée cluster HDFS)
Figure SEQ Figure \* ARABIC
repose sur deux types de composants majeurs :
51 : logo de Apache HDFS
▪ NameNode : nœud de noms, ce composant gère l'espace de Hadoop
noms, l'arborescence du système de fichiers et les
métadonnées des fichiers et des répertoires. Il centralise la localisation des blocs de
données répartis dans le cluster. Il est unique mais dispose d'une instance secondaire qui
gère l'historique des modifications dans le système de fichiers (rôle de backup). Ce
NameNode secondaire permet la continuité du fonctionnement du cluster Hadoop en cas
de panne du NameNode d'origine.
▪ DataNode : nœud de données, ce composant stocke et restitue les blocs de données.
Lors du processus de lecture d'un fichier, le NameNode est interrogé pour localiser
l'ensemble des blocs de données. Pour chacun d'entre eux, le NameNode renvoie
l'adresse du DataNode le plus accessible, c'est-à-dire le DataNode qui dispose de la plus
grande bande passante. Les DataNodes communiquent de manière périodique au
NameNode la liste des blocs de données qu'ils hébergent. Si certains de ces blocs ne sont
pas assez répliqués dans le cluster, l'écriture de ces blocs s'effectue en cascade par copie
sur d'autres.
1.3.3 Transformation des données
Ici se fait la transformation et la sélection des données devant être stockés dans l'entrepôt
de données dans le Datalake ici seront sélectionnés que les données nécessaires répondant aux
besoins décisionnels et transformé pour ne contenir que les données répondant à la solution déjà
exprimée auparavant dans la partie conception.
En se basant sur les besoins techniques citées en dessus, nous proposons ce comparatif des
meilleurs outils pouvant être utilisés pour répondre à ce besoin :

100
4 REALISATION ET MISE EN OEUVRE

Talend Open Azure Data Pentaho Data


Studio For Big
Outil Data Factory Intégration

Caractéristiques générales
Editeur Talend Microsoft Pentaho
Corporation
Année de création 2012 2014 2004
Communauté sur Faible Grande Moyenne
internet
Facilité Facile Facile Facile
d’utilisation
Interface Oui Oui Oui
graphique
Open Source Oui Non Oui
Caractéristiques techniques
Compatible avec
les technologies Big
Data Oui Oui NON

Types Application Dans le cloud Application


d’application Desktop
Desktop

Connection a Non Oui Non


Github
Ecrit sur du Java C# Java
Tableau 21 : comparaison entre les outils d'intégration de données
En se basant sur la comparaison ci-dessus, notre choix s’est porté sur Talend Open
studio for Big Data que nous avons jugé le plus adapté à notre besoin.
1.3.3.1 Presentation de Talend Open Studio For Big Data:

Talend Open Studio For Big Data est un outil gratuit et open source
pour traiter les données très facilement sur un environnement Big
Data. Nous disposons de nombreux composants Big Data
disponibles dans Talend Open Studio, qui nous permettent de créer
et d'exécuter des jobs Hadoop simplement par un simple glisser-
déposer de quelques composants Hadoop.
Figure SEQ Figure \* ARABIC
52 : logo de l'outil talend open
studio
101
4 REALISATION ET MISE EN OEUVRE

De plus, nous n'avons pas besoin d'écrire de grandes lignes de codes MapReduce.
Talend Open Studio Big data nous aide à le faire avec les composants qui y sont présents. Il
génère automatiquement du code MapReduce pour nous, il nous suffit de glisser-déposer les
composants et de configurer quelques paramètres.
Il nous donne également la possibilité de nous connecter à plusieurs distributions Big Data
comme Cloudera, HortonWorks, MapReduce, Amazon EMR et même Apache.
1.3.4 Infrastructure entrepôt de données
C’est le cœur de notre système décisionnel, Ce composant est créé à partir des données
stockées antérieurement dans HDFS.
Ici se fait la sauvegarde des métadonnées ou seront stockés les données structurées qui seront
utilisées pour répondre aux besoins décisionnels de l’entreprise.
En se basant sur les caractéristiques citées en dessus sur les caractéristiques de ce composant
ainsi que la stratégie open source suivie par ELIT, nous proposons ce comparatif des meilleurs
outils pouvant être utilisés pour répondre à ce besoin :
1.3.4.1 Comparaison des outils créant une infrastructure Data Warehouse

Outil Apache Hive Apache Pig


Caractéristiques générales
Editeur Facebook Yahoo
License Apache Foundation Apache Foundation
Année de création 2011 2008
Communauté sur internet Moyenne Moyenne
Facilité d’utilisation Facile Moyenne
Interface graphique Non Oui
Open Source Oui Oui
Caractéristiques techniques
Langages de traitement Hive QL( Hive Query
Language)
Pig Latin
Basé sur du Java Java
Compatibilité format Compatible avec Parquet, Compatible avec Parquet,
fichier Texte, Binaire Texte, Binaire et AVRO
Ecosystème Hadoop écosystème Hadoop Écosystème
Connectable avec Oui Non
Apache Spark
Basée sur MapReduce Oui Oui

102
4 REALISATION ET MISE EN OEUVRE

Contient le Meta data Oui Non


d’une base de données
Tableau 22 : comparaison entre les outils de création de la structure de données
En se basant sur la comparaison ci-dessus, notre choix tombe sur la couche logicielle
“Apache Hive” déployée sur la couche physique de HDFS comme technologie qui permettrait
de créer, remplir et traiter les données de l'entrepôt de données. En effet, il répond à toutes les
exigences de notre solution et en plus de cela fournit des fonctionnalités très intéressantes.
1.3.4.2 Présentation de Apache HIVE
Apache Hive est une infrastructure d’entrepôt de données intégrée sur
Hadoop permettant l'analyse, le requêtage via un langage proche
syntaxiquement de SQL ainsi que la synthèse de données Bien que
initialement développée par Facebook, Apache Hive est maintenant
utilisée et développée par d'autres sociétés comme Netflix.
Apache Hive prend en charge l'analyse des grands ensembles de
données stockées dans Hadoop HDFS ou des systèmes de fichiers
Figure SEQ Figure \*
compatibles tels que Amazon S3. Il fournit un langage similaire à SQL
ARABIC 53 : logo de
appelée HiveQL avec le schéma lors de la lecture et de manière transparente convertit les
apache hive
requêtes en mapreduce Java, Apache Tez et jobs Spark. Tous les trois moteurs d'exécution
peuvent fonctionner sur Hadoop YARN.
Par défaut, Hive stocke les métadonnées dans une base de données embarquée Apache Derby,
et d'autres bases de données client / serveur comme MySQL peuvent éventuellement être
utilisées.
1.3.5 Conception de cubes et analyse multidimensionnelle
Notre solution étant décisionnel et pour faciliter l’analyse multidimensionnelle,
plusieurs outils de construction des cubes OLAP existent, ces outils peuvent être complet (cube
+ analyse multidimensionnelle) ou bien séparé, la comparaison qui suit nous a permis de choisir
notre outil le plus adéquat pour notre paradigme :

Outil Apache Kylin Pentaho BI


Caractéristiques générales
Editeur Apache software Pentaho
foundation
License Apache Foundation EPL
Année de création 2013 2004
Communauté sur internet Moyenne Moyenne
Facilité d’utilisation Facile Moyenne
Interface graphique Oui Oui
Open Source Oui Community

103
4 REALISATION ET MISE EN OEUVRE

Modes de stockage de données


MOLAP Oui
non
ROLAP Non oui
HOLAP Non non
Offline Oui non
Autres Caractéristiques
Temps réel Oui non
Réécriture non oui
Partitionnement oui non
Équilibrage de charge et oui non
clustering
Connection a outil de Superset, Zeppelin, Tableau, oui
visualisation Qlik, Redash, Microsoft Excel

Modèle multi-cube oui non


connexion a une REST oui non
API
Capacité de stockage libre 256 pour chaque objet
(Community Edition)
Tableau 23 : comparaison entre les outils de l'analyse MOLAP

1.3.5.1 Présentation de l’outil Apache Kylin


Apache Kylin est un moteur de traitement d’analyse (OLAP) open source
distribué pour l'analyse interactive Big Data. Apache Kylin a été conçu pour
fournir une interface SQL et une analyse multidimensionnelle (OLAP) sur
Hadoop et Spark. De plus, il s'intègre facilement aux outils de BI via le
pilote ODBC, le pilote JDBC et l'API REST.
Il a été créé par eBay en 2014, est devenu un projet de haut niveau de la Figure SEQ Figure \*
Fondation Apache Software juste un an plus tard en 2015, et a remporté le ARABIC 54 : logo
meilleur outil de Big Data Open Source en 2015 ainsi qu'en 2016. d’Apache Kylin
Actuellement, il est utilisé par des milliers d’entreprises du monde entier en
tant qu'application d'analyse critique pour le Big Data. Alors que d'autres
moteurs OLAP ont encore du mal avec le volume de données, Kylin permet des réponses aux
requêtes en quelques millisecondes. Il fournit une latence de requête de niveau inférieur au
deuxième niveau sur des ensembles de données pouvant atteindre des pétaoctets. Il obtient sa
vitesse incroyable en pré calculant les différentes combinaisons dimensionnelles et les agrégats
de mesure via des requêtes Hive et en renseignant HBase (Un SGBD NoSQL dans le Hadoop
Écosystème) avec les résultats.
104
4 REALISATION ET MISE EN OEUVRE

1.3.6 Outil de conception des rapports


En respectant la politique open source du groupe, dans le big data et à travers l’outil
kylin, les outils BI auxquelles nous pouvons connecter ce dernier sont apache superset, tableau,
MSTR et Qlik Sense. Afin de choisir la meilleure plateforme qui répond à nos besoins, nous
avons élaboré un Comparaison entre ces outils
Les outils tableau ainsi Qlik Sense et MSTR et Superset tous peuvent faire du reporting, afficher
un tableau de bord, données en temps réel ainsi la gestion des permissions qui est essentielle
dans notre projet car nous avons plusieurs types de décideurs, mais Superset reste le seul outil
open source.

1.3.6.1 Avantages de APACHE SUPERSET

▪ Facilite la BI (facile à utiliser pour ceux qui ne sont


pas des programmeurs : vous avez seulement besoin
de connaître SQL de base)
▪ Configuration simple et rapide Figure SEQ Figure \* ARABIC 55 :
▪ Fournit «SQL-Lab» qui permet des requêtes interactives. logo de l'outil Apache Superset
▪ Une couche sémantique qui élargit le tableau de bord avec des ratios et d'autres
métriques (basées sur SQL)
▪ Vue interactive facile et attrayante, qui permet l'exploration des données
▪ Répond aux besoins de la plupart des entreprises pour permettre une analyse simple des
données.

1.3.7 Infrastructure Logicielle De La Solution


le schéma ci-dessous représente la connexion et les interactions entres les outils que
nous avons choisi

105
4 REALISATION ET MISE EN OEUVRE

Figure 56 : schéma représentant les flux entre les composants de l'écosystème

1.4 Conclusion
Dans ce chapitre, nous avons présenté les différents outils que nous avons utilisés dans
L'implémentation de notre solution en décrivant les critères et caractéristiques qui nous ont
poussés à opter pour ces technologies. En effet, ces outils sont open source et conformes à la
stratégie du Groupe Sonelgaz. Dans le chapitre suivant, nous présenterons en détail
l’implémentation et le déploiement de la solution.

106
4 REALISATION ET MISE EN OEUVRE

Chapitre 2
2 Réalisation Et Déploiement
2.1 Introduction
Suivant la phase de mise en œuvre du projet présenté ci-dessus, nous passons à la partie
décrivant la réalisation technique de la solution.
Cette dernière comporte le développement du lac de données, l'implémentation de la couche
Data Warehouse, la réalisation des processus ELT / ETL ainsi que le développement des cubes
multidimensionnel pour finir avec la phase de restitution des données.
Nous aborderons ensuite l’aspect sécuritaire de la solution, aussi bien logique que physique,
avant de présenter la politique de gestion de changement que nous avons établis pour réussir
l'intégration du nouveau système, pour enfin clôturer ce chapitre par une conclusion

2.2 Réalisation de la solution


La réalisation technique du système passe par plusieurs étapes comme présentés ci-après :
1. Implémentation du lac de données
2. Implémentation de l’infrastructure entrepôt de données dans le lac.
3. Réalisation du processus ELT / ETL
4. Développement des cubes multidimensionnels OLAP
5. Réalisation de la partie de restitution des données

Nous détaillerons dans ce qui suit chaque étape évoquée ci-dessus en décrivant le processus
de développement et en l’illustrant par des exemples.
2.2.1 Implémentation du data Lake
Un lac de données est composé de deux sous-systèmes. La partie donnée est assurée par
la mise en place d’un système de fichiers distribués.
Dans notre implémentation, le Data Lake repose sur le système de fichiers distribués HDFS
(Hadoop Distributed File System) utilisant la technologie du projet HADOOP.
Nous avons opté pour une configuration Multi-Node d’un cluster HDFS avec un facteur de
réplication égale à deux afin de profiter du Parallel Computing ( Traitement des données
parallèle ) sur les machines du cluster ainsi qu’une résistance aux pannes grâce à la redondance
en double des données.
Pour plus de détails, notre ensemble de serveurs HDFS, appelé cluster HDFS, est constitué de
trois machines ayant des rôles différents : deux DataNodes qui servent de nœuds de stockage et
un NameNode sous forme du nœud maître. Ce dernier gère les interactions avec les utilisateurs
ainsi que la distribution et la réplication des données sur les DataNodes.
107
4 REALISATION ET MISE EN OEUVRE

Le cluster HDFS peut être accessible de manière graphique en se connectant à son serveur web
à l’adresse https://namenode-ip-adress:9870 , l’administrateur du système utilise cette interface
pour administrer et faire le suivi du lac de données .
D’autres informations, telles que la santé du cluster,la quantité mémoire utilisée et disponible
sur les datanodes, ou l’accès aux logs ou bien encore l’accès au système de fichiers HDFS
peuvent être aussi retrouvés via cette interface. ci-dessous un aperçu de l’interface en question.

Figure 57 : interface graphique de l'outil HDFS

2.2.2 Implémentation de l'infrastructure entrepôt de données


L'implémentation de notre entrepôt de données virtuel est l'étape de création de la base
de données des modèles dimensionnels que nous avons conçu dans la partie “Conception de la
zone de stockage”.
L'entrepôt de données est réalisé dans l’outil Apache Hive ou les schémas des tables créées sont
enregistrés dans le Metadata de HIVE alors que les données seront mémorisées dans le
Metastore présente dans HDFS.
Nous avons commencé par la création des dimensions où chaque dimension représente une
table identifiée par une clé primaire et contenant d’autres attributs, nous sommes passés par la
suite à la création des tables des faits, ces dernières sont identifiées par une concaténation des
clés étrangères issues des différentes dimensions participantes au schémas en étoile.
La figure ci-dessous montre un exemple qui est la création de la table “Dim organisation” dans
Hive :

108
4 REALISATION ET MISE EN OEUVRE

Figure 58 : script de la création de la dimension organisation dans « Hive »


Nous évoquons aussi un cas spécial qu’est la création et alimentation de la dimension temps à
travers l’invité de commande d’Apache Hive, en effet , la dimension temporelle est présente
dans tout entrepôt de données ,et pour l’alimenter nous avons utilisé un script qui va générer
les dates à partir du 1 janvier 1962 jusqu’au 31 décembre 2028.( Nous avons choisis le
01/01/1962 parce que les données que contiennent les sources du système opérationnelle
commencent à partir de 1962)
Ci-joint une figure qui montre l'étape de création et alimentation de la dimension temps dans
Apache Hive

Figure 59 : script de la création et l'alimentation de la dimension temps


La figure ci-dessous donne un aperçu du contenu de notre base “novadwh” dans HIVE avec
toutes les tables créées :

109
4 REALISATION ET MISE EN OEUVRE

Figure 60 : liste des tables créées sous hive et stocké dans HDFS

2.2.3 Implémentation de l'ELT / ETL


Après implémentation de l’entrepôt de données, nous entamons la phase de l’ELT et l’ETL. La
réalisation de cette phase passe par les étapes suivantes :
2.2.3.1 Création des connexions
La première phase du processus ELT / ETL consiste à connecter les différentes couches de
stockage, sources aussi bien que cible, à l'outil Talend Open Studio For Big Data.
Les systèmes de stockage que nous devons connecter sont :
1. La base de données relationnelle du système NOVA
2. Les fichiers Excel
3. Le lac de données sous HDFS
4. L’entrepôt de données virtuel sur HIVE
La figure ci-après montre les connexions que nous avons créées sur Talend :

110
4 REALISATION ET MISE EN OEUVRE

Figure 61 : les métadonnées de connexion sur Talend


2.2.3.2 Extraction
C’est la première étape du processus ELT / ETL, elle consiste à extraire les données des
différentes sources de données de notre système et les charger dans le lac de données bâti sur
HDFS.
La phase d’extraction des données se compose elle-même en deux phases selon le type de la
source de données.
Nous présentons ces derniers dans ce qui suit :
▪ Transfert des données depuis le SGBD de NOVA vers le data lake
La première phase consiste à transférer les données présentes dans le système de stockage du
système opérationnel NOVA vers le lac de données sans aucune modification.
Afin d’accomplir notre objectif, nous utilisons l’outil Apache Sqoop qui permet le transfert
intégral de données entre une base de données relationnelle et Hadoop Distributed File System.
La figure ci-après montre la commande utilisée pour lancer le job de transfert de données vers
HDFS :
111
4 REALISATION ET MISE EN OEUVRE

Figure 62 : commande d'importation de toutes les tables de la base de données


PostgreSQL vers HDFS

▪ Transfert des données depuis les fichiers Excel au data lake


La deuxième phase de l’extraction consiste à transférer les données présentes dans les
fichiers Excel utilisés pour la gestion des ressources humaines de Sonelgaz vers le lac de
données sans aucune modification.
Afin de parvenir à nos fins, nous utilisons l’outil Talend Open Studio For Big Data qui nous
permet de transférer le fichier Excel directement à partir du disque vers le lac de données. La
figure suivante montre le job qui permet le transfert du fichier Excel vers HDFS :

Figure 63 : job du chargement des données de la paie du fichier Excel vers Hive

2.2.3.3 Transformation et Chargement


Les données, dans le processus ETL, avant d’être stockées dans HIVE subiront dans un
premier temps, différentes opérations dans le cadre de la phase transformation notamment du
nettoyage, traitement des valeurs nulles, jointures des différentes dimensions, agrégation des
données et conversion en cas de nécessité.
La partie transformation dans le processus ELT ne sera pas pris en considération dans le cadre
de ce projet , car son utilisation est nécessaire dans des projets de machine Learning. Ci-après
un exemple qui montre le processus de transformation du volet Suivi des formations
2.2.3.3.1 Processus de transformation du volet Suivie des formations
Dans cet exemple, Nous commençons par récupérer les données relatives aux formations,
pour après traiter les null avec le composant Treplace , nous procédons par la suite en jointant
, à l'aide du composant Tmap , les données avec toutes les dimensions participantes au volet
pour récupérer les clés artificielles que nous stockerons dans la table des faits, pour enfin finir
par agréger les données , en utilisant le composant TAggregateRow sur toutes les dimensions
pour calculer nos mesures qui sont le nombre d’absents par opération somme , et le nombre
d’agents absent par opération Count.La figure ci-après présente le processus en question :

112
4 REALISATION ET MISE EN OEUVRE

Figure SEQ Figure


Figure \* ARABIC
64 : Job 64 : job et
du chargement dualimentation
chargement et
dealimentation de la« table
la table des faits Suiviefait
dessuivi des
formations
formations »
Dans un deuxième temps, nous utilisons les données déjà transformées auparavant et qui sont
d’ailleurs des données bien préparées et prêtes à être chargées dans l'entrepôt de données
seulement si elle n’existe pas déjà dans HDFS dans ce format auparavant et donc une étape de
vérification avant le chargement s'avère nécessaire.
A l’aide du composant TMap, nous comparons les données déjà présentes avec ceux à charger
afin de ne charger que les nouvelles données à la table des faits. La figure ci-après présente le
processus en question :

Figure 65 : Le mécanisme de mise à jour des données

Figure SEQ Figure \* ARABIC 65 : le mécanisme qui garantit la mise à jour des tables de fait
113 après le
lancement des jobs
4 REALISATION ET MISE EN OEUVRE

2.2.4 Développement des cubes


Après l'implémentation et alimentation de l'entrepôt de données de notre système vient
la phase de création des cubes multidimensionnel OLAP.
Afin de parvenir à nos fins, nous avons utilisé l’outil Apache Kylin du projet Hadoop, nous
interagissons avec ce service par le biais de l’interface web sur le port 7070 via le lien :
http://namenode-ip-adresse:7070/kylin.
Nous décrivons dans ce qui suit les étapes de création des cubes MOLAP avec Kylin, nous
prenons l’exemple du cube "Suivi Formations" :
▪ La première étape consiste à se connecter à la plateforme en entrant les coordonnées
d’authentification (username : ADMIN / password : KYLIN par défaut)

Figure 66 : fenêtre d'authentification de KYLIN


▪ La deuxième étape consiste à charger les tables de la base de données précédemment
créé sur HIVE vers KYLIN.

Figure 67 : Modèles des volets dans Apache Kylin

114

Figure SEQ Figure \* ARABIC 67 : la source de données importée au sein de


KYLIN
4 REALISATION ET MISE EN OEUVRE

▪ Avant de créer un cube, nous devons définir un modèle de données. Le modèle de


données définit un schéma en étoile ou flocon de neige. C'est-à- dire que nous
définissions toutes les dimensions avec leurs hiérarchies ainsi que la table de fait du
schéma en étoile, les attributions des dimensions ainsi que les mesures à calculer.
Ci-joint une figure qui montre la liste des modèles créés dans le contexte du projet :

Figure 68 : modèles des différents volets


▪ Et finalement et après Création du modèle, nous passons à la création du cube, nous
définissons les dimensions participantes ainsi que les attributs que nous cherchons, les
mesures à calculer, ainsi que plusieurs paramètres avancés concernant le build du cube
Notamment le Framework utilisé pour le build, l’application ou pas d’un filtre et bien
d’autre. La figure ci-joint montre la liste des cubes créés dans le contexte du projet :

Figure SEQ Figure \* ARABIC 69 : les cubes conçus pour l'analyse

Figure 69 : les cubes conçus pour l’analyse dans Apache Kylin


115
4 REALISATION ET MISE EN OEUVRE

2.2.5 Réalisation de la phase Reporting


Après la phase de développement des cube MOLAP du cube OLAP, nous arrivons enfin
à l’étape finale du processus de réalisation de la solution et qui est la création des tableaux de
bords.
Nous avons utilisé l’outil Apache Superset dans la conception et réalisation des tableaux de
bords, ce dernier offre une interface graphique spécialement conçue à la conception des
tableaux de bords contenant une palette de composants et de graphiques.
Apache Superset peut être accessible de manière graphique en se connectant à son serveur web
à l’adresse https://namenode-ip-adresse:7007/superset pour accéder aux différentes
fonctionnalités qu’offre cet outil.
Nous avons aussi créé différents utilisateurs dans Superset pour gérer les privilèges accordés à
chaque utilisateur du système (PDG du groupe , DHOC , DRH Societe ...etc.) avec un compte
ADMIN qui sera accordé à l’administrateur du système. Ce dernier pouvant ajouter, modifier
et supprimer n’importe quel utilisateur.
Nous présentons dans ce qui suit les étapes suivies pour créer un tableau de bord :
▪ La première étape consiste à se connecter à la plateforme en entrant les coordonnées
d’authentification, nous utiliserons les coordonnées de l’utilisateur admin dans notre
exemple.
▪ Une fois la connexion établie, nous procédons à l'écriture des différentes requêtes sur le
Cube dans l’onglet SQL-Lab afin d’extraire les datasets souhaitées.

Figure SEQ Figure \* ARABIC 70 : requête sql sur le cube des formations sur superset

Figure 70 : Requête SQL sur le cube des formations dans Apache Superset
Ci-joint une figure qui montre l’interface en question :

116
4 REALISATION ET MISE EN OEUVRE

▪ La deuxième étape consiste à connecter Superset à Apache Kylin, pour cela nous
utilisons la bibliothèque Python KylinPy.
▪ Nous entamons la partie réalisation du tableau de bord, pour cela nous utilisons les
Datasets sauvegardés auparavant comme base pour concevoir des graphiques.
▪ Une fois les graphiques prêts, nous finalisons le tableau de bord par un simple “Drag &
Drop” des graphiques dans le Dashboard.

Figure SEQ Figure \* ARABIC 71 : un graphique burnset qui affiche le


nombre des participants par type de formation et part sous thème
Figure 71 : Un graphique BurnSet qui affiche le nombre de participants par type de
formation et sous thème
Voici ci-joint un exemple de tableau de bords créée dans le cadre du projet relatif au volet
“Suivie des formations“

117
4 REALISATION ET MISE EN OEUVRE

Figure 72 : tableau de bord pour le suivi des formations

118
4 REALISATION ET MISE EN OEUVRE

2.3 Sécurité du système


La sécurité est primordiale dans tout projet informatique, c’est un aspect critique étant
donné son importance pour l’entreprise, et de ce fait, tout au long du projet nous avons abordé
ce côté avec très grande prudence.
En effet, nous avons mis en place une politique de sécurité à deux niveaux que nous allons
présenter dans ce qui suit :
2.3.1 Sécurité applicative
La sécurité applicative désigne les mesures prises pour sécuriser les données du système mis en
place, parmi les dispositions mises en place ce qui suit :
1. Déploiement de la solution au sein du réseau interne de Sonelgaz : Le réseau interne
de Sonelgaz est très sécurisé et Pour y accéder, vous devez passer par un serveur proxy
et vous authentifier par une authentification Active directory avec un compte dédié.
2. Sécurité des données : l'accès aux données présentes dans le lac de données est
impossible, Hadoop stock les données dans le lac dans un format codifié illisible aux
humains.
L'accès à la plateforme de création des cubes “Apache Kylin” quand a elle se fait par
authentification.
3. Sécurité des tableaux de bords : L’accès à la plateforme “Apache Superset” se fait à
travers un client léger et requiert une authentification Active directory au réseau de
Sonelgaz pour pouvoir accorder une session au demandeur. Nous avons également
utilisé le gestionnaire d’utilisateurs d’Apache Superset pour définir les rôles et les
privilèges de chaque utilisateur.
Chaque demandeur d’accès doit donc avoir un compte au préalable.
La figure ci-joint montre un exemple des utilisateurs utilisés au sein d’Apache Superset.

Figure 73 : création des comptes utilisateurs et attribution des rôles

2.3.2 Sécurité physique

119
4 REALISATION ET MISE EN OEUVRE

Le deuxième aspect de la sécurité est la sécurité physique, en effet, le système mis en


place est déployé et hébergé au niveau du DataCenter d’ELIT , c’est une salle froide dont l'accès
est interdit à tout le monde excepté aux administrateurs.
Le DataCenter est aussi muni de plusieurs dispositifs sécuritaires anti-désastre tels que les
systèmes d’extinction d’incendie chimiques, des systèmes d’alarmes, des caméras de
surveillance et bien plus encore.

2.4 Mesures d'intégration du système


Nous avons bien évidemment, dans le cadre de lutter contre la résistance au changement
au sein de l’entreprise au niveau du système mis en place, instaurer des mesures et dispositions
servant à familiariser les utilisateurs et concernées du nouveau système.
Nous avons d’abord rédigé une documentation détaillée du système mis en place pour permettre
une utilisation ainsi qu’une configuration plus facile si nécessaire, nous avons par la suite
organiser une séance de formation qui a pour but de présenter le produit aux concernées et
d’initier ces derniers aux fonctionnalités de ce dernier

2.5 Conclusion
Tout le long de ce chapitre, nous avons présenté les étapes de concrétisation de notre
solution en partant de l'implémentation du lac de données, l’implémentation de l'entrepôt de
données virtuel , la réalisation des processus ELT , le développement des cubes
multidimensionnel pour arriver vers la concrétisation des rapports.
Nous avons aussi mis l’accent à travers ce chapitre sur l’aspect sécuritaire de la solution mis en
place avant de présenter la politique d'intégration de la solution au sein de l’entreprise que nous
avons mis en place.

120
REFERENCE BIBLIOGRAPHIQUES

Conclusion Générale Et Perspectives


Conclusion
Le groupe Sonelgaz, leader national de la production et de la distribution d'électricité et
de gaz naturel vise à être parmi les leaders mondiaux dans son domaine, très conscient que la
concurrence est rude de nos jours et qu'une amélioration continue de sa structure sur tous les
aspects s’impose, la nécessité de mettre en place de plus en plus de systèmes informatiques
décisionnels a vu le jour. En effet, ces derniers permettent aux décideurs de prendre des
décisions au moment opportun en se basant sur un volume d’information très important.
Le Groupe Sonelgaz a mené ces dernières années des projets informatiques visant
principalement à améliorer la gestion interne du groupe. Nous pouvons citer parmi ces derniers
le système de gestion des ressources humaines appelé NOVA.
Depuis sa mise en production, il a produit des débits de données immenses, ceci a incité les
décideurs à exprimer la volonté d'utiliser cette mine d’information de manière à mieux analyser
les activités de gestion des ressources humaines et améliorer le processus de prise de décision
en fournissant les informations correctes au bon moment.
Nous avons bien évidemment entamé notre projet par un travail de synthèse au cours duquel
nous avons introduit les concepts liés aux systèmes décisionnels et la gestion des ressources
humaines. Cette étape critique nous a permis de forger une bonne base qui nous a été très utile
pour gérer les différentes étapes du projet.
Après la présentation de l’organisme d’accueil, nous sommes passées à l'analyse de l’existant
opérationnel et décisionnel en s'accentuant sur la procédure de reporting actuelle au niveau du
groupe et sociétés avant d'établir un diagnostic de l'existant montrant les limites du système
existant, les causes engendrant ces dernières et les conséquences qui en découlent.
Ensuite, notre attention s'est tournée vers les décideurs pour identifier leurs besoins à travers
des réunions et des interviews.
Juste après, et en se basant sur les besoins identifiés auparavant, nous avons entamé la
conception de notre système en commençant par une architecture générale de la solution
décrivant chaque composant ainsi que les interactions entre eux, nous sommes par la suite passé
à la modélisation de la zone d'entreposage, la zone d'alimentation avant d'achever notre
conception par une modélisation de la zone de restitution des données.
La dernière partie de notre travail consiste à mettre en œuvre la solution proposée.
Tout d'abord, nous avons présenté les différents outils que nous avons utilisés pour aboutir à
nos fins puis nous avons introduit les différentes étapes de mise en œuvre.
Nous avons réalisé un système d'aide à la décision fonctionnel construit autour d'un écosystème
Big Data fournissant des données fiables et pertinentes accessibles via des cubes
multidimensionnels, rapports et graphiques.

121
REFERENCE BIBLIOGRAPHIQUES

Nous avons par la suite présenté l'aspect sécuritaire du système et les mesures mises en place
pour renforcer ce dernier ainsi que la politique d'intégration du système mis en place au sein de
l'entreprise.
A la fin de ce travail, nous avons pu atteindre les objectifs soulignés au début du projet et qui
sont :
1. Centraliser l’ensemble des données pour permettre un accès plus facile et rapide.
2. Diminuer le nombre de personnes impliquées dans le processus de reporting actuel à
une seule personne.
3. Diminuer considérablement le temps total de préparation des rapports de plusieurs jours
à quelques minutes.
4. Fournir aux décideurs et aux analystes la possibilité de naviguer dans les données et
d'effectuer des analyses appropriées concernant les processus RH de l’organisation.
5. Déterminer les mesures adéquates afin de permettre d’analyser les volets RH existants
(effectif, départs, embauches, masse salariale, absences et formation)

Perspectives
Dans le cadre de l'amélioration continu et dans le but de perfectionner le système mis en
place, nous envisageons un ensemble de perspectives à mettre en place, notamment :
▪ Centraliser le Stockage de toutes les données de l’entreprise au sein du lac de données
▪ Recueillir les suggestions et les remarques des utilisateurs pour pouvoir faire évoluer
le système
▪ Aller vers des analyses poussées avec le data Mining et machine Learning.

122
REFERENCE BIBLIOGRAPHIQUES

Références Bibliographiques
[Adamson 2012] Adamson, Christopher : Mastering data warehouse

aggregates : solutions for star schema performance. John Wiley & Sons,
2012.
[ALPHONSE CARLIER, 2013] ALPHONSE CARLIER : Business intelligence and
management, AFNOR edition , September 2013

[ALEX GORELIK , 2019] , Alex Gorelik ,The Enterprise Big Data Lake: Delivering
the Promise of Big Data and Data Science , Mars 2019

[Bédard et Rivest, 2001] Bédard Yvan & S.Rivest. Analyse

multidimensionnelle et système d’information géographique appliqués à

l’analyse de données de gestion routière , 2001

[BEN HASSEN, 2011] NOURA Ben Hassen, Le développement de l’employabilité


dans les organisations : une aide à la rénovation de la Gestion des Ressources
Humaines et à l’accroissement de performances économiques et sociales Cas
d’entreprises industrielles tunisiennes. Thèse doctorat en science de gestion. Ecole
doctorale art et métiers de la CNAM. 2011

[Boudreau et Milkovich, 1999]Boudreau & Milkovich ,Research in Personnel and


Human Resources Management: Strategic Human Resources Management in the
Twenty-First Century , 1999.

[Corr et Stagnitto 2013] Lawrence Corr et Jim Stagnitto, “Agile Data Warehouse
Design : Collaborative Dimensional Modeling, from Whiteboard to Star Schema”,
Decision One Press, Novembre 2011, 328p

[Christophe Legrenzi, 2011] Christophe Legrenzi , Les tableaux de bord de la


DSI: Pilotage, performance et benchmarking du système d’information, 2011, 272
pages.

[Dean J., et al. 2008] Jeff Dean , Sanjay Ghemawat , MapReduce:

Simplified data processing on large clusters , 2008

123
REFERENCE BIBLIOGRAPHIQUES

[DOLAN et al. ,2002] Dolan, S. L. , Gosselon, E., Carrière, l et

Lamoureux, Psychologie du travail et comportement organisationnel.

Boucherveille : 2e édition, Ed Gaëtan Mori


[Dhruba Borthakur, 2007] Dhruba Borthakur , The Hadoop Distributed File
System:Architecture and Design , 2007

[Ferragu et al., 2013 ] Emmanuel Ferragu, Modélisation des systèmes


d’information décisionnels , Vuivert Sub Informatique , 2013

[Gray et al, 1996] Gray, Layman, A. & Reichart. A relational aggregation


operator generalizing group by,cross-tab,and sub-totals. New Orleans , 1996
[Gilles Exbrayat et al, 2010] Gilles Exbratayt , Nathalie Fisteberg , Ronan
Fouesnant , Le système d’information des ressources humaines : Un atout dans
l’optimisation de la GRH au service de l’entreprise , octobre 2010
[Inmon et al., 2001] Inmon, W.H., Joyce Montanari, Bob Terdeman, and Dan
Meers. Data Warehousing for E-Business. New York: John Wiley & Sons. 2001.

[James G. Shanahan, et al. 2015 ] James G. Shanahan , Laing Dai , Large Scale
Distributed Data Science using Apache Spark , 2015

[James Manyika et al., 2011] James Manyika, Big Data: The Next Frontier for
Innovation, Competition, and Productivity , 2011

[Johannes Passing , 2012] Johannes Passing , The Google File System and its
application in MapReduce , 2012

[KIMBALL, 2013] KIMBALL R, MARGY R. The Data warehouse toolkit: The


Definitive Guide to Dimensional Modeling. 3rd Edition, United States of America:
John Wiley & Sons, 2013, 3-4p.

[Kimball et Ross, 2013] Kimball, Ralph ; Ross, Margy : The data warehouse
toolkit : The definitive guide to dimensional modeling. John Wiley & Sons, 2013.

[KHOURI, 2008] KHOURI S. , Modélisation conceptuelle à base

ontologique d’un entrepôt de données. Thèse de magistère en


informatique. Alger : Institut National de Formation en Informatique
(I.N.I), 2008.
[Kulin, S. Et al. (2015)] Kulin , Review of modern business intelligence and
analytics in 2015 :How to tame the big data in practice ? : Case study-What kind of
modern business intelligence and analytics strategy to choose ? , 2015
124
REFERENCE BIBLIOGRAPHIQUES

[Larbi, 2018] LARBI Abdelmadjid, Conception des entrepôts de données :


évaluation des besoins flexibles. Thèse doctorat en informatique. Alger :
UNIVERSITE DJILLALI LIABES FACULTÉ DES SCIENCES EXACTES SIDI BEL
ABBES , 2018
[Michael Armbrust , et al. ,2021 ] Michael Armbrust , Ali Ghodsi , Reynold Xin ,
Matei Zaharia , Lakehouse: A New Generation of Open Platforms that Unify Data
Warehousing and Advanced Analytics , 2021

[MILOSLAVSKAYA, 2016], Natalia Miloslavskaya, Alexander Tolstoy, Big Data,


Fast Data and Data Lake Concepts,2016,Pages 300-305

[McMahan G.C Virick M. et wright P.M. (1999)],McMahan , Virick , wright


"Alternative Theoretical perspectives for Strategic Human Resources Management
Revisited: Progress Problems, and Prospects", in P'M' Wright , strategic Human
Resources Management in the Twenty First Century, Supplement 4,Jai Press Inc',
Stamford 99-12
[Parth Wazurkar et al, 2017] Parth Wazurkar , Robin Singh Bhadoria , Dhananjai
Bajpai , "Predictive analytics in data science for business intelligence solutions" , 2017

[Reix et al., 1995] Robert Reix, Systèmes d'information et management des


organisations, Éditions Vuibert, First Edition ; 1995, 367 pages

[Rivière et al., 2014] Guillaume Rivière, Informatisation du Système


d’Information, ESTIA 2ème Année , Dernière révision :Avril 2014 ESTA, Pays
Basque.

[Snell S., Youndt M. et Wright P. (1996)] Snell , Youndt , Wright "Establishing a


Framework for Research in Strategic Human Resource Management: Merging
Resource Theory and Organizational Learning", Research in Personnel and Human
Resources Management, Y oI.14, p.67-9

[TESTE ,2000] TESTE O , Modélisation et manipulation d'entrepôts de données


complexes et historisées. Thèse doctorat en informatique. Toulouse : Université Paul
Sabatier de Toulouse (sciences) ,2000 ,5-6p

[VALLEMONT,1999] Serge VALLEMONT, GESTION DES RESSOURCES


HUMAINES DANS L'ADMINISTRATION. Rapport au ministre de la fonction
publique, de la réforme de l'état et de la décentralisation, 1999

[ZHAOHAO, HUASHENG, 2015], ZHAOHAO SUN, HUASHENG ZOU, Big Data


Analytics as a Service for Business Intelligence, p 200-211.

125
REFERENCE BIBLIOGRAPHIQUES

WEBOGRAPHIE
[Ali Ghodsi et al. , 2021] Ali Ghodsi , Brooke Wenig , Webinar “Lakehouse
Architecture : From Vision to Reality”disponible sur
https://databricks.com/fr/p/webinar/lakehouse-architecture-from-vision-to-reality

[Bastien L , 2018] Bastien Laurence "OLAP : définition d’une technologie


d’analyse multidimensionnelle" , 2018 , Blog online disponible sur :
https://www.lebigdata.fr/olap-online-analytical-processing

[Dave Wells , 2021] Dave Wells , Eckerson group blog “An Architect’s View of the
Data Lakehouse: Perplexity and Perspective” disponible sur : “
https://www.eckerson.com/articles/an-architect-s-view-of-the-data-lakehouse-perplexity-
and-perspective “

[Josh Parenteau , 2017] blog by Josh Parenteau “Self-service business


intelligence: definitions and examples” , 2017 , disponible sur
https://www.tableau.com/learn/articles/business-intelligence/self-service-bi

[Laurent Brisson et al,2018] Laurent Brisson et Sylvie Huchet "Architecture d'un


systeme décisionnel, Inmon vs Kimball , Business Intelligence" 2018 Disponible sur "
https://formations.imt-
atlantique.fr/bi/presentations/concepts/data_warehouse_design.html#1

[Rupal Bhandari , 2020] Rupal Bhandari , blog « Traditional vs. Self-Service BI:
Analytics Alternatives Explained » Software Advice , Juin 12, 2020 , disponible sur “
https://www.softwareadvice.com/resources/traditional-bi-vs-self-service”

126
ANNEXE

1
ANNEXE

1. CONDUITE DE PROJET
1.1 DIAGRAMME DE GANTT DU PROJET

Figure 74 : diagramme de gantt pour la conduite du projet

1.2 MÉTHODOLOGIE DE GESTION DE PROJET


Le projet de la mise en place d’un SID dans une grande entreprise comme Sonelgaz est sans doute un
projet a besoin instable. Donc la méthodologie qui convient à ce type de projet devrait être agile. En effet,
cette approche propose de réduire considérablement l’aspect du non-clarté des choses et donne de la visibilité,
en impliquant le client du début à la fin du projet et en utilisant à la fois un processus itératif et incrémental.
La méthodologie agile qui englobe les besoins de la gestion de projet dans notre cas est Scrum qui est la
méthodologie la plus populaire parmi les méthodes agiles existantes et celle qui donne un résultat à la fois
satisfaisant et plus rapide.
Scrum étant un paradigme de gestion de projet. Il est constitué d'une définition des rôles, de réunions et
d'artefacts. Pour garantir son application il est recommandé de définir trois rôles principaux qui sont le Product
Owner, le Scrum Master et l’équipe du projet. La projection de ces rôles sur notre projet donne :
Product Owner : Dans notre cas c’est le département de maintenance SI de ELIT représenté par le chef de
département Mr. SENNAD BELAID.
Scrum Master : Dans notre cas c’est l’ingénieur en BI et en SIAD Mr AMARA AYOUB ABDELDJALIL
ainsi quelque membre de maintenance de NOVA
Equipe de développement : Nous les étudiants SEDJAL et BOUTOUILI
Le cycle de vie Scrum est rythmé par des itérations de quelques semaines appelées Sprints. Nous et notre
scrum master avons mise dans notre projet un sprint chaque semaine, pour la discussion sur l’état
d’avancement ainsi que les problèmes que nous avons vécus. Une fois validée, une autre sera tracée pour la
semaine à venir. Une fois un volet réalisé une présentation pour le Product owner est programmée

2
ANNEXE

Pour discuter sur les besoins et l’aspect fonctionnel, nous organisions une réunion avec les membres qui
travaille sur NOVA

1.3 INTERVIEW
La collecte d’information est une l’étape la plus critique dans la documentation
d’un projet. Car elle permet d’enlever les questions et les énigmes qu’elle se pose.
Ainsi, pour divulguer les besoins du client nous avons décidé de faire une interview
avec une source crédible au sein du projet, à savoir Mr SENNAD le Product owner.

Q : Quels sont vos objectifs majeurs qui vous ont poussé à penser à ce projet ?
R : L’absence d’un système de visualisation de données ainsi leurs
consolidations sur la fonction RH qui est sensible dans le groupe Sonelgaz.
Q : Comment envisager vous réaliser la solution et comment elle va-être déployé ?
R : la solution doit être conçue indépendamment du système nova car on
compte migrer vers un autre système qui est en cours de test.
Q : Aux alentours de combien est le chiffre de l’effectif de Sonelgaz ?
R : Aux alentours de 100k sur tout le groupe ainsi leurs informations
consomment une partie majeure du data center de Sonelgaz.
Q : Comment est conçu le processus du réporting de Sonelgaz et quels sont les acteurs
qui participent ?
R : le processus se déclenche lorsque les PDGs des sociétés ou bien les
responsables veulent avoir un rapport, la demande sera traitée par ELIT et puis on
envoi le rapport, pour les acteurs qui utilisent le reporting RH, c’est les drh des
sociétés, les PDGs des sociétés, ainsi la DOCH.
Q : Quelle est la politique principale d’ELIT ?
R : ELIT, étant une filiale de Sonelgaz sa politique est de concevoir des
solutions informatiques aux différents clients (société de Sonelgaz, ou externe), qui
sont à la fois sécurisé, maintenable et open source.
Q : Les solutions sur un environnement Big data, surtout lorsque nous avons une
grande masse de données comme celle de la RH, que pensez-vous ?
R : Actuellement c’est une tendance des entreprises d’utiliser les technologies
Big data et cloud car elles sont performantes et précise ainsi donnent des résultats en
temps réel.
Q : Quels sont les différents données RH et combien de processus traite le système
NOVA ?
R : ils traitent plusieurs processus mais les plus importants sont : le suivi de
l’effectif, le suivi des paies, le suivi des absences, des formations, des arrivés ainsi les
départs.
Q : Quels sont les types de rapports que vous voulez ?
R : des rapports périodiques statiques, et des rapports dynamiques.
Q : Quels sont vos attentes du système décisionnel ?
R : Un système de qualité qui est facilement maintenable, rapide et sécurisé,
qui permet de faciliter l’analyse a travers des graphiques simple et personnalisable.

3
ANNEXE

2. CANEVAS DES TABLEAUX DE BORDS

2.1Canevas de reporting au niveau des sociétés

Figure 75 : calcul de l'effectif permanent actif


Figure - Canevas pour le calcul de l'effectif permanent

Figure - Canevas du calcul de l'effectif indisponible


Figure 76 : calcul de l'effectif indisponible

Figure 77 : calcul des absences par motif

4
ANNEXE

Figure 78 : calcul de l'effectif par groupe SP


Figure - Canevas de l'effectif temporaire par GSP

Figure 79 : calcul des départs par motif de départ et par group SP

Figure - Départs par motif et par GSP

Figure 80 : calcul des départs par motifs

5
ANNEXE

Figure 81 : calcul des heures d'absences par motif d'absences et par employés
Figure - Heures d'absence par motif et BG

Figure 82 : calcul des heures d'absences par groupe SP et par motif d'absences
Figure - Heures d'absence par GSP et motif

6
ANNEXE

2.2 Canevas de reporting au niveau de la holding

Figure - Heures d'absence par GSP et motif

Figure - Canevas de l'effectif global

Figure 83 : calcul de l'effectif global

Figure 84 Figure - Canevas de l'effectif permanent global par GSP


: calcul de l'effectif global par société et par groupe SP

Figure 85 : calcul des nombres d'absences par société et par motif d'absence

7
ANNEXE

Figure 86 : calcul des départs permanents par société et groupe SP


Figure - Départs définitifs des permanents par GSP

Figure 87 : calcul des départs temporaires par société et groupe SP


Figure - Départs définitifs des temporaires par GSP

Figure 88 : calcul des départs par motif

Figure - Evolution de la masse salariale


Figure 89 : croissance de la masse salariale par société
8

Vous aimerez peut-être aussi