Rapport DESS Pousga Martin KIENDREBEOGO

Page 1

Présenté par :

KIENDREBEOGO Pousga Martin

Etudiant en DESS/2ITIC

Tel : (00226) 70 72 87 34

Mail : [email protected]

Stage effectué à la Direction Générale des Services Informatiques du

Ministère de l’Economie et des Finances du 05/03/2014 au 21/07/2014

Maitre de stage : Directeur de mémoire :

M. Alain OUATTARA M. Yaya TRAORE

Directeur des Etudes et Applications

Enseignant Chercheur à l’IBAM

THÈME : « Mise en Place d’un entrepôt de données sur les financements extérieurs au

Burkina Faso »

Page 2

Table des matières

DEDICACES .............................................................................................................................. 5

REMERCIEMENTS ................................................................................................................... 6

SIGLES, ABREVIATIONS ET ACRONYMES ....................................................................... 7

LISTE DES FIGURES ............................................................................................................... 8

LISTE DES TABLEAUX .......................................................................................................... 9

PREAMBULE .......................................................................................................................... 10

RESUME .................................................................................................................................. 11

INTRODUCTION GENERALE .............................................................................................. 12

Contexte général ....................................................................................................................... 13

Problématique ........................................................................................................................... 14

Planification .............................................................................................................................. 15

PRESENTATION DE LA STRUCTURE D’ACCUEIL ......................................................... 17

PARTIE I: GENERALITES ..................................................................................................... 21

I Introduction ............................................................................................................................ 22

I. 1 Les systèmes décisionnels ..................................................................................... 22

I.1.1 La place du décisionnel dans l’entreprise ......................................................... 23

I.1.2 Les différentes composantes du décisionnel ....................................................... 23

I.2 Le data warehouse ............................................................................................................... 24

I.3 Historique des Data Warehouse .......................................................................................... 25

I.4 Structure des données d’un Data Warehouse ...................................................................... 25

I.5 Les composantes d’un Data Warehouse .............................................................................. 26

I.6 L’architecture d’un Data Warehouse .................................................................................. 27

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

II.1 La modélisation dimensionnelle et ses concepts ................................................................ 27

II.2 Le concept modèle ............................................................................................................. 29

II.3 Le concept OLAP ............................................................................................................... 31

II.3.1 Généralités ................................................................................................................. 31

II.3.2 Les systèmes à architecture MOLAP ......................................................................... 31

II.3.3 Les systèmes à architecture ROLAP .......................................................................... 32

II.3.4 Les systèmes à architecture HOLAP .......................................................................... 32

II.4 La navigation dans les données .......................................................................................... 32

Page 3

II.4.1 Opérateurs de restriction (Slice et Dice) ................................................................... 33

III. Démarche de construction d’un entrepôt de données ......................................................... 35

III.1 Modélisation et conception du data warehouse ................................................................ 35

III.1.1 Approche « besoins d’analyse » ................................................................................. 35

III.1.2 Approche « Source de données » ............................................................................... 36

III.1.3 Approche mixte ......................................................................................................... 37

III.1.4 Choix de l’approche de mise en œuvre ...................................................................... 38

III.2 Alimentation du Data Warehouse ..................................................................................... 38

III.2.1 Les phases de l’alimentation (ETL) ........................................................................... 38

III.2.2 Politique de l’alimentation ......................................................................................... 39

III.2.3 Exploitation du data warehouse ................................................................................ 40

Conclusion ................................................................................................................................ 43

PARTIE II: MODELISATION ................................................................................................ 44

CHAPITRE I: ETUDE DE L’EXISTANT ............................................................................... 45

I Introduction ............................................................................................................................ 46

I.1 Etat de l’opérationnel .......................................................................................................... 46

I.2 Etat du décisionnel .............................................................................................................. 47

I.2.1 Niveau DGCOOP ................................................................................................. 47

I.2.2 Niveau DGB.......................................................................................................... 49

I.2.1 Niveau DGTCP ..................................................................................................... 49

I.3 Etude des besoins ................................................................................................................ 49

I.3.1 Description de la démarche d’étude des besoins ................................................. 50

Conclusion ................................................................................................................................ 52

CHAPITRE II: CONCEPTION DE LA SOLUTION .............................................................. 53

Introduction ............................................................................................................................... 54

I Processus de la modélisation dimensionnelle ........................................................................ 55

I.1 Inscription Projet ................................................................................................................. 55

I.1.1 Présentation du sujet ............................................................................................ 55

I.1.2 Grain du sujet ....................................................................................................... 55

I.1.3 Les dimensions participantes du modèle ............................................................. 56

I.1.4 Les mesurables ..................................................................................................... 58

I.1.5 Le modèle en étoile de l’activité «inscription projet» .......................................... 58

I.2 Elaboration .......................................................................................................................... 58

Page 4


I.2.2 Grain du sujet ....................................................................................................... 58


I.2.4 Le modèle en étoile de l’activité « élaboration » ................................................. 59

I.3 Mobilisation ......................................................................................................................... 59


I.3.2 Grain du sujet ....................................................................................................... 59


I.3.4 Le modèle en flocon de l’activité «mobilisation » ................................................ 60

I.4 Exécution ............................................................................................................................. 60


I.4.2 Grain du sujet ....................................................................................................... 61


Conclusion ................................................................................................................................ 62

PARTIE III: MISE EN OEUVRE DE LA SOLUTION ............................................................. 63

I Introduction ............................................................................................................................ 64

I.1 Etude et Planification .......................................................................................................... 65

I.2 Architecture de chargement ................................................................................................. 65

I.3 Processus général de chargement ........................................................................................ 66

I.4.1 Processus de chargement initial .......................................................................... 67

I.3 Architecture technique de la solution .................................................................................. 67

I.4 Choix de l’ETL .................................................................................................................... 68

I.4.1 Implémentation de l’extraction, de la transformation et du chargement .......... 68

a. Mise en œuvre de l’extraction, de la transformation et du chargement initial . 69

I.4.2 Conception des cubes ........................................................................................... 70

I.4.3 Architecture technique de déploiement ............................................................... 71

I.4.4 Coût de mise en œuvre ......................................................................................... 72

Conclusion ................................................................................................................................ 73

CONCLUSION GENERALE .................................................................................................. 74

Bibliographie ............................................................................................................................ 75

Webographie ............................................................................................................................. 75

Page 5

DEDICACES

A :

Mes feux parents, qui de leur vivant, n’avaient

jamais cessé de m’encourager et me soutenir,

Ma femme Sylvie et ma fille Tinb-Noma

Marthe Anonn,

Mon feu frère Philippe et ma feue sœur Martine :

puisse Dieu les accueillir dans son vaste paradis.

Page 6

REMERCIEMENTS

Au début de ce rapport, nous tenons à remercier, Madame la

Directrice de l’IBAM, toute l’équipe pédagogique et les

intervenants professionnels pour avoir assuré notre formation.

Nous remercions également le Directeur Général des Services

informatiques du Ministère de l’Economie et des Finances pour

nous avoir accepté au sein de son service pour le stage pratique.

Nos vifs remerciements vont particulièrement aux personnes

suivantes :

M. Yaya TRAORE, Enseignant chercheur à l’IBAM, notre

Directeur de mémoire ;

M. Alain OUATTARA, Directeur des Etudes et Applications à la

Direction générale des Services Informatiques, notre maître

de stage.

Enfin, dans le souci de n’oublier personne, nous témoignons de

notre gratitude à tous ceux qui, d’une manière ou d’une autre, ont

apporté leur brique à notre formation ou à la réussite de ce

travail.

Page 7

SIGLES, ABREVIATIONS ET ACRONYMES

BI Business Intelligence

2IOPSIE Ingénierie informatique et organisation et protection des systèmes d’information dans

l’entreprise

2ITIC Ingénierie Informatique et Technologie de l’Information et de la Communication

DBA Data Base Administrator

DDP Direction de la Dette Publique

DESS Diplôme d’Etude Spécialisé Supérieur

DGB Direction Générale du Budget

DGCOOP Direction Générale de Coopération

DGTCP Direction générale du Trésor et de la Comptabilité Publique

DGSI Direction Générale des Services Informatiques

DIM Dimension

DW Data warehouse

ETL Extract, Transform and Load

FK Foreign Key

FTP File Transfer protocol

IBAM Institut Burkinabè des Arts et Métiers

IHM Interface Homme-Machine

KLSL Kilo Ligne Source du Logiciel

MEF Ministère de l’économie et des finances

MOLAP Multidimensional On Line Analytical process

OLAP Hybrid On Line Analytical process

OLTP On Line Transactional process

PDF Portable Document Format

PK Primary key

PTF Partenaires Techniques et Financiers

ROLAP Relational On LIne

SGBD (R) Système de Gestion de Base de Données (Relationnelles)

SQL Structured Query Language

WWW World Wide Web

XP eXtreme Programming

Page 8

LISTE DES FIGURES

