Rapport de PFE mastère PRO

Dédicaces
Je dédie ce projet de fin d’études à mes parents pour leur soutien tout au long
de mes études.
Un coucou a mes frères, sœur, amis et tous ceux qui m’ont encouragé.
Remerciements
Au terme de ce projet de fin d’études, je voudrais remercier ceux qui ont
contribué, de prés ou de loin pour l’élaboration de mon projet, et particulièrement
M. Nouri KHALIFA pour ses directives pertinentes, sa disponibilité et son support.
De même je voudrais remercier le responsable du mastère professionnel
«Génie Logiciel et Développement Rapide d’Application» M. Chiheb CHAIEB et
tous les membres qui ont contribué à l’ouverture de ce mastère.

Résumé
L'objectif principal de ce travail de PFE consiste à développer une application
web en rapport avec la municipalité de Tunis. Cette application permet la gestion
des demandes des citoyens, souhaitant construire ou procéder à des travaux de
restauration d'une construction déjà existante, dans le but d'obtenir un permis de
bâtir.
Mots-clés : Node.JS, Angular.JS, Bootstrap, REST API, HTML5, CSS, SQL
Server
Abstract
This final of studies project aims to develop a web application on the
municipality of Tunis. This application allows the management of requests from
citizens wishing to build or undertake restoration of an existing building, which
aims to obtain a building permit.
Keywords : Node.JS, Angular.JS, Bootstrap, REST API, HTML5, CSS, SQL
Server

Sommaire
Dédicaces....................................................................................................................1
Remerciements...........................................................................................................1
Résumé........................................................................................................................2
Abstract .......................................................................................................................2
Introduction générale...............................................................................................10
Chapitre N° 1 : Cadre et contexte du projet .........................................................12
1 Introduction.......................................................................................................13
2 Présentation de l'organisme d'accueil ............................................................13
2.1 Présentation de la municipalité ...............................................................13
2.2 Organigramme de la municipalité de Tunis ..........................................14
3 Objectifs du projet............................................................................................15
3.1 Présentation du projet...............................................................................15
3.2 Planification du projet ..............................................................................15
3.3 Critique et problématique ........................................................................15
3.4 Solution proposée et cahier de charges ..................................................16
3.5 Méthodologie et formalismes adoptés ...................................................16
4 Environnement matériel et logiciel................................................................17
5 Conclusion.........................................................................................................18
Chapitre N° 2 : Etude préliminaire ........................................................................19
1 Introduction.......................................................................................................20
2 Spécifications des besoins...............................................................................20
2.1 Les besoins fonctionnels ..........................................................................20
2.2 Les besoins non fonctionnels ..................................................................23
3 Spécifications techniques ................................................................................24
3.1 Architecture de l'application....................................................................24
3.2 Architecture adoptée.................................................................................25

3.3 Les technologies de la couche présentation...........................................26
3.4 Les technologies de la couche persistance.............................................28
4 Comparaison .....................................................................................................28
5 Les frameworks utilisés :.................................................................................29
5.1 Node.js........................................................................................................29
5.2 Angular.JS .................................................................................................30
5.3 SPA.............................................................................................................30
5.4 Bootstrap....................................................................................................30
5.5 Express v4..................................................................................................30
5.6 REST API ..................................................................................................30
5.7 JWT (JSON Web Token).........................................................................31
5.8 npm .............................................................................................................31
5.9 Bower .........................................................................................................31
6 Conclusion.........................................................................................................31
Chapitre N° 3 : Conception préliminaire ..............................................................32
1 Introduction.......................................................................................................33
2 Analyse globale de l’application ....................................................................33
2.1 Description des acteurs ............................................................................33
2.2 Identification des cas d'utilisation...........................................................33
2.3 Diagramme de cas d'utilisation général .................................................34
3 Diagramme de cas d'utilisation : Gestion X..................................................35
4 Description formelle : diagramme de séquence système ............................36
4.1 Diagramme de séquence : Ajouter une demande..................................37
4.2 Diagramme de séquence : Modifier une demande ...............................38
4.3 Diagramme de séquence : Supprimer une demande.............................39
5 Les principales interfaces de l'application existante ....................................40
La principale interface de l'application existante ........................................40
5.1 L'interface de gestion des documents.....................................................41
5.2 La fenêtre de recherche d'un dossier ......................................................42

5.3 La fenêtre de gestion des rues .................................................................43
6 Conclusion.........................................................................................................43
Chapitre N° 4 : Conception détaillée.....................................................................44
1 Introduction.......................................................................................................45
2 Conception de l’interface de l’application ....................................................45
3 Conception de la couche métier .....................................................................46
4 Le diagramme de classe...................................................................................46
5 Conception détaillée : Gestion d’une demande ............................................48
5.1 Conception des interfaces : Gestion d’une demande............................48
5.2 Diagramme de séquence détaillé : Ajouter une demande....................49
5.3 Diagramme de séquence détaillé : Modifier une demande..................50
5.4 Diagramme de séquence détaillé : Supprimer une demande...............51
5.5 Diagramme de navigation : Gestion des demandes..............................52
6 Conclusion.........................................................................................................52
Chapitre N° 5 : Réalisation.....................................................................................53
1 Introduction.......................................................................................................54
2 Les interfaces réalisées de l'application.........................................................54
2.1 Interface d'authentification ......................................................................54
2.2 La partie de droite du tableau de bord....................................................55
2.3 La partie de gauche du tableau de bord..................................................56
2.4 La fenêtre de recherche d'un dossier ......................................................57
2.5 La fenêtre de gestion des architectes......................................................58
2.6 La fenêtre d'ajout d'une demande ...........................................................59
2.7 La fenêtre pour la confirmation d’une suppression..............................60
3 Conclusion.........................................................................................................61
Conclusion générale ................................................................................................62
Bibliographie............................................................................................................63
Nétographie ..............................................................................................................63

