Rapport 2 Scrum

République Tunisienne Université de Kairouan
Ministère de l'Enseignement Supérieur Institut Supérieur d’Informatique

et de la Recherche Scientifique et de Gestion de Kairouan
MEMOIRE
Pour l’obtention du diplôme de
MASTERE PROFESSIONNEL
En
INFORMATIQUE
RESEAUX ET APPLICATIONS DISTRIBUEES
Application intelligente de gestion d’un cabinet

d’ophtalmologie
Présenté et soutenu
le XX 10 2023 par
Mariem HAMMEDI
M. Président
M. Anis KALBOUSSI Encadrant pédagogique
M. Riadh BOUZID Encadrant professionnel
Année Universitaire 2022 – 2023

RÉSUMÉ
Ce présent rapport récapitule le travail réalisé dans le cadre du projet de fin d’études pour l’obtention
du diplôme Master professionnel au sein de l’entreprise ITgate-Group.
Durant notre projet nous avons conçu et réalisé une application intelligente de gestion d’un cabinet
d’ophtalmologie. Cette application est dédiée au ophtalmologistes, elle est réservée pour la gestion
des tâches journalières des médecins ophtalmologistes et qui organisent toutes les interactions avec les
différents intervenants dans le secteur d’ophtalmologie, de plus elle offre un espace de consultation et de
contrôle à distance et facilite le travail d’ophtalmologiste à travers un système intelligent de diagnostic
des images radiologiques, de même elle donne un service d’accompagnement des patients à travers un
agent conversationnel intelligent.
La méthodologie utilisée tout au long de ce projet est Scrum.
ABSTRACT
This report summarizes the work carried out as part of the end-of-studies project to obtain of the pro-
fessional Master’s degree within the company ITgate-Group . During our project we designed and
produced an intelligent application for managing an ophthalmology practice. This application is
dedicated to ophthalmologists, it is reserved for the management of the daily tasks of ophthalmologist
doctors and who organize all the interactions with the various stakeholders in the ophthalmology sector,
in addition it offers a space for consultation and remote control and facilitates the ophthalmology’s work
through an intelligent system for diagnosing radiological images, as well as providing a patient support
service through an intelligent conversational agent.
The methodology used throughout this project is Scrum.
i
DÉDICACE
Aucune expression ne peut faire part de ma reconnaissance, ma gratitude d’avoir de tels parents et la
fierté qui m’inonde de pouvoir arriver à ce stade d’éducation et d’études. Que pourrais-je dire, les mots
me manquent. . .
Je dédie cette mémoire à :
Mon cher père Chedlie Qui n’a jamais cessé de m’assister, de me soutenir, et de m’encourager. En
espérant qu’il trouve ici le résultat de longues années de sacrifices et de privations pour m’aider à
avancer dans la vie. Puisse Dieu faire en sorte que ce travail porte son fruit. Merci pour les valeurs
nobles venu de vous Papa.
Ma chère mère Monjia Pour son amour, son soutien et son aide précieuse. Je ferais toujours de mon
mieux pour rester un sujet de fierté à tes yeux. Que Dieu la procure santé, bonheur et longue vie et que
ce travail soit témoignage de mon éternelle reconnaissance pour son amour et ses sacrifices.
Mes sœurs Manel et Monia pour leur encouragement, leur soutien et leur écoute en cas de besoin. Que
dieu vous garde.
Mon cher frère Mourad
Qui je sacre tout l’amour et sur lequel j’ai su compter incessamment.
REMERCIEMENTS
Au terme de ce travail, je tiens à exprimer mes sincères remerciements à tous ceux qui ont collaboré,
de près ou de loin, à l’aboutissement de ce projet.
J’adresse mes sincères remerciements à monsieur ≪ Kalboussi Anis ≫ mon encadrant à l’institut
supérieur d’informatique et de gestion de kairouan,pour son suivi et ses remarques qui m’ont permis de
mener à bien ce travail.
Je tiens également à remercier mon encadrant de la société Itgate-Group, monsieur ≪ Bouzid Riath≫,
pour ces précieux conseils et ces encouragements lors de la réalisation de ce projet.
J’exprime ma gratitude aux membres de l’équipe de Itgate-Group, qui m’ont bien accueilli au sein de
leur groupe de travail.
Mes remerciements s’adressent également à l’administration et aux professeurs de l’institut supérieur
d’informatique et de gestion de kairouan pour la bonne formation durant les deux dernières années qui
m’a aidé énormément à élaborer ce travail.
Je souhaiterais également remercier tous les membres du jury pour avoir bien voulu évaluer mon travail..
iii
Table des matières
Liste des abréviations xii
INTRODUCTION GÉNÉRALE 1
1 Étude préalable 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Présentation de la société ≪ITgate-Group ≫ . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Profit de société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Missions principales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 OPHTEL : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 DrSanté : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.3 Téo : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.4 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 Méthodologie de développement et langage de modélisation . . . . . . . . . . . . . . . 8
1.7.1 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7.2 Langage de modélisation adopté . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 État de l’art 12
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Intelligence Artificielle (IA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Définition de l’intelligence artificielle . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 L’intelligence artificielle dans la médecine . . . . . . . . . . . . . . . . . . . . 13
2.2.3 L’intelligence artificielle dans la médecine d’ophtalmologie . . . . . . . . . . . 14
2.2.4 L’objectif d’un chatbot dans notre application . . . . . . . . . . . . . . . . . . 16
2.2.5 Les approches techniques pour créer une IA conversationnelle . . . . . . . . . . 16
2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
iv
3 Analyse et spécification des besoins 18
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1 Identification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.2 Identification des besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . 21
3.3 Identifications des acteurs et des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . 22
3.4 Modélisation des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.2 Diagramme de classes global . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 Pilotage de projet avec ≪ scrum ≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5.1 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7.1 Architecture logique : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7.2 Architecture physique : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.8 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8.2 Outil de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8.3 Outil de gestion de projet et de collaboration . . . . . . . . . . . . . . . . . . . 29
3.8.4 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.8.5 Outils de bases des données : . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.8.6 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.8.7 Outil de rédaction : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4 Implémentation du Sprint 1 35
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.1 Diagramme du cas d’utilisation du sprint 1 : . . . . . . . . . . . . . . . . . . . . 37
4.2.2 Description détaillée des principaux cas d’utilisations . . . . . . . . . . . . . . . 38
4.3 Conception dynamique du premier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.1 Diagramme de séquence ≪ S’authentifier ≫ . . . . . . . . . . . . . . . . . . . . 41
4.3.2 Diagramme de séquence ≪ Ajouter événement oculaire ≫ . . . . . . . . . . . . 42
4.3.3 Diagramme d’activité ≪S’authentifier≫ . . . . . . . . . . . . . . . . . . . . . . 43
4.3.4 Diagramme de classes du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Réalisation du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.1 Interface ≪ Authentification ≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.2 Interface ≪ Gestion des événements oculaire ≫ . . . . . . . . . . . . . . . . . . 44
4.5 Rétrospectives du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
v
5 Implémentation du Sprint 2 47
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.1 Diagramme du cas d’utilisation globale du sprint 2 : . . . . . . . . . . . . . . . 50
5.2.2 Description détaillée des principaux cas d’utilisations . . . . . . . . . . . . . . . 50
5.3 Conception des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3.1 Diagramme de séquence du cas d’utilisation≪ Ajouter un rendez-vous ≫ . . . . 53
5.3.2 Diagramme d’activité ≪ Envoyer message ≫ . . . . . . . . . . . . . . . . . . . 55
5.3.3 Diagramme de classe du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.4 Réalisation du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.4.1 Interface ≪ Ajouter rendez-vous ≫ . . . . . . . . . . . . . . . . . . . . . . . . 56
5.4.2 Interface ≪Gérer Consultation ≫ . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.4.3 Interface ≪ Consultation en ligne ≫ . . . . . . . . . . . . . . . . . . . . . . . . 58
5.4.4 Interface ≪Demander un rendez-vous ≫ . . . . . . . . . . . . . . . . . . . . . . 58
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6 Implémentation du sprint 3 60
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2 Bcklog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2.1 Choix technologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2.2 Apprentissage Supervisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.3.1 Architecture du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.3.2 Diagramme du cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3.3 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3.4 Les bibliothèques utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.4 Analyse et choix des données utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.4.1 Objets à détecter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.4.2 Caractéristiques des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4.3 Origine des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4.4 L’implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4.5 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.5 Interface graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7 Implémentation du sprint 4 75
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.1.1 Bcklog du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.2 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.2.1 Traitement du langage naturel . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.2.2 Le Machine Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
vi
7.2.3 Le Deep Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.2.4 Les réseaux de neurones artificiels . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.2.5 Choix de l’outil d’apprentissage automatique . . . . . . . . . . . . . . . . . . . 78
7.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.4 Fonctionnement d’un agent conversationnel . . . . . . . . . . . . . . . . . . . . . . . . 79
7.4.1 Intents / Intentions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.4.2 Training phrases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.4.3 Entraı̂ner le bot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.4.4 La compréhension du langage naturel . . . . . . . . . . . . . . . . . . . . . . . 80
7.4.5 Traitement de la demande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.4.6 Génération de réponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.5 Étude expérimentale : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.6 Architecture d’une application chatbot . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
84
Netographie 86
Bibliographie 87
vii
Table des figures
1.1 Logo du Société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Logo de OPHTEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Logo de DrSanté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Logo de Téo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 La méthodologie scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 L’intelligence artificielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Principe de base d’un chatbot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Chatbots basés sur la récupération . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Chatbots génératifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Diagramme de classes global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 L’architecture globale de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 L’architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6 L’architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7 PC HP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8 Logo Pacestar UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.9 Logo Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.10 Logo Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.11 Logo MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.12 Logo phpmyadmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.13 Logo Spring boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.14 Logo Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.15 Logo Kaggle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.16 Logo Google colab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.17 Log Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.18 Logo Api Flask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.19 Architecture p2p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.20 Logo Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
viii
Table des figures
3.21 Logo Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.22 Logo REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.23 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.24 Logo Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1 Diagramme du cas d’utilisation global du ≪ Sprint 1≫ . . . . . . . . . . . . . . . . . . 37

4.2 Diagramme du cas d’utilisation du ≪Authentification≫ . . . . . . . . . . . . . . . . . . 38
4.3 Diagramme du cas d’utilisation ≪ Gestion des utilisateurs ≫ . . . . . . . . . . . . . . . 38
4.4 Diagramme du cas d’utilisation ≪ Gestion des événements oculaires ≫ . . . . . . . . . . 40
4.5 Diagramme de séquence ≪ S’authentifier ≫ . . . . . . . . . . . . . . . . . . . . . . . . 42
4.6 Diagramme de séquence ≪ Ajouter événement oculaire ≫ . . . . . . . . . . . . . . . . . 42
4.7 Diagramme d’activité ≪S’authentifier≫ . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.8 Diagramme de classes du ≪ Sprint 1 ≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.9 Interface ≪ Authentification ≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.10 Interface ≪ Gestion des événements oculaires ≫ . . . . . . . . . . . . . . . . . . . . . . 45
4.11 Interface ≪ Chercher ophtlmologiste ≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1 Diagramme du cas d’utilisation du ≪ Sprint 2≫ . . . . . . . . . . . . . . . . . . . . . . 50

5.2 Diagramme du cas d’utilisation ≪ Gérer rendez-vous≫ . . . . . . . . . . . . . . . . . . 51
5.3 Diagramme du cas d’utilisation du ≪ Gérer dossier médical≫ . . . . . . . . . . . . . . . 52
5.4 Diagramme du cas d’utilisation du ≪ Envoyer message ≫ . . . . . . . . . . . . . . . . . 53
5.5 Diagramme de séquence ≪ Ajouter rendez-vous≫ ≫ . . . . . . . . . . . . . . . . . . . . 54
5.6 Diagramme de séquence du cas d’utilisation ≪ Consulter dossier médical≫ . . . . . . . . 54
5.7 Diagramme de séquence du cas d’utilisation≪ Envoyer message≫ . . . . . . . . . . . . 55
5.8 Diagramme d’activité ≪ Envoyer message ≫ . . . . . . . . . . . . . . . . . . . . . . . . 55
5.9 Diagramme de classe du ≪ Sprint 2 ≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.10 Interface≪ Ajouter rendez-vous ≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.11 ≪Gérer Consultation≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.12 Interface≪ Envoyer message ≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.13 ≪ Consultation en ligne≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.14 ≪Demander un rendez-vous ≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.1 Apprentissage supervisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.2 Principe de l’apprentissage supervisé . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.3 Classification supervisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.4 Les réseaux de neurones convolutifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.5 Conception du classificateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.6 Diagramme du cas d’utilisation ≪Analyser image radiologique ≫. . . . . . . . . . . . . 66
6.7 Diagramme de séquence ≪Analyser image radiologique ≫. . . . . . . . . . . . . . . . . 67
6.8 logo Tensorflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.9 logo Keras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.10 Maladie de Cataract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
ix
Table des figures
6.11 Maladie Glaucoma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.12 Maladie de Retinopathy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.13 Importation des bibliothèques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.14 Téléchargement de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.15 Nommage des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.16 Création du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.17 Former modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.18 Augmentation des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.19 Entrainer le modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.20 Préduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.21 Graphe de précision pour le modèle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.22 Graphe d’erreurs pour le modèle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.23 Interface ≪Gérer analyse ≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.1 Les réseaux de neurones artificiels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7.2 Diagramme de séquence ≪Discuter avec chatbot ≫. . . . . . . . . . . . . . . . . . . . . 79
7.3 Diagramme de séquence ≪Poser question ≫. . . . . . . . . . . . . . . . . . . . . . . . . 79
7.4 chargements des bibliothèques et des données . . . . . . . . . . . . . . . . . . . . . . . 81
7.6 Création des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.7 Construction du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.8 Interface utilisateur graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.9 Architecture d’un chatbot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
x
Liste des tableaux
1.1 Carte d’identité de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 les caractéristiques des certaines solutions existantes . . . . . . . . . . . . . . . . . . . 6
1.3 Comparaison entre les deux méthodes agiles SCRUM et XP . . . . . . . . . . . . . . . 10
1.4 Identifications des rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Le backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Description textuelle du cas ≪S’authentifier ≫ . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Description textuelle du cas ≪ Ajouter utilisateur ≫ . . . . . . . . . . . . . . . . . . . . 39
4.4 Description textuelle du cas ≪Consulter utilisateur≫ . . . . . . . . . . . . . . . . . . . . 39
4.5 Description textuelle du cas ≪ Supprimer utilisateur≫ . . . . . . . . . . . . . . . . . . . 39
4.6 Description textuelle du cas ≪ Ajouter événement≫ . . . . . . . . . . . . . . . . . . . . 40
4.7 Description textuelle du cas ≪ Consulter liste des événements ≫ . . . . . . . . . . . . . 40
4.8 Description textuelle du cas ≪ Modifier événement ≫ . . . . . . . . . . . . . . . . . . . 41
4.9 Description textuelle du cas ≪ Supprimer événement ≫ . . . . . . . . . . . . . . . . . . 41

5.2 Description textuelle du cas ≪ Ajouter rendez-vous ≫ . . . . . . . . . . . . . . . . . . . 51
5.3 Description textuelle du cas ≪ Modifier rendez-vous ≫ . . . . . . . . . . . . . . . . . . 51
5.4 Description textuelle du cas ≪ Annuler rendez-vous ≫ . . . . . . . . . . . . . . . . . . . 52
5.5 Description textuelle du cas ≪ Consulter dossier médical ≫ . . . . . . . . . . . . . . . . 52
5.6 Description textuelle du cas ≪ Envoyer message ≫ . . . . . . . . . . . . . . . . . . . . . 53
xi
Liste des abréviations
– CNN : Convolutional Neural Network.
– DNN : Deep Neural Network.
– DL : Deep learning.
– Http : Hypertext Transfer Protocol.
– IA : Intelligence Artificielle.
– kNN : k-nearest neighbors .
– MVC : Modèle/Vue/Contrôleur.
– NLP : Natural Language Processing.
– NLU : Natural Language Understanding.
– NLG : Natural Language Generation.
– REST :Representational State Transfer.
– SVM : Support Vector Machine.
– UML : Unified Modeling Language .
– Web Rtc : Web real-time communications.
– XP :Modèle/Vue/Contrôleur.
– XP : EXtreme Programming.
xii
INTRODUCTION GÉNÉRALE
Nous vivons dans une société où les nouveaux techniques et les systèmes informatisés ont rendu
facile la production et la diffusion d’informations. Il n’y a jamais eu auparavant autant de données aussi
facilement accessibles et à portée de main. Devant une telle profusion d’informations, le besoin non
seulement de stocker, mais également de traiter l’information est devenu croissant.
L’Intelligence Artificielle (IA) est l’une des révolutions scientifiques majeures de notre génération, om-
niprésente dans notre quotidien (voitures autonomes, moteurs de recherche. . .), elle tend aujourd’hui vers
la performance d’une médecine préventive et personnalisée. L’ophtalmologie est la spécialité médicale
qui utilise d’avantage l’intelligence artificielle, elle continue d’être une pionnière dans l’utilisation de
cette intelligence pour détecter, diagnostiquer et traiter différentes pathologies oculaires telles que le
glaucome, la dégénérescence maculaire liée à l’âge et la rétinopathie diabétique, ce qui peut faciliter au
patient l’accès aux soins et potentiellement soulager les problèmes du système de santé.
Dans cette même perspective et dans le cadre des projets de fin d’études, notre mission consiste à la
conception et la réalisation d’une application web intelligente qui permet de mettre l’organisation et
l’automatisation de l’administration d’un bureau d’ophtalmologie, d’accroı̂tre la fiabilité, de l’efficacité
des efforts humains et de faciliter des tâches difficiles dans le cabinet.
L’objectif de ce projet consiste à garantir une meilleure utilisation des services de clinique d’ophtal-
mologie tout en fournissons un ensemble d’outils d’organisation des soins tels que l’optimisation des
prises de rendez-vous d’urgence à travers la réalisation d’un chabot capable de répondre à la plupart des
questions des patients à tout moment de jour ou de nuit, de plus notre application fournisse la possibilité
d’effectuer des consultations à distance, ainsi qu’un outil intelligent qui propose une lecture des images
radiologique, qui renforce ou complète l’avis d’ophtalmologiste cela permet au ophtalmologiste de ne
pas passer à côté de complications ou traitements nécessaires, et ainsi éviter des traitements plus chers
plus tard.
Le présent rapport s’est évertué à rapporter la progression du travail élaboré et à détailler ses différentes
phases.
Il s’articule autour de sept chapitres :
Le premier chapitre représente une phase préparatoire de notre projet, dans le quel nous présentons notre
organisme d’accueil par la suite nous effectuons une présentation de notre projet et enfin nous entamons
le chapitre par la méthodologie adoptée.
Le second chapitre sera consacré pour la présentation de l’état de l’art.
Le troisième chapitre est dédié à l’analyse et la spécification des besoins dans le quel nous illustrons les
fonctionnalités de notre projet et présentons une conception globale.
le quatrième et cinquième chapitre seront consacrés à la réalisation des deux premiers sprints.
1
INTRODUCTION GÉNÉRALE
Les deux derniére chapitres détaillent l’utilisation de l’intelligence artificielle pour la conception et la
réalisation d’un système de détection des certaines pathologies oculaires ainsi que le développement
d’une entité conversationelle intelligente.
Enfin nous finissons notre rapport par une conclusion générale dans laquelle nous présentons notre travail
en bref et quelques perspectives.
2
Chapitre 1
Étude préalable
3
Chapitre 1. Étude préalable
1.1 Introduction
Ce chapitre sera dédié à la présentation générale du projet qui consiste à présenter l’entreprise d’ac-
cueil en premier lieu ainsi que les services offerts par cette dernière. Par la suite, nous s’intéressons à
l’étude de l’existant, à expliciter la problématique et à donner les objectifs qu’on souhaite atteindre. Il va
nous permettre aussi de mieux comprendre les problèmes posés par le sujet d’un point de vue organisa-
tionnel et technique.
1.2 Présentation de la société ≪ITgate-Group ≫

Dans cette section, nous présentons la société d’accueil ainsi que ses principales missions .
1.2.1 Profit de société
ITgate est une société d’ingénierie informatique, crée en 2015 spécialisée en développement et ser-
vices informatiques.
F IGURE 1.1 – Logo du Société
• Carte d’identité :
Nom de l’entreprise ITgate-Group

Domaine d’activité Développement informatique
Adresse 12 Rue Abdelkadeur Daghrir Hammam Sousse – Sousse 4011
Téléphone (+216) 73 325 001 / (+216) 54 161 325
Site web www.itgate-group.com
Adresse-mail [email protected]
TABLE 1.1 – Carte d’identité de la société
1.2.2 Missions principales
– Prendre de la hauteur pour concevoir votre projet de développement informatique de

manière globale.
– Vous inspirer d’exemples de projets que nous avons déjà réalisés
– Rédéfinir vos process de fonctionnement pour rationaliser vos flux de données
– Repenser les interactions entre vos différents collaborateurs pour gagner en efficacité.
4
– Proposer davantage de valeur ajoutée à vos clients en leur fournissant un espace client person-
nalisé.
1.3 Problématique
Pour terminer le cursus académique au sein de l’institut supérieur d’informatique et de gestion de
Kairouan, j’ai l’honneur d’effectuer le stage de projet de fin d’études dans la société Itgate-Group. Ce
projet est lancé suite à une demande de l’un des collaborateurs du Itgate-Group qui consiste à créer une
plateforme de gestion d’un cabinet d’ophtalmologie afin de faciliter les tâches du médecin ophtalmolo-
giste lors de son travail.
Cette plateforme permettra de lier les acteurs administration, ophtalmologiste, patient et les partenaires,
et d’avoir des données en temps réel sur l’état du patient avec un faible coût.
Elle permet de mettre fin à certains nombres de défaillances qui sont principalement :
– Une mauvaise organisation au niveau de la gestion des rendez-vous.
– Perte beaucoup de temps pour chercher un ophtalmologiste.
– La détection d’une certaine maladie oculaire peut prendre beaucoup de temps.
– Il n’y a pas une fiabilité de l’information.
– Il y a une perte de temps pour chercher l’information.
Le besoin d’une plateforme de gestion d’un cabinet d’ophtalmologie demeure plus que jamais indispen-
sable afin d’assurer une meilleure utilisation des services de clinique d’ophtalmologie.
1.4 Étude de l’existant

L’étude de l’existant permet de déterminer les points faibles et les points forts du projet pour pou-
voir déterminer les besoins du client, en vue d’en prendre en considération lors de la conception et la
réalisation. En effet parmi les solutions existantes on trouve :
1.4.1 OPHTEL :
OPHTEL est un logiciel de gestion de cabinet d’ophtalmologie le plus performant sur le marché ocu-
laire utilisé par les ophtalmologistes afin de mieux gérer leurs cabinets oculaires. Ce logiciel a pour but
d’assurer une meilleure qualité de service pour leur patient doté de plusieurs moyens pour perfectionner
la relation cabinet patiente tel que consultation et rendez-vous en ligne.
La figure 1.2 montre le logo du logiciel OPHTEL.
F IGURE 1.2 – Logo de OPHTEL
5
1.4.2 DrSanté :
DrSanté est une plateforme innovante qui permet de trouver rapidement le médecin le plus proche
chez vous et de prendre par la suite un rendez-vous en ligne gratuitement.
La figure 1.3 présente le logo de la solution DrSanté.
F IGURE 1.3 – Logo de DrSanté
1.4.3 Téo :
Téo est réservé pour la gestion des tâches journalières des médecins ophtalmologistes et qui orga-
nisent toutes les interactions avec les différents intervenants dans le secteur oculaires.
La figure 1.4 illustre le logo de l’application Téo.
F IGURE 1.4 – Logo de Téo
• Le tableau suivant décrire les caractéristiques de certaines solutions existantes.
caractéristiques OPHTEL DrSanté Téo

Le patient peut réserver lui- Oui
même un RDV.
Le patient peut mettre à jour Processus manuel(e-mail ou appel)
ou annuler une réservation.
Diagnostic de l’imagerie Absente
médicale à l’aide d’un
modèle intelligent.
Consultation et contrôle en Indisponible
ligne .
Chatbot Non présente
TABLE 1.2 – les caractéristiques des certaines solutions existantes
1.4.4 Critique de l’existant
La gestion de chaque cabinet d’ophtalmologie peut avoir quelques difficultés celles-ci peuvent se
résumer dans :
6
• Des problèmes de gestion des rendez-vous avec les patients.
• Le manque de confidentialité de l’information.
• La radio, principal outil de diagnostic des pathologies oculaires, manque parfois de précision, et l’ana-
lyse des résultats peut varier d’un ophtalmologiste à un autre.
• La détection d’une certaine maladie oculaire peut prendre beaucoup de temps.
• Recherche difficile sur les registres qui engendre une perte de temps.
• Mauvaise codification sur quelques objets dans la gestion d’information.
• Perte de données et de documents à cause du volume important des informations traitées.
• La difficulté et perte beaucoup de temps pour trouver un ophtalmologiste .
1.5 Solution proposée

Pour faire face aux limites citées dans la section précédente notre application consiste à développer
une application web pour faciliter les tâches pour l’ophtalmologiste et le patient.
Ainsi, notre solution doit fournir un service de pré-examen, de rendez-vous et d’évaluation de consulta-
tion tout en s’appuyant sur un outil de diagnostic permet une lecture intelligente des images radios, cette
technique donne des résultats très concrets pour l’ophtalmologiste.
En détectant certaines pathologies très tôt, on augmente la probabilité de rester sur des soins légers, on
évite donc les interventions plus invasives et chères, redoutées des patients.
De plus , notre application est associée à une entité conversationnelle qui s’occupe de l’orientation des
patients et de les répondre à leurs interrogations dans le domaine de l’ophtalmologie.
Notre application offre aussi la possibilité d’effectuer une consultation ou un contrôle médical à distance.
1.6 Objectifs du projet

Notre objectif sera donc la conception et le développement d’une application web intelligente qui
facilite les tâches des ophtalmologistes et des patients. Elle donne aux patients la possibilité de faire des
réservations des rendez-vous en ligne ainsi que la possibilité de faire des consultations et de contrôle à
distance, aussi elle les fournit un service de guidage et d’accompagnement à l’aide d’une entité conver-
sationelle intelligente capable d’aider les patients pour répondre à la plupart de ces questions.
Elle donne aussi au ophtalmologistes la capacité de détecter certaines maladies oculaires en s’appuyant
sur un système intelligent, de plus il permet d’avoir une gestion efficace des rendez-vous et des dossiers
médicaux.
L’application doit traiter quelques points qui sont très importants :
• Sécurité, elle doit fournir un espace bien sécurisé pour les patients.
• Gestion complète des dossiers des patients.
• Espace de contrôle contenu et de consultation à distance .
• Gérer le plan du traitement.
• Diagnostic rapide à l’aide d’un système intelligent.
• Détection de certaines maladies de façon plus efficace, ce qui permettra des traitements plus rapides et
adaptés.
7
• Entité conversationnelle reposante sur l’intelligence artificielle permet au patient d’obtenir des réponses
aux questions qu’il se pose, à toute heure du jour ou de la nuit.
• Organisation et suivie des rendez-vous .
• Organisent toutes les interactions avec les différents intervenants dans le secteur d’ophtalmologie.
1.7 Méthodologie de développement et langage de modélisation
1.7.1 Méthodologie de développement
La méthode de gestion de projets influence considérablement la réussite d’un projet informatique.

Les statistiques ont montré que plusieurs projets n’ont pas abouti suite à un problème lié à la gestion de
projet selon les facteurs coûts, délais et objectifs. Il y a plusieurs explications possibles à cela :
• Les besoins sont mal définis.
• Les tâches ne sont pas priorisées.
• Les estimations sont mauvaises.
• La communication entre le client et la maı̂trise d’œuvre est quasi inexistante.
• Les équipes sont stressées, démotivées, isolées.
• Il existe des difficultés à intégrer des modifications en cours de projet.
Ainsi, l’utilisation d’une méthode de développement bien appropriée, être réactif aux changements,
établir une relation solide avec ses clients, maintenir la motivation de son équipe et promouvoir l’in-
novation devient inévitable dans une société en perpétuel mouvement.
Il existe, en fait, des dizaines de méthodes de développement ayant chacune sa part d’utilisateurs fidèles,
témoigne du fait que nulle d’entre elles ne convient à tous les types d’applications.
Dans le cadre de la préparation de cette application, nous essayons d’étudier les méthodes les plus po-
pulaires qui sont les nombreuses variantes agiles, pour pouvoir choisir la méthode la plus adéquate à ce
projet.
1.7.1.1 EXtreme Programming
Extreme Programming est une méthode agile qui priorise l’excellence technique. Elle comporte un
ensemble de pratiques interdépendantes qui demandent beaucoup de rigueur, afin de puiser le maximum
d’efficacité des équipes de développement. L’XP repose sur quatre valeurs fondamentales : la communi-
cation, le courage, le retour d’information (feedback), la simplicité. Cette méthode est notamment basée
sur les concepts suivants :
• Les équipes de développement travaillent directement avec le client pour atteindre ses objectifs sur des
cycles très courts d’une à deux semaines maximums.
• L’équipe de développement travaille en collaboration totale sur la base de binômes.
• Le code est testé et nettoyé tout au long du processus de développement, ce qui garantit au produit un
niveau de robustesse très élevé.
L’EXtreme Programming repose sur des cycles rapides de développement (des itérations de quelques
semaines) dont les étapes sont les suivantes :
• Le client écrit ses besoins sous forme de scénarios.
8
• Les développeurs évaluent le coût de chaque scénario, en collaboration avec le client.
• Le client choisit les scénarios à intégrer à la prochaine livraison.
• Chaque développeur prend la responsabilité d’une tâche pour la réalisation d’un scénario.
• Le développeur choisit un partenaire.
• Le binôme écrit les tests unitaires correspondant au scénario à implémenter.
• Le binôme prépare l’implémentation en réorganisant le code existant, puis il procède à l’implémentation
proprement dite.
• Le binôme intègre ses développements à la version d’intégration.
1.7.1.2 La méthode SCRUM
SCRUM est un processus de contrôle empirique de développement logiciel. Il permet aux équipes de
produire des logiciels de manière itérative incrémentale afin d’optimiser la prévisibilité d’un projet et de
mieux contrôler les risques.
SCRUM identifie trois acteurs :
• Le product Owner (Propriétaire de produit) : représente le client et les utilisateurs au sein de son
équipe. Sa fonction principale et de s’assurer de la qualité du produit qui sera livré au client. Il est l’in-
termédiaire entre le client et les membres de son équipe. Il a également la responsabilité de gérer les
priorités dans le calendrier de produit.
• Le Scrum Master : est un membre de l’équipe. Il a la responsabilité de s’assurer la compréhension
de l’application et de la méthodologie Scrum. La compréhension de Scrum n’est pas compliquée mais
pour la mettre en pratique, c’est tout un défi. Il doit aussi veiller à ce que tous les objectifs des différents
évènements Scrum soient respectés. Il aide les équipes à identifier les obstacles pour ensuite les aider à
les surmonter dans le but de faire progresser les équipes.
• L’équipe de développement : les équipes sont composées afin d’avoir toutes les compétences nécessaires
au développement d’un projet. Elles doivent s’auto-organiser et choisir la façon dont le travail à faire sera
accompli. Il n’y a pas de concept de hiérarchie à l’intérieur d’une équipe, les décisions sont prises en-
semble.
– Les Étapes du flux Scrum :
• Product Backlog : liste de fonctionnalités à réaliser classées par ordre de priorité par le product owner
et évaluées par le scrum team.
• Estimation : troisième colonne sur les entrées du product backlog, quantité approximative de travail
nécessaire au développement de l’item déterminée par la Scrum team.
• Sprint : cycle de développement sous forme d’une itération généralement de 30 jours.
• Sprint Backlog : liste de tâches à accomplir pour réaliser un ensemble de fonctionnalités dénies dans
le product backlog, classées par ordre de priorité et évaluées par le scrum team.
• Sprint Planning Meeting : réunion de décision des objectifs du prochain sprint et de la manière de
les implémenter.
• Daily Scrum meeting : réunion d’environ 15 minutes où l’équipe vérifier les tâches réalisées, les
tâches en cours, les tâches non encore réalisées et les problèmes à régler.
Sprint Review Meeting : réunion ouverte où les personnes impliquées dans le projet évaluent les résultats
du sprint et propositions d’améliorations.
9
• Sprint retrospective meeting : réunion fermée pour les membres de l’équipe pour s’auto-évaluer et
proposer des améliorations.
1.7.1.3 Comparaison de deux méthodes
Dans cette section, nous présentons une étude comparative entre les différentes méthodes agiles ci-
dessus présentées. Le tableau suivant résume la comparaison entre les deux méthodes.
Caractéristiques SCRUM XP
Incréments très fins (scénario client,
Développement incrémental Durée d’un sprint (1 à 4semaines).
unité de spécification et de planification).
Développement itératif 1 mois MAX 2 semaines MAX .
Planification avec la ”valeur métier” Document de ”charte”
Justification
pour seul critère de priorité. (chartering document).
Haut : client impliqué,
Haut : client sur site,
Degré d’interaction réunions de SCRUM quotidiennes,
réunions de planification.
réunions de sprint.
Conception et architecture évolutives,
Aucune préconisation technique
intégration continue,
Principales différences (souvent couplé à XP),
binômage systématique,
auto- organisation.
rythme soutenable.
TABLE 1.3 – Comparaison entre les deux méthodes agiles SCRUM et XP
1.7.1.4 Méthodologie adoptée
La réalisation de cette application nécessite une stratégie de travail adaptative et un suivi périodique
en collaboration avec le client. De ce fait, on a décidé ensemble (encadreur académique et nous) d’adopter
Scrum comme une méthode de travail. La figure suivante illustre la méthodologie Scrum.
F IGURE 1.5 – La méthodologie scrum
• Identifications des rôles :
Product Owner Scrum Master Scrum Team

Riad BOUZID Houssem ANGOUD Mariem HAMMEDI
TABLE 1.4 – Identifications des rôles
10
1.7.2 Langage de modélisation adopté
Pour la modélisation de la conception, nous avons choisi le langage UML.

UML (Unified Modeling Language), que l’on peut traduire par ≪ langage de modélisation unifié≫ : est
une notation permettant de modéliser un système de façon standard. Ce langage est né de la fusion de
plusieurs méthodes existantes auparavant, et est devenu la référence en matière de modélisation objet.
UML peut être associé à toute démarche de conception du système informatique à n’importe quelle étape
de la démarche et avec différents environnements de programmation.
Pour la conception de notre application, nous avons exploité plusieurs diagrammes d’UML tels que :
diagramme de cas d’utilisation, de classe, de séquence, d’activité et le diagramme de déploiement.
1.8 Conclusion
Dans ce chapitre nous avons essayé de présenter le cadre général de notre projet à travers une des-
cription de notre sujet proposé en mettant en relief la problématique et la solution envisagée. En outre,
nous avons spécifié la démarche du travail adoptée dans le reste du rapport en choisissant le modèle de
cycle de vie Scrum comme étant la méthode de modélisation suivie.
11
Chapitre 2
État de l’art
12
Chapitre 2. État de l’art
2.1 Introduction
Dans ce chapitre, nous allons présenter l’état de l’art que nous avons effectué pour voir jusqu’à quel
l’intelligence artificielle point peut être un outil puissant pour améliorer la précision des diagnostics dans
le domaine de la médecine oculaire
2.2 Intelligence Artificielle (IA)
2.2.1 Définition de l’intelligence artificielle
L’IA c’est tout simplement des machines intelligentes qui vont agir comme des êtres humains.
L’avantage d’avoir des machines intelligentes, c’est qu’elles accomplissent leurs tâches avec plus de
rapidité et plus efficacement qu’un humain. Aujourd’hui, les machines intelligentes savent agir comme
un humain, mais n’ont pas de conscience. Avec les avancées technologiques, il se pourrait qu’elles ob-
tiennent une conscience, de la sensibilité voire même un esprit. L’intelligence artificielle est un vaste
sujet qui regroupe le Machine Learning (ML) et le Deep Learning (DL), on peut le représenter comme
l’image suivante :
F IGURE 2.1 – L’intelligence artificielle
* Machine learning
Le concept de machine learning réside dans le fait d’entraı̂ner la machine avec un certain nombre
de données qui lui permettront par la suite d’exécuter différentes tâches sans intervention hu-
maine. L’avantage du ML, c’est que nous évitons de faire du code trop compliqué et par la suite,
la machine apprendra toute seule à l’aide de nos données. Plus la machine possède des données
et plus la machine saura agir d’elle-même.
* Deep learning
Le Deep Learning est un concept de l’intelligence artificielle qui va agir comme un cerveau hu-
main. Nous pouvons dire que la machine va apprendre à l’aide de neurones qui vont se regrouper
pour lui permettre de comprendre ce qu’elle voit ou lit.
2.2.2 L’intelligence artificielle dans la médecine
L’intelligence artificielle est omniprésente, elle trouve des applications intéressantes notamment dans
le domaine de la santé. Les données médicales sont une ressource précieuse pour prédire la maladie,
diagnostiquer une pathologie ou améliorer le suivi des patients . L’intelligence artificielle est en effet au
13
cœur de la médecine du futur, avec des opérations assistées, un suivi des patients à distance, des lentilles
intelligentes, et des traitements personnalisés grâce au recoupement de plus en plus de données. Elle est
conçue pour aider les professionnels à améliorer l’efficacité, la productivité et la cohérence de la qualité
des soins aux patients.
2.2.3 L’intelligence artificielle dans la médecine d’ophtalmologie
Au cours des deux dernières décennies, le monde a réalisé d’énormes progrès technologiques et
a affecté de nombreux aspects de la vie humaine. La santé oculaire bénéficie également des avancées
technologiques. Les lentilles intelligentes,lasers,injections oculaires. Le prochain grand sujet en ophtal-
mologie est l’application de l’intelligence artificielle au diagnostic et au traitement, et c’est ce qui on va
l’intéresser dans notre application a travers la réalisation d’un système de diagnostic intelligent capable
de détecter certaines pathologies oculaires. La médecine d’ophtalmologie se présente donc comme un
excellent champ d’application pour l’IA sans parler des outils d’organisation des soins tels que l’optimi-
sation des prises de rendez-vous d’urgence avec un agent coversationel et une salle d’attente virtuelle ou
encore le suivi ambulatoire personnalisé des patients avec assistant virtuel.
2.2.3.1 Système de détection des pathologies oculaires
Un système de détection des pathologies oculaires est une technologie conçue pour identifier et diag-
nostiquer divers problèmes de santé liés aux yeux. Ces systèmes utilisent généralement des techniques
d’imagerie médicale et d’analyse des données pour détecter des anomalies ou des signes de maladies
oculaires.
2.2.3.2 Définition d’un chatbot
Un chabot est un robot qui joue un rôle d’un assistant personnel disponible 24h/24 et 7j/7, il sait
reconnaı̂tre des questions posées par vos contacts après l’entraı̂ner à donner les bonnes réponses, il peut
proposer des différents choix pour préciser une question, il peut alimenter une conversation pour arriver à
la bonne information et il s’améliore chaque jour, ses réponses sont de plus en plus précises et vous êtes de
nouveau disponible pour les réponses personnalisées. Un chabot est un programme informatique capable
de simuler une conversation avec un utilisateur par échange vocal ou textuel et grâce à un enclenché à
l’encontre d’un signal ou d’une donnée il est capable de répondre aux besoins en utilisant l’intelligence
artificielle(IA) et le traitement du langage naturel (NLP).
* Types de chatbot
Actuellement, trois types de chatbots cohabitent.
– Les chatbots basiques :élaborés à base de simples arbres de décision, permettent d’avancer dans sa
demande à travers une série de questions proposées par le bot.
– Les chatbots intelligents : comprennent le langage naturel et sont dotés d’intelligence artificielle.
– Les chatbots hybrides : Les chatbots hybrides : mêlant scripts et IA avec parfois un renvoi à l’hu-
main sur des cas plus complexes.Aucune catégorie n’est meilleure qu’une autre.
14
* Comment ça marche
– Principe de base d’un chabot : recevoir un message et y répondre par un autre message .
– Un message peut être de plusieurs natures .
– L’envoi de messages se fait via une interface (connue ou non), mais en réalité l’interface ne fait
qu’analyser le message au chatbot.
F IGURE 2.2 – Principe de base d’un chatbot
* Chatbot et l’intelligence artificielle

Un chatbot est un logiciel qui peut communiquer avec les gens via des solutions de chat, et comprendre
leurs demandes, apporter des réponses ou initier des opérations en langage naturel par le biais d’un ap-
prentissage initial et d’une formation continue. Agent de chat, également connu sous le nom d’agent vir-
tuel. Ils utilisent des bibliothèques de questions-réponses, mais leur compréhension et leurs compétences
sont très limitées. Désormais, grâce aux avancées de l’intelligence artificielle, de l’analyse sémantique et
de la connectivité des systèmes d’information, les chatbots peuvent analyser et comprendre des requêtes
complexes tout en apprenant de leurs erreurs.
* L’utilité d’un chatbot
Le bot est configuré pour aider l’utilisateur à trouver des informations plus rapidement, plutôt que d’avoir
à les rechercher lui-même. Si son utilisation ne fait pas gagner du temps, les utilisateurs ne s’y tourneront
pas, et la construction de chatbots sera inutile. Il existe différents types de chatbots sur internet et les
réseaux : ceux qui utilisent l’intelligence artificielle et ceux qui n’en utilisent pas. Ce sont ces deux
catégories que nous allons analyser dans ce chapitre.
* Chatbot sans intelligence artificielle
Les robots qui n’utilisent pas l’IA répondent aux utilisateurs à l’aide de commandes qui commencent par
un ≪ ! ≫ suivi de l’information qui amène la réponse à la question voulue. Un des inconvénients dans le
fait de ne pas avoir d’intelligence artificielle, c’est qu’il est nécessaire de connaı̂tre les commandes par
cœur ou de chercher dans l’index proposé avec toutes les actions possibles.
L’exemple de Twitch : Étant un grand fan de jeux-vidéos, j’ai pu constater que sur Twitch (un ser-
vice de streaming et de VOD de jeu vidéo), les streamers utilisent souvent un chatbot pour répondre à
leurs supporters. Notamment, pour les questions les plus fréquentes, pour faire de la publicité pour leurs
marchandises ou celles de leurs sponsors.
15
* Chatbot avec intelligence artificielle

L’utilité de parler à un agent conversationnel, c’est qu’il va essayer de comprendre l’intention et d’y
répondre. C’est une discussion entre humain et machine, le créateur aimerait rendre la machine aussi
vivante qu’un être humain . À titre d’exemple on peut parler sur les voitures intelligentes.
Voitures intelligentes : Les voitures de nos jours sont de plus en plus intelligentes. En prenant exemple
sur la marque Mercedes, le créateur a utilisé DialogFlow pour rendre leurs voitures intelligentes.
2.2.4 L’objectif d’un chatbot dans notre application
Dans le domaine de la santé, les chatbots ont deux finalités principales : la première est de trans-
mettre des finalités non commerciales telles que le conseil, l’accompagnement au traitement, voire le
diagnostic. Contrairement à la première partie, la seconde partie implique des chatbots qui jouent un rôle
commercial. Le chatbot que nous avons créé dans l’application joue le rôle d’un conseiller et d’un guide
qui permet d’aider les patients et de répondre à la plupart de ces questions dans le domaine de l’ophtal-
mologie.
• Orienter les patients qui ne savent pas où et quand ils doivent aller consulter un ophtalmologiste.
• Il offre une réponse 24h/24 et 7j/7
• Améliorer l’information sur le bon usage des médicaments .
• Offre des solutions pour des problèmes médicaux plus simples.
• Accompagnement des patients dans leur quotidien.
2.2.5 Les approches techniques pour créer une IA conversationnelle
Il y a plusieurs approches mais dans notre cas nous mettons en œuvre seulement deux approches les
plus reconnus.
* Chatbots basés sur la récupération :
Un chatbot basé sur la récupération utilise des modèles d’entrée et des réponses prédéfinis. Il utilise en-
suite un type d’approche heuristique pour sélectionner la réponse appropriée.
F IGURE 2.3 – Chatbots basés sur la récupération
* Chatbots génératifs :
Les modèles génératifs ne sont pas basés sur certaines réponses prédéfinies. Ils sont basés sur des réseaux
de neurones seq 2 seq. C’est la même idée que la traduction automatique. En traduction automatique,
16
nous traduisons le code source d’une langue vers une autre langue mais ici, nous allons transformer une
entrée en une sortie.Il a besoin d’une grande quantité de données et est basé sur des réseaux Deep Neural.
F IGURE 2.4 – Chatbots génératifs
2.3 Conclusion
Ce chapitre de l’état de l’art nous a permis de prendre conscience de l’impact transformateur de
l’intelligence artificielle sur la médecine moderne et nous laisse entrevoir un avenir prometteur où la
technologie et la compassion se conjuguent pour préserver la santé. Dans la suite du rapport, et pour avoir
une bonne compréhension du travail et des besoins des utilisateurs, nous devons accomplir une étude
approfondie du sujet en exposant une spécification détaillée des besoins fonctionnels et non fonctionnels
dans notre application.
17
Chapitre 3
Analyse et spécification des besoins
18
Chapitre 3. Analyse et spécification des besoins
3.1 Introduction
Après avoir précisé l’état de l’art dans le chapitre précédent, dans le présent chapitre, nous commençons
par l’analyse et l’extraction des besoins fonctionnels et non fonctionnels de notre application. Ensuite,
nous présentons les acteurs réactifs du système ainsi que leur diagramme de cas d’utilisation général,
diagramme des classes d’analyse globale et le diagramme de déploiement.
De plus nous allons présenter le backlog produit et planifier les sprints. À la fin de ce chapitre nous
présentons l’architecture de notre application, puis les langages et les outils de programmation utilisés.
3.2 Capture des besoins

Cette partie est primordiale dans la conception de notre solution où on va étudier les exigences
fonctionnelles et non fonctionnelles du système.
3.2.1 Identification des besoins fonctionnels
Les besoins fonctionnels d’un système décrivent à quoi sert le système réellement, en d’autres termes,
ce que le système offre à ses utilisateurs. Dans cette partie, nous allons lister les besoins de notre appli-
cation à partir desquels nous allons identifier les différents acteurs.
Nous allons découper les besoins fonctionnels de notre système par cas d’utilisation.
En effet l’application de gestion de cabinet d’ophtalmologie ≪ EyeCare ≫ doit offrir les fonctionnalités
de base suivantes.
19
Fonctionnalité Description
Cette fonctionnalité permet à :
S’authentifier – Tous les utilisateurs (Administrateur, Ophtalmologiste,
Partenaire, Patient) de s’authentifier.
Gérer les utilisateurs. – L’administrateur d’ajouter, modifier , supprimer ou de
consulter la liste des utilisateurs.
– Tous les utilisateurs (Administrateur, Ophtalmologiste,
Gérer compte .
Partenaire, Patient) de consulter ou de modifier leurs profils ,
ainsi que de créer ou désactiver un compte.
Cette fonctionnalité permet au :
– Administrateur d’ajouter, modifier, ou supprimer des événements
Gérer les événements
oculaires.
oculaires.
– Ophtalmologiste de consulter la liste des événements oculaires .
Gérer les rendez-vous. – Ophtalmologiste d’ajouter, modifier ou annuler un rendez-vous.
– Patient de demander un rendez-vous.
– Ophtalmologiste de remplir les informations du patient
Gérer les patients .
et les observations médicales notées par l’ophtalmologiste , ainsi que de
l’ajouter, modifier ou de le supprimer.
20

– Ophtalmologiste d’enregistrer les ordonnances,
Gérer les consul-
les différents diagnostics, ainsi que les certificats, cette consultation
tations.
peut être présentielle ou à distance.
Gérer Analyse . – Ophtalmologiste d’ajouter une analyse tout en s’appuyant
sur un système intelligent permet la détection du certains maladie oculaire .
Gérer les ordon- – Ophtalmologiste d’ajouter, de consulter ou bien supprimer une ordonnance .
nances – Patient de consulter la liste des ordonnances médicales .
Gérer les certifi- – Ophtalmologiste d’ajouter, de consulter
cations médicales. ou bien supprimer une certification médicale.
Gérer les dossiers – Ophtalmologiste de mettre à jour le dossier médical qui comprend
médicaux. l’historique des interventions médicales subis par les patients.
Système de
– Ophtalmologiste de diagnostiquer une image radiologique.
détection des ma-
ladies oculaires.
Agent conversa-
– Patient de poser une question et de trouver des réponses.
tionelle.
TABLE 3.1 – Les besoins fonctionnels
3.2.2 Identification des besoins non fonctionnels
Les besoins non fonctionnels, couvrent toutes les exigences qui ne sont pas prises par les besoins
fonctionnels. Ils spécifient les critères qui évaluent le fonctionnement de notre système qui sont les
suivants :
– Authentification : le système doit permettre une authentification sécurisé à ses utilisateurs selon leurs
rôles.
– Ergonomie : notre application doit offrir aux utilisateurs des interfaces conviviales et interactives
dans le but de garantir plus de facilité d’utilisation, et cela en respectant la charte graphique.
– Sécurité : la sécurité est une exigence majeure pour le bon déroulement de l’intégralité du système.
– Performance : les retards de réponse dus au fonctionnement du système doivent être minimales.
– Extensibilité : l’application doit être développée d’une façon modulaire afin d’assurer que l’ajout des
nouvelles fonctionnalités soit toujours possible et facile.
– La confidentialité : l’application devra assurer la confidentialité de données des utilisatueurs.
21
3.3 Identifications des acteurs et des cas d’utilisation
Notre application introduit la notion des rôles qui assure l’affectation des responsabilités des acteurs
selon les profils privilégiés.
Nous intéressons dans notre module à quatre acteurs ;
* Administrateur :
– Il gère surtout les profils décrivant les droits d’accès.
– L’administrateur aura la possibilité de manipuler les profils des utilisateurs en leur ajoutant, supprimant
des droits ou même créant des nouveaux.
– Gérer les événements oculaires.
* Ophtalmologiste :
– Il peut être lui-même l’administrateur.
– Il peut gérer les consultations quelque soit en ligne ou à distance , peut ajouter, modifier ou supprimer au
niveau la gestion des ordonnances,la gestion des certifications médicales, la gestion de dossier médical,
et La gestion des fiches des patients.
– Analyser les imageries médicales à l’aide d’un système intelligent.
– Consulter événement.
– Ajouter ou annuler un rendez-vous.
– Chercher un partenaire.
– Contacter un partenaire.
* Patient :
– Il peut accéder au planning des visites afin de demander un rendez-vous.
– Il peut faire une consultation en ligne.
– Il peut chercher un ophtalmologiste.
– Il peut discuter avec une entité conversationnelle.
* Partenaire :
– Il peut contacter un ophtalmologiste .
3.4 Modélisation des besoins

Dans cette partie, nous allons étudier les besoins de notre projet de manière conceptuelle, donc nous
présentons le diagramme de cas d’utilisation ainsi que le diagramme de classes global.
3.4.1 Diagramme de cas d’utilisation global
Après avoir mentionné les fonctionnalités de notre application, nous modélisons ces derniers via un
diagramme de cas d’utilisation global. L’utilité de ce diagramme est d’expliquer et simplifier les acteurs
et les besoins du projet, tous les cas d’utilisation nécessitent une authentification.
La figure ci-dessous illustre le diagramme de cas d’utilisation global.
22
F IGURE 3.1 – Diagramme de cas d’utilisation global
3.4.2 Diagramme de classes global
Après avoir représenté l’ensemble des cas d’utilisation, maintenant nous passons au diagramme de
classes qui présente une modélisation statique de notre système en terme des classes et les relations entre
eux.
Ce diagramme représente les classes nécessaires pour assurer le bon fonctionnement du système à mettre
en œuvre.
la figure ci-dessous illustre le diagramme de classes global.
23
F IGURE 3.2 – Diagramme de classes global
3.5 Pilotage de projet avec ≪ scrum ≫

Dans cette section nous allons présenter le backlog de produit ainsi que la planification des sprints.
3.5.1 Backlog de produit
Le backlog de produit est le point important dans tout projet Scrum, il va permettre de planifier les
sprints et de prioriser les attentes et les besoins du client. Le tableau 2.2 représente le backlog de produit.
Ce tableau est une liste ordonnée qui énumère les fonctionnalités, qui soient traduites dans celui-ci par
des ≪ user stories ≫. Où :
– Id : Représente l’identifiant du user story ;
– Items : Représente l’ensemble de nos fonctionnalités ;
– La priorité : Est affectée selon la valeur métier et l’ordre de réalisation, ou le chiffre 1 désigne
≪ ≫
la priorité la plus élevée.

Le produit Backlog de notre application se présente comme le suit :
24
Le backlog de produit
ID Items Périorité[1..5]
1 Authentification . 1
2 Gestion des utilisateurs. 2
3 Gestion de compte . 3
4 Gestion des événements oculaires. 5
5 chercher 1
6 Gestion des fiches patients. 2
7 Gestion des rendez-vous. 1
8 Gestion des consultations. 2
9 Appel vidéo . 2
10 Messagerie . 2
11 Réalisation d’un système de détection des maladies oculaires. 1
12 Agent conversationelle. 2
TABLE 3.2: Le backlog de produit
3.5.2 Planification des sprints
La planification des sprints dans le processus Scrum est l’une des étapes les plus importantes. Elle
sert à planifier le travail à réaliser au cours du sprint, après une réunion avec l’équipe. Dans notre cas,
nous avons réparti notre projet en cinq sprints, chaque sprint est de durée de 4 semaines. Le tableau
suivant présente la planification des sprints :
25
Sprint User Story Estimation
Sprint 0 -Préparation de l’environnement de travail . 30 jours
-Compréhension de sujet.
Sprint 1 -Authentification. 30 jours

-Gérer compte.
-Gérer les utilisateurs.
-Gérer les événements.
-Recherche.
Sprint 2 - Gérer les rendez-vous 30 jours
- Gérer les ordonnances.
- Gérer les certifications médicales.
- Gérer fiche patient.
-Gérer les dossiers médicaux.
-Appel vidéo.
-Messagerie.
Sprint 3 -Système intelligent de détection de certaines pa- 30 jours
thologies oculaires.
Sprint 4 -Agent conversationelle. 30 jours
TABLE 3.3 – Planification des sprints
3.6 Diagramme de déploiement

Un diagramme de déploiement est une vue statique qui sert à représenter l’utilisation de l’infrastruc-
ture physique par le système et la manière dont les composants du système sont répartis ainsi que leurs
relations entre eux.
Notre système contient :
• Le serveur web qui contient le spring boot.
• Un serveur de base de données contient le système de gestion des bases de données MySQL.
• Flask est un micro framework open-source de développement web en Python.
La figure 2.3 présente le diagramme de déploiement de notre application.
F IGURE 3.3 – Diagramme de déploiement
26
3.7 Architecture de l’application
L’architecture d’application donne une vision globale de notre application en représentant les com-
posants et les interactions entre eux, elle est répartie en 3 couches.
Un site web qui permet au patient de chercher un ophtalmologiste, de prendre un rendez-vous et d’inter-
agir avec un agent conversationnel ainsi que la préinscription en ligne.
Une partie intelligente qui contient un système intelligent de détection de certaines pathologies oculaires.
La figure ci-dessous illustre l’architecture globale de notre application .
F IGURE 3.4 – L’architecture globale de la solution
3.7.1 Architecture logique :
L’architecture logique donne une vision globale de notre application en représentant les composants
et les interactions entre eux, La figure ci-dessous illustre notre architecture logique.
F IGURE 3.5 – L’architecture logique
3.7.2 Architecture physique :
L’architecture physique de notre application comme illustrée dans la figure suivante comporte les
serveurs suivants :
• Le serveur de base de données MySQL.
• Flask est un micro framework open-source de développement web en Python.
27
F IGURE 3.6 – L’architecture physique
3.8 Environnement de travail

Cette étape représente la partie pratique du projet, elle est destinée à la description de l’environnement
matériel et logiciel qui est utilisé pour développer la production de l’application.
3.8.1 Environnement matériel
Pour mener à terme de la réalisation, nous avons utilisé comme environnement matériel, une machine
dont les configurations sont les suivantes :
Système d’exploitation Windows 10 professionnel (64bits)

Processeur Un processeur Intel(R) core (TM) i7-3520M CPU
@ 2.90GHz 2.90 GHz
Mémoire vive 12GO
Marque Hp
TABLE 3.4 – Environnement matériel
la figure suivante présente l’image de l’ordinateur qu’on a utilisé :
F IGURE 3.7 – PC HP
3.8.2 Outil de conception
Pacestar UML : : est un logiciel de modélisation UML (langage de modélisation unifié) open source
peut remplacer dans de nombreuses situations logicielles commerciales et coûteuses comme Rational
Rose1. Étant facile à utiliser, nécessitant peu de système de capteurs, en soutenant UML 2, ce logiciel
est une excellente option pour une familiarisation de modélisation. La figure suivante présente le logo
Pacestar Uml.
28
F IGURE 3.8 – Logo Pacestar UML
3.8.3 Outil de gestion de projet et de collaboration
Trello : C’est un outil de gestion de projet en ligne, lancé en septembre 2011 et inspiré par la méthode
Kanban de Toyota. Il est basé sur une organisation d’une liste de projets de planche, chacune des tâches
qu’ils représentent. La figure suivante présente le logo de l’outil Trello.
F IGURE 3.9 – Logo Trello
3.8.4 Environnement de développement
Dans cette sous-section, nous présentons l’environnement de développement que nous avons utilisé
afin de réaliser notre application.
– Visual Studio Code : Visual Studio Code est un éditeur de code source développé par Microsoft
pour windows, linux et macOS. Il inclut la prise en charge du débogage, du contrôle git intégré et de
GitHub, de la coloration syntaxique, de la complétion intelligente du code, des extraits de code et de la
refactorisation du code. La figure suivante illustre le logo de l’éditeur de code extensible (Visual Studio
Code).
F IGURE 3.10 – Logo Visual Studio Code
3.8.5 Outils de bases des données :
– MySQL : est un système de gestion de bases de données relationnelles (SGBDR). Il fait partie des
logiciels de gestion de base de données les plus utilisés au monde .La figure suivante présente le logo
Mysql.
29
F IGURE 3.11 – Logo MySQL
– PHPMyadmin : est une application écrite avec PHP. Celle-ci permet d’administrer, depuis un
navigateur, des bases de données de type MySQL.
F IGURE 3.12 – Logo phpmyadmin
3.8.6 Technologies utilisées
Dans cette partie, nous décrivons les différentes technologies utilisées pour implémenter notre appli-
cation.
– Spring boot :Java Spring Boot est un outil open source qui facilite l’utilisation de frameworks basés
sur Java pour créer des micro-services et des applications Web. La figure suivante présente le logo Spring
boot.
F IGURE 3.13 – Logo Spring boot
– Angular : est un Framework côté client open source basé sur TypeScript dirigée par l’équipe du
projet Angular à google et par une communauté de particuliers et de sociétés. La figure suivante présente
le logo du framework Angular.
F IGURE 3.14 – Logo Angular
– Kaggle : Kaggle est une plateforme populaire pour la compétition en science des données. Elle met
en relation des data scientists avec des organisations qui ont besoin d’aide pour résoudre des problèmes
de données. Les organisations publient des défis sur Kaggle, et les scientifiques des données s’affrontent
pour les résoudre. La figure suivante présente le logo Kaggle.
30
F IGURE 3.15 – Logo Kaggle
– Google colab :Colaboratory, souvent raccourci en ”Colab”, est un produit de Google Research.
Colab permet à n’importe qui d’écrire et d’exécuter le code Python de son choix par le biais du naviga-
teur. C’est un environnement particulièrement adapté au machine learning, à l’analyse de données et à
l’éducation. La figure suivante présente le logo Google colab .
F IGURE 3.16 – Logo Google colab
– Python : est un langage de programmation objet, multi-paradigme et multiplate-forme. Il favorise

la programmation impérative structurée, fonctionnelle et orientée objet. La figure suivante présente le
logo du langage de programmation Python.
F IGURE 3.17 – Log Python
– Flask : est un framework de développement web qui se veut minimaliste, et qui confère à son
utilisateur une liberté de conception, très appréciable pour réaliser une API. Flask repose sur le protocole
WSGI (web server gateway interface), qui permet d’interfacer l’application Python (notre API) et le ser-
veur HTTP.
F IGURE 3.18 – Logo Api Flask
– Web Rtc (Web real-time communications) : est une technique qui permet aux applications et
sites web de capturer et éventuellement de diffuser des médias audio et/ou vidéo, ainsi que d’échanger
des données arbitraires entre les navigateurs sans passer par un intermédiaire. L’ensemble de normes qui
comprend WebRTC permet de partager des données et d’effectuer des téléconférences peer-to-peer, sans
exiger que l’utilisateur installe des plugins ou tout autre logiciel tiers.
31
On a utilisé cette technique qui permet d’assurer la communication via un appel vidéo pour que l’oph-
talmologiste et le patient puissent effectuer une consultation en ligne.
F IGURE 3.19 – Architecture p2p
– Bootstrap : est une collection d’outils utiles à la création du design (graphisme, animation et
interactions avec la page dans le navigateur, etc.) des sites et d’applications web.
La figure suivante présente le logo de Bootstrap.
F IGURE 3.20 – Logo Bootstrap
– Postman : en tant qu’application autonome ou extension Google Chrome, Il permet de tester et de

consommer des services web afin de mieux comprendre la structure des données reçues.
La figure suivante présente le logo de Postman.
F IGURE 3.21 – Logo Postman
– REST (Representational State Transfer) : est un protocole qui constitue un style architectural et
un mode de communication fréquemment utilisé dans le développement de services Web. C’est un style
d’architecture sans état qui base sur le protocole http.
La figure suivante illustre le logo REST.
F IGURE 3.22 – Logo REST
32
– Patron de Conception MVC : l’architecture Modèle/Vue/Contrôleur (MVC) est une façon d’or-
ganiser une interface graphique d’un programme. Elle consiste à distinguer trois entités distinctes qui
sont, le modèle, la vue et le contrôleur ayant chacun un rôle précis dans l’interface. L’organisation glo-
bale d’une interface graphique est souvent délicate. Bien que la façon MVC d’organiser une interface
ne soit pas la solution miracle, elle fournit souvent une première approche qui peut ensuite être adaptée.
Dans l’architecture MVC, les rôles des trois entités sont les suivants :
Modèle : données (accès et mise à jour).
Vue : interface utilisateur (entrées et sorties).
Contrôleur : gestion des événements et synchronisation.
Les différentes interactions entre le modèle, la vue et le contrôleur sont résumés par l’exemple de la
figure suivante :
F IGURE 3.23 – Architecture MVC
3.8.7 Outil de rédaction :
Overleaf : est un système collaboratif d’écriture et d’édition qui rend l’ensemble du processus de
production de documents universitaires beaucoup plus rapide pour les auteurs et les éditeurs. C’est un
service gratuit qui permet de créer, éditer et partager des idées scientifiques facilement en ligne en utili-
sant Latex, qui est un langage et un système de composition de documents. La figure suivante présente
le logo Overleaf.
F IGURE 3.24 – Logo Overleaf
3.9 Conclusion
Tout au long de ce chapitre nous avons présenté en premier lieu les besoins fonctionnels et non
fonctionnels de notre projet. Puis, nous avons présenté en second lieu les acteurs de notre système tout
en spécifiant les différentes interactions entre eux dans le diagramme de cas d’utilisation globale. Par la
33
suite, nous avons réussi à présenter les différents environnements de développement matériel et logiciel
ainsi que l’architecture de notre projet. Dans le chapitre suivant nous détaillons le premier sprint.
34
Chapitre 4
Implémentation du Sprint 1
35
Chapitre 4. Implémentation du Sprint 1
4.1 Introduction
Le sprint représente une itération ou le cycle de développement de Scrum, généralement il dure deux
ou trois semaines, il commence par un sprint planning et se termine par un sprint review. Avant le lance-
ment d’un sprint, l’équipe de développement et le product Owner doivent déterminer le but de ce dernier
et après une discussion nous avons précisé les modules à développer dans ce sprint :
Entamer la partie authentification sécurisée, gestion d’utilisateurs, gestion de compte, gestion des événements
oculaires, et la fonctionnalité recherche, ensuite nous allons détailler la conception globale du sprint.
4.2 Backlog du sprint 1

Le Backlog du sprint est une liste des tâches que l’équipe Scrum doit réaliser durant le sprint dans le
but de transformer un ensemble d’éléments dans une version préliminaire du produit fini répondant aux
exigences prédéfinies. Le tableau ci-dessous regroupe toutes les fonctionnalités qui seront développées
au sein du premier sprint.
Sprint 1
ID Items User-stories Périorité
1 Authentification En tant qu’utilisateur, je peux m’authentifier . 1
2 En tant qu’ administrateur, je peux ajouter des uti- 2
lisateurs .
3 En tant qu’administrateur, je peux consulter la liste 2

des utilisateurs et je peux les modifier.
Gestion des utilisa-
teurs.
4 En tant qu’administrateur, je peux supprimer des 2
utilisateurs.
5 En tant qu’utilisateur, je peux créer un compte . 3
6 En tant qu’utilisateur, je peux mettre à jour mon 3

profil.
Gestion de compte
.
7 En tant qu’utilisateur, je peux modifier mon mot de 3
passe.
8 En tant qu’utilisateur, je peux désactiver mon 3

compte.
9 En tant qu’administrateur, je peux ajouter un 5
événement oculaire.
36
10 En tant qu’administrateur, je peux consulter la liste 5

des événements oculaires.
Gestion des
événements ocu-
laire.
11 En tant qu’administrateur,je peux supprimer un 5
12 En tant qu’administrateur,je peux modifier un 5

13 En tant que ophtalmologiste ,je peux consulter un 5

14 En tant que patient, je veux chercher un ophtalmo- 1
logiste .
chercher
15 En tant que ophtalmologiste, je peux chercher un 1
partenaire.
TABLE 4.1: Backlog du sprint 1
4.2.1 Diagramme du cas d’utilisation du sprint 1 :
Le diagramme de cas d’utilisation nous présente les principales fonctions du système, ainsi que les
acteurs qui interviennent.
La figure suivante illustre le diagramme du cas d’utilisation du premier sprint.
F IGURE 4.1 – Diagramme du cas d’utilisation global du ≪ Sprint 1≫
37
4.2.2 Description détaillée des principaux cas d’utilisations
Maintenant nous allons présenter une description détaillée des principaux cas d’utilisations.
* Diagramme du cas d’utilisation ≪ Authentification≫
La figure 3.2 présente le diagramme du cas d’utilisation ≪authentification≫.
F IGURE 4.2 – Diagramme du cas d’utilisation du ≪Authentification≫
* Description textuelle du cas d’utilisation ≪S’authentifier ≫
CU S’authentifier
Acteur Utilisateur (Administrateur,Ophtalmologiste, Patient, Partenaire)
Pré-condition L’utilisateur doit avoir un compte.
Post-condition Utilisateur authentifié.
Scénario nominal 1. L’utilisateur consulte la page d’authentification.
2. L’utilisateur saisit son email et son mot de passe.
3. L’utilisateur clique sur le bouton connexion.
4. Le système vérifie la validité des données saisies.
5. Le système vérifie l’existence d’utilisateur.
6 .Le système réoriente l’utilisateur vers la page d’accueil.
Scénario alternatif 4.1. L’utilisateur n’a pas saisi le bon paramètre d’authentification.
4.2. L’utilisateur n’existe pas dans la base de données .
TABLE 4.2 – Description textuelle du cas ≪S’authentifier ≫
* Diagramme du cas d’utilisation ≪ Gestion des utilisateurs ≫

La figure suivante présente le diagramme du cas d’utilisation ≪ Gestion des utilisateurs ≫.
F IGURE 4.3 – Diagramme du cas d’utilisation ≪ Gestion des utilisateurs ≫
38
* Description Textuelle du cas d’utilisation ≪ Ajouter utilisateur ≫
CU Ajouter utilisateur
Acteur Administrateur
Pré-condition Administrateur accède à son espace d’administration.
Post-condition Utilisateur ajouté.
Scénario nominal 1. L’administrateur clique sur l’onglet utilisateur.
2. L’administrateur clique sur le bouton ajouter.
3. Le système affiche à l’administrateur une page d’ajout utilisateur.
4. L’administrateur remplit le formulaire.
5. L’administrateur clique sur le bouton ajouter utilisateur.
7. Le système vérifie l’existence d’utilisateur
8. Le système enregistre les nouvelles données.
Scénario alternatif donnée manquante
TABLE 4.3 – Description textuelle du cas ≪ Ajouter utilisateur ≫
* Description Textuelle du cas d’utilisation ≪ Consulter utilisateur ≫
CU Consulter la liste des utilisateurs.

Pré-condition S’authentifier
Post-condition la liste des utilisateurs affichées.
Scénario nominal 1. L’administrateur consulte son espace d’administration.
2. L’utilisateur saisit son email et mot de passe.
3. L’administrateur clique sur l’onglet utilisateur.
4 .Le système affichent une liste des utilisateurs.
Scénario alternatif Aucune
TABLE 4.4 – Description textuelle du cas ≪Consulter utilisateur≫
* Description Textuelle du cas d’utilisation ≪ Supprimer utilisateur≫
CU Supprimer utilisateur
Pré-condition - Administrateur accède à son espace d’administration .
- S’authentifier.
Post-condition Utilisateur supprimé.
Scénario nominal 1. L’administrateur choisi un utilisateur puis clique sur le bouton Sup-
primer.
2. Le système demande la confirmation de la suppression.
3. L’administrateur clique Oui.
4 .le système fait la mis à jour et affiche liste des utilisateurs .
TABLE 4.5 – Description textuelle du cas ≪ Supprimer utilisateur≫
39
* Diagramme du cas d’utilisation ≪ Gestion des événements oculaires≫

La figure 3.4 présente le diagramme du cas d’utilisation ≪ gestion des événements oculaires≫.
F IGURE 4.4 – Diagramme du cas d’utilisation ≪ Gestion des événements oculaires ≫
* Description Textuelle du cas d’utilisation ≪ Ajouter événement ≫
CU Ajouter événement
Pré-condition Administrateur accède à son espace d’administration.
Post-condition Actualité ajouté.
Scénario nominal 1. L’administrateur clique sur l’onglet événement oculaire.
2. L’administrateur clique sur le bouton ajouter.
3. Le système affiche à l’administrateur une page d’ajout événement.
4. L’administrateur remplit le formulaire.
5. l’administrateur clique sur le bouton ajouter événement.
7. Le système vérifie l’existence d’événement.
8. Le système enregistre les nouvelles données .
Scénario alternatif Donnée manquante.
TABLE 4.6 – Description textuelle du cas ≪ Ajouter événement≫
* Description Textuelle du cas d’utilisation ≪ Consulter événement ≫
CU Consulter la liste des événements

Acteur Utilisateur (administrateur, ophtalmologiste)
Pré-condition Utilisateur authentifié.
Post-condition Actualité affichée.
Scénario nominal 1. L’administrateur consulte son espace d’administration.
2. L’utilisateur saisit son email et mot de passe.
3. L’administrateur clique sur l’onglet événement oculaire.
4 .Le système affiche une liste des événements.
TABLE 4.7 – Description textuelle du cas ≪ Consulter liste des événements ≫
* Description Textuelle du cas d’utilisation ≪ Modifier événement ≫
40
CU Modifier événement
Pré-condition Administrateur authentifié.
Post-condition Modification enregistrée.
Scénario nominal 1. L’administrateur choisit l’actualité à modifier .
2. Le système affiche le formulaire de modification.
3. L’administrateur saisit la nouvelle donnée.
4. le système vérifie et enregistre la modification.
5. le système affiche la nouvelle donnée.
Scénario alternatif données manquantes.
TABLE 4.8 – Description textuelle du cas ≪ Modifier événement ≫
* Description Textuelle du cas d’utilisation ≪ Supprimer événement ≫
CU Supprimé événement
Pré-condition Administrateur consulte la liste des actualités.
Post-condition Actualité supprimée.
Scénario nominal 1. L’administrateur choisit un événement puis cliquez sur le bouton sup-
primer.
2. Le système demande la confirmation de la suppression .
3. L’administrateur clique Oui .
4 .le système fait là mis à jour et affiche liste des actualités.
TABLE 4.9 – Description textuelle du cas ≪ Supprimer événement ≫
4.3 Conception dynamique du premier sprint

Nous allons préparer quelques diagrammes des séquences détaillées, le diagramme de classes d’ob-
jets ainsi que la réalisation de certains diagrammes d’activité.
4.3.1 Diagramme de séquence ≪ S’authentifier ≫
Un diagramme de séquence permet de décrire les interactions entre un groupe d’objets en montrant,
de façon séquentielle, les envois de messages qui interviennent entre les objets . le diagramme peut
également montrer les flux de données échangées lors des envois de messages.
À travers ce diagramme illustré par la figure 3.5 ci-dessous, nous allons détailler le scénario du cas
d’utilisation intitulé ”Authentification” . En premier lieu, l’utilisateur est amené à remplir le formulaire
d’authentification et puis il clique sur le bouton “connectez-vous ”. Ensuite, une vérification côté Front-
End est bien effectuée, en admet tant que les entrées soient bien confirmées. Le système vérifie alors
s’il s’agit bien d’un utilisateur à travers une recherche au niveau de la base de données de notre système
41
d’application afin de confirmer l’existence de cet utilisateur. Une fois trouvée, l’authentification s’effec-
tue avec succès en générant et envoyant un Token qui sera enregistré au niveau du “localstorage ” du
navigateur et en fournissant les informations nécessaires liées à cet utilisateur.
F IGURE 4.5 – Diagramme de séquence ≪ S’authentifier ≫
4.3.2 Diagramme de séquence ≪ Ajouter événement oculaire ≫
À travers ce diagramme illustré par la figure 3.6 ci-dessous, nous allons détailler le scénario du cas
d’utilisation intitulé ≪ Ajouter événement oculaire≫.
F IGURE 4.6 – Diagramme de séquence ≪ Ajouter événement oculaire ≫
42
4.3.3 Diagramme d’activité ≪S’authentifier≫
Un diagramme d’activité permet de modéliser le comportement du système, dont la séquence des

actions et leurs conditions d’exécution. Les actions sont les unités de base du comportement du système.
La figure suivante présente le diagramme d’activité ≪S’authentifier≫.
F IGURE 4.7 – Diagramme d’activité ≪S’authentifier≫
4.3.4 Diagramme de classes du sprint 1
La figure ci-dessous illustre le diagramme de classe du premier sprint :
F IGURE 4.8 – Diagramme de classes du ≪ Sprint 1 ≫
43
4.4 Réalisation du sprint 1
Dans cette partie nous allons présenter les scénarios possibles dans ce sprint.
Les figures ci-dessous représentent les interfaces graphiques de la partie authentification, gestion des
événements oculaires et la fonctionnalité chercher ophtalmologiste .
4.4.1 Interface ≪ Authentification ≫
L’utilisateur doit remplir les deux champs d’authentification par son e-mail et son mot de passe afin
qu’il puisse accéder à son espace privé. La figure ci-dessous représente une capture de l’interface pour
ce traitement.
F IGURE 4.9 – Interface ≪ Authentification ≫
4.4.2 Interface ≪ Gestion des événements oculaire ≫
L’administrateur celui qui va gérer les événements oculaires, en fait l’administrateur seul, le respon-
sable qui peut ajouter un événement comme il peut le modifier ou le supprimer.
La figure 3.10 représente une capture de l’interface pour ce traitement.
44
F IGURE 4.10 – Interface ≪ Gestion des événements oculaires ≫
4.4.2.1 Interface ≪Chercher ophtalmologiste ≫
Cette interface permet à un patient de chercher un ophtalmologiste quelque soit par nom ou par ville
.
F IGURE 4.11 – Interface ≪ Chercher ophtlmologiste ≫
4.5 Rétrospectives du Sprint 1

La rétrospective est une réunion située à la fin de chaque sprint pendant laquelle l’équipe scrum se
réunit pour discuter le bilan du sprint et faire une amélioration au cours du prochain sprint .Dans cette
partie, on va mentionner ce qui s’est bien fonctionné, ce qui s’est mal fonctionné et ce que l’équipe
pourrait améliorer.
Ce qui a bien fonctionné :
• Gestion des utilisateurs.
45
• Bien comprendre le sujet.
• La recherche d’un ophtalmologiste.
Ce qui a mal fonctionné :
• L’authentification sécurisée.
• Gestion de compte.
Ce que l’équipe pourrait améliorer :
• Le contrôle de saisie des formulaires inscription et l’authentification.
4.6 Conclusion
Au cours de ce chapitre, nous avons entamé la première partie de notre projet qui comporte des
fonctionnalités importantes telles que l’authentification, la gestion des utilisateurs, la recherche et la
gestion des événements. Dans le chapitre qui suit, notre travail sera dédié pour faire les fonctionnalités
suivantes : Gérer les rendez-vous, Gérer les ordonnances, Gérer les certifications médicales, Gérer les
fiches patients ainsi que la fonctionnalité de messagerie et de l’appel vidéo.
46
Chapitre 5
Implémentation du Sprint 2
47
5.1 Introduction
Dans ce chapitre nous avons choisi d’entamer le sprint 2, donc nous avons présenté les deux phases
de conception et de réalisation vu que nous avons choisi comme méthodologie celle SCRUM agile dont
le principe est de faire les deux étapes pour chaque itération du projet.
5.2 Backlog du sprint 2

Le tableau suivant présente le backlog du deuxième sprint.
Sprint 2
16 En tant que ophtalmologiste, je peux ajouter un pa- 1
tient .
17 En tant que ophtalmologiste, je peux consulter la 2

liste des patients.
Gestion des fiches
patients .
18 En tant que ophtalmologiste, je peux modifier un 1
patient.
19 En tant que ophtalmologiste, je peux supprimer un 3

patient.
20 En tant que patient, je peux demander un rendez- 1
vous .
21 En tant que patient, je peux consulter la liste de mes 1

rendez-vous.
22 En tant que ophtalmologiste, je peux annuler un 2

rendez-vous .
23 En tant que ophtalmologiste, je peux modifier un 1

rendez-vous.
Gestion des
rendez-vous.
24 En tant que ophtalmologiste, je peux ajouter un 1
rendez-vous.
25 En tant que ophtalmologiste, je peux consulter la 2

liste des rendez-vous.
48
26 En tant que ophtalmologiste, je peux ajouter une 1

analyse.
27 En tant que ophtalmologiste, je peux modifier une 3

analyse
28 En tant que ophtalmologiste, je peux supprimer une 2

analyse
29 En tant que ophtalmologiste, je peux ajouter une 3

certification médicale.

Gestion des consul-
tations
31 En tant que ophtalmologiste, je peux consulter une 4

33 En tant que ophtalmologiste, je peux ajouter une or- 1

donnance.

ordonnance.
35 En tant que ophtalmologiste, je peux consulter une 4

ordonnance.

ordonnance.
37 En tant que ophtalmologiste je peux consulter un 1

dossier médical .
38 En tant que ophtalmologiste, je peux lancer un ap- 2
pel vidéo.
Appel vidéo
49
39 En tant que patient ,je peux participer à un appel 2

vidéo.
40 En tant que ophtalmologiste, je peux envoyer mes- 2
sage .
41 En tant que patient, je peux envoyer un message. 2

Messagerie
42 En tant que partenaire, je peux envoyer un message. 2
5.2.1 Diagramme du cas d’utilisation globale du sprint 2 :
La figure suivante présente le diagramme du cas d’utilisation du deuxième sprint.
F IGURE 5.1 – Diagramme du cas d’utilisation du ≪ Sprint 2≫
5.2.2 Description détaillée des principaux cas d’utilisations
* Diagramme du cas d’utilisation ≪ Gestion des rendez-vous≫

L’ophtalmologiste peut gérer un rendez-vous en ajoutant, modifiant ou annulant ce dernier .
50
F IGURE 5.2 – Diagramme du cas d’utilisation ≪ Gérer rendez-vous≫
* Description textuelle du cas d’utilisation ≪ Ajouter rendez-vous ≫
CU Ajouter rendez-vous
Acteur Ophtalmologiste
Post-condition Rendez-vous ajouté
Scénario nominal 1. L’ophtalmologiste clique sur gérer rendez-vous.
2. Le système affiche le formulaire de rendez-vous.
3. L’ophtalmologiste remplit le formulaire présenté.
4. Le système vérifie si tous les champs remplis.
6. Le système affiche un message ≪ rendez-vous ajouté ≫.
Scénario alternatif Date réservé
TABLE 5.2 – Description textuelle du cas ≪ Ajouter rendez-vous ≫
* Description textuelle du cas d’utilisation ≪ Modifier rendez-vous ≫
CU Modifier rendez-vous
Post-condition Rendez-vous modifié
Scénario nominal 1. L’utilisateur clique sur gérer rendez-vous.
2. le système affiche la liste des rendez-vous
3. L’ophtalmologiste choisi le rendez-vous a modifié.
4. Le système affiche le formulaire.
5. L’ophtalmologiste saisit les nouvelles données.
6. L’ophtalmologiste vérifie les champs remplis
7. le système affiche un message ≪ rendez-vous modifié ≫
Scénario alternatif Date reservé
TABLE 5.3 – Description textuelle du cas ≪ Modifier rendez-vous ≫
51
* Description textuelle du cas d’utilisation ≪ Annuler rendez-vous ≫
CU Annuler rendez-vous
Post-condition Rendez-vous annulé
Scénario nominal 1. L’utilisateur clique sur gérer rendez-vous.
2. le système affiche la liste des rendez-vous
3. L’ophtalmologiste sélectionne le rendez-vous a supprimé.
4. Le système supprime le rendez-vous.
TABLE 5.4 – Description textuelle du cas ≪ Annuler rendez-vous ≫
* Diagramme du cas d’utilisation ≪ Gérer dossier médical≫
F IGURE 5.3 – Diagramme du cas d’utilisation du ≪ Gérer dossier médical≫
* Description textuelle du cas d’utilisation ≪ Consulter dossier médical ≫
CU Consulter dossier médical

Post-condition Consulter dossier médical
Scénario nominal 1. L’ophtalmologiste clique sur le dossier médical.
2. Le système affiche la liste de dossiers médicaux.
3. L’ophtalmologiste sélectionne le dossier médical qui veut consulter.
4. Le système affiche le dossier médical sélectionné.
TABLE 5.5 – Description textuelle du cas ≪ Consulter dossier médical ≫
* Diagramme de cas d’utilisation ≪ Envoyer message≫

La figure suivante présente le diagramme du cas d’utilisation ≪ Envoyer message≫.
52
F IGURE 5.4 – Diagramme du cas d’utilisation du ≪ Envoyer message ≫
* Description textuelle du cas d’utilisation ≪Envoyer message ≫
CU Envoyer message
Acteur Utilisateurs (Ophtalmologiste, Patient, Partenaire )
Post-condition Message envoyer
Scénario nominal 1. L’utilisateur clique sur Envoyer message
2. Le système affiche interface envoie message
3. L’utilisateur choisissait le destinataire
4. L’utilisateur écrit le message.
5. L’utilisateur clique sur le bouton envoyé
6. Le système vérifiait la validité des données
7. Le système envoie le message
Scénario alternatif Aucun
TABLE 5.6 – Description textuelle du cas ≪ Envoyer message ≫
5.3 Conception des cas d’utilisation

Nous orienterons dans cette partie a la réalisation de certains diagrammes séquences détaillées, après
nous fournissons le diagramme d’activité ≪ envoyer message ≫, et le diagramme de classes du deuxième
sprint.
5.3.1 Diagramme de séquence du cas d’utilisation≪ Ajouter un rendez-vous ≫
La figure ci-dessous représente le diagramme de séquence qui décrit le processus ≪Ajouter rendez-
vous ≫ .
53
F IGURE 5.5 – Diagramme de séquence ≪ Ajouter rendez-vous≫ ≫
5.3.1.1 Diagramme de séquence du cas d’utilisation≪ Consulter dossier médical≫
Ce diagramme de séquence présente le processus consulté un dossier médical par un ophtalmologiste.
F IGURE 5.6 – Diagramme de séquence du cas d’utilisation ≪ Consulter dossier médical≫
5.3.1.2 Diagramme de séquence du cas d’utilisation≪ Envoyer message≫
Cette figure présente le diagramme de séquence de la fonctionnalité ≪ Envoyer message≫ .
54
F IGURE 5.7 – Diagramme de séquence du cas d’utilisation≪ Envoyer message≫
5.3.2 Diagramme d’activité ≪ Envoyer message ≫
La figure 4.8 présente le diagramme d’activité ≪ Envoyer message ≫
F IGURE 5.8 – Diagramme d’activité ≪ Envoyer message ≫
5.3.3 Diagramme de classe du sprint 2
La figure suivante présente le diagramme de classes du deuxième sprint.
55
F IGURE 5.9 – Diagramme de classe du ≪ Sprint 2 ≫
5.4 Réalisation du sprint 2

Dans cette partie nous allons présenter des captures des interfaces de quelques fonctionnalités réalisées
au cours du deuxième sprint .
5.4.1 Interface ≪ Ajouter rendez-vous ≫
Cette interface permet au ophtalmologiste de gérer les rendez-vous quel que soit de l’ajouter, modifier
ou de le supprimer.
56
F IGURE 5.10 – Interface≪ Ajouter rendez-vous ≫
5.4.2 Interface ≪Gérer Consultation ≫
Cette interface permet au ophtalmologiste de gérer une consultation . La figure 4.11 représente une
capture de l’interface pour ce traitement.
F IGURE 5.11 – ≪Gérer Consultation≫
5.4.2.1 Interface ≪Envoyer message ≫
Cette interface permet au ophtalmologiste de contacter un partenaire.
57
F IGURE 5.12 – Interface≪ Envoyer message ≫
5.4.3 Interface ≪ Consultation en ligne ≫
Notre application offre la possibilité d’effectuer une consultation à distance, dans le cas ou le patient
trouve une difficulté pour se déplacer, par exemple le cas de covid-19 dans ces années montre l’utilité de
ce service. La figure ci-dessous montre une capture de l’interface pour cette fonctionnalité.
F IGURE 5.13 – ≪ Consultation en ligne≫
5.4.4 Interface ≪Demander un rendez-vous ≫
Notre application donne au patient la possibilité de faire une réservation d’un rendez-vous en ligne.
La figure ci-dessous représente une capture de l’interface pour ce traitement.
58
F IGURE 5.14 – ≪Demander un rendez-vous ≫

Comme à la fin de chaque sprint, on va mentionner ce qui a bien fonctionné, ce qui a mal fonctionné
et ce que l’équipe pourrait améliorer.
ce qui bien fonctionné :
• Gestion de rendez-vous
• Gestion des patients.
• Gestion d’un dossier médical.
• Gestion de la consultation
• L’interface de consultation.
5.6 Conclusion
Durant ce chapitre intitulé ≪ Implémentation du sprint 2≫ nous avons commencé par définir notre
ligne de travail grâce au Sprint Backlog. Ensuite, nous avons fait l’analyse détaillée de ce dernier pour
aboutir enfin à l’étude conceptuelle et la réalisation de cette itération. Après avoir terminé le deuxième
sprint en implémentant toutes les exigences demandées, nous pouvons poursuivre notre travail et passer
au chapitre suivant qui présente le sprint le plus important, notre effort sera dédié à l’implémentation
d’un système intelligent de détection de certaines maladies oculaires.
59
Chapitre 6
Implémentation du sprint 3
60
Chapitre 6. Implémentation du sprint 3
6.1 Introduction
Dans ce chapitre nous allons présenter les différents détails liés à la réalisation du système de diag-
nostic des imageries radiologiques oculaires.
6.2 Bcklog du sprint 3

Le tableau suivant présente le backlog du troisième sprint.
Sprint 3
43 En tant que ophtalmologiste, je peux lancer le diag- 1
nostic d’une image radiologie.
Réalisation du
système de
détection des
maladies oculaires.
44 En tant que ophtalmologiste, je peux consulter le 1
résultat.
6.2.1 Choix technologique
Dans cette partie on va s’intéresser à l’étude du choix technologique permettant la réalisation d’un
système de détection des certaines maladies oculaires.
6.2.1.1 Apprentissage d’un réseau de neurone
L’apprentissage est une étape très importante du développement d’un réseau de neurones durant la-
quelle le comportement du réseau est modifié itérativement jusqu’à l’obtention du comportement désiré,
et ce par l’ajustement des poids (connexion ou synapse) des neurones à une source d’information bien
défini (Hebb 1949 ; Grossberg 1982 ; Rumelhart et al. 1986). Il existe plusieurs types de règles d’appren-
tissage qui sont l’apprentissage supervisé et l’apprentissage non supervisé.
* Apprentissage non supervisé :
Dans l’apprentissage non supervisé, seules les données d’entrée (inputs) sont connues. Les données de
sortie (outputs) ne sont pas connues (Müller, Guido 2017).
Ce type d’apprentissage est utilisé lorsqu’on ne connaı̂t pas les données de sortie (outputs). Ce qui n’est
pas le cas avec notre problématique.
* Apprentissage supervisé :
Les algorithmes d’apprentissage automatique qui mettent en œuvre un apprentissage par paire des données
d’entrée et de sortie (inputs/outputs) sont appelés ≪ supervisés ≫, car il y a une intervention et une su-
pervision humaines. Actuellement, l’apprentissage automatique supervisé est la méthode la plus utilisée
61
et souvent la plus efficace pour détecter un objet dans une image . Ce type d’apprentissage correspond à
notre problématique, car on connaı̂t les données de sortie (outputs). Dans notre cas, les données d’entrée
sont les images et les données de sortie sont les objets recherchés.
⇒ Dans notre solution on a utilisé l’apprentissage supervisé.
6.2.2 Apprentissage Supervisé
6.2.2.1 Définition
Également connu sous le terme de supervised learning, l’apprentissage supervisé est une méthode
pour permettre à une intelligence artificielle (IA) d’appliquer ses fonctions en toute autonomie. Les règles
initiales s’agrémentent alors d’exemples pour accroı̂tre la capacité d’actions de l’intelligence artificielle
face à des problématiques données. Selon les cas observés, les paramètres s’ajustent ainsi automati-
quement afin de réagir efficacement devant des situations similaires. Le résultat gagne en pertinence,
réduisant la marge d’erreur du système.
6.2.2.2 Fonctionnement de l’apprentissage supervisé :
Techniquement, l’apprentissage supervisé infère une fonction de données d’apprentissage étiquetées

consistant en un ensemble d’exemples d’apprentissage.
Dans l’apprentissage supervisé, chaque exemple est un couple constitué d’un objet d’entrée (généralement
un vecteur) et d’une valeur de sortie souhaitée (également appelé signal de supervision).
Un algorithme d’apprentissage supervisé analyse les données d’apprentissage et produit une fonction
inférée, qui peut être utilisée pour mapper de nouveaux exemples. Un scénario optimal permettra à l’al-
gorithme de déterminer correctement les classes de classe l pour les instances invisibles. Cela nécessite
que l’algorithme d’apprentissage soit généralisé à partir des données d’entraı̂nement à des situations
invisibles d’une manière ”raisonnable”.
F IGURE 6.1 – Apprentissage supervisé
6.2.2.3 Principe de l’apprentissage supervisé
L’objectif de l’apprentissage supervisé est de prédire une caractéristique (l’étiquette) qui est soit une
catégorie (modèles 1 et 2) soit un prix de vente (modèle 3).
– Les étiquettes à prédire sont discrètes et indiquent l’appartenance à une catégorie/classe, on parle de
modèle de classification supervisée.
– Les étiquettes à prédire sont continues (valeurs réelles), on parle de modèle de régression.
62
F IGURE 6.2 – Principe de l’apprentissage supervisé
⇒ Dans notre cas, il s’agit d’une classification supervisée.
6.2.2.4 Objectif de classification supervisé
L’objectif de la classification supervisée est principalement de définir des règles permettant de classer
des objets dans des classes à partir de variables qualitatives ou quantitatives caractérisant ces objets.
F IGURE 6.3 – Classification supervisé
* Méthodes d’apprentissage supervisé

Plusieurs sont les méthodes de classification supervisée parmi lesquelles on trouve.
– Machine à vecteurs de support
Les machines à vecteurs de support ou séparateurs à vaste marge (en anglais support vector machine,
SVM) sont un ensemble de techniques d’apprentissage supervisé destinées à résoudre des problèmes de
discrimination et de régression. Les SVM sont une généralisation des classifieurs linéaires.
– Méthode des k plus proches voisins
L’algorithme des k plus proches voisins ou k-nearest neighbors (kNN) est un algorithme d’apprentissage
automatique (Machine Learning) supervisé simple et facile à mettre en œuvre qui peut être utilisé pour
résoudre les problèmes de classification et de régression.
– Arbre de décision
L’apprentissage par arbre de décision désigne une méthode basée sur l’utilisation d’un arbre de décision
comme modèle prédictif. On l’utilise notamment en fouille de données et en apprentissage automatique.
– Classification naı̈ve bayésienne
La classification naı̈ve bayésienne est un type de classification bayésienne probabiliste simple basée sur
le théorème de Bayes avec une forte indépendance (dite naı̈ve) des hypothèses. Elle met en œuvre un
classifieur bayésien naı̈f, ou classifieur naı̈f de Bayes, appartenant à la famille des classifieurs linéaires.
– Réseau de neurones convolutif(CNN)
Pour la réalisation de notre système de détection des pathologies oculaires on a utilisé le réseau de
neurones convolutif.
63
6.2.2.5 Réseau de neurones à convolution (CNN)
Les réseaux de neurones à convolution (CNN) sont une application des réseaux de neurones reposant
sur l’application de filtres inspirés du fonctionnement de la partie du cerveau traitant du champ visuel.
Au cours des dernières années, grâce à l’augmentation de la puissance de calcul et à la forte quantité
de données d’entraı̂nement disponibles, les CNN ont réussi à obtenir des performances surhumaines sur
certaines tâches visuelles complexes. Ils alimentent les services de recherches d’images, les voitures au-
tonomes, la vidéo automatique, etc.
Il existe quatre types de couches pour un réseau de neurones convolutif : la couche de convolution, la
couche de pooling, la couche de correction ReLU et la couche fully-connected :
- Couche convolutional :
La couche de convolution reçoit donc en entrée plusieurs images, et calcule la convolution de chacune
d’entre elles avec chaque filtre. Les filtres correspondent exactement aux features que l’on souhaite re-
trouver dans les images. On obtient pour chaque paire (image, filtre) une carte d’activation, ou feature
map, qui nous indique où se situent les features dans l’image : plus la valeur est élevée, plus l’endroit
correspondant dans l’image ressemble à la feature.
- La couche de pooling :
Permet de réduire le nombre de paramètres et de calculs dans le réseau. On améliore ainsi l’efficacité du
réseau et on évite le sur-apprentissage .
Ce type de couche est souvent placé entre deux couches de convolution : elle reçoit en entrée plusieurs
feature maps, et applique à chacune d’entre elles l’opération de pooling. L’opération de pooling consiste
à réduire la taille des images, tout en préservant leurs caractéristiques importantes.
- Couche de Relu :
La couche de correction ReLU remplace donc toutes les valeurs négatives reçues en entrées par des zéros.
Elle joue le rôle de fonction d’activation .
- Couche Fully connected :
La couche fully-connected constitue toujours la dernière couche d’un réseau de neurones, convolutif ou
non elle n’est donc pas caractéristique d’un CNN. Ce type de couche reçoit un vecteur en entrée et pro-
duit un nouveau vecteur en sortie. Pour cela, elle applique une combinaison linéaire puis éventuellement
une fonction d’activation aux valeurs reçues en entrée. La dernière couche fully-connected permet de
classifier l’image en entrée du réseau : elle renvoie un vecteur de taille N, où N est le nombre de classes
dans notre problème de classification d’images. Chaque élément du vecteur indique la probabilité pour
l’image en entrée d’appartenir à une classe.
64
F IGURE 6.4 – Les réseaux de neurones convolutifs
6.3 Conception
6.3.1 Architecture du modèle
Après avoir étudié dans les parties précédentes l’état de l’art sur les réseaux de neurones et le du deep
Learning, nous allons réaliser notre classificateur et créer notre modèle, pour appliquer par la suite ce
modèle sur la base d’image qu’on a choisie. Et afin de réaliser tout ça nous utiliserons le langage python
et les différentes bibliothèques comme Tensorflow et Keras pour l’apprentissage et la classification. Pour
commencer nous avons utilisé deux tâches : l’entraı̂nement et le test.
F IGURE 6.5 – Conception du classificateur
A. L’entrainement :
* Avec l’entraı̂nement qu’on va créer notre modèle grâce à des différentes configurations, comme
la base de données des images ≪ Dataset ≫ et l’algorithme qui va nous permettre de créer notre
réseau de neurones.
* Les classes : c’est un fichier qui porte les noms des classes de notre DataSet qui sont :
≪Cataract≫,≪Glaucoma≫ et ≪Retinopathy≫
* L’exécution des Dataset sur notre algorithme qui sera paramétrée pour générer un modèle, qui
sera à sa part utilisé pour faire le test.
B. Le test :
Dans cette tâche on a besoin de trois choses importantes :
* L’image : on a besoin d’une ou plusieurs dans notre test comme entrées.
65
* Le modèle : c’est un fichier généré dans notre training.

* L’affichage de la classification : on va afficher le résultat sortie du modèle.
6.3.2 Diagramme du cas d’utilisation
La figure suivante illustre le diagramme de cas d’utilisation ≪Analyser image radiologique ≫.
F IGURE 6.6 – Diagramme du cas d’utilisation ≪Analyser image radiologique ≫.
6.3.3 Diagramme de séquence
La figure suivante illustre le diagramme de séquence du cas ≪analyser image radiologique ≫. En

effet, l’ophtalmologiste va charger les données, lancer l’analyse et mettre à jour l’interface graphique.
66
F IGURE 6.7 – Diagramme de séquence ≪Analyser image radiologique ≫.
6.3.4 Les bibliothèques utilisées
TensorFlow :
TensorFlow est crée par l’équipe Google Brain pour mener des recherches sur le ML et le Deep Learning.
Il est considéré comme une version moderne de Theano. C’est une bibliothèque de logiciels open source
pour le calcul numérique à l’aide de graphes de flux de données. Les nœuds du graphe représentent des
opérations mathématiques, tandis que les arêtes du graphe représentent les tableaux de données multidi-
mensionnels (tenseurs) communiqués entre eux.
F IGURE 6.8 – logo Tensorflow
Keras :
Le framework le plus haut niveau, le plus convivial de la liste. Il permet aux utilisateurs de choisir si les
modèles qu’ils construisent sont exécutés sur TensorFlow ou un autre framework.
F IGURE 6.9 – logo Keras
67
On a choisi de travailler avec ces deux bibliothèques car elles sont plus compatibles avec notre version
du langage de programmation python.
6.4 Analyse et choix des données utilisées
6.4.1 Objets à détecter
Les objets qui doivent être détectés, appartiennent aux catégories suivantes :
• Cataract
La cataracte est l’une des causes les plus fréquentes de perte de la vision . Elle est due à la perte de
transparence du cristallin, la lentille naturelle de l’œil.
F IGURE 6.10 – Maladie de Cataract
• Glaucoma
Le glaucome est une maladie chronique de l’œil due à des lésions du nerf optique.
F IGURE 6.11 – Maladie Glaucoma
• Retinopathy
Les vaisseaux sanguins à l’arrière de l’œil s’affaiblissent et saignent, ce qui endommage la rétine..
68
F IGURE 6.12 – Maladie de Retinopathy
6.4.2 Caractéristiques des données
6.4.2.1 Définition :
* Les données traitées sont des images radiologiques.

* Les catégories d’objets à détecter. ≪Cataract≫,≪Glaucoma≫ et ≪Retinopathy ≫
6.4.2.2 qualité :
Les données doivent être représentatives de l’utilisation finale du programme et de nature variée.
6.4.3 Origine des données
La majorité des données d’entraı̂nement sont des images radiologiques d’une clinique oculaires .
6.4.4 L’implémentation
Dans ce qui suit, nous donnerons le code source de notre implémentation :

1 ) Importer TensorFlow et d’autres bibliothèques.
F IGURE 6.13 – Importation des bibliothèques
2 ) Téléchargez et explorez l’ensemble de données.
69
F IGURE 6.14 – Téléchargement de données
3) Vous pouvez trouver les noms de classe dans le ‘categories‘
F IGURE 6.15 – Nommage des classes
4 ) Créer le modèle.
F IGURE 6.16 – Création du modèle
70
5 ) Compiler le modèle puis l’entraı̂ner , ensuite on visualise les résultats de l’entraı̂nement tout en
créant des tracés de perte et de précision sur les ensembles d’apprentissage et de validation.
F IGURE 6.17 – Former modèle
6 ) Nous implémentons l’augmentation des données en utilisant la bibliothèque Scikit-Learn (sklearn)

