Khouloud Rania 2023

Remerciements
Nous sommes reconnaissants envers Dieu, le Tout-Puissant, de nous avoir donné la

santé et la motivation pour entamer et achever ce mini-projet avec succès.
Nous souhaitons exprimer nos profondes gratitudes et nos remerciements les plus
sincères à Mme.Yosra Ben Salem, notre chère professeur et encadrante à ISET'COM pour sa
confiance, son assistance, sa disponibilité et le soin apporté au suivi de ce travail. Elle nous a
conseillé, aidé et guidé durant toute la période de notre projet.
Par la même occasion, nous adressons nos remerciements à l'équipe administrative de

l'Iset'com et tous nos enseignants pour leurs efforts afin de nous garantir une excellente
formation tout au long de nos études universitaires.
Finalement, nous souhaitons aussi exprimer nos respects et nos remerciements aux
membres du jury qui ont accepté d’évaluer notre travail.
Merci à tous et à toutes.

Table de matière
Introduction générale........................................................................................................................... 1
Chapitre 1 : Contexte général du projet ................................................................................................... 2
Introduction ......................................................................................................................................... 2
1. Problématique.................................................................................................................................. 2
2. Etude de l’existant ....................................................................................................................... 2
2.1. Présentation des solutions existantes ................................................................................... 3
2.2. Critique de l'existant ............................................................................................................ 6
2.3. Solution proposée ................................................................................................................ 7
3. Choix de la méthodologie de travail ............................................................................................ 8
3.1. L’approche classique ........................................................................................................... 9
3.2. Les approches agiles .......................................................................................................... 10
3.3. Etude comparative entre les méthodes traditionnelles et agiles ........................................ 11
3.4. Méthode de travail adoptée : SCRUM .............................................................................. 12
Conclusion ......................................................................................................................................... 13
Chapitre 2 : Réalisation d’une étude de marché .................................................................................... 14
Introduction ....................................................................................................................................... 14
1. Description de l’enquête ................................................................................................................ 14
1.1. Utilité du questionnaire ..................................................................................................... 14
1.2. Echantillon......................................................................................................................... 15
1.3. Choix d’une enquête en ligne et de terrain ........................................................................ 15
1.4. Les outils de travail ........................................................................................................... 16
1.5. Présentation du questionnaire ............................................................................................ 17
2. Présentation et analyse des résultats issus de Google................................................................ 17
2.1. Evaluation générale du besoin et de l’idée technologique................................................. 18
2.2. Utilité perçue et intérêt d’utilisation envers l’application d’aide à la décision ................. 21
3. Recommandations pour une application efficace .......................................................................... 23
Conclusion ............................................................................................................................................. 23
Chapitre 3 : Backlog Produit ................................................................................................................. 24
Introduction ....................................................................................................................................... 24
1. Etude préliminaire d’un projet....................................................................................................... 24
1.1. Identification des exigences fonctionnelles ............................................................................ 24
1.2. Identification des exigences non fonctionnelles ..................................................................... 24
2. Spécifications techniques .............................................................................................................. 25
2.1. Les outils de conception et de planification ........................................................................... 25
2.1.2. L’outil de planification ........................................................................................................ 25
2.2. L'architecture logicielle .......................................................................................................... 26
2.3. La maquette de l’application .................................................................................................. 27
3. Spécifications générales des exigences ......................................................................................... 28
3.1. Détermination du cas d’utilisation global ............................................................................... 28
3.2. Détermination du diagramme de classes global du projet ...................................................... 30
4. Planification et Structuration ......................................................................................................... 31
4.1. Backlog du produit ............................................................................................................ 31
4.2. Planification des sprints ..................................................................................................... 33
5. Business Model Canvas............................................................................................................. 33
Conclusion ......................................................................................................................................... 34
Chapitre 4 : Sprint 1 & 2 ....................................................................................................................... 35
Introduction ....................................................................................................................................... 35
1. Sprint 1 .......................................................................................................................................... 35
1.1. Backlog du sprint 1................................................................................................................. 35
1.2. Description fonctionnelle du sprint 1 ..................................................................................... 35
1.3. S’authentifier .......................................................................................................................... 36
1.4. Gérer la liste des maladies ...................................................................................................... 38
2. Sprint 2 .......................................................................................................................................... 41
2.1. Backlog du Sprint 2 ................................................................................................................ 41
2.2. Diagramme du cas d’utilisation du sprint 2 ............................................................................ 42
2.3. S’inscrire ................................................................................................................................ 42
2.4. S’informer sur la maladie ....................................................................................................... 44
2.5. Gérer le profil ......................................................................................................................... 46
Conclusion ......................................................................................................................................... 48
Chapitre 5 : Sprint 3 & 4 ....................................................................................................................... 49
Introduction ....................................................................................................................................... 49
1. Sprint 3 .......................................................................................................................................... 49
1.2. Diagramme du cas d'utilisation du sprint 3 ............................................................................ 49
1.3. Sélectionner les symptômes ressentis ..................................................................................... 50
1.4. Proposer la liste des experts ................................................................................................... 52
1.5. Prendre un rendez-vous .......................................................................................................... 53
1.6. Rappeler l’utilisateur par le rendez-vous ................................................................................ 55
2. Sprint 4 .......................................................................................................................................... 57
2.2. Diagramme du cas d’utilisation du sprint 4 ............................................................................ 57
2.3. Gérer la liste des symptômes .................................................................................................. 58
2.4. Gérer le calendrier des rendez-vous ....................................................................................... 62
Conclusion ......................................................................................................................................... 64
Conclusion générale .............................................................................................................................. 65
Webographie ......................................................................................................................................... 66
Annexe .................................................................................................................................................. 68
Liste des figures
Figure 1 : Application mobile « Med »[1] 3

Figure 2 : Application mobile « QALYO »[2] 4
Figure 3 : La plateforme « Tobba.tn » [3] 4
Figure 4 : Application mobile « At Home Doc » [4] 5
Figure 5 : Application mobile « Doctor At Home, Home Remedies »[5] 5
Figure 6 : Les phases du cycle en « cascade » 9
Figure 7 : Les phases du cycle en « V » 10
Figure 8 : Les phases du cycle en « Spirale » 10
Figure 9 : Méthode de travail Agile 11
Figure 10 : Cycle de vie Scrum 13
Figure 11 : Exemple de question fermée 14
Figure 12 : Exemple de question ouverte 15
Figure 13 : Exemple de question semi-ouvertes 15
Figure 14 : Les publications du questionnaire dans les groupes Facebook 16
Figure 15 : Définition du profil du répondeur 17
Figure 16 : Difficultés de prospection de médecin adéquat 18
Figure 17 : Perte du temps nécessaire pour diagnostiquer les symptômes 18
Figure 18 : La connaissance des applications permettant de trouver le médecin adéquat 19
Figure 19 : Les différentes applications médicales 19
Figure 20 : L’utilisation des applications d’aide à la décision médicale 20
Figure 21 : Fréquence d’utilisation de ces types d’applications 20
Figure 22 : Le pourcentage des personnes intéressés par ces applications 21
Figure 23 : L'utilité et le gain de temps de ces applications 21
Figure 24 : Les fonctionnalités proposées par l'utilisateur 22
Figure 25 : L'intention d'utilisation de l'application 22
Figure 26 : Architecture MVC 26
Figure 27 : Architecture MVP 26
Figure 28 : Architecture MVVM 27
Figure 29 : Le diagramme du cas d’utilisation global 29
Figure 30 : Le diagramme de classes global du projet 30
Figure 31 : Planning des Sprints 33
Figure 32 : Business Model Canvas 34
Figure 33 : Diagramme de cas d'utilisation relatif à l'administrateur 35
Figure 34 : Diagramme de séquence « S’authentifier » 37
Figure 35 Réalisation du cas d’utilisation « S’authentifier » 38
Figure 36 : Diagramme de séquence « Ajouter une maladie » 39
Figure 37 : Diagramme de séquence « Modifier une maladie » 40
Figure 38 : Réalisation du cas d’utilisation « Gérer la liste des maladies » 41
Figure 39 : Diagramme de cas d'utilisation relatif au sprint 2 42
Figure 40 : Description du diagramme du cas d'utilisation « S'inscrire » 43
Figure 41 : Réalisation du cas d’utilisation « S’inscrire » 44
Figure 42 : Diagramme de séquence « S'informer sur la maladie » 45
Figure 43 : Réalisation du cas d’utilisation « S’informer sur les maladies » 45
Figure 44 : Diagramme de séquence « Gérer le profil » 47
Figure 45 : Réalisation du cas d’utilisation « Gérer le profil » 48
Figure 46 : Diagramme du cas d'utilisation relatif au sprint 3 50
Figure 47 : Diagramme de séquence « Sélectionner les symptômes ressentis » 51
Figure 48 : Réalisation du cas d’utilisation «Sélectionner les symptômes ressentis» 51
Figure 49 : Diagramme de séquence « Proposer la liste des experts » 52
Figure 50 : Réalisation du cas d’utilisation « Proposer la liste des experts » 53
Figure 51 : Diagramme de séquence « Prendre un rendez-vous » 54
Figure 52 : Réalisation du cas d’utilisation «Prendre un rendez-vous» 55
Figure 53 : Diagramme de séquence « Rappeler l’utilisateur par le rendez-vous » 56
Figure 54 : Réalisation du cas d’utilisation «Rappeler l’utilisateur par le rendez-vous» 56
Figure 55 : Diagramme du cas d'utilisation relatif au sprint 4 57
Figure 56 : Diagramme de séquence « Ajouter un symptôme » 59
Figure 57 : Diagramme de séquence « Modifier un symptôme » 61
Figure 58 : Réalisation du cas d’utilisation « Gérer la liste des symptômes » 62
Figure 59 : Diagramme de séquence « Gérer le calendrier des rendez-vous » 63
Figure 60 : Réalisation du cas d’utilisation «Gérer le calendrier des rendez-vous » 64
Liste des tableaux
Tableau 1 : Tableau de comparaison entre les solutions existantes 7
Tableau 2 : Tableau de benchmark 8
Tableau 3 : Tableau de comparaison entre les méthodes traditionnelles et agiles 11
Tableau 4 : Backlog du produit 32
Tableau 5 : Backlog du sprint 1 35
Tableau 6 : Description du diagramme du cas d’utilisation « S’authentifier » 36
Tableau 7 : Description du diagramme du cas d'utilisation « Ajouter une maladie » 38
Tableau 8 : Description du diagramme du cas d'utilisation « Modifier une maladie » 40
Tableau 10 : Description du diagramme du cas d'utilisation « S'inscrire » 42
Tableau 11 : Description du diagramme du cas d'utilisation « S'informer sur la maladie » 44
Tableau 12 : Description du diagramme du cas d'utilisation « Gérer le profil » 46
Tableau 14 : Description du diagramme du cas d'utilisation « Sélectionner les symptômes ressentis » 50
Tableau 15 : Description du diagramme du cas d'utilisation « Proposer la liste des experts » 52
Tableau 16 : Description du diagramme du cas d'utilisation « Prendre un rendez-vous » 53
Tableau 17 : Description du diagramme du cas d'utilisation « Rappeler l'utilisateur par le rendez-vous »
55
Tableau 19 : Description du diagramme du cas d'utilisation « Ajouter un symptôme » 58
Tableau 20 : Description du diagramme du cas d'utilisation « Modifier un symptôme » 60
Tableau 21 : Description du diagramme du cas d'utilisation « Gérer le calendrier des rendez-vous » 62
Introduction générale
Certes à nos jours, Il est rare qu'un particulier ne possède pas de smartphone. En effet, les
applications mobiles font désormais partie de notre quotidien et leur marché est en pleine croissance.
Ces dernières années, la montée en puissance des applications mobiles est incontestable et
importante. Selon une étude menée en Juin 2019 en Tunisie, 4 utilisateurs sur 10 utilisent des
applications sur leurs smartphones plus de 30 fois par jour alors que 4 autres sur 10 les utilisent entre 10
et 30 fois.
En effet, Les nouveaux téléphones mobiles sont devenus les outils digitaux les plus utilisés avec
leurs fonctionnalités variées. Ils sont ainsi entrés au cœur de la vie quotidienne de leurs utilisateurs.
Cette prédominance du mobile s’accompagne d’une évolution de la consommation des applications
mobiles.
Vu cette évolution, il devient primordial pour l'utilisateur ou une initiative d’avoir une connaissance
sur la maladie ce qui empêche leur progrès. Dans ce sens, la visualisation des informations doit être
facilement accessible aux utilisateurs.
Dans le cadre de notre mini-projet réalisé au sein de l’Iset’Com, nous avons choisi de développer
une application mobile d'aide à la décision médicale.
Notre travail consiste à concevoir une application qui réunit les différentes fonctionnalités
nécessaires à une application qui confronte les inconvénients des solutions existantes.
Le travail de ce projet est documenté dans ce rapport qui est réparti en cinq chapitres.Le premier
chapitre est consacré à présenter le cadre général du projet en mettant l'accent sur la problématique
suivie d'une étude de l'existant à savoir : la problématique et l’étude approfondie des solutions similaires
existantes .Ensuite, nous présentons la solution proposée et la méthode adoptée pour aboutir au succès
de ce projet.
Le deuxième chapitre concerne l’étude de marché. La troisième chapitre, nous présenterons dans
un premier temps l’étude préliminaire dans laquelle nous recueillerons les besoins fonctionnels et non
fonctionnels du projet. Et dans la deuxième partie, nous présenterons les différentes technologies
nécessaires pour le développement du projet. Et finalement, nous terminerons avec la planification et le
BMC du projet. Le quatrième et le cinquième chapitre présenteront l’étude conceptuelle des quatres
premiers sprints.
1
Chapitre 1 : Contexte général du projet
Introduction
Dans ce chapitre, nous nous intéressons tout d’abord au contexte général de notre sujet ainsi qu’à
sa problématique. Ensuite, nous élaborons une étude approfondie des applications d'aide à la décision
médicales. Pour finir nous présentons la solution proposée et la méthode adoptée pour aboutir au succès
de ce projet.
1. Problématique
Depuis longtemps, l'être humain cherchait de reconnaitre ses états de santé et ses malaises
à travers les symptômes qu'il ressente. Rester en bonne santé et chercher un diagnostic adéquat
dès l'apparition des premiers symptômes d'une maladie représente pour certains une réelle
préoccupation qui peut devenir une cause d'anxiété.
Le challenge pour certains patients est de trouver le médecin adéquat où ils peuvent
consulter à temps afin de ne pas aggraver le cas. Pour certains patients, dans certains cas, les
faux diagnostics dus à une mauvaise orientation peuvent leur perdre du temps et donc aggraver
leurs situations d'une part et d'autre part peuvent leur soient très couteuse, surtout dans la
situation économique actuelle du pays.
En outre, l'ère digitale a révolutionné notre façon d'agir et de penser, et par la suite à
transformer nos activités quotidiennes dans de nombreux domaines, le domaine médical est l'un
des domaines qui se servent des technologies de la communication et de l'information afin
d'offrir des services, en évolution continue pour faciliter le travail des experts d'une part et
satisfaire les besoins des patients d'une autre part. Essayer de reconnaître l'état de santé d'un
patient à travers ses constatations en terme de symptôme par le bais d'une application reste un
défi dans le marché tunisien.
Alors comment pouvons-nous exploiter le pouvoir de nouvelles technologies pour