Annexes.....................................................................................................................64
Glossaire....................................................................................................................66

Liste des figures
Figure 1 : Organigramme de la municipalité de Tunis .......................................14
Figure 2 : Diagramme prévisionnel du projet ......................................................15
Figure 3 : Cycle de vie UP......................................................................................17
Figure 4 : Architecture 3-tiers................................................................................24
Figure 5 : L'architecture 3-tiers..............................................................................25
Figure 6 : Architecture adoptée pour le développement de l'application .........26
Figure 7 : Architecture Angular.JS........................................................................27
Figure 8 : Comparaison entre les différentes technologies de la couche
présentation ........................................................................................................................28
Figure 9 : Comparaison entre les différentes technologies de la couche métier
.............................................................................................................................................29
Figure 10 : Les utilisateurs de l'application..........................................................34
Figure 11 : Diagramme de cas d'utilisation général ............................................35
Figure 12 : Cas d'utilisation : Gestion X...............................................................36
Figure 13 : Diagramme de séquence ajouter une demande ................................37
Figure 14 : Diagramme de séquence modifier une demande .............................38
Figure 15 : Diagramme de séquence supprimer une demande ..........................39
Figure 16 : L'interface principale de l'application existante...............................40
Figure 17 : L'interface de gestion des documents................................................41

Figure 18 : Fenêtre de la recherche d'un dossier..................................................42
Figure 19 : Fenêtre de la gestion des rues.............................................................43
Figure 20 : Schéma de l'application à développer ...............................................45
Figure 21 : Schéma de la couche sercvice ............................................................46
Figure 22 : Le diagramme de classe de l'application ..........................................47
Figure 23 : l'interface ajouter une demande .........................................................48
Figure 24 : Diagramme de séquence détaillé : Ajouter une demande ...............49
Figure 25 : Diagramme de séquence détaillé : Modifier une demande ............50
Figure 26 : Diagramme de séquence détaillé : Supprimer une demande..........51
Figure 27 : Diagramme de navigation : Gestion demande .................................52
Figure 28 : Diagramme réel de réalisation ...........................................................54
Figure 29 : Interface d'authentification .................................................................54
Figure 30 : La partie de droite de l'application réalisée......................................56
Figure 31 : La partie de gauche de l'application réalisée....................................57
Figure 32 : Fenêtre réalisée pour la recherche d'un dossier................................58
Figure 33 : Fenêtre réalisée pour la gestion des architectes...............................59
Figure 34 : Fenêtre réalisée pour la gestion d'une demande...............................60
Figure 35 : Fenêtre réalisée pour la confirmation de suppression.....................61

Liste des tableaux
Tableau 1 : Les abréviations............................... Error! Bookmark not defined.
Tableau 2 : Les différents concepts Angular.JS...................................................28
Tableau 3 : Les différents rôles des acteurs..........................................................33

10
Introduction générale
L'application actuelle de gestion des permis de bâtir de la municipalité de Tunis
présente certaines anomalies qui laissent les utilisateurs peu satisfaits.
C’est dans cette optique, que nous avons essayé de trouver une solution
informatique en développant une application web basée sur des nouvelles technologies
afin de remédier aux anomalies de cette application.
Une première version de l’application a été créée en 2005 par la société SIS
(Software Informatic Solutions) sous l'environnement de développement visual studio
2005, mais cette application présente différentes anomalies d’où l’insatisfaction des
utilisateurs. Ces anomalies se résument aux points suivants :
 Les données ne sont pas à jour,
 Le temps d'exécution de l'application est élevé,
 Les interfaces sont trop chargées et les informations ne sont pas bien
structurées,
 En cas de panne les utilisateurs du siège sont immobilisés.
Le contexte de notre projet est de proposer une solution web permettant d’avoir
une application web, avec des interfaces plus conviviales et rapide en termes
d’exécution.
Ce rapport présente l’ensemble des étapes suivies pour développer notre
application. Il contient cinq chapitres organisés comme suit :
Le premier chapitre intitulé «Cadre et contexte du projet» est consacré à la
présentation de l’organisme d’accueil ainsi que le contexte du projet.

11
Dans le chapitre «Etude préliminaire», nous déterminerons les besoins
fonctionnels et non fonctionnels de notre application ainsi que les spécifications
techniques, l’environnement de travail et les outils utilisés.
Le chapitre «Conception préliminaire» s’articule autour des diagrammes de
séquences de notre application, les différents cas d'utilisations et les principales
interfaces graphiques de l'application existante.
Le quatrième chapitre intitulé «Conception détaillée» détaille les différents
aspects conceptuels de l’application.
Le dernier chapitre intitulé «Réalisation» illustre le travail effectué à travers
quelques interfaces graphiques réalisées dans notre application.
En conclusion, nous mentionnons les atouts et les perspectives du projet.

12
Chapitre N° 1 : Cadre et contexte du projet

