République Tunisienne Ingénieur en :

Ministère de l’Enseignement Supérieur Génie Systèmes Électroniques

et de la Recherche Scientifique et Communication

Université de Sfax Option :

Systèmes Embarqués
École nationale d’électronique
et des télécommunications de Sfax

RAPPORT DE STAGE

présenté à

L’École Nationale d’Électronique et des

Télécommunications de Sfax

Génie des Systèmes Electroniques de Communication

Option :
Systèmes Embarqués

par

Iheb Tliba

Développement et Évaluation de la Solution de Surveillance

du Diabète AlphaGly

Annnée Universitaire 2022 / 2023

 REMERCIEMENT

À l’issue de mon stage, je tiens à exprimer ma profonde gratitude envers toutes les personnes
dont l’apport a été essentiel à la réussite de cette expérience professionnelle. J’espère que ce
rapport reflète pleinement le travail accompli et qu’il satisfait l’ensemble des parties prenantes.

Tout d’abord, je souhaite remercier chaleureusement M. Behjat Bossofara pour m’avoir

accueilli au sein de l’entreprise et pour avoir créé des conditions de travail optimales. Ma
reconnaissance va également à Mme. Imen Ayari, ingénieure mécanique et chef de projet, qui
a été ma superviseure tout au long du stage. Je ne saurais oublier la précieuse contribution
de Mme. Racha Friji, ingénieure chercheuse en intelligence artificielle, qui a été une source
d’inspiration et de conseils inestimables pour mon projet.

Je tiens également à exprimer ma gratitude envers toute l’équipe du département Innovation

Factory, qui m’a apporté une aide précieuse et d’importants conseils concernant les missions
décrites dans ce rapport. Leur soutien constant, le temps qu’ils m’ont accordé et la confiance
qu’ils m’ont témoignée ont été essentiels pour la réussite de ce stage d’ingénieur.

Mes remerciements vont également à tous les membres du jury pour l’honneur qu’ils m’ont
fait en me permettant de présenter ma soutenance. Je n’oublie pas non plus de remercier l’ensemble
de mes professeurs à l’École Nationale d’Électronique et de Télécommunications de Sfax pour
la formation de haute qualité qu’ils m’ont dispensée. .

ENET’COM SFAX Page i

 TABLE DES MATIÈRES

LISTE DES FIGURES v

LISTE DES TABLEAUX vi

LISTE DES ABRÉVIATIONS vii

INTRODUCTION GÉNÉRALE 1

1 Cadre général du projet 2

1.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Talan Tunisie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Histoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Secteur d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.4 Organigramme de l’entreprise . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.3 Solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Démarche et méthodologie adoptées . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.1 Les rôles dans SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.2 Artefacts de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Les événements SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5.1 Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5.2 Sprint Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.3 Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.4 Rétrospective Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6 CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

ENET’COM SFAX Page ii

TABLE DES MATIÈRES

2 Étude conceptuelle et théorique 13

2.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Analyse et spécifications des besoins . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Les Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . 16
2.3.1.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . 16
2.3.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2.1 Diagramme de classe global . . . . . . . . . . . . . . . . . 17
2.3.2.2 Diagramme de classe de mesure . . . . . . . . . . . . . . . 20
2.3.3 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.3.1 Diagramme d’authentification . . . . . . . . . . . . . . . . . 20
2.4 CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Réalisation 22
3.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Environnement du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Architecture et interface de l’application . . . . . . . . . . . . . . . . . . . . . 25
3.3.1 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Les sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.1 Sprint 0 : Analyse du Cahier des Charges et Exploration du Code :
Comprendre les Besoins et les Bases du Projet AlphaGly . . . . . . . . 26
3.4.1.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.1.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4.2 Sprint 1 : Mise en place de l’Authentification de Base . . . . . . . . . . 29
3.4.2.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.2.2 Sprint 1 Backlog . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.2.3 Architecture de l’application . . . . . . . . . . . . . . . . . 30
3.4.2.4 Base de données . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.2.5 Interfaces utilisateur . . . . . . . . . . . . . . . . . . . . . . 30
3.4.3 Sprint 2 : Gestion des Appareils de Mesure . . . . . . . . . . . . . . . 32
3.4.3.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.3.2 Sprint 2 Backlog . . . . . . . . . . . . . . . . . . . . . . . . 32

ENET’COM SFAX Page iii

TABLE DES MATIÈRES

3.4.3.3 Interfaces utilisateur . . . . . . . . . . . . . . . . . . . . . . 33

3.4.4 Sprint 3 : Gestion et Envoi de Notifications . . . . . . . . . . . . . . . 34
3.4.4.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.4.2 Sprint 3 Backlog . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.4.3 Interfaces utilisateur . . . . . . . . . . . . . . . . . . . . . . 35
3.4.5 Sprint 4 : Implémentation du Chatbot pour l’Assistance Utilisateur . . . 36
3.4.5.1 Objectifs du Sprint 4 . . . . . . . . . . . . . . . . . . . . . . 36
3.4.5.2 Sprint 4 Backlog . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.5.3 Interfaces utilisateur . . . . . . . . . . . . . . . . . . . . . . 38

CONCLUSION GÉNÉRALE 39

BIBLIOGRAPHIE 39

ENET’COM SFAX Page iv

 LISTE DES FIGURES

1.1 Talan Tunisie Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Talan consulting worldwide . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 . Talan Tunisia organization chart . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Les rôles dans SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Artéfacts de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Les évènements SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . 17

2.2 diagramme de classe global . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Diagramme de classe de mesure . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Diagramme de séquence «s’authentifier». . . . . . . . . . . . . . . . . . . . . 21

3.1 Flutter Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Spring Boot Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Python Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Arduino Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5 Blender Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.8 Mot de passe oublié . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.9 Interface de mesure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.10 Analyse du glucose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.11 Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.12 Interface de chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

ENET’COM SFAX Page v

 LISTE DES TABLEAUX

3.1 User Stories pour le Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Conception de la base de données . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3 User S tories pour le Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4 User Stories pour le Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.5 User Stories pour le Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.6 Tâches Techniques pour le Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . 38

ENET’COM SFAX Page vi

 LISTE DES ABRÉVIATIONS

IOT Internet des objets

IA Intelligence Artificielle

AMG Auto-Monitoring de la Glycémie

CGM Systèmes de Surveillance en Continu de la Glycémie

UML Langage de Modélisation Unifié

IDE Environnement de Développement Intégré

MVC Modèle-Vue-Contrôleur

API Interface de Programmation Applicative

ENET’COM SFAX Page vii

 INTRODUCTION GÉNÉRALE

