CONCEPTION ET IMPLEMENTATION D’UN SYSTEME D’AIDE A LA DECISION ET A LA GESTION URBAINE POUR LA VILLE DE PORTO-NOVO, BENIN

(1)

RÉPUBLIQUE DU BÉNIN

¤¤¤¤¤¤¤¤¤¤

UNIVERSITÉ D’ABOMEY-CALAVI (UAC) ¤¤¤¤¤¤¤¤¤¤

ECOLE POLYTECHNIQUE D’ABOMEY-CALAVI (EPAC) ¤¤¤¤¤¤¤¤¤¤¤¤¤

DEPARTEMENT DE GENIE INFORMATIQUE ET TELECOMMUNICATION (GIT)

Option : Réseaux Informatiques et Internet (RII)

MEMOIRE DE FIN DE FORMATION

POUR L’OBTENTION DU

DIPLOME D’INGENIEUR DE CONCEPTION

THEME :

Présenté par :

Bidossessi Emmanuel AGOSSOU

Soutenu publiquement le Vendredi 18 février 2011 devant le jury composé de :

Réalisé par :

Hola Florentio Ulrich M. DE SOUZA

Présenté et soutenu publiquement devant le jury composé de : Dr. Marc Kokou ASSOGBA,Président du jury, Enseignant à l’EPAC

Feu Dr. Sèmiyou A. ADEDJOUMA, Directeur de mémoire, Enseignant à l’EPAC Ing. Serge AHOUANVOEDO, Membre du jury

Dr. Jamal Dissou, Membre du jury

Année Académique : 2012 - 2013

6

^ème

Promotion

CONCEPTION ET IMPLEMENTATION D’UN SYSTEME D’AIDE A LA DECISION ET A LA GESTION URBAINE POUR

LA VILLE DE PORTO-NOVO, BENIN

(2)

SOMMAIRE

Dédicaces . . . iii

Remerciements . . . iv

Liste des sigles et abréviations . . . vi

Liste des tableaux . . . ix

Liste des figures . . . x

Résumé . . . xiv

Abstract . . . xv

INTRODUCTION GENERALE . . . 1

PARTIE I : SYNTHESE BIBLIOGRAPHIQUE . . . 7

Chapitre 1 : Rappels théoriques sur les Systèmes d’Information Décisionnels . . . 8

Chapitre 2 : Les Systèmes d’Information Urbains existants . . . 26

PARTIE II : METHODOLOGIE . . . 32

Chapitre 3 : Méthodologie d’étude . . . 33

Chapitre 4 : Modélisation du sytème . . . 41

Chapitre 5 : Choix techniques de réalisation et environnement de test . . . 58

PARTIE III : RESULTATS ET DISCUSSION . . . 64

Chapitre 6 : Résultats obtenus . . . 65

Chapitre 7 : Déploiement réel du système . . . 76

Chapitre 8 : Discussion . . . 85

CONCLUSION ET PERSPECTIVES . . . 87

Références bibliographiques . . . 90

Annexes . . . 94

Glossaire . . . 109

(3)

English version . . . 116 Table des matières . . . 133

(4)

DEDICACES

A

Mon père Jonas C. DE SOUZA Ma mère Clémentine DJOHOSSOU

Tous mes frères et sœurs

je dédie ce travail pour le rôle que chacun d’entre vous a joué dans mon éducation et ma formation .

Hola Florentio Ulrich M. DE SOUZA

(5)

Je remercie en premier lieu le Seigneur Dieu Tout-Puissant pour m’avoir permis d’aller jusqu’au bout du présent travail malgré les in- nombrables douloureuses épreuves traversées.

Je remercie aussi tous ceux qui de près ou de loin ont participé à la réalisation de ce travail. Je pense particulièrement :

– au Pr. Félicien AVLESSI, Directeur de l’Ecole Polytechnique d’Abo- mey-Calavi (EPAC) et à tout le personnel administratif ;

– au Dr. Sèmiyou A. ADEDJOUMA, maître de ce mémoire, qui a accepté encadrer mes travaux. Ses enseignements de qualité, son oreille attentive, sa patience, ses conseils judicieux m’ont été d’une aide précieuse et capitale ;

– au Dr. Marc Kokou ASSOGBA, Chef du Département du Génie Informatique et Télécommunication (GIT) à l’EPAC, pour son at- tention envers les étudiants dudit département ;

– à M. Serge AHOUANVOEDO, Directeur de la Prospective du Dé- veloppement et de la Coopération de la Mairie de Porto-Novo, pour son grand aide dans le présent travail ;

– à mon tuteur M. Vinasétan Ratheil HOUNDJI, Doctorant à l’Uni- versité Catholique de Louvain, pour son assistance et son grand aide dans le présent travail ;

– à tous les professeurs de l’EPAC, et en particulier à ceux qui ont participé à ma formation, pour la richesse de leurs enseignements ;

– à mon frère Gillos pour son soutien constant ;

(6)

Système d’Aide à la Décision pour la gestion urbaine : application à la ville de Porto-Novo, Bénin

– à mes oncles, tantes, cousins, cousines, neveux, nièces ;

– à Boris, Edouard, Maxime, Oscar, Briand, Jean-Boris pour leur soutien, avis critiques et apports de toutes sortes ;

– à tous mes camarades du département GIT, en particulier Sidi- kou, Sédar, Kafu, Stéphanie, Razidath, Abraham, Joris, Samuel, Edgard, Darex avec qui j’ai passé de bons moments ;

– aux ainés de la 4^èmeet 5^èmepromotion du GIT en particulier Ross, Nazirou, Brice, John, Nissa, Paterne, Charbel, Lionnel, Marlyse pour leur soutien et aide.

(7)

A

ANCB : Association Nationale des Communes du Bénin API : Application Programming Interface

B

BDU : Banque de Données Urbaines BI : Business Intelligence

BLR : Boucle Locale Radio

C

CSV : Comma-Separated Values

D

DAT : Délégation à l’Aménagement du Territoire

E

ENDA-tm : Environnement et Développement du tiers monde EPFL : Ecole Polytechnique Fédérale de Lausanne

ETL : Extract Transform Load

(8)

H

HOLAP : Hybrid OnLine Analytical Processing HTTP : HyperText Transfer Protocol

I

IA : Intelligence Artificielle

INSAE : Institut National de la Statistique et de l’Analyse Econo- mique

IP : Internet Protocol

J

JDBC : Java DataBase Connectivity JSF : JavaServer Faces

M

MDGLAAT : Ministère de la Décentralisation, de la Gouvernance Locale, de l’Administration et de l’Aménagement du Territoire MDX : MultiDimensional eXpression

MECPDEAP : Ministère d’Etat Chargé de la Prospective, du Déve- loppement et de l’Evaluation de l’Action Publique

MOLAP : Multidimensional OnLine Analytical Processing

O

OGC : Open Geospatial Consortium OLAP : OnLine Analytical Processing OS : Operating System

(9)

R

RAID : Redundant Arrays of Inexpensive Disk ROLAP : Relational OnLine Analytical Processing

S

SAD : Système d’Aide à la Décision

SAGU : Système d’Aide à la Gestion Urbaine SGBD : Système de Gestion de Base de Données SID : Système d’Information Décisionnel

SIG : Système d’Information Géographique SIT : Système d’Information Territorial

SITG : Système d’Information du Territoire Genevois SIU : Système d’Information Urbain

SLR : Spatial Level Reference

SMURF : Système de Monitoring Urbain Fonctionnel SQL : Strutured Query Language

T

TIC : Technologies de l’Information et de la Communication

U

UML : Unified Modeling Language

V

VLAN : Virtual Local Area Network

X

XML : eXtensible Markup Langage

(10)

LISTE DES TABLEAUX

