Rapport PFE 2021 BENNAJAH

Mémoire du Projet de Fin d'Études
En vue de l'obtention du diplôme
INGÉNIEUR D'ÉTAT
Filière : Génie Informatique
Option : génie logiciel
Sujet
Conception et Réalisation d'une Application web & mobile

d'intermédiation entre les professionnels de santé et
les demandeurs de soins à domicile.
Organisme d'accueil : Wings Technologies
Réalisé par : Sous la direction de :

Pr. EL BANNY Omar (ENSAK)
M. BENNAJAH Marouane
Mr. AHBIB Abdelali (Wings Technologies)
Soutenu le 05 juillet 2021, Devant le jury de :

Pr. Abdelmajid DARGHAM : ENSA Khouribga
Pr. Fatimazohra ENNAJI : ENSA Khouribga
Pr. Omar EL BANNAY : ENSA Khouribga
Année Universitaire
2020 - 2021
Dédicace
“
Je dédie ce travail :
À ma chère mère et à mon cher père
Qui ont toujours été là pour moi, qui m'ont

entouré de tous soins imaginables depuis mon premier pas dans ma vie. je
mets entre vos mains, le fruit de longues années d'études, de votre tendresse et de longs jours
d'apprentissage. Chaque ligne, chaque mot et chaque lettre de ce rapport vous exprime la
reconnaissance, le respect, l'estime et le merci d'être mes parents.
Que dieu, tout puissant, vous garde, vous procure santé, bonheur et longue vie
pour que vous demeuriez le flambeau illuminant mon chemin.
À mes frères, mes grands-parents et ma famille

Qui me donnent de l’amour et de la vivacité.
À tous ceux qui m’ont aidé - de près ou de loin - et ceux

qui ont partagé avec moi les moments d’émotion lors de la
réalisation de ce travail et qui m’ont chaleureusement
supporté et encouragé tout au long de mon parcours.
À tous mes amis
Qui m’ont toujours encouragé, et à qui je souhaite plus de succès.
Merci pour tous les moments inoubliables !
”
- Marouane
Remerciements
Je tiens tout d'abord à remercier Dieu le tout puissant et miséricordieux, qui m'a donné la
force et la patience d'accomplir ce travail.
Je tiens, avant de présenter mon travail, à exprimer ma grande reconnaissance envers

les personnes qui m’ont - de près ou de loin - apporté leurs soutiens. Qu’ils trouvent ici
collectivement et individuellement l’expression de toute ma gratitude et ma reconnaissance.
Je tiens à remercier tout particulièrement et à témoigner toute ma reconnaissance à

M. Abdelali AHBIB, Chef des Projets au sein de Wings Technologies, qui a veillé au bon
déroulement du projet dès son début et à ma correcte intégration durant la période de stage, et
qui était le meilleur guide plein d’enthousiasme et d’énergie positive, qui a accueilli mes
demandes et mes contraintes avec plein joie, patience et éclaircissement, et pour le temps qu’il
m'a consacré à l’encadrement et le suivi de ce travail.
Je tiens à remercier sincèrement M.Omar EL BANNAY, qui, en tant que professeur

encadrant de l'ENSA Khouribga, leur aide et les renseignements précieux qu’il m’ont fourni
ainsi que pour tous les conseils et les informations qu’il m’a prodigués avec un degré de
patience et de professionnalisme sans égal.
Avec beaucoup d'égard, nous ne manquerons pas d'exprimer notre grande reconnaissance
à l’ensemble du corps administratif et enseignant de l’ENSA Khouribga, pour avoir porté un
vif intérêt à notre formation, et pour avoir accordé de l’attention et de l’énergie, et ce, dans un
cadre agréable de respect. J'espère que ce travail sera à la hauteur de vos attentes.
Que les membres de jury trouvent, ici, l’expression de mes remerciements pour l’honneur
qu’ils me font en prenant le temps de lire et d’évaluer ce travail.
Résumé
Le présent rapport constitue une synthèse de mon projet de fin d’études effectué au sein de
la société WINGS Technologies à Casablanca et ayant comme objectif l’étude, la conception,
le déploiement et la réalisation d’une application web & mobile en deux versions Fr-Ar qui
permet l’intermédiation entre les professionnels de santé (notamment Infirmiers,
kinésithérapeutes, urgentistes, etc.) et les demandeurs de soins à domicile, en proposant une
expérience utilisateur facile et pertinente avec un système de recommandations et de recherche
intelligente, et ce en vue de l’obtention du diplôme d’ingénieur d’état en informatique.
Le projet est divisé en trois parties : l’Espace Prestataire pour les professionnels de santé
ou les Hôpitaux qui proposent des services aux personnes qui cherchent et demandent des soins
à domicile, l’Espace Patient destiné aux utilisateurs qui recherchent les meilleurs profils pour
les services dont ils ont besoin, et l'Espace d'administrateur qui gère la totalité des systèmes de
notre application.
Pour pouvoir réaliser ce travail, nous avons utilisé un ensemble d'outils et technologies :
MongoDB, ExpressJS, ReactJS, NodeJS, NextJS, Redux, GraphQL, Apollo server, React
Native, Jest, Google APIs, GitLab CI/CD, Figma, Amazon AWS.
L’étude technique et la mise en place de l'architecture de l'application a été faite

conjointement entre WINGS technologies et des experts dans les outils utilisés. Durant ce stage,
nous avons opté pour la méthodologie SCRUM pour la gestion et la conduite du projet.
Mots clés : Soin à domicile, infirmières, services de soins, recommandation, GraphQL,

Système de suivi, SCRUM, Google APIs
Abstract
This report is a synthesis of my final year project carried out within the company WINGS
Technologies in Casablanca and having as objective the study, the design, the deployment and
the realization of a web & mobile application in two versions Fr-Ar which allows the
intermediation between the professionals of health (in particular Nurses, physiotherapists,
urgentists, etc) and homecare seekers, by offering an easy and relevant user experience with a
recommendation and intelligent search system, and this in order to obtain the state engineering
degree in computer science.
The project is divided into three parts: The Provider Area for health professionals or
Hospitals that offer services to people seeking and requesting home care, the Patient Area for
users who are looking for the best profiles for the services they need, and the Administrator
Area that manages the entire systems of our application.
To be able to realize this work, we used a set of tools and technologies: MongoDB,
ExpressJS, ReactJS, NodeJS, NextJS, Redux, GraphQL, Apollo server, React Native, Jest,
Google APIs, GitLab CI/CD, Figma, Amazon AWS.
The technical study and the implementation of the application architecture was done jointly
between WINGS technologies and experts in the tools used. During this internship, we opted
for the SCRUM methodology for the management and conduct of the project.
Keywords: Home care, Nursing management, care services, recommendation, GraphQL,

Tracking system, SCRUM, Google APIs
Table des matières
Dédicace .......................................................................................................................................
Remerciements .............................................................................................................................
Résumé .........................................................................................................................................
Abstract .........................................................................................................................................
Table des matières ........................................................................................................................
Table des figures ...........................................................................................................................
Table des tableaux ........................................................................................................................
Liste des sigles et acronymes........................................................................................................
Introduction générale .................................................................................................................. 1
Chapitre 1 : Contexte général du projet ...................................................................................... 3
1.1 Présentation de l’organisme d’accueil ......................................................................... 4
1.1.1 Carte d’identité .............................................................................................. 4
1.1.2 Métiers Wings Technologies ......................................................................... 4
1.1.3 Organigramme de l’entreprise Wings Technologies ..................................... 6
1.2 Présentation et contexte du projet ................................................................................ 6
1.2.1 Cadre du projet .............................................................................................. 6
1.2.2 Problématique et solution proposée............................................................... 7
1.3 Conduite de projet ........................................................................................................ 9
1.3.1 Méthodologie de développement .................................................................. 9
1.3.2 Planification du projet ................................................................................. 13
1.4 Conclusion ................................................................................................................. 14
Chapitre 2 : Analyse et spécification des besoins..................................................................... 15
2.1 Spécification des besoins fonctionnels ...................................................................... 16
2.2 Spécification des besoins non fonctionnels ............................................................... 17

2.3 Analyse des besoins fonctionnels .............................................................................. 17
2.3.1 Identification des acteurs ............................................................................. 17
2.3.2 Etude de besoin............................................................................................ 18
2.3.3 Diagramme de cas d'utilisation ................................................................... 20
2.3.4 Description contextuelle des cas d’utilisation ............................................. 23
2.3.5 Diagramme de processus - BPMN .............................................................. 36
2.3.6 Spécifications fonctionnelles de système .................................................... 40
2.4 Conclusion ................................................................................................................. 40
Chapitre 3 : Étude Conceptuelle et architecturale .................................................................... 41
3.1 Étude Conceptuelle .................................................................................................... 42
3.1.1 Diagrammes de séquence ............................................................................ 42
3.1.2 Diagramme de Classe .................................................................................. 45
3.2 Etude technique .......................................................................................................... 47
3.2.1 Structure et Architecture de développement ............................................... 47
3.2.2 Cycle de développement.............................................................................. 50
3.2.3 Branche de développement.......................................................................... 51
3.2.4 Outils et technologies utilisées .................................................................... 52
3.2.5 Les contraintes de sécurité........................................................................... 56
3.2.6 Les Tests unitaires : ..................................................................................... 57
3.3 Conclusion ................................................................................................................. 58
Chapitre 4 : Mise en œuvre de la solution ................................................................................ 59
4.1 Les interfaces graphiques de l’espace patient ............................................................ 60
4.1.1 Page d’authentification ................................................................................ 60
4.1.2 Page d’accueil ............................................................................................. 62
4.1.3 Page gestion profil patient ........................................................................... 64
4.1.4 Page de demander un soin ........................................................................... 68

4.2 Les interfaces graphiques de l’espace Prestataire ...................................................... 70
4.2.1 L’authentification ........................................................................................ 70
4.2.2 L’inscription du prestataire ......................................................................... 70
4.2.3 Gestion profil prestataire ............................................................................. 71
4.2.4 Gestion des demandes ................................................................................. 72
4.2.5 L’espaces des factures ................................................................................. 73
4.3 Conclusion ................................................................................................................. 74
Conclusion générale & perspectives......................................................................................... 75
Webographie............................................................................................................................. 77
Table des figures
Figure 1 : Logo de Wings Technologies .................................................................................... 4
Figure 2 : Savoir-Faire de l'entreprise Wings Technologies ...................................................... 4
Figure 3 : Principal approche de Wings Technologies ............................................................... 5
Figure 4 : Organigramme de Wings Technologies ..................................................................... 6
Figure 5 : Logo du projet WeKareYou ....................................................................................... 6
Figure 6 : Cycle de vie de la méthodologie Scrum .................................................................. 10
Figure 7 : Diagramme de Gantt du projet ................................................................................. 13
Figure 8 : Acteurs du projet ...................................................................................................... 18
Figure 9 : Cas d’utilisation du profil Admin. ........................................................................... 21
Figure 10 : Cas d’utilisation du profil patient........................................................................... 22
Figure 11 : Cas d’utilisation du profil prestataire. .................................................................... 23
Figure 12 : BPMN – Demander service ................................................................................... 37
Figure 13 : BPMN - l'inscription du prestataire ....................................................................... 38
Figure 14 : BPMN - Changement statut balance ...................................................................... 38
Figure 15 : BPMN - facturation................................................................................................ 39
Figure 16 : BPMN- traitement des litiges ................................................................................. 40
Figure 17 : Diagramme de séquence “authentification” ........................................................... 43
Figure 18 : Diagramme de séquence "demander service" ........................................................ 44
Figure 19 : Diagramme de classe. ............................................................................................ 46
Figure 20 : Architecture globale du développement. ............................................................... 47
Figure 21 : Architecture spécifique de développement. ........................................................... 48
Figure 22 : Structure du projet (côté Front - mobile) ............................................................... 49
Figure 23 : Structure du projet (côté Front - web) .................................................................... 49

Figure 24 : Structure du projet (côté Back) .............................................................................. 49
Figure 25 : Modules du projet. ................................................................................................. 50
Figure 26 : Cycle de développement de notre projet. ............................................................... 50
Figure 27 : Branche de développement d'un projet [8]. ........................................................... 51
Figure 28 : Branches "WeKareYou". ....................................................................................... 52
Figure 29 : Outils de développement et intégration du projet. ................................................. 52
Figure 30 : Répertoire du projet sur Gitlab............................................................................... 56
Figure 31 : Tests unitaires par jest ............................................................................................ 57
Figure 32 : Résultats du test d'authentification......................................................................... 58
Figure 33 : Résultats du test options et services ....................................................................... 58
Figure 34 : Page d'authentification ........................................................................................... 60
Figure 35 : Message d'erreur au cas d'anomalie ....................................................................... 60
Figure 36 : Page d'authentification après l'envoi de code......................................................... 61
Figure 37 : Message d'erreur au cas au le code incorrect ......................................................... 61
Figure 38 : Page d’authentification en mode responsive .......................................................... 61
Figure 39 : Page d'accueil WeKareYou.................................................................................... 62
Figure 40 : Page des offres ....................................................................................................... 63
Figure 41 : Profil du prestataire (Popup) .................................................................................. 63
Figure 42 : Page d'accueil en mode responsive ........................................................................ 63
Figure 43 : Profil patient ........................................................................................................... 64
Figure 44 : Profil complet......................................................................................................... 64
Figure 45 : Profil patient en mode responsive .......................................................................... 65
Figure 46 : Page des adresses patient ....................................................................................... 65
Figure 47 : formulaire d'ajouter une adresse ............................................................................ 66
Figure 48 : Formulaire d'ajouter une adresse mode responsive ............................................... 66
Figure 49 : Ajout d’adresse (patient) ........................................................................................ 66