pour augmenter les performances globales du modèle.
F IGURE 6.18 – Augmentation des données
7 ) Compiler et entraı̂ner le modèle.
71
F IGURE 6.19 – Entrainer le modèle
=⇒ Après avoir appliqué l’augmentation des données , il y a moins de surapprentissage qu’aupara-

vant, et la précision de la formation et de la validation est plus proche.
8 ) Prédire sur de nouvelles données.
Enfin, utilisons notre modèle pour classer une image qui n’était pas incluse dans les ensembles d’appren-
tissage ou de validation.
F IGURE 6.20 – Préduction
6.4.5 Validation
Après nos expérimentations, nous avons créé un modèle à l’aide des datasets, et par la suite on a
appliqué sur ce modèle notre base d’image. Après la création du modèle, on va lui faire un test, et on
obtient les deux graphes suivants :
* Graphe de précision
d’après ce graphe on remarque que la précision training et du test augmentent avec le nombre d’époques :
72
F IGURE 6.21 – Graphe de précision pour le modèle.
* Graphe d’erreur
Ce graphe montre que l’erreur du training et du test diminue jusqu’à la première époque, et se stabilisent
de 1ère aux 2ème époque, et après la 2ème époque, le test s’augmente et le training se diminue.
F IGURE 6.22 – Graphe d’erreurs pour le modèle.
6.5 Interface graphique