remédier à toutes contraintes médicales et pour mieux orienter l'utilisateur vers sa maladie ?
Avant tout analyse de problématique, il est judicieux de présenter comment les concurrents
répondent à cette problématique.
2. Etude de l’existant
L'étude de l'existant est une phase importante pour bien comprendre le système et définir
ses objectifs. Elle permet de mettre à table, et de façon très claire les études réalisées sur
l'environnement d'évolution du projet, que ce soit par rapport au marché ciblé ou aux
concurrents qui l'occupent. Cette partie fera donc l'objet de l'étude des solutions existantes.
2
Chapitre1 Contexte général du projet
2.1. Présentation des solutions existantes

Plusieurs solutions existent sur le marché qui traite des sujets similaires à notre projet, il y
a quelques solutions qui traitent une partie de notre problématique à l'échelle nationale. Par
ailleurs, nous pouvons étudier les solutions à l'échelle internationale afin d'améliorer notre
perspective.
Les concurrents nationaux :
En Tunisie, il existe quelques plateformes web et des applications mobiles médicales, mais
qui n’étaient pas conçues pour atteindre les mêmes objectifs que la nôtre. Parmi lesquelles nous
pouvons citer les exemples suivants :
• Med est une application mobile développée en 2020. Elle permet de trouver
gratuitement le bon médecin et de prendre un rendez-vous en ligne. Ainsi, elle
fournit des informations sur les symptômes de maladie les plus courants. L'image
suivante montre l'interface de l'application Med.
Figure 1 : Application mobile « Med »[1]
• QALYO est une application mobile qui était développée en 2015. Cette application
permet de suivre et maitriser les données médicales. Elle s’appuie sur les dernières
technologies de collecte et de mesure des données individuelles pour proposer des
conseils personnalisés. L'image ci-dessous présente l'interface de l'application
QALYO.
3
Figure 2 : Application mobile « QALYO »[2]
• Tobba.tn est un site web développé en 2019. Il œuvre pour la proximité du service
médical en offrant à tout moment l’accès à des médecins et professionnels de santé
compétents et aptes à aider les utilisateurs pour une meilleure prise en charge
médicale dans un contexte digital. L'image ci-dessous présente l'interface du site
web Tobba.tn.
Figure 3 : La plateforme « Tobba.tn » [3]
Les solutions à l’échelle nationale étaient limitées à la présentation des fonctionnalités de

prise de rendez-vous et de suivi de paramètres de santé (mesure de taux de tension, mesure de
taux de glycémie...). Les solutions à l'échelle internationale sont beaucoup plus riches. En effet,
ils offrent des fonctionnalités de nature différentes.
4
Les concurrents internationaux :
• At Home Doc est une application mobile développée en 2017 au Qatar. Elle permet
de fournir une dose quotidienne de contenu informatif sur la santé et le bien être
concernant les problèmes de santé les plus urgents par des professionnels de la
santé. Ainsi, elle permet d'offrir des soins virtuels et en personne (Prendre des
rendez-vous à la demande dans les cliniques du réseau ou même à domicile),
d'interagir avec les utilisateurs et de réserver une consultation à tout moment.
L'image ci-dessous illustre l'interface de l'application At Home Doc.
Figure 4 : Application mobile « At Home Doc » [4]
• L'application Doctor At Home, Home Remedies est une application mobile

développée en 2019 en Inde. Elle permet non seulement de guérir les maladies à la
maison, mais également d'obtenir des informations sur différentes maladies et leurs
causes. L'image ci-dessous illustre l'interface de l'application Doctor At Home,
Home Remedies.
Figure 5 : Application mobile « Doctor At Home, Home Remedies »[5]
5
Après avoir visualisé les solutions existantes, il est indispensable de critiquer ces solutions
afin de proposer la meilleure solution.
2.2. Critique de l'existant

Le but de la critique de l'existant est d'établir un diagnostic précis sur les procédures
utilisées, relever les anomalies, les qualités et les défauts des concurrents. Il est indispensable
de critiquer les cas similaires dans le but de proposer la meilleure solution. Il s'agit
principalement de citer les points forts et les points faibles de chaque solution mentionnée dans
la partie précédente. Nous allons indiquer dans le tableau ci-dessous une analyse comparative
entre les différentes applications retenues :
Nom de la solution Points forts Points faibles

Med -Application gratuite -Pas de téléconsultation
-Ergonomie et design attractif -Pas de saisie des symptômes
-Disponible sur App Store et -Pas d’auto-complète
Play Store
-Une expérience unique et
totalement personnalisée.
-Offre une géolocalisation
-Rappels de rendez-vous par e-
mail et SMS
QALYO -Application gratuite - N’offre pas des résultats à
-Ergonomie et design attractif proximité (par géolocalisation).
-Disponible sur App Store et -Trop d’input
Play Store - Ne peut pas partager un
-Une expérience unique et traitement avec d'autres
totalement personnalisée. personnes.
-Possède un site web -Pas d’auto-complète
Tobba.tn - Temps de chargement rapide - Absence d’application mobile

- Responsive design - Site chargé
- Intégration des réseaux sociaux - N’offre pas des résultats à
-Consultations en ligne proximité (par géolocalisation).
-Possibilité de paiement en ligne -Pas d’auto-complète
At Home Doc -Application gratuite - Manque d'interactivité
- Faire des promotions (Fonctionnalité liée à l’appel d’un
-Disponible sur App Store et expert)
Play Store -Difficulté de créer un compte sur
-Permet de donner le nombre des l’application
patients en consultation -Il existe uniquement 2 langues
instantanément (arabe et anglais)
-Offre une géolocalisation - Application utilisée uniquement
- Temps de chargement rapide en ligne
6
Doctor At Home, -Application gratuite - N’offre pas des résultats à

Home Remedies -Disponible sur App Store et proximité (par géolocalisation)
Play Store -Des interfaces vitrines
-Accéder à une information -Pas d’auto-complète
riche, variée, accessible
facilement et rapidement
Tableau 1 : Tableau de comparaison entre les solutions existantes
D'après le tableau précédent, nous avons pris en considération les points forts et les points
faibles de chaque solution. Cela nous a permis de proposer une meilleure solution à notre
problématique.
2.3. Solution proposée

Après une étude approfondie et comparative sur les différentes solutions existantes, il est
donc primordial au regard des limites de ces applications, de proposer une solution qui pourra
répondre aux besoins réels des utilisateurs. Notre projet consiste à concevoir une application
gratuite d'aide à la décision médicale. Cette application permet de recommander le bon
spécialiste en fonction des symptômes saisis par l'utilisateur.
2.3.1. Objectifs de l’application
La solution que nous avons dégagée doit répondre aux objectifs suivants :
• Informer les utilisateurs sur les différentes maladies.

• Visualiser sur une carte géographique les positions des experts adéquats.
• Saisir les symptômes ressentis.
• Analyser les symptômes pour identifier le type de maladie et de proposer une
solution (Par exemple : médicaments ou consultation chez un médecin spécifique).
• Organiser les rendez-vous des utilisateurs.
Après l'analyse des solutions existantes et la proposition de notre solution, il est important
de faire une analyse comparative entre notre application et les autres applications proposées à
travers le benchmark.
2.3.2. Tableau benchmark
Le benchmark est un ensemble d'actions qui permet d'aider à évaluer et à comparer les
produits, méthodes et services à ceux de la concurrence en s'appuyant sur des métriques
spécifiques. Il permet de trouver les meilleures méthodes pour assurer un avantage
concurrentiel.
7
Les Med QALYO Tobba.tn At Home Doctor At Home

fonctionnalités Doc Home, Care
Home
Remedies
La recherche par + - - + - +
géolocalisation
Les champs auto- - - - - + +
complète
Suggestions des - - - + - +
médecins sur
GoogleMaps
Création des + + + + - +
comptes
Consultations en - - + + - +
ligne
Paiement en + - + - - +
ligne
Gestion des + + + - - +
rendez-vous
Des informations + + - + + +
et des conseils
sur les
différentes
maladies
L'enregistrement - - - + - +
de l'audiovisuel
de l'état du
patient
Accès à + + - - + +
l’application sans
compte
Tableau 2 : Tableau de benchmark
Après l'étape de recherche d'existence et de proposition de solution, il est important

d'établir quelle méthodologie sera utilisée avant de démarrer notre projet. Commencer à
travailler immédiatement pour économiser du temps plutôt que de perdre du temps à planifier
comment accomplir les tâches efficacement.
3. Choix de la méthodologie de travail

Un projet informatique, quelle que soit sa taille et la portée de ses objectifs, nécessite la
mise en place d'un planning organisationnel tout au long de son cycle de vie.
La méthodologie est la démarche organisée rationnellement pour aboutir à un résultat. Les

principales méthodologies diffèrent non seulement par leur structure, mais aussi par la nature
des livrables, processus, outils et même par le logiciel de gestion de projet adopté. Parmi ces
différentes méthodologies nous pouvons distinguer les méthodologies classiques et agiles.
8
3.1. L’approche classique

La gestion de projet traditionnelle ou classique repose sur une organisation du travail et un
fonctionnement séquentiel. En effet, cette approche est basée principalement sur trois modèles
de cycle de vie afin de mieux maîtriser le processus de développement. On distingue alors : le
modèle en cascade, le modèle en V et le modèle en Spirale.
➢ Le modèle en « cascade » :
Le modèle en cascade, ou « waterfall » en anglais, est une organisation des activités d’un
projet sous forme de phases linéaires et séquentielles, où chaque phase correspond à une
spécialisation des tâches et dépend des résultats de la phase précédente. Chaque phase se
termine à une date précise par la production de certains documents ou logiciels, les résultats
sont définis sur la base des interactions entre étape et activité et ils sont soumis à une revue
approfondie. [6]
Figure 6 : Les phases du cycle en « cascade »
➢ Le modèle en « V » :
Le cycle en V en gestion de projet découle du modèle en cascade, qui permet de représenter

des processus de développement de manière linéaire et en phases successives. Ainsi, il donne
une séparation claire entre la vue de l’utilisateur du système, son modèle architectural et le
modèle d’implémentation. Le bras gauche du « V » désigne les tâches relatives à la conception
et au développement du système et le bras droit les mesures d’assurance qualité qui lui sont
associées. [7]
9
Figure 7 : Les phases du cycle en « V »
➢ Le modèle en « Spirale » :
Le modèle en spirale est un modèle de cycle de développement logiciel qui reprend les
différentes étapes du cycle en V. Par l'implémentation de versions successives, le cycle
recommence en proposant un produit de plus en plus complet. Chaque boucle représente une
phase de développement. [8]
Figure 8 : Les phases du cycle en « Spirale »
3.2. Les approches agiles

