Rapport projet de fin d'études licence PFE

Mémoire présenté à la Faculté des Sciences Semlalia de
Marrakech
Licence Techno Web
« Programmation et Technologies Web »
Conception et Réalisation d'une application
D’orientation des locaux
Année Universitaire : 2021-2022
Réalisé par :
AKHATAR Oussama
AHMAM Abderrahmane
Encadré par :
Mr. JARIR Zahi
Mme. LAZAR Hajar

2 | P a g e
Dédicace
A notre raison de vivre, d’espérer,
A notre source de courage, à ceux qu’on a de plus
chères,
Nos petites familles,
Pour leurs sacrifices sans limite,
A nos enseignants
Pour leurs patiences, leurs soutiens
Et leurs encouragements
Et à nos amis
Pour leur témoigner une amitié et fidélité indéfinies.

3 | P a g e
Remerciements
En préambule à ce mémoire, nous remercions Dieu qui nous a aidé et
donné la patience et le courage durant cette longue année d’étude.
Nous souhaitons adresser nos remerciements les plus sincères aux
personnes qui nous ont apporté leur aide et qui ont contribué à l’élaboration
de ce mémoire ainsi qu’à la réussite de cette formidable année
universitaire.
Ces remerciements vont tout d’abord au chef du département
Informatique Mr. JARIR Zahi, et à tous nos enseignants pour la qualité de
formation, et pour les efforts qu’ils ont déployés pour nous transmettre leurs
riches connaissances.
Nous remercions très chaleureusement aussi, Mme. LAZAR Hajar, pour
son encadrement, pour sa confiance et ses encouragements.
Nos remerciements iront également vers tous ceux qui ont accepté
avec bienveillance de participer au jury de ce mémoire.
On n’oublie pas nos parents pour leur contribution, leur soutien et leur
patience.
Enfin, nous adressons nos plus sincères remerciements à tous nos
proches et amis, qui nous ont toujours encouragées au cours de la
réalisation de ce mémoire
Merci à tous et à toutes

4 | P a g e
Résumé
Dans le cadre de notre formation en Licence Professionnelle
Technologies et Programmation Web (LP-TPW), qui s’est déroulée au sein
du département d’informatique de la Faculté des Sciences Semlalia, nous
sommes amenés à passer un stage de fin d’étude. Ceci dans le but de nous
permettre de tirer profit des nombreuses compétences acquises au cours
de cette formation et d’appréhender leurs applications en milieu
professionnel.
L’objectif de ce stage est la conception et la réalisation d'une
application (web et mobile) d’orientation des locaux, cette application
permet aux étudiants et aux invités de l’Université Cadi AYYAD à s’orienter
facilement Aux locaux désirés au sein de la faculté.
L’intérêt principal de ce stage a été la mise en place d’une application
web/mobile, la partie web a été réaliser avec Spring boot Rest API 2.4.1 avec
JDK 11 et Angular TypeScript 13, La partie mobile c’est une Hybrid app réaliser
avec Capacitor 3.5.1 et Angular 13.

5 | P a g e
Table des matières
Dédicace................................................................................................................................................. 2
Remerciements....................................................................................................................................... 3
Résumé .................................................................................................................................................. 4
Introduction Générale............................................................................................................................. 8
ETUDE ET SPECIFICATION DES BESOINS ................................................................................................... 9
I. Introduction :.......................................................................................................................................... 10
II. Cahier de charge..................................................................................................................................... 10
1. Titre du projet : ............................................................................................................................................................... 10
2. Description : .................................................................................................................................................................... 10
3. Objectifs : ........................................................................................................................................................................ 10
4. Exigences : ....................................................................................................................................................................... 10
III. Spécification des besoins..................................................................................................................... 11
5. Spécification des besoins fonctionnels............................................................................................................................ 11
IV. Conclusion .......................................................................................................................................... 12
CONTEXTE GENERAL DU PROJET ........................................................................................................... 13
I. Introduction ........................................................................................................................................... 14
II. Conduite du projet.................................................................................................................................. 14
1. Organisation du projet .................................................................................................................................................... 14
2. Processus de développement ......................................................................................................................................... 15
3. Azure DevOps .................................................................................................................................................................. 15
4. Gestion de source............................................................................................................................................................ 16
III. Conclusion .......................................................................................................................................... 16
ANALYSE ET CONCEPTION..................................................................................................................... 17
I. Introduction ........................................................................................................................................... 18
II. Conception du logo................................................................................................................................. 18
1. Logo + texte..................................................................................................................................................................... 18
2. Logo................................................................................................................................................................................. 18
Notre choix de la boussole dans le logo est une référence au terme direction et orientation. .............................................. 18
III. Description de la méthode de conception utilisée : UML ...................................................................... 19
1. Vue fonctionnelle du système......................................................................................................................................... 19
2. Conception détaille de la base de données..................................................................................................................... 22
IV. Conclusion : ........................................................................................................................................ 22
ENVIRONNEMENT TECHNIQUE.............................................................................................................. 23
I. Introduction ........................................................................................................................................... 24
II. Back Office ( Spring Boot )....................................................................................................................... 24
1. Introduction..................................................................................................................................................................... 24
2. Onion Architecture.......................................................................................................................................................... 24
3. JWT & Spring Security ..................................................................................................................................................... 27
1. Cors Origin....................................................................................................................................................................... 27
2. API Key............................................................................................................................................................................. 29
3. API documentation ( Swagger-UI ) .................................................................................................................................. 29
4. JPA avec Hibernate :........................................................................................................................................................ 30

