Rapport DESS Pousga Martin KIENDREBEOGO

Page 1
Présenté par :
KIENDREBEOGO Pousga Martin
Etudiant en DESS/2ITIC
Tel : (00226) 70 72 87 34
Mail : martin.kiendrebeogo@gmail.com
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
Extract
Transform
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é_temps
jour_desemaine
Mois
trimestre
annee
Dimension
produit
Clé_produit
Description_produit
Categorie_produit
Fait de vente
Clé_temps
Clé_produit
Clé_magasin
Qte_vendue
Somme_vendue
Dimension
magasin
Clé_magasin
nom_magasin
adresse_magasin
type_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énients
Meilleure prise en charge de l’évolution des
besoins
Risque de concevoir une solution obsolète avant qu’elle soit
opérationnelle
Evolution du schéma des données source
Complexité de source de données
Tableau 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
Demande
Instruction 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_TEMPS
DATE
SEMESTRE
ANNEE
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_BAILLEUR
NOM_BAILLEUR
SIGLE_BAILLEUR
CODE_TYPE_BAILLEUR
ADRESSE_BAILLEUR
Figure 27 : La dimension BAILLEUR de l’activité « inscription projet»

Page 57
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_SECTEUR
NOM_SECTEUR
:
:
Figure 28 : La dimension SECTEUR_ACTIVITE de l’activité « inscription projet»
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_ZONE
NOM_ZONE
CODE_REGION
CODE_PROVINCE
CODE_DEPARTEMENT
Figure 29 : La dimension ZONE_GEOGRAPHIQUE de l’activité « inscription projet»
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_TEMPS
DATE
SEMESTRE
ANNEE
DIM BAILLEUR
-
-
-
-
-
PK_CODE_BAILLEUR
NOM_BAILLEUR
SIGLE_BAILLEUR
CODE_TYPE_BAILLEUR
ADRESSE_BAILLEUR
DIM SECTEUR
ACTIVITE
-
-
PK_CODE_SECTEUR
NOM_SECTEUR
:
:
DIM
ZONE_GEOGRAPHIQUE
-
-
-
-
-
PK_CODE_ZONE
NOM_ZONE
CODE_REGION
CODE_PROVINCE
CODE_DEPARTEMENT
Fait inscription projet
-
-
-
-
PK_CODE_BAILLEUR
PK_CODE_SECTEUR
PK_CODE_TEMPS
PK_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_TEMPS
DATE
MOIS
SEMESTRE
ANNEE
DIM BAILLEUR..
-
-
-
-
-
PK_CODE_BAILLEUR
NOM_BAILLEUR
SIGLE_BAILLEUR
CODE_TYPE_BAILLEUR
ADRESSE_BAILLEUR
DIM PROJET..
-
-
-
PK_CODE_PROJET
LIBELLE_PROJET
MONTANT_PROJET
DIM CONVENTION..
-
-
-
-
PK_CODE_CONVENTION
LIBELLE_CONVENTION
DATE_SIGNATURE
MONTANT_CONVENTION
Fait prevision
-
-
-
-
PK_CODE_BAILLEUR
PK_CODE_PROJET
PK_CODE_TEMPS
PK_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_TEMPS
DATE
SEMAINE
MOIS
SEMESTRE
TRIMESTRE
ANNEE
DIM BAILLEUR.
-
-
-
-
-
PK_CODE_BAILLEUR
NOM_BAILLEUR
SIGLE_BAILLEUR
CODE_TYPE_BAILLEUR
ADRESSE_BAILLEUR
DIM PROJET
-
-
-
PK_CODE_PROJET
LIBELLE_PROJET
MONTANT_PROJET
DIM CONVENTION
-
-
-
-
-
PK_CODE_CONVENTION
LIBELLE_CONVENTION
DATE_SIGNATURE
MONTANT_CONVENTION
CODE_MODE_FIN
Fait mobilisation
-
-
-
-
-
PK_CODE_BAILLEUR
PK_CODE_PROJET
PK_CODE_TEMPS
PK_CODE_CONVENTION
PK_CCODE_TYPE_DEC
+
+
MontantInitial ()
MontantFinal ()
: Number
: Number
DIM TYPE_BAILLEUR
-
-
PK_CODE_TYPE_BAILLEU
NOM_TYPE_BAILLEUR
DIM TYPE
DECAISSEMENT
-
-
PK_CODE_TYPE_DEC
LIB_TYPE_DEC
DIM
MODE_FINANCEMENT
-
-
PK_CODE_MODE_FIn
LIB_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.

Rapport DESS Pousga Martin KIENDREBEOGO

Rapport DESS Pousga Martin KIENDREBEOGO

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Similar a Rapport DESS Pousga Martin KIENDREBEOGO

Similar a Rapport DESS Pousga Martin KIENDREBEOGO (20)

Último

Último (6)

Rapport DESS Pousga Martin KIENDREBEOGO