La dernière étape du développement a été de mettre au point une interface graphique permettant au
ophtalmologiste d’utiliser facilement l’application.
* Composition de l’interface graphique
73
L’interface graphique est composée d’une simple et unique fenêtre. Elle permet en termes de fonction-
nalité de :
1) Charger des fichiers dans le dépôt d’images.
2) Lancer l’analyse (affiche la progression durant analyse) .
3) Afficher et accéder aux résultats.
* Interface ≪ Analyse Image ≫
Cette interface permet au ophtalmologiste de gérer l’analyse d’une image radiologique on offrant la
classe à qu’elle appartienne le maladie ainsi avec quel pourcentage.
F IGURE 6.23 – Interface ≪Gérer analyse ≫
6.6 Conclusion
Au cours du ce chapitre, nous avons réussi à développer le troisième sprint .Dans le chapitre suivant,
notre effort sera dédié pour produire le dernier sprint recouvrant les fonctionnalités suivantes : réalisation
d’un agent conversationelle.
74
Chapitre 7
Implémentation du sprint 4
75
7.1 Introduction
Dans ce sprint , nous allons essayer de comprendre les notions fondamentales de l’intelligence arti-
ficielle pour arriver à créer un chatbot dans notre application.
7.1.1 Bcklog du sprint 4
Sprint 4
45 En tant que patient, je peux poser une question sur 2
un agent conversationnel.
Agent conversa-
tionnel
46 En tant que patient, je peux consulter une réponse. 2
7.2 Choix technologiques
7.2.1 Traitement du langage naturel
Le traitement du langage naturel ou NLP(Natural Language Processing) est défini comme la capacité
d’une machine à analyser, comprendre et générer un discours humain. Le but de la NLP est de faire des
interactions entre les machines et les humains qui peuvent ressembler exactement à des interactions entre
les humains. La NLP est un domaine de l’informatique qui existe depuis un certain temps,et elle devient
de plus en plus utilisé au cours des dernières années grâce aux progrès de la technologie qui ont faciliter le
développement des machines dotés de capacités NLP. Les applications de la NLP comprennent les filtres
anti-spam,réponses aux questions, les dialogues et d’autres applications. Pour comprendre comment elle
fonctionne, nous devons examiner ses deux principales composantes :
NLU(Natural Language Understanding) : est la partie la plus difficile de la NLP,de comprendre ou de
donner un sens au langage naturel que l’ordinateur a reçu.
NLG(Natural Language Generation) : est beaucoup plus simple à accomplir.C’est la traduction de
langage artificiel d’une machine en texte, ou en un discours audible avec une synthèse vocale.
7.2.2 Le Machine Learning
Comme on a expliqué dans le sprint précédant le machine learning est une application de l’intel-
ligence artificielle (IA) qui offre aux systèmes la possibilité d’apprendre et de s’améliorer automati-
quement à partir de l’expérience sans être explicitement programmés. Les algorithmes d’apprentissage
automatique sont souvent classés comme supervisés ou non supervisés.
* Faire des prédictions algorithmiquement :Apprentissage supervisé
* Déchiffrer algorithmiquement les modèles dans les données : Apprentissage non supervisé.
* Plongé dans un environnement donné, il apprend en recevant des récompenses ou des pénalités en
76
fonction de ses actions : Apprentissage par renforcement.
Pour l’implémentation de notre chatbot on a utilisé l’apprentissage par renforcement.
7.2.3 Le Deep Learning
* Définition
L’apprentissage en profondeur est une forme d’apprentissage automatique qui permet des ordinateurs
pour apprendre de l’expérience et comprendre le monde en matière de hiérarchie des concepts.
* Deep Learning DNNs (Réseaux de neurones profonds) :
C’est une technique d’apprentissage basée sur les réseaux de neurones artificiels, permettant à un pro-
gramme, par exemple, de reconnaı̂tre le contenu d’une image ou de comprendre le langage parlé. Il
est taillé pour gérer de larges quantités de données en ajoutant des couches au réseau. Un modèle de
deep learning a la capacité d’extraire des caractéristiques à partir des données brutes grâce aux multiples
couches de traitement composé de multiples transformations linéaires et non linéaires et apprendre sur
ces caractéristiques à travers chaque couche avec une intervention humaine.
* Fonctionnement du deep learning :
Les neurones sont regroupés en trois types de couches différents :
1. Couche d’entrée : reçoit des données d’entrée et transmet les entées a la première couche masqué.
2. Couches cachées : effectuent des calculs mathématiques sur nos entrées. L’un des défis de la création
de réseaux neuronaux est de déterminer le nombre de couches cachées, ainsi que le nombre de neurones
pour chaque couche.
3. Couche de sortie : renvoie les données de sortie.
Chaque connexion entre neurones est associée à un poids. Ce poids détermine l’importance de la valeur
d’entrée. Les poids initiaux sont définis aléatoirement.
Chaque neurone a une fonction d’activation . En termes simples, l’un de ses objectifs est de ≪norma-
liser≫ la sortie du neurone. Une fois qu’un ensemble de données d’entrée est passé à travers toutes les
couches du réseau neuronal, il renvoie les données de sortie via la couche de sortie. Pour former un
réseau neuronal il faut :
* Un grand ensemble de données.
* Une grande quantité de puissance de calcul.
Pour former l’intelligence artificiel ≪ IA ≫, on lui donne les informations de l’ensemble de données et
comparer ses résultats avec les résultats de l’ensemble de données. Puisque l’IA n’est toujours pas en-
traı̂née, ses sorties seront fausses.
Une fois que l’ensemble des données est parcouru, on peut créer une fonction qui montre à quel point
les sorties de l’IA étaient erronées par rapport aux sorties réelles. Cette fonction s’appelle la fonction de
coût .
Elle que cette fonction soit nulle. C’est à ce moment que les sorties sont identiques aux sorties du jeu de
données.
77
7.2.4 Les réseaux de neurones artificiels
Le terme deep du DL fait référence à la profondeur du réseau de neurones et aux nombreuses couches
cachées qu’il peut contenir.Ce terme s’est inspiré du fonctionnement du cerveau humain, doté de neu-
rones qui communiquent entre eux par impulsion électrique.Tout réseau de neurones est composé d’in-
puts et d’outputs : une information entre , est traitée puis ressort. L’objectif du DL est de prédire une
sortie à partir de données d’entrée comme présenté sur la figure 6.4.
F IGURE 7.1 – Les réseaux de neurones artificiels
7.2.5 Choix de l’outil d’apprentissage automatique
Pour implémenter notre chatbot on a utilisé comme outils la librairie TensorFlow qui implémente la
libraire Keras et on a utilisé python comme langage de programmation , aussi nous allons utiliser une api
Flask(service) pour rendre les fonctionnalités de Chatbot utilisable dans notre application.
7.3 Conception
* Diagramme de séquence
Au cas où, le patient a besoin d’un assistant virtuel il peut discuter avec le chatbot pour lui guider d’avoir
une bonne réponse à ces questions à tout moment.
78
F IGURE 7.2 – Diagramme de séquence ≪Discuter avec chatbot ≫.
7.4 Fonctionnement d’un agent conversationnel
7.4.1 Intents / Intentions
Les intentions vont être représentées comme une action qui va être annoncée par le client (par le biais
du chat) et qui va être réalisée par le chatbot. Par exemple, notre client veut connaı̂tre les symptômes de
la cataracte., l’intention va être ≪ Cataracte. ≫.
F IGURE 7.3 – Diagramme de séquence ≪Poser question ≫.
7.4.2 Training phrases
Les ≪ training phrases≫ sont toutes les phrases qu’on va mettre pour que l’agent comprenne de
quel ≪ intent ≫ on est en train de parler. Continuons avec l’exemple de tout à l’heure pour connaı̂tre les
symptômes de la cataracte, nous pouvons le dire de différentes façons et donc le bot doit être en mesure
79
de s’adapter à ce que nous écrivons.
7.4.3 Entraı̂ner le bot
Il y a deux manières de faire pour améliorer le robot. La première va être de mettre au minimum 10
à 15 ≪ training phrases ≫ dans chaque intention et la deuxième va être de chatter avec mon chatbot.
* Augmenter les ≪ training phrases ≫ : Pour la compréhension comme on a annoncé précédemment,
plus nous mettrons de ≪ training phrases ≫dans un ≪ intent ≫ et plus le robot va être en mesure d’être
performant sur son choix d’intention. Nous recherchons un pourcentage élevé, pour ne pas avoir un
message du type ≪ je ne comprends pas ce que vous voulez faire ≫ . Pour cela, il suffit de mettre un
maximum de phrases d’entraı̂nement afin de fortifier le raisonnement du bot.
* Chatter pour améliorer l’intelligence du bot : Chaque fois que nous discutons avec un Bot, le
message envoyé sera enregistré sur le site Web.
7.4.4 La compréhension du langage naturel
Cette étape permet d’analyser et de comprendre les demandes des utilisateurs. Cela est dû à la
compréhension du langage naturel ou de la compréhension du langage naturel (NLU). Cette branche
est l’une des sous-branches du traitement du langage naturel (NLP) ou du traitement du langage naturel
(NLP) en anglais, et le composant représente l’intelligence artificielle que les programmes comprennent
les capacités du langage humain.
7.4.5 Traitement de la demande
Une fois l’intention et l’entité définies, nous pouvons continuer à traiter la demande, ce qui peut être
la recherche d’informations dans la base de données ou l’appel d’une API.
7.4.6 Génération de réponse
La génération de réponses peut fonctionner selon deux modèles : les modèles basés sur la récupération
et les modèles dits génératifs. Tout d’abord, la réponse est prédéfinie et extraite directement de la base
de données.
Une réponse basée sur un modèle génératif est une réponse qui n’existe pas et est une réponse créée
dynamiquement en fonction de l’utilisateur et du contexte.
7.5 Étude expérimentale :

