mise en place d’un système d’information pour la gestion des collectivités locales (openerp...

Mise en place d’un Système d’Information pour la gestion

des collectivités locales (OpenERP 7)

Réalisé par :

M. Mohamed Amine AZAHAF M. Mohammed OMARI

Membres de Jury :

M. Abdellah ZAOUIA (INPT)

M. Amine BAINA (INPT)

M. Abdellatif MEZRIOUI (INPT)

M. Zakaria El KARKARI (Archos Technology)

M. Karim AMRI (Capital Consulting)

Année Universitaire 2013/2014

http://ma.viadeo.com/fr/profile/abdellatif.mezrioui

3 | P a g e

Mohammed OMARI - Mohamed Amine AZAHAF

Mise en place d’un SI pour la gestion des collectivités locales

Dédicace

Je n’écris cette dédicace que parce qu’elle est de coutume. La

gratitude que j’éprouve envers les personnes que je compte remercier, n’est

nullement formulable avec des mots simples.

Je dédie ce travail,

À mes chers parents, M. Houssain AZAHAF et Mme. Fatma Boukdir.

Ils représentent ma principale source d’inspiration et de motivation. Que Dieu

les garde et que Dieu les protège.

À mes frères : Zakaria et Soufiane et à mes sœurs : Asmae et

Maryam.

À mes amis : Ibrahim, Oussama, Dina, Islam, Ilyas, Amine, Ilias, Lamya,

Farouk, Mohamed El Amine, Sarah.

À tous les membres de ma deuxième famille à l’INPT, que je n’ai pas pu

citer, faute d’espace et de feuilles.

À toutes les personnes qui croient en moi.

Mohamed Amine AZAHAF

4 | P a g e



Dédicace

Toutes les lettres ne sauraient trouver les mots qu’il faut.

Tous les mots ne sauraient exprimer la gratitude, l’amour, le respect, la

reconnaissance.

C’est tout simplement que je dédie ce projet de fin d’étude :

A mes parents, qui m'ont comblé de leur soutien et m'ont voué un amour

inconditionnel. Vous êtes pour moi un exemple de courage et de sacrifice

continu. Je vous dois ce que je suis aujourd’hui et ce que je serai demain et je

ferai toujours de mon mieux pour rester votre fierté. Que Dieu, le tout

puissant, vous préserve, vous accorde santé, bonheur, quiétude de l’esprit et

vous protège de tout mal.

A mes adorables frères et sœurs, merci d’être toujours à mes côtés,

par votre présence, par votre amour dévoué et votre tendresse, pour donner

du goût et du sens à ma vie.

A tous mes ami(e)s, pour leurs compréhensions, leurs soutiens, leurs

tendresse. Je vous remercie d’avoir embelli ma vie par de précieux moments

de bonheur. J’espère du fond de mon cœur que vous trouverez dans ce travail

l’expression de mon amour et de mon estime les plus sincères.

Mohammed OMARI

5 | P a g e



Remerciements

Le présent rapport reflète le fruit des efforts conjugués de plusieurs personnes. Il

nous est alors primordial de souligner notre gratitude et notre reconnaissance auprès de

toute autre personne, dont l’intervention au cours de ce projet, a favorisé son

aboutissement.

Nous souhaitons remercier notre encadrant externe, M. Zakaria El KARKARI, pour

nous avoir donné la chance de travailler sur un projet d’une grande envergure, et dont les

directives aussi concises que soient elles nous ont aidé à atteindre ce résultat. Nous

remercions également M. Karim AMRI et M. Ahmed LAHBABI, pour leurs maints conseils

et leçons, pour leur contribution au développement de notre expertise personnelle et

professionnelle.

Nous remercions particulièrement M. Abdellah ZAOUIA, notre professeur de

gestion et notre encadrant interne, pour ses conseils constructifs et son aide précieux.

Nous tenons à remercier M. Amine BAINA et M. Abdellatif MEZRIOUI d’avoir accepté de

faire partie du jury de notre soutenance.

Nous remercions également M. Hassan El ARROUCHI, responsable à la commune

Urbaine de Casablanca, pour nous avoir éclairé la piste de nos recherches dans le

labyrinthe des collectivités locales marocaines.

Nos remerciements s’adressent aussi à l’ensemble du corps professoral de l’INPT,

aux personnels d’Archos Technology, de Capital-Consulting et d’UrbaSoft, ainsi qu’au Jury

qui a accepté de juger notre travail.

Que tous ceux et celles qui ont contribué de prés ou de loin trouvent l’expression de

nos remerciements les plus chaleureux.

Mohammed OMARI &

Mohamed Amine AZAHAF.

6 | P a g e



Résumé

Il est indubitable que les technologies de l’information ont connu un essor

important ces dernières années. Elles ne font plus partie d’un domaine spécifique et

restreint aux connaisseurs de l’informatique, mais elles commencent plutôt à se montrer

comme une composante indispensable de plusieurs secteurs.

La gestion est l’une des disciplines qui ont largement bénéficié de l’évolution

quantitative ainsi que qualitative des technologies de l’information, dans la mesure où la

voluminosité des données et des procédures ne représentent plus un obstacle.

L’informatisation de la gestion a permis d’atteindre des niveaux inédits de rapidité et

d’efficacité.

C’est dans cette optique que s’inscrivent les services apportés par les Progiciels de

Gestion Intégré PGI, communément connus sous le nom Enterprise Resource Planning

ERP. Un progiciel de gestion intégré est « Un progiciel qui intègre les principales

composantes fonctionnelles de l'entreprise : gestion de production, gestion commerciale,

logistique, ressources humaines, comptabilité, contrôle de gestion. À l'aide de ce système

unifié, les utilisateurs de différents métiers travaillent dans un environnement

applicatif identique qui repose sur une base de données unique. Ce modèle permet

d'assurer l’intégrité des données, la non-redondance de l'information, ainsi que

la réduction des temps de traitement. ». Le point fort incontournable des ERP est l’unicité

de la base de données. Cet avantage permet de grouper les multiples services de la même

entité dans une même applicative sans avoir à dupliquer les règles de gestion ni les

données. De ce fait, un PGI peut être facilement considéré comme le socle indispensable

de toute forme de système d’information.

Il est de notoriété publique que le capital majeur des entreprises actuelles, tout

secteur compris, est l’information. Son importance n’est pas un fruit du hasard, dans la

mesure où la grande majorité des entreprises actuelles créent de la valeur en traitant de

l’information. Cette dernière- qui peut être traduite en une donnée, une fois un traitement

bien déterminé est effectué dessus- représente une composante indispensable de la

définition classique d’un système d’information. Ce dernier est souvent défini comme un

ensemble structuré d’éléments et ressources qui peuvent prendre plusieurs formes :

matériel, personnel, logiciels, progiciels, données. Cet ensemble permet généralement le

traitement, la diffusion, la collecte, la gestion et le transport de l’information. Faire le

parallèle avec une collectivité locale ne semble pas être très complexe, dans la mesure où

une commune urbaine n’est qu’une forme spéciale d’entreprise, qui dispose elle aussi d’un

budget, d’objectifs stratégiques, de salariés et bien évidemment de clients. Ces derniers

font la différence : tout citoyen est un client d’une commune urbaine, ce qui alourdit

davantage la responsabilité.

Mots Clés : Technologie de l’information, Collectivité locales, Commune Urbaine, PGI,

ERP.

7 | P a g e



Abstract

There is no doubt that information technology has experienced significant growth in

recent years. They are no longer part of a specific area and restricted to computer geeks,

but they begin to show as an essential component of several sectors.

Management is one of the disciplines that have benefited greatly from the

quantitative and qualitative evolution of information technology, to the extent that the

bulkiness of the data and procedures are no longer an obstacle. The computerization of the

management helped achieve new rates of speed and efficiency.

It is well known that the major capital companies today, all fields included, is

information. Its importance is not a coincidence, given the fact that the vast majority of

companies create value by processing information. The latter-which can be translated into

a data, once a definite treatment is performed over -represents an essential component of

the classic definition of an information system. An information system is often defined as a

structured elements and resources that can take many forms together: equipment,

personnel, software, software packages, data.

This set usually allows the processing, distribution, collection, management and

transport information. Drawing a parallel with a public administration does not seem to be

very complex, since an urban municipality is a special form of enterprises, which also has a

budget, strategic objectives, employees and customers. The latter makes the difference:

every citizen is a potential customer of an urban municipality, which increases the

responsibility.

8 | P a g e



ملخص

لتي يشهد العالم اليوم واقعا جديدا يمتاز بالدينامكية و سرعة التغيير نتيجة الثورات ا

مرت بها تكنولوجيا المعلومات الحديثة فهذه األخيرة أصبحت قطعة مركزية في تطور

.منشاة من المنشآت أيفشل أوفي نجاح أساسياجميع المجاالت و تعتبر عامال

فهاته . بدورها تعتمد في نجاحها و بشكل كبير على النظم المعلوماتية اإلداريةالعملية إن

تلعب دورا رئيسيا في بناء أضحتللبيئة الحاضنة لها و مالئمةاكتر أصبحت األخيرة

قتصادية و االجتماعية تحقيق األهداف اال إلىالمعلومة المساعدة على اتخاذ قرارات ترنو

.المنشودة

و كما هو الحال بالنسبة للشركات الخاصة، تبقى المنشآت اإلدارية و اإلدارة العمومية في

حاجة أكثر من غيرها لمواكبة العصر و بالتالي لتبني إستراتجية تمكنها من وضع أسس

المجتمع و االقتصاد المبني على المعرفة . في هذا الصدد يأتي هذا العمل لترسيخ مكان

تكنولوجيا المعلومات في تعزيز القدرات التنظيمية لإلدارة ألحديثة و التي ال و لن تسعى إال

للتحسين من مستوى خدمتها للمواطنين.

9 | P a g e



Avant-propos

Binôme :

Mohammed OMARI

Mohamed Amine AZAHAF

Intitulé du sujet :

Mise en place d’un Système d’Information pour la gestion des Collectivités

Locales.

Etablissement d’Accueil :

Archos Technology

Adresse : Technopark: route de Nouacer – 7ème étage B.P16428 - 20190

Casablanca – Maroc

Tel : +212 (0)5 22 50 60 36 Fax : +212 (0)5 22 50 61 43

Encadrant dans l’organisme d’accueil :

M. Zakaria El Karkari, Directeur de Projets.

Encadrant à l’INPT :

M. Abdelah Zaouia, Professeur à l’INPT.

Date de début et de fin du stage :

17 Février au 17 Juin 2014.

10 | P a g e



Liste des Abréviations

Abréviation Désignation

PGI Progiciel de Gestion Intégré

ERP Enterprise Resource Planning

SICL Système d’Information pour la gestion des Collectivités Locales

DGCL Direction General des Collectivité Locales

CU Commune Urbaine

CR Commune Rurale

CL Collectivité Locale

SI Système d’Information

UML Unified Modeling Language

RUP Rational Unified Process

XP eXtreme Programming

XML eXtended Markup Language

SGBDRO Système de Gestion de Base de Données Relationnelle et Objet

SQL Structured Query Language

TMA Tierce Maintenance Applicative

TRA Tierce Recette Applicative

MVC Modèle Vue Contrôleur

ORM Object Relational Mapping

SLA Service Level Management

GTK The Gimp ToolKit

11 | P a g e



Liste des figures

Figure 1: logo Archos-Technology ................................................................................... 18

Figure 2: logo Capital Consulting Group ......................................................................... 18

Figure 3: Les 6 Business-Units d’Archos Technology ...................................................... 19

Figure 4: Les trois leviers de la stratégie de croissance d’Archos-Technology ............... 20

Figure 5: références d’Archos-Technology ..................................................................... 21

Figure 6: découpage administratif du royaume .............................................................. 24

Figure 7: CU de Casablanca ............................................................................................. 26

Figure 8: CU de Kenitra.................................................................................................... 27

Figure 9: Organigramme de la CU de Kenitra ................................................................. 29

Figure10: Organigramme de la Division Urbanisme ....................................................... 30

Figure10bis: Organigramme de la Division Affaires Juridiques et Administratives ........ 30

Figure12: Découpage du projet en phases ..................................................................... 34

Figure 13: Prototypage .................................................................................................... 37

Figure 14: Avantages du prototypage ............................................................................. 38

Figure 15: Rôles et Responsabilités ................................................................................. 39

Figure 16: Structure du Projet ......................................................................................... 40

Figure 17: Cartographie SI ............................................................................................... 43

Figure 18: Publipostage ................................................................................................... 46

Figure 19: logo d’OpenMairie ......................................................................................... 48

Figure 20: Couverture Fonctionnelle du Projet Open Marie .......................................... 49

Figure 21: Etude Comparative des ERP Open Source ..................................................... 50

Figure 22: logo d’OpenERP .............................................................................................. 51

Figure 23: Architecture d'OpenERP ................................................................................. 53

Figure 24: Postgre SQL .................................................................................................... 59

Figure 25: ETL .................................................................................................................. 59

Figure 26: logo de Pentaho ............................................................................................. 60

Figure 27: Processus de génération de rapport .............................................................. 61

Figure 28: logo d’OpenOffice .......................................................................................... 62

12 | P a g e



Figure 29: logo d’Apache OpenOffice ............................................................................. 62

Figure 30: logo de Python .............................................................................................. 63

Figure 31: XML ................................................................................................................. 64

Figure 32: logo Urbasoft .................................................................................................. 65

Figure 33: Architecture du système unifié ...................................................................... 66

Figure 34: Architecture technique proposée .................................................................. 67

Figure 35: Ecran d’accueil................................................................................................ 69

Figure 36: Le module Massira-Urbanisme ...................................................................... 70

Figure 37: Liste des Enregistrements .............................................................................. 70

Figure 38: Filtre et option de recherche ......................................................................... 71

Figure 39: Renseignement sur la Personne Physique ..................................................... 71

Figure 40: Renseignement sur la Personne Morale ........................................................ 72

Figure 41: Formulaire pétitionnaire ................................................................................ 72

Figure 42: Formulaire de la demande d’autorisation ..................................................... 73

Figure 43: Check List Dynamique-PP ............................................................................... 73

Figure 44: Check List Dynamique-GP .............................................................................. 74

Figure 45: Récépissé de demande d’autorisation de Construction ................................ 75

Figure 46: Formulaire Taxation ....................................................................................... 76

Figure 47: Fiche de taxation ............................................................................................ 77

Figure 48: Permis d’habiter ............................................................................................. 78

Figure 49: Fiche Permis d’habiter ................................................................................... 78

Figure 50 Lien vers Google Maps .................................................................................... 79

Figure 51: Localisation de la Parcelle Terrestre .............................................................. 79

Figure 52: Tableau de Bord ............................................................................................. 80

Figure 53: Jeux de test ..................................................................................................... 81

Figure 54: Lancement de l installation ............................................................................ 96

Figure 55: Lancement de l’installation de PostgreSQL. .................................................. 97

Figure 56: Fin de l’installation ......................................................................................... 97

Figure 57: Utilitaire de contrôle des services .................................................................. 98

13 | P a g e



Figure 58: Serveur OpenERP ........................................................................................... 98

Figure 59: Plug-in OpenOffice Report Designer ............................................................ 100

Figure 60: La fenêtre de «extension Manager » après installation du Plug-in ............. 101

Figure 61: Connexion vers le serveur & puis vers la Base de données ......................... 101

Figure 62 : Sélection du modèle dans la base de données ........................................... 102

Figure 63 : Envoie du rapport au serveur OpenERP ...................................................... 102

Figure 64: Création de rapport à l’aide des fonctions .................................................. 103

Diagrammes :

Diagramme 1 : Diagramme de GANTT ............................................................................ 38

Diagramme 2: Processus Métier de la division Urbanisme ............................................ 44

Diagramme 3: Processus Métier du service PA .............................................................. 45

Diagramme 4: Diagramme de cas d’utilisation ............................................................... 57

Diagramme 5: Diagramme de classes ............................................................................. 58

Tableaux :

Tableau 1: Matrice SWOT OpenERP ................................................................................ 52

Tableau 2: Moteurs de rapport OpenERP ....................................................................... 61

Tableau 3: Documents à fournir ...................................................................................... 92

14 | P a g e



Sommaire

Dédicace ........................................................................................................................................ 3

Dédicace ........................................................................................................................................ 4

Remerciements ............................................................................................................................. 5

Résumé .......................................................................................................................................... 6

Abstract ........................................................................................................................................ 7

8 ............................................................................................................................................. ملخص

Avant-propos ................................................................................................................................. 9

Liste des abréviations .................................................................................................................. 10

Liste des figures ........................................................................................................................... 11

Sommaire .................................................................................................................................... 14

Introduction générale .................................................................................................................. 15

Première partie ........................................................................................................................... 16

Chapitre 1 : Présentation de l’organisme d’accueil .......................................................... 17

Chapitre 2 : Présentation du cadre général du projet ...................................................... 22

Deuxième partie .......................................................................................................................... 42

Chapitre 3 : Analyse fonctionnelle .................................................................................... 43

Chapitre 4 : Analyse et réalisation technique ................................................................... 48

Chapitre 5 : Installation et simulation ............................................................................... 70

Conclusion générale .................................................................................................................... 84

Bibliographie ............................................................................................................................... 85

Table des matières ...................................................................................................................... 86

Annexes ....................................................................................................................................... 90

Annexe 1 ........................................................................................................................... 91

Annexe 2 ........................................................................................................................... 93

Annexe3 ............................................................................................................................ 95

Annexe4 .......................................................................................................................... 101

15 | P a g e



Introduction générale

Le présent rapport est l’aboutissement d’un stage de fin d’études d’une durée de

quatre mois et d’un dévouement complet au projet pilote lancé par Archos Technology

filiale à 100% de Capital Consulting Group. Notre projet de fin d’études est le

couronnement d’un cursus universitaire de trois années au sein de l’Institut National des

Postes et Télécommunications, un cursus qui sera sanctionné par un diplôme d’Ingénieur

d’Etat en systèmes d’information.

L’évolution démographique galopante des villes, la politique de modernisation des

services publics et le développement durable des villes marocaines, sont tous des facteurs

qui font en sorte que ce projet soit une avancée inédite dans le domaine des systèmes

d’information au Maroc. Contrairement aux communes urbaines françaises qui sont dotées

de systèmes d’information communaux aidant à la gestion de la majorité écrasante des

activités, les communes marocaines se montrent encore incapables d’atteindre ce niveau de

maturité, dorénavant considéré dans les pays développés comme standard. C’est dans ce

cadre que figure l’objectif principal du projet, qui est la mise en place d’un système

d’information aidant à la gestion des collectivités locales marocaines. Etant donné que la

commune urbaine de Kenitra est le client pilote, des ateliers de définition du besoin ont été

organisés dans le dessein de mieux cadrer l’évolution du projet.

Notre système d’information est à base du progiciel de gestion intégré de licence

libre OpenERP 7. Ce dernier présente un environnement et un Framework propices pour

développer des nouveaux modules répondant à des besoins spécifiques, des besoins qui

n’ont pas été pris en compte par les modules OpenERP par défaut.

A travers ce rapport nous allons essayer de mettre en exergue le chemin suivi pour la

mise en place d’un système d’information pour la gestion des communes urbaines

marocaines. La première partie comporte une présentation de l’organisme d’accueil, un

descriptif détaillé du contexte du projet et de ses enjeux ainsi que l’environnement du

travail. Elle décrit la nature et l’activité du client final, à savoir la commune urbaine

marocaine, ainsi que les enjeux stratégiques impliqués dans ce projet pilote à multiples

dimensions.

Quant à la deuxième partie, elle est beaucoup plus axée sur la modélisation, la

conception, la réalisation technique du système d’information basé sur le progiciel de

gestion intégré de licence libre OpenERP 7, et l’interfaçage préliminaire avec l’application

Massira Smart-City. Elle énumère les outils informatiques utilisés ainsi que les langages de

programmation manipulés. Sans oublier bien évidemment l’étude benchmark réalisée pour

pouvoir choisir le progiciel de gestion intégré adéquat. Cette partie développe en détail

l’analyse fonctionnelle du besoin recueilli au niveau de la commune urbaine pilote de

Kenitra, en détaillant les différents services et processus métier pouvant exister au sein des

communes urbaines marocaines.

16 | P a g e



Chapitre 1 :

- Présentation de l’organisme d’accueil

Chapitre 2 :

- Présentation du cadre général du projet

17 | P a g e



Chapitre1

Présentation de l’organisme d’accueil

Ce chapitre comprend une présentation et

une description de l’organisme d’accueil Archos

Technology. Il présente son historique, décrit son

état et sa stratégie de croissance.

18 | P a g e



I. Présentation de Archos Technology

Archos Conseil est une SSII (Société de Services en Ingénierie Informatique), qui a été

créée vers la fin de l'année 1994, pour faire du conseil opérationnel en Organisation,

Management et Systèmes d’Information.

Figure 1 : logo Archos-Technology

Archos Conseil a investi, depuis 1996, dans le créneau de l'informatique

décisionnelle et a pu développer une très forte expertise dans toute la chaîne de valeur.

Cette expertise se traduit aujourd'hui par l'intervention sur près d'une centaine de projets

réussis et par la reconnaissance méritée de son savoir-faire dans ce domaine. Archos s’est

positionnée après sur les nouveaux métiers de l’informatique en élargissant ses offres vers

l’intégration de nouvelles solutions en PGI (Progiciel de Gestion Intégré) et en GRC (Gestion

de la Relation Client).

En 2009 Archos Conseil devient Archos Technology, filiale à 100% de Capital

Consulting Group.

Figure 2: logo Capital Consulting Group

Elle est actuellement l’un des pionniers du marché marocain. Elle présente une offre

globale à l'image des grandes multinationales du conseil : Stratégie, Management,

Organisation, Ressources Humaines, Systèmes d'information, Pilotage, Infogérance et

Intégration.

1- Métiers d’Archos-Technology

Archos Technology offre une panoplie complète de services à ses clients. Ces services

sont regroupés dans les six Business Units illustré par cette figure :

19 | P a g e



Figure 3: Les 6 Business-Units d’Archos Technology

Archos Institut

Il s’agit de la BU (Business Unit) regroupant les offres concernant la formation et

l’accompagnement du Middle Management du système d’information :

Stratégie de formation personnalisée: e-Learning, collaborative

Certification: PMP (Project Management Professional), ITIL (Information

Technology Infrastructure Library) ...

Software solutions

Cette BU regroupe les activités de vente des licences et des contrats de support et de

maintenance.

Financial Services Solutions

Cette BU regroupe les offres d'intégration de solutions dédiées au secteur financier :

Global Banking / Monétique / Crédit

Gestion de la communication et de production commerciale

Infogérance

C’est la BU dédiée aux offres d'externalisation des processus informatiques :

Infogérance des infrastructures SI

Prestations de service dans le cadre de la SLA (Service Level Agreement) /

Helpdesk

20 | P a g e



Business intelligence

Cette BU regroupe les compétences et le savoir-faire des projets décisionnels :

Une démarche globale de Management de la Performance

Une plateforme unique pour la prise de décision

Software factory

C’est la BU consacrée aux offres en ingénierie logicielle:

Développement d'applications spécifiques: Net, PHP (Hypertext

Preprocessor)...