Une méthode Agile est une approche itérative et collaborative, capable de prendre en
compte les besoins initiaux du client et ceux liés aux évolutions. Elle permet aux utilisateurs
d'obtenir une meilleure visibilité de la gestion des travaux et un feedback régulier afin
d’appliquer directement les changements nécessaires.
Le but d'une méthode agile est de maximiser la valeur ajoutée. Le développement s'effectue
par itérations successives, il est possible, à la fin de chaque itération, de changer les priorités en
faisant en sorte que les éléments apportant le plus de valeur soient réalisés a priori. [9]
10
Figure 9 : Méthode de travail Agile
La figure ci-dessus montre que les méthodes agiles utilisent le principe de développement
itératif qui consiste à découper le projet en plusieurs étapes d’une durée de quelques semaines
qu’on appelle itérations. Ces itérations sont des mini-projets définis avec le client en détaillant
les différentes fonctionnalités qui seront développées selon leur priorité. L’objectif est
d’obtenir, au terme de chaque itération, un sous ensemble opérationnel du système cible et au
terme de la dernière itération, la version finale du produit.
3.3. Etude comparative entre les méthodes traditionnelles et agiles

Il est fondamental de bien choisir la méthode de travail qui répond parfaitement aux besoins et qui
s’adapte le mieux aux exigences du client. Alors, il est nécessaire de faire une étude comparative entre
les méthodes pour pouvoir sélectionner la meilleure qui s’adapte au projet. Le tableau ci-dessous, décrit
les approches classiques et les méthodes Agiles en représentant les points forts et les points faibles de
chacune.
Points forts Points faibles

Les - Celles sont des approches - Un cadre de travail rigide : il y a peu
approches prédictives « tout doit être de possibilité de changement si un
classiques prévisible », en tout début du imprévu survient au cours d’un projet.
projet. - Des tests tardifs
- Des besoins parfois difficiles à définir
- Une mauvaise communication.
- Une documentation pléthorique.
Les -La communication est de meilleure - Peu de supports écrits : si l'un des
approches qualité. membres quitte l'équipe cela peut perturber
agiles - La visibilité est meilleure. l'ensemble du projet.
- La qualité est évaluée en continu. - "Sprints" exigent un niveau de
- Les risques sont détectés très tôt. productivité maximal pour tous les acteurs
- Les coûts sont contrôlés. du projet.
- Accueil favorable au - Moins compatible dans des entreprises
changement, intégré dans le à forte hiérarchie.
processus.
-Satisfaction client par la
livraison de valeur ajoutée
Tableau 3 : Tableau de comparaison entre les méthodes traditionnelles et agiles
11
A travers cette comparaison, nous constatons que ces approches prédictives se sont révélées
trop « rigides » voire rendent leurs utilisateurs moins réactifs alors que les méthodes agiles bien
qu’elles soient moins prédictives, elles sont plus souples face aux besoins d’adaptation,
facilitant ainsi l’agilité de leurs utilisateurs.
Une fois que nous avons décidé d’adopter une gestion de développement Agile, il reste
encore à choisir la méthode la plus adaptée à notre projet. En effet, les méthodes Agiles
disponibles sont nombreuses et peuvent être source de confusion. Scrum est parmi les méthodes
agiles les plus populaires en usage aujourd’hui.
3.4. Méthode de travail adoptée : SCRUM

Nous avons opté pour la méthode Scrum, faisant partie des approches agiles les plus
utilisées dans la gestion des projets informatiques. Cette méthode signifie mêlée au rugby. Le
principe de base étant d'être toujours prêt à réorienter le projet au fil de son avancement. [10]
Trois piliers soutiennent l'implémentation d'un contrôle empirique de processus :
• La transparence : Les aspects importants du processus doivent être visibles à ceux qui
sont responsables des retombées. Elle requiert la définition d'un standard commun pour
ces aspects afin que les observateurs partagent une compréhension commune de ce qui
est observé.
• L’inspection : Cette inspection quotidienne permet de détecter rapidement d'éventuels
écarts entre l'objectif de l'itération, le travail envisagé et la réalité du quotidien. La
fréquence de ces inspections ne devrait pas gêner le travail en cours. Ces inspections
sont bénéfiques lorsqu'elles sont effectuées de manière diligente sur les lieux du travail
par les personnes qualifiées.
• L’adaptation : Si un inspecteur détermine qu’un ou plusieurs aspects du processus
dérivent hors des limites acceptables, et que le produit qui en résulte sera inacceptable,
le processus ou le matériel utilisé par le processus doit être ajusté. Un ajustement doit
être fait dès que possible afin de minimiser le risque d’autres dérives.
La méthode Scrum définit trois rôles qui sont :
• Le Product Owner : est responsable de maximiser la valeur du produit et du travail de

l’Équipe de Développement. La façon de jouer ce rôle peut varier grandement selon les
entreprises, les Équipes Scrum et les individus. Il est la seule personne responsable de
gérer le carnet de produit (Product Backlog).
• Le Scrum Master : est responsable de s’assurer que Scrum est compris et mis en
œuvre. Les Scrum Masters remplissent leurs rôles en s’assurant que l’Équipe Scrum
adhère à la théorie, aux pratiques et aux règles de Scrum. Il a un rôle de facilitateur
aidant à l’amélioration de la communication au sein de l’équipe et cherchant à
maximiser le savoir-faire et la productivité de celle-ci.
• Le Scrum Team : l’équipe de développement, chargée de transformer les besoins
définis par le Product Owner en fonctionnalités utilisables. Pluridisciplinaire, elle
possède en interne toutes les compétences nécessaires à la réalisation du projet.
12
Figure 10 : Cycle de vie Scrum
Cette figure au-dessus illustre le déroulement du cycle projet scrum qu’est ensuite organisé
en itérations, ou sprints. Chaque sprint dure généralement de deux à quatre semaines. Une
réunion de planification est organisée avant le début d’un sprint, afin de sélectionner les Users
Stories qui seront réalisées durant le sprint. Elles composent alors le sprint backlog. Au-delà du
Sprint, le cycle se répète jusqu'à ce que la liste des tâches du Product Backlog soit achevée ou
le budget du projet est épuisé ou une autre limite est atteinte. L'un de ces jalons marque la fin
du travail sur le projet. Peu importe la cause de clôture, scrum assure que le travail le plus
important a été achevé lors de la fin du projet.
Scrum propose la création de trois artefacts essentiels :
• Le backlog de produit (Product backlog) : est une liste ordonnée et priorisée de

toutes les fonctionnalités qui doivent constituer le produit.
• Carnet d'itérations (Sprint backlog) : est une liste contenant les spécifications
techniques pour les tâches devant être accomplies par l'équipe de développement
au cours d'une période donnée (sprint).
• L'incrément en Scrum (product increment) : correspond à l'ensemble des items
du backlog de produits qui ont été accomplis pendant le sprint en cours.
Conclusion
Ce chapitre nous a présenté le cadre général du projet à savoir : la problématique et sa

