Vous êtes sur la page 1sur 48

Université de Carthage

L'École supérieure des communications de Tunis

RAPPORT DE

Stage d’Ingénieur

Sujet : Développement d’une


Application dédiée à l’analyse des
données médicales

Auteur :
Ouhibi Mouhamed
Entreprise : Yobitrust
Encadrant Entreprise : Mr. Agrebi Saïd
Adresse : Technopark El Gazala - B11 ,Ariana, Tunisie.
Tél : (+216) 53 994 295

Année Universitaire :2019/2020


Appréciations et signature de
l’encadrant
Remerciements

En guise de reconnaissance, je tiens à témoigner mes sincères remerciements à


toutes les personnes qui ont contribué de près ou de loin au bon déroulement de ce stage
et à l’élaboration de ce travail dans les meilleures conditions.

Je voudrais, aussi, exprimer mes sincères reconnaissances à l’équipe de Yobitrust , pour


leur patience, leurs conseils pleins de sens et pour le suivi et l’intérêt qu’ils ont portaient
à ce travail.

J’ai l’honneur d’exprimer à travers ces courtes lignes mes sincères reconnaissances à mon
encadrant Mr. Agrebi Saïd qui m’a accordé sa confiance et attribué des missions
valorisantes durant ce stage et qui m’a formé et accompagné tout au long de cette
expérience professionnelle avec beaucoup de patience et de pédagogie.

De ma part, j'espère que ma conduite et mon apprentissage ont laissé une bonne
impression de l’école supérieure des communications de Tunis et ont affirmé son image
de marque.
Table des matières

Introduction Générale 1

1 Contexte du projet .................................................................................................. 3


1.1 Présentation générale de l’organisme d’accueil .................................................... 3
1.1.1 El Ghazela Technopark ............................................................................. 3
1.1.2 Yobitrust .................................................................................................. 4
1.2 Spécification du projet .......................................................................................... 5
1.2.1 Cadre du projet .......................................................................................... 5
1.2.2 Problématique et solution proposée............................................................ 6
1.3 Conclusion ............................................................................................................ 6

2 Analyse et spécification des besoins ..................................................................... 8


2.1 Analyse des besoins............................................................................................... 8
2.1.1 Les besoins fonctionnels .................................................................................... 8
2.1.2 Les besoins non fonctionnels ........................................................................... 9
2.2 Spécification des besoins ....................................................................................... 9
2.2.1 Langage de modélisation ................................................................................... 9
2.2.2 Identifications des acteurs............................................................................... 10
2.2.3 Diagrammes des cas d’utilisation .................................................................. 10
2.2.4 Diagrammes de séquence ................................................................................ 11
2.3 Conclusion ........................................................................................................... 21

3 Conception ............................................................................................................... 22
3.1 Conception globale............................................................................................... 22
3.2 Architecture de l’application ................................................................................ 25
3.3 Diagramme de classe ............................................................................................ 26
3.4 Structure de données ........................................................................................... 27
3.4.1 Base de données orientée documents ............................................................. 27
3.4.2 Représentation des données dans une base orientée documents ................. 28
3.5 Conclusion ........................................................................................................... 29

4 Réalisation ................................................................................................................ 30
4.1 Environnement de travail .................................................................................... 30
4.1.1 Environnement matériel .................................................................................. 30
4.1.2 Environnement logiciel .................................................................................... 31
4.2 Choix techniques.................................................................................................. 32
4.2.1 Framework Spring Boot .................................................................................. 32
4.2.2 Framework React Native ................................................................................ 32
4.2.3 SGBD MongoDB ............................................................................................. 32
4.3 Aperçu sur le travail réalisé : Application mobile ................................................ 33
4.3.1 Chronogramme................................................................................................. 36
4.4 Conclusion ........................................................................................................... 36

Conclusion et perspectives 37

Netographie 39
Table des figures

1.1 Logo de Yobitrust ................................................................................................. 4


2.1 Diagramme des cas d’utilisation .......................................................................... 11
2.2 Diagramme de séquence du cas d’utilisation : SignUp ........................................ 12
2.3 Diagramme de séquence du cas d’utilisation : LogIn ........................................... 13
2.4 Diagramme de séquence du cas d’utilisation : consult measurement record ......... 14
2.5 Diagramme de séquence du cas d’utilisation : Edit profile ................................... 15
2.6 Diagramme de séquence du cas d’utilisation : Quick test .................................... 16
2.7 Diagramme de séquence du cas d’utilisation : continuous data storing
(connecting_device)............................................................................................. 18
2.8 Diagramme de séquence du cas d’utilisation : continuous data storing
(device_send_data)............................................................................................. 19
2.9 Diagramme de séquence du cas d’utilisation : Chatbot_without_data_access ... 20
2.10 Diagramme de séquence du cas d’utilisation : Chatbot_with_data_access ....... 21
3.1 Conception globale............................................................................................... 22
3.2 Fonctionnement d’un Chatbot ............................................................................. 24
3.3 Architecture MVC ............................................................................................... 26
3.4 Diagramme de classe ............................................................................................ 26
3.5 Collection : Data .................................................................................................. 28
3.6 Collection : User .................................................................................................. 28
4.1 Logo Visual Studio Code ..................................................................................... 31
4.2 Logo MongoDB Compass..................................................................................... 31
4.3 Logo Postman ...................................................................................................... 31
4.4 Logo IntelliJ IDEA .............................................................................................. 31
4.5 Logo Spring ......................................................................................................... 32
4.6 Logo React Native ............................................................................................... 32
4.7 Interface d’authentification .................................................................................. 33
4.8 Interface de création de compte ........................................................................... 33
4.9 Interface d’authentification avec error ................................................................. 34
4.10 Interface de profile ............................................................................................... 34
4.11 Interface de base .................................................................................................. 34
4.12 Interface de Test rapide ....................................................................................... 34
4.13 Interface de Résultat de test ................................................................................ 35
4.14 Interface de health record .................................................................................... 35
4.15 Interface de changement d'informations personnelles........................................... 35
4.15 Interface de changement d'informations personnelles (2) ..................................... 35
Liste des tableaux

