Vous êtes sur la page 1sur 155
Mémoire de fin d’études Pour l’obtention du diplôme d’Ingénieur d’Etat en Informatique Option : Systèmes

Mémoire de fin d’études

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

Option : Systèmes d’information

Thème

Conception et réalisation d’un Data Warehouse pour la mise en place d’un système décisionnel

Document de base

Réalisé par

- FILALI ABDERRAHMANE

- KEDJNANE SOFIANE

Promotion : 2009/2010

Encadré par

- MERABET SOUAD

- MEDJAOUI NADJI

Remerciements

Nos remerciements vont tout spécialement à nos familles, qui ont sus nous supporter et encourager tout au long de notre vie, ainsi que pour leur aide inestimable, leur patience et leur soutien indéfectible.

Nous tenons aussi, à remercier tout les enseignants qui ont contribué de près ou de loin à notre formation.

Nous remercions Mme Souad Merbet et M. Nadji Medjaoui pour avoir assuré l’encadrement de ce projet, qui n’a pas toujours été de tout repos. On remercie monsieur Medjaoui pour nos séances de travail agréables et fructueuses, ses remarques pertinentes, mais aussi pour son écoute et son discours bienveillants.

Nous remercions Mme Merabet pour la confiance quelle nous a accordé et de nous avoir donné l’opportunité de travailler sur un projet d’une tel envergure.

Nous remercions Mme Ait Ali Yahia pour ces critiques constructives qui nous ont permis d’améliorer ce mémoire.

Nous nous devons de mentionner la précieuse et totale collaboration que nous avons reçu au sein de ELIT, de part les moyens mis à notre disposition et l’aide et le support apporté par l’ensemble des employés et des cadres.

On remercie vivement Mesdames et Messieurs les membres du jury d’avoir accepter d’évaluer ce travail.

Pour finir, et afin de n’oublier personne (amis, membre de la famille et tous ceux qui nous sont chers) nous utiliserons la formule : « Merci à… ».

^xw}ÇtÇx^xw}ÇtÇx^xw}ÇtÇx^xw}ÇtÇx 9999 Y|ÄtÄ|Y|ÄtÄ|Y|ÄtÄ|Y|ÄtÄ|

DédicacesDédicacesDédicacesDédicaces

Je dédie ce modeste travail à :

M

es parents, qui n’ont jamais cessé de m’encourager et me soutenir,

M

on

frère : M ohammed, et mes sœurs :Amina et Soumia

M

on binôme et ami

Sofiane et sa famille,

M

es amis : Amine, M ouhata, M ohammed, Lotfi …

Tous les membres de ma famille,

Ceux qui me sont chers,

M on cousin : Samir, puisse dieu l’accueillir dans son vaste paradis.

