RPP Finaleaaa

République Tunisienne Département
Ministère de l’enseignement supérieur et Multimédia & Web

de la recherche scientifique Année Universitaire 2022-2023
Université de Gabès
Institut Supérieur d’Informatique et de
Multimédia de Gabès
RAPPORT DE PROJET FIN D’ETUDE

Présenté en vue de l’obtention du
DIPLÔME DE LICENCE EN SCIENCE DE L’INFORMATIQUE
ET MULTIMÉDIA
Intitulé
Plateforme de Gestion interne de Clinique
Réalisé par :
Chamseddine Nacer
Au sein de : SotuDev
Soutenu le 24 Juin 2022 devant le jury composé de :
Président :
Rapporteur :
Encadrant Interne : M. Riadh Ouali ISIMG
Encadrant Externe : M. Ramzi Houidi SOTUDEV

CHAPITRE 2 ÉTUDE PRÉALABLE
1
Dédicaces
Je dédie ce travail à mes très chers parents,
A tous les membres de ma grande famille,
A tous mes amis,
Et à toutes les personnes qui mon ont aidé.
2
Remerciements
Avec beaucoup de plaisir, Je tiens, tout d’abord, à exprimer

ma profonde gratitude, ma reconnaissance, mon respect et
mes remerciements les plus sincères, à M. Riadh Ouali, mon
encadrante interne pour avoir accepté d'assurer le suivi de
ce projet et qui n’a pas cessé de me prodiguer de ses conseils
et ses recommandations tout au long de ce travail.je tiens
aussi à remercier mon encadreur externe Mr. Ramzi Houidi
de l'agence web et communication(SotuDev) pour sa
disponibilité, ses explications et ses conseils fructueux.
Enfin, je remercie les membres du jury pour avoir accepté
d'évaluer mon travail.
3
Table des matières
Introduction générale ............................................................................................................ 10

Chapitre 1 : Étude préalable................................................................................................. 11
1.1 Introduction : ............................................................................................................. 11
1.2 Cadre du projet : ........................................................................................................ 11
1.3 Présentation du projet et objectif :............................................................................. 11
1.4 Présentation de l’organisme d’accueil : .................................................................... 12
1.4.1 Genèse : .............................................................................................................. 12
1.5 Planning prévisionnel : .............................................................................................. 13
1.6 Etude et critique de l’existant .................................................................................... 14
1.6.1 Clinique Amen Nabeul : .................................................................................... 14
1.6.2 Ennaser Médical : .............................................................................................. 15
1.6.3 Tabibi : ............................................................................................................... 16
1.6.4 Bilan des solutions existant ................................................................................ 18
1.7 Synthèse : .................................................................................................................. 19
1.8 Analyses des besoins : ............................................................................................... 19
1.8.1 Les besoins fonctionnels : .................................................................................. 20
1.8.2 Les besoins non fonctionnels : ........................................................................... 21
1.9 Conclusion :............................................................................................................... 22
Chapitre 2 : Étude Conceptuelle .......................................................................................... 23
2.1 Introduction : ............................................................................................................. 23
2.2 L’outil de modélisation UML : ................................................................................. 23
2.3 Définition : ................................................................................................................ 23
2.4 Diagramme de cas d’utilisation :............................................................................... 23
2.4.1 Identification des acteurs : ................................................................................. 24
2.4.2 Identification des cas d’utilisation : ................................................................... 24
2.4.3 Classification des cas d'utilisation par acteur : .................................................. 24
2.4.4 Le diagramme de cas d’utilisation global .......................................................... 25
4
2.4.5 Le diagramme de cas d’utilisation par acteurs ................................................... 27

2.4.5.1 Le diagramme de cas d’utilisation Administrateur ........................................ 27
2.4.5.2 Le diagramme de cas d’utilisation Médecin .................................................. 27
2.4.6 Description textuelle des principaux cas d'utilisation ........................................ 28
2.5 Vue statique ............................................................................................................... 31
2.5.1 Patron de conception .......................................................................................... 31
2.5.2 Le diagramme de classes ................................................................................... 32
2.6 Vue dynamique du système....................................................................................... 34
2.6.1 Les diagrammes de séquence ............................................................................. 34
2.6.1.1 Cas d’utilisation « S’AUTHENTIFIER » ...................................................... 34
2.6.1.2 Cas d’utilisation « inscription » ..................................................................... 35
2.6.1.3 Cas d’utilisation « Ajouter rendez-vous » ...................................................... 36
2.6.1.4 Cas d’utilisation « Modifier rendez-vous » .................................................... 37
2.6.1.5 Cas d’utilisation « Gestion de stock "Entrée” » ............................................. 38
2.7 Conclusion................................................................................................................. 38
Chapitre 3 : Réalisation ......................................................................................................... 39
3.1 Introduction ............................................................................................................... 39
3.2 Environnement de développement et choix techniques ............................................ 39
3.2.1 Environnement matériel ..................................................................................... 39
3.2.2 Environnement et technologies .......................................................................... 40
3.2.2.1 Environnement logiciel .................................................................................. 40
3.2.2.2 Choix de technologies .................................................................................... 42
3.2.3 Architecture de l’application.............................................................................. 43
3.2.3.1 Architecture physique .................................................................................... 43
3.2.3.2 Architecture logique ....................................................................................... 44
3.3 Captures d’écrans ...................................................................................................... 45
3.3.1 Interface d'accueil ................................................................................................ 45
3.3.2 Interface login ...................................................................................................... 45
3.3.3 Interface d'inscription .......................................................................................... 46
3.3.4 Interface profile (Patient / Médecin) .................................................................... 47
3.3.5 Espace Patient ...................................................................................................... 48
5
3.3.5.1 Interface Ajouté Rendez-vous : ..................................................................... 48

