Memoire

1
Ecole Supérieure PRivée d’Ingénieurs de Monastir

(ESPRIMS’)
Conception et développement d’une application

mobile pour les échanges de biens et deservices
Encadrant académique :
Ikbel Sayahi
Réalisé par :
Encadrant professionnel :
Faten Hmila
Houssem Abbes
Mohamed Hachem Bouajila
30 juillet 2021
Résumé
Le présent rapport a été élaboré dans le cadre de projet de fin d’études pour l’obtention du diplôme d’ingénieur
en informatique. Le travail est réalisé pendant la période de Février 2021 à Juin 2021.
Ce projet intitulé « Conception et développement d’une application mobile pour les échanges de biens et de
services » et a été réalisé au sein de la société Anypli.
Le projet se décompose en trois parties :
— Back-end : développé en utilisant le framework Laravel dans sa version la plus récente, et MySQL comme
système de gestion de la base de données.
— Dashboard web de gestion pour l’administrateur : développé en utilisant la bibliothèque ReactJs.
— Application mobile iOS : développé en utilisant le langage de programmation Swift dans la version 5.
Au cours de cette période, nous avons essayé d’être fidèle aux exigences mentionnées dans le document de spécifi-
cation.
Mots Clés : Application, Mobile, Dashboard, Php, Laravel, SQL, React, Ios, Swift.
Dédicaces
C’est avec profonde gratitude et sincère mots que je dédie ce modeste travail de fin d’études à mes chers
parents Hamila Khalil et Khamaja Moufida qui ont consacré leurs vies pour assurer ma réussite et m’ont
éclairé le chemin par leurs conseils judicieux. Puisse Dieu, le très haut, vous accorder santé, bonheur et longue
vie et faire en sorte que jamais je ne vous déçoive.
A ma sœur Fatma hamila en témoignage de l’attachement et de l’affection que nous nous portons l’une pour
l’autre, pour son incontournable amour envers moi, sa confiance et son entente.
A mon frère Mohamed son épouse et leurs enfants que Dieu, le tout puissant, vous protège et vous garde.
Je tiens à remercier mes chers amis Ben Ameur Ranim, Bayoudh Marwen pour leurs soutien incessants. A
tous mes collègues pour l’aide mutuelle échangé pendant cette année scolaire.
A tous ceux qui me sont chers...
HAMILA Faten
1
Remerciements
Au terme de mon projet de fin d’études, je tiens à adresser mes plus vifs remerciements à toutes les personnes
qui, de près ou de loin, ont contribué à la réalisation de ce travail dans les meilleures conditions.
Je tiens à exprimer mes remerciements les plus vifs en premier lieu à ceux qui me font l’honneur de participer
et de siéger dans ce jury et être les rapporteurs de ce travail.
J’adresse, tout d’abord, mes sincères remerciements à mon encadrante, à l’école supérieure privée d’ingénieurs
de Monastir (ESPRIMS’), madame Ikbel Sayahi que j’adresse tout mes profonds respects et ma reconnaissance
pour le temps consacré à la lecture et aux réunions qui ont rythmées les étapes de mon projet de fin d’étude. Je
la remercie aussi pour sa disponibilité à encadrer ce travail à travers ses propositions d’amélioration, patience,
ses conseils permanents, ses longues discussions et ses critiques.
Je tiens à remercier sincèrement mes deux encadrants dans la société Anypli Mr. Houssem Abbes et Mr.
Mohamed Hachem Bouajila, pour l’efficacité de leur encadrement, leur soutien immense et la pertinence de
leurs conseils, fruits d’une grande expérience dans le domaine.
Mes remerciements s’adresse aussi à tous les enseignants de l’école supérieure privée d’ingénieurs de Monastir
pour la qualité de formation qu’ils fournissent.
Je remercie enfin tous ceux qui, d’une manière ou d’une autre, ont contribué à la réussite de ce travail.
2
Table des matières
1 Présentation du projet 2
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 Présentation de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2 Activités de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5.1 Netbedloo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5.2 Swouitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.3 TrocWoah . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.4 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 Méthodologie de gestion du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7.1 Choix de la méthodologie : Méthodologie agile . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7.2 La méthodologie SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7.2.1 Les rôles dans SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7.2.2 Les réunions dans SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7.2.3 Les artefacts de communication dans SCRUM . . . . . . . . . . . . . . . . . . . 12
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Analyse et spécification des besoins 13

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Élaboration du Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Analyse globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.2 Diagramme de classes global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 «Étude technique» 21
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Environnement de développement et choix techniques . . . . . . . . . . . . . . . . . . . . . . . . 22
3
3.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2.1 Outils de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2.2 Outil de prototypage et design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2.3 Outils de test des APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2.4 Outil de gestion de base de données . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2.5 Outil de rédaction de rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2.6 Outils de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3 Environnement de développement intégré (IDE) . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.3.1 PhpStorm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.3.2 WebStorm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.3.3 Xcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.4 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.4.1 Langage de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.4.2 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.4.3 Bibliothèques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.2 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Diagramme de déploiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5 Patrons de conception : MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4 Realease 1 : Gestion de l’authentification et des ressources de l’application 36

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Sprint 1 : Gestion d’authentification et profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.1 Spécifications fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.1.1 Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.1.2 Diagramme de cas d’utilisation détaillé du sprint 1 . . . . . . . . . . . . . . . . . 37
4.2.1.3 Diagramme de cas d’utilisation s’authentifier pour l’administrateur . . . . . . . 38
4.2.1.4 Diagramme de cas d’utilisation Créer un compte . . . . . . . . . . . . . . . . . 39
4.2.1.5 Diagramme de cas d’utilisation récupérer le compte . . . . . . . . . . . . . . . . 40
4.2.1.6 Diagramme de cas d’utilisation modifier le profile . . . . . . . . . . . . . . . . . 41
4.2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.2.1 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.2.2 Diagramme de séquence pour le scénario d’authentification . . . . . . . . . . . . 42
4.2.2.3 Diagramme de séquence pour le scénario récupérer le compte . . . . . . . . . . . 43
4.2.2.4 Diagramme de séquence pour le scénario modifier le profil . . . . . . . . . . . . . 44
4.2.2.5 Diagramme d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.2.6 Diagramme d’activité s’authentifier . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2.7 Diagramme d’activité créer un compte . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2.8 Diagramme d’activité modifier le profile . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.2.9 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.3.1 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.3.2 Interfaces d’inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4
4.2.3.3 Interfaces de récupération du mot de passe . . . . . . . . . . . . . . . . . . . . . 50
4.2.3.4 Interface de modifiation du profil . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3 Sprint 2 : Gestion des ressources de l’application et des utilisateurs . . . . . . . . . . . . . . . . . 53
4.3.1.3 Diagramme de cas d’utilisation détaillé de la gestion des utilisateurs . . . . . . . 56
4.3.1.4 Diagramme de cas d’utilisation détaillé de l’ajout d’une catégorie . . . . . . . . 56
4.3.1.5 Diagramme de cas d’utilisation détaillé de la modification d’une catégorie . . . 57
4.3.1.6 Diagramme de cas d’utilisation détaillé de la suppression d’une catégorie . . . . 58
4.3.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.2.2 Diagramme de séquence pour le scénario ajouter catégorie . . . . . . . . . . . . 58
4.3.2.4 Diagramme d’activité ajouter catégorie . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.2.5 Diagramme d’activité modifier catégorie . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.2.6 Diagramme d’activité supprimer catégorie . . . . . . . . . . . . . . . . . . . . . . 61
4.3.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.3.3.1 Interfaces de gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.3.3.2 Interfaces de gestion des catégories . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5 Realease 2 : Gestion des annonces , des avis, des messages et des notifications 65
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2 Sprint 1 : Gérer les annonces et les avis et système de matching . . . . . . . . . . . . . . . . . . . 66
5.2.1.3 Diagramme de cas d’utilisation ajouter une annonce . . . . . . . . . . . . . . . 68
5.2.1.4 Diagramme de cas d’utilisation modifier une annonce . . . . . . . . . . . . . . . 68
5.2.1.5 Diagramme de cas d’utilisation ajouter un avis . . . . . . . . . . . . . . . . . . 69
5.2.1.6 Diagramme de cas d’utilisation éffectuer une recherche . . . . . . . . . . . . . . 70
5.2.1.7 Diagramme de cas d’utilisation vérifier une annonce . . . . . . . . . . . . . . . . 71
5.2.1.8 Diagramme de cas d’utilisation supprimer un avis . . . . . . . . . . . . . . . . . 72
5.2.1.9 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2.1.11 Diagramme de séquence pour le scénario ajouter une annonce . . . . . . . . . . 72
5.2.1.12 Diagramme de séquence pour le scénario rechercher . . . . . . . . . . . . . . . . 73
5.2.1.13 Diagramme de séquence pour le scénario ajouter un avis . . . . . . . . . . . . . 74
5.2.1.14 Diagramme de séquence pour le scénario notifier l’administrateur . . . . . . . . 75
5.2.1.16 Diagramme d’activité ajouter une annonce . . . . . . . . . . . . . . . . . . . . . 76
5.2.1.17 Diagramme d’activité modifier une annonce . . . . . . . . . . . . . . . . . . . . 77
5.2.1.18 Diagramme d’activité ajouter un avis . . . . . . . . . . . . . . . . . . . . . . . . 78
5
5.2.2 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2.2.1 Interface d’ajout d’une annonce . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2.2.2 Interface de modification d’une annonce . . . . . . . . . . . . . . . . . . . . . . . 80
5.2.2.3 Interface de recherche d’annonces . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.2.2.4 Interface de verification d’une annonce . . . . . . . . . . . . . . . . . . . . . . . 81
5.2.2.5 Interface de suppression d’un avis . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.3 Sprint 2 : Envoyer des messages, consulter les recommandations et gérer les statistiques . . . . . 82
5.3.1.3 Diagramme de cas d’utilisation détaillé de l’envoie des messages . . . . . . . . . 84
5.3.1.4 Diagramme de cas d’utilisation détaillé de la consultation des recommandations 85
5.3.1.5 Diagramme de cas d’utilisation détaillé de la gestion des statistiques . . . . . . . 85
5.3.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.3.2.1 Diagramme de séquence pour le scénario gérer les statistiques . . . . . . . . . . . 86
5.3.2.2 Diagramme de séquence pour le scénario envoyer des messages . . . . . . . . . . 87
5.3.2.3 Diagramme d’activité envoyer un message . . . . . . . . . . . . . . . . . . . . . 88
5.3.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3.3.1 Interface d’ajout d’envoie de messages . . . . . . . . . . . . . . . . . . . . . . . . 90
5.3.3.2 Interface de consultation des statistiques . . . . . . . . . . . . . . . . . . . . . . 90
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6
Table des figures
1.1 Logo Anypli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Logo de Netbedloo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Logo de Swouitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Logo de TrocWoah . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Sotution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Schéma descriptif du processus de la méthodologie Agile . . . . . . . . . . . . . . . . . . . . . . . 10
1.7 Cycle de vie de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8 Récapitulatif de la méthodologie Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Diagramme de classes global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1 Logo Draw.io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Logo Adobe XD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Logo Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Logo TablePlus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Logo Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6 Logo Vagrant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.7 Logo Laravel Homestead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.8 Logo MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.9 Logo PhpStorm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.10 Logo WebStorm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.11 Logo Xcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.12 Logo Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.13 Logo Swift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.14 Logo Swift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.15 Logo Laravel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.16 Logo React . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.17 Logo JWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.18 Schéma déscriptif du FCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.19 Schéma déscriptif du FCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.20 Schéma déscriptif des étapes du FCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.21 Logo Swagguer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.22 Architecture 3 tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.23 Architecture logique de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.24 Diagrammme de déploiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.25 Modèle MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7
4.1 Diagramme de cas d’utilisation du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Diagramme de cas d’utilisation s’authentifier de l’administrateur . . . . . . . . . . . . . . . . . . 38
4.3 Diagramme de cas d’utilisation créer un compte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Diagramme de cas d’utilisation s’authentifier de l’utilisateur . . . . . . . . . . . . . . . . . . . . . 40
4.5 Diagramme de cas d’utilisation modifier le profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6 Diagramme de séquence pour le scénario authentification . . . . . . . . . . . . . . . . . . . . . . 43
4.7 Diagramme de séquence pour le scénario récupérer le compte . . . . . . . . . . . . . . . . . . . . 44
4.8 Diagramme de séquence pour le scénario modifier le profile . . . . . . . . . . . . . . . . . . . . . 45
4.9 Diagramme d’activité s’authentifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.10 Diagramme d’activité créer un compte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.11 Diagramme d’activité modifier le profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.12 Diagramme de classe du sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.13 Interface d’authentification de l’administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.14 Interface d’inscription de l’utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.15 Interface de localisation de l’utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.16 Interface de vérification de l’e-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.17 Interface de vérification de code de réinitialisation . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.18 Interface de réinitialisation du mot de passe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.19 Interface de profil de l’utilisateur : section annonces . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.20 Interface de profil de l’utilisateur : section avis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.21 Interface de modification de profil de l’utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.23 Diagramme de cas d’utilisation gérer les utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.24 Diagramme de cas d’utilisation ajouter une catégorie . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.25 Diagramme de cas d’utilisation modifier une catégorie . . . . . . . . . . . . . . . . . . . . . . . . 57
4.26 Diagramme de cas d’utilisation gérer les catégories . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.27 Diagramme de séquence pour le scénario ajouter une catégorie . . . . . . . . . . . . . . . . . . . 59
4.28 Diagramme d’activité ajouter catégorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.29 Diagramme d’activité modifier catégorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.30 Diagramme d’activité supprimer catégorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.31 Diagramme de classe du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.32 Interface des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.33 Interface des détails utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.34 Interface d’ ajout d’une catégorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.35 Interface de modification d’une catégorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.36 Interface de suppression d’une catégorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2 Diagramme de cas d’utilisation ajouter une annonce . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.3 Diagramme de cas d’utilisation modifier une annonce . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4 Diagramme de cas d’utilisation ajouter un avis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5 Diagramme de cas d’utilisation rechercher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.6 Diagramme de cas d’utilisation vérifier une annonce . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.7 Diagramme de cas d’utilisation supprimer un avis . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.8 Diagramme de séquence pour le scénario ajouter une annonce . . . . . . . . . . . . . . . . . . . 73
5.9 Diagramme de séquence pour le scénario rechercher . . . . . . . . . . . . . . . . . . . . . . . . . 74
8
5.10 Diagramme de séquence pour le scénario ajouter un avis . . . . . . . . . . . . . . . . . . . . . . 75
5.11 Diagramme de séquence pour le scénario notifier l’administrateur . . . . . . . . . . . . . . . . . 76
5.12 Diagramme d’activité ajouter une annonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.13 Diagramme d’activité modifier une annonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.14 Diagramme d’activité ajouter un avis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.15 Diagramme de classe du sprint3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.16 Interface d’ajout d’une annonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.17 interface de modification d’une annonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.18 Interface de recherche d’annonces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.19 Interface de verification d’une annonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.20 Interface de suppression d’un avis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.21 Diagramme de cas d’utilisation envoyer des messages, des notifications et des recommandations . 83
5.22 Diagramme de cas d’utilisation envoyer des messages . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.23 Diagramme de cas d’utilisation aconsulter les recommandations . . . . . . . . . . . . . . . . . . . 85
5.24 Diagramme de cas d’utilisation gérer les statistiques . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.25 Diagramme de séquence pour le scénario gérer les statistiques . . . . . . . . . . . . . . . . . . . 87
5.26 Diagramme de séquence pour le scénario envoyer des messages . . . . . . . . . . . . . . . . . . . 88
5.27 Diagramme d’activité envoyer un message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.28 Diagramme de classe du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.29 Interface d’envoie de messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.30 Interface de consultation des statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
9
Liste des tableaux
1.1 Tableau comparatif de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Étude comparative entre les méthodes agiles et les méthodes classiques . . . . . . . . . . . . . . . 9
2.1 Tableau du Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Description textuelle de cas d’utilisation du sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Description textuelle du cas d’utilisation s’authentifier . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Description textuelle du cas d’utilisation créer un compte . . . . . . . . . . . . . . . . . . . . . . 40
4.5 Description textuelle du cas d’utilisation récupérer le compte . . . . . . . . . . . . . . . . . . . . 41
4.6 Description textuelle du cas d’utilisation modifier profile . . . . . . . . . . . . . . . . . . . . . . 42
4.8 Description textuelle du cas d’utilisation du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.9 Description textuelle du cas d’utilisation gérer les utilisateurs . . . . . . . . . . . . . . . . . . . . 56
4.10 Description textuelle du cas d’utilisation ajouter une catégorie . . . . . . . . . . . . . . . . . . . 57
4.11 Description textuelle du cas d’utilisation modifier une catégorie . . . . . . . . . . . . . . . . . . 57
4.12 Description textuelle du cas d’utilisation supprimer une catégorie . . . . . . . . . . . . . . . . . 58

