Code PFE : M-221-23

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université de la Manouba

Institut supérieur des Arts Multimédias

Mémoire de fin d’études

Préparé en vue de l’obtention du diplôme Mastère Professionnel en

Ingénierie des Médias
Spécialité : Développement Web

Conception et développement d’une application

web/mobile d’un système de covoiturage

Réalisé par
Rim Ben Abdelfatteh

Encadré par
M. Marouen Kachroudi – ISAMM
M. Oussema Ben Amor – NAXXUM MEA

Année universitaire : 2022/2023

 Dédicaces

À Dieu tout-puissant, qui m’a donné la force, la volonté et le courage nécessaires pour mener
ce travail à terme.
À ma famille qui a toujours été mes piliers, me guidant avec sagesse et m'encourageant à
poursuivre mes rêves.
À mes amis qui ont été mes compagnons de route, apportant de la joie, des rires et un
précieux soutien à chaque étape.
À mes chers proches, votre présence chaleureuse et vos encouragements sincères ont illuminé
mon chemin.
À tous ceux qui me sont chers, à l’homme de ma vie qui m’a toujours soutenu.
 Remerciements

Je tiens à exprimer ma sincère gratitude envers toutes les personnes qui m'ont soutenu
tout au long de ce projet. Tout d'abord, je remercie chaleureusement mes enseignants de
l’Institut Supérieur des Arts Multimédia de la Manouba pour leurs précieuses guidances et leurs
conseils éclairés. Leur expertise a été d'une importance capitale pour la réussite de ce projet.

Je souhaite adresser mes plus sincères remerciements à mon encadrant académique, Mr

Kachroudi Marouen, pour sa précieuse guidance tout au long de la réalisation de ce projet.

Je tiens également à remercier les responsables et le personnel de la société Naxxum

pour avoir accepté de m'accueillir et de me permettre de réaliser mon stage au sein de leur
organisation. Leur collaboration et leur soutien ont grandement contribué à l'enrichissement de
mon expérience professionnelle.
Je souhaite également remercier chaleureusement mes encadrants professionnels, Harb
Malek et Ben Amor Oussama, toute l'équipe de travail chez l’unité de travail Diamond Cruise,
notamment, Allouche Chiheb Eddine, Slama Mohamed Omar ainsi que notre manager
Arouaoui Yasser, pour leur soutien continu, leurs précieux conseils, et leur collaboration
exceptionnelle. Chacun d'entre eux a contribué de manière significative à la réussite de ce
projet, et je suis profondément reconnaissant pour leur engagement et leur expertise.

Enfin, je tiens à exprimer mes remerciements à ma famille et mes amis pour leur soutien
indéfectible et leur encouragement constant. Leur confiance en moi a été ma source
d'inspiration.

Merci à tous pour avoir rendu cette expérience enrichissante et mémorable.

 Table des matières
Introduction générale............................................................................................................................... 1
Chapitre I : Contexte général du projet ................................................................................................... 3

I. Présentation de l’organisme d’accueil ............................................................................................. 3

I.1 Activité de l’organisme d’accueil ................................................................................................ 3

I.2 Organigramme de l’organisme d’accueil.................................................................................... 4

II. Contexte général du projet ............................................................................................................. 4

II.1 Etude de l’existant ..................................................................................................................... 4

II.2 Solution proposée ..................................................................................................................... 7

III. Méthodologie adoptée ................................................................................................................... 8

III.1 Etude comparative de quelques méthodologies ..................................................................... 8

III.2 Présentation et principe de Scrum ........................................................................................... 9
III.3 Affectation des rôles Scrum ................................................................................................... 10

Chapitre II : Etude Préalable .................................................................................................................. 12

I. Spécification des besoins :.............................................................................................................. 12

I.1 Identification des acteurs : ....................................................................................................... 12

I.2 Besoins fonctionnels : ............................................................................................................... 12
I.3 Besoins non fonctionnels : ....................................................................................................... 13
I.4 Diagramme de cas d’utilisation global ..................................................................................... 14
I.5 Diagramme de classes global ................................................................................................... 14
I.6 Enchainement de la livraison ................................................................................................... 16
I.7 Planification du projet .............................................................................................................. 17

II. Pilotage de projet avec Azure DevOps .......................................................................................... 17

III. Elaboration du Backlog du produit ............................................................................................... 18
IV. Environnement de développements............................................................................................ 21

IV.1 Environnement matériel ........................................................................................................ 22

IV.2 Environnement Logiciels ........................................................................................................ 22

V. Architecture de l’application ......................................................................................................... 32

V.1 Architecture Microservices ..................................................................................................... 32

 V.2 Clean Architecture................................................................................................................... 33
V.3 Architecture MVVM (Partie Web) ........................................................................................... 35
V.4 Architecture MVC (Partie mobile) ........................................................................................... 36
V.5 Architecture globale du projet ................................................................................................ 36

Chapitre III : Release 1 ........................................................................................................................... 38

I. Sprint 1: Authentification ............................................................................................................... 38

I.1 Objectif de sprint ...................................................................................................................... 38

I.2 Backlog de Sprint n°1 Authentification .................................................................................... 38
I.3 Conception du Sprint n°1 ......................................................................................................... 39
I.4 Sprint Review ............................................................................................................................ 47
I.5 Rétrospective du Sprint n°1 ...................................................................................................... 50

II. Sprint 2 : Gestion des profils ......................................................................................................... 51

II.1 Objectif de sprint ..................................................................................................................... 51

II.2 Backlog de Sprint n°2 Gestion des profils................................................................................ 51
II.3 Conception du Sprint n°2 ........................................................................................................ 52
II.4 Sprint Review ........................................................................................................................... 59
II.5 Rétrospective du Sprint n°2 ..................................................................................................... 61

Chapitre IV : Release 2........................................................................................................................... 62

I. Sprint 3 : Gestion des Annonces..................................................................................................... 62

I.1 Objectif de sprint ...................................................................................................................... 62

I.2 Backlog de Sprint n°3 Gestion des annonces ........................................................................... 62
I.3 Conception du Sprint n°3 ......................................................................................................... 64
I.4 Sprint Review ............................................................................................................................ 70
I.5 Rétrospective du Sprint n°3 ...................................................................................................... 72

II. Sprint 4 : Gestion des réclamations............................................................................................... 72

II.1 Objectif de sprint ..................................................................................................................... 72

II.2 Backlog de Sprint n°4 Gestion des réclamations ..................................................................... 72
II.3 Conception du Sprint n°4 ........................................................................................................ 73
II.4 Sprint Review ........................................................................................................................... 75
II.5 Rétrospective du Sprint n°4 ..................................................................................................... 77

Chapitre V : Release 3............................................................................................................................ 78

 I. Sprint 5 : Gestion des réservations................................................................................................. 78

I.1 Objectif de sprint ...................................................................................................................... 78

I.2 Backlog de Sprint n°5 Gestion des réservations ....................................................................... 78
I.3 Conception du Sprint n°5 ......................................................................................................... 79
I.4 Sprint Review ............................................................................................................................ 86
I.5 Rétrospective du Sprint n°5 ...................................................................................................... 87

II. Sprint 6 : Evaluation ...................................................................................................................... 88

II.1 Objectif de sprint ..................................................................................................................... 88

II.2 Backlog de Sprint n°6 Evaluation............................................................................................. 88
II.3 Conception du Sprint n°6 ........................................................................................................ 88
II.4 Sprint Review ........................................................................................................................... 91
II.5 Rétrospective du Sprint n°6 ..................................................................................................... 92

Conclusion générale .............................................................................................................................. 93

Webographie ......................................................................................................................................... 94
 Table des figures
Figure 1: Logo de la société Naxxum ........................................................................................ 3
Figure 2: Organigramme de la société Naxxum ......................................................................... 4
Figure 3: Logo BlaBlaCar .......................................................................................................... 5
Figure 4: Logo Mobicoop .......................................................................................................... 5
Figure 5: Logo Go Voiturage ..................................................................................................... 6
Figure 6: Le modèle SCRUM .................................................................................................... 9
Figure 7: Diagramme de cas d’utilisation global ..................................................................... 15
Figure 8: Diagramme de classes global .................................................................................... 16
Figure 9: Plan des releases ....................................................................................................... 16
Figure 10: Planification du projet............................................................................................. 17
Figure 11: Interface de gestion avec Azure Boards ................................................................. 18
Figure 12: Interface de gestion du code source avec Azure Repo .......................................... 18
Figure 13: Caractéristiques de l’environnement matériel ........................................................ 22
Figure 14: Logo de Visual Studio Code ................................................................................... 22
Figure 15: Logo de Visual Studio Community ........................................................................ 23
Figure 16: Logo de Android Studio ......................................................................................... 23
Figure 17: Logo de Lucidchart ................................................................................................. 23
Figure 18: Logo Figma ............................................................................................................. 23
Figure 19: Logo Microsoft SQL Server ................................................................................... 24
Figure 20: Logo Google Chrome ............................................................................................. 25
Figure 21: Logo Microsoft Teams ........................................................................................... 25
Figure 22: Logo du Langage de Modélisation Unifié .............................................................. 26
Figure 23: Logo .NET CORE .................................................................................................. 26
Figure 24: Logo C# .................................................................................................................. 27
Figure 25: Logo Ocelot ............................................................................................................ 27
Figure 26: Logo RabbitMQ ...................................................................................................... 27
Figure 27: Logo MediatR ......................................................................................................... 28
Figure 28: Logo Docker ........................................................................................................... 28
Figure 29: Logo MySQL .......................................................................................................... 29
Figure 30: Logo Swagger ......................................................................................................... 29
Figure 31: Logo Angular .......................................................................................................... 29
Figure 32: Logo TypeScript ..................................................................................................... 30
Figure 33: Logo HTML ............................................................................................................ 30
Figure 34: Logo Bootstrap ....................................................................................................... 30
Figure 35: Logo CSS ................................................................................................................ 31
Figure 36: Logo Flutter ............................................................................................................ 31
Figure 37: Logo Dart ................................................................................................................ 31
Figure 38: Architecture Microservices ..................................................................................... 32
Figure 39: Clean Architecture .................................................................................................. 33
Figure 40: Schéma de Médiator ............................................................................................... 34
Figure 41: Schéma du Modèle CQRS ...................................................................................... 35
Figure 42: Architecture MVVM .............................................................................................. 36
Figure 43: Schéma MVC.......................................................................................................... 36
Figure 44: Architecture Globale de l’application ..................................................................... 37
Figure 45: Diagramme de cas d’utilisation « S’inscrire » ........................................................ 40
Figure 46: Diagramme de cas d’utilisation « S’authentifier » ................................................. 40
Figure 47: Diagramme de classe de sprint n°1 ......................................................................... 40
Figure 48: Diagramme de séquence « S’inscrire » partie Mobile ............................................ 42
Figure 49: Diagramme de séquence du cas d’utilisation « S’inscrire » Web .......................... 44
Figure 50: Diagramme de séquence du cas d’utilisation « S’authentifier » partie Web .......... 45
Figure 51: Diagramme de séquence de mot de passe oublié.................................................... 47
Figure 52: Interface d’inscription partie Web .......................................................................... 47
Figure 53: Interface login ......................................................................................................... 48
Figure 54: Interface mot de passe oubliée Dashboard Admin ................................................. 48
Figure 55: Interfaces mot de passe oubliée Application Mobile .............................................. 49
Figure 56: Interface de l’e-mail de confirmation d’inscription ................................................ 49
Figure 57: Interface login Application Mobile ........................................................................ 50
Figure 58: Les interfaces d’inscription de la partie mobile ...................................................... 50
Figure 59: Diagramme de cas d’utilisation « Gérer son profil » .............................................. 53
Figure 60: Diagramme de cas d’utilisation « Gérer les utilisateurs » ...................................... 53
Figure 61: Diagramme de cas d'utilisation « Modifier son rôle » ............................................ 54
Figure 62: Diagramme de classe de Sprint n°2 ........................................................................ 54
Figure 63: Diagramme de séquence du cas d’utilisation « Modifier le rôle d’un utilisateur » 56
Figure 64: Diagramme de séquence du cas d’utilisation « Modifier ses données personnelles »
.................................................................................................................................................. 57
Figure 65: Diagramme de séquence du cas d’utilisation « Changer mot de passe » ............... 58
Figure 66: Interface de gestion des utilisateurs ........................................................................ 59
Figure 67: Interface de changement des rôles .......................................................................... 59
Figure 68: Interface de gestion de profil administrateur .......................................................... 60
Figure 69: Interfaces gestion des profils utilisateurs ................................................................ 60
Figure 70: Diagramme de cas d’utilisation « Gérer les annonces pour les conducteurs » ....... 64
Figure 71: Diagramme de cas d’utilisation « Gérer les annonces pour les passagers » ........... 65
Figure 72: Diagramme de cas d’utilisation « Gérer les annonces pour administrateur » ........ 65
Figure 73: Diagramme de cas d’utilisation « Gérer les options » ............................................ 66
Figure 74: Diagramme de classe de Sprint n°3 ........................................................................ 66
Figure 75: Diagramme de séquence du cas d’utilisation « Ajouter une annonce » ................. 68
Figure 76:Diagramme de séquence du cas d’utilisation « Modifier une annonce » ................ 69
Figure 77: Interface gestion des annonces partie administrateur ............................................. 70
Figure 78: Interface gestion des options partie administrateur ................................................ 70
Figure 79: Interface gestion des commentaires partie administrateur ...................................... 71
Figure 80: Interfaces gestion des annonces partie mobile........................................................ 71
Figure 81: Diagrammes de cas d'utilisation « Envoyer une réclamation » .............................. 73
Figure 82: Diagrammes de cas d'utilisation « Consulter la liste des réclamations » ............... 73
Figure 83: Diagramme de classe de Sprint n°4 ........................................................................ 74
Figure 84: Diagramme de séquence du cas d’utilisation du cas d’utilisation « Envoyer une
réclamation » ............................................................................................................................ 75
Figure 85: Interface gestion des réclamations .......................................................................... 76
Figure 86: Interfaces envoyer une réclamation partie utilisateurs ........................................... 76
Figure 87: Diagramme de cas d'utilisation « Gestion des réservations pour les passagers » ... 79
Figure 88: Diagramme de cas d’utilisation « Gestion des réservations pour les conducteurs »
.................................................................................................................................................. 80
Figure 89: Diagramme de cas d'utilisation « Consulter la liste des réservations » .................. 80
Figure 90: Diagramme de classe de Sprint n°5 ........................................................................ 81
Figure 91: Diagramme de séquence de cas d’utilisation « Demander une réservation » ......... 83
Figure 92: Diagramme de séquence de cas d’utilisation «Traiter une demande de réservation»
.................................................................................................................................................. 84
Figure 93: Diagramme de séquence de cas d'utilisation « Annuler une réservation » ............. 86
Figure 94: Interface gestion des réservations partie web ......................................................... 87
Figure 95: Interfaces gestion des réservations partie mobile ................................................... 87
Figure 96: Diagramme de cas d’utilisation « Donner avis » .................................................... 89
Figure 97: Diagramme de classe de Sprint n°6 ........................................................................ 89
Figure 98: Diagramme de séquence du cas d’utilisation « Donner un Avis » ......................... 91
Figure 99: Interfaces des évaluations ....................................................................................... 91
 Liste des tableaux