4.1 Caractéristiques de la machine ............................................................................ 30


Liste des sigles et acronymes

AI Artificial Intelligence
NLP Natural Language Processing
MQTT Message Queuing Telemetry Transport
HTTP Hypertext Transfer Protocol
JSON JavaScript Object Notation
MVC Model View Controller
IDE Integrated Development Environment
API Application Programming Interface
Introduction générale

« Les données, c’est la nouvelle huile. » (Cité par l’entrepreneur innovant Will
Murphy). Avec les évolutions importantes qu’a connue la technologie ces dernières
années, les données ne cessent d’acquérir une importance cruciale au fil du temps. Elles
sont devenues le nouveau carburant pour donner une valeur aux grandes entreprises.
Par conséquent, la taille des données demeure en augmentation exponentielle de sorte
que d’innombrables papiers et méthodes ont été développés afin d’analyser
d’importantes sources de données aussi rapidement et efficacement que possible. Cette
taille gigantesque de données a fait naître de nouvelles voies de développement qui
influencent plusieurs secteurs notamment celui de l’e-santé. Ceci est dû à l’exploitation
de la TIC qui a énormément influencé le secteur de santé. Cette tendance s’affirme sous
un seul et unique objectif : combattre la maladie et la mort.

L’innovation dans cette industrie a permis de procurer l’Homme des moyens pour
devenir acteur de sa santé, révéler ou prédire l’apparition de certaines maladies plus
précocement, fournir des diagnostiques plus précises, établir un lien plus fort entre les
patients et les médecins et optimiser la création des nouveaux traitements. Par
conséquent, on trouve de nos jours plusieurs médecins qui encouragent l’utilisation de
ces applications.

Parmi les branches influencées par l’e-santé est le suivi d’un mode de vie sain connu
sous le nom « Healthy life style ». De nos jours, l’Homme moderne a atteint une
certaine maturité au point qu’il est devenu conscient des différents dangers qui peuvent
menacer sa santé tel que l’obésité.

D’après l’OMS 2,8 millions de personnes au moins décédant chaque année du fait de leur
surpoids ou de leur obésité[URL1]. En effet, cette dernière peut être à l’origine de

1
plusieurs maladies comme le diabète et le cholestérol et augmente énormément le risque
de mortalité.

Ainsi grâce à l’impact des réseaux sociaux comme Instagram la notion healthy life style
a connu une énorme célébrité et devenue en vogue dans le monde entier.

Face à la gravité des problèmes dues aux tel problème (exemple : obésité), un suivi
régulier devient un besoin crucial pour la survie des personnes atteintes et même pour
ceux qui veulent jouir d’une vie plus saine loin des maladies. L’application de
l’intelligence artificielle dans le domaine de la santé est devenue la tendance du siècle
par excellence. Comme les autres domaines, l’industrie médicale est bouleversée par les
technologies de l’IA qui a nettement élargi son champ d’applications. Avec
l’apprentissage profond qui s’accentue en permettant la collecte et l’analyse des données
massives le diagnostic médical, les techniques de prévention, de suivi des patients, ainsi
que les traitements ont connu un véritable essor.

Dans cette optique, mon travail vise à offrir l’utilisateur un moyen de suivre sa santé
pour mener à un mode de vie plus sain, grâce à une application conviviale.

Ce rapport décrit en détail la progression du projet qui se décompose essentiellement de


quatre chapitres : le premier chapitre portera sur le contexte du projet où je vais
présenter l’organisme d’accueil ainsi qu’une description du travail. Le deuxième chapitre
est consacré à l’analyse et la spécification des besoins. Le troisième chapitre a pour but
de décrire la modélisation conceptuelle globale et détaillée de la solution proposée. Enfin,
le dernier chapitre comportera l’étude technique réalisée, il comportera également des
captures d’écrans pour décrire les différentes fonctionnalités de l’application.

2
Chapitre 1
Contexte du projet

Dans ce chapitre, je vais décrire le contexte général du projet. Tout d’abord je


vais présenter l’organisme d’accueil et le travail qui sera élaboré. Ensuite je vais donner
une vue générale de mon travail.

1.1 Présentation générale de l’organisme d’accueil

1.1.1 El Ghazela Technopark

• Présentation et emplacement

Le Pole El Ghazela des technologies de communication « El ghazela technopark


», le premier Technoparc tunisien, fait partie de la stratégie nationale pour le
développement de la recherche scientifique, de l’innovation et de la production à haute
valeur ajoutée, par le biais d’une cartographie de 10 Technoparc spécialisés chacun dans
un secteur d’activité différent.