TMA (Tierce Maintenance Applicative) / TRA (Tierce Recette Applicative)

Conception, création et gestion de portails collaboratifs et d'entreprises.

2- Stratégie de développement

La stratégie de croissance d’Archos-Technology est basée sur trois leviers :

Figure 4 : Les trois leviers de la stratégie de croissance d’Archos-Technology

Ces trois leviers constituent la vision de l’entreprise autour duquel se structure et

s’organise cette dernière, à commencer par la consolidation de l’offre traditionnelle, en

passant par la Régionalisation de l’offre qui vise à consolider la place de l’entreprise dans le

marché marocain et gagner davantage de l’importance à l’échelle internationale en

l’occurrence dans le continent Africain . La figure ci-dessus détaille encore plus les différents

piliers de développement adopté par Archos-Technology.

Capitaliser sur l’expertise

acquise dans les métiers clés

Conforter le positionnement

sur les domaines

d’interventions phares :

secteur financier, business

intelligence, développement

informatique offshore.

Consolidation de

l’offre traditionnelle Régionalisation de l’offre Diversification de l’offre

Reprendre les activités au

niveau régional et gagner

de nouveaux clients en

Afrique

Exploiter pleinement les

possibilités d’Archos

Technology en développant

les offres : e-learning, TMA,

Solution pour le secteur

financier.

21 | P a g e



3- Références

La diversité qui caractérise le secteur d’activités de Archos Technology, lui a permis

d’avoir un large portefeuille de clients. En voilà, les plus notables :

Figure5 : références d’Archos-Technology

Visiblement, la culture inculquée à l’entreprise, basée sur la volonté d’innover en

apportant des solutions simples et efficaces à des problématiques des plus complexes, se

voit être traduite par le choix et la confiance dont témoigne Archos Technology vis-à-vis de

ses clients.

Conclusion

Après avoir présenté l’organisme d’accueil ainsi que ses composantes hiérarchiques.

Nous tenons à aborder le contexte général du projet.

22 | P a g e



Chapitre2

Présentation du cadre général du projet

La présentation du cadre général du projet a pour but

de présenter le client final, situer le projet dans son

environnement organisationnel et contextuel, décrire la

problématique à traiter et de présenter la démarche suivie

pour la réalisation du projet.

23 | P a g e



I- Présentation du client final

Etant donné que le client final du projet n’est autre que l’ensemble des collectivités

locales marocaines, nous avons jugé nécessaire de mettre en exergue cette notion

territoriale dans le dessein de mettre dans un contexte la portée stratégique du projet. De

prime à bord, nous allons exposer le découpage territorial de notre royaume à la lumière des

dernières actualités administratives, tout en définissant exactement les différents types des

collectivités locales. Par la suite, nous allons nous intéresser à un type particulier des

collectivités locales, à savoir la commune urbaine. Dans le cadre de ce projet, la commune

urbaine de Kenitra a été désignée comme commune urbaine pilote. En addition, des ateliers

ont été tenus avec la commune urbaine de Casablanca, dans une phase préliminaire du

projet.

1- Organisation territoriale du Maroc

L’organisation territoriale de notre royaume revêt une complexité assez particulière,

vu les différents niveaux de dédoublement fonctionnel qui caractérise les régions et les

préfectures (ou provinces). Selon le dernier découpage administratif de 2009, le Maroc

compte 16 régions associées à 17 wilayas (la région de Tanger-Tétouan en

comprenant deux) rassemblent 75 préfectures ou provinces (13 préfectures et 62 provinces)

regroupant 1 503communes (221 urbaines et 1 282 rurales). Or d’après le projet de

régionalisation avancée de 2011, le nombre des régions a été réduit de 25%, soit 12 régions

au lieu de 16. Les régions sont :

Tanger-Tétouan, Oriental et Rif, Fès-Meknès, Rabat-Salé-Kénitra, Béni Mellal-Khénifra,

Casablanca-Settat, Marrakech-Safi, Drâa-Tafilalet, Souss-Massa, Guelmim-Oued Noun,

Laâyoune-Saguia al Hamra et Ed-Dakhla-Oued ed Dahab.

24 | P a g e



Figure 6 : découpage administratif du royaume

Bien que le découpage administratif marocain semble assez complexe, il est en

parfaite concertation avec les spécificités et les contraintes géographiques du royaume.

Dans ce sens, l’organisation territoriale est toujours vouée au changement. L’exemple

marocain n’est pas l’exception.

1.1- Collectivités locales

« Les collectivités territoriales du Royaume sont les régions, les préfectures, les

provinces et les communes. Elles constituent des personnes morales de droit public et gèrent

démocratiquement leurs affaires. Les Conseils des régions et des communes sont élus au

suffrage universel direct. Toute autre collectivité territoriale est créée par la loi, le cas

échéant, en substitution d’une ou plusieurs collectivités mentionnées à l’alinéa premier. »

[Constitution marocaine- Article 135]

La décentralisation marocaine initiatique amorcée en 1960 a connue un tournant

historique en 1976. Cette année est considérée par nombre d’analystes l’an numéro de la

décentralisation. En effet, elle a mis fin à la gestion bicéphale et transféré aux édiles locaux

d’importantes attributions antérieurement dévolus aux autorités locales. Les collectivités

locales sont, selon la constitution du 7 octobre 1996, les régions, les préfectures et les

provinces et les communes. Elles sont dotées de la personnalité morale et de l'autonomie

financière et élisent des assemblées chargées de gérer démocratiquement leurs affaires.

Commune Urbaine ou

Rurale (1503)

Prefectures ou Provinces (75)

Wilaya (17)

Régions (12)

25 | P a g e



Ainsi, le Dahir du 30 septembre 1976 consacre le principe de la compétence générale

de la commune pour régler toutes les questions d'intérêt local. Il a, dans son article 30,

explicitement investi la commune de responsabilités économiques.

Elle définit le plan de développement économique et social de la commune,

conformément aux orientations et aux objectifs retenus par le plan national. La commune

décide de son programme d'équipement dans la limite de ses moyens et de ceux mis à sa

disposition. Elle propose à l'administration les actions à entreprendre pour promouvoir le

son développement lorsque celles-ci dépassent ses compétences ou excèdent ses moyens.

La préfecture ou la province constitue le deuxième niveau de décentralisation

territoriale. Son statut hybride à la fois déconcentré et décentralisé lui confère un rôle de

mise en cohérence des actions des entités y rattachées. Elle constitue le niveau de l’action

socioculturelle et d‘appui au développement rural et de mise en œuvre du développement

concerté.

La région est le 3ème échelon de la décentralisation et la dernière collectivité créée.

Instituée en 1971 comme une simple circonscription territoriale de planification économique

et d'aménagement du territoire, la région a été élevée au rang de collectivité locale par la

constitution révisée de 1992 et c'est le Dahir du 2 avril 1997 qui en fixe l'organisation. Le

conseil régional règle par ses délibérations les affaires de la région, et, à cet effet, décide des

mesures à prendre pour lui assurer son plein développement économique, social et culturel,

et ce, dans le respect des attributions dévolues aux autres collectivités locales.

[www.hcp.ma]

1.2- Commune urbaine

« Les communes sont des collectivités territoriales de droit public, dotées de la

personnalité morale et de l'autonomie financière. Elles sont divisées en communes urbaines

et en communes rurales. Les communes sont créées et peuvent être supprimées par décret.

Le chef-lieu de la commune rurale est fixé par arrêté du ministre de l'intérieur. Le

changement de nom d'une commune est décidé par décret, sur proposition du ministre de

l'intérieur après consultation du conseil communal intéressé, ou sur proposition de ce

dernier. » [Charte communale- article1]

26 | P a g e



Dans le cadre de la décentralisation du pays, c'est la commune urbaine est la plus

petite subdivision administrative du territoire : les communes (niveau 3) sont regroupées au

sein de préfectures ou provinces (niveau 2), respectivement à dominante urbaine ou rurale,

elles-mêmes regroupées au sein de régions (niveau 1). Communes urbaines — ou

municipalités — et rurales sont à distinguer, les communes rurales comportant parfois des