Tableau 1: Tableau comparative des plateformes ...................................................................... 6
Tableau 2: Tableau comparative des méthodologies ................................................................. 9
Tableau 3: Backlog du produit ................................................................................................. 21
Tableau 4: Backlog de Sprint n°1 Authentification ................................................................. 39
Tableau 5: Description textuelle du cas d’utilisation « S’inscrire » partie mobile .................. 41
Tableau 6: Description textuelle du cas d’utilisation « S’inscrire » partie web ....................... 43
Tableau 7: Description textuelle du cas d’utilisation « S’authentifier » partie web ................ 45
Tableau 8: Description textuelle du cas d’utilisation « Mot de passe oublié » partie web ...... 46
Tableau 9: Rétrospective de sprint n°1 .................................................................................... 51
Tableau 10: Backlog de Sprint n°2 Gestion des profils ........................................................... 52
Tableau 11: Description textuelle du cas d’utilisation « Modifier le rôle d’un utilisateur » ... 55
Tableau 12: Description textuelle du cas d’utilisation « Modifier ses données personnelles »56
Tableau 13: Description textuelle du cas d’utilisation « Changer mot de passe » ................... 58
Tableau 14: Rétrospective du Sprint n°2.................................................................................. 61
Tableau 15: Backlog de Sprint n°3 Gestion des annonces ....................................................... 64
Tableau 16: Description textuelle du cas d’utilisation « Ajouter une annonce » ..................... 68
Tableau 17: Description textuelle du cas d’utilisation « Modifier une Annonce » .................. 69
Tableau 18: Rétrospective du Sprint n°3.................................................................................. 72
Tableau 19: Backlog de Sprint n°4 Gestion des réclamations ................................................. 73
Tableau 20: Description textuelle du cas d’utilisation « Envoyer une réclamation » .............. 75
Tableau 21: Rétrospective du Sprint n°4.................................................................................. 77
Tableau 22: Backlog de Sprint n°5 Gestion des réservations .................................................. 79
Tableau 23: Description textuelle de cas d’utilisation « Demander une réservation » ............ 82
Tableau 24: Description textuelle de cas d’utilisation « Confirmer une réservation » ............ 84
Tableau 25: Description textuelle de cas d’utilisation « Annuler réservation » ...................... 85
Tableau 26: Rétrospective du Sprint n°5.................................................................................. 88
Tableau 27: Backlog de Sprint n°6 Evaluation ........................................................................ 88
Tableau 28: Description textuelle du cas d’utilisation « Donner avis » ................................... 90
Tableau 29: Rétrospective du Sprint n°6.................................................................................. 92
 Liste des abréviations

RUP : Rational Unified Process

XP : eXtreme Programming
IDE : Un environnement de développement intégré
CQRS : Command Query Responsibility Segregation
API: application programming interface
MVVM : Modèle-Vue-Vue Modèle
MVC : Modèle-Vue-Contrôleur
IA : Intelligence artificielle
HTML: HyperText Markup Language
CSS : Cascading Style Sheets
 Introduction générale
Durant ces dernières années, dans le secteur des transports, la croissance de la mobilité
a intensifié la pollution, le stress et les embouteillages.
Face à ces enjeux, des solutions alternatives gagnent en intérêt, comme les transports
collectifs. Le covoiturage se démarque comme une solution de mobilité à encourager, et c'est
précisément là que s'inscrit notre projet.
Notre projet vise à développer une application web et mobile de covoiturage, exploitant
les technologies les plus récentes. L'objectif de notre projet de covoiturage est de concevoir et
de développer une solution numérique qui permettra aux utilisateurs de trouver des solutions
de mobilité efficaces et durables en visant à centraliser et à faciliter l'accès à des informations
pertinentes pour les utilisateurs à la recherche de covoiturage. Grâce à l'intégration des
technologies modernes, nous souhaitons offrir aux utilisateurs une expérience conviviale et
fluide, soit pour la recherche, la réservation et le partage de trajets deviennent un processus
intuitif et simple. Ce projet intègre l'architecture microservices avec des design patterns adaptés.
L'application sera à cet effet divisée en composants autonomes, favorisant le développement,
la maintenance et l'adaptabilité de chaque fonctionnalité. L'utilisation du design patterns
améliore la gestion des données et les interactions entre les microservices, renforçant la
scalabilité, la flexibilité et la réactivité. Cette approche garantit une expérience utilisateur
exceptionnelle tout en nous préparant à répondre efficacement et rapidement aux changements
des besoins du marché et des utilisateurs.
Afin de mener à bien ce projet, nous avons choisi une approche de management inspirée
du framework agile SCRUM. Cette approche vise à garantir l'atteinte de nos objectifs,
notamment la satisfaction du client à chaque étape, en assurant des livraisons régulières et
pertinentes.

Notre rapport comporte sur cinq chapitres, apportant chacun une perspective
enrichissante à notre projet.

Le premier chapitre, "Contexte général du projet", nous immerge dans le cadre de travail en
exposant la problématique sous-jacente, en décrivant le contexte global de notre projet, et en
expliquant notre choix de la méthodologie SCRUM.

1
Le deuxième chapitre, intitulé "Étude Préalable", approfondit les aspects conceptuels et
logiciels de notre application tout en spécifiant les exigences. Il met en évidence les besoins
fonctionnels et non fonctionnels qui ont guidé notre démarche, ainsi qu'la planification du
projet.

Le troisième chapitre, "Release 1", se concentre sur les particularités du premier livrable,
détaillant les sprints 1 et 2 et présentant les fonctionnalités essentielles que nous avons
développées.

Le quatrième chapitre, "Release 2", est entièrement consacré aux sprints 3 et 4, offrant un
aperçu des innovations que nous avons apportées.

Le cinquième chapitre, "Release 3", éclaire les sprints 5 et 6, ajoutant une dimension
supplémentaire à notre projet.

Notre rapport s'achève par une synthèse de nos découvertes et une réflexion sur les perspectives
à venir, créant ainsi une toile complète de notre travail accompli jusqu'à présent.

2
 Chapitre I : Contexte général du projet
Introduction
Tout d’abord, dans ce chapitre, nous présenterons l’organisme d’accueil au sein de
laquelle nous avons réalisé ce stage. Ensuite, nous décrirons le cadre général du projet et nous
analyserons les différents projets existants à travers une étude approfondie pour identifier notre
problématique et proposer une solution. Enfin, nous introduisons le choix de l’approche adopté
dans la réalisation du projet.

I. Présentation de l’organisme d’accueil

Dans cette partie, nous présenterons l'organisme d'accueil « Naxxum », sa hiérarchie et

ses principales activités.

I.1 Activité de l’organisme d’accueil

Naxxum Group est un hub de startup, permettant de transformer une idée de l’état
embryonnaire à la concrétisation et au développement d’un business réel. De plus, Naxxum est
avant tout un ensemble de jeunes talents passionnés de nouvelles technologies croyant que
l’innovation est un moyen de progression sociale, économique et culturelle. Par le biais de
l’innovation, Naxxum Mea opte pour mettre à disposition son savoir-faire pour mener des
projets proposant des solutions aux problématiques de tous les jours des homos sapiens du
21éme siècle.
Naxxum est une Entreprise de Services du Numérique internationale, l’une de partenaire
de Microsoft, qui offre des services IT tournant autour des prestations de conseil,
développement spécifique, maintenance (corrective, évolutive, préventive), assurance qualité
et du cyber sécurité.

Figure 1: Logo de la société Naxxum

3
 I.2 Organigramme de l’organisme d’accueil

Le schéma ci-dessous représente l'organigramme de la société Naxxum. Nous avons effectué

notre stage avec l'équipe « Diamond Cruise ».

Figure 2: Organigramme de la société Naxxum

II. Contexte général du projet

Ce travail s’inscrit dans le cadre de la préparation du projet de fin d’études, en vue de

l’obtention d’un diplôme en Master Professionnel d’ingénierie des médias développement web,
pour l’année universitaire 2022-2023 au sein de l’Institut Supérieur des Arts Multimédia de la
Manouba. Il a été réalisé au sein de la société Naxxum Group à Tunis à l’unité d’affaires
Diamond Cruise pendant une durée de 7 mois.

II.1 Etude de l’existant

Dans cette section, nous présentons une étude qui se base sur l'observation de différentes
applications web similaires à celles que nous sommes chargés de développer. L'examen des
applications existantes est important, car il nous permet de comprendre les tendances actuelles
du marché, d'identifier leurs atouts majeurs, et ensuite d'entreprendre une évaluation critique.

4
 II.1.1 Solutions Existantes

• BlaBlaCar anciennement connu sous le nom de covoiturage.fr, est un acteur

incontournable dans le domaine du covoiturage. Il compte un grand nombre
d'utilisateurs et permet aux utilisateurs de renseigner leur itinéraire et de choisir leur
conducteur. Il est également possible de publier son propre itinéraire pour trouver des
compagnons de voyage et réduire les dépenses. La communauté est vaste et il est facile
de trouver des conducteurs. Cependant, il est important de noter que le site prélève une
commission de 7% sur chaque voyage.

Figure 3: Logo BlaBlaCar

• Mobicoop est un site de covoiturage coopératif basé sur l'économie sociale et solidaire.
Le fonctionnement est simple : les conducteurs postent leur trajet en indiquant les détails
tels que la date, l'heure et le lieu de départ et d'arrivée. Les passagers peuvent ensuite
réserver une place et participer aux frais de manière solidaire, selon une fourchette de
prix recommandée.

Figure 4: Logo Mobicoop

• Go voiturage est un nouveau site de covoiturage en Tunisie, qui malgré son aspect très
pratique, n'a pas encore attiré un grand nombre d'utilisateurs. Le fonctionnement du site
est simple : le conducteur doit remplir un formulaire pour publier une annonce de
covoiturage, tandis que le passager peut consulter les annonces publiées et choisir celle

5
 qui lui convient en fonction des lieux de départ et de destination ainsi que de la date.
Ensuite, le passager peut contacter le conducteur par email ou téléphone pour réserver
une place.

Figure 5: Logo Go Voiturage

II.1.2 Comparaison des solutions existantes

Pour évaluer les solutions existantes, nous avons pris en compte les retours d'utilisateurs
de ces applications sur les réseaux sociaux, ce qui nous a permis d'obtenir une compréhension
plus approfondie concernant principalement les critères relatifs à l'ergonomie, aux options de
paiement, aux fonctionnalités fournies, à la sécurité, au support client et à l’interactivité entre
les utilisateurs. Ci-après, un tableau qui illustre le résultat de cette étude comparative.

Plateforme BlaBlacar Mobicoop Go Voiturage

Ergonomie **** *** *

Frais Payante Gratuite Gratuite

Fonctions fournies *** **** ***

Sécurité **** **** ***

Options de
***** ***** *
paiement

Support client ** **** **

Interactivité entre
** * *
les utilisateurs
Tableau 1: Tableau comparative des plateformes

6
 II.1.3 Critique de l'existant

L’étude comparative ci-dessus, nous a permis de dégager les critiques suivantes :

• Temps d'attente trop longs : Les temps d'attente pour trouver un covoitureur sont
souvent trop longs, ce qui peut décourager les utilisateurs et les amener à chercher
d'autres solutions de transport.
• Manque de flexibilité : Les solutions de covoiturage actuelles ne sont pas suffisamment
flexibles pour répondre aux besoins des utilisateurs en termes de choix de trajet et de
critères de sélection des covoitureurs.
• Expérience utilisateur limitée : L'expérience utilisateur des solutions de covoiturage
actuelles peut être limitée en termes de facilité d'utilisation, de convivialité de l'interface
utilisateur, ou de qualité du service client.
• Certaines solutions exigent que le paiement soit effectué avant la prise de contact avec
le conducteur.

II.2 Solution proposée

Notre projet vise à mettre en œuvre une solution innovante de covoiturage, offrant aux
utilisateurs la possibilité de trouver des covoitureurs pour partager les frais de transport entre
différents points de départ et d'arrivée. Cette application se distingue par sa fonctionnalité de
réponse assez interactive et rapide. Le projet sera réalisé à travers deux parties distinctes : une
partie Web pour l’administrateur et une partie Mobile pour les utilisateurs, afin de fournir une
expérience utilisateur fluide.
Notre plateforme de covoiturage vise à surmonter ces limitations en offrant une
expérience utilisateur optimale. Nous avons pour objectif de transformer l'industrie du
covoiturage en proposant une plateforme souple, dynamique et centrée sur les besoins
individuels.
Nous devons noter aussi que la solution proposée est une solution qui va aider à :

• La mise en avant de la qualité du service pour des trajets plaisants, économiques et

respectueux.
• La prise en compte des préférences individuelles telles que la localisation, les horaires,
etc., pour trouver le compagnon de covoiturage idéal.

7
 • La possibilité aux conducteurs de publier des annonces pour proposer et les clients pour
rechercher des trajets spécifiques avec plusieurs options comme animaux autorisés ou
pas, WIFI disponible ou pas, bagages autorisés ou pas, fumeurs autorisés ou pas etc...
• La possibilité aux utilisateurs de signaler tout comportement inapproprié des
conducteurs pour une expérience de covoiturage sécurisée et agréable.
• La réservation et l’annulation des trajets simplifiées grâce à une interface intuitive.
• La permission aux utilisateurs de partager leur expérience et donner leur avis pour
améliorer la qualité du service.
• Le suivi personnalisé pour garantir la satisfaction totale des clients.

III. Méthodologie adoptée

Il est très important de choisir une méthode de management permettant l’implication du

client optimale pour répondre au mieux à ses besoins évolutifs dans le temps en offrant un suivi
régulier, une transparence indispensable donnant la possibilité d’une livraison rapide des
produits intermédiaires au client. A cet effet, Nous avons comparé les approches agiles les plus
utilisées à ce jour à savoir RUP, XP et Scrum, pour sélectionner celle qui convient le mieux aux
besoins du client pour notre projet.

III.1 Etude comparative de quelques méthodologies

Ci-dessous, vous trouverez un tableau comparatif, des méthodologies sus mentionnées.

Méthodologie Avantages Inconvénients
 Documentation complète  Processus lourd et complexe.
RUP et détaillée.  Coûts élevés de formation et de
 Processus bien défini et mise en œuvre.
structuré.
 Adaptabilité aux  Peut être difficile à appliquer
changements fréquents. pour des projets avec des
XP  Moins de dépendance à la exigences changeantes.
documentation.  Le client doit être impliqué de
manière continue, ce qui peut
être difficile dans certains cas.

8
  Grande flexibilité face aux  Peut être difficile à appliquer
changements. pour des projets complexes.
SCRUM  Réduction du gaspillage et  Exige une certaine discipline
de la surcharge. pour suivre le processus.
 Transparence et visibilité
du processus.

Tableau 2: Tableau comparative des méthodologies

Compte tenu des objectifs de notre projet et de l’étude comparative ci-dessus, nous avons opté
pour la méthodologie Scrum, qui offre :

• Une approche souple et réactive.

• Capacité à s'adapter rapidement aux changements grâce à des itérations courtes.
• Une collaboration continue entre le client et l'équipe.
• Une livraison rapide des produits.

III.2 Présentation et principe de Scrum

Scrum est conçu pour les petites équipes et vise à maximiser la productivité grâce à des
règles de vie flexibles adaptées au cycle de développement [1]. Voici un schéma illustrant le
fonctionnement de Scrum :

Figure 6: Le modèle SCRUM

9
Les grandes étapes de la méthode Scrum :

