Mise en place d’un Système d’Information pour la gestion des collectivités locales (OpenERP 7)

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

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 soeurs : 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 soeurs, 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 coeur 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éviationsAbré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 oeuvre 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 :

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 oeuvre. 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 oeuvre 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 oeuvre 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 Administrative
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 oeuvre 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 oeuvre 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.

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.

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 oeuvre. 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 oeuvre
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]

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 oeuvre 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/

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 oeuvre ........................................................................................ 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-002131PostgreSQLbin
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

Mise en place d’un Système d’Information pour la gestion des collectivités locales (OpenERP 7)

Contenu connexe

Tendances

En vedette

Similaire à Mise en place d’un Système d’Information pour la gestion des collectivités locales (OpenERP 7)

Mise en place d’un Système d’Information pour la gestion des collectivités locales (OpenERP 7)