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 produc-tion et la restituproduc-tion d’informaproduc-tions 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 tabu-laire (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-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 ana-lyse ;

– 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 prin-cipaux 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 disposi-tion des SIU pour leur foncdisposi-tionnement. 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

Deuxième partie

METHODOLOGIE

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’informa-tion 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’informa-tion veut apporter des solud’informa-tions.

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

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

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 fonc-tionnement 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

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) con-naissent 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’informa-tions 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’en-semble 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 indica-teurs 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 ;

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

– permettre l’importation dans cette base de données, des don-nées de différentes sources : bases de dondon-né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 indi-cateurs 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).

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

Démographie

Densité de la po-pulation

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 en-seignant

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

Taux d’alphabéti-sation

Proportion de personnes lettrées par quar-tier, par arrondissement et dans la com-mune 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’en-fants 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

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

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 re-porting. 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’ar-chitecture 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

processus de traitement, de communication avec le serveur OLAP.

La seconde option (en bas figure 3.2) constitue un client léger, qui se connecte à une couche intermédiaire de type intergiciel. Ce client ne fait qu’afficher les résultats au niveau de l’utilisateur. Il envoie un ensemble de requêtes générées à l’issue des différents choix de l’utili-sateur à une première couche. Cette couche communique avec le ser-veur OLAP qui interagit à son tour avec l’entrepôt. Il s’agit d’une archi-tecture n tiers. Cette approche permet de définir clairement les rôles des différents éléments : le serveur OLAP se charge de la couche d’accès aux données (gestion de la persistance) et l’intergiciel du trai-tement métier (traitrai-tement et transformation éventuelle des données).

Le client, quant à lui, permet la présentation et l’interaction entre l’uti-lisateur et les autres couches.

Nous avons opté pour la deuxième solution pour plusieurs raisons.

Tout d’abord, il est inutile, dans cette configuration, d’installer quoi que ce soit sur le poste de l’utilisateur final : il n’a besoin que d’un naviga-teur web afin d’accéder au serveur en ligne. Ensuite, la partie métier n’est traitée que par un serveur dédié. Il n’y a pas de dispersion ni de mélange dans les couches applicatives.

3.3.3 Fonctionnement global

Le fonctionnement global de notre solution est identique au fonc-tionnement d’un système d’information décisionnel (voir section 1.3).

La figure 3.3 illustre le fonctionnement global des différents éléments constitutifs de notre projet lorsqu’un utilisateur exploite le système.

Les utilisateurs du système sont essentiellement des agents gestion-naires de la municipalité de la ville.

Ces utilisateurs accèdent au système via une application web hé-bergée sur un serveur d’application. A partir de cette application, ils définissent les différents paramètres de l’analyse. Ensuite le serveur

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

Figure3.3 – Principe de fonctionnement global de notre système

d’application traduit les demandes en requêtes multidimensionnelles et en requêtes spatiales si leurs demandes font intervenir les cartes.

Ces requêtes sont envoyées vers un serveur d’analyse. Ce dernier en liaison directe avec l’entrepôt de données, traduit les différentes requêtes en requêtes SQL qu’il exécute sur l’entrepôt. L’entrepôt re-groupe des données structurées et homogènes issues des différentes sources de données existantes. Ces données passent par le proces-sus d’ETL pour être intégrées dans l’entrepôt. Une fois la requête SQL exécutée, un résultat est retourné au serveur d’analyse. À son tour, le serveur d’analyse renvoie le résultat au serveur d’application. Le ser-veur d’application affiche aux utilisateurs les résultats de sa demande d’analyse sous différentes formes : tableau, graphe (histogramme, ca-membert) et carte à travers l’application web de visualisation.

MODELISATION DU SYSTEME 4

Ce chapitre a pour objectif de présenter les modèles mis en œuvre pour concevoir notre entrepôt, pour y intégrer les données et réaliser l’outil de visualisation.

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