III.I Extrait de la liste des indicateurs retenus . . . 37 V.I Synthèse des outils utilisés . . . 61 V.II Liste des équipements utilisés pour les tests . . . 63 V.III Taille de données générées par source de données . . 63 VII.I Caractéristiques recommandées des serveurs . . . 81 VII.II Estimation du coût . . . 84 I Liste des indicateurs utilisés dans notre système (Ex-

trait 1) . . . 96 II Liste des indicateurs utilisés dans notre système (Ex-

trait 2) . . . 97 III List of hosts used for the simulation . . . 125 IV Recommended characteristics of the servers . . . 129

(11)

1.1 Niveaux et membres de la dimension temporelle . . . . 10

1.2 Modèle en étoile . . . 13

1.3 Modèle en flocon . . . 13

1.4 Modèle mixte . . . 14

1.5 Modèle en constellation . . . 14

1.6 Architecture « magasin de données indépendantes » (Source : (Ariyachandra et Watson, 2005)) . . . 15

1.7 Architecture « bus de magasin de données » (Source : (Ariyachandra et Watson, 2005)) . . . 16

1.8 Architecture « Hub-and-Spoke » (Source : (Ariyachan- dra et Watson, 2005)) . . . 17

1.9 Architecture « entrepôt de données centralisées » (Source : (Ariyachandra et Watson, 2005)) . . . 18

1.10 Architecture fédérée (Source : (Ariyachandra et Wat- son, 2005)) . . . 19

1.11 Architecture des systèmes décisionnels (Source : (Le- brun et Charrier, 2008)) . . . 22

1.12 Couhe de préparation de données (back-room) (Source : (Lebrun et Charrier, 2008)) . . . 23

1.13 Couche de stockage de données (Source : (Lebrun et Charrier, 2008)) . . . 24

1.14 Couche de restitution de données (front-room) (Source : (Lebrun et Charrier, 2008)) . . . 24

3.1 Méthodologie d’etude de notre système . . . 34

(12)

3.2 Deux architectures métiers possibles : « client serveur

» (en haut) et « n tiers » (en bas) . . . 38 3.3 Principe de fonctionnement global de notre système . . 40 4.1 Modèle en étoile potentiel de l’entrepôt . . . 43 4.2 Différents niveaux de granularité des indicateurs sui-

vant la dimension « region » . . . 44 4.3 Modèle mixte de l’entrepôt de données du système . . . 46 4.4 Diagramme de classe de l’entrepôt de données du sys-

tème . . . 46 4.5 Back-room potentiel du modèle physique de données

de l’entrepôt . . . 47 4.6 Front-room potentiel du modèle physique de données

de l’entrepôt . . . 48 4.7 Processus d’intégration de données dans l’entrepôt . . 50 4.8 Principe de fonctionnement du serveur ROLAP . . . 53 4.9 Gestion d’une requête par le processus d’analyse en

ligne . . . 54 4.10 Diagramme de cas d’utilisation de l’outil de visualisation

OLAP . . . 55 4.11 Diagramme de séquence de l’outil de visualisation OLAP 56 4.12 Architecture globale de l’outil de visualisation . . . 57 4.13 Diagramme de flux simplifié pour la construction d’une

requête MDX . . . 57 5.1 Architecture réseau utilisée pour nos tests . . . 62 6.1 Architecture de la solution . . . 66 6.2 Interface graphique de l’outil de visualisation OLAP de

notre système . . . 68 6.3 Extrait de données de l’entrepôt . . . 69

(13)

6.4 Valeur des indicateurs « Nombre de centres de santé » dans chaque quartier de Porto-Novo pour l’année 2013 :

vue tabulaire . . . 70

6.5 Valeur des indicateurs « Nombre de centres de santé » et « Mortalité infantile » dans chaque quartier de Porto- Novo pour l’année 2013 : vue histogramme . . . 71

6.6 Effectif scolaire des filles par quartier de Porto-Novo au cours de l’année 2012 : vue camembert . . . 72

6.7 Consommation en eau dans chaque arrondissement de Porto-Novo de 2008-2013 . . . 73

6.8 Affichage sur la carte géographique de la commune de Porto-Novo les valeurs des indicateurs « Taux de pau- vreté » et « Croissance démographique » dans chaque arrondissement pour l’année 2013 . . . 74

6.9 Contenu du fichier PDF exporté après analyse des indicateurs « Taux de pauvreté » et « Croissance démogra- phique » par arrondissement de Porto-Novo pour l’an- née 2013 . . . 75

6.10 Contenu respectif des fichiers Excel et CSV exportés après analyse des indicateurs «Taux de pauvreté» et «Croissance démographique» par arrondissement de Porto-Novo pour l’année 2013 . . . 75

7.1 Présentation de l’architecture réseau de déploiement du système . . . 78

C.1 Carte de l’Afrique (gauche), carte du Bénin (droite) . . . 106

C.2 Carte de Porto-Novo (Fond RFU-Porto-Novo, 2005) . . 106

D.1 Interface de visualisation OLAP du système . . . 107

1 Data integration process in the warehouse . . . 123

2 Functioning of the OLAP analysis server . . . 124

3 Architecture of the system . . . 125

4 Graph-like per-area statistics (histogram) . . . 127

(14)

5 Graph-like per-district statistics (Curve) . . . 128 6 Spatial distribution of indicators per-district . . . 128 7 Network architecture . . . 130

(15)

Les Systèmes d’Aide à la Décision, appliqués en milieu urbain, constituent aujourd’hui des outils essentiels d’aide à la décision pour l’ensemble des acteurs d’une ville en particulier les gestionnaires de la ville. Ce travail présente un tel outil développé au travers de l’application à un cas réel : la ville de Porto-Novo au Bénin. La méthodologie adoptée se résume comme suit : analyse des besoins, proposition d’un système, modélisation, implémentation et tests. Dans la base de données PostgreSQL munie de Postgis, nous avons implémenté un entrepôt de données suivant le modèle mixte de l’approche ROLAP (Relationnal OnLine Analytical Processing). Cet entrepôt regroupe les indicateurs de développement de la ville de Porto-Novo. L’ETL Kettle, les serveurs ROLAP Mondrian et cartographique MapServer et un outil de visualisation écrite en Java ont été déployés afin de stocker et d’afficher les données de l’entrepôt sous forme de tableau, graphe et carte. Des données tests d’indicateurs de Porto-Novo sur dix ans ont été entrées. Le système a montré ses capacités à les stocker et les analyser. Il renforce l’aide à la décision proposée par les systèmes existants tels que le SMURF, le SIT du Bénin et le SAGU en permettant d’intégrer de gros volumes de données de sources hétérogènes et éparses.

Mots clés : entrepôt de données, système d’information décisionnel, Porto-Novo, analyse OLAP, aide à la décision, modélisation multidimensionnelle.

(16)

ABSTRACT

Nowadays, Decision-making Support Systems applied in urban areas are essential tools for decision-making support for all players in a city, particularly for city managers. This work present the design of such a tool developed through the application to a real case : Porto- Novo city at Benin. The methodology adopted to realize this system is as follows : needs analysis, proposal of a system, system modeling, implementation and testing. In the PostgreSQL DBMS equipped with its PostGIS extension, we have implemented a data warehouse ac- cording to the mixed multidimensional model of ROLAP (Relational Online Analytical Processing) approach. The warehouse includes de- velopment indicators of the city of Porto-Novo. Kettle ETL, Mondrian ROLAP server and MapServer and a web application written in Java were made to allow users to view the data in the warehouse as a table, graph and map. Testing data from indicators have been randomly ge- nerated over ten years. The system has shown its capacity to store and analyze them. This system enhances decision-making support proposed by existing systems in urban areas such as SMURF, TIS of Benin and the SAGU by its capacity of integration of large volumes of data from heterogeneous and scattered sources.