• Sprint Planning : Cette réunion Agile est la première étape du cycle de réalisation. Elle
se déroule au début de l'itération et a pour objectif de sélectionner les user stories qui
seront intégrées dans le cycle de développement d’un sprint.
• Daily Scrum : Il s'agit de la réunion la plus importante du cycle Agile, centrée sur
l'efficacité opérationnelle. Elle dure 15 minutes, se tient quotidiennement et rassemble
l'équipe de développement. Durant cette réunion, chaque membre est appelé à partager
les points de situation :
➢ Les progrès réalisés depuis la dernière réunion.
➢ Les tâches qu'il a prévu d'accomplir au cours de la journée.
➢ Les obstacles ou difficultés rencontrés dans la réalisation des tâches depuis la
dernière réunion.
• Sprint Review : C'est lors de cette réunion, qui marque la fin d'une itération de
développement, que l'équipe SCRUM présente son travail aux parties prenantes du
projet, les "Stakeholders". L'objectif est de démontrer que toutes les fonctionnalités
développées fonctionnent conformément aux spécifications. Chaque "User Story" est
passée en revue et démontrée.
• Sprint rétrospective : L'objectif fondamental de cette réunion consiste à évaluer le
sprint écoulé en examinant les réussites remarquables dans la résolution des difficultés
et à tirer des enseignements précieux des pratiques bénéfiques. De plus, elle vise à
identifier clairement les erreurs ou les inefficacités relevées pendant cette période de
travail. Cette rencontre représente un moment crucial pour l'ensemble de l'équipe,
offrant à chacun l'opportunité de présenter son point de vue sur l’amélioration du
fonctionnement de l'équipe, que ce soit du point de vue technique ou organisationnel.

III.3 Affectation des rôles Scrum

Scrum implique généralement trois rôles principaux :

• Le Product Owner : Est responsable de définir, dans le Product Backlog, les

spécifications fonctionnelles, de prioriser les fonctionnalités à développer ou à corriger,
de participer avec les parties prenantes à valider les fonctionnalités développées [2].
• Le Scrum Master : Son rôle consiste à garantir le respect des principes et des valeurs
de Scrum, tout en favorisant une communication fluide au sein de l'équipe. Son objectif
est d'améliorer la productivité et les compétences de l'équipe de manière proactive [3].

10
 • L'équipe de développement : Est composée de professionnels de développement qui
fournissent à la fin de chaque Sprint un incrément abouti du produit, pouvant être livré
potentiellement. Ces membres sont autonomes dans leur organisation et possèdent des
compétences variées [4].
Dans notre projet, les rôles sont répartis comme suit :
➢ Product Owner : Mr. Yasser AROUAOUI
➢ Scrum Master : Mme Malek HARB et Mr Oussema ben Amor
➢ Equipe de travail : Rim Ben Abdelfatteh, Mohamed Omar SLAMA, et Chiheb
Eddine ALLOUCHE

Conclusion

Ce chapitre nous a permis de présenter notre projet de manière générale, d'analyser

l'existant, d'identifier ses limitations et ses points forts et de déduire les tâches à effectuer pour
proposer une meilleure solution. Dans le deuxième chapitre intitulé "Étude préalable", nous
approfondirons notre analyse et examinerons les aspects nécessaires à prendre en compte avant
de passer à la mise en œuvre concrète du projet.

11
 Chapitre II : Etude Préalable
Introduction
Dans ce chapitre, nous avons choisi une approche détaillée pour présenter notre projet
en précisant les besoins fonctionnels. Nous utilisons le diagramme de cas d'utilisation pour
illustrer les différentes fonctionnalités du système, ainsi que les besoins non fonctionnels qui
expliquent les contraintes à respecter. En plus, nous examinerons d’une manière détaillée le
backlog de notre projet et élaborerons le planning d'exécution des tâches.

I. Spécification des besoins :

La spécification de besoin est une approche scientifique qui raisonne en termes de

fonctions doivent être assurées par un produit : elle consiste à caractériser, et hiérarchiser les
fonctions d’un système. C’est pour cela nous présentons dans ce qui suit tous les besoins
fonctionnels classés par acteurs ainsi que les besoins non fonctionnels du système.

I.1 Identification des acteurs :

Un acteur désigne les actions qu’une entité autonome interne ou externe peut avoir avec
le système dont nous souhaitons décrire le fonctionnement. D’une manière générale, un acteur
correspond à une personne physique ou moral interne ou externe ayant une tâche ou une
interaction avec le périmètre de notre projet.
Voici les acteurs identifiés dans notre projet :

• Administrateur : L’administrateur est le seul à avoir accès à l’information complète

du système. Il peut faire la gestion globale du système, par exemple gérer les profils
utilisateurs ainsi que la gestion des annonces, il gère et maintient son bon
fonctionnement.
• Conducteur : Le conducteur peut publier un ou plusieurs trajets, il est le responsable
d’accepter les demandes de réservations du passager à un moment donné.
• Passager : Le passager peut lancer des différentes recherches pour trouver des trajets
qui conviennent au ses attentes et faire des réservations.

I.2 Besoins fonctionnels :

Les besoins fonctionnels sont généralement formulés sous forme d'exigences

fonctionnelles, et sont l'expression de ce que le produit ou le service délivré par le projet devrait

12
être ou faire [5]. Dans ce contexte notre application de covoiturage, doit répondre aux exigences
suivantes :

• Le système doit permettre à l’administrateur de consulter toutes les annonces de

covoiturages et les commentaires, ainsi de supprimer les commentaires ou les annonces
frauduleuses signaler par les utilisateurs et de les bloquer si y en besoin.
• Le système doit permettre aux conducteurs et aux passagers de pouvoir s’inscrire de
façon autonome via une application mobile et à l’administrateur via l’interface web.
• Le système doit permettre au conducteur l’ajout, la modification et la suppression d’une
annonce de trajet.
• Le système doit permettre aux passagers et aux conducteurs de faire des commentaires
sur les annonces de covoiturage.
• Le système doit aussi permettre aux utilisateurs de rechercher des trajets. Ces recherches
peuvent s’effectuer suivant des critères précis. Suite à l’affichage des résultats le
passager peut choisir le trajet qui lui convient.
• Le système doit mettre en place une fonctionnalité permettant aux utilisateurs de
soumettre des réclamations à l'administrateur en cas de problèmes ou d'incidents liés au
covoiturage.
• Le système doit offrir aux passagers la possibilité d'effectuer des demandes de
réservation. Une fois la réservation est demandée, la confirmation peut être donnée par
le conducteur. De même, les conducteurs ou les passagers ont la possibilité d'annuler
une réservation en cours. Un contrôle complet est exigé sur les interactions liées aux
réservations.
• Le système doit offrir aux utilisateurs la possibilité d'exprimer leur opinion et de laisser
des avis après chaque expérience de covoiturage.
• Le système doit permettre à chacun des membres de faire la gestion de son compte. Il
sera possible de modifier des informations personnelles ou des préférences.

I.3 Besoins non fonctionnels :

Un besoin non fonctionnel est un besoin spécifiant des propriétés du système, telles que les
contraintes liées à l'environnement et l'implémentation, les exigences en matière de
performances, de dépendances de plate-forme, de facilité de maintenance, d'extensibilité et de
fiabilité [6]. Dans notre système, les besoins non fonctionnels se présente comme suit :

13
 • Performance : l'application doit être rapide et réactive, en offrant des temps de réponse
rapides même avec un grand nombre d'utilisateurs simultanés.
• Scalabilité : l'application doit pouvoir gérer une augmentation du nombre d'utilisateurs
et de trajets sans compromettre ses performances.
• Convivialité : notre application doit fournir des interfaces simples et élégantes
conformes aux normes d’ergonomie dont le but est de garantir une facilité d’exploitation
et une rapidité de service.
• Sécurité : les données des utilisateurs et les communications doivent être protégées et
sécurisées contre tout accès non autorisé.
• Maintenance : l'application doit être facile à entretenir et à mettre à jour, minimisant
ainsi les temps d'arrêt et les perturbations pour les utilisateurs.
• Efficacité : l’application devra être fonctionnelle indépendamment de toutes
circonstances pouvant entourer l’utilisateur.
• Disponibilité : l’application doit être disponible à tout moment sans défaillance pour
répondre au besoin de client.

I.4 Diagramme de cas d’utilisation global

Le diagramme de cas d'utilisation global présente les interactions et les fonctionnalités

principales de l'ensemble du système. Il permet de visualiser les actions que les utilisateurs
peuvent effectuer et comment ils interagissent avec le système, fournissant ainsi une vue
d'ensemble des fonctionnalités de l'application de covoiturage. La figure ci-dessous représente
notre diagramme de cas d’utilisation globale de notre plateforme [7].

I.5 Diagramme de classes global

Le diagramme de classe globale représente la structure et les relations entre les classes
principales du système de l'application de covoiturage. Il offre une vue d'ensemble des entités
clés, de leurs attributs et de leurs relations, permettant ainsi de comprendre la structure générale
du système et comment les différentes classes interagissent entre elles.

14
Figure 7: Diagramme de cas d’utilisation global

15
 Figure 8: Diagramme de classes global

I.6 Enchainement de la livraison

La livraison des incréments a été planifiée en fonction de jalons de livraison appelés

"Releases". Chaque livraison est composée de deux sprints représentant une période de
développement spécifique avec des objectifs biens définis. Ce rapport est structuré en alignant
les chapitres sur les différentes "Releases", comme illustré dans le graphique ci-dessous :

Figure 9: Plan des releases

16
 I.7 Planification du projet

La planification de projet joue un rôle vital dans la gestion efficace des tâches, des
ressources et des délais. Les tableaux de Gantt, largement utilisés dans ce contexte, offrent une
vue visuelle des différentes étapes du projet, facilitant ainsi la coordination et le suivi des
activités. Ce tableau présente la planification prévue pour la réalisation des différentes phases
du projet.

Figure 10: Planification du projet

II. Pilotage de projet avec Azure DevOps

Dans le cadre de ce projet, nous avons bénéficié de l'occasion d'exploiter Azure DevOps
pour assurer la gestion et le suivi de notre projet. Pour traduire les diverses user stories à
développer en tâches concrètes, nous avons choisi d'utiliser Azure Boards. Parallèlement, Azure
Repos a été employé pour gérer notre code source, à travers la création de trois dépôts distincts.
Microsoft Azure DevOps est un outil qui prend en charge les équipes de développement
de logiciels tout au long du cycle de vie du développement, de la collecte des exigences à la
mise en œuvre, aux tests et au déploiement automatisé. Le nom DevOps est dérivé des
abréviations Développement (Dev) et Operations (Ops) et est considéré comme l’une des
principales tendances de l’industrie qui attire de plus en plus l’attention [8].
Dans le cadre de notre démarche, nous avons choisi d'adopter Azure Boards comme
outil central pour la gestion des user stories à élaborer. Cette plateforme nous permet de manière
visuelle et structurée de suivre l'évolution de chaque étape du projet, comme illustré dans la
figure suivante :

17
 Figure 11: Interface de gestion avec Azure Boards
Nous avons opté pour l'utilisation d'Azure Repos pour assurer la gestion du code source
de notre application. Cette plateforme nous offre un espace centralisé pour stocker, modifier et
collaborer sur le code, renforçant ainsi notre processus de développement, comme démontré
dans la figure suivante :

Figure 12: Interface de gestion du code source avec Azure Repo

III. Elaboration du Backlog du produit

Avec la méthodologie SCRUM, il est essentiel de construire un backlog de produit. Ce

backlog constitue une liste hiérarchisée des éléments à réaliser, sur laquelle le Product Owner
(le responsable du produit) joue un rôle décisif pour la définition des priorités, en attribuant à
chaque élément une priorité de 1 à 5, où 1 représente la plus haute priorité.

18
 N° de
La
la Rôle User story Priorité
durée
tache
En tant
Administrateur/
qu’utilisateur je
1 Conducteur / 10 1
peux créer un
Passager
compte

Sprint 1 : En tant
Administrateur/
Release 1 authentification qu’utilisateur je
2 Conducteur / 10 2
peux accéder à
Passager
l’application
En tant
qu’utilisateur, si
Administrateur/
j'ai oublié mon
3 Conducteur / 10 3
mot de passe, je
Passager
peux le
réinitialiser
En tant
qu’administrateur
4 Administrateur je peux consulter 5 1
la liste des
utilisateurs
En tant
Conducteur / qu’utilisateur je
5 5 5
Passager peux changer
mon rôle
En tant
Sprint 2 : qu’administrateur
Gestion des 6 Administrateur je peux modifier 5 5
utilisateurs le rôle
Release 1
d’utilisateur

En tant
qu’administrateur
7 Administrateur 5 3
je peux bloque un
utilisateur

En tant
Administrateur/ qu’utilisateur je
8 Conducteur / peux modifier 5 3
Passager mes données
personnelles

Sprint 3 : En tant
Administrateur/
Release 2 Gestion qu’utilisateur je
9 Conducteur / 5 2
d’Annonce peux changer
Passager
mon mot de passe

19
 En tant que
conducteur je
10 Conducteur peux poster une 3 1
annonce de
covoiturage
En tant que
conducteur je
11 Conducteur peux modifier 3 4
une annonce de
covoiturage
En tant
qu’utilisateur je
Conducteur /
12 peux supprimer 3 5
Administrateur
une annonce de
covoiturage
En tant
qu’administrateur
je peux ajouter
13 Administrateur option (WIFI, 3 5
bagages,
animaux,
fumeurs…)
Release 2 Sprint 3 : En tant
Gestion qu’administrateur
d’Annonce je peux supprimer
14 Administrateur option (WIFI, 3 5
bagages,
animaux,
fumeurs…)
En tant
qu’utilisateur je
peux choisir les
options de
15 Conducteur 3 5
l’annonce (WIFI,
bagages,
animaux,
fumeurs…)
En tant
Conducteur / qu’utilisateur je
16 3 5
Passager peux commenter
annonce
En tant
qu’administrateur
17 Administrateur je peux consulter 3 3
la liste des
commentaires

20
 En tant
Administrateur/
qu’utilisateur je
18 Conducteur / 3 2
peux consulter
Passager
annonce
En tant
qu’utilisateur je
19 Passager 20 1
peux envoyer une
Sprint 4 : réclamation
Gestion des
Réclamations En tant
qu’administrateur
20 Administrateur 10 1
je peux consulter
les réclamations

En tant que
passager je peux
21 Passager réserver places 6 1
sur l’annonce de
trajet

En tant que
conducteur je
22 Conducteur 6 3
peux accepter
réservation
Sprint 5 : En tant que
Release 3 Réservation conducteur je
23 Conducteur 6 3
peux refuser
réservation
En tant
Conducteur / qu’utilisateur je
24 6 5
Passager peux annuler
réservation
En tant
qu’administrateur
25 Administrateur 6 2
je peux consulter
les réservation
Sprint 6 :
Evaluation En tant
Conducteur /
26 qu’utilisateur je 30 1
Passager
peux donner avis
Tableau 3: Backlog du produit

IV. Environnement de développements

Cette section est dédiée à l'environnement matériel et logiciel qui a été utilisé lors de la
réalisation de notre projet.

21
 IV.1 Environnement matériel

Pendant la réalisation de notre application, nous avons utilisé des équipements dotés des
caractéristiques suivantes :

Figure 13: Caractéristiques de l’environnement matériel

IV.2 Environnement Logiciels

Dans cette section, nous allons introduire le contexte logiciel qui a été utilisé durant la phase de
développement de notre application.

IV.2.1 Logiciels de développement

Dans ce que suit, nous présentons les logiciels de développement adoptés :

• Visual Studio Code est un éditeur de code source léger mais puissant. Sur le
plan architectural, il combine le meilleur des technologies Web, natives et
spécifiques à la langue [9].