TuwxÜÜt{ÅtÇx

DédicacesDédicacesDédicacesDédicaces

A

:

M es parents, pour leur soutient indéniable et leur aide précieuse

« Pourrais-je jamais vous dire tous mon amour»,

M a grand-mère, pour sa patience et pour avoir su me supporter,

M a

sœur

Linda,

et

mes

frères

Tareq

encouragements et leur amour,

et

Yacine,

pour

leurs

Tous les membres de la famille, pour l’intérêt qu’ils m’ont montré,

M on binôme (et ami) Abderrahmane

pour ce qu’ils m’ont apporté,

« Hamza » et toute sa famille,

M es amis, pour tous ce qu’on a partagé ensemble,

Toutes les personnes proches que je n’ai pas citées

Je dédie ce travail.

fÉy|tÇx

Sommaire Résumé :……………………………………………………………………………………… I

Abréviations :………………………………………………………………………………….II

Liste des tableaux …………………………………………………………………………….IV

Liste des figures ……………………………………………………………………………

VI

Introduction générale

9

1. Problématique

10

2. Objectifs du projet

11

 

Partie I: Synthèse Bibliographique.

I. Introduction

15

I.1.

Les systèmes décisionnels

15

I.1.1.

La place du décisionnel dans l’entreprise

16

I.1.2.

Les différents composantes du décisionnel

17

I.2.

Décisionnel vs transactionnel

18

II. Le Data Warehouse

19

II.1

Qu’est ce qu’un Data Warehouse

19

II.2

Historique des Data Warehouse

20

II.3

Structure des données d’un Data Warehouse

21

II.4

Les éléments d’un Data Warehouse

22

II.5

Architecture d’un Data Warehouse

25

III.

Modélisation des données de l’entrepôt

26

III.1

La modélisation dimensionnelle et ses concepts

26

III.1.1

Concept de fait

27

III.1.2

Concept de dimension

27

III.1.3

Comparatif entre les tables de faits et les tables de dimensions

28

III.2

Différents modèles de la modélisation dimensionnelle

28

III.3

Le concept OLAP

29

III.3.1

Généralités

29

III.3.2

Architectures des serveurs OLAP

29

III.4

La navigation dans les données

31

III.4.1

Slice & Dice

31

III.4.2

Drill-down & Roll-up

32

IV.

Démarche de Construction d’un Data Warehouse

34

IV.1

Modélisation et conception du Data Warehouse

34

IV.1.2

Approche « Source de données »

35

IV.1.3

Approche mixte

36

IV.2

Alimentation du Data Warehouse

37

IV.2.1

Les phases de l’alimentation « E.T.L. »

37

IV.2.2

Politiques de l’alimentation

38

IV.2.3

Les outils

40

IV.3

Mise en œuvre du Data Warehouse

40

IV.4

Maintenance et expansion

42

V.

Conclusion

43

 

PartieII: Conception de la solution.

Chapitre 1: Présentation de l'organisme d'accueil.

 

I. Présentation de SONELGAZ

46

I.1 Historique

46

I.1.1

Organisation du groupe SONELGAZ

47

I.1.2

Le groupe SONELGAZ en chiffres

49

I.2

Le métier de la distribution

50

I.2.1

Organisation des sociétés de distribution

51

I.2.2

La clientèle de la distribution

52

I.3

L’informatique au sein du groupe SONELGAZ

53

I.3.1

Présentation de la filiale « ELIT »

53

II. Conclusion

56

Chapitre 2: L'éxistant décisionnel.

I. Introduction

58

II. Etat du décisionnel au sein du groupe

58

II.1

Niveau Groupe

58

II.2

Niveau Société de Distribution

60

II.3

Niveau Direction de Distribution

61

III.

Conclusion

62

Chapitre 3:Etude des besoins.

I.

Introduction

64

I.1

Description de la démarche d'étude des besoins

65

1. Étude préliminaire des systèmes sources et interviews sommaires avec les DBA

65

2. Détection des postes susceptibles d'être porteur d'informations utiles

65

3. Planification, préparation et conduite des interviews

66

5.

Rédaction et validation du recueil récapitulatif des besoins

68

 

I.2

Problèmes et obstacles rencontrés

69

II.

Conclusion

70

Chapitre 4: Conception de la zone « entreposage des données ».

I. Introduction

73

II. Processus de la modélisation dimensionnelle

73

 

II.1

Volet « vente »

74

II.2

Volet « recouvrement »

89

II.3

Volet « suivi des affaires »

93

II.4

Volet « Suivi des abonnés »

99

III.

Conclusion

103

Chapitre 5: Conception de la zone « Alimentation ».

I. Introduction

105

II. Etude et planification

105

 

II.1

Les sources de données

105

II.2

Détection des emplacements des données sources

106

II.3

Définition de la périodicité de chargement

106

III. Architecture du processus d’alimentation

107

IV. Processus de chargement

109

 

IV.1

Processus de chargement de dimension

110

IV.2

Processus de chargement des table de fait

112

IV.3

Processus de chargement particulier

114

IV.3.1

Processus de chargement de la dimension « temps »

114

IV.3.2

Processus de construction d’agrégats

114

V.

Conclusion

115

Chapitre 6: Conception des cubes dimensionnels.

I. Définition des niveaux et des hiérarchies

117

II. La liste des cubes

121

III. Présentation des cubes dimensionnels

123

IV. Conclusion

123

Chapitre 7: Conception des Meta Data.

I. Les « Meta Data » ou « méta données » de l’entrepôt

129

II. Rôle des méta données

129

III. Exploitation des métas données

133

III.2 Présentation de la partie supervision

133

IV. Conclusion

133

Partie III: Implémentation et déploiement.

I. Introduction

135

II. Implémentation

II.1

135

Périmètre technique et fonctionnel

135

II.1.1

II.1.2

Matériel

135

Systèmes d’exploitation

135

II.2

II.3

II.4

Architecture technique de la solution

136

Zone de stockage

136

Zone d’alimentation de l’entrepôt

137

II.5

Zone de restitution

137

III.

Déploiement

139

III.1

Déploiement de la zone d’alimentation

139

III.2

Déploiement de la zone de restitution

140

IV. Conclusion ………………………………………… ……………………………….141

Conclusion générale et perspectives ……………… Bibliographie

……………………………………142

145

Résumé :

Le groupe SONELGAZ, premier opérateur énergétique en Algérie, assure plusieurs missions dans le domaine de l’énergie. Ces dernières, allant de la gestion du réseau électrique et gazier à la distribution et commercialisation de l’électricité et du gaz au profit tant des professionnels que des particuliers, font de SONELGAZ un acteur incontournable de l’économie nationale. Le groupe SONELGAZ rencontre, dans le cadre de son activité de distribution, quelques problèmes dans sa politique de Reporting clientèle. Ces difficultés sont liées notamment à la lenteur et au coût de la procédure, du fait du nombre important d’intermédiaires et/ou intervenants. Ces difficultés ont rendu tout effort d’analyse vain ; et c’est pourquoi les dirigeants du groupe aspirent à la mise en place d’un système qui procure aux décideurs les informations nécessaires et fiables, les aidant ainsi à pendre dans les meilleurs délais les décisions les plus appropriées. Dans ce contexte, et afin de répondre à ces attentes grandissantes le groupe a sollicité sa filiale spécialisée dans les systèmes d’information et les nouvelles technologies « Elit ». Le But recherché étant d’aller vers la mise en place d’un système s’inscrivant dans le cadre du Système de Gestion de la Clientèle « S.G.C ». Ce système sera construit autour d’une base de données dédiée totalement aux décisionnel un « Data Warehouse » et répondant à tout les besoins d’analyse du groupe dans sa fonction de distribution. Ce présent projet a donc pour vocation première de réaliser une telle base de données. Mots clés : Data Warehouse « Entrepôt de données », Décisionnel, Business Intelligence « B.I », intégration de données, solutions « BI » Open Source.

Abréviations :

BI : Business Intelligence. BT : Basse Tension. BP : Basse Pression.

CTI : Centre de Traitement Informatique. DAP : Direction Analyses et Prévision. DAR : Direction Affaires De Régulation. DBA : Data Base Administrator. DCF : Direction Comptabilité et Finance. DCM: Direction Commercial Et Marketing. DD : Direction de Distribution. DED : Département Etudes et Développement. DGDS : Direction Générale du Développement et de la Stratégie. DIM : Dimension. DR : direction régionale(DD). DRD : Direction de Distribution Régionale. DW : Data Warehouse (Entrepôt de données). ED : Etude et développent. EDW : Entreprise Data Warehouse. EGA : Electricité et Gaz d’Algérie. ELIT : EL-djazaïr Information Technology. EPIC : Etablissement Publique à caractère Industriel et Commercial. ETL : Extract, Transform and Load (ETC). FK: Foreign Key. FTP : File Transfer Protocol. HOLAP: Hybrid On Line Analytical Process. HP : Haute Pression. HT : Haute Tension. MOLAP: Multidimensional On Line Analytical Process. MP: Moyenne Pression. MT : Moyenne Tension. OLAP : On Line Analytical Process. OLTP: On Line Transactional Process.

PDG: Président Directeur General. PK : Primary Key. ROLAP : Relational On Line Analytical Process. SD : Socièté de Distribution. SGC : Système de Gestion de la Clientèle. SI : Systèmes d’Information. SID: Systèmes d’Information Décisionnels. SID : Systèmes d’information de la distribution. SIAD : Systèmes d’Information d’Aide à la Décision SGBD : Système de Gestion de Base de Données. SMTP : Server Mail Transfer Protocol. SONELGAZ : Société Nationale de l’Electricité et du GAZ. SPA : Société Par Action. SQL : Structured Query Language.

Liste des tableaux

Partie I : Synthèse Bibliographique.

Tableau I.1 : Tableau comparatif entre les systèmes transactionnels et les systèmes décisionnels

6

Tableau I.2 : Tableau comparatif entre les tables de faits et les tables de dimensions

16

Tableau I.3 : Avantages et inconvénients de l’approche « Besoins d’analyse »

23

Tableau I.4 : Avantages et inconvénients de l’approche « Sources de données »

24

 

Partie II: Conception de la solution.

Tableau II.1 :

Le groupe SONELGAZ en chiffres

38

Tableau II.2 :

Présentation des sociétés de distribution

40

Tableau II.3 :

Tableau présentant la population a interviewé

54

Tableau II.4 :

Synthétisation des besoins détectés

56

Tableau II.5 :

Tableau descriptif de la dimension « Temps »

63

Tableau II.6 :

Tableau descriptif de la dimension « Client »

65

Tableau II.7 :

Tableau descriptif de la dimension « Facture »

67

Tableau II.8 :

Tableau descriptif de la dimension « Zone géographique »

69

Tableau II.9 :

Tableau descriptif de la dimension « Activité »

70

Tableau II.10 : Tableau descriptif de la dimension « Tarif »

70

Tableau II.11 : Tableau descriptif de la dimension « Energie »

71

Tableau II.12 : Liste des agrégats potentiels de l’activité « Vente »

75

Tableau II.13 : Liste des agrégats utiles de l’activité « Vente »

75

Tableau II.14 : Détection des dimensions communes entre les volets « Vente » et

«

Recouvrement »

76

Tableau II.15 : Tableau descriptif de la dimension « Nature »

77

Tableau II.16 : Tableau descriptif des agrégats potentiel du modèle « Recouvrement »

79

Tableau II.17 : Tableau descriptif des agrégats utiles du modèle « Recouvrement »

79

Tableau II.18 : Détection des dimensions communes entre les volets « Vente »,

« Recouvrement » et « Suivi des affaires »………………… …………….…………………80

Tableau II.19 : Tableau descriptif de la dimension « Affaire»

81

Tableau II.20 : Tableau descriptif de la dimension « Type affaire »

8

Tableau II.21 : Tableau descriptif de la dimension « Phase »

83

Tableau II.22 : Tableau descriptif des agrégats potentiel du modèle « suivi des affaires »

85

Tableau II.23 : Tableau descriptif de des agrégats utiles du modèle « Suivi des affaires »

85

Tableau II.24 : Détection des dimensions communes entre les volets « Vente »,

«

Recouvrement », « Suivi des affaires » et « suivi des abonnés »

86

Tableau II.25 : Tableau descriptif de la dimension « Type abonné »

87

Tableau II.26 : Tableau descriptif des agrégats potentiels du modèle « Suivi abonnés »

89

Tableau II.27 : Tableau descriptif des agrégats utiles du modèle « Suivi abonnés »

89

Tableau II.28 : Tableau donnant les nivaux hiérarchiques de chaque dimension

10

Tableau II.29 : Listes des cubes dimensionnels

107

Liste des figures

Figure I.1 :

Le décisionnel au sein du système d’information

9

Figure I.2 :

Les différentes composantes du décisionnel

5

Figure I.3 :

Historique des bases de données décisionnelles

8

Figure I.4 :

Structure des données d’un Data Warehouse

9

Figure I.5 :

Les Data Mart dans un entrepôt de données selon l’architecture proposée par

B. Inmon dite Entreprise Data Warehouse

Figure I.6 :

11

Les Data Mart dans un entrepôt de données selon l’architecture proposée par

R.

kimball dite approche bus

13

Figure I.7 :

Architecture globale d’un Data Warehouse

13

Figure I.8 :

Considération d’un sujet d’analyse comme un cube à plusieurs dimensions. 14

Figure I.9 :

Un modèle dimensionnel typique

15

Figure I.10 : Principe de l’architecture MOLAP

18

Figure I.11 : Principe de l’architecture ROLAP

18

Figure I.12 : Exemple de Slicing

20

Figure I.13 : Exemple de Dicing

20

Figure I.14 : Exemple de Roll up

21

Figure I.15 : Exemple de Drill Down

21

Figure I.16 : Illustration de l’approche « Besoin d’analyse » grâce au cycle de vie dimensionnel de kimball

22

Figure I.17 : Illustration de l’approche « source de données » grâce au cycle de développement du Data Warehouse de Inmon

23

Figure I.18 : Illustration de l’approche mixte

24

Figure I.19 : Objectif de qualité de données dans un processus E.T.L

27

Figure II.1 :

Planification de la conduite du projet

34

Figure II.2 :

Organigramme représentant l’organisation du Groupe SONELGAZ

37

Figure II.3 :

Evolution du chiffre d’affaire du groupe publiée dans le rapport d’activité de

l’année 2008 ………………………………………………………………………………38

Figure II.4 :

Répartition du chiffre d’affaire publiée dans le rapport d’activité de l’année

2008…………

39

Figure II.5 :

Organisation des sociétés de distribution

40

Figure II.6 :

Organisation des directions de distribution

41

Figure II.7 :

Organisation de la filiale ELIT

44

Figure II.8 :

Organisation de la direction d’étude et de développement

44

Figure II.9 :

Diagramme d’activité modélisant l’édition de rapport pour le niveau groupe48

Figure II.10 :

Warehouse………………………………………………………………………………….52

La place de l’étape de définition des besoins dans un projet Data

Figure II.11 :

 

Analyse des priorités du cas de la distribution « SONELGAZ »

60

Figure II.12 :

La dimension du Temps de l’activité « Vente »

64

Figure II.13 :

La dimension client de l’activité « Vente »

65

Figure II.14 :

La dimension facture de l’activité « Vente »

68

Figure II.15 :

La dimension zone de l’activité « Vente »

 

70

Figure II.16 :

La dimension activité de l’activité « Vente »

70

Figure II.17 :

La dimension Tarif de l’activité « Vente »

 

70

Figure II.18 :

La dimension énergie de l’activité « Vente »

71

Figure II.19 :

Modèle en étoile de l’activité « Vente »

 

74

Figure II.20 :

La dimension Nature de l’activité « Recouvrement »

78

Figure II.21 :

Modèle en étoile de l’activité « Recouvrement »

79

Figure II.22 :

La dimension affaire de l’activité «Suivi des affaires »

83

Figure II.23 :

La dimension type affaire de l’activité « Suivi des affaires »

82

Figure II.24 :

La dimension phase de l’activité « suivie des affaires »

83

Figure II.25 :

Modèle en étoile de l’activité « Suivie des affaires »

84

Figure II.26 :

La dimension type abonné de l’activité « Suivi des abonné »

87

Figure II.27 :

Modèle en étoile de l’activité « Suivi des abonné »

88

Figure II.28 :

Architecture global du processus E.T.L

 

95

Figure II.29 :

Diagramme d’activité du processus d’alimentation

94

Figure II.30 :

Diagramme d’activité du processus de chargement de dimension

98

Figure II.31 :

Diagramme d’activité du processus de chargement de fait

99

Figure II.32 :

Cube dimensionnel

« Suivi des ventes

»

109

Figure II.33 :

Cube dimensionnel « Suivi des ventes et des consommations

110

Figure II.34 :

Cube dimensionnel

« Suivi des abonnés »

 

111

Figure II.35 : Cube dimensionnel « Suivi des recouvrements

111

Figure

II.36

:

Cube

dimensionnel « Suivi

des

affaires

112

Figure II.37 :

Diagramme de classe des métadonnées

 

115

Figure II.38 :

DCU navigation dans les métadonnées et administration des MAJ

utilisateurs…………

 

116

Figure II.39 : DCU de

117

Figure II.40 :

 

Architecture technique de la

121

Figure II.41 :

Digramme de déploiement de la zone

 

125

Figure II.42 :

Diagramme de déploiement de la zone de

126

Introduction générale

Contexte général

C’est dans un environnement fortement complexe et hautement concurrentiel qu’évolue la majeure partie, si ce n’est la totalité, des entreprises. Ce climat de forte concurrence exige de ces entreprises une surveillance très étroite du marché afin de ne pas se laisser distancer par les concurrents et cela en répondant, le plus rapidement possible, aux attentes du marché, de leur clientèle et de leurs partenaires.

Pour se faire, les dirigeants de l’entreprise, quelque en soit d’ailleurs le domaine d’activité, doivent être en mesure de mener à bien les missions qui leur incombent en la matière. Ils devront prendre notamment les décisions les plus opportunes. Ces décisions, qui influeront grandement sur la stratégie de l’entreprise et donc sur son devenir, ne doivent pas être prises ni à la légère, ni de manière trop hâtive, compte tenu de leurs conséquences sur la survie de l’entreprise. Il s’agit de prendre des décisions fondées, basées sur des informations claires, fiables et pertinentes. Le problème est de savoir donc comment identifier et présenter ces informations à qui de droit, sachant par ailleurs que les entreprises croulent d’une part sous une masse considérable de données et que d’autre part les systèmes opérationnels « transactionnels » s’avèrent limités, voire inaptes à fournir de telles informations et constituer par la même un support appréciable à la prise de décision.

C’est dans ce contexte que les « systèmes décisionnels » ont vu le jour. Ils offrent aux décideurs des informations de qualité sur lesquelles ils pourront s’appuyer pour arrêter leurs choix décisionnels. Pour se faire, ces systèmes utilisent un large éventail de technologies et de méthodes, dont les « entrepôts de données » (Data Warehouse) représentent l’élément principal et incontournable pour la mise en place d’un bon système décisionnel.

De part sa dimension économique et sa position sur le marché énergétique algérien, l’activité journalière de la SONELGAZ génère des données complexes et volumineuses. Ces données représentent une source précieuse d’informations, qui serait à même d’améliorer de façon significative le processus de prise de décision. Cependant, ces données ne sont pas exploitées de manière satisfaisante, hypothéquant ainsi le processus de prise de décision à tous les niveaux du groupe.

Le présent projet tend à la mise en place d’un système en mesure de consolider les données issues des systèmes transactionnels, et d’offrir des informations de qualité pour les décideurs. Il s’agit en fait de mettre à la disposition des décideurs des données à même de les éclairer et leur faciliter une prise de décision prompte en connaissance de cause. Un tel système requiert la mise en place d’un entrepôt de données fiables contenant les informations nécessaires à l’accomplissement des processus décisionnels.

1. Problématique

Le groupe SONELGAZ est l’opérateur historique et leader du domaine énergétique en Algérie, notamment dans le domaine de la distribution de l’électricité et du gaz pour les professionnels et les particuliers.

Appelé à interagir avec ses clients sur différentes phases de la distribution (demande de branchement, facturation, résiliation,…etc.), le groupe s’est doté, dans un souci de suivi de la clientèle et de gestion de la distribution, d’un « Système de Gestion de la Clientèle –S.G.C.- » constitué de 35 applications, développées en interne et exploité par plus de 2900 utilisateurs. Ce système est déployé dans chacune des 58 directions de distributions « D.D. » exploitant une base de donnée décentralisée au niveau de chaque « D.D. ».

Dans un pareil contexte, la plus simple des opérations d’analyse devient une tâche ardue. En effet, les sociétés de distributions « SD » se trouvent dans l’incapacité de faire des analyses fiables, efficaces et à des moments opportuns sans engager des moyens considérables sur des périodes plus ou moins longues. Ainsi, les principales difficultés rencontrées peuvent être résumées en :

Difficultés dans l’élaboration des rapports d’activité :

généralement, plusieurs

intermédiaires. En effet, à chaque fois qu’il est nécessaire d’élaborer un rapport d’activité , il faudra procéder d’abord à l’ extraction les données à partir des 58 bases de données installées au niveau des directions de distribution, pour les acheminer ensuite manuellement vers une structure centralisée, qui en fera enfin la consolidation. Il s’agit là d’une procédure lourde outre les éventuelles incohérences et erreurs. Les retards enregistrés, parfois, font que le rapport d’activité est élaboré sur la base d’une consolidation antérieure, en sachant pertinemment que les données ne sont pas à jour.

L’élaboration

des

rapports

d’activité

fait

intervenir,

Lenteur de la procédure de Reporting : La politique de Reporting actuelle, qui du reste est quasi manuelle, connait des lenteurs qui n’arrangent pas les décideurs. Ceux ci ont besoin d’informations fiables et dans des délais raisonnables. À titre indicatif, l’édition d’un rapport national peut prendre, en moyenne, plus d’un mois ce qui est plus que pénalisant pour une bonne prise de décision.

Coût de la procédure de Reporting 1 : la procédure de Reporting est jugé très couteuse pour l’entreprise, et cela est principalement du au nombre d’intervenant et des moyens mis en place pour cette dernière.

Insuffisance du module « Statistique » : Afin de produire et offrir un moyen de suivi des activités de la distribution, un module « Statistique » a été développé et intégré dans le système « SGC ». Ce dernier fournit des états statistiques permettant, aux décideurs de niveau D.D., l’analyse et la prise de décision. Cependant, ce module connait quelques

1 Voir annexe A

problèmes dû au fait qu’il interroge directement la base de données en production. En effet le lancement de la production de n’importe quel rapport du module pénalise le système. Pour éviter cela le module n’est accessible qu’au chef du CTI de la DD.

2. Objectifs du projet

Afin de palier aux problèmes précédemment cités, le groupe a initié, à travers sa filiale Elit, le présent projet.

Ce projet a pour but d’introduire, en premier lieu, une informatique décisionnelle au sein du groupe, tout en conférant aux décideurs un support fiable pour une meilleure prise de décision. Ainsi, les principaux objectifs assignés au projet sont :

La réduction de la durée globale de l’élaboration des rapports, en essayant de ramener

cette durée, au moins, en dessous de la barre des 48 heures.

La Réduction des coûts de la procédure de Reporting actuelle.

La réduction du nombre d’intervenants lors de la production de rapports.

Offrir aux décideurs et aux analystes la possibilité de faire des analyses appropriées.

Offrir des informations fiables, cohérentes et pertinentes, contenant la logique

business souhaitée.

Planification et conduite du projet

L’initiation de tout proje t nécessite une phase de planification. C elle-ci permet de définir les tâches à réaliser, m aîtriser les risques et rendre compte de l’état d’avancement du projet.

« Planifier optimise ainsi l es chances de réussite d'un projet en améliora nt la productivité grâce à une meilleur e maîtrise de la qualité. » [Soler, 2001].

Pour garantir le bon déro ulement du projet, tout en respectant les délai s, nous avons

élaboré une planification globale

planification ainsi que l’ordonnan cement prévu des phases du projet.

de conduite du projet. Le diagramme suiva nt décrit cette

Con ception E.T.L
Con ception E.T.L

Figure : Planification et conduite du projet.

Afin de présenter notre tr avail, le présent mémoire est organisé en troi s parties et se présente comme suit :

Après une introduction gé nérale dans laquelle nous présentons le conte xte général du projet, ainsi que la problématique et les objectifs visés. La première partie prése nte les aspects théoriques du domaine des systè mes d’information d’aide à la décision, en é voquant leurs définitions et les concepts de base s relatifs aux « entrepôts de données » et à l a modélisation dimensionnelle.

Dans la deuxième partie, nous présentons le travail réalisé au sein du Groupe SONELGAZ à travers les six suivants chapitres:

Le chapitre un, présente l’organisme d’accueil, sa structure organisationnelle, son activité et la culture de l’entreprise en matière d’utilisation des technologies de l’information.

Le chapitre deux a pour vocation de présenter l’existant décisionnel au sein de l’entreprise et selon différents niveaux de prise de décision.

Le chapitre trois présente une synthèse de la collecte des besoins des utilisateurs, ainsi que son déroulement.

Le chapitre quatre contient la conception de la partie d’entreposage de notre solution. Il présente entre autre les modèles dimensionnels des activités recensées.

Le chapitre cinq à pour but de présenter la conception de la zone d’alimentation, ainsi que les stratégies adoptées.

Le chapitre six, quant à lui, donne la conception des cubes dimensionnels en détaillant les différentes caractéristiques de chaque cube (dimensions, mesurables et hiérarchies).

La troisième partie décrie l’architecture globale de la solution, et cela en présentant les différents outils intégrés et les volets de la solution développés. Elle décrit aussi la manière dont se passe le déploiement de la solution.

Une conclusion générale est proposée afin de synthétiser le travail réalisé et de citer les perspectives du projet.

Partie I :

Synthèse

bibliographique

« Un entrepôt de données ne s'achète pas, il se construit. » Bill Inmon

I.

Introduction

Toutes les entreprises du monde disposent d’une masse de données plus ou moins considérable. Ces informations proviennent soit de sources internes (générées par leurs systèmes opérationnels au fil des activités journalières), ou bien de sources externes (web,

partenaire,

etc.).

Cette surabondance de données, et l’impossibilité des systèmes opérationnels de les exploiter à des fins d’analyse conduit, inévitablement, l’entreprise à se tourner vers une nouvelle informatique dite décisionnelle qui met l’accent sur la compréhension de l’environnement de l’entreprise et l’exploitation de ces données à bon escient. En effet, les décideurs de l’entreprise ont besoin d’avoir une meilleure vision de leur environnement et de son évolution, ainsi, que des informations auxquelles ils peuvent se fier. Cela ne peut se faire qu’en mettant en place des indicateurs « business » clairs et pertinents permettant la sauvegarde, l’utilisation de la mémoire de l’entreprise et offrant à ses décideurs la possibilité de se reporter à ces indicateurs pour une bonne prise de décision.

Le « Data Warehouse », « Entrepôt de données » en français, constitue, dans ces conditions, une structure informatique et une fondation des plus incontournables pour la mise en place d’applications décisionnelles.

Le concept de Data Warehouse, tel que connu aujourd’hui, est apparu pour la première fois en 1980 ; l’idée consistait alors à réaliser une base de données destinée exclusivement au processus décisionnel. Les nouveaux besoins de l’entreprise, les quantités importantes de données produites par les systèmes opérationnels et l’apparition des technologies aptes à sa mise en œuvre ont contribué à l’apparition du concept « Data Warehouse » comme support aux systèmes décisionnels.

I.1. Les systèmes décisionnels

La raison d’être d’un entrepôt de données, comme évoqué précédemment, est la mise en place d’une informatique décisionnelle au sein de l’entreprise. Pour cela il serait assez intéressant de définir quelques concepts clés autour du décisionnel.

Afin de mieux comprendre la finalité des systèmes décisionnels, nous nous devons de les placer dans leurs contextes et rappeler ce qu’est un système d’information.

«Le système d’information est l’ensemble des méthodes et moyens de recueil de contrôle et de distribution des informations nécessaires à l’exercice de l’activité en tout point de l’organisation. Il a pour fonction de produire et de mémoriser les informations, de l’activité du système opérant (système opérationnel), puis de les mettre à disposition du système de décision (système de pilotage)»[Le Moigne, 1977].

Les différences qui existent entre le système de pilotage et le système opérationnel, du point de vue fonctionnel ou des tâches à effectuer, conduit à l’apparition des « systèmes d’information décisionnels » (S.I.D.). Ces différences seront clairement illustrées un peu plus loin dans notre document.

Les origines des SID remonte nt au début de l’informatique et des systèmes d’information qui ont, tous deux, connu une gra nde et complexe évolution liée notamment à l a technologie. Cette évolution se poursuit à ce jo ur 2 .

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

du décisionnel « business intelligence B.I. »

qui ont été

"Le Décisionnel est le pro cessus visant à transformer les données en in formations et, par l'intermédiaire d'inte rrogations successives, transformer ces inf ormations en

connaissances." [Dresner,

2001].