Nous allons simplifier la construction de ce chabot en 5 étapes :
Étape 1 : Importez les bibliothèques et chargez les données : Commencez par créer un nom de fichier
comme ”trainc hatbot.py”.
Nous importons les packages nécessaires pour notre chatbot et initialisant les variables que nous
utiliserons dans notre projet Python.
80
F IGURE 7.4 – chargements des bibliothèques et des données
Étape 2 : Prétraiter les données : Lorsque vous travaillez avec des données texte, nous devons
effectuer divers prétraitements sur les données avant de créer un modèle d’apprentissage automatique ou
d’apprentissage en profondeur. La création de jetons est la première chose que vous puissiez faire sur les
données textuelles. Le tokenisation est le processus qui consiste à diviser le texte entier en petites parties
comme des mots.
F IGURE 7.5 – Prétraitement des données
Étape 3 : Créer des données de formation et de test : Maintenant, nous allons créer les données
d’entraı̂nement dans lesquelles nous fournirons l’entrée et la sortie. Notre entrée sera le modèle et la
sortie sera la classe à laquelle appartient notre modèle d’entrée. Mais l’ordinateur ne comprend pas le
texte, nous allons donc convertir le texte en nombres.
F IGURE 7.6 – Création des données
Étape 4 : Construisez le modèle : Nous avons nos données d’entraı̂nement prêtes, nous allons
maintenant construire un réseau neuronal profond qui a 3 couches. Nous utilisons l’API séquentielle Ke-
ras pour cela. Après avoir entraı̂né le modèle pendant 200 époques, nous avons atteint une précision de
81
100% sur notre modèle.
F IGURE 7.7 – Construction du modèle
Étape 5 : Interagir avec le chatbot (interface utilisateur graphique) : Notre modèle est prêt à
chatter, alors créons maintenant une belle interface utilisateur graphique pour notre chatbot dans notre
application.Pour cela nous allons utiliser un Api Flask(service) pour rendre les fonctionnalités de chatbot
utilisables dans notre application.
F IGURE 7.8 – Interface utilisateur graphique
7.6 Architecture d’une application chatbot