Figure 50 : Page des demandes – patient (incomplet) .............................................................. 67
Figure 51 : Page de paramètres - patient .................................................................................. 67
Figure 52 : Services favoris (incomplet) .................................................................................. 67
Figure 53 : Prestataires favoris (incomplet) ............................................................................. 68
Figure 54 : demande de soin ..................................................................................................... 68
Figure 55 : ajout d’adresse........................................................................................................ 68
Figure 56 : tracking de prestataire ............................................................................................ 69
Figure 57 : tracking de prestataire(responsive) ........................................................................ 69
Figure 58 : Formulaire de contactez-nous ................................................................................ 69
Figure 59 : Page d’authentification de prestataire .................................................................... 70
Figure 60 : Les étapes d'inscription du prestataires .................................................................. 71
Figure 61 : Profil prestataire ..................................................................................................... 71
Figure 62 : Paramètres prestataires ........................................................................................... 72
Figure 63 : Section demandes - prestataires ............................................................................. 73
Figure 64 : Liste des factures prestataires ................................................................................ 73
Figure 65 : Détails d'une facture ............................................................................................... 74
Figure 66 : Contactez-nous prestataire - version mobile .......................................................... 74

Table des tableaux
Tab 1 : Backlog-Product / Prestataire Story-Map .................................................................... 11
Tab 2 : Aperçu du sprint-backlog numéro 4 de projet WeKareYou. ....................................... 12
Tab 3 : Aperçu du Tableau kanban WeKareYou ..................................................................... 12
Tab 4 : Aperçu du Tableau d'ordonnancement des tâches par priorité ..................................... 13
Tab 5 : Acteurs en interaction avec le système ........................................................................ 18
Tab 6 : Description contextuelle du cas d'utilisation admin "s’authentifier " .......................... 24
Tab 7 : Description contextuelle du cas d'utilisation admin "Gérer utilisateurs" ..................... 26
Tab 8 : Description contextuelle du cas d'utilisation admin "Gérer services".......................... 26
Tab 9 : Description contextuelle du cas d'utilisation admin "Gérer factures" .......................... 27
Tab 10 : Description contextuelle du cas d'utilisation admin "Gérer tickets/litiges" ............... 28
Tab 11 : Description contextuelle du cas d'utilisation patient "s'authentifier" ......................... 29
Tab 12 : Description contextuelle du cas d'utilisation patient "Gérer profil" ........................... 29
Tab 13 : Description contextuelle du cas d'utilisation patient "Consulter services" ................ 30
Tab 14 : Description contextuelle du cas d'utilisation patient "Consulter tickets" ................... 31
Tab 15 : Description contextuelle du cas d'utilisation patient "Consulter demandes" ............. 32
Tab 16 : Description contextuelle du cas d'utilisation prestataire "s’inscrire" ......................... 33
Tab 17 : Description contextuelle du cas d'utilisation prestataire "Gérer profil" ..................... 34
Tab 18 : Description contextuelle du cas d'utilisation prestataire "Consulter demandes" ....... 35
Tab 19 : Description contextuelle du cas d'utilisation prestataire "Consulter factures" ........... 36

Liste des sigles et acronymes
COVID-19 coronavirus disease of 2019
GraphQL Graph Query Language
MVP Minimum Viable Product
BPMN Business Process Model and Notation
SEO Search Engine Optimization
SSR Server side rendering
SSG Static site generation
CSR Client side rendering
HTTP Hypertext Transfer Protocol
JSON JavaScript Object Notation
JWT JSON Web Token
REST Representational State Transfer
IT Information Technology
UX User experience
UML Unified Model Language
IHM Interface Homme Machine
NoSQL Not Only Structured query language
AWS Amazon Web Services
API Application programming interface
CI Continuous integration
CD Continuous Deployment
DB Database
Introduction générale
La digitalisation des entreprises est un défi commun pour tous les secteurs, y inclut le
secteur de « santé et soins à domicile ». En fait, ce secteur va bénéficier au maximum après la
digitalisation de ces pratiques dans les différents processus qu’il suit. Ce bénéfice sera garanti
grâce aux diverses opportunités présentes dans la centralisation des processus et données et sa
manipulation.
La solution digitale de soins à domicile permet de booster la visibilité des annonces de

soins sur le web et par conséquent d’augmenter les chances de trouver le bon prestataire et gérer
le processus de demander un soins clé en main, de même il permet de gagner du temps dans la
recherche d'une infirmière ou d'un prestataire et de permettre au patient de choisir comme il le
souhaite entre les prestataires qui répondent le mieux aux exigences. Même histoire pour les
prestataires qu'ils trouveront dans ce genre de solution d'autres opportunités de travail et mieux.
En effet, la tendance des solutions de santé s'est beaucoup plus élargie. Ces dernières
années L'intelligence artificielle, Machine Learning, le big data et l'analyse des données sont
au cœur des innovations dans le secteur IT (information technologie), offrant de nombreuses
possibilités aux administrateurs d'applications de soins et de soins à domicile pour
recommander et proposer les bons profils et améliorer l'interaction de la solution avec les
utilisateurs. , qu'il s'agisse de patients ou de prestataires, ou encore vérifier la validation des
éléments constitutifs d’un prestataire.
A cet égard, Wings technologies a décidé d’intégrer ce nouveau monde digital qui ouvre,
sans doute, plusieurs opportunités pour l’entreprise. L’objectif de mon stage est le
développement d’une application web & mobile permettant de mettre en relation, d'une part,
des professionnels de santé et des infirmières qualifiées et, d'autre part, des personnes qui ont
besoin (ou leurs proches) de soins à domicile, qu'elles soient âgées, handicapées ou souffrant
de maladies chroniques. Avec la solution proposée, le patient peut rechercher un ou plusieurs
infirmiers qui peuvent se rendre à son domicile avec une proximité et un service de qualité.
Le présent rapport abordera en détail mon projet de fin d’études, il comporte quatre
chapitres :
1
Introduction générale
Le premier chapitre est consacré à la présentation de l’organisme d’accueil, la

problématique de notre projet et la solution proposée, puis la dernière partie du chapitre sera
destiné à présenter la planification du déroulement des différentes activités prévues lors de la
période de réalisation de notre projet.
Le deuxième chapitre aborde l’analyse et spécifications des différents aspects du projet,

nous allons présenter d’abord, une introduction du cahier de charge. Puis, nous passons à la
spécification et aux cas d’utilisation. La dernière partie est consacrée à la présentation du
digramme de processus et les prototypes de l’applications.
Le troisième chapitre, traite une étude conceptuelle et architecturale du projet qui

commence par la conception du projet à travers les diagrammes d’UML, à savoir le diagramme
de séquence et le diagramme de Classes.
Le dernier chapitre, concerne la réalisation et l’implémentation du projet à travers les

différents Sprints en présentant les démonstrations des tâches réalisées.
A la fin du rapport nous présentons une conclusion générale, ainsi que les perspectives
attendues du projet.
2
Chapitre 1
Contexte général du projet
“ Ce chapitre a pour but de situer le projet dans son environnement organisationnel et
contextuel. Il présente dans sa première partie l’organisme d’accueil, tandis que sa deuxième
partie décrit les objectifs du projet et ses fonctionnalités, La dernière partie est réservée à la
démarche et la conduite adoptée pour la réalisation du projet. ”
3
Chapitre 1 : Contexte général du projet
1.1 Présentation de l’organisme d’accueil

Nous présentons dans cette partie une brève présentation de l’organisme d’accueil
Wings Technologies, en présentant son organigramme et ses métiers.
1.1.1 Carte d’identité
Figure 1 : Logo de Wings Technologies
Wings Technologies dont le logo est présenté dans la figure 1.1 est une société marocaine
créée en 2020 dispose un local à Technopark Casablanca, et emploie 20 collaborateurs dans
différents domaines. Elle offre à ses clients une solide expertise sur la conception et la
réalisation des plateformes, les enjeux numériques, l’UX (User Experience), et l’aspect
marketing et marketing digital, elle aide aussi les entreprises à mener à bien leur transformation
digitale en s’appuyant sur une équipe talentueuse qui possède les connaissances récentes en
matière de pointe, ce qui permet aussi de conquérir la révolution industrielle 4.0 et de franchir
une étape solide dans l’évolution des marchés d’aujourd’hui.
Wings Technologies occupe une position concurrentielle sur le marché de transformation

digitale. Elle répond aux exigences des professionnels grâce à une qualité irréprochable et un
service d’accompagnement personnalisé. Le client particulier bénéficie lui, d’un modèle de
commande simple, des prix très bas et d’un service après-vente à sa disposition.
1.1.2 Métiers Wings Technologies
Figure 2 : Savoir-Faire de l'entreprise Wings Technologies
4
L’entreprise Wings Technologies développe des solutions innovantes et des nouvelles

fonctionnalités technologiques, de la phase d’étude à la mise en œuvre de la solution sur le
terrain. Wings Technologies assure le suivi et le maintien en conditions opérationnelles du
système déployé. Elle possède également un département « Customer Care » qui assure le
support en direct aux clients on-line de Wings avec les trois langues : Arabe, Français et
Anglais.
Wings technologies fédère toutes les compétences indispensables au bon déroulement des
projets de ses clients, du conseil à la réalisation en passant par l’ergonomie, le design,
l’interface utilisateur.
Ainsi le métier du Wings technologies est organisé en trois pôles :
 Le pôle « Développement logiciel ».

 Le pôle « Marketing digital ».
 Le pôle « Conseil en technologie d’entreprise ».
Figure 3 : Principal approche de Wings Technologies
5
1.1.3 Organigramme de l’entreprise Wings Technologies
Figure 4 : Organigramme de Wings Technologies
Comme c’est présenter dans la figure ci-dessus, L’entreprise Wings Technologies se

constitue d’un fondateur, et gérée par des managers IT, CS (Customer care), et marketing, ces
pôles se décomposent de plusieurs postes à savoir : chef de projet, Développeur, Ingénieure
informatique, Designer, marketeur.
1.2 Présentation et contexte du projet

1.2.1 Cadre du projet
Figure 5 : Logo du projet WeKareYou
Notre projet intitulé « Etude, conception et la réalisation d’une application web &
mobile en deux versions FR-AR qui permet l’intermédiation entre les professionnels de santé
et patients à domicile » a été proposé dans le cadre de l’élaboration d’un stage de fin d’études
au sein de la société Wings Technologies.
6
1.2.2 Problématique et solution proposée