Keywords: data warehouse, Decision-making Support System, Porto- Novo, OLAP analysis, decision-making support, multidimensional modeling.

(17)

INTRODUCTION

GENERALE

(18)

INTRODUCTION GENERALE

La gestion urbaine est un processus complexe qui nécessite une base d’informations conséquentes et une grande coordination entre les acteurs qui font la ville (Repetti et Prelaz-droux, 2002). Ces diffé- rents acteurs publics sont en marge d’information et faute de pouvoir la traiter efficacement, passent à côté d’opportunités ou pire, prennent de mauvaises décisions. Des systèmes efficaces, fiables sont apparus suite au développement des Technologies de l’Information et de la Communication (TIC) afin de les aider à renforcer leur capacité de planification et de gestion de la ville : les Systèmes d’Information Urbains (SIU).

D’un autre côté, pour une meilleure gestion urbaine, il est néces- saire de mettre en place un système fiable regroupant l’ensemble des informations utiles au développement de la ville. Ce système doit permettre aux acteurs de la ville, une vue décisionnelle sur l’ensemble des secteurs d’activité de la ville. Il est donc important d’intégrer aux systèmes d’information urbains des outils d’aide à la décision basés sur l’informatique décisionnelle afin d’obtenir un Système d’Informa- tion Décisionnel (SID). Ces derniers sont nés d’un besoin des entreprises à fournir aux décideurs des moyens d’accéder aux données de leurs propres systèmes dans le but de piloter leurs activités (Kimball, 2001). Il se base sur les entrepôts de données, des outils d’analyse OLAP (Online Analytical Processing) et des outils de datamining faci-

(19)

litant l’aide à la prise de décision.

Ce projet vise à concevoir un outil à caractère de SID permettant aux différents acteurs des villes en développement de renforcer leurs capacités de planification et de gestion de leur ville.

1 Contexte, justification et problématique

Les villes des pays en voie de développement connaissent une vé- ritable explosion démographique. Abritant plus de 35% des popula- tions du Sud, elles voient leur taille doubler tous les quinze ans en moyenne ; tous les dix ans, en Afrique de l’Est et de l’Ouest (ONU, 2013).

Grâce à l’avènement de la décentralisation, les communes, en particulier la commune de Porto-Novo au Bénin, sont devenues auto- nomes pour la gestion de leurs activités. Cependant, le manque de moyens financiers, de personnels qualifiés et d’outils nécessaires à la gestion des villes a engendré d’importants problèmes socio-économi- ques : infrastructures mal entretenues, mauvais suivi des activités économiques de la ville, absence d’un registre pour l’inventaire des actions menées sur la ville.

Face à tous ces problèmes, plusieurs travaux de recherche ont été réalisés afin de proposer des outils d’aide à la gestion urbaine dans les villes des pays en développement. On peut citer le Système de Mo- nitoring Urbain Fonctionnel (SMURF) développé et appliqué à la ville de Thiès et Saint Louis (Sénégal), Nakuru (Kenya), Bobo-Dioulasso (Burkina-Faso) (Repetti et Prélaz-Droux, 2002), le Système d’Infor- mation Territorial (SIT) réalisé en 2009 par la Délégation à l’Amé- nagement du Territoire (DAT) du Ministère de la Décentralisation, de la Gouvernance Locale, de l’Administration et de l’Aménagement du Territoire du Bénin implémenté N’Dali, Bénin, etc. (DAT, 2011) et le

(20)

Système d’Aide à la Gestion Urbaine (SAGU) réalisé pour la gestion urbaine et appliqué à la ville de Porto-Novo, Bénin (Adédjouma et Houndji, 2012), etc.

Le SMURF bien qu’il ait été appliqué à la ville de Thiès au Sénégal et dans plusieurs autres villes en développement, demeure un outil de monitoring peu accessible et onéreux. Quant au SAGU, il constitue un outil de gestion urbaine flexible, évolutif et très accessible. Néanmoins, cet outil est dépourvu de données cartographiques de la ville et ne permet pas aussi de faire de la fouille de données. Le SIT quant à lui est un outil de gestion urbaine encore embryonnaire. Il est à une étape de test dans certaines communes du Bénin telles que N’Dali, Tchaourou, Parakou, etc. (DAT, 2011). Certains aspects tels que la fouille de données sont manquants dans ce système.

Les données ou indicateurs utilisés par l’ensemble de ces différents systèmes sont des variables quantitatives et qualitatives permettant d’analyser et d’appréhender les différentes évolutions et tendances des différents secteurs d’activité de la ville (Adédjouma et Houndji, 2012). Ces données proviennent généralement de différentes sources hétérogènes. Elles sont éparpillées et éparses parce que chacune d’elles est née d’un besoin d’analyse d’un indicateur d’un secteur donné. Cependant, les SIU cités précédemment ne permettent pas l’intégration de ces données hétérogènes issues de différentes sources. L’un des plus grands atouts dans la bonne gestion urbaine étant justement l’analyse détaillée des indicateurs sectoriels, le fait de pouvoir rendre structurées, homogènes ces différentes données permettra de dégager les grandes tendances d’évolution de la ville et de proposer des analyses pertinentes. Un entrepôt de données répond à tous ces problèmes de données et permet de faire des analyses sur de gros volumes de ces données sous forme de tableau de bord, de tableaux multidimensionnels, de graphes et de cartes géographiques

(21)

interactives. Il offre une aide à la décision, détermine des indicateurs de suivi et permet de faire des analyses en temps réel (Tranchant, 2011). La représentation des données sur des cartes dans un SIU permet aux décideurs de pouvoir percevoir et dégager facilement et rapidement les informations utiles (Bédard, 2008). Ce projet propose donc la conception d’un nouveau système d’aide à la décision en milieu urbain à travers la conception d’un entrepôt de données et le dé- ploiement des outils d’analyse de données (analyse en ligne OLAP).

Ce système d’information à caractère d’observatoire urbain sera ap- pliqué à un cas réel : la ville de Porto-Novo, Bénin.

2 Objectifs

L’objectif principal de ce projet est de concevoir un outil fiable, flexible, robuste d’aide à la prise de décision en milieu urbain. Cet outil permettra aux acteurs de la ville (et en priorité à la municipalité) de renforcer leurs capacités de planification et de gestion de la ville.

Les objectifs spécifiques sont :

– mettre à la disposition des différentes villes du tiers-monde en particulier la ville de Porto-Novo au Bénin, un dispositif leur permettant une lecture exhaustive et fiable de leur niveau de déve- loppement et des dynamiques en cours sur leur territoire ;

– permettre l’aide à la prise de décision sur des données justes et conséquentes, offrant une image réelle du territoire local ;

– faciliter à la municipalité, la promotion d’un développement équi- table et durable de leur localité.

Le présent mémoire fait le point de nos travaux et comprend trois parties :

– Dans la première partie, nous présenterons d’abord une syn- thèse bibliographique sur les principaux concepts des technolo-

(22)

gies décisionnelles et les systèmes d’information. Ensuite, nous dresserons un panorama des systèmes d’information urbains existants, desquels nous tirerons les problèmes et déduisons les insuffisances ;

– Dans la deuxième partie, nous proposons une solution au processus de gestion urbaine. Cette partie présente donc notre proposition, la méthodologie adoptée, sa modélisation ainsi que les différents choix techniques opérés ;

– La troisième partie fait une présentation et une analyse des ré- sultats issus de notre travail ;

– Enfin, dans une conclusion, nous faisons le point de nos travaux et proposons des perspectives.

(23)

SYNTHESE

BIBLIOGRAPHIQUE

(24)

CHAPITRE

RAPPELS THEORIQUES SUR LES SYSTEMES 1