13
1 Introduction
Le présent chapitre a pour objectif de présenter l’organisme d’accueil (la
municipalité de Tunis) et les problèmes qui nous ont poussés à élaborer ce projet.
2 Présentation de l'organisme d'accueil
2.1 Présentation de la municipalité
Les municipalités ou communes urbaines en Tunisie sont des territoires de
plusieurs centaines d'hectares incluant des espaces urbains et ruraux organisés en
général autour d'une ville principale.
La municipalité de Tunis est à 100% urbaine et comprend quinze
arrondissements.
 Bab Bhar
 La Médina
 Bab souika
 Sidi Béchir
 Essijoumi
 El Omrane
 Cité El khadra
 El Ouardia
 Ezzouhour
 Ettahrir
 El Omrane Superieur
 El Menzah
 Jebel Jelloud
 El Kabaria
 El Hrairia

14
2.2 Organigramme de la municipalité de Tunis
L'organigramme ci-dessous s'inscrit dans le cadre des mesures d'application du
plan de mise à niveau municipal visant à mieux maîtriser et gérer les tâches
municipales en vue d'un meilleur rendement et d'un développement soutenu de la ville.
L'administration municipale de Tunis se compose :
Figure 1 : Organigramme de la municipalité de Tunis

15
3 Objectifs du projet
3.1 Présentation du projet
L'application de permis de bâtir relative au service des affaires urbaines de la
municipalité de Tunis souffre de divers soucis, les utilisateurs sont insatisfaits. Nous
essayons d’apporter une solution à ces problèmes et de réaliser une application en
utilisant de nouvelles technologies existantes sur le marché.
3.2 Planification du projet
La planification est parmi les phases d’avant-projet. Elle consiste à prévoir le
déroulement du projet tout au long des phases constituant le cycle de développement.
Le diagramme de la figure suivante représente le chronogramme prévisionnel de la
réalisation du projet.
Figure 2 : Diagramme prévisionnel du projet
3.3 Critique et problématique
Parmi les insuffisances de l’ancienne application de permis de bâtir, nous citons :
 La maintenance est difficile (sur site),
 La structure de l’interface client ne permet pas une consultation intuitive
des données,
 Le temps d'exécution est très élevé,

16
 L'application doit être installée sur une machine Windows bien
configurée.
3.4 Solution proposée et cahier de charges
Dans un souci de développer une application avec des interfaces plus conviviales
et facile à utiliser nous étions emmenés à :
 Créer une application web,
 Offrir des interfaces riches et conviviales,
 Réduire le temps de réponse de l'application,
 Garantir la sécurité de l'information,
 Utiliser des technologies nouvelles et gratuites.
3.5 Méthodologie et formalismes adoptés
Nous allons adopter la méthode PU (Processus Unifié) comme un processus de
développement logiciel.

17
Le processus unifié est un processus de développement logiciel itératif, centré sur
l'architecture, piloté par des cas d'utilisation et orienté vers la diminution des risques.
C'est un patron de processus pouvant être adaptée à une large classe de systèmes
logiciels et à différents domaines d'application.
Figure 3 : Cycle de vie UP
4 Environnement matériel et logiciel
Pour la réalisation de ce travail, nous avons eu recours aux environnements
suivants.
 Environnement matériel :
Les caractéristiques de la machine utilisée pour la réalisation de ce projet sont :
 Système d'exploitation : Windows 7 professionnel
 Processeur : Intel(R) Core(TM) i3-2370M CPU @ 2.40GHz
 Mémoire vive (RAM) : 6 Go
 Disque dur : 500 Go
 Type du système : 64 bits

18
 Environnement logiciel :
 WebStorm 9.01 : IDE pour le développement des langages NodeJS, AngularJS,
HTML ...
 Microsoft SQL Server 2008 R2 : système de gestion de base de données
relationnel
 Power AMC 15.1 : outil de modélisation
 Adobe Photoshop CS5 : Adobe Photoshop est un logiciel de retouche, de
traitement et de dessin assisté par ordinateur édité par Adobe. Il est
principalement utilisé pour le traitement de photographies numériques.
 Adobe Illustrator CS5 : Adobe Illustrator est un logiciel de création graphique
vectorielle. Il fait partie de la gamme Adobe et peut être utilisé
indépendamment ou en complément de Photoshop, il offre des outils de dessin
vectoriel puissants.
 Gantt Project : Gantt Project est un outil permettant de gérer des projets sur le
modèle des diagrammes de Gantt.
5 Conclusion
Dans ce chapitre nous avons élaboré une vision générale sur l’organisme
d’accueil, et nous avons présenté le contexte général du projet.

19
Chapitre N° 2 : Etude préliminaire

20
1 Introduction
L'étude préliminaire constitue une base de départ pour notre application. La
première étape est consacrée au traitement des besoins spécifiques du projet. La
seconde étape aborde la spécification technique de l'architecture adoptée pour la
réalisation de notre application. La dernière étape, donne une vision générale sur les
frameworks utilisés dans le projet.
2 Spécifications des besoins
Cette partie est une description détaillée des besoins de l’application. Dans ce qui
suit, nous identifions les besoins fonctionnels et les besoins non fonctionnels, ensuite
nous spécifions les besoins techniques.
2.1 Les besoins fonctionnels
L'application de permis de bâtir est constituée de deux grandes parties, la
première partie est consacrée aux arrondissements et la seconde à la direction générale
technique.
En effet, toute personne souhaitant construire ou procéder à des travaux de
restauration dans son bâtiment, est appelé à déposer les pièces et documents
constitutifs de son dossier dans l’arrondissement de l’adresse des éventuels travaux
afin d'obtenir la prestation demandée (autorisation de bâtir, autorisation de démolition,
recollement, …) dans les meilleurs délais.
La seconde partie forme le « noyau » de l'application. Elle est censée introduire
les résultats des études et des commissions de toutes les demandes puis de fournir une
autorisation (permis de bâtir ou autres). Il est à noter que cette application est
développée avec la technologie VB.net (Visual Basic).
L'application qui nous concerne dans ce projet est l'application qui sera utilisée
au niveau des arrondissements, dans laquelle nous essayons d'y introduire toutes les

