2020 - 2021

INFORMATIQUE

Conception et implémentation d'un

Cockpit d'administration pour SHR
Analytics v4

Réalisé par: FOURATI Karim

Encadrant ESPRIT: ZEMZEM Amina

Encadrants Entreprise: DAOUD Hamdi

MATOUSSI Iheb
J’autorise l’étudiant à faire le dépôt de son rapport de stage en

vue d’une soutenance.

Encadrant professionnel, Monsieur Hamdi DAOUD

Signature et cachet

J’autorise l’étudiant à faire le dépôt de son rapport de stage en

vue d’une soutenance.

Encadrante académique, Madame Amina ZEMZEM

Signature
Dédicaces

Je dédie ce travail :

À mes parents Hamed et Lamia,

Aucune dédicace ne pourrait exprimer la profondeur des sentiments que j’éprouve

pour vous. Vous avez guetté mes pas, et m’avez couvé de tendresse, vos prières
et bénédictions m’ont été d’un grand secours pour mener à bien mes études.

J’espère que vous trouvez dans ce travail toute ma reconnaissance et mon amour

À mon frère Malek,

Ta bonté, ton encouragement tout au long de mes années d’étude, ton amour
et ton soutien, ont été pour moi l’exemple de persévérance.

À tous les membres de ma famille,

Il me tient énormément à coeur de vous dire MERCI d’être ma famille, et de

m’avoir donnée de solide racine pour m’épanouir.

À mes amis Farouk et Nihel et tout ceux qui me sont chers,

Merci pour les bons moments que nous avons vécus ensemble.

J’espère que ce travail sera pour eux une petite compensation pour les
sacrifices qu’ils ont toujours consentis à mon égale.

Karim FOURATI

ii
Remerciements

Au terme de ce travail, je tiens à exprimer mes sincères remerciements à toutes

les personnes qui m’ont aidée à passer ce stage de fin d’études au sein de la
société Sopra Steria dans des conditions favorables.

Je tiens à remercier mon maitre de stage, Monsieur Hamdi DAOUD, pour

ses bonnes explications qui m’ont éclairé le chemin de travail et sa

collaboration dans l’accomplissement de ce modeste travail. Il fut d’une bonne

aide dans des situations de galère.

J’aimerais aussi gratifier les efforts de Monsieur Iheb MATOUSSI, mon

encadrant au sein de la société Sopra, qui a eu l’amabilité de répondre à mes

questions et de fournir les explications nécessaires, pour la confiance qu’il m’a

accordée, sa disponibilité et surtout ses efforts pour mener à bien ce projet

Je tiens à remercier Madame Amina ZEMZEM, mon encadrante au sein de

l’ESPRIT pour son support et son aide précieuse pour la rédaction de ce

rapport.

Je remercie tous les enseignants de l’ESPRIT qui m’ont enseigné les bases de
l’informatique durant les trois années passées, et qui m’ont donné la clé de la

réussite par la patience et l’ambition,

Enfin, J’ouvre ici mon cœur à tous ceux qui ont contribué de prêt ou de loin à

l’élaboration de ce mémoire, et j’adresse à tous mes sincères remerciements.

Karim FOURATI

iii
Table des matières

Introduction générale 1

1 Identification 3
1.1 Identification de l’entreprise . . . . . . . . . . . . . . . . . . . . 4

1.1.1 Sopra Steria . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.2 Sopra HR Software . . . . . . . . . . . . . . . . . . . . 5

1.2 Identification du projet . . . . . . . . . . . . . . . . . . . . . . 8

1.2.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . 8

1.2.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . 8

1.2.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . 9

1.2.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . 10

1.2.5 Méthode de travail . . . . . . . . . . . . . . . . . . . . 10

1.2.6 Planification du projet . . . . . . . . . . . . . . . . . . 17

2 Etude de l’art 19

2.1 Business Intelligence . . . . . . . . . . . . . . . . . . . . . . . . 20

2.1.1 Fonction de la chaîne décisionnelle . . . . . . . . . . . . 20

2.1.2 Governance des données . . . . . . . . . . . . . . . . . . 21

2.2 DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.1 Déploiement continu . . . . . . . . . . . . . . . . . . . . 25

2.2.2 Approche CI/CD . . . . . . . . . . . . . . . . . . . . . 25

2.2.3 Automatisation . . . . . . . . . . . . . . . . . . . . . . 26

iv
 2.2.4 SenseOps . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 Analyse et conception 29

3.1 Objectifs stratégiques . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 Construction du tableau de bord . . . . . . . . . . . . . . . . . 30

3.3 Caractéristiques des indicateurs clés de performances . . . . . . 31

3.4 Spécification des Besoins . . . . . . . . . . . . . . . . . . . . . 32

3.4.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . 32

3.4.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . 32

3.4.3 Identification des acteurs . . . . . . . . . . . . . . . . . 33

3.4.4 Diagramme « Cas d’utilisation » . . . . . . . . . . . . . 33

3.5 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . 34

3.5.1 Architecture technique . . . . . . . . . . . . . . . . . . 34

3.5.2 Architecture fonctionnelle . . . . . . . . . . . . . . . . . 35

3.6 Maquettes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.6.1 Dashboard License . . . . . . . . . . . . . . . . . . . . . 37

3.6.2 Dashboard User . . . . . . . . . . . . . . . . . . . . . . 37

3.6.3 Dashboard Application . . . . . . . . . . . . . . . . . . 38

3.6.4 Dashboard Log . . . . . . . . . . . . . . . . . . . . . . 39

3.6.5 Dashboard Performance . . . . . . . . . . . . . . . . . . 40

3.6.6 Dashboard Task . . . . . . . . . . . . . . . . . . . . . . 41

3.6.7 Dashboard QMC . . . . . . . . . . . . . . . . . . . . . 42

4 Implémentation 44

4.1 Environnement . . . . . . . . . . . . . . . . . . . . . . . . . . 45

v
 4.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . 45
4.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . 46

4.2 Intégration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.1 Implémentation de l’application «Governance» . . . . . 49

4.2.2 Intégration de la partie DevOps . . . . . . . . . . . . . 57

5 Déploiement et visualisation 66

5.1 Déploiement de l’application «Governance» . . . . . . . . . . . 67

5.1.1 Choix du thème . . . . . . . . . . . . . . . . . . . . . . 67

5.1.2 Visualisation des Dashboards . . . . . . . . . . . . . . . 68

5.2 Déploiement sur GitLab . . . . . . . . . . . . . . . . . . . . . . 74

Conclusion générale 76

Bibliographie 78

vi
Table des figures

1.1 Historique de Sopra Steria avec les progiciels RH . . . . . . . . 5

1.2 Création de Sopra HR Software . . . . . . . . . . . . . . . . . . 6

1.3 Domaines d’activités de Sopra HR Software . . . . . . . . . . . 7

1.4 Produit SHR Analytics . . . . . . . . . . . . . . . . . . . . . . 9

1.5 Les atouts du produit SHR Analytics . . . . . . . . . . . . . . 9

1.6 Les atouts du produit SHR Analytics . . . . . . . . . . . . . . 14

1.7 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . 18

2.1 La chaîne décisionnelle . . . . . . . . . . . . . . . . . . . . . . 21

2.2 Les atouts du produit SHR Analytics . . . . . . . . . . . . . . 24

2.3 La méthode DevOps . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4 La méthode SensOps . . . . . . . . . . . . . . . . . . . . . . . 27

3.1 Le diagramme de cas d’utilisation . . . . . . . . . . . . . . . . 33

3.2 L’architecture technique du système . . . . . . . . . . . . . . . 35

3.3 L’architecture fonctionnelle du système . . . . . . . . . . . . . 36

3.4 Dashboard License . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.5 Dashboard User . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.6 Dashboard Application . . . . . . . . . . . . . . . . . . . . . . 39

3.7 Dashboard log . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.8 Dashboard Performance . . . . . . . . . . . . . . . . . . . . . . 41

3.9 Dashboard License . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.10 Dashboard QMC . . . . . . . . . . . . . . . . . . . . . . . . . 43

vii
Table des figures

4.1 L’environnement matériel . . . . . . . . . . . . . . . . . . . . . 46

4.2 Logo QlikSense . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3 Logo du Visual Studio Code . . . . . . . . . . . . . . . . . . . 47

4.4 Logo du GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.5 Logo du GitLab Runner . . . . . . . . . . . . . . . . . . . . . . 48

4.6 La connexion à la base MT22 . . . . . . . . . . . . . . . . . . . 52

4.7 La connexion à la base PostgreSQL . . . . . . . . . . . . . . . 53

4.8 La phase d’extraction pour la base PostgreSQL . . . . . . . . . 54

4.9 La phase d’extraction pour la base MT22 . . . . . . . . . . . . 55

4.10 Fonction d’agrégation . . . . . . . . . . . . . . . . . . . . . . . 56

4.11 La fonction de transformation minuscule . . . . . . . . . . . . . 56

4.12 La phase de chargement . . . . . . . . . . . . . . . . . . . . . . 57

4.13 Création d’un projet QLBuilder . . . . . . . . . . . . . . . . . 59