D’INFORMATION DECISIONNELS

Les Systèmes d’Aide à la Décision (SAD) sont des systèmes flexi- bles qui aident les décideurs dans l’extraction d’informations utiles pour identifier et résoudre des problèmes et pour prendre des déci- sions (Kimball, 2001). Ils harmonisent ces informations, provenant de différentes sources, dans un environnement unique, uniforme et fa- milier à l’utilisateur final. Ils assurent la combinaison, l’uniformisation et la synchronisation des bases de données avec les modèles d’analyse et les techniques de visualisation, afin de comparer les résultats obtenus et de pouvoir concevoir des hypothèses données. Parmi les systèmes d’aide à la décision, les systèmes d’entrepôts de données sont les plus utilisés dans le monde industriel et académique (Tran- chant, 2011).

1.1 Entrepôts de données

1.1.1 Définition et concepts principaux

Un entrepôt de données est « une collection de données intégrées, non volatiles et historisées pour la prise de décisions » (Inmon, 2005).

(25)

Plus précisément, il est :

– orienté sujet : car chaque zone (fait) de l’entrepôt est organisée pour répondre à une problématique métier, par exemple, les ha- bitudes d’achat des clients, ou l’efficacité d’une équipe (Inmon, 2005) ;

– intégré : car il permet le rassemblement de sources de données provenant de différents systèmes applicatifs à l’échelle de l’entreprise. Les données sources sont souvent incohérentes, puis- qu’elles arborent des formats différents. Les sources de données intégrées doivent subir une mise en cohérence pour présenter une vue unifiée des données aux utilisateurs (Inmon, 2005) ; – historisé : car chaque donnée est horodatée et ne sera jamais

effacée ni modifiée (voir «non volatile»). Ceci permet à l’utilisateur du système de constater une progression, comprendre les tendances, etc. (Inmon, 2005) ;

– non volatile : les nouvelles données viennent toujours s’ajouter en supplément à la base de données et non en remplacement.

La base de données absorbe continuellement ces nouvelles don- nées en les intégrant de manière incrémentielle aux données précédentes (Inmon, 2005).

Lorsque l’entrepôt de données est spécialisé sur un thème ou un métier, on le désigne par le terme anglo-saxon datamart (Tranchant, 2011). Les datamarts sont généralement utilisés dans les très grands systèmes, où de nombreux utilisateurs doivent pouvoir effectuer leurs analyses, sans impacter les autres.

La modélisation multidimensionnelle constitue le modèle utilisé dans les systèmes d’entrepôts de données (Kimball, 2001). Elle consiste à considérer un sujet analysé comme un point dans un espace à plusieurs dimensions. Elle fait intervenir de nouveaux concepts tels que les faits et les dimensions (Kimball et al., 1998). Dans ce modèle, le

(26)

concept central est le cube¹ ou hypercube, lequel est constitué des éléments appelés cellules qui peuvent contenir une ou plusieurs mesures. La localisation de la cellule est faite à travers les axes, qui cor- respondent chacun à une dimension.

La dimension constitue une perspective de l’analyse. En effet, elle représente les différents axes d’analyse. Les dimensions peuvent être organisées de façon hiérarchique : on parle de dimensions hiérar- chiques. Chaque hiérarchie est composée de plusieurs niveaux dont les différentes valeurs sont appélées membres (figure 1.1). Un niveau représente une granularité ou un degré de précision dans l’analyse de l’information.

Figure1.1 – Niveaux et membres de la dimension temporelle

Si l’on prend comme référence la branche gauche de la figure 1.1, les membres sont représentés par des rectangles. Les membres « Janvier », « Février » et « Mars » sont des enfants du membre «

1. En géométrie un cube désigne un solide à six faces carrées. Dans le modèle multidimensionnel, un cube est une manière d’organiser des données, en réalité il ne s’agit pas d’un cube. Ce n’est qu’une métaphore graphique afin de mieux comprendre le modèle.

(27)

Trimestre 1 », lui-même enfant de « 2011 ».

Le fait est le sujet de l’analyse et l’élément central de la structure.

Il est formé de mesures, généralement numériques et renseignées de manière continue. Ces mesures permettent de résumer un grand nombre d’enregistrements des données sources en quelques-uns. Le fait est analysé selon les dimensions. Celles-ci, par leurs croisements, donnent le contexte de la valeur du fait.

Le niveau le plus bas de la hiérarchie impose la granularité maxi- male de l’entrepôt. En effet, les données sont généralement agrégées au niveau le plus petit/précis de la structure multidimensionnelle. Tou- jours dans l’exemple illustré dans la figure 1.1, la granularité de la dimension temporelle est le mois. Chaque niveau d’une hiérarchie re- présente un degré de précision différent de l’information, on dit encore qu’elle représente une granularité différente de l’information. La défi- nition de la granularité est capitale lors de la conception d’un entrepôt de données. Elle permet d’identifier le modèle multidimensionnel des données dans l’entrepôt.

1.1.2 Conception d’un entrepôt de données

La mise en place d’un entrepôt de données est un processus complexe. En effet, pour réaliser un entrepôt de données, il faut définir l’approche de conception de l’entrepôt, l’architecture logique des données et l’architecture physique de stockage de ces données dans l’entrepôt (Kimball, 2001).

1.1.2.1 Approche de conception d’un entrepôt de données

Les approches de conception d’entrepôts peuvent être classées en trois catégories (Rizzi et al., 2006) :

– Les approches « descendantes » ou « top-down » (Kimball et Ross, 1996 et Prat et al., 2006) : elles permettent de construire

(28)

le schéma de l’entrepôt à partir d’une analyse détaillée des besoins des décideurs. Les problèmes de correspondances entre ces besoins et les sources existantes sont traités à postériori lors du chargement des données dans l’entrepôt ;

– Les approches « ascendantes » ou « bottom-up » (Golfarelli et Rizzi, 1998 et Hüsemann et al., 2000) : elles débutent par une analyse détaillée des sources de données. Les besoins des dé- cideurs ne sont pris en compte que vers la phase d’analyse en ligne des données ;

– Les approches « mixtes » (Zepda et al., 2008) : elles considèrent à la fois les besoins des décideurs et la disponibilité des don- nées sources. Elles présentent donc l’avantage de concevoir des schémas multidimensionnels valides par rapport aux sources de données.

1.1.2.2 Architecture logique des données d’un entrepôt de données

Les données d’un entrepôt sont stockées suivant un modèle logique. Ce modèle logique est réalisé suivant trois approches : l’approche Relational OnLine Analytical Processing (ROLAP), l’approche Multidimensional OnLine Analytical Processing (MOLAP) et l’approche Hybrid OnLine Analytical Processing (HOLAP).

L’approche ROLAP est la plus utilisée (Kimball, 2001). Elle permet de modéliser l’entrepôt de données autour d’une base de données relationnelle en émulant les concepts de « dimensions », de « mesures » ou de « hiérarchies » (Tranchant, 2011). Il existe quatres (4) modèles définis par l’approche ROLAP (Tranchant, 2011) :

– Le modèle en étoile (figure 1.2) qui présente les dimensions qui sont liées à une table de faits centrale. Ces dimensions sont nor- malisées c’est-à-dire leur structure est fixée.

(29)

Figure1.2 – Modèle en étoile

– Le modèle en flocon (figure 1.3) qui dérive du schéma en étoile avec une relation centrale et autour d’elle les différentes dimensions sont éclatées ou décomposées suivant les niveaux de leur hiérarchie et ne sont plus normalisées comme pour le schéma étoile.

Figure1.3 – Modèle en flocon

– Le schéma mixte, résultat de la combinaison des structures en étoile et en flocon, ce modèle, illustré par la figure 1.4, exploite les avantages des deux : certaines dimensions sont normalisées,