6 | P a g e
5. Implémentation............................................................................................................................................................... 30
1. PhpMyAdmin................................................................................................................................................................... 31
2. Déploiement.................................................................................................................................................................... 31
3. ReCAPTCHA ..................................................................................................................................................................... 31
III. Front Office ( Angular )........................................................................................................................ 32
1. Introduction..................................................................................................................................................................... 32
2. Les intercepteurs............................................................................................................................................................. 32
3. Les Pipes .......................................................................................................................................................................... 32
4. AdminLTE......................................................................................................................................................................... 32
5. Leaflet.............................................................................................................................................................................. 33
6. Angular DataTable........................................................................................................................................................... 33
7. Bootstrap......................................................................................................................................................................... 34
8. Node Js ............................................................................................................................................................................ 34
9. Npm................................................................................................................................................................................. 34
IV. Mobile................................................................................................................................................ 34
1. Capacitor ......................................................................................................................................................................... 34
V. Algorithme Ray casting ........................................................................................................................... 34
VI. Conclusion : ........................................................................................................................................ 35
I. Introduction ........................................................................................................................................... 37
II. Application web côté Administrateur ...................................................................................................... 37
1. Interface Authentification ............................................................................................................................................... 37
2. Interface Accueil SuperAdministrateur ........................................................................................................................... 38
3. Interface Gestion des utilisateurs.................................................................................................................................... 38
4. Interface Gestion des établissements ............................................................................................................................. 39
5. Interface ajouter établissement...................................................................................................................................... 39
6. Interface modifié établissement ..................................................................................................................................... 40
7. Interface Gestion types des locaux ................................................................................................................................. 40
8. Interface ajouter type de local ........................................................................................................................................ 41
9. Interface Gestion des locaux ........................................................................................................................................... 41
10. Interface ajouter local................................................................................................................................................. 42
11. Interface Modifier local............................................................................................................................................... 42
12. Interface Consultation des messages.......................................................................................................................... 43
13. Consultation du nombre de visite d’un local dans un établissement ......................................................................... 43
III. Application mobile côté Client............................................................................................................. 44
1. Interfaces de l’application mobile................................................................................................................................... 44
IV. Conclusion : ........................................................................................................................................ 44
Conclusion Générale et Perspectives ..................................................................................................... 45
Les références et webographies ............................................................................................................ 46

7 | P a g e
Table des figures
Figure 1 : Scrum Board ............................................................................................................................................14
Figure 2:Backlogs .....................................................................................................................................................14
Figure 3:Scrum framwork.......................................................................................................................................15
Figure 4: Azure DevOps...........................................................................................................................................15
Figure 5 : Azure DevOps Repository....................................................................................................................16
Figure 6 : logo + text ................................................................................................................................................18
Figure 7 : logo.............................................................................................................................................................18
Figure 8 : Diagrammes UML..................................................................................................................................19
Figure 9 : diagramme de cas d’utilisation.......................................................................................................20
Figure 10 : Diagramme de séquence.................................................................................................................21
Figure 11 : Modèle Conceptuel des Données...................................................................................................22
Figure 12 : Illustration de l’Onion architecture.................................................................................................24
Figure 13 : Implémentation de l’architecture Onion .....................................................................................26
Figure 14 : Diagramme de séquence d'authentification ............................................................................27
Figure 15 : Cors Origin..............................................................................................................................................28
Figure 16 : Api Key.....................................................................................................................................................29
Figure 17 : Api Documentation .............................................................................................................................30
Figure 18 : EndPoint Contrôleur de projet .........................................................................................................30
Figure 19 : Plus de fonctionnalités avec Angular & JQuery DataTable...................................................33
Figure 20 : Ray Casting...........................................................................................................................................35
Figure 21 : Interface d'authentification..............................................................................................................37
Figure 22 : Interface Accueil de l’administrateur...........................................................................................38
Figure 23 : Interface gestion des admins.........................................................................................................38
Figure 24 : Interface gestion établissements .................................................................................................39
Figure 25 : Interface ajouter établissement ....................................................................................................39
Figure 26 : Interface consultation des messages .........................................................................................40
Figure 27 : Interface gestion types des locaux ...............................................................................................40
Figure 28 : Interface gestion locaux...................................................................................................................41
Figure 29 : Interface consultation des messages .........................................................................................43
Figure 30 : Consultation de nombre de visite ................................................................................................43
Figure 31 : Interfaces application mobile .........................................................................................................44

8 | P a g e
Introduction Générale
L'informatique est devenue l’épine dorsale de l'entreprise quel que soit
son secteur d’activité, même le secteur de l’éducation, en effet, Et dans ce
sens on s’intéresse à développer des solutions qui permettent d’orienter
facilement Les étudiants, les enseignants et tout usager de l’application,
aux locaux demandés, Nous permettons de gagner de temps et de rendre
la recherche des locaux plus flexible et facile.
Dans ce contexte, la mission de notre stage était la conception et la
réalisation d'une application Pour s’orienter facilement aux différents locaux
de l’université CADY AYYAD.
Ce rapport sera divisé en cinq chapitres. Le premier chapitre sera
consacré à l’étude de périmètre du projet. Dans cette partie, la spécification
des besoins ainsi que la présentation du projet à réaliser seront traitées. Le
deuxième chapitre était pour donne un contexte général de notre projet,
ainsi que les différentes techniques utilisées. Une description de la
conception réalisée fera l’objectif du troisième chapitre. Cette conception
est effectuée à l’aide d’UML. La description du travail réalisé,
l’implémentation feront l’objet du quatrième chapitre. En suit le cinquième
chapitre doit être donné un aperçu sur le travail réalisé. Enfin, nous clôturons
par une conclusion et perspective.

9 | P a g e
ETUDE ET
SPECIFICATION DES
BESOINS