L’architecture d’une application chatbot se base sur le modèle un tiers comme présenté sur la fi-
gure 6.13 une couche de présentation, une couche de logique, une couche de données, et une couche
communication/API.
82
F IGURE 7.9 – Architecture d’un chatbot
• La couche de présentation :est une interface de messagerie, c’est elle qui assure la trans-
mission de la requête et de la réponse entre le bot et l’utilisateur.
• La couche logique : contient les étapes de traitement du langage naturel définies plus haut,
c’est ici qu’interviennent les processus liés à l’intelligence artificielle.
• La couche de données : contient des modèles de réponses.
• La couche API :contient des services externes pour l’obtention de données en lien avec l’in-
tention/entité de l’utilisateur.

Comme d’habitude dans cette partie, on va mentionner ce qui s’est bien fonctionné, ce qui s’est mal
fonctionné et ce que l’équipe pourrait améliorer.
ce qui bien fonctionné :
• Réalisation de l’interface graphique du chtabot.
• Le temps de réponse du chatbot .
• La qualité de réponse de chatbot .
7.8 Conclusion
Au cours du ce chapitre, nous avons réussi à développer le dernier sprint afin d’atteindre un produit
complet et fonctionnel.
83
CONCLUSION GÉNÉRALE ET
PERSPECTIVES
Le présent document est une présentation du travail réalisé pendant cinq mois dans le cadre d’un
stage de fin d’étude au sein de l’entreprise ITgate-Group .
Le projet s’intitule ≪ Application intelligente de gestion d’un cabinet d’ophtalmologie ≫ et qui a pour
objectif de résoudre des problèmes rencontrés par des médecins ophtalmologistes.
Nous sommes passés par des étapes pour réaliser ce projet, commençant par la phase préparatoire durant
laquelle nous avons fait une étude générale pour mieux comprendre notre projet et choisi les bonnes
technologies et la méthodologie adoptée .
Par la suite, nous avons dégagé les besoins fonctionnels et fait une modélisation via une conception glo-
bale et détaillée dans la partie mise en œuvre.
La dernière étape c’est le développement de l’application.
Nous avons rencontré plusieurs difficultés tout au long du stage mais grâce aux connaissances que j’ai ap-
prise durant mon parcours universitaire à l’institut supérieur d’informatique et de gestion kairouan,et bien
sûr sans oublier mon encadrant professionnel et académique, ils étaient toujours présents pour répondre à
toutes mes questions, nous avons réussi à réaliser ce projet et répondre aux besoins du client à travers une
application qui permet d’améliorer les services d’un cabinet d’ophtalmologie qui fournit une meilleure
gestion des rendez-vous, facilite le processus de recherche d’un d’ophtalmologiste , offre la possibilité
de faire une consultation ou un contrôle médical à distance, de plus elle facilite les tâches d’un médecin
ophtalmologiste à travers un système intelligent qui permet de détecter certaines maladies oculaires très
tôt, aussi notre application peut guider et orienter les patients grâce à une entité conversationnelle capable
de répondre à la plupart de ces questions dans le domaine d’ophtalmologie.
Perspectives
En termes de perspectives, bien que la solution réalisée présente une réponse claire au cahier des charges,
nous pourrions améliorer la solution de différentes manières afin de progresser vers des nouvelles ver-
sions plus matures.
En ce qui concerne la partie système de détection des maladies oculaires, le système développé actuel-
lement incomplet, il ne détecte pas tous les types des pathologies oculaires ce qu’on pourra le faire au
84
futur, avec l’ajout de nouvelles catégories.
Finalement, vu l’accomplissement de projet, nous souhaitons très fortement qu’il soit le fruit du progrès,
de l’évolution et qu’il reste à la hauteur des exigences de la société, nous souhaitons par ailleurs la satis-
faction de la société ITgate-Group et de tous ses responsables, ainsi que les membres de jury.
85
Netographie
[1] : https ://www.inbenta.com/fr/blog/guide-agent-conversationnel/ , consulté le 28/07/2023