5.2 Description textuelle de cas d’utilisation du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3 Description textuelle du cas d’utilisation ajouter une annonce . . . . . . . . . . . . . . . . . . . 68
5.4 Description textuelle du cas d’utilisation modifier une annonce . . . . . . . . . . . . . . . . . . . 69
5.5 Description textuelle du cas d’utilisation ajouter un avis . . . . . . . . . . . . . . . . . . . . . . 70
5.6 Description textuelle du cas d’utilisation éffectuer une recherche . . . . . . . . . . . . . . . . . . 71
5.7 Description textuelle du cas d’utilisation vérifier une annonce . . . . . . . . . . . . . . . . . . . . 71
5.8 Description textuelle du cas d’utilisation supprimer un avis . . . . . . . . . . . . . . . . . . . . . 72
5.10 Description textuelle de cas d’utilisation du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.11 Description textuelle du cas d’utilisation envoyer des messages . . . . . . . . . . . . . . . . . . . 84
5.12 Description textuelle du cas d’utilisation consulter les recommandations . . . . . . . . . . . . . . 85
5.13 Description textuelle du cas d’utilisation gérer les statistiques . . . . . . . . . . . . . . . . . . . . 86
10
Introduction Générale
Le troc existe depuis que l’homme est apparu sur la Terre. Il a en effet commencé dès qu’un être suffisamment
intelligent a pu comprendre qu’il pouvait échanger un silex contre une peau de bison sans devoir aller le chasser
lui-même... L’origine du troc se confond avec celle de l’homme
L’échange d’objets entre particuliers est une action pratiquée depuis plusieurs siècles et qui s’impose de plus
en plus comme une tendance sociétale forte et durable dans l’univers de la consommation.
L’échange rend la consommation plus responsable, plus éthique. Et contrairement à l’achat-vente, le troc
est complètement gratuit ! Effectivement vous n’avez pas besoin de dégainer votre carte bleue à chaque fois
que vous souhaitez vous faire plaisir ce qui fait que les crises monétaires favorisent la notion de troc puisque
aucune intervention de monnaie n’y parvient. En plus d’obtenir des objets ou de réaliser des projets que certains
n’auraient pas pu acquérir sans cet échange de biens ou de savoir-faire, de créer des relations ou tout simplement
d’établir un contact humain solidaire, l’échange est un acte écologique et économique.
C’est dans ce contexte que s’inscrit notre application. Par le biais de cette dernière, les utilisateurs peuvent
consulter les biens et les services proposés par la communauté, faire des échanges, s’évaluer les uns les autres,
chatter en temps réel ... Etc.
Ce rapport s’articule autour de cinq chapitres comme suit : Le premier chapitre « Présentation du projet »
consiste à présenter l’organisme d’accueil, l’étude de l’existant et sa critique et la présentation de la méthodologie
de travail.
Le second chapitre « Analyse et spécification des besoins » illustre la conception générale de l’application
où on définit nos acteurs et leurs fonctionnalités et les différentes tables formant notre base des données ainsi
que la planification des sprints.
Le troisième chapitre, « Sprint 0 : Etude Technique » présente l’environnement de développement tel que le
choix des outils techniques et des technologies ainsi l’architecture physique et logique de l’application.
Le quatrième chapitre, « Release 1 : Realease 1 : Gestion de l’authentification et des ressources de l’application
» englobe la prenière partie de notre travail.
Le dernier chapitre « Release 2 : Gestion des annonces , des avis, des messages et des notifications » détaille
la deuxième partie de notre travail.
Ce manuscript est clôturé par une conclusion générale.
1
Chapitre 1
Présentation du projet
Contents
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 Présentation de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2 Activités de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5.1 Netbedloo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5.2 Swouitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.3 TrocWoah . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.4 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 Méthodologie de gestion du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7.1 Choix de la méthodologie : Méthodologie agile . . . . . . . . . . . . . . . . . . . . . . 9
1.7.2 La méthodologie SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2
1.1 Introduction
Afin de créer une application d’une manière adéquate et réussie, il est important de passer par la phase de
l’étude préliminaire. Ainsi, ce premier chapitre servira en premier lieu à la présentation du cadre général du
projet et de l’organisme d’accueil au sein du quel nous avons effectué notre stage. Nous présentons par la suite
les solutions existantes en dégageant la problématique correspondante, dont le but de dévoiler les objectifs de
notre travail. Nous allons expliquer à la fin la méthodologie adoptée et les démarches suivies afin de réaliser ce
projet.
1.2 Présentation du projet

Ce projet intitulé « Conception et développement d’une application mobile pour les échanges de biens et de
services » s’englobe dans le cadre d’un projet de fin d’études au sein de l’École Supérieure Privée d’Ingénieurs
de Monastir (ESPRIMS) pour l’obtention du diplôme national d’ingénieur en Génie Informatique et a été réalisé
au sein de la société Anypli.
1.3 Organisme d’accueil

Cette partie comporte la présentation de l’organisme d’accueil ainsi qu’une brève description des activités
de l’équipe dans laquelle nous nous sommes intégrés.
1.3.1 Présentation de la société

Anypli, dont le logo est présenté dans la figure 1.1, est une agence de création d’applications web et mobile
basée en Tunisie et fondée en 2011 par une équipe de jeunes promoteurs. Ses principaux partenaires sont des
grands comptes à l’international pour lesquels elle apporte un savoir-faire de qualité ainsi que des coûts très
attractifs. Composée d’ingénieurs issus des meilleures écoles , ses collaborateurs seront disponibles pour garantir
un niveau de satisfaction maximum.
Figure 1.1 – Logo Anypli
1.3.2 Activités de la société

Les experts chez Anypli assurent les services suivants :
— Développement : Des ingénieurs avec un très haut niveau de compétences en développement mobile et web
vous conseillent dans les choix technologiques et architecturaux de votre plateforme afin de maximiser
les performances tout en restant le plus évolutif possible.
— Déploiement : Au sein d’Anypli la fin de projet n’est que le début d’une nouvelle étape dans laquelle
l’équipe tient à vous accompagner. C’est pourquoi elle s’occupe de la phase de déploiement de votre site
ou de soumission de votre application sur le store.
3
— UI - UX : L’interface graphique (UI) et l’expérience utilisateur (UX) sont les aspects les plus importants
pour les clients. C’est pourquoi les ingénieurs chez Anypli apportent toute leurs expériences et leurs
savoir-faire dans ce domaine pour vous conseiller sur les dernières tendances.
1.4 Problématique
L’échange de produits et de services est un concept qui ne datent pas d’hier. En effet il était déjà utilisé
dans les sociétés primitives, alors que la monnaie n’existait pas encore. Depuis on a renoué avec ce modèle très
utile pendant les périodes de pénurie et de crise.
L’échange, comme son nom le reflète, exige une relation, un lien avec quelqu’un. Naturellement, le troc de
biens se propage donc aux services. Même le petit coup de main est désormais une sorte de monnaie d’échange,
avec la possibilité d’échanger un service contre un autre. Avec le troc, vos affaires deviennent à moi et mes
affaires sont à vous. Donc , afin qu’un troc soit effectué il fallait au moins satisfaire la condition majeure :
L’existence d’un individu avec qui on va pouvoir faire un échange. Pour cela, y’a quoi de mieux que profiter du
moyen le plus populaire et puissant a ce niveau, Internet, pour créer une sorte de réseaux, une communauté de
troqueurs. Internet donne aujourd’hui un nouvel essor à l’échange Il permet de multiplier les contacts entre les
personnes, de génèrer la confiance plus rapidement et surtout faciliter la prise de décision entre inconnus. Une
fois le contact est établi et la négociation est effectuée, l’échange peut avoir lieu dans la vraie vie. C’est le cas
de notre application qui vous permet de consommer autrement, et de consommer mieux.
1.5 Étude de l’existant

L’étude de l’existant est une phase importante pour bien comprendre le système actuel. Elle a pour objectif
d’étudier et de dégager les lacunes des systèmes existants, proposer les solutions adéquates et définir les objectifs
à atteindre au titre de perfectionnement. Il existe deux cas possibles lorsque l’on procède à l’étude de l’existant :
— Soit le produit existe déjà, alors il faut l’améliorer.
— Soit le produit n’existe pas, il faudra donc le créer.
Tout d’abord nous allons présenter un petit résumé descriptif pour chaque application puis un tableau
récapitulatif des fonctionnalitées sera réalisé pour aboutir enfin au choix concernant notre application.
1.5.1 Netbedloo
Développée en 2017 par Naru une startup tunisienne fondée dans la même année par deux jeunes ingénieurs,
Netbedloo est une application dédiée aux échanges gratuit et intelligent de livre et de jeux vidéo. Elle se présente
sous forme web et une application mobile. Dans le but de renforcer la culture du partage et dans un soucis de
donner accès à la culture gratuite à l’ensemble des citoyens, Netbedloo met à la disposition de ses utilisateurs
ses algorithmes d’intelligence artificielle et un ensemble d’outils et de fonctionnalités pour faciliter les opérations
de trocs. Grâces à ses algorithmes intelligent, Netbedloo cherche automatiquement la personne avec laquelle
vous pouvez effectuer un échange et offre tout un réseau social a tous ces membres pour partager leurs passions.
Chaque utilisateur choisit parmi un ensemble illimité de livres et de jeux vidéo, ceux qu’il possède et ceux qu’il
souhaite avoir. Au moment où deux utilisateurs ont des besoins mutuels, Netbedloo les informe par notification
push. Ils pourront par la suite refuser l’échange ou l’accepter puis discuter en privé pour se mettre d’accord sur
les détails du rendez-vous. Les utilisateurs peuvent également ajouter des amis, customiser leurs profils, noter
des livres ou jeux vidéo et donner leurs avis. L’application est gratuite et actuellement disponible seulement en
version Android. La figure 1.2 présente le logo de l’application Netbedloo.
4
Figure 1.2 – Logo de Netbedloo
1.5.2 Swouitch
Swouitch a été mise sur le marché en mars 2015 en France par David Chavanis, son fondateur, et une équipe
de 6 personnes qui mettent chacune à profit leurs expériences et expertises au service de la jeune pousse. En se
basant sur le fonctionnement de Tinder, Swouitch se lance, par analogie, dans la rencontre d’objets. Le principe
est simple , lorsqu’un utilisateur indique son intérêt pour un objet, le propriétaire n’en est pas informé. C’est
seulement quand il y a réciprocité d’intérêts que les deux propriétaires découvrent en même temps la possibilité
d’un échange. Après avoir effectué l’inscription qui est d’ailleurs possible seulement via Facebook, l’utilisateur
prend en photo l’objet qu’il souhaite échanger, choisi la communauté à laquelle il est destiné (enfant, jeune,
homme, femme), détermine sa catégorie, le nomme, le qualifie par une brève description et estime son prix, un
objet en échange est automatiquement proposé. Si l’utilisateur indique son désintérêt a l’objet proposé il sera
remplacé par un autre. L’utilisateur peut modifier les critères de recherche selon la catégorie et la distance des
objets. De plus,l’application offre la possibilité de communiquer et suivre les utilisateurs dont on apprécie les
objets, les univers et de voir en priorité leurs nouvelles mises en ligne. L’application est gratuite et disponible
en version iOS. Le logo et le slogan de l’application sont présentés par la figure 1.3
Figure 1.3 – Logo de Swouitch
5
1.5.3 TrocWoah
Cette application a été crée en novembre 2019 par trois développeurs. TrocWoah propose la solution idéale
pour ne pas dépenser son argent inutilement sur Internet : le troc. En téléchargeant l’application, l’utilisateur
peut découvrir en quelques minutes l’ensemble des produits que les les autres souhaitent échanger contre d’autres
produits ou des services. L’utilisateur peut simplement explorer la carte ou consulter les nombreux biens et
services a proximité en fonction de sa position géographique. La procédure est très simple. Dès qu’il trouve
un bien qui l’intéresse, il suffit de se positionner dessus et de proposer en échange un de ses biens ou de ses
services. Après avoir ouvert un compte le troqueur cré un événement pour que celui-ci apparaisse sur la carte.
Maintenant, il suffit d’attendre pour être contacté très rapidement pour un échange de services en fonction de
sa position géographique. Un système de notation et d’avis est mis en disposition pour développer la confiance
entre les utilisateurs et évaluer en un instant la fiabilité d’un profil. Les utilisateurs ont la possibilité de discuter,
échanger des idées et créer des groupes d’évènements, de faire des propositions, d’ajouter des amis et de créer
également des alertes pour être tenu informé en temps réel. L’application est disponible dans les deux version
iOS et Android comme le montre la figure 1.4
Figure 1.4 – Logo de TrocWoah
1.5.4 Critique de l’existant

Afin de pouvoir créer une application pertinente et innovante nous devons établir une étude comparative
durant laquelle nous extrairons les differents points positifs et négatifs des applications déjà existantes.
Pour l’application Netbedloo sont défaut majeur c’est l’inexistence d’échange de services et les catégories qui
sont restraintes a seulement livres et jeux vidéo. En plus aucune opération de recherche ne peut être effectuée.
En ce qui concerne Swouitch on trouve aussi le même défault concernant l’inexistence des services, a qui
s’ajoute une deuxième faille qui est l’inscription qui est possible seulement via Facebook.
Dans le cas de TrocWoah, les faiblesses citées auparavant ne sont pas présentes, mais on ne trouve ni un
système de recommendation ni de matching d’ou le manque d’originalité dans l’application.
Le tableau 1.1 présente en détails cette étude basée sur les fonctionnalités qui nous semblent essentielles
pour ce type de service ( Création de compte, Échange de biens, Échange de services, Catégories existantes,
Recherche, Recommandation, Réception de notifications, Envoie de messages, Publication d’avis, Existance de
matching, Disponibilité ).
6
Table 1.1 – Tableau comparatif de l’existant
Application Netbedloo Swouitch TrocWoah

Oui (seulement via Face-
Création de compte Oui Oui
book)
Échange de biens Oui Oui Oui
Échange de services Non Non Oui
Uniquement livres et jeux
Catégories existantes Toutes les catégories Toutes les catégories
vidéo
Possibilité de re- Oui (Facteur : catégorie (Facteur : catégorie et
Non
cherche et distance) distance)
Publication d’avis Oui Oui Oui
Réception de notifica-
Oui Oui Oui
tions
Envoie de messages Oui Oui Oui
Réception de recom- Oui (Facteur : valeur es-
Nom Non
mandations timée)
Oui (Facteur : j’aime mu-
Existance de matching Oui (Facteur : nom) Non
tuel)
Version disponible Web et Android iOS iOS et Android
1.6 Solution proposée

Partant de cette étude comparative, nous pouvons noter que ces applications apportent beaucoup d’avantages
mais aussi chacune a son point faible. Pour remédier à ces lacunes nous allons combiner les points fort de ces
applications tout en apportant une amélioration avec un système de correspondance propre à nous. La société
ANYPLI nous a demandé de créer deux applications, une application mobile destinée aux utilisateurs et une
autre application web ayant pour objectif la gestions des différentes ressources. Notre application sera dédiée à la
fois pour les biens et les services. Nous trouverons une multitude de catégories pour assurer que chaque internaute
trouve son bonheur, avec la possibilité de recherche parmi ces catégories. Aucune restriction d’utilisation n’est
imposée. L’utilisateur peut créer un compte en utilisant une adresse e-mail et un mot de passe. Nous offrirons
notamment le service de notification pour alerter l’utilisateur suite a une correspondance entre objets, le service
de messagerie entre les utilisateurs qui sera utile pour planifier le rendez-vous d’échange, et l’évaluation pour
développer la confiance entre les troqueurs et assurer la fiabilité d’un profil. Le petit détail final qui parfait
notre application est le système de recommandation qui sera basé sur les étiquettes que l’utilisateur inclut dans
son annonce. Cette solution consiste à développer un système informatique composé de :
— Application mobile : permet aux utilisateurs de consulter et publier des annonces d’échange, de recevoir
des notifications et des recommandations, de s’envoyer des messages.
— Application web : permet a l’administrateur de gérer les utilisateurss et les annonces , les différentes
catégories, sous-catégories et étiquettes et de consulter les statistiques ce qui se résume dans la figure 1.5
7
Figure 1.5 – Sotution proposée
1.7 Méthodologie de gestion du projet