I.1.1.

La place du décisionn el dans l’entreprise:

2001]. I.1.1. La place du décisionn el dans l’entreprise: Figure I.1 : Le décision nel au

Figure I.1 : Le décision nel au sein du Système d’information [Goglin, 1998].

La figure ci-dessus illustr e parfaitement la place qui revient au décis ionnel au sein d’une entreprise. Cette place, com prend plusieurs fonctions clés de l’entreprise . Les finalités

but

décisionnelles, étant différentes

d’engendrer plusieurs composante s.

selon

le

poste

et

la

fonction

occupée,

ont

pour

2 Synthétisation à partir de la thèse de B ouzghoub A. « Modélisation des entrepôts de données XML:

application au domaine de la sécurité so ciale » [Bouzghoub, 2008].

I.1.2. Les différentes co mposantes du décisionnel

En relation étroite ave c les nouvelles technologies de l’inform ation et des

télécommunications, le système

utilités et leurs missions principal es, comme illustré dans la figure suivante :

décisionnel se manifeste à différents niveau x selon leurs

se manifeste à différents niveau x selon leurs Figure I.2 : Les différ entes composantes du

Figure I.2 :

Les différ entes composantes du décisionnel [Goglin, 19 98].

I.3. Décisionnel vs transactionnel

Le tableau suivant résume de façon non exhaustive les différences qu’il peut y avoir entre les systèmes transactionnels et les systèmes décisionnels selon les données et l’usage fait des systèmes.

Différence

Systèmes transactionnels

 

SID

 
 

Orienté applications

 

Orienté thèmes et sujets

 

par les données

Situation instantanée

 

Situation historique

 

Donnée

détaillées

et

codées

non

Informations agrégées cohérentes

redondantes

 

souvent avec redondance

 

Données changeantes constamment

Informations stables et synchronisées

dans le temps

 
 

Pas de référentiel commun

 

Un référentiel unique

 
 

Assure l’activité au quotidien

 

Permet

l’analyse

et

la

prise

de

 

décision

 

Pour les opérationnels

 

Pour les décideurs

 

Mises à jour et requêtes simples

 

Lecture unique et requêtes complexes

L’usage

 

transparentes

 

Temps de réponse immédiats

 

Temps de réponse moins critiques

 
 

Faibles volumes à chaque transaction

Large volume manipulé

 

Conçu pour la mise à jour

 

Conçue pour l’extraction

 

Usage maîtrisé

 

Usage aléatoire

 

Tableau I.1 : Tableau comparatif entre les systèmes transactionnels et les systèmes décisionnels.

Ces différences font ressortir la nécessité de mettre en place un système répondant aux besoins décisionnels. Ce système n’est rien d’autre que le « Data Warehouse ».

II.

Le Data Warehouse Qu’est ce qu’un Data Warehouse

II.1

Bill Inmon définit le Data Warehouse, dans son livre considéré comme étant la référence dans le domaine “Building the Data Warehouse” [Inmon, 2002] comme suit:

« Le Data Warehouse est une collection de données orientées sujet, intégrées, non volatiles et évolutives dans le temps, organisées pour le support d’un processus d’aide à la décision. »

Les paragraphes suivants illustrent les caractéristiques citées dans la définition d’Inmon.