solution la plus adéquate aux attentes des utilisateurs, l'étude approfondie des solutions
similaires existantes et les objectifs que nous sommes fixés ainsi que la méthodologie à suivre
pour le pilotage du projet. Le chapitre qui suit portera sur une étude de marché.
13
Chapitre 2 : Réalisation d’une étude de marché
Introduction
Dans le chapitre précédent, nous nous sommes focalisés sur la présentation du cadre
général du projet, du choix de la méthode de travail en expliquant son principe. Dans la première
partie de ce chapitre, nous allons présenter l’enquête par questionnaire faite dans le but de savoir
si l`application médicale sera utile pour nos cibles. En deuxième partie, nous allons conclure
avec les résultats de l’outil Google Forms et nous terminerons par la présentation des
recommandations.
1. Description de l’enquête
L'enquête par questionnaire est un outil d’observation qui permet de quantifier et comparer
l’information. Cette information est collectée auprès d’un échantillon représentatif de la
population visée par l’évaluation.
1.1. Utilité du questionnaire

Un questionnaire est un ensemble de questions construit dans le but d’obtenir l'information
correspondante aux questions de l’évaluation. Un bon questionnaire décline en effet la
problématique de base en question élémentaires auxquelles le répondant saura parfaitement
répondre.
Les enquêtes combinent souvent deux formes de questionnaire, avec une dominante de
questions fermées et quelques questions ouvertes et/ou semi-ouvertes, plus riches mais aussi
plus difficiles à traiter statistiquement. [11]
• Le questionnaire fermé : Dans un questionnaire fermé, les questions imposent au

répondant une forme précise de réponse et un nombre limité de choix de réponses. Les
questionnaires fermés sont utilisés pour obtenir des renseignements factuels, juger d'un
accord ou non avec une proposition, connaître la position du répondant concernant une
gamme de jugements, etc.
Figure 11 : Exemple de question fermée
14
Chapitre2 Réalisation d’une de marché
• Le questionnaire ouvert : Dans un questionnaire ouvert, la personne interrogée

développe une réponse que l'enquêteur prend en note. Dans ce cas, l'enquête par
questionnaire ouvert ressemble à un entretien individuel de type directif. Une question
ouverte laisse la réponse libre dans sa forme et dans sa longueur.
Figure 12 : Exemple de question ouverte
• Les questions semi-ouvertes : sont convenables là où on veut obtenir une réponse soit
concrète, soit textuelle. La réponse textuelle est habituellement séparée, placée au-
dessous des réponses proposées. Les répondants la choisissent au cas où s’ils n’arrivent
pas à faire leur choix parmi les réponses proposées.
Figure 13 : Exemple de question semi-ouvertes
1.2. Echantillon
Notre échantillon est composé d’un seul profil : Les personnes qui recherchent un moyen
plus simple et plus rapide de mieux identifier leurs maladies à partir des symptômes qu’ils
ressentent.
1.3. Choix d’une enquête en ligne et de terrain

Pour assurer plus d’efficacité et pertinence, il fallait combiner deux méthodes : une enquête
en ligne et une enquête de terrain
Une enquête en ligne dans le but de :
• Une mise en place rapide : Créer un questionnaire en ligne prend peu de temps et
est rendu extrêmement facile grâce à des outils dédiés comme Google Form,
SurveyMonkey, Polldaddy, etc
• Le partage sur de nombreux canaux : Nous pouvons partager le questionnaire
très facilement via un lien.
15
• L’instantanéité des résultats : Nous pouvons évaluer en direct la réussite de notre

sondage en ligne en étudiant les caractéristiques des répondants, la pertinence des
réponses, etc.
Le questionnaire a été diffusé à nos cibles par messages privés et par publication dans les
groupes créés sur le réseau social Facebook.
Figure 14 : Les publications du questionnaire dans les groupes Facebook
Une enquête de terrain : Pour être à l’écoute de nos cibles, des enquêtes sur terrain
étaient effectuées pour plus de détails, avis et remarques pertinentes. Ce type d’enquête
présente plusieurs avantages, parmi lesquelles :
• Minimiser l'erreur de cadre d'échantillon.
• Aucune perte de données.
• Chaque réponse est sûre et sécurisée.
1.4. Les outils de travail
Google forms : est une solution gratuite dédiée aux entreprises comme aux
particuliers qui désirent réaliser des sondages en ligne pour collecter des
informations. Cette application permet de créer des formulaires, puis de
collecter les données pour les analyser.
16
1.5. Présentation du questionnaire

• Choix des questions :
Pour des questions posées, nous avons essayé d’éviter les risques de biais en évitant : Les
questions faisant appel à des connaissances que le pratiquant n’a pas ; Les questions sensibles
ou agressives.
• Questions posées :
Au total, notre enquête comprend 18 questions. La présentation du questionnaire sera
détaillée au niveau de « l’annexe : Présentation du questionnaire », tout en le décomposant en
trois parties :
Partie 1 : Fiche signalétique

Partie 2 : Questions introductives
Partie 3 : Questions spécifiques
2. Présentation et analyse des résultats issus de Google

Nous allons procéder à l’analyse des graphes statistiques les plus importants pour pouvoir
tirer des conclusions. Ainsi, nous avons collecté un nombre total de 139 réponses.
Figure 15 : Définition du profil du répondeur
- 48 réponses en ligne.
- 10 réponses après l’enquête sur terrain que nous avons entrées par la suite pour obtenir
les résultats statistique s de l’outil Google.
17
2.1. Evaluation générale du besoin et de l’idée technologique

Nous avons commencé par savoir si les utilisateurs trouvent vraiment des difficultés lors
de la recherche des médecins adéquats. En effet, nous constatons à partir de la figure ci-dessous
que la majorité des personnes trouvent toujours des difficultés à trouver des médecins adéquats.
Figure 16 : Difficultés de prospection de médecin adéquat
À partir de figure 17, nous pouvons voir que la plupart des personnes mettent beaucoup
de temps à diagnostiquer leurs symptômes avec un médecin.
Figure 17 : Perte du temps nécessaire pour diagnostiquer les symptômes
18
Le figure 18 vise à savoir si les individus sont familiers avec le concept des applications
d'aide à la décision médicale qui les aident à trouver le bon médecin.
Figure 18 : La connaissance des applications permettant de trouver le médecin

adéquat
Nous constatons d’après la figure 19 que la plupart des gens connaissent principalement
l'application Med.
Figure 19 : Les différentes applications médicales
19
La figure 20 montre le pourcentage d'utilisateurs qui utilisent actuellement des

applications d'aide à la décision médicale ou liée au domaine médical.
Figure 20 : L’utilisation des applications d’aide à la décision médicale
Nous constatons d’après la figure 21 que la majorité des personnes utilisent

occasionnellement les applications d'aide à la décision médicale ou liée au domaine médical.
Figure 21 : Fréquence d’utilisation de ces types d’applications
20
La figure22 représente par un histogramme illustre le niveau d’utilité de ce type

d’application
Figure 22 : Le pourcentage des personnes intéressés par ces applications
2.2. Utilité perçue et intérêt d’utilisation envers l’application d’aide à la

décision
Nous remarquons à partir la figure 21 que la plupart des gens trouvent cette application
utile et rapide.
Figure 23 : L'utilité et le gain de temps de ces applications
21
Ce graphique montre les différentes fonctionnalités que notre cible veut trouver au sein de
notre application. Et d’après la figure 24 ci-dessous, nous constatons que la plupart des
personnes sont tout à fait d’accord pour l’utilité des fonctionnalités de la nouvelle application
d'aide à la décision médicale.
Figure 24 : Les fonctionnalités proposées par l'utilisateur
Figure 25 : L'intention d'utilisation de l'application
Les figures 24 et 25 montrent que la majorité des gens approuvent l‘utilisation de la

nouvelle application pour appuyer leurs décisions dans le domaine médical.
22
3. Recommandations pour une application efficace

Afin de garantir une expérience utilisateur optimale, nous avons utilisé des questions
ouvertes dans notre enquête pour recueillir le plus grand nombre de fonctionnalités souhaitées
par les utilisateurs dans le but de les inclure dans la création de notre application. Parmi ces
améliorations, nous citons :
➢ Une application est conforme aux réglementations et aux normes de sécurité de

l’industrie de la santé
➢ Téléconsultation
➢ Le paiement en ligne
➢ Plateforme dynamique et fluide
➢ Facile à utiliser et à naviguer
➢ Recherche des spécialistes les plus proches
➢ Travaille avec des professionnels de la santé
➢ L’enregistrement de l’audiovisuel de l’état du patient
➢ L’utilisation des données et des technologies de pointe
➢ La gestion des rendez-vous
➢ Expérience utilisateur personnalisé et offrir des conseils et des informations
Conclusion
L’objectif de ce deuxième chapitre était de présenter les résultats de l’étude de marché.

Dans la première section, nous avons discuté de l’importance de la recherche de mini-projets.
Nous avons ensuite présenté les résultats des données collectées. Finalement, nous avons tiré
les recommandations à suivre après analyse des suggestions des répondants. Au prochain
chapitre, nous allons préciser l’étude du backlog produit de notre projet
23
Chapitre 3 : Backlog Produit
Introduction
Dans le chapitre précédent, nous avons présenté l’enquête réalisée tout en exposant les
résultats statistiques obtenus et les recommandations déduites. Dans ce chapitre, nous
entamerons les choix technologiques ainsi que la phase de spécification générale des besoins.
Nous présenterons en premier lieu l’étude préliminaire dans laquelle nous recueillerons les
besoins fonctionnels et non fonctionnels du projet. Et dans la dernière partie, nous terminerons
avec la planification et le BMC du projet.
1. Etude préliminaire d’un projet

L'étude préliminaire constitue une étape essentielle du processus de développement. Elle
consiste à déterminer les besoins fonctionnels et non fonctionnels, en s'appuyant sur les
spécifications du client. L’objectif de cette étape est principalement la spécification détaillée
des fonctionnalités attendues d'un service ou d'un produit. Cette étude sera donc l'objectif de
cette partie.
1.1. Identification des exigences fonctionnelles

Les exigences fonctionnelles définissent les fonctionnalités fournies par un système. Ce
sont les actions et les réactions que le système doit faire suite à une demande d'un acteur
principal. Cette application est divisée en deux parties principales, une pour les utilisateurs
(patients) et une pour les experts. Tenant compte de la nature de l'application, nous distinguons
ces besoins :
• Gestion de l'authentification : Elle permet aux utilisateurs de s’inscrire, de

s’identifier, de mettre à jour les informations professionnelles et de réinitialiser le
mot de passe.
• Saisie des données : Elle permet aux utilisateurs de saisir ses symptômes qu'ils
ressentent à travers les questions posées, les photos capturées et le son enregistré.
• Analyse des informations recueillies sur les maladies : elle permet aux utilisateurs
de s’informer sur la nature de la maladie, ses causes et les solutions possibles.
• Recommandation des experts : Elle permet de recommander un expert adéquat à
l'utilisateur en lui proposant une liste des experts les plus proches en fonction de leur
localisation.
• Consultation et paiement en ligne : Elle permet aux utilisateurs d'avoir une
consultation avec un expert dans un contexte digital et la possibilité de paiement en
ligne.
• Organisation des rendez-vous : Organiser et rappeler les utilisateurs par leurs
rendez-vous.
1.2. Identification des exigences non fonctionnelles

Les exigences non fonctionnelles définissent les caractéristiques attendues d'un logiciel. Il
s'agit des exigences qui caractérisent le système en matière de performance et de qualité de
l'exécution des exigences fonctionnelles. Pour assurer un fonctionnement efficace aux
utilisateurs, il est important de satisfaire les exigences de qualité suivantes.
24
Chapitre 3 Backlog Produit
• Sécurité : Assurer la confidentialité et l'intégrité des informations personnelles des

utilisateurs et toutes les opérations administratives. L’application doit être sécurisée
pour que les données des utilisateurs de l’application ne seront pas divulguées.
• Performance : L'application doit réduire le temps de réponse pour le chargement
de pages, l'affichage des résultats et les délais de rafraîchissement.
• Responsive : la plateforme doit être adaptée aux différents terminaux qu’un
utilisateur peut utiliser (ordinateur portable, téléphone mobile, tablette, etc.).
• Intégrité des données : des contrôles de saisie doivent être effectués pour s’assurer
que les données soient cohérentes et pertinentes.
• Ergonomie et bonne interface : l'application doit être conviviales c’est-à-dire
simples, ergonomiques et adaptées à l’utilisateur sans qu’il ne fournisse aucun effort
(utilisation claire et facile) du point de vue navigation entre les différentes interfaces,
couleurs et mise en textes utilisés.
• Accessibilité au GPS : Demander l’autorisation pour accéder à la géolocalisation
des utilisateurs et visualiser les experts placés selon des rayons par rapport à sa
position.
2. Spécifications techniques
Après avoir établi les exigences fonctionnelles et non fonctionnelles, nous allons présenter
la spécification technique. Puisque les besoins techniques donnent une vision globale sur
l'architecture générale de notre projet, ce qui entraîne le développement de l'application mobile.
Cette section est consacrée à l'identification des technologies à utiliser pour garantir le bon
fonctionnement de l'application. En effet, la section suivante met l'accent sur le choix de
certaines technologies suivante : Les outils de conception, de planification et de design,
l'architecture logicielle, la maquette de de l’application
2.1. Les outils de conception et de planification

2.1.1. L’outil de conception
StarUML : est un outil de conception de diagrammes en vue d'une

programmation. Il est capable de prendre en charge de nombreux diagrammes
commerciaux et techniques comme UML. [12]
2.1.2. L’outil de planification
Trello : est un outil de gestion de projet en ligne. Il permet une

excellente visualisation des tâches et de leur avancement,
notamment grâce à la création de catégories ou la mise en place
de dates limites. [13]
2.1.3. Les outils de design
Adobe Illustrator : est un logiciel de création graphique vectorielle et offre

des outils de dessin vectoriel puissants. Les images vectorielles sont
constituées de courbes générées par des formules mathématiques. [14]
25
2.2. L'architecture logicielle

Avant de détailler l'architecture logique de notre application, il est recommandé d'avoir une
vue globale sur les différents types d’architectures existantes.
2.2.1. Description des architectures types
• Architecture MVC(MODEL-VIEW-CONTROLLER) : est une architecture

de développement visant à séparer le code source en modules. En effet, ce modèle très
répandu, consiste à séparer distinctement l’accès aux données (bases de données), la vue
affichée à l’utilisateur et la logique métier. Ainsi, comme le démontre la figure 26. [15]
Figure 26 : Architecture MVC
• Architecture MVP(MODELE-VUE-PRESENTATION) : C'est un design

Pattern qui propose de découper et de structurer l'architecture des interfaces utilisateur en
couches. On peut le combiner à un découpage de l'accès aux données qu'on peut appeler
DAL : Data Access Layer, et qui sépare les informations en mémoire de l'accès physique à
la base de données). Il permet de séparer le code de gestion de l'interface (UI), du code qui
manipule les données métier. Cette architecture en couches de l'application et de l'UI permet
de rendre les projets plus faciles à maintenir et à faire évoluer. [16]
Figure 27 : Architecture MVP
26
• Architecture MVVM(MODEL-VIEW-VIEW-MODEL) : C'est une

architecture et une méthode de conception utilisé dans le génie logiciel. MVVM est
originaire de Microsoft et adaptée pour le développement des applications basées sur les
technologies Windows Presentation Foundation. Cette méthode permet, tel le modèle MVC
de séparer la vue de la logique et de l'accès aux données en accentuant les principes de
binding et d'évènement. [17]
Figure 28 : Architecture MVVM
2.2.2. Choix de l'architecture de l'application
Pour concevoir l'architecture logique de notre système nous optons pour l'architecture
MVC qui est une façon d'organiser une interface graphique d'un programme. Elle consiste à
distinguer trois entités distinctes qui sont le modèle, la vue et le contrôleur ayant chacun un rôle
précis de l'interface. L'organisation globale d'une interface graphique est souvent délicate. Ce
choix permet de :
- Faciliter la maintenance et les évolutions futures grâce à la séparation entre les

différentes couches.
- Faciliter le travail de plusieurs développeurs (front-end et back-end) sur le même
projet puisque les fichiers sont séparés
2.3. La maquette de l’application

Avant d’aller au développement et à la réalisation de l’application mobile, il était
absolument nécessaire de faire une maquette d’une part pour nous permettre d’optimiser
l’ergonomie et les conversions de notre application. Et d’autre part, cette phase est très
bénéfique au niveau des coûts et du temps.
27
Pour notre projet nous avons opté sur l’outil suivant :

Adobe XD : est un outil de conception et de prototypage vectoriel
spécialement conçu pour la conception de sites Web et les applications
mobiles. Ce logiciel offre une interface simplifiée, une multitude de
fonctionnalités et d’extensions gratuits, une possibilité d’édition très facile
ainsi qu’un dynamisme et interactivité aux designs crées avec un service
d’hébergement en ligne. [18]
3. Spécifications générales des exigences

Une fois les exigences fonctionnelles et non fonctionnelles établies, nous allons proposer
la spécification des exigences qui doivent être établie selon les besoins identifiés.
Cette étape consiste à dégager dans un premier temps le diagramme de cas d’utilisation
général et le diagramme de classes global du projet. Par la suite nous allons passer vers la
classification et la planification des cas d’utilisation en itérations.
3.1. Détermination du cas d’utilisation global

Le diagramme de cas d'utilisation est un diagramme UML utilisé pour une représentation
du comportement fonctionnel d'un système logiciel.
Il est utile pour des présentations auprès de la direction ou des acteurs d'un projet, mais
pour le développement, les cas d'utilisation sont plus appropriés.
Il permet l'organisation des besoins fonctionnels, la définition des acteurs généralement des
individus impliqués dans le système et les relations.
Selon le diagramme figuré ci-dessus, on distingue 4 acteurs qui sont :
Administrateur qui peut gérer la liste des maladies afin de modifier ou ajouter une maladie et
gérer la liste des spécialités dans le même but.
Utilisateur qui peut s’inscrire pour créer un nouveau compte et s’informer sur diverses maladies
et accéder à des informations et des conseils.
Expert, il hérite toutes les actions qu’un simple utilisateur peut faire, mais il peut gérer la liste
des symptômes relatives aux spécialités, valider une consultation en ligne, gérer son profil et
gérer son calendrier des rendez-vous.
Patient, il hérite toutes les actions qu’un simple utilisateur peut faire, mais il est capable aussi
de gérer son profil, sélectionner ses symptômes ressentis, accéder à la liste des experts les plus
proches et de prendre un rendez-vous.
28
Figure 29 : Le diagramme du cas d’utilisation global
29
Le diagramme de classe est considéré comme le plus important de la modélisation orientée

objet. Bien que le diagramme de cas d'utilisation montre un système du point de vue des acteurs,
le diagramme de classes en montre la structure interne.
3.2. Détermination du diagramme de classes global du projet

Un diagramme de classe est un type de diagramme UML qui décrit un système en
visualisant les différents types d'objets au sein d'un système et les types de relations statiques
qui existent entre eux. Ils sont généralement utilisés pour explorer les concepts de domaine,
comprendre les exigences logicielles et décrire les conceptions détaillées.
Figure 30 : Le diagramme de classes global du projet
La figure ci-dessus illustre clairement les principales classes de notre application :
- Classe Utilisateur : est la classe qui contient toutes les informations concernant
l'utilisateur et contient deux méthodes, une méthode « Inscription » qui permet de
crée un compte et une méthode « Info_maladie» pour donner les informations
nécessaires sur les maladies.
30
- Classe Patient : est la classe qui contient toutes les actions que le patient peut faire.
Elle contient une méthode « Gerer_profil » pour mettre à jour les informations
personnelles.
- Classe Administrateur : sert à présenter les principales fonctionnalités d'un
administrateur : un administrateur peut gérer la liste des maladies et la liste des
spécialités.
- Classe Maladie : est la classe qui contient toutes les informations concernant les
maladies des patients et contient deux méthodes, une méthode « Ajouter_maladie »
et une méthode « Afficher_resultat_maladie » pour afficher la maladie adéquate.
- Classe Expert : cette classe représente les principales fonctionnalités liées aux
experts. Dans laquelle, il y a deux méthodes, qui sont « Gèrer_profil » et
« Gérer_liste_symptoms »pour modifier ou ajouter un symptôme.
- Classe Calendrier : cette classe représente le calendrier des rendez-vous d’un
expert bien déterminé. Elle possède deux methodes « Ajouter_date » et
« Modifier_date »
- Classe Spécialité : Comporte une seule méthode qui est « Ajouter_spécialité »
- Classe Paiement : Cette classe permet de valider un paiement à travers une méthode
« Valider_paiement ».
- Classe Symptôme : qui comporte deux methodes « Select_symptome » et
« Ajouter_symptom » pour ajouter et afficher un symptôme
4. Planification et Structuration
La planification de projet correspond à l'organisation des tâches à réaliser sur une période
donnée. L'objectif de la planification est de déterminer la meilleure manière d'ordonnancer
toutes les tâches à effectuer, l'estimation des charges et les ressources nécessaires à la
réalisation. Dans cette section, nous allons montrer d'abord le tableau de backlog du produit.
Par la suite, nous présenterons les rôles de chaque membre de l'équipe dans la méthodologie du
Scrum.
4.1. Backlog du produit

Dans cette partie, nous allons donner une définition du backlog de produit ainsi que le
tableau de toutes les fonctionnalités qui doivent être implémentés dans notre application.
4.1.1. Définition
Un backlog produit est une liste hiérarchisée de tâches destinées à l'équipe de

développement. Il est l'élément le plus important de Scrum puisqu'il représente l'ensemble des
caractéristiques fonctionnelles ou techniques qui constituent le produit souhaité. Les
caractéristiques fonctionnelles sont appelées des histoires utilisateur (user story) qui décrivent
les interactions de l'utilisateur avec l'application et les caractéristiques techniques sont appelées
des histoires techniques (technical story). Dans un backlog du produit, les stories sont rangées
selon l'ordre envisagé pour leur réalisation. [19]
4.1.2. Tableau de backlog du produit
Le backlog du produit dans le tableau ci-dessous, montre la liste des fonctionnalités qui
doivent être implémentées dans notre application. Le choix des priorités dans cette section
est basé sur la dépendance entre les fonctionnalités de l'application.
31
ID User Story Descriptions Priorités

1 S’authentifier En tant qu’administrateur, je peux me connecter à Haute
l’application.
2 Gérer la liste des En tant qu'administrateur, je peux ajouter ou Haute
maladies modifier une maladie.
3 Gérer la liste des En tant qu'administrateur je peux ajouter ou Haute
spécialités modifier une spécialité.
4 S’inscrire En tant qu’utilisateur, je peux créer un compte. Haute
5 S’informer sur la En tant qu’utilisateur, je peux avoir des Haute
maladie informations et des conseils sur les différentes
maladies.
6 Gérer le profil En tant qu’utilisateur, je peux faire la mise à jour Haute
de mes informations personnelles.
7 Sélectionner les En tant qu’un patient, je peux sélectionner les Haute
symptômes symptômes que je ressens.
ressentis
8 Proposer une liste En tant qu’un patient, je peux faire apparaître la Moyenne
des experts liste des experts adéquats les plus proches.
9 Prendre un rendez- En tant qu’un patient, je peux prendre un rendez- Moyenne
vous vous, soit en ligne ou soit sur place.
10 Rappeler En tant qu’un patient, je peux avoir des rappels Faible
l’utilisateur par le concernant mes rendez-vous.
rendez-vous
11 Gérer la liste des En tant qu'un expert, je peux ajouter ou modifier un Moyenne
symptômes symptôme.
12 Gérer le calendrier En tant qu’un expert, je peux modifier le calendrier Moyenne
des rendez-vous des rendez-vous.
13 Valider une En tant qu’un expert, je peux valider une demande Faible
consultation en de consultation en ligne
ligne
Tableau 4 : Backlog du produit
Le tableau 4 résume le Backlog du produit de notre future application. Dans ce tableau

chaque histoire utilisateur (User Story) est caractérisée par un rang déduit à partir de sa priorité.
32
4.2. Planification des sprints

La planification du sprint a pour objectif de définir ce qui peut être livré dans le sprint et
comment y parvenir. Elle est l'événement le plus important dans la méthode de travail Scrum.
Le but est de préparer le planning de travail, d'identifier le backlog des sprints et de choisir la
durée des sprints qui diffère selon la complexité du projet et la taille de l'équipe.
Figure 31 : Planning des Sprints
Comme le montre la figure ci-dessus, notre projet se déroule en quatre livrables (Sprints).
- Le premier livrable contenant les fonctionnalités de la partie administrative de

notre application. Nous citons la gestion des listes des maladies et des spécialités
ainsi l’authentification.
- Le deuxième livrable présente trois fonctionnalités qui sont gestion du profil,
s’informer sur les maladies et l’inscription.
- Le troisième livrable présente les fonctionnalités de la partie du patient qui sont
sélectionner les symptômes ressentis, proposer la liste des experts, prendre un
rendez-vous et rappeler l’utilisateur par le rendez-vous.
- Le dernier livrable inclut les fonctionnalités d’un expert qui sont gérer la liste
des symptômes, valider une consultation en ligne et gérer le calendrier des
rendez-vous.
5. Business Model Canvas

Le business model, ou modèle économique, est l'élément clé d'un business plan. C'est lui
qui détermine comment un projet pourra engendrer des gains. Il est donc indispensable de bien
comprendre cette notion afin de choisir le business model le plus adapté à notre projet. La Figure
32 ci-dessous présente le modèle économique adapté à notre projet. [20]
33
Figure 32 : Business Model Canvas
Conclusion
Dans ce chapitre, nous avons préparé notre plan (organisation des sprints) de travail. Puis
nous avons capturé les besoins fonctionnels et non fonctionnels de l’application ainsi que
l’étude technique du projet. Dans le chapitre suivant, nous montrerons la conception du premier
et du deuxième Sprints
34
Chapitre 4 : Sprint 1 & 2
Introduction
Dans le chapitre précédent, nous nous sommes focalisés sur l’étude préliminaire du projet,
son étude technique, et la planification des différentes tâches.Dans ce chapitre nous allons
aborder une tâche importante dans l’élaboration de ce projet. Nous nous intéressons à l’étude
conceptuelle du première et deuxième sprint.
1. Sprint 1
1.1. Backlog du sprint 1
Le tableau 5 regroupe toutes les fonctionnalités qui seront développées lors de ce sprint.
ID User story Description Priorité

1 S’authentifier En tant qu’administrateur, je peux me Haute
connecter à l’application.
2 Gérer la liste des En tant qu'administrateur, je peux ajouter Haute
maladies ou modifier une maladie.
3 Gérer la liste des En tant qu'administrateur je peux ajouter Haute
spécialités ou modifier une spécialité.
Tableau 5 : Backlog du sprint 1
Une fois le backlog du premier sprint est fixé, nous nous concentrons sur la description
fonctionnelle de ce sprint pour décrire les aspects métiers de l'application et établir le périmètre
fonctionnel du projet.
1.2. Description fonctionnelle du sprint 1

Pour donner une vision globale du comportement fonctionnel du système, nous utilisons le
diagramme du cas d'utilisations. C'est l'objectif de cette partie.
1.2.1. Diagramme du cas d’utilisation du sprint 1
Figure 33 : Diagramme de cas d'utilisation relatif à l'administrateur
35
Chapitre 4 Sprint 1 & 2
La figure 33 présente les fonctionnalités que l’administrateur peut faire. Il gère la liste des
maladies et la liste des spécialités, mais à condition qu’il soit connecté à son compte.
1.3. S’authentifier
Cette section présente l'analyse et la conception du cas d'utilisation « S'authentifier »
1.3.1. Description textuelle du cas d’utilisation « S’authentifier »
Pour rendre le diagramme du cas d'utilisation plus lisible et pour expliquer le

fonctionnement du système, nous avons décidé d'utiliser la technique de la description textuelle
des cas d'utilisation pour détailler l'enchaînement des tâches.
Nom du cas d’utilisation S’authentifier

Acteur Administrateur/utilisateur
Objectif Accéder aux fonctionnalités de l’application
Précondition Connexion internet disponible (wifi/3G/4G)
Scénario nominal 1. L'administrateur demande à s'authentifier
2. Le système affiche le formulaire d'authentification
3. L'administrateur saisit les paramètres et les valide
4. Le système vérifie les données saisies et affiche
l'interface d'accueil
Scénario alternatif 4. Le système détecte des données incorrectes
4.1. Le système affiche un message d’erreur
4.2. Le scénario reprend le scénario à l’étape 2.
Post condition Être authentifié
Tableau 6 : Description du diagramme du cas d’utilisation « S’authentifier »
Selon le tableau 6, l'authentification d'un administrateur nécessite la disponibilité d'une

connexion. Ainsi, l'administrateur clique sur le bouton « S’authentifier ». Ensuite, il procède à
la saisie de ses paramètres. Enfin, il valide le formulaire. Dans cette étape le système vérifie les
données saisies : si l'administrateur introduit des paramètres correctes, il accède à l'application
sinon le système affiche un message d'erreur en demandant à l’utilisateur de ressaisir une autre
fois ses informations.
1.3.2. Étude conceptuelle du cas d'utilisation « S’authentifier »
L'étude conceptuelle permet d’étudier des spécifications fonctionnelles exprimées

antérieurement afin de savoir ce que l'application va réaliser réellement en termes de métier.
C'est une étape primordiale dans le cycle de vie d'une application. L'objectif principal de cette
partie est de présenter les échanges de messages entre l’acteur, le système et la base de données
grâce au diagramme de séquence système.
Ce diagramme permet la visualisation d’une séquence de messages entre les différentes
entités par une lecture de haut en bas.
• L’axe vertical représente le temps
• L’axe horizontal représente les entités qui collaborent
• Une ligne verticale en pointillés représente la ligne de vie de chaque objet.
36
Figure 34 : Diagramme de séquence « S’authentifier »
La figure ci-dessus présente le diagramme de séquence système du cas d'utilisation

« S'authentifier ». Après que l’utilisateur ait saisi ses informations, la Vue « authentification »
effectue la vérification des champs et envoyer une requête à la base de données pour vérifier
l'existence des informations et retourner les résultats. En cas d’erreur ou dans le cas où elle est
déjà utilisée par un autre utilisateur, un message d’erreur sera envoyé à l’utilisateur pour
ressaisir ses informations, sinon l'interface d'accueil s'affiche.
1.3.3. Les interfaces du cas d’utilisation « S’authentifier »
Dans cette partie nous avons réalisé les interfaces du cas d’utilisation « S’authentifier ».
Les figures ci-après les présentent :
L’interface "Accueil" : Cette interface permet à accéder à notre application HomeCare.
L’interface "Authentification" : Cette interface permet aux utilisateurs de s'authentifier.
37
Figure 35 Réalisation du cas d’utilisation « S’authentifier »
La figure 35 visualise la page de connexion. En effet l'administrateur doit saisir son email
et son mot de passe correctes pour s’authentifier.
1.4. Gérer la liste des maladies

1.4.1. Ajouter une maladie
• Description textuelle du cas d’utilisation « Ajouter une maladie » :

Nom du cas d’utilisation Ajouter une maladie
Acteur Administrateur
Objectif Ajouter une maladie avec ses différentes
informations.
Précondition L'administrateur est authentifié
Scénario nominal 1. L’administrateur accède à son espace
2. L'administrateur demande à insérer une nouvelle
maladie
3. Le système affiche le formulaire correspondant
4. L'administrateur saisit les informations nécessaires et
les valide
5. Le système vérifie les données introduites et affiche le
succès de l'ajout
4.2. Le scénario reprend à l’étape 3
Post condition Maladie ajoutée
Tableau 7 : Description du diagramme du cas d'utilisation « Ajouter une maladie »
Selon le tableau ci-dessous, L'administrateur demande à insérer une nouvelle maladie mais
à condition qu'il soit authentifié. Le système affiche le formulaire concerné puis l'administrateur
saisit les informations nécessaires. Dans cette étape, le système vérifie les données saisies. En
cas d’erreur de saisie, un message d’erreur sera envoyé à l’utilisateur pour ressaisir ses
informations.
38
• Étude conceptuelle du cas d'utilisation « Ajouter une maladie »
Figure 36 : Diagramme de séquence « Ajouter une maladie »
La figure ci-dessus montre le diagramme de séquence système du cas d'utilisation « Ajouter

une maladie ». Après que l'administrateur ait saisi ses informations, le système effectue la
vérification des champs. En cas d’erreur de saisie, un message d’erreur sera envoyé à
l'administrateur pour ressaisir ses informations.
1.4.2. Modifier une maladie
• Description textuelle du cas d’utilisation « Modifier une maladie »
Selon le tableau ci-dessus, L'administrateur demande à modifier une maladie mais à

condition qu'il soit authentifié. Le système affiche le formulaire rempli. L'administrateur fait
les modifications nécessaires. Dans cette étape le système vérifie les données saisies. En cas
d’erreur de saisie, un message d’erreur sera envoyé à l’utilisateur pour ressaisir les informations
de la maladie.
39
Nom du cas d’utilisation Modifier une maladie

Acteur Administrateur
Objectif Modifier les informations d’une maladie
Précondition L'administrateur est authentifié
Scénario nominal 1. L’administrateur accède à son espace
2. L’administrateur demande à modifier une maladie
3. Le système affiche la liste des maladies
4. L’administrateur sélectionne une maladie
5. Le système affiche le formulaire rempli
6. L’administrateur met à jour les informations
7. Le système vérifie les informations remplies et les
valide
Post condition Maladie modifiée
Tableau 8 : Description du diagramme du cas d'utilisation « Modifier une maladie »
• Étude conceptuelle du cas d'utilisation « Modifier une maladie »
Figure 37 : Diagramme de séquence « Modifier une maladie »

40
La figure 37 illustre le diagramme de séquence du cas d'utilisation modifier une maladie.

Après l’authentification de l’administrateur, il peut demander à modifier une maladie. Dans ce
cas, le système renvoie le formulaire rempli pour le modifier. Ensuite, le système envoie les
modifications à la base de données pour les enregistrer. En cas d’une erreur dans la base, un
message d’errer sera envoyé sinon un message de validation sera envoyé.
• Les interfaces du cas d’utilisation « Gérer la liste des maladies »
Dans cette partie nous avons réalisé les interfaces du cas d’utilisation « Gérer la liste des
maladies ». Les figures ci-aprés les présentent :
L’interface "Administrateur" : Cette interface permet d’accéder aux fonctionnalités que
l’administrateur peut faire.
L’interface "Maladie" : Cette interface permet à l’administrateur de modifier ou ajouter
une maladie.
Figure 38 : Réalisation du cas d’utilisation « Gérer la liste des maladies »
Concernant l’administrateur, il peut à travers ces interfaces, gérer la liste des maladies, soit
pour ajouter une maladie ou soit pour la modifier.
2. Sprint 2
2.1. Backlog du Sprint 2
Dans ce tableau, nous distinguons trois fonctionnalités : une fonction « S’inscrire » pour la
création des comptes, une fonction « Gérer le profil » pour mettre à jours les données
personnelles et une fonction « S’informer sur la maladie » pour avoir des informations sur les
diverses maladies.
41
ID Fonctionnalité Description Priorité

1 S’inscrire En tant qu’utilisateur, je peux Haute
créer un compte.
2 S’informer sur la maladie En tant qu’utilisateur, je peux Haute
avoir des informations et des
conseils sur les différentes
maladies.
3 Gérer le profil En tant qu’utilisateur, je peux Haute
faire la mise à jour de mes
informations personnelles.
2.2. Diagramme du cas d’utilisation du sprint 2
Figure 39 : Diagramme de cas d'utilisation relatif au sprint 2
La figure ci-dessus présente les fonctionnalités que l’utilisateur et le patient peuvent faire.
Un simple utilisateur peut procéder à l’inscription pour créer un compte. Après l`inscription,
l'utilisateur devient un patient qui peut gérer son profil et modifier ses données.
2.3. S’inscrire
2.3.1. Description textuelle de cas d’utilisation « S’inscrire »
Nom du cas d’utilisation S’inscrire
Acteur Utilisateur
Objectif Créer un compte sur l'application
Précondition -
Scénario nominal 1. Accéder à l’application
2. L’utilisateur demande à s’inscrire
3. Le système affiche le formulaire d’inscription
4. L’utilisateur saisit les informations personnelles tels
que l'adresse email, le mot de passe, etc
5. Le système vérifie les données saisies et affiche
l’interface d’accueil
5.1. Le système affiche un message d'erreur
5.2. Le système reprend à l'étape 3 du scénario nominal
Post condition L’utilisateur est ajouté à la base de données
Tableau 10 : Description du diagramme du cas d'utilisation « S'inscrire »
42
D’après le tableau ci-dessus, nous constatons que l’utilisateur procède à la saisie de ses
informations. Dans cette étape notre système vérifie les données saisies. Dans le cas où la forme
d’une information est erronée, des champs vides ou bien au cas où elle est déjà utilisée par un
autre utilisateur, le système affiche un message d'erreur en demandant à l’utilisateur de ressaisir
une autre fois ses informations sinon il sera redirigé vers la page d'accueil de l'application.
2.3.2. Étude conceptuelle du cas d'utilisation « S’inscrire »
Figure 40 : Description du diagramme du cas d'utilisation « S'inscrire »
La figure ci-dessus montre le diagramme de séquence système du cas d'utilisation