La phase de choix d’une méthodologie pour le projet est une étape cruciale pour garantir une application
avec une qualité irréprochable. Le choix parmis tous les modèles de processus de développement dépend de la
nature du projet et de sa taille. Lorsqu’il s’agit d’un projet où les données ne sont pas réunies dès le départ
ou les besoins sont incomplets voire floues, il recommandé de s’orienter vers une méthode itérative ou orientée
prototypes.
Le tableau 1.2 présente une étude comparative entre les méthodologies agiles et les méthodologies classiques.
8
Table 1.2 – Étude comparative entre les méthodes agiles et les méthodes classiques
Thème Approche traditionnelle Approche agile

En cascade ou en V, sans rétroaction
Cycle de vie Itératif et incrémental
possible, phases séquentielles
Échelle des projets Grande échelle Petite et moyenne échelle
Le modèle traditionnel favorise l’anti-
Préférence de modèle Le modèle agile favorise l’adaptation
cipation
Adaptative avec plusieurs niveaux de
Prédictive, caractérisée par des plans
planification(macro- et microplanifica-
plus ou moins détaillés sur la base
Planification tion) avec ajustements si nécessaires
d’un périmètre et d’exigences définies
au fil de l’eau en fonction des change-
et stables au début du projet.
ments survenus.
Les clients sont impliqués au début du
Les clients sont impliqués dès l’exécu-
Implication des clients projet mais pas une fois l’exécution
tion du travail
commencée
Produite en quantité importante Réduite au strict nécessaire au profit
Documentation comme support de communication, d’incréments fonctionnels opération-
de validation et de contractualisation nels pour obtenir le feedback du client.
Une équipe responsabilisée où l’initia-
Une équipe avec des ressources spécia-
Équipe tive et la communication sont privilé-
lisées, dirigées par un chef de project.
gées, soutenue par le chef de projet.
Un contrôle qualité précoce et perma-
Contrôle qualité à la fin du cycle de
nent, au niveau du produit et du pro-
Qualité développement. Le client découvre le
cessus. Le client visualise les résultats
produit fini.
tôt et fréquemment.
1.7.1 Choix de la méthodologie : Méthodologie agile

Une équipe de développement logiciel a un seul et simple objectif qui est la satisfaction des besoins de ses
clients. Cependant, ces besoins sont généralement mal exprimés et surtout ils sont souvent incomplets au début
du projet et ne cessent d’évoluer. De ce fait, l’équipe se trouve en train de développer des applications avec
des spécifications non précises et changeantes, ce qui cause soit la non satisfaction des clients, soit les retards
de livraison. Ces problématiques ont poussé les ingénieurs à réinventer les méthodes de gestion de projet et de
conception en introduisant ce que nous appelons la méthode agile.
"Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif,
avec juste ce qu’il faut de formalisme. Elle génère un produit de haute qualité tout en prenant en compte
l’évolution des besoins des clients. (Messager, 2007)."
En décidant d’adapter une méthode agile pour la conduite de notre projet, nous allons le découper en
plusieurs itérations de durée relativement courte et aboutissant chacune à un sous objectif. A la fin de chaque
itération, une version minimale du projet est développée et livrée. Ceci permettra d’avoir toujours un feedback
immédiat qui garantira une adaptation efficace aux changements des exigences et une validation de la version
finale du logiciel qui n’est que l’intégration continue des différentes versions successives. Plusieurs méthodologies
respectent les principes agiles tout en répondant chacune à certains types de projets selon leurs tailles, l’équipe
de développement, la criticité du système, etc.... Donc il ne s’agit pas de choisir la meilleure méthode parmi celles
existantes mais plutot la meilleur adaptée a notre projet Pour cela, il a été convenu d’adopter la méthodologie
SCRUM.
La figure 1.6 détaille le processus de la méthodologie Agile.
9
Figure 1.6 – Schéma descriptif du processus de la méthodologie Agile
1.7.2 La méthodologie SCRUM

Scrum est une méthodologie de développement agile utilisée dans le développement de logiciels basés sur
des processus itératifs et incrémentaux L’objectif principal de Scrum est de satisfaire les besoins du client par
le biais d’un environnement de transparence dans la communication, de responsabilité collective et de progrès
continu.
Scrum permet à une équipe de collaborer efficacement dans le but de développer un produit de meilleure
qualité tout en respectant les délais. Le développement commence à partir d’une idée générale de ce qui doit être
construit, en élaborant une liste de caractéristiques classées par priorité (product backlog) que le propriétaire
du produit veut obtenir.
L’élaboration du produit final se fait en plusieurs itérations nommées « Sprint » d’une durée de 2 à 4
semaines. Durant chacune de ces itérations, une partie du produit nommée « Incrément » est réalisée en se
basant sur les parties crées lors des itérations précedentes, et livrées a` la fin du Sprint. Ceci permet à l’équipe
de répondre à la rétroaction et au changement, pour construire exactement et seulement ce qui est nécessaire
pour le client.
Scrum synthétise un processus présenté par la figure 1.7 et reposant sur :
• Les capacités des membres de l’équipe à faire preuve de créativité, d’interaction efficace et de développement
interne.
• Un cycle itératif et incrémental, de développement du logiciel.
• Des rôles, des artefacts de communication et des réunions.
10
Figure 1.7 – Cycle de vie de SCRUM
1.7.2.1 Les rôles dans SCRUM
Dans la méthodologie SCRUM, les trois rôles principaux qui interviennent sont :
• Scrum Master (Monsieur ABBES Houssem) : La personne qui dirige l’équipe en la guidant pour qu’elle se
conforme aux règles et aux processus de la méthodologie. Il veille à ce que chacun puisse donner le maximum
de ses capacités en éliminant les obstacles et en protégeant l’équipe des perturbations extérieures. Il travaille
avec le Product Owner pour maximiser le retour sur investissement. Le Scrum Master est chargé de maintenir
Scrum à jour, de fournir un encadrement, un mentorat et une formation aux équipes en cas de besoin C’est un
véritable facilitateur sur le projet.
• Product owner (Monsieur BOUAJILA Mohamed Hachem) : dans la majorité des projets, c’est le respon-
sable de l’équipe projet client. Il est le responsable produit (Product Owner). C’est lui qui a pour mission de
prioriser et définir la liste des fonctionnalités du produit et planifier la date et le contenu de chaque sprint sur
la base des valeurs qui lui sont communiquées par l’équipe.
• Équipe (HAMILA Faten) : Ce sont les membres responsable au développement du projet en réalisant
les stories auxquelles ils s’engagent au début de chaque sprint.. Ils s’organisent eux-même, ils ne changent pas
durant un sprint. Tous leurs efforts doivent être centralisés sur la livraison du produit.
1.7.2.2 Les réunions dans SCRUM
La vie d’un projet Scrum se déroule suivant un ensemble de réunions qui sont clairement définies et limitées
dans le temps (timeboxing) :
1. Sprint (Sprint = itération) : Le Timeboxing est utilisé pour définir la longueur du Sprint. Le Sprint est
une boiˆte de temps allant jusqu’a un mois dans laquelle l’équipe de mêlée livrera les buts du Sprint.
2. Planification du sprint (Sprint Planning) : Au cours de cette réunion, l’équipe de développement sélectionne
les éléments prioritaires du « Product Backlog » qu’elle pense pouvoir réaliser durant un sprint (en collaboration
avec le « Product Owner »).
3. La mêlée quotidienne (Daily Scrum) : C’est une réunion de 15 minutes pour chaque période de 24 heures
(elle est aussi appelée "stand up meeting") qui aide l’équipe de mêlée a` synchroniser les activités et à rendre
visible tout obstacle pour l’atteinte de l’objectif du sprint. Chacun répond principalement à 3 questions : «
Qu’est ce que j’ai fait depuis la dernière mêlée ? Qu’est ce que j’aurai accompli d’ici la prochaine mêlée ? Quels
obstacles me retardent ? ».
11
4. La revue du sprint (Sprint Review) : Ayant lieu à la fin du sprint, au cours de cette réunion l’équipe
de développement présente les fonctionnalités terminées au cours du sprint et recueille les retours du Product
Owner et des utilisateurs finaux. C’est également le moment pour anticiper le périmètre des prochains sprints
et d’ajuster au besoin la planification de release (nombre de sprints restants).
5. La rétrospective du Sprint (Sprint Retrospective) : La rétrospective qui est l’occasion de s’améliorer
(productivité, qualité, efficacité, conditions de travail, etc) en prenant comme référence le sprint écoulé (principe
d’amélioration continue). Elle permet à l’équipe de se concentrer sur sa performance globale et d’identifier des
stratégies d’amélioration continue. Elle a généralement lieu après la revue de sprint.
1.7.2.3 Les artefacts de communication dans SCRUM
Les artefacts Scrum sont des composants permettant de faire fonctionner le cadre de travail Scrum, tout en
respectant les principes et les pratiques de l’agilité. Au nombre de 3, ils regroupent
• Backlog du produit : présente une liste de fonctionnalités demandées nommées « User Stories » ou « Récits
utilisateur », classées par priorité. On associe a chaque élément de la liste des attributs tels qu’ un ordre de
priorité ,une description, une estimation...
• Backlog du sprint : présente une sélection de tâches retenues du « Backlog du produit » que l’équipe
s’engage à réaliser pendant un sprint en tenant compte des priorités et de sa capacité.
• Increment du produit : présente la première étape concrète vers le Product Goal. Il englobe l’ensemble
des éléments terminé du sprint en cours mais aussi de ceux déjà finalisé dans les sprint précédents. Il four-
nit principalement de la valeur aux parties prenantes. Ainsi tout ce qui est dans l’incrément est utilisable et
potentiellement livrable en production.
la figure 1.8 résume les catactéristiques de la méthodologie Scrum
Figure 1.8 – Récapitulatif de la méthodologie Scrum
1.8 Conclusion
Dans ce chapitre, nous avons commencé par la présentation du cadre général du projet où nous avons présenté
l’entreprise d’accueil. Ensuite nous avons dégagé la problématique à travers l’étude des applications d’échange
existantes sur le marché, ce qui nous a permis d’avoir une vue synthétique sur leurs caractéristiques afin de
créer une solution qui répondait au mieux aux besoins des utilisateurs, ce que nous allons bien détailler dans le
prochain chapitre. Enfin, nous avons choisi la méthodologie qui sera utilisée tout au long du projet.
12
Chapitre 2
Analyse et spécification des besoins
Contents
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Élaboration du Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Analyse globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.2 Diagramme de classes global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13
2.1 Introduction
L’analyse des exigences et la spécification des besoins est une étape indispensable dans le cycle de dévelop-
pement d’un logiciel. Elle représente le fondement de la planification des itérations et des objectifs de chacune
d’entre elles. Cette étude vise en général à faciliter le processus de conception et de développement d’applications
informatiques. Dans ce chapitre, nous exposons la phase d’analyse du projet dont nous identifions tout d’abord,
les acteurs principaux et leurs besoins. Ensuite, nous allons définir le Backlog de produit et la planification des
sprints. Enfin, nous allons clôturer le chapitre par une modélisation globale du projet.
2.2 Analyse des besoins

L’analyse des besoins a pour but l’identification des exigences du projet et faire le point sur les éléments
attendus. Il s’agit de mettre le projet dans son contexte et d’analyser les attentes pour donner un cadre au
projet. Nous présentons dans ce qui suit les utilisateurs de notre application ainsi que les besoins fonctionnels
et non fonctionnels.
2.2.1 Identification des acteurs

Nous énumérons les acteurs susceptibles d’interagir avec le système. Tout d’abord, nous commençons par
définir ce qui est un acteur. Un acteur est une entité externe au système. Il représente une personne ou un autre
système informatique qui attend un ou plusieurs services offerts par une interface d’accès. Il interagit avec le
système par envoi ou réception des messages. Les acteurs qui vont interagir avec notre système sont :
• L’utilisateur : c’est la personne qui a l’accès a l’application mobile où il peut consulter et publier des
annonces.
• L’administrateur : c’est la personne qui maintient l’accès pour le back office de gestion de l’application.
2.2.2 Les besoins fonctionnels

Il s’agit des fonctionnalités du système. Ce sont les besoins spécifiant un comportement ou une action que doit
effectuer le système en réponse à une demande. Dans cette partie, nous exprimons les exigences qui concernent
le comportement de notre application. En fait pour assurer la qualité du service offert, notre application doit
offrir ces différentes fonctionnalités pour les utilisateurs auxquels elle est dédiée. Le projet comporte deux parties
Première partie : Dashboard de gestion ou l’administrateur est amené a :
• Gérer les comptes des utilisateurs : l’administrateur peut lister les utilisateurs et consulter leurs informa-
tions.
• Gérer les annonces : l’administrateur peut lister toutes les annonces et consulter leurs détails, les vérifier
et changer leur visibilité.
• Gérer les catégories des annonces : l’administrateur peut lister les catégories, ajouter modifier et supprimer
une catégorie.
• Gérer les sous-catégories des annonces : l’administrateur peut lister les sous-catégories, ajouter, modifier
et supprimer une sous-catégorie.
• Gérer les étiquettes des annonces : l’administrateur peut lister les étiquettes, ajouter, modifier et supprimer
une étiquette. • Gérer les avis : l’administrateur peut lister les avis et supprimer un avis.
• Recevoir des notifications : l’administrateur peut recevoir des notifications suite à l’ajout d’une nouvelle
annonce.
• Consulter les statistiques : l’administrateur peut consulter les statistiques de l’application. exemple : le
nombre total des utilisateurs inscrits par jour, le nombre d’annonces publiées par jour ..etc
- Deuxième partie : application mobile iOS ou l’utilisateur peut :
14
• S’inscrire : l’utilisateur doit créer un compte avec un nom, un email et un mot de passe pour pouvoir
ajouter des annonces.
• Récupérer le compte : l’utilisateur peut récupérer son compte en cas d’oubli du mot de passe.
• S’authentifier : pour bénéficier des fonctionnalités de l’applications, le client doit s’authentifier d’abord
avec son email et son mot de passe.
• Gérer le profil : l’utilisateur peut gérer ses informations personnelles : il peut modifier son nom d’utilisateur,
son email et son mot de passe. Il peut également changer sa photo de profil et son addresse.
• Gérer les annonces : l’utilisateur peut consulter les biens et les services proposés par la communauté. Il
peut ajouter, modifier une annonce et même ajouter une étiquette si cette dernière n’existe pas déjà.
• Consulter les profils : l’utilisateur peut visiter les profils des autres utilisateurs pour vérifier les avis.
• Évaluer des utilisateurs : l’utilisateur peut évaluer l’utilisateur avec lequel un échange a été éffectué.
• Envoyer des messages : L’utilisateur peut chatter en temps réel avec un ou plusieurs utilisateurs.
• Recevoir des recommandations : l’utilisateur peut consulter les annonces recommandées par le système.
2.2.3 Les besoins non fonctionnels

Les besoins non-fonctionnels concernent les contraintes à prendre en considération pour garantir le bon
fonctionnement de l’application et mettre en place une solution adéquate aux attentes des utilisateurs. Ces
spécifications sont les suivantes :
• La performance : il s’agit d’optimiser le temps de chargements des données par l’utilisation des bonnes
pratiques du développement et les frameworks convenables.
• L’extensibilité : l’application doit être extensible, c’est-à dire la possibilité d’ajouter de nouvelles fonction-
nalités ou de faire des mises à jour pour assurer l’évolution et la maintenance, ce qui résulte de l’utilisation de
la méthodologie Scrum et d’une architecture basée sur les repositories.
• La sécurité : l’application doit répondre à toutes les exigences des internautes en termes d’intégrité et de
confidentialité des données d’où l’utilisation des JSON web token (JWT). Ainsi l’accès aux informations est
impossible sans vérification des privilèges.
• La convivialité : l’application doit fournir des interfaces ergonomiques, simples et facile à utiliser afin de
garantir une meilleure expérience utilisateur la raison pour laquelle nous avons suivi une charte graphique.
2.3 Élaboration du Backlog produit