3.3.5.2 Interface gestion de Rendez-vous : ............................................................... 48
3.3.5.3 Interface Listes des Rendez-vous Accepté : .................................................. 49
3.3.5.4 Interface Consulter Dossier Médical : ........................................................... 50
3.3.6 Espace Médecin ................................................................................................... 50
3.3.6.1 Interface gestion des Rendez-vous : .............................................................. 50
3.3.6.2 Interface Ajouter consultation ....................................................................... 51
3.3.6.3 Interface Reporter ordonnance ...................................................................... 52
3.3.7 Espace Admin ................................................................................................ 52
3.3.7.1 Interface de tableau de bord .......................................................................... 52
3.3.7.2 Interface gestion Médecin ............................................................................. 53
3.3.7.3 Interface liste des rendez-vous ...................................................................... 53
3.3.7.4 Interface effectué Médecin ............................ Error! Bookmark not defined.
3.4 Tests des APIs : .......................................................................................................... 54
3.4.1 L'API d'authentification ....................................................................................... 54
3.4.2 L'API d’un nouveau rendez-vous ........................................................................ 54
3.4.3 L'API récupère les rendez-vous par patient ......................................................... 55
3.5 Conclusion..................................................................................................................... 56
Conclusion générale ............................................................................................................... 57
Bibliographie............................................................................................................................ 58
6
Liste des Figures
Figure 1:Interface d’accueil de AMEN ……………………………………………………. 10

Figure 2: Interface de Ennaser……………………………………………………………… 11
Figure 3: Interface de Tabibi……………………………………………………………….. 12
Figure 4: Diagramme de cas d’utilisation global…………………………………………… 22
Figure 5: Diagramme de cas d’utilisation Administrateur………………………………….. 23
Figure 6: Diagramme de cas d’utilisation Médecin…………………………………………. 23
Figure 7: Diagramme de paquetages………………………………………………………… 27
Figure 8: Diagramme de paquetage…………………………………………………………. 28
Figure 9: Diagramme de classes…………………………………………………………….. 29
Figure 10: Diagramme de séquence pour le cas d’utilisation « s’authentifier»……………... 30
Figure 11: Diagramme de séquence pour le cas d’utilisation « inscription »……………….. 31
Figure 12: Diagramme de séquence pour le cas d’utilisation « ajouter rendez-vous »…….. 32
Figure 13: Diagramme de séquence pour le cas d’utilisation « modifier rendez-vous»…….. 33
Figure 14: Diagramme de séquence pour le cas d’utilisation « consulter notification »……. 34
Figure 15: Diagramme de séquence pour le cas d’utilisation « Consulter /modifier profile » 35
Figure 16: Diagramme de séquence pour le cas d’utilisation « Gérer stock Entrée »………. 36
Figure 17: Logo de « IntelliJ IDEA »………………………………………………………. 39
Figure 18: Logo de « Visual Studio Code »………………………………………………… 40
Figure 19: Logo de « Postman »……………………………………………………………. 40
Figure 20: Logo de « GitHub »……………………………………………………………... 40
Figure 21: Logo de « Spring Boot »…………………………………………………………41
Figure 22: Logo de « Angular »…………………………………………………………….. 41
Figure 23: Logo de « Node.js »…………………………………………………………….. 42
Figure 24: Logo de « MySQL »……………………………………………………………. 42
Figure 25: Logo de « JSON »………………………………………………………………. 43
Figure 26: Logo de « Visual Paradigme »………………………………………………….. 43
Figure 27: architecture 3-tiers……………………………………………………………….. 44
Figure 28: architecture logique……………………………………………………………… 45
Figure 29: interface d'accueil………………………………………………………………... 46
Figure 30: interface login……………………………………………………………………. 47
Figure 31: interface d'inscription……………………………………………………………. 48
Figure 32: interface profile Médecin………………………………………………………… 48
Figure 33: interface profile Patient…………………………………………………………...48
Figure 34: interface Ajouter Rendez-vous…………………………………………………... 49
7
Figure 35: interface Gestion Rendez-vous………...………………………………………… 50

Figure 36: interface Détail Rendez-vous…………………………………………………….. 50
Figure 37: interface Rendez-vous Accepté………………………………………………….. 51
Figure 40: interface Ajouter consultation…………………………………………………….53
Figure 41: interface ordonnance…………………………………………………………….. 54
Figure 42: interface tableau de bord…………………………………………………………. 56
Figure 43: interface gestion médecin………………………………………………………... 56
Figure 44: API authentification……………………………………………………………… 59
Figure 45: API PostRendez-vous……………………………………………………………. 60
Figure 46: API geTRendez-vousByPatient………………………………………………….. 61
8
Liste des Tableaux
Table 1 : Planning prévisionnel ............................................................................................... 13

Table 2: Tableau récapitulatif .................................................................................................. 18
Table 3:Classification des cas d'utilisation par acteur ............................................................. 25
Table 4:Description textuelle cas d'utilisation "S’inscrire" ..................................................... 28
Table 5:Description textuelle cas d'utilisation "Ajouter rendez-vous" .................................... 29
Table 6:Description textuelle cas d'utilisation "Consulter rendez-vous" ................................. 29
Table 7:Description textuelle cas d'utilisation "Consulter dossier médical" ........................... 30
Table 8:Description textuelle cas d'utilisation "Consulter rendez-vous" ................................. 31
Table 9: Matériels utilisés ........................................................................................................ 39
9
Introduction générale
Une entreprise qui gère bien les flux d’information autour d'elle, peut s’adapter sur son marché
en assurant sa compétitivité. Ce défi n'est plus un grand souci, grâce à l'impact positif d'internet
et des nouvelles technologies.
C'est dans ce cadre que s'inscrit notre projet de fin d'études qui a pour but de concevoir une
application web pour la gestion interne d'une clinique, afin d'augmenter sa productivité et
améliorer sa façon de travailler.
Les buts à atteindre sont de mettre les acteurs de la clinique en relation, par l'implémentation
des processus de prise de rendez-vous et de consultation, ainsi que la gestion des dossiers
médicaux. L'application offre également une gestion de supervision des opérations d'entrées et
de sorties du stock.
Ce rapport décrit les différentes étapes suivies pour mener à bien ce projet et les reflète en trois
chapitres :
➢ Le premier chapitre est consacré à la présentation générale du projet, en outre l’analyse

et spécification des besoins
➢ Le deuxième chapitre s'articule autour les différents aspects conceptuels
➢ Le dernier chapitre comporte les détails de réalisation, ainsi que les tests réalisés.
10
Chapitre 1 : Étude préalable
1.1 Introduction :
L’étude préalable représente la partie préliminaire à la réalisation de l'application. En premier
lieu, je vais présenter mon projet ainsi que les objectifs à atteindre. Par la suite, je présenterai
l’organisation d'accueil SotuDev, et expliquerai l'environnement du stage, puis je passerai à
l’étude de l’existant en exposant leurs avantages et leurs inconvénients. Enfin, je proposerais
les différentes solutions aux problèmes soulevés.
1.2 Cadre du projet :