« S'inscrire ». Après que l’utilisateur ait saisi ses informations, le système effectue la
vérification des champs. En cas d’erreur de saisie, un message d’erreur sera envoyé à
l’utilisateur pour ressaisir ses informations, sinon les données seront envoyées à la base de
données où se fait la vérification des informations et l’envoi du résultat.
2.3.3. L’interface du cas d’utilisation « S’inscrire »
Dans cette partie nous avons réalisé l’interface du cas d’utilisation «S’inscrire». La figure
ci-après le présente :
L’interface "Inscription" : Cette interface permet à un utilisateur de créer un compte.
43
Figure 41 : Réalisation du cas d’utilisation « S’inscrire »
Comme il est présenté dans la figure 41, en cliquant sur le bouton s’inscrire l'utilisateur
doit saisir les informations indiquées d’une façon correcte pour valider son inscription.
2.4. S’informer sur la maladie

2.4.1. Description textuelle de cas d’utilisation « S’informer sur la maladie »
Nom du cas d’utilisation S’informer sur la maladie
Acteur Utilisateur
Objectif Accéder à des informations sur les différentes
maladies
Précondition -
2. Le système affiche la liste des maladies par catégorie
3. L’utilisateur choisit une maladie
4. Le système affiche les informations et les conseils
relatives à cette maladie
Scénario alternatif -
Post condition Avoir des informations et des conseils pour les
différentes maladies
Tableau 11 : Description du diagramme du cas d'utilisation « S'informer sur la
maladie »
D’après le tableau ci-dessus, nous constatons que lorsque l'utilisateur choisit une maladie,
le système renvoyé la vue qui comporte les informations et les conseils de cette maladie.
2.4.2. Étude conceptuelle du cas d'utilisation « S’informer sur la maladie »
Comme l’illustre la figure ci-dessous du diagramme de séquence système du cas
d'utilisation « S'informer sur la maladie ». Après que l’utilisateur accède à l'application une liste
des maladies s'affichent. Ensuite, l'utilisateur choisit une maladie pour plus d'informations, dans
ce cas, le système envoie une requête à la base de données pour retourner les informations des
maladies enregistrées.
44
Figure 42 : Diagramme de séquence « S'informer sur la maladie »
2.4.3. Les interfaces du cas d’utilisation « S’informer sur la maladie »
Dans cette partie nous avons réalisé les interfaces du cas d’utilisation «S’informer sur la
maladie». Les figures ci-après les présentent :
L’interface "Spécialité" : Cette interface permet d’accéder aux différentes spécialités.
L’interface "Liste maladie" : Cette interface permet aux patients d’avoir la liste des maladies
concernant une spécialité bien déterminé.
L’interface "Informer" : Cette interface permet aux patients d’accéder aux diverses
informations et conseils d’une maladie précise.
Figure 43 : Réalisation du cas d’utilisation « S’informer sur les maladies »
45
2.5. Gérer le profil