Le Backlog produit est l’artefact le plus important de Scrum, c’est l’ensemble des caractéristiques fonction-
nelles ou techniques qui constituent le produit souhaité. Il représente l’unique source du travail effectué par
l’équipe Scrum. Les caractéristiques fonctionnelles sont appelées des histoires utilisateurs (user story) et les
caractéristiques techniques sont appelées des histoires techniques (technical story).
Le tableau 2.1 représente le backlog produit de notre application :
15
16
17
Table 2.1 – Tableau du Backlog produit
2.4 Planification des sprints

La structuration d’un projet consiste à le diviser en différents lots d’activités pour avoir non seulement
une vision globale de comment ce travail sera effectué, mais aussi des sous-parties dont la complexité est plus
facilement maîtrisable. Le but de la planification des sprints est de définir ce qui peut être livré pendant un
sprint et comment ce travail sera effectué. La planification des sprints se fait en collaboration avec l’ensemble
de l’équipe Scrum. Pour notre projet, nous présentons trois releases.
Le tableau 2.2 résume notre planning du travail.
Table 2.2 – Planification des sprints
Thème Release 1 Release 2

Gestion des categories, sous-categories,
Sprint1 Gestion d’authentification et du profil
etiquettes et utilisateurs
Gestion des annonces, des avis et la Gestion des messages, notifications et
Sprint 2
recherche statistiques
2.5 Analyse globale

Les fonctionnalités mentionnées précédemment dans la table 2.1 seront présentées dans la partie qui suit par
un diagramme de cas d’utilisation global et un diagramme de classes global. Reconnu comme étant le standard
industriel par excellence de la modélisation objet, nous avons opté pour le langage de modélisation UML. Cette
illustration permettra de mieux structurer les interactions entre les acteurs et le système.
18
2.5.1 Diagramme de cas d’utilisation global
À ce niveau, nous pouvons représenter les différents cas d’utilisation d’une façon générale pour les utilisateurs
de l’application. Les différents cas d’utilisations sont représentés par la figure 2.1
Figure 2.1 – Diagramme de cas d’utilisation global
2.5.2 Diagramme de classes global

Le diagramme de classes permet d’identifier les différentes structures d’un système avec les différentes pro-
priétés et méthodes de chaque classe. Alors que le diagramme de cas d’utilisation montre un système du point de
vue des acteurs, le diagramme de classes en montre la structure interne. Il permet de fournir une représentation
abstraite des objets du système qui vont interagir pour réaliser les cas d’utilisation. Il est important de noter
qu’un même objet peut très bien intervenir dans la réalisation de plusieurs cas d’utilisation. Les cas d’utilisation
19
ne réalisent donc pas une partition des classes du diagramme de classes. Un diagramme de classes n’est donc
pas adapté (sauf cas particulier) pour détailler, décomposer, ou illustrer la réalisation d’un cas d’utilisation
particulier. La figure 2.2 présente le diagramme de classes global de notre application.
Figure 2.2 – Diagramme de classes global
2.6 Conclusion
Ce chapitre nous a permis de bien délimiter le projet et d’avoir une vision plus claire sur le sujet. Nous
avons commencé par identifier les acteurs du système, énumérer les besoins fonctionnels, non fonctionnels, et le
Backlog produit. Ensuite, nous avons passé à la planification et l’organisation du temps consacré à la réalisation
du projet en identifiant les sprints. Puis, nous avons présenté le diagramme de cas d’utilisation global et le
diagramme de classes global. Dans le chapitre suivant, nous allons identifier l’étude technique du projet.
20
Chapitre 3
«Étude technique»
Contents
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Environnement de développement et choix techniques . . . . . . . . . . . . . . . . 22
3.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.3 Environnement de développement intégré (IDE) . . . . . . . . . . . . . . . . . . . . . 25
3.2.4 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.2 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Diagramme de déploiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5 Patrons de conception : MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
21
3.1 Introduction
Après avoir présenté le cadre général de notre projet, nous dédions ce chapitre a l’élaboration de l’étude
technique. Nous commencons par décrire l’environnement de développement de l’application en présentant les
différents technologies et Framework utilisés, et nous finirons par exposer l’architecture de notre système.
3.2 Environnement de développement et choix techniques

Après avoir effectué une analyse des besoins du projet, nous allons définir l’environnement de travail et les
choix techniques pour aboutir a la réalisation de notre système. Cette section est dédiée à la présentation de
l’environnement matériel et logiciel utilisé lors de l’élaboration de ce travail
3.2.1 Environnement matériel

Ce travail est réalisé avec un ordinateur MacBook Air dont les caractéristiques sont les suivantes :
• Processeur : Intel Core i5 Dual-Core 1.8 GHz
• Mémoire : 4 Go
• Disque dur : 128 Go
• Système d’exploitation : macOS Catalina Version 10.15.6
3.2.2 Environnement logiciel

Dans cette partie, nous présentons les outils de conception et de prototypage, les technologies et les envi-
ronnements, ainsi les framework de développement utilisés pour la réalisation du projet. Enfin, nous exposerons
l’architecture de notre système.
3.2.2.1 Outils de conception
Draw.io dont le logo est présenté par la figure 3.1 est une application en ligne, accessible via son navigateur
permettant de dessiner des diagrammes ou des organigrammes. Cet outil nous propose de concevoir des dia-
grammes de modélisation UML (Unified Modeling Language) de dessins vectoriels, et toutes autres sortes de
diagrammes et de les enregistrer au format XML puis de les exporter. Il constitue une excellente option pour
une familiarisation à la modélisation.
Figure 3.1 – Logo Draw.io
3.2.2.2 Outil de prototypage et design
Adobe XD, dont le logo est présenté par la figure 3.2 est un logiciel de réalisation de prototypes d’applications
ou de sites web qui permet d’avoir un visuel, une maquette, même si l’application ou le site n’existe pas en vrai.
C’est un outil parfait pour montrer aux collaborateurs, clients à quoi va ressembler le produit fini. Ensuite,
22
débute le réalisation avec le codage ou le design pour concrétiser le projet. En ce qui concerne le design, adobe
XD vous offre la possibilité de concevoir les interfaces graphiques avec des composants réel (comme si vous etes
vraiment sur un device ou un navigateur)
Figure 3.2 – Logo Adobe XD
3.2.2.3 Outils de test des APIs
Postman, dont le logo est présenté par la figure 3.3 est un outil pour tester, vérifier une API. Postmanexiste en
deux versions : une application in browser et une application packagée, toutes deux pour Chrome. Les fonction-
nalités sont proches mais pas strictement identiques. Une fois Postman installé, on dispose d’un environnement
graphique complet pour gérer l’ensemble des interactions avec nos API Web. Postman propose les collections : Il
est ainsi possible d’organiser les requêtes en groupes, elles-mêmes pouvant bénéficier de répertoires pour faciliter
la navigation en cas de grand nombre de requêtes. Postman couvre aussi la gestion d’environnements. Dans ce
cas, les éléments pourront être variabilisés et ainsi permettre de garder un même ensemble logique de requêtes,
alimentées de ces éléments sur simple sélection de l’environnement souhaité.
Figure 3.3 – Logo Postman
3.2.2.4 Outil de gestion de base de données
TablePlus, dont le logo est présenté par la figure 3.4 est un outil graphique très récent, puissant et convivial
dans le domaine des logiciels permettant de visualiser et gérer des bases de données relationnelles. Se caracté-
risant d’une interface facile à utiliser et d’une apparence apaisante , ce logiciel offre rapidité et simplicité sans
avoir a sacrifier la puissance ou le contrôle. De plus, une large gamme de raccourcis clavier est présente pour
aider son utilisateur à condenser ses tâches. Conçu pour gérer les formats SQL les plus courants, dont MySQL,
SQLite et PostgreSQL. TablePlus est extensible, permettant d’ajouter de nouveaux plugins et pilotes lorsqu’ils
sont nécessaires. Léger et minimal, il intègre pourtant la flexibilité et la performance nécessaires afin de répondre
à tous les défis.
23
Figure 3.4 – Logo TablePlus
3.2.2.5 Outil de rédaction de rapport
Overleaf, dont le logo est présenté par la figure 3.5 est un éditeur LaTeX collaboratif basé sur le cloud utilisé
pour la rédaction,l’édition et la publication de documents scientifiques. Il s’associe à un large éventail d’éditeurs
scientifiques pour fournir des modèles LaTeX officiels et des liens de soumission directe.
Figure 3.5 – Logo Overleaf
3.2.2.6 Outils de développement
— Vagrant
Vagrant, dont le logo est présenté par la figure 3.6 est un outil qui permet la création des machines virtuelles
pendant le développement d’une application pour obtenir l’environnement désiré sans pour autant changer la
configuration de la machine. Il permet d’automatiser le processus d’installation et configuration de la machine
virtuelle. L’objectif est de pouvoir travailler, en développement, dans le même environnement qu’en production
ou en staging. Vagrant fournit un client de ligne de commande simple et facile à utiliser pour gérer ces envi-
ronnements ainsi qu’un interpréteur pour les définitions des configurations qui sont rassemblés dans un fichier
spécial appelé Vagrantfile.
Figure 3.6 – Logo Vagrant
— Laravel Homestead
Laravel Homestead, dont le logo est présenté par la figure 3.7 est une "box" Vagrant officiel et pré-emballé qui
vous offre un merveilleux environnement de développement sans avoir à installer PHP, HHVM, un server Web
et tout autre logiciel sur votre machine local. Homestead fonctionne sur n’importe quel ordinateur Windows,
24
Mac et Linux, et inclus un serveur web Nginx, PHP 7, MySQL, Postgres, Redis, Memcached et tous les autres
outils dont nous aurons besoin pour développer nottre application.
Figure 3.7 – Logo Laravel Homestead
— MySQL
MySQL, dont le logo est présenté par la figure 3.8 est un système de gestion de base de données (SGBD). Son
rôle est d’enregistrer des données de manière organisée et cohérente afin de vous aider à les retrouver facilement
plus tard. MySQl dérive directement de SQL (Structred Query Language) qui est un langage de requeˆte vers les
bases de donneés exploitant le mode`le relationnel. MySQL, selon le type de l’application, sa licence est libre
ou proprie´taire. Il fait partie des logiciels de gestion de base de donneés les plus utilise´s au monde, autant par
le grand public ( les applications web principalement) que par des professionnels. MySQL est de´veloppe´ dans
un souci de performance e´leveé en lecture, ce qui signifie qu’il est oriente´ vers le service de donneés de´ja`
en place vers celui de mises a` jour fre´quentes et fortement sećuriseés. Il est multithread et multiutilisateurs.
On a choisi MySQL car il est sous licence Open Source et qu’il est le SGBD le plus populaire au monde graˆce
a` sa haute performance, sa fiabilite´ et sa simplicite´ d’utilisation. Ce SGBD est en concurrence avec Oracle
et Microsoft SQL Server.
Figure 3.8 – Logo MySQL
3.2.3 Environnement de développement intégré (IDE)

3.2.3.1 PhpStorm
PhpStorm, dont le logo est présenté par la figure 3.9 est un IDE PHP qui "comprend" votre code. Il existe
depuis plus de 10 ans et posse`de une large communaute´ de plus de 600 000 utilisateurs autour du globe. Il
prend en charge PHP 5.3/5.4/5.5/5.6/7.0/7.1/7.2, fournit la pre´vention des erreurs a` la voleé, les meilleurs
outils de saisie automatiques et de refactorisation de code, un de´bogage sans configuration et un e´diteur
JavaScript, CSS et HTML e´tendu.
25
Figure 3.9 – Logo PhpStorm
3.2.3.2 WebStorm
WebStorm , dont le logo est présenté par la figure ?? est un IDE qui permet, entre autres, l’auto-comple´tion
en recherchant activement les classes/fonctions dećlare´s dans un projet, la synchronisation automatique des
fichiers locaux et les fichiers distants a` la sauvegarde (et a` la sauvegarde automatique)l’historique de versions
des fichiers (en local), des raccourcis clavier qui sont vraiment utiles. Les points forts de cet IDE sont :
• Coloration syntaxique
• Auto-comple´tion.
• Introspection du code.
• Outils de recherche avanceé.
• Parame´trage IDE/Projet.
• Versionning / Bug-tracker.
• Tre´s bon suivi et mises a` jour fre´quentes.
• Multiple-plateforme.
Figure 3.10 – Logo WebStorm
3.2.3.3 Xcode
Xcode, dont le logo est présenté par la figure 3.11 est un ensemble d’outils complet a` la disposition des
de´veloppeurs et conçue pour la creátion d’apps pour Mac, iPhone, iPad, Apple Watch et Apple TV. Xcode
permet d’e´laborer des interfaces utilisateur, de coder, de tester ses applications, de les de´boguer et de les
envoyer sur l’App Store d’une seule traite.
Figure 3.11 – Logo Xcode
26
3.2.4 Choix techniques
Notre projet se dećompose de deux parties : back-end et front-end. Dans cette section nous allons mentionner
les bibliothèques et les frameworks utilisés pour le développement de ces deux parties.
3.2.4.1 Langage de programmation
— Php
PHP, dont le logo est présenté par la figure 3.12 est un langage de script côté serveur qui est intégré au
HTML. Il est utilisé pour gérer le contenu dynamique, les bases de données, le suivi des sessions, et même pour
construire des sites entiers de commerce électronique. Il est intégré à un certain nombre de bases de données
populaires, notamment MySQL, PostgreSQL, Oracle, Sybase, Informix et MicrosoftSQL Server.
Figure 3.12 – Logo Javascript
— Javascript
Javascript, dont le logo est présenté par la figure 3.13 est un langage de programmation de scripts princi-
palement employé dans les pages web interactives mais aussi pour les serveurs avec l’utilisation (par exemple)
de Node.JS. C’est un langage orienté objet à prototype, c’est-à-dire que les bases du langage et ses principales
interfaces sont fournies par des objets qui ne sont pas des instances de classes, mais qui sont chacun équipés
de constructeurs permettant de créer leurs propriétés, et notamment une propriété de prototypage qui permet
d’en créer des objets héritiers personnalisés. En outre, les fonctions sont des objets de première classe.
Figure 3.13 – Logo Swift
— Swift
Swift, dont le logo est présenté par la figure 3.14 est un langage à la fois rapide et efficace qui fournit
des retours en temps réel et s’intègre naturellement au code Objective-C existant. Les développeurs peuvent
donc rédiger un code plus sûr et plus fiable, gagner du temps et créer des applications offrant aux utilisateurs
une expérience plus riche. Apple a officiellement commencé à développer Swift au sein de Swift.org en 2010.
Crée dans le but d’être facile à utiliser, le langage assure un typage fort, ce qui permet d’éviter de nombreuses
catégories d’erreurs de programmation courantes. Swift a également été crée pour être sûr sans nuire aux
performances.Les similitudes avec le langage C et la programmation orientée objet ont contribué à emporter
l’adhésion des programmeurs. Le langage est simple à apprendre, ce qui le rend accessible aux novices et aux
programmeurs chevronnés.
27
Figure 3.14 – Logo Swift
3.2.4.2 Framework
Un Framework est un cadre de travail basé sur une architecture applicative. Il propose ainsi un ensemble
d’outils et de composants logiciels cohérents tels qu’une bibliothèque logicielle réutilisable. Sa structure tech-
nique et logique impose au développeur le respect de certaines pratiques et normes de développement. Un
Framework sert de fondation et de squelette à une application. Toute la partie technique (architecture, struc-
ture et bibliothèque) est gérée en toute transparence. Sa conception est faite de telle manière à faciliter le
travail du développeur et lui permettre de ne se concentrer que sur l’essentiel, c’est à-dire le développement des
composants métiers.
— Laravel
Laravel, dont le logo est présenté par la figure 3.15 est un framework PHP open source, multi-plateforme
permettant de creér des applications web. Crée en 2011 par Taylor Otwell, ce framework regroupe les meilleures
librairies utiles pour créer un site web. Laravel est principalement un framework de de´veloppement Backend,
En outre, l’excellent framework laravel intègre aussi bien d’autres fonctionnalités exclusives. C’est notamment le
cas de son moteur de template Blade. Les applications Laravel sont hautement e´volutives et leur base de code
est facile a` maintenir. Les de´veloppeurs peuvent e´galement ajouter des fonctionnalite´s a` leurs applications
de manie`re transparente, graˆce au syste`me de packaging modulaire de Laravel et a` la gestion robuste des
de´pendances.
• Un système de routage perfectionné (RESTFul et ressources) ce système a été pris sur le framework PhP
Symfony
• Un créateur de requêtes SQL et un ORM performant
• Un moteur de template efficace
• Un système d’authentification pour les connexions
• Un système de validation
• Un système de pagination
• Un système de migration pour les bases de données
• Un système d’envoi d’e-mails
• Un système de cache
• Une gestion des sessions
• Possibilité d’effectuer des tests unitaires
Figure 3.15 – Logo Laravel
28
3.2.4.3 Bibliothèques
— React Js
React, dont le logo est présenté par la figure 3.16 est un projet open-source , de´sormais distribue´ sous
la tre`s populaire licence MIT et pilote´ par Facebook, dont tous les produits web et mobiles reposent sur
cette technologie. Autour d’une e´quipe principale composeé d’une vingtaine de personnes, gravitent plus de
mille contributeurs occasionnels. En octobre 2017, plus de 20 000 modules sur npm (le principal re´fe´rentiel
de modules de de´veloppement, surtout oriente´ JavaScript, qui contient quelques 650 000 modules au total)
avaient un rapport a` l’ećosyste`me React. ReactJS est une bibliothe`que JavaScript dećlarative , efficace et
flexible pour la construction de composants d’interface utilisateur reútilisables. Il s’agit d’une bibliothe`que
frontale open source baseé sur des composants qui n’est responsable que de la couche d’affichage de l’application.
Il a e´te´ initialement de´veloppe´ et maintenu par Facebook et utilise´ plus tard dans ses produits comme
WhatsApp et Instagram.
Figure 3.16 – Logo React
— JSON Web Token (JWT)