Le Technoparc El Ghazela est un environnement intégré pour le développement de


petites et moyennes entreprises ainsi que pour les multinationaux et les grands groupes
du secteur des technologies de l’information et de la communication. Son objectif
principal est d’accueillir et de soutenir le développement d’activités de haute technologie
et de promouvoir la recherche, le développement et le transfert de technologie.

3
• Priorités Stratégiques

Les principales priorités stratégiques du Technoparc sont reprises dans 5


domaines principaux qui sont :

1- Création d’entreprises : favoriser la création d’entreprises de TIC et


soutenir le processus de développement des activités de TIC.

2- Relais technologiques : Établir des relais technologiques entre la recherche,


les SEM et les multinationales en Tunisie.

3- Dynamique intersectorielle : impliquer différents secteurs économiques


dans les activités menées par le pôle et adapter l’offre et la demande de systèmes
TIC en Tunisie et créer un environnement de confiance.

4- Innovation : Promouvoir un environnement global propice à l’innovation


et aux acteurs du cluster.

5- Investissement : drainer les investissements directs étrangers.

1.1.2 Yobitrust

• Présentation

La mission de Yobitrust est de stimuler l’innovation liée à la science des données


et à l’intelligence artificielle (DSAI) appliquée à plusieurs domaines tels que la cyber
sécurité, l’industrie, l’internet des objets et le domaine médical.

Figure 1.1 – Logo de Yobitrust[URL2]

• Forme juridique

Yobitrust est une start-up d’équipe multidisciplinaire utilisant des outils


mathématiques pour analyser des données variables et développer des algorithmes pour
la santé, la cyber sécurité et l’internet des objets. DSAI Labs investit dans la Recherche
et développement multidisciplinaire centrée sur DSAI pour proposer des solutions
performantes et innovantes. Yobitrust dispose également d’un comité scientifique
multidisciplinaire doté d’une expertise de renommée internationale dans les domaines

4
des statistiques, de l’apprentissage automatique, de l’informatique répartie, de l’industrie
4.0 et de la ville intelligente, ainsi que dans le domaine de la biologie, des neurosciences
et des sciences cognitives.

• L’équipe Yobitrust

Derrière cette idée étonnante existe le fondateur de Yobitrust.

1- Said Agrebi responsable de la science des données et expert statisticien avec près de
20 ans d’expérience dans la direction de projets de business intelligence, de big data
et de science des données avec des multinationales (Allianz, Engie, L’Oréal, SG,
Thales, Eads, GIE CB, Scor, etc.)
2- Sans doute, il n’ya pas d’entreprise prospère sans son équipe d’experts dans différents
domaines que je peux citer : la santé et les maladies, l’images et le textes, la
génétique etc.

• Les services offerts par Yobitrust


1- les formations : En raison de l’énorme quantité de données générées chaque jour, il
est nécessaire de développer des compétences pour pouvoir optimiser notre capacité à
manipuler les données. La formation proposée par Yobitrust vous permet d’atteindre
un bon niveau de connaissances et de compétences dans le domaine de Big Data, de
la science des données et de l’intelligence artificielle.
2- Le traitement des données : Yobitrust est là pour vous aider à extraire des
connaissances à partir de données
3- les stages : Les stages sont offerts pour les étudiants, les chercheurs et toute personne
intéressée de faire partie d’une start-up dynamique gagnant un grand pas en avant
dans la science des données

1.2 Spécification du projet

1.2.1 Cadre du projet

Le fondateur de Yobitrust lui-même dans le cadre d’un stage ingénieur de deux


mois m’a proposé ce projet. En fait, ce projet fait partie du système innovant suivi par
la société qui comprend le développement, l’exploration de données, la sécurité,
l’internet des objets et l’intelligence artificielle au sein d’une architecture distribuée. Il
s’agit d’un grand projet réalisé par un groupe d’ingénieurs dont je fais partie et consiste

5
à développer un système dual « Application Mobile - Appareil connecté » pour
l'accusation, le suivi et l'analyse de des données santé a la base d’un système de gestion
et d’analyse distribuée en BackEnd

1.2.2 Problématique et solution proposée

Les systèmes multi-technologies constituent une approche technique permettant


de résoudre un problème spécifique. En le considérant comme objectif général englobant
une série de mini-défis. L’ensemble de ce système représente une End-To-End solution.
En général, dans une telle approche, l’équipe doit décomposer le problème principal en
une série de puzzles faciles à identifier dans un domaine particulier (problèmes d’IA,
d’IoT, de développement, etc.), puis intègre tout ça, dans un système singulier
L'accusation et l'analyse des données médicales indépendamment de l'intervention
humaine sont l'un des plus grands défis qui nécessitent une approche multi
technologique (comme indiqué ci-dessus). Face à ce défi, il est nécessaire de répondre à
d'autres problèmes tels que l'acquisition de données, la détection de l'état de santé, la
gestion des données (flux de données et stockage de données), sécurité des données ...

Créer un système autonome qui réponde aux besoins. Va aider les gens (normaux ou
patients) à suivre en temps réel leur état de santé, être averti en cas d'anomalie et être
alerté en cas de menace potentielle.

Mon travail consistait à développer la partie FrontEnd Mobile en React native ainsi que
la partie gestion des donnes BackEnd , développer l’API REST en Spring Boot . Les
outils technologiques permettant de répondre à ce sujet sont nombreux et le défi
consistait à développer une application conviviale qui répond aux besoins de l’utilisateur
en temps réel.