Orienté sujet : le Data Warehouse est organisé autour des sujets majeurs de l’entreprise, contrairement à l’approche transactionnelle utilisée dans les systèmes opérationnels, qui sont conçus autour d’applications et de fonctions telles que : cartes bancaires, solvabilité client…, les Data Warehouse sont organisés autour de sujets majeurs de l’entreprise tels que : clientèle, ventes, produits…. Cette organisation affecte forcément la conception et l’implémentation des données contenues dans le Data Warehouse. Le contenu en données et en relations entre elles diffère aussi. Dans un système opérationnel, les données sont essentiellement destinées à satisfaire un processus fonctionnel et obéit à des règles de gestion, alors que celles d’un Data Warehouse sont destinées à un processus analytique.

Intégrée : le Data Warehouse va intégrer des données en provenance de différentes sources. Cela nécessite la gestion de toute incohérence.

Evolutives dans le temps : Dans un système décisionnel il est important de conserver les différentes valeurs d’une donnée, cela permet les comparaisons et le suivi de l’évolution des valeurs dans le temps, alors que dans un système opérationnel la valeur d’une donnée est simplement mise à jour. Dans un Data Warehouse chaque valeur est associée à un moment « Every key structure in the data warehouse contains - implicitly or explicitly -an element of time » [Inmon, 2000].

Non volatiles : c’est ce qui est, en quelque sorte la conséquence de l’historisation décrite précédemment. Une donnée dans un environnement opérationnel peut être mise à jour ou supprimée, de telles opérations n’existent pas dans un environnement Data Warehouse.

Organisées pour le support d’un processus d’aide à la décision : Les données du Data Warehouse sont organisées de manière à permettre l’exécution des processus d’aide à la décision (Reporting, Data Mining…).

II.2

Historique des Data Warehouse

L’origine du concept « Data Warehouse » D.W (entrepôt de données en français) remonte aux années 80, durant lesquelles un intérêt croissant au système décisionnel a vu le jour, dû essentiellement à l’émergence des SGBD relationnel et la simplicité du modèle relationnel et la puissance offerte par le langage SQL,

Au début, le Data Warehouse n’était rien d’autre qu’une copie des données du système opérationnel prise de façon périodique, dédiée à un environnement de support à la prise de décision. Ainsi, les données étaient extraites du système opérationnel, stockées dans une nouvelle base de données «concept d’infocentre », le motif principal étant de répondre aux requêtes des décideurs sans pour autant altérer les performances des systèmes opérationnels.

Le Data Warehouse, tel qu’on le connaît actuellement, n’est plus vu comme une copie -ou un cumul de copies prises de façon périodique- des données du système opérationnel. Il est devenu une nouvelle source d’information, alimenté avec des données recueillies et consolidées des différentes sources internes et externes.

Entrepôt de données Infocentre bases de données opérationnelles 1970 1980 1990
Entrepôt de
données
Infocentre
bases de
données
opérationnelles
1970
1980
1990

Figure I.3 :

évolution des bases de données décisionnelles.

II.3

Structure des données d’un Data Warehouse

Le Data Warehouse a une structure bien définie, selon différents niveaux d’agrégation et de détail des données. Cette structure est définie par Inmon [Inmon, 2000] comme suit :

Données fortement agrégées M Données agrégées E T A D O N N Données détaillées
Données fortement agrégées
M
Données agrégées
E
T
A
D
O
N
N
Données détaillées
É
E
S

Données détaillées archivées

Figure I.4 :

Structure des données d’un Data Warehouse.

Données détaillées : ce sont les données qui reflètent les événements les plus récents, fréquemment consultées, généralement volumineuses car elles sont d’un niveau détaillé.

généralement

stockées dans un disque de stockage de masse, peu coûteux, à un même niveau de détail que les données détaillées.

Données

détaillées

archivées :

anciennes

données

rarement

sollicitées,

Données agrégées : données agrégées à partir des données détaillées.

Données fortement agrégées : données agrégées à partir des données détaillées, à un niveau d’agrégation plus élevé que les données agrégées.

Meta données : ce sont les informations relatives à la structure des données, les méthodes d’agrégation et le lien entre les données opérationnelles et celles du Data Warehouse. Les métadonnées doivent renseigner sur :

Le modèle de données,

La structure des données telle qu’elle est vue par les développeurs,

La structure des données telle qu’elle est vue par les utilisateurs,

Les sources des données,

Les transformations nécessaires,

Suivi des alimentations,

II.4

Les éléments d’un Data Warehouse

L’environnement du Data Warehouse est constitué essentiellement de quatre composantes : les applications opérationnelles, la zone de préparation des données, la présentation des données et les outils d’accès aux données.

Les applications opérationnelles : ce sont les applications du système opérationnel de l’entreprise et dont la priorité est d’assurer le fonctionnement de ce dernier et sa performance. Ces applications sont extérieures au Data Warehouse.

Préparation des données : la préparation englobe tout ce qu’il y a entre les applications opérationnelles et la présentation des données. Elle est constituée d’un ensemble de processus appelé ETL, « Extract, transform and Load », les données sont extraites et stockées pour subir les transformations nécessaires avant leur chargement.

« Un point très important, dans l’aménagement d’un entrepôt de données, est d’interdire aux utilisateurs l’accès à la zone de préparation des données, qui ne fournit aucun service de requête ou de présentation » [Kimball, 2002].

Présentation des données : c’est l’entrepôt où les données sont organisées et stockées. Si les données de la zone de préparation sont interdites aux utilisateurs, la zone de présentation est tout ce que l’utilisateur voit et touche par le biais des outils d’accès.

L’entrepôt de données est constitué d’un ensemble de Data Mart. Ce dernier est défini comme étant une miniaturisation d’un Data Warehouse, construit autour d’un sujet précis d’analyse ou consacré à un niveau départemental 3 .

Cette différence de construction, autour d’un sujet ou au niveau départemental, définit la façon d’implémentation du Data Mart au niveau de l’entrepôt. On distingue, en effet, deux architectures internes du Data Warehouse :

3 Synthétisation [Chuck, 1998] page 86.

1.

Data Mart indépendant

Les Data Mart

sont des

départemental, alimentées par le

informations [Inmon, 2002].

versions miniaturisées du Data Warehou se au niveau

Data Warehouse et basées sur les besoins dépa rtementaux en

Warehouse et basées sur les besoins dépa rtementaux en Figure I.5 : les Data Mart dans

Figure I.5 :

les Data Mart dans un entrepôt de données selon l’architecture E ntreprise Data W arehouse (E.D.W) [Inmon, 2002].

2.

Data Mart interconnecté s

aux tables des

faits contenues dans le Data Wa rehouse, ce dernier se compose alors des Da ta Mart et ces tables des faits, appelées bus 4 .

Les Data Mart sont const ruits autour de sujets, interconnectés grâce

sont const ruits autour de sujets, interconnectés grâce Figure I.6 : les Data Mart dans un

Figure I.6 :

les Data Mart dans un entrepôt de données selon l’architecture b us de données

[Kimball, 2002].

l’ensemble des moyens fournis aux utilisat eurs du Data

Warehouse pour exploiter la zone de présentation des données en vue de la pri se de décision. Ces outils varient des simples req uêtes ad hoc aux outils permettant l’applicatio n de forage de

données plus complexes. Environ 80 à 90% des utilisateurs sont desservis par de es applications d’analyses préfabriquées, consista nt essentiellement en des requêtes préétablies.

Zone d’outils d’accès : c’est

4 Appellation proposée par R. Kimball da ns son ouvrage [Kimball, 2002].

II.5

Architecture d’un Data Warehouse

Après avoir exposé et défini chacun des éléments constituant l’environnement d’un Data Warehouse, il serait intéressant de connaitre le positionnement de ces éléments dans une architecture globale d’un Data Warehouse :

dans une architecture globale d’un Data Warehouse : Figure I.7 : Architecture globale d’un Data Warehouse

Figure I.7 : Architecture globale d’un Data Warehouse 5 .

5 http://www.formations-sas.fr/data-warehouse

III.

Modélisation des données de l’entrepôt

III.1

La modélisation dimensionnelle et ses concepts

Les Data Warehouse sont destinés à la mise en place de systèmes décisionnels. Ces systèmes, devant répondre à des objectifs différents des systèmes transactionnels, ont fait ressortir très vite la nécessité de recourir à un modèle de données simplifié et aisément compréhensible. La modélisation dimensionnelle permet cela. Elle consiste à considérer un sujet d’analyse comme un cube à plusieurs dimensions, offrant des vues en tranches ou des analyses selon différents axes.

des vues en tranches ou des analyses selon différents axes. Figure I.8 : Considération d’un sujet

Figure I.8 :

Considération d’un sujet d’analyse comme un cube à plusieurs dimensions.

En plus de la perception intuitive qu’offre la modélisation dimensionnelle, celle-ci est réputée pour ses performances élevées.

La nomination « schéma des jointures en étoile » a longtemps été adoptée pour décrire un modèle dimensionnel. Cette nomination est due au fait que le diagramme qui représente un modèle dimensionnel ressemble à une étoile, avec une grande table centrale et un jeu de petites tables auxiliaires disposées en étoile autour de la table centrale. Celle-ci est appelée table de faits et les autres tables sont appelées tables de dimensions. La figure suivante illustre untel modèle :

Figure I.9 : III.1.1 Concept de fait Un modèle dimensionnel typique [Kimball, 1996]. Une table

Figure I.9 :

III.1.1 Concept de fait

Un modèle dimensionnel typique [Kimball, 1996].

Une table de faits est la table centrale d’un modèle dimensionnel, où les mesures de performances sont stockées. Une ligne d’une table de faits correspond à une mesure. Ces mesures sont généralement des valeurs numériques, additives ; cependant des mesures textuelles peuvent exister mais sont rares. Le concepteur doit faire son possible pour faire des mesures textuelles des dimensions, car elles peuvent êtres corrélées efficacement avec les autres attributs textuels de dimensions.

Une table de faits assure les liens plusieurs à plusieurs entre les dimensions. Elles comportent des clés étrangères, qui ne sont autres que les clés primaires des tables de dimension.

III.1.2 Concept de dimension

Les tables de dimension sont les tables qui raccompagnent une table de faits, elles contiennent les descriptions textuelles de l’activité. Une table de dimension est constituée de nombreuses colonnes qui décrivent une ligne. C’est grâce à cette table que l’entrepôt de données est compréhensible et utilisable; elles permettent des analyses en tranches et en dés.

Une dimension est généralement constituée : d’une clé artificielle, une clé naturelle et des attributs.

« Une table de dimension établit l’interface homme / entrepôt, elle comporte une clé

primaire » [Kimball, 2002].

III.1.3 Comparatif entre les tables de faits et les tables de dimensions

Le tableau suivant récapitule les différences au niveau des données de ces tables :

 

Tables de faits

 

Tables de dimensions

Structure

Peu de colonnes beaucoup de lignes

Peu de lignes beaucoup de colonnes

Données

Mesurable, généralement numérique

Descriptives généralement textuelles

Référentiel

Plusieurs clés étrangères

 

Une clé primaire

Valeur

Prend de nombreuses valeurs

 

Plus ou moins constantes

Manipulation

Participe à des calculs

 

Participe à des contraintes

Signification

Valeurs de mesure

 

Descriptive

Rôle

Assure

les

relations

entre

les

Assure l’interface homme / entrepôt de données

dimensions

 

Tableau I.2 :

Tableau comparatif entre les tables de faits et les tables de dimensions.

III.2

Différents modèles de la modélisation dimensionnelle

Modèle en étoile : comme indiqué précédemment, ce modèle se présente comme une étoile dont le centre n’est autre que la table des faits et les branches sont les tables de dimension. La force de ce type de modélisation est sa lisibilité et sa performance.

Modèle en flocon : identique au modèle en étoile, sauf que ses branches sont éclatées en hiérarchies. Cette modélisation est généralement justifiée par l’économie d’espace de stockage, cependant elle peut s’avérer moins compréhensible pour l’utilisateur final, et très couteuse en terme de performances.