Un JSON Web Token est un access token (jeton d’accès) aux normes RFC 7519 qui permet un échange sécurisé
de donnée entre deux parties. Il contient toutes les informations importantes sur une entité, ce qui rend la
consultation d’une base de données superflue et la session n’a pas besoin d’être stockée sur le serveur (stateless
session).
Les JSON Web Token, dont le logo est présenté par la figure 3.17 sont particulièrement appréciés pour les
opérations d’identification. Les messages courts peuvent être chiffrés et fournissent alors des informations sûres
sur l’identité de l’expéditeur et si celui-ci dispose des droits d’accès requis. Les utilisateurs eux-mêmes ne sont
qu’indirectement en contact avec les token, par exemple lorsqu’ils entrent un nom d’utilisateur et un mot de
passe dans un masque. La véritable communication se fait entre les différentes applications du côté serveur et
client.
Figure 3.17 – Logo JWT
— Firebase Cloud Messaging (FCM)

Firebase Cloud Messaging, dont le logo est présenté par la figure 3.18 est un service multiplateforme qui gère
l’envoi, le routage et la mise en file d’attente des messages (flux) entre les applications serveur et les applications
client.
À l’aide de FCM, les serveurs d’applications peuvent envoyer des messages à un seul périphérique, à un
groupe d’unités ou à un certain nombre d’unités abonnées à un sujet. Une application cliente peut utiliser FCM
pour s’abonner à des messages en aval à partir d’un serveur d’applications (par exemple recevoir des notifications
à distance).
29
Figure 3.18 – Schéma déscriptif du FCM
— Firebase Cloud Messaging en action

Comme illustré dans la figure 3.19, FCM agit comme un intermédiaire entre les expéditeurs de message et les
clients. Lorsqu’un message aval est envoyé à une application cliente à partir d’un serveur d’application, le serveur
d’application envoie le message à un serveur de connexion FCM fourni par Google ; le serveur de connexion
FCM, à son tour, transmet le message à un périphérique qui exécute l’application cliente. Étant donné que les
applications client ne sont pas toujours connectées ou en cours d’exécution, le serveur de connexion FCM met
en file d’attente et stocke les messages, les envoyant aux applications client à mesure qu’ils se reconnectent et
deviennent disponibles. De même, pour le serveur d’applications s’ il n’est pas disponible.
Figure 3.19 – Schéma déscriptif du FCM
FCM utilise les informations d’identification suivantes pour identifier le serveur d’applications et l’application
cliente et utilise ces informations d’identification pour autoriser les transactions de message via FCM :
-ID de l’expéditeur : on l’obtient depuis la console Firebase.
-Clé de l’API : La clé de l’API permet au serveur de l’application d’accéder aux services Firebase. FCM
utilise cette clé pour authentifier le serveur d’applications. Cette référence est également appelée clé de serveur
ou clé API Web.
-App ID : L’identité de votre application client (indépendante de tout périphérique donné) qui s’enregistre
pour recevoir des messages de FCM.
-Registration Token : Le jeton d’enregistrement (également appelé ID d’instance) est l’identité FCM de
votre application client sur un dispositif. Le jeton d’enregistrement est généré au moment de l’exécution. Votre
30
application reçoit un jeton d’inscription lors de son enregistrement initial auprès de FCM lors de son exécution
sur un périphérique. Le jeton d’enregistrement autorise une instance de votre application cliente (exécutée sur
ce périphérique particulier) à recevoir des messages de FCM.
— Inscription à FCM
Comme illustré dans la figure 3.20,Une application cliente doit d’abord s’inscrire auprès de FCM avant que
la messagerie puisse avoir lieu. L’application cliente doit effectuer les étapes d’enregistrement indiquées dans
la figure 46 : 1- L’application cliente contacte FCM pour obtenir un jeton d’enregistrement, transmettant l’ID
de l’expéditeur, la clé API et l’ID d’application à FCM. 2- FCM renvoie un jeton d’inscription à l’application
cliente. 3- L’application cliente (facultativement) transmet le jeton d’inscription au serveur d’applications.
Figure 3.20 – Schéma déscriptif des étapes du FCM
— Swagguer
Pour résumer en une phrase ce qu’est Swagger, dont le logo est présenté par la figure 3.21, on peut dire
que c’est un ensemble d’outils pour aider les développeurs dans la conception, le build, la documentation et la
consommation d’API.
En 2010, Swagger n’était qu’une spécification open source pour construire des API REST. A cela est venu
se greffer divers outils, également open source, pour aider à implémenter et visualiser les API ; on parle là
de Swagger UI, Swagger Editor et Swagger Codegen. En 2015, le projet Swagger est récupéré par Smartbear
Software et la spécification swagger est renommée OpenAPI.
Figure 3.21 – Logo Swagguer
3.3 Architecture de l’application

L’architecture représente le point de départ pour concevoir une application. Une architecture d’application
fournit un descriptif sur les modèles et les techniques utilisés pour créer une application. L’architecture fournit
les meilleures pratiques à suivre pour créer une application bien structurée.
31
3.3.1 Architecture physique
Il est nécessaire à la conception de toute application de choisir l’architecture adéquate qui permet d’assurer un
bon fonctionnement et de meilleures performances. Notre application.repose sur une architecture 3-tiers, Cette
architecture se compose de trois composants, Chaque composant a un rôle et une responsabilité spécifiques au
sein de l’application :
• Le client : celui qui demande les ressources qui peut etre un navigateur ou un smartphone...
• Le serveur d’application qui est un middleware chargé de fournir la ressource mais faisant appel à un autre
serveur.
• Le serveur secondaire généralement un serveur de base de données, fournissant un service au premier
serveur.
L’approche 3-tiers, comme le montre la figure 3.22 dispose de plusieurs avantages. Parmi ses avantages
- Une séparation des données d’où une conception plus claire et plus efficace.
- Un gain de temps de maintenance et d’évolution de l’application.
- Une plus grande souplesse pour organiser le développement de l’application entre différents développeurs.
- Indépendance entre les trois niveaux.
- Plus de flexibilité dans l’allocation des ressources et dans les requêtes du client vers le serveur.
Figure 3.22 – Architecture 3 tiers
3.3.2 Architecture logique

Après avoir présenté l’architecture opérationnelle de notre application, nous allons détailler l’architecture
applicative, qui est décrite par la figure 3.23, en mettant en évidence la communication entre les différentes
couches applicatives.
— La couche de présentation : serait chargée de gérer l’ensemble de la logique de communication de l’interface
utilisateur et du navigateur, elle n’a pas besoin de savoir ni de s’inquiéter de la manière d’obtenir les données
client ; il suffit que cette information soit affichée sur un écran dans un format particulier.
— La couche métier : assure les fonctionnalités de la partie serveur de l’application et réalise les traitements
sur les données.
— La couche d’accès aux données : le serveur de base de données partage les données stockées avec la
couche métier pour qu’elle puisse terminer son traitement. Il assure la persistance des données qui doivent être
conservées.
32
Figure 3.23 – Architecture logique de l’application
3.4 Diagramme de déploiment

Les diagrammes de déploiement se rapprochent encore plus de la réalité physique, puisqu’ils identifient les
éléments matériels (PC, Modem, Station de travail, Serveur, etc.), leur disposition physique (connexions) et la
disposition des exécutables (représentés par des composants) sur ces éléments matériels. La figure 3.24 présente
la structure physique de notre système informatique et la répartition des composants logiciels sur ce système
par ce diagramme de déploiement.
Le déploiement de l’application suit l’architecture 3-tiers qui se compose de :
• Coté client : désigne une application accessible via une interface web à l’aide du navigateur et une appli-
cation mobile accessible a l’aide d’un smartphone.
• Coté serveur : c’est un serveur web nginx capable d’interpréter les requêtes et de fournir des réponses.
• Serveur de donnée : le système de gestion de base de donné MySQL qui contient les tables de notre
application.
33
Figure 3.24 – Diagrammme de déploiment
3.5 Patrons de conception : MVC

La conception d’une application commence par le choix de l’architecture. Comme toute architecture, pour
pouvoir la réussir, il est vivement conseillé de se baser sur les expériences des architectes et concepteurs. Les
expériences sont illustrées dans le monde du génie logiciel par ce qu’on appelle des patrons de conception.
Un patron de conception (souvent appelé design pattern) est une disposition caractéristique de modules,
reconnu comme bonne pratique en réponse à un problème de conception d’un logiciel.
Modèle-Vue-Contrôleurs (MVC) : Il s’agit d’un patron de conception dont le but est de garantir une séparation
des propos et un couplage faible entre les entités d’une application afin de simplifier la maintenance et l’évolution
de la solution. L’utilisation de DAO (Data Access Object) permet de s’abstraire de la façon dont les données
sont stockées au niveau des objets métier. Ainsi, le changement du mode de stockage ne remet pas en cause le
reste de l’application. Pour cela, il est recommandé de découper l’application suivant le modèle de la figure 3.25.
Le but de MVC est justement de séparer la logique du code en trois parties principales que l’on retrouve
dans des fichiers distincts, comme l’explique la description qui suit.
• Le Modèle : cette partie a pour rôle de gérer les différents données du site. Son rôle est d’aller récupérer les
informations brutes dans la base de données, de les organiser et de les assembler pour qu’elles puissent ensuite
être traitées par le contrôleur. On y trouve donc les requêtes SQL ainsi que les relations entre modèles et leurs
validations.
• La Vue : c’est la partie visible qui fait l’interface avec l’utilisateur. On y trouve des formulaires, des
boutons.. tous ce qui objets visuels permettant l’intéraction avec l’utilisateur. Elle a pour tâches l’affichage des
données qu’elle a récupérées auprès du modèle et recevoir les action de l’utilisateur.
• Le Contrôleur : cette partie gère la logique métier qui prend des décisions. C’est en quelque sorte le
34
synchroniseur entre le modèle et la vue : le contrôleur va demander au modèle les données, les analyser, prendre
des décisions et renvoyer le texte à afficher à la vue. Le contrôleur est souvent décomposé en plusieurs sections
dont chacune reçoit les événements relative à une partie des composants.
Figure 3.25 – Modèle MVC
3.6 Conclusion
Dans ce chapitre, nous avons décrit les étapes effectuées durant le premier release qui a été consacrée à l’au-
thentification , la gestion du profile et des ressources de l’application. Pour chaque sprint, nous avons commencé
par une spécification fonctionnelle, ensuite, nous avons détaillé la conception en présentant les diagrammes
de séquences, d’activités et de classes. Enfin, nous avons clôturé par la présentation de la réalisation via les
interfaces Homme-Machine.
35
Chapitre 4
Realease 1 : Gestion de l’authentification

et des ressources de l’application
Contents
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Sprint 1 : Gestion d’authentification et profile . . . . . . . . . . . . . . . . . . . . . 37
4.2.1 Spécifications fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Sprint 2 : Gestion des ressources de l’application et des utilisateurs . . . . . . . . 53
4.3.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
36
4.1 Introduction
Tout au long de ce chapitre, nous allons présenter le premier release qui se décompose d’un premier sprint
pour l’authentification de l’administrateur et de l’utilisateur un deuxième pour la gestion des ressources de
l’application . L’étude de chaque sprint est organisée sur trois phases : l’analyse, la conception, et la réalisation.
4.2 Sprint 1 : Gestion d’authentification et profile

Ce sprint présente le premier sprint de notre application. Il détaille la gestion de l’authentification et du
profile.
4.2.1 Spécifications fonctionnelles

Ce sprint représente la première partie de notre projet.
4.2.1.1 Backlog du Sprint 1
Le Sprint backlog est le tableau que nous tirons du Backlog Product. Après avoir fixé l’objectif du sprint 1,
nous définissons quelles sont les « user stories » qui vont faire l’objet du Backlog de ce sprint. Nous présentons
à travers le tableau 4.1 les différentes tâches de chaque user story.
Table 4.1 – Backlog du sprint 1
Histoire utilisateur Description Priorité
S’authentifier En tant qu’administrateur, je souhaite m’authentifier Èlevée

En tant qu’administrateur, je souhaite consulter mon pro-
Consulter le profile Moyenne
fil
Modifier le profile En tant qu’administrateur, je souhaite modifier mon profil Moyenne
Créer un compte En tant qu’utilisateur, je souhaite m’inscrire Élevée
S’authentifier En tant qu’utilisateur, je souhaite m’authentifier Èlevée
Consulter le profile En tant qu’utilisateur, je souhaite consulter mon profil Moyenne
Modifier le profile En tant qu’utilisateur, je souhaite modifier mon profil Moyenne
En tant qu’utilisateur, je souhaite récupérer mon compte
Récupérer le compte Moyenne
en cas d’oubli de mon mot de passe
4.2.1.2 Diagramme de cas d’utilisation détaillé du sprint 1
Par la suite, nous présentons la phase d’analyse dont nous décrivons le diagramme de cas d’utilisation et la
description textuelle. La figure 4.1 décrit le diagramme de cas d’utilisation détaillé relatif a ce sprint ainsi que
sa description textuelle à travers le tableau 4.2.
37
Figure 4.1 – Diagramme de cas d’utilisation du sprint 1
Table 4.2 – Description textuelle de cas d’utilisation du sprint1
Clause Description
Identifiant Gérer l’authentifiaction et configurer le profile.
l’administrateur et l’utilisateur peuvent s’authentifier et configu-
Résumé
rer leurs profile
Acteur Administrateur et utilisateur
Contexte de déclenche- Authentification préalable (sauf pour la création et la récupéra-
ment tion de compte)
Pré conditions Api-token valide pour la gestion de profile.
Email existant dans la base de données pour la récupération du
compte
Si l’administrateur ou l’utilisateur possède la clé d’autorisation
Description
api token valide, il peut gérer son profile.
4.2.1.3 Diagramme de cas d’utilisation s’authentifier pour l’administrateur
La figure 4.2 illustre le diagramme détaillant le cas d’utilisation de l’authentification de l’administrateur

ainsi que sa description textuelle présentée dans le tableau 4.3.
Figure 4.2 – Diagramme de cas d’utilisation s’authentifier de l’administrateur
38
Table 4.3 – Description textuelle du cas d’utilisation s’authentifier
Cas d’utilisation S’authentifier

Acteur Administrateur.
Pré conditions Avoir un compte.
Le système va rediriger l’administrateur vers la page d’acceuil
Post conditions
du Dashboard.
Scénario nominal 1- L’administrateur demande l’interface d’authentification.
2- Le système affiche l’interface d’authentification.
3- L’administrateur saisit son email ainsi que son mot de passe.
4- Le système vérifie les identifiants et fourni un jeton d’accés.
Scénario alternatif 3- L’administrateur saisit des identifiants non corrects.
3-1 Le système affiche un message d’erreur.
4.2.1.4 Diagramme de cas d’utilisation Créer un compte
La figure 4.3 illustre le diagramme détaillant le cas d’utilisation de de la création de compte pour l’utilisateur
Figure 4.3 – Diagramme de cas d’utilisation créer un compte
39
Table 4.4 – Description textuelle du cas d’utilisation créer un compte
Cas d’utilisation Créer un compte