Figure 1 : Le diagramme de GRANT ........................................................................................ 15 Figure 2 : Le diagramme d’allocation de ressources ................................................................. 16 Figure 3 : Légende du diagramme d’allocation de ressources .................................................. 16 Figure 4 : Le décisionnel au sein du Système d’information [Goglin, 1998] ............................. 23 Figure 5 : Les différentes composantes du décisionnel [Goglin, 1998] ...................................... 23 Figure 7 : Structure des données d’un data warehouse ............................................................... 25 Figure 8 : Architecture global d’un data warehouse ................................................................... 27 Figure 9 : Cube à plusieurs dimensions ...................................................................................... 28 Figure 10 : Un modèle dimensionnel typique [Kimball, 1996] .................................................. 28 Figure 11 : Modèle en étoile ....................................................................................................... 30 Figure 12 : Modèle en flocon ...................................................................................................... 30 Figure 13 : Modèle en constellation ............................................................................................ 30 Figure 14 : Principe de l’architecture MOLAP [Nakache, 1998] ............................................... 31 Figure 15 : Principe de l’architecture ROLAP [Nakache, 1998] ................................................ 32 Figure 16 : Exemple de cube dimensionnel ................................................................................ 33 Figure 17 : Exemple de slicing .................................................................................................... 33 Figure 18 : Exemple de dicing .................................................................................................... 34 Figure 19 : Exemple de drill up & drill down ............................................................................. 34 Figure 20 : Exemple de rotate ..................................................................................................... 35 Figure 21 : Illustration de l’approche « besoins d’analyse » [Kimball, 2004] ............................ 36 Figure 22 : Illustration de l’approche « source de données » [Inmon, 2002] ............................. 36 Figure 23 : Illustration de l’approche « mixte » .......................................................................... 37 Figure 24 : Objectif de qualité de données dans un processus ETL [Kimball, 2004] ................. 40 Figure 25 : Diagramme d’activité modélisant l’édition d’un rapport sur les projets et convention ..................................................................................................................................................... 48 Figure 27 : Analyse des priorités ................................................................................................. 55 Figure 28 : La dimension Temps de l’activité « inscription projet» ........................................... 56 Figure 28 : La dimension BAILLEUR de l’activité « inscription projet» .................................. 56 Figure 30 : La dimension SECTEUR_ACTIVITE de l’activité « inscription projet» ................ 57 Figure 31 : La dimension ZONE_GEOGRAPHIQUE de l’activité « inscription projet» .......... 57 Figure 32 : Modèle en étoile de l’activité « inscription projet» ................................................. 58 Figure 33 : Modèle en étoile de l’activité « élaboration» .......................................................... 59 Figure 34 : Modèle en étoile de l’activité « mobilisation» ........................................................ 60 Figure 35 : Modèle en constellation de l’activité « exécution» ................................................. 61 Figure 36 : diagramme de l’activité du processus d’alimentation .............................................. 66 Figure 35 : Architecture technique de la solution ....................................................................... 67 Figure 36 : Gestionnaire de connexions à oracle depuis SQL Server ......................................... 68 Figure 37 : Enchainement des taches du chargement initial ....................................................... 69 Figure 38 : Exemple de conversion de type de données. ............................................................ 69 Figure 39 : Figure illustratif du chargement de la dimension convention. ................................. 70 Figure 40 : Cube du fait mobilisation. ......................................................................................... 70 Figure 41 : Exemple d’analyse du cube de fait mobilisation. ..................................................... 71 Figure 42 : Architecture de deploiement. .................................................................................... 71

Page 9

LISTE DES TABLEAUX

Tableau 1 : Tableau comparatif entre le transactionnel et le décisionnel ................................... 24 Tableau 2 : Tableau comparatif entre tables de faits et tables de dimensions ............................ 29 Tableau 3 : Avantages et inconvénients de l’approche « besoins d’analyse » ............................ 36 Tableau 4 : Avantages et inconvénients de l’approche « source de données » ........................... 37 Tableau 5 : Tableau représentant les différents postes de travail ................................................ 50 Tableau 6 : Synthétisation des besoins recensés. ........................................................................ 51 Tableau 7 : Tableau descriptif de la dimension TEMPS ............................................................. 56 Tableau 7 : Tableau descriptif de la dimension BAILLEUR ...................................................... 57 Tableau 9 : Tableau descriptif de la dimension Secteur_activité ................................................ 57 Tableau 10 : Tableau descriptif de la dimension zone géographique ......................................... 57

Page 10

PREAMBULE

L’institut burkinabé des arts et métiers (IBAM) est un établissement de l’Université de Ouagadougou

(UO). Il a été créé en 2000 suite à la refondation de l’université de Ouagadougou et a pour objectif la

formation professionnelle.

De 2006 à 2010, l’IBAM disposait des filières de formation suivantes :

- DUT option Secrétariat de Direction/ Secrétariat de Direction Bilingue ;

- DUT option Finance Comptabilité ;

- DUT option Gestion Commerciale ;

- DUT option Banque ;

- Licence Professionnelle Finances et Audits Comptable(LPFAC) ;

- Licence Professionnelle en Marketing et Gestion;

- Licence Professionnelle en Banque ;

- Licence Professionnelle Secrétariat ;

- Méthodes Informatiques Appliquées à la Gestion (MIAGE) ;

- DESS en Ingénierie Informatique et Technologies de l’Information et de la communication (2ITIC).

- DESS en Ingénierie Informatique et Organisation et Protection des Systèmes d’Information dans

l’Entreprise (2IOPSIE).

La filière MIAGE a pour objectifs de répondre aux besoins croissants des entreprises en cadres de bon

niveau dans le domaine de la technologie et des techniques informatiques. La formation en MIAGE était

ouverte aux titulaires d’un BTS/DUT en Informatique, d’un DEUG en Mathématique et Physique, en

Physique Chimie ou d’un diplôme reconnu équivalent. La durée de la formation est de deux ans. Aussi,

suite à des relations de partenariat existant entre l’IBAM, l’université de Bobo-Dioulasso et l’IAI Niger,

l’opportunité est offerte aux étudiants de ces universités ayant un diplôme d’ingénieur de travaux

informatiques d’intégrer la deuxième année MIAGE après examen de dossier.

A compter de l’année universitaire 2011-2012, la formation à l’IBAM intègre le système LMD

(Licence, Master, Doctorat) et les filières ont été réorganisées de la manière suivante :

- Marketing, Gestion;

- Comptabilité, Contrôle, Audit ;

- Assurance, Banque, Finance;

- Assistant de direction bilingue;

- Méthode Informatiques Appliquées à la Gestion ;

Il y a aussi la formation en DESS (2ITIC, 2IOPSIE) et en MIAGE 2 soir.

Pour l’obtention du DESS, un stage suivi de la rédaction d’un mémoire est obligatoire. C’est pour

répondre à cette obligation que nous avons fait un stage à la Direction Générale des Services

Informatiques qui nous a permis de nous pencher sur la mise en œuvre d’un entrepôt de données des

financements extérieurs au Burkina Faso.

Page 11

RESUME

Dans le but de disposer d’outils performants et fiables à même d’améliorer la gestion budgétaire, le

Burkina Faso s’est lancé dans un vaste chantier d’informatisation. Dans ce processus figure pour une

grande part, la gestion des financements extérieurs, préoccupation qui est traduite dans le Plan d’Action

pour le Renforcement de la Gestion Budgétaire (PRGB), adopté le 31 Juillet 2002.

Malgré l’exploitation du logiciel dédié à la gestion de la dette, les structures chargées de la gestion des

financements extérieurs éprouvent de réelles difficultés de mise en place d’une base de données

exhaustive des éléments de la dette. Ainsi pour plus d’efficacité dans la gestion des financements

extérieurs afin de rendre compte avec célérité de leur utilisation, il s’est avéré nécessaire de mettre en

place un dispositif prenant en compte des aspects organisationnel et informatique. Ainsi est né le Circuit

Intégré des Financement Extérieurs (CIFE) dont les objectifs sont entre autres :

- la prise en compte les besoins des différents départements ministériels en terme d’inscription

annuelle de projets de développement ;

- la saisie des conventions de financements entre le Burkina Faso et ses différents partenaires

techniques ;

- la budgétisation annuelle des prévisions de financements par bailleurs au titre des

investissements ainsi que la mobilisation des ressources budgétisées;

- l’exécution du titre 5 ainsi que la prise en compte dans la comptabilité de l’Etat;

Malgré la mise en œuvre de cet arsenal de mesures devant conduire à une meilleure gestion des finances

publiques, force est de constater la persistance de réelles difficultés dans des secteurs tels celui des

financements extérieurs quant à la maîtrise des données et de leur suivi pour une meilleur prise de

décisions par les autorités.

Ce travail fournit un effort d’analyse et de développement d’un entrepôt de données qui devra donc

résoudre la problématique posée qui est de mettre à disposition des décideurs un outil décisionnel

performent. Il a pour objectifs d’être un outil qui va:

offrir des informations agrégées et détaillées en matière de prévision budgétaire sur

financements ;

permettre d’analyser les flux de décaissements effectuées par les partenaires techniques et

financiers ;

permettre une bonne lecture de l’exécution et surtout fournir en temps réel l’utilisation faite

