Dédicaces

A mes parents

Pour tous les sacrifices qu’ils ont faits et pour tout le soutien qu’ils ont offert tout au
long de mes études.

J’espère qu’ils puissent trouver dans ce modeste travail un témoignage d’amour et

d’affection envers eux.

A mes amis et mes collègues

Pour leur encouragement et pour tous les bons moments qu’on a vécus ensemble.
J’espère que notre amitié durera éternellement.

Fehmi

i
 Remerciements
Au terme de ce travail, je tiens à remercier mademoiselle Mariem el
Chikh, directrice général de HypaTech, de m’avoir accordé cette
opportunité d’entreprendre ce projet au sein de l’équipe de HypaTech.

Un grand merci à mademoiselle Manel Blaghji ma superviseur à

l’ISET, pour son assistance, sa disponibilité, ces conseils judicieux
lors de la réalisation de ce projet et son aide à l’aboutissement de la
bonne organisation de ce rapport.

Et je ne peux pas passer au silence toute l'équipe de COZI co-working

space pour leur accueil, leur esprit d'équipe et en particulier Mr
Houssem Akrout, qui m'a accordé de son temps précieux pour m’aider
et me soutenir.

Je tiens également à exprimer toute ma gratitude aux membres du jury

pour avoir accepté d’assister à ce modeste travail.

Enfin, je ne veux pas oublier tous ceux qui ne cessent de

m’encourager de près ou de loin.

ii
Table de matières
Introduction générale .................................................................................................................. 1

Chapitre 1: Etude préalable ..................................................................................................... 3

Introduction ............................................................................................................................ 3

1.1 Étude de l’organisme d'accueil .................................................................................... 3

1.2 Présentation du projet .................................................................................................. 3

1.3 Spécification des besoins ............................................................................................. 4

1.3.1 Spécification des besoins fonctionnels ................................................................. 4

1.3.2 Spécification des besoins non fonctionnels .......................................................... 5

1.4 Planification de projet .................................................................................................. 6

Conclusion .............................................................................................................................. 7

Chapitre 2: Etude conceptuelle ............................................................................................... 9

Introduction ............................................................................................................................ 9

2.1 Méthodes et outils de modélisation ............................................................................. 9

2.1.1 Langage de modélisation (UML) ......................................................................... 9

2.1.2 L’outil de modélisation ........................................................................................ 9

2.2 Identification des acteurs et des cas d’utilisation ...................................................... 10

2.3 Diagrammes de cas d’utilisation................................................................................ 10

2.3.1 Diagramme de cas d’utilisation global ............................................................... 10

2.3.2 Diagramme de cas d’utilisation de l’administrateur .......................................... 11

2.3.2.1 Description du cas d’utilisation gestion des spécialités .............................. 12

2.3.3 Diagramme de cas d'utilisation du patient.......................................................... 13

2.3.3.1 Description du cas d’utilisation de prise de rendez-vous............................ 14

2.3.3.2 Description du cas d’utilisation de recherche de médecin .......................... 14

2.3.3.3 Description du cas d’utilisation de création du compte patient .................. 15

2.3.4 Diagramme de cas d'utilisation du médecin ....................................................... 16

i
 2.4 Etude de quelques diagrammes des séquences .......................................................... 17

2.4.1 Diagramme de séquence de prise de rendez-vous .............................................. 17

2.4.2 Diagramme de séquence de recherche du médecin ............................................ 18

2.4.3 Diagramme de séquence de création du compte patient .................................... 19

2.4.4 Diagramme de séquence de l’administrateur ..................................................... 20

2.5 Diagramme de classes ............................................................................................... 21

2.6 Diagramme de déploiement ....................................................................................... 22

2.7 Schéma de la base de données ................................................................................... 24

2.8 Conception architecturale .......................................................................................... 24

2.9 Charte graphique ........................................................................................................ 26

2.9.1 Le logotype ......................................................................................................... 26

2.9.1.1 Les données colo-métriques :...................................................................... 26

2.9.1.2 Les formes ................................................................................................... 27

2.10 Prototypes d’interface ............................................................................................ 27

Conclusion ............................................................................................................................ 28

Chapitre 3: Réalisation .......................................................................................................... 30

Introduction .......................................................................................................................... 30

3.1 Architecture du système et environnement de test .................................................... 30

3.1.1 Pourquoi utiliser un Framework ? ...................................................................... 30

3.1.2 Le Framework Laravel ....................................................................................... 31

3.1.2.1 Définition .................................................................................................... 31

3.1.2.2 Structure du répertoire ................................................................................ 31

3.2 Environnement de développement ............................................................................ 32

3.2.1 Environnement matériel ..................................................................................... 32

3.2.2 Environnement logiciel ...................................................................................... 33

3.2.2.1 Application Web ......................................................................................... 33

3.2.2.2 Application Desktop ................................................................................... 34

ii
 3.2.2.3 Application mobile...................................................................................... 35

3.3 Description des interfaces réalisées ........................................................................... 36

3.3.1 Application android ............................................................................................ 36

3.3.1.1 Interface d’authentification ......................................................................... 36

3.3.1.2 Interface de recherche d’un médecin dans la carte ..................................... 37

3.3.1.3 Interface profil d’un médecin et processus de prise d’un rendez-vous ....... 38

3.3.1.4 Interface de liste des rendez-vous ............................................................... 40

3.3.2 Application Web ................................................................................................ 42

3.3.2.1 Interface d’authentification ......................................................................... 42

3.3.2.2 Interface calendrier des rendez-vous........................................................... 43

3.3.2.3 Interface statistiques .................................................................................... 43

3.3.2.4 Interface profil médecin .............................................................................. 44

3.3.2.5 Interface profil patient ................................................................................. 44

3.3.2.6 Interface fiche rendez-vous ......................................................................... 45

3.3.3 Application desktop............................................................................................ 46

3.3.3.1 Interface d’authentification ......................................................................... 47

3.3.3.2 Interface de vérification des médecins ........................................................ 47

3.3.3.3 Interface de gestion des spécialités ............................................................. 48

Conclusion ............................................................................................................................ 49

Conclusion Générale ................................................................................................................ 50

Bibliographie ............................................................................................................................ 51

iii
 Liste des figures