Ce projet s'inscrit dans le cadre d'un projet de fin d'études à l'institut supérieur d'informatique
et multimédia de Gabès pour l'obtention du diplôme de fondamental en science informatique
et multimédia pour l’année universitaire 2021-2022.
1.3 Présentation du projet et objectif :

L'approche médicale est basée sur l'observation du patient. Les mémoires des médecins étaient
autrefois suffisantes pour enregistrer les données des patients, Avec l'augmentation des effets
de l'environnement, il est nécessaire d'avoir des ressources informatiques pour une bonne tenue
des Dossiers médicaux, afin d'obtenir des résultats rapides.
Pour cela et dans le cadre du diplôme de troisième année en science de l'informatique et
multimédia, je suis appelé à concevoir, développer et mettre en œuvre une plateforme de
gestion de la gestion interne d'une clinique.
Cette application met à disposition un processus de gestion de rendez-vous, tenant à compte le
besoin critique du patient à un rendez-vous, lors d'un cas d’urgence.
Ainsi de suite, une consultation sera programmée par le premier médecin disponible choisi par
le patient.
11
Ce qui annonce la naissance d'un dossier médical amassant toutes les données relatives, créé
par le médecin accessible par le patient.
Notre système offre également un processus de gestion des entrées- sorties du stock dédiées
pour les employées de la clinique.
1.4 Présentation de l’organisme d’accueil :
1.4.1 Genèse :
Mon stage de fin d’études s’est déroulé au sein de l’entreprise SotuDev (Agence web et
communication) qui est une agence de communication orientée web basée en Tunisie (Tunis
et Paris), et qui offre une gamme diversifiée de services professionnels.
Avec plusieurs années d'expérience, l'agence de communication SOTUDEV Web Tunisie
conseille et inspire ses clients avec de nouvelles idées qui combinent la gestion de
l'environnement et les technologies modernes.
Les services proposés par SOTUDEV sont les suivants :

✔ Mettre en place et gérer des projets
✔ Conseiller et guider ses clients
✔ Communiquer et générer de nouvelles entreprises
SOTUDEV est fondé sur ces atouts :

✔ L’étude de faisabilité et la gestion de projet
✔ La rédaction de cahiers des charges technique et fonctionnel à la création de sites
internet et e-commerce
✔ Identité visuelle de marque
✔ Ergonomie web et applicative
12
Tous les services proposés par cette boîte de communication web respectent les normes et
pratiques internationales, sur de l'open source, des contrôles réguliers et une recherche
permanente des nouveaux outils et technologies.
1.5 Planning prévisionnel :

La clé principale de la réussite d’un projet est un bon planning. En effet, le planning aide à bien
subdiviser le travail et séparer les tâches à réaliser, il offre une meilleure Estimation et gestion
du temps nécessaire pour chaque tâche. De plus, il donne assez de visibilité permettant
d’estimer approximativement la date d’achèvement de chaque tâche.
Dans notre projet, nous avons estimé de réaliser notre application dans une durée
approximativement quatre mois. Le tableau ci-dessous montre le planning que nous avons
adapté pour mener à bien notre réalisation des différentes parties du projet.
Février Mars Avril Mai
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Etude préalable
Conception
Réalisation
Rédaction du
rapport
Table 1 : Planning prévisionnel
Comme le montre le tableau 1.1 ci-dessous quatre principales phases peuvent être dégagés :
L’étude préalable : le résultat de cette phase est la détermination des objectifs à atteindre
dans notre future application en partant de l’existant.
Conception : il s’agit de détailler les spécifications des fonctions ainsi que la structure des
données, et des contrôles et les interfaces.
Réalisation : il s’agit de réaliser l’implémentation des programmes et effectuer les tests
unitaires.
Rédaction du rapport : description détaillée de notre travail.
13
1.6 Etude et critique de l’existant

L’étude de l’existant permet de comprendre le sujet et d'élaborer une évaluation analytique
pour détecter les points faibles et les points forts de système existant et fournir une solution
plus efficace.
Cette étude me permet de dégager les fonctionnalités offertes ainsi que les carences, ce qui met
en évidence les enjeux et les problématiques qui seront traitées dans ce projet.
Il s’agit notamment de :
1.6.1 Clinique Amen Nabeul :
https://nabeul.amensante.com/Fr/
Figure 1– Interface d’accueil de AMEN

Amen Nabeul est une clinique, située à Nabeul, qui possède un site web permettant de gérer
l'ensemble des activités existantes
14
● Les points forts :

- Prendre un rendez-vous en ligne à tout moment,
● Les points faibles :
- Mauvais référencement du site
- L’absence d'un espace pour le patient et le médecin
- Pas de gestion de consultation
- L’absence d’un Gestion et Suivi du Dossier Médical
- Pas de gestion de rendez-vous (seulement ajouter RDV)
1.6.2 Ennaser Médical :

https://ennasr-medical.tn/
Figure 2 – Interface de Ennaser
Ennaser Médical est un groupement de cabinets Médicaux privés au cœur de la cité Ennasr à
Tunis, qui possède une application web pour la gestion des cabinets.

- Réserver un rendez-vous en ligne à tout moment,
15
- Permet de rechercher un médecin à l'aide de filtre (par nom, spécialités...)

- Mauvais référencement du site
- Difficile de prendre un rendez-vous
- L’absence d'un espace pour le patient et le médecin
- Pas de gestion de consultation
- L’absence d’un Gestion et Suivi du Dossier Médical
- Pas de gestion de rendez-vous (seulement ajouter RDV)
1.6.3 Tabibi :
http://tabibi.tn/
Figure 3– Interface de Tabibi
Tabibi.tn est une plateforme informatique tunisienne gratuite innovante conçue pour la gestion
des cabinets médicaux.
16

- Réserver un rendez-vous en ligne à tout moment,
- Il comporte deux espaces, un pour les patients et l'autre pour les médecins.
- Assure une recherche de médecin intuitif dont il peut filtrer sa recherche par
(nom, spécialités…,).
-
- Difficile de créer un nouveau compte.
- Pas de gestion de consultation.
- L’absence d’un Gestion et Suivi du Dossier Médical.
- Pas de gestion de rendez-vous (seulement ajouter RDV).
17
1.6.4 Bilan des solutions existant