1.3 Conclusion

Dans ce premier chapitre, je souhaitais mettre en place le projet dans son


intégralité en présentant l’entreprise hôte en général et en donnant une idée générale de
ce que mon travail devait être dans ce projet.

6
Dans le chapitre suivant, je vais aller un peu plus loin dans les détails en expliquant des
notions théoriques fondamentales relatives à la compréhension du projet.

7
Chapitre 2
Analyse et spécification des besoins

Le but de l’analyse préalable du projet est de définir ce que le système doit faire
« le quoi » sans se préoccuper de la façon dont il doit le faire « le comment ». En effet,
la réussite de toute étude dépend de la qualité de son départ. De ce fait, l’étape de
spécification constitue la base de départ de ce travail.

Par ailleurs, l’aptitude de toute application à répondre aux besoins des


utilisateurs et aux traitements envisagés mettra en relief la valeur ajoutée de
l’application et son utilité future. Pour assurer ces objectifs, il est indispensable de
clarifier les différents besoins visés dans ce projet. Dans ce chapitre, nous allons donc
détailler les différentes fonctionnalités souhaitées.

2.1 Analyse des besoins

Dans cette étape critique pour le développement de l’application, on va se


concentrer sur l'identification des services que le système doit fournir et définir les
contraintes de réalisation.

2.1.1 Les besoins fonctionnels

Les besoins fonctionnels se réfèrent aux fonctions de base que l'application a une
fois développées doit exposer.

8
L’application doit fournir un ensemble spécifique des services qui sont :
• Création des comptes
• Authentification
• Gestion de profile ( nom , âge , groupe sanguin …)
• Lancer des tests médicaux : L'état de santé en fonction de Signes vitaux
• Consulter l’historiques des mesures de signes vitaux
• Connecter l’appareil* pour faire des mesures en temps réel
• Commencer une discussion avec le Chatbot ( service qui aide l’utilisateur à
interpréter les résultats a la base d’une conversation normale )

2.1.2 Les besoins non fonctionnels

Ce sont les besoins qui permettent d’améliorer la qualité des services de la


solution proposée, parmi les besoins non fonctionnels :
• Performance et flexibilité : La solution proposée doit être rapide, fiable et
opérationnel d’une façon continue
• Clarté : Cette solution doit avoir une interface graphique claire où la façon
d'utilisation Pourrait être compréhensible.
• Maintenance et évolutivité : Le code de l’application doit être bien lisible et
compréhensible pour pouvoir le maintenir facilement et rapidement. En outre,
le système doit être évolutif afin de répondre aux changements de besoins du
marché.
• La sécurité : Les données des utilisateurs de l’application n’auront aucun
risque de divulgation.

2.2 Spécification des besoins

Nous expliquerons dans cette section les acteurs qui interagissent avec le système
et les divers cas d'utilisation avec leurs scénarios associés. Par la suite, nous proposons
quelques diagrammes de séquence pour mieux comprendre l’application conçue.

2.2.1 Langage de modélisation

Pour la modélisation objet, on a utilisé le langage commun UML « Unified


Modeling Langage ». En effet, c’est un langage de modélisation et de conception des
programmes informatiques. De plus c’est un langage qui est standard et qui offre une

9
grande fluidité et une facilité en matière de représentation graphique des différents
diagrammes.

2.2.2 Identifications des acteurs

Un acteur est un élément externe qui interagit avec le système, il prend des
décisions et des initiatives. On considère dans cette application :
• Client : la personne qui utilise les services disponibles sur l'application mobile
• L’appareil de mesure : un appareil tiers, responsable de l'acquisition des
données (température, glycémie ...) et de l'envoyer au nom d'un utilisateur
• Base de données : entité de stockage des donnes
• Service de chatbot : un service externe ayant accès au profil et à l'historique
d'un patient afin de déterminer la réponse appropriée

2.2.3 Diagrammes des cas d’utilisation

Un cas d’utilisation modélise un service rendu par le système.


Il exprime les interactions acteurs/système et apporte une valeur ajoutée notable à
l’acteur concerné. Le modèle des cas d’utilisation, représenté dans la figure suivante,
définit les fonctionnalités auxquelles le client aura accès.

10
Figure 2.1 - Diagramme des cas d’utilisation

2.2.4 Les diagrammes de séquence

Un diagramme de séquence illustre précisément les interactions entre les


composants différents de l’application pour réaliser une action

11
• Diagramme de séquence du cas d’utilisation : SignUp

Figure 2.2 - Diagramme de séquence du cas d’utilisation : SignUp

12
• Diagramme de séquence du cas d’utilisation : LogIn

Figure 2.3 - Diagramme de séquence du cas d’utilisation : LogIn

13
• Diagramme de séquence du cas d’utilisation : consult measurement
record

Figure 2.4 - Diagramme de séquence du cas d’utilisation : consult measurement record

14
• Diagramme de séquence du cas d’utilisation : Edit profile

Figure 2.5 - Diagramme de séquence du cas d’utilisation : Edit profile

15
• Diagramme de séquence du cas d’utilisation : Quick test

Figure 2.6 - Diagramme de séquence du cas d’utilisation : Quick test