(30)

généralement les plus grandes tables et d’autres ne le sont pas.

Figure1.4 – Modèle mixte

– Le schéma en constellation (figure 1.5) représente plusieurs tables de faits qui partagent des dimensions communes. Ces dimensions sont qualifiées de conformes. Autour de ces faits, le schéma utilisé peut-être en étoile, en flocon ou mixte. L’utilisation de dimensions conformes permet d’obtenir une grande cohérence entre les vues destinées aux utilisateurs et oblige à une homogénéité des attributs et des mesures.

Figure1.5 – Modèle en constellation

Ces différentes architectures des données sont encore appelées modèles multidimensionnels de données.

(31)

1.1.2.3 Architecture physique de stockage de données dans un entrepôt de données

L’architecture physique de stockage des données dans un entrepôt permet de matérialiser les différentes couches de stockage de don- nées dans l’entrepôt ainsi que l’accès à ces données par les outils extérieurs. Il existe essentiellement cinq (5) architectures pour le stockage de données dans un entrepôt de données (Kimball, 1996) :

1. L’architecture « magasin de données indépendantes »

Cette architecture (figure 1.6) a pour caractéristique principale les datamarts qui opèrent de façon différente au sein de l’entre- pôt, les données sont disposées en « silos fonctionnel ». Cette architecture est très simple à mettre en place et moins coûteuse (Ariyachandra et Watson, 2005). Cependant, des risques d’inco- hérences et de redondances entre les datamarts existent et cette architecture n’est pas extensible (Ariyachandra et Watson, 2005) ;

Figure1.6 – Architecture « magasin de données indépendantes » (Source : (Ariya- chandra et Watson, 2005))

2. L’architecture « bus de magasin de données »

L’architecture « bus de magasin de données » (figure 1.7) est ca- ractérisée par des datamarts de l’entrepôt reliés entre eux par

(32)

soit une dimension ou, soit une mesure (dimension/mesure commune). Elle intègre des données assurées par des dimensions conformes et donne des résultats rapides (Kimball, 2001). Elle se base sur l’approche bottom-up de Ralph Kimball. Le modèle multidimensionnel utilisé par cette architecture est le modèle en étoile. Cependant, il offre des performances sous-optimales des analyses impliquant plusieurs datamarts (Ariyachandra et Wat- son, 2005) ;

Figure1.7 – Architecture « bus de magasin de données » (Source : (Ariyachandra et Watson, 2005))

3. L’architecture « Hub-and-Spoke »

L’architecture « Hub-and-Spoke » (figure 1.8) est caractérisée par l’entrepôt de données (hub) qui contient des données atomiques (c’est-à-dire de niveau de détail le plus fin), les datamarts(spoke) qui reçoivent les données de l’entrepôt. Ces datamarts suivent le modèle dimensionnel et sont partiellement résumés (pas ato- mique). Dans cette architecture, la plupart des requêtes analytiques sont faites sur les datamarts. Il se base sur l’approche top-down de Bill Inmon. Comme avantage, cette architecture per-

(33)

met l’intégration et la consolidation complètes des données de l’entreprise (Inmon, 2005). Cependant, on peut avoir des redondances de données entre les datamarts et du coup une performance sous-optimale des analyses impliquant plusieurs datamarts (Ariyachandra et Watson, 2005) ;

Figure 1.8 – Architecture « Hub-and-Spoke » (Source : (Ariyachandra et Watson, 2005))

4. L’architecture « entrepôt de données centralisées »

Cette architecture (figure 1.9) est similaire à l’architecture « Hub- and-Spoke » mais sans des datamarts dépendants. Elle est ca- ractérisée par un volumineux entrepôt de données servant l’entreprise. Les données peuvent être atomiques ou résumées. Com- me avantage, cette architecture permet aux utilisateurs d’avoir accès à toutes les données de l’entreprise. L’intégration et la main- tenance des données sont faciles car les données sont à un seul endroit (Ariyachandra et Watson, 2005). Cependant, cette architecture est longue et très coûteuse à développer, son extensibilité est limitée ou très coûteuse (Ariyachandra et Watson, 2005) ;

(34)

Figure 1.9 – Architecture « entrepôt de données centralisées » (Source : (Ariya- chandra et Watson, 2005))

5. L’architecture fédérée

L’architecture fédérée (figure 1.10) est caractérisée par un en- trepôt de données distribué sur plusieurs systèmes hétérogènes.

Tout se fait de manière transparente, l’utilisateur ne voit pas que les données sont réparties. Les données sont intégrées logique- ment ou physiquement à l’aide des métadonnées. Comme avantage, ce système est utile lorsqu’il y a déjà un entrepôt en place (acquisition ou fusion de plusieurs compagnies par exemple). Il demande aussi peu de ressources matérielles additionnelles (Ari- yachandra et Watson, 2005). Cependant, il est très complexe (synchronisation, parallélisme, concurrence, etc.). Il a de faibles performances et ne permet pas de contrôler les sources et les qualités de données (Ariyachandra et Watson, 2005).

Parmi ces 5 architectures, trois (3) d’entre elles sont les plus uti- lisées par les systèmes décisionnels pour diverses raisons : qualité de l’information (précise, complète, cohérente), qualité du système (flexible, extensible, intégration), impact sur les décideurs (producti- vité, bonne décision, satisfaction) (Ariyachandra et Watson, 2005). Il s’agit de : l’architecture « bus de magasin de données », l’architecture

(35)

Figure1.10 – Architecture fédérée (Source : (Ariyachandra et Watson, 2005))

« Hub-and-Spoke » et l’architecture « entrepôt de données centrali- sées » (Tranchant, 2011).

1.2 Les systèmes d’information

Un Système d’Information est un ensemble de composants interre- liés qui recueillent de l’information, la traitent, la stockent et la diffusent afin de soutenir la prise de décision et le contrôle au sein d’une organisation (Bédard, 2008). Lorsque l’information se rapporte à un lieu plus précisément à une ville, on parle de Système d’Information Ur- bain (SIU) ou Système d’Information Géographique (SIG).

1.2.1 Le Système d’Information Urbain

Les SIU sont apparus au courant des années 70 et constituent des outils d’aide à la décision facilitant la planification et la gestion des villes (Turki, 2010). On distingue deux grands types de SIU : ceux servant essentiellement pour l’administration des services urbains et

(36)

ceux, plus récents, dont l’objectif majeur est l’analyse de l’espace urbain (Turki, 2010). Il s’agit respectivement de Banque de Données Urbaines (BDU) et des observatoires urbains.

1.2.2 L’information géographique et les SIG

Un SIU (BDU ou Observatoire Urbain) manipule parfois des don- nées géographiques afin de matérialiser le territoire de façon conve- nable. Lorsque le SIU nécessite un aspect cartographique, il hérite des caractéristiques d’un système d’information géographique.

L’information géographique est la représentation d’un objet ou d’un phénomène réel localisé dans l’espace à un moment donné. Elle est caractérisée par une composante purement spatiale et une composante sémantique (Degréne et Salgé, 1997). La composante spatiale permet de représenter la position sur la surface terrestre et la forme d’un objet du monde réel (localisation d’une commune ou d’un dépar- tement au Bénin par coordonnées géographiques). La composante sémantique quant à elle représente l’information relative à la nature, l’aspect et les propriétés descriptives d’un objet ou à un phénomène du monde terrestre (département ou une commune du Bénin est défi- nie par un nom : Littoral, sa population, etc.).

A l’intérieur des SIG, les données géographiques, organisées sous forme de couches, sont mémorisées selon deux différents modèles : les modèles vectoriel et matriciel (Bédard, 2008). Un SIG permet d’ac- quérir, d’archiver, d’analyser et d’afficher des données géographiques sous forme de carte (Mitchell, 2005). Ce processus est appelé analyse spatiale de données.