Le tableau suivant illustre les fonctionnalités des différentes applications à l’issue d’étude de
l’existant
Application
AMEN Ennaser Tabibi
Fonctionnalités
Gratuit X X X
Application Web Pour X

Clinique
Espace Patient X
Espace Médecin X
Recherche X X X
Notification par email
Gestion de Rendez-vous Seulement ajouter

RDV
Gestion de Consultation
Gestion des entrées-

sorties du stock
Table 2: Tableau récapitulatif
18
1.7 Synthèse :
Lors de l’étude et la critique de l’existant, je constate que les applications étudiées sont limitées
à la gestion des rendez-vous
En outre, je note aussi :
➢ Manque d'un espace dédié au patient et au médecin dans l'une des applications étudiées.
➢ Pénurie de la gestion de rendez-vous, il existe seulement ajouter le rendez-vous
➢ L’absence d’un processus de gestion consultation et suivi du Dossier Médical
➢ Les applications étudiées ne possèdent pas un système de gestion des entrées- sorties
du stock.
L’étude réalisée montre qu’il n'y a pas une perfection dans les solutions du marché étudiées et
la majorité des applications ne prennent pas en compte le besoin déclenché de mon projet.
Pour cela, je justifie la nécessité de la mise en place d’un système numérique pour fournir une
solution plus efficace.
1.8 Analyses des besoins :

La spécification des besoins est la première phase du cycle de développement d’une
application.
Dans cette section, je vais identifier les besoins et les acteurs principaux de mon système, afin
de développer une plateforme adéquate à l'ensemble des activités existantes dans cette clinique
et d'apporter des résultats optimaux et la satisfaction du client. Il se compose de deux parties,
la première pour les internautes (espace patient, espace médecin) et la deuxième pour
l'administrateur.
19
1.8.1 Les besoins fonctionnels :

Il s'agit des fonctionnalités du système. Ce sont les besoins spécifiques d’un comportement
d'entrée / sortie du Système.
Les exigences des différents acteurs peuvent être résumés comme suit :
Espace Patient :
➢ Gérer les informations de son compte.

➢ Prendre rendez-vous.
➢ Reporter ou annuler un rendez-vous.
➢ Modifier le rendez-vous.
➢ Consulter son historique de rendez-vous.
➢ Recherche (médecin, consultation…,).
➢ Rapport PDF (dossier médical…,).
➢ Recevoir des notifications sur (App, Email)
Espace Médecin :
➢ Gérer les informations de son compte

➢ Créer un dossier médical
➢ Consulter son historique de rendez-vous
➢ Annuler ou reporter un rendez-vous
➢ Consulter son historique de consultation
➢ Report PDF (dossier médical, ordonnance.,)
➢ Consulter dossier médical
➢ Rechercher (dossier médicale, patient…,)
Espace employé Interne:
➢ Gérer les informations de son compte

➢ Consulter salaire
➢ Ajouter stock Sortie
20
➢ Consulter stock Sortie

Espace Administrateur :
➢ Gérer les compte (médecin, patient)

➢ Consulter liste patient/ médecin.
➢ Consulter rendez vous
➢ Consulter Salaires(employés)
➢ Gérer Stock Entrée
➢ Consulter Stock Sortie
➢ Système de notification
1.8.2 Les besoins non fonctionnels :

Il s'agit d'exigences liées aux performances du système, à la facilité d'utilisation, à l'ergonomie
de l'interface utilisateur, à la sécurité etc. Et parmi ses besoins nous citons :
❖ Sécurité
La sécurité des données doit être garantie pour protéger l'accès aux formulaires.
❖ Performance
Temps de réponse rapide, ressources utilisatrices minimales.
❖ Responsive
L’application est satisfaite de toutes les résolutions d’écran (smartphone, tablette…,).
❖ Maintenance
Le code doit être simple à maintenir.
Afin de développer une application web générique responsive et compatible avec la plupart des
navigateurs, Je vais utiliser les nouvelles tendances technologiques du web (Spring-Boot,
Angular, MySQL...) qui sont de nos jours, des outils incontournables pour les développeurs
web.
21
1.9 Conclusion :
Dans ce chapitre, j’ai défini le champ de mon étude, puis j’ai effectué une étude préalable au
cours de laquelle l’organisation d'accueil SotuDev et l’étude de l’existant des différentes
applications de gestion de clinique, afin de préciser nos objectifs à atteindre et les solutions
proposées.
Dans le chapitre suivant, je présenterai la partie étude conceptuelle.
22
2 Chapitre 2 : Étude Conceptuelle
2.1 Introduction :
Dans ce chapitre, j’entame présenter le diagramme de cas d'utilisation qui donne une vue
d’ensemble de mon application. Ensuite je passe à fournir la vue statique du système sous
forme de diagramme de classes. En outre, je montre la chronologie des opérations par les
diagrammes de séquence. Finalement, je récapitule par une brève conclusion.
2.2 L’outil de modélisation UML :

Pour accomplir la conception de mon projet, je vais opter pour utiliser un langage de UML
comme un outil de la modélisation conceptuelle. Dans la partie suivante, je définis ce langage
et ses approches
2.3 Définition :
UML (Unified Modeling Language) est un langage de modélisation graphique à base de
pictogrammes, il peut être appliqué à toutes sortes de systèmes, pas seulement au domaine
informatique. UML nous permet de modéliser notre projet de manière claire en se basant sur
une notion graphique.
Dans le cadre de ce projet je vais utiliser le logiciel Visual Paradigme Online pour la
modélisation.
2.4 Diagramme de cas d’utilisation :

Le diagramme de cas d’utilisation est utilisé pour modéliser le comportement fonctionnel d’un
système en définissant les fonctionnalités fournies par le système observé par les acteurs.
23
2.4.1 Identification des acteurs :

Un acteur est une idéalisation du rôle joué par un étranger, processus ou choses qui interagissent
avec le système.
Les acteurs de notre système sont :
● Patient
● Médecin
● Employé Interne
● L'administrateur
● Utilisateur
2.4.2 Identification des cas d’utilisation :

Les cas d'utilisation sont des descriptions des opérations que le système engage pour atteindre
les objectifs d'un utilisateur.
2.4.3 Classification des cas d'utilisation par acteur :