Le diabète représente aujourd’hui un défi majeur pour la santé publique, touchant plus de
463 millions de personnes à travers le monde et avec près de 19 millions de nouveaux cas
diagnostiqués chaque année. Face à cette pandémie silencieuse, il est impératif de trouver des
solutions innovantes pour améliorer la qualité de vie des patients et alléger le fardeau sur les
systèmes de santé mondiaux.

Au sein de ce contexte, nous explorons une idée de projet novatrice : le microchip AlphaGly.
Ce concept visionnaire vise à révolutionner la gestion du diabète en proposant une surveillance
continue et non invasive de la glycémie. Bien que le microchip AlphaGly ne soit pas encore une
réalité, il offre un potentiel considérable pour améliorer la vie des patients diabétiques.

L’objectif de ce rapport est d’examiner en détail cette idée de projet et d’explorer comment
elle pourrait changer la donne pour les personnes atteintes de diabète à l’échelle mondiale.
Nous allons envisager les possibilités futures de développement de cette technologie, ainsi que
les avantages potentiels qu’elle pourrait apporter. Bien que le microchip AlphaGly n’ait pas
encore été créé, il représente une lueur d’espoir et un appel à l’innovation pour relever le défi
du diabète qui persiste.

Rejoignez-nous dans cette réflexion sur l’avenir de la gestion du diabète et sur la manière
dont des idées novatrices peuvent avoir un impact significatif sur la vie de millions de personnes
à travers le monde. .

ENET’COM SFAX Page 1

Chapitre

1
Cadre général du projet

Sommaire
1.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . 3
1.2.1 Talan Tunisie . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Histoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Secteur d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.4 Organigramme de l’entreprise . . . . . . . . . . . . . . . . . . . 5
1.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.3 Solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Démarche et méthodologie adoptées . . . . . . . . . . . . . . . 9
1.4.1 Les rôles dans SCRUM . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.2 Artefacts de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Les événements SCRUM . . . . . . . . . . . . . . . . . . . . . . 10
1.5.1 Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5.2 Sprint Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.3 Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.4 Rétrospective Sprint . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6 CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

ENET’COM SFAX Page 2

CADRE GÉNÉRAL DU PROJET

1.1 INTRODUCTION

L’étude d’un projet est une étape essentielle pour permettre de donner une vision globale
sur celui-ci pour bien organiser son déroulement. Ce premier chapitre a donc comme objectif
de placer le projet dans son cadre général. Il est composé d’une présentation de l’organisme
d’accueil, l’introduction du contexte de projet et la méthodologie de travail.

1.2 Présentation de l’organisme d’accueil

Dans cette section, nous vous invitons à découvrir "Talan Tunisia International", l’entreprise
qui a ouvert ses portes à notre projet , ainsi que le département "Innovation Factory" où nous
avons réalisé notre travail. Explorez l’univers de notre organisme d’accueil et son rôle essentiel
dans notre parcours académique et professionnel.

F IGURE 1.1 – Talan Tunisie Logo

1.2.1 Talan Tunisie

Talan a été fondée en 2002 par Mehdi Houas, Eric Ben Amou et Philippe Cassoulat. Elle
offre ses services en matière de gestion, de fonctionnalités et de technologies à l’échelle internationale,
avec plus de 6 000 employés et 32 implantations. La société est présente sur quatre continents,
notamment en Australie, en Belgique, au Canada, en France, à Hong Kong, au Luxembourg,
au Maroc, à Singapour, en Espagne, en Suisse, en Tunisie et au Royaume-Uni, comme illustré
dans la Figure 1.2.

ENET’COM SFAX Page 3

CADRE GÉNÉRAL DU PROJET

Talan a créé un centre de développement en Tunisie appelé "Talan Tunisia Consulting" pour
renforcer son développement, mobilisant à ce jour environ 200 ingénieurs de développement
technologique supplémentaires et collaborant avec des clients européens clés. [01]

F IGURE 1.2 – Talan consulting worldwide

1.2.2 Histoire

— Juin 2002 : Création de l’entreprise.

— Septembre 2002 : Lancement de l’activité en France, au Royaume-Uni et au Benelux.

— Janvier 2006 : Ouverture du bureau de New York.

— Mars 2006 : Lancement de l’activité "nearshore" en Tunisie.

— Février 2007 : Ouverture du bureau de Hong Kong.

— Décembre 2008 : 320 consultants, 27 millions de dollars de chiffre d’affaires.

1.2.3 Secteur d’activité

— Le secteur financier : en collaborant avec des banques d’investissement et des compagnies

d’assurance.

ENET’COM SFAX Page 4

CADRE GÉNÉRAL DU PROJET

— Le secteur des télécommunications : à travers des projets pour les opérateurs de télécommunications
et une gamme de fournisseurs de services Internet.

— Le secteur des transports et de la logistique.

— Le secteur de l’énergie : grâce à des projets de développement destinés aux opérateurs

d’électricité, de gaz, d’eau, etc.

Ces différents secteurs se caractérisent par la fourniture d’un ensemble de services, notamment :

— Le conseil et l’assistance à la gestion de projet.

— La refonte et l’optimisation des processus métier.

— Le soutien aux projets majeurs de transformation.

— L’alignement des systèmes d’information sur les changements organisationnels et la gestion

du changement.

1.2.4 Organigramme de l’entreprise

Talan déploie ses compétences commerciales, fonctionnelles et technologiques à l’échelle

internationale, avec des bureaux à Paris, Londres, Tunis, New York et Hong Kong. En 2008,
Talan a établi son centre de développement en Tunisie. À ce jour, plus de 500 ingénieurs de
développement travaillent sur de nouvelles technologies. L’organisation de cette entreprise est
illustrée dans la Figure 1.3.

ENET’COM SFAX Page 5

CADRE GÉNÉRAL DU PROJET

F IGURE 1.3 – . Talan Tunisia organization chart

Talan Innovation Factory Talan Tunisia considère l’innovation comme le cœur de son
développement et mène ses activités dans des domaines liés à la transformation numérique de
grandes entreprises, c’est pourquoi le département Talan Innovation Factory y est également
impliqué. Talan Innovation Factory représente le département RD[2] de Talan Tunisia, qui
a commencé ses activités en 2017. Il explore des technologies perturbatrices telles que la
blockchain[3], l’Internet des objets (IoT)[4], la science des données et l’intelligence artificielle(IA)
[5].

1.3 Présentation du projet

Une étape essentielle pour tout projet consiste à effectuer une étude préalable. En effet, dans
le cas général, la mise en place d’un projet est due à un problème, il faut donc bien étudier
l’existant pour obtenir des solutions efficaces qui répondent au besoin.