10 | P a g e
I. Introduction :
Dans cette partie, on explique en détail ce que l’application est censée faire et ceci à travers la
spécification des besoins fonctionnels et non fonctionnels.
II. Cahier de charge
1. Titre du projet :
« Conception et réalisation d'une application pour l’orientation des locaux »
2. Description :
L’application se compose à deux différentes parties, il y‘a la partie web et mobile. Dans la partie
web, on traiter la gestion des utilisateurs (les admins), la gestion des établissements, la gestion des locaux,
la gestion des messages envoyées par les étudiants de l’université, ainsi que le tracking d’un local par
établissement.
3. Objectifs :
L’application est accessible par un administrateur (SuperAdmin) qui gère :
• La création des admins avec leurs établissements
• La création des types des locaux
• Les statistiques de nombre de visite des locaux par établissement
Elle est accessible aussi par un Admin qui gère :
• La création des locaux
• Les statistiques des locaux d’établissement qu’il gère,
L’application est accessible par les étudiants, le corps professoral ainsi que par les invités au sein de
l’université afin d’orienter directement et facilement au local désiré en utilisant la version mobile.
4. Exigences :
a. Exigences fonctionnelles :
L'application doit proposer les exigences fonctionnelles suivantes :
Acteur : Super Administrateur
Liste des gestions :
• Gestion des sous admins
• Gestion des établissements de l’UCA
• Gestion des locaux
• Gestion des types des locaux
• Gestion des messages
• Consultation du nombre des visiteurs d’un local
Acteur : Sous Administrateur (Responsable d’un établissement)
Liste des gestions :
• Gestion des locaux dans l’établissement concerné
• Consultation du nombre des visiteurs d’un local dans l’établissement concerné

11 | P a g e
Acteur : Étudiant ou invité
• Ils ont le droit de consulter les locaux de l’établissement concerné
• Envoyer des messages
• Contacter les réalisateurs de l’application
b. Exigences non fonctionnelles :
Après avoir déterminé les exigences fonctionnelles, nous présentons ci-dessous l’ensemble des
contraintes à respecter pour garantir la performance du système tout en respectant les exigences de
l’utilisateur :
• Performance :
Notre application doit assurer un temps de réponse minimum tout en répondant aux besoins du
manipulateur.
• La simplicité :
Chaque utilisateur pourra utiliser cette application d’une manière facile et claire.
• L’ergonomie de l’interface :
Les interfaces doivent être simples et conviviales.
• La modularité de l’application :
Avoir un code simple facile à maintenir et à comprendre en cas de besoin.
• Maintenabilité :
Traçage des erreurs, possibilité des mises à jour, extensibilité modificabilité du système initial, portabilité
en fonction de l’implantation géographique du futur système, testabilité.
• Fiabilité :
Capacité à gérer les erreurs du système, densité des défauts de qualité, capacité à être remis en état
rapidement, capacité à résister aux attaques.
• La Sécurité :
Traçage des mises à jour des données dans le système, gestion de la confidentialité, cryptographie,
journaux d’historiques, gestion de l’intégrité des données, protection des données personnelles.
III. Spécification des besoins
5. Spécification des besoins fonctionnels
La création d’un site web passe par l’élaboration de trois parties, la première partie concerne la
création et la mise en place des pages accessibles par tous les étudiants et les invités, la seconde partie
c’est la configuration et la mise en place de l’espace du sous administrateur responsable d’un
établissement, la troisième c’est la configuration et la mise en place de l’espace du super admin
responsable de l’UCA.
Les fonctionnalités accessibles par les étudiants et les invités peuvent faire :

12 | P a g e
• Consulter les locaux de l’établissement dans lequel ils existent
• Envoyer des messages
• Contacter les réalisateurs de l’application
A traves l’espace d’administration :
• Le sous administrateur peut faire :
✓ Gestion des locaux dans l’établissement concerné
✓ Consultations le nombre des visiteurs d’un local dans l’établissement concerné
• Le super administrateur peut faire :
✓ Gestion des sous admins
✓ Gestion des établissements de l’UCA
✓ Gestion des locaux
✓ Gestion des types des locaux
✓ Gestion des messages
✓ Consultations le nombre des visiteurs d’un local
IV. Conclusion
Cette première partie de ce chapitre a été dédiée à une étude détaillée de l’application : son
objectif, son fonctionnement et son environnement logiciel.
Cette étude nous a permis de distinguer les différents points sur lesquels on va travailler et les
technologies qu’on va utiliser pour réaliser notre application.

13 | P a g e
CONTEXTE GENERAL
DU PROJET

14 | P a g e
I. Introduction
Cette partie constitue la présentation du projet. Contenus la description du projet, les fonctions
qu’il doit assurer. Et elle critique l’existant pour trouver des solutions convenables
II. Conduite du projet
1. Organisation du projet
L’organisation est résumée dans le tableau des Stories suivants Scrum board.
Figure 1 : Scrum Board
Figure 2:Backlogs

15 | P a g e
2. Processus de développement
Nous avons opté pour un cycle de développement agile, qui permet le développement rapide des
applications. SCRUM est une méthode agile dédiée à la gestion des projets. Son objectif est d’améliorer la
productivité des équipes auparavant ralenties par des méthodologies plus lourdes. La démarche propose
un mode de pilotage itératif prenant en compte les évolutions qu’un projet de développement peut subir
en cours de route. Cette méthode ne suit pas un processus prédictif et les travaux à faire sont ajustés
régulièrement au cours du projet, notamment à la fin de chaque itération, appelée << Sprint>>.
Figure 3:Scrum framwork
3. Azure DevOps
Le DevOps est une approche visant à unifier le développement logiciel (dev) et les opérations (ops). Les
principes DevOps privilégient des cycles de développement courts, des tests réguliers, des déploiements plus
fréquents et des livraisons en continu. Des modules sont implantés progressivement en respectant les priorités de
votre entreprise, et ce, tout en augmentant la satisfaction des utilisateurs finaux.
Microsoft Azure DevOps a été créé spécifiquement pour soutenir l’instauration et la croissance d’une culture
DevOps dans les entreprises. Entre autres, cette plateforme facilite la planification des tâches liées à un projet et
favorise la collaboration entre les membres de l’équipe.
Figure 4: Azure DevOps