Depuis toujours et sur tout lors de la crise sanitaire COVID-19, où le besoin réel a été
constaté, la recherche d'une infirmière qui peut se déplacer à votre domicile, pose un problème
d'approvisionnement ainsi qu'un risque de sécurité. Il faut du temps, de la patience et de
nombreux coups de téléphone avant de trouver un professionnel disponible. Dans ce contexte,
WeKareYou propose une solution innovante qui n'existe pas encore au Maroc.
WeKareYou est un projet innovant qui vise à simplifier la mise en relation entre les patients
qui ne nécessitent pas d'hospitalisation et les professionnels de santé, en permettant aux patients
de trouver rapidement un professionnel dans leur quartier via une plateforme unique, et aux
infirmiers de connaître les demandes de soins dans leur zone géographique en temps réel. Il
s'agit de la première plateforme numérique qui permet l'intermédiation entre des infirmiers
qualifiés et les personnes qui ont besoin (ou leurs proches) de soins à domicile qu'elles soient
âgées, handicapées ou souffrant de maladies chroniques, cette population a besoin d'une prise
en charge quotidienne ou hebdomadaire selon les cas et pour cela nous souhaitons leur offrir
un service de proximité et de qualité.
Donc comme il est déjà mentionné le projet vise le développement d'une application web
et mobile, qui contient trois parties :
Espace patient :
Cette partie du projet concerne principalement les patients (ou demandeurs de soins), c'est
un espace qui doit faciliter la mission de l'utilisateur qui recherche un service de soins à
domicile, ceci sera assuré en mettant à la disposition des utilisateurs/patients toutes les offres
des prestataires disponibles sur la plateforme, après avoir sélectionné le service dont ils ont
besoin. Cet espace sera caractérisé par la possibilité d'effectuer un filtrage multi-conditionnel,
par exemple nous pourrons filtrer les prestataires par prix, secteurs d'intervention, meilleur
prestataire (selon les commentaires des utilisateurs), disponibilité, années d'expérience et par
les différents services offerts sur la plateforme. La plateforme se chargera de recommander des
prestataires au patient en répondant au maximum des exigences possibles. Après avoir
sélectionné un profil le patient peut commencer la procédure de création d'une demande de
soins ou il a la possibilité d'effectuer un paiement en ligne ou un paiement cash à la fin de la
prestation, le patient bénéficie également d'un système de suivi de ses demandes en temps réel.
7
Espace Infirmier / Prestataire :
Cette partie est dédié aux professionnels de santé ou aux hôpitaux qui offrent des services
aux personnes qui cherchent et demandent des soins à domicile, chaque Prestataire doit remplir
les informations nécessaires au moment de l'inscription en spécifiant les services qu'il peut
offrir, la disponibilité et les secteurs où il veut travailler. Avec l'existence d'un espace où le
prestataire peut consulter et accepter ou refuser les demandes en temps réel.
Espace d’administration :
Cette partie est destiné à l’administrateur qui gère l'ensemble des systèmes de notre
application : gestion des utilisateurs, gestion des services et des options, gestion des demandes,
gestion de la facturation, gestion de la messagerie, gestion des tickets, etc.
Pour le patient et le prestataire, ils ont aussi la possibilité de suivre les demandes et de
communiquer avec l'administrateur via un système de messagerie et créer des tickets
(réclamation/ litige) en cas de blocage rencontré.
1.2.3 Les Objectifs du projet
L'objectif est de créer une plateforme plus simple, plus ergonomique, plus moderne qui
rassemble nos professionnels de santé dans un réseau mobilisable en cas de besoin ! Dédiée à
leur activité de professionnels de santé à domicile, elle leur permet de gérer leurs patients, leurs
agendas et toutes leurs activités en quelques clics sur une même plateforme. Et il permet aux
demandeurs de soins de trouver rapidement un professionnel dans leur quartier.
Nous pouvons résumer les objectifs spécifiques comme suit :
 Création d’un système d'authentification admin, Prestataire, patient par téléphone.

 Création d'un espace patient avec une expérience utilisateur très simple pour ajouter des
demandes de soins et rechercher des professionnels de santé.
 Création d'un espace Prestataire où il pourra ajouter des offres de soins, des services et
leurs tarifs, des secteurs d'intervention et des disponibilités. Sans oublier la possibilité de
consulter et accepter ou refuser les demandes en temps réel.
 Création d’un espace Administrateur pour gérer les différents systèmes de notre
application.
8
 Création d'un système de paiement en ligne afin que nos patients puissent payer leurs
demandes et que nos prestataires puissent payer leurs factures.
 Création d’un système de gestion des tickets qui traitera toutes les réclamations et litiges
qu'ils soient liés aux applications ou à des blocages dans l'utilisation de la plateforme.
 Création d'un système de recommandation intelligent basé sur différentes contraintes
telles que les zones géographiques et la disponibilité des professionnels.
 Création d'un système d'archivage des demandes réalisées à l'aide d'une base de données
NoSQL.
 Création d’un système de messagerie et de notification.
 Gain en complexité et en temps pour trouver un professionnel de santé.
1.3 Conduite de projet

La prise de décision concernant la conduite de projet est indispensable pour garantir le
succès d’un projet informatique. Pour cette raison, nous nous sommes concentrés sur la
définition de la méthodologie de développement et sur la planification globale afin d'obtenir
une image macroscopique du déroulement du projet après la finalisation du planning à suivre.
1.3.1 Méthodologie de développement

La méthodologie est une démarche organisée rationnellement pour aboutir à un résultat.[1]
En effet il existe deux types de méthodologies, agile et classique. Plusieurs méthodologies

classiques sont utilisées, nous citons par exemple le modèle en V, en spirale et en cascade, ce
dernier est souvent adopté pour les projets simples qui ne sont pas susceptible à des
changements brusques et inattendus.
Pour notre projet WeKareYou, nous avons adopté la méthode agile Scrum qui est une
méthode de gestion et de développement de projets ou programmes informatiques. Le principe
de la méthodologie SCRUM est de développer un logiciel de manière incrémentale en
maintenant une liste totalement transparente des demandes d’évolutions ou de corrections à
implémenter (backlog).[2]
Avec des livraisons très fréquentes, toutes les 4 semaines en général, le client reçoit un
logiciel à chaque itération. Plus nous avançons dans le projet, plus le logiciel est complet
et possède de plus en plus de fonctionnalités.
9
Pour cela, la méthode s’appuie sur des développements itératifs à un rythme constant, de 2
à 4 semaines (2 semaines pour notre cas) comme le montre la figure 6 :
Figure 6 : Cycle de vie de la méthodologie Scrum
Cette méthodologie représente plusieurs points forts, surtout pour les projets complexes et
instables et même les projets innovants.
En réalité, plusieurs raisons ont obligé l’adoption d’une telle méthodologie agile :
 L’instabilité du Product-Backlog et l’ajout de nouvelles fonctionnalités chaque fois.

 La nécessité d'effectuer des livraisons rapprochées pour assurer le lancement et la
commercialisation de la plateforme dans les plus brefs délais.
 La capacité d’adaptation aux changements inattendus grâce à des itérations courtes.
La méthodologie SCRUM fait intervenir 3 rôles principaux qui sont :
 Product Owner : Dans la majorité des projets, le responsable produit (product owner)
est le responsable de l’équipe projet client. C’est lui qui va définir et prioriser la liste
des fonctionnalités du produit et choisir la date et le contenu de chaque sprint sur la
base des valeurs (charges) qui lui sont communiquées par l’équipe.
 ScrumMaster : Véritable facilitateur sur le projet, il veille à ce que chacun puisse
travailler au maximum de ses capacités en éliminant les obstacles et en protégeant
l’équipe des perturbations extérieures.
 Équipe de développement : elle regroupe l’ensemble des rôles habituellement
nécessaires à un projet, à savoir le concepteur, ledéveloppeur, le testeur, etc. L’équipe
s’organise elle-même et elle reste inchangée pendant toute la durée d’un sprint
Le schéma illustre un exemple de planification en Scrum : les itérations (sprints) durent en

pratique entre 2 et 4 semaines, et chacune a un objectif. L'objectif de chaque sprint est une liste
10
d’items du backlog de produit ou de fonctionnalités à réaliser. Ces items sont décomposés par
l’équipe en tâches élémentaires de quelques heures. Comme nous pouvons le remarquer dans
cette figure, pour mettre en place la méthode SCRUM, nous devons d'abord définir les
différentes fonctionnalités de notre application qui constituent le backlog de produit. Vient
ensuite l'étape de planification du sprint pour définir le plan détaillé d'une itération.
Dans notre cas et comme déjà mentionné, la plateforme web et mobile contient trois
espaces : l'espace infirmière, l'espace patient et l'espace administration qui feront l'objet de notre
backlog produit.
Le product-backlog prestataire se présente de la manière suivante :
Tab 1 : Backlog-Product / Prestataire Story-Map
Ce tableau illustre les Users stories ou les items qui décrivent les fonctionnalités à développer
par l’équipe Scrum l’espace prestataire.
11
Les User stories du Backlog-Product sont présentées et priorisé dans le sprint-backlog qui
représente un carnet sous forme de tâches à réaliser au cours de l’itération.
Nous avons travaillé par une plateforme web qui est le logiciel JIRA qui représente un
système de gestion des projets, et qui va nous permettre de mieux planifier et organiser nos
tâches.
Tab 2 : Aperçu du sprint-backlog numéro 4 de projet WeKareYou.
Durant un sprint, il y a toujours des réunions quotidiennes entre les différents collaborateurs
du projet afin de présenter l’état d’avancement des différentes tâches en cours, les difficultés
rencontrées ainsi que les tâches restantes à réaliser. Une fois que le produit partiel est prêt, nous
vérifions la conformité de ce qui a été fait durant le sprint et nous pouvons alors l’améliorer en
procédant à l’étape de rétrospective.
Pour chaque projet que nous gérons, nous utilisons un Task Board ou le tableau de tâches,
également appelé tableau Kanban. C’est un outil basique, mais essentiel pour l’équipe il permet
de visualiser rapidement l'état d’avancement du projet. C'est également la base sur laquelle nous
pouvons discuter lors du Daily scrum.
Tab 3 : Aperçu du Tableau kanban WeKareYou
12
1.3.2 Planification du projet

La planification du projet permet le bon ordonnancement des différentes tâches, selon
une logique qui prend en compte leur criticité, leurs dépendances et leur durée, et l'élaboration
d'un plan de travail qui permettra d'atteindre les objectifs envisagés et souhaités.
Tab 4 : Aperçu du Tableau d'ordonnancement des tâches par priorité
Normalement, en Scrum, il est très difficile de donner un planning exact pour le projet, car le
Planning détaillé est déterminé pour chaque Sprint, mais cela n’empêche pas de donner une
vision globale sur le Planning globale.
La figure suivante (figure 9) présente le diagramme de Gantt qui illustre le Planning globale
du projet :
Figure 7 : Diagramme de Gantt du projet
13
1.4 Conclusion
Dans ce chapitre, nous avons d'abord présenté en premier lieu l’organisme d’accueil. Dans
un second lieu, nous avons déterminé le cadre du projet. Puis nous avons spécifié la
problématique et le contexte général du projet. Et en dernier lieu, nous avons présenté la
méthode de travail à adopter et illustré le déroulement du travail avec le planning suivi tout au
long du projet. Dans le chapitre qui suit, nous allons présenter l’analyse fonctionnelle et non
fonctionnelle de notre projet ainsi que la conception détaillée, dans laquelle, nous allons défini
les spécifications dans le but d’élaborer l’architecture globale du projet.
14
Chapitre 2
Analyse et spécification des besoins
“ Dans ce chapitre, nous aborderons les phases d’analyse et de spécification des besoins
du projet, afin d’avoir une vision globale claire du comportement du projet ainsi que des
attentes des utilisateurs. Nous allons présenter d'abord une introduction du cahier de charge.
Puis, nous passons à la spécification et aux cas d’utilisation. La dernière partie est consacrée
à la présentation du digramme de flux. ”
15
Chapitre 2 : Analyse et spécification des besoins
2.1 Spécification des besoins fonctionnels

La capture des besoins fonctionnels est une étape importante du projet. Cette étape permet
de produire le dossier de spécifications fonctionnelles, au cours duquel sont formalisées les
fonctionnalités attendues ainsi que toutes les règles de gestion qui les régissent. Les besoins
fonctionnels détectés sont résumés dans les points suivants :
 Gestion de profils :
Le projet doit comprendre plusieurs profils qui seront gérés différemment selon leur rôle, leur
fonctionnement, leurs actions et leur importance pour garantir la sécurité des données et des
personnes.
 Gestion des demandes :
La plateforme doit permettre une gestion avancée des informations relatives aux demandes
grâce à des vues intuitives et ergonomiques, avec des fonctions de recherche et de filtrage
puissantes.
 Système de suivi :
La plateforme doit permettre un suivi avancé des demandes de prestations en temps réel avec
des Google Maps et des changements de statut actualisés.
 Gestion des services et options :
La plateforme doit permettre la gestion des services offerts par la plateforme afin de garantir
une flexibilité maximale aux demandeurs de soins.
 Système de recommandation des offres :
La plateforme doit permettre la recommandation d’offres selon un algorithme intelligent de

mise en correspondance (Matching) entre les offres les offres disponibles sur la plateforme et
les demandes de soins.
 Gestion des factures :
La plateforme doit permettre aux utilisateurs de payer et de consulter les factures des demandes
traitées afin de faciliter les transactions entre la plateforme et les professionnels de santé.
16
 Gestion des tickets :
La plateforme doit permettre la gestion des réclamations soit au niveau d’utilisation de la

plateforme soit au niveau des litiges.
2.2 Spécification des besoins non fonctionnels

Les besoins non fonctionnels concernent les contraintes à prendre en considération pour
mettre en compte une solution adéquate aux attentes des concepteurs des architectures
dynamiques.
Ce sont des exigences qui ne concernent pas spécifiquement le comportement du système
mais plutôt ils identifient les contraintes internes et externes du système.
Notre application doit nécessairement assurer ces besoins :
 La sécurité : Avoir une sécurité forte lors de l'authentification et lors de l'accès à

l'application.
 L’extensibilité : Dans le cadre de ce travail, l’application doit être extensible, c'est-à-dire
qu'il pourra y avoir une possibilité d'ajouter ou de modifier de nouvelles fonctionnalités.
 La simplicité : Un visiteur modeste pourra utiliser un tel service de façon intuitive.
 La performance : L’application doit être performante, c’est-à-dire que le système doit