(37)

1.3 Les systèmes d’information décisionnels

Un système d’information décisionnel (SID) constitue un regrou- pement de données orientées vers certains sujets, intégrées, dépen- dantes du temps, non volatiles, pour supporter le processus de prise de décision d’une organisation (Inmon, 1996). Il se base sur l’informatique décisionnelle, aussi nommée Business Intelligence (BI). Il ré- pond aux problématiques posées par le croisement de données hé- térogènes, déstructurées et éparses rencontrées dans les différents systèmes d’information des entreprises (Tranchant, 2011). Or, l’une des plus grandes richesses d’une société, étant justement ces informations, le fait de pouvoir les synthétiser afin de dégager les grandes tendances d’évolution de son métier donne un avantage concurrentiel important à toute entreprise ayant mis en place ce genre de structure.

S’adressant principalement aux dirigeants, il n’a d’autre finalité que de délivrer des informations pertinentes afin de leur permettre une bonne prise de décision.

Cette discipline a connu un essor particulier dans les années 90, avec la création d’environnements spécialisés dans l’aide à la déci- sion, ainsi qu’avec l’arrivée à maturité des algorithmes permettant l’extraction d’informations à partir de données brutes. Ces algorithmes proviennent du monde de la statistique et de la recherche dans le domaine de l’Intelligence Artificielle (IA). Ce système repose sur une architecture dont les bases théoriques viennent principalement des pères des entrepôts de données Ralph Kimball et Bill Inmon (Hüse- mann et al., 2000).

L’architecture d’un système décisionnel (figure 1.11) est organisée comme une chaîne : localisation des données sources ; extraction, nettoyage, transformation et chargement dans un entrepôt ; interroga- tion des bases de données (back-room), mise sous forme multidimensionnelle ; et enfin, service à des outils d’analyse ou de fouille (front-

(38)

room).

Figure1.11 – Architecture des systèmes décisionnels (Source : (Lebrun et Charrier, 2008))

1.3.1 La couche de préparation de données : back-room

La couche de préparation de données (figure 1.12) est constituée de sources de données et des outils d’extraction, transformation et chargement de données dans l’entrepôt (ETL). Les différents services d’une ville utilisent plusieurs programmes, chacun ayant systémati- quement un stockage de données (base de données relationnelle, fichier XML (eXtended Markup Language), format propriétaire, etc.).

Hétérogènes, dispersées, difficiles à atteindre, ces informations sont cependant d’une importance capitale pour le système décisionnel.

Leur acquisition par les outils ETL est la source de nombreux amé- nagements dans le système d’information : changement d’encodage, ouverture de liens d’accès aux SGBD, adaptation du réseau et mise en place d’authentifications (Tranchant, 2011). Les ETL assurent l’extraction, la transformation (filtrage, formatage, dénormalisation, agré-

(39)

gation ou désagrégation, etc.) puis le chargement de données dans l’entrepôt.

Figure1.12 – Couche de préparation de données (back-room) (Source : (Lebrun et Charrier, 2008))

1.3.2 La couche de stockage de données

La couche de stockage de données (figure 1.13) stocke l’ensemble des informations issues des différentes sources de données dans un entrepôt de données. Les données sont atomiques et agrégées au niveau de cette couche. Il s’agit d’une source unique de données à tous les utilisateurs, peu importe l’emplacement physique des don- nées. Cette couche fournit un accès simplifié et rapide aux données pour les utilisateurs (requêtes ad hoc par exemple) et applications de BI.

1.3.3 La couche de restitution de données front-room

La couche de restitution de données (figure 1.14) offre des interfaces d’accès simplifié aux données. Elle est constituée de différents outils d’analyse supportant les besoins analytiques des utilisateurs :

(40)

Figure1.13 – Couhe de stockage de données (Source : (Lebrun et Charrier, 2008))

rapport, analyse en ligne, fouille de données, etc.. Elle permet de gé- rer les requêtes des utilisateurs (reformulation/optimisation, redirec- tion vers la bonne ressource informationnelle, navigation d’agrégation, gestion de priorité). Elle gère aussi la sécurité, les accès et permet le monitoring d’utilisation.

Figure 1.14 – Couhe de restitution de données (front-room) (Source : (Lebrun et Charrier, 2008))

(41)

L’analyse en ligne ou OnLine Analytical Processing (OLAP) désigne une technologie d’analyse qui fait appel à une vue multidimensionnelle de données agrégées pour offrir un accès rapide à des informations stratégiques, à des fins d’analyses évoluées (Blascka et al., 1998). Elle permet de faire une analyse des données conforme au paradigme multidimensionnel avec des temps de réponse très optimi- sés à travers des opérateurs OLAP (opérateurs de forage drill-down et roll-up, les opérateurs de coupe slicing, dicing, rotate ou pivot) traduits en requêtes multidimensionnelles ou requêtes MDX (MultiDimensio- nal eXpression).

Le datamining ou fouille de données est un processus d’analyse qui permet à des décideurs d’aller plus loin que la simple description des comportements passés d’un élément et de faire des prédictions (Tranchant, 2011). Il permet de déceler les comportements « mys- térieux » des différents éléments d’un système et les règles qui les sous-tendent (Kimball, 2001). Grâce à ces découvertes, il est pos- sible d’anticiper, de prendre des décisions préalables sur le compor- tement d’un fait. Les différentes techniques pour effectuer cette fouille de données sont : le machine learning, la statistique, les réseaux de neurones, etc. (Inmon, 1996).

Sur le marché du décisionnel, il existe plusieurs outils permettant de faire de l’OLAP. On peut citer entre autres : les clients OLAP JPi- vot², IcCube³, JRubik⁴, etc.. Ces différents clients OLAP offrent des fonctionnalités de base de navigation dans l’entrepôt de données.

Pour le datamining on peut citer l’outil fouille de données Weka⁵, le langage R⁶.

2. JPivot : http ://jpivot.sourceforge.com 3. IcCube : http ://www.iccube.com 4. JRubik : http ://jrubik.sourceforge.com 5. Weka : http ://www.wakaito.com 6. R : http ://rdatamining.com

(42)

CHAPITRE

LES SYSTEMES D’INFORMATION URBAINS 2

EXISTANTS

La décentralisation, le développement et l’essor des différents secteurs d’activités des différentes villes du monde en particulier les villes du tiers-monde ont amené celles-ci à procéder à une gestion autonome et complète de ses différentes ressources et activités (Adéd- jouma et Houndji, 2012). Afin de faciliter cette gestion, des systèmes d’information urbains ont été réalisés. Nous présenterons dans ce chapitre les systèmes d’information urbains existants. Nous mettrons beaucoup plus l’accent sur les projets qui ont abouti à des systèmes d’information visant à faciliter l’aide à la décision dans les villes en voie de développement. Ces travaux sont entre autres le SMURF, le SIT et le SAGU.

2.1 Le Système de Monitoring Urbain Fonctionnel (SMURF)

Les problématiques de développement des pays en développe- ment sont très différentes de celles des pays du tiers-monde, de même

(43)

que les moyens alloués à la gestion des différentes villes (Repetti, 2004).

Ayant observé l’étendue des besoins des pays en développement, l’ONG ENDA-tm (Organisation Non Gouvernementale Environnement et Développement du tiers monde) en partenariat avec l’EPFL (Ecole Polytechnique Fédérale de Lausanne) a développé un SIU pour renforcer la gestion urbaine dans les villes en développement (Repetti, 2004) : le Système de Monitoring Urbain Fonctionnel (SMURF). Il a été appliqué à la ville de Thiès et Saint Louis (Sénégal), Nakuru (Ke- nya), Bobo-Dioulasso (Burkina-Faso) (Repetti, 2004).