Figure 14: Logo de Visual Studio Code

• Visual Studio Community est un environnement de développement intégré

(IDE) extensible, complet et gratuit pour créer des applications modernes pour

22
 Android, iOS, Windows, ainsi que des applications web et des services cloud
[10].

Figure 15: Logo de Visual Studio Community

• Android Studio est un environnement de développement pour développer des

applications mobiles Android. Il est basé sur IntelliJ IDEA et utilise le moteur
de production Gradle [11].

Figure 16: Logo de Android Studio

• Lucidchart est une application Web de création de diagrammes et graphiques,

utilisé pour créer les diagrammes de conception de mon application [12].

Figure 17: Logo de Lucidchart

• Figma est un éditeur de graphiques vectoriels et un outil de prototypage. Il est

principalement basé sur le web, avec des fonctionnalités hors ligne activée [13].

Figure 18: Logo Figma

23
• Git Bash Git Bash est une application pour les environnements Microsoft
Windows qui fournit une couche d'émulation pour une expérience de ligne de
commande Git. Bash est l'acronyme de Bourne Again Shell. Un shell est une
application de terminal utilisée pour faire l'interface avec un système
d'exploitation par le biais de commandes écrites. Bash est un shell par défaut
populaire sous Linux et macOS. Git Bash est un package qui installe Bash,
quelques utilitaires Bash courants et Git sur un système d'exploitation Windows
[14].

Figure 19: Logo de Git Bash

• Azure DevOps Offrez de la valeur à vos utilisateurs plus rapidement en utilisant

des outils agiles éprouvés pour planifier, suivre et commenter le travail entre
équipes [15].

Figure 20: Logo de Azure DevOps

• Microsoft SQL Server est un système de gestion de base de données (SGBD)

en langage SQL incorporant entre autres un SGBDR (SGBD relationnel »)
développé et commercialisé par la société Microsoft. SQL Server se distingue
de la concurrence par une grande richesse ne nécessitant aucune option payante
supplémentaire dans la limite de la version choisie [16].

Figure 19: Logo Microsoft SQL Server

• Google Chrome est un navigateur web développé par Google, reconnu pour sa
rapidité, sa sécurité et ses nombreuses fonctionnalités. Il est largement utilisé

24
 pour naviguer sur Internet et exécuter des applications web. Nous avons utilisé
le navigateur Chrome pour tester et déboguer l’interface utilisateur de notre
application web, en nous assurant qu’elle fonctionne de manière optimale dans
un environnement couramment utilisé par les utilisateurs finaux.

Figure 20: Logo Google Chrome

• Microsoft Teams est une plateforme de communication et de collaboration en

équipe qui intègre la messagerie, les appels audio et vidéo, ainsi que la
collaboration sur des documents au sein d’un espace de travail partagé. Nous
avons utilisé Microsoft Teams pour faciliter la communication et la
collaboration entre les membres de l’équipe de développement, en permettant le
partage de documents, les discussions en temps réel et les réunions virtuelles
[17].

Figure 21: Logo Microsoft Teams

IV.2.2 Langage de modélisation adoptés

L’UML (Unified Modeling Language), langage de modélisation unifié, a été élaboré

pour être un langage visuel qui combine une riche sémantique et une syntaxe complète. Son
objectif est de simplifier la création, la conception et la mise en œuvre de systèmes logiciels
complexes en offrant une représentation cohérente à la fois de leur structure et de leur
fonctionnement. [18]

25
 Figure 22: Logo du Langage de Modélisation Unifié
L’outil de modélisation UML est similaire aux plans utilisés dans d’autres domaines et
se compose de différents types de diagrammes qui permettent de décrire le comportement du
système ainsi que des objets qui le composent. Ils offrent une représentation graphique claire et
détaillée de notre système, facilitant ainsi la compréhension et la communication au sein de
notre équipe de développement.

IV.2.3 Les technologies utilisées

Cette partie présente l’ensemble des technologies utilisées pour la réalisation de notre projet.

• .NET CORE 7 : est la dernière version du Framework de développement

multiplateforme de Microsoft. Il offre des outils avancés et des bibliothèques
pour la création d’applications modernes et évolutives. .NET Core 7 se distingue
par ses performances optimisées, sa polyvalence pour le développement web,
mobile et cloud, ainsi que son support pour les nouvelles technologies. Cela
permet aux développeurs de créer des solutions logicielles performantes et
robustes, adaptées à une variété de scénarios et de plateformes [19].

Figure 23: Logo .NET CORE

• C# représente un langage de programmation moderne et orienté objet élaboré

par Microsoft. Bien qu’il ait été initialement créé pour la construction
d’applications sur la plateforme .NET, il offre également la possibilité d’être
exploité sur diverses autres plates-formes [20].

26
 Figure 24: Logo C#

• API Gateway « Ocelot » est un point d’entrée centralisé pour les clients dans
une architecture de microservices. Elle simplifie les requêtes clients en dirigeant
les demandes vers les services appropriés, gérant l’authentification,
l’autorisation et la mise en cache. Elle facilite également la gestion des erreurs,
la surveillance et l’exposition des API. En résumé, l’API Gateway améliore
l’efficacité du développement et la sécurité en centralisant la gestion des
interactions entre les clients et les services [21].

Figure 25: Logo Ocelot

• RabbitMQ est un système de messagerie qui facilite la communication entre les

différentes microservices. Il agit comme un intermédiaire pour l’échange de
messages entre les composants, les microservices ou les applications. En
utilisant des files d’attente, RabbitMQ assure une transmission fiable des
messages même dans des environnements complexes et à grande échelle [22].

Figure 26: Logo RabbitMQ

• MediatR est un modèle de conception logicielle qui facilite la communication

entre les différentes parties d’une application en suivant le principe de la
médiation. Il permet de réduire les dépendances directes entre les composants en
utilisant des médiateurs pour faciliter les interactions. En utilisant MediatR, les

27
 différentes parties de l’application peuvent communiquer de manière centralisée
en envoyant des demandes et en gérant les actions à l’aide de gestionnaires
spécifiques. Cela simplifie la gestion des interactions et rend le code plus
modulaire et facilement extensible. MediatR est particulièrement utile pour la
mise en œuvre du modèle CQRS (Command Query Responsibility Segregation)
et pour créer des applications plus flexibles et évolutives [23].

Figure 27: Logo MediatR

• Docker est une plateforme de virtualisation légère et portable qui permet
d’emballer, de distribuer et d’exécuter des applications et leurs dépendances de
manière isolée dans des conteneurs. Cette approche facilite le déploiement
cohérent et reproductible des applications sur différents environnements, tout en
optimisant l’utilisation des ressources système [24].

Figure 28: Logo Docker

• MySQL est un système de gestion de base de données relationnelle open source

largement utilisé dans le développement d’applications. Il permet de stocker,
gérer et interroger efficacement des données structurées dans des tables
relationnelles. MySQL offre une performance élevée, une grande stabilité et une
compatibilité avec de nombreux langages de programmation et Framework. Il
est fréquemment utilisé pour la création de sites web, d’applications d’entreprise
et d'autres solutions nécessitant la gestion et la manipulation de données [25].

28
 Figure 29: Logo MySQL

• Swagger est un ensemble d’outils open source utilisés pour concevoir,

construire, documenter et tester des API REST. Il fournit une manière
standardisée de décrire les end points, les paramètres, les réponses et les schémas
de données d’une API, ce qui facilite la communication entre les développeurs,
les équipes et les clients. Swagger génère également une documentation
interactive basée sur cette description, ce qui permet aux utilisateurs d’explorer
et de tester facilement l'API [26].

Figure 30: Logo Swagger

• Angular est un framework de développement d’applications web frontales basé

sur TypeScript. Il permet de créer des applications dynamiques et interactives en
utilisant des composants réutilisables, des directives et un système de gestion de
l’état [27].

Figure 31: Logo Angular

• TypeScript est un langage de programmation open source développé par

Microsoft. Il sert de sur-ensemble à JavaScript, ajoutant des fonctionnalités de
typage statique, de classes et d’interfaces. TypeScript facilite le développement

29
 d’applications web complexes en détectant les erreurs à l’avance et en
améliorant la maintenabilité du code [28].

Figure 32: Logo TypeScript

• HTML5 est la dernière version du langage de balisage HTML utilisé pour

structurer le contenu des pages web. Il introduit de nouvelles fonctionnalités
telles que les balises sémantiques, la vidéo et l’audio intégrés, ainsi que des API
pour la manipulation de l’interface utilisateur [29].

Figure 33: Logo HTML

• Bootstrap est un framework CSS open source qui facilite la création d’interfaces
web responsives et esthétiques. Il offre une collection de composants prédéfinis,
de grilles et de styles CSS prêts à l’emploi, accélérant ainsi le processus de
conception et d’alignement [30].

Figure 34: Logo Bootstrap

• Les feuilles de style en cascade (CSS) sont utilisées pour définir la présentation
visuelle des éléments HTML. CSS permet de personnaliser les couleurs, les
polices, les marges et d’autres aspects de la mise en page, contribuant à l’aspect
esthétique et à l’expérience utilisateur d’un site web [31].

30
 Figure 35: Logo CSS

• Flutter est un framework open source développée par Google pour la création
d’applications mobiles multiplateformes. Il utilise le langage Dart et propose une
approche de développement rapide et cohérente pour iOS et Android. Flutter se
distingue par ses widgets personnalisables et sa haute performance graphique
[32].

Figure 36: Logo Flutter

• Dart est un langage de programmation moderne développé par Google. Il est

utilisé principalement pour le développement d’applications web, mobiles et de
bureau. Dart se caractérise par sa simplicité, ses performances élevées et sa
syntaxe propre. Il est notamment utilisé avec le framework Flutter pour la
création d’applications mobiles multiplateformes, grâce à son approche de
développement rapide et à sa capacité à générer des interfaces utilisateur fluides
et réactives. Dart prend en charge à la fois la programmation orientée objet et
fonctionnelle, ce qui en fait un choix polyvalent pour une variété de projets de
développement [33].

Figure 37: Logo Dart

31
V. Architecture de l’application

V.1 Architecture Microservices

L’architecture en microservices modèle le développement d’une application sous la

forme d’un ensemble de plusieurs services. Chacun de ces services fonctionne d’une manière
indépendante au sein de son propre processus léger et interagit, en cas de besoin, à travers le
message broker basé pour notre projet sur la technologie RabbitMQ. Ces services sont conçus
en fonction des compétences métiers et déployés de manière autonome grâce à des processus
automatisés [34]. Cette architecture a le grand avantage d’assurer le développement des services
par de petites équipes autonomes et permet à chacun d’elle d’apporter des modifications voire
de remplacer un service par un autre, sans se soucier de l’impact sur le reste du système.

Figure 38: Architecture Microservices

Cette architecture offre divers avantages tels que la variété technologique, la résilience
face aux pannes, la possibilité d’une évolutivité personnalisée, la simplicité de déploiement,
une meilleure adéquation avec la structure organisationnelle, ainsi que la réutilisabilité, entre
autres.
Pour la gestion des communications entre les différents microservices d’une manière
asynchrone, nous avons opté pour l’utilisation de RabbitMQ en tant que message broker.
RabbitMQ offre une fiabilité exceptionnelle dans la transmission des messages entre les
services, garantissant ainsi que les informations cruciales parviennent rapidement et de manière
cohérente à leurs destinations respectives. De plus, pour simplifier la gestion des demandes
d’API et router efficacement le trafic, nous avons choisi Ocelot en tant qu’API Gateway. Ocelot
facilite la configuration des points d’entrée et la gestion des autorisations, ce qui améliore la

32
sécurité et la performance globale de notre système. Ces décisions architecturales renforcent la
robustesse et la capacité d’adaptation de notre application de covoiturage.

V.2 Clean Architecture

La Clean Architecture est un concept de conception logicielle qui vise à créer des
systèmes modulaires et faciles à entretenir en organisant le code en différentes couches. Ces
couches sont conçues pour être indépendantes les unes des autres, ce qui favorise la séparation
des préoccupations et la réduction des dépendances entre les composants [35].

Figure 39: Clean Architecture

Les quatre couches de la Clean Architecture sont :

• Couche de Domaine : La couche de domaine encapsule la logique métier

centrale de l’application. Elle contient les règles métier, les entités et les valeurs
qui définissent le cœur de l’application. Cette couche est généralement
indépendante de tout cadre ou technologie spécifique.
• Couche d’Interface de Programmation Applicative (api) : Cette couche
représente l’interface utilisateur, que ce soit une application web, une application
mobile ou une interface en ligne de commande. Elle gère les interactions avec
les utilisateurs et présente les données de manière compréhensible.
• Couche d’Application : Cette couche contient la logique métier de l’application.
Elle coordonne les actions de l’utilisateur et orchestre les opérations métier en

33
 utilisant les services de la couche de domaine. Elle est également responsable de
la validation des données et de la gestion des erreurs.
• Couche d’Infrastructure : Cette couche gère les détails techniques tels que les
bases de données, les services externes, la communication réseau, etc. Elle agit
comme une passerelle entre les couches supérieures et les composants externes,
en veillant à ce que la couche de domaine ne soit pas dépendante des
technologies sous-jacentes.

Dans l’ensemble, la Clean Architecture favorise la maintenabilité, la testabilité et la

flexibilité en garantissant que chaque couche a une portée clairement définie et en minimisant
les dépendances entre elles. Cela permet également d’isoler les changements et les évolutions
technologiques, ce qui facilite la mise à jour ou le remplacement de composants spécifiques
sans affecter l’ensemble du système.
Pour l’amélioration des performances, clean architecture recommande l’introduction
des notions ci-après.

IV.2.1 Le Pattern Médiator

Le modèle Médiator est un pattern de conception qui facilite les interactions entre les
composants d’une application en centralisant la communication entre eux. Au lieu d’avoir des
liaisons directes entre les composants, Médiator agit comme un intermédiaire, réduisant les
dépendances et simplifiant la maintenance. Il favorise la modularité en permettant aux
composants de collaborer sans connaître les détails de mise en œuvre des autres composants.
Médiator est souvent associé à CQRS pour gérer la communication entre les commandes et les
gestionnaires de requêtes [36].

Figure 40: Schéma de Médiator

34
 IV.2.2 Le Pattern CQRS

Le modèle CQRS (Command Query Responsibility Segregation) est un pattern

architectural qui découple les opérations de lecture (query) des opérations d’écriture
(command) au sein d’une application. Cela permet d’optimiser la performance en traitant les
requêtes et les commandes de manière distincte, en accord avec les besoins spécifiques de
chaque type d’opération. Ce modèle est souvent mis en œuvre conjointement avec Médiator
pour gérer les communications entre les différents composants de l’application [37].

Figure 41: Schéma du Modèle CQRS

V.3 Architecture MVVM (Partie Web)

L’architecture MVVM (Modèle-Vue-Vue Modèle) est un modèle d’architecture qui sépare

les différentes responsabilités d’une application en trois composants principaux : le Modèle,
la Vue et le Vue Modèle [38].

• Modèle (Model) : Le Modèle représente les données et la logique métier de

l’application. Il gère les opérations de manipulation de données, de stockage et de
communication avec les sources de données externes, telles que les bases de données
ou les services web.
• Vue (View) : La Vue est responsable de l’affichage des données à l’utilisateur et de
l’interaction avec lui. Elle se concentre sur la présentation visuelle de l’interface
utilisateur. Dans le contexte de MVVM, la Vue est généralement passive et ne contient
pas de logique métier complexe.
• Vue Modèle (ViewModel) : Le Vue Modèle agit comme un intermédiaire entre le
Modèle et la Vue. Il gère la logique de présentation et les actions de l’interface
utilisateur. Le Vue Modèle récupère les données du Modèle et les prépare de manière
à ce qu’elles puissent être affichées de manière appropriée dans la Vue. Il gère