réagir dans un délai précis, quelle que soit l’action de l’utilisateur.
 La modularité : Avoir un code simple à maintenir et facile à comprendre en cas de besoin.
 La convivialité : La plate-forme doit être facile à utiliser. En effet, les interfaces
utilisateurs doivent être conviviales c'est-à-dire simples, ergonomiques et adaptées à
l'utilisateur.
2.3 Analyse des besoins fonctionnels

L’analyse des besoins est une étape très importante dans le processus de l’étude et le
développement des systèmes d’information. Cette partie identifie l’ensemble des acteurs qui
interagissent avec le système et définit tous les cas d'utilisation de ce dernier sur la base de
diagrammes UML.
2.3.1 Identification des acteurs

Un acteur est une personne, un matériel ou un logiciel qui interagit avec le système.
L’analyse de ce projet commence par une identification des acteurs agissant sur les différentes
17
parties du système. Nous avons principalement trois acteurs : le prestataire, le demandeur de

soins ou le patient et l’administrateur.
Figure 8 : Acteurs du projet
Le tableau 5 résume les acteurs en interaction avec le système, en précisant le rôle de chacun
d'eux avant de définir plus précisément leurs interactions avec le système à l'aide de
diagrammes de cas d'utilisation.
Acteur Fonction
L’administrateur est un utilisateur privilégié,

L’admin qui peut utiliser toutes les fonctionnalités de
la plateforme.
C'est un profil qui permet de rechercher des

Le patient (le demandeur de soins) professionnels de santé et de créer des
demandes de soins au sein de la plateforme et
de bénéficier des services de la plateforme.
C’est un profil qui pourra accéder à la

Le prestataire plateforme vu un numéro de téléphone et
proposer des services de soins à domicile.
Tab 5 : Acteurs en interaction avec le système
2.3.2 Etude de besoin

Les différents besoins peuvent être regroupées comme suit :
 Le prestataire doit pouvoir s'inscrire sur l'application.

 Le prestataire doit avoir la possibilité de modifier son profil.
 Le prestataire doit avoir la possibilité de savoir l’état de son compte.
 Le prestataire doit avoir la possibilité de créer des offres de soins.
 Le prestataire doit avoir la possibilité d’ajouter une raison avant d’annuler une prestation.
 Le prestataire doit avoir la possibilité de consulter les détails d’une demande.
18
 Le prestataire doit avoir la possibilité d’accepter ou rejeter une demande.

 Le prestataire doit avoir la possibilité de mettre à jour le statut de la demande.
 Le prestataire doit avoir la possibilité de consulter le profil du patient.
 Le prestataire doit avoir la possibilité de consulter les avis des patients.
 Le prestataire doit avoir la possibilité d’ajouter des commentaires pour ses patients.
 Le prestataire doit avoir la possibilité de consulter la balance et toutes les transactions
déjà effectuées.
 Le prestataire doit avoir la possibilité de consulter et payer les factures.
 Le prestataire doit avoir la possibilité de générer automatiquement des factures et le
contrat d’inscription.
 Le patient doit avoir la possibilité de s’inscrire par téléphone.
 Le patient doit avoir la possibilité de modifier son profil.
 Le patient doit avoir la possibilité de configurer les notifications.
 Le patient doit avoir la possibilité d’ajouter des adresses de prestations.
 Le patient doit avoir la possibilité de consulter son profil et ses activités.
 Le patient doit avoir la possibilité de supprimer son profil.
 Le patient doit avoir la possibilité de consulter les profils des prestataires.
 Le patient doit avoir la possibilité de voir toutes les offres des prestataires et pas seulement
celles qui existent dans son quartier.
 Le patient doit avoir la possibilité de filtrer les offres des prestataires.
 Le patient doit avoir la possibilité de trier les offres de soins.
 Le patient doit avoir la possibilité de partager une offre ou un profil de prestataire.
 Le patient doit avoir la possibilité d'afficher les offres de prestataires qui correspondent
aux critères de recherche.
 Le patient doit bénéficier d’une recommandation des offres qui seront fournies par
l'application sur la base de l'historique d'utilisation de l'application et des informations sur
le prestataire.
 Le patient doit avoir la possibilité d’annuler une demande de soins.
 Le patient doit avoir la possibilité d’ajouter un lieu.
 Le patient doit avoir la possibilité d’effectuer un paiement en ligne.
 Le patient doit avoir la possibilité de demander une ou plusieurs prestations.
 Le patient doit avoir la possibilité de créer un ou plusieurs tickets.
 Le patient doit avoir la possibilité de poursuivre les démarches d'une demande
incomplète.
19
 Le patient doit avoir la possibilité d’ajouter une revue après chaque prestation.
 Le patient doit avoir la possibilité de modifier sa revue.
 Le patient doit avoir la possibilité d’ajouter une raison avant d'annuler une demande.
 Le patient doit avoir la possibilité de consulter ses demandes de prestations dans son
profil.
 Le patient doit avoir la possibilité de mettre à jour le statut d’un litige.
 L'administrateur doit avoir la possibilité de vérifier et d’approuver les paiements.
 L’administrateur doit avoir la possibilité d’examiner les demandes d'inscription des
prestataires et les approuver ou les rejeter.
 L’administrateur doit avoir le droit d'ajouter, de modifier et de supprimer les services et
leurs options s'ils existent.
 L’administrateur doit avoir la possibilité d’approuver ou de refuser un prestataire.
 L’administrateur doit avoir la possibilité d’ajouter, de modifier, de supprimer, de
désactiver ou d’activer un prestataire.
 L’administrateur doit avoir la possibilité de gérer les factures et d’approuver les
paiements.
 L’administrateur doit avoir la possibilité de gérer les tickets.
 L’administrateur doit avoir la possibilité de mettre à jour le statut de ticket.
 L’administrateur doit avoir la possibilité de configurer et paramétrer l’application.
 L’administrateur doit avoir la possibilité de gérer les demandes.
 L’administrateur doit avoir la possibilité de créer des utilisateurs privilégiés et d’ajouter
et modifier leurs permissions.
 L’administrateur doit avoir la possibilité de consulter les statistiques de l’application.
 L’utilisateurs doit avoir la possibilité de communiquer avec l’administration de
l’application.
 L'application doit automatiser les processus autant que possible et minimiser les entrées
pour assurer la simplicité.
2.3.3 Diagramme de cas d'utilisation

Le diagramme des cas d'utilisation (Use Case Diagram) constitue la première étape de
l’analyse UML en modélisant les besoins des utilisateurs, identifiant les grandes fonctionnalités
et les limites du système, et représentant les interactions entre le système et ses utilisateurs [3].
20
C'est pour ces raisons que l'établissement du diagramme de cas d'utilisation est très
important pour un bon démarrage du projet.
Dans la partie qui suit, nous allons présenter l’ensemble des cas d’utilisation de la
plateforme WeKareYou en se basant sur les diagrammes des cas d’utilisation du système et les
descriptions contextuelles des cas d’utilisation. Les cas d'utilisation sont présentés ci-après en
fonction des acteurs du système.
2.3.3.1 Diagramme de cas d’utilisation pour l’administrateur
Les présents cas d’utilisation concernent l’acteur administrateur. Une fois authentifié,
l’administrateur peut gérer les utilisateurs et leurs droits, gérer les services et les options, gérer
les factures, les demandes, les tickets, les litiges, les notifications et consulter le Dashboard de
l’application, et il peut également accéder à l’espace de configuration pour paramétrer la
plateforme. Tous les cas d’utilisation passent obligatoirement par une authentification (voir la
figure 9) :
Figure 9 : Cas d’utilisation du profil Admin.
21
2.3.3.2 Diagramme de cas d’utilisation pour le patient
Les présents cas d’utilisation concernent l’acteur patient (demandeur de soins). Une fois
authentifié, le demandeur de soins à la possibilité de gérer son compte, de consulter les services
et options de la plateforme, de créer une demande des soins, de consulter les profils des
prestataires, de consulter les notifications et la listes des prestataires, et bien sûr la possibilité
de déconnecter de son espace. Tous les cas d’utilisation nécessitent une authentification (voir
la figure 10) :
Figure 10 : Cas d’utilisation du profil patient.
22
2.3.3.3 Digramme de cas d’utilisation pour le prestataire
Les présents cas d’utilisation concernent l’acteur prestataire. Après avoir authentifié le
prestataire peut gérer son profil, les demandes ainsi que les factures (voir la figure 11)
Figure 11 : Cas d’utilisation du profil prestataire.
2.3.4 Description contextuelle des cas d’utilisation

Les descriptions contextuelles sont utilisées pour documenter différents cas d'utilisation en
montrant les interactions dans un cas de succès typique (le cas nominal) avec des informations
contextuelles et un cas d'exception typique (le cas d'erreur) s'il existe.
2.3.4.1 Description contextuelle des cas d'utilisation administrateur
Cas d’utilisation S’authentifier : permet à l'administrateur de se connecter au système avec son

login (adresse mail) et son mot de passe afin de sécuriser l’application.
23
Sommaire d'identification :
Objectif : Cette fonctionnalité permet à l’administrateur de se connecter à la plateforme.

Acteur : l’administrateur.
Pré condition : L’acteur se connecte au système.
Post condition : L’accès à l’espace d’acteur.
Description des scénarios :
Scénario nominal :
1. L’acteur saisit son login et son mot de passe.
2. Le système vérifie les informations saisies.
3. Le système constate que les informations saisies sont valides.
4. Le système vérifie le rôle de l’acteur.
5. Le système connecte l’acteur à son espace.
Scénario d’erreur : données non valides
1. L’acteur saisit son login et son mot de passe.
2. Le système vérifie les informations saisies.
3. Le système constate que les informations saisies ne sont pas valides.
4. Le système demande à l’acteur de vérifier les informations saisies.
Tab 6 : Description contextuelle du cas d'utilisation admin "s’authentifier "
Cas d’utilisation Gérer utilisateurs : permet à l’administrateur de s'occuper de la gestion des

utilisateurs de la plateforme.
Objectif : Cette fonctionnalité permet à l’administrateur de gérer les utilisateurs du

WeKareYou qui sont soit des utilisateurs simples (prestataire / patient) ou des utilisateurs
privilégiés.
Acteur : l’administrateur
Précondition : L’acteur se connecte à son espace.
Scénarios nominaux :
1. Gérer les utilisateurs privilégiés
1.1 Ajouter utilisateur avec des privilèges
L’acteur saisit les informations de l’utilisateur.
L’acteur assigner des privilèges et des permissions à cet utilisateur.
Le système confirme l’enregistrement de l’utilisateur à l’administrateur.
24
Le système affiche la liste des utilisateurs contenant l’utilisateur ajouté.

1.2 Désactiver utilisateur
L’acteur affiche la liste des utilisateurs.
L’acteur sélectionne l’utilisateur à désactiver.
Le système alerte l’acteur de son action.
L’acteur valide son action.
Le système confirme à l’acteur la désactivation de l’utilisateur.
1.3 Modifier utilisateur
L’acteur sélectionne l’utilisateur à modifier.
Le système affiche les informations et les privilèges de l’utilisateur
sélectionné.
L’acteur modifie les champs ou les privilèges concernés.
L’acteur attribue / désattribue des privilèges.
L’acteur valide ses modifications.
Le système confirme à l’acteur que les informations ont été mises à
jour. Le système affiche la liste des utilisateurs contenant l’utilisateur
modifié.
2. Gérer les simples utilisateurs
2.1 Accepter / rejeter l’inscription d’un prestataire
L’acteur affiche la liste des demandes d’inscription.
L’acteur sélectionne une demande.
Le système affiche les informations sur la demande et les fichiers
joints de la demande sélectionnée.
L’acteur consulte les fichiers et les informations de la demande.
L’acteur accepte/rejette la demande d’inscription et ajoute un
commentaire.
Le système informe le prestataire de la décision de l'administrateur.
Le système met à jour la liste des demandes.
2.4 Suspendre / activer utilisateur
L’acteur sélectionne l’utilisateur à suspendre / activer.
Le système alerte l’acteur sur son action.
Le système confirme la suspension / activation de l’utilisateur à l’acteur.
3. Chercher des utilisateurs
L’acteur clique sur l’icône de recherche.
L’acteur choisit les critères de recherche.
25
L’acteur lance la recherche.

Le système affiche les résultats de la recherche
Scenario d’erreur :
2.3.d Si l'utilisateur a des tâches incomplètes sur la plate-forme, le système empêche
sa suppression et affiche un message d'erreur.
Tab 7 : Description contextuelle du cas d'utilisation admin "Gérer utilisateurs"
Cas d’utilisation Gérer les services :
Objectif : Cette fonctionnalité permet à l’administrateur de gérer la liste des services et

des options disponibles dans la plateforme.
Pré condition : L’acteur se connecte à son espace.
1. Ajouter service
L’acteur saisit les informations de service et ses options s’elles existent.

Le système confirme à l’administrateur l’enregistrement du service.
Le système affiche la liste des services contenant le service ajouté.
2. Désactiver service
L’acteur affiche la liste des services de la plateforme.

