Tunisian republic

Ministry of Higher Education

and Scientific Research
ESPRIT
Private Higher School of Engineering and
Technology

Rapport de stage ingénieur

specialité génie logiciel

Développement et réalisation d’une

plateforme pour commander et livraison des
repas

Realisé au sein de Confledis

Encadré par : Mr Akim Kabinda

Par :
Yosser Snoussi

Specialité : Software Architecture Engineering

Annee universitaire : 2022-2023

Remerciements
A l’occasion de ce stage j’ai l’honneur de présenter mes vifs remerciements à mon
encadrant MR Akim KABINDA ainsi à toute l’équipe de Confledis qui m’ont aidé et
contribué durant ce stage à me faire découvrir le milieu professionnel.

Je tiens également à remercier tous ceux qui m’ont fait preuve d’un grand esprit de
collaboration et d’initiative

Pour ma part, j’espère que ma conduite et mon apprentissage ont laissé une bonne
impression de mon école « ESPRIT » et affirmant son image de marque.

i
Table des matières

1 Introduction générale 1

2 Présentation de Confledis et analyse du projet 3

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Organisme d’acceuil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.3 Secteurs d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Cadre général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Spécification des besoins et conception 6

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.3 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Conception générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1 Modèle MVC(Model View Controller) . . . . . . . . . . . . . . . . . 8
3.3.2 Conception UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.3 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . 8
3.3.4 Création d’une commande . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.5 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.6 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.7 Scénario général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Réalisation 13
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Editeurs de développemnt . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4.1 Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4.2 Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4.3 Logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5 Modules réalisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

ii
Table des matières Table des matières

4.5.1 Portail du Backoffice . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.5.2 Test des APIs avec Swagger . . . . . . . . . . . . . . . . . . . . . . 19
4.5.3 Portail d’authentification . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5.4 Portail d’enregistrement . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5.5 Interface profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5.6 Ajout d’un produit . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5.7 Interface Markets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5.8 Interface paiement . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5.9 Méthode de paiement . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Conclusion 24

iii
Table des figures

2.1 Plateforme de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1 Diagramme du modèle MVC . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Création d’une commande . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Ajout d’un plat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5 Livraison d’une commande . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.6 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.7 Création d’une commande . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.8 Ajout d’un plat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.9 Livraison d’une commande . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 Logo de Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Logo de Webstorm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4 Logo de Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5 Logo de Ionic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6 Logo de Symfony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.7 Logo de GraphQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.8 Logo de PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.9 Logo de Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.10 Logo de Gitlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.11 Logo de Jira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.12 Backoffice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.13 Interface Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.14 Interface produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.15 Test APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.16 Interface Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.17 Interface Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.18 Interface Profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.19 Interface ajout d’un produit . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.20 Interface Markets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.21 Interface payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.22 Interface méthode de paiement . . . . . . . . . . . . . . . . . . . . . . . . . 23

iv
Chapitre 1

Introduction générale

Parfois, on ne sait pas si on a envie de manger un Burger, un chawarma, une pizza ou

des pates. C’est ainsi que Confledis a pensé au développement de CongoFood afin d’aider
les gens à trouver les meilleurs restaurants juste à proximité.

CongoFood est donc une nouvelle façon de commander les repas ou de réserver une
table auprès des restaurants implantés dans la ville de Kinshasa.

La plateforme CongoFood à développer va permettre à toute personne de pouvoir

commander un repas ou son plat préféré à partir de l’application web CongoFood qui sera
accessible par ordinateur, tablette ou téléphone.

Grâce à cette application, nous souhaitons proposer différents services tels que :
- Une application simple et fluide lors de son usage grâce notamment :
- Au recensement de tous les restaurants Halal sur l’application
- La création d’une carte où figureront les restaurants précédemment cités et à travers
laquelle les utilisateurs pourront partager leurs avis et photos des établissements testés.
- La possibilité de voir la carte du restaurant ainsi que la disponibilité des tables afin de
procéder à une réservation.
- Le gain de bons de réduction et/ou cadeaux pour les clients fidèles. Pour cela, il sera
nécéssaire
-tant pour le client que pour le restaurateur- de créer un compte par lequel il pourra,
selon son statut, proposer ou bénéficier de ces services.