centres urbains, dits « villes », qui sont des entités urbaines définies à des fins statistiques à

chaque recensement décennal par le haut-commissariat au Plan, mais n'ayant pas le statut

administratif de villes et n'apparaissant donc pas comme telles dans le Bulletin officiel du

Royaume du Maroc, contrairement aux communes urbaines.

Depuis le dernier découpage administratif de 2009, elles sont au nombre de 1 503

(221 urbaines et 1 282 rurales), réparties dans 75 préfectures ou provinces (13 préfectures

et 62 provinces), elles-mêmes réparties dans 16 régions administratives- [Guide Juridique des

Collectivités Locales – Ministère de l’Intérieur, 2012]

2- Ateliers de définition du besoin

Le lien de collaboration mutuelle qui lit Capital Consulting Group et la commune

urbaine de Kenitra ainsi que la disponibilité du chef de la division Urbanisme de la commune

urbaine de Casablanca , ont pu renforcer les chances de l’aboutissement un résultat concret

quant à la proposition d’un système d’information aidant à la gestion interne des processus

métier des communes urbaines, fidèle au contexte marocain.

2.1- Commune urbaine de Casablanca

Figure 7 : CU de Casablanca

En attendant la tenue de la première réunion avec le secrétaire général de la

commune urbaine de Kenitra, nous nous étions décidés de prendre l’initiative et aller à la

quête de l’information. Nos premiers déplacements ont été effectués aux instances

publiques suivantes :

http://fr.wikipedia.org/wiki/Administration_territoriale_du_Maroc#Cadre_de_la_d.C3.A9centralisation

http://fr.wikipedia.org/wiki/Pr%C3%A9fecture_ou_province_(Maroc)

http://fr.wikipedia.org/wiki/R%C3%A9gion_(Maroc)

http://fr.wikipedia.org/wiki/Ville_(Maroc)

http://fr.wikipedia.org/wiki/Haut-commissariat_au_Plan

http://fr.wikipedia.org/wiki/Bulletin_officiel_du_Royaume_du_Maroc

http://fr.wikipedia.org/wiki/Bulletin_officiel_du_Royaume_du_Maroc

27 | P a g e



Préfecture de Casa-Anfa (Division SI et Communication).

Préfecture des Arrondissements de Mers-Sultan (Division des Ressources

Humaines).

Commune Urbaine de Casablanca.

Dar Al-Khadamat- Division de l’Urbanisme (rattachée à la CU de Casablanca).

A travers nos multiples ateliers avec des responsables au sein des instances

susmentionnées, nous avons pu se construire une image plus claire sur l’état actuel des

procédures métier communales et leur aptitude à être informatisées et intégrées dans un

système d’information communal. Nous tenons à présenter quelques propos et constats

cueillis lors de nos réunions.

Le Directeur de la division des SI et communication de la préfecture de Casablanca

Anfa à avancé qu’avoir un ERP dans les collectivités locales relève du domaine de

l’impossible vu les métiers extrêmement différents qu’elles ont à traiter. Il ajoute que le

besoin se fait plus entendre en matière de communication entre les différents applicatifs

métiers séparément instaurées.

M. Arrouchi Hassan, le chargé du service des gestions des cadres, à son tour, s’est

prononcé sur la possibilité de commencer par des applicatifs traitant la strate support, et sur

le fait que les processus métier relèvent d’une complexité hors mesure, en absence de toute

documentation consistante.

Compte tenu de ces différentes remarques, nous avons demandé à avoir des ateliers

avec la division Urbanisme de Dar Al-Khadamat. L’équipe s’occupant du traitement des

différentes demandes d’autorisations, nous ont détaillé l’ensemble du processus. Et ce, en

traitant une demande d’autorisation de construction de bout en bout pour nous illustrer les

différentes étapes. Arrivée la première réunion de cadrage avec la commune urbaine pilote

de Kenitra, nous avions d’ores et déjà un prototype qui couvre une grande partie du

processus métier.

2.2- Commune urbaine pilote de Kenitra

Figure 8 : CU de Kenitra

28 | P a g e



Lors de la première réunion avec les dirigeants de la commune urbaine, qui était en

guise de présentation du produit proposé, nous nous sommes convenus sur la démarche à

adopter pour aboutir aux résultats fixés. Un planning prévisionnel de plusieurs ateliers a été

établi, en collaboration avec le responsable des systèmes d’information au sein de la

commune urbaine. Deux divisions étaient concernées par les ateliers :

La division d’Urbanisme et le service de la Police administrative relatif à la division des

Affaires Juridiques et Administratives. En somme, trois réunions de définition du besoin ont

été organisées, ainsi que 3 réunions de mise au point avec les agents fonctionnels pour

tailler la solution sur les exigences pratiques de la division.

Avant d’aborder l’analyse fonctionnelle du besoin, il nous a paru utile de dresser des

organigrammes synthétisant l’organisation de la commune urbaine de Kenitra, la division

Urbanisme et de la division des Affaires Juridiques et Administratives.

29 | P a g e



Organigramme de la commune urbaine de Kenitra

Figure 9 : Organigramme de la CU de Kenitra

Service de Contrôle

de Gestion

Service planification locale

Président

Cabinet

Secrétaire General Bureau d’Ordre

Supervision des

Travaux communaux Audit Interne

Ressources

Humaines

Budget &

Comptabilité

Finance

Communale

Protection

Civile

Aff. Juridiques

& Admin

Communication

et Partenariat

Environnement

& dev. Durable

Technique Urbanisme Affaires Culturelles,

Économiques

Patrimoine

30 | P a g e



Organigramme de la division Urbanisme

Figure10- Organigramme de la Division Urbanisme

Organigramme de la division des Affaires Juridiques et Administratives

Figure10bis- Organigramme de la Division Affaires Juridiques et Administratives

Division des Affaires

Juridiques & Administratives

Service des Affaires

Juridiques Service d’état Civil Service Légalisation Service Police

Administrative

Service Etude &

développement urbain

Division de l’Urbanisme

Service des Autorisations

Service Controle

d’Urbanisme

31 | P a g e



II- Problématique

La conjoncture socio-économique actuelle qui connait une évolution démographique

accélérante des villes, exige une réforme de la politique de modernisation des services publics. De

ce fait, le besoin d’informatisation commence à se faire sentir de plus en plus au niveau des

administrations publiques. Les communes urbaines n’échappent point à la problématique. La

lenteur et la lourdeur des procédures des différents services procurés par les CU ne semblent pas

enchanter les citoyens qui ne cessent d’exprimer leur mécontentement. La fluidité des opérations

laisse véritablement à désirer, notamment en ce qui concerne le traitement des demandes des

multiples types d’autorisation.

L’état actuel des systèmes d’information communaux, s’il se trouve qu’il en existe, ne peut

être qualifié que de chaotique et obsolète. C’est un constat appuyé par les nombreux responsables

au sein des communes urbaines de Casablanca et Kenitra, que nous avions rencontré lors de nos

ateliers. De ce fait, il s’est avéré que la mise en place d’un Système d’Information pour la gestion

des Collectivités Locales n’est plus un luxe, mais une nécessité pressante.

A priori, le grand challenge qui aurait pu entraver la réussite du projet est la pénurie

critique des documents relatifs au fonctionnement des collectivités locales. La majorité écrasante

des processus métier n’est pas formalisée, faute d’urbanisation du système d’information. En

addition, la quête de l’information juste et précise s’avère laborieuse vu la politique de

l’échappatoire pratiquée par les différents nivaux de la hiérarchie communale. Ce paysage

contraignant est encore plus enrichi par la complexité marquante des procédures administratives

qui peuvent être régies, selon le cas, par plusieurs textes de loi historiques ou tout simplement par

aucun.

III- Objectifs du projet

Le projet pilote de mise en place d’un système d‘information pour la gestion des

collectivités locales représente une avancée inédite dans le domaine des systèmes d’information

communaux. L’objectif du projet en sa globalité est d’informatiser l’ensemble des services et des

procédures de la commune urbaine pilote de Kenitra, en proposant un système d’information qui

sera un véritable levier de performance pour la gestion de la ville et qui améliorera la qualité des

différents services offerts aux citoyens tout en garantissant une meilleure gestion des ressources.

La solution sera bien évidemment généralisée par la suite, à toutes les communes urbaines

marocaines.

32 | P a g e



Notre solution est basée sur le progiciel de gestion intégré de licence libre OpenERP 7 qui

est un ERP modulaire permettant de développer des modules spécifiques aux besoins non

standards. Le système d’information doit se plier aux exigences fonctionnelles et métier de la

commune urbaine, tout en respectant les textes de loi et les circulaires. Plus spécifiquement,

l’objectif ultime du projet est de proposer des modules supportant des processus métier et ce

dans le dessein de couvrir un périmètre fonctionnel aussi large que possible. Les modules

proposés tiennent leurs forces du simple fait qu’ils répondent à des besoins métiers très

particuliers et importants. Le choix des processus à développer est fixé après une analyse

fonctionnelle que nous allons détailler par la suite.

IV- Conduite générale du projet

Un projet qui porte sur l’implémentation d’un ERP représente un investissement onéreux

et relativement long à mettre en œuvre. De facto, il est primordial de quantifier les enjeux et de

définir précisément les résultats attendus.

1- Enjeux du Projet

Dans une collectivité locale nous avons pris connaissance de trois types d’enjeux que nous

tenons à gérer tout au long du présent projet.

Stratégiques :

- Amélioration du service client, qui n’est autre que le citoyen.

- Suivre les tendances du métier.

Economique :

- Maitrise des couts de déploiement et de maintien.

- Minimiser le cout de fonctionnent.

Sociaux :

- Anticipation des Risques.

- Fournir une vision partagée de l’avenir.

- Impliquer le plus grand nombre d’agents fonctionnels.

2- Indicateurs de Performances

Pour un pilotage rationnel et performant du projet, il nous est paru judicieux de définir des

indicateurs précis pouvant nous donner une vue claire sur les résultats tangibles attendus.

33 | P a g e



Taux de service Citoyen

Il s’agit ici de réduire les délais relatifs au traitement de chaque dossier. Certes, une étape

primordiale dans notre processus relève d’un intervenant purement externe mais il nous est

toutefois possible d’alléger la procédure de la taxation en introduisant un calcul automatisé des

taxes et une impression automatiques des fiches, qui supposait auparavant la disponibilité en

temps plein d’un agent spécialisé.

Productivité Administrative :

C’est un indicateur lié dans une certaine mesure avec le taux de service. Il s’agit ici de la

réduction des taches administratives, de facto, du personnel administratif dans un processus, et

du coup, du temps relatif à chaque processus. L’opération de la taxation en fait l’exemple le plus

concret, le service verra son personnel passer de 7 à 1 ou deux agents fonctionnels.

Visibilité des supérieurs.

Auparavant, le fait d’avoir une visibilité sur le travail effectif réalisé par les agents relevait

du domaine de l’impossible, compte tenu de la difficulté du recensement des informations

relatives à chaque dossier. En implémentant un tableau de bord, les chefs de division peuvent

dorénavant consulter des statistiques leurs donnant une idée claire, précise et très concise de

l’activité de leurs services.

3- Suivi des Enjeux

Dans le début du projet, nous avons tenu de mesurer les indicateurs de performance. Le

but est d’user de ces valeurs en les comparants avec celles recueillies une fois le nouveau système

mis en production.

En termes de taux de service citoyen, la division traite 10 à 15 dossiers par jour, une durée

qui sera nettement nivelée une fois le système est opérationnel. Pour ce qui est de la productivité

Administrative, le service Urbanisme verra son effectif se réduire de 20%.

Le dernier indicateur est celui qui révolutionne la gestion au niveau de ce service. Nous

parlons des rapports sous forme de documents ou carrément des tableaux de bords. Auparavant

c’a n’existait point, c’est donc une fonctionnalité qui se présente comme une plus-value

incontournable - [ERP, méthode pratique de mise en œuvre pour PME et PMI- 2010]

34 | P a g e



4- Démarche d’implémentation d’un ERP

Découpage en Phases :

Un projet ERP peut se décomposer en 5 phases méthodologiques. Ce découpage permet

une meilleure gestion du processus de convergence itératif entre les besoins fonctionnels définis

en termes purement métier et les possibilités du progiciel.

Fig12 : Découpage du projet en phases

Phase I : Conception Générale

Il s’agit de formaliser les règles de gestions au sein des collectivités locales

marocaines, ainsi que documenter et modéliser les processus qui y sont inhérents, et en

dernier lieu rédiger les spécifications fonctionnelles. Pour ce faire, nous avons jugé utile

d’étudier de près le projet français OpenMairie. Nous avons essayé de profiter de

l’expérience française dans le monde des progiciels libres pour la gestion des organismes

publics et ce, en analysant les processus de base et les diagrammes UML. Cette phase s’avère une

occasion pour la collectivité de remettre à plat et optimiser ses règles de gestion et ses

processus métier, ainsi bien que de rechercher des sources d'économie.

Conception

Générale

(Organisation

& Processus

majeurs)

Conception

Détaillée

(Processus Cible,

Prototypage)

Déploiement Site Pilote

(Mise en production, Formation des

Utilisateurs)

Déploiement

Généralisé

(Site 1… Site n)

Suivi de Projet et Conduite de Changement.

Réalisation

(Developments &

Tests)

35 | P a g e



Phase II : Conception Détaillée

Chaque processus formalisé, schématisé, pour nous doit voir un module développé

spécifiquement pour répondre à ses différentes spécificités. En cas d’existence d’un module

prédéfini qui s’approche de l’aspect métier en cours de traitement, nous effectuons un

paramétrage adéquat, ce faisant, nous réduisons l’écart fonctionnel entre le module type et le

module souhaité. Nous essayons de produire des modules personnalisés et fidèles au contexte

communal marocain à la limite du possible, tout en proposant des interfaces intuitives et

faciles à manipuler par l’ensemble du personnel administratif, souvent, non connaisseur des

rouages informatiques.

Phase III : Réalisation

Lors de cette phase, nous nous sommes plus concentrés sur la conception et la réalisation

des interfaces.

Dés lors, nous nous sommes plus confrontés au socle technique en vue d’adapter le

progiciel aux exigences métier préalablement définies et assurer la couverture fonctionnelle la

plus large qui soit.

Pour chaque fonction réalisée, des cas de tests sont préparés. Pour chaque cas de test,

des jeux de test encore dénommés jeux d’essai ou encore jeux de données sont conçus. Il

s’agit ici de tester le fonctionnement correct de tous les processus et les modules de gestion dans

la collectivité locale qui fait objet de l’étude.

Généralement, cette phase se caractérise par la finalisation des travaux informatiques sur

l’outil.

Phase IV : Déploiement

C'est la phase ultime de mise en production de l'ERP. Un site pilote est souvent

désigné pour servir de "cobaye"(Dans notre cas, c’est la commune de Kenitra). Nous nous

basculons en effet qu'au niveau d’une entité géographique, un service avec un nombre

restreint d'utilisateurs (de "end users"), avant de généraliser la bascule à l'ensemble de la

collectivité ou à l'ensemble du territoire, mais à long terme.

36 | P a g e



Phase V : Conduite de Changement

Le projet d’implémentation du SICL ne pourra véritablement réussir que si les

utilisateurs finaux adhérent à ce nouveau progiciel qui leur est proposé et qu’ils acceptent

d’adapter leurs méthodologies de travail. Les rôles et responsabilités peuvent être à même

d’évoluer avec ce nouvel outil. Les moyens de préparer les futurs utilisateurs sont légions. Dans un

premier temps, il est préférable de commencer par sensibiliser les utilisateurs en leur présentant

les bénéfices de l’ERP, du nouvel outil, dans leur travail quotidien, le temps qu’ils gagnent et