[2] :https ://keras.io/ , consulté le 15/06/2023
[3] :https ://kaggle.com/datasets/andrewmvd/ocular-disease-recognition-odir5 , consulté le 22/08/2023
[4] :https ://datascientest.com/knn , consulté le 1/07/2023
[5] :https ://datascientest.com/convolutional-neural-network , consulté le 05/08/2023
[6] :https ://webrtc.org/ , consulté le 8/07/2023
[7] :https ://www.tensorflow.org/federated , consulté le 12/08/2023
[8] : https ://kaggle.com/datasets/jr2ngb/cataractdataset , consulté le 14/0/2023
[9] : https ://kaggle.com/datasets/jr2ngb/cataractdataset , consulté le21/08/2023
[10] :https ://flask.palletsprojects.com/en/2.0.x/tutorial/index.html , consulté le 11/07/2023
[11] : https ://www.refdoc.fr/documentation/soins-oculaires/ , consulté le 18/06/2023
[12] :https ://learning.oreilly.com/library/view/deep-learning , consulté le 18/05/2023
[13] :www.mysql.com , consulté le 12/06/2023
86
Bibliographie
[14] : Chatbot, RONCE, Samuel, 2017. Comprendre et développer un chatbot

[15] :L’apprentissage, thesesante.ups-tlse.fr/1587/1/2017TOU33008.pdf
[16] : Intelligence artificielle thesesante.ups-tlse.fr/1587/1/2017TOU33008.pdf
[17] : Cataracte , www.passeportsante.net/fr/Maux/Problemes/doc=Cataracte
[18] : Intelligence artificielle WASICEK, Amin, 2018. Artificial Intelligence
[19] : D Hadjouis www.sciencedirect.com/science/article/abs/
[20] : P Fauchard , books.google.tn/books ?hl=les+maladies+oculaires+pdfots
[21] : M Penneau, https ://www.sciencedirect.com/science/article/abs/pii/
[22] : L Radoi , http ://www.revuedegeriatrie.fr/lespdf
[23] : CNN ,http ://dspace.univ-tlemce/Classification-des-images.pdf
[24] : Machine learning , GURU99, 2019. AI vs Machine Learning
[25] : Python , The Python Language Reference, Guido van Rossum
[26] : Classification, revu ;Deep learning, Yann LeCun1,2, Yoshua Bengio3
87
Bibliographie
88