La cible
Nous savons, grâce à nos statistiques que nous touchons majoritairement une popu-
lation jeune soit, 48Cette cible est une population très connectée et donc très active et
réactive sur les réseaux sociaux et autres applications. En moyenne, ils passent deux heures
et demi par jour sur leur téléphone.

LA CONCURRENCE
Il y a, depuis peu, une autre application qui propose un service similaire à celui que
nous voulons proposer.

1
Chapitre 1. Introduction générale

La différence est, que cette entreprise est spécialisée et priorise les établissement se situants
sur Paris et sa région, soit l’Île de France.

2
Chapitre 2

Présentation de Confledis et analyse

du projet

2.1 Introduction
Dans ce chapitre introductif, nous allons faire dans une première partie une descrip-
tion générale de Confledis(Paris), son service IT et ses principaux projets exploités. Une
étude de l’existant occupe une deuxième partie pour mettre en évidence les besoins et la
problématique que nous allons résoudre dans la société. Finalement, nous proposerons le
besoin afin de remédier aux différents problèmes identifiés.

2.2 Organisme d’acceuil

Confledis est une société de conseil moderne axée sur la stratégie et la transformation
numérique autour de l’analyse intelligente des données, des technologies web et mobile
ainsi que de la virtualisation des infrastructures.

Confledis aide les entreprises à saisir l’ensemble des opportunités que présente le cloud,
le digital et les plateformes pour leur transformation et leur recherche de performance.

Confledis construit l’avenir avec ses clients en créant des solutions sur mesure qui s’ap-
puient sur son savoir-faire, sa capacité d’innovation et son agilité.

Figure 2.1 – Plateforme de l’entreprise

3
Chapitre 2. Présentation de Confledis et analyse du projet 2.2. Organisme d’acceuil

2.2.1 Objectifs
Fondée en 2019, CONFLEDIS a pour objectifs :

Proposer une gamme de prestations la plus large possible, pour pouvoir prendre en
compte toutes les demandes des clients dans les meilleurs délais.

Réduire les coûts de clients et leurs permettre d’accéder aux services et prestations
avancés et efficaces.

2.2.2 Services
Confledis a les ressources nécessaires pour réagir rapidement aux besoins des clients –
un atout essentiel lorsque l’on veut voir aboutir ses projets en quelques semaines plutôt
que quelques mois.

Confledis garanti ainsi donc, la prise en charge optimum des besoins des clients à tra-
vers les solutions suivantes :

Technologies web, mobile et desktop : Android, iOS, Windows

Systèmes, Réseaux, Sécurité, Infogérance et Cloud : Windows, Linux, Azure, AWS
Big Data : Power BI, Tableau Software, Talend
CRM : Salesforce
Administration base des données : Oracle, PostgreSQL, Ms Server, MySQL et MongoDB
Formation professionnelle en nouvelles technologies.

Figure 2.2 – Technologies

2.2.3 Secteurs d’activités

Confledis accompagne les entreprises et les aide à prospérer et à dépasser leurs limites
pour créer les produits et services du futurs dans divers secteurs, notamment :

-Service Public
-Banque – Finance – Assurance
-Énergie – Industrie - Télécom
-Grande consommation – Distribution

4
Chapitre 2. Présentation de Confledis et analyse du projet 2.3. Cadre général

-Transport
-Santé

2.3 Cadre général

2.3.1 Problématique
Parfois, vous ne savez pas si vous voulez prendre un burger, chawarma, pizza ou des
pâtes.Voilà comment Confledis a pensé à développer CongoFood pour aider les gens à
trouver les meilleurs restaurants tout près.

2.3.2 Solution
CongoFood est une plateforme de commande et livraison de repas pour les restaurants.
L’objectif est de permettre à toute personne disposant d’un portefeuille mobile et d’un
compte CongoFood de pouvoir commander un plat et de se le faire livrer ou de réserver
une table dans un restaurant.
La livraison est rassurée par la logistique de Confledis pour une livraison dans 30 minutes.