4.14 Le fichier [Link] . . . . . . . . . . . . . . . . . . . . . . . . 60

4.15 Le fichier [Link] . . . . . . . . . . . . . . . . . . . . . 60

4.16 L’importation d’un fichier QVS . . . . . . . . . . . . . . . . . . 60

4.17 Le Reload de l’application . . . . . . . . . . . . . . . . . . . . 61

4.18 Script PipeLine . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.19 Notification d’un mail d’alerte . . . . . . . . . . . . . . . . . . 62

4.20 Création d’une branche . . . . . . . . . . . . . . . . . . . . . . 64

4.21 Push sur une nouvelle branche GitLab . . . . . . . . . . . . . . 64

4.22 Création d’un patch . . . . . . . . . . . . . . . . . . . . . . . . 65

4.23 Application du patch . . . . . . . . . . . . . . . . . . . . . . . 65

viii
5.1 Thème QlikSense . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2 Dashboard license . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.3 Dashboard Application . . . . . . . . . . . . . . . . . . . . . . 70

5.4 Dashboard User . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.5 Dashboard App Details . . . . . . . . . . . . . . . . . . . . . . 72

5.6 La feuille Performance . . . . . . . . . . . . . . . . . . . . . . . 73

5.7 Dashboard Task Details . . . . . . . . . . . . . . . . . . . . . . 74

5.8 Déploiement de l’application sur GitLab . . . . . . . . . . . . 75

ix
Liste des tableaux

1.1 Tableau comparatif des méthodes . . . . . . . . . . . . . . . . 16

4.1 les données HR Access . . . . . . . . . . . . . . . . . . . . . . 49

4.2 Les données de monitoring . . . . . . . . . . . . . . . . . . . . 51

x
Liste des abréviations

— BI = Business Intelligence

— BSC = Balanced Scoreband

— CI = Continuous Integration

— CS = Customer Sucess

— ETL = Extract Transform Load

— GIMSI= Généralisation Information Mesure Système Initiative

— KPI = Key Performance Indicator

— QVD = QlikView Data

— QVF = Qlikview File

— QVS = Qlikview Script

xi
Introduction générale

De nos jours, les entreprises font de leur mieux essayant de perfectionner

continuellement leurs facteurs de production et leurs méthodes et outils commerciaux

pour se concurrencer.

D’une part, l’informatique décisionnelle a commencé à prendre de plus

en plus d’ampleur dans le monde de l’entreprise, occupant une place de choix

dans la liste de ses priorités. En effet, on trouve la présence de la business

intelligence dans plusieurs activités de l’entreprise qui permettra de procurer

des informations nécessaires pour cette dernière.

Notre projet se situe dans ce contexte, où nous avons eu recours aux fondements

de l’informatique décisionnelle afin de mettre en place une application de monitoring.

D’autre part, de plus en plus les entreprises adoptent DevOps par rapport
aux anciennes pratiques traditionnelles. Le processus utilisé pour créer et déployer

les applications d’aujourd’hui a fondamentalement changé. Le travail qui était

autrefois séparé et exécuté de manière isolée est combiné dans un processus qui

intègre le développement et les opérations.

Cette nouvelle méthode, DevOps, peut combler l’écart entre le développement

et les opérations pour fournir des logiciels plus rapidement, plus fréquemment

et de manière plus fiable. DevOps est l’une des nouvelles tendances les plus
importantes et la BI reste une demande. Et notre application comble parfaitement

1
Introduction générale

les deux aspects.

Ce présent rapport comporte les différentes phases d’études et de réalisations

du projet réparties sur cinq chapitres :

Le premier chapitre « Identification » consiste à présenter l’entreprise d’accueil

ainsi que le projet en termes de problématique, solution proposée et l’élaboration

du choix de la méthode de gestion de projet.

Le deuxième chapitre, intitulé « Etude de l’art » contenant quelques notions

de base servant à comprendre de quoi il s’agit le projet.

Le troisième chapitre « Analyse et conception » Il s’agit de présenter les

étapes effectuées pour concevoir le tableau de bord destiné à notre client final.

Le quatrième chapitre « Implémentation » consiste à présenter la phase de

réalisation de notre solution comprenant entre autres l’architecture, l’environnement

de travail, les outils et la phase d’extraction, transformation et chargement à

réaliser.
Enfin, le cinquième chapitre « Déploiement et visualisation » décrira la

phase de restitution en représentant les différentes maquettes modules réalisées.

2
 Chapitre 1

Identification

Plan
1 Identification de l’entreprise . . . . . . . . . . . . . . . . . . . . . . 4

2 Identification du projet . . . . . . . . . . . . . . . . . . . . . . . . . 8
Chapitre 1 : Identification

Introduction

Ce premier chapitre a pour objectif de situer le projet dans son cadre

général. Nous allons commencer par présenter l’organisme d’accueil. Ensuite,

nous allons présenter le contexte général du stage ainsi que la méthodologie

adaptée pour assurer la modélisation et la réalisation de notre projet Finalement

nous allons présenter quelques notions théoriques dont nous aurons besoins.

1.1 Identification de l’entreprise

Cette partie sert à présenter la société Sopra HR Software.

1.1.1 Sopra Steria

Sopra Steria Group a été créé en 1968 et propose quatre principaux domaines

de services : le logiciel Sopra HR, le logiciel bancaire Sopra, Sopra Immobilier

et Sopra Steria Consulting.

Sopra Steria est le leader européen de la transformation numérique. Pour fournir

aux clients une variété de services, veuillez noter : conseil, intégration de systèmes,

publication de solutions commerciales, gestion d’infrastructure et services de

processus d’affaires, Sopra Steria apporte une réponse globale aux défis de

développement des entreprises mondiales.

Sopra Steria compte actuellement plus de 42 000 collaborateurs dans plus de 20

pays/régions avec un chiffre d’affaires de 3,8 milliards d’euros en 2017. [1]. La

4
Chapitre 1. Identification

figure ci-dessous présente l’historique de Sopra Steria avec les progiciels RH :

Figure 1.1: Historique de Sopra Steria avec les progiciels RH

1.1.2 Sopra HR Software

[Link] Historique de la société

Sopra HR Software compte près de 12 millions de collaborateurs dans

différents services et 1 300 collaborateurs, dont 450 internationaux. Il s’appuie

sur plus de 47 ans d’expérience en gestion des ressources humaines et peut

répondre aux besoins des gestionnaires des ressources humaines et des grandes
et moyennes entreprises. Elle s’appuie sur deux gammes de produits : Pléiades

et HR Access.
La figure suivante présente la création de Sopra HR Software

5
 Chapitre 1. Identification

Figure 1.2: Création de Sopra HR Software

La société Sopra HR Software est issue de la fusion de plusieurs entités :

2013 : Acquisition de HR Access par Sopra Group

2014 : Création de la société Sopra HR Software

2014 : Mise en place de gouvernances communes avec DSRH Division Solutions

Ressources Humaines de Sopra autour du Commerce, du Marketing, de

l’Offre, de l’Outsourcing

2014 : Intégration d’IBM HCM dans Sopra HR Software

2015 : Intégration de DSRH, Division Solutions Ressources Humaines de Sopra

2015 : Intégration des activités RH de Sopra autour d’HR Access

[Link] Domaines d’activités de Sopra HR Software

Sopra HR Software est un éditeur de logiciels de gestion des ressources

humaines. Son domaine d’activité est illustré à la figure suivante.[2]

6
Chapitre 1. Identification

Figure 1.3: Domaines d’activités de Sopra HR Software

[Link] Présentation de l’équipe "CS"

Notre stage a été effectué dans le département Customer Sucess (CS)

de Sopra HR Software Tunisia. L’équipe CS a pour mission de soutenir la

réussite des projets clients en assurant la maintenance applicative (TMA) et

l’externalisation de la paie. Une fois la solution HRAccess mise en production,

l’application est exécutée en assurant les tâches suivantes :

- Maintenance corrective : l’ensemble des travaux de correction des anomalies

de disfonctionnement de l’application.

- Maintenance évolutive : l’ensemble des travaux d’amélioration, de changement

ou d’enrichissement de l’application

- Maintenance adaptative : l’ensemble des travaux d’adaptation de l’application

aux évolutions des plateformes techniques

- Maintenance préventive : l’ensemble des travaux destinés à améliorer le

7
Chapitre 1. Identification

fonctionne- ment et la maintenabilité de l’application sans en changer les

fonctionnalités

- Exploitation : Exécution et suivi de l’exploitation de l’application en particulier

le cycle de paie

- Pilotage de la maintenance (comités avec le client, indicateurs de suivi,

bulletin qualité...).

1.2 Identification du projet

1.2.1 Contexte du projet

Dans le cadre de l’amélioration de la gestion des environnements analytics.

Sopra HR propose un projet de fin d’études qui donnera plus d’efficience pour

gérer, administrer et maintenir le produit SHR Analytics en suivant les bonnes

pratiques de la méthodologie DevOps. L’offre standard de QlikSense est limitée

de sorte qu’elle ne permette pas d’aider un administrateur à analyser et à