des financements extérieurs ;

offrir une large possibilité de génération d’un certains nombre d’états d’aide à la décision.

Page 12

INTRODUCTION GENERALE

Page 13

Contexte général

La prise en compte des systèmes informatisés dans la gestion des finances publiques au Burkina Faso

est un élément indispensable pour un meilleur suivi et une meilleure prise de décision en vue

d’améliorer la croissance économique nationale. Dans le souci de satisfaire ce besoin, le gouvernement

dans sa politique nationale en matière des TIC s’est doté des logiciels pour accroitre la disponibilité du

service publique en matière des finances publiques mais aussi réduire les délais de traitement des

dossiers. Ces solutions pour la plupart apportent satisfaction à nos décideurs en matière d’information

financières. En effet le climat sur fond de crise dans lequel évolue le monde aujourd’hui et

particulièrement les Etats en voie de développement, fortement dépendant de l’aide extérieur, exige de

ces derniers une surveillance très étroite de la mobilisation et de l’exécution des finances publiques afin

d’accroitre la croissance, de maintenir une confiance vis-à-vis des partenaires techniques financiers, et

aussi de garantir la stabilité gaze de développement. Pour ce faire, nos autorités, 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.

Cependant, ces logiciels existant s’ils permettent d’atteindre un niveau très acceptable en matière de

gestion des finances publiques, n’offrent pas à nos jours une possibilité de simulation et de prédiction à

nos décideurs sur une période définie.

Ces décisions, qui influeront grandement sur la stratégie nationale et donc sur le devenir de la nation, ne

doivent pas être prises ni à la légère, ni de manière trop hâtive, compte tenu de leurs conséquences sur le

développement et la stabilité nationale. Il s’agit de prendre des décisions fondées, basées sur des

informations claires, fiables et pertinentes.

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.

Dans le présent rapport qui s’articule autour de trois parties, il sera question dans un premier temps de

faire une synthèse bibliographique afin de définir les concepts d’entrepôt de données, ensuite, de

dépeindre succinctement la structure d’accueil et de la conception de la solution, enfin viendra

l’implémentation, la présentation pratique et le déploiement de la solution conçue.

Page 14

Problématique

Les financements extérieurs représentant en termes d’exécution, 76% du Programme d’investissement

Public contre 24 % pour les ressources internes au cours de l’année budgétaire 2002, il devient

indispensable d’améliorer leur suivi, en particulier celui des dépenses sur financements extérieurs, dans

le cadre de la transparence de la gestion et du suivi des dépenses dans la lutte contre la pauvreté. Dès

lors, il s’avère urgent de mettre en œuvre un dispositif (en termes d’organisation à mettre en place, de

renforcement des capacités et d’outil informatique à utiliser) fiable pour mieux gérer les financements

extérieurs.

Dans un pareil contexte, la plus simple des opérations d’analyse devient une tâche ardue. En effet, les

différentes directions en charge du CIFE se trouvent dans l’incapacité de faire des analyses fiables,

efficaces et à des moments opportuns dans des délais courts. Ainsi, les principales difficultés

rencontrées peuvent être résumées en :

Difficultés dans l’élaboration des rapports de suivi des financements extérieurs:

L’élaboration des rapports de suivi de la mobilisation et de l’exécution des financements extérieurs fait

intervenir, généralement, plusieurs acteurs en raison de la multiplicité des intervenants dans le circuit

(DGCOOP, DGTCP, DGB, DGEP…). En effet, à chaque fois qu’il est nécessaire d’élaborer un rapport,

il faudra procéder d’abord à l’extraction les données à partir de la base de productions à commencer par

la DGCOOP pour ce qui concerne les projets et les conventions, la DGB pour la mise à disposition du

budget et enfin la DGTCP pour les questions touchant les décaissements, l’exécution et la

comptabilisation du titre 5. 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 est élaboré sur la base d’une consolidation

antérieure, en sachant pertinemment que les données ne sont pas à jour.

L’inexistence d’une procédure de Reporting :

L’inexistence d’une politique de Reporting n’est pas pour arranger les décideurs. Ceux ci ont besoin

d’informations fiables et dans des délais raisonnables. À titre indicatif, l’édition d’un rapport national

qui devra être présenté devant l’assemblée nationale peut prendre, en moyenne, plus d’un mois ce qui

est plus que pénalisant pour une bonne prise de décision.

Insuffisance du module « suivi et évaluation » :

Afin de produire et offrir un moyen de suivi des activités sur la gestion faite des financements

extérieurs, un module « suivi et évaluation » a été développé et intégré dans le système Ce dernier

fournit des états statistiques permettant, aux décideurs au niveau des directions générales, l’analyse et la

prise de décision. Cependant, ce module connait quelques problèmes dû au fait qu’il interroge

directement la base de données en production.

Page 15

Objectifs

Afin de palier aux problèmes précédemment cités, la DGSI à travers la DEA, a initié le présent projet.

Ce projet a pour but d’introduire, en premier lieu, une informatique décisionnelle au sein du Ministère

de l’Economie et des Finances en général et en particulier sur les financements extérieurs, 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 ;

La mise en place d’une politique de Reporting ;

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 souhaitée.

Planification

« Planifier optimise ainsi les chances de réussite d’un projet en améliorant la productivité grâce à une

meilleur maitrise de la qualité » [Soler, 2001]

Pour garantir le bon déroulement du projet, tout en respectant les délais, nous avons élaboré une

planification globale de conduite du projet. Le Diagramme suivant décrit cette phase ainsi que leur

ordonnancement prévu.

Figure 1 : Le diagramme de GRANT

Page 16

Figure 2 : Le diagramme d’allocation de ressources

Figure 3 : Légende du diagramme d’allocation de ressources

Page 17

PRESENTATION DE LA

STRUCTURE D’ACCUEIL

Page 18

I. Attributions

Suivant les termes de l’article 69 du décret N°2012 -546 /PRES/PM/MEF du 2 juillet 2012 portant

organisation du MEF, la DGSI a pour mission d’assurer la coordination et la mise en œuvre de la

politique d’informatisation du MEF.

A ce titre, elle est chargée notamment :

- de réaliser, de déployer, d’administrer et de maintenir les applications informatiques ;

- d’élaborer, d’actualiser et de mettre en œuvre le schéma directeur informatique ;

- de coordonner le suivi de l’exportation et de la maintenance des applications informatiques au

sein du ministère ;

- de gérer le parc informatique et l’infrastructure de communication ;

- d’administrer les systèmes ;

- De former et d’assister les utilisateurs du système informatique ;

- d’assurer la cohérence, la sécurité et l’évolution du système informatique du ministère en

conformité avec le schéma national ;

- de promouvoir l’expertise du ministère en matière de technologies de l’information et de la

communication et de gestion informatisée des finances publiques ;

Pour mieux organiser les tâches qui lui sont confiées, la DGSI est organisée en structures de mission et

structures d’appui.

II. Organisation et fonctionnement de la DGSI

L’organisation et le fonctionnement de la DGSI est régie par l’arrêté N°2012 -473 /MEF/SG/DGSI du

31 décembre 2012 portant attribution, organisation et fonctionnement de Direction Générale des

Services Informatiques. Au terme de l’article 4 du dit arrêté, la DGSI est organisée comme suit :

- La Direction générale ;

- Les structures d’appui ;

- Les structures centrales.

1. La Direction générale

La Direction générale comprend le Directeur général, le secrétariat du Directeur général et la Cellule

d’appui technique.

2. Les structures d’appui

Il existe 5 structures d’appui au sein de la DGSI que :

- la Cellule du Contrôle Interne et de Suivi-évaluation (CCI-SE) ;

- le Service des Ressources Humaines(SRH) ;

- le Service Financier et Matériel (SFM) ;

- le Service de la Communication et Relation Publique (SCRP) ;

- le Service des Archives et de la Documentation (SAD).

3. Les directions de services

Il existe 4 directions de services à la DGSI.

Page 19

3.1. La Direction des études et des applications (DEA)

La direction des études et applications est chargée d’assurer la réalisation, le déploiement,

l’administration et la maintenance des applications informatiques ainsi que du suivi du Schéma

Directeur Informatique du MEF.

Elle comprend deux (02) services qui sont :

- Le Service Etudes et Développement (SED)

- Le Service Exploitation et Production (SEP)

3.2. La Direction de l’Equipement et du Support Technique (DEST)

La direction de l’équipement et du support technique est chargée d’assurer la gestion prévisionnelle et

opérationnelle du parc informatique, le support technique et la formation des utilisateurs.

Elle est composée de trois (03) services :

- Le Service Equipement Informatique (SEI) ;

- Le Service Support Technique (SST) ;

- Le Service Formation des Utilisateurs (SFU) ;

3.3. La Direction des Réseaux et Systèmes (DRS)

La direction des réseaux et systèmes s’occupe de la gestion prévisionnelle et opérationnelle de

l’infrastructure de communication, des systèmes et des outils de collaboration du MEF.

La DRS comprend trois (03) services qui sont :

- Le Service Infrastructures de communication (SIC) ;