Rapport 2 Scrum

Transféré par

Droits d'auteur :

Formats disponibles

Rapport 2 Scrum

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport 2 Scrum

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne Université de Kairouan

Ministère de l'Enseignement Supérieur Institut Supérieur d’Informatique

Application intelligente de gestion d’un cabinet

Année Universitaire 2022 – 2023

Liste des abréviations xii

1.1 Logo du Société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 L’intelligence artificielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1 Diagramme du cas d’utilisation global du ≪ Sprint 1≫ . . . . . . . . . . . . . . . . . . 37

5.1 Diagramme du cas d’utilisation du ≪ Sprint 2≫ . . . . . . . . . . . . . . . . . . . . . . 50

6.1 Apprentissage supervisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.1 Les réseaux de neurones artificiels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

1.1 Carte d’identité de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.1 Backlog du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

1.2 Présentation de la société ≪ITgate-Group ≫

1.2.1 Profit de société

F IGURE 1.1 – Logo du Société

Nom de l’entreprise ITgate-Group

TABLE 1.1 – Carte d’identité de la société

1.2.2 Missions principales

– Prendre de la hauteur pour concevoir votre projet de développement informatique de

1.4 Étude de l’existant

F IGURE 1.2 – Logo de OPHTEL

F IGURE 1.3 – Logo de DrSanté