Acteur Utilisateur.
Pré conditions Api-token valide.
Post conditions le système va rediriger l’utilisateur vers la page d’acceuil du .
Scénario nominal 1- L’utilisateur demande l’interface d’inscription.
2- Le système affiche l’interface d’inscription.
3- L’utilisateur saisit son nom, email, un mot de passe et
confirme son mot de passe.
4- Le système vérifie si les champs saisies par l’utilisateur ré-
pondent aux critères de validation et affiche l’interface de locali-
sation.
5- L’utilisateur se localise ou ignore cette étape .
6- Le système fourni un jeton d’accés.
1- L’utilisateur saisit des champs qui ne répondent pas aux cri-
Scénario alternatif
tères de validation .
2 Le système affiche un message d’erreur.
4.2.1.5 Diagramme de cas d’utilisation récupérer le compte
La figure 4.4 illustre le diagramme détaillant le cas d’utilisation de l’authentification de l’utilisateur ainsi
que sa description textuelle présentée dans le tableau 4.5.
Figure 4.4 – Diagramme de cas d’utilisation s’authentifier de l’utilisateur
40
Table 4.5 – Description textuelle du cas d’utilisation récupérer le compte
Cas d’utilisation Récupérer le compte

Acteur Utilisateur.
Pré conditions E-mail existant dans la base de données.
Le système va rediriger l’utilisateur vers la page d’acceuil de
Post conditions
l’application mobile.
Scénario nominal 1- L’utilisateur demande l’interface d’oubli de mot de passe.
2- Le système affiche l’interface d’oubli de mot de passe.
3- L’utilisateur saisit son email.
4- Le système vérifie l’existance de l’e-mail dans la base de don-
nées, envoie un email contenant un code de quatres chiffres et
affiche l’interface de confirmation de code.
5- L’utilisateur saisit le code reçu.
6- Le système vérifie le code saisit et affiche l’interface de réini-
tialisation du mot de passe.
7- L’utilisateur saisit un nouveau mot de passe
8- Redirection vers la page d’accueil
Scénario alternatif 3- L’utilisateur saisit un e-mail incorrect.
1 Le système affiche un message d’erreur.
2- L’utilisateur saisit un code icorrects.
4- L’utilisateur saisit un mot de passe qui ne réponds pas aux
critères de validation.
5- Le système affiche un message d’erreur.
4.2.1.6 Diagramme de cas d’utilisation modifier le profile
La figure 4.5 illustre le diagramme détaillant le cas d’utilisation de la modification de profile de l’utilisateur
Figure 4.5 – Diagramme de cas d’utilisation modifier le profile
41
Table 4.6 – Description textuelle du cas d’utilisation modifier profile
Cas d’utilisation Modifier profile

Acteur Utilisateur.
Pré conditions L’utilisateur doit s’authentifier..
Post conditions La modification du profil sera effectuée
Scénario nominal 1. L’utilisateur demande l’interface de modification de profil.
2. Le système affiche l’interface de profil.
3. L’utilisateur tape les changements de contenu de ses données
personnelles.
4. Le système vérifie les champs saisis .
3 L’utilisateur saisit des champs qui ne répondent pas aux cri-
tères de validation.
4.2.2 Conception
Dans cette partie, nous passons à la deuxième activité dans le sprint de la gestion d’authentification et du
profile qui est la conception où nous présentons les diagrammes de séquences, d’activités ainsi que le diagramme
de classes de ce sprint.
4.2.2.1 Diagramme de séquence
Les diagrammes de séquences documentent les interactions à mettre en œuvre entre les objets de point de
vue temporel pour réaliser un résultat, tel qu’un cas d’utilisation. Le diagramme de séquence énumère des objets
horizontalement, et le temps verticalement. Il modélise l’exécution des différents messages en fonction du temps.
4.2.2.2 Diagramme de séquence pour le scénario d’authentification
Le diagramme illustré dans la figure 4.6 est le séquencement des interactions entre le client et les objets du
système responsable de l’authentification qui offre au client un formulaire d’authentification.
Dès la validation du client après la saisie de l’e-mail et du mot de passe, le composant côté client consomme
le web service d’authentification exposé par le contrôleur responsable de la partie back-end, ce dernier vérifie
l’existence de ce client et renvoi un résultat sous forme de JSON contenant un token.
Le composant de la partie front-end agit selon le résultat du JSON, si le résultat contient un token, alors
le composant fait une redirection vers la page d’accueil de l’application, sinon une redirection vers la page
d’authentification à nouveau et un message sera affiché à l’utilisateur.
42
Figure 4.6 – Diagramme de séquence pour le scénario authentification
4.2.2.3 Diagramme de séquence pour le scénario récupérer le compte
système responsable de la récupération du compte qui guide le client avec les étapes qu’il faut suivre.
Après la saisie de l’e-mail le composant côté client consomme le web service de récupération de mot de passe
exposé par le contrôleur responsable de la partie back-end, ce dernier vérifie l’existance de cet e-mail dans la
base de données, génère un code aléatoire, l’envoi a l’utilisateur par e-mail et renvoi un résultat sous forme de
JSON.
Le composant de la partie front-end agit selon le résultat du JSON, si le résultat contient un succés et que
l’email est envoyé, alors le composant fait une redirection vers l’interface de saisie du code, sinon un message
d’erreur sera affiché à l’utilisateur.
Le client compose le code reçu,le composant côté client consomme le web service de vérification de code
exposé par le contrôleur responsable de la partie back-end, ce dernier vérifie si le code est correct et renvoi un
résultat sous forme de JSON.
43
Le composant de la partie front-end agit selon le résultat du JSON, si le résultat contient un succés et que
le code est correct, alors le composant fait une redirection vers l’interface de réinitialisation du mot de passe,
sinon un message d’erreur sera affiché à l’utilisateur.
Le client compose son nouveau mot de passe et sa confirmation,le composant côté client consomme le web
service de réinitialisation de mot de passe exposé par le contrôleur responsable de la partie back-end, ce dernier
vérifie si les champs saisies sont valides et renvoi un résultat sous forme de JSON.
Le composant de la partie front-end agit selon le résultat du JSON, si le résultat contient un succés et que le
mot de passe a été mis a jours, alors le composant fait une redirection vers la page d’accueil, sinon un message
d’erreur sera affiché à l’utilisateur. .
Figure 4.7 – Diagramme de séquence pour le scénario récupérer le compte
4.2.2.4 Diagramme de séquence pour le scénario modifier le profil
système responsable de la modification du profile qui offre au client un formulaire a remplir.
Dès la validation du client après la saisie des champs a modifier, le composant côté client consomme le web
service de modification de profile exposé par le contrôleur responsable de la partie back-end, ce dernier vérifie
les champs entré par le client et renvoi un résultat sous forme de JSON.
44
Le composant de la partie front-end agit selon le résultat du JSON, si l’opération est réussite, alors un
message de succés sera affiché et l’interface met a jours les champs, sinon un message d’erreur sera affiché à
l’utilisateur.
Figure 4.8 – Diagramme de séquence pour le scénario modifier le profile
4.2.2.5 Diagramme d’activité
Les diagrammes d’activités permettent de mettre l’accent sur les traitements. Ils sont donc particulièrement
adaptés à la modélisation du cheminement de flots de contrôle et de flots de données. Ils permettent ainsi de
représenter graphiquement le comportement d’une méthode ou le déroulement d’un cas d’utilisation.
45
4.2.2.6 Diagramme d’activité s’authentifier
L’authentification consiste à vérifier l’identité d’une entité, afin d’autoriser son accès au système. Elle permet
donc de valider l’authenticité de l’entité en question. La figure 4.9 décrit les activités suivantes :
• L’administrateur demande l’authentification en faisant l’accès à l’interface d’authentification,
• Un formulaire d’authentification s’affiche pour cet utilisateur,
• L’administrateur saisie son email et son mot de passe,
• Le système vérifie les coordonnées de l’administrateur dans la base,
• Si les données sont acceptées, le système redirige l’administrateur vers l’interface d’accueil du dashboard,
si non il revient à l’étape précédente.
Figure 4.9 – Diagramme d’activité s’authentifier
4.2.2.7 Diagramme d’activité créer un compte
L’insription consiste à ajouter un nouvel objet. Elle permet donc de La figure 4.10 décrit les activités
suivantes :
• L’utilisateur accède à l’interface d’inscription,
• Un formulaire d’inscription s’affiche pour cet utilisateur,
• L’utilisateur saisie les champs requis,
•le systeme redirige l’utilisateur vers l’interface de localisation
• Le système vérifie les champs saisis.
• Si les données sont acceptées, le système redirige l’utilisateur vers l’interface d’accueil de l’application, si
non il revient à l’étape de saisis de données.
46
Figure 4.10 – Diagramme d’activité créer un compte
4.2.2.8 Diagramme d’activité modifier le profile
La figure 4.11 décrit les activités suivantes :

• L’utilisateur accède à l’interface de son profile,
• L’utilisateur modifie ses données,
• Le système vérifie les données saisis.
• Si les données sont acceptées, le système mis a jours les informations de l’utilisateur.
Figure 4.11 – Diagramme d’activité modifier le profile
47
4.2.2.9 Diagramme de classes
Le diagramme de classes permet de décrire la structure interne tout en montrant les différentes classes, leurs
attributs ainsi que les différentes relations structurelles entre ces classes. Il s’agit d’une vue statique, car on
ne tient pas compte du facteur temporel dans le comportement du système. Le diagramme de classes modélise
les concepts du domaine d’application ainsi que les concepts internes créés de toutes pièces dans le cadre de
l’implémentation d’une application. Chaque langage de Programmation orienté objet donne un moyen spécifique
d’implémenter le paradigme objet (pointeurs ou pas, héritage multiple ou pas, etc.), mais le diagramme de classes
permet de modéliser les classes du système et leurs relations indépendamment d’un langage de programmation
particulier. La figure 4.12 décrit le diagramme de classes que nous avons utilisé pour développer le premier
sprint.
Figure 4.12 – Diagramme de classe du sprint1
4.2.3 Réalisation
Dans cette section, nous présentons les résultats de ce sprint où nous allons exposer quelques interfaces à
travers différentes imprimes écrans réalisées.
4.2.3.1 Interface d’authentification
La figure 4.13 représente l’interface d’authentification de l’administrateur.
48
Figure 4.13 – Interface d’authentification de l’administrateur
4.2.3.2 Interfaces d’inscription
Les figures 4.14 et 4.15 représentent les interfaces d’inscription de l’utilisateur.
Figure 4.14 – Interface d’inscription de l’utilisateur
49
Figure 4.15 – Interface de localisation de l’utilisateur
4.2.3.3 Interfaces de récupération du mot de passe
Les figures 4.16, 4.17 et 4.18 représentent les interfaces de récupération du mot de passe de l’utilisateur.
Figure 4.16 – Interface de vérification de l’e-mail
50
Figure 4.17 – Interface de vérification de code de réinitialisation
Figure 4.18 – Interface de réinitialisation du mot de passe
4.2.3.4 Interface de modifiation du profil
Les figures 4.19 , 4.20 et 4.21 représente les interfaces de profil et sa modification de l’utilisateur.
51
Figure 4.19 – Interface de profil de l’utilisateur : section annonces
Figure 4.20 – Interface de profil de l’utilisateur : section avis
52
Figure 4.21 – Interface de modification de profil de l’utilisateur
4.3 Sprint 2 : Gestion des ressources de l’application et des utilisa-

teurs
Ce sprint présente le deuxieme sprint de notre application. Il détaille la gestion des differentes ressources et
les utilisateurs par l’administrateur.

Ce sprint représente la deuxième partie de notre projet.
53

En tant qu’administrateur de l’application, je souhaite
Lister les utilisateurs Faible
lister les utilisateurs et voir leurs informations
Ajouter une catégorie Élevée
ajouter une catégorie
Modifier une catégorie Moyenne
modifier une catégorie
Supprimer une catégorie Faible
supprimer une catégorie
Lister les catégories Faible
lister les catégories
Ajouter une sous- En tant qu’administrateur de l’application, je souhaite
Élevée
catégorie ajouter une sous-catégorie
Modifier une sous- En tant qu’administrateur de l’application, je souhaite
Moyenne
catégorie modifier une sous-catégorie
Supprimer une sous- En tant qu’administrateur de l’application, je souhaite
Faible
catégorie supprimer une sous-catégorie
Lister les sous-catégories Faible
lister les sous-catégories
Ajouter une étiquette Élevée
ajouter une étiquette
Modifier une étiquette Moyenne
modifier une étiquette
Supprimer une étiquette Faible
supprimer une étiquette
Lister les étiquettes Faible
lister les étiquettes
Par la suite, nous présentons la phase d’analyse dont nous décrivons le diagramme de cas d’utilisation et
ladescription textuelle. La figure 4.22 décrit le diagramme de cas d’utilisation détaillé relatif a ce sprint ainsi
que sa description textuelle à travers le tableau 4.9.
54
Table 4.8 – Description textuelle du cas d’utilisation du sprint 2
Clause Description
Identifiant Gérer les ressources et les utilisateurs.
l’administrateur peut gérer les différentes resssources et utilisa-
Résumé
teurs de l’application
Acteur Administrateur
Contexte de déclenche-
Authentification préalable
ment
Si l’administrateur possède la clé d’autorisation valide, il peut
Description
gérer les ressources et les utilisateurs.
55
4.3.1.3 Diagramme de cas d’utilisation détaillé de la gestion des utilisateurs
La figure 4.23 illustre le diagramme détaillant le cas d’utilisation de gestion des utilisateurs ainsi que sa
description textuelle présentée dans le tableau 4.9
Figure 4.23 – Diagramme de cas d’utilisation gérer les utilisateurs
Table 4.9 – Description textuelle du cas d’utilisation gérer les utilisateurs
Cas d’utilisation Gérer les utilisateurs

le système va rediriger l’administrateur vers la page de détails
Post conditions
des utilisateurs.
1- L’administrateur demande l’interface de gestion des utilisa-
Scénario nominal
teurs.
2- Le système affiche l’interface.
3- L’administrateur clique sur une ligne du tableau pour afficher
les détails de l’utilisateur.
4- Le système affiche la page des détails .
Scénario alternatif 3- aucun.
4.3.1.4 Diagramme de cas d’utilisation détaillé de l’ajout d’une catégorie
La figure 4.24 illustre le diagramme détaillant le cas d’utilisation d’ajout d’une catégorie ainsi que sa des-
cription textuelle présentée dans le tableau 4.10
Figure 4.24 – Diagramme de cas d’utilisation ajouter une catégorie
56
Table 4.10 – Description textuelle du cas d’utilisation ajouter une catégorie
Cas d’utilisation Ajouter catégorie

le système va rediriger l’administrateur vers la page de gestion des
Post conditions
catégories.
Scénario nominal 1- L’administrateur demande l’interface des catégories.
3- L’administrateur saisit le nom de la catégorie dans le formulaire .
4- Le système vérifie les informations saisies, stocke la nouvelle ca-
tégorie et fourni un message de succées .
Scénario alternatif 3- L’administrateur saisit des informations non corrects.
4.3.1.5 Diagramme de cas d’utilisation détaillé de la modification d’une catégorie
La figure 4.25 illustre le diagramme détaillant le cas d’utilisation de modification d’une catégorie ainsi que
sa description textuelle présentée dans le tableau 4.11
Figure 4.25 – Diagramme de cas d’utilisation modifier une catégorie
Table 4.11 – Description textuelle du cas d’utilisation modifier une catégorie
Cas d’utilisation Modifier catégorie

le système va rediriger l’administrateur vers la page de gestion
Post conditions
des catégories.
Scénario nominal 1- L’administrateur demande l’interface des catégories.
3- L’administrateur saisit le nouveau nom de la catégorie dans le
formulaaire de modification.
4- Le système cherche la catégorie correspondante, vérifie l’uni-
cité des informations saisies, affecte le nouveau nom a la catégo-
rie et fourni un message de succées .
Scénario alternatif 3- L’administrateur saisit des informations non corrects.
57
4.3.1.6 Diagramme de cas d’utilisation détaillé de la suppression d’une catégorie
La figure 4.26 illustre le diagramme détaillant le cas d’utilisation de la suppression d’une catégorie ainsi que
sa description textuelle présentée dans le tableau 4.12.
Figure 4.26 – Diagramme de cas d’utilisation gérer les catégories
Table 4.12 – Description textuelle du cas d’utilisation supprimer une catégorie
Cas d’utilisation Supprimer catégorie