ENET’COM SFAX Page 6

CADRE GÉNÉRAL DU PROJET

1.3.1 Problématique

La surveillance et la gestion du diabète représentent des défis majeurs pour les patients
et les professionnels de la santé. Ce projet vise à réinventer ces processus pour offrir une
expérience améliorée aux patients diabétiques tout en réduisant les inconvénients des méthodes
traditionnelles de surveillance. Comment pouvons-nous repenser ces processus pour optimiser
la qualité de vie des patients diabétiques et simplifier leur suivi glycémique ?

1.3.2 Objectifs

Finaliser la conception du microchip AlphaGly : Compléter la conception du microchip

sous-cutané en tenant compte des exigences de surveillance en temps réel des niveaux de
glucose dans le sang.

Progresser dans l’intégration avec la carte ESP32 : Avancer dans le développement de

l’interface entre le microchip AlphaGly et la carte ESP32, préparant la fondation pour l’intégration
ultérieure du modèle IA.

Développer une maquette de l’application mobile : Créer une maquette de l’application

mobile prévue, en mettant l’accent sur l’interface utilisateur et les fonctionnalités attendues.

Élaborer le modèle IA pour le futur : Travailler sur la conception du modèle d’intelligence

artificielle (IA) qui sera intégré dans la carte ESP32 pour la surveillance glycémique.

Planifier des tests de faisabilité : Concevoir un plan de tests de faisabilité pour le microchip
AlphaGly et l’interface mobile, même s’ils ne sont pas encore prêts pour les tests complets.

Évaluer la viabilité technique : Examiner la viabilité technique de la conception actuelle du

microchip et de l’interface ESP32 par le biais d’une évaluation préliminaire.

Explorer les considérations réglementaires : Se pencher sur les exigences potentielles en

matière de réglementation médicale et les étapes futures nécessaires pour obtenir les approbations
nécessaires.

ENET’COM SFAX Page 7

CADRE GÉNÉRAL DU PROJET

Planifier les prochaines étapes : Établir un plan détaillé pour les prochaines étapes du projet,
y compris la finalisation de la conception du microchip et son intégration avec le modèle IA.

1.3.3 Solutions existantes

Il existe plusieurs solutions existantes pour la surveillance et la gestion du diabète. Voici

quelques-unes des solutions couramment utilisées :

1. Auto-Monitoring de la Glycémie (AMG) : Les patients diabétiques utilisent des glucomètres

portables pour mesurer leur taux de glucose dans le sang à domicile. Ces appareils nécessitent
une piqûre du doigt pour obtenir une goutte de sang.
2. Systèmes de Surveillance en Continu de la Glycémie (CGM) : Ces dispositifs sont
implantés sous la peau ou portés à la surface de la peau pour surveiller en continu les
taux de glucose dans le sang. Ils envoient des données à un dispositif de lecture ou à une
application mobile.
3. Pompes à Insuline Intelligentes : Ces dispositifs délivrent de l’insuline en fonction
des données de glucose en temps réel, ce qui aide à maintenir un meilleur contrôle
glycémique.
4. Applications Mobiles de Gestion du Diabète : Il existe de nombreuses applications
mobiles conçues pour aider les patients à surveiller leur alimentation, leur activité physique
et leur glycémie. Certaines offrent également des fonctionnalités de suivi et d’analyse des
données.

Cependant, ces solutions existantes ont souvent des limitations, notamment le besoin
de piqûres de sang fréquentes, des interruptions dans la surveillance et des problèmes
de convivialité. Le projet AlphaGly vise à surmonter ces limitations en proposant un
microchip implantable offrant une surveillance continue, précise et non invasive des niveaux
de glucose dans le sang, ainsi que des alertes en temps réel pour les patients diabétiques.

ENET’COM SFAX Page 8

CADRE GÉNÉRAL DU PROJET

1.3.4 Solution proposée

La solution proposée pour le projet AlphaGly est un microchip implantable qui surveille
en temps réel les niveaux de glucose dans le sang des patients diabétiques. Ces données
sont accessibles via une application mobile conviviale, avec des alertes en cas de variations
critiques. Un bracelet intelligent ajoute une couche de sécurité. L’ensemble vise à améliorer
la gestion du diabète, réduire les complications et améliorer la qualité de vie des patients.

1.4 Démarche et méthodologie adoptées

Dans cette partie, nous allons définir et détailler la méthodologie et la démarche que
nous estimons convenables à ce genre d’application. Afin de garder une cohérence de
communication entre les différents membres de l’équipe, nous avons choisi d’adopter la
méthodologie SCRUM[6] pour gérer notre processus de travail. C’est une méthodologie
agile basée sur des itérations appelées Sprints.

1.4.1 Les rôles dans SCRUM

Il y a principalement trois rôles dans SCRUM :

.Product Owner Propriétaire du produit et responsable qui valide ou refuse le produit

livré. Une de ses tâches principales est de définir les besoins à développer et de rédiger
les spécifications. [7]

.SCRUM Master Responsable qui s’assure que la méthode Scrum est correctement mise
en œuvre et appliquée. Assure également la bonne progression et la productivité de l’équipe
en éliminant les obstacles que l’équipe peut rencontrer.[8]

.Team Développeurs, architectes ou testeurs responsables du développement et de la

réalisation d’un produit fiable et utilisable.

ENET’COM SFAX Page 9

CADRE GÉNÉRAL DU PROJET

F IGURE 1.4 – Les rôles dans SCRUM

1.4.2 Artefacts de SCRUM

Dans la liste ci-dessous, nous identifions les artefacts de Scrum que nous devons connaître
pour comprendre le produit :

Product backlog Un outil pour collecter les fonctionnalités attendues ou requises par le
client (User Story). Il évolue avec chaque Sprint [9].

Sprint backlog Contient la liste des tâches à réaliser pour mettre en œuvre les fonctionnalités
prévues pour un Sprint particulier. Chaque tâche est relativement courte et exécutée par
un membre de l’équipe plutôt que par une personne désignée.[10]

Release backlog Il s’agit de la livraison des sous-ensembles de backlog de produit [11].

F IGURE 1.5 – Artéfacts de SCRUM

1.5 Les événements SCRUM

1.5.1 Daily Scrum

Un événement de 15 minutes au cours duquel l’équipe de développement synchronise ses

activités et crée un plan pour les prochaines 24 heures. Le processus est simple, l’équipe
inspecte le travail qui a déjà été fait depuis le dernier Daily Scrum et examine le travail
potentiel [12].

ENET’COM SFAX Page 10