F IGURE 1.4 – Logo de Téo

• Le tableau suivant décrire les caractéristiques de certaines solutions existantes.

caractéristiques OPHTEL DrSanté Téo

TABLE 1.2 – les caractéristiques des certaines solutions existantes

1.4.4 Critique de l’existant

1.5 Solution proposée

1.6 Objectifs du projet

1.7 Méthodologie de développement et langage de modélisation

1.7.1 Méthodologie de développement

La méthode de gestion de projets influence considérablement la réussite d’un projet informatique.

1.7.1.1 EXtreme Programming

1.7.1.2 La méthode SCRUM

1.7.1.3 Comparaison de deux méthodes

TABLE 1.3 – Comparaison entre les deux méthodes agiles SCRUM et XP

1.7.1.4 Méthodologie adoptée

F IGURE 1.5 – La méthodologie scrum

• Identifications des rôles :

Product Owner Scrum Master Scrum Team

TABLE 1.4 – Identifications des rôles

Pour la modélisation de la conception, nous avons choisi le langage UML.

2.2 Intelligence Artificielle (IA)

2.2.1 Définition de l’intelligence artificielle

F IGURE 2.1 – L’intelligence artificielle

2.2.2 L’intelligence artificielle dans la médecine

2.2.3 L’intelligence artificielle dans la médecine d’ophtalmologie

2.2.3.1 Système de détection des pathologies oculaires

2.2.3.2 Définition d’un chatbot

* Comment ça marche

F IGURE 2.2 – Principe de base d’un chatbot

* Chatbot et l’intelligence artificielle

* Chatbot avec intelligence artificielle

2.2.4 L’objectif d’un chatbot dans notre application