le système va rediriger l’administrateur vers la page de
Post conditions
gestion des catégories.
1- L’administrateur demande l’interface de gestion des
Scénario nominal
catégories.
3- L’administrateur supprime la catégorie et confirme son
choix.
4- Si l’opération est réussite alors le système fournit un
message de succées et met a jours l’interface des catégo-
ries sinon il affiche un message d’erreur.
3- L’administrateur renonce a la suppression de la catégo-
rie.
3-1 Le système annule l’opération.
4.3.2 Conception
Dans cette partie, nous passons à la deuxième activité dans le sprint de la gestion des ressources qui est la
conception où nous présentons les diagrammes de séquences, d’activités ainsi que le diagramme de classes de ce
sprint.

4.3.2.2 Diagramme de séquence pour le scénario ajouter catégorie
Le diagramme illustré dans la figure 4.27 est le séquencement des interactions entre l’administrateur et les
objets du système responsable de l’ajout d’une catégorie qui offre a l’administrateur un formulaire d’ajout.
58
Dès la validation de l’administrateur après la saisie du nom de la catégorie, le composant côté client consomme
le web service d’ajout de catégories exposé par le contrôleur responsable de la partie back-end, ce dernier vérifie
l’existence de ce nom, crée la catégorie et renvoi un résultat sous forme de JSON.
Le composant de la partie front-end agit selon le résultat du JSON, si le résultat est un succés, alors le
composant se met a jours et affiche la nouvelle catégorie ajoutée, sinon un message d’erreur sera affiché.
Figure 4.27 – Diagramme de séquence pour le scénario ajouter une catégorie

4.3.2.4 Diagramme d’activité ajouter catégorie

• L’administrateur demande l’ajout d’une catégorie en faisant l’accès à l’interface de gestion des catégories,
• Un formulaire d’ajout s’affiche pour cet administrateur,
• L’administrateur saisie le nom de la catégorie,
• Le système vérifie l’unicité du nom.
• Si les données sont acceptées, le système affiche un message de succés et insère la catégorie qui vient d’être
crée dans l’interface de listing des catégories
4.3.2.5 Diagramme d’activité modifier catégorie
59
Figure 4.28 – Diagramme d’activité ajouter catégorie
• L’administrateur demande la modification d’une catégorie en faisant l’accès à l’interface de gestion des
catégories.
• Un formulaire de modification s’affiche pour cet administrateur,
• L’administrateur saisie le nouveau nom de la catégorie.
• Le système vérifie l’unicité du nom.
• Si les données sont acceptées, le système affiche un message de succés et mis a jours l’interface de listing
des catégories
Figure 4.29 – Diagramme d’activité modifier catégorie
60
4.3.2.6 Diagramme d’activité supprimer catégorie

• L’administrateur demande la suppression d’une catégorie en faisant l’accès à l’interface des catégories.
• Un message de confirmation s’affiche pour cet administrateur.
• L’administrateur confirme.
• Le système supprime la catégorie.
• Si l’opération est réussite, le système affiche un message de succés et mis a jours l’interface de listing des
catégories en éliminant la catégorie déja supprimée.
Figure 4.30 – Diagramme d’activité supprimer catégorie
La figure 4.31 décrit le diagramme de classes que nous avons utilisé pour développer le deuxième sprint.
Figure 4.31 – Diagramme de classe du sprint 2
61
4.3.3 Réalisation
4.3.3.1 Interfaces de gestion des utilisateurs
Les figures 4.32 et 4.33 représente l’interface des utilisateurs et leurs détails.
Figure 4.32 – Interface des utilisateurs
Figure 4.33 – Interface des détails utilisateur
62
4.3.3.2 Interfaces de gestion des catégories
Les figures 4.34, 4.35 et 4.36 représente l’interface des catégories et leur gestion.
Figure 4.34 – Interface d’ ajout d’une catégorie
Figure 4.35 – Interface de modification d’une catégorie
63
Figure 4.36 – Interface de suppression d’une catégorie
4.4 Conclusion
Dans ce chapitre, nous avons décrit les étapes effectuées durant le premier release qui a été consacrée à la
gestion des ressources de l’application et des utilisateurs. Pour chaque sprint, nous avons commencé par une
spécification fonctionnelle, ensuite, nous avons détaillé la conception en présentant les diagrammes de séquences,
d’activités et de classes. Enfin, nous avons clôturé par la présentation de la réalisation via les interfaces Homme-
Machine.
64
Chapitre 5
Realease 2 : Gestion des annonces , des

avis, des messages et des notifications
Contents
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2 Sprint 1 : Gérer les annonces et les avis et système de matching . . . . . . . . . . 66
5.2.2 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.3 Sprint 2 : Envoyer des messages, consulter les recommandations et gérer les
statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.3.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.3.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
65
5.1 Introduction
Tout au long de ce chapitre, nous allons présenter le deuxième release qui se divise en deux sprints. Le
premier sprint est dédié a la gestion des annonces, des avis et des signal. Quant au deuxième il s’occupera des
fonctionnalités du chat en temps réel, de la récepion de notifications et des recommendations. L’étude de chaque
sprint est organisée sur trois phases : l’analyse, la conception, et la réalisation.
5.2 Sprint 1 : Gérer les annonces et les avis et système de matching

Ce sprint présente le troisième sprint de notre application. Il détaille la gestion des annonces et des avis ainsi
que le système de matching implémenté.

Ce sprint représente la troisième partie de notre projet.

En tant qu’administrateur, je souhaite consulter les an-
Consulter les annonces Èlevée
nonces publiées par les utilisateurs
En tant qu’administrateur, je souhaite vérifier une an-
Vérifier une annonce Èlevée
nonce
En tant qu’administrateur, je souhaite recevoir des notifi-
Recevoir des notifications Èlevée
cations suite a l’ajout d’une annonce
En tant qu’administrateur, je souhaite modifier la visibi-
Modifier une annonce Moyenne
lité d’une annonce
En tant qu’administrateur, je souhaite consulter les avis
Consulter les avis Moyenne
publiés par les utilisateurs
Supprimer un avis En tant qu’administrateur, je souhaite supprimer un avis Faible
En tant qu’utilisateur, je souhaite consulter les annonces
Consulter les annonces Èlevée
publiées
Ajouter une annonce En tant qu’utilisateur, je souhaite ajouter une annonce Èlevée
Modifier une annonce En tant qu’utilisateur, je souhaite modifier une annonce Èlevée
En tant qu’utilisateur, je souhaite évaluer les utilisateurs
Évaluer les utilisateurs Moyenne
avec lesquels j’ai éffectué un échange
En tant qu’utilisateur, je souhaite signaler un avis ou un
Supprimer un avis Faible
utilisateur
En tant qu’utilisateur, je souhaite effectuer une recherche
Effectuer une recherche pour trouver les annonces dont je m’interesse (système de Faible
matching)
66
Par la suite, nous présentons la phase d’analyse dont nous décrivons le diagramme de cas d’utilisation et la
description textuelle. La figure 5.1 décrit le diagramme de cas d’utilisation détaillé relatif a ce sprint ainsi que
sa description textuelle à travers le tableau 5.2.
Table 5.2 – Description textuelle de cas d’utilisation du sprint 3
Clause Description
Identifiant Gérer les annonces, les avis.
l’administrateur et l’utilisateur peuvent gérer les annonces, les
Résumé
avis.
Contexte de déclenche- Authentification préalable (sauf pour la consultation des an-
ment nonces pour l’utilisateur)
Pré conditions Api-token valide
Si l’administrateur possède la clé d’autorisation api token valide,
il peut gérer les annonces et les avis et recevoirs les notifications.
Description
Si l’utilisateur possède la clé d’autorisation api token valide, il
peut gérer les annonces.
67
5.2.1.3 Diagramme de cas d’utilisation ajouter une annonce
La figure 5.2 illustre le diagramme détaillant le cas d’utilisation de l’ajout d’une annonce ainsi que sa
description textuelle présentée dans le tableau 5.3.
Figure 5.2 – Diagramme de cas d’utilisation ajouter une annonce
Table 5.3 – Description textuelle du cas d’utilisation ajouter une annonce
Cas d’utilisation Ajouter une annonce

Acteur Utilisateur.
Post conditions le système va rediriger l’utilisateur vers la page d’accueil.
Scénario nominal 1- L’utilisateur demande l’interface d’ajout des annonces .
3- L’utilisateur saisit les champs nécessaires dans le formulaire.
4- Si l’opération est reussite alors le système fournit un message
de succées et redirige l’utilisateur vers la page d’accueil sinon il
affiche un message d’erreur. Ainsi une notification est envoyée a
l’administrateur lui informant sur l’ajout de l’annonce .
Scénario alternatif 3- L’utilisateur saisit des informations manquantes.
5.2.1.4 Diagramme de cas d’utilisation modifier une annonce
La figure 5.3 illustre le diagramme détaillant le cas d’utilisation de la modification d’une annonce ainsi que
68
Figure 5.3 – Diagramme de cas d’utilisation modifier une annonce
Table 5.4 – Description textuelle du cas d’utilisation modifier une annonce
Cas d’utilisation Modifier une annonce

Acteur Utilisateur.
Pré conditions Api-token valide et annonce existante
Post conditions Le système va rediriger l’utilisateur vers la page d’accueil.
1- L’utilisateur demande l’interface de modification des annonces
Scénario nominal
.
3- L’utilisateur saisit les champs a modifier dans le formulaire.
de succées et redirige l’utilisateur vers la page d’accueil sinon il
affiche un message d’erreur .
5.2.1.5 Diagramme de cas d’utilisation ajouter un avis
La figure 5.4 illustre le diagramme détaillant le cas d’utilisation de l’ajout d’un avis ainsi que sa description
textuelle présentée dans le tableau 5.5.
Figure 5.4 – Diagramme de cas d’utilisation ajouter un avis
69
Table 5.5 – Description textuelle du cas d’utilisation ajouter un avis
Cas d’utilisation Ajouter un avis

Acteur Utilisateur.
Pré conditions Api-token valide et échange conclu
Post conditions Le système va rediriger l’utilisateur vers la page d’accueil.
Scénario nominal 1- L’utilisateur demande l’interface de détails d’une annonce .
3- L’utilisateur conclu l’échange.
4- Le système affiche le formulaire d’ajout d’un avis.
5- L’utilisateur saisit une description et attribut un nombre
d’étoiles.
de succées sinon il affiche un message d’erreur .
5.2.1.6 Diagramme de cas d’utilisation éffectuer une recherche
La figure 5.5 illustre le diagramme détaillant le cas d’utilisation de la recherche d’une annonce ainsi que sa
Figure 5.5 – Diagramme de cas d’utilisation rechercher
70
Table 5.6 – Description textuelle du cas d’utilisation éffectuer une recherche
Cas d’utilisation Rechercher une annonce

Acteur Utilisateur.
Pré conditions Api-token valide
Le système filtre les annonces suivant la recherche réalisée par
Post conditions
l’utilisateur.
Scénario nominal 1- L’utilisateur éffectue une recherche en saisissant un mot.
2- Le système redirige l’utilisateur vers l’interface de filtrage ou
ils affiche les annonces correspondantes a la recherche.
3- L’utilisateur choisit un critère de filtrage. En choisissant la
recherche par étiquette l’utilisateur peut saisir un deuxième mot
pour éffectué un matching. De plus il peut contrôler le niveau de
matching.
4- Le système affiche les annonces trouvées.
5- Le système ne trouve aucune annonce qui correspond à la
recherche de l’utilisateur.
5.2.1.7 Diagramme de cas d’utilisation vérifier une annonce
La figure 5.6 illustre le diagramme détaillant le cas d’utilisation de la verification d’une annonce ainsi que
Figure 5.6 – Diagramme de cas d’utilisation vérifier une annonce
Table 5.7 – Description textuelle du cas d’utilisation vérifier une annonce
Cas d’utilisation Verifier une annonce

Pré conditions Api-token valide, annonce existante et non vérifiée
Post conditions le système met a jours les détails de l’annonce.
1- L’administrateur demande l’interface de détails d’une an-
Scénario nominal
nonce.
3- L’administrateur vérifie l’annonce.
4- le système met a jours les détails de l’annonce .
Scénario alternatif 3- aucun
71
5.2.1.8 Diagramme de cas d’utilisation supprimer un avis
La figure 5.7 illustre le diagramme détaillant le cas d’utilisation de la suppression d’un avis ainsi que sa
Figure 5.7 – Diagramme de cas d’utilisation supprimer un avis
Table 5.8 – Description textuelle du cas d’utilisation supprimer un avis
Cas d’utilisation Supprimer un avis

Pré conditions Api-token valide, avis existant
Post conditions le système redirige l’administrateur vers l’interface des avis.
Scénario nominal 1- L’administrateur demande l’interface des avis.
3- L’administrateur supprime l’avis et confirme son choix..
4- Si l’opération est réussite alors le système fournit un message
de succées et met a jours l’interface des avis sinon il affiche un
message d’erreur .
Scénario alternatif 3- L’administrateur renonce a la suppression de l’avis.
3-1 Le système annule l’opération.
5.2.1.9 Conception
Dans cette partie, nous passons à la deuxième activité dans le sprint de la gestion des annonces des avis et du
signal qui est la conception où nous présentons les diagrammes de séquences, d’activités ainsi que le diagramme
de classes de ce sprint.

5.2.1.11 Diagramme de séquence pour le scénario ajouter une annonce
système responsable de l’ajout d’une annonce qui offre au client un formulaire.
Dès la validation du client après la saisie des champs nécessaires , le composant côté client consomme le web
service d’ajout d’une annonce exposé par le contrôleur responsable de la partie back-end, ce dernier vérifie les
données entrées par le client renvoi un résultat sous forme de JSON.
72
Le composant de la partie front-end agit selon le résultat du JSON, si le résultat indique un succés et il
contient une annonce , alors le composant fait une redirection vers la page d’accueil de l’application, sinon un
message sera affiché.
Figure 5.8 – Diagramme de séquence pour le scénario ajouter une annonce
5.2.1.12 Diagramme de séquence pour le scénario rechercher
système responsable de du systeme de matching.
Dès la validation du client après la saisie du premier champs de recherche, le composant côté client consomme
le web service de recherche exposé par le contrôleur responsable de la partie back-end, ce dernier filtres les
annonces suivant le champs entré par le client et renvoi un résultat sous forme de JSON.
Le composant de la partie front-end agit selon le résultat du JSON, si le résultat indique un succés , alors
le composant fait une redirection vers la page de recherche avancée de l’application.
l’utilisateur saisit un deuxième champs avec lequel il pourras consulter les correspondances possibles. Dès
la validation du client, le composant côté client consomme le web service de recherche avancée exposé par le
73
contrôleur responsable de la partie back-end, ce dernier cherche des correspondances entre les annonces suivant
suivant leurs étiquettes et renvoi un résultat sous forme de JSON.
Le composant de la partie front-end agit selon le résultat du JSON, si le résultat indique un succés , alors
le composant affiche les annonces trouvées.
Figure 5.9 – Diagramme de séquence pour le scénario rechercher
5.2.1.13 Diagramme de séquence pour le scénario ajouter un avis
système responsable de l’ajout d’un avis qui offre au client un formulaire.
Dès la validation du client après la saisie des champs nécessaires , le composant côté client consomme le
web service d’ajout d’une avis exposé par le contrôleur responsable de la partie back-end, ce dernier vérifie les
données entrées par le client renvoi un résultat sous forme de JSON.
Le composant de la partie front-end agit selon le résultat du JSON, si le résultat indique un succés et il
contient un avis, alors le composant affiche un message de succés, sinon un message d’erreur sera affiché.
74
Figure 5.10 – Diagramme de séquence pour le scénario ajouter un avis
5.2.1.14 Diagramme de séquence pour le scénario notifier l’administrateur
Le diagramme illustré dans la figure 5.11 est le séquencement des interactions entre l’administrateur et les
objets du système responsable de la reception de notification d’une annonce qui offre au client un formulaire.
Dès l’ajout d’une nouvelle annonce par un utilisateur„l’opération consomme le web service d’envoie de
notification exposé par le contrôleur responsable de la partie back-end, ce dernier renvoi un résultat sous forme
de JSON.
Le composant de la partie front-end agit selon le résultat du JSON, si le résultat indique un succés, alors le
composant mis a jour l’interface et l’administrateur reçoit une notification indiquant l’évenement.
75
Figure 5.11 – Diagramme de séquence pour le scénario notifier l’administrateur

