OumaymaissaRapport PFE-22

J’autorise les étudiantes à faire le dépôt de leurs rapport de stage en vue d’une soutenance.
Encadrant académique, Monsieur Ahmad DJEMAL
Signature
J’autorise les étudiantes à faire le dépôt de leurs rapport de stage en vue d’une soutenance.
Encadrant professionnel, Monsieur Ahmed Rabii ZAYET
Signature et cachet
Dédicaces
J’ai le grand plaisir de dédier ce travail
A mon très cher père Mohamed A l’homme qui est mon précieux offre du
Dieu, qui doit ma vie, ma réussite et tout mon respect, je dédie cet événement
marquant de ma vie en espérant que tu vas trouver de quoi être fier et honoré.
A mon adorable mère Lamia A la femme qui a souffert sans me laisser
souffrir, qui n’a jamais dit non à mes exigences et qui n’a épargné aucun
effort pour me rendre heureuse. Ce travail est dédié pour toi maman chérie
comme signe de reconnaissance et de remerciements.

A mes sœurs Mariem et Marwa et leurs maris Ayman et Rami Vous n’avez
jamais cessé de me conseiller, encourager et soutenir tout au long de mes

études. Merci pour tout. J’espère que vous trouverez dans ce travail un
témoignage de toute la gratitude et amour que je vous dois.

A tous mes chers amis,Houssem-A , Wassim , Houssem-H et Rihem Vous
avez su être ma seconde famille. Vous avez continué à croire en moi même
lorsque je cesse de le faire. Je ne remercierai jamais assez le bon seigneur de
vous avoir mis sur mon chemin. Merci pour tout A tous ceux qui me sont
chers et que me ont omis de citer Que ce travail soit pour vous le témoignage
de nos sentiments les plus sincères et les plus affectueux.

Sans oublier mon binôme et ma meilleure amie Oumaima Merci pour ton
soutien moral, la patience, et ta compréhension tout au long de ce projet.

BENABDALLAH MAYSSA
ii
Dédicaces
J’ai le grand plaisir de dédier ce travail
A mon très cher père Noureddine. Je te dédie ce travail en signe de mon

infinie reconnaissance. Tu t’es sacrifié corps et âme pour ma réussite et mon
bonheur. L’amour et affection que te porte sont infinis. Il me reste encore

beaucoup à faire pour témoigner ma gratitude ; mais pour le moment je t’offre
ce que j’ai de plus précieux ; Ce fruit de toutes ces années de travail.

A ma tendre mère Hela Les mots me manquent pour t’exprimer ce que je
ressens.Je t’aime tellement ma chère mère et je veillerai à te rendre fière

jusqu’à mon dernier souffle. Ce travail t’est dédié comme signe de
sempiternelle tendresse.
A ma sœur Dorra et mon frère Mohamed Amine Merci pour vos soutiens tout
au long de ces années. Des mots ne pourront jamais exprimer la profondeur

de ma considération, ma reconnaissance et mon amour éternel.
A mon cousin Badreddine T’étais pour moi un frère aîné, tu étais toujours
près de moi dans les meilleurs et les pires moments. Tu m’as trop supporté.
A mes amis Wassim Houssem et Rihem qui m’ont apporté leur soutien moral
et leur amitié , qui m’ont prodigué des encouragements et se sont données la
peine de me soutenir durant ce stage .

Sans oublier mon binôme et ma meilleure amie Maissa Merci pour ton soutien
moral, la patience, et ta compréhension tout au long de ce projet.

BOUDAOUARA OUMAIMA
iii
Remerciements
Nous voudrons en premier lieu remercier notre encadrant académique Mr
Ahmad Djemal pour sa disponibilité et ses conseils pour la mission

mentionnée dans ce rapport.
Aucun mot ne peut exprimer notre reconnaissance et notre infinie gratitude

envers lui.
Merci infiniment surtout a notre superviseur Mr Laurent Cerisier pour ses

conseils, sa confiance et ses encouragements quotidiens pendant ce stage.
Nous tenons à remercier aussi notre encadrant au sein de la société Mr

Ahmed Rabii zayet pour son accompagnement, son soutien, ses efforts et la
formation qu’il nous a procuré tout au long de cette expérience. Nos gratitudes
envers lui est au delà de ce que les mot peuvent décrire
Encore, nous voudrons remercier tous les membres de l’équipe de la société

FLYDEV offshore pour leur hospitalité et leurs encouragements.
Nous remercions aussi tous les membres de l’équipe pédagogique et les

enseignants de L’Institut Supérieur des Etudes Technologiques de Sfax
et tous les formateurs qui ont assuré notre formation et notre encadrement.
Nous exprimons également nos sincère gratitudes à tous ceux qui ont contribué
de différentes manières à la réalisation de notre projet de fin d’études.
iv
Table des matières
Introduction générale 1
1 Contexte générale du projet 2