intervenir rapidement pour gérer des problèmes affectants l’environnement.

1.2.2 Etude de l’existant

Dans une volonté de suivre les nouvelles tendances digitales RH, Sopra
HR propose un outil BI nommé « SHR Analytics » permettant de créer des

visualisations de données, des rapports et des tableaux de bord interactifs.

La figure présente le logo de SHR Analytics.

8
Chapitre 1. Identification

Figure 1.4: Produit SHR Analytics

Les avantages du produit SHR Analytics :

- Relier et comprendre les informations non corrélées

- Permettre des Synthèses et analyses poussées basées sur les données antérieures

- Soutenir le procès de prise de décision

Les atouts du produit SHR Analytics :

Figure 1.5: Les atouts du produit SHR Analytics

1.2.3 Problématique

La gestion des environnements analytiques, à cette ère, la donnée est

devenue un axe stratégique pour l’entreprise afin de gagner en terme d’efficience.

9
Chapitre 1. Identification

Le produit actuel SHR Analytics repose sur un modèle standard afin de suivre
l’activité de l’environnement et aider les administrateurs à réaliser leurs tâches

quotidiennes mais présente beaucoup de limites telle que l’absence de l’intégration

continue, ce qui nous dégage une opportunité d’améliorer cet aspect.

1.2.4 Solution proposée

On propose de concevoir une application de gouvernance des données

ayant pour but de gérer les données d’environnement, d’afficher les données de
monitoring sous format d’un Dashboard pour assurer une meilleure visualisation

et de garantir l’automatisation du projet Ceci se fera en faisant recours aux

fondements de l’informatique décisionnelle pour l’extraction et l’analyse de données,

ainsi qu’en adoptant la méthodologie DevOps pour l’intégration continue du

projet. De plus, on propose de mettre en place un système de notification pour

alerter l’utilisateur dans le cas d’un problème.

1.2.5 Méthode de travail

Pour avoir un produit de bonne qualité, nous devons choisir la méthode de

gestion de projets ainsi que la démarche que nous adapterons pour organiser le

bon déroulement et assurer qu’il aboutit dans un triangle représentant l’équilibre

qualité-coût-délai (QCD). Le Choix d’une bonne méthodologie pour conduire le

projet permet à tous les acteurs de travailler efficacement ensemble, en suivant

des règles clairement définies.

La gestion de projet :
La gestion de projet est une démarche visant à organiser d’A à Z le bon

10
Chapitre 1. Identification

déroulement d’un projet. Elle couvre l’ensemble des outils, techniques et méthodes
qui permettent au chef de projet et à l’équipe qui lui est directement associée de

conduire, coordonner et harmoniser les diverses tâches exécutées dans le cadre

du projet.[3]

Quelle que soit la méthodologie de travail que nous allons adapter, nous allons
utiliser l’approche agile pour la gestion de projet.

L’approche agile :
Une méthode agile est une approche itérative et collaborative, capable de prendre

en compte les besoins initiaux du client et ceux liés aux évolutions. [3]
La méthode agile se base sur un cycle de développement qui porte le client au

centre. Le client est impliqué dans la réalisation du début à la fin du projet.

Grâce à la méthode agile, le demandeur obtient une meilleure visibilité de la

gestion des travaux qu’avec une méthode classique. La méthode agile repose sur

quatre grands principes :

- COLLABORATION : Communication et cohésion d’équipe passent avant

les outils et les processus.

- ÉQUIPE : Le privilège de la relation équipe/client est mis en avant plutôt

que la négociation contractuelle.

- APPLICATION : Préférer une application bien construite à une documentation

détaillée.

- ACCEPTATION : Le choix de l’acceptation du changement et de la flexibilité

au détriment d’un plan rigide. [3]

11
Chapitre 1. Identification

[Link] Choix de la méthodologie

Il existe plusieurs méthodes pour conduire des projets tableau de bord,

chaque méthode est adaptée à une stratégie ou à un ensemble de stratégies. En

effet, le projet tableau de bord dépend de la stratégie mise en place et chaque

démarche implique une approche différente suivant cette stratégie. Une étude
s’impose pour déterminer les avantages et les limites de chaque méthode et son

degré d’adaptation à notre projet. Il existe trois méthodes qui comptent parmi
les plus utilisés pour les projets tableaux de bord :

- Le navigateur Skandia.

- Le tableau de bord prospectif (Balanced Scoreband/BSC)

- La méthode GIMSI

- Le navigateur Skandia :
Le navigateur Skandia, a été mis au point chez Skandia, une société multinationale

suédoise d’assurance et de services financiers, privilégie le pilotage de l’immatériel

et plus précisément du capital intellectuel, véritable moteur de la création des

valeurs.
Le modèle est loin d’être récent, c’est une bonne base de réflexion pour construire

un système de pilotage centré sur le capital humain. Le navigateur Skandia

propose un "tableau de bord" composé de 5 axes regroupés dans une dimension

temporelle :

- Axe financier : le long terme : qu’a-t-on fait hier ?

- Axe client : le présent

- Axe humain : le centre de la démarche

12
Chapitre 1. Identification

- Axe processus : le présent

- Axe innovation et développement : que prépare-t-on pour demain ?[4]

- Le tableau de bord prospectif (Balanced Scoreband/BSC) :

Le Balanced Scorecard est un système global de clarification et de formalisation

de la stratégie des organisations dans le but de la déployer et de la mettre

en œuvre plus efficacement. La démarche s’inscrit dans un processus complet

et continu qui commence par l’élaboration d’une stratégie, déclinée en cartes

stratégiques, traduites en objectifs opérationnels par grandes fonctions. La méthode

visant à mesurer les activités de l’entreprise en quatre perspectives principales :

- Apprentissage : Comment piloter l’organisation, le changement, pour plus

de performance ?

- Clients : Comment satisfaire les clients ?

- Processus : Comment améliorer les processus clés en lien avec les clients et
actionnaires ?

- Finances : Comment satisfaire les actionnaires ?[4]

13
Chapitre 1. Identification

- La méthode GIMSI :

Figure 1.6: Les atouts du produit SHR Analytics

La méthode GIMSI est utilisée dans différents domaines. Information :

L’accès à l’Information pertinente est le fondement de l’aide à la décision.

Méthode et Mesure : GIMSI est une méthode, la mesure en est le principe.

Système et Systémique : La méthode permet de construire le Système de

pilotage et de l’intégrer au coeur du Système d’information. Elle est fondée sur

un concept d’inspiration systémique.

Individualité et Initiative : La méthode privilégie l’autonomie des individus

pour une prise d’Initiative plus naturelle.

GIMSI est une méthode de conception du système de pilotage à base de tableaux

de bord centrés sur l’homme décideur en situation, et définit un cadre méthodologique

afin de mieux formaliser les conditions de réussite des projets tableaux de bord.

Elle est structurée en qui couvrent tous les aspects du projet décisionnel, depuis
l’élaboration de la stratégie jusqu’au choix et la mise en oeuvre des progiciels.

La méthode GIMSI est structurée en 10 étapes bien identifiées et regroupées en

14
Chapitre 1. Identification

4 phases :

— Phase 1. Identification : Quel est le contexte ?

- Étape 1. Environnement de l’entreprise

- Étape 2. Identification de l’entreprise

— Phase 2. Conception : Que faut-il faire ?

- Étape 3. Définition des objectifs

- Étape 4. Construction du tableau de bord

- Étape 5. Choix des indicateurs

- Étape 6. Collecte des informations

- Étape 7. Le système de tableau de bord

— Phase 3. Mise en oeuvre : Comment le faire ?

- Étape 8. Le choix des progiciels

- Étape 9. Intégration et déploiemen

— Phase 4. Suivi permanent : Le système correspond-il toujours aux attentes ?

- Étape 10. Audit [5]

Le tableau ci-dessous synthétise les différences entre les trois méthodes.

15
Chapitre 1. Identification

Méthode Navigateur Balanced GIMSI

skandia Scoreband
Volet Privilégie le Adopte la S’adapte à toute
stratégique pilotage de stratégie des les stratégies
l’immatériel organisations
Volet financier Pas de moyens Coûteuse Peu de moyens
financiers financiers
Volet humain Le capital Manque de Favorise la
humain au centre participation du coopération entre
de la démarche personnel les décideurs
Domaine Pilotage Stratégie Pilotage
d’application d’entreprise d’entreprise d’entreprise
Tableau 1.1: Tableau comparatif des méthodes

[Link] Méthode adaptée

Après l’étude que nous avons effectuée, nous avons constaté que la méthode
GIMSI estla plus adaptée à notre projet pour des différentes raisons :

— GIMSI s’adapte à la stratégie mise en place, ce qui est nécessaire pour

notre projet.

— GIMSI adopte le modèle de management participatif ce qui fait que le

projet soit motivant.

— Les tableaux de bord GIMSI sont orientés au métier de pilotage, ce qui est

en parfait accord avec la finalité de notre projet.

— GIMSI permet de réaliser le projet décisionnel dans sa totalité, de la

conception jusqu’aux réalisations.