16
« Generate health status according to data »* :
L’une des fonctions de notre application est d’interpréter les résultats des mesures
des signaux vitaux. Bien que cette interprétation soit clairement un problème de
classification AI, nous n’avons pas le temps de créer un tel modèle. Mais au lieu
de ça, nous avons pensé d’implémenter une fonction mathématique qui retourne
si la valeur mesurée est dans des intervalles normaux, la fonction est :

𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑛𝑛𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉 𝑇𝑇 = 𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉 𝑇𝑇 ∙ 𝐷𝐷𝐷𝐷𝑐𝑐𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑛𝑛𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚


𝑠𝑠𝑠𝑠𝑠𝑠ℎ 𝑎𝑎𝑎𝑎
𝑋𝑋0
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉 = � ⋮ � ; 𝑋𝑋𝑖𝑖 : 𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣 𝑜𝑜𝑜𝑜 𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣 𝑖𝑖 ( 𝑒𝑒𝑒𝑒𝑒𝑒: 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 )
𝑋𝑋𝑛𝑛−1
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝑛𝑛𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚 = 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑(𝐼𝐼𝑖𝑖𝑖𝑖 ); 𝐼𝐼𝑖𝑖𝑖𝑖 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐 𝑡𝑡𝑡𝑡 𝑡𝑡ℎ𝑒𝑒 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛 𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 𝑜𝑜𝑜𝑜 𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣 𝑖𝑖
1 𝑖𝑖𝑖𝑖 𝑋𝑋𝑖𝑖 > max (𝐼𝐼𝑖𝑖𝑖𝑖 )
𝑋𝑋𝑖𝑖 ∙ 𝐼𝐼𝑖𝑖𝑖𝑖 = �−1 𝑖𝑖𝑖𝑖 𝑋𝑋𝑖𝑖 < min (𝐼𝐼𝑖𝑖𝑖𝑖 )
0 𝑖𝑖𝑖𝑖 𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒

17
• Diagramme de séquence du cas d’utilisation : continuous data
storing _connecting_device

Figure 2.7 - Diagramme de séquence du cas d’utilisation : continuous data storing _connecting_device

18
• Diagramme de séquence du cas d’utilisation : continuous data
storing _device_send_data

Figure 2.8 - Diagramme de séquence du cas d’utilisation : continuous data storing _device_send_data

19
• Diagramme de séquence du cas d’utilisation :
Chatbot_without_data_access

Figure 2.9 - Diagramme de séquence du cas d’utilisation : Chatbot_without_data_access

20
• Diagramme de séquence du cas d’utilisation :
Chatbot_with_data_access

Figure 2.10 - Diagramme de séquence du cas d’utilisation : Chatbot_with_data_access

2.3 Conclusion
Dans cette partie, nous avons décrit les fonctionnalités de l’application tout en
précisant les différents cas d’utilisations et les diagrammes de séquence. Nous essayerons
dans le chapitre qui suit de concevoir clairement l’architecture de ce système.

21
Chapitre 3
Conception

Afin d’atteindre les résultats escomptés, on a dû organiser les besoins, exprimés


dans le chapitre analyse et spécification des besoins, selon une méthodologie de
conception qui a le mérite de faciliter la phase de réalisation. Ce chapitre présenter
l’architecture adoptée pour concevoir cette application ainsi que le diagramme de classes
et la conception des données.

3.1 Conception globale

Dans cette phase, nous allons présenter une vue d'ensemble complète de notre
projet tout en détaillant les autres parties dont mes collègues ont les responsables.

Figure 3.1 - Conception globale

22
La solution proposée par Yobitrust est une solution de End-To-End qui intègre
plusieurs technologies réparties comme suit :

• Acquisition des données capteurs et l’envoie à travers le


protocole MQTT/HTTP :

Notre appareil IoT est un gadget portable intelligent, qui détecte les signes vitaux
de l'utilisateur tels que la température, glycémie, rythme cardiaque et d’autres (en totale
6 variables) et envoie les données de manière configurable via le protocole MQTT ou
bien communication à travers les APIs http. L’utilisateur a le choix soit d'autoriser un
transfert continu des données, soit d'imposer une approbation préalable à chaque
utilisation ; l'appareil fonctionne indépendamment de l'appareil, ce qui exige un flux de
données indépendant allant de l'appareil directement au serveur. bien entendu,
l'utilisateur doit toujours avoir le contrôle sur l'appareil, qui est assuré par
l'intermédiaire du serveur. Cette indépendance entre l'appareil et l'application mobile
donne à l'utilisateur la flexibilité et l'efficacité dans certains cas particuliers, tels que
l'utilisation de l'appareil chez un autre utilisateur (un ancien, un patient ...) ou même
l'utiliser pour faire des activités sportives pour cela l’appareil doit répondre à certains
besoins et respecter quelques contraintes, comme :
- Autonome en termes de connectivité : pour cela, l'appareil est équipé de
modules wifi, 3G / 4G / LTE. Et pour les grands espaces dépourvus de Wi-Fi et d'un
réseau cellulaire puissant, nous envisageons actuellement d'utiliser le réseau LoRa.
L’appareil doit déterminer la meilleure alternative pour envoyer des données à partir des
technologies ci-dessus, en respectant certaines contraintes telles que le coût, la vitesse,
l'efficacité et le coût énergétique de la communication
- Efficace en termes de consommation d'énergie : l'appareil doit répondre
aux spécifications ; détecter les signes vitaux et transmettre les données à la demande,
avec une autonomie de batterie relativement longue. L’utilisation d'un capteur précis
peut affecter la contrainte d'autonomie de la batterie. Pour la contrepartie, la qualité
des données est également essentielle pour que le système fonctionne normalement
- Flexible en termes d'utilisation : le périphérique doit prendre en charge
plusieurs utilisateurs, ce qui signifie que le même périphérique doit être partageable pour
plusieurs utilisateurs. Comme nous spécifions précédemment que le périphérique et
l'application mobile sont indépendants, la question qui se pose est de savoir comment
lier chaque opération de mesure à un utilisateur spécifique plutôt que de lier chaque
périphérique à un utilisateur. pour cela, nous avions prévu d’identifier chaque appareil
avec un ID unique, que l’utilisateur (à travers l’application mobile) devait indiquer,