2.5.1. Description textuelle de cas d’utilisation « Gérer le profil »
Nom du cas d’utilisation Gérer le profil

Acteur Patient
Objectif Mis à jour des informations personnelles
Précondition Le patient est authentifié
2. Le patient demande à gérer son profil
4. Le patient ajoute les informations et les valide
5. Le système vérifie les informations saisies

5.1. Le système affiche un message d'erreur
5.2. Le système reprend à l'étape 3 du scénario
nominal
Post condition Profil mis à jour
Tableau 12 : Description du diagramme du cas d'utilisation « Gérer le profil »
Selon le tableau 44, Le patient demande à gérer son profil. Le système affiche le
formulaire rempli. Le patient effectue les modifications nécessaires.
Dans cette étape le système vérifie les données saisies. En cas d’erreur de saisie, un
message d’erreur sera envoyé à l’utilisateur pour ressaisir ses informations.
2.5.2. Étude conceptuelle du cas d'utilisation « Gérer le profil »

La figure 44 illustre le diagramme de séquence du cas d'utilisation de gérer le profil.
Après l’authentification du patient, il peut demander à mettre à jours ses informations.
Dans ce cas, le système renvoie le formulaire rempli pour le modifier. Ensuite, le
système envoie les modifications à la base de données. En cas d’une erreur dans la base, un
message d’errer sera envoyé sinon un message de validation sera envoyé.
46
Figure 44 : Diagramme de séquence « Gérer le profil »
2.5.3. Les interfaces du cas d’utilisation « Gérer le profil »
Dans cette partie nous avons réalisé les interfaces du cas d’utilisation « Gérer le profil ».
La figure ci-après le présente :
L’interface "Mon profil" : Cette interface permet à un utilisateur de mettre à jour ses
informations personnelles.
47
Figure 45 : Réalisation du cas d’utilisation « Gérer le profil »
Concernant le patient, il peut à travers cette interface mettre les informations personnelles
comme nom, prénom, email, etc.
Conclusion
Dans ce chapitre nous avons établi le première et le deuxième sprint, et nous avons défini
ses différentes fonctionnalités réalisées à travers ses description fonctionnelles et sa réalisation.
Dans le chapitre suivant nous décrivons le troisième et le quatrième sprint.
48
Chapitre 5 : Sprint 3 & 4
Introduction
Dans le chapitre précédent, nous nous sommes focalisés à l’étude conceptuelle du première
et deuxième sprint. Dans ce chapitre nous allons aborder une tâche importante dans
l’élaboration de ce projet. Nous nous intéressons à l’étude conceptuelle du troisième et
quatrième sprint.
1. Sprint 3

Dans ce tableau, nous distinguons quatre fonctionnalités : une fonction « Sélectionner les
symptômes ressentis » pour préciser la maladie adéquate, une fonction « Proposer la liste des
experts », une autre fonction « Prendre un rendez-vous » et finalement une fonction « Rappeler
l’utilisateur par le rendez-vous ».

1 Sélectionner les symptômes En tant qu’un patient, je Haute
ressentis peux sélectionner les
symptômes que je ressens.
2 Proposer la liste des experts En tant qu’un patient, je Moyenne
peux faire apparaître la liste
des experts adéquats les plus
proches.
3 Prendre un rendez-vous En tant qu’un patient, je Moyenne
peux prendre un rendez-vous,
soit en ligne ou soit sur place.
4 Rappeler l’utilisateur par le En tant qu’un patient, je Faible
rendez-vous peux avoir des rappels
concernant mes rendez-vous
1.2. Diagramme du cas d'utilisation du sprint 3

La figure 46 présente les fonctionnalités que l’utilisateur et le patient peuvent faire. Un
simple utilisateur peut avoir des informations et des conseils sur diverses maladies. Après
l’inscription, le patient peut selectionner ses symptômes afin de mieux cerner sa maladie.
49
Figure 46 : Diagramme du cas d'utilisation relatif au sprint 3
1.3. Sélectionner les symptômes ressentis

1.3.1. Description textuelle du cas d’utilisation « Sélectionner les symptômes ressentis »
Nom du cas d’utilisation Sélectionner les symptômes ressentis

Acteur Patient
Objectif Avoir une idée sur la maladie
Précondition Authentification
Scénario nominal 1. Le patient clique sur le button « Test » pour spécifier
les symptômes ressentis
2. Le système affiche la liste des symptômes
3. Le patient sélectionne ses symptômes
4. Le système calcule les données sélectionnées et
affiche le résultat
Post condition Avoir des informations pour sa maladie
Tableau 14 : Description du diagramme du cas d'utilisation « Sélectionner les

symptômes ressentis »
Dans le tableau 14, nous pouvons voir que lorsqu'un patient demande une sélection de
symptômes, le système interroge la base de données et renvoie les symptômes, et le système
affiche cette liste. Une fois qu'un patient est sélectionné, le système suggère les maladies
appropriées et leurs informations.
50
1.3.2. Étude conceptuelle du cas d'utilisation « Sélectionner les symptômes ressentis »
Figure 47 : Diagramme de séquence « Sélectionner les symptômes ressentis »
Comme l’illustre la figure 47 du diagramme de séquence système du cas d'utilisation