Le SMURF, également nommé Moniteur Urbain, est une plateforme d’échange d’information, permettant d’accéder à l’ensemble de don- nées et d’indicateurs sur le développement de la ville. Pour ses utilisateurs, il se présente sous la forme d’un observatoire urbain informatisé qui leur permet d’interagir avec une base de données. Cet outil offre des fonctionnalités de consultation, de saisie et de modification de l’information sur l’ensemble des indicateurs urbains (Repetti, 2004). Il a la particularité d’être adapté aux besoins des acteurs urbains : simplicité d’utilisation, structure de données élaborée pour la gestion urbaine et ensemble d’indicateurs pour le monitoring et l’aide à la décision.

La base de données contient des données statistiques et à référence spatiale. Elle est structurée de façon à stocker d’une part les don- nées territoriales utiles à la gestion et d’autre part des informations sur les projets des différents acteurs, qu’ils soient en cours d’élabora- tion ou d’exécution. Le SMURF permet de saisir les données et de les consulter. Il possède également une composante d’analyse spatiale et statistique qui calcule dynamiquement les indicateurs à partir de la base de données (Repetti, 2004). Le premier prototype a été mis en place dans la ville de Thiès (Sénégal) en 2000, une réplication a été faite à Nakuru (Kenya), à Saint Louis (Sénégal) et à Bobo-Dioulasso

(44)

(Burkina-Faso).

Cependant, cet outil a quelques faiblesses qu’il est important de souligner :

– le SMURF n’est pas multi plateforme. En effet, développé avec Visual Basic, il ne peut fonctionner que sous les systèmes d’exploitation de Microsoft. Dans un contexte de pays en développe- ment, cela peut constituer un handicap à l’acquisition du logiciel.

Les gestionnaires des villes devront alors être obligés d’acheter le système d’exploitation et tous les logiciels payants venant avec (Adédjouma et Houndji, 2012) ;

– le logiciel n’intègre pas l’aspect réseau. La gestion du réseau est limitée à une gestion physique. Il s’agit d’une part de mettre les copies de la base de données à la disposition des acteurs et, d’autre part, de copier les fichiers de mise à jour au niveau des machines des utilisateurs (Repetti, 2004). Ces mises à jour sont intégrées à la base de données de référence et par la suite à la base de données de tous les autres utilisateurs. D’un autre côté, si les versions à venir du SMURF prennent en compte la possi- bilité d’avoir une base de données commune, le même problème va se poser en cas de mise à jour du logiciel lui-même. Il faudra alors le réinstaller partout où il se trouve.

2.2 Le Système d’Information Territoriale (SIT) de la DAT, Bénin

Le SIT est un système d’information qui permet de faire une analyse spatiale du territoire béninois à travers un ensemble d’indicateurs afin de pouvoir apprécier les dynamiques et les disparités spatiales liées à la répartition des hommes, des infrastructures et équipements, des activités en production et des ressources naturelles (DAT, 2011). Il met à la disposition des décideurs à différents niveaux et à différentes

(45)

échelles, des informations spatialisées, pertinentes afin de promou- voir l’aménagement du territoire. Une opération pilote a été réalisée à N’Dali. Elle a été dirigée par un comité technique mise en place suite à l’arrêté ministériel N˚095/MDGLAAT/DC/SG/AT/SA en date du 03 sep- tembre 2010 (DAT, 2011) ; le comité est composé des représentants : – du Ministère de la Décentralisation, de la Gouvernance Locale, de l’Administration et de l’Aménagement du Territoire du Bénin (MDGLAAT) notamment la Direction de Cabinet, la DAT et la Di- rection Générale de la Décentralisation et de la Gouvernance Lo- cale ;

– du Ministère d’Etat Chargé de la Prospective, du Développement et de l’Evaluation de l’Action Publique (MECPDEAP) du Bénin notamment la Direction du Développement à la Base ;

– de l’Institut National de la Statistique et de l’Analyse Economique (INSAE) ;

– de l’Association Nationale des Communes du Bénin (ANCB).

Le comité a retenu un nombre raisonnable et réaliste d’indicateurs de plusieurs secteurs d’activité (DAT, 2011). Des bases de données ont été conçues pour le stockage de ces indicateurs. Ils sont ensuite traités et restitués sous forme de tableau de bord, de graphe et répartis sur la carte géographique de la commune. L’alimentation de la base de données est faite soit à travers l’importation des don- nées des formats de fichier Excel ou soit par un enregistrement direct (DAT, 2011). Une fois la phase expérimentale terminée, un déploie- ment dans les autres communes du Bénin est envisagé ainsi que la constitution d’une base de données départementale pour abriter les données au niveau départemental ainsi que la mise en place d’une base de données nationale (DAT, 2011). Cet outil est actuellement en phase d’expérimentation dans différentes communes du Bénin (Para-

(46)

kou, N’Dali, Tchaourou).

Néanmoins, ce système a quelques insuffisances :

– les données sont manipulées depuis des bases de données hé- térogènes, le système exécute du coup de multitudes actions avant de restituer le résultat d’une d’analyse de données. Des problèmes de lenteur sont relevés ;

– l’outil est réalisé par la technologie DotNET de Microsoft. Il né- cessite des logiciels propriétaires. Tout comme le SMURF, il peut engendrer des problèmes d’acquisition surtout pour les pays en voie de développement.

2.3 Le Système d’Aide à la Gestion Urbaine (SAGU)

Le SAGU est un observatoire urbain réalisé par Adédjouma S.A. et Houndji V.R.E. en 2012. Il a été testé sur la ville de Porto-Novo, Bé- nin. Il s’agit d’une application web accessible de n’importe quel endroit assurant le stockage et la gestion des données ainsi que la production et la restitution d’informations utiles. Le SAGU permet le stockage des indicateurs liés aux secteurs d’activité de la ville dans une base de données. Il offre des fonctionnalités de consultation, de stockage et de modification des indicateurs. Il offre plusieurs interfaces d’ac- cès allant de la simple consultation (pour un citoyen quelconque de la ville) à l’analyse plus poussée pour le service de planification de la ville). La consultation d’un indicateur est présentée sous forme tabulaire (tableau avec les différentes valeurs de l’indicateur suivant des critères définis par l’utilisateur), sous forme graphique (histogramme, camembert, etc.). Il est adapté aux besoins des acteurs urbains : flexi- bilité, accessible à partir de la plupart des systèmes d’exploitation et avec tous les navigateurs web, accessible en ligne, simple d’utilisa-

(47)

tion, mise à jour (Adédjouma et Houndji, 2012).

Les faiblesses majeures de cet outil sont :

– Dans sa version actuelle, le SAGU ne gère pas les aspects géo- graphiques qui peuvent être forts utiles pour une meilleure analyse ;

– Le manque de la fouille de données ou datamining dans ce sys- tème réduit les options d’analyse et d’exploration de données.

La plupart des villes développées possèdent aussi leurs propres systèmes d’information urbains. On peut citer par exemple le Sys- tème d’Information du Territoire Genevois (SITG¹) regroupant les principaux acteurs publics en charge de la gestion du territoire : l’Etat de Genève, les villes et communes genevoises, les services industriels de Genève, l’aéroport international, les transports publics, la fonda- tion pour les terrains industriels, etc. Dans ces pays, les technologies de pointe, les moyens aériens, les images satellitaires, les données météorologiques, la cartographie en temps réel, l’intégration des TIC dans toutes les institutions sont autant d’éléments mis à la disposition des SIU pour leur fonctionnement. Ainsi, les problématiques de développement sont très différentes de celles des pays en dévelop- pement, de même que les moyens alloués à la gestion des différentes villes (Repetti, 2004).

1. http ://etat.geneve.ch/sitg/accueil.html

(48)