Le tableau suivant illustre l’ensemble des cas d’utilisation nécessaires pour le bon
fonctionnement du système :
24
Acteur Cas d’utilisation Cas d'utilisation commun

Utilisateur - S'inscrire
- Consulter actualité
- Prendre rendez-vous
Patient - Annuler rendez-vous
- Modifier rendez-vous
- Demander renseignement
- Gérer rendez-vous
- Gérer dossier médicale - S'authentifier
- Consulter Stock Sortie
- Consulter rendez-vous
Médecin - Ajouter Stock Sortie
- Demander renseignement - Consulter DM
- Modifier profil
- Consulter notification
- Gérer utilisateur
Administrateur - Gérer Stock Entrée
- Consulter Stock Sortie
- Consulter Salaire
- Consulter salaire
- Consulter stock Sortie
- Ajouter stock Sortie
Employé Interne - S'inscrire
- S'authentifier
- Consulter notification
- Modifier profil
- Demander renseignement
Table 3:Classification des cas d'utilisation par acteur
2.4.4 Le diagramme de cas d’utilisation global

Pour donner une vue d’ensemble de l’application, je récapitule toute la fonctionnalité étudiée
précédemment dans le diagramme de cas d'utilisation suivante :
25
Figure 4 : Diagramme de cas d’utilisation global
26
2.4.5 Le diagramme de cas d’utilisation par acteurs
2.4.5.1 Le diagramme de cas d’utilisation Administrateur
Figure 5 : Diagramme de cas d’utilisation Administrateur
2.4.5.2 Le diagramme de cas d’utilisation Médecin
Figure 6 : Diagramme de cas d’utilisation Médecin
27
2.4.6 Description textuelle des principaux cas d'utilisation

Afin de mieux comprendre le système dans cette section, les scénarios suivants seront décrits
en détail cas d'utilisation principal.
CU : S’inscrire
Objectif : s'inscrire sur l’application
Acteurs : utilisateur
Pré-condition : utilisateur inscrit
Scénario principal :
« DÉBUT »
+ le système affiche un formulaire aux utilisateurs
+ l’utilisateur remplit le formulaire.
+ le système envoie les données à la base de données
« FIN »
Scénario Alternatif :
un message d'erreur sera affiché, informe que les données sont incorrects
Table 4:Description textuelle cas d'utilisation "S’inscrire"
CU : Ajouter rendez-vous
Objectif : ajouter un ou plusieurs rendez-vous
Acteurs : patient
Pré-condition : s'authentifier.
Pοst-cοnditiοn : rendez-vous ajoutée
« DÉBUT »
28
+ l’utilisateur accède à l’interface l’ajout de rendez-vous.

+ le système affiche un formulaire d’ajout
+ l’utilisateur remplit les champs et choisit un ou plusieurs médecins.
+ le système vérifie les informations et valide. [A]
+ le système enregistre les données.
« FIN »
Scénario Alternatif [A] :
Si un champ d’un formulaire est incomplet ou date de rendez-vous et existe déjà, le
système affiche un message d’erreur.
Table 5:Description textuelle cas d'utilisation "Ajouter rendez-vous"
CU : Consulter rendez-vous
Objectif : Consulter la liste des rendez-vous
Acteurs : Patient, médecin, administrateur
« DÉBUT »
+ l’utilisateur demande l’interface des rendez-vous.
+ le système affiche l’interface des rendez-vous.
+ l’utilisateur recherche le rendez-vous et valide. [A]
+ le système affiche le rendez-vous.
« FIN »
Si le rendez-vous n’existe pas, le système affiche un message d’erreur.
Table 6:Description textuelle cas d'utilisation "Consulter rendez-vous"
29
CU : Consulter dossier médical
Objectif : Consulter dossier médical
Acteurs : Patient, médecin, administrateur
« DÉBUT »
+ l’utilisateur demande l’interface des dossiers.
+ le système affiche l’interface des dossiers.
+ l’utilisateur recherche le dossier et valide. [A]
+ Le système affiche les dossiers.
« FIN »
Si le rendez-vous n’existe pas, le système affiche un message d’erreur.
Table 7:Description textuelle cas d'utilisation "Consulter dossier médical"
CU : Gérer stock Entrée
Objectif : : Mise à jour la liste des stock entrée/sortie
Acteurs : Administrateur
« DÉBUT »
+ L'acteur demande l’interface de stock entrée/sortie.
+ Le système affiche l’interface des articles.
+ L'acteur effectue la mise à jour et valide. [A]
+ Le système enregistre les informations.
« FIN »
30

Si l’article n’existe pas, le système affiche un message d’erreur.
Table 8:Description textuelle cas d'utilisation "Consulter rendez-vous"
2.5 Vue statique

La vue statique permet de présenter les concepts de l’application. Par le suit le concept sont
organisés selon le modèle MVC [1] (Modèle-Vue-Contrôleur), qui signifie Modèle Vue
Contrôleur. Ainsi, notre projet est composé de trois packages illustrer comme suit :
Figure 7 : DIAGRAMME DE PAQUETAGES
2.5.1 Patron de conception

Le modèle MVC est considéré comme patron de conception pour l’application. Ce patron
distingue entre : les données (le modèle), l’interface (Vue) et la logique de contrôleur
Modèle : Cet élément gère les données sur mon application. Sa fonction consiste à récupérer
et d'organiser les données dans la base de données, pour qu'elle par la suie était traitée par le
contrôleur
Vue : Cet élément permet l'affichage des données émanant du modèle.
31
Contrôleur : C’est un module qui gère les actions de l'utilisateur, modifient les modèles et
affichent les données.
Figure 8 : DIAGRAMME DE PAQUETAGES
2.5.2 Le diagramme de classes

Dans la modélisation UML le diagramme de classes est un modèle estimé comme le plus
important de la modélisation orientée objet. Il montre la structure interne et permet une
présentation abstraite des objets du système
32
Figure 9 : DIAGRAMME DE CLASSES
33
2.6 Vue dynamique du système
2.6.1 Les diagrammes de séquence

Le diagramme de séquence affiche les interactions entre les objets et est utilisé pour modéliser
les aspects dynamiques de scénarios complexes et en temps réel mettant en œuvre des objets.
2.6.1.1 Cas d’utilisation « S’AUTHENTIFIER »

Cette figure montre le processus d’authentification
Figure 10 : DIAGRAMME DE SÉQUENCES POUR LE CAS