— GIMSI adopte une approche centrée sur le décideur.

Nous allons aussi essayer d’ajouter de l’agilité sur la méthodologie GIMSI pour
se préparer aux changement prévus par le client.

16
Chapitre 1. Identification

1.2.6 Planification du projet

Le projet s’est déroulé pendant cinq mois entre le 05 Février 2020 et le 30

juin 2020. Nous avons présenté la répartition du temps en fonction des étapes
majeures à suivre afin d’aboutir à une solution fonctionnelle qui répondant à

notre besoin.
-Diagramme de GANT :

Le diagramme de Gantt, couramment utilisé en gestion de projet, est l’un des

outils les plus efficaces pour représenter visuellement l’état d’avancement des

différentes activités qui constituent un projet.

Ce diagramme permet de visualiser d’un seul coup d’œil : - Les différentes tâches

à envisager.
- La date de début et la date de fin de chaque tâche.

- La durée escomptée de chaque tâche.

- Le chevauchement éventuel des tâches, et la durée de ce chevauchement.

- La date de début et la date de fin du projet dans son ensemble.

En résumé, un diagramme de Gantt répertorie toutes les tâches à accomplir

pour mener le projet à bien, et indique la date à laquelle ces tâches doivent être
effectuées.

[6] La figure ci-dessous illustre le plan que nous avons adopté pour réaliser les
différentes parties de notre projet.

17
Chapitre 1. Identification

Figure 1.7: Diagramme de GANTT

Conclusion

Dans ce chapitre introductif, nous avons présenté l’organisme d’accueil

ainsi que le projet à réaliser, la partie qui suit consiste dans la phase de préparation

de ce projet qui est l’état de l’art et l’étude de l’existant.

18
 Chapitre 2

Etude de l’art

Plan
1 Business Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2 DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Chapitre 2 : Etude de l’art

Introduction

Nous procédons dans ce chapitre en accentuant sur les fondements de la

business intelligence, et ceci en recensant les bases du DevOps et SenseOps.

2.1 Business Intelligence

La Business Intelligence est un concept qui permet aux entreprises de

suivre, comprendre et piloter les informations essentielles à leurs activités. Elle

leurs permet de voir plus clair leurs états actuels et donc de prendre la bonne
décision. Elle est devenue un outil indispensable pour toute entreprise qui désire

exploiter efficacement le potentiel des données de leur système ainsi que de

réussir son activité.

Les solutions de Business Intelligence sont des systèmes d’information d’aide à

la décision, elles facilitent la prise de décision par les décideurs. Elles collectent

et transforment les données de votre entreprise en rapports et analyses utiles

dans le but d’améliorer vos performances. [7].

2.1.1 Fonction de la chaîne décisionnelle

Il est coutumier de présenter les éléments et outils composant la chaîne

décisionnelle en quatre catégories correspondant chacune à une fonction spécifique,

à une phase du processus. La figure suivante présente la chaine décisionnelle.

20
Chapitre 2. Etude de l’art

Figure 2.1: La chaîne décisionnelle

1 Collecter, nettoyer et consolider les données Extraire les données des systèmes
de production et les adapter à un usage décisionnel.

2 Stocker Centraliser les données structurées et traitées afin qu’elles soient

disponibles pour un usage décisionnel.

3 Distribuer Ou plutôt faciliter l’accessibilité des informations selon les fonctions

et les types d’utilisation.

4 Exploiter ou comment assister du mieux possible l’utilisateur afin qu’il

puisse extraire la substance de l’information des données stockées à cet

usage. [8]

2.1.2 Governance des données

La première étape est de mettre en place une stratégie, pour avoir une

équipe de gouvernance des données qui soit efficace. Cette stratégie peut démarrer

21
Chapitre 2. Etude de l’art

avec la rédaction d’une charte de gouvernance des données, avec l’aide des
différentes parties prenantes, des acteurs utilisant la data dans l’entreprise. [9]

[Link] Gestion qualité des données

Les problèmes de "silos" et de cloisonnement, les délicates questions de

nettoyage, de formatage et de consolidation tout comme le manque de compétence

des intervenants pour évaluer l’importance de données, rebuteront les plus tenaces.

Finalement, sans une gouvernance des données opérationnelle, la solution de la

facilité l’emportera. On ne collectera que les données les plus faciles à collecter,

sans vision d’assistance à la prise de décision, sans perspective de valeur ajoutée.

[9]

[Link] Difficultés de la collecte

Cette question est aujourd’hui encore plus aiguë avec l’accroissement exponentielle

de la quantité de données produites et la diversité des modes de stockage. Il s’agit

en effet de maîtriser les stockages "traditionnels" de comme les bases de données

relationnelles, bases de données noSQL en plein essor tout comme les solutions
SAAS pour les outils d’ERP, CRM, SIRH... [9]

[Link] Stratégie de collecte

Pour assurer une collecte pertinente, il est essentiel de définir le "Pourquoi",

pour quels besoins d’analyse, avant le "Comment", quelles techniques, quels

outils. Cette démarche ordonnée permettra de poser les questions essentielles

préalables à l’orientation du projet.

- Quelles données devons-nous collecter ?

22
Chapitre 2. Etude de l’art

- Quelles données devrons-nous archiver ?

- Quelles données devons-nous rapprocher ?

- Quelles données doit-on sécuriser ?

Il sera aussi du rôle des responsables de la gouvernance des données de préciser

les règles permettant d’évaluer l’importance des données à collecter et de veiller

à leur application. [9]

[Link] De la donnée à la sagesse

La pyramide DIKW "Data Information Knowledge Wisdom" que l’on

devrait traduire en français par DICS pour "Données, Informations, Connaissances,

Sagesse", résume assez bien le rôle et le bon usage des données dans l’entreprise

et ailleurs. C’est aussi le but ultime de la gouvernance des données : Parvenir à

extraire et à construire un sens des données afin d’accroître la sagesse c’est dire

le "Bon Sens" de ceux qui ont à décider.[9]

La figure suivante présente la pyramide DIKW.

23
Chapitre 2. Etude de l’art

Figure 2.2: Les atouts du produit SHR Analytics

2.2 DevOps

DevOps est un terme utilisé pour désigner un ensemble de pratiques qui

mettent l’accent sur la collaboration et la communication des développeurs de

logiciels et des professionnels des technologies de l’information (TI) tout en

automatisant le processus de livraison de logiciels et les changements d’infrastructure.

Il vise à établir une culture et un environnement où la création, le test et la

publication de logiciels peuvent se produire rapidement, fréquemment et de

manière plus fiable. [10] La figure ci-dessous présente la méthode devops.

24
Chapitre 2. Etude de l’art

Figure 2.3: La méthode DevOps

2.2.1 Déploiement continu

Le principal résultat de la mise en œuvre du modèle DevOps est la création

d’un pipeline d’intégration et de déploiement continu (CI / CD). La méthode

CI / CD peut vous aider à réduire régulièrement l’intervention des utilisateurs,

fournissant ainsi régulièrement des applications aux clients et vérifiant la qualité

du logiciel. Plus précisément, l’approche CI / CD garantit une automatisation

et une surveillance continues de l’ensemble du cycle de vie des applications, des

étapes d’intégration et de test à la distribution et au déploiement. Cela vous

permet d’identifier et de corriger rapidement les problèmes et dysfonctionnements.

Ensemble, ces pratiques sont souvent appelées «pipeline CI / CD» et reposent

sur une collaboration agile entre les équipes de développement et d’exploitation.

2.2.2 Approche CI/CD

Le concept de développement d’applications modernes est de permettre à

plusieurs développeurs de gérer simultanément différentes fonctions de la même

25
Chapitre 2. Etude de l’art

application. Cependant, si la société prévoit de fusionner tous ces codes source

le même jour, la tâche peut être laborieuse et nécessiter beaucoup de temps

et d’étapes manuelles. Lorsque des développeurs travaillant seuls apportent des

modifications à l’application, ces modifications peuvent entrer en conflit avec

différentes modifications apportées par d’autres développeurs en même temps. Si

chaque développeur personnalisait son propre environnement de développement

intégré pour toute l’équipe au lieu d’en définir un dans le cloud, ce problème
deviendrait plus compliqué.

2.2.3 Automatisation

L’automatisation informatique implique l’utilisation de logiciels pour créer

des instructions et des processus reproductibles pour remplacer ou réduire l’interaction

homme-ordinateur avec les systèmes informatiques. Le logiciel d’automatisation

fonctionne dans le cadre de ces instructions, outils ou structures et exécute des

tâches avec une intervention manuelle minimale (le cas échéant). L’automatisation

est un élément clé pour optimiser l’environnement informatique et la transformation

numérique. L’environnement informatique dynamique et moderne doit pouvoir

se développer plus rapidement que jamais, et l’automatisation informatique joue

un rôle essentiel.

2.2.4 SenseOps

DevOps est une façon établie de travailler dans l’industrie informatique

au sens large, mais comment l’appliquer à Sense ?

Certains des concepts mentionnés sur ce site sont du bon sens (sans jeu de mots)

26
Chapitre 2. Etude de l’art