21
informations nécessaires à la description du projet de construction, tel que les
documents, l'architecte, le(s) propriétaire(s), les rues et les demandes.
Tout d'abord, un citoyen est appelé à procurer toutes les pièces suivantes :
 attestation de propriété,
 une demande sur papier libre signée par l'intéressé,
 un projet de la construction en trois exemplaires,
 une étude relative à l'impact du projet sur l'environnement
 un arrêté d'alignement lorsque la parcelle est contigu au domaine public
routier ou au domaine public maritime,
 un récépissé de la déclaration des revenus imposables des personnes
physiques et des sociétés,
 Un reçu de paiement des impôts relatifs au terrain objet de la construction,
 Plan des différents niveaux,
 Plan des fondations de la construction,
 Plan de situation du terrain.
Toutes ces informations sont regroupées dans un dossier, qui est identifié par un
numéro et une date.
La demande est ensuite étudiée et une fiche d’étude est réalisée.
Enfin, le dossier et la fiche d’étude sont présentés devant une commission
technique qui délibère soit par :
- Le refus du dossier
- L’acceptation conditionnée (nouveau document à livrer, légère modification
dans les plans, accord des voisins,…)
- L’acceptation du dossier et la délivrance d’une autorisation de bâtir.
 Les informations nécessaires liées aux dossiers

22
Le dossier est l'élément qui englobe tous les autres éléments, y compris les
différentes demandes, les déplacements du dossier (lieu physique actuel du dossier),
les rues, l'architecte, les propriétaires.
Un dossier est identifié par :
 Numéro dossier : numéro qui ne dépasse pas 6 chiffres,
 Date inscrit : de type date,
 Permis : liste,
 Type dossier : liste.
o Un dossier peut avoir 1 ou plusieurs demande(s).
 Les informations nécessaires liées aux demandes
Une demande se caractérise par :
 Nature demande : liste,
 Type exemple : liste,
 Nature projet : liste,
 Projet : texte,
 Date demande : date.
o [Une demande est relative à un dossier]
o Un dossier peut avoir 1 ou plusieurs demande(s).
 Les informations nécessaires liées aux documents
 Les informations nécessaires liées aux documents
Un document se caractérise par :
 Libellé document : texte,

23
 Date document : document,
 Référence : texte,
 Description : texte.
o [Un document est relatif à une demande]
2.2 Les besoins non fonctionnels
Après avoir déterminé les besoins fonctionnels, nous présentons ci-dessous
l’ensemble des contraintes à respecter afin de garantir l'efficacité de notre solution,
donc de fournir un produit puissant qui respecte les exigences des utilisateurs et qui
peut faire face à des risques de panne ou de non fonctionnement.
Pour présenter aux utilisateurs une application fiable et rapide, nous avons
identifié les besoins majeurs de l’application.
Les principaux besoins non fonctionnels de notre application se résument dans
les points suivants :
 L’ergonomie :
Les interfaces doivent être simples et conviviales.
 La performance :
L’application doit répondre à toutes les exigences des utilisateurs d’une manière
rapide et optimale.
 La sécurité :
Le système doit être fiable et assure la sécurité des données.
 La modularité :

24
Avoir un code simple et facile à maintenir en cas de besoin.
3 Spécifications techniques
Nous expliquons dans cette partie les différentes spécifications : les architectures,
les techniques et les outils utilisés dans notre application.
3.1 Architecture de l'application
Figure 4 : Architecture 3-tiers
Notre application est d'une architecture 3-tiers. Le principe de cette architecture
est simple. Il consiste à séparer la solution en trois couches (couche présentation,
couche métier et couche de persistance) :

25
Figure 5 : L'architecture 3-tiers
 Couche présentation :
La couche présentation est l'interface d’un utilisateur, elle permet à ce dernier de
piloter l'application et d'en recevoir des informations.
 Couche métier
Cette couche est indépendante de toute forme d'interface avec l'utilisateur. Pour
fournir ces services et permettre ainsi l’intégration entre la couche présentation et la
couche de persistance.
 couche persistance
C'est la couche d'accès aux données, qui correspond uniquement à la
préoccupation de la couche accès aux données.
Parmi les avantages que cette architecture propose, c’est la séparation claire et
nette entre les couches, afin de minimiser la charge et centraliser l'information.
3.2 Architecture adoptée
En se basant sur l'architecture 3-tiers et les plateformes adoptées pour la
réalisation du projet, nous illustrons dans le schéma suivant les différentes techniques :

26
Figure 6 : Architecture adoptée pour le développement de l'application
3.3 Les technologies de la couche présentation
Dans la couche présentation on a utilisé les technologies Bootstrap, HTML 5,
CSS 3 et Angular.JS afin de mener à bien notre projet.