Figure 1: Logo du HypaTec ....................................................................................................... 3
Figure 2: Fonctionnement du JWT............................................................................................. 6
Figure 3: Diagramme de Gantt ................................................................................................... 7
Figure 5: Diagramme de cas d'utilisation global ...................................................................... 11
Figure 6: Diagramme de cas d'utilisation de l’administrateur.................................................. 12
Figure 7: Diagramme de cas d'utilisation du patient ................................................................ 13
Figure 8: Diagramme de cas d'utilisation du médecin ............................................................. 16
Figure 9: Diagramme de séquence prendre rendez-vous ......................................................... 17
Figure 10: Diagramme de séquence de recherche du médecin ................................................ 18
Figure 11: Diagramme de séquence de création du compte patient ......................................... 19
Figure 12: diagramme de séquence de l'administrateur ........................................................... 20
Figure 13: Diagramme de classes ............................................................................................. 22
Figure 14: Diagramme de déploiment ...................................................................................... 23
Figure 15: Schéma relationnel de la base de données .............................................................. 24
Figure 16: Pattern MVC ........................................................................................................... 26
Figure 17 : Les 3 nuances de bleu dans le logo ........................................................................ 27
Figure 18: Prototype d’interface d'accueil ............................................................................... 27
Figure 19: prototype d'interface d'inscription .......................................................................... 28
Figure 20: Logo du Framework Laravel .................................................................................. 31
Figure 21 : Logo Post Man ....................................................................................................... 34
Figure 22: Interface de connexion du patient ........................................................................... 36
Figure 23: interface carte et direction ...................................................................................... 37
Figure 24: Interface de chercher un médecin par spécialité ..................................................... 38
Figure 25: Profil médecin ......................................................................................................... 38
Figure 26: Processus de prise d’un rendez vous ...................................................................... 39
Figure 27: Message succès et erreur de rendez-vous ............................................................... 40
Figure 28: Interface liste des rendez-vous ................................................................................ 40
Figure 29 : Interface de connexion du médecin ....................................................................... 42
Figure 30: Interface calendrier des rendez-vous acceptés ........................................................ 43
Figure 31: Interface statistiques ............................................................................................... 43

iv
Figure 32: Profil médecin ......................................................................................................... 44
Figure 33: Profil d’un Patient ................................................................................................... 44
Figure 34: Interface fiche rendez-vous ..................................................................................... 46
Figure 35: interface de connexion administrateur .................................................................... 47
Figure 36: interface de gestion des médecins ........................................................................... 48
Figure 37: interface de gestion des spécialités ......................................................................... 48

v
 Liste des tableaux
Tableau 1: Liste des acteurs par application ............................................................................ 10
Tableau 2:Identification des acteurs et des cas d'utilisations ................................................... 10
Tableau 6: Description du cas d’utilisation Gestion des spécialités ........................................ 13
Tableau 3: description du cas d’utilisation de prise de rendez-vous ........................................ 14
Tableau 4: description du cas d’utilisationde recherche de médecin ....................................... 15
Tableau 5: description de cas de création du compte patient .................................................. 15
Tableau 7: Comparaison entre CMS et Framework ................................................................. 31

vi
 Introduction générale

E tant donné la forte croissance du marché du mobile et des applications mobiles,

aujourd’hui, le développement d’application mobile intéresse énormément d’utilisateurs
et il est reconnu dans la plupart des domaines y compris les domaines de la santé. En effet, les
logiciels et les applications mobiles dans le domaine de la santé connaissent actuellement un
essor important. Leurs utilisations se multiplient et ces produits peuvent être très variés.

C’est dans ce contexte, que s’intègre notre projet de fin d’étude effectué au sein de la société
HypaTech et qui consiste à réaliser un système de gestion des rendez-vous médicaux intitulé
«Allo Doctor».

Nous sommes appelé à concevoir, développer et intégrer un système incluant des interfaces
claires et faciles à utiliser afin de mettre en place une solution mobile pour rapprocher le
médecin de ses patients et faciliter le processus de prise des rendez-vous.

Ce rapport s’articule autour de trois chapitres comme suit :

- Une étude préalable qui nous permet de placer le projet dans son contexte général.
Nous présentons l'organisme d'accueil ainsi qu'une description du projet et une
spécification des besoins fonctionnels et non fonctionnels du système.

- Une étude conceptuelle où nous nous identifierons les acteurs du système et en se

basant sur le langage de modélisation UML nous présenterons les diagrammes
nécessaires.

- Un dernier chapitre, où nous présenterons les outils matériels et logiciels utilisés

pour l’implémentation de notre système, ainsi que les interfaces de certaines
fonctionnalités mises au point.

1
Chapitre 1 : Etude préalable

2
Chapitre 1: Etude préalable
Introduction

’étude d’un projet est une démarche stratégique qui va nous permettre d’avoir une
L vision globale sur ce dernier visant ainsi à bien organiser le bon déroulement du projet.

Cette étude fera donc l’objet du premier chapitre qui sera consacré à la présentation de
l’organisme d’accueil, la présentation du projet et la spécification des besoins fonctionnels et
non fonctionnels de notre système.

1.1 Étude de l’organisme d'accueil

HYPAtech a été fondée en 2015, situé à Djerba.

HypaTech est une société de conseil en organisation et en ingénierie des systèmes

d'information, qui a pour mission de bâtir des solutions Internet de qualité, en offrant des
conseils, des technologies et des services adéquats.

Chez HypaTech, chaque projet est analysé avec une attention particulière afin de développer
des sites fiables qui répondent aux besoins des clients

Figure 1: Logo du HypaTec

HYPAtech travaille dur pour atteindre sa réputation, et si elle travaille pour les petites ou les
grandes entreprises, elle applique les mêmes niveaux de pensée, de soins et d'attention aux
détails.

1.2 Présentation du projet

Etant donnée l'émergence de technologie mobile et le taux d’acquisition croissant des
Smartphones et tablettes chez le grand public, beaucoup d'applications ont été développées
dans divers domaines. Parmi ces domaines, nous trouvons les domaines de la santé.

Durant ce stage, il nous a été demandé de faire la conception et le développement d’une

application mobile qui permet de trouver un médecin en cas de besoin.

3
L’origine de ce sujet était une simple idée pour fournir des informations concises et
pertinentes sur les médecins en Tunisie facilement accessible en cas de besoin. Au fur et à
mesure cette idée a évolué pour concevoir un système de gestion des rendez-vous médicaux
constitué de trois applications :

- une application mobile permettant aux patients de chercher un médecin et d’avoir la

possibilité de le géo-localiser et même de prendre un rendez-vous.
- une application web ou les médecins peuvent gérer leurs rendez-vous, leurs dossiers
médicaux et leurs temps de travail.
- Une application desktop qui permet d’administrer et de gérer le système (les médecins,
les spécialités, etc…)