les simplifications et optimisations apportées.

Par la suite, une formation pédagogique, basée sur la pratique de l’outil en direct sur

des ordinateurs prévus à cet effet dans les salles de formation, est à prévoir.

Eventuellement, des supports de formation détaillés avec des captures d’écran, seront mis à

la disposition des utilisateurs pour qu’ils ne se sentent pas perdus lors de la première

utilisation.

La formation des utilisateurs peut se faire soit directement soit à travers des « Super

Utilisateurs ». Des formateurs (souvent des consultants ERP qui après avoir participé à

plusieurs implémentations de SI, se reconvertissent dans la formation ERP) forment d’autres

formateurs, nommés alors « SuperUsers », ou des « Utilisateurs Clés ». Ces derniers forment les «

end-users », c'est à dire les utilisateurs finaux. Cette méthode est plus pratique, surtout quand

l’outil s’adresse à un grand nombre d’utilisateurs.

5- Notion de Prototypage :

De nombreuses méthodes ont fait leurs preuves dans le pilotage des projets informatiques,

qui se portaient généralement à des développements spécifiques. La différence ici est qu’il est à

long terme question de piloter un projet ERP et donc d’adopter une démarche radicalement

différente de celle d’ordinaire.

En effet, les démarches traditionnelles visaient à développer des solutions spécifiques en

répondant à un besoin précis. La tendance actuelle est celle de s’adapter à un progiciel pour

bénéficier des fonctionnalités transversales que présente ce dernier.

37 | P a g e



Démarche Traditionnelle :

Cette démarche traditionnelle à pour limitations la provocation directe

d’innombrable développements spécifiques.

Les projets ERP sont de nature différente et donc font appel à de nouvelles notions de

pilotage. La démarche convenable à ce type de projet serait axée sur la notion de Prototypage, qui

consiste à recenser les besoins des agents fonctionnels et de les simuler dans un progiciel.

Prototypage :

Figure 13 : Prototypage

Cette méthodologie présente l’avantage de la rapidité quant à l’ajustement des besoins

métiers avec le progiciel. La notion de prototypage implique une collaboration directe et complète

des agents opérationnels, propre au métier, que nous appelons Utilisateurs Clés ou Experts

Métiers. La plupart des travaux se font en équipe mixte composé MOA/MOE générant ainsi un

équilibre des charges entre les différents acteurs.

Prototypage Paramétrage Conception

38 | P a g e



Figure 14 : Avantages du prototypage

Compte tenu de la multitude des avantages que présente la notion de prototypage, elle semble

être la démarche la plus adéquate à adopter pour la mise en place d’un projet ERP. La flexibilité et

l’ajustement aux besoins sont très sollicités ai niveau des projets à longue haleine.

6- Planification du déroulement du projet

Le diagramme de GANTT suivant traduit la planification temporelle des phases du projet :

Diagramme 1 : Diagramme de GANTT

Exploitation d'un capital pratique de

Gestion

Réduction des Coûts

Gain en coût et délai

Facilite de maintenance et garantie de

l'éditeur

39 | P a g e



7- Rôles et Responsabilités

Les équipes projet en présence sont :

La commune Urbaine de Kenitra : Maitrise d’ouvrage du Projet. (MOA)

Capital Consulting Group : MOE, Avec ses diverses composantes.

Archos Technology : Travaux de Développements Informatiques.

UrbaSoft : Travaux de Géo-localisation.

Capital Consulting : Conseil en Organisation.

Chaque intervenant est responsable de l’atteinte des objectifs qui lui sont confiés. De surcroît,

l’obligation de coopérer avec l’ensemble de l’équipe du projet est indiscutable, en vue d’aboutir à

un résultat satisfaisant et complet technologiquement.

Archos Technology

ERP : Responsabilité

du support progiciel,

de réalisation et

développement et

implémentation.

UrbaSoft

Responsabilité de

l’implémentation et

du support de

l’application Massira

Smart-City.

Experts Métier

Responsabilité de

documenter les

processus et de les

reproduire dans le

progiciel.

Capital Consulting

Responsabilité de

l’accompagnement

et conseil en

organisation.

Commune Urbaine de

Kenitra (MOA)

Capital Consulting

GROUP (MOE)

Liens Non Contractuels ou Juridiques

Figure 15 : Rôles et responsabilités

40 | P a g e



Structure du Projet :

La commune urbaine souhaite être assistée d’un intégrateur afin que ce dernier apporte son expertise sur les domaines suivants :

Apport Méthodologique pour définir une nouvelle structure organisationnelle.

Expertise fonctionnelle de l’ERP : Présentation de la solution, recette et formation des utilisateurs.

Pilotage de la mise en œuvre des outils informatiques et des travaux de développement et de mise en production.

Figure 16 : Structure du projet

Cette structure définie un cadre permettant le développement rapide du projet. En

consolidant des canaux de communications transversales, les différents intervenants instaurent un

climat catalyseur de l’atteinte des objectifs souhaités.

Conclusion

Ce deuxième chapitre étant clos, nous avons tâché de décrire amplement le paysage

complet du projet ainsi que ses enjeux stratégiques. Par la suite, une analyse fonctionnelle des

besoins s’impose pour pouvoir mieux définir le périmètre fonctionnel et pour être mieux en

mesure de capitaliser l’ensemble des processus métier.

MOE MOA

Secrétaire

Général

M. Abdelatif

BOUCETTA

Chef de la

Division

Urbanisme

Chef de la

Div des Aff.

Juridique & la

Police

Administrativ

e

Directeur Associé de Capital Consulting Group : M. Abdelmonim FAOUZI.

Archos Technology:

M. Zakaria ElKarkari.

UrbaSoft:

M. Ahmed Lahbabi.

ERP

M. Mohammed

OMARI

M. Mohammed Amine

AZAHAF

Massira Smart-City

M. Youssef

Ait Laidi

Organisation

M. Karim Amri

Comité de

pilotage

Comité de suivi

Capital Consulting:

M. Karim Amri.

41 | P a g e



Chapitre 3 :

- Analyse fonctionnelle

Chapitre 4 :

- Analyse et réalisation technique

Chapitre 5 :

- Installation et simulation

42 | P a g e



Chapitre3

Analyse fonctionnelle

Le but de cette étape est d’optimiser la conduite du

projet. Nous allons tenir à bien définir le besoin client pour

fin de concevoir une solution la plus conforme qui soit. Une

bonne analyse fonctionnelle nous fera éviter quelques

pièges classiques et nous fera gagner en efficacité et en

qualité de notre travail.

43 | P a g e



I. Cartographie SI des Collectivités Locales :

Pour commencer, nous avons travaillé sur l’établissement d’une cartographie orientée

métier, et ce pour tirer part du domaine qui fera objet de nos études et développements. Pour ce

faire, nous nous sommes basés sur le modèle français ainsi que sur des rencontres et directives

des cadres des différentes instances publiques. Cette cartographie, validée par des responsables

inhérents aux collectivités locales, permet entre autre de délimiter l’espace d’action des

préfectures et es communes.

Figure 17 : Cartographie SI

A l’issu de nos différentes rencontres et ateliers, nous nous sommes décidés à travailler sur

le volet de l’urbanisme en premier lieu, et sur celui de la police administrative s’il nous reste assez

de temps.

Nous allons donc mettre à plat, de façon aussi claire que possible, l'analyse qualitative et

quantitative du fonctionnement actuel de la division de l’urbanisme et du service PA, en détaillant

leurs processus métiers respectifs.

44 | P a g e



II. Processus Métiers

A l’issu de nos multiples réunions et ateliers fonctionnels, nous avons cerné et modélisé les

processus métiers relatif à chacune des divisions.

1- Division de l’Urbanisme

Cette division à pour principal mission la délivrance des permis de construire et d’habiter. Ces

documents représentent un outil administratif pour vérifier si un projet de construction respecte

bien la réglementation en vigueur.

Processus :

Diagramme 2 : Processus Métier de la division Urbanisme

Le pétitionnaire dépose son dossier auprès du service dédié à cet effet et reçoit un

récépissé ou un avis de complément de dossier au cas ou ce dernier est incomplet. Une fois

déclaré reçu, le dossier passe à l’étape « Enregistrement », dans laquelle des fichiers sont

automatiquement générés pour être envoyés par courrier aux différents acteurs de la

commission technique (Dispatch). A l’issu de ladite commission, un arrêté de décision valide le

projet du demandeur ou impose quelque mesures supplémentaires, il peut aussi refuser la

demande du demandeur et un avis de refus est rédigé à cet effet, expliquant les raison

derrière. La commission technique peut même décider du report de la prise d’une décision pour

une date ultérieure.

Au cas où la décision de la commission se porte favorable, le demandeur est tenu de régler

les frais de la taxation du dossier, pour que ce dernier soit valide directement après par la

signature du président de la commune. Le demandeur vient donc retirer son dossier tandis que la

version numérique de ce dernier est archivée.

45 | P a g e



2- Service de la Police Administrative

Ce service est responsable de la délivrance des autorisations d’exploitations des lieux de

commerce, ou du domaine public en déposant des panneaux publicitaire ou des kiosques.

Processus :

Diagramme 3 : Processus Métier du service PA

Le pétitionnaire commence par déposer sa demande d’autorisation, un courrier lui est envoyé

s’il manque une pièce à son dossier. Une fois l’enregistrement effectué, le dossier est envoyé à

une commission technique, cette dernière qui fait des investigations et qui se réunit pour décider

du sort de la demande. Au cas où cette dernière est favorable, la commission fera une visite sur les

lieux pour certifier de l’exactitude des informations relatives à la demande. Un accord de principe

est donné pour commencer des travaux d’aménagement. Par la suite, la commission effectue une

deuxième visite en vue de vérifier la conformité des travaux réalisés. Dans un dernier temps, le

pétitionnaire payera des droits publics et peut juste après commencer l’exploitation de sa

demande. Sinon, il a droit à un PV lui décrivant les raisons qui ont vouée sa demande au refus.

III. Etat de l’art en termes de SI

1- Division ‘Urbanisme’

Cette dernière n’a jamais connu de système d’Information. Les agents y travaillent à l’ancienne

ce qui cause un certain surnombre des étapes affectant le processus métier de la présente

division.

Par exemple, les enregistrements se font dans un registre à la main, la taxation se fait aussi

avec les moyens traditionnels, et donc le dossier se voit trainer entre les différents intervenants

qui sont souvent à disponibilité restreinte.

46 | P a g e



2- Service ‘Police Administrative’

Contrairement à toute attente, ce dernier dispose d’un sens d’autonomie et de pro-activité

sans pair. Les agents de ce service ont conçu un SI basé sur les ressources disponibles et ont bien

pu couvrir un certain périmètre de leurs domaines d’intervention.

Dans leurs locaux, nous trouvons des ordinateurs usant de la fonctionnalité « Publipostage ».

En effet, c’est une technique relativement simple mais qui trouve toute son application dans le

contexte actuel. Cette division est responsable de la délivrance de quelque type d’autorisation, c’a

veut dire qu’elle a des modèles de document type, et des informations des pétitionnaires

variables. Le principe du publipostage est d’associer un document type, à une source de données.

Figure 18 : Publipostage

De la manière, ils se permettent de générer des rapports, des autorisations, des avis, voire

même des modèles de PV et ce à travers un simple click. Cette technique bien qu’elle a plusieurs

avantages, l’un d’eux d’ailleurs est de consolider une base de données depuis 2009, trouve ses

limitations au niveau de l’exploitation de la DB pour réaliser des tableaux de bords. La navigation

dans les fichiers Excel quant à elle n’est pas très succincte et suppose une connaissance profonde

de la structuration de la DB.

Conclusion

L’informatisation du volet urbanistique s’avère une étape primordiale pour la mise en

place d’un SICL. Nous avons décidé de commencer avec ce dernier car de un, il subit un manque

flagrant en terme d’outils technologiques, et de deux, il fait partie de la strate métier de la

cartographie, cette dernière qui a un impact direct sur les citoyens est dont les mutations

positives se sentiront rapidement au niveau de la CL ou de la population qui l’entoure. Viendra

ensuite le service de la police administratif, qui fait parti aussi de la strate métier de la

cartographie. Le but final reste de doter les collectivités locales d’un système de gestion de

contenu qui garantit liberté, qualité, efficacité, simplicité, modularité et durabilité.

47 | P a g e



Chapitre4

Analyse et réalisation technique

Ce présent chapitre nous permettra de

détailler exhaustivement les phases et les étapes de

l’analyse technique du projet de mise en place d’un

système d’information pour la gestion des

collectivités locales. De prime à bord, nous allons

commencer par une étude benchmark des outils et

des technologies utilisées pour mener à terme ce

projet. Par la suite, nous allons présenter l’ensemble

de l’étude technique que nous avons faite pour

aboutir à une conception et modélisation adéquates. En dernier lieu, nous détaillons

exhaustivement l’interfaçage avec l’application Massira Smart-City.

48 | P a g e



Avant de commencer tout type de projet informatique, des études benchmark des

différentes solutions et outils à utiliser s’imposent. De ce fait, nous avons procédé à un benchmark

des progiciels de gestion intégré, les outils de l’ETL ainsi que les générateurs des rapports. Et ce,

dans le dessein d’être en mesure d’adopter les outils adéquats et pertinents en termes de

fonctionnalités proposées.

I. Choix du Progiciel de Gestion Intégré

Avant de commencer tout développement, il nous a paru judicieux de s’attarder sur le

choix de l’outil informatique. Nos recherches étaient axées sur des solutions qui pouvaient

répondre en totalité ou en partie à nos besoins technico-fonctionnels.

L’un des critères majeurs est l’usage de progiciel de License libre. En effet, La collectivité

locale pouvant être perçue comme étant une entreprise, est dotée d’un budget bien défini. Il est

donc dans son intérêt de faire appel à de l’expertise en terme de logiciel open source. D’autant

plus, le fait d’avoir recours à cette technologie fait profiter la collectivité et de la gratuité de la

License et de la disponibilité des compétences en matière de technicité à des prix raisonnables.

Développer cette technologie donne aussi la possibilité à l’entreprise nous accueillant de

diversifier ses produits et de cibler facilement d’autres clients en élaborant des offres intéressante

et à portée financière adéquate.

1- Etude détaillée de OpenMairie

Figure 19 : logo de OpenMairie

Dans le cadre de ce projet, il nous a été conseillé d’analyser et étudier de près un projet

français similaire. OpenMairie est un Projet qui englobe plusieurs applications implantées au

niveau des collectivités locales dans le territoire français. Ce progiciel de licence libre couvre la

quasi-totalité des métiers des communes françaises, il est taillé à la mesure de leurs

différents processus.

Techniquement, OpenMairie prend en charge l'interface utilisateur, la connexion à une

base de données relationnelle et la génération de documents au format PDF.

« OpenMairie » compte plus de 30 applications développées par des sociétés de services

en logiciel libre et 10 partenaires publics français qui contribuent au développement du projet. » -

[Site Officiel : www.OpenMairie.org]

49 | P a g e



Figure 20 : Couverture Fonctionnelle du Projet Open Marie

Tenant compte de la véracité et de l’exactitude de ce progiciel, et des spécificités du

contexte marocain, nous nous permettons de poser quelques questions :

Quelle est le degré de ressemblance entre les différents processus dans les CL marocaines

et françaises ?

Serait-il judicieux de paramétrer Open Mairie pour l’adapter aux exigences métiers des CL

marocaines ?

D’après les différentes rencontres avec les responsables des CL au niveau de Kenitra et

Casablanca, et ayant effectué des ateliers avec des agents fonctionnels inhérents à cet

environnement, nous avons remarqué que les processus locaux sont succincts et très concis. Or,