- Le Service Gestion des Systèmes(SGS) ;

- Le Service Internet et Intranet (S2I).

3.4. La Direction des Prestations Externes (DPE)

La direction des prestations externes est chargée de la poursuite de l’exécution de certaines activités de

l’ex Centre National de Traitement de l’Information (CENATRIN). A ce titre, elle est chargée de

fournir des logiciels et des services internet et associés aux clients et de l’expertise du Ministère en

matière de technologie de l’information et de la communication et de gestion informatisée des finances

publiques.

La DPE comprend également deux (02) services notamment :

- Le Service Assistance et Traitement (SAT) ;

- Le Service Relation Clientèle (SRC).

Page 20

4. L’organigramme

DGSI

CCISE CAT

SFM SRH

SAD SCRP

Secrétariat

DEA DESTDRS DPE

Page 21

PARTIE I: GENERALITES

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

Page 22

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 oeuvre 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].

Page 23

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.

Parmi les différentes définitions du décisionnel « business intelligence B.I. » qui ont été données on

trouve : « Le Décisionnel est le processus visant à transformer les données en informations et, par

l'intermédiaire d'interrogations successives, transformer ces informations en connaissances. » [Dresner,

2001].

I.1.1 La place du décisionnel dans l’entreprise

Figure 4 : Le décisionnel au sein du Système d’information [Goglin, 1998]

La figure ci-dessus illustre parfaitement la place qui revient au décisionnel au sein d’une entreprise.

Cette place, comprend plusieurs fonctions clés de l’entreprise.

I.1.2 Les différentes composantes du décisionnel

Figure 5 : Les différentes composantes du décisionnel [Goglin, 1998]

Page 24

I.1.3 Comparaison entre le transactionnel et le décisionnel

Différences Systèmes transactionnels SID

Par les données

Orienté applications Orienté thèmes et sujets Situation instantanée Situation historique

Donnée détaillées et codées non redondantes Informations agrégées cohérentes 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

L’usage

Assure l’activité au quotidien Permet l’analyse et la prise de décision Pour les opérationnel Pour les décideurs Mises à jour et requêtes simples Lecture unique et requêtes complexes

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 1 : Tableau comparatif entre le transactionnel et le décisionnel

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 ».

I.2 Le data warehouse

Définition

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. »

Ces principales caracteristiques sont les usivantes :

- 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…

- 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

Page 25

valeurs dans le temps, alors que dans un système opérationnel la valeur d’une donnée est

simplement mise à jour.

- 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…).

I.3 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.

I.4 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 :

Figure 6 : Structure des données d’un data warehouse

Page 26

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é.

Données détaillées archivées : anciennes données rarement sollicitées, 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 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.

I.5 Les composantes 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].

Page 27

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.

Zone d’outils d’accès (olap et data mining) : c’est l’ensemble des moyens fournis aux utilisateurs du

data warehouse pour exploiter la zone de présentation des données en vue de la prise de décision. Ces

outils varient des simples requêtes ad hoc aux outils permettant l’application de forage de données plus

complexes.

I.6 L’architecture d’un Data Warehouse

ETL

ExtractTransform

Load

Data Warehouse

Systèmes Opérationnels

ERP

CRM

Resource_5

Agrégats

fichier plat

Données

metadata

Analyse OLAP

Reporting

Data mining

Data Mart

Data Mart .

Data Mart.

Figure 7 : Architecture global d’un data warehouse

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

La modélisation multidimensionnelle a été introduite par Ralph Kimball. C’est une technique de

conception logique permettant de structurer les données de manière à les rendre intuitives aux

utilisateurs d'affaires et offrir une bonne performance aux requêtes.

II.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

Page 28

consiste à considérer un sujet d’analyse comme un cube à plusieurs dimensions, offrant des vues en

tranches ou des analyses selon différents axes.

Figure 8 : Cube à plusieurs dimensions

Chaque point du cube contient les mesures relatives à une combinaison particulière de produit, de

magasin et de temps.

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 :

Dimension temps

Clé_tempsjour_desemaineMoistrimestreannee

Dimension produit

Clé_produitDescription_produitCategorie_produit

Fait de venteClé_tempsClé_produitClé_magasinQte_vendueSomme_vendue

Dimension magasin

Clé_magasinnom_magasinadresse_magasintype_magasin

<<<<

Figure 9 : Un modèle dimensionnel typique [Kimball, 1996]

Page 29

II.1.1 Concept de faits 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

II.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].

II.1.3 Comparaison entre table de faits et table de dimensions

Caractéristiques 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

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

Tableau 2 : Tableau comparatif entre tables de faits et tables de dimensions

II.2 Le concept modèle

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.

Page 30

Figure 10 : Modèle en étoile

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.

Figure 11 : Modèle en flocon

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

par des dimensions communes.

Figure 12 : Modèle en constellation

Page 31

II.3 Le concept OLAP

II.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 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].

II.3.2 Les systèmes à architecture MOLAP

Ces systèmes 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.

Figure 13 : Principe de l’architecture MOLAP [Nakache, 1998]

Page 32

II.3.3 Les systèmes à architecture ROLAP

« Ensemble d’interfaces utilisateurs et d’applications qui donnent une 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’un 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.

Figure 14 : Principe de l’architecture ROLAP [Nakache, 1998]

II.3.4 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.

II.4 La navigation dans les données

Les données dimensionnelles sont représentées au travers d’un cube regroupant à la fois la structure et

les valeurs des données (voir Figure 13). Chaque case dans le cube présente les valeurs des mesures

d’un fait (par exemple les montants des locations sont représentées à l’intersection des dimensions

Agence, Véhicule et Temps). Chaque arête du cube, représentant une dimension, est composée des

valeurs d’un paramètre de la dimension considérée.

Page 33

La Figure 16 présente le cube analysant les mesures du fait Location en fonction des paramètres Année

de la dimension Temps, Marque de la dimension Véhicule et Ville de la dimension Agence.

Figure 15 : Exemple de cube dimensionnel

Une nouvelle génération d’opérateurs algébriques basés sur le concept de cube a vu le jour (Codd et al,

1993). La représentation dimensionnelle fait appel à des opérateurs spécifiques qui faciliteront l’analyse

et la visualisation des cubes dimensionnels.

II.4.1 Opérateurs de restriction (Slice et 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].

Figure 16 : Exemple de slicing

Page 34

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

Figure 17 : Exemple de dicing

II.4.2 Opérateurs de forage («Roll_Up» et «Drill_Down»)

Ils permettent soit de généraliser l’analyse, soit de l’affiner en modifiant le paramètre utilisé pour définir

les valeurs d’une arête du cube. En effet, les dimensions sont associées à des hiérarchies; ces deux

opérateurs permettent, respectivement, de « monter » ou de « descendre » dans une hiérarchie.

Figure 18 : Exemple de drill up & drill down

II.4.3 Opérateurs de rotation («rotate»)

L’opérateur de rotation («Rotate») permet d’avoir accès aux différentes vues de données : c’est

le fait d’inverser les axes visualisés du cube. Un cube de n dimensions possède n * (n – 1) vues

possibles.

Page 35

Figure 19 : Exemple de rotate

III. Démarche de construction d’un entrepôt de données

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.

III.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.

III.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 :

Page 36

Figure 20 : Illustration de l’approche « besoins d’analyse » [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 3 : Avantages et inconvénients de l’approche « besoins d’analyse »

III.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).

Figure 21 : Illustration de l’approche « source de données » [Inmon, 2002]

Page 37

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 dirai ce dont j’ai vraiment besoin»1, il considère que les besoins sont

en constante évolution.

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

Avantages inconvénientsMeilleure 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 4 : Avantages et inconvénients de l’approche « source de données »

III.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.

Figure 22 : Illustration de l’approche « mixte »

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.

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

Page 38

III.1.4 Choix de l’approche de mise en œuvre

Après l’étude comparative des approches, l’approche mixte a été retenue par le groupe de projet et

validée par le comité de pilotage, comme le choix le plus judicieux pour la mise en œuvre de la solution

finale. En effet, au vue de l’importance d’avoir une situation exhaustive et transparente de la gestion des

financements extérieurs, la solution future devra être appropriée par tous les acteurs, d’où la nécessité

d’implication et de prise en compte des besoins des utilisateurs. En outre, les solutions opérationnelles

existantes apportent satisfaction en matière de la gestion des finances publiques. Il est donc

indispensable de tenir comptes de ces systèmes dans la mise en œuvre de l’entrepôt.

III.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.

III.2.1 Les phases de l’alimentation (ETL)

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 changements

intervenus sur ces données.

Page 39

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.

III.2.2 Politique 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 sont2 :

• 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 à 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.

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

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

Page 40

Figure 23 : 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.

III.2.3 Exploitation du data warehouse

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.

Page 41

b. Le reporting

Destiné essentiellement à la production de rapports et de tableaux de bord, c’est un procédé visant à

fournir au sein de l'Entreprise une information agrégée ou détaillée, simple ou complexe sous forme de

représentation lisible et interprétable (liste de données, tableau croisé ou graphique) nommée rapport, à

