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
plateforme pour comet m
réalisation
a nder d’une
et
re pa s
livraison des

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

i
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

i
Chapitre
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
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é.

3
FIGURE 2.1 – Plateforme de l’entreprise

4
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
5
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 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

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

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

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

1
Chapitre 3. Spécification des besoins et conception 3.3. Conception

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

1
Chapitre 3. Spécification des besoins et 3.4.

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.

1
Chapitre 3. Spécification des besoins et conception 3.3. Conception

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é.

1
13
Chapitre 4. 4.4. Choix

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

1
Chapitre
Chapitre4.3. Réalisation
Spécification des besoins et conception 4.4.
3.3. Choix techniques
Conception

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

1
Chapitre 4. 4.4. Choix

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

1
Chapitre 4. 4.5. Modules

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

1
Chapitre 4. 4.5. Modules

FIGURE 4.13 – Interface Store

FIGURE 4.14 – Interface produit

1
Chapitre 4. 4.5. Modules

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

1
Chapitre 4. 4.5. Modules

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

2
Chapitre 4. 4.6.

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

2
 Chapitre 4. 4.5. Modules
présenté les interfaces de

2
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.

2
Chapitre 4. 4.6.

FIGURE 4.22 – Interface méthode de paiement

2
Chapitre 4. 4.5. Modules

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é.

2
24