Modèle en constellation : Ce n’est rien d’autre que plusieurs modèles en étoile liés entre eux par des dimensions communes.

III.3

Le concept OLAP

III.3.1 Généralités

Le terme OLAP (On-Line Analytical Processing) désigne une classe de technologies conçue pour l’accès aux données et pour une analyse instantanée de ces dernières, dans le but de répondre aux besoins de Reporting et d’analyse.

R. Kimball définit le concept « OLAP » comme «Activité globale de requêtage et de présentation de données textuelles et numériques contenues dans l’entrepôt de données; Style d’interrogation spécifiquement dimensionnel » [Kimball, 2005].

C’est en continuant sur sa lancée, qui lui a permis de définir le model OLTP pour les bases de données relationnelles, que le concept OLAP fut introduit et défini 6 en 1993 par E.F Codd, le père des bases de données relationnelles, dans un document technique portant le titre de « Providing OLAP (On-Line Analytical Processing) to User-Analysts : An IT Man-date »

[Codd, 1993].

III.3.2 Architectures des serveurs OLAP

Le noyau d’un système OLAP est son serveur. Ces serveurs sont classés selon la politique régissant l’architecture du serveur. Ainsi, ces architectures peuvent être distinguées comme suit:

III.3.2.1

Les systèmes à architecture MOLAP

« Multidimentional On-line Analytical Processing » sont

conçus exceptionnellement pour l’analyse multidimensionnelle.

R. Kimball définit ces systèmes comme étant un « Ensemble d’interfaces utilisateur, d’applications et de technologies de bases de données propriétaire dont l’aspect dimensionnel est prépondérant » [Kimball, 2005].

Ainsi donc cette base adopte réellement la structure multidimensionnelle, exploitant de ce fait ces capacités au maximum. En effet MOLAP offre des temps d’accès optimisés et cela en prédéfinissant les opérations de manipulation et de chemin d’accès prédéfinis.

Autre caractéristique du MOLAP c’est qu’il agrège tout par défaut, pénalisant du coup le système lorsque la quantité de données à traiter augmente. On parle généralement de volume de l’ordre du giga-octet pas plus.

Ces systèmes MOLAP

6 Cette définition passe par l’introduction de 12 règles. Six autres règles furent par la suite, en 1995, ajoutées aux 12 précédentes et le terme « règles » remplacé par dispositif «features » par le même auteur à savoir Codd (Voir annexe B).

Data Warehouse

Data Warehouse D o n n é e s Stockage des données détaillées (et agrégées) Moteur

Données

Stockage des données détaillées (et agrégées)

Moteur MOLAP

des données détaillées (et agrégées) Moteur MOLAP Aide à la décision Présentation Traitements Rapports

Aide à la décision

(et agrégées) Moteur MOLAP Aide à la décision Présentation Traitements Rapports Multi-Dimensionnel Figure
(et agrégées) Moteur MOLAP Aide à la décision Présentation Traitements Rapports Multi-Dimensionnel Figure

Présentation

Traitements

Rapports

Multi-Dimensionnel

Figure I.10 :Principe de l’architecture MOLAP [Nakache, 1998].

III.3.2.2

Les systèmes à architecture ROLAP

vision

dimensionnelle à des bases de données relationnelles » [Kimball, 2005].

Les systèmes ROLAP « Relationnel On-line Analytical Processing » sont en mesure de simuler le comportement d’une SGBD multidimensionnel en exploitant un SGBD relationnel. L’utilisateur aura ainsi l’impression d’interroger un cube multidimensionnel alors qu’en réalité il ne fait qu’adresser des requêtes sur une base de données relationnelles.

ROLAP n’agrège rien. Les règles d’agrégations sont crées au préalable et représentées dans une table relationnelle ce qui cause une lourdeur d’administration mais confère une certaine performance et un gage de cohérence lors de l’utilisation.

Cette structure est généralement adoptée dans le but de se dispenser de l’acquisition d’un SGBD relationnel.

« Ensemble

d’interfaces

utilisateurs

et

d’applications qui

donnent

une

Data Warehouse Moteur ROLAP Aide à la décision Données Traitements Présentation
Data Warehouse
Moteur ROLAP
Aide à la décision
Données
Traitements
Présentation

Stockage des données détaillées (et agrégées) et des méta-données

Figure I.11 :

Génération de plans d'exécution SQL afin d'obtenir des fonctionnalités OLAP.

Rapports

Multi-Dimensionnel

Principe de l’architecture ROLAP [Nakache, 1998].

III.2.2.3 Les systèmes à architecture HOLAP

Les systèmes HOLAP « Hybride On-line Analytical Processing » sont une sorte de compromis entre les différents systèmes précités. Cette combinaison donne à ce type de système les avantages du ROLAP et du MOLAP en utilisant tour à tour l’un ou l’autre selon le type de données.

III.2.2.4 Autres architecture OLAP

Bien que les architectures évoquées ci-dessus soient les plus répandues et les plus adoptées par les fournisseurs de solutions OLAP, d’autres systèmes se basent sur des architectures différentes telles que l’architecture OOLAP « Object On-line Analytical Processing », ou alors DOLAP « Desktop On-line Analytical Processing » qui décrit une catégorie de produits qui ne sont pas nécessairement connectés à un serveur et qui s’appuient sur une source de données (un cube) construites, stockées et exploitées en local sur la machine de l’utilisateur.

III.4

La navigation dans les données

Une fois que le serveur OLAP a construit le cube multidimensionnel « ou simulé ce cube selon l’architecture du serveur », plusieurs opérations sont possibles sur ce dernier offrant ainsi la possibilité de naviguer dans les données qui le constituent. Ces opérations de navigation « Data Surfing » doivent être, d’une part, assez complexes pour adresser l’ensemble des données et, d’autre part, assez simples afin de permettre à l’utilisateur de circuler de manière libre et intuitive dans le modèle dimensionnel.

Afin de répondre à ces attentes, un ensemble de mécanismes est exploité, permettant une navigation par rapport à la dimension et par rapport à la granularité d’une dimension.

III.4.1 Slice & Dice

Le « Slicing » et le « Dicing » sont des techniques qui offrent la possibilité de faire des tranches « trancher » dans les données par rapport à des filtres de dimension bien précis, se classant de fait comme des opérations liées à la structure « se font sur les dimensions ». La différence entre eux se manifestent dans le fait que :

Le Slicing consiste à faire une sélection de tranches du cube selon des prédicats et selon une dimension « filtrer une dimension selon une valeur » [Chouder, 2008].

Figur e I.12 : Exemple de Slicing. Le Dicing, quant à lui, peut être v

Figur e I.12 :

Exemple de Slicing.

Le Dicing, quant à lui, peut être v u comme étant une extraction d’un sous cube.

peut être v u comme étant une extraction d’un sous cube. Fig ure I.13 : III.4.2

Fig ure I.13 :

III.4.2 Drill-down & Roll-up

Exemple de Dicing.

Ces méthodes, appelées auss i « forage vers le bas/vers le haut », sont les

méthodes les

plus répandues pour une navig ation dans un entrepôt de données. Elles

consistent à

représenter les données du cube à

down », ou un niveau supérieu r, c’est le « Roll-up ». En somme, ces de ux opérations

permettent de contrôler le niveau de détail des données du cube.

un niveau de granularité inférieur, dans le c as du « Drill -

Ces opérations ne sont pas aussi faciles à implémenter car basées sur la notion d’une bonne hiérarchisation des attributs d’une dimension et la différenciation entre tous les niveaux de hiérarchie disponibles dans les différentes dimensions.

de hiérarchie disponibles dans les différentes dimensions. Figure I.14 : Exemple de Roll up « moins

Figure I.14 :

Exemple de Roll up « moins de détails sur les années».

: Exemple de Roll up « moins de détails sur les années». Figure I.15 : Exemple

Figure I.15 :

Exemple de Drill-Down « plus de détails sur les régions ».

IV.

Démarche de Construction d’un Data Warehouse

Plusieurs chercheurs ou équipes de recherche ont essayé de proposer des démarches pour la réalisation d’un projet Data Warehouse, ces démarches se croisent essentiellement dans les étapes suivantes :

Modélisation et conception du Data Warehouse,

Alimentation du Data Warehouse,

Mise en œuvre du Data Warehouse,

Administration et maintenance du Data Warehouse,

IV.1

Modélisation et conception du Data Warehouse

Les deux approches les plus connues dans la conception des Data Warehouse sont :

L’approche basée sur les besoins d’analyse,

L’approche basée sur les sources de données,

Aucune des deux approches citées n’est ni parfaite, ni applicable à tous les cas. Toutes deux doivent être étudiées pour choisir celle qui s’adapte le mieux à notre cas.

Quelque soit l’approche adoptée pour la conception d’un Data Warehouse, la définition de celui-là reste la même. En étant un support d’aide à la décision, le Data Warehouse se base sur une architecture dimensionnelle.

IV.1.1 Approche « Besoins d’analyse »

Le contenu du Data Warehouse sera déterminé selon les besoins de l’utilisateur final. Cette approche est aussi appelée « approche descendante » (Top-Down Approach) et est illustrée par R. Kimball grâce à son cycle de vie dimensionnel comme suit :

Kimball grâce à son cycle de vie dimensionnel comme suit : Figure I.16 : illustration de

Figure I.16 : illustration de l’approche « Besoins d’analyse » grâce au cycle de vie dimensionnel de Kimball [Kimball, 2004].

Avantages

 

Inconvénients

 

Aucun risque de concevoir une solution obsolète avant d’être opérationnelle

Pas de prise en compte de l’évolution des besoins de l’utilisateur. Nécessite une modification de la structure du Data Warehouse en cas de nouveau besoin

Négligence du système opérationnel

 

Difficulté

de

déterminer

les

besoins

des

utilisateurs

Tableau I.3 : Avantages et inconvénients de l’approche « Besoins d’analyse ».

IV.1.2 Approche « Source de données »

Le contenu du Data Warehouse est déterminé selon les sources de données. Cette approche est appelée : Approche ascendante (Bottom-up Approach).

est appelée : Approche ascendante (Bottom-up Approach). Figure I.17 : Illustration de l’approche « Source de

Figure I.17 : Illustration de l’approche « Source de données » grâce au cycle de développement du DW de Inmon [Inmon, 2002].

Inmon considère que l’utilisateur ne peut jamais déterminer ses besoins dès le départ, « Donnez moi ce que je vous demande, et je vous direz ce dont j’ai vraiment besoin » 7 , il considère que les besoins sont en constante évolution.

Avantages

Inconvénients

Meilleure prise en charge de l’évolution des besoins

Risque de concevoir une solution obsolète avant qu’elle soit opérationnelle

Evolution du schéma des données source

Complexité de source de données

Tableau I.4 :

Avantages et inconvénients de l’approche « Sources de données».

IV.1.3 Approche mixte

Une combinaison des deux approches appelée hybride ou mixte peut s’avérer efficace. Elle prend en considération les sources de données et les besoins des utilisateurs.

Cette approche consiste à construire des schémas dimensionnels à partir des structures des données du système opérationnel, et les valider par rapport aux besoins analytiques. Cette approche cumule les avantages et quelques inconvénients des deux approches déjà citées, telles que la complexité des sources de données et la difficulté quant à la détermination des besoins analytiques.

quant à la détermination des besoins analytiques. Figure I.18 : Illustration de l’approche mixte. 7 “

Figure I.18 :

Illustration de l’approche mixte.

7 Give me what I tell you I want, then I can tell you what I really want.”[Inmon, 2002]

Cette étape aboutit à l’établissement du modèle dimensionnel validé du Data Warehouse. Ce modèle dimensionnel sera transformé en modèle physique, qui différera du modèle dimensionnel.

IV.2

Alimentation du Data Warehouse