Ce type d’application métier s’avère très utile non seulement afin de subvenir aux besoins des
patients mais il peut aussi représenter un réel avantage pour les médecins. Il s’agit de
rapprocher le médecin de ses patients et de le rendre plus disponible et surtout accessible en
cas de besoin.

1.3 Spécification des besoins

1.3.1 Spécification des besoins fonctionnels

Dans cette partie nous détaillons l’ensemble des fonctionnalités que l’application doit offrir
aux utilisateurs.

En effet, le système à réaliser doit répondre aux besoins fonctionnels suivants :

a. Authentification
Chaque utilisateur (médecin, patient, administrateur), possède un login et un mot de
passe spécifique qui lui permet de vérifier son identité, afin d'autoriser l'accès de cette
entité à des ressources en toute sécurité.
b. Gestion des rendez-vous
Le patient a la possibilité de prendre un rendez-vous et il peut consulter l’état de sa
demande de rendez-vous (En attente, acceptée ou refusée), de plus le médecin peut
accepter ou refuser une demande de rendez-vous selon sa disponibilité.
c. Voir l’historique des rendez-vous
Le médecin peut consulter l’historique des demandes qu’il a acceptées et refusées.
d. Chercher un médecin par nom ou par spécialité
e. Localiser un médecin
f. Gestion des spécialités

4
 L’administrateur du système peut ajouter, modifier une spécialité.
g. Vérification du médecin
Un médecin doit envoyer une image de sa carte d’identité ou une autre pièce qui
vérifie qu’il est un médecin. L’administrateur vérifie cette pièce justificative avant de
valider le compte du médecin.

1.3.2 Spécification des besoins non fonctionnels

Les besoins non fonctionnels sont importants car ils agissent de façon indirecte sur le résultat
et sur la performance du système, ce qui fait qu’ils ne doivent pas être négligés, pour cela il
faut répondre aux exigences suivantes :

- Le système doit être sécurisé au niveau des données : authentification et contrôle des
droits d’accès.
Pour cela nous utiliserons le jeton de sécurité web (Json Web Token ou tout
simplement JWT) qui est un standard pour échanger de l'information de manière
sécurisée via un jeton signé. Par exemple un serveur pourrait émettre un jeton
possédant l'affirmation "utilisateur identifié en tant qu'administrateur" et le fournir au
client. Le client pourrait alors vérifier le jeton pour prouver que l'utilisateur est
identifié en tant qu'administrateur.
Le jeton JWT est composé de trois parties :
 Un entête : indique quel algorithme a été utilisé pour générer la signature
 L’information : variable en fonction de l'application
 Une signature : comprend une clé, un jeton et la signature effective

5
 Figure 2: Fonctionnement du JWT

- Le système doit permettre l’accomplissement des tâches avec le minimum des

manipulations.
- Ergonomie et une Interface Homme Machine conviviale.
- Le système doit signaler tous les messages d’erreur.

1.4 Planification de projet

Pour la planification de projet nous avons eu recours au diagramme de Gantt afin d’illustrer
le déroulement du projet.

Ce diagramme présente les tâches à faire pendant la période de stage, avec des durées
d’accomplissements approximatives.

6
 Figure 3: Diagramme de Gantt

Conclusion
Dans ce chapitre, nous avons présenté le cadre général de notre projet et nous avons exposé
l’analyse et la spécification des besoins permettant de concevoir et de développer un système
qui facilitera la gestion des rendez-vous médicaux. Après avoir fixé nos objectifs, l’étape
suivante sera consacrée à une conception détaillée.

7
Chapitre 2 : Etude conceptuelle

8
Chapitre 2: Etude conceptuelle
Introduction

D ans ce chapitre nous commençons par une présentation des différents outils logiciels
et les langages de modélisations utilisés. Ensuite nous détaillons les diagrammes des
cas d’utilisation, les diagrammes des classes et les diagrammes de séquences.

2.1 Méthodes et outils de modélisation

2.1.1 Langage de modélisation (UML)

Pour la conception de notre système nous avons adopté une méthode orientée objet. En effet
cette dernière est une approche incontournable dans le cadre du développement des
applications.

Pour mieux présenter l’architecture de notre système, on va choisir le langage de modélisation

le plus adopté UML:

C'est un langage de modélisation, défini comme une norme de modélisation objet qui sert à
décrire et à documenter un système d'information.

En utilisant ce langage, les objectifs de la modélisation objet suivant sont assurés :

 Formaliser la conception d’application.

 Faciliter la communication entre les différents intervenants au sein d’un projet
informatique.
 Coordonner les activités entre les différents intervenants.
 Gérer l’évolution d’un projet informatique.
 Proposer des outils standardisés prenant en compte de nombreux aspects de la
conception. [1]

2.1.2 L’outil de modélisation

StarUML est un logiciel de modélisation UML, cédé comme open source par son éditeur, à la
fin de son exploitation commerciale, sous une licence modifiée de GNU GPL.

StarUML gère la plupart des diagrammes spécifiés dans la norme UML 2.0, il est écrit
en Delphi, et dépend de composants Delphi propriétaires.

9
2.2 Identification des acteurs et des cas d’utilisation
Les acteurs sont les entités externes qui interagissent directement avec le système et
communiquent avec ce dernier par émission et réception de messages

Notre système présente trois parties : une application web, une application mobile et une
application desktop. Chaque application concerne un acteur :

Application Acteur
Web Médecin
Mobile Patient
Desktop Administrateur
Tableau 1: Liste des acteurs par application

Les acteurs et les cas d’utilisation sont résumés dans le tableau suivant :

Cas d’utilisation Acteur(s)

Gérer les rendez-vous
Consulter les statistiques
Gérer l’horaire de travail Médecin
Gérer les dossiers patients
Uploader CIN
Chercher médecin
Consulter l’historique des rendez-vous
Patient
Prendre un rendez-vous
Consulter l’état des RDV
Gérer les spécialités
Administrateur
Vérifier les médecins
Gérer le profil Médecin, Patient
Tableau 2:Identification des acteurs et des cas d'utilisations

2.3 Diagrammes de cas d’utilisation

2.3.1 Diagramme de cas d’utilisation global

Un diagramme de cas d’utilisation est un graphe d’acteurs, un ensemble de cas d’utilisation
englobés par la limite du système, des relations de communication entre les acteurs et les cas
d’utilisation, et des généralisations de ces cas d’utilisation.

10
Ce diagramme présente le système entier avec ses trois applications, chaque application a ses
propres cas d’utilisation et son propre acteur comme présenter dans le diagramme ci-dessous.

Figure 4: Diagramme de cas d'utilisation global

2.3.2 Diagramme de cas d’utilisation de l’administrateur