23
lorsqu'un utilisateur est abonné à l’appareil , aucun autre utilisateur n’est autorisé à s’y
abonner (un abonnement unique via l'identifiant de l'appareil)

• Développement des agents conversationnels "Chatbots " en


utilisant NLP (Natural Language Processing) :

Un chatbot est un outil logiciel qui utilise le traitement du langage naturel (NLP)
pour l’interaction homme-machine (IHM) et l’apprentissage automatique (ML). "La
complexité d'un chatbot est proportionnelle à l'étendue du domaine". Un domaine
ouvert nécessite une base de connaissances plus étendue, tandis qu'un domaine fermé
possède une base de connaissances plus spécifique qui a été développée pour atteindre un
objectif spécifique. Nous avons réservé une interface de communication dans notre
application afin de faciliter l'interprétation des données de chaque utilisateur. le principe
est d'utiliser un chatbot qui interprète la question et y répondre en fonction de l'état
physique de l'utilisateur . De manière très classique, le fonctionnement d’un Chatbot est
le suivant :

- L’utilisateur questionne le Chatbot, vocalement ou textuellement via une


interface dédié .
- Un moteur de traitement du langage naturel (NLP) reçoit le texte brut
correspondant à la question de l’utilisateur, l’interprète et renvoie une donnée (la
plupart du temps au format JSON) structurée, sous la forme intention/entités.
- Un moteur conversationnel (service Indépendant) traite la donnée retournée par
le moteur NLP et construit une réponse en fonction de celle-ci. Le moteur
conversationnel est en lien avec notre base de donnés ( via API getway) pour
obtenir des informations pour construire la réponse.
- La réponse est retournée à l’utilisateur

Figure 3.2 - Fonctionnement d’un Chatbot[URL3]

24
• Sécurisation du système :

Nous pouvons protéger nos données par un mot de passe et utiliser des mesures
de sécurité plus avancées, telles que le cryptage des communications, le contrôle d'accès
basé sur les rôles, le filtrage IP et l'audit.

3.2 Architecture de l’application

Pour la conception de n'importe quelle application, il est nécessaire de choisir


l'architecture logique appropriée qui assure la bonne opération et la performance. Cette
application est basée sur l’architecture MVC (Model View Controller) qui permet de
faciliter le développement, l’évolutivité et la maintenance des projets.

MVC est un patron de conception (ou design pattern en anglais) désormais très répandu
pour réaliser des sites web. Ce design pattern est une solution reconnue permettant de
séparer l’affichage des informations (la vue), les actions de l’utilisateur (le contrôleur) et
l’accès aux données (le modèle).[URL4]

• Model : Un modèle contient les données de l'application. Une donnée


peut être un objet unique ou une collection d'objets. Il traite
principalement les données et les interactions avec la base de données.
• Controller : Un contrôleur contient la logique applicative d'une
application. Il fait le lien entre le modèle et la vue, il gère les requêtes
des utilisateurs et détermine les traitements qui doivent être effectués
pour chaque action. Il va utiliser les données du modèle, les traiter et
les envoyer à la vue pour que celle-ci les affiche.
• View : traite ce que nous voyons dans notre navigateur web, elle
restitue le modèle au sein de notre interface web et permet à
l’utilisateur d’interagir avec le modèle.
• Front Controller : Dans Spring Web MVC, la classe DispatcherServlet
fonctionne en tant que contrôleur frontal. Il est chargé de gérer le flux
de l'application Spring MVC.

La figure de la page suivante fournit une vue d’ensemble de l’architecture du modèle


MVC et les interactions entre ses différentes entités (modèle, vue, contrôleur et front
Controller) :

25
Figure 3.3 - architecture mvc

3.3 Diagramme de classe

Les diagrammes de classes sont l'un des types de diagrammes UML les plus
utiles, car ils décrivent clairement la structure d’un système particulier en modélisant ses
classes, ses attributs, ses opérations et les relations entre ses objets.

La figure suivante représente le diagramme de classe général de l’application :

Figure 3.4 – diagramme de classe

26
• Users : cette classe contient tous les détails de l'utilisateur. Chaque
utilisateur est identifié par son id, son nom, email et le hash de mot de
passe. Un utilisateur peut ajouter des data, commences une
conversation avec chabot, connecter un appareil …
• Devices : cette classe contient l’ID d’appareil ainsi l’ID utilisateur que
l’utilise (on peut se trouve dans des cas ou l’appareil et partageable entre
plusieurs utilisateurs ou que aucun utilisateur l’utilise)
• Data : cette classe représente les données des mesures stocker via
l’appareil ou bien manuellement par l’utilisateur, la partie « process »
et le résultat d’analyse générée par le system
• Conversations : cette classe contient tout les conversation (question –
réponse)