partir d'une source de données normalisée issue des différents systèmes amont, apportant une réponse

aux principales questions analytiques dans la société : Que s'est il passé ?

c. L’analyse dimensionnelle

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.

d. L’analyse dimensionnelle

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].

e. Le 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.

f. Maintenance et croissance

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]

Page 42

Support : assurer un support aux utilisateurs pour leur faire apprécier l’utilisation de l’entrepôt de

données. Cela permet en outre de détecter les correctifs nécessaires à apporter.

Formation : il est indispensable de prévoir un plan de formations continues 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. Il

devient alors nécessaire que le support technique doit surveille 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. 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.

Page 43

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 ses

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

Page 44

PARTIE II:

MODELISATION

Page 45

CHAPITRE I: ETUDE DE L’EXISTANT

Page 46

I Introduction

Le ministère de l’Economie et des Finances, à travers la Direction de la Dette Publique, qui est

le secrétariat technique du Circuit Intégré des Financements Extérieurs, veut par le canal de ce présent

projet palier le manque d’outil décisionnel en matière des financements extérieurs.

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, à travers ce chapitre, présenter une analyse de l’existant opérationnel

et décisionnel du ministère en matière de gestion des financements extérieurs. 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

forces et faiblesses qui peuvent exister.

I.1 Etat de l’opérationnel

Le ministère de l’Economie et des Finances dispose depuis avril 2011 d’un outil opérationnel de gestion

des financements extérieurs.

L’objectif global visé est le renforcement des capacités du Burkina Faso dans la gestion des

financements extérieurs à travers :

- la mise en place d’un nouveau schéma du circuit d’échange d’information dans le cadre du suivi de

la gestion des financements extérieurs par la mise en œuvre de nouvelles procédures de gestion et par

la redéfinition du rôle de chacun des intervenants dans le processus ;

- la mise au point d’un outil informatisé de la gestion des financements extérieurs qui prend en compte

toutes les phases de négociations, de mobilisation, d’exécution et de comptabilisation de l’ensemble

des financements extérieurs ;

- la mise en œuvre de l’intégration informatique des systèmes existants (SYGADE, CID, CIR, CIE,

SGDF, SIMP) à travers le développement d’interfaces permettant un échange aisé d’informations

entre les différentes applications actuellement en utilisation au sein du Ministère de l’Economie et

des Finances.

Ce nouveau système permet aux autorités de disposer d’un outil fiable de maîtrise et de suivi des

données pour la prise de décisions stratégiques et contribue à mesurer plus efficacement les efforts du

Burkina Faso dans la lutte pour le développement.

Conçu pour être utilisé par tous les départements ministériels et institutions au Burkina, et aussi par les

unités de coordinations des projets et programmes de développement sur le territoire national, le CIFE

Page 47

connait dans un premier temps une exploitation centralisée se résumant uniquement à l’utilisation de la

DGTCP, de la DGCOOP, de la DGB et de la DGEP.

En exploitation, depuis 2011, l’élaboration, l’exécution et la comptabilisation des financements

extérieurs se font dans le CIFE. Des difficultés sont certes rencontrées, mais une nette progression des

chiffres en termes de budgétisation et d’exécution est à mettre à l’actif de l’application.

I.2 Etat du décisionnel

Il est intéressant de signaler que le ministère des l’Economie et des Finances, dans sa fonction de

mobilisation et d’exécution des financements extérieurs, 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 trois types de rapport à produire par trois

structures différentes en fonction du champ’ d’intervention dans le CIFE. Les trois types de rapports se

distinguent par leurs utilisateurs finaux, la structure chargée de leur élaboration et le niveau de

consolidation. Ce sont les rapports sur les informations générales des projets et programmes et les

informations générales des conventions au niveau de la DGCOOP, le rapport d’élaboration du budget au

niveau de la DGB et enfin le rapport sur la mobilisation et l’exécution au niveau de la DGTCP.

I.2.1 Niveau DGCOOP

A ce niveau, les utilisateurs ont besoin juste des informations d’ordre général des projets et conventions.

Au titre de ces informations nous avons, les composantes, volets et activités des projets, les partenaires

techniques qui financent le projet, les zones d’interventions du projet, les secteurs d’activités….Pour ce

qui concerne les conventions, les besoins demandés sont essentiellement la liste des conventions par

étape, les prévisions de financement par projet et par convention. Cela suppose donc, la participation de

différents acteurs que sont les utilisateurs finaux et l’équipe technique du CIFE.

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 :

Page 48

'

Les données ne sont pas consolidées

Pas de problèmes

Autorité demadeur DGCOOP EQUIPE CIFE

DemandeInstruction de DG

alternative Contacter équipe CIFE

Extraction des données

Transmission des donnéesReception des données

Alternative

Consolider les données

Problèmes dans les données

Elaboration du Rapport

Les données sont déjà consolidées

Reception du rapport

Transmission rapport

Figure 24 : Diagramme d’activité modélisant l’édition d’un rapport sur les projets et convention

À partir de ce diagramme on peut avoir une idée sur le nombre d’intervenants dans cette procédure

d’élaboration d’un rapport sur les projets et programme et les conventions. Cette procédure se déroule

comme suit:

Phase 1 : l’autorité formule la requête sous forme de courrier administratif à la DGCOOP.

Phase 2 : la DGCOOP, en recevant une demande de la part de l’autorité, impute à un agent qui lance la procédure de consolidation si toute fois les données sont disponibles. Sinon l’équipe du projet CIFE sera saisie.

Phase 3 : L’équipe du projet CIFE, en recevant la demande d’extraction, construit une requête à base de

scripts d’extraction. L’étape d’extraction aboutit à la transmission de fichier texte ou Excel vers les

utilisateurs de la DGCOOP.

Phase 4 : Une fois les données reçues en totalité, la consolidation se fait au niveau de l’agent DGCOOP

manuellement. Cette consolidation permet d’élaborer les rapports voulus.

Phase 5 : Le rapport est validé par le chef de service, le Directeur, puis le Directeur Général avant d’être

envoyé à l’autorité demandeur.

Page 49

Remarque : la procédure se répète généralement quatre fois par an, la consolidation des données se

faisant chaque trimestre. Mais cela n’empêche pas le lancement de cette procédure en cas de nécessité.

I.2.2 Niveau DGB

A ce niveau, les utilisateurs ont besoin d’informations plus approfondies. Au titre de ces informations

nous avons, les dépenses prévues par projet ou programme, par bailleur, les imputations budgétaires

ainsi que le budget prévisionnel annuel par bailleur. Cela suppose toujours, la participation de différents

acteurs que sont les utilisateurs finaux et l’équipe technique du CIFE.

Remarque : la procédure se répète généralement une fois par an.

I.2.1 Niveau DGTCP

A ce niveau, les utilisateurs ont besoin en général, d’informations financières. Au titre de ces

informations nous avons, les décaissements hebdomadaires par bailleurs et par projet, les dépenses

effectives par projets, les paiements effectifs par bailleurs, projets et dépenses. Cela suppose toujours, la

participation de différents acteurs que sont les utilisateurs finaux et l’équipe technique du CIFE.

La procédure se répète généralement chaque semaine. 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.

I.3 Etude des besoins

L’objectif premier de tout entrepôt de données est d’être en mesure de répondre aux besoins des

utilisateurs. Une étude approfondie des besoins s’avère donc nécessaire. Cette étude se fait suivant les

deux démarches décrites lors de la synthèse bibliographique. Ce sont l’approche «Buttom-Up » et

l’approche « Top-Down ».

En règle générale, il est déconseillé l’application exclusive de l’une des démarches. Celle généralement

adoptée est la démarche mixte qui allie entre les deux précédentes dans un souci de prise en

considération des besoins des décideurs sans perdre de vue toute possibilité et opportunité offerte par les

données sources. Cette approche permet donc de recueillir, corriger et de modérer les attentes des

utilisateurs dès le départ, tout en détectant d'éventuels besoins non exprimés.

Durant l’étude des besoins on ne peut se limiter à ceux exprimés par les utilisateurs, il faudrait

absolument prendre en compte l’avis des administrateurs des bases de données des systèmes sources.

« Les DBA sont les principaux experts sur les applications existantes susceptibles d’alimenter l’entrepôt

de données. Leurs interviews servent à confronter aux réalités certains des thèmes qui surgissent lors

des rencontres avec les utilisateurs finaux. »[Kimball, 96]

Page 50

I.3.1 Description de la démarche d’étude des besoins

Dans le souci de réaliser une étude complète que possible, nous avons adopté la démarche mixte qui a

pour étapes :

- É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 ;

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

a. Etude préliminaire des systèmes sources et interviews des DBA

Cette phase représente une étape de compréhension des systèmes opérationnels et de leur interaction.

Elle a pour but de consolider les connaissances acquises durant l’étude de l’existant. En outre, elle

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, les expert métiers de CIFE et des différentes applications interdépendantes, ont été une

source d’information assez bénéfique, eu égard à leur connaissance des applications et de leur maîtrise

du métier.

b. Description des postes susceptible d’être porteur d’informations.

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ées dans le tableau