CADRE GÉNÉRAL DU PROJET

1.5.2 Sprint Planning

Une réunion avec le "Product Owner" au cours de laquelle l’équipe de développement

sélectionne les éléments prioritaires du "Product Backlog" qui peuvent être atteints au
cours du sprint [13].

1.5.3 Sprint Review

Organisé à la fin de chaque cycle de développement. C’est une présentation des différentes
fonctionnalités développées au cours du cycle. Le propriétaire du produit aura la possibilité
d’évaluer et de vérifier le produit avec la spécification placée pendant la session de planification
d’itération. La fin de la révision génère un nouveau cycle d’itération qui commence
de la planification, du développement à la révision. Il s’agit d’un point de surveillance
quotidien pour l’ensemble de l’équipe, limité à 15 minutes, où ils alignent et synchronisent
leur travail afin d’optimiser la planification pour les prochaines 24 heures.[14]

1.5.4 Rétrospective Sprint

Se produit après la révision du sprint et avant la planification du sprint suivante. C’est une
réunion de trois heures pour un mois de Sprints. Pour les Sprints plus courts, l’événement
est généralement plus court. [15]

F IGURE 1.6 – Les évènements SCRUM

ENET’COM SFAX Page 11

CADRE GÉNÉRAL DU PROJET

1.6 CONCLUSION

Ce chapitre introductif nous a permis de présenter l’entreprise d’accueil et de mettre le

projet dans son cadre général. En partant d’une étude préalable sur le projet. Après avoir
fixé les objectifs, le chapitre suivant s’intéresse à la partie spécification des besoins et la
conception pour avoir une vision plus claire du projet.

ENET’COM SFAX Page 12

 Chapitre

2
Étude conceptuelle et théorique

Sommaire
2.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Analyse et spécifications des besoins . . . . . . . . . . . . 14
2.2.1 Les Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . 14
2.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . 15
2.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . 16
2.3.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . 17
2.3.3 Diagrammes de séquences . . . . . . . . . . . . . . . . . . 20
2.4 CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . 21

ENET’COM SFAX Page 13

ÉTUDE CONCEPTUELLE ET THÉORIQUE

2.1 INTRODUCTION

Ce chapitre se plonge dans l’univers conceptuel et théorique qui sous-tend notre projet. Il
vise à établir une base solide de compréhension pour les aspects clés du domaine. Nous
explorerons les concepts fondamentaux, les modèles théoriques, les avancées technologiques
pertinentes et les principes qui guideront la conception et le développement de notre
solution.

2.2 Analyse et spécifications des besoins

La phase de spécifications des besoins tente d’abord de comprendre et d’expliquer précisément

les exigences de l’utilisateur de la plateforme.

2.2.1 Les Besoins Fonctionnels

Les besoins fonctionnels décrivent les principales fonctionnalités que l’application doit
fournir pour répondre aux besoins des utilisateurs. Ces besoins sont essentiels pour assurer
le bon fonctionnement de l’application.

(a) Inscription des Utilisateurs : Les utilisateurs doivent pouvoir créer un compte en
fournissant leurs informations personnelles, telles que leur nom, prénom, adresse
e-mail et mot de passe.
(b) Authentification : Les utilisateurs enregistrés doivent pouvoir se connecter à leur
compte en saisissant leurs identifiants (nom d’utilisateur ou adresse e-mail) et leur
mot de passe.
(c) Gestion du Profil Utilisateur : Chaque utilisateur doit avoir un profil où il peut
ajouter, modifier ou supprimer des informations personnelles telles que son âge, son
poids, sa taille, ses antécédents médicaux, etc.

ENET’COM SFAX Page 14

ÉTUDE CONCEPTUELLE ET THÉORIQUE

(d) Consultation des Données de Glucose : Les utilisateurs doivent pouvoir consulter
leurs données de glucose stockées dans l’application. Cela inclut l’affichage des
mesures passées sous forme de graphiques ou de tableaux.
(e) Recevoir des Alertes : L’application doit être capable de notifier les utilisateurs
en cas de variations critiques de leurs niveaux de glucose. Les alertes peuvent être
envoyées via des notifications push.
(f) Communication avec le Chatbot : Les utilisateurs doivent avoir la possibilité de
communiquer avec un chatbot intégré pour poser des questions sur leur diabète,
recevoir des conseils et des informations.
(g) Sécurité et Confidentialité : Les données des utilisateurs, en particulier les informations
médicales sensibles, doivent être sécurisées et protégées conformément aux réglementations
sur la confidentialité des données.

2.2.2 Besoins non fonctionnels

Les besoins non fonctionnels définissent les caractéristiques et les contraintes du système
qui ne sont pas directement liées aux fonctionnalités, mais qui sont essentielles pour
garantir la qualité, la performance et la sécurité de l’application.

— Extensibilité : L’application doit être conçue de manière à être extensible, ce qui

signifie qu’il doit être possible d’ajouter de nouvelles fonctionnalités facilement à
l’avenir sans perturber le fonctionnement existant.

— Sécurité : Étant donné la sensibilité des données traitées, la sécurité doit être une
priorité. L’accès à l’application doit être strictement contrôlé et se faire par authentification
des utilisateurs. Les données doivent être protégées contre les accès non autorisés.

— Performance : En raison du contrôle en temps réel du système, la performance est

cruciale. Tout retard causé par le fonctionnement du système doit être minimal, voire
nul, pour garantir une expérience utilisateur fluide.

— Disponibilité : L’application doit être disponible en permanence, ou avec un temps

d’indisponibilité minimal planifié pour la maintenance. Les utilisateurs doivent pouvoir
y accéder à tout moment.

ENET’COM SFAX Page 15

ÉTUDE CONCEPTUELLE ET THÉORIQUE

2.3 Conception

Pour modéliser l’application à développer, nous avons utilisé le langage de modélisation

UML (Unified Modeling Language)[16], qui représente un langage de modélisation orientée
objet et qui se compose d’une série de schémas appelés diagrammes offrants chacune une
vision différente du fonctionnement du logiciel considéré. En ce qui nous concerne, nous
allons modéliser certains diagrammes primordiaux pour la réalisation de notre application
tels que diagramme de classe, de cas d’utilisation, de séquence et d’activité.

2.3.1 Diagramme de cas d’utilisation

Le diagramme des cas d’utilisation est utilisé pour décrire les besoins de l’utilisateur de
l’application. Le diagramme de cas d’utilisation est utilisé pour rassembler les exigences
d’un système, y compris les influences internes et externes. Ces exigences sont principalement
des exigences de conception.

2.3.1.1 Diagramme de cas d’utilisation global