D’UTILISATION « S’AUTHENTIFIER »
34
2.6.1.2 Cas d’utilisation « inscription »

Ce diagramme présente l’inscription de l’utilisateur, un formulaire d’inscription est affiché,
l’utilisateur saisit ses informations. Si les données saisies est incorrect alors le système affiche
un message d’erreur sinon confirme l’ajout

D’UTILISATION « INSCRIPTION »
35
2.6.1.3 Cas d’utilisation « Ajouter rendez-vous »

Ce diagramme décrit le processus l’ajout de rendez-vous pour le patient, un formulaire d’ajout
est affiché le patient saisit les données de rendez-vous. Le système vérifie l’ajout et enregistre
les informations saisies dans la base sinon un message d’erreur sera affiché

D’UTILISATION « AJOUTER RENDEZ-VOUS »
36
2.6.1.4 Cas d’utilisation « Modifier rendez-vous »

Après l’authentification, l’utilisateur peut faire le GRUD d’un rendez-vous, La figure ci-
dessous nous présente le diagramme de séquence de « Modifier rendez-vous »

D’UTILISATION « MODIFIER RENDEZ-VOUS »
37
2.6.1.5 Cas d’utilisation « Gestion de stock "Entrée” »

Si l’authentification passe avec succès, l’administrateur peut faire le CRUD de stock Entrée

D’UTILISATION de « Gérer stock Entrée »
2.7 Conclusion
Ce chapitre a donné une description de l'architecture et de la conception de l'application. Lors
de l'introduction de l'architecture de l'application, la conception de l'application est réalisée à
l'aide du diagramme de classes global et du quelque diagramme de séquence de chaque cas
d'utilisation. Pour cela il devient possible de passer à la phase de réalisation, qui fait l'objet du
chapitre suivant.
38
3 Chapitre 3 : Réalisation
3.1 Introduction
Ce chapitre constitue le dernier volet de ce rapport, il traite la phase qui a pour objectif
l’implémentation de notre application. Tout d’abord, je commence par présenter
l’environnement matériel et logiciel. Ensuite, le choix de la technologie et l’architecture
utilisée. Pour finir, j’illustre le travail réalisé à travers les différentes interfaces.
3.2 Environnement de développement et choix techniques
3.2.1 Environnement matériel

L’implémentation de mon application est effectuée via un ordinateur portable ayant les
caractéristiques suivantes :
Marque Lenovo Thinkpad T460
Intel(R) Core (TM) i5-6200U CPU @

Processeur
2.30GHz 2.40 GHz
Disque dur 500 GB
RAM 8.00 GB
System d'exploitation Windows 10 Pro

Table 9: Matériels utilisés
39
3.2.2 Environnement et technologies
3.2.2.1 Environnement logiciel

Pour accomplir cette tâche avec succès, nous devons savoir utiliser les bons outils nécessaires.
Ce choix peut influencer la qualité du système obtenu
IntelliJ IDEA [2] :

Au cours du développement de mon application, j utilisé IntelliJ IDEA comme un éditeur de
code que développé par Jetbrains, ce dernier est un environnement de développement intégré,
principalement destiné à langage Java, il se caractérise par sa facilité d'utilisation, sa
conception solide et sa flexibilité.
Figure 17 : LOGO DE « IntelliJ IDEA »
Visual Studio Code [3] :

Visual Studio Code est un éditeur de code léger multiplateforme, open source et gratuit
développé par Microsoft qui s'exécute sous Windows, MacOs et Linux. De plus, peut être
utilisé avec une variété de langage sont fonctionnalités incluent dans : la complétion intelligente
du code, la mise en évidence de la syntaxe, la refactorisation du code et Git intégrer. La figure
ci-dessous présente son logo.
Figure 18 : LOGO DE « Visual Studio Code »
40
Postman [4] :
Postman est une application multiplate-forme (Windows/MacOs/Linux) basée sur le langage
JSON, il permet de résoudre les problèmes de tester les API REST. Ainsi, il inclut toutes les
fonctions de demande REST avec une interface pour ajouter des paramètres.
Figure 19 : LOGO DE « Postman »

GitHub [5] :
Est un est un service d'hébergement open source. Il permet aux programmeurs de travailler
ensemble et de suivre et partager le code informatique du projet.
Figure 20 : LOGO DE « GitHub »
Visual Paradigme [6] :

C’est un logiciel gratuit multi plateforme de conception, facile à utiliser et comporte plusieurs
outils pour développer des projets informatiques, il permet la création de différents diagrammes
UML.
Figure 26 : LOGO DE « Visual Paradigme »
41
3.2.2.2 Choix de technologies

Spring Boot [7] :
Spring Boot ou Spring MVC est un nouveau Framework open source de développement
informatique essentiellement utilisé pour développer des API REST pour l’application Java, il
fournit des serveurs intégrés tels que Tomcat, etc. ce dernier comprend une foule de
caractéristiques telle que la sécurité, flexibilité et la configuration automatique dès
l’application.
Figure 21: LOGO DE « Spring Boot »
Angular [8]:
Angular est un Framework et une plate-forme JavaScript, conçu pour créer des applications
web d'une seule page « Single Page Applications ». De plus, il est basé sur l’architecture MVC
(Modèle, vue, contrôleur).
Figure 22 : LOGO DE « Angular »
Node.js [9] :
Est une plateforme open source en langage javascript et qui s'exécute côté serveur. De plus,
vous pouvez effectuer plusieurs actions en même temps grâce aux opérations non bloquantes.
Figure 23 : LOGO DE « Node.js »
42
MySQL [10] :
MySQL est un système de gestion de bases de données relationnelles open source sous licence
GPL, il est multi-utilisateur et multi-thread. De plus, il permet de stocker les informations dans
des tables séparées de tout regrouper dans une seule table.
Figure 24 : LOGO DE « MySQL »
JSON (JavaScript Object Notation) [11] :

JSON est un langage léger principalement utilisé pour d’échange de données textuelles entre
un client et un serveur, il est totalement indépendant de tout langage de programmation.
Figure 25 : LOGO DE « JSON »
3.2.3 Architecture de l’application
3.2.3.1 Architecture physique