suivant:

Structure Intitulé du poste

DGCOOP Direction de la Coopération Bilatérale (DCB) Direction de la Coopération Multilatérale (DCM)

DGB Direction de la Programmation Budgétaire (DPB) Direction de l’Exécution Budgétaire (DEB)

DGTCP Direction de la Dette Publique (DDP) DGEP Direction de la Coordination et l'Evaluation des Investissements publics (DCEI)

Tableau 5 : Tableau représentant les différents postes de travail

Page 51

c. Rédaction et validation du recueil 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 :

volets Besoins enregistrés

Suivi des projets et programmes

utilisateurs Ce volet a été sollicité surtout au niveau de la DCB et de la DCM et la DGEP

besoins

Les utilisateurs du module 1 ont besoin surtout de connaitre la répartition des projets par zone géographique, par secteur d’activité et dans le temps, leur décomposition en composante/volet, l’apport des bailleurs par projet en terme de requête conclues.

Suivi de l’élaboration budgétaire

utilisateurs Ce volet a été sollicité surtout au niveau de la DGB et de la DGTCP

besoins Les utilisateurs du module 3 ont besoin surtout de connaitre les prévisions annuelles par bailleurs, par convention et par projet

Suivi de la mobilisation

utilisateurs Ce volet a été sollicité surtout au niveau de la DGTCP

besoins Les utilisateurs des modules 3 et 4 ont besoin surtout de connaitre les décaissements hebdomadaires initiés par type de demandes et par bailleur, ainsi que les décaissements effectifs

Suivi de l’exécution

utilisateurs Ce volet a été sollicité surtout au niveau de la DGTCP

besoins

Les utilisateurs du module 5 ont besoin surtout de connaitre les dépenses effectuées au sein des projets par natures, par projet, et dans le temps Aussi, les paiements effectifs par dépense, par projet et dans le temps

Tableau 6 : Synthétisation des besoins recensés.

Page 52

Conclusion

L’étude de l’existant nous permet d’une part, d’avoir une vision générale des procédures d’élaboration

de rapports et de consolidation des données d’autre part de décider de la manière de construction de

l’entrepôt de données et de son architecture.

Page 53

CHAPITRE II: CONCEPTION DE LA SOLUTION

Page 54

Introduction

La conception de la solution est réalisée à partir de l’étude des besoins fonctionnels. Elle a pour objectif

de fournir aux utilisateurs, une définition détaillée et complète des aspects externes et internes du

fonctionnement du système futur. Pour mieux atteindre notre objectif, nous procéderons à une

modélisation dimensionnelle qui est le plus souvent associée aux entrepôts de données compte tenu de

ses avantages.

Il est souvent nécessaire de classifier les sujets recensés selon l’intérêt qu’ils représentent pour les

décideurs et les facilités de réalisation. En effet cette classification devra permettre d’aider au choix de

l’activité à modéliser en premier de manière à garantir des résultats satisfaisants.

Page 55

I Processus de la modélisation dimensionnelle

La conception d’un modèle dimensionnel passe par cinq étapes essentielles qui sont :

- le choix de l’activité à modéliser ;

- la définition de l’activité ;

- la définition des dimensions qui décrivent une ligne de la table de fait ;

- la définition des mesurables du fait ;

- la définition des agrégats.

Le choix de l’activité à modéliser se fait après classement des activités dans une matrice dite d’analyse

des priorités [Kimball, 2004]. Cette matrice à pour objectif la détermination de la première activité. La

figure suivante donne une illustration du classement des sujets recensés fait en collaboration avec les

décideurs et les techniciens.

Exécution

Mobilisation

Inscription Projets

Elaboration

Figure 25 : Analyse des priorités

I.1 Inscription Projet

I.1.1 Présentation du sujet

Ce volet constitue le point de départ des financements extérieurs. Les coûts de projets, les montants des

requêtes de financement par bailleurs ainsi que la répartition géographique et par secteur d’activités

constituent des indicateurs indispensables de sorte que leur disponibilité s’avère nécessaire pour les

décideurs.

I.1.2 Grain du sujet

Le choix du grain le plus fin donne un maximum de flexibilité. Dans le cas des projets et programme le

grain le plus fin, ou le niveau de détail le plus bas, correspond à une inscription du projet ou programme

dans la liste des projets en exécution, d’où une ligne de table de fait correspondant à :

Suivi du volume de financement et de la quantité des projets par zone géographique, secteur d’activité,

par bailleur à une date donnée.

Page 56

I.1.3 Les dimensions participantes du modèle

Les dimensions ont pour objectif de décrire le fait.

a) Dimension « Temps »

La dimension temps est « la seule dimension qui figure systématiquement dans tout entrepôt de

données, car en pratique tout entrepôt de données est une série temporelle. Le temps est le plus souvent

la première dimension dans le classement sous jacent de la base de données » [Kimball, 2001].

Elle se présente comme suite :

Dimension _Temps----

PK_CODE_TEMPSDATESEMESTREANNEE

Figure 26 : La dimension Temps de l’activité « inscription projet»

Le niveau de détail le plus bas de cette dimension est le semestre en raison de la fréquence lente

d’inscription de projet et programme de développement sur le plan national. Il sera utilisé une clé

artificielle dans cette dimension comme clé primaire pour faciliter la manipulation.

Nom colonne description PK_CODE_TEMPS Clé artificielle de la dimension temps DATE La date au format complet SEMESTRE Semestre de la date ANNEE Année de la date

Tableau 7 : Tableau descriptif de la dimension TEMPS

b) Dimension « Bailleur »

Le bailleur s’impose comme un élément important dans l’analyse et intéresse les analystes et les

décideurs de tous les départements étant donné que les financements proviennent d’eux. Outre ce qu’il

représente dans une opération d’inscription d’un projet ou programme, l’analyse du comportement du

bailleur peut aider à mieux gérer la collaboration et les relations de partenariat.

DIM BAILLEUR-----

PK_CODE_BAILLEURNOM_BAILLEURSIGLE_BAILLEURCODE_TYPE_BAILLEURADRESSE_BAILLEUR

Figure 27 : La dimension BAILLEUR de l’activité « inscription projet»

Page 57

Nom colonne description PK_CODE_BAILLEUR Clé de la dimension bailleur NOM_BAILLEUR Le nom complet du bailleur SIGLE_BAILLEUR Le sigle ou le nom court du bailleur ADRESSE_BAILLEUR Adresse du bailleur (sa localité, son téléphone, son mail…) CODE_TYPE_BAILLEUR Le type du bailleur (bilatéral ou multilatéral)

Tableau 8 : Tableau descriptif de la dimension BAILLEUR

c) Dimension « secteur activité »

Un secteur d’activité est un domaine défini d’activités interdépendantes qui concourent au

développement du dit domaine.

DIM SECTEUR ACTIVITE

--

PK_CODE_SECTEURNOM_SECTEUR

: :

Figure 28 : La dimension SECTEUR_ACTIVITE de l’activité « inscription projet»

Nom colonne description PK_CODE_SECTEUR Clé de la dimension secteur d‘activité NOM_SECTEUR Le nom complet du secteur d’activité

Tableau 9 : Tableau descriptif de la dimension Secteur_activité

d) Dimension « Zone géographique »

Elle définit la zone où le fait a eu lieu. Le grain le plus ici correspond au département. Une clé

artificielle a été introduite du fait de l’évolution possible de cette dimension.

DIM

ZONE_GEOGRAPHIQUE-----

PK_CODE_ZONENOM_ZONECODE_REGIONCODE_PROVINCECODE_DEPARTEMENT

Figure 29 : La dimension ZONE_GEOGRAPHIQUE de l’activité « inscription projet»

Nom colonne description PK_CODE_ZONE Clé de la dimension Zone géographique NOM_ZONE Le nom complet de la zone CODE_REGION Code de la région CODE_PROVINCE Code de la province CODE_DEPARTEMENT Code du département

Tableau 10 : Tableau descriptif de la dimension zone géographique

Page 58

I.1.4 Les mesurables

Les mesurables qui correspondent à l’activité « inscription projet» et qui permettent de mesurer les

performances de cette activité, sont la « quantité des projets inscrits» et le « volume de financement »

I.1.5 Le modèle en étoile de l’activité «inscription projet»

Dimension _Temps----

PK_CODE_TEMPSDATESEMESTREANNEE

DIM BAILLEUR-----


DIM SECTEUR ACTIVITE

--

PK_CODE_SECTEURNOM_SECTEUR

: :

DIM ZONE_GEOGRAPHIQUE-----

PK_CODE_ZONENOM_ZONECODE_REGIONCODE_PROVINCECODE_DEPARTEMENT

Fait inscription projet----

PK_CODE_BAILLEURPK_CODE_SECTEURPK_CODE_TEMPSPK_CODE_ZONE

::::

++

Quantite ()Volume ()

: int: Number

Figure 30 : Modèle en étoile de l’activité « inscription projet»

I.2 Elaboration


L’élaboration du budget sur financements extérieurs est la phase de prévision pour chaque projet de