3.4 Structure de données

L’approche que nous avons adaptée pour notre projet consiste à utiliser une base
de données NoSQL orientée document pour des raisons liées à la flexibilité et à
l'évolutivité dont nous avons besoin pour des traitement à long terme (migration Big
Data, application AI …)

3.4.1 Base de données orientée documents

Une base de données de documents est un type de base de données non


relationnelle conçu pour stocker et interroger des données sous forme de documents de
type JSON. Les bases de données de documents permettent aux développeurs de stocker
et d'interroger une base de données en utilisant le même format de modèle de document
que celui qu'ils utilisent dans leur code d'application. La nature souple, semi-structurée
et hiérarchique des documents et des bases de données de documents leur permet
d'évoluer avec les besoins des applications. Le modèle de document fonctionne bien avec
les cas d’utilisation, comme des catalogues, des profils d'utilisateurs et des systèmes de
gestion de contenu où chaque document est unique et évolue au fil du temps. Les bases
de données de documents permettent une indexation flexible, des requêtes ad hoc
efficaces et des analyses sur des recueils de documents.[URL5]

27
3.4.2 Représentation des données dans une base orientée
documents

D’une manière générale, les documents structurés sont des graphes dont chaque
partie est auto-décrite

• Représentation de collection : Data

Figure 3.5 – collection : Data

• Représentation de collection : User

Figure 3.6 – collection : User

28
3.5 Conclusion

Dans ce chapitre, nous avons parlé dans un premier temps de la conception


globale. Ensuite l’approche architecturale à adopter pour ce système. Puis, nous avons
décrit les différentes parties de l’architecture utilisée par les diagrammes de classe et la
structure des données. Le prochain chapitre sera une discussion de nos choix techniques
de la phase de mise en œuvre de notre application.

29
Chapitre 4
Réalisation

Les choix des environnements logiciel et matériel ainsi que les technologies
constituent une étape primordiale dans la mise en œuvre de tout projet. De ce fait, ce
chapitre sera consacré à la présentation des déploiements matériels, langages, outils de
programmation ainsi qu’aux technologies adoptés qui me permettent d’aboutir à la
réalisation de ce travail.

4.1 Environnement de travail

Dans les parties qui suivent je vais détailler les environnements matériels et
logiciels qui m’ont permis d’accomplir ce travail.

4.1.1 Environnement matériel

Processeur Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz 1.90 GHz


RAM 6 Go
Disque Dur 400 Go
Système d’exploitation Windows 10 Pro
Tableau 4.1 - Caractéristiques de la machine

30
4.1.2 Environnement logiciel

Dans cette partie, nous listons les différents logiciels que nous avons utilisés tout
au long du développement de notre application :

• Visual Studio Code

C’est un ensemble complet d'outils de développement permettant


de générer des projets ReactNative pour le développement des
application native, cross platform pour IOS et Android en utilisant
Figure 4.1 – Logo
JavaScript Visual Studio
Code[URL6]

• MongoDB Compass

C'est un outil d'interface graphique qui affiche des informations


sur une base de données MongoDB et effectue des requêtes. Il vous
permet de créer facilement des requêtes et à modifier éventuellement
la commande de requête générée si vous souhaitez plus de contrôle.
Figure 4.2 – Logo
MongoDB
Compass[URL7]

• Postman

Parmi les nombreuses solutions pour interroger ou tester


webservices et API, Postman propose de nombreuses fonctionnalités,
une prise en main rapide et une interface graphique agréable.
Figure 4.3 – Logo
Postman [URL8]

• IntelliJ IDEA

C’est un environnement de développement intégré de technologie


Java destiné au développement de logiciels informatiques. Il intègre de
nombreuses fonctionnalités pour aider les développeurs qui utilisent
Spring et Spring Boot, ce qui leur permet de tester et de déboguer leurs
Figure 4.4 – Logo
applications plus facilement IntelliJ IDEA[URL9]

31
4.2 Choix techniques

4.2.1 Framework Spring Boot

Spring Boot est un Framework Java open


source utilisé pour créer des micro services.
Développé par l’équipe Pivotal, il est utilisé
pour créer des applications Spring autonomes et
prêtes à la production. Il permet de configurer
automatiquement votre application. En d'autres Figure 4.5 – Logo Spring[URL10]
termes, si vous avez importé des dépendances,
Spring Boot ira consulter cette liste puis produira la configuration nécessaire pour que
tout fonctionne correctement. Aussi lorsqu'on commence le développement d'un
Microservice. Un starter va apporter à votre projet un ensemble de dépendances,
communément utilisées pour un type de projet donné. Ceci va vous permettre de créer
un "squelette" prêt à l'emploi très rapidement.[URL11]

4.2.2 Framework React Native

Il s'agit d'un framework créé par Facebook à la suite d'un


Hackaton en 2015. React Native est basé sur React, une librairie
Javascript développée deux ans auparavant par un ingénieur
Facebook (Jordan Walke), [URL13]

Il est utilisé pour développer des applications pour Android, iOS et