L’administrateur du système peut gérer les spécialités, en ajoutant une nouvelle spécialité
ou/et en modifiant une qui existe déjà.

De plus l’administrateur est le seul qui a le droit d’accepter ou rejeter un médecin.

En effet, après la vérification de la carte d’identité envoyée par le médecin, l’administrateur a

la possibilité de valider ou bien de refuser l’inscription de ce dernier.

11
 Figure 5: Diagramme de cas d'utilisation de l’administrateur

2.3.2.1 Description du cas d’utilisation gestion des spécialités

Cas d’utilisation Gestion des spécialités
L’administrateur peut gérer les spécialités qui existent dans le système :
Résumé
il peut ajouter ou modifier une spécialité.
Acteurs Administrateur
1.1. L’administrateur saisie le nom de spécialité
1.2. Le système vérifie l’information saisie
1.3. Le système enregistre la spécialité
1.4. L’administrateur reçoit un message de succès
Scénario nominale
2.1 L’administrateur choisie une spécialité
2.2 L’administrateur change le nom de la spécialité
2.3 Le système enregistre le nouveau nom
2.4 L’administrateur reçoit un message de succès
Scénario d’erreur 1.1.1. L’administrateur saisie un nom d’une spécialité existante
1.1.2. L’administrateur ne saisit rien
2.1. L’administrateur ne choisit aucune spécialité
2.2. L’administrateur saisie un nom d’une spécialité existante

12
Pré-condition Administrateur authentifié
Post condition - Spécialité ajouté
- Spécialité mis à jour
Tableau 3: Description du cas d’utilisation Gestion des spécialités

2.3.3 Diagramme de cas d'utilisation du patient

Figure 6: Diagramme de cas d'utilisation du patient

Le patient est l’utilisateur de l’application mobile, Pour pouvoir accéder aux différentes
fonctionnalités de l’application, le patient doit se connecter s’il possède déjà un compte, sinon
il doit créer un compte.

Un patient peut chercher un médecin directement à partir de la carte où chaque médecin

enregistré dans le système a un marqueur, de plus il peut chercher un médecin par son nom
ou par sa spécialité.

Une fois le médecin a été sélectionné, le patient peut prendre un rendez-vous selon la
disponibilité du médecin.

13
Après avoir pris un rendez-vous, le patient peut consulter la liste de ses rendez-vous
(acceptés, refusés et en attente). Tant que le rendez-vous est encore en attente, le patient a la
possibilité de l’annuler.

Le patient peut aussi changer les informations de son compte.

Si un rendez-vous a été accepté par le médecin et le patient rate la consultation plusieurs fois
son compte sera supprimé.

2.3.3.1 Description du cas d’utilisation de prise de rendez-vous

Cas d’utilisation prendre rendez-vous

Ce cas permet au patient de prendre un rendez-vous avec un
Résumé
médecin
Acteurs Patient
Scénario nominale 1. Le patient sélectionne la date du rendez-vous
2. Le patient sélectionne l’heure du rendez-vous
3. Le système vérifie la disponibilité du médecin
4. Le rendez-vous est enregistré dans la base de données
Scénario d’erreur 1. Le patient décide de quitter l’interface de sélection de la
date
2. Le patient décide de quitter l’interface de sélection de
l’heure
3. La date ne correspond pas à la disponibilité du médecin
Pré-condition Choisir un médecin
Etre authentifié
Post condition Le rendez-vous enregistré
Tableau 4: description du cas d’utilisation de prise de rendez-vous

2.3.3.2 Description du cas d’utilisation de recherche de médecin

Cas d’utilisations Chercher un médecin
Résumé Ce cas permet au patient de chercher un médecin
Acteurs Patient
1.1.1 Le patient choisit un médecin sur la carte
1.1.2. Le système affiche le profil du médecin
Scénario nominale
1.2.1. Le patient choisit une spécialité
1.2.2. Le système cherche tous les médecins avec la spécialité choisie

14
 1.2.3. Le patient choisit un médecin de la liste
1.2.4. Le système affiche le profil du médecin sélectionné
1.3.1. Le patient saisit le nom du médecin
1.3.2. Le système cherche tous les médecins avec ce nom
1.3.3. Le patient choisit un médecin de la liste
1.4.4. Le système affiche le profil du médecin
Scénario d’erreur 1.2.1. Le patient ne choisit aucune spécialité
1.2.3. Le patient ne choisit aucun médecin
1.3.1.1. Le patient saisie un nom erroné
1.3.1.2. Le patient ne saisit aucun nom
1.3.3. Le patient ne choisit aucun médecin
Pré-condition Patient authentifié
Post condition Profil de médecin affiché
Tableau 5: description du cas d’utilisationde recherche de médecin

2.3.3.3 Description du cas d’utilisation de création du compte patient

Cas d’utilisation Création du compte patient (application android)
Résumé Ce cas permet au patient de créer un compte
Acteurs Patient
1. Le patient saisie les données
2. Le système reçoit les données saisies
3. Si le données sont valides un jeton de sécurité sera crée
Scénario nominale
4. Le système enregistre les informations dans la base de données
5. Le système envoie le jeton de sécurité au patient
6. Le patient sera redirigé à l’interface d’accueil
Scénario d’erreur 2. Le patient saisit des données erronées
5. Le système envoie un message d’erreur au patient
6. Le patient sera redirigé à l’interface de création du compte
Pré-condition -
Post condition Compte crée
Tableau 6: description de cas de création du compte patient

15
2.3.4 Diagramme de cas d'utilisation du médecin

Figure 7: Diagramme de cas d'utilisation du médecin

Le médecin dans le système peut gérer ses disponibilités, il peut ajouter ou modifier ses jours
et heure de travail.

De plus, le médecin peut accepter ou refuser un rendez-vous.

Si un rendez-vous est accepté, le médecin peut gérer le dossier du patient: il peut ajouter une
ordonnance, ajouter une observation ou télécharger une fiche médicale.

Le médecin peut aussi consulter les statistiques des rendez-vous.

16
2.4 Etude de quelques diagrammes des séquences

2.4.1 Diagramme de séquence de prise de rendez-vous

Figure 8: Diagramme de séquence prendre rendez-vous

Pour prendre un rendez-vous, le patient sélectionne la date et l’heure du rendez-vous souhaité.

Après la vérification de la disponibilité du médecin, le rendez-vous est enregistré dans la base
de données et un message de confirmation s’affiche au patient. Si la date et/ou l’heure
sélectionnée ne correspondent pas à la disponibilité du médecin, le système envoie un
message d’erreur au patient pour lui informer que son rendez-vous n’a pas été enregistré et lui
demande de choisir une autre date.