Ce diagramme de cas d’utilisation résume les détails des acteurs du système et leurs
interactions avec le système.

ENET’COM SFAX Page 16

ÉTUDE CONCEPTUELLE ET THÉORIQUE

F IGURE 2.1 – Diagramme de cas d’utilisation global

2.3.2 Diagramme de classe

2.3.2.1 Diagramme de classe global

Dans ce diagramme de classes UML, nous avons représenté la structure et les relations
entre les principales classes de notre application. L’application est conçue pour gérer des
utilisateurs, des messages, des dispositifs de kit, des notifications, des salles de discussion
(chatrooms) et des mesures. Voici une description détaillée des principales classes et de
leurs attributs et méthodes associés :

— Classe User :

— Attributs : id, FirstName, LastName, PhoneNumber, PhoneNumber2, EmailAddress,

Password, Token, Gender, UseType, Weight, Height, BirthDate, BloodType, Status,
joined, enabled, pictureu rl.M thodes : Authenticate(), U pdatei nf o(), F orgotP assword(), Signu

— Classe Message :

— Attributs : id, Text, CreationDate, WasRead.

— Méthode : SendText().

ENET’COM SFAX Page 17

ÉTUDE CONCEPTUELLE ET THÉORIQUE

— Classe KitDevices :

— Attributs : Name, Model, Version, S/N, Sold, Country.

— Méthodes : Validate(), OutputAsLabel().

— Classe Notification :

— Attributs : id, From, To, TypeNotif, Title, Content, Sent.

— Méthode : SendNotif().

— Classe ChatRoom :

— Attributs : id, isActive, name.

— Classe Mesures :

— Attributs : id, Captured, State, GlucoseLevel.

— Méthodes : Calculate(), Predict(), Monitoring().

Nous utilisons également des énumérations pour certains attributs, notamment ‘SexeEnum‘,
‘UserType‘, ‘BloodType‘, ‘UserStatus‘, ‘StateEnum‘ et ‘NotifEnum‘, pour définir des
valeurs possibles.

ENET’COM SFAX Page 18

ÉTUDE CONCEPTUELLE ET THÉORIQUE

F IGURE 2.2 – diagramme de classe global

ENET’COM SFAX Page 19

ÉTUDE CONCEPTUELLE ET THÉORIQUE

2.3.2.2 Diagramme de classe de mesure

F IGURE 2.3 – Diagramme de classe de mesure

2.3.3 Diagrammes de séquences

2.3.3.1 Diagramme d’authentification

ENET’COM SFAX Page 20

ÉTUDE CONCEPTUELLE ET THÉORIQUE

F IGURE 2.4 – Diagramme de séquence «s’authentifier».

2.4 CONCLUSION

Ce chapitre a jeté les bases conceptuelles de notre projet AlphaGly. Nous avons identifié
les besoins fonctionnels et non fonctionnels, défini les entités clés, et exploré les concepts
théoriques pertinents. Cette étape essentielle nous prépare à passer à la phase de conception
et de développement de notre solution de surveillance du diabète.

ENET’COM SFAX Page 21

 Chapitre

3
Réalisation

Sommaire
3.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Environnement du travail . . . . . . . . . . . . . . . . . . . 23
3.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . 23
3.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . 23
3.3 Architecture et interface de l’application . . . . . . . . . 25
3.3.1 Architecture de l’application . . . . . . . . . . . . . . . . . 25
3.4 Les sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.1 Sprint 0 : Analyse du Cahier des Charges et Exploration
du Code : Comprendre les Besoins et les Bases du Projet
AlphaGly . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.2 Sprint 1 : Mise en place de l’Authentification de Base . . . 29
3.4.3 Sprint 2 : Gestion des Appareils de Mesure . . . . . . . . 32
3.4.4 Sprint 3 : Gestion et Envoi de Notifications . . . . . . . . 34
3.4.5 Sprint 4 : Implémentation du Chatbot pour l’Assistance
Utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

ENET’COM SFAX Page 22

RÉALISATION

3.1 INTRODUCTION

Cette partie constitue le dernier volet de ce rapport. Nous allons présenter chaque sprint
et les tâches qui y sont effectuées seront détaillées. Ensuite, nous allons illustrer notre
travail par des captures d’écran.

3.2 Environnement du travail

3.2.1 Environnement matériel

Concernant la partie matérielle, il convient d’utiliser des périphériques performants au

niveau du processeur et de la mémoire pour économiser le temps de réponse et d’exécution
de l’application. Par conséquent, j’ai utilisé un PC portable comme environnement matériel
pour développer l’application. La configuration est comme suit :

— Marque : Hp Victus

— Processeur : Intel Core i5-12500H

— RAM : 16GB

— Disque dur : 500 Go

— Système d’exploitation : Windows 11

3.2.2 Environnement logiciel

Cette partie représente l’environnement de développement et les outils logiciels utilisés

durant l’élaboration du projet.

IntelliJ IDEA est un IDE[17] de pointe pour le développement Java et d’autres langages,
créé par JetBrains. Il se distingue par son efficacité, son analyse statique et son intégration
avec les outils de construction. Disponible en versions Community (gratuite) et Ultimate
(payante), il est apprécié pour sa productivité et sa personnalisation.

ENET’COM SFAX Page 23

RÉALISATION

Flutter est un framework de développement d’applications multiplateformes open-source

créé par Google, utilisant le langage Dart, offrant des performances élevées et une grande
personnalisation des interfaces utilisateur.

F IGURE 3.1 – Flutter Logo

Spring Boot est un framework[18] Java simplifiant le développement d’applications robustes

et prêtes pour la production, grâce à une configuration minimale et des fonctionnalités
intégrées.

F IGURE 3.2 – Spring Boot Logo

Python est un langage de programmation polyvalent, simple à apprendre et largement

utilisé pour diverses applications, de l’automatisation aux projets de développement complexes.

F IGURE 3.3 – Python Logo

Arduino est une plateforme open-source de développement matériel et logiciel conçue

pour simplifier la création de projets électroniques interactifs.

Blender est un logiciel open-source de modélisation, d’animation et de rendu 3D. Il est

utilisé pour créer des graphiques, des animations, des jeux, des effets spéciaux et bien
plus encore.

ENET’COM SFAX Page 24

RÉALISATION

F IGURE 3.4 – Arduino Logo

F IGURE 3.5 – Blender Logo

3.3 Architecture et interface de l’application

3.3.1 Architecture de l’application

Après avoir choisi la méthode de développement XP, l’approche de conception adoptée