UWP en permettant aux développeurs d’utiliser React avec les
Figure 4.6 – Logo React
fonctionnalitées native de ces plateformes. Native[URL12]

4.2.3 SGBD MongoDB

MongoDB est une base de données distribuée, universelle et basée sur des
documents, qui a été conçue pour les développeurs d'applications modernes et pour l'ère
du Cloud , répartissable sur un nombre quelconque d'ordinateurs et ne nécessitant pas
de schéma prédéfini des données.[URL14]

32
4.3 Aperçu sur le travail réalisé : Application mobile

Ces interfaces ont été capturées lors de l'exécution de l'application dans les
conditions suivantes

• Le serveur d’application est en mode « standalone » à la base de


conteneur de servlet « Tomcat » hébergé localement sur le port 8080
• La base de données « MongoDB » est en mode locale host sur le port
27017
• L’application mobile fonctionne en mode Test sur le platform « expo »
sur le port 19000
• Les tests ont été réalisés avec IPhone 5 sous le système Ios

Figure 4.7 - Interface d’authentification Figure 4.8 - Interface de création de compte

33
Figure 4.9 - Interface d’authentification avec error Figure 4.10 - Interface de profile

Figure 4.11 - Interface de base Figure 4.12 - Interface de Test rapide

34
Figure 4.13 - Interface de Résultat de test Figure 4.14 – interface de health record

Figure 4.15 – interface de changement Figure 4.16 – interface de changement


d'informations personnelles d'informations personnelles(2)

35
4.3.1 Chronogramme

Ce travail a été réalisé durant une période de 2 mois.En effet les deux premiéres
semaines étaient dédiées à la documentation et la familiarisation avec les outils de
travail. Dans la semaine qui suit je me suis concentrée sur la conception et la
spécification des besoins du systéme. Puis, la quatiéme et la cinquiéme semaine étaient
celles de l’implémentaion des interfaces du font end. Durant les deux semaines suivantes
j’ai développé le service BackEnd, En fin pendent la dernière semaine j’ai travaillé sur la
mise en oeuvre de system dans ça intégrité

4.4 Conclusion

Dans ce chapitre, j’ai expliqué les différentes technologies, environements


matériels et logiciels qui m’ont offert un environnement favorable à la mise en oeuvre du
projet. J’ai également présenté les interfaces utilisateurs de l’application.

36
Conclusion et perspectives

Dans le cadre de ce projet, j'ai eu l'occasion de concevoir et de développer une


application de bout en bout (FrontEnd et BackEnd) pour collecter, stocker et analyser
des données à partir de mesures des signaux vitaux d'un utilisateur.

J'ai utilisé le Framework "React native" pour concevoir l'application mobile et "Spring
boot" pour les services web. Cette application permet aux utilisateurs de suivre et
d'interpréter leur état de santé.

A travers ce document, nous avons détaillé, en quatre chapitres, les différentes étapes de
la réalisation de ce travail. Tout d'abord, nous avons présenté l'organisme d’accueil et le
cadre général de notre travail. Dans le Deuxième chapitre, nous avons spécifié les
besoins que nous a permis de préciser les différentes fonctionnalités offertes par le
système. Ensuite, nous avons présenté la conception en mettant en évidence
l'architecture du système. Enfin, nous avons décrit les outils utilisés et notre réalisation.

Pour conclure, après deux mois, mon expérience s’enrichit et mes connaissances
approfondissent. En outre, ce projet j’ai donné l’occasion de me mettre dans les
conditions de travail en équipe et sous la supervision d'un encadrant qui m’a
essentiellement préparé pour démarrer la vie professionnelle en renforçant ma
compétence et en améliorant ma capacité de travail.

Finalement, en guise de perspectives pour ce projet, nous prévoyons intégrer des models
Machine learning plus sophistiqués afin de permettre de prédire l’état de la santé plus
précisément et même de prédire les cas des maladies et des dangers potentiels , aussi
d’implémenter des services de gestion de régime alimentaire supplémentaires

37
Résumé — Ce rapport décrit les étapes de conception et de développement d’une
système dédiée à la gestion et l’analyse des données médicales d’un utilisateur ,travaillé
avec un groupe d’ingénieurs dans le cadre d’un stage d’été de deux mois.

Ma Tâche consiste à développer La partie FrontEnd par « React Native » et la patie


BackEnd par « Spring Boot ».

Mots clés : Gestion de données, analyse de données, l’état de santé, les signaux vitaux

38
Netographie

[URL1] https://www.who.int/features/factfiles/obesity/fr/

[URL2] https://yobitrust.com/

[URL3] https://blog.octo.com/compte-rendu-petit-dejeuner-psychanalyse-du-
chatbot/

[URL4] https://www.javatpoint.com/spring-mvc-tutorial

[URL5] https://aws.amazon.com/fr/nosql/document/

[URL6] https://code.visualstudio.com/

[URL7] https://www.mongodb.com/products/compass

[URL8] https://www.getpostman.com/

[URL9] https://www.jetbrains.com/idea/

[URL10] https://spring.io/projects/spring-boot

[URL11] https://openclassrooms.com/fr/courses/4668056-construisez-des-
microservices/5122425-decouvrez-le-framework-spring-boot

[URL12] https://facebook.github.io/react-native/

[URL13] https://medium.com/@Nextoo/react-native-a6ea0138f1b7

[URL14] https://www.mongodb.com/mongodb-scale

39