Une fois le Data Warehouse conçu, il faut l’alimenter et le charger en données. Cette alimentation (le plus souvent appelée processus ETL « Extract-Transform-Load ») se déroule en 3 phases qui sont :

Extraction des données primaires (issues par exemple des systèmes de production),

Transformation des données,

 

Le chargement des données traitées dans l’entrepôt de données,

 

Ces

trois

étapes

décrivent

une

mécanique

cyclique

qui

a

pour

but

de

garantir

l’alimentation du Data Warehouse en données homogènes, propres et fiables.

IV.2.1 Les phases de l’alimentation « E.T.L. »

Les phases du processus E.T.L. représentent la mécanique d’alimentation du Data Warehouse. Ainsi elles se déroulent comme suit :

a) L’extraction des données

« L’extraction est la première étape du processus d’apport de données à l’entrepôt de données. Extraire, cela veut dire lire et interpréter les données sources et les copier dans la zone de préparation en vue de manipulations ultérieures. » [Kimball, 2005]. Elle consiste en :

Cibler les données,

Appliquer les filtres nécessaires,

Définir la fréquence de chargement,

Lors du chargement des données, il faut extraire les nouvelles données ainsi que les

Pour cela, il existe trois stratégies de capture de

changements intervenus sur ces données. changement :

Colonnes d’audit : la colonne d’audit, est une colonne qui enregistre la date d’insertion ou du dernier changement d’un enregistrement. Cette colonne est mise à jour soit par des triggers ou par les applications opérationnelles, d’où la nécessité de vérifier leur fiabilité.

Capture des logs : certains outils ETL utilisent les fichiers logs des systèmes sources

afin de détecter les changements (généralement logs du SGBD). En plus de l’absence de cette fonctionnalité sur certains outils ETL du marché, l’effacement des fichiers logs engendre la perte de toute information relative aux transactions.

Comparaison avec le dernier chargement : le processus d’extraction sauvegarde des

copies des chargements antérieurs, de manière à procéder à une comparaison lors de chaque nouvelle extraction. Il est impossible de rater un nouvel enregistrement avec cette méthode.

b) La transformation des données

La transformation est la seconde phase du processus. Cette étape, qui du reste est très importante, assure en réalité plusieurs tâches qui garantissent la fiabilité des données et leurs qualités. Ces tâches sont :

Consolidation des données.

Correction des données et élimination de toute ambiguïté.

Elimination des données redondantes.

Compléter et renseigner les valeurs manquantes.

Cette opération se solde par la production d’informations dignes d’intérêt pour l’entreprise et de et sont donc prêtes à être entreposées.

c) Le chargement des données

C’est la dernière phase de l’alimentation d’un entrepôt de données, le chargement est une étape indispensable. Elle reste toute fois très délicate et exige une certaine connaissance des structures du système de gestion de la base de données (tables et index) afin d’optimiser au mieux le processus.

IV.2.2 Politiques de l’alimentation

Le processus de l’alimentation peut se faire de différentes manières. Le choix de la politique de chargement dépend des sources : disponibilité et accessibilité. Ces politiques sont 8 :

Push : dans cette méthode, la logique de chargement est dans le système de production. Il " pousse " les données vers la zone de préparation quand il en a l'occasion. L'inconvénient est que si le système est occupé, il ne poussera jamais les données.

Pull : contrairement de la méthode précédente, le Pull " tire " les données de la source vers la zone de préparation. L'inconvénient de cette méthode est qu'elle peut surcharger le système s'il est en cours d'utilisation.

Push-pull : c'est la combinaison des deux méthodes. La source prépare les données à envoyer et indique à la zone de préparation qu'elle est prête. La zone de préparation va alors récupérer les données.

8 http://grim.developpez.com/articles/concepts/etl/

Aussi, le processus d’alimentation doit répondre à certaines exigences illustrées par la figure suivante :

Être rapide
Être rapide
Être correctif
Être correctif
Processus ETL
Processus
ETL
Être transparent
Être transparent
Être sûr
Être sûr

Figure I.19 :

Objectif de qualité de données dans un processus ETL [Kimball, 2004].

Sûr : assure l’acheminement des données et leur livraison.

Rapide : la quantité de données manipulées peut causer des lenteurs. Le processus

d’alimentation doit palier à ce problème et assurer le chargement du Data Warehouse dans des

délais acceptables.

Correctif : le processus d’alimentation doit apporter les correctifs nécessaires pour améliorer la qualité des données.

Transparent : le processus de l’ETL doit être transparent afin d’améliorer la qualité des données.

IV.2.3 Les outils E.T.L.

Les outils E.T.L, en français E.T.C « Extraction-Transformation-Chargement » [Kimball, 2005], sont des outils qui garantissent la faisabilité et facilitent le déroulement des trois phases citées précédemment. D’où leur importance dans un projet Data Warehouse.

IV.3

Mise en œuvre du Data Warehouse

C’est la dernière étape d’un projet Data Warehouse, soit son exploitation. L’exploitation du Data Warehouse se fait par le biais d’un ensemble d’outils analytiques développés autour du Data Warehouse. Donc cette étape nécessite l’achèvement du développement, ou de la mise en place, de ces outils qui peuvent accomplir les fonctions suivantes:

a. Requêtage ad-hoc :

Le requêtage ad-hoc reste très fréquent dans ce type de projet. En effet, les utilisateurs de l’entrepôt de données, et spécialement les analystes, seront amenés à interagir avec le DW via des requêtes ad-hoc dans le but de faire les analyses requises par leurs métiers et, d’élaborer aussi, des rapports et des tableaux de bords spécifiques.

L’accès à ce genre de service peut se faire via différentes méthodes et outils. Cependant, les spécialistes en la matière préconisent de laisser la possibilité à l’utilisateur de choisir les outils qui lui paraissent les plus adéquats.

b. Reporting :

Destiné essentiellement à la production de rapports et de tableaux de bord, « il est la présentation périodique de rapports sur les activités et résultats d'une organisation, d'une unité de travail ou du responsable d'une fonction, destinée à en informer ceux chargés de les superviser en interne ou en externe, ou tout simplement concernés par ces activités ou résultants » 9 .

Ces outils de Reporting ne sont pas, à proprement parler, des instruments d'aide à la décision, mais, lorsqu’ils sont utilisés de manière appropriée, ils peuvent fournir une précieuse vue d’ensemble.

Les rapports sont alors crées par le biais d’outils de Reporting qui permettent de leur donner un format prédéterminé. Les requêtes sont constituées lors de l’élaboration des rapports qui seront ensuite diffusés périodiquement en automatique ou ponctuellement à la demande.

9 http://fr.wikipedia.org/wiki/Reporting

c.

Analyse dimensionnelle des données:

L’analyse dimensionnelle est sans doute celle qui exploite et fait ressortir au mieux les capacités de l’entrepôt de données. Le but par l’analyse dimensionnelle est d’offrir aux utilisateurs la possibilité d’analyser les données selon différents critères afin de confirmer une tendance ou suivre les performances de l’entreprise. Cette analyse se fait selon le principe OLAP, offrant de ce fait aux utilisateurs les possibilités de recourir à différentes opérations facilitant la navigation dans les données. La mise en place de ces outils est une option très intéressante dans la mesure où les données seront accessibles en analyses instantanées. Plusieurs fournisseurs de solution OLAP existent sur le marché et offrent des solutions construites sur des méthodes et technologies différentes. C’est d’ailleurs pour cela que le choix de la solution doit se faire au préalable, selon les besoins en utilisation, la taille de l’entrepôt et les moyens techniques disponibles.

d. Tableaux de bord :

Les tableaux de bord sont un outil de pilotage qui donne une vision sur

l’évolution

d’un processus, afin de permettre aux responsables de mettre en place des actions correctives.

« Le tableau de bord est un ensemble d’indicateurs peu nombreux conçus pour permettre aux gestionnaires de prendre connaissance de l’état et de l’évolution des systèmes qu’ils pilotent et d’identifier les tendances qui les influenceront sur un horizon cohérent avec la nature de leurs fonctions » [Bouquin, 2003].

Cette forme de restitution a la particularité de se limiter à l’essentiel, c'est-à-dire la mise en évidence de l’état d’un indicateur par rapport à un objectif, tout en adoptant une représentation graphique de l’information.

e. Data Mining :

Au sens littéral du terme, le Data Mining signifie le forage de données. Le but de ce forage est d’extraire de la matière brute qui, dans notre cas, représente de nouvelles connaissances. L’idée de départ veut qu’il existe dans toute entreprise des connaissances utiles, cachées sous des gisements de données. Le Data Mining permet donc, grâce à un certain nombre de techniques, de découvrir ces connaissances en faisant apparaître des corrélations entre ces données.

Le Data Warehouse constituera alors la première source de données sur laquelle s’exécutera le processus de découverte de connaissances. Dans la majeure partie du temps, l’entrepôt de données représente un pré requis indispensable à toute fouille de données.

Le recours à ce genre de méthode est de plus en plus utilisé dans les entreprises modernes. Les applications et outils implémentant ces solutions sont rarement développés en interne. En effet, les entreprises préfèrent se reposer sur des valeurs sûres du marché afin d’exploiter au plus vite les données en leur possession.

IV.4

Maintenance et expansion

La mise en service du Data Warehouse ne signifie pas la fin du projet, car un projet Data Warehouse nécessite un suivi constant compte tenu des besoins d’optimisation de performance et ou d’expansion. Il est donc nécessaire d’investir dans les domaines suivants

[Kimball, 2002] :

Support : assurer un support aux utilisateurs pour leur faire apprécier l’utilisation de l’entrepôt de données. En outre, la relation directe avec les utilisateurs permet de détecter les correctifs nécessaires à apporter.

Formation :

il est indispensable d’offrir un programme de formation permanant aux

utilisateurs de l’entrepôt de données.

Support technique : un entrepôt de données est considéré comme un environnement de production. Naturellement le support technique doit surveiller avec la plus grande vigilance les performances et les tendances en ce qui concerne la charge du système.

Management de l’évolution : il faut toujours s’assurer que l’implémentation répond aux besoins de l’entreprise. Les revues systématiques à certain point de contrôle sont un outil clé pour détecter et définir les possibilités d’amélioration. En plus du suivi et de la maintenance du Data Warehouse, des demandes d’expansion sont envisageables pour de nouveaux besoins, de nouvelles données ou pour des améliorations.

Ces travaux d’expansion sont à prévoir de façon à faciliter l’évolution du schéma du Data Warehouse.

V.

Conclusion

Le concept « Data Warehouse » est apparu comme une réponse à des besoins grandissants dans le domaine décisionnel. Son adaptabilité et sa capacité de fournir les données nécessaires à une bonne analyse, ont fait de lui un atout majeur et incontournable pour toute entreprise soucieuse du suivi de ces performances.

Afin de mettre en place ce genre de système, il est nécessaire de choisir et d’adopter une démarche précise qui doit tenir compte des réalités de l’entreprise et des contraintes du projet. La modélisation de l’entrepôt se fait dans tous les cas grâce à la modélisation dimensionnelle. L’alimentation en données constitue l’étape à laquelle il faut accorder le plus d’attention et de temps. En effet, elle est le garant de contenance de l’entrepôt en données fiables et correctes. Une fois l’alimentation terminée, l’exploitation des données peut alors se faire par différentes méthodes. L’utilisation d’outil OLAP reste, cependant, l’aspect le plus intéressant dans cette exploitation permettant la navigation dans les données de l’entrepôt à la demande.

Au cours de la seconde partie de cette étude, nous allons essayer d’utiliser les concepts présentés dans la synthèse bibliographique, et cela afin de mettre en œuvre notre système.

Partie II :

Cas pratique « filiales de

distribution SONELGAZ »

Chapitre I :

Présentation

d’accueil.

de

l’organisme

I.