est cohérente avec l’architecture du projet. Cette partie présente l’architecture MVC sur
laquelle l’application est basée.

L’architecture MVC (Model-View-Controller) [10] est l’une des architectures logicielles

les plus utilisées pour les applications Web. Elle permet de bien structurer un projet en
trois parties distinctes. Elle se compose de trois modules :

— Modèle : il s’agit du noyau de l’application qui gère les données. Il permet de

récupérer les informations dans la base de données et de les organiser pour qu’elles
puissent ensuite être traitées par le contrôleur.

— Vue : c’est le composant graphique de l’interface qui présente les données du modèle
à l’utilisateur.

— Contrôleur : il est responsable des prises de décision et gère la logique du code qui
prend des décisions. Il agit comme un intermédiaire entre le modèle et la vue. [19]

ENET’COM SFAX Page 25

RÉALISATION

F IGURE 3.6 – Architecture MVC

Parmi les points forts de l’architecture MVC, elle permet de rendre la conception graphique
de l’application plus claire et efficace. Ce qui rend cette architecture meilleure dans la
réalisation de notre projet.

3.4 Les sprints

3.4.1 Sprint 0 : Analyse du Cahier des Charges et Exploration du

Code : Comprendre les Besoins et les Bases du Projet AlphaGly

3.4.1.1 Objectifs

Les objectifs de ce projet sont les suivants :

(a) Développer un microchip AlphaGly : Concevoir et créer un microchip minuscule

capable de surveiller en temps réel les taux de glucose dans le sang des patients
diabétiques.

ENET’COM SFAX Page 26

RÉALISATION

(b) Créer une application mobile : Développer une application mobile conviviale
qui permet aux patients diabétiques de suivre leurs taux de glucose en temps réel,
d’afficher des courbes et de recevoir des alertes en cas de variations critiques.
(c) Assurer la sécurité des données : Mettre en place des mesures de sécurité robustes
pour garantir que les données des patients sont protégées et confidentielles.
(d) Intégrer une intelligence artificielle : Développer un modèle d’intelligence artificielle
capable d’analyser les données de glucose collectées par le microchip pour détecter
les tendances et prévenir les complications.
(e) Connecter le microchip à un bracelet intelligent : Créer une connectivité entre
le microchip AlphaGly et un bracelet intelligent pour permettre aux patients de
recevoir des alertes et de suivre leur santé en temps réel.
(f) Réduire les complications du diabète : L’objectif ultime est de contribuer à la
réduction des complications graves liées au diabète en offrant une surveillance continue
et en permettant aux patients de prendre des mesures proactives.
(g) Améliorer la qualité de vie des patients : En offrant une surveillance continue et
des alertes en temps réel, le projet AlphaGly vise à améliorer la qualité de vie des
patients diabétiques.
(h) Alléger la charge des systèmes de santé : En aidant les patients à mieux gérer leur
diabète, le projet peut contribuer à réduire la pression sur les systèmes de santé en
évitant les hospitalisations et les complications coûteuses.
(i) Effectuer des recherches approfondies : Le projet nécessite des recherches avancées
pour développer un microchip et un modèle d’intelligence artificielle efficaces.
(j) Implanter le programme dans la carte ESP32 : Une fois la solution développée,
l’objectif final est d’implanter le programme dans la carte ESP32 pour une utilisation
pratique.

3.4.1.2 Analyse

(a) Étude de Faisabilité : Pendant le Sprint 0, il est essentiel de réaliser une étude de
faisabilité approfondie. Cela implique d’évaluer la viabilité technique, économique
et opérationnelle du projet. Vous devez examiner si la technologie nécessaire est

ENET’COM SFAX Page 27

RÉALISATION

disponible, si le projet est financièrement réalisable et si les ressources humaines et

matérielles sont disponibles.
(b) Définition des Besoins : Une partie cruciale du Sprint 0 est la définition claire
des besoins du projet AlphaGly. Cela comprend l’identification des besoins des
utilisateurs finaux, des exigences fonctionnelles et non fonctionnelles, et des cas
d’utilisation. Il est essentiel de comprendre les attentes des patients diabétiques et
des professionnels de la santé pour concevoir une solution pertinente.
(c) Planification : Au cours du Sprint 0, l’équipe doit élaborer un plan de projet détaillé.
Cela inclut la planification des ressources, l’attribution des rôles et des responsabilités,
l’établissement d’un calendrier de développement, et l’estimation des coûts. Une
planification solide garantit que le projet reste sur la bonne voie tout au long de son
développement.
(d) Risques et Contraintes : L’identification des risques potentiels est une étape importante
du Sprint 0. Cela permet à l’équipe de prendre des mesures préventives pour minimiser
les obstacles futurs. Les contraintes telles que les délais, le budget et les ressources
doivent également être clairement définies.
(e) Méthodologie de Développement : Le Sprint 0 est l’occasion de choisir la méthodologie
de développement la plus adaptée pour le projet AlphaGly. Vous avez mentionné
avoir choisi la méthode de développement XP (Extreme Programming), ce qui signifie
que vous devrez définir les pratiques et les valeurs spécifiques de cette méthodologie
que vous allez appliquer.
(f) Documentation : Tout au long du Sprint 0, l’équipe doit commencer à documenter
le projet. Cela comprend la création de documents tels que le cahier des charges, le
plan de projet, les spécifications techniques, et d’autres documents pertinents.
(g) Équipe : L’équipe doit être formée et prête à commencer le développement au terme
du Sprint 0. Cela inclut l’identification des compétences nécessaires, le recrutement
si nécessaire, et la formation sur les outils et technologies à utiliser.

ENET’COM SFAX Page 28

RÉALISATION

3.4.2 Sprint 1 : Mise en place de l’Authentification de Base

3.4.2.1 Objectifs

(a) Concevoir et mettre en œuvre un système d’inscription permettant aux utilisateurs

de créer un compte.
(b) Implémenter un mécanisme de connexion permettant aux utilisateurs de s’authentifier
avec leurs identifiants.
(c) Mettre en place un processus de réinitialisation de mot de passe pour les utilisateurs
qui l’oublient.
(d) Stocker en toute sécurité les informations d’authentification des utilisateurs
dans une base de données.

3.4.2.2 Sprint 1 Backlog

Lors de la réunion de planification du Sprint 1, les user stories suivantes ont été définies :

ID User Story Priorité

1 Créer l’interface utilisateur de la page d’inscription Haute

2 Mettre en place la logique de traitement de l’inscription Haute

3 Implémenter la fonction de validation des champs d’inscription Moyenne

4 Concevoir la page de connexion de l’application Haute