2.4 Conclusion
Après avoir une idée sur l’entreprise et découvrir ses historiques, son process de dé-
veloppement , on a présenté le cadre de notre projet . Le chapitre suivant englobe une
spécification détaillée des besoins.

5
Chapitre 3

Spécification des besoins et

conception

3.1 Introduction
Nous allons réaliser dans ce chapitre une spécification des besoins fonctionnels et non
fonctionnels. Ensuite, nous allons voir des différents cas d’utilisation de l’application et
enfin nous allons exposer les diférents diagrammes en adoptant le langage de modélisation
l’UML(«Unified Modeling Language»).

3.2 Spécification des besoins

Comme toute solution, notre application va répondre à plusieurs besoins et assurer
plusieurs fonctionnalités.

3.2.1 Besoins fonctionnels

Gestion des commandes
Ce package contient la consultation des plats, la commande et son suivi (commande va-
lidée,commande en cours de préparation, expédiée). Il est en liaison avec un système de
paiement.
Gestion administration
Ce package contient la mise en ligne des plats. Il permet de consulter la liste des com-
mandes, d’attribuer une commande à un livreur, de consulter la liste des livreurs avec
leurs statuts (en cours de livraison, disponibles, . . .) et de voir où se trouve un livreur à
un instant "t". L’administrateur peut aussi consulter la liste des commandes. Il est chargé
de mettre à jour les plats proposés.
Gestion livraison
Il permet au livreur d’indiquer son statut (libre, en cours de livraison) et de valider la
réception des plats avec le client. Lorsque la commande est livrée, le livreur n’est plus "en
livraison" mais "libre". Le livreur valide une livraison (statut commande livrée), il sera
donc prêt pour recevoir une nouvelle commande. Le client peut suivre sa livraison via un
système de localisation.

6
Chapitre 3. Spécification des besoins et conception 3.2. Spécification des besoins

3.2.2 Besoins non fonctionnels

* La performance : L’application doit être avant tout performante c’est-à-dire à travers
ses fonctionnalités, répondent à toutes les exigences des usagers d’une manière optimale.

* Maintenance et réutilisabilité : Le code source de l’application doit être assez com-

préhensible pour faciliter sa maintenance.

* L’ergonomie : l’interface de notre application doit être conviviale et ergonomique

l’interface doit être simple à utiliser car l’utilisateur n’est pas forcement un informaticien.
Elle doit assurer une facilité de navigation entre les interfaces.
* Les contraintes techniques : L’application ne dépassera pas la performance du matériel
réservé à l’application, il faut aussi éliminer le gaspillage des ressources et minimiser les
ressources matérielles les plus possibles. Il est recommandé d’utiliser un langage de pro-
grammation bien maitrisé.

* La sécurité et la confidentialité : Notre application devra être hautement sécurisée

car les informations ne devront pas être accessibles à tout le monde, elle doit restreindre
les droits d’accès à travers l’authentification.

3.2.3 Identification des acteurs

Les acteurs principaux sont : Client, Livreur et Administrateur.
Le client doit pouvoir :
- s’inscrire (enregistrement de ses coordonnées)
- s’authentifier
- consulter les plats du jour
- ajouter les plats dans un panier
- commander des plats et payer en ligne
- suivre sa commande (préparation, livraison) et suivi GPS.
Le livreur doit pouvoir :
- s’authentifier (pour recevoir les commandes à livrer et donner sa position GPS)
- recevoir une commande à livrer
- valider une commande livrée
L’administrateur doit pouvoir :
- s’authentifier
- renseigner les nouveaux plats du jour
- connaitre la position d’un livreur
- attribuer une commande à un livreur
- voir les commandes passées en une journée, connaitre le chiffre d’affaire sur une période

7
Chapitre 3. Spécification des besoins et conception 3.3. Conception générale

3.3 Conception générale

3.3.1 Modèle MVC(Model View Controller)
Notre application est basée sur le modèle MVC, elle est ainsi composée de plusieurs
couches indépendantes, mais reliée les unes aux autres pour obtenir le résultat ou l’affi-
chage voulu.

Figure 3.1 – Diagramme du modèle MVC