27
Figure 7 : Architecture Angular.JS
Dans son architecture, Angular.JS utilise plusieurs concepts, patrons de
conception et des bonnes pratiques incontournables dans le monde du développement
web actuel.
Nous présentons ces différents concepts dans le tableau suivant :
Module C'est un conteneur pour les différentes parties d'une application, y
inclus les contrôleurs, les services et les directives.
Config C'est une fonction importante utilisée pour la configuration de
l'application.
Routes Une des principales raisons pour lesquelles Angular.JS est très
populaire, cette fonctionnalité de routage est la clé pour la création
d'une application dans une seule page.
View C'est la vue, ce que l'utilisateur voit.
Scope Le contexte où le modèle et les fonctions sont stockées pour que les
contrôleurs, les directives et les expressions puissent y accéder.
Controller C'est le contrôleur, la logique métier derrière les vues.

28
Directives Extension du langage HTML, permet de créer des nouveaux attributs
et des éléments personnalisés.
Factories C'est une usine injectable, qui peut retourner une fonction ou un objet.
Services Les services aident à créer des composants réutilisable dans les
modules Angular.JS, ces services pourraient alors être injecté dans un
autre module en utilisant la fonction d'injection de dépendance.
Dependency
Injection
L'injection de dépendance est le responsable d'instancier les différents
composants et de les relier.
Filtres Les filtres sont responsables d’encapsuler toute la logique nécessaire
pour formater des données. Ils sont utilisés souvent au sein des vues.
Tableau 1 : Les différents concepts Angular.JS
3.4 Les technologies de la couche persistance
Sequelize est un ORM conçu particulièrement pour Node.JS. Il prend en charge
les dialectes PostgreSQL, MySQL, MariaDB, SQLite et MSSQL (SQL Server) et
dispose d'un soutien solide de la transaction et les relations.
4 Comparaison
Dans notre projet nous avons essayé d'utiliser des frameworks, qui sont à la fois
évolués et gratuits.
Ainsi, nous avons eu recours à google trends pour être au courant des
technologies les plus utilisées.
Figure 8 : Comparaison entre les différentes technologies de la couche présentation

29
Ce schéma illustre bien que la technologie Angular.js est la plus utilisée à présent
à côté des technologies Backbone.js, Knockout.js et Ember.js.
Figure 9 : Comparaison entre les différentes technologies de la couche métier
La figure ci-dessus montre bien que la technologie JAVA EE était la plus utilisée
en 2005 en comparaison avec les technologies Ruby on Rails et avant l'apparition de
Node.js. De nos jours Node.js se trouve au sommet de ces technologies.
5 Les frameworks utilisés :
5.1 Node.js
Node.js est une plateforme de développement Javascript. Elle utilise la machine
virtuelle V8 et implémente sous licence MIT. Node.js contient une bibliothèque de
serveur HTTP intégrée, ce qui rend possible de faire tourner un serveur web sans avoir
besoin d'un logiciel externe comme Apache, elle permet aussi de mieux contrôler la
façon dont le serveur web fonctionne.
Node.js est de plus en plus populaire comme plateforme serveur, elle est utilisée
par Groupon, SAP, LinkedIn, Microsoft, Yahoo!, Walmart, Rakuten et PayPal…
[2]

30
5.2 Angular.JS
Angular.JS est un framework libre et open source JavaScript développé par
Google. Son objectif principal est de faciliter la réalisation des applications web et
mobiles en simplifiant la syntaxe JavaScript. En outre il propose de solides bases pour
le développement d’application mono-page (SPA - Single Page Application).
5.3 SPA
Une SPA est une application qui une fois chargée, ne nécessite pas un
rechargement total de la page lorsque l’utilisateur interagit avec elle. Cela signifie que
toutes les ressources de l’application (données, templates, scripts et styles) sont
chargées lors de la première requête.
5.4 Bootstrap
Bootstrap est une collection d'outils utile à la création de sites et d'applications
web. C'est un ensemble qui contient des codes HTML et CSS, des formulaires,
boutons, outils de navigation et autres éléments interactifs, ainsi que des extensions
JavaScript en option.
5.5 Express v4
Express est l'un des frameworks les plus populaires dans la communauté
Node.JS, il fournit un ensemble robuste de fonctionnalités pour des applications web et
mobiles.
De même il comprend également une multitude d'utilitaires pour travailler avec
le protocole HTTP et les API de construction.
5.6 REST API
REST (Representational State Transfer) est un style d’architecture qui repose sur
le protocole HTTP, il est possible d'accéder à une ressource à travers son URI
(Uniform Resource Identifier), pour procéder à diverses opérations :

31
 GET : lecture
 POST : écriture
 PUT : modification
 DELETE : suppression
5.7 JWT (JSON Web Token)
JSON Web Token (JWT) est une convention, façon de représenter l'URL d'une
manière sécurisée pour être transférée entre deux parties. Les revendications de JWT
sont codées comme un objet JSON.
5.8 npm
npm est la commande du gestionnaire de paquets installé avec Node.js. Elle
permet de chercher, installer et désinstaller des paquets (modules).
5.9 Bower
Bower est un gestionnaire de paquets pour le web. Il permet d’installer, mettre à
jour et désinstaller simplement, proprement toutes les librairies, scripts dont dépend le
projet web.
6 Conclusion
Nous avons présenté dans ce chapitre une idée sur l’architecture 3-tiers, ainsi
l'architecture à adopter dans notre projet. De plus, nous avons présenté les
technologies à utiliser. Une étude plus approfondie sera présentée dans les prochains
chapitres. La conception préliminaire fera l’objet du chapitre suivant.

32
Chapitre N° 3 : Conception préliminaire