L’acteur sélectionne le service à désactiver.
Le système confirme à l’acteur la désactivation du service.
3. Modifier service
L’acteur affiche la liste des services.

L’acteur sélectionne un service à modifier.
Le système affiche les informations relatives au service sélectionné.
L’acteur modifie les champs concernés.
Le système confirme à l’acteur que les informations ont été mises à jour.
Tab 8 : Description contextuelle du cas d'utilisation admin "Gérer services"
26
Cas d’utilisation Gérer les factures :
Objectif : Cette fonctionnalité permet à l’administrateur de gérer la liste des factures du

prestataires et patient.
Pré condition : L’acteur se connecte à son espace.
1. Générer facture
L’acteur crée une facture.

L’acteur sélectionne le destinataire de la facture.
L’acteur ajoute les informations nécessaires.
Le système affiche les informations et le format final de la facture à l’acteur.
L’acteur valide la facture.
L’acteur programme une date d’envoi de la facture.
Le système confirme la création de la facture à l’acteur.
2. Modifier statut facture :
L’acteur affiche la liste des factures.

L’acteur sélectionne une facture à modifier.
Le système affiche les informations de la facture sélectionnée.
L’acteur ajoute un scan de versement s’il existe.
le système met à jour la listes des factures.
Tab 9 : Description contextuelle du cas d'utilisation admin "Gérer factures"
Cas d’utilisation Gérer les tickets / litiges :
Objectif : Cette fonctionnalité permet à l’administrateur de gérer la liste des tickets crées
par les utilisateurs de la plateforme.
27
1. Changer statut ticket
L’acteur affiche la liste des tickets.

L’acteur sélectionne un type de ticket.
L’acteur sélectionne un ticket à modifier.
Le système affiche les informations et le statut du ticket sélectionnée.
L’acteur modifie le statut du ticket.
L’acteur valide la modification.
Le système confirme à l’acteur que le statut a été mis à jour.
Tab 10 : Description contextuelle du cas d'utilisation admin "Gérer tickets/litiges"
2.3.4.1 Description contextuelle des cas d'utilisation pour le patient
Cas d’utilisation s’authentifier : permet aux utilisateurs de se connecter au système avec un

numéro valide de téléphone après la vérification d’un code qui va être envoyer par SMS afin de
sécuriser la plateforme.
Objectif : Cette fonctionnalité permet aux utilisateurs de se connecter.

Acteur : les simples utilisateurs (les patients et les prestataires)
Précondition : L’acteur se connecte au système.
Postcondition : L’accès à l’espace d’acteur.
Scénario nominal :
1. L’acteur choisit une méthode d’authentification (par téléphone / par Facebook).
2. L’acteur saisit son numéro de téléphone.
3. Le système vérifie la validation de numéro saisi.
4. Le système constate que le numéro saisi est valide.
5. Le système envoie un code de vérification au numéro saisi.
6. L’acteur saisie le code de vérification
7. Le système vérifie le code saisi par l’acteur.
8. Le système constate que le code saisi est valide.
9. Le système connecte l’acteur à son espace.
3.a. Si le numéro saisi par l’acteur n’est pas valide, le système affiche un message
d’erreur.
3.b. Le système demande à l’acteur de vérifier leur numéro saisi.
7. a. Si le code saisi par l’acteur est incorrect le message affiche un message
d’erreur.
28
7.b. l’acteur a la possibilité de renvoyer le code à son numéro après 1min.

7.c. Chaque fois le code est incorrect le système affiche un message d’erreur et
demande de ressaisir le code
7.d. Si l’acteur dépasse 5min, le système supprime le code et demande de saisir à
nouveau le numéro pour envoyer un nouveau code.
Tab 11 : Description contextuelle du cas d'utilisation patient "s'authentifier"
Cas d’utilisation s’inscrire : Cette fonctionnalité est la même décrite dans le cas d’utilisation
précèdent « s’authentifier patient ».
Cas d’utilisation Gérer le compte profil :
Objectif : Cette fonctionnalité permet au patient de gérer son compte personnel.

Acteur : le patient
1. Consulter profil
L’acteur accède à son profil.

Le system affiche les informations personnelles et le pourcentage de validation
du profil
L’acteur clique sur mes adresses pour consulter et ajouter des localisations.
L’acteur clique sur services favoris pour consulter la liste des prestataires
préférer.
L’acteur clique sur paramètres pour configurer les méthodes de notification.
L’acteur clique sur mes demandes pour consulter la liste des demandes en
cours ou terminées.
L’acteur clique sur mes tickets pour consulter la liste des tickets en cours ou
fermés.
2. Supprimer profil

L’acteur clique sur supprimer mon profil.
L’acteur confirme son action.
Le système redirige l'acteur vers la page d'accueil.
Tab 12 : Description contextuelle du cas d'utilisation patient "Gérer profil"
29
Cas d’utilisation Consulter les services :
Objectif : Cette fonctionnalité permet au patient de gérer son compte personnel.

Acteur : le patient
1. Chercher service :
L’acteur sélectionne les critères de recherche.
L’acteur lance la recherche.
Le système affiche les résultats de recherche.
2. Consulter et partager profil du prestataire

L’acteur cherche un service.
L’acteur sélectionne un service/offre à consulter.
Le système affiche les informations du service où existe également le profil du
prestataire.
L’acteur clique sur le profil du prestataire pour afficher plus de détails sur
celui-ci.
Le système affiche le profil du prestataire.
L’acteur partage le profil.
3. Demander service
L’acteur accède à la page d’accueil.

L’acteur clique sur un service.
Le système redirige l’acteur vers l’espace des offres de service.
L’acteur cherche une offre de soins.
L’acteur sélectionne une offre.
L’acteur consulte les détails de l’offre et le profil du prestataire.
L’acteur clique sur demander.
Le système affiche un formulaire à remplir.
L’acteur remplit le formulaire.
Le système demande l’ajout de l’adresse de prestation.
L’acteur ajoute une localisation.
L’acteur choisit une méthode de paiement et paie.
Le système confirme à l’acteur la création de la demande de soins.
Tab 13 : Description contextuelle du cas d'utilisation patient "Consulter services"
30
Cas d’utilisation Consulter les tickets :
Objectif : Cette fonctionnalité permet au patient de gérer ses tickets personnels.

Acteur : le patient
1. Ajouter ticket
L’acteur clique sur l’icône d’ajouter ticket.

Le système demande à l’acteur de choisir le type de ticket.
L’acteur choisit un type de ticket et click sur suivant.
Le système demande de l’acteur de remplir un formulaire.
L’acteur remplit les champs nécessaires et valide.
Le système confirme la création de ticket à l’acteur.
2. Modifier ticket

L’acteur affiche la liste des tickets.
L’acteur sélectionne un ticket à modifier.
Le système affiche le statut et les informations du ticket sélectionné.
Le système affiche à nouveau la liste des tickets.
Tab 14 : Description contextuelle du cas d'utilisation patient "Consulter tickets"
Cas d’utilisation Consulter les demandes :
Objectif : Cette fonctionnalité permet au patient de gérer ses demandes et les suivis avec
la possibilité de créer un litige.
Acteur : le patient
1. Consulter les demandes en cours :
1.1 Suivre demande
31
L’acteur affiche la liste des demandes en cours.

Le système affiche les statuts et les détails de la demande.
L’acteur appelle le prestataire s’il veut.
L'acteur ajoute un litige en cas d'un problème rencontré.
L’acteur ajoute une revue à la fin du suivi.
Le système informe les parties prenantes des modifications apportées au
statut de la demande.
1.2 Annuler demande :
L’acteur affiche la liste des demandes en cours.
Le système affiche les détails de la demande
L’acteur annule la demande et ajoute un commentaire s’il veut.
Le système confirme à l’acteur l’annulation de la demande et met à jour la
liste des demandes en cours
1.3 Continuer les étapes d’une demande
L’acteur affiche la liste des demandes incomplètes.
Le système affiche les étapes non complétées de la demande
L’acteur complète les étapes et confirme.
Le système confirme à l’acteur la création de la demande et met à jour la
liste des demandes.
2. Consulter les demandes terminées :
2.1 Modifier une revue

L’acteur affiche la liste des demandes terminées.
Le système affiche les informations de la demande sélectionnée.
L’acteur clique sur la revue pour la modifier.
L’acteur modifie la revue.
L’acteur valide la modification.
Le système confirme à l’acteur la modification et met à jour les
informations de la demande
3. Rechercher demande
L’acteur affiche la liste des demandes.
L’acteur sélectionne les critères de recherche.
Le système affiche les détails de la demande sélectionnée
Tab 15 : Description contextuelle du cas d'utilisation patient "Consulter demandes"
32
2.3.4.3 Description contextuelle des cas d'utilisation pour le prestataire
Cas d’utilisation s’authentifier : Cette fonctionnalité est la même décrite pour le patient.
Cas d’utilisation s’inscrire : permit au prestataire de s’inscrire sur la plateforme.
Objectif : Cette fonctionnalité permet au prestataire d’inscrire et d’ajouter des offres.

Acteur : Le prestataire
Précondition : L’acteur s’authentifie.
Le système affiche les étapes d'inscription.
L’acteur ajoute les services et les options qu’il offre avec leur prix et valide.
L’acteur ajoute les disponibilités de la semaine et valide.
L’acteur sélectionne une ville d’intervention.
L’acteur ajoute les régions d’interventions et valide.
Le système affiche un formulaire à remplir.
L’acteur ajoute des informations personnelles et valide.
L’acteur ajoute les fichiers de validation de compte : le diplôme, le CIN, etc.
Le système affiche les termes et les conditions de l’application
L’acteur accepte les conditions de l’application et valide.
Le système confirme à l’acteur la création du compte.
Tab 16 : Description contextuelle du cas d'utilisation prestataire "s’inscrire"
Cas d’utilisation Gérer le compte profil :
Objectif : Cette fonctionnalité permet au prestataire de gérer son compte personnel.

Acteur : le prestataire
1. Consulter profil
Le system affiche les informations personnelles de l’acteur.
L’acteur clique sur programme pour consulter sa disponibilité.
33
L’acteur clique sur les demandes pour consulter la liste des demandes selon leur
état.
L’acteur clique sur facture pour consulter la liste des factures selon leur état.
2. Modifier profil
2.1 Modifier les informations personnelles
Le système affiche les informations personnelles de l’acteur.
2.2 Modifier les services et les prix et les régions d’interventions
L’acteur clique sur les services et options pour consulter et modifier les
services.
Le système affiche la liste des services et options, et leur prix.
2.3 Modifier les régions d’interventions

L’acteur clique sur les régions d’intervention.
Le système affiche la ville du prestataire et la liste des secteurs.
L’acteur modifie les régions d’interventions.
2.4 Modifier les disponibilités
L’acteur accède à son espace.

Le system affiche les informations personnelles de l’acteur.
L’acteur clique sur le programme pour consulter et modifier sa disponibilité.
Le système met à jour les informations et informe l’acteur par les
modifications apportées.
3. Supprimer profil
Cette fonctionnalité est la même que celle décrite pour le profil du patient.
Tab 17 : Description contextuelle du cas d'utilisation prestataire "Gérer profil"
Cas d’utilisation Consulter les demandes :
Objectif : Cette fonctionnalité permet au prestataire de consulter les demandes et changer

leurs statuts.
34
Précondition : L’acteur se connecte à son espace
1. Accepter/ rejeter demande
L’acteur affiche la liste des demandes de soins.

Le système affiche les informations sur la demande.
L’acteur consulte les informations de la demande.
L’acteur accepte/rejette la demande.
Le système envoie un message informatif au demandeur de soins.
Le système met à jour le statut de la demande et affiche la page de Suivi de la
demande.
2. Ajouter ticket
Cette fonctionnalité est la même que celle décrite dans le cas d’utilisation ajouter
ticket (Patient).
3. Rechercher demande
Cette fonctionnalité est la même que celle décrite dans le cas d’utilisation
rechercher demande (Patient).
4. Changer statut demande
L’acteur affiche la liste des demandes de soins en cours.
Le système affiche les informations de la demande et le Traking Map.
L’acteur modifier le statut.
Le système met à jour le statut de la demande.
Le système envoie un message informatif au demandeur de soins.
5. Consulter le profil du patient
L’acteur affiche la liste des nouvelles demandes de soins en attente.

Le système affiche les informations de la demande et le profil de patient.
L’acteur clique sur le profil du patient pour afficher plus de détails sur celui-ci.
Le système affiche le profil du prestataire.
Tab 18 : Description contextuelle du cas d'utilisation prestataire "Consulter demandes"
35
Cas d’utilisation Consulter les factures :
Objectif : Cette fonctionnalité permet au prestataire de consulter et payer ses factures.