Les besoins exprimés dans le chapitre précédent nous ont ame-nés à définir un ensemble d’indicateurs. Ces indicateurs doivent être stockés dans un entrepôt de données.

Au chapitre 1, les concepts de dimensions hiérarchiques, de membre et de mesures ont été présentés. Cette section présentera l’approche conceptuelle adoptée pour notre entrepôt, ensuite nous dresserons les dimensions et les tables de faits potentiels de l’entrepôt, ainsi que leur modèle d’organisation, enfin nous présenterons le modèle phy-sique de stockage des données dans l’entrepôt.

4.1.1 Approche conceptuelle de l’entrepôt

Les indicateurs permettent de mesurer, d’indiquer, de montrer ou d’attirer l’attention (avec plus ou moins d’exactitude) des différents

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

teurs de la ville sur l’ensemble des secteurs d’activité de développe-ment.

La conception de l’entrepôt doit prendre en compte non seulement les différentes sources de données de ces indicateurs, mais aussi les différentes analyses à effectuer par les acteurs de la ville. En effet, ces sources de données sont indispensables et constituent la porte d’en-trée de notre entrepôt. Parallèlement, il faut aussi considérer les diffé-rentes analyses à faire par les utilisateurs du système afin de pouvoir adapter l’entrepôt aux exigences des utilisateurs. Il serait inutile d’in-tégrer dans l’entrepôt, des données qui n’intéressent pas les acteurs de la ville ou qui n’apportent aucun apport à la prise de décision de la ville.

Pour cela, l’entrepôt sera conçu suivant une approche de concep-tion « mixte ».

4.1.2 Modélisation multidimensionnelle de l’entrepôt de données La modélisation multidimensionnelle de l’entrepôt du système com-mence d’abord par la définition des différentes dimensions ou diffé-rents axes d’analyse, des différentes mesures à estimer. Ensuite, suit le modèle logique formé par ces dimensions et ces différentes me-sures regroupées dans une ou plusieurs tables de faits.

Les indicateurs constituent le lien commun entre les besoins d’ana-lyse des acteurs de la ville et les sources de données. Ces différents acteurs ont besoin d’évaluer les différentes valeurs prises par ces in-dicateurs afin de pouvoir prendre différentes décisions.

La mesure principale à évaluer par notre système constitue la va-leur exacte de chacun des indicateurs au niveau de la ville. Cette me-sure est, soit un nombre (ex : 100000 d’habitants pour l’indicateur « Nombre d’habitants ») ou une proportion (exemple : 15.8% pour

l’indi-cateur « Taux de scolarisation »). Cette valeur est relative à un temps donné et à une région. Ainsi à un instant t et à une région r correspond une valeur d’un indicateur.

A partir de là, nous dégageons deux principales dimensions : la dimension « indicateur » dont chaque membre équivaut à chacun de nos indicateurs, la dimension « temps » dont chaque membre cor-respond à une période donnée (année) et une dimension « muette

» : la dimension « region » ; elle est dite « muette » ici parce qu’elle ne possède qu’un seul niveau à un membre (la ville) ; et un fait « fait_indicateur » qui a pour mesure la valeur de l’indicateur.

A ce stade, nous pouvons déjà établir un premier modèle dimen-sionnel potentiel de données basé sur un modèle en étoile de l’ap-proche ROLAP (figure 4.1).

Figure4.1 – Modèle en étoile potentiel de l’entrepôt

La définition de la granularité de notre entrepôt est une phase très importante de la modélisation. En effet avec le modèle de la figure 4.1, la granularité de la mesure est arrêtée au niveau "année" pour la dimension « temps » et au niveau "ville" pour la dimension « région

». De plus, il est intéressant pour une bonne précision d’analyse de s’intéresser aux différentes valeurs de ces indicateurs au sein des différentes entités de la ville. Cela nous amène à décomposer la ville entière en ses différents arrondissements et ceux-ci en quartiers. Pour certains indicateurs il faut aller encore plus en profondeur, c’est-à-dire

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

