SlideShare une entreprise Scribd logo
République Tunisienne
Ministére de l’Enseignement Supérieur et de la Rcherche scientifique
Université de Tunis El Manar
Département Technologies de l’Information et de la Communication
Rapport du Projet de Fin d’Année
Conception et développement d’un site
web pour la suggestion et notification
des restaurants et salons de thé
présenté par
JAOUADI Houssemeddine & BOUBAYA Mouhamed
Encadré par
M BEN AISSA Anis
Groupe : 2Année Télécommnications 1
Année Universitaire : 2016-2017
Remerciements
Avant de commencer notre rapport du projet de fin d’année, nous voulons
exprimer notre gratitude envers tous ceux qui nous ont encouragé, soutenue
et aidé pour le bon déroulement de ce projet.
Nous remercions également, l’ ensemble du cadre enseignant de l’ Ecole
Nationale d’ Ingénieurs de Tunis et en particulier Monsieur Anis BEN AISSA,
pour son suivi, son aide et la qualité de l’ encadrement dont il nous a fait
bénéficier.
Conception et développement d’un site web pour la
suggestion et notification des restaurants et des salons
thé
Résumé :
ce projet consiste à concevoir et réaliser une solution de marketing pour les
restaurants, pâtisseries, salons de thé sous la forme d’un réseau social. Ainsi, ce
dernier offre à ces établissements la possibilité de présenter gratuitement leurs
produits, promotions, offres. Cela à travers des publications (photos, statuts
écrites, vidéos, GIF) dans un espace ouvert permettant l’interaction directe
avec leurs clients. En revanche, un visiteur inscrit et authentifié peut consulter
et suivre les publications des établissements et réagir avec elles (satisfait ou
non, commentaire, partage). Il peut aussi consulter leurs zones géographiques
à l’aide d’une interface Google Maps dans laquelle il est indiqué la zone où se
trouve chaque établissement.
Mots clés : API, service web, REST, HTTP, établissement, page, publica-
tion,client
Table des matières
Introduction générale 1
1 Présentation génerale du projet 2
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Objectif du projet . . . . . . . . . . . . . . . . . . . . . 3
1.3 Etude préalable . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 Etude de l’existant . . . . . . . . . . . . . . . . . . . . 3
1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . 4
1.3.3 Solutions proposées . . . . . . . . . . . . . . . . . . . . 4
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Analyse et spécification des besoins 6
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . 7
2.2.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . 7
2.2.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . 8
2.3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Vue globale du système . . . . . . . . . . . . . . . . . . 9
2.3.2 Diagrammes de cas d’ utilisation raffinés . . . . . . . . 10
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Conception 12
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Conception globale . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . 14
3.3.2 Diagrammes de séquences . . . . . . . . . . . . . . . . 15
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Réalisation 18
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . 19
4.2.1 Environnement matériel . . . . . . . . . . . . . . . . . 19
4.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . 19
4.3 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . 20
TABLE DES MATIÈRES
4.4 Travail réalisé et scénarios d’ exécution . . . . . . . . . . . . . 21
4.4.1 Le sénario du client . . . . . . . . . . . . . . . . . . . . 22
4.4.2 Le sénario du représentant d’ établissement . . . . . . . 26
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Conclusion et perspectives 29
Bibliographie 38
iv
Table des figures
2.1 Diagramme de cas d’ utilisation global . . . . . . . . . . . . . 9
2.2 Diagramme de cas d’ utilisation du client . . . . . . . . . . . . 10
2.3 Diagramme de cas d’ utilisation du Représentant de l’ établis-
sement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Architecture globale du systeme . . . . . . . . . . . . . . . . . 13
3.2 Diagramme de classes de la couche modèle . . . . . . . . . . . 14
3.3 Diagramme de séquence de l’ authentification . . . . . . . . . 16
3.4 Diagramme de séquence de la création d’ une publication . . . 17
4.1 Architecture technique et choix technologiques . . . . . . . . . 20
4.2 Inscription pour un client . . . . . . . . . . . . . . . . . . . . 22
4.3 Authentification du client . . . . . . . . . . . . . . . . . . . . 22
4.4 Profil du client . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5 Page de recherche d’ établissements . . . . . . . . . . . . . . . 23
4.6 Indication géographique d’ un établissement . . . . . . . . . . 24
4.7 Page principale d’ un établissement . . . . . . . . . . . . . . . 25
4.8 Réactions sur une publication . . . . . . . . . . . . . . . . . . 26
4.9 Ajout d’ établissement . . . . . . . . . . . . . . . . . . . . . . 27
4.10 Ajout d’ un article . . . . . . . . . . . . . . . . . . . . . . . . 27
4.11 Ajout d’ une publication . . . . . . . . . . . . . . . . . . . . . 28
12 Exemple d’ une reqête GET et réponse du serveur . . . . . . 33
13 Structure d’ un jeton JWT . . . . . . . . . . . . . . . . . . . . 36
14 Requête de l’authentification . . . . . . . . . . . . . . . . . . . 37
15 Réponse reçue par le serveur . . . . . . . . . . . . . . . . . . . 37
Liste des tableaux
4.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . 19
2 Exemple d’ une API REST (Méthodes HTTP, routes et des-
criptions) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Liste des acronymes
API Application Programming Interface
CSS Cascading de Stile Sheet
ENIT Ecole Nationale d’ Ingénieurs de Tunis
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
JS JavaScript
JSON JavaScript Object Notation
JWT JSON Web Token
ORM ObjectRelational Mapping
PFA Projet Fin d’ Année
PHP PhpHypertext Processor
REST Representational State Transfer
SGBD Système de Gestion de Bases de Données
SQL SStructured Quering Language
UML UnifiedModeling Language
Introduction générale
Les réseaux sociaux sont devenues les environnements les plus favorables
pour les producteurs pour promettre leurs produits tout en assurant son ef-
ficacité et sa rentabilité . En effet, la plupart de ces réseaux garantissent la
gratuité d’un grand part du marketing. Ils leurs offrent un espace libre per-
mettant une interraction directe entre le consommateur et le producteur. Cela
se fait à travers les publications, les commentaires, le partage des avis.
En Tunisie, on remarque bien que les restaurants, les cafés et les salons
de thé trouvent un succès en matière de rentabilité. Ainsi, ces établissements
cherchent toujours des nouvelles méthodes et des nouvelles solutions de mar-
keting moins couteuses et très performantes en même temps. En revanche, les
clients ont besoin d’une application qui leur permet de consulter le plus grand
nombre possible d’ établissements et découvrir ainsi leurs produits, offres,
promotions. Et de les évaluer et réagir avec elles.
On s’intéresse alors dans ce cadre à concevoir puis développer un réseau
social sous la forme d’un site Web dynamique.
Ce rapport sera alors réparti comme suit :
- Une partie pour la présentation génerale du contexte de notre projet
- La deuxième partie sera consacrée à l’ analyse et la spécification des
besoins
- La troisiéme s’ occupera de la conception de notre application
- Dans la derniére partie nous décriverons le travail réalisé de notre projet
Chapitre 1
Présentation génerale du projet
Sommaire
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Objectif du projet . . . . . . . . . . . . . . . . . . . . 3
1.3 Etude préalable . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 Etude de l’existant . . . . . . . . . . . . . . . . . . . . 3
1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . 4
1.3.3 Solutions proposées . . . . . . . . . . . . . . . . . . . . 4
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Introduction
1.1 Introduction
Dans ce premier chapitre, nous allons commencer en un premier lieu par
expliquer le cadre du projet. Puis, faire notre étude préalable qui contient l’
étude, la critique de l’ existant et nos solutions proposées.
1.2 Cadre du projet
Ce projet est un travail de binômes dans le cadre du projet de fin d’année
(PFA) ayant comme sujet " Conception et développement d’ un site web pour
la suggestion et notification des réstaurants et des salons de thé "
1.2.1 Objectif du projet
Nous sommes demandés dans ce projet de faire la conception puis le dé-
veloppement d’ un site web qui réunit les restaurants et les salons de thé
avec leurs clients. Notre application vérifie les spécificités d’un réseau social
classique. En effet, elle offre aux établissements la possibilité de créer des
publications (publier des photos, vidéos, GIF ...) au sein de leurs pages.
Elle offre aux clients la possibilité de consulter ces publications et réagir
avec elles. Elle leurs offre d’ avantage l’ occasion de consulter géographique-
ment les locaux des établissements à travers une interface de Google Maps.
Notre application dispose aussi de plus d’ une recherche rapide et intelligente.
1.3 Etude préalable
Dans cette partie du rapport on va entamner l’étude de l’existant. Puis on
va le critiquer pour en deduire des solutions qui seront proposés au sein de
notre projet
1.3.1 Etude de l’existant
On a fait ici une recherche sur les sites qui proposent des solutions de
Marketing similaires pour les restaurants, cafés, salons de thé . Nous avons
alors dégagé les informations ci-dessous.
- BIGDeal.tn : est un site web d’achat groupé qui propose à ses visi-
teurs des réductions pour des offres diversifiés, BigDeal publie toujours
les offres de tout type de restaurants, cafés, hotels ...etc. Il joue le rôle
de l’intermédiére entre l’établissement et le client [1] .
3
1.3 Etude préalable
- restaurant-internet.com : c’est un site web permettant aux restau-
rants de créer leurs interfaces web dans lesquelles ces dérniers peuvent
publier leurs informations, actualitées, produits ... etc [2].
- resto-tunisie.com : ce site permet de regrouper les restaurants, cafés,
pÃtisseries âetc en Tunisie et offre à ses visiteurs de consulter les menus
ainsi que passer des commandes et réserver en ligne [3].
- onamangepourvous.tn : On a mangé pour vous est une plateforme
dans laquelle on trouve les produits délivrés par des restaurants et des
salons de thé en Tunisie, les visiteurs peuvent rágir avec ces produits
et donner leurs avis à propos des prix, la qualité de service et du menu
proposé [4].
La gestion des établissements de ce genre n’ est plus facile vu la concurrence
dù à l’augmentation de leur nombre dans le monde et surtout en Tunisie. Les
outils dont on a déja parlé et d’autes proposent des différentes solutions pour
faciliter l’opération de marketing. Chacun essaie d’offrir une solution innovante
et efficasse. Dans les parties suivante, on va critiquer ce genre de solutions et
on va proposer d’autres.
1.3.2 Critique de l’existant
Certes les outils cités précédement sont utiles, connues et serviables, mais
ils souffrent de plusieurs limites. Nous allons maintenant les décrire :
- Elles ne sont pas gratuites. Un étqblissement doit payer pour pouvoir
publier quelque chose
- Pas d’ interractions entre le client et l’ établissement. Elles ne donnent
pas aux clients la possibilité de réagir avec les publications ou de contac-
ter les établisements
- Absence de recherche géographique. Un client ne peut pas consulter l’
adresse de l’ établissement directement à travers un map.
1.3.3 Solutions proposées
La solution proposée est d’aller dans l’approche des réseaux sociaux et de
concevoir et développer un réseau social pour les restaurants et les salons de
thé.
Notre application comporte trois acteurs : Un client, un représentant d’
établissement et un super administrateur. Elle sera décomposée comme suit :
- Un espace d’authentification : comporte deux pages : une pour
l’inscription des clients et autre pour l’authentification.
- Une page d’établissement : dans laquelle le représentant peut par-
tager des publications, voir les réactions des visiteurs et répondre à
4
1.4 Conclusion
leurs commentaires.
- Une page d’accueil : dans laquelle un client peut consulter les nou-
vautés des pages des établissements qu’il suit.
- Une interface pour le profil de chaque client
- Un espace d’administration : dedié au super administrateur. Il
contient une interface pour la gestion des établissements et une pour
la gestion des clients.
1.4 Conclusion
Dans ce chapitre, on a commencé par une présentation du cadre du projet
dans laquelle on a décrit son objectif. Puis, on a passé par une étude préalale
qui contient l’ étude de et la critique de l’existant accampagné de quelques
solutions proposées. A ce qui concerne le chapitre suivant, on s’ interessera à
l’ analyse des besoins fonctionnels et non fonctionnels et á la specification de
ces besoins.
5
Chapitre 2
Analyse et spécification des
besoins
Sommaire
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . 7
2.2.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . 7
2.2.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . 8
2.3 Spécification des besoins . . . . . . . . . . . . . . . . . 9
2.3.1 Vue globale du système . . . . . . . . . . . . . . . . . 9
2.3.2 Diagrammes de cas d’ utilisation raffinés . . . . . . . . 10
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1 Introduction
2.1 Introduction
Ce chapitre sera divisé en deux parties : La premiére est une analyse des
besoins dans laquelle on va citer en un premier lieu les différents acteurs inter-
venants dans l’application. En second lieu on va décrir d’ une façon détaillée
nos besoins fonctionnels et non fonctionnels. Dans la deuxiéme partie on s’in-
teressera à la spécification de ces besoins à traves les diagrammes de cas d’
utilisation de l’ UML.
2.2 Analyse des besoins
2.2.1 Identification des acteurs
On s’intéresse maintenant à présenter les acteurs qui sont en contact direct
avec l’ application et qui profitent de différenrs accés aux données. (Notons
ici que tout genre d’ accée est obligatoirement authentifié)
- Client : C’ est l’ utilisateur qui peut consulter des pages et des pu-
blications et réagir avec elles.
- Représentant d’ établissement : c’ est l’ administrateur de la page
de l’ établissement qu’ il reprśente. Il peut gérer les publications et les
informations sur sa page et se comporte aussi comme un client.
- Super administrateur : il gére les pages (création, modification et
suppression) et affecte les représentants aux établissements ainsi qu’ il
peut gérer les clients.
2.2.2 Besoins fonctionnels
Notre application doit permettre les différents acteurs de s’ inscrir, s’au-
thentifier afin d’ accéder à leurs données. il peuvent ainsi consulter leurs pro-
files et modifier leurs informations. Pour le reste des besoins fonctionnels, ils
varient d’ un acteur à un autre qu’ on va les spécifier pour chacun en détail
Client :
- Un client est caractérisé par son nom, son prénom, adresse, numéro de
téleéphone, email, mot de passe et pseudo.
- Les informations d’ un clients doivent l’ être accessibles pour qu’ il
puisse les consulter et les modifier
- Dispose d’ un éspace pour faire des recherches sur les établissements
qui existent
7
2.2 Analyse des besoins
- Il peut consulter n’ importe quelle page et suivre ses actualitées soit
par visiter la page directement ou bien à travers sa page d’ accueil
- Il peut aussi réagir avec des publications en la notant ou par des com-
mentaires.
Représentant d’ établissement :
- C’ est un utilisateur inscrit comme étant un client, affecté par le super
administrateur à la page de l’ établessement qu’ il représente pour
pouvoir la gérer
- Un établissement est caractérisé par un nom, une adresse, une specialité
et une catégorie.
- Il peut gérer les informations de la page de son établissement.
- Il peut gérer les publications sur sa page ( les publications peuvent
être des textes simples ou peut contenir des images ...) et réagir avec
les commentaires et les avis des visiteurs de la page.
Super administrateur
- C’est le seul qui peut gérer les pages des établissements et leurs affecter
des représentants
- Peut aussi gérer les clients
2.2.3 Besoins non fonctionnels
Les besoins non fonctionnels forment l’ ensemble des contraintes techniques
auquelles notre système doit répondre.
- La rapidité : le temps de traitement exigé par l’ application doit être
suffisamment court pour garantir l’ accés souhaitable aux informations
- La sécurité : Tout type d’ accés aux donnée doit être authentifié.
Aussi, l’application doit contenir un systéme permettant la gestion des
mots de passe, l’authentification sécurisée et les droits d’accés
- La performance : Les algorithmes utilisés pour certains traitements
dovent avoir une complexité la plus faible que possible ainsi qu’ une
utilisation économique des ressources.
- Maintenabilité et convivialité : Ce genre de sites web ou d’ appli-
cations doit être dedié vers toutes les catégories de gens elle doit ainsi
être facile en usage et en apprentissage.
- Portabilité : L’ application doit fonctionner sur n’importe quel type
de machine et de syst `me d’ exploitation et accessible à travers le plus
8
2.3 Spécification des besoins
grand nombre des navigateurs connus et largement utilisés (Chrom,
FireFox, Edge, Safari ...)
2.3 Spécification des besoins
Ici on va spécifier nos besoins en se basant sur les diagrammes de cas d’
utlisation de l’ UML
2.3.1 Vue globale du système
Nous sitons ici le diagramme de cas d’ utilisation global de notre applica-
tion
Figure 2.1 – Diagramme de cas d’ utilisation global
9
2.3 Spécification des besoins
2.3.2 Diagrammes de cas d’ utilisation raffinés
2.3.2.1 Diagrammes de cas d’ utlisation du client
Nous décrivons ici le diagramme de cas d’ utilisation du client
Figure 2.2 – Diagramme de cas d’ utilisation du client
2.3.2.2 Diagrammes de cas d’ utlisation du représentant d’ établis-
sement
Nous décrivons ici le diagramme de cas d’ utilisation du Représentant de
l’ établissement
10
2.4 Conclusion
Figure 2.3 – Diagramme de cas d’ utilisation du Représentant de l’ établis-
sement
2.4 Conclusion
Dans ce chapitre nous avons commencé par une analyse des besoins dans
laquelle nous avons cité nos besoins fonctionnels et non fonctionnels. Puis nous
avons décrit la spécification de ces besoins en se basant sur les diagrammes
de cas d’ utilisation de l’ UML.
Dans le chaitre suivant on va entamner la conception de notre application.
11
Chapitre 3
Conception
Sommaire
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Conception globale . . . . . . . . . . . . . . . . . . . . . 13
3.3 Conception détaillée . . . . . . . . . . . . . . . . . . . . 14
3.3.1 Diagramme de classes . . . . . . . . . . . . . . . . . . 14
3.3.2 Diagrammes de séquences . . . . . . . . . . . . . . . . 15
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Introduction
3.1 Introduction
Avant de commencer le développement ou la réalisation d’ une solution qui
répond aux besoins demandés il est nécessaire de faire sa conception. Dans
cette étape nous nous intéressons à la description de la conception globale de
notre système ainsi que la conception détaillée.
3.2 Conception globale
Nous cherchons, au cours de la réalisation de notre projet, à augmenter
l’ éfficacité de l’ organisation de notre travail. Nous devons alors choisir une
architecture qui nous offre tout ça et nous aide à améliorer la qualité de notre
application. Nous avons alors opté à utiliser l’ architecture trois tiers qui est la
plus utilisée par les développeurs dans le monde et qui répond à nos objectifs.
Elle est expliquée dans la figure 3.1 ci-dessous
Figure 3.1 – Architecture globale du systeme
Couche presentation :
Un seul type de client :
Client léger : Accessible par tous les acteurs à travers un navigateur
Web .
Couche metier : Cette couche présente la partie fonctionnelle de notre
application. Elle contient les traitements fait sur les données et forme un
intermediére entre la base de données et les clients. Elle fait la gestion des
requêtes envoyées par le client ainsi que les réponses qu’ il reçoive.
Couche Accés aux données : Ce tiers est responsable au stockage des don-
nées dans une base de donnée centrale ainsi que la gestion de ces derniers.
13
3.3 Conception détaillée
3.3 Conception détaillée
A l’ aide des diagrammes du langage UML, nous allons entamner dans
cette partie la conception détaillée de notre application.
3.3.1 Diagramme de classes
La figure ci-dessous présente le diagramme de classe des enitités de notre
système.
Figure 3.2 – Diagramme de classes de la couche modèle
- Utilisateur : cette classe représente l’ utilisateur de l’ application qui
peut être soit un client, soit un représentant d’ établissement ou bien
le super administrateur
- Etablissement : Cette entité décrit les établissements qui sont gérés
par leurs représentants
- Article : Chaque établissement offre un ensemble d’ articles
- Publication : Un établissement peut toujours partager des publica-
tions pour les clients. Une publication peut contenir un article.
14
3.3 Conception détaillée
- Commentaire : chaque publication peut être commentée par les
utilisateurs
3.3.1.1 Schémas relationnel
Le shéma relationnelle est consitue d’une ensemble des shémas de tables
de base de donnèes . Voici les schémas relationnels de notre base de donnée :
- Utilisateur (id ,nom , prénom , email, adresse, pseudo, mot_de_passe,
is_admin, path_photo)
- Etablissement (id, nom, categorie, adresse, specialite, path_photo, #id_representant)
- Article (id, nom, prix, path_photo, #id_etablissement)
- Publication (id,contenue, titre, date, #id_etablissement, #id_article)
- Commentaire (id , contenue , date, #id_utilisateur, #id_publication)
- Suit(id_utlisateur ,#id_etablissement)
3.3.2 Diagrammes de séquences
3.3.2.1 Diagramme de séquence de l’ authentification
La figure 3.4 représente le diagramme de séquence de l’ authentification
15
3.3 Conception détaillée
Figure 3.3 – Diagramme de séquence de l’ authentification
Afin d’ améliorer la sécurité, on utilise l’ authentification à base de token
( voir Annexe B). Le diaramme de séquence ci-dessus explique les étapes de l’
authentification d’ un client. Ce dernier doit saisir son pseudo et son mot de
passe dans les champs convenables. les données saisis seront envoyées dans une
reqête HTTP vers l’ API de route /api/login_check avec la méthode POST.
si les données sont correctes on lui renvoie son token et son profil et on le
renvoie un erreur et il sera redirigé de nouveau vers la page de l’ authentifica-
tion. La figure 3.4 représente le diagramme de séquence de la création d’ une
publication
16
3.4 Conclusion
Figure 3.4 – Diagramme de séquence de la création d’ une publication
Un utlisateur demande la page d’ un établissement, il envoie alors son token
dans une requête GET pour demander les informations de l’ établissement, s’
il est son représentant, la page de gestion de l’ établissement est retournée.
Dans le cas contraire, on lui retourne la page accessible par le simple client.
3.4 Conclusion
Dans ce chapitre nous avons expliqué la conception de notre projet. Nous
avons commencé par la conception globale. Puis nous avons passé à la concep-
tion détaillée dans laquelle nous avons cité le diagramme de classe et les dia-
grammes de séquence de l’authenification et de la création de publication. Le
prochain chapitre sera consacré à la réalisation de notre application.
17
Chapitre 4
Réalisation
Sommaire
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Environnement de travail . . . . . . . . . . . . . . . . . 19
4.2.1 Environnement matériel . . . . . . . . . . . . . . . . . 19
4.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . 19
4.3 Choix technologiques . . . . . . . . . . . . . . . . . . . 20
4.4 Travail réalisé et scénarios d’ exécution . . . . . . . . 21
4.4.1 Le sénario du client . . . . . . . . . . . . . . . . . . . . 22
4.4.2 Le sénario du représentant d’ établissement . . . . . . 26
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1 Introduction
4.1 Introduction
Aprés avoir traité la partie conception de notre travail nous allons, dans
ce chapter, expliquer le travail réalisé pendant notre projet, nous allons com-
mencer par l’ environnement du travail dans lequelle nous précisons l’ envi-
ronnement matériel ainsi que l’ environnement logiciel et nous allons passer
aprés à expliquer nos choix technologiques et terminer par décrire le travail
réalisé et les scénarios dâexécution de notre application.
4.2 Environnement de travail
4.2.1 Environnement matériel
Le matériel étant à notre disposition pendant le développement de notre
application est formé par deux ordinateus portables dont les caractéristiques
sont cités dans la table suivante :
Table 4.1 – Environnement matériel
Ordinateur 1 Ordinateur 2
Processeur Intel core i 3 Processeur Intel core i 3
Mémoire : 4Go de RAM M ´moire : 4Go de RAM
DD : 512 Go DD : 512Go
SE : Linux Mint 17.2 SE : OS X yosemite 10.10.5
4.2.2 Environnement logiciel
Nous Allons maintenant décrir l’ environnement logiciel avec lequel nous
avons effectué notre travail. C’ est l’ensemble des outils et de logiciels que
nous avons opté à utiliser pour pouvoir développer notre application.
- Atom : Editeur de texte
- Pluguin Symfony3 pour atom
- PhpStorm : Environnement de développement intégré (EDI) déve-
loppé par JetBrains, Il permet de supporter le language PHP. Il in-
tégre également un support des gestionnaires de version tels que Git
et CVS, une intégration des bases de données et des outils de test des
API(Application programming interfaces)
- Pluguin Symfony3 pour PhpStorm
- Apache 2 : Serveur Web
19
4.3 Choix technologiques
- MySQL : Système de gestion de base de donnés
- PHPMyAdmin : Interface graphique développée en PHP et acces-
sible par Web permettant la gestion du SGBD MySQL.
- Git : Gestionnaire de version décentralisé.
- Postman : Le client REST du navigateur Chrumium qui nous permet
d’ exécuter des requêtes HTTP afin de tester des API REST
- StarUML : Outil de modélisation UML
- sharelatex : Éditeur de Document LaTeX en ligne.
4.3 Choix technologiques
La figure suivante représente l’architechture technique et choix technolo-
gique
Figure 4.1 – Architecture technique et choix technologiques
- HTML : C’est un language de balisage utilisé pour la création des
pages web
20
4.4 Travail réalisé et scénarios d’ exécution
- CSS : Un language qui permet de définir des styles sur un ou plusieurs
documents
- Angular JS : Frame-work JavaScript open-source développé par Google
permettant développer des applications web dynamiques en utilisant le
modéle MV-VM , on va l’ utiliser pour consommer les API REST dé-
veloppés avec Symfony
- PHP5 : Un langage de script fréquemment utilisé par les développeurs
pour la création des pages web dynamiques. PHP est aussi le plus
répendu chez les hébergeurs ce qui justifie notre choix.
- Symfony3 : Frame-work ćrit en langage PHP permettant de séparer
les trois couches du model MVC et nous l’ avons utilisé pour le déve-
loppement de notre API REST.
Doctrine : ORM du frame-work Symfony utilisé pour la gestion de la
base de donnée.
- JSON : Le format de notation des objets le plus leger et utilisé pour
la communication du service web REST.
- YML : Langage de configuration pour Symfony.
4.4 Travail réalisé et scénarios d’ exécution
Nous allons ici décrire notre travail réalisé et nous allons éxpliquer le scé-
narios dâ exécution à l’ aide des captures d’écran. La figure 4.2 montre l’
interface d’ inscription pour un client.
21
4.4 Travail réalisé et scénarios d’ exécution
4.4.1 Le sénario du client
Figure 4.2 – Inscription pour un client
Sachant que tout type d’ accé aux données doit être authentifié. La figure
4.3 présente l’ interface de l’ authentification
Figure 4.3 – Authentification du client
Aprés avoir être authentifié, Un client peut consulter son profil et le gérer.
La figure 4.4 montre l’ interface qui contient le profil du client
22
4.4 Travail réalisé et scénarios d’ exécution
Figure 4.4 – Profil du client
Aussi, ce dernier profite d’ un éspace de recherche. Un client peut cher-
cher un établissement avec son nom, son adresse, et sa catégorie. La figure
4.5 présente la page de recherche dans notre application. Les résultats de la
recherches sont affichés sur la m ˆme page sans la refraichir (grace à AngularJs)
Figure 4.5 – Page de recherche d’ établissements
En faisant un simple clique sur la photo de l’ un des établissements affichés,
23
4.4 Travail réalisé et scénarios d’ exécution
Une interface goosle map est aussi affichée sur la page indiquant sa position
géographique comme le montre la figure ci-dessous.
Figure 4.6 – Indication géographique d’ un établissement
En cliquant aussi sur le nom d’ un établissement, un client peut consulter
sa page. Cette page contient toutes les informations sur cet établissement ainsi
que ses articles et ses publications comme le décrit la figure suivante :
24
4.4 Travail réalisé et scénarios d’ exécution
Figure 4.7 – Page principale d’ un établissement
En arrivant à ce stade, un utilisateur peut choisir une publication et réagir
avec elle comme la montre la figure ci-dessous
25
4.4 Travail réalisé et scénarios d’ exécution
Figure 4.8 – Réactions sur une publication
4.4.2 Le sénario du représentant d’ établissement
Un représenatant doit tout d’abord créer la page de son établissement et
attendre la validation du super administrateur. La figure 1.9 montre l’ interface
destinée à l’ ajout de de l’ établissement.
26
4.4 Travail réalisé et scénarios d’ exécution
Figure 4.9 – Ajout d’ établissement
Aprés avoir être validée par le super administrateur, le représentant peut
commencer à ajouter des articles et partager des publications comme le montre
la figure 4.10
Figure 4.10 – Ajout d’ un article
Le représentant peut ansi consulter la liste des articles de son établisse-
ment et choisir un et lui ajouter une description puis le publier. La figure
ci-dessous décrit cette opération
27
4.5 Conclusion
Figure 4.11 – Ajout d’ une publication
4.5 Conclusion
Dans ce chapitre, nous avons commencé par décrire notre environnement
matériel de travail ainsi que notre environnement logiciel, puis nous avons
passé aux choix techniques et nous avons terminé par les scénarios dâ exécu-
tion.
28
Conclusion et perspectives
Tout au long de ce projet de fin d’ année, nous avons travaillé sur la concep-
tion et le développement d’ un site web pour la suggestion et la notifications
des restaurants et des salons de thé. Cette application ayant la forme d’ un ré-
seau social présente une solution de marketing pour ce type d’ établissements.
Nous avons commencé en premier lieu par la présentation du cadre géne-
ral du projet. Dans cette partie nous avons expliqué le cadre du projet et son
objectif. Puis, nous avons passé à citer quelques autres solutions similaires
et les critiquer en dégageant leurs limites pour en proposer des nouvelles so-
lutions.En second lieu nous avons entamné l’ analyse et la spécification des
besoins. Nous avons cité les acteurs qui interviennent avec le site et nous
avons décrit nos besoins fonctionnels et non fonctionnels. Puis, et à l’ aide des
diagrammes de cas d’ utilisation du langage UML nous avons fait la spécifi-
cation des besoins. La troisiéme partie était la partie conceptuelle de notre
projet. Nous avons commencé par la conception générale puis la conception
détaillée dans laquelle, et en se basant sur les diagrammes de l’ UML nous
avons cité le diagramme de classe puis les diagrammes de séquence. Dans la
derniére partie, nous avons parlé du travail réalisé à savoir les technologies et
l’ environnement de travail ainsi que les sénarios déxecusion à l’ aide de la
présentation des interfaces de l’ application.
Ce projet effectué nous a permis dâ acquŕir une expérience enrichissante
et de mettre en pratique les concepts et les méthodologies théoriques acquis
durant notre cursus académique. Et de maîtriser de nouvelles technologies
plus quâ intéressantes.
Cependant, Nous pensons toujours d’ améliorer notre projet. En effet,
Nous pouvons rajouter un module de chat et de notifications temps réel pour
améliorer l’ interraction entre le client et l’ établissement. Nous pouvons aussi
développer une application mobile pour les clients. D’ autre part, nous comp-
tons développer des algorithmes pour améliorer la suggestion des établisse-
ment, Par exemple, unalgorithme qui suit les activité des clients et qui peut
savoir les types d’ établissement qu’ ils favorisent le plus.
Annexe.A : Le service Web REST
Le service Web
Un service web est un protocole d’ interface informatique de la famille des
technologies web permettant la communication et l’ échange des données entre
applications et systèmes héterogénes []
La communication est toujours définie dans le cadre d’ un protocole de la
couche application. Le protocole actuellement utilisé est HTTP.
Le protocole HTTP
Définition
C’ est un protocole de communication client-serveur. HTTPS est la va-
riante du HTTP sécurisée par l’ usage des protocoles SSL et TLS [].
Les méthodes du protocole HTTP
Les requêtes HTTP éffectuées sur le serveur disposent d’ une méthode qui
est une commande qui a pour rôle de spécifier l’ action qu’ on veut éffectuer
sur es ressources du serveur.
API REST
Définition
Une API REST peut être modélisée comme une boite noire qui contient
des fonctions chacune nous permet de gérer des ressources sur le serveur.
Chaque fonction est distinguée par une route et une méthode HTTP. Ainsi,
pour accéder au service d’ une fonction on envoie une requête HTTP avec sa
méthode et sur sa route.
Exemples
Le tableau suivant présente un exemple d’ API de gestion d’ utilisateur.
31
Table 2 – Exemple d’ une API REST (Méthodes HTTP, routes et descrip-
tions)
Méthode
HTTP
Route Description2 Type de
lâopération3
GET /api/clients Récupérer la liste des
clients
Lecture seule
GET /api/clientt/1 Récupérer les infor-
mations relatives au
client ayant l’ identi-
fiant 1
Lecture seule
POST /api/client Ajouter un nouveau
client
Ecriture
PUT /api/client/1 Mettre à jour le client
qui posséde lidenti-
fiant 1
Ecriture
PATCH /api/client/1 Mise à jour partielle
des informations du
client qui posséde l’
identifiant 1
Ecriture
DELLETE /api/restaurant/1 Suprimer le client
dont lidentifiant est
égal aÌ 1
Ecriture
Format et représentation
Les données échangées entre le serveur et le client peuvent avoir plusieurs
formats : JSON, XML, CSV, etc. Mais vu sa simplicité et la rapidité de sa
lecture, JSON est le plus utilisé.
JSON : c’ est un format de données textuelles dérivé de la notation
des objets du langage JavaScript. Il permet de représenter de lâinformation
structurée comme le permet XML par exemple [].
32
Exemple
Figure 12 – Exemple d’ une reqête GET et réponse du serveur
33
Annexe.B : Authentification à
base de token
Principe
Les jetons sont utilisés pour prouver une identité par voie électronique .
Par exemple, un client tenant d’ accéder à son profil [5] .
Dans le cas des applications où on a besoin de plusieurs connexions simul-
tannés. Plusieurs utilisateurs vont éffectuer reqêtes d’ une façon simultané sur
le serveur. c’ est pour celà qu’ on doit identifier chaque utilisateur par son
jeton qui lui identifie. Un utilisateur authentifié avec succé reçoit automati-
quement son jeton. Ce dernier est une chaîne de caractŕes de longueur et de
durée de vie bien determinée.
JWT : JSON Web Token
Description
Les JWT sont des jetons générés par un serveur lors de l’ authentification
d’ un utilisateur sur une application web, et qui sont ensuite transmis au client
[6] .
Pourquoi JWT
Dans le cas d’ une application où on consomme des API REST. Le transfert
des données se fait à travers des reqêtes HTTP et sous format JSON. Et c’
est comme ça que l’ authentification avec JWT fonctionne.
Structure d’ un jeton JWT
Un jeton JWT se compose de 3 champs selon la norme RFC 7519. La
figure ci-dessous représente les différents champs d’ un exemple de jeton JWT
[7] .
35
Figure 13 – Structure d’ un jeton JWT
- Header : Contient l’ algorithme utilisé pour la signature ainsi que le
type de jeton.
- Payload : Le champ dans lequel se trouve les informations de l’
utilisateur, le temps de la requête ...etc
- Signature : Contient la concaténation du header et Payload chiffrés
avec la clé privée.
Requête d’ obtention du token JWT
Dans les deux figures ci-dessous on reprśente, à l’ aide de Postman la
requête ainsi que la réponse pour l’ obtention d’ un token JWT
36
Figure 14 – Requête de l’authentification
Ici la réponse du serveur qui contient le token. Dans le cas de l’ échec de
l’ authentification on reçoit un message d’ erreur.
Figure 15 – Réponse reçue par le serveur
37
Bibliographie
[ 1 ] Big Deal. https ://www.bigdeal.tn/ [En ligne ; derniére consulta-
tion :14.03.2017].
[ 2 ] Restaurant-internet . http ://restaurant-internet.com/product [En
ligne ; derniére consultation :14.03.2017]
[ 3 ] Resto-Tunisie. http ://www.resto-tunisie.com/ [En ligne ; derniére
consultation :14.03.2017]
[ 4 ] On a mangé pour vous. http ://www.onamangepourvous.tn/ [En ligne ;
derniére consultation :21.03.2017]
[ 5 ] Les tokens d’ authentification. https ://www.supinfo.com/articles/single/2759-
tokens-authentification [En ligne ; derniére consultation :21.04.2017]
[ 6 ] Jetons JWT et sécurité .Principes et cas d’ utilisation. https ://www.vaadata.com
//blog/frjetons-jwt-et-securite-principes-et-cas-dutilisation/ [En ligne ; derniére
consultation :21.04.2017]
[ 7 ] Token-Based Authentication With AngularJS & NodeJS. https ://code.tutsplus.com
/tutorials/token-based-authentication-with-angularjs-nodejs- -cms-22543 [ En
ligne ; derniére consultation :21.04.2017 ]
39

Contenu connexe

Tendances

Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...
Ayoub Mkharbach
 
gestion de magasin vente matériels informatique
gestion de magasin vente matériels informatiquegestion de magasin vente matériels informatique
gestion de magasin vente matériels informatiqueOussama Yoshiki
 
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Nawres Farhat
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
FaissoilMkavavo
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
Lina Meddeb
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
Donia Hammami
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben Slima
Ilef Ben Slima
 
Presentation pfe Système de gestion des rendez-vous médicaux
Presentation pfe Système de gestion des rendez-vous médicauxPresentation pfe Système de gestion des rendez-vous médicaux
Presentation pfe Système de gestion des rendez-vous médicaux
Fehmi Arbi
 
Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2
Ben Abdelwahed Slim
 
Présentation resto
Présentation restoPrésentation resto
Présentation resto
Mehdi Labidi
 
Rapport de stage du fin d'étude
Rapport de stage du fin d'étudeRapport de stage du fin d'étude
Rapport de stage du fin d'étude
Yahyaoui Mohamed Yosri
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...
Addi Ait-Mlouk
 
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et HelpdeskRapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Raef Ghribi
 
Présentation PFE : Mise en place d’une solution de gestion intégrée (OpenERP...
Présentation PFE :  Mise en place d’une solution de gestion intégrée (OpenERP...Présentation PFE :  Mise en place d’une solution de gestion intégrée (OpenERP...
Présentation PFE : Mise en place d’une solution de gestion intégrée (OpenERP...
Mohamed Cherkaoui
 
Présentation pfe Développement d'une application bancaire mobile
Présentation pfe Développement d'une application bancaire mobilePrésentation pfe Développement d'une application bancaire mobile
Présentation pfe Développement d'une application bancaire mobile
Nader Somrani
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
Ilyas CHAOUA
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
Rouâa Ben Hammouda
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
Nader Somrani
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
Anouar Kacem
 

Tendances (20)

Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...
 
gestion de magasin vente matériels informatique
gestion de magasin vente matériels informatiquegestion de magasin vente matériels informatique
gestion de magasin vente matériels informatique
 
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben Slima
 
Presentation pfe Système de gestion des rendez-vous médicaux
Presentation pfe Système de gestion des rendez-vous médicauxPresentation pfe Système de gestion des rendez-vous médicaux
Presentation pfe Système de gestion des rendez-vous médicaux
 
Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2
 
Présentation resto
Présentation restoPrésentation resto
Présentation resto
 
Rapport de stage du fin d'étude
Rapport de stage du fin d'étudeRapport de stage du fin d'étude
Rapport de stage du fin d'étude
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...
 
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et HelpdeskRapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
 
Présentation PFE : Mise en place d’une solution de gestion intégrée (OpenERP...
Présentation PFE :  Mise en place d’une solution de gestion intégrée (OpenERP...Présentation PFE :  Mise en place d’une solution de gestion intégrée (OpenERP...
Présentation PFE : Mise en place d’une solution de gestion intégrée (OpenERP...
 
Présentation pfe Développement d'une application bancaire mobile
Présentation pfe Développement d'une application bancaire mobilePrésentation pfe Développement d'une application bancaire mobile
Présentation pfe Développement d'une application bancaire mobile
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
 
Pfe 2015
Pfe 2015Pfe 2015
Pfe 2015
 

Similaire à Conception et developpement d'un site web pour la suggestion et notification des restaurants et salons de thé

Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
Adem Amen Allah Thabti
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
SafaAballagh
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Houssem Eddine Jebri
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
mouafekmazia
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti MohammedRapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Mohammed JAITI
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
Hosni Mansour
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objets
Université de Rennes 1
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développement
Glei Hadji
 
Rapport de projet de fin d"études
Rapport de projet de fin d"étudesRapport de projet de fin d"études
Rapport de projet de fin d"études
Mohamed Boubaya
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de test
ahmed oumezzine
 
Fourth year internship report
Fourth year internship reportFourth year internship report
Fourth year internship report
Slimane Akaliâ , سليمان أقليع
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFE
Donia Hammami
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédia
Nazih Heni
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
ichrafkhalfaoui
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
Ben Ahmed Zohra
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Mohamed Amine Mahmoudi
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
nesrine haloui
 
Android VoIP/SIP Softphone
Android VoIP/SIP SoftphoneAndroid VoIP/SIP Softphone
Android VoIP/SIP SoftphoneHamza Lazaar
 

Similaire à Conception et developpement d'un site web pour la suggestion et notification des restaurants et salons de thé (20)

Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti MohammedRapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objets
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développement
 
Rapport de projet de fin d"études
Rapport de projet de fin d"étudesRapport de projet de fin d"études
Rapport de projet de fin d"études
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de test
 
Fourth year internship report
Fourth year internship reportFourth year internship report
Fourth year internship report
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFE
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédia
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
 
Android VoIP/SIP Softphone
Android VoIP/SIP SoftphoneAndroid VoIP/SIP Softphone
Android VoIP/SIP Softphone
 

Dernier

Rénovation des prairies sans labour est-ce possible en bio.pdf
Rénovation des prairies sans labour est-ce possible en bio.pdfRénovation des prairies sans labour est-ce possible en bio.pdf
Rénovation des prairies sans labour est-ce possible en bio.pdf
idelewebmestre
 
PFE MASTER en Développement d’une Application E-commerce avec la Technologie ...
PFE MASTER en Développement d’une Application E-commerce avec la Technologie ...PFE MASTER en Développement d’une Application E-commerce avec la Technologie ...
PFE MASTER en Développement d’une Application E-commerce avec la Technologie ...
ayoub_anbara96
 
S210-S-27.04-chaudiere-à-vapeur bilan thermique
S210-S-27.04-chaudiere-à-vapeur bilan thermiqueS210-S-27.04-chaudiere-à-vapeur bilan thermique
S210-S-27.04-chaudiere-à-vapeur bilan thermique
ALIIAE
 
Note Agro-climatique et prairies n°4 - Juin 2024
Note Agro-climatique et prairies n°4 - Juin 2024Note Agro-climatique et prairies n°4 - Juin 2024
Note Agro-climatique et prairies n°4 - Juin 2024
idelewebmestre
 
PFE ABDOUS BERRI 2024, RAPPORT COMPLET RETA FINAL.pdf
PFE ABDOUS BERRI 2024, RAPPORT COMPLET RETA FINAL.pdfPFE ABDOUS BERRI 2024, RAPPORT COMPLET RETA FINAL.pdf
PFE ABDOUS BERRI 2024, RAPPORT COMPLET RETA FINAL.pdf
iheberry
 
Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
Daniel Bedard
 
SRE - Mythes et Réalités - Voxxed 2024.pdf
SRE - Mythes et Réalités - Voxxed 2024.pdfSRE - Mythes et Réalités - Voxxed 2024.pdf
SRE - Mythes et Réalités - Voxxed 2024.pdf
Henri Gomez
 

Dernier (7)

Rénovation des prairies sans labour est-ce possible en bio.pdf
Rénovation des prairies sans labour est-ce possible en bio.pdfRénovation des prairies sans labour est-ce possible en bio.pdf
Rénovation des prairies sans labour est-ce possible en bio.pdf
 
PFE MASTER en Développement d’une Application E-commerce avec la Technologie ...
PFE MASTER en Développement d’une Application E-commerce avec la Technologie ...PFE MASTER en Développement d’une Application E-commerce avec la Technologie ...
PFE MASTER en Développement d’une Application E-commerce avec la Technologie ...
 
S210-S-27.04-chaudiere-à-vapeur bilan thermique
S210-S-27.04-chaudiere-à-vapeur bilan thermiqueS210-S-27.04-chaudiere-à-vapeur bilan thermique
S210-S-27.04-chaudiere-à-vapeur bilan thermique
 
Note Agro-climatique et prairies n°4 - Juin 2024
Note Agro-climatique et prairies n°4 - Juin 2024Note Agro-climatique et prairies n°4 - Juin 2024
Note Agro-climatique et prairies n°4 - Juin 2024
 
PFE ABDOUS BERRI 2024, RAPPORT COMPLET RETA FINAL.pdf
PFE ABDOUS BERRI 2024, RAPPORT COMPLET RETA FINAL.pdfPFE ABDOUS BERRI 2024, RAPPORT COMPLET RETA FINAL.pdf
PFE ABDOUS BERRI 2024, RAPPORT COMPLET RETA FINAL.pdf
 
Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
 
SRE - Mythes et Réalités - Voxxed 2024.pdf
SRE - Mythes et Réalités - Voxxed 2024.pdfSRE - Mythes et Réalités - Voxxed 2024.pdf
SRE - Mythes et Réalités - Voxxed 2024.pdf
 

Conception et developpement d'un site web pour la suggestion et notification des restaurants et salons de thé

  • 1. République Tunisienne Ministére de l’Enseignement Supérieur et de la Rcherche scientifique Université de Tunis El Manar Département Technologies de l’Information et de la Communication Rapport du Projet de Fin d’Année Conception et développement d’un site web pour la suggestion et notification des restaurants et salons de thé présenté par JAOUADI Houssemeddine & BOUBAYA Mouhamed Encadré par M BEN AISSA Anis Groupe : 2Année Télécommnications 1 Année Universitaire : 2016-2017
  • 2. Remerciements Avant de commencer notre rapport du projet de fin d’année, nous voulons exprimer notre gratitude envers tous ceux qui nous ont encouragé, soutenue et aidé pour le bon déroulement de ce projet. Nous remercions également, l’ ensemble du cadre enseignant de l’ Ecole Nationale d’ Ingénieurs de Tunis et en particulier Monsieur Anis BEN AISSA, pour son suivi, son aide et la qualité de l’ encadrement dont il nous a fait bénéficier.
  • 3. Conception et développement d’un site web pour la suggestion et notification des restaurants et des salons thé Résumé : ce projet consiste à concevoir et réaliser une solution de marketing pour les restaurants, pâtisseries, salons de thé sous la forme d’un réseau social. Ainsi, ce dernier offre à ces établissements la possibilité de présenter gratuitement leurs produits, promotions, offres. Cela à travers des publications (photos, statuts écrites, vidéos, GIF) dans un espace ouvert permettant l’interaction directe avec leurs clients. En revanche, un visiteur inscrit et authentifié peut consulter et suivre les publications des établissements et réagir avec elles (satisfait ou non, commentaire, partage). Il peut aussi consulter leurs zones géographiques à l’aide d’une interface Google Maps dans laquelle il est indiqué la zone où se trouve chaque établissement. Mots clés : API, service web, REST, HTTP, établissement, page, publica- tion,client
  • 4. Table des matières Introduction générale 1 1 Présentation génerale du projet 2 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.1 Objectif du projet . . . . . . . . . . . . . . . . . . . . . 3 1.3 Etude préalable . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3.1 Etude de l’existant . . . . . . . . . . . . . . . . . . . . 3 1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . 4 1.3.3 Solutions proposées . . . . . . . . . . . . . . . . . . . . 4 1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2 Analyse et spécification des besoins 6 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . 7 2.2.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . 7 2.2.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . 8 2.3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . 9 2.3.1 Vue globale du système . . . . . . . . . . . . . . . . . . 9 2.3.2 Diagrammes de cas d’ utilisation raffinés . . . . . . . . 10 2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3 Conception 12 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2 Conception globale . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . 14 3.3.2 Diagrammes de séquences . . . . . . . . . . . . . . . . 15 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4 Réalisation 18 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . 19 4.2.1 Environnement matériel . . . . . . . . . . . . . . . . . 19 4.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . 19 4.3 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . 20
  • 5. TABLE DES MATIÈRES 4.4 Travail réalisé et scénarios d’ exécution . . . . . . . . . . . . . 21 4.4.1 Le sénario du client . . . . . . . . . . . . . . . . . . . . 22 4.4.2 Le sénario du représentant d’ établissement . . . . . . . 26 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Conclusion et perspectives 29 Bibliographie 38 iv
  • 6. Table des figures 2.1 Diagramme de cas d’ utilisation global . . . . . . . . . . . . . 9 2.2 Diagramme de cas d’ utilisation du client . . . . . . . . . . . . 10 2.3 Diagramme de cas d’ utilisation du Représentant de l’ établis- sement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1 Architecture globale du systeme . . . . . . . . . . . . . . . . . 13 3.2 Diagramme de classes de la couche modèle . . . . . . . . . . . 14 3.3 Diagramme de séquence de l’ authentification . . . . . . . . . 16 3.4 Diagramme de séquence de la création d’ une publication . . . 17 4.1 Architecture technique et choix technologiques . . . . . . . . . 20 4.2 Inscription pour un client . . . . . . . . . . . . . . . . . . . . 22 4.3 Authentification du client . . . . . . . . . . . . . . . . . . . . 22 4.4 Profil du client . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.5 Page de recherche d’ établissements . . . . . . . . . . . . . . . 23 4.6 Indication géographique d’ un établissement . . . . . . . . . . 24 4.7 Page principale d’ un établissement . . . . . . . . . . . . . . . 25 4.8 Réactions sur une publication . . . . . . . . . . . . . . . . . . 26 4.9 Ajout d’ établissement . . . . . . . . . . . . . . . . . . . . . . 27 4.10 Ajout d’ un article . . . . . . . . . . . . . . . . . . . . . . . . 27 4.11 Ajout d’ une publication . . . . . . . . . . . . . . . . . . . . . 28 12 Exemple d’ une reqête GET et réponse du serveur . . . . . . 33 13 Structure d’ un jeton JWT . . . . . . . . . . . . . . . . . . . . 36 14 Requête de l’authentification . . . . . . . . . . . . . . . . . . . 37 15 Réponse reçue par le serveur . . . . . . . . . . . . . . . . . . . 37
  • 7. Liste des tableaux 4.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . 19 2 Exemple d’ une API REST (Méthodes HTTP, routes et des- criptions) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
  • 8. Liste des acronymes API Application Programming Interface CSS Cascading de Stile Sheet ENIT Ecole Nationale d’ Ingénieurs de Tunis HTML HyperText Markup Language HTTP HyperText Transfer Protocol JS JavaScript JSON JavaScript Object Notation JWT JSON Web Token ORM ObjectRelational Mapping PFA Projet Fin d’ Année PHP PhpHypertext Processor REST Representational State Transfer SGBD Système de Gestion de Bases de Données SQL SStructured Quering Language UML UnifiedModeling Language
  • 9. Introduction générale Les réseaux sociaux sont devenues les environnements les plus favorables pour les producteurs pour promettre leurs produits tout en assurant son ef- ficacité et sa rentabilité . En effet, la plupart de ces réseaux garantissent la gratuité d’un grand part du marketing. Ils leurs offrent un espace libre per- mettant une interraction directe entre le consommateur et le producteur. Cela se fait à travers les publications, les commentaires, le partage des avis. En Tunisie, on remarque bien que les restaurants, les cafés et les salons de thé trouvent un succès en matière de rentabilité. Ainsi, ces établissements cherchent toujours des nouvelles méthodes et des nouvelles solutions de mar- keting moins couteuses et très performantes en même temps. En revanche, les clients ont besoin d’une application qui leur permet de consulter le plus grand nombre possible d’ établissements et découvrir ainsi leurs produits, offres, promotions. Et de les évaluer et réagir avec elles. On s’intéresse alors dans ce cadre à concevoir puis développer un réseau social sous la forme d’un site Web dynamique. Ce rapport sera alors réparti comme suit : - Une partie pour la présentation génerale du contexte de notre projet - La deuxième partie sera consacrée à l’ analyse et la spécification des besoins - La troisiéme s’ occupera de la conception de notre application - Dans la derniére partie nous décriverons le travail réalisé de notre projet
  • 10. Chapitre 1 Présentation génerale du projet Sommaire 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . 3 1.2.1 Objectif du projet . . . . . . . . . . . . . . . . . . . . 3 1.3 Etude préalable . . . . . . . . . . . . . . . . . . . . . . . 3 1.3.1 Etude de l’existant . . . . . . . . . . . . . . . . . . . . 3 1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . 4 1.3.3 Solutions proposées . . . . . . . . . . . . . . . . . . . . 4 1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 5
  • 11. 1.1 Introduction 1.1 Introduction Dans ce premier chapitre, nous allons commencer en un premier lieu par expliquer le cadre du projet. Puis, faire notre étude préalable qui contient l’ étude, la critique de l’ existant et nos solutions proposées. 1.2 Cadre du projet Ce projet est un travail de binômes dans le cadre du projet de fin d’année (PFA) ayant comme sujet " Conception et développement d’ un site web pour la suggestion et notification des réstaurants et des salons de thé " 1.2.1 Objectif du projet Nous sommes demandés dans ce projet de faire la conception puis le dé- veloppement d’ un site web qui réunit les restaurants et les salons de thé avec leurs clients. Notre application vérifie les spécificités d’un réseau social classique. En effet, elle offre aux établissements la possibilité de créer des publications (publier des photos, vidéos, GIF ...) au sein de leurs pages. Elle offre aux clients la possibilité de consulter ces publications et réagir avec elles. Elle leurs offre d’ avantage l’ occasion de consulter géographique- ment les locaux des établissements à travers une interface de Google Maps. Notre application dispose aussi de plus d’ une recherche rapide et intelligente. 1.3 Etude préalable Dans cette partie du rapport on va entamner l’étude de l’existant. Puis on va le critiquer pour en deduire des solutions qui seront proposés au sein de notre projet 1.3.1 Etude de l’existant On a fait ici une recherche sur les sites qui proposent des solutions de Marketing similaires pour les restaurants, cafés, salons de thé . Nous avons alors dégagé les informations ci-dessous. - BIGDeal.tn : est un site web d’achat groupé qui propose à ses visi- teurs des réductions pour des offres diversifiés, BigDeal publie toujours les offres de tout type de restaurants, cafés, hotels ...etc. Il joue le rôle de l’intermédiére entre l’établissement et le client [1] . 3
  • 12. 1.3 Etude préalable - restaurant-internet.com : c’est un site web permettant aux restau- rants de créer leurs interfaces web dans lesquelles ces dérniers peuvent publier leurs informations, actualitées, produits ... etc [2]. - resto-tunisie.com : ce site permet de regrouper les restaurants, cafés, pÃtisseries âetc en Tunisie et offre à ses visiteurs de consulter les menus ainsi que passer des commandes et réserver en ligne [3]. - onamangepourvous.tn : On a mangé pour vous est une plateforme dans laquelle on trouve les produits délivrés par des restaurants et des salons de thé en Tunisie, les visiteurs peuvent rágir avec ces produits et donner leurs avis à propos des prix, la qualité de service et du menu proposé [4]. La gestion des établissements de ce genre n’ est plus facile vu la concurrence dù à l’augmentation de leur nombre dans le monde et surtout en Tunisie. Les outils dont on a déja parlé et d’autes proposent des différentes solutions pour faciliter l’opération de marketing. Chacun essaie d’offrir une solution innovante et efficasse. Dans les parties suivante, on va critiquer ce genre de solutions et on va proposer d’autres. 1.3.2 Critique de l’existant Certes les outils cités précédement sont utiles, connues et serviables, mais ils souffrent de plusieurs limites. Nous allons maintenant les décrire : - Elles ne sont pas gratuites. Un étqblissement doit payer pour pouvoir publier quelque chose - Pas d’ interractions entre le client et l’ établissement. Elles ne donnent pas aux clients la possibilité de réagir avec les publications ou de contac- ter les établisements - Absence de recherche géographique. Un client ne peut pas consulter l’ adresse de l’ établissement directement à travers un map. 1.3.3 Solutions proposées La solution proposée est d’aller dans l’approche des réseaux sociaux et de concevoir et développer un réseau social pour les restaurants et les salons de thé. Notre application comporte trois acteurs : Un client, un représentant d’ établissement et un super administrateur. Elle sera décomposée comme suit : - Un espace d’authentification : comporte deux pages : une pour l’inscription des clients et autre pour l’authentification. - Une page d’établissement : dans laquelle le représentant peut par- tager des publications, voir les réactions des visiteurs et répondre à 4
  • 13. 1.4 Conclusion leurs commentaires. - Une page d’accueil : dans laquelle un client peut consulter les nou- vautés des pages des établissements qu’il suit. - Une interface pour le profil de chaque client - Un espace d’administration : dedié au super administrateur. Il contient une interface pour la gestion des établissements et une pour la gestion des clients. 1.4 Conclusion Dans ce chapitre, on a commencé par une présentation du cadre du projet dans laquelle on a décrit son objectif. Puis, on a passé par une étude préalale qui contient l’ étude de et la critique de l’existant accampagné de quelques solutions proposées. A ce qui concerne le chapitre suivant, on s’ interessera à l’ analyse des besoins fonctionnels et non fonctionnels et á la specification de ces besoins. 5
  • 14. Chapitre 2 Analyse et spécification des besoins Sommaire 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . 7 2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . 7 2.2.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . 7 2.2.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . 8 2.3 Spécification des besoins . . . . . . . . . . . . . . . . . 9 2.3.1 Vue globale du système . . . . . . . . . . . . . . . . . 9 2.3.2 Diagrammes de cas d’ utilisation raffinés . . . . . . . . 10 2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
  • 15. 2.1 Introduction 2.1 Introduction Ce chapitre sera divisé en deux parties : La premiére est une analyse des besoins dans laquelle on va citer en un premier lieu les différents acteurs inter- venants dans l’application. En second lieu on va décrir d’ une façon détaillée nos besoins fonctionnels et non fonctionnels. Dans la deuxiéme partie on s’in- teressera à la spécification de ces besoins à traves les diagrammes de cas d’ utilisation de l’ UML. 2.2 Analyse des besoins 2.2.1 Identification des acteurs On s’intéresse maintenant à présenter les acteurs qui sont en contact direct avec l’ application et qui profitent de différenrs accés aux données. (Notons ici que tout genre d’ accée est obligatoirement authentifié) - Client : C’ est l’ utilisateur qui peut consulter des pages et des pu- blications et réagir avec elles. - Représentant d’ établissement : c’ est l’ administrateur de la page de l’ établissement qu’ il reprśente. Il peut gérer les publications et les informations sur sa page et se comporte aussi comme un client. - Super administrateur : il gére les pages (création, modification et suppression) et affecte les représentants aux établissements ainsi qu’ il peut gérer les clients. 2.2.2 Besoins fonctionnels Notre application doit permettre les différents acteurs de s’ inscrir, s’au- thentifier afin d’ accéder à leurs données. il peuvent ainsi consulter leurs pro- files et modifier leurs informations. Pour le reste des besoins fonctionnels, ils varient d’ un acteur à un autre qu’ on va les spécifier pour chacun en détail Client : - Un client est caractérisé par son nom, son prénom, adresse, numéro de téleéphone, email, mot de passe et pseudo. - Les informations d’ un clients doivent l’ être accessibles pour qu’ il puisse les consulter et les modifier - Dispose d’ un éspace pour faire des recherches sur les établissements qui existent 7
  • 16. 2.2 Analyse des besoins - Il peut consulter n’ importe quelle page et suivre ses actualitées soit par visiter la page directement ou bien à travers sa page d’ accueil - Il peut aussi réagir avec des publications en la notant ou par des com- mentaires. Représentant d’ établissement : - C’ est un utilisateur inscrit comme étant un client, affecté par le super administrateur à la page de l’ établessement qu’ il représente pour pouvoir la gérer - Un établissement est caractérisé par un nom, une adresse, une specialité et une catégorie. - Il peut gérer les informations de la page de son établissement. - Il peut gérer les publications sur sa page ( les publications peuvent être des textes simples ou peut contenir des images ...) et réagir avec les commentaires et les avis des visiteurs de la page. Super administrateur - C’est le seul qui peut gérer les pages des établissements et leurs affecter des représentants - Peut aussi gérer les clients 2.2.3 Besoins non fonctionnels Les besoins non fonctionnels forment l’ ensemble des contraintes techniques auquelles notre système doit répondre. - La rapidité : le temps de traitement exigé par l’ application doit être suffisamment court pour garantir l’ accés souhaitable aux informations - La sécurité : Tout type d’ accés aux donnée doit être authentifié. Aussi, l’application doit contenir un systéme permettant la gestion des mots de passe, l’authentification sécurisée et les droits d’accés - La performance : Les algorithmes utilisés pour certains traitements dovent avoir une complexité la plus faible que possible ainsi qu’ une utilisation économique des ressources. - Maintenabilité et convivialité : Ce genre de sites web ou d’ appli- cations doit être dedié vers toutes les catégories de gens elle doit ainsi être facile en usage et en apprentissage. - Portabilité : L’ application doit fonctionner sur n’importe quel type de machine et de syst `me d’ exploitation et accessible à travers le plus 8
  • 17. 2.3 Spécification des besoins grand nombre des navigateurs connus et largement utilisés (Chrom, FireFox, Edge, Safari ...) 2.3 Spécification des besoins Ici on va spécifier nos besoins en se basant sur les diagrammes de cas d’ utlisation de l’ UML 2.3.1 Vue globale du système Nous sitons ici le diagramme de cas d’ utilisation global de notre applica- tion Figure 2.1 – Diagramme de cas d’ utilisation global 9
  • 18. 2.3 Spécification des besoins 2.3.2 Diagrammes de cas d’ utilisation raffinés 2.3.2.1 Diagrammes de cas d’ utlisation du client Nous décrivons ici le diagramme de cas d’ utilisation du client Figure 2.2 – Diagramme de cas d’ utilisation du client 2.3.2.2 Diagrammes de cas d’ utlisation du représentant d’ établis- sement Nous décrivons ici le diagramme de cas d’ utilisation du Représentant de l’ établissement 10
  • 19. 2.4 Conclusion Figure 2.3 – Diagramme de cas d’ utilisation du Représentant de l’ établis- sement 2.4 Conclusion Dans ce chapitre nous avons commencé par une analyse des besoins dans laquelle nous avons cité nos besoins fonctionnels et non fonctionnels. Puis nous avons décrit la spécification de ces besoins en se basant sur les diagrammes de cas d’ utilisation de l’ UML. Dans le chaitre suivant on va entamner la conception de notre application. 11
  • 20. Chapitre 3 Conception Sommaire 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2 Conception globale . . . . . . . . . . . . . . . . . . . . . 13 3.3 Conception détaillée . . . . . . . . . . . . . . . . . . . . 14 3.3.1 Diagramme de classes . . . . . . . . . . . . . . . . . . 14 3.3.2 Diagrammes de séquences . . . . . . . . . . . . . . . . 15 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17
  • 21. 3.1 Introduction 3.1 Introduction Avant de commencer le développement ou la réalisation d’ une solution qui répond aux besoins demandés il est nécessaire de faire sa conception. Dans cette étape nous nous intéressons à la description de la conception globale de notre système ainsi que la conception détaillée. 3.2 Conception globale Nous cherchons, au cours de la réalisation de notre projet, à augmenter l’ éfficacité de l’ organisation de notre travail. Nous devons alors choisir une architecture qui nous offre tout ça et nous aide à améliorer la qualité de notre application. Nous avons alors opté à utiliser l’ architecture trois tiers qui est la plus utilisée par les développeurs dans le monde et qui répond à nos objectifs. Elle est expliquée dans la figure 3.1 ci-dessous Figure 3.1 – Architecture globale du systeme Couche presentation : Un seul type de client : Client léger : Accessible par tous les acteurs à travers un navigateur Web . Couche metier : Cette couche présente la partie fonctionnelle de notre application. Elle contient les traitements fait sur les données et forme un intermediére entre la base de données et les clients. Elle fait la gestion des requêtes envoyées par le client ainsi que les réponses qu’ il reçoive. Couche Accés aux données : Ce tiers est responsable au stockage des don- nées dans une base de donnée centrale ainsi que la gestion de ces derniers. 13
  • 22. 3.3 Conception détaillée 3.3 Conception détaillée A l’ aide des diagrammes du langage UML, nous allons entamner dans cette partie la conception détaillée de notre application. 3.3.1 Diagramme de classes La figure ci-dessous présente le diagramme de classe des enitités de notre système. Figure 3.2 – Diagramme de classes de la couche modèle - Utilisateur : cette classe représente l’ utilisateur de l’ application qui peut être soit un client, soit un représentant d’ établissement ou bien le super administrateur - Etablissement : Cette entité décrit les établissements qui sont gérés par leurs représentants - Article : Chaque établissement offre un ensemble d’ articles - Publication : Un établissement peut toujours partager des publica- tions pour les clients. Une publication peut contenir un article. 14
  • 23. 3.3 Conception détaillée - Commentaire : chaque publication peut être commentée par les utilisateurs 3.3.1.1 Schémas relationnel Le shéma relationnelle est consitue d’une ensemble des shémas de tables de base de donnèes . Voici les schémas relationnels de notre base de donnée : - Utilisateur (id ,nom , prénom , email, adresse, pseudo, mot_de_passe, is_admin, path_photo) - Etablissement (id, nom, categorie, adresse, specialite, path_photo, #id_representant) - Article (id, nom, prix, path_photo, #id_etablissement) - Publication (id,contenue, titre, date, #id_etablissement, #id_article) - Commentaire (id , contenue , date, #id_utilisateur, #id_publication) - Suit(id_utlisateur ,#id_etablissement) 3.3.2 Diagrammes de séquences 3.3.2.1 Diagramme de séquence de l’ authentification La figure 3.4 représente le diagramme de séquence de l’ authentification 15
  • 24. 3.3 Conception détaillée Figure 3.3 – Diagramme de séquence de l’ authentification Afin d’ améliorer la sécurité, on utilise l’ authentification à base de token ( voir Annexe B). Le diaramme de séquence ci-dessus explique les étapes de l’ authentification d’ un client. Ce dernier doit saisir son pseudo et son mot de passe dans les champs convenables. les données saisis seront envoyées dans une reqête HTTP vers l’ API de route /api/login_check avec la méthode POST. si les données sont correctes on lui renvoie son token et son profil et on le renvoie un erreur et il sera redirigé de nouveau vers la page de l’ authentifica- tion. La figure 3.4 représente le diagramme de séquence de la création d’ une publication 16
  • 25. 3.4 Conclusion Figure 3.4 – Diagramme de séquence de la création d’ une publication Un utlisateur demande la page d’ un établissement, il envoie alors son token dans une requête GET pour demander les informations de l’ établissement, s’ il est son représentant, la page de gestion de l’ établissement est retournée. Dans le cas contraire, on lui retourne la page accessible par le simple client. 3.4 Conclusion Dans ce chapitre nous avons expliqué la conception de notre projet. Nous avons commencé par la conception globale. Puis nous avons passé à la concep- tion détaillée dans laquelle nous avons cité le diagramme de classe et les dia- grammes de séquence de l’authenification et de la création de publication. Le prochain chapitre sera consacré à la réalisation de notre application. 17
  • 26. Chapitre 4 Réalisation Sommaire 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2 Environnement de travail . . . . . . . . . . . . . . . . . 19 4.2.1 Environnement matériel . . . . . . . . . . . . . . . . . 19 4.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . 19 4.3 Choix technologiques . . . . . . . . . . . . . . . . . . . 20 4.4 Travail réalisé et scénarios d’ exécution . . . . . . . . 21 4.4.1 Le sénario du client . . . . . . . . . . . . . . . . . . . . 22 4.4.2 Le sénario du représentant d’ établissement . . . . . . 26 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28
  • 27. 4.1 Introduction 4.1 Introduction Aprés avoir traité la partie conception de notre travail nous allons, dans ce chapter, expliquer le travail réalisé pendant notre projet, nous allons com- mencer par l’ environnement du travail dans lequelle nous précisons l’ envi- ronnement matériel ainsi que l’ environnement logiciel et nous allons passer aprés à expliquer nos choix technologiques et terminer par décrire le travail réalisé et les scénarios dâexécution de notre application. 4.2 Environnement de travail 4.2.1 Environnement matériel Le matériel étant à notre disposition pendant le développement de notre application est formé par deux ordinateus portables dont les caractéristiques sont cités dans la table suivante : Table 4.1 – Environnement matériel Ordinateur 1 Ordinateur 2 Processeur Intel core i 3 Processeur Intel core i 3 Mémoire : 4Go de RAM M ´moire : 4Go de RAM DD : 512 Go DD : 512Go SE : Linux Mint 17.2 SE : OS X yosemite 10.10.5 4.2.2 Environnement logiciel Nous Allons maintenant décrir l’ environnement logiciel avec lequel nous avons effectué notre travail. C’ est l’ensemble des outils et de logiciels que nous avons opté à utiliser pour pouvoir développer notre application. - Atom : Editeur de texte - Pluguin Symfony3 pour atom - PhpStorm : Environnement de développement intégré (EDI) déve- loppé par JetBrains, Il permet de supporter le language PHP. Il in- tégre également un support des gestionnaires de version tels que Git et CVS, une intégration des bases de données et des outils de test des API(Application programming interfaces) - Pluguin Symfony3 pour PhpStorm - Apache 2 : Serveur Web 19
  • 28. 4.3 Choix technologiques - MySQL : Système de gestion de base de donnés - PHPMyAdmin : Interface graphique développée en PHP et acces- sible par Web permettant la gestion du SGBD MySQL. - Git : Gestionnaire de version décentralisé. - Postman : Le client REST du navigateur Chrumium qui nous permet d’ exécuter des requêtes HTTP afin de tester des API REST - StarUML : Outil de modélisation UML - sharelatex : Éditeur de Document LaTeX en ligne. 4.3 Choix technologiques La figure suivante représente l’architechture technique et choix technolo- gique Figure 4.1 – Architecture technique et choix technologiques - HTML : C’est un language de balisage utilisé pour la création des pages web 20
  • 29. 4.4 Travail réalisé et scénarios d’ exécution - CSS : Un language qui permet de définir des styles sur un ou plusieurs documents - Angular JS : Frame-work JavaScript open-source développé par Google permettant développer des applications web dynamiques en utilisant le modéle MV-VM , on va l’ utiliser pour consommer les API REST dé- veloppés avec Symfony - PHP5 : Un langage de script fréquemment utilisé par les développeurs pour la création des pages web dynamiques. PHP est aussi le plus répendu chez les hébergeurs ce qui justifie notre choix. - Symfony3 : Frame-work ćrit en langage PHP permettant de séparer les trois couches du model MVC et nous l’ avons utilisé pour le déve- loppement de notre API REST. Doctrine : ORM du frame-work Symfony utilisé pour la gestion de la base de donnée. - JSON : Le format de notation des objets le plus leger et utilisé pour la communication du service web REST. - YML : Langage de configuration pour Symfony. 4.4 Travail réalisé et scénarios d’ exécution Nous allons ici décrire notre travail réalisé et nous allons éxpliquer le scé- narios dâ exécution à l’ aide des captures d’écran. La figure 4.2 montre l’ interface d’ inscription pour un client. 21
  • 30. 4.4 Travail réalisé et scénarios d’ exécution 4.4.1 Le sénario du client Figure 4.2 – Inscription pour un client Sachant que tout type d’ accé aux données doit être authentifié. La figure 4.3 présente l’ interface de l’ authentification Figure 4.3 – Authentification du client Aprés avoir être authentifié, Un client peut consulter son profil et le gérer. La figure 4.4 montre l’ interface qui contient le profil du client 22
  • 31. 4.4 Travail réalisé et scénarios d’ exécution Figure 4.4 – Profil du client Aussi, ce dernier profite d’ un éspace de recherche. Un client peut cher- cher un établissement avec son nom, son adresse, et sa catégorie. La figure 4.5 présente la page de recherche dans notre application. Les résultats de la recherches sont affichés sur la m ˆme page sans la refraichir (grace à AngularJs) Figure 4.5 – Page de recherche d’ établissements En faisant un simple clique sur la photo de l’ un des établissements affichés, 23
  • 32. 4.4 Travail réalisé et scénarios d’ exécution Une interface goosle map est aussi affichée sur la page indiquant sa position géographique comme le montre la figure ci-dessous. Figure 4.6 – Indication géographique d’ un établissement En cliquant aussi sur le nom d’ un établissement, un client peut consulter sa page. Cette page contient toutes les informations sur cet établissement ainsi que ses articles et ses publications comme le décrit la figure suivante : 24
  • 33. 4.4 Travail réalisé et scénarios d’ exécution Figure 4.7 – Page principale d’ un établissement En arrivant à ce stade, un utilisateur peut choisir une publication et réagir avec elle comme la montre la figure ci-dessous 25
  • 34. 4.4 Travail réalisé et scénarios d’ exécution Figure 4.8 – Réactions sur une publication 4.4.2 Le sénario du représentant d’ établissement Un représenatant doit tout d’abord créer la page de son établissement et attendre la validation du super administrateur. La figure 1.9 montre l’ interface destinée à l’ ajout de de l’ établissement. 26
  • 35. 4.4 Travail réalisé et scénarios d’ exécution Figure 4.9 – Ajout d’ établissement Aprés avoir être validée par le super administrateur, le représentant peut commencer à ajouter des articles et partager des publications comme le montre la figure 4.10 Figure 4.10 – Ajout d’ un article Le représentant peut ansi consulter la liste des articles de son établisse- ment et choisir un et lui ajouter une description puis le publier. La figure ci-dessous décrit cette opération 27
  • 36. 4.5 Conclusion Figure 4.11 – Ajout d’ une publication 4.5 Conclusion Dans ce chapitre, nous avons commencé par décrire notre environnement matériel de travail ainsi que notre environnement logiciel, puis nous avons passé aux choix techniques et nous avons terminé par les scénarios dâ exécu- tion. 28
  • 37. Conclusion et perspectives Tout au long de ce projet de fin d’ année, nous avons travaillé sur la concep- tion et le développement d’ un site web pour la suggestion et la notifications des restaurants et des salons de thé. Cette application ayant la forme d’ un ré- seau social présente une solution de marketing pour ce type d’ établissements. Nous avons commencé en premier lieu par la présentation du cadre géne- ral du projet. Dans cette partie nous avons expliqué le cadre du projet et son objectif. Puis, nous avons passé à citer quelques autres solutions similaires et les critiquer en dégageant leurs limites pour en proposer des nouvelles so- lutions.En second lieu nous avons entamné l’ analyse et la spécification des besoins. Nous avons cité les acteurs qui interviennent avec le site et nous avons décrit nos besoins fonctionnels et non fonctionnels. Puis, et à l’ aide des diagrammes de cas d’ utilisation du langage UML nous avons fait la spécifi- cation des besoins. La troisiéme partie était la partie conceptuelle de notre projet. Nous avons commencé par la conception générale puis la conception détaillée dans laquelle, et en se basant sur les diagrammes de l’ UML nous avons cité le diagramme de classe puis les diagrammes de séquence. Dans la derniére partie, nous avons parlé du travail réalisé à savoir les technologies et l’ environnement de travail ainsi que les sénarios déxecusion à l’ aide de la présentation des interfaces de l’ application. Ce projet effectué nous a permis dâ acquŕir une expérience enrichissante et de mettre en pratique les concepts et les méthodologies théoriques acquis durant notre cursus académique. Et de maîtriser de nouvelles technologies plus quâ intéressantes. Cependant, Nous pensons toujours d’ améliorer notre projet. En effet, Nous pouvons rajouter un module de chat et de notifications temps réel pour améliorer l’ interraction entre le client et l’ établissement. Nous pouvons aussi développer une application mobile pour les clients. D’ autre part, nous comp- tons développer des algorithmes pour améliorer la suggestion des établisse- ment, Par exemple, unalgorithme qui suit les activité des clients et qui peut savoir les types d’ établissement qu’ ils favorisent le plus.
  • 38. Annexe.A : Le service Web REST
  • 39. Le service Web Un service web est un protocole d’ interface informatique de la famille des technologies web permettant la communication et l’ échange des données entre applications et systèmes héterogénes [] La communication est toujours définie dans le cadre d’ un protocole de la couche application. Le protocole actuellement utilisé est HTTP. Le protocole HTTP Définition C’ est un protocole de communication client-serveur. HTTPS est la va- riante du HTTP sécurisée par l’ usage des protocoles SSL et TLS []. Les méthodes du protocole HTTP Les requêtes HTTP éffectuées sur le serveur disposent d’ une méthode qui est une commande qui a pour rôle de spécifier l’ action qu’ on veut éffectuer sur es ressources du serveur. API REST Définition Une API REST peut être modélisée comme une boite noire qui contient des fonctions chacune nous permet de gérer des ressources sur le serveur. Chaque fonction est distinguée par une route et une méthode HTTP. Ainsi, pour accéder au service d’ une fonction on envoie une requête HTTP avec sa méthode et sur sa route. Exemples Le tableau suivant présente un exemple d’ API de gestion d’ utilisateur. 31
  • 40. Table 2 – Exemple d’ une API REST (Méthodes HTTP, routes et descrip- tions) Méthode HTTP Route Description2 Type de lâopération3 GET /api/clients Récupérer la liste des clients Lecture seule GET /api/clientt/1 Récupérer les infor- mations relatives au client ayant l’ identi- fiant 1 Lecture seule POST /api/client Ajouter un nouveau client Ecriture PUT /api/client/1 Mettre à jour le client qui posséde lidenti- fiant 1 Ecriture PATCH /api/client/1 Mise à jour partielle des informations du client qui posséde l’ identifiant 1 Ecriture DELLETE /api/restaurant/1 Suprimer le client dont lidentifiant est égal aÌ 1 Ecriture Format et représentation Les données échangées entre le serveur et le client peuvent avoir plusieurs formats : JSON, XML, CSV, etc. Mais vu sa simplicité et la rapidité de sa lecture, JSON est le plus utilisé. JSON : c’ est un format de données textuelles dérivé de la notation des objets du langage JavaScript. Il permet de représenter de lâinformation structurée comme le permet XML par exemple []. 32
  • 41. Exemple Figure 12 – Exemple d’ une reqête GET et réponse du serveur 33
  • 42. Annexe.B : Authentification à base de token
  • 43. Principe Les jetons sont utilisés pour prouver une identité par voie électronique . Par exemple, un client tenant d’ accéder à son profil [5] . Dans le cas des applications où on a besoin de plusieurs connexions simul- tannés. Plusieurs utilisateurs vont éffectuer reqêtes d’ une façon simultané sur le serveur. c’ est pour celà qu’ on doit identifier chaque utilisateur par son jeton qui lui identifie. Un utilisateur authentifié avec succé reçoit automati- quement son jeton. Ce dernier est une chaîne de caractŕes de longueur et de durée de vie bien determinée. JWT : JSON Web Token Description Les JWT sont des jetons générés par un serveur lors de l’ authentification d’ un utilisateur sur une application web, et qui sont ensuite transmis au client [6] . Pourquoi JWT Dans le cas d’ une application où on consomme des API REST. Le transfert des données se fait à travers des reqêtes HTTP et sous format JSON. Et c’ est comme ça que l’ authentification avec JWT fonctionne. Structure d’ un jeton JWT Un jeton JWT se compose de 3 champs selon la norme RFC 7519. La figure ci-dessous représente les différents champs d’ un exemple de jeton JWT [7] . 35
  • 44. Figure 13 – Structure d’ un jeton JWT - Header : Contient l’ algorithme utilisé pour la signature ainsi que le type de jeton. - Payload : Le champ dans lequel se trouve les informations de l’ utilisateur, le temps de la requête ...etc - Signature : Contient la concaténation du header et Payload chiffrés avec la clé privée. Requête d’ obtention du token JWT Dans les deux figures ci-dessous on reprśente, à l’ aide de Postman la requête ainsi que la réponse pour l’ obtention d’ un token JWT 36
  • 45. Figure 14 – Requête de l’authentification Ici la réponse du serveur qui contient le token. Dans le cas de l’ échec de l’ authentification on reçoit un message d’ erreur. Figure 15 – Réponse reçue par le serveur 37
  • 46. Bibliographie [ 1 ] Big Deal. https ://www.bigdeal.tn/ [En ligne ; derniére consulta- tion :14.03.2017]. [ 2 ] Restaurant-internet . http ://restaurant-internet.com/product [En ligne ; derniére consultation :14.03.2017] [ 3 ] Resto-Tunisie. http ://www.resto-tunisie.com/ [En ligne ; derniére consultation :14.03.2017] [ 4 ] On a mangé pour vous. http ://www.onamangepourvous.tn/ [En ligne ; derniére consultation :21.03.2017] [ 5 ] Les tokens d’ authentification. https ://www.supinfo.com/articles/single/2759- tokens-authentification [En ligne ; derniére consultation :21.04.2017] [ 6 ] Jetons JWT et sécurité .Principes et cas d’ utilisation. https ://www.vaadata.com //blog/frjetons-jwt-et-securite-principes-et-cas-dutilisation/ [En ligne ; derniére consultation :21.04.2017] [ 7 ] Token-Based Authentication With AngularJS & NodeJS. https ://code.tutsplus.com /tutorials/token-based-authentication-with-angularjs-nodejs- -cms-22543 [ En ligne ; derniére consultation :21.04.2017 ]
  • 47. 39