« Sélectionner les symptômes ». Après que l’utilisateur accède à l'application et demande à
sélectionner ses symptômes, une liste des symptômes s’affiche afin de sélectionner et calculer
ses symptômes pour mieux l’informer sur la maladie ressentie.
1.3.3. L’interface du cas d'utilisation « Sélectionner les symptômes ressentis »
Dans cette partie nous avons réalisé l’interface du cas d’utilisation «Sélectionner les
symptômes ressentis». La figure ci-aprés le présente : L’interface "Symptoms" : Cette interface
permet aux patients de sélectionner leurs symptômes ressentis pour trouver la maladie adéquate.
Figure 48 : Réalisation du cas d’utilisation «Sélectionner les symptômes ressentis»
51
1.4. Proposer la liste des experts

1.4.1. Description textuelle du cas d’utilisation « Proposer la liste des experts »
Nom du cas d’utilisation Proposer la liste des experts

Acteur Patient
Objectif Avoir une liste des experts les plus proches
Précondition Le patient sélectionne ses symptômes ressentis
Scénario nominal 1. Le patient accède à l’interface expert
2. Le patient demande la liste des experts
3. Le système lit les cordonnées GPS du patient
4. Le système trouve les experts les plus proches
5. Le système affiche la liste des experts les plus proches
Scénario 3. Le patient n’autorise pas la lecture du GPS
d’exception 3.1. Le système affiche un message d’erreur
3.2. Le système quitte le cas d’utilisation avec exception
Post condition Avoir l’expert le plus proche
Tableau 15 : Description du diagramme du cas d'utilisation « Proposer la liste des
experts »
Dans le tableau 15, nous pouvons constater que le patient n’accède à la liste des experts
que lorsqu’il sélectionne ses symptômes. Suite à la demande du patient de cette liste, le système
l'affichera.
1.4.2. Étude conceptuelle du cas d'utilisation « Proposer la liste des experts »
Figure 49 : Diagramme de séquence « Proposer la liste des experts »
52
Comme l’illustre la figure 49, après que l’utilisateur accède à l'application et demande à
sélectionner ses symptômes, il demande d’avoir une liste des experts les plus proches, le
système envoi une requête à la base de données pour retourner la liste. Et par conséquence, il
va afficher.
1.4.3. L’interface du cas d'utilisation « Proposer la liste des experts »
Dans cette partie nous avons réalisé l’interface du cas d’utilisation «Proposer la liste des
experts». La figure ci-après le présente : L’interface "Liste expert" : Cette interface permet
d’avoir la liste des experts les plus proches.
Figure 50 : Réalisation du cas d’utilisation « Proposer la liste des experts »
Comme le montre dans la figure 50, le patient peut accéder à la liste des experts les plus
proches à votre position.
1.5. Prendre un rendez-vous

1.5.1. Description textuelle du cas d’utilisation « Prendre un rendez-vous »
Nom du cas d’utilisation Prendre un rendez-vous

Acteur Patient
Objectif Enregistrer un rendez-vous
Précondition Le patient demande à proposer une liste des experts
Scénario nominal 1. Le patient accède à l’interface de la liste des experts
2. Le patient choisit un expert
3. Le système affiche un formulaire de rendez-vous
4. Le patient sélectionne les données nécessaires
5. Le système envoie un message de validation
Post condition Rendez-vous enregistré
Tableau 16 : Description du diagramme du cas d'utilisation « Prendre un rendez-

vous »
53
Dans le tableau 16, nous pouvons constater que le patient ne prend un rendez-vous que
lorsqu’il accède à la liste des experts. Suite à la demande d’un rendez-vous le système renvoie
un formulaire. Le patient sélection les informations et valider le formulaire dans ce cas le
système va retourner un message valide.
1.5.2. Étude conceptuelle du cas d'utilisation « Prendre un rendez-vous »
Figure 51 : Diagramme de séquence « Prendre un rendez-vous »
Comme l’illustre la figure ci-dessous du diagramme de séquence système du cas

d'utilisation « Prendre un rendez-vous ». Après que l’utilisateur accède à l'application et
demande à prendre un rendez-vous, le système affiche un formulaire. Le patient sélectionne les
données nécessaires et les valide, dans ce cas, le système envoie une requête à la base de
données pour les enregistrées. Enfin le système affiche un message valide.
1.5.3. L’interface du cas d'utilisation « Prendre un rendez-vous »
Dans cette partie nous avons réalisé l’interface du cas d’utilisation «Prendre un rendez-
vous». La figure ci-aprés le présente : L’interface "Rendez-vous" : Cette interface permet de
prendre un rendez-vous soit en ligne ou sur place.
54
Figure 52 : Réalisation du cas d’utilisation «Prendre un rendez-vous»
La figure 52 montre que le patient peut prendre un rendez-vous à travers la sélection des
informations nécessaires ( date, paiement, ..) et la validation.
1.6. Rappeler l’utilisateur par le rendez-vous

1.6.1. Description textuelle de cas d’utilisation « Rappeler l’utilisateur par le rendez-
vous »
Nom du cas d’utilisation Rappeler l’utilisateur par le rendez-vous

Acteur Patient
Objectif Avoir un rappel à chaque rendez-vous
Précondition Le patient prend un rendez-vous
Scénario nominal 1. La base de données envoie un déclanchement au
système
2. Le système fait une vérification et envoie une
notification au patient
Post condition Rappel de rendez-vous s’effectue
Tableau 17 : Description du diagramme du cas d'utilisation « Rappeler l'utilisateur

par le rendez-vous »
Dans le tableau 17, nous pouvons voire que lorsque la date de rendez-vous arrive, la base
de données envoie un déclanchement au système. Suit à ce déclanchement le système envoi une
notification au patient pour le rappeler à son rendez-vous.
55
1.6.2. Étude conceptuelle du cas d'utilisation « Rappeler l’utilisateur par le rendez-

vous »
Figure 53 : Diagramme de séquence « Rappeler l’utilisateur par le rendez-vous »
1.6.3. L’interface du cas d'utilisation «Rappeler l’utilisateur par le rendez-vous»
Dans cette partie nous avons réalisé l’interface du cas d’utilisation «Rappeler l’utilisateur
par le rendez-vous». La figure ci-après le présente : L’interface "Rappel" : Cette interface
permet aux patients de se faire rappeler à leurs rendez-vous.
Figure 54 : Réalisation du cas d’utilisation «Rappeler l’utilisateur par le rendez-

vous»
La figure ci-dessus montre la notification envoyée à un patient lorsque son rendez-vous

arrive.
56
2. Sprint 4

Le tableau ci-dessous regroupe toutes les fonctionnalités qui seront développées lors de ce
sprint. Dans ce tableau, nous distinguons trois fonctionnalités : une fonction « Gérer la liste des
symptômes » pour modifier ou ajouter un symptôme, une fonction pour « Gérer le calendrier
des rendez-vous » et une fonction « valider une consultation en ligne ».

1 Gérer la liste des symptômes En tant qu'un expert, je peux Moyenne
ajouter ou modifier un
symptôme.
2 Gérer le calendrier des rendez- En tant qu’un expert, je peux Moyenne
vous modifier le calendrier des
rendez-vous.
3 Valider une consultation en En tant qu’un expert, je peux Faible
ligne valider une demande de
consultation en ligne
2.2. Diagramme du cas d’utilisation du sprint 4
Figure 55 : Diagramme du cas d'utilisation relatif au sprint 4
La figure 55 présente les fonctionnalités que l’expert peut faire. L’expert peut gérer son
profil, gérer la liste des symptomes et gérer son calendrier des rendez-vous à condition qu’il
soit authentifié.
57
2.3. Gérer la liste des symptômes

2.3.1. Ajouter un symptôme
• Description textuelle de cas d’utilisation « Ajouter un symptôme »
Nom du cas d’utilisation Ajouter un symptôme
Acteur Expert
Objectif Ajouter un symptôme avec ses différentes

informations.
Précondition Expert est authentifié
Scénario nominal 1. L’expert accède à son espace

2. L'expert demande à insérer un nouveau symptôme
3. Le système affiche le formulaire correspondant
4. L'expert saisit les informations nécessaires et les
valide
5. Le système vérifie les données introduites et affiche le
succès de l'ajout

Post condition Symptôme ajouté
Tableau 19 : Description du diagramme du cas d'utilisation « Ajouter un symptôme »
Selon le tableau 19, L’expert demande à insérer un nouveau symptôme mais à condition
qu'il soit authentifié. Le système affiche le formulaire concerné puis l’expert saisi les
informations nécessaires. Et enfin, le système vérifie les données saisies. S’il y a une erreur de
saisie, un message d’erreur sera envoyé à l’utilisateur pour ressaisir ses informations.
58
• Étude conceptuelle du cas d'utilisation « Ajouter un symptôme »
Figure 56 : Diagramme de séquence « Ajouter un symptôme »
La figure 56 montre le diagramme de séquence système du cas d'utilisation « Ajouter un

symptôme ». Après que l'expert ait saisi ses informations, le système effectue la vérification
des champs. En cas d’erreur de saisie, un message d’erreur sera envoyé à l'expert pour ressaisir
ses informations.
59
2.3.2. Modifier un symptôme
• Description textuelle du cas d’utilisation « Modifier un symptôme »
Nom du cas d’utilisation Modifier un symptôme

Acteur Expert
Objectif Modifier les informations d’un symptôme
Précondition L'expert est authentifié
Scénario nominal 1. L’expert accède à son espace
2. L’expert demande à modifier un symptôme
3. Le système affiche la liste des symptômes
4. L’expert sélectionne un symptôme
6. L’expert met à jour les informations
7. Le système vérifie les informations remplies et les
valide

Post condition Symptôme modifié
Tableau 20 : Description du diagramme du cas d'utilisation « Modifier un symptôme »
Selon le tableau ci-dessus, L'expert demande à modifier un symptôme mais à condition

qu'il soit authentifié. Le système affiche la liste des symptômes, puis l’expert sélectionne un
symptôme. Le système affiche le formulaire rempli. L'expert fait les modifications nécessaires.
Dans cette étape le système vérifie les données saisies. En cas d’erreur de saisie, un message
d’erreur sera envoyé à l’utilisateur pour ressaisir ses informations.
• Étude conceptuelle du cas d'utilisation « Modifier un symptôme »
La figure 57 illustre le diagramme de séquence du cas d'utilisation modifier un symptôme.

Après l’authentification de l’expert, il peut demander à modifier un symptôme. Dans ce cas, le
système renvoie le formulaire pour le modifier. Ensuite, le système envoie les modifications à
la base de données pour les enregistrer. En cas d’une erreur dans la base, un message d’erreur
sera envoyé sinon un message de validation sera envoyé.
60
Figure 57 : Diagramme de séquence « Modifier un symptôme »
• Les interfaces du cas d’utilisation « Gérer la liste des symptômes »
Dans cette partie nous avons réalisé les interfaces du cas d’utilisation «Gérer la liste des
symptômes ». Les figures ci-après les présentent :
L’interface "Expert" : Cette interface permet à accéder aux fonctionnalités que l’expert
peut faire.
L’interface "Symptôme" : Cette interface permet à un expert de modifier ou ajouter un
symptôme.
61
Figure 58 : Réalisation du cas d’utilisation « Gérer la liste des symptômes »
Concernant l’expert, il peut à travers ces interfaces, gérer la liste des symptômes, soit pour
ajouter un symptôme ou soit pour le modifier.
2.4. Gérer le calendrier des rendez-vous

2.4.1. Description textuelle du cas d’utilisation « Gérer le calendrier des rendez-vous »
Nom du cas d’utilisation Gérer le calendrier des rendez-vous

Acteur Expert
Objectif Mis à jour de calendrier
Précondition L'expert est authentifié
2. L’expert demande à gérer son calendrier des rendez-
vous
3. Le système affiche le calendrier rempli
4. L’expert modifie le calendrier
5. Le système envoie un message de validation
Post condition Calendrier mis à jour
Tableau 21 : Description du diagramme du cas d'utilisation « Gérer le calendrier des

rendez-vous »
Dans le tableau ci-dessus, nous pouvons constater que l’expert peut consulter et modifier
son calendrier des rendez-vous. Le système renvoie un formulaire. L’expert modifie les
informations s’il veut dans ce cas le système va retourner un message valide.
62
2.4.2. Étude conceptuelle du cas d'utilisation « Gérer le calendrier des rendez-vous »
Figure 59 : Diagramme de séquence « Gérer le calendrier des rendez-vous »
Comme l’illustre la figure 59 du diagramme de séquence système du cas d'utilisation