également dans le développement Sense. Mais d’autres concepts, largement

adoptés dans la plupart des autres environnements de développement, sont

totalement absents de l’écosystème Sense.

Autrement dit : jusqu’à présent, le développement de Sense a été fait de

manière plutôt ponctuelle, sans utiliser les meilleures pratiques et les enseignements

de la communauté plus large du développement logiciel. [10] La figure suivante

présente la méthode senseops.

Figure 2.4: La méthode SensOps

27
Chapitre 2. Etude de l’art

Conclusion

Dans ce chapitre, nous avons présenter les premières étapes vers la compréhension

des outils du travail, la Business Intelligence et la Devops.

Nous avons détaillé ainsi l’utilité de l’automatisation en détaillant la méthode

DevOps.

28
 Chapitre 3

Analyse et conception

Plan
1 Objectifs stratégiques . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2 Construction du tableau de bord . . . . . . . . . . . . . . . . . . . 30

3 Caractéristiques des indicateurs clés de performances . . . . . . . 31

4 Spécification des Besoins . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6 Maquettes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Analyse et conception

Introduction

Dans ce chapitre, nous allons présenter en premier lieu notre vision sur Les

objectifs stratégiques. Ensuite, l’architecture fonctionnelle du projet. Ensuite,

nous allons mettre en place notre architecture technique du projet. Pour finir

par maquettage.

3.1 Objectifs stratégiques

Notre objectif est de mettre en place un système de gestion d’environnement

analytique, qui se base premièrement sur la collecte des données de l’environnement

et les intégrer afin d’assurer une telle gouvernance de ces données. Deuxièment
l’affichage des données se fera sous format d’un dashboard qui assure une meilleure

visualisation. Enfin, nous allons mettre en place un système de notification en

cas d’un problème d’environnement

3.2 Construction du tableau de bord

Le tableau de bord est l’intermédiaire entre le décideur et le système

d’aide à la décision. Il représente les indicateurs de performances nécessaires

pour piloter une activité. Un tableau de bord GIMSI doit offrir une idée sur la
situation d’un premier coup d’oeil. En plus, il doit être capable de répondre à

ces trois questions :

- Que se passe-t-il ? - Pourquoi cela se passe-t-il ainsi ? - Comment résoudre le

30
Chapitre 3. Analyse et conception

problème afin de revenir à un état sous contrôle ?

Afin d’assurer que ces critères soient vérifiés, nous avons opté pour un
tableau de bord ayant les caractéristiques suivantes :

— Facilement utilisable : il ne demande pas un grand savoir informatique.

— Interactif : Les rapports générés doivent être construits directement par les

utilisateurs grâce à une interface graphique facile à utiliser.

— Accès facile et à distance : accès à travers une interface web.

— Conviviale : les tableaux de bord doivent être clairs et bien choisis pour
refléter L’analyse.

3.3 Caractéristiques des indicateurs clés de performances

« Un indicateur de performance KPI est une mesure ou un ensemble de

mesures braquées sur un aspect critique de la performance globale de l’organisation.

Un indicateur de performance ne laisse jamais le décideur indifférent. Lorsque

le décideur n’agit pas c’est en toute conscience. »[11]

La qualité des décisions dépendante directement de la qualité de la mesure et

de la pertinence des indicateurs. Un tableau de bord GIMSI doit comporter un

nombre d’indicateurs limité, puisqu’une personne ne peut percevoir qu’ entre 5

et 9 informations à la fois, qui doivent répondre aux caractéristiques suivantes :

- Temps réel : Il est rafraîchi fréquemment afin de permettre la prise de décision

dans les meilleures conditions.

31
Chapitre 3. Analyse et conception

- Mesure un ou plusieurs objectifs : Il mesure la performance selon un ou

plusieurs objectifs.

3.4 Spécification des Besoins

3.4.1 Besoins fonctionnels

— Collecter des données de l’environnent Analytics.

— Intégrer des données fonctionnelles pour assurer une gouvernance de données.

— Visualiser les résultats sous forme des Dashboard.

— Création d’une Plateforme de livraison Analytics.

— Création d’une Plateforme de livraison des patch Analytics.

— Mettre en place un système de notification en cas d’un problème d’environnement.

3.4.2 Besoins non fonctionnels

Selon Jacobson un besoin non fonctionnel est un besoin spécifiant des

propriétés du système.

— Performance : Ce projet doit fournir des apports de rapidité et de vélocité

pour aider à améliorer la performance puisqu’il s’agit de l’objectif principal

de la mise en œuvre de cet outil.

— Maintenabilité : Le système devrait être ouvert à toute amélioration,

Ainsi il devrait permettre l’ajout de nouvelles fonctionnalités sans pour

autant risquer la régression des anciennes.

32
Chapitre 3. Analyse et conception

— Fiabilité : Le système devrait offrir aux utilisateurs des résultats fiables

et corrects.

3.4.3 Identification des acteurs

Les principaux acteurs interagissant directement avec notre application

sont :
Administrateur, employée : Manipuler la source de données, gérer les QVDs,

consulter les tableaux de bord, d’effectuer des analyses à travers des filtres.

3.4.4 Diagramme « Cas d’utilisation »

La figure ci-dessous présente le diagramme « Cas d’utilisation » de notre

projet.

Figure 3.1: Le diagramme de cas d’utilisation

33
Chapitre 3. Analyse et conception

3.5 Architecture globale

3.5.1 Architecture technique

L’architecture technique est une vue tournée sur l’organisation logique de

la plateforme informatique, c’est-à-dire les moyens techniques clés qui seront

utilisés par tous les logiciels applicatifs.

La vue contient le matériel informatique, les logiciels systèmes, les middlewares,

ainsi que les réseaux de télécommunication et les relations entre ces différents

éléments. Pour une entreprise ou une institution, le choix de l’architecture

technique vise à maxi- miser les possibilités d’implantation de logiciels du commerce

ainsi que de réalisation de logiciels sur mesure.

Il vise également à rentabiliser l’utilisation du matériel et des logiciels déjà

acquis par l’institution. Pour une entreprise ou une institution qui transforme
son architecture technique, le plan d’architecture est accompagné d’un planning

et d’un budget des acquisitions, des ventes et des opérations de migration

nécessaires pour aligner le système informatique avec le plan.

La figure ci-dessous présente l’architecture technique de notre projet

34
Chapitre 3. Analyse et conception

Figure 3.2: L’architecture technique du système

L’architecture du notre projet se base sur le regroupement des données

des deux bases MT22 et PostgreSQL (procurées par Sopra HR) concernant les
informations de Sopra ainsi que les données permettant le monitoring (La base

PostgreSQL).
Ces données passeront par une étape de filtration afin de garantir une meilleure

manipulation, et vont servir pour élaborer le dashboard demadé.

3.5.2 Architecture fonctionnelle

L’architecture fonctionnelle d’un logiciel correspond à une description de

haut niveau du logiciel. Cette description facilite les échanges entre les développeurs
et les acteurs du transfert car elle établit une vision partagée du logiciel. Elle

consiste à décomposer itérativement la fonctionnalité du système en fonctions

35
Chapitre 3. Analyse et conception

et sous-fonctions issues de l’analyse des processus métiers et en mettant en

évidence leurs interactions.

La figure ci-dessous présente l’architecture fonctionnelle de notre projet

Figure 3.3: L’architecture fonctionnelle du système

Le démarche de formulation du Dashboard se résume en deux grandes

étapes : - Extraction des données : des deux bases MT22 et PostgreSQL

- Préparation des données : filtration et nettoyage de données

3.6 Maquettes

Après la définition des objectifs, la dernière étape de la deuxième phase

de GIMSI consiste à la construction des maquettes des tableaux de bord.

Les figures de chaque feuilles sera représentées ci-dessous, ce qui font la maquette

du tableau de bord du projet

36
Chapitre 3. Analyse et conception

3.6.1 Dashboard License

— Des informations sur la license des utilisateurs : le coût, les détails, l’accès

total. . .

— La date de la dernière modification affectée sur tous les utilisateurs du

système par exemple l’utilisateur qui a accordé ou restreint l’accès pour un

autre.

— Historique d’affectation License.

— Information sur usage détail de License.

Figure 3.4: Dashboard License

3.6.2 Dashboard User

— Information sur les user début accès et fin accès

— Sommes des user par session

37
Chapitre 3. Analyse et conception

— Nombre user qui authentifier premier fois

— Historique d’affectation des Object

— Top 50 user par session

Figure 3.5: Dashboard User

3.6.3 Dashboard Application

— Nombre d’Accès d’utilisateur sur le Stream

— Accès historique sur le Stream par application

— Sommes des user qui utiliser application par rapport rôle

— Sommes des user qui utiliser Stream par rapport rôle

— Top 50 Application par session

— Tous les Détail sur application

38
Chapitre 3. Analyse et conception

Figure 3.6: Dashboard Application

3.6.4 Dashboard Log

— Information sur les détails de log de serveur

— Information sur License monitoring

— Information sur opération monitoring

— Log de qlik sense serveur

— Information sur les erreur et Waring