16 | P a g e
4. Gestion de source
Pour la gestion des versions et le partage des fichiers entre les différents membres de l’équipe, ce
sont GIT qui ont été retenus pour faciliter le travail en groupe.
Figure 5 : Azure DevOps Repository
III. Conclusion
Cette partie a permis de concevoir une idée générale sur notre projet, ce qui nous permettions ensuite
de déterminer nos besoins en outils de développement, afin d’atteindre les solutions définies.

17 | P a g e
ANALYSE ET
CONCEPTION

18 | P a g e
I. Introduction
Penser avant d’agir, faire des plans avant de construire, concevoir d’abord, développer ensuite
c’est la démarche qui doit être suivre lors du développement d’une application et pour réussir n’importe
quel projet.
En effet, ce chapitre est dédié à la conception et la mise en œuvre du système d’information, en
donnant la conception du logo et les diagrammes UML (Cas d'utilisation, Séquences, Classes).
II. Conception du logo
1. Logo + texte
Notre choix de ce nom est dû à l'utilisation de cette application dans n'importe quel établissement et pourquoi pas
dans les grandes surfaces.
2. Logo
Notre choix de la boussole dans le logo est une référence au terme direction et orientation.
Figure 6 : logo + text
Figure 7 : logo

19 | P a g e
III. Description de la méthode de conception utilisée : UML
Pour élaborer cette application et pour attendre le but de notre projet, nous avons choisi le langage
de conception adaptable avec nos besoins : « UML » (en anglais Unified Modeling Language ou langage
de modélisation unifié) c’est un langage de modélisation graphique à base de pictogrammes. Il est
apparu dans le monde du génie logiciel, dans le cadre de la « conception orientée objet ». Couramment
utilisé dans les projets logiciels, il peut être appliqué à toutes sortes de systèmes ne se limitant pas au
domaine informatique.
Les 14 diagrammes UML sont dépendants hiérarchiquement et se complètent, de façon à
permettre la modélisation d'un projet tout au long de son cycle de vie.
1. Vue fonctionnelle du système
c. Identification des acteurs
Les acteurs qui interagissent avec le système sont :
Le sous administrateur : c’est le responsable d’un établissement
Le super administrateur : c’est le grand responsable de l’application qui a tous les droits d’accès
L’étudiant et l’invité : c’est l’utilisateur qui peut consulter les locaux dans son établissement.
d. Diagramme des cas d'utilisation
Ce diagramme permet d'identifier les possibilités d'interaction entre le système et les acteurs
(intervenants extérieurs au système). Il représente toutes les fonctionnalités que le système doit fournir
Figure 8 : Diagrammes UML

20 | P a g e
Figure 9 : diagramme de cas d’utilisation

21 | P a g e
Le super administrateur doit s'authentifier pour avoir accès aux fonctionnalités suivantes :
✓ Gestion des sous admins
✓ Gestion des établissements de l’UCA
✓ Gestion des locaux
✓ Gestion des types des locaux
✓ Gestion des messages
✓ Consultations le nombre des visiteurs d’un local
Le sous administrateur aussi doit s'authentifier pour avoir accès aux fonctionnalités suivantes :
✓ Gestion des locaux dans l’établissement concerné
✓ Consultations le nombre des visiteurs d’un local dans l’établissement concerné
L’étudiant ou l’invité doit s'authentifier par GPS et doit avoir l’accès internet pour avoir accès aux
fonctionnalités suivantes :
✓ Consulter les locaux de l’établissement dans lequel ils existent
✓ Envoyer des messages
✓ Contacter les réalisateurs de l’application
e. Cas d’utilisation authentification Mobile (diagramme de séquence)
Figure 10 : Diagramme de séquence

22 | P a g e
2. Conception détaille de la base de données
a. Modèle Conceptuel des Données
Figure 11 : Modèle Conceptuel des Données
IV. Conclusion :
Dans ce chapitre, nous avons présenté notre étude conceptuelle du système. La vue fonctionnelle
a été illustrée par les diagrammes d’UML.
Ensuite, une vue générale sur le déroulement des cas d’utilisation et leurs exécutions. Dans le
chapitre suivant, nous détaillons quelques aspects de la réalisation.

23 | P a g e
ENVIRONNEMENT
TECHNIQUE

24 | P a g e
I. Introduction
La phase qui suit une conception bien détaillée est éventuellement l’implémentation. Le module
additionnel sera implémenté en tant qu’une application web répondant à plusieurs exigences. En effet, le
projet devrait être orienté objet, développé en Java et JavaScript/TypeScript et utiliser la base de données
existante MySQL.
II. Back Office ( Spring Boot )
1. Introduction
Afin de réaliser notre site, nous avons eu recours à MySQL comme serveur de notre base de
données et à Intellij IDE comme outil de développement. Le Framework Spring Boot est l'environnement
de travail qui sera utilisé durant ce travail.
Spring Boot est un Framework de développement JAVA. C'est une
déclinaison du Framework classique de Spring qui permet essentiellement de
réaliser des micro-services (ce sont la majeure partie du temps des services web
qui sont regroupés en API). Autrement, Spring Boot est un Framework de
développement JAVA permettant la création d'API web.
2. Onion Architecture
L'architecture compile de nombreuses conceptions et principes de code, comme SOLID, des
abstractions stables et autres. Mais l'idée centrale est de diviser le système en niveaux en fonction de la
valeur commerciale. Par conséquent, le niveau le plus élevé a des règles métier, chaque niveau inférieur
se rapprochant des d'E/S.
De plus, nous pouvons traduire les niveaux en couches. Dans ce cas, c'est le contraire. La couche
interne est égale au niveau le plus élevé, et ainsi de suite :
Figure 12 : Illustration de l’Onion architecture

25 | P a g e
Tableau 1 : les couches de l’architecture Onion.
Couches Mappage à
l'architecture d'oignon
Description POJO? Dépend de
Core Modèle objet + services
objet
Couche de domaine avec règles
métier et connaissances : agrégats
racine, entités, référentiels,
événements de domaine, services
de domaine, etc.
X -
API Application services Couche applicative sans règles &
connaissances métier : services
applicatifs, aspects transactionnels,
aspects sécurité, etc.
X Core
Infra Infrastructure Se connecte aux SGBDR, aux bases
de données NoSQL, aux stockages
d'objets, etc. ; consomme des
WebServices ; publie des messages,
des flux d'événements, etc.
Core
Infra-api Infrastructure Sert de point d'entrée à
l'architecture ; fournit des API REST,
des API SOAP, etc. ; met en œuvre
des travaux ; consomme des
messages, des flux d'événements,
etc.
API , Core
UI Interface utilisateur Contient les frontaux hébergés par
cette application Spring Boot (qui
pourrait être basée sur un
Framework Web comme réagir,
angulaire, vue, etc.)
Infra-api
App - L’application Spring Boot qui
enveloppe toutes les autres
couches et produit un package
déployable (JAR/WAR)
UI, Infra-api,
Infra, API, Core
Remarquez la différence entre la couche infra et infra-api : la première consomme des services REST (ou SOAP),
la seconde fournit des services REST (ou SOAP) ! La raison de les avoir dans des couches séparées .

26 | P a g e
Voici le résultat des différentes couches du projet qui illustrent notre convention de nommage :
Figure 13 : Implémentation de l’architecture Onion

27 | P a g e
3. JWT & Spring Security
Pendant longtemps, les cookies ont été utilisés pour identifier
les utilisateurs. Cela fonctionne encore parfaitement aujourd’hui pour
certaines applications. Il est parfois cependant nécessaire de
disposer d’un peu plus de flexibilité. C’est là qu’interviennent les JSON
Web Token. Ce nouveau standard ouvert est de plus en plus pris en charge par les principaux sites Web
et applications.
Authentification avec un JSON Web Token ( JWT ) :
La figure ci-dessous [Figure 7] présente le diagramme de séquence du système du cas d'utilisation
« Authentification»
Figure 14 : Diagramme de séquence d'authentification
1. Cors Origin
Le Cross-Origin Resource Sharing ou CORS (littéralement « partage de ressources entre origines
multiples ») est un mécanisme qui permet à des ressources restreintes d'une page web d'être récupérées
par un autre domaine extérieur au domaine à partir duquel la première ressource a été servie1. Une page
web peut librement intégrer des ressources d'origines différentes telles que des images, des feuilles de
style, des scripts, des iframes et des vidéos2. Certaines "demandes inter-domaine" (en anglais : cross-
domain), notamment les requêtes Ajax, sont interdites par défaut par la politique de sécurité de même
origine (en anglais : same origin security policy).

28 | P a g e
Figure 15 : Cors Origin

29 | P a g e
2. API Key
Une clé d'interface de programmation d'application (API) est un identifiant unique utilisé pour
authentifier un utilisateur, un développeur ou un programme appelant auprès d'une API. Cependant, ils
sont généralement utilisés pour authentifier un projet avec l'API plutôt qu'un utilisateur humain. Différentes
plates-formes peuvent implémenter et utiliser les clés API de différentes manières.
On a utilisé pour protéger les requetés utiliser dans l’application mobile par ce qu’il ne nécessite pas une
authentification.
3. API documentation ( Swagger-UI )
La documentation est une étape très chronophage du développement et, bien souvent, les
personnes extérieures au projet ignorent à quel point celle-ci peut s’avérer utile pour la maintenance et
le développement ultérieur d’un système. On s’en aperçoit plus tard, lorsque ces tâches sont confiées à
d’autres personnes que l’équipe à l’origine du système ; ce qui est davantage la règle que l’exception.
Ainsi, Swagger est vite devenu la technologie la plus appréciée pour la documentation API. Plus
précisément, pour documenter les API REST, très souvent utilisées. Swagger a été développé par Reverb,
mais il s’agit désormais d’une solution indépendante et open source, sous la gouvernance de la fondation
Linux, et plus précisément de l’OpenAPI Initiative. Avec ce changement d’acteurs, Swagger a été rebaptisé
Figure 16 : Api Key

30 | P a g e
« spécification OpenAPI », même s’il reste officieusement connu sous le nom plus accrocheur de
« Swagger ».
4. JPA avec Hibernate :
Configurer Hibernate
Pour que Spring puisse se connecter à la base de données, vous devriez configurer des
paramètres nécessaires dans le fichier application.properties.
1. server:
port: 8080
2. spring:
datasource:
url: jdbc:mysql://${DB_HOST:localhost}:3306/orientationlocation2?createDatabaseIfNotExist=true
username: ${DB_USERNAME:root}
password: ${DB_PASSWORD:}
jpa:
show-sql: true
hibernate:
ddl-auto: update
naming-strategy: org.hibernate.cfg.ImprovedNamingStrategy
properties:
hibernate:
dialect: org.hibernate.dialect.MySQL8Dialect
5. Implémentation
Swagger-ui :
Figure 17 : Api Documentation
Figure 18 : EndPoint Contrôleur de projet

31 | P a g e
1. PhpMyAdmin
Est une application web de gestion pour les systèmes de gestion de base de données MySQL
réalisée principalement en PHP et distribuée sous licence GNU GPL.
2. Déploiement
Pour héberger notre application, nous avions utilisé Heroco pour déployer l'API et la base de
donnee, et pour le côté client, nous avions utilisé Firebase.
a. Heroku
Heroku est une PaaS (plateforme en tant que service) permettant de déployer des applications sur le Cloud. A la
façon dont un hébergeur web propose d’héberger un site web sur ses propres serveurs, cette solution vous permet
de déployer votre application sur le Cloud pour permettre aux internautes de l’utiliser.
Les applications sont exécutées dans des dynos, à savoir des ordinateurs virtuels dont la puissance peut être
ajustée en fonction de l’envergure de l’application. Ainsi, les dynos peuvent être comparés à des blocs de
construction.
Si vous avez besoin de traiter davantage de données ou d’effectuer des tâches plus complexes, il est possible
d’ajouter davantage de blocs. C’est ce que l’on appelle le scaling horizontal. Il est aussi possible d’augmenter la taille
des blocs, ce qu’on appelle le scaling vertical. Heroku facture ensuite ses clients en fonction du nombre de dynos
utilisés et de leur taille. Heroku a été racheté par Salesforce en 2010.
b. Firebase
Firebase est un ensemble de services d'hébergement pour n'importe quel type d'application (Angular,Android,
iOS, Javascript, Node.js, Java, Unity, PHP, C++ ...). Il propose d'héberger en NoSQL et en temps réel des bases de
données, du contenu, de l'authentification sociale (Google, Facebook, Twitter et Github), et des notifications, ou
encore des services, tel que par exemple un serveur de communication temps réel. Lancé en 2011 sous le nom
d'Envolve, par Andrew Lee et par James Templin, le service est racheté par Google en octobre 2014.
3. ReCAPTCHA
ReCAPTCHA est un système de détection automatisée d'utilisateurs
appartenant à Google et mettant à profit les capacités de reconnaissance de ces
derniers, mobilisées par les tests CAPTCHA, pour améliorer par la même occasion le
processus de reconnaissance des formes par les robots. Jusqu'en 2014, il était présenté
sous forme de CAPTCHA de reconnaissance de texte, et servait à la numérisation de
livres, là où échouaient les systèmes de reconnaissance optique de caractères (OCR).
Aujourd'hui il s'agit d'une case à cocher, suivie, si jugé nécessaire par le robot, par un
CAPTCHA de reconnaissance d'images.