3.3.2 Conception UML

Pour l’application développée, nous avons choisi le langage de modélisation le plus
adopté UML pour plusieurs raisons :
. La représentaton sous forme de diagrammes complémentaires facilite la compréhension
et le déchiffrement en détails l’utilisation de notre application.
. UML est un langage universel pouvant servir de support pour tout langage orienté objet.
En fait, l’UML offre une notation graphique simple et compréhensible. C’est également
un bon moyen de maîtriser la complexité et d’assurer la cohérence d’un système.

3.3.3 Diagramme de cas d’utilisation général

Le diagramme de cas d’utilisation représente la structure des grandes fonctionnalités
nécessaires aux utilisateurs de notre application.

3.3.4 Création d’une commande

1. Le client consulte les repas du jour
2. Il remplit son panier
3. Il souhaite payer
a. S’il n’est pas authentifier, il peut le faire à ce moment.
b. S’il n’est pas inscrit, il peut le faire également à ce moment.
c. S’il est authentifié, il accède directement au paiement.

Ajout d’un plat du jour

1. L’administrateur accède à une page d’administration grâce à son authentification
2. Il met à jour la liste des plats disponible
3. En validant, les menus sont insérés dans la base de données.
Livraison d’une commande 1. Prérequis : L’administrateur reçoit une commande à

8
Chapitre 3. Spécification des besoins et conception 3.3. Conception générale

Figure 3.2 – Diagramme de cas d’utilisation

Figure 3.3 – Création d’une commande

livrer.
2. Il cherche les livreurs qui sont disponibles dans le quartier de la livraison.
3. Lorsqu’il trouve le livreur, 2 scénarii sont envisageables ;
a. Le livreur possède déjà le plat demandé. Dans ce cas, l’administrateur lui envoie
l’adresse de livraison et la commande.

9
Chapitre 3. Spécification des besoins et conception 3.3. Conception générale

Figure 3.4 – Ajout d’un plat

Figure 3.5 – Livraison d’une commande

b. Le livreur ne possède pas le plat demandé : l’administrateur lui prépare en attendant

que le livreur passe le chercher puis lui donne l’adresse de livraison.
4. Le livreur valide la livraison avec le client.

3.3.5 Diagramme de classe

3.3.6 Diagrammes de séquences
Création d’une commande
Ajout d’un plat du jour
Livraison d’une commande

3.3.7 Scénario général

- L’administrateur met les plats et les desserts du jour dans la base de données
- Liste des livreurs qui ne sont pas en repos
- S’il le faut, mise à jour des statuts à "libre" à la prise du service
- Affichage des sacs livreurs et remise à zéro des sacs livreurs
- Un utilisateur consulte les plats disponibles aujourd’hui
- Il s’enregistre comme client
- Le client ajoute une adresse de livraison
- Il crée une commande
- Il ajoute des produits à sa commande
- Mise à jour de la commande avec le prix (calcul du prix) (dernier numero de commande)
- Mise à jour du prix
- L’administrateur reçoit la commande à préparer

10
Chapitre 3. Spécification des besoins et conception 3.3. Conception générale

Figure 3.6 – Diagramme de classe

Figure 3.7 – Création d’une commande

- Le statut de la commande passe "en cours de préparation"

- L’administrateur consulte les données des livreurs (statut, position) et leur sac
- Il update le sac du livreur le plus proche du lieu de livraison (on jette un oeil sur la
commande)
- Le livreur change de statut : "en livraison"
- La commande change de statut : "en cours de livraison"
- La commande passe ensuite à "livrée"
- Le livreur redevient disponible

11
Chapitre 3. Spécification des besoins et conception 3.4. Conclusion

Figure 3.8 – Ajout d’un plat

Figure 3.9 – Livraison d’une commande

- Les commandes de la journée

- La recette du 2022-12-03

3.4 Conclusion
Tout au long de ce chapitre, nous avons présenté dans une première phase les besoins
fonctionnels,en présentant les modules et ses fonctions principales traitées dans l’appli-
cation, de deux , pour achever la phase de la conception, le langage de modélisation
UML détaille les fonctionnalités et les interventions des acteurs dans l’application .Dans
le chapitre suivant, nous allons détailler la réalisation de l’application.