1. Payer une facture
L’acteur affiche la liste des factures.
L’acteur sélectionne une facture à consulter.
Le système affiche les informations de la facture sélectionnée
L’acteur ajoute un scan de versement si le paiement est par virement.
L’acteur paie la facture sélectionnée.
Le système vérifie les informations de paiement.
Le système met à jour le statut de la facture.
Le système met à jour la liste des factures.
6.a. Si les informations de paiement saisi par l’acteur n’est pas valide, le système affiche
un message d’erreur.
Tab 19 : Description contextuelle du cas d'utilisation prestataire "Consulter factures"
2.3.5 Diagramme de processus - BPMN

Le Business Process Model and Notation (BPMN) est la norme standard pour la
modélisation de processus métier, est une méthode d’organigramme qui modélise d’A à Z les
étapes d’un processus métier planifié. Élément clé de la gestion d’un processus métier, elle
permet de représenter visuellement une séquence détaillée des activités et des flux
d’informations nécessaires à la réalisation d’un processus [4]
Le but principal de BPMN est de fournir une notation qui soit facilement compréhensible
par tous les utilisateurs de l'entreprise, depuis les analystes métier qui créent les ébauches
initiales des processus, jusqu'aux développeurs responsables de mettre en place la technologie
qui va exécuter les processus applicatifs correspondants, et finalement, jusqu'aux utilisateurs de
l'entreprise qui vont mettre en œuvre ces processus. [5]
36
BPMN et UML sont complémentaires, en fait BPMN est ressemblé aux diagrammes de
flux et d'activité en UML. Et ci-dessous les diagrammes de processus que nous avons réalisé
dans notre projet
Diagramme de processus : Demander service
Le présent diagramme (figure 12) décrit les détails du processus de demande de service en
montrant le flux d'informations et les différentes étapes par lesquelles passe une demande de sa
création à son achèvement et les acteurs qui interagissent et participent à ce processus.
Figure 12 : BPMN – Demander service
Premièrement le patient sélectionne un service et consulte les offres de soins disponibles

pour trouver une offre convenable, après que le patient ait sélectionné un prestataire, il peut
commencer la création de la demande, à cette étape le système vérifie si le patient est authentifié
ou non : si c'est le cas, c'est-à-dire que l'utilisateur n'est pas authentifié, le système obligera
l’authentification. Dès que l’utilisateur est authentifié, la plateforme demandera le lieu de la
prestation, après cela, l’utilisateur sera invité à remplir un formulaire contenant les informations
nécessaires à la prestation. Avant d’envoyer la demande, il doit choisir une méthode de
paiement en ligne ou en espèce. Si le patient choisit le paiement en ligne, le système vérifiera
37
les informations de paiement et enverra la demande au prestataire, si le paiement est en espèces,

la création de la demande est terminée. Et le système attendra l'approbation du prestataire pour
afficher le suivi complet au patient, et si le prestataire refuse la demande, le système
recommandera d'autres prestataires.
Diagramme de processus : l’inscription du prestataire
Le présent diagramme (figure 13) décrit les détails du processus d’inscription d’un
prestataire sur la plateforme en montrant le flux d'informations et les différentes étapes par
lesquelles passe une demande d’inscription depuis sa création jusqu’à la validation de
l’administrateur et les acteurs qui interagissent et participent à ce processus.
Figure 13 : BPMN - l'inscription du prestataire
Diagramme de processus : changement statut balance
Le présent diagramme (figure 14) décrit le processus de changement de statut de la balance

du prestataire selon la méthode de paiement.
Figure 14 : BPMN - Changement statut balance
38
Diagramme de processus : facturation
Le présent diagramme (figure 15) décrit les détails du processus de facturation des
demandes en montrant le flux d'informations et les différentes étapes par lesquelles passe une
facture de sa création à sa génération ainsi que les acteurs qui interagissent et participent à ce
processus.
Figure 15 : BPMN - facturation
Diagramme de processus : traitement des litiges
Le présent diagramme (figure 16) décrit les détails du processus de traitement d’un litige
en montrant le flux d'informations et les différentes étapes par lesquelles passe un litige de son
ouverture à sa fermeture ainsi que les principaux acteurs qui interagissent et participent à ce
processus.
39
Figure 16 : BPMN- traitement des litiges
2.3.6 Spécifications fonctionnelles de système

Le système (la plateforme lui-même) peut effectuer les tâches suivant d’une manière
automatique :
1. Vérifier la validation des données : Mot de passe, Email, Nom, etc.

2. Vérifier les droits d’accès.
3. Envoyer des rappels et des messages informatifs sur les changements et les mises à
jour.
4. Recommander des prestataires en fonction des demandes.
5. Générer et envoyer un contrat pour les prestataires.
6. Générer les factures.
2.4 Conclusion
Le but de ce chapitre était de définir et d’analyser l’ensemble des besoins fonctionnels de
notre solution. Cette étape est primordiale dans le développement d’un projet informatique
puisqu’elle nous permet de définir le périmètre fonctionnel du projet, et de garantir la
couverture de l’ensemble des fonctionnalités recensées.
40
Chapitre 3
Étude Conceptuelle et architecturale
“ Dans ce chapitre nous allons nous concentrer sur l’aspect conceptuel et architectural
de la solution à mettre en place. Cette étude conceptuelle est basée sur l’élaboration et
l’analyse des différents schémas et diagrammes de classes. ”
41
Chapitre 3 : Étude Conceptuelle et architecturale
3.1 Étude Conceptuelle

3.1.1 Diagrammes de séquence
Les diagrammes de séquence sont une solution de modélisation dynamique très
appréciée. La modélisation dynamique s'intéresse aux interactions se produisant à l'intérieur
d'un système. Les diagrammes de séquence sont plus précisément consacrés aux « liens vitaux
» d'un objet et comment ils communiquent avec d'autres objets pour accomplir une action avant
que le lien vital ne s’interrompe [6].
Séquence d’authentification par numéro téléphone :
Ce diagramme représente le diagramme de séquence du cas d'authentification d'un patient ou

d'un prestataire utilisant un numéro de téléphone.
Cela commence par la saisie du numéro de téléphone par l'acteur, puis le système vérifie si le
numéro est valide, si ce n'est pas le cas le système lui demande de ressaisir son numéro de
téléphone, s'il est valide un code par message lui est envoyé. Si le code est correct, l'acteur se
connecte, sinon il doit attendre 1 minute pour pouvoir entrer à nouveau le code ou il peut
demander au système de lui en envoyer un nouveau, mais si le temps dépasse 5min en général,
le système efface le code et demande d'entrer à nouveau le numéro pour envoyer un nouveau
code.
La figure suivante (figure 17) représente la séquence d’authentification par numéro de

téléphone :
42
Figure 17 : Diagramme de séquence “authentification”
Séquence de demander un service de soins :
Ce diagramme représente le diagramme de séquence de la consultation d'un service par un

patient.
Tout d'abord, le patient accède à la page d'accueil de l'application puis clique sur service,
ce qui l'amène à la zone des offres de service.
Il affiche la liste des offres et choisit celle qui lui convient le mieux, ensuite il consulte les
détails de l'offre et de son prestataire, puis il clique sur demander, s'il n'est pas authentifié, il est
dirigé vers l'espace d'authentification, s'il l'est, il est invité à remplir un formulaire, puis à ajouter
son adresse. Ensuite, il choisit son mode de paiement préféré : si c'est en ligne, il saisit ses
informations, puis le système vérifie si elles sont correctes, sa demande est créée, sinon un
message d'erreur est délivré, si c'est en espèces, un message de succès est délivré.
Ensuite, la liste des offres est envoyée aux prestataires pour être contrôlée et vérifiée, puis
le prestataire envoie sa réponse.
43
Si la demande est acceptée, un message de réussite et des informations de suivi sont

envoyés au patient concerné, sinon, pour des raisons de planning, un message d'erreur est
envoyé au patient avec une liste d'autres prestataires disponibles en fonction de son offre, avec
la possibilité de choisir l'un d'entre eux ou non.
La figure suivante (figure 18) représente la séquence de demander un service de soins :
Figure 18 : Diagramme de séquence "demander service"
44
3.1.2 Diagramme de Classe

Il représente les classes intervenant dans le système. Le diagramme de classe est une
représentation statique des éléments qui composent un système et de leurs relations [7].
C’est dans ce contexte que la présente tentative de modélisation en classes prend place. En
fait, nous avons deux classes de deux acteurs (prestataire et patient) qui hérite d’une classe mère
(utilisateur). Le patient peut demander un ou plusieurs demandes de soins alors qu’un service
de soins ne peut être effectuer que par un et un seul prestataire, mais cette dernière peut bien
créer plusieurs offres de soins à travers son inscription et son profil.
D’autre part, un simple utilisateur (patient ou prestataire) peut créer un ou plusieurs

tickets (réclamation) et cette dernière a un et un seul propriétaire.
Chaque facture concerne un ou plusieurs demandes et peut être payer par un seul
prestataire.
Le prestataire a un ou plusieurs disponibilités tandis que chaque disponibilité concerne un

et un seul prestataire
La figure suivante (figure 19) représente le diagramme de Classe :
45
Figure 19 : Diagramme de classe.
46
3.2 Etude technique

Dans cette partie, nous procéderons à l’étude technique du projet. Dans un premier lieu
nous allons présenter l’architecture, le cycle et la branche de développement, avant de détailler
l’environnement de développement à savoir les outils utilisés et les langages adoptés. Ce choix
d’outils peut influencer la qualité du produit obtenu et donc nécessite une attention
particulière et doit se baser sur les besoins du projet et le résultat escomptés.
3.2.1 Structure et Architecture de développement

La bonne préparation de l’architecture du développement et le bon choix de cette
dernière est une phase critique du projet, car grâce à elle le projet se lance dans des bonnes
conditions et continue correctement pour atteindre ses objectifs, et à cause d’elle le projet vient
à des points quand il se bloque et complique la vie.
3.2.1.1 Architecture globale du projet
Grâce aux causes citées auparavant, nous avons choisi l’architecture globale suivante
(figure 20) qui est capable de répondre aux besoins expliqués dans le cahier de charges :
Figure 20 : Architecture globale du développement.
En effet, notre architecture se compose de trois grandes composantes qui communiquent

entre eux :
 La couche Client : c’est la couche visible pour l’utilisateur et dans laquelle la

manipulation de différentes données est faite. C’est une couche qui contient l’ensemble
des ressources JS, CSS et visuelles. De plus, cette couche contient les actions transmis à
la couche Serveur, et le Store où nous stockons des données après le feedback venant du
Serveur.
47
 La couche Serveur : c’est une couche qui s’occupe de la communication avec la base de
données, après avoir réalisé les opérations nécessaires au niveau du résolveur. Non
seulement ça, mais cette couche est responsable aussi de la transmission des données
nécessaire au web service et de stocker les fichiers dans le serveur de stockage.
 La couche Données : c’est la couche au niveau de laquelle on stocke nos données.
3.2.1.2 Architecture spécifique
Après avoir présenté l’architecture globale du projet, on vient à la spécification des détails
de l’architecture et la logique suivie pour choisir les technologies du système.
Figure 21 : Architecture spécifique de développement.
En fait, nous allons utiliser dans la couche Client web (Front) Next JS caractérisé par son
architecture détaillé et compréhensible. Et dans la partie mobile nous allons utiliser
ReactNative. La figure suivante (figure 22 - 23) illustre la structure du projet dans la couche
Client :
48
Figure 23 : Structure du projet (côté Front - web) Figure 22 : Structure du projet (côté Front - mobile)
Or, pour la couche Serveur, on a utilisé NodeJS (Express) et le module Mongoose qui
garantit la communication avec la base de données. La figure suivante (figure 24) illustre la
structure du projet dans la couche Serveur :
Figure 24 : Structure du projet (côté Back)
49
Finalement, pour la base de données nous avons choisi une base de données NoSQL qui
est MongoDB qui communique avec la couche serveur à travers des objets JSON. La figure
suivante (figure 25) illustre les différents modules du projet.
Figure 25 : Modules du projet.
3.2.2 Cycle de développement
Figure 26 : Cycle de développement de notre projet.
50
Le développement dans notre projet se fait par plusieurs étapes consécutives. Nous allons
commencer d'abord par la préparation des maquettes graphiques qui donnent une idée assez
exacte sur le résultat attendu. Nous allons passer après à la phase de division des tâches qui se
fait durant la réunion du Scrum Planning dans le début de chaque Sprint. L’étape prochaine
c’est l’intégration des maquettes graphiques sous le serveur Client. Après validation de
l’intégration, nous commencerons le développement des fonctionnalités et on les tests après en
utilisant le Cross Testing dans lequel chaque membre de l’équipe de développement teste les
fonctionnalités développées par un autre membre de l’équipe.
Finalement, et après traitement de retour des BUGS de l’ancienne étape, et après validation,
Nous allons passer au déploiement en ligne du projet.
3.2.3 Branche de développement
Figure 27 : Branche de développement d'un projet [8].
En fait, il y a deux branches principales “dev” et “Main ”, et d’autres branches temporaires

