Rapport DESS Pousga Martin KIENDREBEOGO

929 vues

Publié le

Mise en place d'un entrepôt de données sur les financements extérieurs au Burkina Faso. Ce document permet de comprendre l'apport de l'aide extérieur dans le budget du burkina, dans l'investissement surtout. Il permet de prendre en compte la prise de décision depuis les idées de mise en oeuvre des projets et programmes de développement, les signature des conventions de financements avec les partenaires techniques, du mode de décaissement et leur taux et de l’exécution des dépenses sur financements extérieurs sur les projets et programmes. Ceci est un documents utile pour les pays en voie de développement dont l'aide extérieur a une part importante dans l'investissement. Il propose une analyse pour une prise de décision et d'orientation pour la bonne gouvernance...

Publié dans : Données & analyses
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
929
Sur SlideShare
0
Issues des intégrations
0
Intégrations
12
Actions
Partages
0
Téléchargements
27
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Rapport DESS Pousga Martin KIENDREBEOGO

  1. 1. 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 »
  2. 2. 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 
  3. 3. 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 
  4. 4. Page 4  I.2.1  Présentation du sujet............................................................................................58  I.2.2  Grain du sujet.......................................................................................................58  I.2.3  Les dimensions participantes du modèle.............................................................58  I.2.4  Le modèle en étoile de l’activité « élaboration ».................................................59  I.3 Mobilisation.........................................................................................................................59  I.3.1  Présentation du sujet............................................................................................59  I.3.2  Grain du sujet.......................................................................................................59  I.3.3  Les dimensions participantes du modèle.............................................................59  I.3.4  Le modèle en flocon de l’activité «mobilisation » ................................................60  I.4 Exécution.............................................................................................................................60  I.4.1  Présentation du sujet............................................................................................60  I.4.2  Grain du sujet.......................................................................................................61  I.4.3  Les dimensions participantes du modèle.............................................................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 
  5. 5. 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.
  6. 6. 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.
  7. 7. 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
  8. 8. 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 
  9. 9. 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 
  10. 10. 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.
  11. 11. 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.
  12. 12. Page 12  INTRODUCTION GENERALE
  13. 13. 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.
  14. 14. 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.
  15. 15. 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
  16. 16. Page 16  Figure 2 : Le diagramme d’allocation de ressources Figure 3 : Légende du diagramme d’allocation de ressources
  17. 17. Page 17  PRESENTATION DE LA STRUCTURE D’ACCUEIL
  18. 18. 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.
  19. 19. 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).
  20. 20. Page 20  4. L’organigramme DGSI CCISE CAT SFM SRH SAD SCRP Secrétariat DEA DESTDRS DPE
  21. 21. Page 21  PARTIE I: GENERALITES « Un entrepôt de données ne s'achète pas, il se construit. » Bill Inmon
  22. 22. 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].
  23. 23. 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]
  24. 24. 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
  25. 25. 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
  26. 26. 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].
  27. 27. 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
  28. 28. 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]
  29. 29. 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.
  30. 30. 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
  31. 31. 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]
  32. 32. 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.
  33. 33. 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
  34. 34. 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.
  35. 35. 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 :
  36. 36. 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]
  37. 37. 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] 
  38. 38. 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.
  39. 39. 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/ 
  40. 40. 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.
  41. 41. 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]
  42. 42. 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.
  43. 43. 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.
  44. 44. Page 44  PARTIE II: MODELISATION
  45. 45. Page 45  CHAPITRE I: ETUDE DE L’EXISTANT
  46. 46. 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
  47. 47. 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 :
  48. 48. 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.
  49. 49. 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]
  50. 50. 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
  51. 51. 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.
  52. 52. 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.
  53. 53. Page 53  CHAPITRE II: CONCEPTION DE LA SOLUTION
  54. 54. 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.
  55. 55. 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.
  56. 56. 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»
  57. 57. Page 57  Nom colonne description PK_CODE_BAILLEUR Clé de la dimension bailleur NOM_BAILLEUR Le nom complet du bailleur SIGLE_BAILLEUR Le sigle ou le nom court du bailleur ADRESSE_BAILLEUR Adresse du bailleur (sa localité, son téléphone, son mail…) CODE_TYPE_BAILLEUR Le type du bailleur (bilatéral ou multilatéral) Tableau 8 : Tableau descriptif de la dimension BAILLEUR c) Dimension « secteur activité » Un secteur d’activité est un domaine défini d’activités interdépendantes qui concourent au développement du dit domaine. DIM SECTEUR ACTIVITE - - PK_CODE_SECTEUR NOM_SECTEUR : : Figure 28 : La dimension SECTEUR_ACTIVITE de l’activité « inscription projet» Nom colonne description PK_CODE_SECTEUR Clé de la dimension secteur d‘activité NOM_SECTEUR Le nom complet du secteur d’activité Tableau 9 : Tableau descriptif de la dimension Secteur_activité d) Dimension « Zone géographique » Elle définit la zone où le fait a eu lieu. Le grain le plus ici correspond au département. Une clé artificielle a été introduite du fait de l’évolution possible de cette dimension. DIM ZONE_GEOGRAPHIQUE - - - - - PK_CODE_ZONE NOM_ZONE CODE_REGION CODE_PROVINCE CODE_DEPARTEMENT Figure 29 : La dimension ZONE_GEOGRAPHIQUE de l’activité « inscription projet» Nom colonne description PK_CODE_ZONE Clé de la dimension Zone géographique NOM_ZONE Le nom complet de la zone CODE_REGION Code de la région CODE_PROVINCE Code de la province CODE_DEPARTEMENT Code du département Tableau 10 : Tableau descriptif de la dimension zone géographique
  58. 58. 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 I.2.1 Présentation du sujet 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. I.2.2 Grain du sujet 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. I.2.3 Les dimensions participantes du modèle Les dimensions participantes à ce modèle sont essentiellement les dimensions « temps », la dimension « projet », la dimension « convention » et la dimension « bailleur »
  59. 59. 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 I.3.1 Présentation du sujet 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. I.3.2 Grain du sujet 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. I.3.3 Les dimensions participantes du modèle 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 ».
  60. 60. 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 I.4.1 Présentation du sujet 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.

×