12
Chapitre 4

Réalisation

4.1 Introduction
Après avoir accompli les phases d’étude technique et de conception, nous nous sommes
penchés sur l’implémentation et le développement de l’application. Nous vous présentons
dans ce chapitre, une description des outils matériels et logiciels utilisés ainsi qu’une
sélection des tests du dernier livrable présentés sous forme de figures.

4.2 Environnement de travail

Dans cette section, nous allons décrire et détailler l’environnement matériel ainsi que
logiciel utilisé pour le développement de notre application.

4.2.1 Environnement matériel

Afin de réaliser notre application web, nous avons eu recours à utiliser différents ordi-
nateurs pour moi et mon équipe dont le mien est :

Figure 4.1 – Environnement matériel

4.3 Editeurs de développemnt

Partie backend
Visual Studio Code est un éditeur de code extensible développé par Microsoft pour Win-
dows, Linux et macOS. Les fonctionnalités incluent la prise en charge du débogage, la
mise en évidence de la syntaxe, la complétion intelligente du code, les snippets, la refac-
torisation du code et Git intégré.

13
Chapitre 4. Réalisation 4.4. Choix techniques

Figure 4.2 – Logo de Visual Studio

Partie Frontend
WebStorm est un environnement de développement intégré pour JavaScript et les techno-
logies connexes. Comme les autres IDE de JetBrains, il rend votre expérience de dévelop-
pement plus conviviale, en automatisant les tâches répétitives et en vous aidant à gérer
les tâches complexes avec facilité.

Figure 4.3 – Logo de Webstorm

4.4 Choix techniques

4.4.1 Front-end
Angular
Angular est un framework pour clients, open source, basé sur TypeScript et codirigé
par l’équipe du projet « Angular » chez Google ainsi que par une communauté de particu-
liers et de sociétés. Angular est une réécriture complète d’AngularJS, cadriciel construit
par la même équipe.

Figure 4.4 – Logo de Angular

14
Chapitre 4. Réalisation 4.4. Choix techniques

Ionic
Ionic est un framework open-source créé en 2013 par Max Lynch, Ben Sperry, et Adam
Bradley. Deux versions distinctes sont disponibles, incompatibles entre elles : la première
version, 1.3.3, se base sur AngularJS 1.5.3 tandis que la version 3.5.0 se base sur Angular
4.1.3 et TypeScript.

Figure 4.5 – Logo de Ionic

4.4.2 Back-end
Symfony
Symfony est un ensemble de composants PHP ainsi qu’un framework MVC libre écrit
en PHP. Il fournit des fonctionnalités modulables et adaptables qui permettent de faciliter
et d’accélérer le développement d’un site web.

Figure 4.6 – Logo de Symfony

GraphQL
GraphQL est un langage de requêtes et un environnement d’exécution, créé par Fa-
cebook en 2012, avant d’être publié comme projet open-source en 2015. Inscrit dans le
modèle Client-Serveur, il propose une alternative aux API REST.

Figure 4.7 – Logo de GraphQL

15
Chapitre 4. Réalisation 4.4. Choix techniques

4.4.3 Logiciels
PostgreSQL
PostgreSQL est un système de gestion de base de données relationnelle et objet. C’est
un outil libre disponible selon les termes d’une licence de type BSD. Ce système est
comparable à d’autres systèmes de gestion de base de données, qu’ils soient libres, ou
propriétaires.

Figure 4.8 – Logo de PostgreSQL

Docker
Docker est une plateforme permettant de lancer certaines applications dans des conte-
neurs logiciels. Selon la firme de recherche sur l’industrie 451 Research, « Docker est un
outil qui peut empaqueter une application et ses dépendances dans un conteneur isolé,
qui pourra être exécuté sur n’importe quel serveur ».

Figure 4.9 – Logo de Docker

Gitlab
GitLab est un logiciel libre de forge basé sur git proposant les fonctionnalités de wiki,
un système de suivi des bugs, l’intégration continue et la livraison continue.

Figure 4.10 – Logo de Gitlab