qui servent à traiter les BUGS ou le développement de quelques fonctionnalités précises.
Concernant la branche “dev”, c’est la branche dans laquelle sont faits tous les
développements. Alors que la branche “Main” correspond au code dans sa version prête à
déployer. Aucun commit ne doit être fait sur cette branche. Un fusionnement (Merge) de la
branche “ dev” est fait dans cette branche au moment des releases. La figure suivante (figure
28) illustre les branches créer par l’équipe WeKareYou dans Gitlab :
51
Figure 28 : Branches "WeKareYou".
Pour une bonne gestion du versioning du projet, Il arrive qu’on remonte des problèmes
dans l’environnement de production ! Une branche “Hotfix” est alors utilisée pour corriger ce
qui peut l’être facilement. C’est une branche utilisée uniquement pour de petites interventions
simples sur le code de production. C’est la seule branche qui part directement de la branche de
production “Main”. Dès que la correction est faite, elle est fusionnée à la fois avec la branche
de développement (dev) et avec la branche de production (Main) et celle-ci est taguée avec un
nouveau numéro de version.
Avoir une telle branche de développement dédiée aux corrections de bug permet de les
corriger sans gêner le reste du processus de développement.
3.2.4 Outils et technologies utilisées

Dans n’importe quel projet, le choix des technologies est très important pour une meilleure
projection des phases précédentes de l’étude et l’analyse. Nous allons présenter les outils et
langages de programmation choisi pour la réalisation de notre projet, ainsi que la justification
des choix de ces outils et langages.
3.2.4.1 Outils de développement
Figure 29 : Outils de développement et intégration du projet.
52
Next js
Next JS, ce framework React orienté Server Side Rendering, s'est imposé parmi les
frameworks JavaScript les plus populaires. Il est livré par défaut avec des fonctionnalités
pratiques qui ne sont pas disponibles dans une application "vanilla" React. Next JS propose des
fonctionnalités hybrides de SSG (Static Generation) & SSR, c’est un outil puissant pour les
gens qui ont un fort besoin pour la performance des utilisateurs et le SEO.
Graphql
GraphQL (pour Graph Query Language) est un langage de requête développé et maintenu
par Facebook. Celui-ci permet notamment aux consommateurs de l’API de demander
seulement les champs nécessaires à l’inverse d’une API REST qui expose un schéma prédéfini.
Il est par exemple possible avec cette technologie d’effectuer une seule requête HTTP avec
différentes entités là où il est généralement nécessaire de faire plusieurs appels lorsqu’il s’agit
d’une API REST.
Apollo Server
Appollo server est un serveur GraphQL open source et conforme aux spécifications,
compatible avec n'importe quel client GraphQL, y compris Apollo Client. C'est le meilleur
moyen de créer une API GraphQL auto-documentée, prête pour la production, qui peut utiliser
des données de n'importe quelle source.
React native
React Native est un framework d'applications mobiles open source créée par Facebook. Il
est utilisé pour développer des applications pour Android, iOS en permettant aux développeurs
d’utiliser React avec les fonctionnalités natives de ces plateformes. Les principes de
fonctionnement de React Native sont pratiquement identiques à ceux de React, à la différence
que React Native ne manipule pas le DOM via le DOM virtuel. Il s'exécute dans un processus
en arrière-plan (qui interprète le code JavaScript écrit par les développeurs) directement sur le
terminal et communique avec la plate-forme native via une passerelle de sérialisation,
asynchrone et par lots.
53
Expo
Expo c'est à la fois un framework et une plateforme qui simplifient la création et le déploiement
d'applications mobiles avec React Native. Expo embarque de nombreux outils utiles et des
librairies natives pour React Native. Il gère aussi la mise à jour de ces librairies.
Type script :
TypeScript est un langage de programmation libre et open source développée par Microsoft
qui a pour but d'améliorer et de sécuriser la production de code JavaScript. Il s'agit d'un sur
ensemble syntaxique strict de JavaScript (c'est-à- dire que tout code JavaScript correct peut être
utilisé avec TypeScript). Le code TypeScript est transcompilé en JavaScript, et peut ainsi être
interprété par n'importe quel navigateur web ou moteur JavaScript.
TypeScript permet un typage statique optionnel des variables et des fonctions, la création
de classes et d'interfaces, l'import de modules, tout en conservant l'approche non contraignante
de JavaScript. Il supporte la spécification ECMAScript 6.
MongoDB
Nous allons utiliser un SGDB NoSQL à savoir MongoDB vu le nombre qui peut être
énorme des données dans la base de données, est un système de gestion de base de données
orienté documents, répartissable sur un nombre quelconque d'ordinateurs et ne nécessitant pas
de schéma prédéfini des données. Il fait partie de la mouvance NoSQL.
CSS
Les feuilles de styles (en anglais "Cascading Style Sheets", abrégé CSS) sont un langage
qui permet de gérer la présentation d'une page Web. Les styles permettent de définir des règles
appliquées à un ou plusieurs documents HTML. Ces règles portent sur le positionnement des
éléments, l'alignement, les polices de caractères, les couleurs, les marges et espacements, les
bordures, les images de fond, etc.
ReactJS
C’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 (ou portion) HTML à chaque
changement d'état.
54
Node.JS
C’est un environnement d'exécution JavaScript multiplate-forme et open source permettant

d'exécuter du code JavaScript côté serveur. Historiquement, JavaScript était principalement
utilisé pour les scripts côté client, dans lesquels les scripts écrits en JavaScript sont incorporés
dans le code HTML d'une page Web, à exécuter côté client par un moteur JavaScript dans le
navigateur Web de l'utilisateur. Node.js permet à JavaScript d'être utilisé pour les scripts côté
serveur et exécute des scripts côté serveur pour produire un contenu de page Web dynamique
avant que la page ne soit envoyée au navigateur Web de l'utilisateur.
Express
Express.js est un Framework pour construire des applications web basées sur Node.js. C'est
de fait le Framework standard pour le développement de serveur en Node.js.
Jest
Créée et maintenu par Facebook en 2014, Jest, rendu open-source, est une librairie de test
JavaScript ayant énormément gagné en popularité depuis sa mise en libre circulation. Conçu
pour fonctionner aussi bien sur du JavaScript côté navigateur (frontend) que côté serveur
(backend), Jest a su convaincre par sa rapidité d’exécution des tests, son API complète et sa
facilité d’installation. Sa documentation complète et bien maintenue en fait la librairie la plus
populaire pour tous les différents tests js.
Vs code
Visual Studio Code est un éditeur de code extensible développé par Microsoft pour
Windows, Linux et macOS2. Les fonctionnalités incluent la prise en charge du débogage, la
mise en évidence de la syntaxe, la complétion intelligente du code, les snippets, la
refactorisation du code et Git intégrer. Les utilisateurs peuvent modifier le thème, les raccourcis
clavier, les préférences et installer des extensions qui ajoutent des fonctionnalités
supplémentaires.
55
3.2.4.2 Outils de gestion
Le système de contrôle des versions GIT
C’est un logiciel libre de gestion de versions décentralisé, créé par Linus Torvalds (le
créateur du noyau Linux), c’est un outil bas niveau, qui se veut simple et très performant, dont
la principale tâche est de gérer l’évolution du contenu d’une arborescence. Il fonctionne en
mode distribué avec un serveur distant.
Figure 30 : Répertoire du projet sur Gitlab
JIRA
JIRA est un outil de gestion des projets en mode Agile, il est doté de fonctionnalités qui
visent à soutenir chacune des étapes des processus de développement de logiciels pour aider les
équipes de développement à planifier leurs projets.
Les majeures fonctionnalités de JIRA sont :
 Suivi des projets et des tickets

 Hiérarchisation de backlogs et planification de sprints
3.2.5 les contraintes de sécurité

Les contraintes de la sécurité de l’information ont été très importantes tout au long de la
mise en place du notre projet. Nous avons progressé étape par étape, en commençant par la
gestion des utilisateurs et leurs rôles. L’application doit être impénétrable depuis l’extérieur et
fortement sécurisée pour tout ce qui concerne l’accès aux données stockées dans le système.
Seuls les intervenants possédant un compte sont autorisés à accéder, et pour garantir une
meilleure sécurité à notre application 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. Ils seront renvoyés avec chaque requête
HTTP au serveur, ce qui lui permettra d’identifier l’utilisateur.
56
JSON Web Token
JSON Web Token (JWT) est un standard (RFC 7519) qui définit une solution compacte et
autonome pour transmettre de manière sécurisée des informations entre les applications en tant
qu’objet structuré au format JSON (JavaScript Object Notation). En raison de leur petite taille,
les JWT peuvent être envoyés via une URL, un paramètre POST ou dans un en-tête HTTP. De
plus, la plus petite taille signifie que la transmission est rapide. Le JWT contient toutes les
informations requises sur l’utilisateur, ce qui évite d’avoir à interroger la base de données plus
d’une fois pour connaitre le détail de l’identité d’un client authentifié. JWT est constitué de
trois parties séparées par un point «. » :
• Header (XXX)
• Payload (YYY)
• Signature (ZZZ)
La forme d’un JWT est donc : xxx.yyy.zzz

3.2.6 Les Tests unitaires :
De manière générale, les tests unitaires servent à s'assurer que les fonctions développées
dans un projet restent correctes pendant toute la durée de vie du projet. Par exemple : une
fonction, qui fait exactement ce qui est demandé pour tous les cas utiles. Plus tard, si nous
décidons d'ajouter un paramètre à cette fonction : les tests serviront à s'assurer que la fonction
continue de donner les bons résultats pour les premiers cas d'utilisation.
Comme déjà mentionné, nous avons utilisé « JEST » pour établir les tests unitaires au
niveau de quelques API du Backend. Ces tests se focalisent sur les fonctions CRUD. Après
démarrage du test sur un API, donne un récapitulatif des résultats obtenus. Les figures suivantes
illustrent les tests unitaires faites dans ce stade.
Figure 31 : Tests unitaires par jest
57
Les tests unitaires de « Authentification » :
Figure 32 : Résultats du test d'authentification
Les tests unitaires de « Services et options » :
Figure 33 : Résultats du test options et services
3.3 Conclusion
Ce chapitre présente une vue conceptuelle et technique de la solution à mettre en place. Il
expose les différents diagrammes UML pour mieux comprendre les fonctionnalités offertes et
pour mieux représenter la communication entre les différents objets du projet, Il expose aussi
l’environnement de développement, les outils et technologies utilisés dans le projet. Le chapitre
suivant, présente la partie mise en œuvre de l’application.
58
Chapitre 4
Mise en œuvre de la solution
“ Ce chapitre est le fruit de tout le travail et toutes les étapes menées pour l’obtention
d’une application web et mobile qui aide les patients à trouver des Professional de sante dans
leur quartier. Afin de mettre en évidence le résultat de notre travail, nous présenterons un
aperçu sur les différentes interfaces de notre application ”
59
Chapitre 4 : Mise en œuvre de la solution
L’une des étapes de la vie d’un projet, aussi importante que la conception, est
l’implémentation. Cette étape constitue la phase d’achèvement et d’aboutissement du projet.
L’objectif de cette partie est de donner un aperçu sur les différentes interfaces (IHMs) du
système développé, ainsi que les fonctionnalités offertes à l’utilisateur
4.1 Les interfaces graphiques de l’espace patient

Comme nous l'avons dit précédemment, nous avons commencé par la création de cet espace
dans la version web et nous avons comme objectif de travailler sur la version mobile après avoir
terminé l'espace du prestataire selon l'ordre des tâches que nous avons fait au début de projet.
4.1.1 Page d’authentification

Quand l’utilisateur clique sur « Se connecter » le système redirige l’utilisateur vers l’espace
d’authentification, où la connexion se fait soit par son numéro de téléphone ou son compte
Facebook.
Figure 34 : Page d'authentification
Au cas où le numéro du téléphone est erroné, un message d’erreur s’afficherait en dessous de

la case.
Figure 35 : Message d'erreur au cas d'anomalie
60
Après validation du numéro de téléphone par le système, ce dernier enverra un code de

quatre chiffres à l'utilisateur, qui est invité à saisir ce code pour pouvoir se connecter à son
espace.
Figure 36 : Page d'authentification après l'envoi de code
Si le code de confirmation n'est pas envoyé ou que l'utilisateur a du mal à retrouver son
code, il peut renvoyer le code sur son téléphone après 1 min.
Figure 37 : Message d'erreur au cas au le code incorrect
Si le code de validation est erroné, le système affiche une erreur et l'utilisateur ne peut pas
se connecter. Le patient a le droit de 5 essais et le code de vérification envoyé par le système
valable 5min sinon le système va demander de ressaisir le numéro de téléphone.
Figure 38 : Page d’authentification en mode responsive
61
4.1.2 Page d’accueil