5.2.1.16 Diagramme d’activité ajouter une annonce
L’ajout d’une annonce consiste à la création d’un nouvel objet. La figure 5.12 décrit les activités suivantes :
• L’utilisateur demande l’interface d’ajout d’une annonce.
• Un formulaire d’ajout s’affiche pour cet utilisateur.
• L’utilisateur saisie les champs nécessaires pour ajouter une annonces.
• Le système vérifie les champs.
• Si les données sont acceptées, le système crée une nouvelle annonce et redirige l’utilisateur vers l’interface
d’accueil de l’application.
76
Figure 5.12 – Diagramme d’activité ajouter une annonce
5.2.1.17 Diagramme d’activité modifier une annonce
La modification d’une annonce consiste à modifier un objet déja existant. La figure 5.13 décrit les activités
suivantes :
• L’utilisateur demande l’interface de modification de l’annonce.
• Un formulaire contenant les informations de l’annonce s’affiche pour cet utilisateur.
• L’utilisateur modifie les champs souhaités.
• Le système vérifie les champs saisis.
• Si les données sont acceptées, le système modifie l’annonce et redirige l’utilisateur vers l’interface d’accueil
de l’application.
Figure 5.13 – Diagramme d’activité modifier une annonce
77
5.2.1.18 Diagramme d’activité ajouter un avis
L’ajout d’un avis consiste a créer un nouvel objet. La figure 5.14 décrit les activités suivantes :
• L’utilisateur accède à l’interface de détails d’une annonce.
• L’utilisateur conclu l’échange de l’annonce.
• Le système affiche un formulaire pour ajouter un avis.
• L’utilisateur saisit les champs requis dans le formulaire.
• Si les données sont acceptées, le système affiche un message de succés et redirige l’utilisateur vers la page
d’accueil.
Figure 5.14 – Diagramme d’activité ajouter un avis
La figure 5.15 décrit le diagramme de classes que nous avons utilisé pour développer le premier sprint.
78
Figure 5.15 – Diagramme de classe du sprint3
5.2.2 Réalisation
5.2.2.1 Interface d’ajout d’une annonce
La figure 5.16 représente l’interface d’ajout d’une annonce pour l’utilisateur.
79
Figure 5.16 – Interface d’ajout d’une annonce
5.2.2.2 Interface de modification d’une annonce
La figure 5.17 représente l’interface de modification d’une annonce pour l’utilisateur.
Figure 5.17 – interface de modification d’une annonce
80
5.2.2.3 Interface de recherche d’annonces
La figure 5.18 représente l’interface de recherche d’annonces pour l’utilisateur.
Figure 5.18 – Interface de recherche d’annonces
5.2.2.4 Interface de verification d’une annonce
La figure 5.19 représente l’interface de verification d’une annonce pour l’administrateur.
Figure 5.19 – Interface de verification d’une annonce
81
5.2.2.5 Interface de suppression d’un avis
La figure 5.20 représente l’interface de de suppression d’un avis pour l’administrateur.
Figure 5.20 – Interface de suppression d’un avis
5.3 Sprint 2 : Envoyer des messages, consulter les recommandations

et gérer les statistiques
Ce sprint présente le quatrième sprint de notre application. Il détaille la gestion des messages, la consultation
des recommandations et la gestion des statistiques.

Ce sprint représente la quatrième partie de notre projet.
82

En tant qu’administrateur, je souhaite gérer les statis-
Gérer les statistiques Moyenne
tiques de l’application
En tant qu’utilisateur de l’application, je souhaite envoyer
Envoyer des messages Élevée
des messages en temps réel
En tant qu’utilisateur de l’application, je souhaite consul-
Consuter les messages Élevée
ter les messages
Recevoir des notifications En tant qu’utilisateur, je souhaite Recevoir des notifica-
Moyenne
de recommandations tions de recommandations
Consulter les recomman- En tant qu’utilisateur, je souhaite consulter les recom-
Moyenne
dations mandations
Par la suite, nous présentons la phase d’analyse dont nous décrivons le diagramme de cas d’utilisation et
la description textuelle. La figure 5.21 décrit le diagramme de cas d’utilisation détaillé relatif a ce sprint ainsi
quesa description textuelle à travers le tableau 5.10
Figure 5.21 – Diagramme de cas d’utilisation envoyer des messages, des notifications et des recommanda-
tions
83
Table 5.10 – Description textuelle de cas d’utilisation du sprint 4
Clause Description
Identifiant Gérer les ressources.
l’administrateur peut gérer les statistiques et l’utilisateur peut
Résumé consulter et envoyer des message ainsi que recevoir des recom-
mandations.
Contexte de déclenche-
Authentification préalable.
ment
Si l’administrateur possède la clé d’autorisation valide,il peur gé-
rer les statistiques. Si l’utilisateur possède la clé d’autorisation
Description
valide, il peut consulter et envoyer des message ainsi que rece-
voir des recommandations.
5.3.1.3 Diagramme de cas d’utilisation détaillé de l’envoie des messages
La figure 5.22 illustre le diagramme détaillant le cas d’utilisation d’envoie d’un message ainsi que sa descrip-
tion textuelle présentée dans le tableau 5.11.
Figure 5.22 – Diagramme de cas d’utilisation envoyer des messages
Table 5.11 – Description textuelle du cas d’utilisation envoyer des messages
Cas d’utilisation Envoyer des messages

Acteur Utilisateur.
Post conditions Api-token valide.
Scénario nominal 1- L’administrateur demande l’interface des messages.
3- L’administrateur saisit le message et l’envoie.
4- Le système envoie le messages a tous les utilisateurs qui parti-
cipent a la discussion.
Scénario alternatif aucun
84
5.3.1.4 Diagramme de cas d’utilisation détaillé de la consultation des recommandations
La figure 5.23 illustre le diagramme détaillant le cas d’utilisation de la consultation des recommandations
Figure 5.23 – Diagramme de cas d’utilisation aconsulter les recommandations
Table 5.12 – Description textuelle du cas d’utilisation consulter les recommandations
Cas d’utilisation Consulter les recommandations

Acteur Utilisateur.
le système va rediriger l’utilisateur vers les annonces recomman-
Post conditions
dées.
1-Le système cherche les annonces compatibles avec celles de
Scénario nominal l’utilisateur en inversant les étiquettes. S’il en trouve,il lui envoie
une notification.
3- Le système ne trouve aucune annonce qui peut interesser
l’utilisateur .
5.3.1.5 Diagramme de cas d’utilisation détaillé de la gestion des statistiques
La figure 5.24 illustre le diagramme détaillant le cas d’utilisation de la gestion des statistiques de l’application
Figure 5.24 – Diagramme de cas d’utilisation gérer les statistiques
85
Table 5.13 – Description textuelle du cas d’utilisation gérer les statistiques
Cas d’utilisation Gérer les statistiques

Post conditions ? ?.
Scénario nominal 1- L’administrateur demande l’interface des statistiques.
3- L’administrateur consulte les statistiques de l’application.
Scénario alternatif aucun.
5.3.2 Conception
Dans cette partie, nous passons à la deuxième activité dans le sprint de la gestion des messages , recomman-
dations et statistiques qui est la conception où nous présentons les diagrammes de séquences, d’activités ainsi
que le diagramme de classes de ce sprint.
5.3.2.1 Diagramme de séquence pour le scénario gérer les statistiques
Le diagramme illustré dans la figure 5.25 est le séquencement des interactions entre l’adminidtrateur et les
objets du système responsable des statistiques.
Dès la demande de l’administrateur de la page des statistiques, le composant côté client consomme le web
service de gestion des statistiques exposé par le contrôleur responsable de la partie back-end, ce dernier extrait
les données et renvoi un résultat sous forme de JSON.
composant se met a jours et affiche les différents graphiques contenant les statistiques des données.
86
Figure 5.25 – Diagramme de séquence pour le scénario gérer les statistiques
5.3.2.2 Diagramme de séquence pour le scénario envoyer des messages
Le diagramme illustré dans la figure 5.26 est le séquencement des interactions entre l’utilisateur et les objets
du système responsable de l’envoie des messages .
Dès la validation de l’administrateur après la saisie du message, le composant côté client consomme le web
service d’envoie de messages exposé par le contrôleur responsable de la partie back-end, ce dernier envoie le
message en temps réel a travers Firebase cloud Messaging(FCM) et renvoi un résultat sous forme de JSON.
composant se met a jours en affichant le message envoyé.
87
Figure 5.26 – Diagramme de séquence pour le scénario envoyer des messages
5.3.2.3 Diagramme d’activité envoyer un message

• L’utilisateur demande l’interface d’envoie de messages.
• L’utilisateur saisie le texte du message.
• Le système envoie le message.
• Si le message est envoyé, l’interface se met a jours pour afficher le message.
88
Figure 5.27 – Diagramme d’activité envoyer un message
La figure 5.28 décrit le diagramme de classes que nous avons utilisé pour développer le quatrième sprint.
Figure 5.28 – Diagramme de classe du sprint 4
5.3.3 Réalisation
89
5.3.3.1 Interface d’ajout d’envoie de messages
La figure 5.29 représente l’interface d’envoie de messages pour l’utilisateur.
Figure 5.29 – Interface d’envoie de messages
5.3.3.2 Interface de consultation des statistiques
La figure 5.30 représente l’interface de consultation des statistiques pour l’administrateur.
Figure 5.30 – Interface de consultation des statistiques
5.4 Conclusion
Dans ce chapitre, nous avons décrit les étapes effectuées durant le deuxième release qui a été consacrée
pour la gestion des annonces,avis et signal chat. Pour chaque sprint, nous avons commencé par une spécification
fonctionnelle, ensuite, nous avons détaillé la conception en présentant les diagrammes de séquences et de classes.
Enfin, nous avons clôturé par la présentation de la réalisation via les interfaces Homme-Machine.
90
Conclusion Générale
L’objectif visé à travers ce rapport est de présenter notre application mobile d’échange de bien et de services
réalisée au cours de notre stage de projet de fin d’études au sein de la société Anypli.
Dans un premier temps, nous avons consacré nos réflexions à l’étude de l’existant, et nous avons critiqué les
applications existantes dans le marché pour améliorer notre application.
Cette étude nous a permis de passer à une phase plus importante qui est : citer les besoins de l’application
et les répartir en besoins fonctionnels et non fonctionnels. Une phase de conception détaillée a précédé l’im-
plémentation de ce projet. En effet, on a pu développer une application mobile qui répond éventuellement aux
exigences soulignés pendant l’analyse et la conception.
Nous avons également appris à appliquer les bonnes pratiques de la réalisation d’un produit de qualité,
tout en appliquant Scrum comme une méthodologie de développement. Mis à part l’instabilité des besoins,
les obstacles techniques rencontrés, ainsi que la période critique de la pandémie, nous considérons que notre
travail a atteint les objectifs définis au niveau du Backlog produit. Néanmoins, il reste toujours susceptible à
être amélioré et à évoluer.
Ce stage était une opportunité pour observer le déroulement de la vie professionnelle et les difficultés que
rencontre chaque membre de la sociétéé au quotidien pour faire évoluer les projets.
Chaque jour les membres de l’équipe alternent des tâches d’organisation, de réflexion, de débuggage, d’amé-
lioration ou même de documentation. Cela nous a permis de nous rendre compte des différentes tâches auxquelles
nous serons confronté et que parfois la connaissance seule ne suffit pas pour résoudre les problèmes. Cela nous
permet de dire que rien n’est acquis et que le travail d’ingénieur est une formation et un apprentissage de tous
les jours. Ce projet est un noyau sur lequel on peut prévoir plusieurs perspectives :
• Rendre cette application disponible sur Android.
• Possibilité de signaler un utilisateur.
• Affichage des annonces sur une carte indiquant leurs emplacements.
• Création d’une sorte de monnaie électronique, virtuelle pour les utilisateurs qui garantira certains prévi-
lèges.
91
Nétographie
[1] site officiel documentation Laravel : http ://github.com/laravel-france/documentation/ [Accés le 11-Mai-

2021]
[2] article sur Laravel : https ://www.memoireonline.com [Accés le 16-Mai-2021]
[3] site officiel de JetBrains : https ://www.jetbrains.com [Accés le 17-Mai-2021]
[4] site officiel de documentation de Apple : https ://developer.apple.com/ [Accés le 17-Mai-2021]
[5] tutoriel laravel : https ://developer.mozilla.org/ [Accés le 18-Mai-2021]
[6] site officielle de Apple : https ://www.apple.com/ [Accés le 20-Mai-2021]
[7] article sur ReactJs : https ://adventy.org/ [Accés le 21-Mai-2021]
[8] tutoriel ReactJs : https ://www.numendo.com/ [Accés le 27-Mai-2021]
[9] article sur Swagguer : https ://kinsta.com/ [Accés le 27-Mai-2021]
[10] article sur TrocWoah : https ://www2.itroom.fr/ [Accés le 27-Mai-2021]
[11] article sur Swouitch : www.ionos.fr/ [Accés le 30-Mai-2021]
[12] tutoriel ReactJs :https ://fr.accentsconagua.com/ [Accés le 30-Mai-2021]
[13] article sur Netbedloo :https ://www.magazine-avantages.fr/ [Accés le 31-Mai-2021]
[14] site officiel Firebase :https ://docs.microsoft.com/en-us/xamarin/android/data-cloud/google-
messaging/firebase-cloud-messaging/ [Accés le 11-juin-2021]
92
93

Memoire

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Memoire

Transféré par

Droits d'auteur :

Formats disponibles

1

Ecole Supérieure PRivée d’Ingénieurs de Monastir

Conception et développement d’une application

2 Analyse et spécification des besoins 13

4 Realease 1 : Gestion de l’authentification et des ressources de l’application 36

1.1 Logo Anypli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 Logo Draw.io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1 Diagramme de cas d’utilisation du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

1.1 Tableau comparatif de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Tableau du Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

1.2 Présentation du projet

1.3 Organisme d’accueil

1.3.1 Présentation de la société

Figure 1.1 – Logo Anypli

1.3.2 Activités de la société

1.5 Étude de l’existant

Figure 1.3 – Logo de Swouitch

Figure 1.4 – Logo de TrocWoah

1.5.4 Critique de l’existant

Application Netbedloo Swouitch TrocWoah

1.6 Solution proposée

1.7 Méthodologie de gestion du projet

Thème Approche traditionnelle Approche agile

1.7.1 Choix de la méthodologie : Méthodologie agile

1.7.2 La méthodologie SCRUM

1.7.2.1 Les rôles dans SCRUM

1.7.2.2 Les réunions dans SCRUM

1.7.2.3 Les artefacts de communication dans SCRUM

Figure 1.8 – Récapitulatif de la méthodologie Scrum

Analyse et spécification des besoins

2.2 Analyse des besoins

2.2.1 Identification des acteurs

2.2.2 Les besoins fonctionnels

2.2.3 Les besoins non fonctionnels

2.3 Élaboration du Backlog produit

2.4 Planification des sprints

Table 2.2 – Planification des sprints

Thème Release 1 Release 2

2.5 Analyse globale

Figure 2.1 – Diagramme de cas d’utilisation global

2.5.2 Diagramme de classes global

Figure 2.2 – Diagramme de classes global

3.2 Environnement de développement et choix techniques

3.2.1 Environnement matériel

3.2.2 Environnement logiciel

3.2.2.1 Outils de conception

Figure 3.1 – Logo Draw.io

3.2.2.2 Outil de prototypage et design

Figure 3.2 – Logo Adobe XD

3.2.2.3 Outils de test des APIs

Figure 3.3 – Logo Postman

3.2.2.4 Outil de gestion de base de données

3.2.2.5 Outil de rédaction de rapport

Figure 3.5 – Logo Overleaf

3.2.2.6 Outils de développement

Figure 3.6 – Logo Vagrant

Figure 3.7 – Logo Laravel Homestead

Figure 3.8 – Logo MySQL

3.2.3 Environnement de développement intégré (IDE)

Figure 3.10 – Logo WebStorm