16
Chapitre 4. Réalisation 4.5. Modules réalisés

Jira
Jira est un système de suivi de bugs, de gestion des incidents et de gestion de projets
développé par Atlassian et publié pour la première fois en 2002. Il propose des solutions
à la fois à destination des développeurs et des intervenants non développeurs.

Figure 4.11 – Logo de Jira

4.5 Modules réalisés

Dans cette partie nous présentons un ensemble de captures d’écran de notre applica-
tion avec une brève description du rôle de chaque interface présentée.

4.5.1 Portail du Backoffice

L’administarteur peut ajouter, supprimer ou modifier soit un compte, un store, un
produit ...

Figure 4.12 – Backoffice

Création d’un store

Exemple : créer un store

Création d’un produit

Exemple : créer un produit

17
Chapitre 4. Réalisation 4.5. Modules réalisés

Figure 4.13 – Interface Store

Figure 4.14 – Interface produit

18
Chapitre 4. Réalisation 4.5. Modules réalisés

4.5.2 Test des APIs avec Swagger

Swagger est un langage de description d’interface permettant de décrire des API RES-
Tful exprimées à l’aide de JSON.

Figure 4.15 – Test APIs

4.5.3 Portail d’authentification

L’utilisateur : Livreur peut s’authentifier à son compte pour suivre les commandes.

Figure 4.16 – Interface Login

19
Chapitre 4. Réalisation 4.5. Modules réalisés

4.5.4 Portail d’enregistrement

L’utilisateur peut faire un compte.

Figure 4.17 – Interface Register

4.5.5 Interface profil

Profil de l’utilisateur qui contient les commandes, le processus de la commande, ses
informations personnelles ..

4.5.6 Ajout d’un produit

L’utilisateur peut ajouter un produit

4.5.7 Interface Markets

Les différents stores qui existent dans notre base de données

4.5.8 Interface paiement

L’utilisateur peut payer sa commande en ligne

20
Chapitre 4. Réalisation 4.6. Conclusion

Figure 4.18 – Interface Profil

Figure 4.19 – Interface ajout d’un produit

4.5.9 Méthode de paiement

L’utilisateur peut payer sa commande en ligne par la méthode qui lui convient.

4.6 Conclusion
Dans ce chapitre tout d’abord nous avons cité l’environnement de travail qui se divise
en environnement matériel et environnement logiciel. Par la suite, nous avons détaillé
les choix techniques pour notre application. Finalement, on a présenté les interfaces de

21
Chapitre 4. Réalisation 4.6. Conclusion

Figure 4.20 – Interface Markets

Figure 4.21 – Interface payment

l’application mise en oeuvre via des captures d’écran.

22
Chapitre 4. Réalisation 4.6. Conclusion

Figure 4.22 – Interface méthode de paiement

23
Chapitre 5

Conclusion

Dans le cadre de notre projet avec Confledis, nous avons conçu et développé une ap-
plication web pour commander et livrer des repas.

En premier lieu, dans le rapport présent, j’ai introduit le contexte général de mon stage,
qui s’est déroulé au sein de Confledis. Puis j’ai identifié les différents besoins. Ensuite, j’ai
présenté les besoins fonctionnels et non fonctionnels du projet et de leur conception en
présentant les cas d’utilisation et les diagrammes de séquences et de classes.

Enfin j’ai clôturé par une présentation de l’environnement de travail et les différentes
interfaces de l’application.

Ce stage m’a beaucoup aidé avec mes lacunes passées et m’a appris de nouvelles techno-
logies et des méthodologies de travail. J’ai pu m’adapter à un environnement professionnel
et à m’intégrer dans une équipe de travail soudée.

Ce projet m’ a donné aussi l’opportunité d’appliquer toutes nos connaissances récem-

ment enrichies.

Ce projet est encore ouvert pour plusieurs modifications et d’ajout de nouvelles fonc-
tionnalités.

Dans le but d’améliorer cette application, Nous avons pensé à développer une applica-
tion mobile qui va être téléchargé sur les smartphones des utilisateurs pour leurs permettre
de communiquer plus facilement et en temps réel avec leur société.

24