5 Créer la fonctionnalité de connexion en utilisant Spring Boot Haute

6 Ajouter la possibilité de réinitialiser le mot de passe oublié Moyenne

7 Assurer la sécurité des données utilisateur pendant l’authentification Haute

8 Mettre en place des journaux de sécurité pour suivre les activités de connexion Basse

TABLE 3.1 – User Stories pour le Sprint 1

ENET’COM SFAX Page 29

RÉALISATION

3.4.2.3 Architecture de l’application

L’architecture de l’application est basée sur le modèle MVC (Model-View-Controller),

qui permet de séparer la logique métier, la présentation et le contrôleur. Cette approche
garantit la modularité et la maintenabilité du code.

3.4.2.4 Base de données

Pour stocker les données utilisateur, nous utilisons une base de données relationnelle. La
conception de la base de données comprend les tables suivantes :

— Table "Utilisateurs" : Stocke les informations des utilisateurs, telles que leur nom,
prénom, adresse e-mail, etc.

— Table "Authentification" : Contient les informations d’authentification, y compris

les mots de passe hachés et les jetons d’authentification.

— Table "Historique de connexion" : Journaux d’activités de connexion, ID de l’utilisateur,

Date, Adresse IP, etc.

Table Description Colonnes

Utilisateurs Stockage des informations utilisateur ID, Nom, Prénom, E-mail

Authentification Informations d’authentification ID, ID de l’utilisateur, Mot de passe

TABLE 3.2 – Conception de la base de données

3.4.2.5 Interfaces utilisateur

Les interfaces utilisateur sont conçues de manière conviviale pour offrir une expérience
utilisateur optimale. Nous utilisons Flutter pour créer des interfaces réactives et esthétiques.

ENET’COM SFAX Page 30

RÉALISATION

(a) Interface d’inscription (b) Interface de connexion

F IGURE 3.7 – Authentification

F IGURE 3.8 – Mot de passe oublié

ENET’COM SFAX Page 31

RÉALISATION

3.4.3 Sprint 2 : Gestion des Appareils de Mesure

3.4.3.1 Objectifs

Les objectifs du Sprint 2 pour la gestion des appareils de mesure sont les suivants :

(a) Développer la fonction de gestion des appareils de mesure : Concevoir et implémenter

une fonctionnalité permettant aux utilisateurs de gérer les appareils de mesure associés
à leur compte. Cela inclut l’ajout, la modification et la suppression d’appareils.
(b) Créer la fonction de connexion des Kits de Mesure : Mettre en place un mécanisme
permettant aux utilisateurs de connecter leurs kits de mesure (par exemple, un glucomètre
ou un moniteur de pression artérielle) à l’application mobile.
(c) Valider les Appareils de Mesure : Développer un processus de validation des
appareils de mesure pour s’assurer de leur fonctionnement correct et de leur précision.
Cela pourrait impliquer des étalonnages ou des vérifications régulières.
(d) Sécuriser les Données : Garantir que les données provenant des appareils de mesure
sont sécurisées et ne peuvent pas être altérées ou interceptées par des tiers non
autorisés.
(e) Intégration avec l’Application Mobile : Assurer que ces fonctionnalités sont intégrées
de manière transparente dans l’application mobile, offrant une expérience utilisateur
fluide.
(f) Documentation et Tests : Documenter soigneusement ces fonctionnalités pour faciliter
la maintenance future et effectuer des tests rigoureux pour garantir leur bon fonctionnement.

Ces objectifs aideront à développer une gestion complète et sécurisée des appareils de
mesure au sein de l’application AlphaGly.

3.4.3.2 Sprint 2 Backlog

Lors de la réunion de planification du Sprint 2, les user stories suivantes ont été définies :

ENET’COM SFAX Page 32

RÉALISATION

ID User Story Priorité

1 Gérer les appareils de mesure Haute

2 Connecter le Kit de Mesure Haute

3 Valider les appareils de mesure Moyenne

4 Ajouter la fonction de mesure automatique Moyenne

5 Intégrer l’intelligence artificielle pour l’analyse des mesures Haute

6 Créer une interface utilisateur pour la gestion des mesures Haute

TABLE 3.3 – User S tories pour le Sprint 2

3.4.3.3 Interfaces utilisateur

Les interfaces utilisateur sont conçues de manière conviviale pour offrir une expérience
utilisateur optimale. Nous utilisons Flutter pour créer des interfaces réactives et esthétiques.

(a) Interface D’acceuil (b) Journal de mesure

F IGURE 3.9 – Interface de mesure

ENET’COM SFAX Page 33

RÉALISATION

F IGURE 3.10 – Analyse du glucose

3.4.4 Sprint 3 : Gestion et Envoi de Notifications

3.4.4.1 Objectifs

Les objectifs de ce sprint sont les suivants :

(a) Implémenter la fonction de gestion des notifications : Concevoir et mettre en

œuvre un système de gestion des notifications qui permettra aux utilisateurs de
recevoir des alertes et des informations importantes.
(b) Développer la fonction d’envoi de notifications : Mettre en place un mécanisme
d’envoi de notifications aux utilisateurs, en prenant en compte leurs préférences et
leurs paramètres.
(c) Créer une interface utilisateur pour la gestion des notifications : Concevoir
une interface conviviale qui permettra aux utilisateurs de gérer leurs notifications,
y compris la possibilité de les activer/désactiver, de définir des préférences, et de
consulter l’historique des notifications reçues.

ENET’COM SFAX Page 34

RÉALISATION

(d) Intégrer la gestion des notifications avec le modèle IA : Assurer l’intégration entre
la gestion des notifications et le modèle d’intelligence artificielle pour permettre des
notifications intelligentes basées sur les données de glucose.
(e) Garantir la sécurité des notifications : Mettre en place des mesures de sécurité
pour protéger la confidentialité des notifications des utilisateurs.
(f) Tester et déboguer les fonctionnalités de notification : Effectuer des tests approfondis
pour garantir que les notifications fonctionnent correctement et résoudre tout problème
de performance ou de fiabilité.
(g) Documentation : Mettre à jour la documentation du projet pour inclure les nouvelles
fonctionnalités de gestion et d’envoi de notifications.

3.4.4.2 Sprint 3 Backlog

Lors de la réunion de planification du Sprint 3, les user stories suivantes ont été définies :

ID User Story Priorité

1 Concevoir et implémenter la fonction de gestion des notifications Haute

2 Développer la fonction d’envoi de notifications aux utilisateurs Haute

3 Créer une interface utilisateur pour la gestion des notifications Moyenne

4 Intégrer la gestion des notifications avec le modèle IA Haute