Présentation de SONELGAZ I.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ée l’Etablissement 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 massive des étrangers qui représentaient plus de 87% de la clientèle. Par ailleurs, les tâches les plus urgentes ont été de reprendre le fichier des abonnés, reconstituer les plans des ouvrages et des réseaux, procéder au recrutement et à la formation dans tous les domaines et de ramener le niveau de consommation de l’énergie à celui de 1961.

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-. Ce texte s’inscrit dans le cadre des mesures de nationalisation des secteurs clés de l’économie nationale. L’ordonnance précitée a attribué à l’entreprise le monopole de la production, du transport, de la distribution, de l’importation et de l’exportation de l’électricité et du gaz manufacturé (art. 4 et 7). L’ensemble des biens de l’ex-EGA lui a été légué.

1977, le plan national d’électrification : Dès le milieu des années 70, l’Algérie s’est engagée dans un ambitieux plan national d’électrification qui avait objectif l’amélioration des conditions de vie des populations des campagnes tout en assurant un développement harmonieux de l’espace rural.

1983, naissance des entreprises travaux : six entreprises autonomes voient le jour :

KAHRIF pour l’électrification; KAHRAKIB - Infrastructures et installations électriques; KANAGAZ - Réalisation des réseaux gaz; INERGA - Génie civil; 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 Etablissement 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. Le décret exécutif n° 95-280 du 17 septembre 1995 confirme la nature de SONELGAZ en tant qu’Etablissement Public à caractère Industriel et Commercial.

1998, création de filiales périphériques : Le 1er janvier 1998, neuf filiales périphériques ont vu le jour.

2002, promulgation de la loi 02 / 01 du 5 février 2002 : Promulguée en février 2002, la nouvelle loi relative à l’électricité et à la distribution du gaz par canalisations est venue supprimer le monopole exercé jusque là par SONELGAZ, en ouvrant le secteur de l’électricité et du gaz à la concurrence, sauf pour les activités de Transport qui ont un caractère de monopole naturel.

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’Etablissement Public à caractère Industriel et Commercial à une Société Par Actions dont le capital est détenu par l’Etat. Sur le plan de son fonctionnement, SONELGAZ Spa est dotée d’une Assemblée Générale et d’un Conseil d’Administration. Elle est dirigée par un Président directeur général.

I.1.1

Organisation du groupe

SONELGAZ, et afin de se mettre en conformité avec les dispositions de la loi de février 2002, qui lui confère le statut de Société Par Actions, s’est érigée en un Groupe Industriel constitué de sociétés opérationnelles et d’une Société Mère. Chacune des sociétés ayant des missions et objectifs différents, il en ressort les principes d’organisation suivants :

Maison Mère : elle est chargée essentiellement de l’élaboration de la stratégie et de 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.

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.

L’organigramme suivant donne une vision claire et précise de la l’entreprise et de son administration :

structure de

de la l’entreprise et de son administration : structure de Figure II.1 : Organigramme représentant l’organisation

Figure II.1 :

Organigramme représentant l’organisation du Groupe SONELGAZ.

I.1.2

Le groupe en chiffres

Le tableau suivant donne les chiffres relatifs à l’activité du groupe pour l’année 2008:

Critères

Chiffres

Chiffre d’affaire groupe

137 529 millions de DA

Investissements groupe

190 828 millions de DA

Ventes

Electricité

32 584 millions de kWh

Gaz

7.44 Milliards de m3

Nombre de clients

Electricité

6 298 682

Gaz

2 638 963

Production d’électricité groupe

Production SPE

28 970 millions de kWh

Production IPP

11 017 millions de kWh

Personnel en activité du groupe

Permanents

35 633 agents

Temporaires

24 761 agents

Tableau II.1 :

Le groupe SONELGAZ en chiffres « année 2008 ».

La figure suivante illustre l’évolution du chiffre d’affaire du groupe depuis l’année 2001 :

du chiffre d’affaire du groupe depuis l’année 2001 : Figure II.2 : Evolution du chiffre d’affaire

Figure II.2 :

Evolution du chiffre d’affaire du groupe « rapport d’activité de l’année 2008 ».

La répartition du chiffre d’affaire du groupe pour l’année 2008 est de la manière suivante :

du groupe pour l’année 2008 est de la manière suivante : Figure II.3 : Répartition du

Figure II.3 :

Répartition du chiffre d’affaire publiée dans le rapport d’activité de l’année

2008.

I.2 Le métier de la distribution

L’un des métiers les plus importants du groupe, et dans lequel s’inscrit notre projet, est la fourniture et la distribution de l’énergie électrique et gazière. Ce métier, vu l’organisation du groupe, est assuré par quatre filiales qui sont les « Sociétés de Distribution ». Les sociétés sont :

Sociétés de Distribution d’Electricité et du Gaz de l’Ouest (SDO).

Sociétés de Distribution d’Electricité et du Gaz du Centre (SDC).

Sociétés de Distribution d’Electricité et du Gaz d’Alger (SDA).

Sociétés de Distribution d’Electricité et du Gaz de l’Est (SDE).

Les Sociétés de Distribution d’Ele ctricité et du Gaz ont pour principales mission s d’assurer :

L’exploitation et la mainte nance du réseau de distribution de l’électricité et du gaz.

Le développement des r éseaux électricité et gaz permettant le racc ordement des nouveaux clients.

La commercialisation de l’ électricité et du gaz.

Le tableau suivant donne une distribution :

vue d’ensemble des chiffres d’affaires de s sociétés de

 

SDO

SDC

SDA

SDE

Création

Jan. 2006

Jan. 2006

Jan. 2006

Jan. 20 06

Chiffre d’affaire (MDA)

26.366,14

16.242

17.713

39,752

 

ELEC

1.668.668

1.290.058

810.636

2.069. 266

Nombre de clients

GAZ

549.904

389.410

383.583

893.75 0

Nombre d’employés

4406

3211

2412

4887

Tableau II.2 :

Présentati on des sociétés de distribution en chiffres « an née 2008 ».

I.2.1

Organisation des soci étés de distribution

niveau de son

siège, et gère un certain nombre d e « Directions de distribution ». Chacune de ces Directions de Distributions gère des « Servic es Commerciaux ». L’organigramme suivant i llustre :

Chaque société de distribution

compte cinq directions centrales, situées au

distribution compte cinq directions centrales, situées au Figure II.4 : Organisation des sociétés de distribution. 51

Figure II.4 :

Organisation des sociétés de distribution.

L’organisation des directions de d istribution se présente comme suit :

des directions de d istribution se présente comme suit : I.2.2 Figure II.5 : O rganisation

I.2.2

Figure II.5 :

O rganisation des Directions de Distribution.

La clientèle de la dist ribution

La segmentation des clients se client. Ainsi, on distingue :

fait selon la puissance de l’énergie à laquelle

est abonné le

a.

en électricité :

Client « Basse Tension- BT » : jusqu’à une puissance de 40 KVA, considéré comme un clien t BT. La tension délivrée est 220 V ou 380 V.

l’abonné est

Client « Moyenne Tensi on-MT » : d’une puissance de 50 KVA jusqu ’à 630 KVA, l’abonné est considéré co mme un client MT La tension d’alimentation est de 10 KV ou 30 KV.

Client « Haute Tension- HT » : est considéré comme client « Haute

Tension-HT »

tout client dont la tension

d’alimentation est supérieure à 60 KV.

b.

En gaz :

Client « Basse Pression-B P » : tout client alimenté sous une pression d e 21 bars à travers un détendeur.

Client « Moyenne Pressi on-MP » : tout client alimenté sous une pressi on de

4 bars

avec un poste de détente g az.

Client « Haute Pression- HP » : tout client alimenté sous une pression supérieure à 4 bars avec un poste de déte nte gaz.

En BT/BP, on distingue plusieurs types de clients :

Clients ménages : il s’agit des clients domestiques.

Clients non ménages : il s’agit des clients non domestiques (Activités commerciales).

Clients FSM (Facturation sur mémoire).

I.3 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 Electricité 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 ».

I.3.1

Présentation de « ELIT »

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.

L’organigramme suivant illustre la manière dont est organisée la filiale « ELIT » et la distribution de son effectif:

la filiale « ELIT » et la distribution de son effectif: F i g u r

Figure II.6 :

La direction études et développement

Organisation de la filiale ELIT.

Notre stage se déroule au sein de la direction d’étude et de développement. Ce département a pour mission de faire : l’étude, la conception, le développement et le déploiement de solutions nouvelles et la mise en place des systèmes d’information du groupe. Aussi, il offre l’assistance nécessaire et le suivi des solutions déployées.

L’organigramme et l’effectif de la direction « études et développement » se présente comme suit :

« études et développement » se présente comme suit : Figure II.7 : Organisation de la

Figure II.7 :

Organisation de la direction d’étude et de développement.

Remarque : au niveau de chaque « DD » il existe une « Division Gestion des Systèmes Informatique ». Cette dernière s’occupe essentiellement du suivie et de la maintenance des systèmes déjà déployés, ainsi que de la gestion du matériel informatique au niveau de la DD et des agences affiliées.

II.

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 du métier de la distribution, qui est le premier visé par ce projet, et 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 distribution, sera présentée.

Chapitre II : étude de l’existant

I.

Introduction

Le groupe SONELGAZ veut, par le biais de ce projet, palier à un manque important en matière de décisionnel. Ce manque se caractérise par la quasi inexistence de support d’aide à la décision, et l’indisponibilité de moyens de Reporting efficaces, en mesure de fournir des informations adéquates en temps voulu.

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 de distribution. 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.

II. Etat du décisionnel au sein du groupe

Il est intéressant de signaler que le groupe, dans sa fonction de distribution, ne dispose

d’aucun système d’aide à la décision automatique ou semi-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 consolidées à partir des systèmes transactionnels d’une

manière manuelle.

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, la structure chargée de leur élaboration et le niveau de consolidation.

II.1

Niveau Groupe

A ce niveau de hiérarchie, les utilisateurs ont besoin de chiffres qui concernent l’ensemble

du groupe, dans sa fonction de distribution. Ces rapports sont essentiellement livrés par la filiale « ELIT ». Les données étant consolidées à partir des bases de production des « DD » des quatre filiales de distribution. Cela suppose donc, la participation de différents acteurs dispersés sur l’ensemble du territoire national ainsi que sur l’ensemble des filiales distributions.

Dans le meilleur des cas, le rapport demandé concerne des données déjà consolidées et prêtes à l’utilisation. L’élaboration du rapport se fait donc sans grandes difficultés. Sinon, le procédé d’extraction et de consolidation est relancé. Le diagramme suivant donne une vision claire de la manière dont sont consolidées les données et les rapports élaborés en partant de la demande d’un état donné jusqu'à sa production :

Figure II.8 : Diagramme d’activité modélisant l’édition de rapport pour le niveau groupe. À partir

Figure II.8 :

Diagramme d’activité modélisant l’édition de rapport pour le niveau groupe.

À partir de ce diagramme on peut d’ores et déjà avoir une idée sur le nombre d’intervenants dans cette procédure qui reste une tâche très fastidieuse, surtout dans sa partie consolidation des données. Cette procédure se déroule comme suit:

Phase 1 : les utilisateurs de niveau groupe, principalement des analystes et des décideurs de la DGDS et de la maison mère, formulent leurs requêtes qui sont transmises au département « Systèmes d’information de la distribution » (SID) de la filiale « ELIT ».

Phase 2 : le département SID, en recevant une demande de la part des utilisateurs de niveau groupe, lance la procédure de consolidation des données à partir des différentes DD du groupe. Cette procédure doit faire l’objet d’une validation de la part du directeur études et développement. La demande est ensuite transmise au chef de CTI de chaque DD.

Phase 3 : Les chefs de CTI, en recevant la demande d’extraction, programment une tranche horaire et préparent les scripts d’extraction. L’étape d’extraction aboutit à la transmission de fichier texte vers le département SID.