39
Chapitre 3. Analyse et conception

Figure 3.7: Dashboard log

3.6.5 Dashboard Performance

— Information sur le system Dernier 24 heure

— Information sur le system dernier 7 jours et 30 jours

— Information sur RAM

— Information sur CPU

— Concurrent entre user et application

40
Chapitre 3. Analyse et conception

Figure 3.8: Dashboard Performance

3.6.6 Dashboard Task

— Information sur le nombre de reload (jour, heur, mois)

— Nombre de reload d’application par heurs

— Nombre de reload CPU par jour en heur

— Durée de chaque task reload

— Information sur chaque task statistique

41
Chapitre 3. Analyse et conception

Figure 3.9: Dashboard License

3.6.7 Dashboard QMC

— Détail de chargement de l’application

— Détail de nombre de chargement par user

— Détail de chargement de QMC

42
Chapitre 3. Analyse et conception

Figure 3.10: Dashboard QMC

Conclusion

Dans ce chapitre, nous avons présenté en premier lieu objectifs stratégiques.

Ensuite, nous avons présenté architecture globale du projet (fonctionnelle et

technique). Pour finir par le maquettage.

43
 Chapitre 4

Implémentation

Plan
1 Environnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2 Intégration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Chapitre 4 : Implémentation

Introduction

Après avoir identifier les phases initiales du projet suivant la méthode

GIMSI, nous présentons dans ce chapitre l’environnement du travail : matériel

et logiciel. Ceci nous permettra de s’organiser pour les phases de développement

et déploiement de la solution sur gitlab.

4.1 Environnement

4.1.1 Environnement matériel

Pour une application SHR analytic gouvernance, nous devons avoir une
machine robuste pour optimiser le temps d’exécution.

Alors, pour concrétiser notre solution nous utilisons une machine HP avec les
caractéristiques suivantes :

— Processeur intel (R) Core (TM) [email protected] 1.90GHz.

— Mémoire Ram : 8 Go

— Type du système : Système d’exploitation 64 bits, processeur x64

— Système d’exploitation : Microsoft Windows 10 Entreprise

45
Chapitre 4. Implémentation

Figure 4.1: L’environnement matériel

4.1.2 Environnement logiciel

Pour cette section nous allons introduire l’environnement logiciel tout au

long la mise en place de notre projet.

[Link] QlikSense

Qlik Sense est une plateforme d’analyse visuelle permettant à chaque

utilisateur d’exploiter au maximum les informations et d’avoir une meilleure

visibilité de ces informations. Tous les utilisateurs, quels que soient leurs niveaux,

peuvent ainsi générer des visualisations leur permettant de répondre instantanément

aux questions qu’ils se posent et de régler les problèmes liés à leur activité

professionnelle, problèmes qui nécessitent généralement plus qu’un simple aperçu

des informations.

[12] la figure suivante illustre le logo du QlikSense.

46
Chapitre 4. Implémentation

Figure 4.2: Logo QlikSense

[Link] Visual Studio Code

Visual Studio Code est présenté lors de la conférence des développeurs

Build d’avril 2015 comme un éditeur de code multi-plateforme, open source et

gratuit, supportant une dizaine de langages.

Il est basé sur Electron, une structure utilisée pour déployer des applications

[Link] pour le bureau exécuté sur le moteur Blink. Bien qu’il utilise le framework
Electron, le logiciel n’utilise pas Atom mais utilise le même composant éditeur

(nommé "Monaco") utilisé dans Azure DevOps (anciennement appelé Visual

Studio Online et Visual Studio Team Services)[12] La figure ci-dessous montre

le logo du Visual Studio Code.

Figure 4.3: Logo du Visual Studio Code

47
Chapitre 4. Implémentation

[Link] GitLab

GitLab est un logiciel libre de forge basé sur git proposant les fonctionnalités

de wiki, un système de suivi des bugs, l’intégration continue et la livraison

continue. Développé par GitLab Inc. [12] La figure ici montre le logo du GitLab.

Figure 4.4: Logo du GitLab

[Link] GitLab Runner

GitLab Runner est le projet open source utilisé pour exécuter vos travaux

et renvoyer les résultats à GitLab. Il est utilisé conjointement avec GitLab CI

/ CD , le service d’intégration continue open source inclus avec GitLab qui

coordonne les travaux. [12] La figure suivante présente le logo du GitLab Runner.

Figure 4.5: Logo du GitLab Runner

48
Chapitre 4. Implémentation

4.2 Intégration

4.2.1 Implémentation de l’application «Governance»

[Link] Collecter les données

Dans notre travail nous avons eu recours à deux bases de données :

- La base de donnée Oracle (MT22) pour les données de HR Access.

- Une deuxième base PostgreSQL pour les données de monitoring.

Ci-dessous le tableau présentant les données de HR Access. Les tables utilisées :

Nom de la table Attribut Description

LOGNID Identifiant de
ZY4I
l’utilisateur
NMPRUS Nom et prénom de
l’utilisateur
ROLMOD Modèle de rôle
ZY09
ROLVAL Valeur de rôle
IDPS00 Poste
ZY3B
IDJB00 Emploi
ZYCA CLASSI Classification
Tableau 4.1: les données HR Access

Ci-dessous le tableau présentant les données de monitoring.

Les tables utilisées :

49
Chapitre 4. Implémentation

Nom de la table Attribut Description

Id Identifiant du task
monitor createdDate Date de création de
apps task
REST modifiedDate Date de la dernière
task modification de task
modifiedByUserName Id du l’utilisateur
modifiant du task
Name Nom du task
taskType Type de task
Id Identifiant du task
createdDate Date de création de
monitor l’event
apps modifiedDate Date de la dernière
REST modification de l’event
event modifiedByUserName Id du l’utilisateur
modifiant de l’event
Name Nom de l’event
eventType Type de l’event
startDate Date de début de
l’event
expirationDate Date d’expiration de
l’event
monitor-apps userId Identifiant de
REST l’utilisateur
user userDirectory Id de l’utilisateur
condensed créeant un stream

50
Chapitre 4. Implémentation

Nom de la table Attribut Description

totalTokens Le total des tokens
monitor
apps availableTokens Les tokens disponibles
REST tokensEnabled Les tokens actives
license allocatedTokens Les tokens alloués
overview usedTokens Les tokens utilisés
unavailableTokens Les tokens non
disponibles
ReloadStatusTEMP Failed, success
Tasks
temp taskReloadStatusColor Green, orange, red
taskReloadStatusSort Booléen pour savoir si
c’est trier ou pas
Max Sense Engine Le max du RAM
RAM
Max Concurrent Users Max utilisateurs
dim dash simultanés
Max Concurrent Apps Max applications
simultanées
User Sessions La session de
l’utilisateur
Reloads Nombre de recharges
Reload Failures Nombre de recharges
échoués
Avg Reload Duration La durée des recharges
moyenne
Tableau 4.2: Les données de monitoring

[Link] Phase d’alimentation

La phase d’alimentation est la plus importante pour initier les données

dans des fichiers QVS, après les avoir récupérer des deux bases sources (MT22
et PostgreSQL).

Dans une première partie, on a chargé les QVS à partir de la base MT22 qui

51
Chapitre 4. Implémentation

concerne les informations des utilisateurs ainsi que leurs coordonnées comme
montre la figure ci-dessous.

Figure 4.6: La connexion à la base MT22

Pour la deuxième partie, on a fait une jointure pour récupérer les informations
de monitoring qui correspondent aux utilisateurs (Première partie),

La figure suivante illustre cette phase.

52
Chapitre 4. Implémentation

Figure 4.7: La connexion à la base PostgreSQL

Maintenant que toutes données nécessaires sont enregistrées dans les fichiers
QVS, nous passeront à la modélisation des données suivant des règles de bonne

pratique.
Alors, dans ce qui suit, nous passerons par trois phases majeures : la phase

d’extraction des données à partir des QVS, une phase de transformations qui
servira à la filtration des données selon le besoin et enfin la dernière phase est

celle de chargement.

[Link] Phase d’extraction

Cette première étape consiste à extraire les données à partir de leur source,

qui est dans notre cas les fichiers QVS déjà alimentés (phase d’alimentation) en
utilisant principalement la commande LOAD.

53
Chapitre 4. Implémentation

. La figure suivante montre l’extraction des données à partir de la base PostgreSQL

Figure 4.8: La phase d’extraction pour la base PostgreSQL

La figure suivante montre l’extraction des données à partir de la base

MT22

54
Chapitre 4. Implémentation

Figure 4.9: La phase d’extraction pour la base MT22

[Link] Phase de transformation

La transformation implique l’utilisation des règles et des fonctions de script

afin de traiter les données, et ce pour arriver à une structure de modèle de

données qui répond aux besoins.

Il existe plusieurs exemples classiques pour cette transformation parmi lesquels

on cite :
- Calcul de nouvelles valeurs

- Traduction des valeurs codées

- Modification des noms de champ. . .

Dans notre application, on a effectué plusieurs transformations sur les données,

dont la modification des noms de champ est la plus utilisée pour presque tous

les champs.

