projet fin d'année ENIT 2017 lien : https://github.com/Boubaya-Mohamed/End_of_year_project

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