Deuxième partie

METHODOLOGIE

(49)

METHODOLOGIE D’ETUDE 3

Le travail réalisé vise à proposer un système d’aide à la prise de décision en milieu urbain. Nous avons proposé un système adapté à l’analyse des processus urbains et basé sur les systèmes d’information décisionnels.

3.1 Méthodologie adoptée

La figure 3.1 présente l’approche méthodologique adoptée pour la réalisation de notre système.

Analyse des besoins : ici l’on évoque globalement les différents besoins qui ont amené à la genèse du projet. Il s’agit d’énumérer les différents problèmes qui existent et auxquels notre système d’information veut apporter des solutions.

Proposition d’une solution : il s’agit de pouvoir dégager à partir de ses besoins un premier prototype du système. Ce prototype fait ressortir le principe de fonctionnement du système et ses différents modules.

Modélisation du système: il s’agit de concevoir les différents mo- dèles du système. Une conception architecturale est premièrement

(50)

Figure3.1 – Méthodologie d’etude de notre système.

requise afin de mettre en œuvre l’architecture des différents modules du système. Ensuite suit une conception détaillée qui explique le fonctionnement des différents blocs du système à travers des machines d’état, des organigrammes des diagrammes et des modèles. Cette étape met en relief le fonctionnement détaillé du système.

Implémentation du système : ici, à partir du modèle du système, il faut faire des choix techniques de réalisation. Il s’agit de choisir les outils qui peuvent permettre d’implémenter les différents blocs du sys- tème (exemple : choix d’un SGBD, choix d’un langage de programma- tion, etc.). A la fin de cette étape, le système est implémenté et peut être testé pour une évaluation de performances.

Tests: il s’agit d’effectuer les différents tests du système. Les tests peuvent être globaux ou unitaires. Un test global permet d’évaluer les performances globales du système alors qu’un test unitaire se focalise sur un module donné du système et évalue sa performance. Ce n’est

(51)

qu’à partir des tests que l’on peut savoir si le système conçu répond aux besoins exprimés par les utilisateurs.

3.2 Définition des besoins

Les villes en République du Bénin (en particulier Porto-Novo) connaissent un problème de gestion des données reflétant les différentes actions menées. Ces données sont dispersées dans des bases de données et dans d’autres sources de données. Ces données hétéro- gènes, et éparses rencontrées dans les différents systèmes d’informations mis en place par plusieurs acteurs de la ville cachent des détails d’informations utiles pour assurer la planification et la gestion de l’ensemble des processus de la ville. Ces bases de données sont souvent liées à un secteur ou à une thématique, et leur degré de précision est assez faible. Le manque d’une base de données organisée et structu- rée regroupant l’ensemble des indicateurs sectoriels pouvant informer les acteurs du développement est un problème majeur.

Ainsi le niveau d’appropriation par les acteurs locaux est très faible, ce qui les amène à délaisser lesdites bases de données peu de temps après leur utilisation. Les différents acteurs de la ville (élus, services techniques municipaux, associations, organisations non gouvernemen- tales et citoyens) sont alors en marge des informations sur les indicateurs urbains.

Les besoins exprimés par ces villes, plus précisément la ville de Porto-Novo, Bénin peuvent se résumer comme suit :

– disposer d’une base de données communale durable et viable de par son dispositif de stockage de données ;

– intégrer dans cette base de données de gros volumes de don- nées réalistes et fiables couvrant tous les secteurs d’activités de la ville ;

(52)

– permettre l’importation dans cette base de données, des don- nées de différentes sources : bases de données opérationnelles, fichier XML, Excel, etc. ;

– spatialiser les données (traduire dans l’espace les données à partir des cartes géographiques de la ville) ;

– disposer d’un outil de visualisation des données de la base de données ;

– visualiser à partir de l’outil, les données sous différentes formes afin de faciliter l’aide à la décision ;

– rendre plus convivial l’outil à travers des interfaces d’utilisation et d’administration assez faciles, souples, attrayantes ;

– permettre une exportation des résultats d’analyse en un format portable pour réutilisation hors application .

Pour répondre à ces besoins, une liste d’indicateurs a été retenue.

Un indicateur est une variable qualitative ou quantitative permettant d’apprécier un phénomène ou une action à partir des objectifs, expri- més sous forme de valeurs normatives ou comparatives (Turki, 2010).

C’est aussi une variable utilisée pour montrer l’état d’un système, un modèle qui simplifie un sujet complexe, réservé aux spécialistes, et le rend facilement accessible et compréhensible par l’opinion publique (Adédjouma et Houndji, 2012). Les indicateurs utilisés dans ce travail ont été retenus avec la Mairie de Porto-Novo, Bénin à travers sa Di- rection de la Prospective du Développement et de la Coopération. Ils se rapprochent de ceux du SAGU et du SMURF. Le choix de ces indicateurs nous permettra d’apporter une véritable solution aux besoins exprimés en se basant sur des données fiables et raisonnables étant donné qu’elles touchent presque tous les aspects de développement des villes : éducation, santé, démographie, eau potable, assainisse- ment, habitat, route, etc.. Le tableau III.I présente un extrait de la liste de ces différents indicateurs. (cf annexe A pour la liste complète).

(53)

TableauIII.I – Extrait de la liste des indicateurs retenus Catégories Indicateurs Détails

Démographie

Densité de la population

Nombre d’habitants évalué par kilomètre carré exprimé en habitants/km²

Taux de pauvreté

Nombre d’habitants dont les revenus sont en dessous d’un seuil défini comme seuil de pauvreté (1 dollar)

Education Nombre moyen d’élèves par enseignant

Nombre moyen d’élèves par enseignant par école, par quartier, par arrondissement et dans la commune exprimé en élèves/enseignant

Taux d’alphabéti- sation

Proportion de personnes lettrées par quartier, par arrondissement et dans la commune exprimée en pourcentage

Santé Nombre de

centres de santé

Nombre total de cliniques, dispensaires, maternités, centres d’hospitalisation, etc.

par quartier, par arrondissement et dans la commune

Mortalité infantile

Proportion d’enfants d’âge compris entre 0 et 1 an, mort sur le nombre total d’enfants d’âge compris en 0 et 1 an exprimé en pourcentage

3.3 Présentation de notre proposition

A la connaissance de ces besoins, nous avons étudié puis proposé une solution basée sur les systèmes d’information décisionnels et en- globant les contraintes exprimées.

3.3.1 Vue globale

Notre projet consiste à la mise en place d’un système décisionnel, la conception de l’entrepôt de données en passant par la préparation et l’intégration des données dans l’entrepôt ; à la mise en place d’une couche de restitution des données. Cette couche se chargera de faire de l’analyse OLAP et du reporting sur l’entrepôt. En découlent trois grandes tâches à réaliser.

Tout d’abord, nous allons modéliser et mettre en place un entrepôt

(54)

de données stockant les informations issues de différentes sources de données. Ensuite, nous allons mettre en place une interface pour interroger l’entrepôt via OLAP afin d’effectuer des analyses et du reporting. Enfin, nous allons proposer une architecture physique de dé- ploiement pour la mise en œuvre réelle du système.

3.3.2 Architecture métier de notre proposition

L’architecture métier fait ressortir les différents éléments de notre système, leurs interrelations et leurs interactions. Deux options d’architecture métier sont possibles (figure 3.2).

Figure3.2 – Deux architectures métiers possibles : « client serveur » (en haut) et « n tiers » (en bas)

Dans la première architecture (appelée « client-serveur », en haut sur la figure 3.2), le client se connecte à un serveur OLAP à partir d’une application embarquée à son niveau. Cette application interroge d’elle-même le serveur OLAP et interprète les résultats qui lui sont envoyés par ce serveur. Le client est autonome et embarque tout le