17
2.4.2 Diagramme de séquence de recherche du médecin

Figure 9: Diagramme de séquence de recherche du médecin

Le patient peut chercher un médecin par son nom, sa spécialité ou par sa localisation sur la
carte.
La localisation des médecins sur la carte est disponible en deux modes : terrain et satellite.
Le patient peut choisir celui qui lui convient le mieux, c’est une fonctionnalité gérée par l’API
de Google adaptée pour un usage facile et rapide.
Le patient peut choisir un médecin directement en cliquant sur son marqueur sur la carte.
Pour chercher un médecin par spécialité, il suffit de choisir une des spécialités existante dans
la base de données et le système affiche la liste des médecins de cette spécialité.
En plus, le patient a la possibilité de chercher un médecin par son nom. Pour cela, il suffit de
saisir un nom et le système affiche la liste des médecins avec ce nom.

18
2.4.3 Diagramme de séquence de création du compte patient

Figure 10: Diagramme de séquence de création du compte patient

Pour accéder à l’application, le patient doit avoir un compte.

Pour crée un compte, le patient doit saisir les informations demandées correctement puis le
système vérifie ces informations et si n’a pas des erreurs le compte sera créé et les
informations seront enregistrées dans la base de données.

19
2.4.4 Diagramme de séquence de l’administrateur

Figure 11: diagramme de séquence de l'administrateur

20
Une fois authentifié, l’administrateur a le droit de gérer les spécialités :

- Il peut consulter la liste de toutes les spécialités existantes dans la base de données
- Il peut ajouter une nouvelle spécialité
- Il peut modifier une spécialité qui existe déjà.

De plus, l’administrateur peut consulter la liste des médecins. Si le compte du médecin est
inactif, il vérifie la copie de la carte d’identité nationale envoyée par ce dernier. Suite à cette
vérification, il peut soit activer le compte du médecin soit annuler son inscription.

L’administrateur de système peut changer son mot de passe.

2.5 Diagramme de classes

Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les classes et
les interfaces des systèmes ainsi que les différentes relations entre celles-ci. Ce diagramme
fait partie de la partie statique d'UML car il fait abstraction des aspects temporels et
dynamiques.

Dans notre diagramme de classes on a trois classes (administrateur, médecin et patient) qui
hérite d’une classe mère nommé utilisateur.

Un patient peut prendre un rendez-vous avec un médecin, et ce dernier peut accepter ou

refuser le rendez-vous selon son horaires de travail, si le rendez-vous est accepté il faut avoir
un dossier patient qui contient les observations et les ordonnances de rendez-vous.

Un médecin admet une spécialité gérée par l’administrateur du système.

L’administrateur valide le compte d’un médecin après la vérification de son carte d’identité
nationale.

21
 Figure 12: Diagramme de classes

2.6 Diagramme de déploiement

Un diagramme de déploiement est une vue statique qui sert à représenter l'utilisation de
l'infrastructure physique par le système et la manière dont les composants du système sont
répartis ainsi que leurs relations entre eux.

Notre système contient cinq nœuds :

- Le serveur web qui contient laravel.

- Un serveur de base de données contient le système de gestion des bases de données
MySQL.
- Une application android.
- Une application desktop.

22
- Une machine client dans laquelle le médecin peut accéder à son espace de travail via
un navigateur web.

Figure 13: Diagramme de déploiment

23
2.7 Schéma de la base de données
Nous avons utilisé le système de gestion de base de données relationnel MySQL pour
enregistrer les tables de notre système.

Nous avons choisi ce SGBD vu qu’il est très léger et simple à utiliser et configurer, de plus il
est open source et tous les hébergeurs web le fournie avec leur packs d’hébergement.

La figure ci-dessous montre les relations entre les différentes tables de notre système.

Figure 14: Schéma relationnel de la base de données

2.8 Conception architecturale