35
 également les interactions de l’utilisateur et peut contenir une partie de la logique
métier liée à l’interface.

Figure 42: Architecture MVVM

V.4 Architecture MVC (Partie mobile)

L’architecture MVC (Modèle-Vue-Contrôleur) est un modèle d’architecture qui divise une

application en trois composants principaux : le Modèle, la Vue et le Contrôleur [39].

• Modèle : Tout comme dans l’architecture MVVM, le Modèle gère les données et la
logique métier de l’application.
• Vue : La Vue est chargée de présenter les données au format approprié pour l’utilisateur.
Elle ne contient généralement pas de logique métier.
• Contrôleur : Le Contrôleur agit comme un intermédiaire entre le Modèle et la Vue. Il
gère les interactions de l’utilisateur et la logique de traitement. Contrairement au Vue
Modèle de MVVM, le Contrôleur peut contenir davantage de logique métier, y compris
celle liée à l’interface.

Figure 43: Schéma MVC

V.5 Architecture globale du projet

Dans la figure suivante, on peut observer la représentation architecturale de notre plateforme,

reflétant les technologies choisies :

36
 Figure 44: Architecture Globale de l’application
Conclusion :
Ce Chapitre a établi un solide fondement pour le projet en présentant le contexte général,
les besoins spécifiques, la méthodologie de développement et les choix architecturaux. Ces
éléments fournissent une base solide pour la réalisation du projet, en alignant les objectifs avec
les ressources et les méthodes les plus appropriées. La prochaine étape consistera à mettre en
œuvre ces concepts et à concrétiser la vision du projet.

37
 Chapitre III : Release 1
Introduction
Une fois les exigences identifiées dans le Product Backlog, il est temps d’expliquer en
détail chaque livraison.
Au cours de ce chapitre, nous allons détailler la première livraison, en détaillant les
étapes de sa réalisation.

I. Sprint 1: Authentification

Ce sprint a été consacré à la mise en place de Microservice Authentification pour

permettre à l’utilisateur, conducteur, passager ou administrateur, de s’authentifier.

I.1 Objectif de sprint

L’objectif de ce Sprint est de mettre en œuvre l’ensemble des fonctionnalités nécessaires

pour permettre aux utilisateurs de s’inscrire, s’authentifier et de réinitialiser mot de passe en
cas d’oubli.

I.2 Backlog de Sprint n°1 Authentification

Le début du projet a été marqué par le premier sprint, centré sur l’établissement de
l’authentification et de l’inscription. Ces deux fonctionnalités revêtent une importance cruciale
pour garantir la sécurité de l’application. Avant d’entamer les travaux de ce sprint, l’équipe a
sélectionné les scénarios utilisateurs à traiter au cours de cette phase de développement. Par la
suite, ces scénarios ont été décomposés en tâches élémentaires, avec une estimation de la durée
en heures pour chacune, consignée dans le Backlog du sprint 1.

ID Rôle User Story Taches Priorité

• Création d’un compte
• Activation d’un compte
En tant • Envoyer mail
Administrateur/ qu’utilisateur je d’activation
1 Conducteur / • Réaliser interface 1
peux créer un d’inscription pour
Passager
compte Dashboard
• Réaliser des interfaces
d’inscription pour
application mobile

38
 • Réaliser interface
d’activation compte
mobile
• Réaliser interface
d’activation compte web
• Authentification
En tant • Réaliser interface
d’authentification pour
Administrateur/ qu’utilisateur je Dashboard
2 Conducteur / • Réaliser interface 2
peux accéder à
Passager
d’authentification pour
l’application
application mobile

• Réinitialiser le mot de
passe
• Envoyer mail de
En tant
réinitialisation mot de
qu’utilisateur, si passe
Administrateur/ j’ai oublié mon • Réaliser interface de
3 Conducteur / réinitialisation mot de 3
mot de passe, je passe pour Dashboard
Passager
peux le • Réaliser interface
réinitialisation mot de
réinitialiser
passe pour application
mobile

Tableau 4: Backlog de Sprint n°1 Authentification

I.3 Conception du Sprint n°1

I.3.1 Diagramme de cas d’utilisation « S’inscrire »

Les diagrammes de cas d’utilisation décrivent ce que fait un système et comment les
acteurs l’utilisent, sans montrer comment le système fonctionne à l’intérieur.
La figure ci-dessous représente le diagramme de cas d’utilisation « S’inscrire ».

39
 Figure 45: Diagramme de cas d’utilisation « S’inscrire »

I.3.2 Diagramme de cas d’utilisation « S’authentifier »

Le diagramme de cas d’utilisation qui suit représente le processus d’authentification

dans l’application.

Figure 46: Diagramme de cas d’utilisation « S’authentifier »

I.3.3 Diagramme de classe de Sprint n°1

Ce diagramme représente la structure des classes et des relations spécifiques au premier
sprint du projet, couvrant l’authentification, l’inscription et réinitialisation de mot de passe.

Figure 47: Diagramme de classe de sprint n°1

40
 I.3.4 Description textuelle du cas d’utilisation « S’inscrire »
partie Mobile
Pour la partie mobile, la description textuelle du cas d’utilisation « S’inscrire » concerne
le processus de création de compte. Cette partie présente en détail les étapes et les
fonctionnalités liées à cette fonctionnalité. Le tableau suivant détaille la description textuelle
du cas d’utilisation « S’inscrire » dans la partie mobile.

Cas d’utilisation S’inscrire

Acteur(s) Passager, Conducteur.

Pré condition L’utilisateur n’a pas un compte.

Post-condition Créer un compte correct qui permet la connexion, et l’accès aux services
de l’application.
Scénario 1. L’utilisateur remplit les champs du formulaire (Nom utilisateur, mot
nominal
de passe …)
2. Soumettre le formulaire.
3. Vérification des informations par le système, et l’envoie d’un code
pour confirmer le compte.
4. L’utilisateur saisi le code de confirmation reçu par mail.
5. Compte créé.
Scénario 1.1 Si les champs obligatoires sont vides, ou les données entrées ne
alternatif vérifies pas la forme demandée : un message d’erreur est affiché, et
demande de ressaisie.
3.1 Si le compte est déjà existant : affichage d’un message d’erreur.
4.1 Si le code est incorrect : affichage d’un message d’erreur.
Tableau 5: Description textuelle du cas d’utilisation « S’inscrire » partie mobile

I.3.5 Diagramme de séquence « S’inscrire » partie Mobile

Le schéma de séquence constitue un type de diagramme d’interaction qui dépeint les

éléments engagés dans une interaction spécifique, ainsi que les échanges de messages qu’ils
accomplissent, structurés selon des séquences temporelles. De manière générale, dans ce
schéma, la dimension verticale symbolise le temps (de haut en bas), tandis que la dimension
horizontale illustre les divers éléments participants.

41
 Figure 48: Diagramme de séquence « S’inscrire » partie Mobile

I.3.6 Description textuelle du cas d’utilisation « S’inscrire »

partie web

La description textuelle du cas d’utilisation « S’inscrire » dans la partie web concerne

également le processus de création de compte. Cette section expose de manière détaillée les
différentes étapes et fonctionnalités associées à cette action.

Cas d’utilisation S’inscrire

Acteur(s) Administrateur.

42
 Pré condition L’Administrateur n’a pas un compte.

Post-condition Créer un compte correct qui permet la connexion, et l’accès aux services
de Dashboard.
Scénario 1. L’Administrateur remplit les champs du formulaire (Nom utilisateur,
nominal mot de passe …)
2. Soumettre le formulaire.
3. Vérification des informations par le système, et l’envoie d’un email
pour confirmer le compte.
4. Confirmation de compte à travers le lien reçu par mail.
5. Compte créé.
Scénario 1.1 Si les champs obligatoires sont vides, ou les données entrées ne
alternatif vérifies pas la forme demandée : un message d’erreur est affiché, et
demande de ressaisie.
3.1 Si le compte est déjà existant : affichage d’un message d’erreur.
4.1 Si l’Administrateur se connecte sans avoir confirmer son compte
avec le lien reçu par mail : affichage d’un message d’erreur.
Tableau 6: Description textuelle du cas d’utilisation « S’inscrire » partie web

I.3.7 Diagramme de séquence du cas d’utilisation « S’inscrire »

partie Web

Le diagramme de séquence ci-dessous illustre le cas d’utilisation « S’inscrire » dans la

version Web.

43
 Figure 49: Diagramme de séquence du cas d’utilisation « S’inscrire » Web

I.3.8 Description textuelle du cas d’utilisation « S’authentifier »

partie web

Le tableau suivant expose la description textuelle du cas d’utilisation « S’authentifier »

dans la partie web.

Cas d’utilisation S’authentifier

Acteur(s) Administrateur.
Pré condition L’Administrateur est déjà inscrit.
Post-condition Accès au Dashboard.

44
 Scénario 1. L’Administrateur remplit le formulaire.
nominal 2. Le système vérifie les données saisies.
4. Le système affiche l’interface d’accueil.
Scénarios 1.1 L’Administrateur remplit le formulaire par des données incorrectes.
alternatif 1.2 Le système vérifie les données et Le système affiche un message
d’erreur.
Tableau 7: Description textuelle du cas d’utilisation « S’authentifier » partie web

I.3.9 Diagramme de séquence du cas d’utilisation

«S’authentifier» partie Web

Le diagramme de séquence ci-après illustrant le processus d’authentification dans la

partie Web de l’application.

Figure 50: Diagramme de séquence du cas d’utilisation « S’authentifier » partie Web

45
 I.3.10 Description textuelle du cas d’utilisation « Mot de passe
oublié » partie Mobile

Le Tableau 8 décrit de manière détaillée le cas d’utilisation « Mot de passe oublié » dans
la partie Mobile, mettant en lumière les étapes clés de ce processus.

Cas d’utilisation Mot de passe oublié

Acteur(s) Passager, Conducteur.

Pré condition L’utilisateur a oublié son mot de passe et souhaite le réinitialiser.

Post-condition Le mot de passe de l’utilisateur est réinitialisé avec succès.

Scénario 1. Le système affiche un formulaire de réinitialisation de mot de passe.

nominal 2. L’acteur saisit son adresse e-mail associée à son compte.
3. Le système génère un code unique et l’envoie à l’adresse e-mail de
l’utilisateur.
4. Le système affiche l’interface de saisi du code.
5. L’utilisateur saisi le code.
6. Le système affiche l’interface de réinitialisation de mot de passe.
7. L’acteur saisit et confirme le nouveau mot de passe, puis valide.
8. Le système affiche un message de succès.
Scénario 1.1 L’utilisateur saisit une adresse e-mail invalide ou non enregistrée.
alternatif 5.1 L’utilisateur saisi un code non valide : un message d’erreur s’affiche
7.1 L’utilisateur saisit un nouveau mot de passe faible qui ne répond pas
aux critères de sécurité : un message d’erreur s’affiche.
Tableau 8: Description textuelle du cas d’utilisation « Mot de passe oublié » partie web

I.3.11 Diagramme de séquence de mot de passe oublié

Voici le diagramme de séquence du cas d’utilisation « Mot de passe oublié » dans l’application.

46
 Figure 51: Diagramme de séquence de mot de passe oublié

I.4 Sprint Review

La revue du sprint est tenue à la fin de chaque Sprint pour démontrer l’incrément, l’inspecter et
adapter le Product Backlog si nécessaire.
Les figures suivantes représentent l’interface d’inscription partie Web et Mobile :

• L’interface d’inscription côté web permet aux administrateurs de créer un compte sur le
Dashboard Admin en fournissant ses informations.

Figure 52: Interface d’inscription partie Web

47
• Interface de Connexion Web représente l’écran par lequel les administrateurs peuvent
se connecter au Dashboard en saisissant leur adresse e-mail et leur mot de passe.

Figure 53: Interface login

• L’interface mot de passe oublié représente un mécanisme permettant aux utilisateurs de

récupérer leur mot de passe en cas d’oubli. Cela se fait via une petite fenêtre contextuelle
qui s’affiche, leur permettant de fournir des informations pour réinitialiser leur mot de
passe.

Figure 54: Interface mot de passe oubliée Dashboard Admin

48
 Figure 55: Interfaces mot de passe oubliée Application Mobile

• La figure suivante représente l’e-mail envoyé aux utilisateurs après leur inscription sur
notre plateforme. Cet e-mail contient un message, un lien de confirmation, et le code de
vérification pour activer leur compte.

Figure 56: Interface de l’e-mail de confirmation d’inscription

49
 • Les interfaces de l’application mobiles comprennent l’inscription, la connexion, le
téléchargement d’une image de profil et la vérification par e-mail via un code. Elles
offrent une expérience utilisateur complète et sécurisée.

Figure 57: Interface login Application Mobile

Figure 58: Les interfaces d’inscription de la partie mobile

I.5 Rétrospective du Sprint n°1

Lors de la rétrospective du Sprint 1, nous avons identifié ce qui a bien fonctionné, ce

qui peut être amélioré et élaboré un plan d’actions pour la suite du projet. Ce processus nous a

50
permis de tirer des enseignements précieux pour optimiser notre méthodologie et notre
efficacité.
Le tableau ci-dessous illustre les résultats de la rétrospective du sprint 1 :
Ce qui a bien fonctionné Ce qui peut être amélioré Plan d’actions
• L’installation de
• La bonne • Renforcer la
l’environnement de travail
compréhension des communication au sein de
• Authentification mise en
besoins de Product l’équipe en organisant des
place avec succès
Owner réunions plus fréquentes.

Tableau 9: Rétrospective de sprint n°1

II. Sprint 2 : Gestion des profils

Ce sprint a été consacré à la mise en place de Microservice Gestion des profils pour
permettre à l’utilisateur, conducteur ou passager, de gérer son profil, son rôle, et à
l’administrateur de gérer les utilisateurs et son profil.

II.1 Objectif de sprint

L’objectif du sprint est de :

• Mettre en place les fonctionnalités nécessaires pour que les utilisateurs puissent
modifier leurs données personnelles et de personnaliser leurs profils sur la
plateforme et de changer leurs propres mots de passe en toute simplicité.
• Permettre d’une part à l’administrateur de consulter la liste des utilisateurs, de
changer le rôle d’un utilisateur et de bloquer un utilisateur.

II.2 Backlog de Sprint n°2 Gestion des profils

Ce Backlog représente une liste de tâches et d’objectifs prioritaires à réaliser lors du

deuxième sprint du projet de gestion des profils, couvrant des aspects tels que la gestion des
informations personnelles et des images de profil, la modification de mot de passe, etc.
ID Rôle User story Tâches Priorité
• Récupérer la liste des
En tant utilisateurs
qu’administrateur • Réaliser une interface
4 Administrateur je peux consulter pour afficher les 1
la liste des utilisateurs
utilisateurs • Afficher les listes des
utilisateur

51
 • Basculer entre rôle «
En tant conducteur » ou
Conducteur / qu’utilisateur je « passager »
5 peux changer mon • Réaliser une interface 5
Passager
rôle mobile pour changer le
rôle
En tant • Modifier le rôle d’un
qu’administrateur utilisateur
6 Administrateur je peux modifier le • Réaliser une interface 5
rôle d’un web simple pour changer
utilisateur le rôle d’un utilisateur