33
1 Introduction
Dans ce chapitre nous abordons la partie conception du projet, dans laquelle,
nous détaillons les différents éléments de conception, à savoir les cas d'utilisation, les
diagrammes de séquences, et le diagramme de classe.
2 Analyse globale de l’application
2.1 Description des acteurs
Cette section a pour objet de présenter les acteurs et les fonctionnalités
auxquelles doit répondre notre application. Ils sont les suivants :
 Le responsable :
Cette personne bénéficie de tous les droits et par conséquent utilise toutes
fonctionnalités de l’application, il est généralement le premier responsable de
l’arrondissement ou la personne qui le représente.
 L’utilisateur :
Cette personne possède les droits du responsable en omettant le droit de la
gestion des utilisateurs.
2.2 Identification des cas d'utilisation
Le tableau suivant résume les opérations qui peuvent être effectuées par les
différents rôles.
Fonctionnalité Utilisateur Responsable
Gestion Dossier X X
Gestion Demande X X
Gestion Document X X
Gestion Architecte X X
Gestion Déplacement X X
Gestion Propriétaire X X
Gestion Utilisateur X
Tableau 2 : Les différents rôles des acteurs

34
Ce schéma présente les utilisateurs de notre système, l'utilisateur et le
responsable.
Figure 10 : Les utilisateurs de l'application
2.3 Diagramme de cas d'utilisation général
Chaque usage que les acteurs font du système est représenté par un cas
d’utilisation.
Chaque cas d’utilisation représente une fonctionnalité qui leur est offerte afin de
produire le résultat attendu.
Ainsi, « le diagramme de cas d’utilisation décrit l’interaction entre le système et
l’acteur en déterminant les besoins de l’utilisateur et tout ce que doit faire le système
pour l’acteur ».
Ci-dessous le diagramme de cas d’utilisation général de notre système :

35
Figure 11 : Diagramme de cas d'utilisation général
3 Diagramme de cas d'utilisation : Gestion X
Le cas d'utilisation (gestion X) est identique pour les différentes entités :
 Gestion dossier,
 Gestion demande,
 Gestion architecte,
 Gestion propriétaire,
 Gestion rue
 Gestion document,
 Gestion déplacement.

36
Figure 12 : Cas d'utilisation : Gestion X
4 Description formelle : diagramme de séquence système
Les diagrammes de séquences sont la représentation graphique des interactions
entre les acteurs et le système selon un ordre chronologique dans la formulation UML.
Dans ce qui suit, nous présentons les diagrammes de séquence pour chaque cas
d’utilisation dans notre système.

37
4.1 Diagramme de séquence : Ajouter une demande
Figure 13 : Diagramme de séquence ajouter une demande

38
4.2 Diagramme de séquence : Modifier une demande
Figure 14 : Diagramme de séquence modifier une demande

39
4.3 Diagramme de séquence : Supprimer une demande
Figure 15 : Diagramme de séquence supprimer une demande

40
5 Les principales interfaces de l'application existante
Nous présentons dans les illustrations ci-dessous quelques interfaces de
l'application existante de permis de bâtir.
Cette application est développée en 2005, avec l'environnement de
développement visual studio 2005.
La principale interface de l'application existante
L'interface ci-dessous est l'interface qui rassemble toutes les informations
relatives aux demandes, dossier, rues, architecte et propriétaires.
Figure 16 : L'interface principale de l'application existante

41
5.1 L'interface de gestion des documents
La gestion des documents relative à une demande est possible à travers l'interface
ci dessous.
En ce qui concerne la modification de la date du document, l'utilisateur doit
appuyez sur la touche F4 et F5, ce qui n'est pas évident pour les nouveaux utilisateurs
de l'application.
Figure 17 : L'interface de gestion des documents

42
5.2 La fenêtre de recherche d'un dossier
La recherche de tel ou tel dossier est accessible à travers la fenêtre illustrée ci-
dessous où nous avons la possibilité de chercher avec certains paramètres.
Figure 18 : Fenêtre de la recherche d'un dossier

43
5.3 La fenêtre de gestion des rues
La fenêtre ci-dessous permettant d'ajouter, modifier ou supprimer des rues.
Figure 19 : Fenêtre de la gestion des rues
6 Conclusion
Dans ce chapitre nous avons identifié les cas d'utilisation, les diagrammes de
séquences et nous avons indiqué quelques interfaces pris de l'application existante de
permis de bâtir.

44
Chapitre N° 4 : Conception détaillée

45
1 Introduction
Dans cette partie nous présentons la conception de quelques interfaces de
l'application, aussi nous exposons les diagrammes de séquence détaillés, le diagramme
de classe et finissant par le diagramme de navigation.
2 Conception de l’interface de l’application
Nous essayons de concevoir une interface claire et simple, dont l'utilisateur n'a
pas besoin de naviguer sur plusieurs onglets ou pages afin de remplir ou consulter les
informations relatives aux projets. Cette interface est à l'instar d'un tableau de bord de
l'application.
Figure 20 : Schéma de l'application à développer

46
3 Conception de la couche métier
Le schéma ci dessous représente la liaison entre l'application et le serveur, dans
laquelle on trouve l'architecture REST.
Figure 21 : Schéma de la couche sercvice
4 Le diagramme de classe
Un diagramme de classes dans le langage de modélisation unifié (UML) est un
type de diagramme de structure statique qui décrit la structure d'un système en
montrant le système de classes, leurs attributs et les relations entre les classes.
Ci-dessous, le diagramme de classe de notre système :

47
Figure 22 : Le diagramme de classe de l'application
Cette figure illustre les principales classes de notre application.
Classe Dossier : est la classe qui contient toutes les informations concernant les
dossiers.
Classe Demande : est la classe qui contient tous les détails relative aux
demandes.