32 | P a g e
III. Front Office ( Angular )
1. Introduction
Angular est un Framework JavaScript de Google. Lancé en 2016, ce
Framework open source mise non seulement sur le développement de Single Page
Applications, mais aussi sur le développement multiplateforme. C’est notamment
pour cette raison que le Framework est indépendant de la plateforme. Outre
JavaScript, Angular prend également en charge le langage de programmation
TypeScript développé par Microsoft, ce qui permet de mettre en œuvre des
concepts de programmation avancés. En raison de son ampleur et de sa complexité, le Framework
convient surtout aux grandes entreprises.
Alors on a utilisé Angular version 13.2.0 en basant sur un Template ÀdminLTE` version 3.2.0 et pour
faciliter les tâches de styles on a utilisé aussi le Bootstrap et précisément le package NgBootstrap v12.0.2
parce qu'il offre des composants "pre-build"
Pour notre projet nous avons 6 pages principales, chaque page permet d'effectuer des opérations
CRUD sur une entité bien particulier, mais la page d'accueil permet de lister toutes les interventions de
tous les utilisateurs, alors que la page d'interventions permet de lister seulement les interventions de
l'utilisateur courant.
Les interfaces seront changées selon les droits de l'utilisateur connecter :
• Un utilisateur avec un droit d'accès Àdmin` peut accéder à toutes les pages et effectuer toutes
les opérations CRUD (sauf modifier ou supprimer ou ajouter des interventions pour les autres
utilisateurs, ou bien modifier le profil d'un utilisateur).
• Un utilisateur avec un droit d'accès Ùtilisateur` peut accéder à leurs interventions effectuer les
opérations CRUD concernant ces dernières, il a aussi le doit de modifier leur profil.
2. Les intercepteurs
Une Meilleure requête HTTP sur Angular. Le traitement des Token basé sur l'API est parfois fastidieux.
Du fait que, à chaque demande, nous devons envoyer un Token en paramètre pour pouvoir contacter le
serveur. Dans Angular, cela devient plus facile à l'aide d'intercepteurs HttpClient. Dans ce didacticiel, je
vais vous expliquer comment configurer une fois un jeton et l'utiliser à chaque demande avec des
intercepteurs.
3. Les Pipes
Les Pipes sont des filtres utilisables directement depuis la vue afin de transformer les valeurs lors du "binding".
4. AdminLTE
AdminLTE est un Angular Web application, open source populaire pour les tableaux de bord
d'administration et les panneaux de contrôle. Il s'agit d'un modèle HTML réactif basé sur le Framework CSS
Bootstrap 3. Il utilise tous les composants Bootstrap dans sa conception et redéfinit de nombreux plugins
couramment utilisés pour créer une conception cohérente pouvant être utilisée comme interface
utilisateur pour les applications backend. AdminLTE est basé sur une conception modulaire, ce qui lui
permet d'être facilement personnalisé et développé.

33 | P a g e
5. Leaflet
Leaflet est une bibliothèque JavaScript libre de cartographie en ligne développée par l'ukrainien Vladimir Agafonkin
de CloudMade et de nombreux contributeurs. Elle est notamment utilisée par le projet de cartographie libre et
ouverte OpenStreetMap5.
La bibliothèque est utilisée sur les sites cartographiques OpenStreetMap (bibliothèque par défaut), Flickr,
Wikipédia (greffon de cartographie et application mobile), Foursquare, craigslist, Institut national de l'information
géographique et forestière, Washington Post, le Wall Street Journal, Geocaching.com, City-Data.com, StreetEasy,
Nestoria, Skobbler et d'autres5.
6. Angular DataTable
Il est fréquent de devoir afficher une grande quantité de données dans nos applications web et,
pour bien organiser cette information, on utilise des tableaux HTML. Avec Angular, il est très facile de
remplir les lignes du tableau en utilisant des directives de type boucle, comme *ngFor, dans nos
templates HTML.
Néanmoins, la complexité arrive quand nous devons ajouter des fonctionnalités à notre tableau
comme la pagination, les tris, la recherche ou le téléchargement des données via Ajax.
Pour mettre en place ces fonctionnalités, plutôt que de les coder ‘from scratch’ dans notre
application, on est travail avec : Angular DataTables . Ce plug-in est construit sur le plug-in DataTables
pour jQuery.
Figure 19 : Plus de fonctionnalités avec Angular & JQuery DataTable.
Effectue des recherches
Naviguer avec une pagination
Enregistrer les données

34 | P a g e
7. Bootstrap
Bootstrap est une collection d'outils utiles à la création du design (graphisme,
animation et interactions avec la page dans le navigateur, etc.) 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. C'est l'un des projets les plus populaires sur la plate-forme de gestion de
développement GitHub.
8. Node Js
Node.js est une plateforme logicielle libre en JavaScript, orientée vers les
applications réseau évènementielles hautement concurrentes qui doivent pouvoir
monter en charge.
Elle utilise la machine virtuelle V8, la librairie libuv pour sa boucle d'évènements, et
implémente sous licence MIT les spécifications CommonJS.
9. Npm
Npm est le gestionnaire de paquets par défaut pour l'environnement
d'exécution JavaScript Node.js de Node.js.
IV. Mobile
1. Capacitor
Capacitor est un projet open source qui exécute
nativement des applications Web modernes sur iOS,
Android, Electron et Web (à l'aide de la technologie
Progressive Web App) tout en fournissant une interface
puissante et facile à utiliser pour accéder aux SDK natifs
et aux API natives sur chaque plate-forme. En tant qu'alternative à Cordova, Capacitor offre les mêmes
avantages multiplateformes, mais avec une approche plus moderne du développement d'applications,
tirant parti des dernières API Web et des capacités de la plate-forme native.
V. Algorithme Ray casting
Un moyen simple de déterminer si le point se trouve à l'intérieur ou à l'extérieur d'un polygone
simple consiste à tester combien de fois un rayon, partant du point et allant dans n'importe quelle
direction fixe, coupe les bords du polygone. Si le point est à l'extérieur du polygone, le rayon coupera son
bord un nombre pair de fois. Si le point se trouve à l'intérieur du polygone, il coupera le bord un nombre
impair de fois. L'état d'un point sur le bord du polygone dépend des détails de l'algorithme d'intersection
des rayons.
Cet algorithme est parfois également connu sous le nom d'algorithme de nombre de croisements
ou d'algorithme de règle pair-impair, et était connu dès 1962. L'algorithme est basé sur une observation
simple que si un point se déplace le long d'un rayon de l'infini jusqu'au point sonde et s'il franchit la limite
d'un polygone, éventuellement plusieurs fois, alors il va alternativement de l'extérieur vers l'intérieur, puis
de l'intérieur vers l'extérieur, etc. En conséquence, tous les deux "passages de frontière", le point mobile
sort. Cette observation peut être prouvée mathématiquement en utilisant le théorème de la courbe de
Jordan.