Le pattern modèle-vue-contrôleur(en abrégé MVC, de l'anglais model-view-controller), est un
modèle destiné à répondre aux besoins des applications interactives en séparant les
problématiques liées aux différents composants au sein de leur architecture respective.

Ses avantages :

24
  Séparation des compétences (design, base de données, application)
 Simplicité de mise à jour
 Vitesse de création de pages.

Ce paradigme regroupe les fonctions nécessaires en trois catégories :

 Un modèle (Modèle de données) ;

 Une vue (présentation, interface utilisateur) ;
 Un contrôleur (logique de contrôle, gestion des événements, synchronisation).

Nous expliquons ces trois parties l'une après l'autre :

a. Le modèle (ou Model) :

Le modèle représente les structures de données. Typiquement, les classes modèles contiennent
des fonctions qui aident à récupérer, à insérer et à mettre à jour des informations de la base de
données.

Par exemple, lorsque nous disons« le contrôleur récupère les données d’un outil», il va en fait,
faire appel au modèle Outil (« Tool »). C'est le modèle qui peut récupérer les données de cet
outil, généralement via une requête au serveur SQL. Au final, il permet au contrôleur de
manipuler les outils mais sans savoir comment ils sont stockés, gérés, etc. C'est une couche
d'abstraction.

b. La vue (ou View) :

La vue correspond à l'interface avec laquelle l'utilisateur interagit. Elle se présente sous la
forme d'une Template représentant l'interface.

Reprenons l'exemple de l’outil. Ce n'est pas le contrôleur qui affiche le formulaire, il ne fait
qu'appeler la bonne vue. Si nous avons une vue formulaire, les balises HTML du formulaire
d'édition de l’outil y seront et finalement le contrôleur ne fera qu'afficher cette vue sans savoir
vraiment ce qu'il y a dedans.

Donc en pratique, c'est le « designer » d'un projet qui travaille sur les vues. La séparation de
vues et contrôleurs permet aux designers et aux développeurs PHP de travailler ensemble sans
besoin de contact direct.

c. Le contrôleur (ou Controller) :

Il gère l'interface entre le modèle et le client. Il va interpréter la requête de ce dernier pour lui
envoyer la vue correspondante. Il effectue la synchronisation entre le modèle et les vues.

25
Il est la couche qui se charge d'analyser et de traiter la requête de l'utilisateur. Le contrôleur
contient la logique de notre application et va se contenter « d'utiliser » les autres composants :
les modèles et les vues. Concrètement, un contrôleur va récupérer, par exemple, les
informations sur l'utilisateur courant, vérifier qu'il a le droit de modifier un tel outil, récupérer
les données de cet outil et demander la page du formulaire d'édition de l’outil. [2]

Figure 15: Pattern MVC

2.9 Charte graphique

2.9.1 Le logotype

2.9.1.1 Les données colo-métriques :

• Le logotype apparaît toujours avec le texte, qui se compose du nom « Allo Doc»
(référence typo :Rakoon Medium ).

• Le logotype se compose de 3 couleurs et une valeur, il se compose de trois nuances de

colure bleu.

26
 Figure 16 : Les 3 nuances de bleu dans le logo

Le bleu symbolise la relaxation, la confiance, la fiabilité, la satisfaction, le calme, la

passivité, la propreté c’est pour quoi on a utilisé ce colleur pour notre logo.

2.9.1.2 Les formes

LE CERCLE, SYMBOLE PERFECTION ET CRÉATIVITÉ

Le cercle est également un symbole de perfection et de créativité. Ses formes arrondies

évoquent la plénitude, le calme. Elles se veulent plus rassurantes que les formes anguleuses
d'un carré ou d'un triangle.

2.10 Prototypes d’interface

Dans cette section nous listons quelques prototypes d’interfaces de notre système.

Figure 17: Prototype d’interface d'accueil

La figure ci-dessus montre le prototype d’interface d’accueil de l’application du médecin.

Dans cette interface nous trouvons un calendrier qui contient les rendez-vous acceptés et des
liens vers la page de statistiques et la page de gestion des rendez-vous.

27
La figure ci-dessous montre le prototype du page d’inscription dans l’application web, cette
interface est très importante car elle est la première interaction du médecin avec notre
système, alors nous choisissons une interface très simple qui contient quelques champs de
texte à remplir par des informations du médecin comme son nom, son prénom, son email, son
mot de passe, sa prix de visite …

Cette interface doit être anti-spam alors nous aurons mis un système de vérification de type
Récaptcha pour éliminer les inscriptions des rebout.

Pour compléter l’inscription, le médecin doit accepter les termes d’utilisation du système.

Figure 18: prototype d'interface d'inscription

Conclusion
Dans ce chapitre, nous avons pu concevoir un système de gestion des rendez-vous médicaux
en se basant sur les diagrammes du langage UML à savoir le diagramme de cas d'utilisation,
le diagramme de séquences et le diagramme de classes .

Le prochain chapitre sera dédié à la réalisation de notre application.

28
Chapitre 3: Réalisation

29
 Chapitre 3: Réalisation
Introduction
e chapitre représente le dernier volet de ce rapport, il sera consacré à l’implémentation

C de notre système. Nous commençons par la présentation des ressources matérielles

et logicielles utilisées. Nous passons ensuite à présenter des captures d’écran dans le
but de mettre en évidence l’aspect ergonomique et fonctionnel des interfaces développées.

3.1 Architecture du système et environnement de test

3.1.1 Pourquoi utiliser un Framework ?

Un framework est un ensemble d'outils et de composants logiciels organisés conformément à
un plan d'architecture et des patterns, l'ensemble formant ou promouvant un « squelette » de
programme. Il est souvent fourni sous la forme d'une bibliothèque logicielle, et accompagné
du plan de l'architecture cible du framework.

Les avantages des frameworks sont nombreux. En effet,, un Framework est portable, de la
part de son abstraction de la base de données et de la gestion générique du cache. Les temps
de développement avec un Framework sont réellement plus courts. Tous les outils essentiels
sont déjà écrits. Le développement des applications sécurisées est facile.grâce aux systèmes
d'authentification, à la gestion des injections SQL ainsi qu'à la protection CSRF (Cross-Site
Request Forgery) qui est gérée par la plupart des Framework. Les Framework sont des outils
communautaires et ont, par conséquent, des forums, des listes de diffusion et des canaux IRC
pour les soutenir. De plus vu que les framework sont largement déployés, la chance de
trouver les correctifs des problèmes rencontrés est plus grande.

Utiliser le langage PHP et passer par le modèle MVC signifie l’utilisation des outils convenables pour
bien respecter ce modèle et bien mener nos travaux de développement. Les solutions
proposées sur ce domaine sont les frameworks et les CMS. Dans cette partie, nous allons mener
une étude comparative pour bien choisir la solution qui répondra le plus à nos exigences et nos
attentes.

CMS Framework
Coût Réduit pour les projets personnels Elevé
Compatible avec Les projets personnels essentiellement Tous les projets

30
 Des fonctionnalités superflues pour les Des APIs importantes un
Fonctionnalité
projets professionnels peu compliqués
Importante pour quelques CMS Importante pour la
Communauté
plupart des Framework
Extensibilité Très Difficile de l’étendre Toujours extensible
Tableau 7: Comparaison entre CMS et Framework

En prenant en considération l’étude comparative qu’on a élaborée, nous déduisons que les
Framework sont la solution la plus apte pour notre application en matière d’extensibilité et
l’importance de leurs communautés, ainsi que la nature de projet à réaliser.

3.1.2 Le Framework Laravel

3.1.2.1 Définition
Laravel est un Framework web gratuit, open-source, créé par Taylor Otwell et destiné au
développement d'applications Web suivant le modèle-vue-contrôleur (MVC). Certaines des
caractéristiques de Laravel sont un système modulaire système d'emballage avec un
gestionnaire de dépendances dédié, pour accéder à différentes façons de bases de données
relationnelles, les services publics que l'aide au déploiement d'applications et de maintenance,
et son orientation vers le sucre syntaxique

En Mars 2015, Laravel est considéré comme l’une des plus populaires Framework PHP.

Le code source de Laravel est hébergé sur Git Hub sous licence conformément aux termes de
licence MIT. [3]

Figure 19: Logo du Framework Laravel

3.1.2.2 Structure du répertoire

 Répertoire App
Contient le code de base de l’application.
Le répertoire App contient une variété de répertoires supplémentaires tels que
Console, http qui contient les contrôleurs et Providers et les modelés d’application.
 Répertoire Bootstrap

31
 Contient des fichiers d’auto loading.
 Répertoire Config
Comme son nom l'indique, contient tous les fichiers de configuration de l’application.
 Répertoire data base
Contient la migration de la base de données.
 Répertoire public
Contient le fichier, ce qui est le point d'entrée pour toutes les demandes entrant dans
l’application. Ce répertoire contient également les images, JavaScript et CSS.
 Répertoire Routes
Contient toutes les définitions de route pour l’application. Par défaut, plusieurs fichiers
d'itinéraire sont inclus avec Laravel:
- web.php
- api.php
- console.php

3.2 Environnement de développement

Pour mettre en place notre système, nous avons utilisé un environnement de
développement qui a assuré le bon déroulement de la phase implémentation. Cet
environnement comporte des outils matériels ainsi que logiciels.

3.2.1 Environnement matériel

Pour le développement de notre application nous avons utilisé un PC portable «
DELL inspiron 15 » dont la configuration est la suivante :

 Processeur Intel Core i7-3537U avec fréquence 2.5 GHz

 Quantité de mémoire vive 8 Go
 Capacité du disque dur 1 To

De plus, pour tester notre application, nous avons utilisé un Smartphone Samsung galaxy g3
SM-J320f dont la configuration est :

 Version android 5.1.1

 Ram 1.5 Go
 Processeur quad-core 1.5GHz Cortex A7

32
3.2.2 Environnement logiciel

3.2.2.1 Application Web

a. PHP Storm:

PhpStorm est un éditeur pour PHP, HTML et JavaScript, édité par l’entreprise informatique
JetBrains.

Il soutient PHP 5.3, 5.4 et 5.5 pour des projets modernes et anciens. L'IDE fournit les
meilleurs codes auto-complétion, sur la volée de prévention d'erreur, soutient le mélange de
langues et plus. Il traite automatiquement le code avec précaution, pour aider les développeurs
à effectuer des changements globaux du projet facilement et en toute sécurité.

b. Bootstrap:

Bootstrap est un Framework qui facilite et accélère le développement Front-End. Il inclue une
base CSS très complète (au format LESS) configurée à partir d’un fichier de variables, un
ensemble de conventions de structure HTML et de nommage de classes des librairies
JavaScripts simples pour les fonctions les plus courantes.

c. Blade:

Blade est le moteur de modélisation simple, mais puissant. Contrairement à d'autres moteurs
de modèles PHP populaires, Blade n’empêche pas l'utilisation du code PHP simple dans les
vues. En fait, toutes les vues de Blade sont compilées en code PHP ordinaire et mises en
cache jusqu'à ce qu'elles soient modifiées, ce qui signifie que Blade ajoute une surcharge de
zéro à l’application. Les fichiers de vue Blade utilisent l'extension « .blade.php » et sont
généralement stockés dans le répertoire ressources/vies.

d. Eloquent:

L’ORM Eloquent fournit une simple implémentation Active Record pour travailler avec la
base de données. Chaque table de base de données a un "Modèle" correspondant qui est utilisé
pour interagir avec cette table. Les modèles les permettent de demander des données dans les
tableaux, ainsi que d'insérer de nouveaux enregistrements dans la table.

e. Postman:

Postman est une application permettant avec un navigateur Web de lancer des appels d’API et
de les tester.

33
Postman permet d’envoyer des requêtes vers l’API de site en lui ajoutant des en-têtes clés /
valeurs puis il permet de formater le résultat sur plusieurs formats tels que JSON, XML,
HTML et autres.

Figure 20 : Logo Post Man

f. MySQL:

MySQL est un système de gestion de base de données relationnelle (SGBDR). Il est distribué
sous une double licence GPL et propriétaire. Il fait partie des logiciels de gestion de base de
données les plus utilisés au monde, autant par le grand public (applications web
principalement) que par des professionnels, en concurrence avec Oracle et Microsoft SQL
Server. [4]

g. JQuery:

jQuery est une bibliothèque JavaScript libre développée initialement par John Régis et
qui est aujourd'hui maintenue et mise à jour par la communauté jQuery Team. Le
Framework JavaScript jQuery code rapidement et simplement des traitements à base de
code JavaScript pour dynamiser et améliorer l'ergonomie des sites internet.

3.2.2.2 Application Desktop

a. Microsoft Visual Studio :

Visual Studio est un ensemble complet d'outils de développement permettant de générer des
applications web ASP.NET, des services web XML, des applications bureautiques et des
applications mobiles. Visual Basic, Visual C++, Visual C# utilisent tous le même
environnement de développement intégré (IDE), qui leur permet de partager des outils et
facilite la création de solutions faisant appel à plusieurs langages. Par ailleurs, ces langages
permettent de mieux tirer parti des fonctionnalités du framework .NET, qui fournit un accès à
des technologies clés simplifiant le développement d'applications web ASP et de services web
XML grâce à Visual Web Developer. [5]

34
Nous utilisons le langage c# pour l’application desktop, C# est un langage de programmation
orienté objet, commercialisé par Microsoft depuis 2002 et destiné à développer sur la
plateforme Microsoft .NET.

3.2.2.3 Application mobile

a. Android studio :

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

Android. Il permet principalement d'éditer les fichiers JAVA et les fichiers de configuration
d'une application Android. Il propose entre autres des outils pour gérer le développement
d'applications multilingues et permet de visualiser la mise en page des écrans sur des écrans
de résolutions variées simultanément.

b. Java :

C’est un langage de programmation informatique orientée Objet. La particularité et l'objectif

central de Java est que les logiciels écrits dans ce langage doivent être très facilement
portables sur plusieurs systèmes.

35
3.3 Description des interfaces réalisées

3.3.1 Application android

3.3.1.1 Interface d’authentification

Figure 21: Interface de connexion du patient

L’interface d’authentification est une des interfaces les plus importantes dans l’application
android, car chaque patient doit être enregistré dans notre système pour qu’il puisse profiter
des fonctionnalités de notre application.

A travers cette interface le patient donne son email et son mot de passe. Si cette combinaison
correspond aux informations qui existent dans la base de données, l’application le redirige
vers l’interface de recherche des médecins sinon un message d’erreur apparait.

L’authentification reste active pendant deux semaines: durant cette période le patient n’est pas
obligé de saisir ses données d’authentification à chaque utilisation de l’application sauf s’il
choisit de se déconnecter.

36
3.3.1.2 Interface de recherche d’un médecin dans la carte

Figure 22: interface carte et direction

La localisation d’un médecin (coordonnées GPS) sur la carte représentée par la figure 23 est
affichée en mode terrain au moment du chargement de l’interface. Néanmoins, l’utilisateur a
la possibilité de changer le mode satellite et choisir le mode qui lui convient.

Si le patient clique sur un marqueur relatif à un médecin, l’application affiche le nom du

médecin et dessine le plus court chemin entre la position actuelle du patient (déterminée par
GPS) et la position du médecin.

A travers cette interface de recherche d’un médecin, l’utilisateur a la possibilité de chercher

un médecin par nom ou par spécialité comme le montre la figure suivante :

37
 Figure 23: Interface de chercher un médecin par spécialité

3.3.1.3 Interface profil d’un médecin et processus de prise d’un rendez-vous

Figure 24: Profil médecin

Cette interface s’affiche dans deux cas :

38
  Si le patient clique sur le marqueur d’un médecin
 Si le patient choisit un médecin après une recherche par spécialité ou par nom

Dans cette interface le patient trouve les informations relatives à un médecin : biographie,
email et numéro de téléphone.

L’application permet d’appeler automatiquement le médecin et ceci suite à un clic sur le

numéro de téléphone du médecin.

De plus, le patient a la possibilité de prendre un rendez-vous en cliquant sur l’icône

Ensuite, il faut préciser l’heure et la date du rendez-vous souhaité comme le montre la figure
suivante.

Figure 25: Processus de prise d’un rendez vous

Après avoir sélectionné la date et l’heure du rendez-vous, le patient reçoit un message qui lui
informe si sa demande de rendez-vous a été enregistrée ou pas.

39
 Figure 26: Message succès et erreur de rendez-vous

Si le rendez-vous sélectionné ne correspond pas aux horaires de travail du médecin, un

message d’erreur s’affiche, sinon il sera enregistré dans la liste des rendez-vous en attente et
c’est le médecin qui doit le valider.

3.3.1.4 Interface de liste des rendez-vous

Figure 27: Interface liste des rendez-vous

40
Dans cette interface le patient peut trouver la liste de tous ses rendez-vous classés par état :

Une première liste contient les rendez-vous en attente que le patient a la possibilité de les
annuler.

Une deuxième liste contient les rendez-vous acceptés par le médecin et une troisième liste
contient les rendez-vous refusés.

41
3.3.2 Application Web

3.3.2.1 Interface d’authentification

Figure 28 : Interface de connexion du médecin

Pour accéder à son espace de travail, le médecin doit s’authentifier et son compte doit être
actif (un email d’activation est envoyé au médecin après l’inscription contient le lien et le
code d’activation du médecin).

Si le compte n’existe pas ou s’il est inactif, un message d’erreur apparait, sinon, le médecin
sera redirigé à son espace de travail.

42
3.3.2.2 Interface calendrier des rendez-vous
Dans cette interface le médecin trouve la liste de tous les rendez-vous acceptés dans un
calendrier.
Le calendrier peut être affiché par mois, par semaine et même par jour.

Figure 29: Interface calendrier des rendez-vous acceptés

3.3.2.3 Interface statistiques

Dans cette interface, le médecin peut consulter les statistiques des rendez-vous.

Il peut choisir entre consulter les statistiques de l’année courante qui affiche le taux des
rendez-vous acceptés et refusés par mois ou il peut préciser une année pour consulter les
rendez-vous de cette année.

Figure 30: Interface statistiques

43
3.3.2.4 Interface profil médecin
Cette interface présente le profil du médecin, dans laquelle le médecin peut trouver tous ses
coordonnées.

A partir de cette interface le médecin peut changer sa biographie, ses photo de profil, sa
position sur la carte et ses jours de travail.

Figure 31: Profil médecin

3.3.2.5 Interface profil patient

Dans cette interface le médecin peut trouver toutes les informations relatives à un patient.

Figure 32: Profil d’un Patient

44
3.3.2.6 Interface fiche rendez-vous
Pour chaque patient, un dossier médical sera créé.

Si un rendez-vous est accepté, le médecin peut créer une fiche de rendez-vous le jour de la
consultation. A travers cette fiche, il peut :

- ajouter une observation,

- ajouter une ordonnance (à l’aide d’une liste des médicaments),
- imprimer l’ordonnance sous format PDF,
- télécharger un fichier médical (image, scanner, etc…) dans le dossier du
patient.

45
 Figure 33: Interface fiche rendez-vous

3.3.3 Application desktop

Comme dans l’application android, dans l’application du bureau on a utilisé le ‘Material
design’1 pour garder la même charte graphique (nuance du bleu et du blanc).

1
Le Material Design est un ensemble de règles de design proposées par Google et qui s'appliquent à l'interface
graphique des logiciels et applications

46
3.3.3.1 Interface d’authentification

Figure 34: interface de connexion administrateur

A partir de l’interface d’authentification, l’administrateur peut accéder à notre application

desktop. Pour se faire l’administrateur introduit son email et son mot de passe.

3.3.3.2 Interface de vérification des médecins

Pour qu’un médecin soit visible sur la carte (dans l’application android du patient), il doit
envoyer une copie de sa carte d'identité nationale.

Dans ce cas, l’administrateur doit vérifier l’image envoyée par le médecin avant d’activer son
compte en cliquant sur le check box comme le montre la figure suivante.

47
 Figure 35: interface de gestion des médecins

3.3.3.3 Interface de gestion des spécialités

L’administrateur est le seul responsable d’ajout et de modification des spécialités.

A partir de l’interface de gestion des spécialités, l’administrateur peut consulter la liste de

toutes les spécialités qui existent dans la base de données, comme il peut ajouter une nouvelle
spécialité ou encore modifier une spécialité existante.

Figure 36: interface de gestion des spécialités

48
Conclusion
Au cours de ce chapitre, nous avons décrit les plateformes matérielles et logicielles sur
lesquelles nous avons développé notre système. Nous avons ensuite présenté les trois
applications de notre système de gestion des rendez-vous médicaux à travers quelques
interfaces que nous avons développées.

49
 Conclusion Générale

e projet de fin d’études, réalisé au sein de la société HypaTech, a pour objectif de

C réaliser un système de gestion des rendez-vous médicaux "AlloDoctor" permettant d’une
part aux patients de chercher un médecin et prendre un rendez-vous en utilisant leurs
Smartphones, et d’autre part aux médecins de gérer les rendez-vous et les dossiers des
patients.

De ce fait, notre système engloba plusieurs médecins de différentes spécialités exerçant en

Tunisie. Cela nous a permis de mettre à la disposition des utilisateurs une riche base de
données de médecins qu'ils puissent y avoir recours en cas de besoin.

La réalisation de ce travail a passé par trois phases essentielles. En premier lieu, nous avons
effectué une étude préalable qui nous a permis d’identifier les besoins de notre application.
En deuxième lieu, nous avons entamé la partie conception. Enfin, nous avons présenté les
outils de développement adoptés et les résultats obtenus.

Finalement, notre application peut être améliorée et enrichie par de nouvelles fonctionnalités.

50
 Bibliographie

[1] https://openclassrooms.com/courses/debutez-l-analyse-logicielle-avec-uml/uml-c-est-quoi

[2]https://book.cakephp.org/2.0/fr/cakephp-overview/understanding-model-view-
controller.html

[3] https://laravel.com/docs/5.4

[4] https://www.oracle.com/fr/mysql/index.html

[5] https://fr.wikipedia.org/wiki/Microsoft_Visual_Studio

51