1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Présentation de l’entreprise FLYDEV . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Catalogue des services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Organigramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Cadre de stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Présentation génerale du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 SWOT analyse [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7.1 Symfony 5.4.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7.2 ReactJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7.3 OpenAPI (Swaggr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7.4 MySQL 5.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.8 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.9 Outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.9.1 GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.9.2 Logo Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.9.3 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.9.4 PhpStorm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.9.5 Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.9.6 Balsamiq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.9.7 Google Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.9.8 Jira Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.10 Choix méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
v
1.10.1 Les méthodes agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.10.2 Méthodologie adoptée : SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.11 Présentation de l’équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.12 Chronogramme de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 Sprint 0 « Etude fonctionnelle, méthodologique, architectural et technique » 17

2.1 Identification des besoins fonctionnels et non fonctionnels . . . . . . . . . . . . . . . 18
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.2 Identification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . 18
2.1.3 Identification des besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . 19
2.2 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Planifications des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6 Architecture Logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7 Diagramme de classes global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3 Sprint 1 : Authentification et gestion de profil 30

3.1 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Les diagrammes d’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.1 Cas d’utilisation « S’authentifier »et«Réinitialiser mot de passe » . . . . . . 33
3.2.2 Description textuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.3 Cas d’utilisation « Gérer Profil » . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.4 Description textuelle du cas d’utilisation « Consulter Profil » . . . . . . . . . 35
3.2.5 Description textuelle du cas d’utilisation «Mettre à jour les données de Profil» 35
3.2.6 Description textuelle du cas d’utilisation «Changer Image de Profil» . . . . . 36
3.2.7 Description textuelle du cas d’utilisation « Inscrption » . . . . . . . . . . . . 36
3.2.8 Description textuelle du cas d’utilisation « Reinitialiser Mot de passe » . . . . 37
3.3 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4.1 Diagramme de classes «Utilisateur » . . . . . . . . . . . . . . . . . . . . . . . 39
3.5 Sécurité de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
vi
3.5.1 JWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.7 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.7.1 Maquettes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.7.2 REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.7.3 Interfaces graphiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4 Sprint 2 : Gestion des accés , des Expériences 48

4.1 sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.1 Diagramme de cas d’utilisation « Gestion opération » . . . . . . . . . . . . . 52
4.2.2 Description du cas d’utilisation « Gestion Opération » . . . . . . . . . . . . . 52
4.2.3 Diagramme du cas d’utilisation « Demande accés » . . . . . . . . . . . . . . . 53
4.2.4 Description textuelle du cas d’utilisation « Gérer accés » . . . . . . . . . . . . 55
4.2.5 Description textuelle du cas d’utilisation « Recherche d’un professionnel de
santé » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.6 Description textuelle du cas d’utilisation « Consulter les détails de la demande » 56
4.2.7 Description textuelle du cas d’utilisation « Confirmer ou rejeter une demande » 56
4.3 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.6.1 Maquettes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.6.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5 Sprint 3 : Gestion dossier 66

5.1 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2.2 Description du cas d’utilisation « Gestion dossier » . . . . . . . . . . . . . . . 70
5.3.1 Diagramme de séquence « Ajouter fréquence cardiaque » . . . . . . . . . . . 72
vii
5.3.2 Diagramme de séquence «Supprimer fréquence cardiaque » . . . . . . . . . . 73
5.5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.6.1 Maquettes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.6.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6 Sprint 4 : Gestion Question-Reponse et tableau de bord 82

6.1 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.2.1 Diagramme de cas d’utilisation «Gestion Question-Reponse» . . . . . . . . . 85
6.2.2 Description textuelle «Ajouter question» . . . . . . . . . . . . . . . . . . . . 85
6.3.1 Diagramme de séquence du cas d’utilisation « Répondre au question » . . . . 86
6.3.2 Diagramme de séquence du cas d’utilisation « Ajouter question » . . . . . . . 86
6.4 Diagrammes de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.6.1 Maquettes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.6.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
CONCLUSION GÉNÉRALE 92
BIBLIOGRAPHIE 92
viii
Table des figures
1.1 Logo FLYDEV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Organigramme de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Analyse SWOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Logo Symfony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Logo React . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Logo MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.8 Logo GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.9 Logo Postman (version 7.27.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.10 Visual Studio Code (version 1.47.0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.11 Logo PhpStorm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.12 Logo overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.13 Logo Balsamiq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.14 Logo Google Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.15 Logo Jira Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.16 Cycle de vie Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.17 Chronogramme de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1 Temps de réponse du serveur pour les statistiques . . . . . . . . . . . . . . . . . . . . 20

2.2 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Plannification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Architecture physique de notre solution . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5 Architecture physique de notre solution . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6 Diagramme de classes globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1 Diagramme de cas d’utilisation S’authentifier et réinitialiser mot de passe . . . . . . 33

3.2 Diagramme de cas d’utilisation Gérer Profil . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Diagramme de séquence du cas d’utilisation « s’authentifier » . . . . . . . . . . . . . 38
3.4 Diagramme de séquence du cas d’utilisation « Reinitialiser mot de passe » . . . . . . 38
3.5 Diagramme de classes utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
ix
Table des figures
3.6 Exemple d’un jwt généré par LexikJWTAuthenticationBundle . . . . . . . . . . . . 40

3.7 Test de la methode de récupération profile d’un patient . . . . . . . . . . . . . . . . 41
3.8 Maquette consulter profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.9 Maquette d’authentification et de réinitialisation mot de passe . . . . . . . . . . . . . 42
3.10 Maquette de gestion de Profil patient . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.11 Interface d’authentification d’un professionnel de santé/patient . . . . . . . . . . . . 44
3.12 Interface d’authentification d’un Administrateur . . . . . . . . . . . . . . . . . . . . 44
3.13 Interface de réinitialisation de mot de passe . . . . . . . . . . . . . . . . . . . . . . . 45
3.14 Un E-mail de récupération du mot de passe . . . . . . . . . . . . . . . . . . . . . . . 45
3.15 Interface de consultation des information de profile . . . . . . . . . . . . . . . . . . . 46
3.16 Interface de changement de mot de passe . . . . . . . . . . . . . . . . . . . . . . . . 46
3.17 Interface de modification de profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1 Diagramme de cas d’utilisation « Gérer opération » . . . . . . . . . . . . . . . . . . . 52

4.2 Diagramme du cas d’utilisation « Gérer accés» . . . . . . . . . . . . . . . . . . . . . 54
4.3 Diagramme de séquence de cas d’utilisation « Supprimer Expérience» . . . . . . . . . 57
4.4 Diagramme de classes du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.5 Test de l’API Patient en attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.6 Maquette « Ajouter une expérience » . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.7 Maquette « choix une spécialité » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.8 Maquette « choisir un professionel de santé » . . . . . . . . . . . . . . . . . . . . . . 60
4.9 Interface « Gestion expérience » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.10 Interface « choix d’une spécialité » . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.11 Interface « Recherche d’ un professionnel de santé » . . . . . . . . . . . . . . . . . . 62
4.12 Interface « Demande d’accés , consulter un professionnel de santé » . . . . . . . . . . 63
4.13 Interface «traitement des accés » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.14 Interface «consulter les medecins qui ont l’accés a un compte patient» . . . . . . . . 64
4.15 Interface «Liste des Demandes des patients» . . . . . . . . . . . . . . . . . . . . . . . 64
4.16 Interface «Liste des Demandes des professionnels de santé » . . . . . . . . . . . . . . 65
5.1 Diagramme de cas d’utilisation «gestion dossier . . . . . . . . . . . . . . . . . . . . . 70

5.2 Diagramme de séquence de cas d’utilisation «Ajouter fréquence cardiaque» . . . . . . 72
x
5.3 Diagramme de séquence de cas d’utilisation «Supprimer fréquence cardiaque» . . . . 73
5.4 Diagramme de classes gestion dossier . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.5 test de l’API liste des vaccinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.6 Maquette « traitement » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.7 Maquette « Mesure » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.8 Interface « profil médical » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.9 Interface « les mesures d’un profil médical » . . . . . . . . . . . . . . . . . . . . . . . 76
5.10 Interface « Ajout traitement » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.11 Interface « Historique des traitements » . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.12 Interface « Ajout Hospitalisation par professionnel de santé » . . . . . . . . . . . . . 78
5.13 Swagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.14 Code de l’implémentation de l ’API Ajout Hospitalisation par docteur . . . . . . . . 79
5.15 Interface « Liste des hospitalisation » . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.16 Interface « Liste des ordonnances » . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.17 Interface « Liste patient » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.18 Interface « Liste des professionnels de santé » . . . . . . . . . . . . . . . . . . . . . . 81
6.1 Diagramme de cas d’utilisation « Question - Reponse » . . . . . . . . . . . . . . . . 85

6.2 Diagramme de séquence «Répondre aux questions» » . . . . . . . . . . . . . . . . . . 86
6.3 Diagramme de séquence «Ajouter question» » . . . . . . . . . . . . . . . . . . . . . . 86
6.4 Test de la méthode ajout question . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.5 Interface « Liste des question médicaux » . . . . . . . . . . . . . . . . . . . . . . . . 88
6.6 Interface « Liste des questions » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.7 Interface « Ajouter un question » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.8 Interface « tableau de bord d’un patient » . . . . . . . . . . . . . . . . . . . . . . . . 90
6.9 Interface « tableau de bord d’un professionnel de santé » . . . . . . . . . . . . . . . . 90
xi
Liste des tableaux
1.1 équipe du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1 product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1 Sprint backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2 Description Textuelle du cas d’utilisation "S’authentifier" . . . . . . . . . . . . . . . 34
3.3 Description textuelle du cas d’utilisation « Consulter Profil » . . . . . . . . . . . . . 35
3.4 Description textuelle du cas d’utilisation « Mettre à jour les données de Profil » . . . 35
3.5 Description textuelle du cas d’utilisation « Mettre à jour les données de Profil » . . . 36
3.6 Description textuelle du cas d’utilisation « Inscription » . . . . . . . . . . . . . . . . 36
3.7 Description textuelle du cas d’utilisation « Réinitialiser mot de passe » . . . . . . . . 37
4.2 sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3 Description textuelle du cas d’utilisation « Ajouter expérience » . . . . . . . . . . . 52
4.4 Description textuelle du cas d’utilisation « Modifier une expérience » . . . . . . . . 53
4.5 Description textuelle de cas d’utilisation « Supprimer une expérience » . . . . . . . 53
4.6 Description textuelle du cas d’utilisation « recherche d’un professionnel de santé » . 55
4.7 Description textuelle du cas d’utilisation « recherche d’un professionel de santé » . . 55
4.8 Description textuelle du cas d’utilisati« Consulter les détails de la demande »» . . . 56
4.9 Description textuelle du cas d’utilisation « traiter la demande » . . . . . . . . . . . . 56
5.2 sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.3 Description textuelle du cas d’utilisation « Ajout des informations médicaux » . . . . 71
5.4 Description textuelle du cas d’utilisation « Consulter historique » . . . . . . . . . . . 71
5.5 Description textuelle du cas d’utilisation « Chercher patient - professionnel de santé » 72
6.2 Description textuelle du cas d’utilisation « Ajouter question » . . . . . . . . . . . . . 85
xii
Liste des abréviations
— API = Application Programming Interface
— CSS = Cascading Style Sheets
— CU = Cas d’Utilisation
— DOM = Document Object Model
— HTML = HyperText Markup Language
— HTTP = Hypertext Transfer Protocol
— JSON = JavaScript Object Notation
— JWT = JSON Web Token
— PHP = Hypertext Preprocessor
— REST = Representational State Transfer
— UI = User Interface
— UML = Unified Modeling Language.
— URL = Uniform Resource Locator
— VSCode = Visual Studio Code.
xiii
Introduction générale
Le projet de fin d’études est une initiation à la vie professionnelle vu que c’est une opportunité
pour valoriser nos compétences et nos connaissances dans le domaine informatique grâce à nos cursus
scolaires en particulier à l’Institut Supérieur des Etudes Technologiques de Sfax.
C’est le fruit de nos travaux pour obtenir nos diplômes de licences appliquées en développement de
systèmes d’information.
Afin de faciliter les taches des médecins, les personnels de santé ont migrés vers le domaine de
l’informatique avec des moyens assez avancés, notamment les plateformes web.
A titre d’exemple, notre projet de fin d’études est effectué au sein de la société FLYDEV où on
a développé une application web sous le nom «Espace Numérique De Santé » qui permet à ses
utilisateurs (médecins et patients) de partager les données.
Dans ce contexte, notre activité consiste à développer cette application.
Une application qui conserve, centralise et sécurise toutes les informations de santé d’un patient.
Tout patient peut partager son dossier avec les professionnels de santé de son choix, et ainsi être
soigné plus précisément. En effet rien n’est plus gratifiant que de donner un tel service afin de sauver
une vie.
Le présent rapport est structuré en 6 chapitres.
• Chapitre 1 : « Contexte général de projet »présentera en premier lieu l’organisme d’accueil
et leurs services puis abordera la présentation du projet, l’étude de l’existant et enfin exposera
la solution proposée.
• Chapitre 2 : « (Sprint 0) Etude fonctionnelle, méthodologique, architectural et technique » .
• Chapitre 3 : « (Sprint 1) : Authentification et gestion profil »
• Chapitre 4 : « (Sprint 2) :Gestion des accès , des opérations »
• Chapitre 5 : « (Sprint 3) :Gestion des dossiers »
• Chapitre 6 : « (Sprint 4) : Gestion Question-Reponse et tableau de bord »
1
Chapitre 1
Contexte générale du projet
Plan
1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . 3
2 Cadre de stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Présentation génerale du projet . . . . . . . . . . . . . . . . . . . . . . . 5
4 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9 Outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10 Choix méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11 Présentation de l’équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12 Chronogramme de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Chapitre 1. Contexte générale du projet
Introduction
Le succès de toute étude dépend de la qualité de son départ. C’est pour cette raison que
ce premier chapitre est dédié à l’étude du cadre de projet, ainsi, qu’à sa compréhension globale.
Nous allons entamer, dans la première partie, la présentation de l’organisme d’accueil. Par la suite,
nous allons enchaîner avec le contexte du projet, l’existant, la problématique ainsi que la solution
proposée.
1.1 Présentation de l’organisme d’accueil
Dans cette partie, nous allons présenter l’organisme d’accueil où a été réalisé notre projet de
fin d’études. Pour ce faire, nous allons commencer par introduire l’entreprise mère.
1.1.1 Présentation de l’entreprise FLYDEV
FLYDEV est une société française immatriculée au registre du commerce est active depuis
3 ans. Elle est spécialisée dans le secteur d’activité de la programmation informatique on peut dire
aussi que c’est une agence digitale full service basée à Paris et Tunis
La figure 1.17 présente le logo du groupe FLYDEV.[1]
Figure 1.1 : Logo FLYDEV
1.1.2 Catalogue des services
En tant que société de services, FLYDEV prend en charge les projets de A jusqu’à Z, elle
met à la disposition des clients des compétences dans les domaines de :
• Frontend Backend : Sites Web réactifs Applications Web, Applications monopage (SPA),API
RESTful,Mean Stack.
• UI / UX : UX Design,UI Design ,Gravit, Pixlr ,Bannières ,Branding identité
3
• Développement Web : WordPress,Drupal, ,Blog sur mesure Gestion des actualités ,Système
d’adhésion , Applications PHP performantes ,Portails Web
• Outsourcing / Offshoring : Équipe de développement dédiée à Tunis , Chef de projet dédié

à Paris communication constante
• Commerce électronique : Commerces en ligne sur Magento et Prestashop.
1.1.3 Organigramme
Figure 1.2 : Organigramme de la société
1.2 Cadre de stage
Le présent projet intitulé ENS "Espace Numérique de Santé" est réalisé dans le cadre
d’un projet de fin d’études en vue de l’acquisition du diplôme national de licence en technologies
d’informatique. Ce projet a été effectué au sein de l’entreprise FLYDEV durant 14 semaines.
4
1.3 Présentation génerale du projet
Aujourd’hui, le secteur de la santé évolue rapidement grâce aux technologies digitales qui
bouleversent les relations entre médecins et patients voire également entre les médecins eux-mêmes.
A l’heure de cette crise sanitaire, le Covid-19, les patients prennent des rendez-vous sur Internet ;
effectuent de la téléconsultation ..., la santé est résolument entrée dans une ère nouvelle. Dans ce
cadre , on a réalisé notre projet de fin d’études intitulé ENS "Espace Numérique de Santé" qui
présente un dossier médical partagé entre les patients et les professionnels de santé . Dans lequel il
y’a partage des informations de santé : traitements, résultats d’examens, allergies... en toute sécurité.
1.3.1 SWOT analyse [2]
Figure 1.3 : Analyse SWOT
La méthode d’acronyme « SWOT » (Forces, Faiblesses, Opportunités, Menaces) est utile aux
acteurs de la prévention pour approfondir les réflexions sur les stratégies et politiques en matière de
santé et sécurité au travail (SST) l’analyse aide à gérer les risques en amont du processus de décision
.
1.4 Etude de l’existant
med.tn : un service complet de gestion de cabinet médical, qui vous permet de trouver
rapidement un médecin le plus proche de chez vous et de prendre rendez-vous en ligne gratuitement.
lerdvmedical.tn : L’annuaire médical en ligne qui facilite la communication entre les citoyens et
les professionnels de santé et leurs permet de prendre un rendez-vous à distance, avec des mise a
jours garanties.
5
1.5 Problématique
Parmi les causes qui poussent FLYDEV à développer cette plateforme , c’est que les solutions
existantes manquent la notion de partage qui va faciliter les tâches et assurer un meilleur suivi de la
santé du patient.P lus besoin d’apporter ses anciennes radios, ordonnances, courriers. . ., pour justifier
de ses antécédents médicaux. Plus besoin non plus de se souvenir des examens ou médicaments
prescrits. Alors ,le ENS recense toutes ses informations médicales et permet ainsi une meilleure
gestion de sa santé.
1.6 Solution proposée
Après avoir dégagé notre problématique, le défi de ce projet est de faire une conception et de
mettre en place une solution de partage qui comble les insuffisances énumérées précédemment. Cette
solution doit être unique et partagée par l’ensemble des collaborateurs de FLYDEV France et Tunisie
qui permet une meilleure transmission de l’information, favorise le partage et la communication entre
les professionnels de santé et les patients.
1.7 Choix technologiques
Le choix technologique doit être structurant et lié à l’aspect général du projet. Ce choix se
base généralement sur 3 axes :
• Le système de gestion de bases de données
• Le langage de développement
• Les outils de développement
1.7.1 Symfony 5.4.8
Symfony est un ensemble de composants PHP.[4] Il fournit des fonctionnalités modulables

et adaptables qui permettent de faciliter et d’accélérer le développement d’un site web. Il constitue
aujourd’hui un environnement stable, reconnu à l’échelle international. Symfony, est choisi comme
une base de développement pour beaucoup de projets Open Source et a depuis de nombreuses années
conquit le monde de la Tech, au point même que PrestaShop, Laravel ou encore eZ Publish l’ont
imbriqué dans leur propre solution
La figure 1.17 présente le logo du Symfony.
6
Figure 1.4 : Logo Symfony
Le choix de Symfony est fait pour plusieurs raisons : [3]
• Une fiabilité approuvée : En tant que logiciel libre Symfony crée des applications robustes et
offre aux développeurs un contrôle total. C’est un Framework comfortable, flexible et accessible.
• Des tests facilités : Pour garantir la fiabilité et la stabilité de notre application chaque ligne
de code doit être testée. Grâce à l’utilisation de la bibliothèque indépendante « PHPUnit », le
test unitaire est assez facile d’utilisation.
• Une communauté solide : Symfony est un framework reconnu dans le monde et présent dans
le TOP 3 mondial des frameworks PHP open source. Une des grandes forces du framework est
sans aucune doute sa forte communauté internationale
• La sécurité : Symfony intègre des mesures de sécurité préventives pour lutter contre les failles et
attaques XSS, CSRF et injection SQL. Symfony embarque systématiquement ces mécanismes
de sécurité, sans avoir à les implémenter à chaque fois.
• Performances
• Son plus gros avantage réside dans les possibilités d’amélioration des performances qu’il offre
nativement l’optimisation du code pour permettre d’éviter de recompiler le code PHP à chaque
appel et donc pouvoir afficher plus rapidement les pages du site, aussi les fonctions de cache
HTTP natives permettant de mettre en place facilement une stratégie de cache côté visiteur
et côté serveur.
1.7.2 ReactJS
React est une bibliothèque JavaScript libre développée par Facebook depuis 2013. Le but
principal de cette bibliothèque est de faciliter la création d’application web monopage, via la création
de composants dépendant d’un état et générant une page HTML à chaque changement d’état[6]
7
Figure 1.5 : Logo React
Le choix de React JS est fait pour plusieurs raisons : [5]
• Flexibilité La structure modulaire de ReactJS en fait l’un des meilleurs outils flexibles. Cela
facilite la maintenance, ce qui permet d’économiser beaucoup de temps de développement et
d’argent à long terme. Les applications créées avec cet outil sont faciles à mettre à l’échelle, à
entretenir et deviennent très flexibles.
• Rapidité : ReactJS crée son propre DOM virtuel où sont rattachés vos composants. Cette
approche vous donne énormément de flexibilité et des performances exceptionnelles, car ReactJS
calcule quel changement dans le DOM a besoin d’être fait, et change juste LA PARTIE qui
a besoin d’être mise à jour. De cette façon, ReactJS évite des opérations coûteuses dans le
DOM.
• Intelligibilité : ReactJS produit du code « propre » (simple à lire), sa lecture permet de

déterminer immédiatement quelles sont les fonctionnalités de votre application. Ce qui est
essentiel pour la maintenance et l’expansion de votre projet dans le temps.
1.7.3 OpenAPI (Swaggr)
La spécification OpenAPI est un format de description d’API pour les API REST. Un fichier
OpenAPI vous permet de décrire l’intégralité de votre API. Les spécifications de l’API peuvent
être écrites en YAML ou JSON. Le format est facile à apprendre et lisible pour les humains et
les machines. Swagger est un ensemble d’outils open source construits autour de la spécification
OpenAPI qui va nous aider à concevoir, construire, documenter et consommer des API REST.
8
1.7.4 MySQL 5.7
Figure 1.6 : Logo MySQL
MySQL est un système de gestion de bases de données relationnelles (SGBDR) open-source

puissant et gratuit. Il fait partie des logiciels de gestion de base de données les plus utilisés au monde,
autant par le grand public que par des professionnels, en concurrence avec Oracle, PostgreSQL et
Microsoft SQL Server.[7]
1.8 Environnement matériel
Nous avons élaboré ce travail en utilisant 2 ordinateurs portables qui représentent les machines
de développement possédant les caractéristiques suivantes :
Figure 1.7 : Environnement matériel
9
1.9 Outils utilisés
1.9.1 GitHub
Figure 1.8 : Logo GitHub
C’est un service web d’hébergement et de gestion de développement de logiciels, utilisant le

logiciel de gestion de versions Git. Le site assure également un contrôle d’accès et des fonctionnalités
destinées à la collaboration comme le suivi des bugs, les demandes de fonctionnalités, la gestion de
tâches et un wiki pour chaque projet. [8]
1.9.2 Logo Postman
Figure 1.9 : Logo Postman (version 7.27.1)
C’est un outil que nous avons utilisé pour tester les web services et API. Il permet de
construire et d’exécuter des requêtes HTTP, de les stocker dans un historique afin de pouvoir les
rejouer, mais surtout de les organiser en Collections. En fait, Postman permet de consommer des
web services en utilisant ses différentes méthodes :
• GET pour la récupération des données sous différentes format connue format JSON, XML,
HTML. . .
• POST pour insérer les données.
• PUT pour la modification des données
• DELETE pour la suppression des données
10
1.9.3 Visual Studio Code
Figure 1.10 : Visual Studio Code (version 1.47.0)
Est un éditeur de code, développé par Microsoft. Il peut interpréter et compiler toute languages
à l’aide des extensions à integrer. [9]
1.9.4 PhpStorm
Figure 1.11 : Logo PhpStorm
PhpStorm est un éditeur pour PHP, HTML, CSS et JavaScript, édité par JetBrains. Il permet
d’éditer du code PHP pour les versions allant de la 5.3 à la 8.1. [10]
1.9.5 Overleaf
Figure 1.12 : Logo overleaf
Un éditeur Latex en ligne pour l’écriture des rapports. [11]
11
1.9.6 Balsamiq
Figure 1.13 : Logo Balsamiq
Balsamiq est un logiciel de conception de wireframes qui permet aux équipes de créer des
maquettes et des prototypes interactifs, mais aussi de réaliser des tests utilisateurs .
1.9.7 Google Drive
Figure 1.14 : Logo Google Drive
Google Drive est un service de stockage et de partage de fichiers dans le cloud lancé par la
société Google. Google Drive, qui regroupe Google Docs, Sheets et Slides, Drawings, est une suite
bureautique permettant de modifier des documents, des feuilles de calcul, des présentations, des
dessins, des formulaires, etc.
1.9.8 Jira Software
Figure 1.15 : Logo Jira Software
12
Jira Software fait partie d’une gamme de produits conçus pour aider les équipes de tous types
à gérer leur travail. À l’origine, Jira a été pensé comme un outil de suivi des bugs et des tickets. Mais
aujourd’hui, c’est devenu un puissant outil de gestion du travail pour toutes sortes de cas d’usage,
de la gestion des exigences et des cas de test au développement logiciel Agile. [12]
1.10 Choix méthodologique
Choisir la bonne méthodologie de gestion de projet est une étape indispensable pour réussir
notre projet. Cette méthodologie doit valoriser les objectifs de notre projet et les points forts de
l’équipe, aussi de finaliser le projet dans les délais de livraison.
1.10.1 Les méthodes agiles
Les méthodes de développement agiles se basent sur un cycle de développement qui attire le
client vers le centre. Ce dernier est impliqué dans la réalisation dans tous les phases de la réalisation
du projet. La méthode agile garantie au client une meilleure visibilité de la gestion et de la réalisation
du projet. L’implication de ce dernier dans le processus favorise à l’équipe d’avoir un feedback régulier
pour appliquer d’une manière directe les changements nécessaires. L’application de de cette méthode
permet d’accélérer le développement du logiciel en assurant la réalisation des livrables fonctionnels
tout au long de la durée de sa création. Le principe de base consiste à proposer une version minimale
du logiciel puis à intégrer des fonctionnalités supplémentaires à cette base, par processus itératif. Le
processus itératif regroupe une séquence d’instructions à répéter autant de fois que possible, selon
le besoin. La méthode agile repose sur quatre grands principes :
• La collaboration : Communication et cohésion d’équipe passent avant les outils et les processus.
• L’équipe : Le privilège de la relation équipe/client est mis en avant plutôt que la négociation
contractuelle.
• L’application : Préférer une application bien construite à une documentation détaillée.
• L’acceptation : Le choix de l’acceptation du changement et de la flexibilité au détriment d’un

plan rigide.
1.10.2 Méthodologie adoptée : SCRUM
La méthode de gestion SCRUM se base sur les développements itératifs à un rythme constant
qui varie entre 2-4 semaines « sprints ». Parmi les avantages d’adaptation de la méthodologie
13
Agile avec la méthode SCRUM, la diminution de la documentation au minimum pour gagner en

productivité pour nous permettre la sauvegarde de l’historique des décisions prises sur le projet du
client et d’effectuer facilement dans le futur des interventions sur la solution logicielle surtout que
Scrum est qualifié comme simple, pragmatique et transparent. La méthode Scrum se compose de 3
principaux acteurs :
• Le Product Owner : il est considéré comme le responsable du Product Backlog, son rôle est
de définir les spécifications fonctionnelles, établit la priorité des fonctionnalités à développer
ou corriger, coordonne l’implication des utilisateurs et des parties prenantes, ce qui le permet
de considérer comme l’interface entre l’utilisateur, le Scrum Master et les équipes chargées du
développement.
• Le Scrum Master membre de l’équipe qui s’assure que les principes et les valeurs de Scrum
sont respectés pour garantir la constante amélioration des performances et donc la réussite
d’un projet agile. Il est considéré comme le garant de la méthode Scrum.
• L’équipe opérationalle c’est l’équipe Scrum qui va mettre en œuvre les solutions techniques,
réaliser les développements. Tous les membres de l’équipe apportent leur savoir-faire pour
accomplir les tâches. Elle doit travailler de façon incrémentale et livrer une partie du produit
utilisable et testable à la fin de chaque sprint ou itération.
On ne peut pas passer par la méthode Scrum sans connaître les termes suivants :
• Le product backlog c’est un document contenant une liste des besoins du client à réaliser
et qui est la seule source d’exigences pour toute modification à apporter au produit.
• Le sprint backlog c’est un regroupement des éléments d’un document que l’équipe s’engage
à livrer du début à la fin du sprint et qui sont présenter sous forme d’un tableau kanban (ou
Scrum board).
• User story c’est une brève description simple d’une fonctionnalité décrite généralement par
un utilisateur ou un client du système.
• La mêlée (Scrum) C’est une réunion d’avancement quotidienne durant le sprint pour faire
un point sur ce qui a été fait et ce qu’il est prévu de faire.[13]
14
Figure 1.16 : Cycle de vie Scrum
1.11 Présentation de l’équipe
Rôle Acteur Mission
Propriétaire de Catherine Propose les besoins fonctionnels à

produit desgreesdulou développer et valide le produit final à
livrer
Scrum master Laurent Cerisier Assure le bon déroulement du projet

en aidant l’équipe dans la recherche et
l’identification des solutions
Équipe de Mayssa ben • Conception de l’architecture de la
développement abdallah , solution
Oumaima • Mise en place des entités de la base
Boudaouara de données
• Implémentation des Services Web
• Implémentation des interfaces
utilisateurs
• Consommation et intégration des
Service Web
15
Développeur senior Ahmed zaiyet • Responsable technique

• Ingénieur système
Tableau 1.1 : équipe du projet
1.12 Chronogramme de travail
La clé principale pour la réussite d’un projet est un planning efficace. Ce dernier, nous permet
de décomposer le projet en un ensemble de tâches et d’activités afin d’estimer la période nécessaire
pour la réalisation de chacune d’elles. Pour cela, nous avons estimé le planning ci dessous
Figure 1.17 : Chronogramme de travail
Conclusion
Dans ce premier chapitre, nous avons situé notre projet dans son contexte, en présentant
l’organisme d’accueil et le contexte du projet. Nous nous sommes aussi intéressés à l’étude de
l’existant et nous l’avons critiqué pour pouvoir déterminer nos objectifs d’une façon claire et objective
en choisissant la méthodologie la plus adéquate qui est dans notre cas la méthodologie Scrum. Pour le
chapitre suivant nous nous concentrons sur l’identification des acteurs, les besoins fonctionnels et non
fonctionnels, la planification des sprints, l’architecture de notre solution et les choix technologique
adoptés
16
Chapitre 2
Sprint 0 « Etude fonctionnelle,

méthodologique, architectural et
technique »
Plan
1 Identification des besoins fonctionnels et non fonctionnels . . . . . . . 18
2 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . 23
4 Planifications des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6 Architecture Logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7 Diagramme de classes global . . . . . . . . . . . . . . . . . . . . . . . . . 27

Chapitre 2. Sprint 0 « Etude fonctionnelle, méthodologique, architectural et technique »
Introduction
Ce chapitre sera dédié pour la conception qui est une phase très importante dans le cycle de
développement d’un système puisqu’elle prépare l’implémentation. Elle permet de décider comment
satisfaire les besoins dégagés. En premier lieu, nous présentons le backlog produit. En second lieu,
nous allons présenter notre diagramme de classes global. Après nous allons décrire notre architecture
logicielle et nous finirons par les choix technologiques adoptés.
2.1 Identification des besoins fonctionnels et non fonctionnels
2.1.1 Identification des acteurs
Les principaux acteurs qui sont en interaction avec la plateforme sont :
— L’administrateur : c’est le responsable technique de la ministre de santé tunisie , il a

le contrôle total sur le système c’est-à-dire qu’il peut faire les opérations de bases tel que
l’acceptation ou le refus de chaque inscription et il est identifié par une adresse email et un
mot de passe qu’il peut lui-même modifier.
— Patient : Est un utilisateur appartient a la communauté sociale il est identifié par des champs
spécifiques qui a des fonctionnalités limités et spécifiques tel que l’ inscription sur le plateform
en saisissant les informations personnelles , le droit a la recherche des professionnels de santé
déja inscrit sur la plateform , l’intéraction avec le professionnel de santé , consulter le dossier
médical gérer par les professionnel de santés qui ont l’accés
— Professionnel de santé : Est un utilisateur appartient a la Décanat des médecins il est

identifié par des champs spécifiques qui a des fonctionnalités limités et spécifiques tel que
l’ inscription sur le plateform en saisissant les informations personnelles , traitement des
demandes des patients , gérer dossier , l’intéraction avec le patient en répondant a ses questions
2.1.2 Identification des besoins fonctionnels
Les besoins fonctionnels ou besoin métiers sont les tâches exécutées par le système afin de
satisfaire une requête donnée. Notre application couvre les besoins fonctionnels suivants :
• Authentification :
• La création d’un compte à travers un formulaire
18
• L’authentification par email et un mot de passe.

• Le contrôle d’accès aux différentes fonctionnalités par acteur.
• Gestion des accés :

il s’agit d’un module permettant d’effectuer les opérations telles que (Traitement des demandes
, la recherche, la consultation).
• Gestion d’expérience :
Géré par les professionnels de santé permettant d’effectuer les opérations de gestion telles que
(L’ajout, la modification, la suppression et la consultation).
• Gestion des dossiers :

il s’agit d’un module permettant de partager les rapports necessaire entre le patient et ses
professionnels de santé en se basant sur les droits d’accés
• Géstion question-Réponse
• Le patient peux poser des questions médicaux a son professionnel de santé
• Le professionnel de santé doit répondre aux questions : il s’agit d’un module permettant
d’effectuer une opération de gestion telle que l’ajout d’une réponse
• Gestion des paramètres généraux : Cela permet de mettre plusieurs paramètres configurables.
• Tableau de bord et statistique.
2.1.3 Identification des besoins non fonctionnels
• Performance :L’application doit optimiser les traitements pour avoir un temps de génération
de schéma raisonnable. La lenteur d’une application web pourrait avoir un impact négatif sur
l’UX (ou User Expérience). C’est pour cela que notre solution doit être avant tout performante
pour répondre à toutes les exigences des usagers d’une manière rapide et efficace. Ici revient
le choix technique de l’utilisation du Framework Angular que l’un de ces avantages est la
réalisation des interfaces de type mono-page qui fonctionnent sans rechargement de la page
web. En effet sur un mono-page après le chargement initial de la page, plus aucun code HTML
n’est envoyé sur le réseau. Au lieu de cela, seules les données sont demandées au serveur, donc
moins de temps et de bande passante que l’envoi constant de HTML. La figure suivante prouve
la rapidité de réponse du serveur (0.234 seconde) pour les statistiques :
19
Figure 2.1 : Temps de réponse du serveur pour les statistiques
• Ergonomie : En parallèle à l’UX, il y a l’UI (ou User Interface) qui est le lien entre l’humain et
la machine. Donc la plateforme doit offrir une interface conviviale et ergonomique exploitable
par l’utilisateur en envisageant toutes les interactions possibles à l’écran du support tenu.
• Sécurité : La plateforme doit assurer la sécurité pour les utilisateurs. Donc pour garantir
cette sécurité, nous avons utilisé les « JSON Web Token » ou JWT qui sont des jetons générés
par un serveur lors de l’authentification d’un utilisateur sur une application Web, et qui sont
ensuite transmis au client.
• Efficacité : La plateforme doit être fonctionnelle indépendamment de toutes les évènements

pouvant entourer l’utilisateur.
• Maintenabilité :Notre code doit être maintenable, c’est-à-dire non seulement pouvoir être
modifié facilement par moi-même mais également par quelqu’un d’autre. Angular a ses règles
de bonnes pratiques pour faciliter la vie des développeurs et éviter les pièges. On parle
ici du « tslint » qui est un package qui analyse votre code Typescript à la recherche de
points qui "enfreignent les règles de bonnes pratiques". Il est livré avec un ensemble de règles
préconfigurées pour les meilleures pratiques dans Typescript en général.
2.2 Backlog de produit
Un backlog produit contient les éléments qu’un client veut que l’équipe réalise sous forme
d’une liste. Cette liste est composée par plusieurs fonctionnalités hiérarchisées à atteindre sous forme
des brèves descriptions. Le classement de ces fonctionnalités est fait selon la valeur ajoutée que cet
élément apporte donc par ordre de priorité de réalisation. Alors nous pouvons dire que le product
backlog Scrum est autorisé à mesurer, croître et à évaluer que nous en apprenons plus sur le produit
ainsi que ses clients. Un backlog Scrum typique comprend les différents types d’éléments suivants :
20
• Fonctionnalités
• Bogues
• Travail technique
• Acquisition de connaissances
De loin, le principal moyen utilisé par une équipe Scrum pour exprimer les fonctionnalités du backlog
de produit consiste en des user stories, des descriptions courtes et simples de la fonctionnalité
souhaitée, présentées du point de vue de l’utilisateur. Le Backlog du produit comprend les champs
suivants :
• IDF : un identifiant de fonctionnalité.
• Fonctionnalité : un ensemble de user stories et qui construit un service, observable de l’extérieur
• Histoire Utilisateur « User story » : une phrase décrivant la fonctionnalité désirée par le client
• D-US : un nombre unique et auto-incrémenté pour, chaque histoire utilisateur.
• Business Value (B.V) : la valeur, métier qui dirige la priorisation du développement des histoires
utilisateurs suivant les attentes et les besoins du client, allant de 0 à 100 (étant 100 le plus
important)
• Story point (S.P) : Les Story Points permettent de mesurer une tâche en termes d’effort d’une
équipe concrète, au lieu de simplement faire des estimations en jour-hommes, qui fluctuent
selon les personnes. On utilise souvent, et on utilisera ici, la suite de Fibonnacci (1, 2, 3, 5, 8,
13, 21. . .) pour décliner la quantité d’effort à fournir.
Composée principalement de quatre grandes phases, nous allons citer les étapes de chacune
d’entre elles.
IDF Fonctionnalité ID-US User Story B.V S.P
F1 Gérer 1.1 En tant que patient , je souhaite 100 8

l’authentification m’authentifier à la plateforme via un
email et un mot de passe
1.2 En tant qu’un professionnel de santé , je
souhaite m’authentifier à la plateforme
via un email et un mot de passe.
21
1.3 En tant qu’administrateur je souhaite

m’authentifier à la plateforme via un
email et un mot de passe.
1.4 En tant que utilisateur ,je peux
reinitialiser mon mot de passe
F2 Gérer Expérience 1.1 En tant que professionnel de santé , je 100 8

souhaite consulter , ajouter , supprimer
ou modifier une expérience
F3 chercher 1.1 En tant que professionnel de santé , 60 3

patient/professionnel je souhaite trouver mes patients a fin
de santé d’ajouter des documents
1.2 En tant qu’un professionnel de santé , je
souhaite trouver tous les professionnels
de santés .
F4 Consulter dossier 1.1 En tant que professionnel de santé , 100 8

je souhaite consulter le dossier d’un
patient dont j’ai l’accés
F5 Partager document 1.1 En tant professionnel de santé , 100 8

je souhaite partager le rapport de
chaque consultation , hospitalisation et
traitement avec mon patient
F6 Gérer demande 1.1 En tant patient , je souhaite envoyer une 100 13

d’accés demande d’accés a mes professionnels de
santé
1.2 En tant que professionnel de santé ,
je souhaite accepter ou refuser une
demande d’accés d’un patient
22
1.3 En tant Administrateur , je souhaite

traiter les demandes d’accés des
utilisateurs
F74 Gérer question 1.1 En tant que professionnel de santé , je 100 8

reponse souhaite répondre au question de mes
patients
1.2 En tant qu’un patient je souhaite ecrire
des questions selon les spécialités .
Tableau 2.1 : product backlog
2.3 Diagramme de cas d’utilisation global
Les cas d’utilisation permettent d’exprimer les besoins des utilisateurs d’un système. Le
diagramme des cas d’utilisation permet donc d’identifier les possibilités d’interaction entre le système
et les acteurs. Le use case, qui présente l’ensemble des fonctionnalités offerte par l’application pour
nos utilisateurs .
23
Figure 2.2 : Diagramme de cas d’utilisation global
2.4 Planifications des sprints
La répartition des sprints sera planifiée comme indique ce modéle :
24
Figure 2.3 : Plannification des sprints
2.5 Architecture physique
La figure décrit l’ensemble des composants matériels supportant notre solution
Figure 2.4 : Architecture physique de notre solution
25
L’architecture de notre application est composée d’un frontend (react js), d’un backend
implémenté en symfony et d’un SGBD (système de gestion de base de donnés) MySql. Le frontend
et le backend sont déployés sur deux serveurs distincts. Le serveur backend interagit avec le SGBD
qui hébèrge une base de données. Depuis sa machine, un utilisateur envoie ses requetes, à travers
un navigateur, vers le serveur frontend qui interagit avec le serveur backend qui à son tour interagit
avec le SGBD. Le serveur de base de données interprète la requete et retourne le résultat au serveur
backend. Une fois le résultat est prêt au niveau du serveur backend, il sera renvoyé au serveur
frontend et sera disponible dans le navigateur.
2.6 Architecture Logique
Figure 2.5 : Architecture physique de notre solution
Les utilisateurs utilisent un navigateur web pour accéder à l’interface graphique de l’application
qui est implémentée en React js. Les actions utilisateur sont ensuite traduites en requêtes HTTP et
envoyées au controlleur Front qui invoque à son tour les services demandés. Dans le cas où la couche
service a besoin d’informations stockées dans la base de données, une couche d’accès aux données
est responsable de communiquer avec une base de donnés MySql et retourne le résultat à la couche
service qui à son tour fait la logique métier avant de renvoyer le résultat au controlleur.
Le controlleur retourne le résultat au client react js en format json qui sera traduit en javascript.
26
La couche sécurité permet à l’application de sécuriser les actions coté client et serveur.
2.7 Diagramme de classes global
Le diagramme de classes est considéré comme l’élément le plus important de la modélisation

UML. Il contient les éléments qui composent un système et leurs relations sous forme des classes,
qui vont se traduire par la suite dans la partie développement en des classes et objets logiciels réels.
27
Figure 2.6 : Diagramme de classes globale
28
Conclusion
Dans ce chapitre nous avons circonscrit notre problème et nous nous sommes focalisés sur
les différents diagrammes conceptuels, la présentation du backlog du produit et la planification des
sprints qu’on va attaquer dans les prochains chapitres sans oublier les technologies adoptées dans le
but d’avoir une meilleure vision sur notre projet.
Maintenant que la conception est réalisée, nous commençons par notre premier sprint : Authentification
et gestion de profil .
29
Chapitre 3
Sprint 1 : Authentification et
gestion de profil
Plan
1 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2 Les diagrammes d’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5 Sécurité de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Chapitre 3. Sprint 1 : Authentification et gestion de profil
Introduction
Après avoir présenté l’environnement matériel, logiciel et après une longue vision précise sur
le déroulement du projet dans le sprint 0,nous nous somme dirigés vers les sprints pour décrire
les principaux objectifs et les fonctionnalités de l’application. Tout au long de ce chapitre, nous
allons traiter les users-stories du sprint 1 de leurs existences dans le Backlog sprint vers la fin leurs
réalisations pour produire un incrément potentiellement livrable
3.1 Sprint Backlog
ID User Story Tâche Estimation[H]
1
— Choix du Template react 8
— Intégration du Template react 7
2 En tant qu’un utilisateur ,

— Mettre en place les entités de la base de 16
je souhaite m’authentifier à
données
la plateforme via un e-mail
et un mot de passe.
— Implémenter les JWT (Json Web Token) 16
— Implémenter les méthodes d’authentification 16

et exposer les web services
3 En tant qu’administrateur,
— Implémenter l’interface d’authentification 8
je souhaite m’authentifier à
la plateforme via un e-mail
et un mot de passe.
31
— Implémenter l’interface de réinitialisation 8

mot de passe
— Consommer les web services 6

d’authentification
— Elaboration le diagramme de cas 32

d’utilisation, de séquence système, de
séquences détaillées et de classes du cas
d’utilisation «S’authentifier»
4
En tant que admin je peux — Implementer l’interface des demandes 8
traiter les demandes
— consommer les APIs de traitement 24
4
Gestion de Profil (Cas — Analyse du besoin 8
Générale)
— Elaboration le diagramme de cas 24

d’utilisation, de séquence système, de
séquences détaillées et de classes du cas
d’utilisation «Gestion Profil»
— Développement le code de récupération les 24

données et modification des informations
32
— Conception de l’interface Profil 4
5
En tant qu’un utilisateur je — Développement le code de récupération les 2
peux consulter mon profil données
— Développement le code d’affichage des 5

données react
Tableau 3.1 : Sprint backlog.
3.2 Les diagrammes d’analyse
3.2.1 Cas d’utilisation « S’authentifier »et«Réinitialiser mot de passe »
Figure 3.1 : Diagramme de cas d’utilisation S’authentifier et réinitialiser mot de passe
3.2.2 Description textuelle
Afin de mieux spécifier les cas d’utilisation, nous avons préparé leurs raffinements pour mieux
décrire les différents scénarios possibles et en ce qui suit les tableaux de raffinements sont présentés
33
3.2.2.1 Description textuelle du cas d’utilisation « s’authentifier »
Titre : S’authentifier
Acteurs : professionnel de santé , Patient
Pré-condition l’utilisateur est vérifié par l’administrateur
Post Condition : L’utilisateur est connecté
« DEBUT »
1. L’utilisateur ouvre la page d’authentification.
2. Le système lui affiche le formulaire d’authentification.
3. L’utilisateur saisit ses données d’authentification.
Enchainement Nominal
4. L’utilisateur clique sur le bouton « S’identifier »
5. Le systéme vérifie les données saisies et affiche l’interface réservée
à l’utilisateur.
« FIN »
5.1 Les données saisies ne sont pas valides

Enchainement alternatif 5.1.1 Le format d’email n’est pas valide, le système affiche un message d’erreur
5.1.2 l’utilisateur est refusé par l’administrateur
Tableau 3.2 : Description Textuelle du cas d’utilisation "S’authentifier"
3.2.3 Cas d’utilisation « Gérer Profil »
Figure 3.2 : Diagramme de cas d’utilisation Gérer Profil
34
3.2.4 Description textuelle du cas d’utilisation « Consulter Profil »
Titre : Consulter Profil
Pré-condition Authentification acceptée
Post Condition : Profil affiché
« DEBUT »
1. L’acteur clique sur mon profil qui existe dans le sidebar ou widget
2. Le profil sera affiché
« FIN »
Tableau 3.3 : Description textuelle du cas d’utilisation « Consulter Profil »
3.2.5 Description textuelle du cas d’utilisation «Mettre à jour les données

de Profil»
Titre : Mettre à jour les données de Profil
Pré-condition L’utilisateur consulte son profil
Post Condition : Profil Modifié
« DEBUT »
1. L’acteur saisie les nouvelles informations
2. Le système vérifie la validité des données saisies
3. L’acteur clique sur le bouton « enregistrer les modifications »
4. Le système fait la mise à jour,
« FIN »
Tableau 3.4 : Description textuelle du cas d’utilisation « Mettre à jour les données de Profil »
35
3.2.6 Description textuelle du cas d’utilisation «Changer Image de Profil»
Titre : Changer Image de Profil
Pré-condition L’utilisateur consulte son profil
Post Condition : Image de Profil Modifié
« DEBUT »
1. L’acteur clique sur le bouton « Choisir un fichier »
2. Le système affiche un popup pour choisir image
Enchainement Nominal 3. L’acteur choisit une image et clique sur le bouton
« Enregistrer »
4. Le système fait la mise à jour,
« FIN »
Tableau 3.5 : Description textuelle du cas d’utilisation « Mettre à jour les données de Profil »
3.2.7 Description textuelle du cas d’utilisation « Inscrption »
Titre : Inscription
Pré-condition Besoins d’accès à l’interface d’inscription
Post Condition : Inscription validée par l’administrateur
« DEBUT »
1. Le système affiche l’interface d’inscription
Enchainement Nominal 2. L’utilisateur saisit ses informations personnelles
3. L’administrateur accepte la demande de création de compte
« FIN »
Tableau 3.6 : Description textuelle du cas d’utilisation « Inscription »
36
3.2.8 Description textuelle du cas d’utilisation « Reinitialiser Mot de

passe »
Titre : Reinitialiser mot de passe
Pré-condition L’utilisateur avait un compte valide
Post Condition : Mot de passe modifié
« DEBUT »
1. Le système affiche l’interface de demande de réinitialisation de
mot de passe
2. L’utilisateur saisit son email si email invalide alors « E1 »
3. Le système envoyer un email contenant un nouveau mot de passe .
4. L’utilisateur reçoie l’email envoyé .
5. Le système affiche l’interface d’authentification
« FIN »
Exception
E1 : invalidation email
Tableau 3.7 : Description textuelle du cas d’utilisation « Réinitialiser mot de passe »
3.3 Diagramme de séquence
Afin de mieux comprendre la communication entre l’utilisateur et le système, nous avons

utilisé les diagrammes de séquences qui sont présentés en ce qui suit.
37
3.3.0.1 Diagramme de séquence du cas d’utilisation « S’authentifier »
Figure 3.3 : Diagramme de séquence du cas d’utilisation « s’authentifier »
3.3.0.2 Diagramme de séquence du cas d’utilisation «Reinitialiser mot de

passe »
Figure 3.4 : Diagramme de séquence du cas d’utilisation « Reinitialiser mot de passe »
38
3.4 Diagramme de classes
Le diagramme de classes est un élément principal de conception d’un logiciel, c’est un modèle
représentant la structure du système à concevoir. Le diagramme de classes est un schéma utilisé
pour présenter les classes et les différentes relations. Ce diagramme appartient à la partie statique
d’UML
3.4.1 Diagramme de classes «Utilisateur »
Figure 3.5 : Diagramme de classes utilisateur
3.5 Sécurité de l’application
3.5.1 JWT
Pour déployer la sécurisation JWT sur une application Symfony 5 on utilise ici le bundle : «
LexikJWTAuthenticationBundle ». Le principe d’authentification JSON Web Tokens est de retourner
un token chiffré grâce à une clé secrète. Le token comporte directement les informations client tel
que le username. Ainsi on évite de stocker des informations relatives au token côté serveur. D’un
point de vu Client / Serveur : Le client envoie via un formulaire d’authentification son couple :
username et mot de passe. En retour, le serveur va envoyer un token contenant le username. En
effet, le username est directement encodé dans le token grâce à la clé privé (SHA256) qui aura été
39
préalablement générée sur le serveur. Le client possède en retour son token. Ce token est conservé
du coté client (localStorage) et est envoyé à chaque requête vers le serveur. Ainsi, à chaque requête,
le serveur décrypte le token toujours grâce à la clé privée de manière à récupérer directement et
simplement le username. De plus, le token contient une signature permettant de s’assurer que le
contenu n’a pas été altéré par le client.
Figure 3.6 : Exemple d’un jwt généré par LexikJWTAuthenticationBundle
40
3.6 Test
Figure 3.7 : Test de la methode de récupération profile d’un patient
3.7 Réalisation
La partie de réalisation représente la dernière phase du cycle de développement d’un sprint.

Elle permet de présenter les résultats obtenus lors de l’étape de développement afin d’assurer et de
garantir une version de qualité. Nous allons montrer cela par des captures d’écrans des fonctionnalités
ayant été développées
3.7.1 Maquettes
Cette technique consiste à préparer quelques interfaces graphiques de l’application en utilisant

un outil de conception des prototypes afin de mesurer le degré de satisfaction du client par rapport à
la compréhension du projet. L’interaction qui se produit entre l’utilisateur final et le développeur, à
la suite de la discussion sur ces interfaces, permet d’ajuster les besoins et de les concevoir de manière
précise et exacte. En effet, les interfaces graphiques font que l’utilisateur final soit plus interactif,
précis et le pousse à mieux s’exprimer.
41
3.7.1.1 Consulter les informations du compte
Figure 3.8 : Maquette consulter profile
3.7.1.2 Authentification et de réinitialisation mot de passe
Figure 3.9 : Maquette d’authentification et de réinitialisation mot de passe
42
3.7.1.3 Gérer profile patient/professionnel de santé
Figure 3.10 : Maquette de gestion de Profil patient
3.7.2 REST API
Une API RESTful est une interface de programme d’application (API) qui utilise des requêtes
HTTP pour les données GET, PUT, POST et DELETE. Elle est basée sur la technologie de
pointe (REST), un style architectural et une approche de la communication souvent utilisés dans le
développement de services Web.
3.7.3 Interfaces graphiques
3.7.3.1 Interface d’authentification
L’interface d’authentification, c’est la première interface vue par l’utilisateur aprés la page
d’acceuil . Chaque utilisateur doit s’authentifier pour accéder à la partie utilisateur, et pour chaque
authentification une génération de Token se fait et l’utilisateur obtient ses privilèges
43
Figure 3.11 : Interface d’authentification d’un professionnel de santé/patient
Figure 3.12 : Interface d’authentification d’un Administrateur
3.7.3.2 Interface de réinitialisation de mot de passe
Suite à une demande de réinitialisation de mot de passe, le système envoie un message de

récupération vers son compte google mail contenant un nouveau mot de passe.
44
Figure 3.13 : Interface de réinitialisation de mot de passe
Figure 3.14 : Un E-mail de récupération du mot de passe
3.7.3.3 Interface de consultation profile
Suite à une authentification, l’interface de consultation profile permet aux professionnel de

santés et aux patients de consulter leurs informations personnels .
45
Figure 3.15 : Interface de consultation des information de profile
3.7.3.4 Interface de changement de mot de passe
Suite à une authentification, l’interface de changement de mot de passe permet aux professionnel
de santés et aux patients de modifier leur mot de passe. Il s’agit de ressaisir un nouveau mot de
passe et le confirmer .
Figure 3.16 : Interface de changement de mot de passe
3.7.3.5 Interface de modification de profil
Suite à une authentification, l’interface de modification de profil (figure 20) permet aux chefs
de projet et aux chefs d’équipe de consulter et modifier leur profil. Il s’agit de changer le nom, le
prénom, le numéro de téléphone et la photo de profil pour modifier leurs informations.
46
Figure 3.17 : Interface de modification de profil
Conclusion
Dans ce chapitre, nous avons montré au début le Backlog du sprint « Authentification » et «

Gestion de Profil » qui décrit les tâches traitées. Puis, nous avons illustré les différents diagrammes
UML, pour modéliser la plateforme. De plus, nous avons décrit les interfaces et le fonctionnement des
différentes tâches traitées. Nous avons présenté les tests de validation. Le prochain chapitre consacré
à l’étudie du deuxième sprint « Gestion des Accés » et « Gestion des expériences »
47
Chapitre 4
Sprint 2 : Gestion des accés , des

Expériences
Plan
1 sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Chapitre 4. Sprint 2 : Gestion des accés , des Expériences
Introduction
Ce chapitre est consacré à l’étude du sprint 2,Nous allons détailler les différents user-story
de ce sprint, ces tâches et l’estimation de temps pour les accomplir.
4.1 sprint backlog
Dans cette partie, nous allons élaborer les différents user stories de ce sprint, ainsi que les
tâches qui devront être accomplies à la fin du sprint et leurs estimations.
1 En tant qu’un
administrateur et selon mes
données
permissions je peux
attribuer les droits d’accès
— Implémenter les méthodes accepter ou 7
en acceptant ou en refusant
refuser un utilisateur
un compte crée
— Consommer les web services d’acceptation et 8

de refus
2 En tant que patient et

selon mes permissions je
données
peux attribuer les droits
d’accès en ajoutant les
— Implémenter la méthode d’ajout 7
professionnels de santés
concerné
— consommer et intégrer le web service de 8
l’ajout
49
3 En tant que patient je peux

— Implémenter la méthode pour afficher les 16
afficher les détails d’un
détails d’un professionnel de santé et exposer
professionnel de santé .
son web service
— Implémenter l’interface d’affichage d’un 16

professionnel de santé
— Consommer et intégrer le web service 5

d’affichage
4 En tant qu’un professionnel

— Implémenter la méthode pour consulter les 8
de santé je peux consulter
demandes d’accés
les demandes d’accés des
patients .
— Exposer la méthode en tant que web service 8
— Consommer et intégré l’API 6
5 En tant que patient je peux

— Implémenter la méthode pour consulter la 8
consulter les professionnels
liste des professionnels de santé
de santé qu’il m’ont accepté
ma demande d’accés
50

— Implémenter la méthode pour ajouter une 8
de santé je peux ajouter
experience
une expérience .
7 En tant qu’un
professionnel de santé je
données
peux modifier une
expérience
— Implémenter les méthodes de modification 7
d’une expérience

données

de santé je peux supprimer
données
une expérience
— Implémenter les méthodes de suppression 6

d’une expérience

données
Tableau 4.2 : sprint backlog
51
4.2.1 Diagramme de cas d’utilisation « Gestion opération »
Figure 4.1 : Diagramme de cas d’utilisation « Gérer opération »
4.2.2 Description du cas d’utilisation « Gestion Opération »
4.2.2.1 Description textuelle du cas d’utilisation « Ajouter opération »
Titre : Ajouter expérience
Acteur : professionnel de santé
Pré-condition : Acteur possède ce rôle
Post Condition : l’ajout de l’expérience est traitée
« DEBUT »
1. Le professionnel de santé clique sur le bouton « Ajouter expérience »
2. L’acteur saisie les informations de l’expérience
3. Le système Vérifie les données saisies.
4. Le système enregistre les données dans la base de données
« FIN »
Tableau 4.3 : Description textuelle du cas d’utilisation « Ajouter expérience »
52
4.2.2.2 Description textuelle du cas d’utilisation « Modifier expérience »
Titre : Modifier expérience
Post Condition : la modification de l’expérience est traitée
« DEBUT »
1. Le professionnel de santé clique sur le bouton « Modifier »
2. L’acteur saisie les nouvelles informations de l’expérience
« FIN »
Tableau 4.4 : Description textuelle du cas d’utilisation « Modifier une expérience »
4.2.2.3 Description textuelle du cas d’utilisation « Supprimer expérience »
Titre : Supprimer expérience
Post Condition : la suppression de l’expérience est traitée
« DEBUT »
1. Le professionnel de santé clique sur le bouton « supprimer »
Enchainement Nominal 2. Le système supprime les données dans la base de données
3. Le système affiche la suppression
« FIN »
Tableau 4.5 : Description textuelle de cas d’utilisation « Supprimer une expérience »
4.2.3 Diagramme du cas d’utilisation « Demande accés »
La figure 4.2 illustre le diagramme de cas d’utilisation raffiné pour le module de la demande d’accés
53
Figure 4.2 : Diagramme du cas d’utilisation « Gérer accés»
54
4.2.4 Description textuelle du cas d’utilisation « Gérer accés »
Titre : demande d’accés à mon professionnel de santé
Acteur : Patient
Pré-condition le patient cherche son professionnel de santé
Post Condition : la demande traiter avec succés
« DEBUT »
1. le profile du medecin est affiché
2. le patient clique sur le bouton « Demande accés »
3. Le système vérifie la demande .
4. une demande sera envoyer
« FIN »
Enchainement alternatif la demande déja envoyer
Tableau 4.6 : Description textuelle du cas d’utilisation « recherche d’un professionnel de santé »
4.2.5 Description textuelle du cas d’utilisation « Recherche d’un

professionnel de santé »
Titre : Recherche d’un professionnel de santé
Acteur : Patient
Pré-condition : le patient choisit la spécialité de son professionnel de santé
Post Condition : l’utilisateur recherché a été affiché
« DEBUT »
1. Le patient choisit la spécialité de son professionnel de santé
2. L’acteur saisie la ville ou il situé son professionnel
4. le systéme affiche la liste des professionnels de santé concerné
« FIN »
Tableau 4.7 : Description textuelle du cas d’utilisation « recherche d’un professionel de santé »
55
4.2.6 Description textuelle du cas d’utilisation « Consulter les détails de

la demande »
Titre : Consulter les détails d’une demande demande
Post Condition : Liste des demandes affiché
« DEBUT »
1. L’acteur appuie sur le bouton qui est dans le tableau de bord
Enchainement Nominal « afficher les demandes »
2. le systéme doit afficher la liste des demandes d’accés des patient
« FIN »
Enchainement alternatif Les informations sont incorrectes : Un message d’erreur sera affiché
Tableau 4.8 : Description textuelle du cas d’utilisati« Consulter les détails de la demande »»
4.2.7 Description textuelle du cas d’utilisation « Confirmer ou rejeter

une demande »
Titre : Confirmer ou rejeter une demande
Pré-condition Liste des demandes affichés /Demande non traitées
Post Condition : Demande traité
« DEBUT »
1. L’acteur consulte la demande
Enchainement Nominal 2. L’acteur clique sur le bouton « confirmer » ou « rejeter »
3. Le système fait la modification dans la base de données
« FIN »
Tableau 4.9 : Description textuelle du cas d’utilisation « traiter la demande »
56
4.3 Diagrammes de séquences
Figure 4.3 : Diagramme de séquence de cas d’utilisation « Supprimer Expérience»
La figure 22 représente le diagramme de classes relatif au module « gestion des accés » « gestion
expérience » :
57
Figure 4.4 : Diagramme de classes du sprint 2
4.5 Test
Pour assurer le bon fonctionnement d’une API, On a utilisé l’outil postman pour pouvoir
régulièrement faire les test API.
58
Figure 4.5 : Test de l’API Patient en attente
4.6 Réalisation
4.6.1 Maquettes
4.6.1.1 Gérer expérience
Figure 4.6 : Maquette « Ajouter une expérience »
59
4.6.1.2 Gérer expérience
Figure 4.7 : Maquette « choix une spécialité »
4.6.1.3 choisir un professionnel de santé
Figure 4.8 : Maquette « choisir un professionel de santé »
60
4.6.2 Interfaces
Dans cette section, nous présentons le travail que nous avons réalisé à travers des interfaces
permettant d’exploiter facilement les fonctionnalités développées La figure represente la gestion
d’expérience d’un médecin
4.6.2.1 Ajouter expérience
Pour ajouter une nouvelle experience, il suffit de cliquer sur le bouton « Nouvelle experience ».
Figure 4.9 : Interface « Gestion expérience »
4.6.2.2 Le process de demande d’accés
Les trois figures ci dessous représentent le process de demande d’accés a un professionnel de santé :
La figure 4.9 représente la phase ou le patient doit choisir la spécialité de son médecin
61
Figure 4.10 : Interface « choix d’une spécialité »
La figure 4.10 représente l’interface du choix de ville où le patient cherche son professionnel de santé
dés le clique sur « Recherche » une liste contient les professionnel de santé et leur spécialité sera
affiché
Figure 4.11 : Interface « Recherche d’ un professionnel de santé »
Pour ajouter un professionnel de santé, il suffit de cliquer sur le boutton « Demande d’accés ».
62
L’interface ci-dessous (figure 4.11) présente l’interface de l’ajout d’un professionnel de santé
Figure 4.12 : Interface « Demande d’accés , consulter un professionnel de santé »
La figure ci-dessous (4.12) représente la liste des patients en attente :qui ont envoyé une demande a
leur professionnel de santés.Le professionnel de santé traite cette demande.
Figure 4.13 : Interface «traitement des accés »
63
La figure ci-dessous (4.13) représente la liste des professionnel de santés qui ont l’accés a un dossier
du patient
Figure 4.14 : Interface «consulter les medecins qui ont l’accés a un compte patient»
La figure (4.14) représente l’espace administratif d’ou on peut trouver la liste des patients déja inscrit
dans la plateform selon le Code de la sécurité sociale l’administrateur fait la verification des comptes
Figure 4.15 : Interface «Liste des Demandes des patients»
La figure (4.15) interface représente l’espace administratif d’ou on peut trouver la liste des
professionnels de santé déja inscrit dans la plateform selon le Répertoire Partagé des Professionnels
de Santé l’administrateur fait la verification des comptes
64
Figure 4.16 : Interface «Liste des Demandes des professionnels de santé »
Conclution
Dans ce chapitre, nous nous sommes intéressés à la réalisation du module de la gestion des accés et
des opérations .
Pour ce faire, nous avons commencé par l’élaboration du sprint backlog, puis une étude conceptuelle
et finalement la réalisation.
65
Chapitre 5
Sprint 3 : Gestion dossier
Plan
1 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Chapitre 5. Sprint 3 : Gestion dossier
Introduction
Le but de ce sprint est de mettre en œuvre les différentes fonctionnalités qui vont servir à gérer
dossier patient Pour ce faire, nous allons élaborer le sprint backlog et les diagrammes relatifs à la
conception, puis nous clôturerons cette partie par des captures d’écran expliquant la réalisation
5.1 Sprint Backlog
1 En tant qu’un patient je

— Implémenter la méthode pour consulter mon 8
peux consulter mon dossier
dossier
médical
2 En tant que patient je

peux ajouter des
données
taritements des antecedents
des maladie des allergies
— Implémenter les méthodes d’ajout 7
des vaccination
traitement , antecedent , maladie ,
vaccination , allergie
67
3 En tant que professionnel

de santé je peux ajouter
données
des documents medicaux et
des consultations .
— Implémenter la méthode d’ajout des 16
documents médicaux
— Exposer les web services 16
— Consommer et intégrer l’API 16

— Intégrer la méthode de recherche des 8
de santé je peux chercher
patients
un patient déja dans ma
liste .

— Implémenter la méthode de consultation de 8
la liste des patients
les informations génerale de
mes patients
68
6 En tant qu’un
— Implémenter la méthode de consultation des 8
notifications
peux consulter les
informations génerale de
la méthode en tant que web service 7
toute professionnel de santé
dans la liste
7 En tant qu’un
— Implémenter la méthode de L’ajout des 8
informations dans le rapport médical
peux ajouter des rapports (
hospitalisation et
Taitement ) pour le dossier
de mes patients
8 En tant qu’un
— Implémenter la méthode de consultation des 8
notifications
peux ecrire une
consultation sera partagé
avec le patient concerné
Tableau 5.2 : sprint backlog
69
5.2.1 Diagramme de cas d’utilisation
Figure 5.1 : Diagramme de cas d’utilisation «gestion dossier
5.2.2 Description du cas d’utilisation « Gestion dossier »
La figure illustre la description de l’ajout des informations médicaux
70
Titre : Ajout Information médicaux
Acteur : Patient
Pré-condition le professionel de santé avait l’accés pour le dossier du patient
Post Condition : l’ajout des informations dans le dossier est traité
« DEBUT »
1. L’acteur clique sur le bouton « Ajouter Traitement » ,
« Ajouter maladie » , « Ajouter allergie »
Enchainement Nominal 2. L’acteur saisie les informations nécessaire
4. Le système affiche les données dans une liste
« FIN »
Tableau 5.3 : Description textuelle du cas d’utilisation « Ajout des informations médicaux »
La figure illustre la description de la consultation d’historique
Titre : Consulter l’ Historique
Acteur : patient / professionnel de santé
Pré-condition le professionel de santé avait l’accés pour le dossier du patient
Post Condition : Les détails des historiques sont affichés
« DEBUT »
1. Le patient appuie sur le bouton qui est dans la barre de navigation
« dossier médical »
Enchainement Nominal 1.1 le professionnel de santé cherche un patient
2. l’acteur clique sur les bouton d’historique de chaque domaine
3. le systéme affiche la liste des historiques
« FIN »
Tableau 5.4 : Description textuelle du cas d’utilisation « Consulter historique »

La figure illustre la description de la recherche de la liste patient et professionel de santé
71
Titre : chercher patient-professionnel de santé
Post Condition : Les listes des informations sont affichés
« DEBUT »
« Liste des patients » « Liste des professionnels de santé »
2. l’acteur cherche a partir d’un id ou nom, prénom
3. le systéme affiche la liste des informations
« FIN »
Enchainement alternatif Les informations sont incorrectes : c’est le vide
Tableau 5.5 : Description textuelle du cas d’utilisation « Chercher patient - professionnel de

santé »
5.3.1 Diagramme de séquence « Ajouter fréquence cardiaque »
Figure 5.2 : Diagramme de séquence de cas d’utilisation «Ajouter fréquence cardiaque»
72
5.3.2 Diagramme de séquence «Supprimer fréquence cardiaque »
Figure 5.3 : Diagramme de séquence de cas d’utilisation «Supprimer fréquence cardiaque»
La figure(5.4) illustre le diagramme de classes raffiné pour le sprint gestion dossier .
73
Figure 5.4 : Diagramme de classes gestion dossier
5.5 Test
La figure 5.5 représente le test de L’API Liste vaccination ajouter par un docteur
Figure 5.5 : test de l’API liste des vaccinations
74
5.6 Réalisation
Dans cette section, nous présentons le travail que nous avons réalisé à travers des maquettes
et des interfaces permettant d’exploiter facilement les fonctionnalités développées.
5.6.1 Maquettes
Figure 5.6 : Maquette « traitement »
Figure 5.7 : Maquette « Mesure »
75
5.6.2 Interfaces
5.6.2.1 Profil médical
La figure 5.5 représente l’interface d’un profil médical.
Figure 5.8 : Interface « profil médical »
5.6.2.2 Les mesures d’un profil
La figure 5.8 représente l’interface d’un profil médical. Pour ajouter un poids, il suffit de
cliquer sur le bouton « Ajouter une valeur ».
Figure 5.9 : Interface « les mesures d’un profil médical »
76
5.6.2.3 Ajout traitement
Pour ajouter un nouveau traitement, il suffit de cliquer sur le bouton « Ajouter un traitement
».
Figure 5.10 : Interface « Ajout traitement »
5.6.2.4 Historique traitement
Pour visualiser tous les traitements, il suffit de cliquer sur le bouton «Historique de traitement
».
Figure 5.11 : Interface « Historique des traitements »
77
5.6.2.5 Ajout hospitalisation
Pour que un professionnel ajoute une nouvelle hospitalisation, il suffit de cliquer sur le bouton
« Ajouter hospitalisation ».
Figure 5.12 : Interface « Ajout Hospitalisation par professionnel de santé »
Le bundle NelmioApiDocBundle nous permet de générer de la documentation au format

OpenAPI (Swagger).
Figure 5.13 : Swagger
78
Figure 5.14 : Code de l’implémentation de l ’API Ajout Hospitalisation par docteur
5.6.2.6 List hospitalisation
Pour que un professionnel visualise tous les hospitalisations , il suffit de cliquer sur le bouton
«Historique d’hospitalisation ».
Figure 5.15 : Interface « Liste des hospitalisation »
5.6.2.7 List ordonnance
La figure ci-dessous (figure 5.) présente la liste des ordonnances d’un patient ajouté par le
professionnel de santé.
79
Figure 5.16 : Interface « Liste des ordonnances »
5.6.2.8 Liste des patients
La figure ci-dessous (figure 5.16) présente la liste des patients déja accéptés dans lequel le
professionnel de santé peut filtrer soit par identifiant soit par nom soit par prénom .
Figure 5.17 : Interface « Liste patient »
5.6.2.9 Liste des professionnels
La figure ci-dessous (figure 5.17) présente la liste des professionnel de santés dans lequel le
professionnel de santé peut filtrer soit par identifiant soit par nom soit par prénom .
80
Figure 5.18 : Interface « Liste des professionnels de santé »
Conclution
Dans ce chapitre, nous nous sommes intéressés à la réalisation du module de la gestion du

dossier Pour ce faire, nous avons commencé par l’élaboration du sprint backlog, puis une étude
conceptuelle et finalement la réalisation.
81
Chapitre 6
Sprint 4 : Gestion Question-Reponse

et tableau de bord
Plan
1 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4 Diagrammes de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Chapitre 6. Sprint 4 : Gestion Question-Reponse et tableau de bord
Introduction
Le but de ce sprint est de mettre en œuvre les différentes fonctionnalités qui vont servir à
gérer les questions réponses. Pour ce faire, nous allons élaborer le sprint backlog et les diagrammes
relatifs à la conception, puis nous clôturerons cette partie par des captures d’écran expliquant la
réalisation
6.1 Sprint backlog
ID User Story Tâche

— Implémenter la méthode
peux ecrire un question
pour ajouter question
médical a mon
professionnel de santé
— Exposer la méthode en tant que

web service
— Consommer et intégré l’API
2 En tant qu’un
— Mettre en place les entités
de la base de données
peux répondre au questions
proposé par mes patients
— Exposer la méthode en tant que
web service
83

— Mettre en place les entités de
la base de données
les statistiques .
— Exposer les web services
— Consommer et intégrer l’API

— Intégrer la méthode de consulter
de santé je peux voir les
les patients
demandes d’accés envoyé
par les patient

— Implémenter la méthode de
peux envoyer une demande
consultation de la liste des patients
d’accés a un professionnel
de santé dans le tableau de
bord
— Exposer la méthode en tant que web
service

— Implémenter la méthode de
peux consulter la liste des
consultation des notifications
professionnel de santés qui
ont accepté mes demandes
la méthode en tant que web service
84
Consommer et intégré l’API

— 8
6.2.1 Diagramme de cas d’utilisation «Gestion Question-Reponse»
Figure 6.1 : Diagramme de cas d’utilisation « Question - Reponse »
6.2.2 Description textuelle «Ajouter question»
Titre : Ajouter question
Acteur : Patient
Post Condition : Message envoyé avec succés a mon professionnel de santé
« DEBUT »
« Contact »
Enchainement Nominal 2. l’acteur seléctionne le professionnel de santé concerné
et saisie le titre et le question
3. le systéme envoie le question au professionnel de santé concerné
« FIN »
Enchainement alternatif Les informations sont incorrectes : c’est le vide
85
Tableau 6.2 : Description textuelle du cas d’utilisation « Ajouter question »
6.3.1 Diagramme de séquence du cas d’utilisation « Répondre au question

»
Figure 6.2 : Diagramme de séquence «Répondre aux questions» »
6.3.2 Diagramme de séquence du cas d’utilisation « Ajouter question »
Figure 6.3 : Diagramme de séquence «Ajouter question» »
86
6.4 Diagrammes de classes
6.5 Test
Cette figure représente le test de la méthode d’ajout question pour un docteur concerné
87
Figure 6.4 : Test de la méthode ajout question
6.6 Réalisation
6.6.1 Maquettes
Figure 6.5 : Interface « Liste des question médicaux »
6.6.2 Interfaces
La figure ci-dessous (figure 6.6) présente les questions posés par les patients.
88
Figure 6.6 : Interface « Liste des questions »
Pour qu’un patient ajoute un question, il suffit qu’il clique sur le boutton « Ajouter un
question». L’interface ci-dessous (figure 6.7) présente l’interface de l’ajout d’un question
Figure 6.7 : Interface « Ajouter un question »
6.6.2.1 tableau de bord d’un patient
La figure ci-dessous (figure 6.8) présente le tableau de bord de l’interface du patient .
89
Figure 6.8 : Interface « tableau de bord d’un patient »
6.6.2.2 tableau de bord d’un professionnel de santé
La figure ci-dessous (figure 6.8) présente le tableau de bord de l’interface du professionnel de

santé .
Figure 6.9 : Interface « tableau de bord d’un professionnel de santé »
Conclution
Dans ce chapitre, nous nous sommes intéressés à la réalisation du module de la gestion

Question/Réponse et Tableau de bord .
90
Pour ce faire, nous avons commencé par l’élaboration du sprint backlog, puis une étude conceptuelle
et finalement la réalisation.
91
CONCLUSION GÉNÉRALE
Ce projet de fin d’études , realisé au sein de l’entreprise FLYDEV , a pour objectif de réaliser
un plateform partagé entre les professionnels de santé et les patients "ENS". permettant aux patients
de donner les accés aux professionnels de santé et de partager avec eux leurs informations de santé
en toute sécurité , et d’autre part aux médecins de gérer les accés des patients et de gérer leurs
dossiers.
Pour atteindre note objectif, nous avons commencé par mettre en relief la problématique par
une étude de l’existant ensuite d’identifier les acteurs et de dégager les besoins fonctionnels et non
fonctionnels.
En deuxiéme lieu , nous avons entamé la partie conception et l’implémentation des différents sprints
Malgré la complexité des enjeux et les contraintes de temps, nous avons arrivé à réussir au final à
mettre en place une solution qui peuvent être évolutive et flexible, pouvant être considérablement
étendue par l’ajout de nouvelles fonctionnalités.
Notre travail était réalisé avec une importance considérable dans la mesure où il nous a servi
comme portail vers le monde professionnel et la vie en entreprise. De point de vue technique, il nous
a permis de mettre en œuvre les acquis théoriques que nous avons appris tout le long de notre cursus
universitaire et de les enrichir par la découverte de nouvelles technologies.
Pour finir, ce projet ne s’arrête pas là. La richesse et la complexité du domaine de santé
permet toujours l’apparition de nouveaux besoins que la structuration et la conception de notre
solution permet de les gérer sans beaucoup de difficulté.
92
BIBLIOGRAPHIE
[1] https ://www.flydev.fr/
[2] https ://www.journaldunet.fr/business/dictionnaire-du-marketing/1198257-swot-definition-explication-et-exem
[3] https ://easypartner.fr/blog/5-bonnes-raisons-dutiliser-symfony/
[4] https ://symfony.com/
[5] https ://www.software-developer-india.com/fr/avantages-de-react-js-pour-le-developpement-web/
[6] https ://fr.reactjs.org/
[7] https ://matob.web.id/fr/avantages-de-base-de-donnees-mysql/
[8] https ://fr.wikipedia.org/wiki/GitHub
[9] https ://code.visualstudio.com/
[10] https ://www.jetbrains.com/fr-fr/phpstorm/
[11] https ://fr.overleaf.com/project
[12] https ://www.atlassian.com/fr/software/jira
[13] https ://bubbleplan.net/blog/agile-scrum-gestion-projet/
93

OumaymaissaRapport PFE-22

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

OumaymaissaRapport PFE-22

Transféré par

Droits d'auteur :

Formats disponibles

J’autorise les étudiantes à faire le dépôt de leurs rapport de stage en vue d’une soutenance.

Encadrant académique, Monsieur Ahmad DJEMAL

Encadrant professionnel, Monsieur Ahmed Rabii ZAYET

J’ai le grand plaisir de dédier ce travail

comme signe de reconnaissance et de remerciements.

jamais cessé de me conseiller, encourager et soutenir tout au long de mes

témoignage de toute la gratitude et amour que je vous dois.

de nos sentiments les plus sincères et les plus affectueux.

soutien moral, la patience, et ta compréhension tout au long de ce projet.

J’ai le grand plaisir de dédier ce travail

A mon très cher père Noureddine. Je te dédie ce travail en signe de mon

bonheur. L’amour et affection que te porte sont infinis. Il me reste encore

ce que j’ai de plus précieux ; Ce fruit de toutes ces années de travail.

ressens.Je t’aime tellement ma chère mère et je veillerai à te rendre fière

au long de ces années. Des mots ne pourront jamais exprimer la profondeur

peine de me soutenir durant ce stage .

moral, la patience, et ta compréhension tout au long de ce projet.

Nous voudrons en premier lieu remercier notre encadrant académique Mr

Ahmad Djemal pour sa disponibilité et ses conseils pour la mission

Aucun mot ne peut exprimer notre reconnaissance et notre infinie gratitude

Merci infiniment surtout a notre superviseur Mr Laurent Cerisier pour ses

Nous tenons à remercier aussi notre encadrant au sein de la société Mr

Encore, nous voudrons remercier tous les membres de l’équipe de la société

Nous remercions aussi tous les membres de l’équipe pédagogique et les

de différentes manières à la réalisation de notre projet de fin d’études.

1 Contexte générale du projet 2

2 Sprint 0 « Etude fonctionnelle, méthodologique, architectural et technique » 17

3 Sprint 1 : Authentification et gestion de profil 30

4 Sprint 2 : Gestion des accés , des Expériences 48

5 Sprint 3 : Gestion dossier 66

6 Sprint 4 : Gestion Question-Reponse et tableau de bord 82

1.1 Logo FLYDEV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Temps de réponse du serveur pour les statistiques . . . . . . . . . . . . . . . . . . . . 20

3.1 Diagramme de cas d’utilisation S’authentifier et réinitialiser mot de passe . . . . . . 33

3.6 Exemple d’un jwt généré par LexikJWTAuthenticationBundle . . . . . . . . . . . . 40

4.1 Diagramme de cas d’utilisation « Gérer opération » . . . . . . . . . . . . . . . . . . . 52

5.1 Diagramme de cas d’utilisation «gestion dossier . . . . . . . . . . . . . . . . . . . . . 70

6.1 Diagramme de cas d’utilisation « Question - Reponse » . . . . . . . . . . . . . . . . 85

1.1 équipe du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1 product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Sprint backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2 sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.2 Description textuelle du cas d’utilisation « Ajouter question » . . . . . . . . . . . . . 85

— API = Application Programming Interface

— CSS = Cascading Style Sheets

— DOM = Document Object Model

— HTML = HyperText Markup Language

— HTTP = Hypertext Transfer Protocol

— JSON = JavaScript Object Notation

— JWT = JSON Web Token

— PHP = Hypertext Preprocessor

— REST = Representational State Transfer

— UML = Unified Modeling Language.

— URL = Uniform Resource Locator

— VSCode = Visual Studio Code.

• Chapitre 2 : « (Sprint 0) Etude fonctionnelle, méthodologique, architectural et technique » .

• Chapitre 3 : « (Sprint 1) : Authentification et gestion profil »

• Chapitre 4 : « (Sprint 2) :Gestion des accès , des opérations »

• Chapitre 5 : « (Sprint 3) :Gestion des dossiers »

• Chapitre 6 : « (Sprint 4) : Gestion Question-Reponse et tableau de bord »

Contexte générale du projet

3 Présentation génerale du projet . . . . . . . . . . . . . . . . . . . . . . . 5