35 | P a g e
On a utilisé cet algorithme pour vérifier si le point GPS d’utilisateur d’application mobile est existé
dans un établissement enregistré.
VI. Conclusion :
Dans ce chapitre, nous avons présenté notre Front End avec le langage utilisé ainsi que le Back
End et son propre langage et les outils utilisés au niveau du développement de l’application
Figure 20 : Ray Casting

36 | P a g e
DESCRIPTION DES
TRAVAUX REALISES

37 | P a g e
I. Introduction
Ce chapitre comporte des captures d’écran de quelques interfaces de notre application
accompagnées par une brève description.
II. Application web côté Administrateur
Nous présentons dans cette partie, à travers un enchainement de captures d’écran, les interfaces
de l’application web coté administrateur.
1. Interface Authentification
La figure suivante nous présenterons l’interface login, lorsque l’utilisateur veut accéder au site, une
page de login sera affichée au début. En cas d’échec d’authentification un message d’erreur sera affiché
et l’utilisateur doit réécrire le courriel ou le mot de passe.
Figure 21 : Interface d'authentification

38 | P a g e
2. Interface Accueil SuperAdministrateur
Une fois l’administrateur est authentifié, si l’utilisateur de type SuperAdmin une page d’accueil
s’affiche comme l’illustre la figure 19. À partir de cette page, l’administrateur peut accéder à l’ensemble
des fonctionnalités de l’application. Il peut gérer les utilisateurs (sous admins), les établissements, les
locaux et les types des locaux, les messages et le suivi d’un local, et aussi deux graphes pour consulter le
nombre des locaux par établissement et nombre des visiteurs par établissement.
Figure 22 : Interface Accueil de l’administrateur
3. Interface Gestion des utilisateurs
Cette interface permet à l’administrateur de gérer les admins des établissements dans la base de
données (supprimer un admin, activer ou désactiver un admin).
Figure 23 : Interface gestion des admins