55
Chapitre 4. Implémentation

Fonctions d’agrégation :
La transformation faite s’agit des fonctions d’agréation (Min, Max, Avg. . . ).

Dans cette figure on a enregistré un arrondi de la moyenne des sessions CPU en

millisecondes sous l’alias AVG CPU Spent.

Figure 4.10: Fonction d’agrégation

Fonction de transformation minuscule :

On a appliqué une fonction «lower» pour faire une transformation sur les champs
«lognid» de la majuscule au minuscule, comme illustré dans la figure suivante.

Figure 4.11: La fonction de transformation minuscule

56
Chapitre 4. Implémentation

[Link] Phase de chargement

Afin de passer aux dernières phases, nous sommes amenés à passer par

cette phase de chargement, qui a pour but d’exécuter le script pour charger le
modèle de données, la figure ci-dessous présente le code utilisé pour le chargement

des données.

Figure 4.12: La phase de chargement

4.2.2 Intégration de la partie DevOps

Jusqu’à présent, le développement avec Qlik Sense était de manière plutôt

classique, sans utiliser les meilleures pratiques du développement logiciel.

DevOps est une combinaison de pratiques et d’outils qui améliore la capacité

d’une entreprise à livrer des applications et des services à un rythme élevé.

Il permet de faire évoluer et d’optimiser les produits plus rapidement que les

entreprises utilisant des processus traditionnels de développement de logiciels

57
Chapitre 4. Implémentation

et de gestion de l’infrastructure.
Cette vitesse permet aux entreprises de mieux servir leurs clients et de gagner

en compétitivité

[Link] C’est quoi QLBuilder

En général, qlbuilder est un outil qui communique avec les applications

Qlik (à l’aide de l’API Engine) et définit le script. Le script est situé sur la

machine locale et peut être "assemblé" à partir de plusieurs fichiers.

- Pourquoi utiliser qlbuilder ?

Tout le monde a son propre éditeur IDE / texte préféré et nous pouvons y écrire
ses propres scripts de chargement Qlik Sense et utiliser include / mustinclude à

l’intérieur de l’application pour "amener" le script à l’intérieur de l’application.

Mais ce sera bien si nous pouvons écrire les scripts localement et les télécharger

directement dans l’application telle quelle.

L’idée de base est que nous allons écrire chaque onglet de script Qlik Sense

dans un fichier .qvs distinct et que qlbuilder les combinera (si nécessaire) dans
un seul fichier et définira son contenu dans l’application Qlik Sense dédiée

(sur un environnement QS dédié). Qlbuilder peut effectuer quelques actions

supplémentaires, à part combiner et définir le script : vérifier les erreurs de

syntaxe, recharger l’application, "surveiller" les changements de script et vérifier

les erreurs de syntaxe. Avec cette approche, je peux écrire mon script dans Visual
Studio Code (en combinaison avec Qlik pour Visual Studio Code extension) et

utiliser tous les raccourcis.

- Les commandes QLbuilder :

58
Chapitre 4. Implémentation

— Crée les dossiers et fichiers initiaux dans le dossier actuel.

- qlbuilder create [nom]