« Gérer le calendrier des rendez-vous ». Après que l’expert accède à l'application et demande
de consulter le calendrier, le système affiche le calendrier concerné. L’expert peut aussi
modifier son calendrier, dans ce cas, le système envoie une requête update à la base de données
après que l’expert ait saisi ses modifications.
63
2.4.3. L’interface du cas d'utilisation « Gérer le calendrier des rendez-vous »
Dans cette partie nous avons réalisé les interfaces du cas d’utilisation « Gérer le calendrier
des rendez-vous ». La figure ci-après le présente :
L’interface "Calendrier" : Cette interface permet de consulter et modifier le calendrier
des rendez-vous d’un expert donné.
L’interface "Rendez-vous" : Cette interface permet de consulter la liste des rendez-
vous enregistrés.
L’interface "Expert" : Cette interface permet d’accéder aux fonctionnalités que
l’expert peut faire.
Figure 60 : Réalisation du cas d’utilisation «Gérer le calendrier des rendez-vous »
Conclusion
Dans ce chapitre nous avons établi le troisième et le quatrième sprint, et nous avons défini
ses différentes fonctionnalités réalisées à travers ses description fonctionnelles et sa réalisation.
64
Conclusion générale
De nos jours, les téléphones portables font partie de notre quotidien, tant dans notre vie
personnelle qu'au travail, notamment via les applications mobiles. D'ailleurs, ce dernier est en
cours de développement pour toucher tous les utilisateurs et toucher tous les domaines, y
compris la santé.
En effet, dans le cadre de notre mini projet, nous avons conçu une application gratuite
d’aide à la décision médicale. Cette application peut recommander le bon spécialiste en fonction
des symptômes saisis par l’utilisateur.
Après avoir mené une étude préliminaire, clarifié la problématique et établi une méthode
de travail, nous avons procédé à l'analyse et à l'identification des besoins. Ensuite, nous avons
mené une étude conceptuelle d'une application basée sur l'architecture MVC. Enfin, dans notre
travail, nous avons créé le maquettage de ses différentes fonctionnalités.
De même, Ce projet a été très enrichissant puisqu'il nous a permis de connaître et de mieux
gérer les outils de conception tels que UML, Trello et Adobe xd. De plus, nous avons une
opportunité de pratiquer de nouveaux concepts, en particulier la pensée agile, maîtriser la
gestion du temps, la gestion d’équipe, en assurant la bonne écoute des idées de chacun de nous,
ainsi la bonne gestion du projet.
Enfin, il s'agit d'une expérience très bénéfique et intéressante puisqu’il nous a permis
d'élaborer une idée innovante et d'enrichir la notion du travail en groupe et la prise de
responsabilité.
65
Webographie
[1] Aymen Tourki , « Med.tn » , https://www.med.tn/ : Consulté le 10/2022
[2] « Qalyo », https://www.qalyo.com/ : Consulté le 10/2022
[3] « Tobba.tn » , https://www.tobba.tn/ : Consulté le 10/2022
[4] « at-home-doc.com »https://at-home-doc.com/ : Consulté le 10/2022
[5] « home.treatment.doctorathome» , https://play.google.com/store/apps/

=com.gallant.home.treatment.doctorathome : Consulté le 11/2022
[6] « ionos », https://www.ionos.fr/digitalguide/sites-internet/developpement-

web/modele-en-cascade/ : Consulté le 11/2022
[7] « manager-go », https://www.manager-go.com/gestion-de-projet/cycle-en-v.htm :

Consulté le 11/2022
[8] « Le parisien », https://dictionnaire.sensagent.leparisien.fr/ : Consulté le 11/2022
[9] Agence Idéematic, « ideematic », https://www.ideematic.com/ : Consulté le 11/2022
[10] « savoiragile », https://savoiragile.com/ : Consulté le 11/2022
[11] « europa », https://europa.eu/ : Consulté le 11/2022
[12] « Staruml », https://staruml.io/ : Consulté le 12/2022
[13] « trello », https://trello.com/fr : Consulté le 12/2022
[14] « illustartor », https://www.adobe.com/fr/products/illustrator/chart-design-

software.html : \textbf{Consulté le 12/2022
[15] « apcpedagogie », https://apcpedagogie.com/le-modele-mvc/ : Consulté le 12/2022
[16] « pcsoft », https://aide.pcsoft.fr/ : Consulté le 12/2022
[17] « medium », https://medium.com/androidmood/comprendre-larchitecture-mvvm-

sur-android : Consulté le 12/2022}
66
[18] « AdobeXD », https://www.adobe.com/products/xd/learn/get-started/what-is-adobe-
xd-used-for.html : Consulté le 12/2022
[19] « My Business Plan», https://www.my-business-plan.fr/dossiers/business-model :

Consulté le 12/2022
67
Annexe
1. Présentation de questionnaire :
Partie 1 : Questions introductives
Le but derrière ces questions est de savoir :
• S’il y a des personnes trouvent vraiment des difficultés dans la recherche des médecins
adéquats ;
• Les outils qu’ils utilisent pour trouver des médecins adéquats ;
• La fréquence d’utilisation des applications médicales ;
• L’utilité perçue des applications médicales.
68
69
Partie 2 : Questions spécifiques
70
71
Partie 3 : Fiche signalétique
72
2.Charte Graphique :
1. Logo Home Care :

Le logo est présenté sous une forme horizontale et verticale pour se prêtre à toutes les
présentations.
Logotype verticale :
Logotype horizontale :
Le logo contient quatre éléments importants :
Le nom de l'application : Le terme "home care" (soins à domicile) fait référence aux services
de soins de santé qui sont fournis à un patient dans son domicile plutôt que dans un
établissement médical. Il indque que l'entreprise est impliquée dans la fourniture de soins de
santé à domicile ou dans l'aide à la gestion de la santé à la maison dans le but d'aider les patients
à rester en bonne santé et à vivre de manière autonome à la maison.
73
Stethoscope : Un stéthoscope est un instrument médical utilisé pour écouter les sons internes
du corps, principalement le cœur, les poumons et les intestins. Il est souvent utilisé par les
médecins et les infirmiers pour diagnostiquer et surveiller la santé des patients. La forme d'un
stéthoscope indique que l'application est liée à la santé ou au monde médical de quelque
manière.
Maison : pour symbolise un lieu de soins et de soutien pour les patients. Pour montrer que
l'application offre une assistance médicale à domicile ou que l'application est destinée à aider
les gens à gérer leur santé à la maison. La maison pourrait également être utilisée pour suggérer
que l'application est facile à utiliser et accessible, comme si elle était une "maison" pour la santé
et le bien-être. En général la forme d'une maison dans un logo peut être utilisée pour suggérer
la sécurité, le confort et l'accueil.
Un slogon : "the first wealth is health" (la première richesse est la santé) suggère que la santé
est la première et la plus importante forme de richesse qu'une personne peut avoir. Cela signifie
que, même si une personne peut être financièrement prospère, elle ne peut pas être vraiment
heureuse ou réussie si elle n'a pas de bonne santé. Le slogon permet d'encourager les gens à
prendre soin de leur santé et à mettre en priorité leur bien-être physique et mental.
74
2.version couleurs
Les couleurs utilisées sont : Le bleu avec sa dégradation
Le bleu pétrole : c'est une couleur associée à la sécurité, la fiabilité et la confiance. Pour montrer
que notre application est digne de confiance et fiable en matière de soins de santé et aussi pour
suggérer notre application est sécurisée et protégée, comme si elle était un refuge ou un havre
de paix pour les patients. C'est une couleur calme et apaisante, ce qui peut être un atout pour
une application médicale qui souhaite rassurer et réconforter les patients.
Le bleu ciel : est considérée comme une couleur fraîche et rafraîchissante, ce qui peut être un
atout pour une application médicale qui souhaite être perçue comme innovante et moderne.
3.version négative
Une version négative d'une charte graphique est une version inversée de la charte graphique qui
utilise des couleurs et des formes opposées à celles de la charte originale. Elle est utilisée pour
adapter une charte graphique à différents contextes ou supports de communication.
La version blanche sur un fond noir :
75
La version noir sur un fond blanc :
4.Typographie principale :
Pour la construction du logo , nous avons utilisé la police : Segoe UI Symbol Regular. Cette
police combine avec élégance une simplicité gothique et un design distinctif néanmoins subtil.
Une force architecturale s’en dégage grâce à l’épaisseur constante des lettres et un effet de
poussée verticale. Les symboles et les icônes de Cette police sont conçus de manière
professionnelle et bien exécutée, ce qui peut ajouter de la crédibilité et de la qualité au logo.
ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrtsuvwxyz àâçéèêîÏôèuùûü

1234567890$%-.,;:()/«»?!*
5.Usages interdits du logo :
5.1 gestion de la taille et des formations :

Le logo ne doit jamais être déformé.
76
Les couleurs ne doivent jamais être modifiées.
Le logo ne doit pas être utilisé sur un fond photographique pouvant nuire à sa lisibilité.
Le logo ne doit jamais être utilisé sur un fond à motif :
77
Le logo ne doit jamais être modifié en 3D.
5.2. Zone de dégagement
Pour préserver l’impact visuel du logo et éviter qu’il entre en conflit avec d’autres éléments
visuels environnants, il faut respecter une zone minimale de dégagement tout autour. Cette zone
correspond à un carré formé par la hauteur de la lettre H du mot Home.
78
6.Application mobile :
6.1. Les différentes interfaces d’accueil
6.2. Les interfaces d’inscription et d’authentification
6.3. Les interfaces de la liste des spécialités
79
6.4. Les interfaces des maladies
6.5. L’interface des symptômes
6.6. Les interfaces de la liste des experts les plus proches et de prendre des rendez-vous
80
6.7. Les interfaces de gestion de profil
6.8. L’interface calendrier
6.9. Les interfaces d’accueil de l’expert et de l’administrateur
81
6.10. L’interface de la liste des rendez-vous d’un expert
6.11. Les interfaces de gestion des symptômes
6.13. Les interfaces de gestion de la liste des maladies et la liste des experts
82

Khouloud Rania 2023

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Khouloud Rania 2023

Transféré par

Droits d'auteur :

Formats disponibles

Remerciements

Nous sommes reconnaissants envers Dieu, le Tout-Puissant, de nous avoir donné la

Par la même occasion, nous adressons nos remerciements à l'équipe administrative de

Merci à tous et à toutes.

Figure 1 : Application mobile « Med »[1] 3

Alors comment pouvons-nous exploiter le pouvoir de nouvelles technologies pour

2.1. Présentation des solutions existantes

Les concurrents nationaux :

Figure 1 : Application mobile « Med »[1]

Figure 2 : Application mobile « QALYO »[2]

Figure 3 : La plateforme « Tobba.tn » [3]

Les solutions à l’échelle nationale étaient limitées à la présentation des fonctionnalités de

Les concurrents internationaux :

Figure 4 : Application mobile « At Home Doc » [4]

• L'application Doctor At Home, Home Remedies est une application mobile

Figure 5 : Application mobile « Doctor At Home, Home Remedies »[5]

2.2. Critique de l'existant

Nom de la solution Points forts Points faibles

Tobba.tn - Temps de chargement rapide - Absence d’application mobile

Doctor At Home, -Application gratuite - N’offre pas des résultats à

2.3. Solution proposée

2.3.1. Objectifs de l’application

• Informer les utilisateurs sur les différentes maladies.

2.3.2. Tableau benchmark

Les Med QALYO Tobba.tn At Home Doctor At Home

Après l'étape de recherche d'existence et de proposition de solution, il est important

3. Choix de la méthodologie de travail

La méthodologie est la démarche organisée rationnellement pour aboutir à un résultat. Les

3.1. L’approche classique

Figure 6 : Les phases du cycle en « cascade »

Le cycle en V en gestion de projet découle du modèle en cascade, qui permet de représenter

Figure 7 : Les phases du cycle en « V »

Figure 8 : Les phases du cycle en « Spirale »

3.2. Les approches agiles

Figure 9 : Méthode de travail Agile

3.3. Etude comparative entre les méthodes traditionnelles et agiles

Points forts Points faibles

3.4. Méthode de travail adoptée : SCRUM

Trois piliers soutiennent l'implémentation d'un contrôle empirique de processus :

La méthode Scrum définit trois rôles qui sont :

• Le Product Owner : est responsable de maximiser la valeur du produit et du travail de

Figure 10 : Cycle de vie Scrum

Scrum propose la création de trois artefacts essentiels :

• Le backlog de produit (Product backlog) : est une liste ordonnée et priorisée de

Ce chapitre nous a présenté le cadre général du projet à savoir : la problématique et sa

1.1. Utilité du questionnaire

• Le questionnaire fermé : Dans un questionnaire fermé, les questions imposent au

Figure 11 : Exemple de question fermée

• Le questionnaire ouvert : Dans un questionnaire ouvert, la personne interrogée

Figure 12 : Exemple de question ouverte

Figure 13 : Exemple de question semi-ouvertes

1.3. Choix d’une enquête en ligne et de terrain

• L’instantanéité des résultats : Nous pouvons évaluer en direct la réussite de notre

Figure 14 : Les publications du questionnaire dans les groupes Facebook

1.4. Les outils de travail

1.5. Présentation du questionnaire

Partie 1 : Fiche signalétique

2. Présentation et analyse des résultats issus de Google

Figure 15 : Définition du profil du répondeur

2.1. Evaluation générale du besoin et de l’idée technologique

Figure 16 : Difficultés de prospection de médecin adéquat

Figure 17 : Perte du temps nécessaire pour diagnostiquer les symptômes

Figure 18 : La connaissance des applications permettant de trouver le médecin