Remarque : les fichiers, étant d’une taille assez volumineuse, peuvent atteindre une centaine de mégas voire plus. Ces dits fichiers subissent parfois des altérations durant le transfert ou deviennent carrément inutilisables. Dans ce cas les « D.D. » concernées sont recontactées pour une nouvelle extraction ou un nouvel envoi selon la nature du problème. Il arrive parfois, suite à des problèmes réseaux, de recourir au transfert des données sur support physique transportable (CD, clé USB).

Phase 4 : Une fois les données reçues en totalité, la consolidation se fait au niveau du département « SID » manuellement. Cette consolidation permet d’élaborer les rapports voulus.

Phase 5 :

utilisateurs finaux.

Le rapport est validé par le chef de département est et envoyé aux

Remarque : la procédure se répète généralement quatre fois par an, la consolidation des chiffres se faisant chaque trimestre. Mais cela n’empêche pas le lancement de cette procédure en cas de nécessité. Sauf en cas de problèmes, toute échange d’information « demandes et fichiers joints » se fait par le biais de la messagerie interne du groupe.

II.2

Niveau Sociétés de Distribution

Pour le niveau « SD », la procédure se déroule exactement comme pour le niveau groupe. A cela près que « ELIT » n’intervient pas à ce niveau là. C’est alors aux ingénieurs de la structure concernée de prendre en charge la consolidation et l’élaboration des rapports. Les différences notées sont :

Emission de la demande : La demande est formulée par les analystes et décideurs des deux directions Commerciale Marketing « DCM » et Comptabilité et Finance « DCF ».

Extraction des données: l’extraction se fait toujours aux niveaux des DD affiliées à la SD. Dans la plupart du temps les données sont transférées directement sous forme de rapports 10 .

Consolidation des données : la consolidation se fait soit à partir des fichiers de données, soit en se basant sur les rapports transmis par les DD. Cette consolidation se fait toujours de façon manuelle et monopolise les ingénieurs et techniciens de SD.

Remarque :

la

procédure

d’élaboration

de

rapports

au

niveau

SD

se

fait

généralement chaque fin de mois. Elle peut aussi être lancée en cas de nécessité.

10 Ces rapports obéissent à des canevas prédéfinis.

II.3

Niveau Directions de Distribution

Les consommateurs de rapports au niveau des DD utilisent des rapports livrés directement par leurs CTI. Ces rapports, basés exclusivement sur les données des systèmes transactionnels, sont élaborés et transmis à la demande des managers. Le schéma suivant montre la manière dont sont traitées les demandes de rapport au niveau DD.

La demande est transmise directement du manager vers le chef de CTI via la messagerie interne «lotus de l’entreprise ». Le chef de CTI charge son équipe technique de l’élaboration du rapport demandé qu’il contrôle avant sa transmission à qui de droit.

L’élaboration des rapports se fait à ce niveau soit par le bais du module « Statistique 11 » du SGC, Soit par des requêtes SQL. La présentation du rapport se fait alors selon le canevas demandé.

Remarque : Vu le nombre important de demandes et de sollicitations, certaines DD ont mis à la disposition des managers et des décideurs des systèmes qui fournissent des états statistiques à la demande. Cependant, ces systèmes, en interrogeant directement la base de données transactionnelle en production, offrent des services limités avec des temps de réponse non satisfaisants. Cette mise en place de systèmes, ne fait qu’encourager le groupe à uniformiser les procédures et méthodes de prise de décision.

11 Ce module a été développé pour fournir un certain nombre de rapports statistiques au niveau DD. Il interagit directement avec la base de données en production et pénalise souvent le système transactionnel.

III.

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.

Le chapitre suivant consacré à l’étude des besoins, aidera à détecter ceux des utilisateurs de manière à pouvoir y répondre.

Chapitre III : Définition des besoins.

I.

Introduction

Tout Data Warehouse doi t être en mesure de répondre aux attentes d es utilisateurs. Cela ne peut, évidemment, se fair e sans une étude approfondie de leurs besoins.

Ainsi,

il

existe

deux

d émarches

qui

ont

été

décrites

lors

de

n otre

synthèse

bibliographique, et qui sont: l'appr oche « Buttom Up » et l'approche « Top Dow n ».

nullement des

résultats satisfaisants. La démarc he généralement adoptée est une démarche m ixte, qui allie entre les deux précédentes dans u n souci de prise en considération des besoins des décideurs

sources. Cette

sans perdre de vue toute possib ilité et opportunité offerte par les données

approche permet donc de recueill ir, corriger et de modérer les attentes des util isateurs dès le

départ, tout en détectant d'éventue ls besoins non exprimés.

L'application exclusive d e l'une de ces deux approches ne produit

Durant l’étude des besoin s on ne peut se limiter aux interviews avec l es utilisateurs, néanmoins, il faudrait absolumen t prendre en compte l’avis des Administrateur s des bases de

données des systèmes sources«

Les DBA sont les principaux experts sur le s applications

existantes susceptibles d'alimen ter l'entrepôt de données. Leurs intervie ws servent à

confronter aux réalités certains utilisateurs finaux. » [Kimball, 96 ]

des thèmes qui surgissent lors des rencon tres avec les

] des thèmes qui surgissent lors des rencon tres avec les Figure II.9 : La place

Figure II.9 :

La place de l’ét ape d’étude des besoins dans un projet Data W arehouse.

Ce chapitre a pour principale vocation d’exposer et de décrire la démarche adoptée pour la détection des besoins ainsi que la présentation de la synthèse qui en sera faite.

I.1 Description de la démarche d'étude des besoins

Afin de faire une étude aussi complète que possible, nous avons choisi d'adopter une démarche qui nous a permis de combiner, d’une manière assez satisfaisante, entre l'approche « Buttom Up » et l'approche « Top Down ».

Ainsi, notre démarche peut se résumer au travers des étapes suivantes:

Étude préliminaire des systèmes sources et interviews sommaires avec les DBA,

Détection des postes susceptibles d'être porteurs d'informations utiles,

Planification, préparation et conduite des interviews:

Utilisation d’autres moyens pour la détection des besoins,

Rédaction et validation du recueil récapitulatif des besoins,

a. Étude préliminaire des systèmes sources et interviews sommaires avec les DBA

Cette étude représente une étape de compréhension des systèmes opérationnels et de leur environnement. Elle a pour mérite de consolider les connaissances acquises durant l’étude de l’existant, ainsi que le jargon et le fonctionnement de l’entreprise. En outre, cette étape permet de détecter, de manière succincte, les postes susceptibles d’interagir avec le Data Warehouse. Elle est de ce fait indispensable pour un bon recensement des besoins.

Outre les DBA, qui sont pour la plupart des chefs de CTI, les gestionnaires qui se trouvent au sein de l’Elit, et dont la fonction principale est de définir les règles de gestion des applications et de s’assurer du respect des procédures propres à la distribution, ont été une source d’information assez bénéfique, eu égard à leur connaissance des applications du SGC et de leur maîtrise du métier du groupe.

b. Détection des postes susceptibles d'être porteurs d'informations utiles

Vu le grand nombre d’employés activant au sein du groupe SONELGAZ, notamment dans la fonction de distribution, ainsi que la dispersion géographique des filiales, il nous a été, bien sûr, impossible de voir et d’interviewer toute cette population. Ainsi, notre étude s’est axée sur les utilisateurs SDA, SDC.

Cette étape nous a permis, donc, d’identifier, en premier lieu, les services qui peuvent être porteurs d’informations tangibles et qui représentent la population potentiellement utilisatrice du projet. Ces dits services sont classés selon leur appartenance aux différentes structures, indiqué dans le tableau suivant:

Structure

Intitulé du poste

Nombre total de postes

Direction de distribution

Directeur régional de distribution

58 (1 chef par DD)

Commercial

58 (1 chef par DD)

Division finance et comptabilité

58 (1 comptable par DD)

Administrateur

58 (1 administrateur par DD)

Société de distribution

P.D.G de la SD

4

D.C.M

4

Directeur finance et comptabilité

4

Groupe

P.D.G

1

DGDS

3

 

- DAP

- DAR

- ED

 

Total

248

Tableau II.3 :

Tableau présentant la population à interviewer.

c. Planification, préparation et conduite des interviews

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 pour la plus part des décideurs et des analystes.

Dans le souci de conduire à bien cette étape, qui du reste est très critique et délicate, il est nécessaire de passer par différentes phases, à savoir :

1 La phase de planification

La planification se fait généralement plusieurs jours à l’avance. Elle nous permet de prendre les rendez-vous nécessaires et de prévenir les futurs interviewés de notre arrivée et du motif de cet entretien.

Cette phase, qui est un préalable indispensable, s’est avérée être une tâche très ardue. En effet, la nature organisationnelle et la dispersion des structures liées à la distribution ont posé des problèmes que nous évoquerons plus loin. Cependant ces mêmes facteurs nous ont

poussés à entreprendre ce genre de démarches dans un souci de bonne conduite du projet et afin de ne pas perdre de temps dans des allers et retours improductifs.

Aussi, nous avons essayé de planifier nos entretiens de manière à avoir une certaine alternance entre les interviews des potentiels utilisateurs et les entretiens avec les DBA et les gestionnaires de manière à combiner entre les besoins d’analyse et les potentialités des systèmes sources et de leurs données.

2 La phase de préparation

Une fois la planification de l’entretien terminée, sa préparation doit se faire de telle sorte à ce qu’il se déroule dans les meilleures conditions possibles.

La préparation se résume essentiellement en l’identification des questions à poser, des points à soulever et des thèmes à éviter afin de ne pas trop s’éparpiller.

Les questions à poser sont classées en deux catégories, selon le poste de la personne interviewée. Ainsi certaines questions sont destinées aux décideurs alors que d’autres sont destinées aux analystes.

3 La conduite des entretiens

Dernière phase de l’étape, la conduite des interviews représente la réalisation sur le terrain des phases précédentes. Le but escompté étant d’amener les interviewés, au travers de leurs réponse à nos questions, de présenter leur travail et la manière dont ils procèdent pour le faire. L’identification des besoins se fera alors en détectant les métriques qu’ils utilisent et les informations sur lesquelles ils s’appuient pour la prise de décision.

d. Autres moyens utilisés pour la détection des besoins

Bien que les entretiens représentent une source importante d’informations et aident grandement à l’identification des besoins des utilisateurs, leur utilisation exclusive n’est pas conseillée dans la construction d’un entrepôt de données. Cela tient principalement au fait que les utilisateurs ne peuvent, même avec la meilleure volonté du monde, exprimer tous leurs besoins.

De ce fait, il est fait appel à l’étude des rapports déjà demandés et des données disponibles a même de fournir des informations exploitables. L’étude des rapports offre un certain apport à notre démarche d’études des besoins, dans la mesure où les utilisateurs peuvent ne pas mentionner des besoins qui leur paraissent évidents ou qui ne leur viennent pas à l’esprit durant nos interviews, ces derniers peuvent être, en effet, influencés par nos questions.

L’étude des données, quant à elle, sert à détecter des besoins non déclarés et qui peuvent se faire sentir ultérieurement, le but de cette démarche étant de construire un entrepôt de données capable de répondre à ces éventuels nouveaux besoins.

e. Rédaction et validation du recueil récapitulatif des besoins

L’étude des besoins nous a permis de recenser les besoins que nous avons classés par volets spécifiques. Ils peuvent être présentés de la manière suivante :

Volet Détecté

Besoins enregistrés (Les critères d’analyse)

Suivi des

Utilisateurs : Ce volet a été évoqué et solliciter à tous les niveaux et par différents postes. Cependant les utilisateurs des services Commerciaux et marketing, de la DCM et de la DFC ont exprimé un vif intérêt pour ce volet. Besoins : Les utilisateurs ont besoin de connaître l’évolution des ventes et des consommations dans le temps et selon différents critères à savoir :

(Zone géographique, type d’abonnement, secteur d’activité)