— Construit le script de chargement complet à partir des fichiers /src/*.qvs.

- build qlbuilder

— Se connecte à Qlik et recharge l’application .

- qlbuilder reload [env]

[Link] Plateforme de gestion d’application analytics

Afin d’assurer la gestion des applications qlik et assurer leurs automatisation

et leurs intégration par GitLab , nous avons opté pour une phase additionnelle

qui se résume en ces trois grande étapes comme suit.

- Connexion avec une application QlikSense :

Premièrement, nous avons créé le projet à travers QLBuilder Create, comme

présenté ci-dessous.

Figure 4.13: Création d’un projet QLBuilder

Maintenant en faisant ainsi un changement dans le fichier de configuration

59
Chapitre 4. Implémentation

[Link], et ce pour assurer la connexion au serveur, la figure suivante présente

le fichier [Link].

Figure 4.14: Le fichier [Link]

Ensuite, nous avons créé un fichier [Link] dont on a mis les coordonnées
de l’utilisateur pour accéder au serveur comme dans la figure suivante.

Figure 4.15: Le fichier [Link]

Puis, à travers la commande « GetScript » nous allons importer des QVS

vers Visual Studio Code comme le détaillera la figure suivante.

Figure 4.16: L’importation d’un fichier QVS

Enfin, nous sommes amenés à passer par cette phase de chargement, qui

a pour but d’exécuter le script pour charger l’application comme le montre la

figure suivante.

60
Chapitre 4. Implémentation

Figure 4.17: Le Reload de l’application

- Création script PipeLine :

Après le chargement de l’application, on vise l’automatisation de cette dernière

et pour se faire nous avons coder un script pipeline comme illustre la figure

suivante qui va opérer comme suit :

— Pull du projet sur le desktop

— Reload de l’application

61
Chapitre 4. Implémentation

Figure 4.18: Script PipeLine

- Notification d’un mail d’alerte :

En cas d’échec de chargement de l’application sur GitLab, un mail sera envoyer

avec tous les détails des erreurs, comme le démontre la figure suivante.

Figure 4.19: Notification d’un mail d’alerte

62
Chapitre 4. Implémentation

[Link] Livraison des correctifs(Patch)

- C’est quoi un patch :

C’est un correctif développé par le vendeur du logiciel. Ça permet d’ajouter

quelques fonctionnalités qui n’étaient pas prêtes au moment du lancement public

ou bien ça permet de corriger des bugs.

Par ailleurs, l’ordre d’application des patches peut s’avérer essentiel : passer un

patch avant un autre peut conduire à une situation difficilement récupérable.

D’où, on a eu recours à un logiciel de management des projets qui offre l’avantage

de l’intégration continue. On parle sur le fameux GitLab.

- Création d’un patch :

Nous avons utilisé GitLab en développant les releases sur de branches spécifiques.
Dans ce cas, l’employé va gérer le déploiement des patchs crées sur la branche

Master, la figure ci-dessous illustre la création d’une nouvelle branche.

— Dans le Projet créer une nouvelle branche à partir de la branche master

nommé : PatchV1

— Faire les modifications nécessaires sur le code de la branche PatchV1.

63
Chapitre 4. Implémentation

Figure 4.20: Création d’une branche

Le résultat de l’application des commandes suivantes sera présenté dans

la figure suivante :

git add .
git commit -m "Modification "

git push-uorigin PatchV1

Figure 4.21: Push sur une nouvelle branche GitLab

Créer un patch contenant les changements appliqués au script de la branche

64
Chapitre 4. Implémentation

PatchV1 par rapport la branche master. Voiçi les commandes :

Git diff master PatchV1> [Link]

Get-Content ..patch | Set-Content -Encoding utf8 [Link]

Figure 4.22: Création d’un patch

- Application d’un patch :

Appliquer le patch livré par les développeurs pour mettre à jour la branche à
travers la commande suivante :

git apply [Link]

Figure 4.23: Application du patch

Conclusion

Ce chapitre présente la phase la plus importante dans le projet, où on a

expliqué le déroulement du travail ainsi qu’on a montré le « comment » des

choses. Ce qui nous conduit au dernier chapitre de la restitution des données.

65
 Chapitre 5

Déploiement et visualisation

Plan
1 Déploiement de l’application «Governance» . . . . . . . . . . . . 67

2 Déploiement sur GitLab . . . . . . . . . . . . . . . . . . . . . . . . 74

Chapitre 5 : Déploiement et visualisation

Introduction

Ce dernier chapitre englobera les différentes maquettes à réaliser ainsi que

les tableaux de bord du système. Le chapitre précédent nous a implémenter au

niveau de l’application, ce qui nous ramène aux spécifications et développement

de l’application utilisateur.

5.1 Déploiement de l’application «Governance»

5.1.1 Choix du thème

Le support fondamental de toute communication d’une application se base

essentiellement sur sa charte graphique.

L’un des objectifs de la charte graphique est de maintenir la cohérence graphique

dans l’application, sa mise en œuvre garantit une identité visuelle unifiée et

permet donc de communiquer d’une seule.

Nous avons eu l’inspiration de l’ancien thème de l’application fournie par Sopra

illustrée dans la figure suivante, pour mettre en place un nouveau thème qui
garantit une meilleure ergonomie et un éclat de couleur. La figure Thème QlikSense

montre notre application.

67
Chapitre 5. Déploiement et visualisation

Figure 5.1: Thème QlikSense

5.1.2 Visualisation des Dashboards

[Link] Dashboard Licence

C’est la partie initiale du Dashboard, qui nous procure des informations

les plus importantes.

Une partie « Overview » qui donne un historique de 7jours jusqu’à 90jours du

nombre total des utilisateurs qui ont accès au serveur ainsi que les « Professional

Users », « Max Sense Engine RAM », « Max Concurrent User » et « First Time
User ».

On a aussi une partie Licence «allocated access» qui montre la liste des utilisateurs

68
Chapitre 5. Déploiement et visualisation

qui ont édité les droits d’accès des autres utilisateurs au serveur.
Une autre partie consacrée aux informations du serveur comme le sera figuré

ci-dessous.

Figure 5.2: Dashboard license

[Link] Dashboard Application

Pour cette feuille, nous trouvons en haut les filtres temporels avec lesquels
on veut organiser l’affichage des données (TimeStamp, Months. . . )

Nous trouvons essentiellement les informations relatives aux streams, telles que
le nombre d’utilisateurs travaillant sur les stream et les applications. Aussi on

a les top 50 applications selon le nombre des utilisateurs y travaillant.

69
Chapitre 5. Déploiement et visualisation

On a consacré ensuite une partie pour les détails de la session contenant l’ID
et le nom de l’utilisateur travaillant dessus, le temps de calcul sur le processeur

CPU ainsi que la durée de la session. La figure ci-dessous montre le dashboard

Application.

Figure 5.3: Dashboard Application

[Link] Dashboard User

Cette interface englobe les informations sur les utilisateurs ainsi que leurs
sessions.

On peut examiner les données selon les filtres prédéfinis placés en haut, tels
que l’heure (TimeFrame), la date (Month, weekBegining. . . ), Allocated Access

70
Chapitre 5. Déploiement et visualisation

Type (Professional or simple User), App Stream. . .

Trié par date, on trouve la liste des utilisateurs avec leurs droits d’accès accordés

au serveur. Aussi, on a l’histogramme qui forme les tops 50 utilisateurs selon

leurs nombres de sessions, et à l’instar de ce dernier, on a un autre histogramme

ayant le nombre des utilisateurs par sessions.

Le dernier histogramme encadre le First Time User, le nombre de nouveaux

utilisateurs par jour. Enfin, on a tout englobé dans un tableau contenant tout
utilisateur ayant accès au serveur avec leurs types (Professional or simple user)

avec leurs droit d’accès et la date de la dernière connexion.

Figure 5.4: Dashboard User

71
Chapitre 5. Déploiement et visualisation

[Link] Dashboard App Details

Comme le nom indique cette feuille regroupe toute informations relatives

aux applications : ID, taille, stream. . .

Ainsi, nous avons deux histogrammes démontrant l’utilisation du processeur par

utilisateur et par application. La figure suivante illustre la feuille App Details.

Figure 5.5: Dashboard App Details

[Link] Dashboard Performance

Tout d’abord on a une partie Overview qui met en valeur trier par date,

les informations des utilisateurs telles que les « First Time Users » et le nombre
total des utilisateurs connectés au serveur. Ensuite, on a les pourcentages des :

72
Chapitre 5. Déploiement et visualisation

— Utilisation maximale de la RAM

— Utilisation maximale du CPU

— Le nombre des reloads

— Le nombre des reloads échoués

— La durée moyenne des reloads

— La durée maximale des reloads

— Le nombre des erreurs et alertes.

Enfin, on a consacré une partie pour le pourcentage du max de temps de

calcul du CPU ainsi que la RAM sous forme de courbe qui sera mieux démontrer
par la figure suivante

Figure 5.6: La feuille Performance

73
Chapitre 5. Déploiement et visualisation

[Link] Dashboard Task Details

A l’instar de la dernière feuille, Task Details et aussi dédiée aux informations

des tâches et les reloads. L’affichage est personnalisé par année, mois, semaine,
jour, heure. . .

La figure suivante illustre la feuille Task Details.

Figure 5.7: Dashboard Task Details

5.2 Déploiement sur GitLab

Afin d’assurer l’automatisation du chargement des applications, nous avons

déployé le projet sur GitLab.

Dans les étapes précédentes particulièrement dans la phase SensOps, on a vu

comment charger le script sous Visual Code et à partir du script pipeline nous

74
Chapitre 5. Déploiement et visualisation

avons créé les « Job ».

La figure ci-dessous montre le résultat après l’exécution des scripts.

Figure 5.8: Déploiement de l’application sur GitLab

Conclusion

A travers ce dernier chapitre nous avons illustré quelques scenarios de ce

travail à travers des captures d’écran témoignant des différentes Dashboard que
contient notre application.

75
Conclusion générale

Ce projet est le fruit de travail quotidien de cinq mois au sein de la société

Sopra HR, et qui s’enroule dans le cadre de stage de fin d’études d’ingénierie
informatique à ESPRIT.

Ce travail a pour objectif la conception et implémentation d’un Cockpit d’admini

-stration pour SHR Analytics Governance, qui fait partie de l’amélioration de

la gestion des environnements analytics.

A l’issue de cet objectif, nous avons comme mission de collecter les données

de l’environnement analytics afin de les restituer sous forme de Dashboard et

KPIs, ainsi que la mise en place d’un système de notification pour alerter en cas

de problème.
Ensuite, nous avons consacré le temps pour comprendre les fondements de la

business intelligence, qui présentent un challenge vu la restriction temporelle et

la quantité de travail à accomplir. Durant la formation d’ingénierie, et tenant

compte que nous avons suivi une spécialité basée sur le cloud computing, les

bases de la business intelligence étaient un nouvel axe à conquérir.

Nous avons consacré un temps quotidien pour les réunions avec l’encadrant afin

d’examiner l’avancement des tâches à réaliser.

Enfin, cette expérience m’est très chère vu les challenges achevés avec les
efforts de toute l’équipe et particulièrement la disponibilité de l’encadrant, elle

nous a permis de maîtriser les enjeux de la business intelligence et ce projet

76
Conclusion générale

était une introduction au domaine du Devops, en effet en suivant les bonnes

pratiques du DevOps, on a introduit un changement fondamental au niveau de

la façon dont les opérations de développement sont effectuées aujourd’hui.

En perspective, ce projet peut être enrichi en assurant le déploiement sur

Docker ainsi que l’utilisation du kubernetes au niveau de l’infrastructure, et ce

pour permettre au QlikSense de devenir une propre Infrastructure à Sopra.

77
Bibliographie

[1] (18 juillet 2018). Sopra Steroa. [Accès le 8-Février-2020], Sopra Steria, adresse : http:
//[Link]%20HR%[Link]//.

[2] D. R. Humaine. (20 janvier 2018). Document interne. [Accès le 06-Février-2020], Sopra
HR Software.

[3] M. agile. (3mars 2014). Méthode agile. [Accès le 15-février-2020], adresse : https :
//[Link]/.

[4] piloter. (3avril 2012). [Accès le 6-février-2020], adresse : [Link]

[5] A. Fernandez. (26 juin 2009). Les nouveaux tableaux de bord des managers. [Accès
le 26-Février-2020].

[6] RH. (). Diagramme de GANTT. [Accès le 14 Mars-2020], adresse : [Link]

com/fr.

[7] B. Intelligence. (). BI. [Accès le 14 Mars-2020], adresse : [Link]

business-Intelligence#.XupJgEVKg2w.

[8] C. décisionnelle. (). BI. [Accès le 3-Avril-2020], adresse : [Link]

business - intelligence / business - intelligence . htm# : ~ : text = Les % 204 % 20fonctions %
20de % 20la , %C3 % A0 % 20une % 20phase % 20du % 20processus . &text = Les % 204 %
20phases%20du%20processus,la%20donn%C3%A9e%20%C3%A0%20l’information..

[9] RH. (). BI. [Accès le 21-Avril-2020], adresse : https : / / www . piloter . org / business -
intelligence/[Link].

[10] (). SensOps. [Accès le 22-Avril-2020], adresse : [Link]

[11] A. Fernandez. (6Aout 2016). Les nouveaux tableaux de bord des managers. [Accès
le 06-Février-2020].

[12] (). Les outils logiciels. [Accès Mai-2020], adresse : [Link]

78
Document Information

Analyzed document Karim_FOURATI_version_3.docx (D75505479)

Submitted 6/23/2020 [Link] PM

Submitted by
Submitter email [Link]@[Link]

Similarity 10%
Analysis address [Link]@[Link]

Sources included in the report

URL: [Link]
5
Fetched: 5/8/2019 [Link] PM

URL:
[Link] ... 9
Fetched: 3/28/2020 [Link] PM

URL: [Link]
1
Fetched: 6/23/2020 [Link] PM

URL: [Link] ...

1
Fetched: 6/23/2020 [Link] PM

URL: [Link]
3
Fetched: 6/23/2020 [Link] PM

URL: [Link] ...

1
Fetched: 6/14/2020 [Link] AM

1/22
Résumé
Ce travail s’inscrit dans le cadre du projet de fin d’études réalisé au sein de la

société Sopra Steria en vue de l’obtention du diplôme national d’ingénieur à l’École

supérieure privée d’ingénierie et de technologie. L’objectif de ce projet consiste à la

réalisation d’une application du monitoring du serveur, ainsi que l’automatisation

des tâches et le déploiement sur GitLab.

Mots clés : Monitoring, automatisation des tâches, déploiement, GitLab

Abstract
This work is part of the end study project, within the company Sopra Steria with

a view to obtaining the national engineering degree at the Private Higher School
of Engineering and Technology. This project consists in the realization of a server

monitoring application, as well as the automation of tasks and the deployment on

GitLab.

Keywords : Monitoring, automation of tasks, deployment