En tant • Suppression logique

qu’administrateur d’utilisateur
7 Administrateur je peux bloquer un • Confirmation de 3
utilisateur suppression

• Modifier les données

personnelles
• Réaliser une interface
En tant
web simple pour afficher
Administrateur/ qu’utilisateur je
et modifier les données
8 Conducteur / peux modifier mes 3
personnelles
Passager données
• Réaliser une interface
personnelles
Mobile simple pour
afficher et modifier les
données personnelles
• Modifier le mot de passe
• Réaliser une interface
En tant
Administrateur/ web simple pour changer
qu’utilisateur je
9 Conducteur / le mot de passe 2
peux changer mon
Passager mot de passe • Réaliser une interface
Mobile simple pour
changer le mot de passe
Tableau 10: Backlog de Sprint n°2 Gestion des profils

II.3 Conception du Sprint n°2

II.3.1 Diagramme de cas d’utilisation « Gérer son profil »

Ce diagramme permet de visualiser les interactions possibles entre l’utilisateur et son

profil au sein du système.

52
 Figure 59: Diagramme de cas d’utilisation « Gérer son profil »

II.3.1 Diagramme de cas d’utilisation « Gérer les utilisateurs »

La figure suivante représente le diagramme des cas d’utilisations détaillé du sprint 2 « Gérer
les utilisateurs » :

Figure 60: Diagramme de cas d’utilisation « Gérer les utilisateurs »

53
 II.3.2 Diagramme de cas d’utilisation « Modifier son rôle »
La figure suivante représente le diagramme des cas d’utilisations détaillé du sprint 2 « Modifier
son rôle » :

Figure 61: Diagramme de cas d'utilisation « Modifier son rôle »

II.3.3 Diagramme de classe de Sprint n°2

Ce diagramme représente la structure des classes et des relations spécifiques au

deuxième sprint du projet, couvrant la gestion des profils et d’autres fonctionnalisées liées aux
utilisateurs.

Figure 62: Diagramme de classe de Sprint n°2

54
 II.3.4 Description textuelle du cas d’utilisation « Modifier le rôle
d’un utilisateur »

La description textuelle du cas d’utilisation « Modifier le rôle d’un utilisateur », Comme

le montre le tableau ci-dessous, désigne la possibilité pour l’administrateur de modifier le rôle
d’un utilisateur au sein du système.
Cas d’utilisation Modifier le rôle d’un utilisateur

Acteur(s) Administrateur

Précondition Administrateur authentifié

Post condition Rôle modifié

Scénario nominal 1. L’administrateur accède au section

utilisateur.
2. L’administrateur clique sur le bouton
modifier.
3. Un pop-up s’affiche.
4. L’administrateur sélectionne un rôle
parmi la liste des rôles.
5. L’administrateur clique sur enregistrer
6. Mise à jour de la section utilisateur avec
affichage de nouveau rôle
Scénario alternatif 3.1 L’administrateur ferme le pop-up sans
rien modifier
Tableau 11: Description textuelle du cas d’utilisation « Modifier le rôle d’un utilisateur »

II.3.5 Diagramme de séquence du cas d’utilisation « Modifier le

rôle d’un utilisateur »

Ce diagramme montre la séquence d’actions et d’interactions entre l’administrateur et

le système lorsqu’il modifie le rôle d’un utilisateur.

55
 Figure 63: Diagramme de séquence du cas d’utilisation « Modifier le rôle d’un utilisateur »

II.3.6 Description textuelle du cas d’utilisation « Modifier ses

données personnelles »

La Description textuelle du cas d’utilisation « Modifier ses données personnelles »

décrit le processus par lequel l’utilisateur met à jour ses informations personnelles dans
l’application.

Cas d’utilisation Modifier ses données personnelles

Acteur(s) Conducteur, Passager, Administrateur
Précondition Utilisateur authentifié
Post condition Données personnelles modifiées
Scénario nominal 1. L’utilisateur accède à la section mon
profil.
2. L’utilisateur consulte son profil
3. L’utilisateur modifie les champs à
modifier.
4. L’utilisateur enregistre ses modifications.
5. Mise à jour des données personnelles.
Scénario alternatif 4.1 L’utilisateur clique sur annuler.

Tableau 12: Description textuelle du cas d’utilisation « Modifier ses données personnelles »

56
 II.3.7 Diagramme de séquence du cas d’utilisation « modifier
profil »

Le diagramme suivant illustre de manière séquentielle les étapes et les interactions entre
l’utilisateur et le système lorsqu’il effectue des modifications à son profil dans l’application.

Figure 64: Diagramme de séquence du cas d’utilisation « Modifier ses données personnelles »

II.3.8 Description textuelle du cas d’utilisation « Changer mot de

passe »

Cette partie décrit comment un utilisateur peut mettre à jour son mot de passe au sein
de l’application pour renforcer la sécurité de son compte.
Cas d’utilisation Changer mot de passe

Acteur(s) Conducteur, Passager, Administrateur

Précondition L’utilisateur authentifié.

Post condition Mot de passe changé.

Scénario nominal 1. L’utilisateur accède au formulaire du

changement de mot de passe.
2. L’utilisateur saisit son mot de passe
actuel.
3. L’utilisateur saisit le nouveau mot de
passe.

57
 4. L’utilisateur clique sur enregistrer le
changement.
Scénario alternatif 2.1 Le mot de passe actuel saisit par
L’utilisateur est incorrect : afficher un
message d’erreur.
2.2 Le nouveau mot de passe saisit par
L’utilisateur est court ou faible (au moins 8
caractères avec au minimum un chiffre, un
caractère spécial et une lettre en majuscule).
Tableau 13: Description textuelle du cas d’utilisation « Changer mot de passe »

II.3.9 Diagramme de séquence du cas d’utilisation « Changer mot de passe »

La figure suivante montre les étapes et les interactions entre l’utilisateur et le système lors
d’un changement de mot de passe.

Figure 65: Diagramme de séquence du cas d’utilisation « Changer mot de passe »

58
 II.4 Sprint Review

Pour illustrer la réalisation de la gestion des profils, des captures d’écran ont été incluses
dans la Sprint Review, mettant en évidence les fonctionnalités implémentées telles que la
modification des informations personnelles et la mise à jour des images de profil. Ces images
offrent un aperçu concret des avancées réalisées au cours de ce sprint.

• Voici les interfaces du Dashboard Admin de gestion des utilisateurs, ou

il peut non seulement consulter la liste des utilisateurs, mais aussi, de chercher un
utilisateur de le bloquer, ou de modifier son rôle.

Figure 66: Interface de gestion des utilisateurs

Figure 67: Interface de changement des rôles

• Voici une interface de Dashboard Admin ou l’administrateur peut changer sa photo de

profil, ses données personnelles et son mot de passe.

59
 Figure 68: Interface de gestion de profil administrateur

• Voici les interfaces de l’application mobile de gestion des profils pour les utilisateurs,
offrant une expérience conviviale et pratique pour la gestion de leurs informations
personnelles, de leur photo de profil, et d’autres paramètres associés à leur profil au sein
de l’application.

Figure 69: Interfaces gestion des profils utilisateurs

60
 II.5 Rétrospective du Sprint n°2

Pour garantir une amélioration continue, nous avons élaboré un plan d’amélioration
comprenant les actions suivantes notamment en ce qui concerne la gestion des images des
profils, nous avons remarqué que le chargement prend un temps assez important qui dépend de
la taille de l’image. Pour y remédier, nous avons prévu d’implémenter une solution de stockage
d’images plus efficace et conviviale :
Ce qui a bien fonctionné Ce qui peut être amélioré Plan d’actions
• Mise en place d’une
• Gestion des profils mise en • Gestion des images à solution de réduction de
place de manière efficace. améliorer. temps de chargement
d’image.

Tableau 14: Rétrospective du Sprint n°2

Conclusion
La Release 1, englobant les sprints 1 et 2, axés sur l’authentification et la gestion des
profils, a été couronnée de succès. Les livrables du Sprint 1 et Sprint 2 ont marqué une avancée
significative dans notre projet, améliorant ainsi l’expérience globale de nos utilisateurs. Nous
sommes désormais prêts à poursuivre notre progression avec la Release 2 pour étendre
davantage les fonctionnalités de notre application.

61
 Chapitre IV : Release 2
Introduction
Dans cette deuxième phase de notre projet, appelée Release 2, nous nous concentrons
sur deux aspects essentiels : la gestion des annonces lors du Sprint 3 et la gestion des
réclamations lors du Sprint 4. Ces éléments sont cruciaux pour offrir une expérience utilisateur
optimale. Nous explorerons en détail les fonctionnalités développées dans ces sprints, en
mettant en avant leurs bénéfices pour notre système de covoiturage.

I. Sprint 3 : Gestion des Annonces

Le troisième sprint a été consacré à la mise en place de Microservice Gestion des

Annonces pour pouvoir gérer les annonces de covoiturage, gérer les commentaires sur ses
annonces et gérer les options spécifiques des annonces, comme animaux autorisés ou pas, WIFI
disponible ou pas, bagages autorisés ou pas, fumeurs autorisés ou pas etc.…, qui donnent un
aspect plus personnalisé à chaque annonce de covoiturage qui rend l’expérience d’utilisateur
très enrichissante.

I.1 Objectif de sprint

Ce sprint a pour objectif de mettre en place les fonctionnalités essentielles liées à la

gestion des annonces de covoiturage. Il permettra :

• Aux conducteurs d’ajouter, de modifier et de supprimer leurs annonces et de

personnaliser les options (défense ou pas de fumer, wifi, animaux etc..),
spécifiques de chaque annonce.
• Les utilisateurs pourront laisser des commentaires sur les annonces et consulter
les offres disponibles.
• L’administrateur de surveiller les annonces et les commentaires, ainsi que
d’ajouter ou de supprimer les options de covoiturage (défense ou pas de fumer,
wifi, animaux etc..), si nécessaire.

I.2 Backlog de Sprint n°3 Gestion des annonces

Ce Backlog représente une liste de tâches et d’objectifs prioritaires à réaliser lors du

troisième sprint du projet de gestion des annonces.

62
 ID Rôle User story Tâches Priorité
10 En tant que • Ajouter une annonce
conducteur je • Réaliser une interface
Conducteur peux poster une Mobile pour ajouter 1
annonce de une annonce
covoiturage
11 En tant que • Modifier une annonce
conducteur je • Réaliser une interface
Conducteur peux modifier Mobile pour afficher
une annonce de les données actuelles 4
covoiturage d’une annonce et les
modifier
12 En tant • Suppression logique
qu’utilisateur je d’une annonce
Conducteur / peux supprimer • Confirmer la 5
Administrateur une annonce de suppression d’une
covoiturage annonce
13 En tant • Ajouter une option de
qu’administrateur covoiturage (défense
je peux une ou pas de fumer, wifi,
ajouter des animaux etc…)
options • Réaliser une interface
Administrateur spécifiques pour web pour ajouter des 5
les annonces options (défense ou pas
(défense ou pas de fumer, wifi,
de fumer, wifi, animaux etc…)
animaux etc..)
14 En tant • Supprimer une option
qu’administrateur (défense ou pas de
je peux supprimer fumer, wifi, animaux
Administrateur une option etc...) 5
(défense ou pas
de fumer, wifi,
animaux etc..)
15 En tant • Récupérer les options
qu’utilisateur je (défense ou pas de
peux choisir les fumer, wifi, animaux
options de etc..)
Conducteur l’annonce • Afficher les options 5
(défense ou pas • Sélectionner les
de fumer, wifi, option(s) (défense ou
animaux etc..) pas de fumer, wifi,
animaux etc..)

63
 16 En tant • Ajouter commentaire
Conducteur / qu’utilisateur je • Afficher les
peux commenter commentaires de 5
Passager
annonce chaque annonce
17 En tant • Récupérer les
qu’administrateur commentaires
Administrateur je peux consulter • Afficher les 3
les commentaires commentaires
18 En tant • Récupérer les
Administrateur/ qu’utilisateur je annonces
Conducteur / peux consulter les • Afficher les annonces 2
Passager annonces

Tableau 15: Backlog de Sprint n°3 Gestion des annonces

I.3 Conception du Sprint n°3

I.3.1 Diagramme de cas d’utilisation « Gérer les annonces pour

les conducteurs »

Le diagramme de cas d’utilisation suivant illustre les actions et fonctionnalités

spécifiques que les conducteurs peuvent effectuer pour administrer leurs annonces au sein de
l’application.

Figure 70: Diagramme de cas d’utilisation « Gérer les annonces pour les conducteurs »

64
 I.3.2 Diagramme de cas d’utilisation « Gérer les annonces pour
les passagers »

Les interactions des passagers avec les annonces sont illustrées dans ce diagramme :

Figure 71: Diagramme de cas d’utilisation « Gérer les annonces pour les passagers »

I.3.3 Diagramme de cas d’utilisation « Gérer les annonces pour

administrateur »

Les actions et fonctionnalités spécifiques que les administrateurs peuvent entreprendre

pour gérer les annonces au sein de l’application sont illustrées dans la figure ci-après.

Figure 72: Diagramme de cas d’utilisation « Gérer les annonces pour administrateur »

65
 I.3.4 Diagramme de cas d’utilisation « Gérer les options »

Le schéma qui se suit représente la gestion des options, comme animaux autorisés ou
pas, WIFI disponible ou pas, bagages autorisés ou pas, fumeurs autorisés ou pas etc, au sein
d’une application ou d’un système par l’administrateur.

Figure 73: Diagramme de cas d’utilisation « Gérer les options »

I.3.5 Diagramme de classe de Sprint n°3

Le diagramme suivant représente les classes et des relations spécifiques développées lors du
troisième sprint du projet.

Figure 74: Diagramme de classe de Sprint n°3

66
 I.3.6 Description textuelle du cas d’utilisation « Ajouter une
annonce »

Dans le contexte de l’application de gestion d’annonces, la description textuelle du cas

d’utilisation « Ajouter une Annonce » décrit comment un conducteur propose un nouveau
trajet.
Cas d’utilisation Ajouter une annonce

Acteur(s) Conducteur

Précondition Conducteur authentifié.

Post-condition L’annonce est ajoutée.

Scénario nominal 1. Le conducteur accède à la page d’ajout d’une

annonce.
2. Le conducteur saisit manuellement ou à partir du
Google Maps le point de départ de covoiturage.
3. Le conducteur saisit manuellement ou à partir du
Google Maps le point d’arrivée (le destination) de
covoiturage.
4. Le conducteur sélectionne la date de covoiturage.
5. Le conducteur sélectionne l’heure de départ.
6. Le conducteur sélectionne le nombre de places
disponibles.
7. Le conducteur saisit le prix.
8. Le conducteur écrit une description sur le
covoiturage (optionnel).
10. Le conducteur ajoute la trajectoire et les arrêts si
y en a (optionnel).
11. Le conducteur sélectionne le(s) option(s) offertes
par cette annonce (défense ou pas de fumer, wifi,
animaux etc..).
12. Le conducteur clique sur le bouton publier.
13. Le conducteur confirme la publication de
l’annonce.

67
 Scénario alternatif 13.1 Le conducteur annule la publication de
l’annonce
Tableau 16: Description textuelle du cas d’utilisation « Ajouter une annonce »

I.3.7 Diagramme de séquence du cas d’utilisation « Ajouter une

annonce »

En se référant aux descriptions textuelles dans la section précédente, nous élaborons un

diagramme de séquence détaillé pour l’ajout d’une annonce.