développement, les futurs possibles décaissements de l’année N+1. Les indicateurs les plus utilisés à ce

niveau sont le taux de l’apport extérieur dans le budget national, le taux de prévision par bailleur d’une

année N par rapport à une année N+1, le taux global des financements extérieurs d’une année N par

rapport à une année N+1.


Dans le cas de l’élaboration, le grain le plus fin, ou le niveau de détail le plus bas, correspond à une

prévision par bailleur et par projet à une date donnée, d’où une ligne de table de fait correspondant à :

Suivi des montants prévu par bailleur et par projet à une date donnée.


Les dimensions participantes à ce modèle sont essentiellement les dimensions « temps », la dimension

« projet », la dimension « convention » et la dimension « bailleur »

Page 59

I.2.4 Le modèle en étoile de l’activité « élaboration »

Dimension _Temps.,

-----

PK_CODE_TEMPSDATEMOISSEMESTREANNEE

DIM BAILLEUR..-----


DIM PROJET..---

PK_CODE_PROJETLIBELLE_PROJETMONTANT_PROJET

DIM CONVENTION..----

PK_CODE_CONVENTIONLIBELLE_CONVENTIONDATE_SIGNATUREMONTANT_CONVENTION

Fait prevision----

PK_CODE_BAILLEURPK_CODE_PROJETPK_CODE_TEMPSPK_CODE_CONVENTION

+ Montantprevu () : Number

Figure 31 : Modèle en étoile de l’activité « élaboration»

I.3 Mobilisation


Le volet mobilisation des financements extérieurs est d’autant plus complexe qu’il met en relation l’Etat

et ses différents bailleurs pour ce qui est du décaissement des prévisions annuelles mais aussi parce que

les procédures de décaissement varient selon les bailleurs. Les indicateurs à ce niveau sont

essentiellement le taux de décaissement par bailleur. Il est intéressant de suivre cet indicateur qui est

fortement dépendant du taux de l’exécution des dépenses que nous verrons dans le volet suivant.


Dans le cas de la mobilisation, le grain le plus fin, ou le niveau de détail le plus bas, correspond à un

décaissement par bailleur à une date donnée, d’où une ligne de table de fait correspondant à :

Suivi des montants décaissements demandés et le montant réellement décaissé par bailleur et par

demande de décaissement à une date donnée.


Les dimensions participant au modèle de l’activité mobilisation sont : la dimension « temps », la

dimension « convention », la dimension « projet », la dimension « bailleur », la dimension

« type_decaissement » et la dimension « type_bailleur ».

Page 60

I.3.4 Le modèle en flocon de l’activité «mobilisation »

Dimension _Temps.

-------

PK_CODE_TEMPSDATESEMAINEMOISSEMESTRETRIMESTREANNEE

DIM BAILLEUR.-----


DIM PROJET---


DIM CONVENTION-----

PK_CODE_CONVENTIONLIBELLE_CONVENTIONDATE_SIGNATUREMONTANT_CONVENTIONCODE_MODE_FIN

Fait mobilisation-----

PK_CODE_BAILLEURPK_CODE_PROJETPK_CODE_TEMPSPK_CODE_CONVENTIONPK_CCODE_TYPE_DEC

++

MontantInitial ()MontantFinal ()

: Number: Number

DIM TYPE_BAILLEUR--

PK_CODE_TYPE_BAILLEUNOM_TYPE_BAILLEUR

DIM TYPE DECAISSEMENT

--

PK_CODE_TYPE_DECLIB_TYPE_DEC

DIM MODE_FINANCEMENT

--

PK_CODE_MODE_FInLIB_MODE_FIN

: :

Figure 32 : Modèle en étoile de l’activité « mobilisation»

I.4 Exécution


Le volet exécution des financements extérieurs comprend deux (2) sous volet qui sont intrinsèquement

liés. Il s’agit du sous volet dépenses effectués et du sous volet paiement dépenses effectuées. En effet le

paiement d’une dépense effectué sur financement extérieur doit subir d’abord une validation a posteriori

par le bailleur afin qu’il puisse être comptabilisé parmi les dépenses effectives. Des cas de rejet peuvent

intervenir en cas d’inéligibilité d’une dépense. Les indicateurs à ce niveau sont essentiellement le taux

d’exécution des dépenses par projet, le taux de rejet des paiements par projet, le taux global d’exécution

des dépenses sur financements extérieurs et le taux de comptabilisation des financements extérieurs. Il

est indispensable de suivre ces indicateurs pour maintenir la confiance des partenaires techniques et

pour mieux cerner les investissements en termes de développement.

Page 61


Au titre de l’exécution, le grain le plus fin, ou le niveau de détail le plus bas, correspond à une dépenses

par bailleur à une date donnée ainsi qu’à un paiement d’une dépense effective par type de paiement et à

un moment donné, d’où une ligne de ces deux tables de fait correspondant à :

Suivi des dépenses effectives et des paiements y afférents par bailleur et par type de paiement à une date

donnée.


Les dimensions participantes à ce modèle sont : la dimension « temps », la dimension « projet », la

dimension « bailleur », la dimension « type_paiement »

Dimension _Temps..-------

PK_CODE_TEMPSDATESEMAINEMOISSEMESTRETRIMESTREANNEE

: : : : : : :

DIM BAILLEUR...-----


DIM PROJET.---


Fait depense--

PK_CODE_PROJETPK_CODE_TEMPS

+++

MontantPrevu ()MontantExecute ()TauxExecution ()

: Num: Num: Num

Fait paiement----

PK_CODE_PROJETPK_CODE_TEMPSPK_CODE_BAILLEURPK_CODE_TYPE_PMT

+++

Montantdepense ()Montantpaiement ()Tauxpaiement ()

: Num: Num: Num

DIM TYPE_PAIEMENT--

PK_CODE_TYPE_PMTLIB_TYPE_PMT

Figure 33 : Modèle en constellation de l’activité « exécution»

Page 62

Conclusion

La zone d’entreposage constitue la zone exploitable par les utilisateurs. La modélisation de cette zone se

fait grâce à la modélisation dimensionnelle. Cette manière de représenter les données offre aux

utilisateurs des modèles intuitifs et compréhensibles permettant de naviguer et de manipuler les

données, détaillées ou agrégées, sans difficulté afin de satisfaire leurs besoins en analyse.

La finalisation de la conception de l’entrepôt, nous permet de passer à la construction de la zone

d’alimentation qui constitue l’objet du prochain chapitre.

Page 63

PARTIE III: MISE EN

OEUVRE DE LA SOLUTION

Page 64

I Introduction

L’ETL, ou l’alimentation du Data Warehouse, est une étape des plus importantes dans un projet Data

Warehouse, elle représente 80% de la charge de travail. Cette étape a pour objectif d’assurer

l’acheminement des données des systèmes sources jusqu’à l’entrepôt de données, en passant par les différentes phases de nettoyage et de transformations nécessaires.

La conception du processus d’alimentation nécessite les étapes suivantes :

• Etude et planification ;

• Choix de l’architecture ;

• Conception des processus de chargement :

- Processus de chargement des tables de dimension ;

- Processus de chargement des tables de faits ;

- Processus de chargement de table temps.

Page 65

I.1 Etude et Planification

Cette phase représente une phase préliminaire à l’ensemble du processus. Elle consiste en :

• l’étude des sources de données :

- la source de données est constituée des six modules du CIFE

• la détection des emplacements des données source :

- cette tache est en partie réalisée par les DBA

• la définition de la périodicité du chargement.

- A ce niveau nous avons retenu la périodicité mensuelle pour ce qui concerne

l’inscription des projets et programmes et l’élaboration du budget compte tenu du fait

que ces deux activités ne sont pas fréquemment réalisées.

- Pour les autres activités la périodicité journalière a été retenue compte tenu de la

fréquence élevée de celle-ci.

I.2 Architecture de chargement

L’architecture globale de chargement du système futur se présente de la sorte :

BD Production

Collecte

Taging Area

Extraction.

DW

Collecte.

Extraction.

AlimentationSERVER ETL

La zone « Taging Area » permet de stocker les donner à transformer et collectées depuis les bases de

productions. Elle permet de résoudre les problèmes d’indisponibilité des systèmes opérationnels qui

sont permanemment en utilisation.

Page 66

I.3 Processus général de chargement

Le diagramme d’activités suivant décrit le processus général de l’alimentation de l’entrepôt de données

dés sa mise en service :

Figure 34 : diagramme de l’activité du processus d’alimentation

La stratégie d’extraction adoptée consiste à comparer des chargements successifs afin de détecter les

changements. Cette stratégie, étant la plus fiable, est incontournable pour la capture des changements

pour des raisons de non fiabilité des champs date, généralement non renseignés. Cette détection se fait

au niveau de la zone de préparation améliorant sensiblement les performances.

Page 67

I.4.1 Processus de chargement initial

Comme son nom l’indique, ce type de chargement permet de prendre en compte le premier chargement

de l’entrepôt. Toutes les dimensions sont préalablement vidées pour s’assurer qu’il n’y a pas des

données préexistantes. Excepté la dimension « temps », le chargement initial de tous les autres