les applicatifs de démonstrations d’Open Marie nous ont humblement démontré que ce progiciel

est étroitement taillé sur les propres mesures des processus français, ces derniers qui affichent

une complication et un détail anodin vis-à-vis du contexte marocain.

Visiblement, le choix d’implémenter Open Mairie sera pénalisant surtout en termes de qualité

de l’outil, parce que le métier des CL marocaines ne parviendra pas à s'adapter aux processus du

progiciel, et ce dernier demandera trop de développements spécifiques pour faire le chemin

inverse et s’adapter aux exigences des métiers locaux.

openElec Gestion des listes électorales

openResultats Affichage des résultats électoraux

openScrutin Gestion de la composition des bureaux de votes

openElu Gestion de la composition du conseil municipal

openRecouvrement Recouvrement de titres

openStock Gestion des stocks et facturation

openCourrier Gestion du courrier

openCimetière Gestion des cimetières

openCadastre Gestion du cadastre (fichier de la DGI (Direction générale

des impots)

openReglement Gestion des pièces d'identités et autres documents administratifs

openPlanning Gestion des resources

openMainCourante Pour la police municipale et les centres d'appel

50 | P a g e



2- Benchmark des PGI existants

En absence de tout progiciel pouvant répondre à notre besoin, le développement

spécifique et le besoin de création de cet outil se met à l’affiche.

Nous nous sommes basés sur une analyse faite par SMILE, un cabinet expert dans la

branche de la veille technologique. Les consultants de ce dernier ont publié un rapport comparatif

de plusieurs solutions open source, ERP à l’occasion. Sans donner de synthèse, ce rapport sur

lequel nous nous sommes basés présente de manière quantitative les force et les faiblesses de

trois ERP, à savoir Compiere, OpenBravo et enfin OpenERP.

La figure suivante donne une vue d’ensemble sur les différents ERP open source.

Figure 21 : Etude Comparative des ERP Open Source. (Smile, Guide OpenSource, p233, p234, p235)

Nous remarquons qu’OpenBravo présente des faiblesses en comparaison avec les autres

ERP en termes de périmètre fonctionnel. Sauf que ce facteur ne nous sera pas décisif, du moment

que nous comptons créer nos propres applicatives et donc nous allons encore plus se baser sur le

Framework, de facto sur les ressources disponibles, et sur la qualité du socle technique, et sur

l’extensibilité.

Tenant compte des trois facteurs, OpenERP se distingue par sa qualification largement au

dessus de la moyenne. Le facteur de la notoriété vient se rajouter pour maintenir cet ERP dans sa

position de Leader et ainsi rendant clair la question du choix du PGI libre et performant.

51 | P a g e



2.1- OpenERP :

Figure 22 : logo d’penERP

Anciennement connu sous le nom TinyERP, signifiant la fourmi de l’Enterprise resource

planning) est un progiciel intégré de gestion ouvert, libre de droits comprenant les ventes, la

gestion de relation client (CRM), la gestion de projet, la gestion d'entrepôt, la production, la

comptabilité et les ressources humaines. OpenERP a trois composants séparés : le serveur

openerp-server qui stocke ses données dans une base postgresql, le client openerp-client qui

s'installe sur le poste de l'utilisateur et le serveur web Openerp-web qui permet une utilisation

depuis un navigateur. Ces trois composants communiquent par les protocoles XML-RPC et NET-

RPC.

Le logiciel est basé sur une forte architecture MVC, des flux de travail flexibles, une

interface-utilisateur graphique dynamique, une interface XML-RPC, et un système personnalisable

de comptes-rendus avec une intégration pratique d'OpenOffice.org. Dans la classification des

logiciels, OpenERP, comme tout autre PGI sur le marché est un package destiné, a priori, à tous les

secteurs, à toutes les fonctions, les adaptations nécessaires se faisant par paramétrage.

Il dispose de forts arguments commerciaux pour séduire les dirigeants (il propose de

mettre un terme au désordre du système d’information, et aussi de régler des problèmes

d’organisation sans effort politique). Cette offre séduisante par sa qualité et sa cohérence se

révèle à l’usage plus risquée que l’on avait pu l’imaginer : elle ne peut être efficace que si l’on

accepte les contraintes qu’elle impose. Sa mise en œuvre comporte des difficultés et des pièges.

Implanter un PGI a ses avantages, parmi lesquels je cite :

Optimisation des processus de gestion.

Cohérence et homogénéité des informations.

Intégrité et unicité du Système d’information.

Mise à disposition d’un outil multilingue et multidevises (très adapté aux multinationales).

Communication interne et externe facilitée par le partage du même système

d’information.

Meilleure coordination des services et donc meilleur suivi des processus (meilleur suivi de

commande ou meilleure maîtrise des stocks par exemple).

Normalisation de la gestion des ressources humaines (pour les entreprises gérant de

nombreuses entités parfois géographiquement dispersées).

Minimisation des coûts (formation et maintenance).

Maîtrise des coûts et des délais de mise en œuvre et de déploiement.

Mise à disposition, des cadres supérieurs, d’indicateurs nettement plus fiables que

lorsqu’ils étaient extraits de plusieurs systèmes différents.

52 | P a g e



OpenERP comporte plusieurs modules fonctionnels, je cite les exemples suivants :

CRM ; gestion de la relation client.

Comptabilité analytique et financière (Conforme aux exigences françaises).

Gestion des stocks.

Gestion de production (GPAO).

Gestion de projets et des activités de services.

Norme qualité : ISO 9001 version 2000.

Gestion des ventes.

Gestion des achats.

Marketing.

Logistique.

Ressources humaines.

Gestion documentaire.

Matrice SWOT (OpenERP):

Nous proposons d’effectuer un diagnostic interne pour déterminer les forces et les

faiblesses de cet ERP, ainsi qu’un diagnostic externe pour identifier les menaces et les

opportunités que présente l’environnement pour le développement de cette solution, et ce en

conduisant une analyse SWOT.

Tableau1 : Matrice SWOT OpenERP

Force :

Bon Framework de développement.

Disponibilité d’une interface Web complète, rapide et facile à utiliser qui fonctionne avec les différents navigateurs.

Léger et assez facile a appréhender.

Modularité : OpenERP est très modulaire, et il est possible de n’installer que les modules dont on a besoin.

Une communauté dynamique, et qui code énormément.

Faiblesse :

La faiblesse fonctionnelle des modules officiels, OpenERP possède le minimum dans chaque domaine.

Manque d’intégrateurs expérimentés.

Opportunités :

Devenir le leader des ERPs OpenSource.

Développement de scripts de migration communautaires avec le projet OpenUpgrade.

Menace :

Mauvaise gestion des copyrights par l'éditeur sur les modules officiels qui pourrait amener des contributeurs de la communauté à contester la validité de la licence.

http://openupgrade-server.readthedocs.org/

53 | P a g e



Ce que nous pouvons tirer de cette étude c’est que les limitations internes et externes

peuvent être palier par une bonne exploitation notamment des ressources et des avantages que le

diagnostic vient de nous révéler. - [www.people.via.ecp.fr/~alexis/openerp/#intro]

Déploiement d’OpenERP :

Coté architecture, OpenERP est basé sur une architecture 3 tiers:

1. Un serveur de base de données PostgreSQL (qui peut contenir plusieurs bases de

données)

2. Un serveur d'applications (contenant les objets de gestion, le moteur de workflow, le

générateur d'édition, etc.)

3. Un serveur de présentation (appelé OpenERP Web) qui permet à l'utilisateur de se

connecter à OpenERP avec n'importe quel navigateur internet).

Figure 23: Architecture d'OpenERP

La partie serveur est écrite en langage Python. Les différentes briques sont organisées en

«modules». Un module est un dossier avec une structure prédéfinie contenant du code Python et

des fichiers XML. Un module définit la structure de données, formulaires, rapports, menus,

procédures, flux de travail, etc.

Le client est léger car il ne contient pas de logique d'entreprise (l'ensemble est embarqué dans

le serveur d'application). Ainsi, l'ajout de nouveaux objets, comme les menus ou formulaires, le

rend accessible à tout type de client graphique.

54 | P a g e



Framework OpenERP

Le Framework de OpenERP est considéré comme le point le plus fort de ce progiciel de

gestion intégré, il est indubitablement un avantage incontournable. Nous citons ci-dessous

quelques points de force :

ORM : Dès ses débuts, OpenERP s'est doté d'un ORM, alors que cette

technologie était encore très peu répandue. L'ORM permet d'avoir une couche d'abstraction par

rapport à la base de donnée ; il gère les droits d'accès, les traductions et évite d'avoir à écrire le

code SQL dans lequel il faut refaire toutes les relations entre les tables avec des JOIN. OpenERP a

fait évoluer son ORM au fur et à mesure des versions, mais continue d'utiliser son propre ORM et

n'a pas basculé vers un ORM libre "standard" tel que SQLAlchemy par exemple.

Cependant, il reste possible d'utiliser des requêtes SQL dans le code d'OpenERP, par

exemple pour certaines parties du code où les performances sont très importantes. Mais

attention, le fait d'utiliser une requête SQL dans le code d'OpenERP contourne la gestion des

droits d'accès d'OpenERP. L'ORM d'OpenERP ne fonctionne qu'avec PostgreSQL, même si l'éditeur

avait ajouté à une époque dans une branche de test le support de MySQL, dans le cadre

d'un partenariat avec Sun Microsystem (après le rachat de MySQL par Sun et avant le rachat de

Sun par Oracle), mais cette branche n'a jamais été mergée avec la branche officielle et on n'a plus

jamais entendu parler de ce partenariat.

L'accès généralisé via les Webservices en XML-RPC et JSON-RPC.

Tous les objets d'OpenERP (exemple d'objets : les commandes, les factures, les écritures

comptables, ...) sont accessibles via les webservices en lecture, écriture, création et suppression.

Mieux : toutes les fonctions d'OpenERP sont accessibles en webservices. Cela signifie par exemple

que n'importe quel clic sur un bouton de l'interface d'OpenERP (comme par exemple le

bouton Créer la facture ou le bouton Valider le mouvement de stock) peut être fait depuis un

webservice.

Le moteur de Workflow : OpenERP a un moteur de workflow simple mais

généralement suffisant pour les besoins ERP des PMEs. Ce moteur de workflow est spécifique à

OpenERP.

Serveur OpenERP : Toute l'intelligence d'OpenERP est côté serveur ; il n'y a aucune

intelligence côté client. Même à l'époque où le client Gtk était disponible (avant son abandon avec

la sortie d'OpenERP 7.0), ce logiciel qu'on désignait sous le terme de "client lourd" (par opposition

à l'interface Web qui est désignée sous le terme de "client léger") n'avait en réalité rien de lourd,

car il se contentait de faire le rendu graphique d'un écran qui a été généré par le serveur OpenERP

en XML.

http://www.sqlalchemy.org/

https://code.launchpad.net/~openerp-commiter/openobject-server/server-sa

http://fptiny.blogspot.fr/2010/01/sun-openerp-partnership.html

55 | P a g e



L’interface Web : L’interface Web d'OpenERP a été lancée avec OpenERP v4.2. Elle a

été améliorée dans OpenERP version 5.0 et 6.0, puis elle a été entièrement réécrite dans OpenERP

v6.1 sous l'impulsion du nouveau directeur R&D d'OpenERP, Antony Lesuisse, et son design et son

ergonomie ont encore été grandement améliorés dans OpenERP version 7.0. Avec la nouvelle

interface Web introduite dans OpenERP 6.1, l'interface Web est même devenue aussi rapide que

le client Gtk utilisé avec le protocole Net-RPC (Net-RPC était le plus rapide des protocoles

disponibles avec le client Gtk). Elle fonctionne bien sous Firefox, Chrome et Safari, ce qui en fait

une solution d'accès à OpenERP multi-plateforme (Windows, Mac, Linux... mais aussi iPad ou

tablette Android).

Une variante mobile de l'interface Web était disponible dans OpenERP 6.1 en version beta et

permettait un accès en lecture seule à l'ERP adapté à la petite taille des écrans des téléphones

mobiles. Cette variante mobile a été retirée d'OpenERP 7.0 ; le directeur technique d'OpenERP

voudrait à terme qu'il y ait une seule interface responsive qui s'adapte à toutes les tailles d'écran,

ce qui éviterait d'avoir une version mobile de l'interface Web avec du code dédié.

56 | P a g e



II. Analyse et conception UML

1- UML

L’UML (Unified Modeling Language) ou Langage de modélisation unifié, est un langage de

modélisation graphique qui s’use des pictogrammes dans le but de bien décrire votre proposition

de solution informatique. Au milieu des années 90, les auteurs de Booch, OOSE et OMT ont décidé

de créer un langage de modélisation unifié avec pour objectifs :

Modéliser un système des concepts à l'exécutable, en utilisant les techniques orientée

objet.

Réduire la complexité de la modélisation.

Utilisable par l'homme comme la machine :

- Représentations graphiques mais disposant de qualités formelles suffisantes pour

être traduites automatiquement en code source.

- Ces représentations ne disposent cependant pas de qualités formelles suffisantes

pour justifier d'aussi bonnes propriétés mathématiques que des langages de

spécification formelle (Z, VDM...). – [Cours UML – Pierre Gérard]

Son utilité se manifeste surtout lors des phases de modification et de construction des

documents relatifs au développement informatique d’un logiciel orienté objet.

Ce langage de modélisation compte plusieurs types de diagrammes, nous en citons les

deux plus utilisés :

Diagramme des cas d'utilisation : ce diagramme permet de représenter l’interaction entre

le système et des intervenants extérieurs, en se positionnant du côté utilisateur.

Diagramme des classes : ce diagramme, comme son nom l’indique, décrit exhaustivement

la structure interne du système en exposant les différentes relations existantes entre les

classes le constituant.

57 | P a g e



2- Diagramme des cas d'utilisation

La gestion urbanistique se rapporte à l’organisation du développement urbain dans villes et

agglomérations. Pour faciliter les processus de ce service ainsi que pour atteindre un résultat

efficient, les utilisateurs sont tenus de capitaliser sur l’outil informatique.

Diagramme 4 : Diagramme des cas d’utilisation

Gérer les demandes : ce cas d’utilisation permet aux acteurs de créer et de gérer les différentes demandes d’autorisations, avec la possibilité de modifier même avant sa création, donnant ainsi la possibilité aux demandeurs de compléter leurs dossiers si ces derniers manquent de documents administratifs imposés par la réglementation en vigueur. A l’issu de ce cas d’utilisation, des fiches préétablies sont générées automatiquement pour être ensuite distribuées aux différents acteurs qui constituent la commission technique. Durant la réunion de cette dernière, des discussions sont entamées quant à la faisabilité du projet attesté par la demande d’autorisation.

Générer les autorisations : des fiches pré-remplies sont générées automatiquement, suivant chaque type de demande.

Taxation des dossiers : dans ce cas d’utilisation, l’agent fonctionnel procède à la taxation du dossier, ceci en supposant que ce dernier a été validé par la commission technique. La taxation se fait en respectant des règles de gestion bien précises qui diffèrent selon la nature de projet et son métrage.

Générer les fiches de taxation : ce cas d’utilisation permet d’avoir des fiches de taxation qui renseignent sur les détails de l’opération, en détaillant les calculs adoptés ainsi que la somme à payer.

58 | P a g e



Consulter les tableaux de bord : des tableaux dynamiques recensant différentes statistiques sont à la disposition du chef de la division, lui permettant d’avoir une visibilité sur l’ensemble des opérations en cours.

3- Diagramme des classes

Ce diagramme représente les classes nécessaires pour assurer un bon

fonctionnement du système à mettre en œuvre.

Diagramme 5 : Diagramme des classes