Figure 75: Diagramme de séquence du cas d’utilisation « Ajouter une annonce »

I.3.8 Description textuelle du cas d’utilisation « Modifier une

annonce »

Dans le contexte de l’application de gestion d’annonces, la description textuelle du cas

d’utilisation « Modifier une Annonce » décrit comment un conducteur peut modifier une
annonce de covoiturage.
Cas d’utilisation Modifier une annonce
Acteur(s) Conducteur
Précondition Conducteur authentifié.

68
 Post-condition L’annonce est modifiée.
Scénario nominal 1. Le conducteur accède à la liste de ses annonces.
2. Le conducteur sélectionne l’annonce qu’il
souhaite modifier.
3. L’interface affiche les informations actuelles de
l’annonce.
4. Le conducteur modifie les informations
nécessaires de l’annonce.
5. Le conducteur clique sur le bouton enregistrer.
6. Le conducteur confirme la modification de
l’annonce.
Scénario alternatif 6.1 Le conducteur annule la modification de
l’annonce
Tableau 17: Description textuelle du cas d’utilisation « Modifier une Annonce »

I.3.9 Diagramme de séquence du cas d’utilisation « Modifier une

annonce »

En se référant aux descriptions textuelles dans la section précédente, nous élaborons un

diagramme de séquence pour du cas d’utilisation « Modifier une Annonce ».

Figure 76:Diagramme de séquence du cas d’utilisation « Modifier une annonce »

69
 I.4 Sprint Review

Pour rendre compte de la mise en œuvre de la gestion des annonces, des options (défense
ou pas de fumer, wifi, animaux etc..), et des commentaires, ces captures d’écran sont fournies
dans la Sprint Review, montrant les fonctionnalités clés mises en place. Ces images illustrent
visuellement les progrès réalisés au cours de ce sprint.

• Les interfaces suivantes sont des captures d’écran qui montrent le tableau de
bord de l’administrateur pour gérer les annonces, les options et les
commentaires, respectivement.

Figure 77: Interface gestion des annonces partie administrateur

Figure 78: Interface gestion des options partie administrateur

70
 Figure 79: Interface gestion des commentaires partie administrateur

• Les interfaces de gestion des annonces pour les utilisateurs sur la partie mobile
fournissent aux utilisateurs les outils nécessaires pour gérer leurs propres annonces ou
interactions avec les annonces sur l’application mobile. Cela inclut la recherche
d’annonces, la consultation des détails des annonces, la publication de l’annonce, et
d’autres fonctionnalités liées aux annonces.

Figure 80: Interfaces gestion des annonces partie mobile

71
 I.5 Rétrospective du Sprint n°3

Dans ce sprint, nous avons réussi à mettre en place la gestion des annonces. Cependant,
nous avons également identifié quelques domaines d’amélioration, notamment en ce qui
concerne la suivie en temps réel de la localisation du covoitureur par le passager, et de la
localisation du passager par le covoitureur.
Ce qui a bien fonctionné Ce qui peut être amélioré Plan d’actions

• Implémentation • Suivie de la • Mise en place d’une solution

réussite des localisation en de localisation en temps
fonctionnalités liées temps réel réel.
aux annonces.
Tableau 18: Rétrospective du Sprint n°3

II. Sprint 4 : Gestion des réclamations

Le quatrième sprint a été consacré à la gestion des réclamations afin de limiter les tentatives de
fraudes et d’assurer la sécurité des utilisateurs pour une bonne expérience de covoiturage.

II.1 Objectif de sprint

L’objectif de ce sprint est d’implémenter des fonctionnalités permettant :

• Aux passagers de signaler des problèmes liés aux annonces ou conducteurs, une
interface conviviale sera mise en place pour faciliter le processus de signalement.
• Enregistrement des réclamations des passagers de manière fiable. En parallèle, un
tableau de bord administratif sera développé pour permettre à l’administrateur de gérer
efficacement ces signalements et de prendre les mesures appropriées pour maintenir un
environnement respectueux et transparent au sein de la plateforme.

II.2 Backlog de Sprint n°4 Gestion des réclamations

Dans ce sprint, nous nous focalisons sur la mise en place de la fonctionnalité

Réclamation. Cette fonctionnalité permet aux utilisateurs de contribuer à un environnement
sécurisé et d’exprimer leurs opinions sur leur expérience globale au sein de la plateforme.

72
 ID Rôle User story Tâches Priorité
En tant que • Sélectionner type de
passager je peux réclamation
19 Passager envoyer une • Envoyer une 1
réclamation réclamation

En tant
qu’administrateur • Consulter une
20 Administrateur je peux consulter réclamation 1
les réclamations

Tableau 19: Backlog de Sprint n°4 Gestion des réclamations

II.3 Conception du Sprint n°4

II.3.1 Diagramme des cas d’utilisation « Gestion des

réclamations »

Les fonctionnalités relatives à la gestion des réclamations au sein de l’application sont

illustrées dans les diagrammes suivants.

Figure 81: Diagrammes de cas d'utilisation « Envoyer une réclamation »

Figure 82: Diagrammes de cas d'utilisation « Consulter la liste des réclamations »

II.3.2 Diagramme de classe de Sprint n°4

Nous illustrerons les différentes classes liées au quatrième sprint du projet.

73
 Figure 83: Diagramme de classe de Sprint n°4

II.3.3 Description textuelle du cas d’utilisation « envoyer une

réclamation »

Ce tableau détaille le cas d’utilisation « Envoyer une réclamation ».

Cas d’utilisation Envoyer une réclamation

Acteur(s) Passager

Précondition Passager authentifié

Post-condition La réclamation est enregistrée

1. Le passager consulte les détails de

l’annonce.
2. Le passager clique sur le bouton
« Signaler ».
3. Une fenêtre contextuelle s’affiche,
Scénario nominal
proposant une liste d’options de réclamation
incluant la possibilité de signaler une
annonce ou un utilisateur.
4. Le passager sélectionne le type de
réclamation souhaitée.

74
 5. Le passager confirme l’envoi de la
réclamation.
6. La réclamation est envoyée à
l’administrateur.

Scénario alternatif 5.1 le passager annule l’envoi de réclamation

Tableau 20: Description textuelle du cas d’utilisation « Envoyer une réclamation »

II.3. 4 Diagramme de séquence du cas d’utilisation du cas

d’utilisation « Envoyer une réclamation »

Ce diagramme de séquence détaille les interactions séquentielles entre passager et le

système lorsqu’il soumet une réclamation.

Figure 84: Diagramme de séquence du cas d’utilisation du cas d’utilisation « Envoyer une
réclamation »

II.4 Sprint Review

La revue de sprint relatif à la gestion des réclamations est illustrée par des captures
d’écran détaillant la mise en place des fonctionnalités liées aux réclamations. Ces images offrent

75
une vue visuelle de la façon dont les utilisateurs peuvent soumettre des réclamations et comment
les administrateurs peuvent gérer ces réclamations de manière efficace.

• La figure ci-dessous représente la gestion des réclamations du côté administrateur.

Figure 85: Interface gestion des réclamations

• Ces interfaces, qui se trouvent dans partie des utilisateurs, permettent d’illustrer l’envoi
d’une réclamation.

Figure 86: Interfaces envoyer une réclamation partie utilisateurs

76
 II.5 Rétrospective du Sprint n°4

Au cours de ce sprint, nous avons introduit un mécanisme de gestion des réclamations

qui a été bien accueilli par le Product Owner. Cependant, nous avons constaté des retards dans
le traitement de certaines réclamations coté administrateur. Pour résoudre ce problème, nous
prévoyons d’améliorer notre système de suivi des réclamations pour une résolution plus rapide.

Ce qui a bien fonctionné Ce qui peut être amélioré Plan d’actions

• Optimisation du système de
• Intégration réussie du
• Temps de traitement lourd suivi des réclamations pour
mécanisme de gestion
des réclamations réduire les délais de
des réclamations
traitement.

Tableau 21: Rétrospective du Sprint n°4

Conclusion
En conclusion de cette deuxième release, la gestion des annonces permet aux
conducteurs de publier et de gérer leurs offres de covoiturage de manière conviviale, alors que
la gestion des réclamations offre aux utilisateurs un moyen simple et efficace pour signaler des
problèmes. Ces fonctionnalités renforcent la confiance des utilisateurs dans notre plateforme,
ce qui est essentiel pour son succès continu. Dans le prochain chapitre, nous explorerons la
troisième release, où nous continuerons à ajouter des fonctionnalités essentielles pour améliorer
encore l’expérience de nos utilisateurs.

77
 Chapitre V : Release 3
Introduction
Dans cette livraison, nous nous concentrons sur la gestion des réservations et le
développement d’un système d’évaluation. Ces fonctionnalités visent à optimiser davantage
l’expérience des utilisateurs, en leur offrant une gestion simplifiée des réservations et la
possibilité d’exprimer leur satisfaction à travers des évaluations.

I. Sprint 5 : Gestion des réservations

Le cinquième sprint a été consacré à la mise en place de Microservice Gestion des

réservations ce sprint vise à faciliter le processus de coordination entre conducteurs et passagers
pour assurer des trajets efficaces et harmonieux.

I.1 Objectif de sprint

L’objectif de ce sprint est de mettre en place un système de gestion des réservations pour
les utilisateurs de la plateforme de covoiturage.

• Les passagers auront la possibilité d’envoyer des demandes de réservation sur

les annonces de covoiturage, en indiquant le nombre de places souhaitées. Ils
pourront également consulter l’état de leurs réservations et annuler une demande
si nécessaire.
• Les conducteurs pourront voir la liste des réservations sur leurs annonces,
accepter ou rejeter les demandes de réservation.

I.2 Backlog de Sprint n°5 Gestion des réservations

Ce Backlog représente une liste de tâches et d’objectifs prioritaires à réaliser lors du

cinquième sprint du projet de gestion des réservations.
ID Rôle User story Tâches Priorité
En tant que
passager je peux • Sélectionner le nombre
réserver des de places à réserver
21 Passager places sur • Confirmer la 1
l’annonce de réservation
trajet
En tant que
conducteur je • Accepter une
22 Conducteur peux accepter réservation 3
une réservation

78
 En tant que
conducteur je
23 Conducteur • Refuser une réservation 3
peux refuser une
réservation
En tant
Conducteur / qu’utilisateur je • Annuler une
24 peux annuler une réservation 5
Passager
réservation
En tant • Récupérer les
qu’administrateur réservations
25 Administrateur je peux consulter • Afficher les 2
les réservations réservations
Tableau 22: Backlog de Sprint n°5 Gestion des réservations

I.3 Conception du Sprint n°5

I.3.1 Diagramme de cas d’utilisation « Gestion des réservations

pour les passagers »

Ce diagramme illustre visuellement les actions que les passagers peuvent entreprendre pour
gérer leurs réservations au sein de l’application ou du système.

Figure 87: Diagramme de cas d'utilisation « Gestion des réservations pour les passagers »

79
 I.3.2 Diagramme de cas d’utilisation « Gestion des réservations
pour les conducteurs »

Les conducteurs peuvent gérer leurs réservations au sein de l’application en réalisant les
actions suivantes.

Figure 88: Diagramme de cas d’utilisation « Gestion des réservations pour les conducteurs »

I.3.3 Diagramme de cas d’utilisation « Consulter la liste des

réservations »

L’administrateur peut consulter la liste des réservations afin de superviser et de gérer

efficacement l’ensemble des réservations effectuées sur la plateforme.

Figure 89: Diagramme de cas d'utilisation « Consulter la liste des réservations »

80
 I.3.4 Diagramme de classe de Sprint n°5

Ce diagramme représente les classes et les relations spécifiques développées lors du

cinquième Sprint du projet.

Figure 90: Diagramme de classe de Sprint n°5

I.3.5 Description textuelle de cas d’utilisation « Demander une

réservation »

La description textuelle suivante explique comment les utilisateurs peuvent initier une
demande de réservation.

Cas d’utilisation Demander une réservation sur une annonce

de covoiturage
Acteur(s) Passager

Précondition Passager authentifié

81
 Post condition Réservation envoyé

Scénario nominal 1. Le passager consulte l’annonce

2. Le passager clique sur bouton réserver
3. Un pop-up contenant le nombre de places
disponibles est affiché
4. Le passager sélectionne le nombre de
places à réserver
5. Le passager confirme l’envoi de la
demande de réservation
6. La réservation est envoyée et elle reste en
attente de confirmation de la part de
conducteur
Scénario alternatif 5.1 Le passager annule l’envoi de la demande
de réservation

Tableau 23: Description textuelle de cas d’utilisation « Demander une réservation »

I.3.6 Diagramme de séquence de cas d’utilisation « Demander

une réservation »

Cette figure illustre chronologiquement les étapes et les interactions entre l’utilisateur
et le système lorsqu’il fait une demande de réservation.

82
 Figure 91: Diagramme de séquence de cas d’utilisation « Demander une réservation »

I.3.7 Description textuelle de cas d’utilisation « Traiter une

demande de réservation »

Cette description textuelle du cas d’utilisation explique comment les utilisateurs peuvent
confirmer une réservation.

Cas d’utilisation Traiter une demande de réservation

Acteur(s) Conducteur

Précondition Conducteur authentifié

Post condition Réservation traitée

83
 Scénario nominal 1. Le conducteur reçoit une notification de
réservation
2. Le conducteur consulte la liste des
réservations reçut
3. Le conducteur clique sur bouton accepter
4. La réservation est acceptée
Scénario alternatif 3.1 Le conducteur clique sur bouton refuser
4.1 La réservation est supprimée

Tableau 24: Description textuelle de cas d’utilisation « Confirmer une réservation »

I.3.8 Diagramme de séquence de cas d’utilisation « Traiter une

demande de réservation »

En utilisant les descriptions textuelles précédemment fournies, nous élaborons un

diagramme de séquence détaillé de traiter une demande de réservation.

Figure 92: Diagramme de séquence de cas d’utilisation «Traiter une demande de réservation»

84
 I.3.9 Description textuelle de cas d’utilisation « Annuler
réservation »

La Description textuelle du cas d’utilisation « Annuler une Réservation » explique les

scénarios comment les utilisateurs peuvent annuler une réservation.

Cas d’utilisation Annuler réservation

Acteur(s) Passager

Précondition Passager authentifié

Post condition Réservation annulée

Scénario nominal 1. Le passager consulte la réservation

2. Si la réservation est en attente
2 .1 Le passager annule la demande de
réservation
2.2 Réservation annulée
2.3 Mises à jour de la liste des réservations
envoyée
3. Si la réservation est confirmée
3 .1 Le passager annule la réservation
3.2 La réservation est annulée
3.3 Mises à jour du nombre des places
libres
3.4 Mises à jour de la liste des réservations
envoyées
Scénario alternatif 1.1 Le passager abandonne l’annulation

Tableau 25: Description textuelle de cas d’utilisation « Annuler réservation »

85
 I.3.10 Diagramme de séquence de cas d’utilisation « Annuler une
réservation »

Ce diagramme décrit les interactions entre l’utilisateur et le système lorsqu’il annule une
réservation.

Figure 93: Diagramme de séquence de cas d'utilisation « Annuler une réservation »

I.4 Sprint Review

Les captures d’écran suivantes de sprint de la gestion des réservations détaillent le

processus complet de réservation au sein de l’application.

86
 Figure 94: Interface gestion des réservations partie web

Figure 95: Interfaces gestion des réservations partie mobile

I.5 Rétrospective du Sprint n°5