passer du quartier aux différentes structures du quartier (école, centre de santé, point d’approvisionnement d’eau, marché, etc.) qui ont un rapport avec l’indicateur. Par exemple, le « Taux de scolarisation » peut est évalué pour une école d’un quartier, la « Mortalité infantile » peut est évaluée pour un centre de santé situé dans un quartier, etc..

La figure 4.2 présente la granularité de l’entrepôt. L’entrepôt est de granularité 4.

Figure4.2 – Différents niveaux de granularité des indicateurs suivant la dimension

« region »

Aussi, chaque indicateur appartient à un secteur ou une catégo-rie donnée (exemple : « Taux de scolarisation » appartient au secteur

« Éducation » , « Mortalité infantile » appartient au secteur « Santé

»). Certains indicateurs peuvent être définis par des valeurs journa-lières (« Quantité de déchets produits », « Taux de déchets éliminés

», « Consommation en eau potable », etc.), d’autres par valeurs men-suelles (« Croissance démographique », « Nombre d’habitants par tranche d’âge », « Lits d’hôpital disponibles », etc.) et d’autres par an (« Mortalité infantile », « Taux d’alphabétisation » par exemple). Ces choix dépendent du degré de précision d’analyse défini par ces diffé-rents indicateurs. L’entrepôt de données doit répondre à ces attentes, et stocker la valeur de tous ces indicateurs, peu importe le type (jour-nalier, hebdomadaire, mensuel, annuel, etc.). Cette valeur doit pouvoir être affichée à l’utilisateur lors d’une analyse avec les détails de la pé-riode correspondante.

Vu tout cela, tout d’abord la dimension « region » doit être décom-posée en sous-hiérarchies « arrondissement », « quartier » et «

struc-ture ». Chacune de ces sous-hiérarchies devient une nouvelle dimen-sion. De plus, une autre nouvelle dimension apparait dans le modèle, la dimension « domaine ». Cette dimension permettra de parcourir les indicateurs de manière descendante c’est-à-dire du domaine de l’indicateur à l’indicateur lui-même. Par exemple, le choix du domaine Ecole permet de ressortir tous les indicateurs de ce domaine (« Taux d’alphabétisation », « Taux de scolarité brut », etc.). Il est donc im-portant dans le modèle que « domaine » soit une dimension à part au lieu d’être un niveau de la dimension « indicateur ». Enfin, la dé-finition de certains indicateurs amène à conserver les données selon diverses fréquences. Par rapport à la dimension temporelle, il contient 3 différents niveaux : « jour », « mois » « an » . Pour les données jour-nalières, ces niveaux doivent définir le jour (jour/mois/année), quant aux données mensuelles seuls les niveaux mois et an doivent être renseignés, ainsi de suite. Notre modèle ne permet pas de stocker

struc-ture ». Chacune de ces sous-hiérarchies devient une nouvelle dimen-sion. De plus, une autre nouvelle dimension apparait dans le modèle, la dimension « domaine ». Cette dimension permettra de parcourir les indicateurs de manière descendante c’est-à-dire du domaine de l’indicateur à l’indicateur lui-même. Par exemple, le choix du domaine Ecole permet de ressortir tous les indicateurs de ce domaine (« Taux d’alphabétisation », « Taux de scolarité brut », etc.). Il est donc im-portant dans le modèle que « domaine » soit une dimension à part au lieu d’être un niveau de la dimension « indicateur ». Enfin, la dé-finition de certains indicateurs amène à conserver les données selon diverses fréquences. Par rapport à la dimension temporelle, il contient 3 différents niveaux : « jour », « mois » « an » . Pour les données jour-nalières, ces niveaux doivent définir le jour (jour/mois/année), quant aux données mensuelles seuls les niveaux mois et an doivent être renseignés, ainsi de suite. Notre modèle ne permet pas de stocker