39 | P a g e
4. Interface Gestion des établissements
Cette interface permet à l’administrateur de gérer les établissements dans la base de données
(ajouter, modifier, supprimer, et générer les détails du compte admin).
Figure 24 : Interface gestion établissements
5. Interface ajouter établissement
Pour ajouter un établissement il faut saisir le nom et après définie les bordures de l’établissement pour le GPS
authentification,
Figure 25 : Interface ajouter établissement

40 | P a g e
6. Interface modifié établissement
Pour modifier un établissement il faut modifier le nom et après modier les bordures de l’établissement ,
Figure 26 : Interface consultation des messages
7. Interface Gestion types des locaux
Cette interface permet à l’administrateur de gérer les types des locaux des établissements dans
la base de données (ajouter, modifier, supprimer un type).
Figure 27 : Interface gestion types des locaux

41 | P a g e
8. Interface ajouter type de local
Chaque local et à partir d’un type, pour ajouter un type il faut saisir le nom et la description de type,
comme Amphi, DI …
9. Interface Gestion des locaux
Cette interface permet à l’administrateur de gérer les locaux des établissements dans la base de
données (ajouter, modifier, supprimer un local).
Figure 28 : Interface gestion locaux

42 | P a g e
10. Interface ajouter local
Pour ajouter un local il faut saisir le nom, description et sélectionner le type de local et établissement, après définie
dans le MAP le point exact de local
11. Interface Modifier local
Pour modifier le local il faut ressaisirai les informations, pour le point dans le Map if faut cliquer sur le Button
modifier dans le Map et après changer l’emplacement ou bin supprimer et rerajouter.