Les pétitionnaires peuvent avoir maintes demandes d’autorisation, et les agents à la division de l’urbanisme peuvent bénéficier des maintes fonctionnalités pour gérer le mieux possible le flux d’information qu’ils traitent.

III. Technologies mises en œuvre

1- PostgreSQL

PostgreSQL est un système de gestion de base de données relationnelle et

objet(SGBDRO). C'est un outil libre disponible selon les termes d'une licence de type BSD.

59 | P a g e



Ce système est concurrent d'autres systèmes de gestion de base de données, qu'ils soient

libres (comme MySQL et Firebird), ou propriétaires (comme Oracle, Sybase, DB2, Informix et

Microsoft SQL Server). Comme les projets libres Apache et Linux, PostgreSQL n'est pas contrôlé

par une seule entreprise, mais est fondé sur une communauté mondiale de développeurs et

d'entreprises. PostgreSQL peut stocker plus de types de données que les types traditionnels

entiers, caractères, etc. L'utilisateur peut créer des types, des fonctions, utiliser l'héritage de type

etc. PostgreSQL est pratiquement conforme (de plus en plus conforme) aux normes ANSISQL 89,

SQL 92 (SQL 2), SQL 99 (SQL 3), SQL:2003 et SQL:2008. Il fonctionne sur diverses plates-formes

matérielles et sous différents systèmes d'exploitation.

Figure 24 : PostgreSQL

PostgreSQL fonctionne sur Solaris, SunOS, Mac OS X, HP-UX, AIX, Linux, IRIX, Digital

Unix, BSD, NetBSD, FreeBSD, OpenBSD, SCO unix, NeXTSTEP, UnixWare et toutes sortes d'Unix.

Depuis la version 8.0, PostgreSQL fonctionne également nativement sur Windows. Avant la version

8, il fallait un émulateur de type cygwin pour faire fonctionner PostgreSQL sur ce système

d'exploitation.

PostgreSQL est largement reconnu pour son comportement stable, proche d’Oracle. Mais

aussi pour ses possibilités de programmation étendues, directement dans le moteur de la base de

données, via PL/pgSQL. Le traitement interne des données peut aussi être couplé à d'autres

modules externes compilés dans d'autres langages. - [docs.postgresqlfr.org , Rapport PFE Hamli]

2- Choix de l’outil de l’ETL

Source de

données 1

Source de

données n

Entrepot

Source de

Donnée

ETL

Figure 25 : ETL

60 | P a g e



Les processus ETL (Extraction, Transformation et Chargement) sont les composants les plus

critiques - et les plus importants – pour l’alimentation d’un data warehouse ou d’un système

décisionnel. Bien que cachés de l’utilisateur de la plate-forme décisionnelle, les processus ETL

rassemblent les données à partir des systèmes opérationnels et les pré-traitent pour les outils

d’analyse et de reporting. La précision et la vitesse de la plateforme décisionnelle toute entière

dépendent des processus ETL, notamment :

L’extraction de données des applications et des bases de données de production (ERP,

CRM, SGBDR, fichiers, etc.)

La transformation de ces données pour les réconcilier entre les différentes sources, pour

effectuer des calculs ou du découpage de texte, pour les enrichir avec des données

externes et aussi pour respecter le format requis par les système cibles (Troisième Forme

Normale, Schéma en Etoile, Dimensions à Evolution Lente, etc.)

Le chargement des données résultantes dans les différentes applications décisionnelles :

DataWarehouse ou Enterprise DataWarehouse, Data Marts, applications OLAP (Online

Analytical Processing) ou “cubes”. – [Site officiel de Talend]

3- Pentaho Data Integration

Figure 26 : logo de Pentaho

PDI (Pentaho Data Integration), qui était auparavant connu sous le nom de Kettle, est un

logiciel d’ETL (Extract, Transform, Load) Open Source qui permet la conception ainsi que

l’exécution des opérations de manipulation et de transformation de données très complexes.

Pentaho Data Integration prépare et croise les données afin de créer une vision complète de votre

entreprise qui génère des informations exploitables. La plate-forme complète d'intégration des

données fournit aux utilisateurs finaux des données précises «prête pour l'analytique » à partir de

n'importe quelle source.

Parmi ses fonctionnalités principales, on trouve :

Outil d’ETL (extraction, transformation et chargement) graphique pour charger et traiter les sources de Big Data avec des moyens familiers.

Vaste bibliothèque de composants préconfigurés permettant d'accéder aux données et de les transformer à partir d'une gamme de sources complète.

Interface visuelle permettant d'appeler du code personnalisé et d'analyser des images et des fichiers vidéo afin de créer des métadonnées utiles.

61 | P a g e



Transformations dynamiques au moyen de variables pour déterminer les règles de mappage, de validation et d'enrichissement des champs.

Débogueur intégré à des fins de test et de mise au point de l'exécution des tâches. - [Site officiel

de Pentaho]

4- Générateur des rapports

Il existe plusieurs moteurs de rapport dans OpenERP, pour produire des rapports à partir

de différentes sources et dans de nombreux formats.

Figure 27 : Processus de génération de rapport

Voici un tableau récapitulatif des moteurs de rapport utilisables avec OpenERP :

Nom du moteur de

rapport

Module Mainteneur Outil de conception des

rapports

Formats de sortie possibles

RML Intégré dans le serveur OpenERP + module officiel base_report_designer. C'est le moteur par défaut. Il ne sera plus utilisé à partir d'OpenERP 8.0.

OpenERP S.A. Codage manuel en RML ou conception dans OpenOffice

SXW, HTML, PDF, TXT

QWeb Intégré dans le serveur OpenERP 8.0 ; c'est le moteur utilisé dans les rapports officiels d'OpenERP 8.0.

OpenERP S.A. Codage manuel

HTML, PDF, TXT

Jasper Projet openerp-jasperserver de Syleam ou projet openobject-jasper-reports de NaN-tic

Syleam(intégrateur français) et NaN-tic (intégrateur espagnol)

Jasper iReport

Tous les formats supportés par Jasper

Aeroo Module communautaire report_aeroo

Alistek(intégrateur Letton)

LibreOffice Tous les formats supportés par LibreOffice : ODT, PDF, HTML, DOC, ...

Tableau2 : moteurs de rapport OpenERP

Le moteur de rapport par défaut d'OpenERP est basé sur le langage RML (Report Markup

Language), qui est un standard mis au point par la société anglaise ReportLab. Nous avons

choisi de l’utiliser tout en utilisant OpenOffice pour la conception des rapports. –