48
5 Conception détaillée : Gestion d’une demande
5.1 Conception des interfaces : Gestion d’une demande
La gestion des demandes est accessible à travers cette fenêtre qui apparait en cas
d'ajout d'une nouvelle demande ou de modification d'une autre existante.
Figure 23 : l'interface ajouter une demande

49
5.2 Diagramme de séquence détaillé : Ajouter une demande
Figure 24 : Diagramme de séquence détaillé : Ajouter une demande

50
5.3 Diagramme de séquence détaillé : Modifier une demande
Figure 25 : Diagramme de séquence détaillé : Modifier une demande

51
5.4 Diagramme de séquence détaillé : Supprimer une demande
Figure 26 : Diagramme de séquence détaillé : Supprimer une demande

52
5.5 Diagramme de navigation : Gestion des demandes
Figure 27 : Diagramme de navigation : Gestion demande
6 Conclusion
Dans cette partie nous avons présenté quelques interfaces conçus pour
l'application, nous avons aussi détaillé les diagrammes de séquences détaillés, le
diagramme de classe ainsi que le diagramme de navigation.

53
Chapitre N° 5 : Réalisation

54
1 Introduction
Dans ce qui suit, nous présentons quelques interfaces réalisées dans notre
application.
Ce schéma représente le chronogramme de notre avancement lors de la
préparation de ce projet.
Figure 28 : Diagramme réel de réalisation
2 Les interfaces réalisées de l'application
2.1 Interface d'authentification
L'interface d'authentification est la face de l'application de permis de bâtir, où
l'utilisateur est appelée à déterminer son arrondissement, login et mot de passe.
Figure 29 : Interface d'authentification

55
2.2 La partie de droite du tableau de bord
L'interface de l'application de permis de bâtir est assez large, nous l’avons
présenté en deux parties (une de droite et une de gauche) afin de mieux faire apparaître
leurs fonctionnalités.
Chaque partie est composée d’un ensemble de panels qui gèrent chacun de son
côté une fonctionnalité de l’application.
Chaque panel dans cette interface possède les boutons de base de gestion entre
autres, l'ajout, la modification et la suppression.
La partie droite de l’interface permet de gérer :
 Dossiers en cours d’utilisation,
 Types de demandes,
 Les architectes.

56
Figure 30 : La partie de droite de l'application réalisée
2.3 La partie de gauche du tableau de bord
Cette partie est celle de gauche de notre application. En haut se trouve une barre
contenant le bouton de déconnexion, le nom de l'utilisateur, son arrondissement ainsi
que ses droits d’utilisation (tel que la gestion des utilisateurs).

57
Figure 31 : La partie de gauche de l'application réalisée
2.4 La fenêtre de recherche d'un dossier
La recherche d'un dossier existant est accessible à travers la fenêtre conçue ci-
dessous, où il existe une fonctionnalité de recherche universelle.

58
Figure 32 : Fenêtre réalisée pour la recherche d'un dossier
2.5 La fenêtre de gestion des architectes
L'ajout ou la modification d'un architecte est possible par cette fenêtre. Pour
affecter un architecte à une demande il suffit de le chercher ou de l'ajouter puis par
l'appui sur le bouton accepter.

59
Figure 33 : Fenêtre réalisée pour la gestion des architectes
2.6 La fenêtre d'ajout d'une demande
Cette fenêtre est conçue pour ajouter ou modifier une demande relative à un
dossier.

60
Figure 34 : Fenêtre réalisée pour la gestion d'une demande
2.7 La fenêtre pour la confirmation d’une suppression
Selon la demande des responsables de la commune de Tunis, une suppression
doit être devancée par une fenêtre de confirmation afin que l’utilisateur puisse prendre
le temps de valider sa décision.
Par conséquent, la suppression d'un quelconque élément du dossier n'est possible
qu'à travers cette fenêtre.

61
Figure 35 : Fenêtre réalisée pour la confirmation de suppression
3 Conclusion
Dans ce chapitre nous avons détaillé les fonctionnalités de base de notre
application à travers un ensemble de captures d’écran.

62
Conclusion générale
L’objectif de ce projet de fin d’études était de concevoir et développer une
application de rechange à celle de la municipalité de Tunis, permettant la gestion des
dossiers de permis de bâtir.
Ce projet nous a donné la possibilité de découvrir de nouvelles approches de
développement web et d’utiliser de nouvelles technologies, telles que Node.JS, ainsi
que les frameworks Angular.JS, REST API et Bootstrap.
L’expérience au sein d’un cadre professionnel, nous a été bénéfique. Ce travail
nous a permis de nous familiariser à la vie professionnelle, d’exploiter des notions
fondamentales et d’approfondir nos connaissances théoriques, acquises à l'institut
supérieur des études technologiques de Sousse. Nous souhaitons que la municipalité de
Tunis adopte réellement notre application et la met en exécution.
Enfin, l’application que nous avons développée pourrait être enrichie par des
fonctionnalités avancées telles, l’utilisation d’un protocole de communication plus
sécurisé que le HTTP comme le HTTPS. Nous pouvons aussi ajouter un module de
messagerie et de discussion instantanée entre les utilisateurs.

