Merge remote-tracking branch 'origin/main'

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)

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
+<img src="../diagrams/MS.png" />
+
+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.

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.
+
+<img src="../diagrams/Archi_model_de_donnees.jpg">

Documentation/sous-section/fonctionnement.md

@@ -0,0 +1,75 @@
+# Fonctionnement du Système
+
+<img src="../diagrams/archi.jpg"/>
+
+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.

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.

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.|

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.