[www.people.via.ecp.fr/~alexis/openerp/#intro]

https://launchpad.net/openerp-jasperserver

https://launchpad.net/openobject-jasper-reports

https://launchpad.net/openobject-jasper-reports

http://www.syleam.fr/

http://www.nan-tic.com/

http://www.nan-tic.com/

http://jasperforge.org/projects/ireport

http://jasperforge.org/projects/ireport

https://launchpad.net/aeroo

http://www.alistek.com/

http://www.libreoffice.org/

http://www.reportlab.com/

62 | P a g e



5- OpenOffice

Figure 28 : logo de OpenOffice.org

OpenOffice.org est un projet né le 13 octobre 2000 à l'initiative de Sun Microsystems en

vue de produire un intégré bureautique libre fondé sur StarOffice. Le produit résultant est diffusé

sous le même nom et sous plusieurs licences (la LGPL et, jusqu’à la version 2.0beta2 incluse,

la SISSL), et fonctionne sur plusieurs plates-formes dont Windows, de

nombreux Unix : Linux, Solaris, ou Apple Mac OS X. Le but énoncé est d'offrir une alternative à la

suite bureautique propriétaire Microsoft Office à laquelle OpenOffice prendra une part de marché

significative.

Dans le cadre de sa politique de transparence, le format de stockage utilisé par OOo sera dès la

version 2.0 conforme au format ouvert OpenDocument, adopté par l’organisme de

normalisation OASIS, puis par l’ISO, comme format bureautique de référence. OOo permet

également l'export au format PDF. Afin de faciliter l'interopérabilité, OOo permet l'import des

formats Microsoft.

Figure 29 : logo de Apache OpenOffice

ApacheOpenOffice est issu du projet OpenOffice.org lancé par Sun Microsystems puis repris par Oracle Corporation. À la suite de la scission intervenue entre Oracle et la communauté OpenOffice, le projet original s'est alors scindé en deux branches distinctes :

la branche Oracle qui a conservé le nom OpenOffice.org, mais diffuse le produit sous le nom Apache OpenOffice,

la branche communautaire, au sein de la fondation The Document Foundation, qui diffuse le produit sous le nom LibreOffice.

Peu après cette scission, Oracle abandonne le projet et cède ses droits, y compris le nom OpenOffice.org, à la fondation Apache. Le projet prend alors le nom Apache OpenOffice et rejoint l'incubateur de projet Apache avant de devenir un projet officiel de la fondation en octobre 2011. Le projet reçoit alors le soutien d'IBM qui a également annoncé son intention de faire don d'une partie de Lotus Symphony.

63 | P a g e



Afin d'assurer l'interopérabilité avec les autres suites bureautiques, les documents sont enregistrés sous le format ouvert OpenDocument de l’organisme de normalisation OASIS, puis par l’ISO. L’exportation en fichier Portable Document Format (PDF) est disponible pour produire des documents à des fins de publications.

Le logiciel permet également l'import des fichiers aux formats Microsoft Office.

Comme le tronc commun dont il est issu, AOO comporte six modules :

Writer, traitement de texte.

Calc, tableur.

Impress, module de présentation.

Draw, le module de dessin.

Base, le module de bases de données.

Math, l'éditeur d'équation mathématique.- [Site officiel de OpenOffice]

6- Langages et outils de programmation

6.1- Python

Python est un langage de programmation multi-paradigme. Il favorise la programmation

impérative structurée, et orientée objet. Il est doté d'un typage dynamique fort, d'une gestion

automatique de la mémoire par ramasse-miettes et d'un système de gestion d'exceptions ; il est

ainsi similaire à Perl, Ruby, Scheme, Smalltalk et Tcl.

Le langage Python est placé sous une licence libre proche de la licence BSD et fonctionne sur

la plupart des plates-formes informatiques, des supercalculateurs aux ordinateurs centraux, de

Windows à Unix en passant par Linux et Mac OS, avec Java ou encore .NET. Il est conçu pour

optimiser la productivité des programmeurs en offrant des outils de haut niveau et une syntaxe

simple à utiliser. Il est également apprécié par les pédagogues qui y trouvent un langage où la

syntaxe, clairement séparée des mécanismes de bas niveau, permet une initiation plus aisée aux

concepts de base de la programmation.

Figure 30 : logo de Python

64 | P a g e



Python est un langage :

Conçu pour produire du code de qualité, portable et facile à intégrer : grâce à sa syntaxe

claire, cohérente et concise, Python permet aux développeurs de produire du code de qualité,

lisible et maintenable. Écrire du code Python est un exercice agréable, même en respectant les

conventions de codage. Fourni dès le départ avec des modules de tests, Python est un langage

agile. Le terme agile est originellement issu de la méthodologie de programmation agile (Beck et

Al.), très proche de la programmation itérative. Cette méthodologie, qui réduit les risques liés à la

conception de logiciels, introduit entre autres des principes de tests continus du code.

De haut niveau, orienté objet et totalement libre : même si elle n’est pas imposée, Python

permet la programmation orientée objet. Tous les mécanismes objet essentiels sont implémentés

et toutes les données manipulées sont des instances de classes, comme pour les langages

SmallTalk ou Ruby. Enfin, le code peut être structuré en modules (fichiers) qui sont ensuite

importables dans l’interpréteur. Ce découpage, permet d’organiser le code et son utilisation par

des espaces de noms, et aussi de faciliter l’extension du langage par des bibliothèques tierces

compilées dans d’autres langages.

Hautement productif : La conception d’applications en Python est très rapide car certains

aspects de programmation sont gérés automatiquement, comme la gestion des ressources

mémoire et le typage des données. Grâce à des types de base très puissants et des primitives de

haut niveau, un programme Python est simple à concevoir et concis. Un programme Python est en

général 3 à 5 fois plus court qu’un programme C++ équivalent. Ces qualités font de Python un

langage idéal dans beaucoup de domaines. Enfin, la bibliothèque standard de Python est très

complète, et permet de répondre aux besoins communs de programmation. Grâce au modèle

Open Source, la communauté des développeurs Python est en outre très productive et de

nombreuses extensions gravitent autour du langage.

Dynamique : dans la plupart des implémentations, le code source n’est pas compilé

contrairement à des langages comme C ou Pascal, mais exécuté à la volée. On parle alors de

langage interprété. Ce mode de fonctionnement rend la programmation beaucoup plus souple

puisqu’il est possible de changer un programme en cours d’exécution, ou de tester du code en

mode interactif sans disposition particulière. L’interprétation rend aussi l’exécution plus lente,

mais ce défaut est surmontable grâce à de bonnes pratiques de programmation et des techniques

d’optimisation. [Site officiel de Python, Rapport de Hamli]

6.2- XML (eXtensible Markup Language)

Figure 31 : XML

65 | P a g e



XML (eXtensible Markup Language) est en quelque sorte un langage HTML amélioré

permettant de définir de nouvelles balises. Il s'agit effectivement d'un langage permettant de

mettre en forme des documents grâce à des balises (markup).

Contrairement à HTML, qui est à considérer comme un langage défini et figé (avec un

nombre de balises limité), XML peut être considéré comme un métalangage permettant de définir

d'autres langages, c'est-à-dire définir de nouvelles balises permettant de décrire la présentation

d'un texte. La force de XML réside dans sa capacité à pouvoir décrire n'importe quel domaine de

données grâce à son extensibilité. Il va permettre de structurer, poser le vocabulaire et la syntaxe

des données qu'il va contenir.

En réalité les balises XML décrivent le contenu plutôt que la présentation (contrairement À

HTML). Ainsi, XML permet de séparer le contenu de la présentation, ce qui permet par exemple

d'afficher un même document sur des applications ou des périphériques différents sans pour

autant nécessiter de créer autant de versions du document que l'on nécessite de représentations.

XML a été mis au point par le XML Working Group sous l'égide du World Wide Web Consortium

(W3C) dès 1996. Depuis le 10 février 1998, les spécifications XML 1.0 ont été reconnues comme

recommandations par le W3C, ce qui en fait un langage reconnu.

XML est un sous ensemble de SGML (Standard Generalized Markup Language), défini par le

standard ISO8879 en 1986, utilisé dans le milieu de la Gestion Electronique Documentaire (GED).

XML reprend la majeure partie des fonctionnalités de SGML, il s'agit donc d'une simplification de

SGML afin de le rendre utilisable sur le web !

XML fait partie du code des modules composants OpenERP, les vues par lesquelles sont

représentés les différents objets sont écrites en XML, ainsi nous y trouvons la description détaillée

de l’affichage des arbres, formulaires, menus et autres actions. [Introduction à XML - Comment Ça

Marche]

IV. Interfaçage « Archos-Urbanisme » & « Massira Smart-City » de UrbaSoft

1- Présentation générale

La société UrbaSoft

Figure 32 : logo Urbasoft

Urbasoft , filiale à 100% de Capital Consulting Group, est un éditeur de solutions de cartographie GIS / GPS

(système d’information géographique / géo-positionnement).

66 | P a g e



Objectif & Stratégie

Le module Urbanisme présente un applicatif complet qui permet de gérer le processus des

demandes d’autorisation de construction, lotissement ou morcèlement de bout en bout. Tenant

compte de l’opération de la taxation ainsi que de celle de la délivrance des permis d’habiter.

Le projet Massira Smart-City porte sur la mise en place d’une application mobile pouvant

dialoguer avec un serveur central en communicant des données géographiques. Le projet, comme

son nom l’indique, présente aux collectivités locales ainsi qu’à un multiple d’organismes étatiques

la chance et la possibilité de passer à un autre niveau de gestion du domaine territorial.

Idée Clé :

Lors de nos différentes rencontres nous avons saisi le besoin du chef de la division

d'Urbanisme qui porte sur l'affichage de toutes les opérations en cours sur une carte. Ce qui va lui

permettre entre autres de repérer facilement l’opération qu'il veut et par suite avoir part de

toutes les informations relatives à cette dernière.

Ayant assisté à une présentation et des séances de notes aux locaux d’UrbaSoft, nous

avons pu conclure une pré-architecture du système qui représente un terrain de convergence

entre nos deux applicatives.

Figure 33 : Architecture du système unifié

Le module Urbanisme dispose de toutes les informations nécessaires, il dispose même de

deux champs décrivant avec exactitude la parcelle terrestre qui fait l’objet de l’opération. L’équipe

d’UrbaSoft quant à elle, a un savoir faire en tout ce qui est géo localisation, et pour ancrer les

opérations sur une carte, elle n'a besoin que de deux valeurs, la latitude, et la longitude, que nous

offrons déjà. La divergence entre les deux solutions -en termes de technologie- nous a amené à

proposer une communication simple -entre nos deux bases de données- via les deux valeurs clés

pour la géo-localisation de l'opération en cours, à savoir, la latitude, et la longitude. L’équipe

d’UrbaSoft récupère une table préalablement faite par le biais d’un ETL « Pentaho Data

Integration », et transpose les enregistrements sur une carte qui leurs est propre.

Administration

Tableau de Bord, Reporting

CARTE GEOGRAPHIQUE

Module 1 Module 2 Module n

Base de données Unifiée (Postgre SQL)

67 | P a g e



2- Architecture technique proposée

L’équipe UrbaSoft a travaillé sur une connexion reliant leur application avec OpenERP.

L’utilisateur peut désormais se rediriger vers OpenERP et ce depuis l’interface de Massira Smart-

City. Le schéma ci-après élucide la manière avec laquelle les deux applicatifs vont communiquer,

en backoffice.

Figure 34 : Architecture technique proposée

3- Charte Graphique

Lors de son authentification, l’utilisateur ne doit pas sentir qu’il y a existence de deux

applicatives. Il était donc question d’unifier la charte graphique entre OpenERP et Massira Smart-

City.

Pour ce faire, nous nous sommes basés sur les couleurs que porte le logo de l’application,

qui englobera en quelque sorte les différents modules OpenERP.

Conclusion

Après avoir détaillé l’analyse et la réalisation technique de notre module, ainsi que

l’interfaçage avec l’application Massira-Smart City, nous allons éclaircir davantage le

fonctionnement du module en détaillant le processus par une simulation.

OpenERP

DB

Plusieurs

Tables

ETL Inter DB

ETL

Plusieurs

Tables

Table Unique

UrbaSoft

DB

68 | P a g e



Chapitre5

Installation et Simulation

Nous essaierons à travers ce 5ème chapitre de

présenter l’état final du module Massira-Urbanisme

en détaillant les différentes phases de l’utilisation. Ce

chapitre est amplement illustré avec des captures

d’écrans pour être en mesure de découvrir de près

notre solution.

69 | P a g e



I. Installation du module Massira-Urbanisme

Dans cette partie, nous allons vous faire part d’un aperçu du module que nous avons

développé, et qui répond à l’intégralité des exigences du métier de l’urbanisme de la CU de

Kenitra.

Bien évidement, il a été décidé vers la fin de converger notre applicatif avec l’application

Massira Smat City, c’est la raison qui nous a mené à travailler tout d’abord sur une charte

graphique commune, rendant unanime l’identité visuelle des deux solutions.

Figure 35 : Ecran d’accueil

Après avoir placé le dossier « Demandeur » dans le dossier « Addons », le module apparait

dans la liste des modules non installés. Après l’avoir installé, des renseignements sur ce dernier

sont disponibles et sont facilement consultables.

70 | P a g e



Figure 36 : Le module Massira-Urbanisme

II. Simulation

1- Enregistrements

Une fois connecté, l’agent fonctionnel consulte la liste des enregistrements préalablement

effectués. Les informations apparaissant, peuvent être facilement paramétrées.

Figure 37 : Liste des Enregistrements

L’outil de recherche très puissant lui donne la possibilité de chercher un enregistrement par

n’importe quel attribut. L’attribut par défaut est le nom, mais l’agent peut toutefois chercher un

dossier par l’information dont il dispose : son titre foncier, le CIN de son pétitionnaire…

71 | P a g e



Figure 38 : Filtre et option de recherche

Nous avons aussi mis à la disposition de l’agent une fonctionnalité lui permettant de trier

les dossiers par leurs états de décision (relatifs à la commission technique). De cette manière,

l’utilisateur peut se repérer facilement entre les dossiers dont l’état est approuvé, refusé ou

encore pas défini.

2- Renseignement sur une demande

Une fois un pétitionnaire présenté, l’agent se met à l’enregistrement de sa demande. Pour

ce faire, il commence par renseigner sur la nature de la personne à la demande d’autorisation, s’il

s’agit d’une personne physique ou morale, et puis sur son nom et prénom et CIN ou registre de

commerce et siège principal, selon les cas.

Pour raison de rendre les choses beaucoup plus claires et succinctes, il nous est paru

judicieux de faire profiter l’agent de deux menu liste, un premier pour les personnes physique, et

un autre pour les sociétés ou autres. Ces deux menus apparaissent suivant le choix du statut :

Morale ou Physique.

Figure 39 : Renseignement sur la Personne Physique

72 | P a g e



Figure 40 : Renseignement sur la Personne Morale

Après avoir renseigné sur le pétitionnaire, l’agent passe à une seconde étape qui porte sur

le renseignement de la demande d’autorisation.

Figure 41 : Formulaire pétitionnaire

73 | P a g e



Figure 42 : Formulaire de la demande d’autorisation

L’agent commence par renseigner des informations générales sur la demande

d’autorisation. Il passe après à une rubrique dédiée à la localisation de la parcelle terrestre (voir

III) qui fera objet de la transformation. Il indique aussi l’architecte responsable de la construction

et vers la fin, nous avons mis sur place une check liste des documents à fournir, dynamique et qui

change selon chaque type de demande. Un numéro d’inscription est automatiquement attribué à

la demande d’autorisation, ce dernier est unique.

Figure 43 : Check List Dynamique-PP

74 | P a g e



Figure 44 : Check List Dynamique-GP

Une fois l’enregistrement terminé, le pétitionnaire acquiert un récépissé faisant foi de son

action de déposition.

Ce dernier, depuis un simple click, donne toute information susceptible de décrire le mieux la

demande d’autorisation. Il est complet, rempli, renseigné, et contient même une liste des

documents non présentés par le pétitionnaire. Vers la fin nous trouvons le visa de l’agent qui

atteste de l’exactitude des données dans le récépissé.

Les rapports sont d’autant plus personnalisés, et affichent l’identité visuelle de la CU de Kenitra.

75 | P a g e



Figure 45 : Récépissé de demande d’autorisation de Construction.

3- Taxation

La commission réunie différent intervenant pour décider du sort de la demande. Si cette

dernière est approuvée, elle est taxée.

Nous avons donc mis à la disposition des agents fonctionnels responsables de la taxation

un outil leurs facilitant cette opération laborieuse. En effet, cette opération se fait à la

traditionnelle, un agent s’occupe de la définition du métrage, un autre effectue les calculs, et un

troisième élabore la facture. L’applicative proposée allège la procédure, en sollicitant l’interaction

avec un et un seul agent, au lieu de trois.

L’Agent commence par créer une nouvelle taxe, et récupère la demande qui fera objet de

la taxation.

76 | P a g e



Juste après, il renseigne le métrage et autre champs complémentaire. Il revient vers le

même formulaire pour indiquer la date de paiement et la date de retrait de la demande

d’autorisation de construction.

Figure 46 : Formulaire Taxation

Il est à noter que l’agent ne renseigne sur le paiement et le retrait que lors d’une seconde

interaction avec le même formulaire.

L’agent rend au pétitionnaire une fiche indiquant le montant dû avec un détail clarifiant la

manière avec laquelle le calcul a été fait.

Suite à la demande d’un agent fonctionnel de la CU de Kenitra , nous avons mis le total en chiffres

et en lettres dans la fiche de taxation. Le calcul du total se fait en interne, suivant la

réglementation en vigueur.

77 | P a g e



Figure 47 : Fiche de taxation

Le pétitionnaire paye le montant indiqué dans la fiche et retourne pour récupérer son

dossier, et commencer ses travaux.

4- Permis d’habiter

Les travaux achevés, le détenteur du bien foncier peut bien y habiter. Nous ne traitons pas

le cas ou il s’agit d’une exploitation commerciale ou autre, ceci est l’apanage de la police

administrative.

La personne désirant avoir un permis d’habiter se dirige vers le même guichet pour

déposer sa demande. La procédure est similaire à celle de l’obtention de l’avis favorable de

construction. Le pétitionnaire doit attendre le passage d’une commission qui attestera que les

travaux effectué respectent bien les jeux de plan et les prescriptions relatifs au code général de

l’urbanisme.

78 | P a g e



Figure 48 : Permis d’habiter

Par cette action, la démarche d’obtention d’un permit de construire et d’habiter est close.

Figure 49 : Fiche Permis d’habiter

79 | P a g e



5- Géo-localisation de la Parcelle terrestre :

Nous avons mis à la disposition de l’utilisateur la possibilité de repérer facilement la parcelle

terrestre qui fait objet de l’opération de construction, et ce, en cliquant sur un bouton que nous

avons mis à sa disposition. Le bouton « Map » est lié, dans un premier temps pour des raisons

d’essai, à la plateforme Google Maps qui nous permet à l’agent fonctionnel de situer précisément

l’emplacement de la parcelle terrestre dont il est question. Cette opération présente l’avantage de

pouvoir récupérer les coordonnées spatiales de la parcelle, à savoir la latitude et la longitude.

Figure 50: Lien vers Google Maps

Figure 51 : Localisation de la Parcelle Terrestre

6- Tableau de bord

Nous avons avancé d’un autre pas, et travaillé sur la mise en place d’un tableau de bord

faisons état des dossiers traités dans cette division. Nous avons donc généré des graphes qui sont

automatiquement actualisés et qui donnent une meilleure visibilité de l’activité de la division de

l’Urbanisme. Les statistiques présentées par cet outil relevaient auparavant du domaine de

l’impossible.

80 | P a g e



Ce tableau de bord présente d’une manière synthétique l’information qui pourrait

intéresser le top management de la commune. Parmi les graphes générés, nous trouvons les

montants de taxations par mois, le nombre de dossiers déposés par mois, le nombre de dossiers

traités par architecte, le pourcentage des dossiers approuvés et celui des dossiers rejetés, et enfin

les dossiers par type et par nature. La liste est loin d’être exhaustive, et ce panneau de graphe

n’est qu’un exemple de ce que nous pouvons générer.

Figure 52 : Tableau de Bord

Nous avons travaillé aussi sur l’ajout d’autres tableaux de bord pour les exploiter dans un

prochain module. Il est pour nous question de faire parler les données, pour assurer à la division

une meilleure maitrise de son domaine opérationnel.

III. Jeux de Test

1- Les Test

L’étape du test fait objet d’une activité très importante qui a comme but de nous

rapprocher du « zéro défaut » de notre applicative. Les jeux de test prennent s’accapare

généralement de 40% des tests.

81 | P a g e



Cycle de développement des tests :

Figure 53 : Jeux de test

2- Test : « Boite Noire »

Le test de la boîte noire est utilisé en programmation informatique et en génie logiciel, pour

tester un programme en vérifiant que les sorties obtenues sont bien celles prévues pour des entrées

données.

Principe :

- On considère le programme dans son aspect fonctionnel et non plus structurel.

- On partitionne le domaine (DE) en classes.

- On génère des cas de test aux limites de classe.

Conclusion

Nous avons essayé, à travers ce dernier chapitre, de mettre en exergue la réalisation de

notre module en simulant une demande d’autorisation. Et ce, pour pouvoir parcourir le processus

métier de bout en bout.

82 | P a g e



Conclusion générale

Ce stage fut pour nous l’occasion de côtoyer le monde des entreprises, et plus

spécifiquement celui des éditeurs de logiciel et des cabinets de conseil. Nous avons découvert que

les plus grandes réussites commencent toujours par une idée, qui laisse après place à la créativité

de ses porteurs pour garantir sa concrétisation et sa réussite.

Le travail que nous avons mené permettra aux communes urbaines d’opérer efficacement.

Nous avons pu faciliter les tâches relatives aux services de l’urbanisme, et ainsi leur donner la

possibilité de mieux servir leurs clients, qui ne sont autre que nos concitoyens.

Nous avons commencé par une quête torride de l’information. Nous nous sommes

déplacés aux différents locaux de la CU de Casablanca pour détecter un besoin spécifique, tirer

part d’une problématique et travailler sur la proposition d’une solution. Nous avons ensuite

détaillé le processus relatif à l’urbanisme, et développé un module OpenERP qui facilite la gestion

des demandes d’autorisation de construction. Il y a eu lieu après, la première réunion avec la CU

de Kenitra, qui a donné naissance à une suite d’ateliers fonctionnels pour adapter notre module à

leurs exigences métiers.

Le module Massira-Urbanisme clôturé, nous avons entamé l’étude fonctionnelle d’un

autre service, celui de la police administrative. Nous avons parvenu à délimiter le contour

fonctionnel de leurs métiers, et travaillé sur la charte graphie d’OpenERP pour l’adapter à

l’application Massira Smart-City.

La responsabilité était de taille dans ce trajet de longue haleine. Nous étions en amont de

l’équipe informatique et cela nous mené à rentrer en contact direct avec des personnes que nous

nous connaissions point, mais que nous avions à travailler avec.

Outre le savoir faire technique, nous avons appris, de la part de nos encadrants, l’art de

valoriser son travail, de gagner la confiance et la sympathie de son client, ainsi que de cultiver le

dynamisme, prendre l’initiative et d’être force de proposition.

La volonté de voir un Maroc nouveau, était la force motrice de notre motivation de percer

et de réussir cette première partie de ce projet. En effet, notre pays n’a plus le choix entre

entreprendre une politique contemporaine de développement ou pas, il doit s’assurer de la

convergence de ses mécanismes avec la vague mondiale de modernisation. Dans ce contexte, nos

perspectives se ramène à couvrir en SI l’ensemble du métier des Collectivités locales, leurs

donnant ainsi l’outil nécessaire et indispensable aux pouvoir locaux pour atteindre leurs objectifs

stratégiques, sociaux et économiques.

83 | P a g e



Bibliographie

Bibliographie

ERP, méthode pratique de mise en œuvre pour PME et PMI- Philippe Jouffroy (2010)

Recueil des Norme de l’Etat, Trésorerie General du Royaume.

Maroc Numérique 2013, MICNT, 2013.

Bonnes Pratiques Intérieur – Collectivité Locales, Ministère de l’Intérieur, 2012.

Guide Juridique des Collectivités Locales – Ministère de l’Intérieur, 2012.

Apprenez à Programmer en Python, OpenClassroms, 2012.

Tutoriel OpenERP V 6.0.3 –Thierry Godin 2012

Tutoriel OpenERP V 7.0 – Thierry Godin-2013

OpenERP Memento Technique-Thierry Godin -2013

Politique OpenSource, SMILE, 2013

Guide OpenSource, SMILE, 2013

Rapport PFE de Ait Mellouk Addi, Faculté des Sciences de Marrakech, 2013.

Rapport PFE de Ghandi Othmane, INPT, 2013.

Rapport PFE de Hamli Merouane, Ensa Tanger, 2012

Cours UML – Pierre Gérard

Webographie

www.openmairie.org Documentation officiel d’OpenMairie.

www.glmaroc.org, Site Officiel du Projet Gouvernance Locale Maroc.

www.openerp.com, site officiel d’OpenERP.

OpenERP Google Communauté, Communauté OpenERP dans google

Openoffice.org Site Officiel de l’utilitaire du « reporting » OpenOffice.

www.kenitra.ma

www.openclassrooms.com

www.people.via.ecp.fr/~alexis/openerp/#intro

www.erpfacts.drupalgardens.com/blog

www.hcp.ma

Sites officiels de Talend, Pentaho, OpenOffice et Python.

Introduction à XML - Comment Ça Marche

docs.postgresqlfr.org/

http://www.commentcamarche.net/contents/1332-introduction-a-xml

84 | P a g e



Table des matières

Dédicace ........................................................................................................................................ 3

Dédicace ........................................................................................................................................ 4

Remerciements ............................................................................................................................. 5

Résumé .......................................................................................................................................... 6

Abstract ........................................................................................................................................ 7

8 ............................................................................................................................................. ملخص

Avant-propos ................................................................................................................................. 9

Liste des abréviations .................................................................................................................. 10

Liste des figures .......................................................................................................................... 11

Sommaire .................................................................................................................................... 14

Introduction générale .................................................................................................................. 15

Première partie ........................................................................................................................... 16

Chapitre 1 .................................................................................................................................... 17

Présentation de l’organisme d’accueil ....................................................................................... 17

I. Présentation de Archos Technology ................................................................................. 18

1-Métiers de Archos Technology ................................................................................. 18

2-Stratégie de développement .................................................................................... 20

3-Références ................................................................................................................ 21

Conclusion ................................................................................................................................... 21

Chapitre 2 .................................................................................................................................... 22

Présentation du cadre général du projet .................................................................................... 22

I. Présentation du client final ............................................................................................... 23

1-Organisation territoriale du Maroc .......................................................................... 23

1.1-Collectivités Locales ....................................................................................... 24

1.2-Commune Urbaine ......................................................................................... 25

2-Ateliers de définition du besoin ............................................................................... 26

2.1-Commune urbaine de Casablanca ................................................................. 26

2.2-Commune urbaine pilote de Kenitra ............................................................. 27

II. Problématique ................................................................................................................. 31

III. Objectifs du projet .......................................................................................................... 31

85 | P a g e



IV. Conduite générale du projet .......................................................................................... 32

1-Enjeux du projet........................................................................................................ 32

2-Indicateurs de performance ..................................................................................... 32

3-Suivi des enjeux ........................................................................................................ 33

4-Démarche d’implémentation d’un ERP .................................................................... 34

5-Notion de prototypage ............................................................................................. 36

6-Planification du déroulement du projet ................................................................... 38

7-Rôles et responsabilités ............................................................................................ 39

Conclusion ................................................................................................................................... 40

Deuxième partie .......................................................................................................................... 41

Chapitre 3 .................................................................................................................................... 42

Analyse fonctionnelle .................................................................................................................. 42

I. Cartographie SI des collectivités locales ........................................................................... 43

II. Processus Métier ............................................................................................................. 44

1-Division de l’urbanisme ............................................................................................ 44

* Processus ........................................................................................................ 44

2-Service de la Police Administrative ........................................................................... 45

* Processus ........................................................................................................ 45

III. État de l’art en termes de SI ........................................................................................... 45

1-Division de l’urbanisme ............................................................................................ 45

2-Service de la Police Administrative ........................................................................... 46

Conclusion ................................................................................................................................... 46

Chapitre 4 .................................................................................................................................... 47

Analyse et réalisation technique ................................................................................................. 47

I. Choix du progiciel de Gestion Intégré .............................................................................. 48

1-Etude détaillée de OpenMairie ................................................................................. 48

2-Benchmark des PGI ................................................................................................... 50

2.1-OpenERP ........................................................................................................ 51

II. Analyse et conception UML ............................................................................................. 56

1-UML........................................................................................................................... 56

2-Diagramme de cas d’utilisation ................................................................................ 57

3-Diagramme de classes .............................................................................................. 58

86 | P a g e



III. Technologies mises en œuvre ........................................................................................ 58

1-PostgreSQL ................................................................................................................ 59

2-Choix de l’outil de l’ETL ............................................................................................. 59

3-Pentaho Data Integration ......................................................................................... 60

4-Génération des rapports........................................................................................... 61

5-OpenOffice ................................................................................................................ 62

6-Langages et outils de programmation ...................................................................... 63

6.1-Python ............................................................................................................ 63

6.2-XML ................................................................................................................ 64

IV. Interfaçage de « Massira-Urbanisme » et « Massira-Smart City » ........................... 65

1-Présentation générale .............................................................................................. 65

2-Architecture technique proposée ............................................................................. 67

3-Charte graphique ...................................................................................................... 67

Conclusion ................................................................................................................................... 67

Chapitre 5 .................................................................................................................................... 68

Installation et simulation ............................................................................................................. 68

I. Installation du module « Massira-Urbanisme » .............................................................. 69

II. Simulation ........................................................................................................................ 70

1-Enregistrements........................................................................................................ 70

2-Renseignement sur une demande ............................................................................ 71

3-Taxation .................................................................................................................... 75

4-Permis d’habiter ....................................................................................................... 77

5-Géo-localisation de la parcelle terrestre .................................................................. 79

6-Tableaux de bord ...................................................................................................... 79

III. Jeux de test ..................................................................................................................... 80

1-Les Tests .................................................................................................................... 80

2-Test : « Boite Noire » ................................................................................................ 81

Conclusion ................................................................................................................................... 81

Conclusion générale .................................................................................................................... 82

Bibliographie ............................................................................................................................... 83

Table des matières ...................................................................................................................... 84

87 | P a g e



Annexes ....................................................................................................................................... 88

Annexe 1 .............................................................................................................................. 89

Annexe 2 .............................................................................................................................. 91

Annexe 3 .............................................................................................................................. 93

Annexe 4 ............................................................................................................................. 99

88 | P a g e



Annexes

Annexe1 : ORGANIGRAMME-TYPE ADAPTE à LA COMMUNE URBAINE DE

CASABLANCA

Annexe 2 : TYPES DE DEMANDES AVEC LES DOCUMENTS A FOURNIR

Annexe 3 : INSTALLATION d’OPENERP v7 : LINUX ET WINDOWS

Annexe 4 : UTILISATION d’OPENOFFICE REPORT DESIGNER

89 | P a g e



Annexe 1 :

ORGANIGRAMME-TYPE ADAPTE à LA COMMUNE

URBAINE DE CASABLANCA

90 | P a g e



ROYAUME DU MAROC

MINISTERE DE L’INTERIEUR

DIRECTION GENERALE DES COLLECTIVITES

LOCALES

91 | P a g e



Annexe 2 :

Type des demandes avec les documents à fournir

92 | P a g e



Les Grand Projets : les projets à réaliser par ou pour les administrations, les collectivités

locales, les établissements et les entreprises publiques, qu'il s'agisse de projets destinés à

l'exercice de leurs activités principales ou de projets à caractère secondaire par rapport à

leurs activités principales. Entrent dans cette rubrique, à titre indicatif et non limitatif, les

projets de construction et d'aménagement des lotissements et des bâtiments plus que R+3.

Les petits Projets : Les projets de construction à usage d'habitation ou professionnels. Ne

doivent pas dépasser R+3.

Les Petits Travaux : Les projets de modification de petite envergure.

Documents à fournir selon type de demande :

Type de la demande Documents à Fournir

Petits Projets

Certificat de propriété, Plan cadastral, Tirage

de Plan, Contrat d’architecte, Photocopie

CIN OU Statuts de la Société, Engagement du

Propriétaire, Demande d'autorisation, Cahier

de Chantier.

Grands Projet

Certificat de propriété, Plan cadastral, Tirage

de Plan, Contrat d’architecte, Photocopie

CIN OU Statuts de la Société, Engagement du

Propriétaire, Demande d'autorisation, Cahier

de Chantier, Note de renseignement, Plan

de Coté.

Petits Travaux.

Certificat de propriété, Engagement du

Propriétaire, Photocopie CIN OU Statuts de

la Société, Accord du Syndique.

Tableau 3 : documents à fournir

93 | P a g e



Annexe 3:

Installation d’OpenERP v7: Linux & Windows

94 | P a g e



Installation d’OpenERP v7 : Linux & Windows

1. La démarche d’installation d’OpenERP Sous linux (distribution ubuntu):

1.1. Créer un utilisateur OpenERP

Dans un premier temps on se connecté en tant que root sous le terminale linux et on crée un

nouveau utilisateur « openerp » :

1.2. Installer le package PostgreSQL

Après l’ajout de l’utilisateur « openerp » on Install le serveur de base de donne postgresql et

pgadmin3 pour simplifier la gestion à l’aide des interfaces graphique fourni par pgadmin3 :

1.3. Créer l'utilisateur de base de donne OpenERP

Dont le terminal on se connecte en tant que postgres.

On crée l’utilisateur de base de donnée « openerp »

1.4. Installer les dépendances

L’utilisation d’OpenERP nécessite un ensemble des bibliothèques python on les installe

comme suit :

sudo adduser --system --home=/opt/openerp --group openerp

sudo apt-get install postgresql

sudo apt-get install pgadmin3

sudo su postgres

createuser --createdb --username postgres --no-createrole --no-superuser --pwprompt

openerp

95 | P a g e



Sinon l’ors de l’installation d’OpenERP toutes les dépendances python sont installer

automatiquement (c’est l’avantage d’utilisation d’Openerp sous linux par rapport à Windows

qui oblige l’installation de ces dépendances manuellement).

1.5. Télécharger la dernière version de OpenERP

Toutes les versions d’open source OpenERP sont disponible sur les sites suivant dans notre

cas (linux ubuntu) on va télécharger le paquet « openerp_7.0-20130302-002131-1_all.deb »

https://www.openerp.com/en/pricing

https://launchpad.net/openobject/

http://nightly.openerp.com/7.0/nightly/deb/

Après le téléchargement du paquet on cherche le paquet et on vérifier s’il n’est pas installer

et après on lance l’installation :

1.6. Flash plugin

Votre navigateur doit avoir le plugin Flash installé, car OpenERP Web utilise des Composants

Flash.

2. La démarche d’installation d’OpenERP Sous windows (toutes les versions):

2.1 Installation d’OpenERP et Postgresql

OpenERP fonctionne en mode Saas (Software as a service, en fait logiciel en ligne) ou en

mode client/serveur. Je vous conseille de l’utiliser en mode « logiciel en ligne » pour deux

raisons

apt-get install python-dateutil python-feedparser python-gdata python-ldap \

python-libxslt1 python-lxml python-mako python-openid python-psycopg2 \

pythonpybabel python-pychart python-pydot python-pyparsing python-reportlab \

pythonsimplejson python-tz python-vatnumber python-vobject python-webdav \

pythonwerkzeug python-xlwt python-yaml python-zsi python-docutils \ python-psutil

bzr

wget python-unittest2 python-mock

sudo dpkg -i `find . -type f -name '*.deb'`

sudo apt-get -f install

Sudo apt-get install flashplugin-nonfree

96 | P a g e



il suffit d’installer sur un PC (ou un serveur) le serveur et le serveur web … et c’est

tout, pas d’installation sur les autres PC, l’utilisation du logiciel se fait avec un

navigateur web.

L’interface graphique est plus « actuelle ».

En cliquant sur le programme d’installation, tout est automatisé, l’installation du Server, du

Web client ainsi que le gestionnaire de base de données.

Il suffit de cliquer sur SUIVANT, à chaque étape de l’installation.

Figure 54 : Lancement de l’installation

Conservez et notez le nom d’utilisateur et le mot de passe nécessaire lors de l’installation.

Pour accéder au logiciel en mode Web il faut simplement ouvrir un navigateur web et saisir

l’adresse suivante : http://localhost:8069

2.2 Installation des composants postgresql

Afin d’exploiter les base de donnes du SGBD postgresql il fout installer un ensemble des

outils à savoir le serveur Apache PHP et phpPgadmin qui permet d’exécuter les scriptes PHP.

Puis pgAgent qui permet de planifier les taches en fonction du temps choisie (la sauvegarde

97 | P a g e



automatique de base de données). Pour procédé l’installation on utilise « stackbuilder » qui

existe par défaut dans le dossier d’installation de postgresql.

C:\Program Files (x86)\OpenERP 7.0-20130302-002131\PostgreSQL\bin

Figure 55 : Lancement de l’installation de PostgreSQL.

Figure 56 : Fin de l’installation

98 | P a g e



c) Contrôle des services :