43 | P a g e
12. Interface Consultation des messages
Cette interface permet à l’administrateur de consulter les messages des utilisateurs de
l’application mobile.
Figure 29 : Interface consultation des messages
13. Consultation du nombre de visite d’un local dans un établissement
Cette interface permet à l’administrateur de consulter le suivi (nombre des visiteurs) d’un local
d’un établissement dans la base de données.
Figure 30 : Consultation de nombre de visite

44 | P a g e
III. Application mobile côté Client
Nous présentons dans cette partie, à travers un enchainement de captures d’écran, les interfaces
de l’application mobile coté client. Dans cette partie, l’étudiant va choisir le local qu’il veut , avec la
possibilité de chercher sur la barre de recherche pour faire un filtre sur les locaux, les types des locaux ou
la description. Quand il choisit le local, il va cliquer sur la première icône à droite, puis il va activer son
point GPS, après s’il veut, il peut faire un plein d’écran pour une meilleur expérience d’utilisation.
1. Interfaces de l’application mobile
IV. Conclusion :
Dans ce chapitre, nous avons présenté des captures d’écran de quelques interfaces de notre
application accompagnées par une brève description.
Figure 31 : Interfaces application mobile

45 | P a g e
Conclusion Générale et Perspectives
Notre sujet de stage était la conception et la réalisation d'une application pour
l’orientation des étudiants, le corps professoral, ou bien les usagers vers les différents
locaux de l’établissement.
Au cours de ce stage, nous avons tout d’abord défini les besoins de notre
application. Et pour mener à bien notre projet, notre décision était d’utiliser la méthode
SCRUM, une fois le système d’information est conçu, nous avons commencé par la
programmation de Backend, puis on a attaqué le Front-end.
Ce projet nous a permis de cumuler des connaissances diverses dans plusieurs
champs, et de maitriser des nouvelles technologies et nouveaux frameworks tel que
Spring Boot et Angular, qui seront certes utiles dans nos futures vies professionnelles.
La période de la réalisation de ce projet nous a permis de mettre en pratique les
acquises tout au long de nos formations en général et au long de cette formation (LP-
TPW) en particulier. Les écarts le plus souvent entre la théorie et la pratique de ces acquis
ont été comblés par les expériences que nous acquérions au fur et à mesure que nous
avancions dans ce projet.
En conclusion, ce stage est une période de transaction de l’esprit, une transaction
qui se fait du théorique vers la pratique, de l’abstrait vers le concret, d’un cadre restreint
vers un espace libre et riche, mais qui est régi par des contraintes, qui doivent être
surmontées.

46 | P a g e
Les références et webographies
W3School: https://www.w3schools.com/
Codecademy: https://www.codecademy.com/
Javatpoint: https://www.javatpoint.com/
Wikipedia: https://en.wikipedia.org/
Ray Casting: https://rosettacode.org/wiki/Ray-casting_algorithm
Onion architecture: https://www.codeguru.com/csharp/understanding-onion-architecture/
GPS: https://www.gps.gov/systems/gps/french.php
Angular: https://angular.io/guide/pipes
Leaflet: https://fr.wikipedia.org/wiki/Leaflet
Azure: https://www.devopsgroup.com/insights/resources/tutorials/all/what-is-azure-devops/
Firebase: https://fr.wikipedia.org/wiki/Firebase
DevOps: https://classeaffaires.com/
Heroku: https://www.lebigdata.fr/heroku-definition

Rapport projet de fin d'études licence PFE

Contenu connexe

Tendances

Similaire à Rapport projet de fin d'études licence PFE

Dernier

Rapport projet de fin d'études licence PFE