63
Bibliographie
Grant, Andrew. 2014. Beginning AngularJS. 2014.
Syed, Basarat Ali. 2014. Beginning Node.js. 2014.
Wahlin, Dan. 2013. AngularJS in 60 Minutes. 2013.
Nétographie
[1] : http://docs.sequelizejs.com/en/latest/
[2] : https://nodejs.org
[3] : http://www.angularjs.org
[4] : http://getbootstrap.com
[5] : http://angular-ui.github.io
[6] : http://nodejs.org
[7] : http://ngmodules.org
[8] : http://nodejs.developpez.com/tutoriels/javascript/node-js-livre-debutant/
[9] : http://www.commune-tunis.gov.tn/publish/content/article.asp?ID=730

64
Annexes
Les articles du code d'aménagement du territoire et de l'urbanisme
Tunisienne :
Art. 68 : Toute personne souhaitant construire, ou procéder à des travaux de
restauration pour conforter une construction déjà existante ou y apporter des
modifications, doit obtenir un permis du président de la municipalité à l'intérieur des
zones communales et du gouverneur pour le reste des zones.
Un plan d'architecture du projet de construction est établi par un architecte inscrit
sur le tableau de l'ordre des Architectes de Tunisie, exceptés les cas fixés par arrêté du
Ministre chargé de L'Urbanisme.
Art. 69 : Les permis visés à l'article 68 du présent code sont délivrés par le
président de la municipalité ou le gouverneur, selon le cas, sous forme d'arrêté après
avis d'une commission technique dont la composition et les modalités de
fonctionnement seront fixées par arrêté du Ministre chargé de l'Urbanisme.
La commission technique est instituée dans chaque gouvernorat ou municipalité
par arrêté du Ministre chargé de l'Urbanisme et sur proposition du Gouverneur ou du
président de la municipalité territorialement compétent.
Le représentant du Ministre chargé de l'Urbanisme peut opposer son veto à la
délivrance du permis et ce conformément aux modalités et délais prescrits par l'arrêté
visé à l'alinéa premier susvisé.
Il est statué sur la demande du permis dans un délai ne dépassant pas quarante
cinq (45) jours à partir de la date de dépôt, à cet effet, d'un dossier dûment constitué :
Ce délai est porté à :
Soixante (60) jours si le plan d'aménagement est en cours d'élaboration ;

65
quatre vingt dix (90) jours si la construction projetée se situe dans la limite de
deux cents (200) mètres autour:
- des sites naturels ;
- des sites culturels et archéologiques
- des zones de sauvegarde ;
- des monuments historiques.
Les permis de bâtir relatifs à l'édification de logements personnels ou familiaux
ou aux logements des ouvriers dans des exploitations agricoles, sont délivrés dans les
mêmes formes et délais prévus ci-dessus après avis du Commissaire régional du
développement agricole.
Les permis de bâtir relatifs aux projets de construction jouxtant des installations
militaires dans une limite de cent cinquante (150) mètres sont délivrés après avis du
Ministre de la Défense Nationale.
Sont délivrés, après avis du Ministre chargé du patrimoine, les permis de bâtir
relatifs aux projets de construction et de restauration à l'intérieur des sites culturels.
L'octroi du permis ne préjuge pas des droits des tiers.
Art. 70 : Ne sont pas soumis à autorisation, les constructions militaires ayant un
caractère secret ainsi que les travaux visant à apporter des modifications ou des
réparations normales et nécessaires à une construction existante et dont une liste est
fixée par arrêté du Ministre chargé de l'Urbanisme, exceptés ceux régis par des
dispositions législatives ou réglementaires spéciales.
Art. 71 : Un arrêté du Ministre chargé de l'Urbanisme fixera les pièces
nécessaires à la constitution du dossier de permis de bâtir, le délai de validité, de ce
dernier de sa prorogation ainsi que les conditions de son renouvellement.

66
Art. 72 : Tout détenteur d'un permis de bâtir est tenu d'afficher à l'entrée du
chantier une pancarte indiquant de manière apparente, le numéro du permis, la date de
sa délivrance, et mentionnant la collectivité publique locale qui l'a octroyé.
Glossaire
API : Application Programming Interface, littéralement interface de
programmation d’application. C’est une façade constituée de classes, méthodes ou de
fonctions permettant l’interraction avec d’autres applications.
CSS : Cascading Style Sheets, littéralement Feuilles de style en cascade, est un
langage qui décrit, notamment, la présentation des documents HTML.
Directive : C’est un composant Angular.JS autonome et réutilisable.
Framework : C'est un ensemble d'outils constituant les fondations d'un logiciel
informatique ou d'applications web, et destiné autant à faciliter le travail qu'à
augmenter la productivité du programmateur.
HTML : HyperText Markup Language, est un format de données visant à
représenter des pages web en écrivant de l’hypertexte.
HTTP : Hypertext Transfer Protocol, littéralement protocole de transfert
hypertexte, est un protocole de communication client-serveur développé pour le web.
JSON : C'est un format de données textuelles dérivé de la notation des objets du
langage JavaScript.
Open source : Logiciel dont le code source est disponible librement et dont
l’utilisation commerciale est possible mais soumise à certaines conditions.
URL : Uniform Resource Locator, littéralement localisateur uniforme de
ressource, couramment appelé adresse web.
Web : C’est ce que l’on appelle le World Wide Web abrégé WWW ou W3, est
un système hypertexte fonctionnant sur l’Internet. On pourra y consulter des pages de
sites en utilisant un navigateur.

Rapport de PFE mastère PRO

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Rapport de PFE mastère PRO

Similaire à Rapport de PFE mastère PRO (20)

Dernier

Dernier (12)

Rapport de PFE mastère PRO