5 Mettre en place des mesures de sécurité pour les notifications Haute

6 Tester et déboguer les fonctionnalités de notification Moyenne

7 Mettre à jour la documentation du projet Basse

TABLE 3.4 – User Stories pour le Sprint 3

3.4.4.3 Interfaces utilisateur

Les interfaces utilisateur sont conçues de manière conviviale pour offrir une expérience
utilisateur optimale. Nous utilisons Flutter pour créer des interfaces réactives et esthétiques.

ENET’COM SFAX Page 35

RÉALISATION

(a) Interface d’acceuil (b) Interface de notifications

F IGURE 3.11 – Notifications

3.4.5 Sprint 4 : Implémentation du Chatbot pour l’Assistance Utilisateur

3.4.5.1 Objectifs du Sprint 4

(a) Implémentation de l’Envoi de Messages Directs : Mettre en place la fonctionnalité

permettant aux utilisateurs de l’application de s’envoyer des messages directs.
(b) Interface Utilisateur pour les Messages Directs : Créer une interface utilisateur
conviviale pour la composition et l’envoi de messages directs.
(c) Gestion des Conversations : Assurer la gestion des conversations entre les utilisateurs,
y compris la création de nouvelles conversations et la gestion de l’historique des
messages.
(d) Notifications pour les Messages Directs : Mettre en place un système de notifications
pour informer les utilisateurs des nouveaux messages directs reçus.
(e) Sécurité et Confidentialité : Garantir que les messages directs sont sécurisés et que
la confidentialité des utilisateurs est respectée.

ENET’COM SFAX Page 36

RÉALISATION

(f) Tests et Débogage : Effectuer des tests approfondis pour s’assurer que la fonction
d’envoi de messages directs fonctionne correctement et corriger tout bogue identifié.
(g) Documentation : Documenter la nouvelle fonctionnalité et mettre à jour la documentation
de l’application.

3.4.5.2 Sprint 4 Backlog

ID User Story Priorité

1 En tant qu’utilisateur, je veux pouvoir ouvrir une fenêtre de Haute

chat avec le chatbot depuis l’application mobile.

2 En tant qu’utilisateur, je veux pouvoir poser des questions Haute

au chatbot et recevoir des réponses en temps réel.

3 En tant qu’utilisateur, je veux pouvoir demander des Moyenne

informations sur mes données de glucose stockées dans
l’application.

4 En tant qu’utilisateur, je veux pouvoir demander des Moyenne

conseils sur la gestion de mon diabète à travers le chatbot.

5 En tant qu’utilisateur, je veux que le chatbot respecte ma Haute

confidentialité et sécurise mes données.

6 En tant qu’utilisateur, je souhaite avoir la possibilité de Moyenne

fermer la fenêtre de chat avec le chatbot à tout moment.

TABLE 3.5 – User Stories pour le Sprint 4

ENET’COM SFAX Page 37

RÉALISATION

Tâches Techniques

1 Intégrer un framework de chatbot compatible avec

l’application.

2 Développer la logique de compréhension des questions

posées par l’utilisateur.

3 Implémenter un moteur de réponse pour le chatbot.

4 Mettre en place des mesures de sécurité pour protéger les

données de conversation.

5 Tester la fonctionnalité du chatbot avec des scénarios de

test.

6 Documenter l’ajout du chatbot et son utilisation dans la

documentation de l’application.

TABLE 3.6 – Tâches Techniques pour le Sprint 4

3.4.5.3 Interfaces utilisateur

F IGURE 3.12 – Interface de chat

ENET’COM SFAX Page 38

 CONCLUSION GÉNÉRALE

En conclusion, ce rapport a exploré en profondeur le projet AlphaGly, une solution novatrice

destinée à révolutionner la gestion du diabète. Tout au long de ce rapport, nous avons mis
en lumière les défis posés par le diabète dans le monde, notamment l’impact sur des
millions de vies et les complications graves associées à une surveillance inadéquate.

Le projet AlphaGly se veut une réponse à ces défis, en proposant un microchip révolutionnaire
implanté sous la peau pour surveiller la glycémie en temps réel. Cette technologie, couplée
à une application mobile et à un bracelet intelligent, offre une surveillance continue et
précise tout en éliminant le besoin de piqûres douloureuses.

Nous avons également souligné l’importance de la recherche et du développement dans ce

projet, notamment la création d’un modèle d’intelligence artificielle et son implémentation
dans une carte ESP32, afin de garantir des résultats fiables et une sécurité renforcée.

Les objectifs du projet AlphaGly sont clairs : améliorer la qualité de vie des patients
diabétiques, prévenir les complications graves, faciliter le suivi personnel, réduire la
charge sur les systèmes de santé et intégrer des technologies de pointe.

En fin de compte, AlphaGly représente bien plus qu’une solution technologique. C’est
un espoir pour des millions de personnes touchées par le diabète, un pas vers une vie
meilleure et plus saine. Ce projet incarne l’innovation, la technologie et, surtout, la possibilité
de transformer la manière dont nous gérons le diabète dans le monde entier.

ENET’COM SFAX Page 39

 BIBLIOGRAPHIE

[1] Groupe de conseil en innovation et transformation .https ://talan.com/

[2] Département RD .https ://talan.com/.

[3] Blockchain.https ://www.blockchain.com/.

[4] IOT.https ://www.oracle.com/fr/internet-of-things/what-is-iot/

[5] IA.https ://openai.com/

[6] Scrum.https ://asana.com/fr/resources/what-is-scrum

[7] Product owner.https ://asana.com/fr/resources/what-is-scrum

[8] Scrum master.https ://asana.com/fr/resources/what-is-scrum

[9] Product backlog.https ://asana.com/fr/resources/what-is-scrum

[10] Sprint backlog.https ://asana.com/fr/resources/what-is-scrum

[11] Release backlog.https ://asana.com/fr/resources/what-is-scrum

[12] Daily scrum.https ://asana.com/fr/resources/what-is-scrum

[13] Sprint Planning.https ://asana.com/fr/resources/what-is-scrum

[14] Sprint review.https ://asana.com/fr/resources/what-is-scrum

[15] Retrospective sprint.https ://asana.com/fr/resources/what-is-scrum

[16] UML.hhttps ://www.lucidchart.com/pages/fr/langage-uml

[17] IDE.https ://www.redhat.com/en/topics/middleware/what-is-ide

[18] framework.https ://www.codecademy.com/resources/blog/what-is-a-framework/

[19] MVC.https ://talks.freelancerepublik.com/comprendre-utiliser-architecture-mvc/

ENET’COM SFAX Page 40