Pour faciliter le développement de mon application et d'en assurer la maintenance et l'évolution,
j'ai adopté l’architecture 3 tiers.
Comme indiqué dans le schéma, cette structure est composée des éléments suivants ;
● Un client : en ce qui concerne l'affichage, la restitution sur le poste de travail, le
dialogue avec l'utilisateur.
● Serveur applicatif : correspondant à la mise en œuvre de l'ensemble des règles de
gestion et de la logique applicative.
43
● L'accès aux données persistantes : relatives à des données qui seront stockées
pendant une longue période, voire de manière permanente
Figure 27 : architecture 3-tiers
3.2.3.2 Architecture logique

Notre application est basée sur un modèle en trois couches.
● Niveau de présentation est la couche frontale du système à 3 niveaux et se consiste
en une interface utilisateur à laquelle on peut accéder par un navigateur web ou une
application et qui fournit un contenu et des informations utiles à l'utilisateur final.
● Niveau d'application contient la logique métier fonctionnelle qui pilote les capacités
de base d'une application. Il est souvent écrit en Java, C#, Python, etc.
● Niveau de données comprend le système de base de données, de stockage de données
et la couche d'accès aux données. Parmi les exemples de tels systèmes, citons : MySQL,
PostgreSQL, MongoDB, etc. Les données sont accessibles par la couche application
via des appels API.
Figure 28 : architecture logique
44
3.3 Captures d’écrans

Dans cette section, j’ai présenté quelques interfaces de mon application GESIC construite à
l'aide de l'outil cité et défini dans le chapitre précédent.
3.3.1 Interface d'accueil

La figure ci-dessous, présente l’interface d’accueil de mon application " GESIC". Cette
interface permet aux utilisateurs d'accéder à leur espace.
Figure 29 : interface d'accueil
3.3.2 Interface login

Dans la figure 31, je présente l’interface login qui permet aux utilisateurs de s’authentifier à
partir de l’application.
45
Figure 30 : interface login
3.3.3 Interface d'inscription

La figure ci-dessous présente l’interface d’inscription pour l’utilisateur
Figure 31 : interface d'inscription
46
3.3.4 Interface profile (Patient / Médecin)

Après authentification, l'utilisateur est redirigé vers son interface de profil.
Figure 32 : interface profile Médecin
Figure 33 : interface profile Patient
47
3.3.5 Espace Patient

3.3.5.1 Interface Ajouté Rendez-vous :
Cette interface permet au patient de prendre un rendez-vous, il peut choisir un ou plusieurs
médecins de même spécialité.
Figure 34 : interface Ajouté Rendez-vous

3.3.5.2 Interface gestion de Rendez-vous :
La figure ci-dessous présente une liste des Rendez-vous en attente. Le patient peut consulter,
modifier ou annuler un rendez-vous,
48
Figure 35 : interface gestion Rendez-vous
Figure 36 : interface Détail Rendez-vous
3.3.5.3 Interface Listes des Rendez-vous Accepté :

Après la confirmation du médecin choisi à un rendez-vous, une entrée est ajoutée à cette liste.
Figure 37 : interface Rendez-vous Accepté
49
3.3.5.4 Interface Consulter Dossier Médical :

Cette figure présente l’interface dossier médical qui amassant toutes les données relatives, créé
par le médecin accessible par le patient.
Figure 38 : interface Dossier Médical
3.3.6 Espace Médecin
3.3.6.1 Interface gestion des Rendez-vous :

C'est l'interface dont le médecin comporte deux choix :
➢ Si l’action était refusée, le système va effectuer à la prochaine médecin

➢ Si l’action était acceptée, le rendez-vous serait fixé, et une notification
par mail était envoyée au patient
50
Figure 39 : interface gestion des Rendez-vous
3.3.6.2 Interface Ajouter consultation

Après avoir fixé le rendez-vous par le médecin, une notification sera envoyée au patient.
Une consultation aura lieu à l'arrivée du patient à la clinique.
La figure ci-dessous présente l’interface de l’ajout de consultation.
Figure 40 : interface Ajouter consultation
51
3.3.6.3 Interface Reporter ordonnance

A chaque consultation, une ordonnance sera imprimée, la figure ci-dessous résume cette
étape.
Figure 41 : interface ordonnance
3.3.7 Espace Admin
3.3.7.1 Interface de tableau de bord

Dans la figure suivante, je présente l’interface tableau de bord de l’administrateur qui lui
permet de voir ses sections et un graphe représente les dépenses.
Ainsi nous retrouvons également dans la barre “Sidebar ”les outils suivants : Gestion des
fournisseurs, Gestion des rendez-vous, Gestion des stock Entrée…,
52
Figure 42 : interface tableau de bord
3.3.7.2 Interface gestion Médecin

La figure suivante représente une liste des médecins où l'administrateur peut les supprimer, les
modifier et consulter profil.
Figure 43 : interface gestion médecin
3.3.7.3 Interface ajouter employer :

Cette interface permet à l'administrateur de créer le compte de l'employé
53
Figure 44 : interface Ajouter compte
3.4 Tests des APIs :

Parmi les nombreuses solutions pour interroger ou tester webservices et API, Postman
propose de nombreuses fonctionnalités, une prise en main rapide et une interface graphique
agréable.
Dans cette partie, je présente les différentes tâches réalisées pour tester le développement des
APIs (backend) afin de préciser nos objectifs à atteindre et les solutions proposées.
3.4.1 L'API d'authentification

La figure 51 montre la documentation des API relative à l'authentification
Puisqu’elle est une requête en mode POST nous sommes obligées de fournir le body par un
code JSON qui contient (username, password). Quant à l'URL, je dois fournir le routage
“signin”. Elle retourne un code 200 en cas de succès.
Figure 45 : API authentification
3.4.2 L'API d’un nouveau rendez-vous

La Figure 52 montre comment j'ai implémenté l'API pour la prise de rendez-vous.
54
Comme il s'agit d'une requête POST, je dois fournir le contenu sous la forme d'un code JSON
qui contient (description, date, idpatient...,). Pour l’url, je dois fournir le routage "avantRdv".
Elle renvoie un code de 200 si elle est réussie.
Figure 46 : API PostRendez-vous
3.4.3 L'API récupère les rendez-vous par patient

