diff --git a/Documentation/Readme.md b/Documentation/Readme.md
new file mode 100644
index 0000000..754a31b
--- /dev/null
+++ b/Documentation/Readme.md
@@ -0,0 +1,20 @@
+# Rapport du Projet - Solution Complète
+
+Ce document centralisé constitue l'ensemble du rapport pour la solution complète du projet. Il est divisé en plusieurs
+sections pour détailler tous les aspects du projet, y compris le POC (Proof of Concept) mais également la solution
+globale qui en découle. Chaque section correspond à un domaine précis, avec des explications détaillées et des analyses
+concernant différents composants et aspects du système.
+
+Les sections du rapport sont les suivantes :
+- [Introduction](sous-section/intro.md)
+- [User stories](sous-section/usecases.md)
+- [Périmètre Du POC](sous-section/perimetre.md)
+- [Quickstart](sous-section/quickstart.md)
+- [Fonctionnement du Système](sous-section/fonctionnement.md)
+- [Les Services du Système](sous-section/services.md)
+- [Les choix technologiques](sous-section/techno.md)
+- [Architecture pour les Microservices](sous-section/architectureMS.md)
+- [Modèle de Données](sous-section/dataModel.md)
+- [Sécurité des données](sous-section/securite.md)
+- [Matrice de risque](sous-section/matriceRisque.md)
+- [Structure de code](sous-section/structureCode.md)
\ No newline at end of file
diff --git a/Documentation/diagrams/Archi_model_de_donnees.jpg b/Documentation/diagrams/Archi_model_de_donnees.jpg
new file mode 100644
index 0000000..b52ec7e
Binary files /dev/null and b/Documentation/diagrams/Archi_model_de_donnees.jpg differ
diff --git a/Documentation/diagrams/MS.png b/Documentation/diagrams/MS.png
new file mode 100644
index 0000000..62f1646
Binary files /dev/null and b/Documentation/diagrams/MS.png differ
diff --git a/Documentation/diagrams/archi.jpg b/Documentation/diagrams/archi.jpg
new file mode 100644
index 0000000..b8e764f
Binary files /dev/null and b/Documentation/diagrams/archi.jpg differ
diff --git a/Documentation/sous-section/architectureMS.md b/Documentation/sous-section/architectureMS.md
new file mode 100644
index 0000000..bfcdeca
--- /dev/null
+++ b/Documentation/sous-section/architectureMS.md
@@ -0,0 +1,28 @@
+# Architecture pour les Microservices
+
+Nous avons choisi une architecture orientée services (SOA) pour sa capacité à structurer notre système de manière
+modulaire et évolutive. En organisant nos composants en services indépendants, chacun dédié à une fonction métier
+spécifique, nous pouvons développer, déployer et maintenir chaque service de manière autonome. Cette approche facilite
+la réutilisabilité des services, améliore leur maintenabilité et permet une meilleure adaptabilité aux changements des
+besoins métier. Elle rend notre architecture flexible et résiliente face aux évolutions technologiques et fonctionnelles.
+
+## Structure des Services
+
+
+L'architecture est organisée en trois couches principales :
+
+### 1. **Couche Controller (API Layer)**
+- Cette couche représente le point d'entrée des services, où sont définis les endpoints d'API.
+- Elle sert d'interface de communication entre les services et les autres composants du système, assurant ainsi
+les échanges de données et les interactions externes.
+
+### 2. **Couche Service**
+- Cette couche est dédiée à la logique métier.
+- Elle contient les traitements et la logique applicative, prenant en charge les opérations nécessaires pour répondre
+aux demandes transmises par la couche Controller.
+- Elle centralise les règles métier et le flux logique des opérations.
+
+### 3. **Couche DAO (Data Access Object)**
+- Cette couche est responsable de l'accès aux données.
+- Elle gère les interactions avec la base de données ou les sources de données externes, assurant ainsi la persistance
+des données de manière sécurisée et structurée.
diff --git a/Documentation/sous-section/dataModel.md b/Documentation/sous-section/dataModel.md
new file mode 100644
index 0000000..a93f549
--- /dev/null
+++ b/Documentation/sous-section/dataModel.md
@@ -0,0 +1,52 @@
+# Modèles des Données
+
+Dans notre système, la structure des données repose sur deux bases de données principales, chacune jouant un rôle
+essentiel dans la gestion des informations critiques : l'une dédiée aux alertes et l'autre aux données des patients.
+
+## Base de données des alertes
+Cette base est destinée à stocker des informations détaillées pour chaque alerte émise par le système.
+Chaque enregistrement d'alerte contient les champs suivants :
+
+- **id** : Un identifiant unique, généré automatiquement pour chaque alerte.
+- **Date** : Enregistre la date et l’heure de la détection de l'alerte.
+- **Type** : Identifie le déclencheur de l'alerte (par exemple, température, accélération, rythme cardiaque, ou taux de glucose).
+- **Message** : Fournit une description de l'alerte.
+- **gatewayId** : Permet d’associer l’alerte à un utilisateur spécifique.
+- **Treated** : Indique si l’alerte a été traitée.
+- **Modified** : Enregistre si l’alerte a été modifiée après sa création.
+- **Value** : Indique la valeur qui a déclenché l'alerte.
+- **Severity** : Définit la gravité de l'alerte.
+
+## Base de données des patients
+Cette base contient plusieurs collections, chacune dédiée à un aspect des informations du patient.
+
+### Dossiers patients
+Chaque dossier regroupe les informations personnelles de chaque patient :
+
+- **id** : Un identifiant unique, généré automatiquement pour chaque patient.
+- **firstname** : Le prénom du patient.
+- **lastname** : Le nom de famille du patient.
+- **gender** : Le sexe du patient.
+- **emergencyContactPhoneNumber** : Le numéro de téléphone d'un contact d'urgence.
+- **gatewayId** : Identifiant qui lie les informations du patient aux alertes qui le concernent.
+
+### Consultations des patients
+Cette collection enregistre les informations relatives aux consultations médicales de chaque patient :
+
+- **id** : Un identifiant unique, généré automatiquement pour chaque consultation.
+- **Date** : La date de la consultation.
+- **Entries** : Liste d'entrées, où chaque entrée contient un nom, une valeur, et une remarque pour
+documenter les observations faites lors de la consultation.
+- **doctorId** : Identifiant du médecin ayant effectué la consultation.
+- **patientId** : Identifiant du patient concerné par la consultation.
+
+
+### Ressentis des patients
+Cette collection enregistre les ressentis des patients, ajoutés manuellement via l'interface frontend :
+
+- **id** : Un identifiant unique, généré automatiquement pour chaque ressenti.
+- **Date** : La date à laquelle le ressenti a été enregistré.
+- **Ressentis** : Description des symptômes ou sensations ressentis par le patient.
+- **patientId** : Identifiant du patient ayant enregistré le ressenti.
+
+
diff --git a/Documentation/sous-section/fonctionnement.md b/Documentation/sous-section/fonctionnement.md
new file mode 100644
index 0000000..6ec6aa3
--- /dev/null
+++ b/Documentation/sous-section/fonctionnement.md
@@ -0,0 +1,75 @@
+# Fonctionnement du Système
+
+
+
+Le système de surveillance des patients repose sur une architecture modulaire et dynamique, permettant de collecter,
+analyser et afficher des données critiques pour assurer un suivi médical efficace et en temps réel.
+Ce choix d’architecture modulaire favorise une séparation claire des fonctionnalités, facilitant ainsi la maintenance et
+l’évolution du système en répartissant les responsabilités par module. En outre, cette approche rend le système hautement scalable,
+permettant d’ajouter facilement de nouvelles fonctionnalités ou d’augmenter la capacité de traitement sans affecter les autres composants.
+
+## Phase 1 : Collecte des Données des Capteurs
+Le système commence par la collecte de données provenant de divers capteurs, tels que le cardiofréquencemètre,
+l'accéléromètre, le thermomètre et le glucomètre, qui mesurent les signes vitaux du patient à des fréquences variées.
+Ces capteurs transmettent leurs données via la technologie Zigbee à la gateway placé chez le client. Une fois les données arrivées
+dans la gateway, elles sont envoyées vers un broker (RabbitMQ), qui la sauvegarde des donnée dans la gateway en attendant la transmission au serveur, il garantit une transmission fiable des données.
+
+## Phase 2 : Système de Détection d'Alerte Urgente
+Le système de détection d'alerte, situé côté patient, surveille en temps réel les données provenant des files de chaque
+capteur via RabbitMQ. Ce système est conçu pour détecter toute situation d'urgence nécessitant une intervention rapide.
+Lorsqu'un état critique est identifié, un SMS est envoyé au proche.
+
+Pour s'assurer que le numéro de contact est valide, le système tente d'abord de récupérer le numéro de téléphone
+associé à l'ID de la gateway depuis le Dossier Patient via un appel au service de gestion du Dossier Patient.
+Si cette récupération échoue, un numéro localement enregistré est utilisé par défaut, garantissant ainsi qu'une alerte
+soit envoyée, même en cas d'indisponibilité temporaire du service de gestion des dossiers.
+
+Parallèlement, une alerte est automatiquement enregistrée dans la base de données AlerteDB via le service Gestion Alerte,
+ce qui permet de documenter et centraliser les événements critiques pour un suivi et une analyse ultérieurs.
+
+## Phase 3 : Downsampling et Communication avec le Cloud
+Après la détection des alertes critiques, les données passent à une phase de réduction. La fréquence d'échantillonage est réduite pour correspondre au besoin d'analyse côté serveur. Une fréquence élevée de mesures n'est pas nécessaire une fois la détection d'alertes critiques faite. Les données sont ensuite compactés en batch puis envoyées au serveur.
+
+## Phase 4 : Prometheus pour la Surveillance des Données
+Prometheus consomme les données pour les stocker en vue d'analyses ultérieures. Un service d'analyse de haut niveau
+extrait les données de Prometheus pour fournir aux utilisateurs
+des analyses plus détaillées en fonction de leur rôle. De plus, l'intégration
+d'Alert Manager dans ce processus permet d'identifier des anomalies sur des périodes prolongées en générant des alertes
+via le service de gestion des Alertes.
+
+## Phase 5 : Accès des Utilisateurs
+Les utilisateurs, qu'il s'agisse de proches, de médecins ou d'infirmières, accèdent à l'interface frontend via Traefik,
+qui sert de reverse proxy pour gérer le trafic et garantir la sécurité des connexions. L’authentification et
+l’autorisation des utilisateurs sont gérées par Keycloak, qui assure un contrôle précis des accès en fonction des rôles,
+permettant ainsi de limiter l'accès aux informations sensibles uniquement aux personnes autorisées.
+
+## Phase 6 : Affichage des Données et Alertes via le Frontend
+Le frontend affiche les états des patients à l'aide de graphiques générés par Grafana, qui récupère les données stockées
+dans Prometheus. Cette visualisation permet aux utilisateurs de suivre facilement l'évolution de la santé des patients
+en temps réel. Les analyses et les alertes provenant du Service d'Analyse de Haut Niveau et du Service Gestion Alerte
+sont accessibles aux utilisateurs autorisés, notamment aux médecins, aux infirmières et aux proches des patients.
+
+Grâce à ce frontend, les médecins peuvent créer des dossiers pour les patients et leur associer un identifiant de
+passerelle (gateway ID). De plus, les médecins et les infirmières ont la possibilité de rédiger des rapports médicaux,
+qui sont ensuite stockés dans la base de données patient. Cette intégration assure une dépendance forte entre les dossiers
+et les rapports médicaux, permettant une visualisation cohérente et un accès rapide à l’information cruciale sur la santé des patients.
+
+Le frontend permet également aux patients de participer activement au suivi de leur état de santé en ajoutant leurs
+ressentis directement depuis l'interface. Cette fonctionnalité est rendue possible grâce au microservice Patient, qui
+gère la soumission et le stockage de ces ressentis dans la base de données des patients. Ces ressentis sont accessibles
+aux médecins et aux infirmières dans les dossiers médicaux, contribuant à une prise en charge plus complète et personnalisée des soins.
+
+## Phase 7 : La Partie VPN
+Pour assurer la maintenance et la gestion des gateways installées chez les patients, nous utilisons Tailscale, un réseau overlay distribué peer-to-peer. Tailscale, basé sur le protocole WireGuard, permet d’établir une connexion sécurisée et simplifiée aux gateways sans nécessiter de configuration VPN complexe ou de redirection de ports, garantissant ainsi une communication sécurisée entre les appareils.
+
+Les mises à jour logicielles des gateways s’effectuent via un processus de polling utilisant Docker Compose. Chaque gateway est configurée pour interroger régulièrement une API de gestion dédiée, qui indique si des mises à jour de services conteneurisés sont disponibles. Cette API fournit les versions actualisées des fichiers Docker Compose, permettant ainsi de télécharger et de redéployer les services en fonction des nouvelles configurations.
+
+Cette méthode de mise à jour par polling offre plusieurs avantages :
+
+- Mises à jour automatisées : Les services conteneurisés sur les gateways peuvent être mis à jour sans intervention manuelle, garantissant la continuité des correctifs de sécurité et des nouvelles fonctionnalités.
+
+- Fiabilité accrue : En récupérant les nouvelles configurations depuis une API centrale, chaque gateway est assurée de rester synchronisée avec les mises à jour nécessaires.
+
+- Gestion centralisée : L’API de gestion fournit une visibilité globale sur l’état des versions et des configurations, facilitant le suivi et la maintenance de l’ensemble des gateways.
+
+En combinant Tailscale pour un accès direct et un système de mise à jour via Docker Compose et polling, cette architecture garantit un support continu et sécurisé pour la maintenance à distance des gateways, assurant ainsi la fiabilité et l’évolution du système en temps réel.
diff --git a/Documentation/sous-section/intro.md b/Documentation/sous-section/intro.md
new file mode 100644
index 0000000..2b8afb0
--- /dev/null
+++ b/Documentation/sous-section/intro.md
@@ -0,0 +1,19 @@
+# Introduction
+
+Dans un contexte de vieillissement de la population et de besoin croissant en services de santé, le suivi médical
+des personnes âgées devient un enjeu de société majeur. Nombreuses sont les familles et les professionnels de santé
+confrontés aux défis de la surveillance des paramètres vitaux des personnes âgées en temps réel, notamment pour prévenir
+les incidents tels que les chutes, les anomalies de fréquence cardiaque, ou les variations de température corporelle.
+Afin de répondre à cette problématique, ce projet propose de concevoir un système de suivi médical pour les personnes
+âgées, destiné à fournir une surveillance complète et continue, et à faciliter la coordination entre différents acteurs
+impliqués dans leur prise en charge.
+
+L’objectif principal de ce système est de centraliser et d’automatiser le suivi des paramètres vitaux d’une
+personne âgée en utilisant des capteurs pour mesurer la température corporelle, le rythme cardiaque et détecter
+d'éventuelles chutes. Le système intègre également un module permettant d’ajouter manuellement des données spécifiques,
+comme le taux de glucose sanguin, afin de couvrir un éventail plus large de besoins médicaux.
+Ces informations sont mises à la disposition des différents acteurs de l’entourage de la personne âgée,
+incluant les médecins, les infirmiers, et les proches, via une interface accessible sur authentification sécurisée.
+
+Dans cette étude, nous réaliserons une analyse des besoins fonctionnels et techniques, en identifiant les différentes
+fonctionnalités nécessaires pour répondre aux exigences des utilisateurs.
diff --git a/Documentation/sous-section/matriceRisque.md b/Documentation/sous-section/matriceRisque.md
new file mode 100644
index 0000000..82e12b0
--- /dev/null
+++ b/Documentation/sous-section/matriceRisque.md
@@ -0,0 +1,15 @@
+# Matrice des Risques
+
+Dans le cadre de notre projet, voici une analyse des risques potentiels. Cette matrice identifie les risques majeurs, leur probabilité et leur impact, ainsi que les mesures de mitigation envisagées pour réduire leur occurrence ou leurs effets.
+
+| **Risque** | **Description** | **Probabilité** | **Impact** | **Stratégie de Mitigation** |
+|------------|-----------------|-----------------|------------|-----------------------------|
+| Envoi de fausses alertes par SMS| L'algorithme de détection côté client peut déclencher des alertes en fonction de valeurs erronées, générant ainsi de fausses alertes. | Élevée| Moyen| Difficulté de contrôle côté client en raison de ressources limitées. Les utilisateurs peuvent vérifier manuellement l'alerte en appelant la personne âgée pour s'assurer de sa situation.|
+| Envoi des alertes SMS à la mauvaise personne | Le numéro d’urgence est récupéré via un appel au service patient. En cas d’indisponibilité de ce service n'aurait pas le possiblite de recuperere le numéro| Moyenne| Élevé| Conserver une copie locale du numéro de téléphone d’urgence avec l'ID du gateway pour un envoi de secours en cas de panne du service patient.|
+| Indisponibilité d’un service| Certains services peuvent devenir momentanément indisponibles ou surchargés, affectant le système global.| Moyenne| Élevé| Héberger plusieurs instances de chaque service avec un load balancer pour répartir la charge, assurant une haute disponibilité et limitant les interruptions en cas de surcharge.|
+| Problème de connexion client-cloud| Si Prometheus devient indisponible pour surcharge ou autre problème, les données peuvent ne pas être enregistrées correctement.| Moyenne| Élevé| Utiliser un broker de messages pour stocker temporairement les données en file d’attente, permettant leur transmission une fois la connexion rétablie. |
+| Indisponibilité de la base de données| Si la base de données MongoDB est indisponible en raison d’une surcharge ou d'un problème de serveur, cela peut entraîner des interruptions. | Moyenne | Élevé | Déployer plusieurs instances de la base de données avec une synchronisation continue pour garantir la disponibilité et répartir les requêtes. |
+| Coupure d’électricité| Une coupure de courant au niveau du gateway pourrait interrompre le fonctionnement du système de détection d’alerte.| Faible| Élevé| Installer une batterie de secours dans le gateway pour garantir une alimentation continue en cas de coupure électrique. |
+| Risques de sécurité| Des vulnérabilités peuvent affecter les communications entre microservices, exposant le système aux attaques.| Moyenne| Élevé| Assurer une communication sécurisée en utilisant HTTPS entre les microservices pour protéger les données contre les interceptions et les attaques.|
+| Mauvaise gestion des accès| Un accès non sécurisé pourrait compromettre l'intégrité et la confidentialité des données du système.| Moyenne| Élevé| Mettre en place un système d'authentification robuste et sécurisé pour garantir la sécurité des accès au sein de l’application.|
+| Non-conformité réglementaire| Le non-respect des réglementations sur la protection des données personnelles peut exposer l’organisation à des sanctions.| Moyenne| Élevé| Adopter une politique de protection des données en conformité avec le RGPD ou autres réglementations locales. Effectuer des audits de conformité réguliers et former le personnel.|
diff --git a/Documentation/sous-section/perimetre.md b/Documentation/sous-section/perimetre.md
new file mode 100644
index 0000000..0180c8f
--- /dev/null
+++ b/Documentation/sous-section/perimetre.md
@@ -0,0 +1,24 @@
+# Définition du périmètre du POC
+
+Pour notre étude, nous nous sommes concentrés sur un POC qui porte principalement sur la collecte, le traitement
+et la gestion des données de santé des patients âgés, en intégrant un système d'alerte pour les médecins.
+
+## Objectifs du POC
+
+### Collecte des données des patients
+Mise en place d'un système IoT pour recueillir des informations en temps réel sur les signes vitaux des patients.
+Cette collecte inclut les données provenant de capteurs.
+
+### Détection et gestion des alertes
+Développement de modules d'analyse des données de santé pour détecter des situations potentiellement urgentes.
+En cas de détection d'anomalies, des alertes urgentes sont générées. Le système permet également l'envoi automatique de
+SMS aux proches afin d'assurer une réponse rapide en cas de besoin.
+
+### Consultation des informations par les médecins
+Intégration d'une interface de visualisation permettant aux médecins d’accéder aux données médicales et d'effectuer
+un suivi précis de l’état de santé des patients. Ce module facilite la consultation de l'historique des alertes ainsi
+que de l'état général des patients.
+
+### Gestion des comptes des patients
+Création et administration de comptes patients dans le système, offrant un moyen structuré pour les professionnels
+de santé de suivre l’évolution des patients, de mettre à jour leurs informations et d'ajouter des capteurs assignés.
diff --git a/Documentation/sous-section/quickstart.md b/Documentation/sous-section/quickstart.md
new file mode 100644
index 0000000..1499bfa
--- /dev/null
+++ b/Documentation/sous-section/quickstart.md
@@ -0,0 +1,36 @@
+# Quickstart
+
+This project is composed of 3 parts :
+- Sensors
+- Gateway
+- WebApp
+
+**Launch the Webapp** by deploying the 2 docker compose :
+- [Prometheus stack](../../docker-compose.yaml)
+- [Services](../../cloud/backend/docker-compose.yml)
+
+**Launch the webapp portail** directly on the [frontend directory](../../cloud/frontend/)
+```
+npm install
+```
+pour installer les dépendances
+```
+npm run start
+```
+pour lancer le serveur de développement
+
+Access the frontend at [http://localhost:8080](http://localhost:8080)
+ - Register a new patient
+ - Connect to the mongoDB and retrieve his gateway ID
+
+Replace the gateway id in the corresponding environment variables in the [gateway docker compose](../../gateway/docker-compose.yml)
+**Launch the gatway** by deploying the following docker compose :
+
+- [Gateway](../../gateway/docker-compose.yml)
+
+
+After this two steps you can execute the simulate.py script that will emulate data to the gateway adapter as if you were using sensors. The gateway will then compute the measures and send it to the prometheus server.
+
+
+You can now explore you're metrics directly on the prometheus server :
+[http://localhost:9090](http://localhost:9090)
\ No newline at end of file
diff --git a/Documentation/sous-section/securite.md b/Documentation/sous-section/securite.md
new file mode 100644
index 0000000..1cd773a
--- /dev/null
+++ b/Documentation/sous-section/securite.md
@@ -0,0 +1,18 @@
+# Sécurité des données
+
+## Risque :
+##### Perte des données :
+**Coupure internet :**
+En cas de coupure de la connexion entre la gateway et le serveur, la gateway ne peut plus déverser les mesures prises dans le serveur. La solution implémentée embarque un broker [RabbitMQ](https://www.rabbitmq.com/). Ce broker permet de stocker les métriques récoltées sur le disque de la gateway en s'assurant de leur transmission avant de les supprimer du disque.
+
+**Incident côté serveur :**
+Grâce à la technologie cloud et à la réplication possible avec le serveur Prometheus, les données des patients peuvent être sauvegardées en différents endroits, garantissant qu'en cas de perte d'un serveur, le deuxième puisse prendre le relais sans perte de données.
+
+Des sauvegardes de la base de données sont également réalisées toutes les 4 heures.
+
+##### Vol des données :
+**Côté gateway :**
+Les données des patients sont stockées sur la gateway de manière anonyme. Chaque patient se voit attribuer une gateway possédant son propre identifiant. Les données sont remontées au serveur avec l’identifiant de la gateway et non celui du patient. Le lien entre l'identité du patient et les données récoltées n'est fait qu'au moment de la visualisation.
+
+**Pendant l'envoi :**
+Les envois de données sont réalisés de manière sécurisée avec le protocole HTTPS, qui permet un envoi chiffré des données.
\ No newline at end of file
diff --git a/Documentation/sous-section/services.md b/Documentation/sous-section/services.md
new file mode 100644
index 0000000..452a459
--- /dev/null
+++ b/Documentation/sous-section/services.md
@@ -0,0 +1,73 @@
+# Description des Services du Système
+
+Dans cette section, nous détaillons les principaux services du système, chacun jouant un rôle spécifique dans la gestion,
+le traitement et la transmission des données de santé des patients. Ces services assurent une surveillance
+en temps réel ainsi que la gestion des alertes.
+
+## Côté Client
+
+1. **[Détection Alerte Service](../../gateway/dataManager/alerter.go)**
+ Ce service est essentiel pour identifier les situations critiques en détectant des valeurs anormales dans les données
+ de santé des patients. Lorsqu'une valeur critique est repérée, une alerte est envoyée par SMS au numéro de téléphone
+ d'un proche stocké localement. Le service utilise une clé 4G pour garantir la transmission des alertes, assurant ainsi
+ une notification immédiate aux proches en cas d'urgence.
+
+ Ce service se situe avant la phase de downsampling pour garantir que les utilisateurs, tels que les proches ou les
+ soignants, sont informés de tout problème de santé potentiel dès qu'il survient. En détectant et en envoyant
+ une alerte immédiatement, nous maximisons la réactivité et la sécurité. En plus de l'envoi automatique du SMS,
+ il est recommandé de procéder à une vérification supplémentaire, comme un appel au patient ou à son proche
+ pour confirmer la situation.
+
+2. **[Down-sampling Service](../../gateway/dataManager/downsampler.go)**
+ Ce service optimise la transmission des informations vers le cloud en réduisant la quantité de données envoyées.
+ En filtrant les informations pour ne conserver que les données pertinentes, le service minimise la consommation des ressources réseau et diminue les risques de fausses alertes. Ainsi, seules les données essentielles sont transmises pour un suivi de qualité.
+
+3. **[PushGateway Service](../../gateway/dataManager/compacter.go)**
+ Ce service transmet les données vers le cloud après avoir atteint un seuil de collecte prédéfini. Le PushGateway
+ permet une transmission contrôlée et périodique des données, facilitant ainsi la centralisation et l'archivage des
+ informations de santé pour une accessibilité future.
+
+## Côté Cloud
+
+1. **[GestionAlertService](../../cloud/backend/alert-management/)**
+ Ce service gère l’ensemble des alertes, les stocke dans une base de données dédiée, et permet diverses opérations :
+ - Récupération d’une alerte spécifique
+ - Récupération des alertes liées à un gateway spécifique
+ - Consultation de toutes les alertes stockées
+ - Filtrage des alertes par gravité et par état (traitées ou non traitées)
+ - Création de nouvelles alertes
+ - Mise à jour ou suppression des alertes existantes
+ - Notification automatique des médecins pour les alertes non traitées
+
+ Ce service assure une gestion et un traitement efficaces des alertes pour un suivi rigoureux des incidents de santé.
+
+2. **[AlertManager](../../cloud/config/alertmanager/)**
+ Ce composant gère les alertes générées par Prometheus pour le suivi de la glycémie, du rythme cardiaque et de la
+ température corporelle du patient. Les alertes peuvent être basées sur la détection de variations rapides
+ (alertes dérivées) ou sur des prédictions de niveaux futurs (alertes prédictives).
+
+ AlertManager centralise la gestion des alertes pour réduire les notifications redondantes et améliorer la réactivité
+ face aux situations critiques. Il permet de configurer des niveaux de gravité, de regrouper des alertes similaires et
+ de les envoyer de manière ciblée.
+
+ Une fois générées Les alertes sont ensuite envoyées au service de gestion des alertes pour être stockées
+ dans la base de données, assurant une traçabilité et facilitant l’analyse des tendances à long terme.
+
+3. **[Service Analyse Haut Niveau](../../cloud/backend/analyse-haut-niveau-management/)**
+ Ce service réalise un traitement avancé des données stockées afin de détecter des comportements inhabituels.
+ Il transforme les données brutes en valeurs plus lisibles et compréhensibles pour les médecins, infirmiers et proches,
+ facilitant ainsi leur interprétation et la prise de décisions médicales.
+
+4. **[Service Gestion Dossiers Patients](../../cloud/backend/patient-management/)**
+ Ce service assure la gestion des dossiers patients pour une organisation précise des informations de chaque patient.
+ Les principales fonctionnalités incluent :
+ - Récupération d'un patient par ID, gatewayID, ou nom et prénom
+ - Création de nouveaux dossiers patients
+ - Suppression des dossiers patients
+
+5. **[Service Gestion Consultation Patient](../../cloud/backend/patient-management/)**
+ Ce service facilite la gestion des consultations des médecins et des infirmiers, permettant de conserver un historique
+ détaillé des interactions médicales. Ses principales fonctionnalités incluent :
+ - Récupération d'une consultation par ID, par patientID, par DoctorID, ou par nurseID
+ - Création d'une nouvelle consultation
+ - Suppression d'une consultation
diff --git a/Documentation/sous-section/structureCode.md b/Documentation/sous-section/structureCode.md
new file mode 100644
index 0000000..e69de29
diff --git a/Documentation/sous-section/techno.md b/Documentation/sous-section/techno.md
new file mode 100644
index 0000000..68c0eb4
--- /dev/null
+++ b/Documentation/sous-section/techno.md
@@ -0,0 +1,53 @@
+# Choix Technologiques
+
+## 1. **Java Quarkus**
+Quarkus est conçu pour les environnements cloud natifs, facilitant la gestion, le déploiement et la scalabilité
+des services. Il se distingue par sa rapidité de démarrage et sa faible utilisation de la mémoire, réduisant les coûts
+en ressources. Ces atouts sont cruciaux pour un déploiement cloud efficace et réactif. Comparé à d'autres langages
+ou frameworks, Quarkus offre un compromis optimal entre la robustesse de l'écosystème Java et la performance, ce qui
+le rend idéal pour des architectures de microservices dans le cloud.
+
+## 2. **Prometheus**
+Prometheus est conçu spécifiquement pour gérer des données chronologiques (time-series), ce qui est idéal pour
+des mesures prises à intervalles réguliers, comme les métriques de santé des utilisateurs. Contrairement à une base
+de données classique, Prometheus est optimisé pour stocker, interroger et analyser rapidement des séries temporelles,
+ce qui facilite la détection de tendances, d'anomalies et l'analyse historique des données. Cette capacité est cruciale
+pour évaluer l'état de santé général des patients et générer des alertes.
+
+## 3. **Grafana**
+Grafana est un excellent choix pour visualiser les données de santé collectées. Il permet de créer des dashboards
+interactifs et personnalisés à partir des métriques de séries temporelles stockées dans des bases de données comme
+Prometheus. Grafana permet d'afficher des données en temps réel de manière claire et visuellement engageante, ce qui
+aide les utilisateurs à analyser facilement les données. De plus, il peut être intégré directement dans une application
+front-end pour faciliter l'accès aux données.
+
+## 4. **Go**
+Go est un excellent choix pour les systèmes IoT en raison de sa performance élevée et de sa faible empreinte mémoire.
+Ces caractéristiques sont essentielles pour des appareils souvent limités en ressources. De plus, Go offre une syntaxe
+simple, facilitant la maintenance du code, et sa gestion automatique de la mémoire assure des performances optimales
+tout en réduisant la complexité du développement.
+
+## 5. **MongoDB**
+MongoDB est choisi pour sa capacité à garantir une scalabilité efficace grâce à son modèle de données orienté document.
+Cela permet une gestion indépendante des données par chaque service sans nécessiter des insertions dans d'autres tables,
+ce qui le rend idéal pour des transactions indépendantes. De plus, MongoDB favorise l'eventual consistency plutôt
+qu'une cohérence immédiate, offrant ainsi une meilleure disponibilité des services, particulièrement dans
+un environnement de microservices distribués.
+
+## 6. **RabbitMQ**
+RabbitMQ est sélectionné pour sa gestion asynchrone des files de messages, garantissant une transmission fiable
+des données même en cas de pics de trafic. Il est particulièrement adapté aux systèmes nécessitant une livraison
+garantie de messages et un traitement rapide. De plus, RabbitMQ est optimisé pour des environnements à ressources
+limitées, offrant un excellent compromis entre performance et consommation des ressources.
+
+## 7. **Traefik**
+Traefik sert de reverse proxy pour diriger le trafic vers le frontend et permettre un accès fluide à certaines
+fonctionnalités. Il simplifie la gestion des points d’entrée pour différents types d’utilisateurs grâce à un routage
+dynamique et la gestion des certificats SSL pour sécuriser les connexions. Traefik est compatible avec des environnements
+comme Docker et Kubernetes, facilitant ainsi le déploiement et la gestion du système dans le cloud, ce qui rend l’architecture évolutive.
+
+## 8. **Keycloak**
+Keycloak est utilisé pour la gestion de l'authentification et de l’autorisation basée sur les rôles des utilisateurs
+(proches, médecins, infirmiers). En centralisant la gestion des identités, Keycloak offre une solution complète, sécurisée
+et modulable pour contrôler les accès aux différentes parties du système. Il garantit que seuls les utilisateurs autorisés
+peuvent accéder aux informations sensibles, ce qui est crucial pour assurer la confidentialité des données de santé.
diff --git a/Documentation/sous-section/usecases.md b/Documentation/sous-section/usecases.md
new file mode 100644
index 0000000..c54ea57
--- /dev/null
+++ b/Documentation/sous-section/usecases.md
@@ -0,0 +1,52 @@
+# Use Case
+
+Dans cette section, nous décrivons les cas d'utilisation sur lesquels repose notre étude, en identifiant les actions,
+les rôles des utilisateurs et les objectifs pour chaque fonctionnalité du système. Chaque cas d'utilisation est conçu
+pour répondre aux besoins spécifiques des différents acteurs (médecins, infirmiers, proches, patients, développeurs
+et système IoT) et contribue à la prise en charge et à la surveillance efficace des personnes âgées.
+
+## 1. Médecin
+- **En tant que médecin**, je veux enregistrer un rapport de consultation, afin de suivre l'évolution du patient
+et partager des informations avec d'autres professionnels de santé.
+- **En tant que médecin**, je veux visualiser les rapports médicaux détaillés, afin de disposer d'une vue complète
+sur l'historique de santé du patient.
+- **En tant que médecin**, je veux assigner des capteurs à un patient, afin de surveiller en temps réel ses signes
+vitaux et recevoir des alertes en cas d'incidents.
+- **En tant que médecin**, je veux gérer des patients, afin de pouvoir créer, supprimer et modifier les comptes
+pour organiser le suivi.
+
+## 2. Médecin ou Infirmier
+- **En tant que médecin ou infirmier**, je veux gérer les proches des patients, afin de leur donner la possibilité
+de suivre l'état de santé du patient.
+- **En tant que médecin ou infirmier**, je veux être notifié lorsque les capteurs cessent d'envoyer des données
+pendant une période prolongée, afin de pouvoir intervenir et éviter toute perte d'information ou problème de santé non détecté.
+
+## 3. Infirmier
+- **En tant qu'infirmier**, je veux enregistrer un rapport de santé du patient, afin de mettre à jour
+les informations médicales régulièrement.
+- **En tant qu'infirmier**, je veux pouvoir renseigner des mesures manuelles dans le système, afin d’ajouter
+des informations supplémentaires non collectées par les capteurs, comme le taux de glucose.
+- **En tant qu'infirmier**, je veux pouvoir visualiser les données des capteurs, afin de suivre l'état de santé
+de la personne de manière proactive.
+
+## 4. Proche du Patient
+- **En tant que membre de la famille**, je veux visualiser l'état général du patient, afin d’avoir un aperçu de
+sa santé sans accéder aux données médicales sensibles.
+- **En tant que membre de la famille ou infirmier**, je veux être notifié en cas d'urgence, afin d'intervenir
+le plus tôt possible si nécessaire.
+
+## 5. Patient
+- **En tant que patient**, je veux remplir un formulaire de ressenti sur mon état de santé, afin de partager
+mon vécu quotidien et mes symptômes avec les professionnels de santé pour un suivi plus personnalisé.
+
+## 6. Développeur
+- **En tant que développeur**, je veux administrer les utilisateurs, afin d'assurer un accès sécurisé et limité
+aux informations sensibles.
+- **En tant que développeur**, je veux configurer et mettre à jour le système, afin de garantir la bonne intégration
+des nouveaux capteurs et la sécurité des données.
+
+## 7. Système IoT
+- **En tant que système IoT**, je veux remonter automatiquement les données, afin de surveiller en temps réel l'état
+du patient.
+- **En tant que système IoT**, je veux notifier automatiquement les utilisateurs en cas de dysfonctionnement ou d'alerte,
+afin qu'ils puissent réagir rapidement en cas de problème.
diff --git a/cloud/frontend/src/components/profil/Profil.tsx b/cloud/frontend/src/components/profil/Profil.tsx
index 9218a1d..0940746 100644
--- a/cloud/frontend/src/components/profil/Profil.tsx
+++ b/cloud/frontend/src/components/profil/Profil.tsx
@@ -72,13 +72,6 @@ export default function Profil() {
-
-
- Alerts
-
-
-
-
Dashboards
@@ -92,6 +85,13 @@ export default function Profil() {
+
+
+ Alerts
+
+
+
+
) : (