La première page qui s’affiche présente la page d’accueil qui contient le bouton de ‘se
connecter’ ainsi qu’une présentation des différents services et le processus de l’envoi de la
demande.
Figure 39 : Page d'accueil WeKareYou.
Si l'utilisateur clique sur un service, le système affiche la page des offres où l'utilisateur
peut consulter les offres de service avant d'en demander une.
62
Figure 40 : Page des offres
Lorsque l'utilisateur clique sur le profil du fournisseur, une Pop-up s'affiche afin qu’il
puisse visualiser le profil du prestataire, sa disponibilité et les avis d'autres patients.
Figure 41 : Profil du prestataire (Popup)
En fait, la page d’accueil est responsive aux différentes versions d’affichage (Mobile,
Tablet, …). La figure suivante est une illustration d’un mode d’affichage :
Figure 42 : Page d'accueil en mode responsive
63
4.1.3 Page gestion profil patient

Les informations personnelles
La page ci-dessous présente le profil de patient et les champs à remplir. Les champs
contiennent des informations obligatoires que l’utilisateur doit remplir pour que son profil soit
validé.
Figure 43 : Profil patient
Le compte est considéré comme valide si le CIN est rempli et validé, et le compte est
considéré comme complet si tous les champs sont valides.
Figure 44 : Profil complet
64
La version arabe du profil :
Voici un exemple de Page du profil patient en mode responsive.
Figure 45 : Profil patient en mode responsive
Si le compte est vérifié (100%), la barre de l’état de validation de compte ne s'affichera pas
pour ne pas déranger l'utilisateur.
Voici la partie où le patient peut ajouter des adresses pour l'utiliser lors d’une demande.
Figure 46 : Page des adresses patient
65
Voici le formulaire d’ajout d’une adresse. Chaque adresse doit contient la ville, le secteur
et l’adresse exacte.
Figure 47 : formulaire d'ajouter une adresse
En mode responsive :
Figure 48 : Formulaire d'ajouter une adresse mode responsive
Après l’ajout des adresses :
Figure 49 : Ajout d’adresse (patient)
66
La section « des demandes » de patient où le patient peut consulter les listes des demandes
terminées ou en cours de traitement. Chaque service s’affiche avec son prix, sa date et son mode
de paiement.
Figure 50 : Page des demandes – patient (incomplet)
La section « Paramètres » où le patient peut choisir le canal de réception des notifications,

soit par courriel, soit par sms, et supprimer son compte.
Figure 51 : Page de paramètres - patient
La Section « Services favoris ».
L’utilisateur peut ajouter des services en favoris pour faciliter l’accès
Figure 52 : Services favoris (incomplet)
67
L’utilisateur peut ajouter des prestataires en favoris dans la Section « prestataires favoris ».
Figure 53 : Prestataires favoris (incomplet)
4.1.4 Page de demander un soin

Après avoir recherché et consulté le profil du prestataire, si le patient clique sur
"Demande", le système l'invite à compléter toutes les informations nécessaires pour envoyer la
demande.
Figure 54 : demande de soin
Après cette étape, l’utilisateur doit ajouter ou autoriser l’application à localiser son adresse.
Figure 55 : ajout d’adresse
68
L’utilisateur peut suivre le prestataire jusqu’à son arrivé
Figure 56 : tracking de prestataire
Le suivi en mode responsive :
Figure 57 : tracking de prestataire(responsive)
Sur cette page, l'utilisateur peut contacter l'équipe WeKareYou pour toute question.
Figure 58 : Formulaire de contactez-nous
69
4.2 Les interfaces graphiques de l’espace Prestataire

Nous avons commencé par créer l'espace réservé aux prestataires dans la version mobile et
nous avons l'intention de travailler sur la version web après avoir terminé l'espace réservé aux
patients dans les deux versions.
4.2.1 L’authentification
La figure ci-dessous représente la page d’accueil et la page de connexion de l’utilisateur à
travers son numéro de téléphone.
Figure 59 : Page d’authentification de prestataire
4.2.2 L’inscription du prestataire

Les démarches pour l'envoi de la demande d'inscription du prestataire, ce dernier doit
remplir toutes les cases pour que sa demande soit validée.
70
Figure 60 : Les étapes d'inscription du prestataires
4.2.3 Gestion profil prestataire

Cette figure représente les différentes options d'utilisation que le prestataire peut faire telles
que la gestion de son profil, la visualisation des notifications et différents paramètres.
Figure 61 : Profil prestataire
71
Le prestataire peut paramétrer et modifier son profil :
Figure 62 : Paramètres prestataires
4.2.4 Gestion des demandes

Le prestataire à l’accès de gérer les demandes et voir les informations du demandeur du
soin.
72
Figure 63 : Section demandes - prestataires
4.2.5 L’espaces des factures

En utilisant la page ci-dessous, le prestataire peut consulter l’état de ses factures dans cette
page.
Figure 64 : Liste des factures prestataires
73
Figure 65 : Détails d'une facture
Contactez-nous :
Le prestataire peut contacter l’admin WeKareYou en cas de besoin comme le montre la

figure ci-dessous.
Figure 66 : Contactez-nous prestataire - version mobile
4.3 Conclusion
Dans ce chapitre, nous avons présenté les interfaces graphiques de l'application et les
fonctionnalités de base de l'application à travers un ensemble de captures d'écran.
74
Conclusion générale & perspectives
Tout au long de la préparation de notre projet de fin d’études, nous avons essayé de mettre
en pratique les connaissances acquises durant nos études universitaires, pour répondre aux
objectifs de l’organisme d’accueil Wings Technologies qui sont la conception, l’intégration, le
déploiement et la réalisation d’une application web & mobile en deux versions Fr-Ar qui permet
l’intermédiation entre les professionnels de santé et les demandeurs de soins à domicile.
Dans ce cadre s’inscrit le présent travail où nous avons utilisé la méthodologie SCRUM pour
répondre aux objectifs.
La première itération du projet consistait en la définition du périmètre du projet. Les

itérations qui suivaient ont été consacrées à la réalisation de plusieurs modules métiers de base
comme la recherche d’une offre de soins et l’inscription des prestataires dans l’application. Lors
de chaque itération, une étude fonctionnelle a été effectuée suivie d’une conception détaillée
permettant par la suite d’enchaîner la phase de réalisation et de développement des modules en
question.
En termes de perspectives, le projet dans sa version actuelle n’est pas encore achevé, nous
sommes actuellement en cours de finaliser les parties qui restent dans les deux espaces ; l’espace
prestataire sur la version mobile, et l’espace patient sur la version web du projet. Les prochaines
itérations porteront toujours sur le sujet d’amélioration de l’expérience utilisateur et de la mise
en œuvre de l’espace d’administrateur. En plus de cela, l'amélioration du processus de demande
de service afin qu'il soit beaucoup plus rapide, plus facile et personnalisable par l'utilisateur.
Notre amélioration peut être enrichie par :
 La réalisation de la boite de messagerie WeKareYou
 L’amélioration de la sécurité et la performance de l’application
 La gestion des tickets par un module d’ERP
 L’utilisation de l’analyse de données comme discipline pour anticiper le comportement

des utilisateurs
 L’intégration des algorithmes de l'intelligence artificielle et machine learning dans la

solution, sur tout sur la partie des recommandations des services et prestataires.
 La réalisation des tests automatisés
75
Conclusion générale
 Basculer à une architecture de micro services pour mieux gérer la charge.
La base de tout ce projet est l’amélioration continue, la recherche constante et les corrections
de tous les processus de développement.
76
Webographie
[1] Définition d’une méthodologie [En Ligne] Disponible sur :

@ http://www.linternaute.com/dictionnaire/fr/definition/methodologie, Consulté en Mars
2021.
[2] Méthodes Agiles [En Ligne] Disponible sur :

@ http://www.idnext.net/la-methode-agile-quest-ce-que-cest/, consulté en Mars 2021.
[3] UML : Diagramme de cas d’utilisation [En ligne] Disponible sur :

@ http://remy-manu.no-ip.biz/UML/Cours/coursUML2.pdf, consulté en Mars 2021.
[4] BPMN [En Ligne] Disponible sur :

@ https://www.lucidchart.com/pages/fr/bpmn3. consulté en Avril 2021.
[5] Business_process_model_and_notation [En Ligne] Disponible sur :

@ https://fr.wikipedia.org/wiki/Business_process_model_and_notation ,consulté en Avril 2021.
[6] Tutoriel sur les diagrammes de séquences [En Ligne] Disponible sur :
@ https://www.lucidchart.com/pages/fr/tutoriel-sur-les-diagrammes-de-s%C3%A9quence ,
consulté en Avril 2021.
[7] Diagramme de Classes [En Ligne] Disponible sur :

@ http://www.uml-sysml.org/diagrammes-uml-et-sysml/diagramme-uml/diagramme-de-classe,
consulté en Avril 2021.
[8] Git branches [En Ligne] Disponible sur :

@ https://www.atlassian.com/fr/git/tutorials/comparing-workflows/gitflow-workflow,
consulté en Mai 2021.
77

Rapport PFE 2021 BENNAJAH

Transféré par

Informations du document

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

Rapport PFE 2021 BENNAJAH

Transféré par

Droits d'auteur :

Formats disponibles

Mémoire du Projet de Fin d'Études

En vue de l'obtention du diplôme

Conception et Réalisation d'une Application web & mobile

Organisme d'accueil : Wings Technologies

Réalisé par : Sous la direction de :

Soutenu le 05 juillet 2021, Devant le jury de :

À ma chère mère et à mon cher père

Qui ont toujours été là pour moi, qui m'ont

À mes frères, mes grands-parents et ma famille

À tous ceux qui m’ont aidé - de près ou de loin - et ceux

À tous mes amis

Qui m’ont toujours encouragé, et à qui je souhaite plus de succès.

Merci pour tous les moments inoubliables !

Je tiens, avant de présenter mon travail, à exprimer ma grande reconnaissance envers

Je tiens à remercier tout particulièrement et à témoigner toute ma reconnaissance à

Je tiens à remercier sincèrement M.Omar EL BANNAY, qui, en tant que professeur

L’étude technique et la mise en place de l'architecture de l'application a été faite

Mots clés : Soin à domicile, infirmières, services de soins, recommandation, GraphQL,

Keywords: Home care, Nursing management, care services, recommendation, GraphQL,

Table des matières ........................................................................................................................

Table des figures ...........................................................................................................................

Table des tableaux ........................................................................................................................

Liste des sigles et acronymes........................................................................................................

Introduction générale .................................................................................................................. 1

Chapitre 1 : Contexte général du projet ...................................................................................... 3

1.1 Présentation de l’organisme d’accueil ......................................................................... 4

1.1.1 Carte d’identité .............................................................................................. 4

1.1.2 Métiers Wings Technologies ......................................................................... 4

1.1.3 Organigramme de l’entreprise Wings Technologies ..................................... 6

1.2 Présentation et contexte du projet ................................................................................ 6

1.2.1 Cadre du projet .............................................................................................. 6

1.2.2 Problématique et solution proposée............................................................... 7

1.3 Conduite de projet ........................................................................................................ 9

1.3.1 Méthodologie de développement .................................................................. 9

1.3.2 Planification du projet ................................................................................. 13

1.4 Conclusion ................................................................................................................. 14

Chapitre 2 : Analyse et spécification des besoins..................................................................... 15

2.1 Spécification des besoins fonctionnels ...................................................................... 16

2.2 Spécification des besoins non fonctionnels ............................................................... 17

2.3.1 Identification des acteurs ............................................................................. 17

2.3.2 Etude de besoin............................................................................................ 18

2.3.3 Diagramme de cas d'utilisation ................................................................... 20

2.3.4 Description contextuelle des cas d’utilisation ............................................. 23

2.3.5 Diagramme de processus - BPMN .............................................................. 36

2.3.6 Spécifications fonctionnelles de système .................................................... 40

2.4 Conclusion ................................................................................................................. 40

Chapitre 3 : Étude Conceptuelle et architecturale .................................................................... 41

3.1 Étude Conceptuelle .................................................................................................... 42

3.1.1 Diagrammes de séquence ............................................................................ 42

3.1.2 Diagramme de Classe .................................................................................. 45

3.2 Etude technique .......................................................................................................... 47

3.2.1 Structure et Architecture de développement ............................................... 47

3.2.2 Cycle de développement.............................................................................. 50

3.2.3 Branche de développement.......................................................................... 51

3.2.4 Outils et technologies utilisées .................................................................... 52

3.2.5 Les contraintes de sécurité........................................................................... 56

3.2.6 Les Tests unitaires : ..................................................................................... 57

3.3 Conclusion ................................................................................................................. 58

Chapitre 4 : Mise en œuvre de la solution ................................................................................ 59

4.1 Les interfaces graphiques de l’espace patient ............................................................ 60

4.1.1 Page d’authentification ................................................................................ 60

4.1.2 Page d’accueil ............................................................................................. 62

4.1.3 Page gestion profil patient ........................................................................... 64

4.1.4 Page de demander un soin ........................................................................... 68