Figure 57 : Utilitaire de contrôle des services.

Vous pouvez contrôler l’état des services OpenERP et Postgresql via l’interface suivant :

Figure 58 : Serveur OpenERP

99 | P a g e



Annexe 4 :

Utilisation d’OpenOffice Report Designer

100 | P a g e



Annexe 4 : Utilisation d’OpenOffice Report Designer.

Dans cette partie, nous allons essayer de détailler la connexion entre OpenERP et

OpenOffice, l’utilitaire avec lequel nous concevons et gênerons des rapports.

Pour commencer, il faut installer OpenOffice et un module permettant la connexion

avec ce dernier dans OpenERP.

Les reports seront conçus dans OpenOffice, et donc nous avons besoin de télécharger

une extension OpenERP et la mettre dans le bon emplacement.

Figure 59 : Plug-in OpenOffice Report Designer.

1. Installation de l’extension

Pour Installer le module O.O Report Designer, nous ouvrons OpenOffice Writer, puis « Extension

Manager » dans le menu>Tools> Extension Manager. Nous cliquons sur le bouton « Add », et nous

cherchons le fichier que nous avons préalablement téléchargé. Nous redémarrons OpenOffice pour

que le changement prenne effet.

101 | P a g e



Figure 60 : La fenêtre de «extension Manager » après installation du Plug-in.

2. Configuration

Avant de commencer la création de nos rapports, nous créons une connexion vers le

serveur OpenERP, puis vers une base de données. Le rapport puisera essentiellement son

contenu de cette DB.

Figure 61 : Connexion vers le serveur & puis vers la Base de données

102 | P a g e



3. Création Ou Modification d’un Rapport

Une fois connecté au serveur, et à une base de donnés, nous avons accès à toutes les

tables qui y font partie. Nous entrons dans OpenERP>Create a new report ou

OpenERP>Modify an existing Report selon notre souhait.

Nous choisissons le modèle sur lequel va pointer notre rapport, et nous commencer la

création de ce dernier.

Figure 62: Sélection du modèle dans la base de données.

Une fois nous avons notre propre rapport, nouvellement crée ou modifié, nous

retournons au même menu pour cliquer cette fois sur « Send to the server ».

Figure 63 : Envoie du rapport au serveur OpenERP.

4. Alimentation du rapport en donnée

Pour récupérer les donnée de vos modèle et les transposer sur votre rapport, il y’a deux

manière de faire :

Soit vous repérer dans la barre principal un « Add Loop » pour pointer sur le model,

et puis « Add Field » pour ajouter un champ.

103 | P a g e



Soit que vous écrivez des petites fonctions qui feront appel à vos donner lors de

l’impression de votre rapport.

Voici un exemple de rapport qui clarifie le second point :

Figure 64 : Création de rapport à l’aide des fonctions.

104 | P a g e



FIN.

Merci pour votre lecture