Dans la figure suivante, je présente l'implémentation de l’API getRendez-vous qui est une
requête en mode GET. Elle renvoie un code de 200 si elle est réussie.
Figure 47 : API geTRendez-vousByPatient
55
3.5 Conclusion
Tout au long de ce chapitre, j'ai discuté de l'environnement de mon projet. J’ai également
présenté les techniques utilisées pour mettre en œuvre le projet, des captures d'écran ont
également été utilisées pour démontrer les applications.
56
Conclusion générale
Au cours de ce projet, j’ai pu présenter le bilan complet de notre travail qui se situe dans le
cadre de mon projet de fin d'études. Ma mission est de développer une application de gestion
de clinique qui a pour but d’augmenter sa productivité et améliorer sa façon de travailler.
J’ai commencé tout d’abord, par une description de cadre général de projet. En outre, j’ai
consacré mes réflexions sur l’étude de l’existant, afin de déterminer les fonctionnalités pouvant
être mises à disposition des utilisateurs.
En deuxième lieu, j’ai amené la conception en faisant recours au langage UML et la mise en
œuvre des bases de données avec le gestionnaire MySQL. Enfin la concrétisation de
l’application sous le langage de programmation Spring boot et Angular.
Ce travail pourra être amélioré en absence de la contrainte temporelle qui a influencé son
affinement, j’estime d’améliorer mon application par ajouter des nouvelles fonctionnalités
telles que :
➢ Inclure la traduction en arabe.

➢ Réaliser le paiement en ligne par carte virtuelle.
➢ Hébergement en ligne.
57
Bibliographie
[1] MVC https://bit.ly/3nk7wIq.

[2] IntelliJ IDEA https://www.jetbrains.com/fr-fr/idea/
[3] Visual Studio Code https://fr.wikipedia.org/wiki/Visual_Studio_Code
[4] Postman https://www.postman.com/.
[5] GitHub https://fr.wikipedia.org/wiki/Git
[6] Spring Boot https://spring.io/projects/spring-boot
[7] Angular https://angular.io/guide/architecture
[8] Node.js https://nodejs.org/en/.
[9] Mysql https://fr.wikipedia.org/wiki/MySQL
[10] REST API https://www.redhat.com/fr/topics/api/what-is-a-rest-api.
[11] Visual paradigm https://online.visual-paradigm.com/fr/about-us
58
PLATEFORME DE GESTION INTERNE

DE CLINIQUE
‫يندرج هذا العمل ضمن مشروع التخرج للحصول على اإلجازة األساسية في علوم‬: ‫الخالصة‬
.‫اإلعالمية والملتيميديا‬
‫ويهدف هذا العمل على تطوير تطبيق الويب لغاية إيجاد حل لحوسبة وتحديث إدارة المواعيد‬
‫ والسجالت الطبية‬،‫المتابعة الطبية‬،
‫ المخزون‬،‫ السجالت الطبية‬،‫ موعد‬,MySQL ,Spring boot ,Angular : ‫المفاتيح‬
Résumé : Ce travail se situe dans le cadre du projet de fin d’études réalisé à

l’Institut Supérieur d’Informatique et Multimédia de Gabès, pour l’obtention du
Diplôme de Licence en Science d’Informatique et Multimédia (LSIM). Il a pour
objectif de réaliser une solution web, afin d’informatiser et moderniser la
gestion des rendez-vous et de consultation, des dossiers médicaux, ainsi que la
gestion d'entrées et de sorties du stock.
Mots clés : Angular, Spring boot, MySQL, Rendez-vous, dossiers médicaux,

Consultation, Stock,
59

RPP Finaleaaa

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

RPP Finaleaaa

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne Département

Ministère de l’enseignement supérieur et Multimédia & Web

RAPPORT DE PROJET FIN D’ETUDE

Plateforme de Gestion interne de Clinique

Soutenu le 24 Juin 2022 devant le jury composé de :

Encadrant Interne : M. Riadh Ouali ISIMG

Encadrant Externe : M. Ramzi Houidi SOTUDEV

Je dédie ce travail à mes très chers parents,

A tous les membres de ma grande famille,

A tous mes amis,

Et à toutes les personnes qui mon ont aidé.

Avec beaucoup de plaisir, Je tiens, tout d’abord, à exprimer

Table des matières

Introduction générale ............................................................................................................ 10

2.4.5 Le diagramme de cas d’utilisation par acteurs ................................................... 27

3.3.5.1 Interface Ajouté Rendez-vous : ..................................................................... 48

Liste des Figures

Figure 1:Interface d’accueil de AMEN ……………………………………………………. 10

Figure 35: interface Gestion Rendez-vous………...………………………………………… 50

Liste des Tableaux

Table 1 : Planning prévisionnel ............................................................................................... 13

➢ Le premier chapitre est consacré à la présentation générale du projet, en outre l’analyse

Chapitre 1 : Étude préalable

1.2 Cadre du projet :

1.3 Présentation du projet et objectif :

1.4 Présentation de l’organisme d’accueil :

Les services proposés par SOTUDEV sont les suivants :

SOTUDEV est fondé sur ces atouts :

1.5 Planning prévisionnel :

1.6 Etude et critique de l’existant

1.6.1 Clinique Amen Nabeul :

Figure 1– Interface d’accueil de AMEN

● Les points forts :

1.6.2 Ennaser Médical :

Figure 2 – Interface de Ennaser

● Les points forts :

- Permet de rechercher un médecin à l'aide de filtre (par nom, spécialités...)

● Les points faibles :

Figure 3– Interface de Tabibi

● Les points forts :

1.6.4 Bilan des solutions existant

Application Web Pour X

Notification par email

Gestion de Rendez-vous Seulement ajouter

Gestion des entrées-

1.8 Analyses des besoins :

1.8.1 Les besoins fonctionnels :

➢ Gérer les informations de son compte.

➢ Gérer les informations de son compte

➢ Gérer les informations de son compte

➢ Consulter stock Sortie

➢ Gérer les compte (médecin, patient)

1.8.2 Les besoins non fonctionnels :

2 Chapitre 2 : Étude Conceptuelle

2.2 L’outil de modélisation UML :

2.4 Diagramme de cas d’utilisation :

2.4.1 Identification des acteurs :

2.4.2 Identification des cas d’utilisation :

2.4.3 Classification des cas d'utilisation par acteur :

Acteur Cas d’utilisation Cas d'utilisation commun

Table 3:Classification des cas d'utilisation par acteur

2.4.4 Le diagramme de cas d’utilisation global

Figure 4 : Diagramme de cas d’utilisation global