dimensions est précédé d’une purge pour s’assuré qu’il n’y a pas de données en attente dans ces dits

dimensions.

Le chargement de la dimension temps (DIM_TEMPS) à l’aide du Data Flow Task consiste à

extraire la date de l’activité des travaux de la table par une requête SQL, ensuite des

transformations sont faites afin d’obtenir le jour, la semaine, le mois, le trimestre, l’année et la

date de l’activité, le code de la date du type de travail concerné. Ensuite les données sont

insérées dans la dimension DIM_TEMPS de l’entrepôt.

Le code de la dimension est obtenu par concaténation du jour, du mois et de l’année de la

l’activité.

I.3 Architecture technique de la solution

La figure suivante illustre la structure et l’architecture technique de la solution

Figure 35 : Architecture technique de la solution

Page 68

I.4 Choix de l’ETL

L’ETL est l’outil permettant l’extraction, la transformation et le chargement des données. Ils sont indépendants des systèmes de gestion de bases de données. Cependant certains systèmes de gestions de base de données intègrent déjà cet outil notamment OWB dans le cas d’oracle, SSIS dans le cas de SQL SERVER…

Pour la mise en œuvre de notre solution la solution ETL retenu est SSIS pour la simple raison que l’entrepôt sera construit à l’aide de SQL SERVER.

Les différents outils qui seront utilisés sont :

outil d’extraction : Integration Services 2008 de SQL Server Business Intelligence

Development Studio ;

outil d’analyse : Analysis Services 2008 de SQL Server Business Intelligence

Development Studio ;

outil de reporting : report Server 2008.

I.4.1 Implémentation de l’extraction, de la transformation et du chargement

L’extraction des données qui se fait depuis une base de données oracle 10g se fait à l’aide

d’une connexion SQL Server par le Gestionnaire de connexions et utilisant le fournisseur

« OracleClient Data Provider » comme l’indique la figure ci-dessous.

Figure 36 : Gestionnaire de connexions à oracle depuis SQL Server

Les deux types de chargement (initial et incrémentiel) se font de façon séparée à l’aide des

pacquages offerts par SQL Server

Page 69

a. Mise en œuvre de l’extraction, de la transformation et du chargement initial

Pour s’assurer de la cohérence des données chargées, le chargement initial est précédé d’une

purge des dimensions ainsi que des faits de l’entrepôt de données. Elle est effectuée à travers

les flux de données.

Figure 37 : Enchainement des taches du chargement initial

Il s’avère nécessaire d’effectuer les conversions convenables avant les éventuels chargements

étant données la différence technologique des deux systèmes de gestion de base de données

utilisé. Ainsi, pour le chargement de la dimension bailleur convention par exemple une

conversion de types suivants est effectuée :

CHAMPS TYPES DEPART TYPES D’ARRIVEES CODE_CONVENTION VARCHAR2 CHAINE [DT_SDR] LIBELLE_CONVENTION VARCHAR2 CHAINE [DT_SDR] MONTANT_CONVENTION NUMBER(18,0) NUMERIQUE [DT_NUMERIC] TYPE_FINANCEMENT NUMBER ENTIER_SIGNE (4 BITS)[DT_I4]

Figure 38 : Exemple de conversion de type de données.

Page 70

La figure ci-dessous illustre le lancement du chargement initial d’une convention.

Figure 39 : Figure illustratif du chargement de la dimension convention.

I.4.2 Conception des cubes

La conception des cubes se fait à l’aide de l’outil Analysis Services 2008 de SQL Server.

Après la création de sources de données liée à l’entrepôt de données, la génération du cube se

fait de façon automatique. Pour le fait « Mobilisation » , on obtient le cube suivant :

Figure 40 : Cube du fait mobilisation.

Connexion à la base oracle et extraction des conventions

Conversion des types d’oracle en type SQL Server

Connexion à la base SQL Server et Insertion

Page 71

Le cube « Fait_Mobilisation » peut être analysé dans l’outil Analysis Services 2008 de SQL

suivant des critères de choix. Le schéma ci-dessous montre une analyse des montants initiaux et

finaux des décaissements du fait « mobilisation » par projet et par bailleur.

Figure 41 : Exemple d’analyse du cube de fait mobilisation.

I.4.3 Architecture technique de déploiement

L’architecture de déploiement demeura la même que celle abritant les applications métiers des

finances publiques (Architecture Trois tier). Elle est constituée d’un serveur d’application sous

windows 2008 Server et un server de base de données oracle sous Linux Redhat et un server de

base de données SQL SERVER 2008.

Figure 42 : Architecture de deploiement.

Base Linux

Base Windows

Poste Client

Server d’application windows

Page 72

I.4.4 Coût de mise en œuvre

Le coût de mise en œuvre de la solution est fonction du scenario de réalisation. Pour une réalisation en

interne, ce sont les informaticiens de l’administration qui formeront le groupe de projet contrairement

à l’option « développement en externe » où le besoin de recruter des consultants se pose. Les tableaux

suivants présentent les différents coûts :

a) Développement en interne

Le développement en interne a un coût relativement nul car les informaticiens qui travailleront sur

l’application sont de l’administration.

Ressources Qté Coût unitaire Nbre Mois Coût total

Développeur 03 0 5 0

Total 0 Tableau 11 : Tableau récapitulatif du coût de mise en œuvre en interne

b) Développement en externe

Ressources Qté Coût unitaire Nbre Mois Coût total

Chef de projet 01 1 700 000 4 6 800 000

Développeur 03 650 000 4 2 600 000

Autres - 2 000 000 - 2 000 000

Total 11 400 000 Tableau 12 : Tableau récapitulatif du coût de mise en œuvre en externe

Page 73

Conclusion

Les cubes dimensionnels est une étape très importante dans tout projet Data Warehouse. C’est grâce à cette dernière que l’utilisateur pourra utiliser et exploiter au mieux les données contenues dans l’entrepôt de données de manière correcte et intuitive.

Dans ce chapitre nous avons essayé donc de définir les cubes dimensionnels en explicitant les dimensions participantes dans chacun d’entre eux. Ensuite nous avons défini, pour chacune des dimensions, les différentes hiérarchies présentes ainsi que les niveaux qui composent ces dernières.

Page 74

CONCLUSION GENERALE

Au terme de ce stage au cours duquel il nous a été demandé la mise en place d’un entrepôt de

données sur les financements extérieurs au Burkina Faso, les bénéfices qui s’en dégagent sont

manifestes. D’abord, sur le plan professionnel, des acquis considérables ont été engrangés. De

plus, outre l’approfondissement de nos connaissances sur la mise en place des systèmes

décisionnels, nous avons touché des doigts les réalités en termes de difficultés de maitrise par

les autorités des flux financiers extérieurs dans le processus du développement national.

En effet, par la modélisation dimensionnelle, l’analyse des besoins nous a mené à concevoir un

scénario présentant un système sous SQL SERVER 2008, en réseaux, ergonomique, simple

mais efficace et qui permettra aux décideurs d’avoir une idée plus claire des flux financiers

extérieurs et de leur utilisation.

En sommes, nous aimerions que le travail que nous avons entrepris au sein de la DGSI,

connaisse son achèvement pour permettre de voir nos efforts couronnés par la mise en place

complète du système informatique décisionnel sur les financements extérieurs.

Page 75

Bibliographie

Ouvrages

1. [Goglin, 1998] : J.F. Goglin; « La Construction du Datawarehouse : du Datamart

au Dataweb »; Hermes 1998.

2. [Inmon, 2002]: W. H. Inmon ; « Building the Data Warehouse Third Edition» ;

Wiley Computer Publishing 2002.

3. [Kimball, 2004] : R. Kimball et J. Caserta ; « The Data warehouse ETL Toolkit» ;

Wiley Publisshing, INC 2004

4. [Kimball, 2002] : R. Kimball et M. Ross ; « Entrepôts de Données : Guide Pratique

de Modélisation Dimensionnelle 2ème édition » ; Vuibert 2002.

5. [Nakache, 1998] : Didier Nakache; « Data Warehouse et Data Mining »;

Conservatoire National des Arts et Métiers de Lille; Version 1.1; 15 juin 1998.

Articles

6. [FILALI ABDERRAHMANE,KEDJNANE SOFIANE, 2009/2010] : Conception

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

décisionnel, lu le 10/03/2014

7. [Florian FRANCHETEAU, 2007/2008] : Étude des ETL Open Source, lu le

20/04/2014

8. [O. Boussaid, 2013-2014] : Le processus d'ETL, lu le 14/05/2014

Webographie

9. https://denglishbi.wordpress.com/tag/ssis/, consulté le 03/03/2014

10. http://support.microsoft.com/kb/943655/fr, consulté le 05/04/2014

11. http://denglishbi.wordpress.com/2009/03/29/ssis-2008-ado-net-source-issue-with- ssas-data-source-error-code-0x80004002/, consulté le 10/06/2014

12. www.labo-microsoft.org.htm, consulté le 12/06/2014

Data & Analytics

Rapport DESS Pousga Martin KIENDREBEOGO