Durant ce sprint, nous avons accompli la mise en place du module de gestion des
réservations conformément à la planification. Cependant, nous avons rencontré des défis en
respectant les délais fixés pour certaines fonctionnalités. Pour améliorer notre gestion du temps,
nous prévoyons de mettre en œuvre une approche de planification plus agile et de renforcer la
communication au sein de l’équipe.

87
Ce qui a bien fonctionné Ce qui peut être amélioré Plan d’actions

• Développement • Respect des délais pour • Communication renforcée au

réussi de la gestion des certaines fonctionnalités à sein de l’équipe pour mieux
réservations. améliorer. anticiper les retards potentiels.

Tableau 26: Rétrospective du Sprint n°5

II. Sprint 6 : Evaluation

Le sixième sprint a été consacré à l’évaluation qui permet aux utilisateurs de donner
leurs avis de satisfaction, ce sprint permettra aux utilisateurs de partager leurs retours et d’aider
à maintenir la qualité du service de covoiturage en mettant en avant les expériences positives et
en identifiant les domaines à améliorer.

II.1 Objectif de sprint

L’objectif de ce sprint est de mettre en œuvre un système d’évaluation des expériences
de covoiturage où les utilisateurs pourront :
• Donner leur avis et exprimer leur satisfaction en utilisant une interface
interactive avec des options de notation visuelles telles que des étoiles.

II.2 Backlog de Sprint n°6 Evaluation

Ce Backlog représente l’objectif à réaliser lors du sixième sprint du projet.

ID Rôle User story Tâches Priorité

• Réalisation d’une
interface d’évaluation.
En tant
• Donner avis.
Conducteur / qu’utilisateur je
21 • Calcul de la moyenne 1
Passager peux donner
des notes d’avis.
mon avis
• Affichage les notes
des utilisateurs

Tableau 27: Backlog de Sprint n°6 Evaluation

II.3 Conception du Sprint n°6

II.3.1 Diagramme de cas d’utilisation « Donner avis »

Ce diagramme décrit l’action laisser un avis après une expérience de covoiturage par le
passager.

88
 Figure 96: Diagramme de cas d’utilisation « Donner avis »

II.3.2 Diagramme de classe de Sprint n°6

La figure suivante illustre le diagramme de classes généré pendant le Sprint n°6.

Figure 97: Diagramme de classe de Sprint n°6

II.3.3 Description textuelle du cas d’utilisation « Donner avis »

Cette description textuelle explique comment un utilisateur peut exprimer son feedback
ou son avis sur une expérience de covoiturage.

89
 Cas d’utilisation Donner avis

Acteur(s) Passager

Précondition Passager authentifié.

Post-condition L’avis a été bien enregistré

Scénario nominal 1. Cliquer sur le bouton donner avis

2. L’application affiche une interface
d’évaluation, comprenant un mécanisme
visuel pour attribuer une note (par exemple,
des étoiles).
3. Le passager sélectionne un certain
nombre d’étoiles pour exprimer sa note.
4. Le passager confirme l’envoi de son avis.
5. Le système calcule automatiquement la
moyenne des notes.
6. L’avis est enregistré
3.1 Si le passager choisit de ne pas donner
Scénario alternatif
d’avis, le processus est annulé.
Tableau 28: Description textuelle du cas d’utilisation « Donner avis »

II.3.4 Diagramme de séquence du cas d’utilisation « Donner un

Avis »

En se basant sur la description textuelle précédente on a conçu le diagramme de

séquence suivant :

90
 Figure 98: Diagramme de séquence du cas d’utilisation « Donner un Avis »

II.4 Sprint Review

Les captures d’écran présentées dans la revue de sprint de la gestion des évaluations
illustrent le processus d’évaluation des covoiturages effectués par les utilisateurs et la note
attribuée à l’utilisateur après.

Figure 99: Interfaces des évaluations

91
 II.5 Rétrospective du Sprint n°6

Dans la rétrospective du sprint 6, nous avons introduit la fonction d’évaluation, ce qui a

permis aux utilisateurs de donner leur avis après l’expérience de covoiturage. Bien que toutes
les fonctionnalités aient été réalisées comme prévu, il y avait des lacunes dans la documentation
technique.
Ce qui a bien fonctionné Ce qui peut être amélioré Plan d’actions
• Développement des
• Introduire et suivre la
fonctionnalités prévu
• Documentation technique documentation technique
• Collaboration efficace
dans la planification
entre les équipes
Tableau 29: Rétrospective du Sprint n°6

Conclusion
En conclusion de cette troisième livraison, achevant nos releases, nous avons ajouté des
fonctionnalités capitales à notre plateforme de covoiturage. La gestion des réservations et le
système d’évaluation renforcent l’expérience utilisateur en simplifiant la réservation de trajets
et en favorisant la confiance au sein de notre communauté. Ces ajouts désignent une étape
importante dans notre projet, et nous continuons notre engagement envers l’amélioration
continue de notre application.

92
 Conclusion générale
Dans le cadre de notre projet de fin d‘études réalisé au sein de la société Naxxum, nous
avons conçu une plateforme de covoiturage moderne qui répond aux besoins actuels de mobilité
tout en encourageant des pratiques plus durables. Inspirant de la méthodologie agile Scrum au
niveau de management, le projet a été couronné de succès.

Ce projet a été une opportunité précieuse pour découvrir l'architecture microservices,

l'utilisation d'Azure DevOps et à la collaboration agile.
Nos résultats témoignent de notre réussite dans la réalisation de cette plateforme. Les
utilisateurs peuvent désormais s'authentifier en toute sécurité, gérer leurs profils, créer et
rechercher des annonces de covoiturage, réserver des trajets, signaler des problèmes et évaluer
leurs expériences de voyage.

En termes de perspectives, nous envisageons d'intégrer une couche d'intelligence

artificielle (IA) pour proposer des trajets aux utilisateurs, en utilisant des algorithmes avancés
de recommandation. Cette fonctionnalité améliorera l'expérience des utilisateurs en leur
suggérant des trajets pertinents en temps réel, tout en contribuant à maximiser l'efficacité du
covoiturage.

93
 Webographie
[1] https ://www.appvizer.fr/magazine/operations/gestion-de-projet/scrum : Article sur la
méthode agile Scrum. Consulté en février 2023.
[2] https ://www.qrpinternational.fr/blog/glossaire/quest-ce-quun-backlog-definition-etapes-
caracteristiques-et-
outils/#:~:text=Qui%20est%20responsable%20du%20product,en%20charge%20par%20les%
20d%C3%A9veloppeurs. : Définition Product Owner. Consulté en février 2023.
[3] https ://asana.com/fr/resources/scrum-master : Définition Scrum Master. Consulté en
février 2023.
[4] https ://blog.myagilepartner.fr/index.php/2019/08/02/lequipe-de-developpement-en-
scrum/#:~:text=L’%C3%A9quipe%20de%20d%C3%A9veloppement%20se,de%20d%C3%A
9veloppement%20cr%C3%A9ent%20l’incr%C3%A9ment. : Définition L’équipe de
développement. Consulté en février 2023.
[5] https ://www.advaloris.ch/nos-services/gestion-de-projet/definir-besoins-fonctionnels-
gestion-de-projet. : Article sur les besoins fonctionnels en gestion de projet. Consulté en
février 2023.
[6] https ://www.memoireonline.com/11/12/6484/m_Conception-et-realisation-dune-
application-de-gestion-des-marches-par-appel-doffres-au-sein7.html. : Conception et
réalisation d’une application de gestion des marchés par appel d’offres au sein de l’Entreprise
Tunisienne d’Activités Pétrolières. Consulté en février 2023.
[7] https ://www.ibm.com/docs/fr/rational-soft-arch/9.5?topic=diagrams-use-case : Définition
de diagrammes de cas d’utilisation. Consulté en février 2023.
[8] https ://learn.microsoft.com/fr-fr/azure/devops/user-guide/devops-alm-
overview?view=azure-devops : Documentation officielle d’Azure DevOps Consulté en février
2023.
[9]
https ://visualstudio.microsoft.com/fr/#:~:text=Visual%20Studio%20Code%20est%20un,de%
20JavaScript%2C%20TypeScript%20et%20Node. : Définition Visual Code. Consulté en
février 2023.
[10] https ://learn.microsoft.com/fr-fr/visualstudio/get-started/visual-studio-ide?view=vs-
2022 : Définition Visual Studio Community. Consulté en février 2023.

94
[11]
https://developer.android.com/studio/intro?hl=fr#:~:text=Android%20Studio%20est%20l'envi
ronnement,vous%20cr%C3%A9ez%20des%20applications%20Android. : Définition Android
Studio. Consulté en février 2023.
[12] https://www.lucidchart.com/pages/fr/exemple/logiciel-conception-base-de-
donnees#:~:text=Lucidchart%20est%20une%20application%20de,donn%C3%A9es%20et%2
0bien%20plus%20encore.&text=D%C3%A9couvrez%20pourquoi%20des%20millions%20d,
entier%20font%20confiance%20%C3%A0%20Lucidchart. : Documentation officielle de
Lucidchart Consulté en février 2023.
[13]
https://www.blogdumoderateur.com/tools/figma/#:~:text=Figma%20est%20une%20plateform
e%20collaborative,UX%20designers%20et%20des%20d%C3%A9veloppeurs. :
Documentation officielle de Figma Consulté en février 2023.
[14] https://www.atlassian.com/fr/git/tutorials/git-
bash#:~:text=Qu'est%2Dce%20que%20Git,acronyme%20de%20Bourne%20Again%20Shell.
: Définition de Git Bash Consulté en février 2023.
[15] https://azure.microsoft.com/fr-fr/products/devops : Documentation officielle d’Azure
DevOps Consulté en février 2023
[16] https://sql.sh/sgbd/sql-server : Article sur Microsoft SQL Server Consulté en février
2023
[17] https://learn.microsoft.com/fr-fr/office365/servicedescriptions/teams-service-
description : Documentation officielle de Microsoft Teams Consulté en février 2023
[18] https://www.ionos.fr/digitalguide/sites-internet/developpement-web/uml-un-langage-de-
modelisation-pour-la-programmation-orientee-objet/ : Article sur UML (Unified Modeling
Language) en programmation orientée objet. Consulté en février 2023.
[19] https://learn.microsoft.com/fr-fr/dotnet/core/whats-new/dotnet-7 : Documentation
officielle de Microsoft .NET. Consultée en février 2023.
[20] https://learn.microsoft.com/fr-fr/dotnet/csharp/tour-of-csharp/ : Documentation officielle
C# Consulté en février 2023
[21] https://learn.microsoft.com/fr-fr/dotnet/architecture/microservices/multi-container-
microservice-net-applications/implement-api-gateways-with-ocelot : Documentation officielle
API Gateway « Ocelot » Consulté en février 2023
[22] https://www.rabbitmq.com/documentation.html : Documentation officielle de
RabbitMQ. Consultée en février 2023.

95
[23] https://learn.microsoft.com/fr-fr/azure/architecture/patterns/cqrs : Documentation
officielle de MediatR. Consultée en février 2023.
[24] https://www.redhat.com/fr/topics/containers/what-is-docker : Définition de Docker.
Consulté en mars 2023.
[25] https://www.websiterating.com/fr/web-hosting/glossary/what-is-
mysql/#:~:text=et%20Open%20Source-
,MySQL%20est%20un%20syst%C3%A8me%20de%20gestion%20de%20base%20de%20do
nn%C3%A9es,le%20voir%20et%20le%20modifier. : Article sur MySQL . Consulté en mars
2023.
[26] https://appmaster.io/fr/blog/outils-du-createur-dapi : Article sur Swagger. Consulté en
mars 2023.
[27] https://angular.io/guide/architecture : Documentation officielle d'Angular, le framework
utilisé pour le développement web. Consultée en février 2023.
[28] https://thetribe.io/metier-
typescript/#:~:text=TypeScript%20est%20un%20langage%20de,peut%20%C3%AAtre%20ut
ilis%C3%A9%20avec%20TypeScript). : Article sur TypeScript Consultée en février 2023.
[29] https://www.hostinger.fr/tutoriels/differences-
html#:~:text=HTML5%20est%20la%20derni%C3%A8re%20version%20de%20HTML%20e
t%20prend%20en,l'audio%20et%20la%20vid%C3%A9o.&text=HTML%20ne%20fournit%2
0pas%20de,audio%20et%20de%20la%20vid%C3%A9o. : Article sur HTML 5 Consultée en
février 2023.
[30] https://www.journaldunet.com/web-tech/developpeur/1159810-bootstrap-definition-
tutoriels-astuces-pratiques/. : Article sur Bootstrap Consultée en février 2023.
[31] https://www.websiterating.com/fr/website-builders/glossary/what-is-
css/#:~:text=CSS%20(Cascading%20Style%20Sheets)%20est,aspects%20visuels%20des%20
pages%20Web.. : Article sur Les feuilles de style en cascade (CSS) Consultée en février
2023.
[32] https://docs.flutter.dev : Documentation officielle de Flutter. Consulté en janvier 2023.
[33] https://dart.dev/guides : Documentation officielle de Dart. Consulté en janvier 2023.

[34] https://www.talend.com/fr/resources/guide-microservices/ : Article sur les microservices.

Consulté en février 2023.

96
[35] https://www.adimeo.com/blog/forum-php-2019-clean-architecture : Article sur Clean
Architecture. Consulté en février 2023.
[36] https://medium.com/elp-2018/mediator-design-pattern-ou-comment-%C3%A9viter-le-
code-spaghetti-8cc3dd35388e : Article sur Mediator design pattern. Consulté en février 2023
[37] https://learn.microsoft.com/fr-fr/azure/architecture/patterns/cqrs : Article sur le modèle
CQRS. Consulté en février 2023
[38] https://www.arkance-systems.fr/blog/pattern-
mvvm/#:~:text=Définition,liés%20à%20la%20logique%20métier : Article sur le modèle de
conception MVVM. Consulté en mars 2023.
[39]
https://www.irif.fr/~carton/Enseignement/InterfacesGraphiques/Cours/Swing/mvc.html#:~:te
xt=L%27architecture%20Modèle%2FVue%2F,rôle%20précis%20dans%20l%27interface :
Article sur l'architecture Modèle-Vue-Contrôleur (MVC) en Swing. Consulté en mars 2023.

97
Résumé

Ce travail s’inscrit dans le cadre de notre projet fin d’étude à l’Institut Supérieur des Arts
Multimédia, en vue de l’obtention d’un diplôme en Master Professionnel d’ingénierie des
médias développement web. Ce projet a été réalisé au sein de l’entreprise NAXXUM intitulé
Conception et développement d’une application web/mobile d’un système de co-
voiturage,
L'objectif de notre projet est de concevoir et de développer une solution numérique de pointe
qui permettra aux utilisateurs en quête de covoiturage de trouver des solutions de mobilité
efficaces et durables.
Nous avons mis en œuvre un ensemble de technologies modernes pour garantir une architecture
robuste et évolutive. Nous avons opté pour une architecture microservices pour favoriser la
modularité et la scalabilité de l'application et pour garantir une communication fluide entre ces
derniers, nous avons intégré le message broker RabbitMQ. Nous avons également suivi les
principes de la Clean Architecture pour maintenir un code propre et bien structuré.En outre,
Nous avons mis en place le design pattern CQRS pour séparer les opérations de lecture et
d'écriture. Nous avons aussi utilisé Flutter pour développer une expérience mobile attrayante et
Angular pour la version web, le tout soutenu par le framework .NET Core pour la logique métier
backend.
Cette combinaison de technologies nous a permis de créer un système polyvalent et performant.