Files
healthai/dossier/dossier.md
Awen Lelu 7340e61a30 add models and temps UML
- add new models
- temp change to UML diagrams
2026-03-08 12:43:23 +01:00

233 lines
9.9 KiB
Markdown

---
title: "MSPR EPSI - HealthAI"
sub_title: "Rapport technique et guide de déploiement"
authors:
- Abdellah Ait Abdelkarim
- Awenn lelu
- Noah Lejolivet
- Thibau Lasblei
- https://gitlab.com/la-team-du-sang-de-la-veine/healthai-coach
---
Table de matières
===
<!-- column_layout: [1,4,1] -->
<!-- column: 1 -->
# Mise en contexte
# Choix technologiques
## Backend
### Framework
### Bases de donnée
## Visualisation
## Environnement de développement
## Environnement de déploiement
# résultat obtenus
# difficultés
# évolutions
Mise en contexte
===
L'entreprise healthAI coach cherche à mettre en place une application
de conseil d'hygiène de vie orienté autour d'une aproche holistique (
considérer la santé comme un ensemble de système interagissant entre eux
plutôt qu'un seul point précis) de la santé.
Dans ce cadre, le but de ce projet est de concevoire une solution logicelle
satisfsaisant les points suivants:
# Business model
La monétisation de l'application doit être assurée par 2 paliers d'abonnements.
Les utilisateurs non abonnés ont accès aux fonctionnalités suivantes:
- journal alimenaire, suivis d'activité, IMC, tableaux de progressions simples
Les 2 paliers suivants donnes accèes aux fonctions suivantes:
- Premium **(9.99€ / mois)**
- accès à des recommendations spécialisés fournis par IA, des plans
nutritionels et sportifs plus détailés, et un suivis plus fin des
objectifs.
- Premium +
- Gestion des données lié au sommeil / poid / fréquence cardiaque,
consultation en ligne avec nutritionistes partenaires.
En plus de ces paliers d'abonnements, l'application dois pouvoir être vendus
en **B2B** à des entreprises partenaires avec la possibilités pour ces
dernières d'apposer leur branding.
Mise en contexte
===
# Cibles
Les cibles de l'application sont:
- Millenials / GenZ
- urbains actifs ne disposant que d'un temps limité pour leur activité sportive
- débutant en nutrition / sport
- personne avec des objectifs spécifiques
- perte de poid
- renforcement musculaire
- amélioration de sommeil
- ...
# Différentation concurentielle
Le marché étant fortement concurenciel, l'application se différencie par les
points suivants:
- approche hollistique de la santé
- intégration de l'IA générative
- stratégie B2B permettant une source de revenu / visibilité suplémentaire
# Scalabilité technologique
Afin de soutenir sa croissance future et son modèle B2B, l'application
dois pouvoir être scalable au niveau de ses différents composants.
Ainsi, chaque module de l'application dois être construit sur de technologies
modernes, documentées et permettant d'assurer la stabilité et la
scalabilité de chaque module séparément, ainsi que leur déploiement et
maintenance pour des clients B2B.
Mise en contexte
===
# Objectif
Dans le cadre de ce bloc de développement, l'objectif est de fournis un
prototype de la partie **Ingestion de données** de l'application finale.
Il s'agis de définir le socle technique et structurel sur lequel les
développements ultérieurs vont se baser.
Le rendus final doit être capable d'ingérer des set de données provenant
de multiples source de données et de les convertir dans un format standardisé
afin d'être exploité par les parties ultérieurs de l'application.
Les objectifs concrêts sont les suivants:
- Mettre en place un système de collecte et de traitement autmatiser des
données de manière fiable et sécuriser.
- Développer un processus de transformation de ces données afin de garantir
l'exploitation de ces dernières dans des outils ultérieurs
- Proposer une **API REST** permettant aux clients mobiles et web d'accéder
à ses données.
- livrer une interface de visualisation permettant de suivre les indicateurs
clés de l'application (revenu, nb d'utilisateurs, abonnements, ect...)
Choix technologique
===
# Backend
## Framework
Le choix à été fait d'utiliser [Django](https://www.djangoproject.com/)
et [Django Rest Framework](https://www.django-rest-framework.org/) afin de
gérer la partie **API** de l'application.
Ce choix est motivé par le fait que
*Django* est un framework reconnu comme étant particulièrement maintenable sur
le long terme, il est conçus avec le language *Python*, qui, bien que simple
à apprendre, ce qui en fait un plus pour l'intégration de nouveaux arrivant,
est un language extrêmement facile à déployé sur de multiples plateformes,
et disposant d'un écosystème riche autant pour le web que pour le traitement
de données et l'IA.
De plus, Django propose nativement une interface d'administration extensible
permettant d'interagir avec les données stockée dans la base de données,
ainsi qu'une gestion des rôles et des utilisateurs, permettant de répondre
à ces besoins pour un coût de développement minime.
Django propose de plus un ORM pouvant s'intégrer dans des scripts externes
permettant de standardiser la manière dont la base de données est accéder,
fiabilisant les opérations de lectures et d'écritures.
## Bases de donnée
### [Postgres](https://www.postgresql.org/)
Base de donnée principale servant au stockage "*froid*" des données,
postgres dispose d'un large écosystème d'utilisateur et de libairies associés et
est reconnu comme une solution performante et open source.
### [Valkey](https://valkey.io/)
Base de données de cache pour les requêtes api et les données d'entrainement
du futur modèle d'IA. **Valkey** est une base clé/valeur stockée en RAM qui implémente
la spécification de *Redis*, ce qui la rend compatible avec le parc de librairie
déjà en place pour cette dernière.
Choix technologique
===
# Visualisation
## [Grafana](https://grafana.com/oss/grafana/)
Grafana est une solution open source simple d'utilisation et extrêmement
versatile concernant les types et sources de données qu'elle peut aggréer.
Elle permet de concevoir des dashboard contenant une variété non négligeable
de graphiques et, de son côté open source, peut être étendre pour satisfaire
les besoin spécifiques du projet.
# Environnement de développement
## [nix](https://nixos.org/)
Nix est un manage de paquet permettant de créer des environnement de
développements et des paquets de manière déclarrative et reproductible.
Ce mécanisme permet d'assurer la reproductibilité de l'environnement de
développement d'un pc à un autre, et de manière isolée, permettant de
réduire les erreurs lié à l'environnement du développeur.
De plus, cela peut être utilisé comme outil de build avec les
mêmes avantages, permettant de réduire les outils de builds différents et
de simplifié drastiquement la maintenance de scripts de builds et de CI/CD.
## [git](https://git-scm.com/)
Le projet est versionné avec git afin d'assurer un historique des
modifications du code et que chaque développeur puisse intervenir sur
des branches spécifiques du code et les fusionner avec celles des autres.
Git est la référence moderne de ce type d'outil et est un choix par défaut
dans la plupart des projets.
## [gitlab](gitlab.com)
Gitlab est la forge logicielle concurente à github, contrairement à ce dernier,
il n'est pas détenu par Microsoft et est self hostable, ce qui fait que le
projet pourra être facilement porté si l'entreprise décide de self hoster son
infrastructure dans le futur. Gitlab intègre de même des outils de gestion de
projet via les issues boards, ainsi qu'une CI/CD solide.
Choix Technologique
===
# Environnement de déploiement
## Virtualisation
### Podman
Dans un soucis d'isolation des différents modules du projet, chaque
composant sera fournis sous la forme d'une image **podman** qui est une
implémentation open source du standard de **Docker**, ce dernier permet de
plus de fonctionner *rootless* par défaut, ce qui permet d'éviter les
escalations de privilèges si la daemon est compromis. De plus, les images
serons builder par **nix** afin d'assurer la reproductibilité des builds.
Le choix de conteurs comme environnement de déploiement permet de pouvoir
isoler les dépendences de chaque module, ainsi que de pouvoir les déployé,
stopper et redémarrer séparément. De plus, dans une optique de scalabilité,
il est possible de lancer plusieurs instances d'un module afin de distribuer
la charge sur toutes les instance disponibles.
Difficultés
===
La plus grosse difficulté du projet fut de déterminer l'approche que l'on
allait avoir concernant le traitement des données par l'IA, quel données était
pertinantes, comment utilisé l'IA dans des fonctions où elle aurais plus
de valeur ajouté qu'une approche déterministe.
Au final, l'approche retenue
est d'utilisé l'IA comme un moteur de suggestions et de concevoir l'interface
de l'application de manière "AI-first", c'est à dire de présenter l'application
comme une interface de conversation avec l'agent, ce dernier pouvant répondre
aux questions de l'utilisateur basée sur ses données biométriques et le
dataset auquel il a accès. L'utilisateur converse ainsi avec l'agent afin
de lui énoncé ses objectifs, lui demandé des exemples de repas et des exercices
sur le moment de son activité, conseils qu'il peut retrouver dans son historique.
Évolutions
===
# CI/CD
La mise en place d'un processus de développement continue permettant d'analyser
de façon automatique la qualité du code serais un plus non négligeable afin
d'assurer la stabilité long terme du produit.
De plus, un système de déploiement continue permettrais de réduire les marges
d'erreurs et les coûts lié à des déploiement manuels, ainsi que de mettre en place
différents environnements (production / développement) de manière automatisé.
# Tests
De la même façon que la mise en place d'une CI, la mise en place de Test unitaires
pour les pipelines d'ingestions et l'API permettrais de s'assurer de l'intégrité
du code au cours des développements successif. Ces points pourrais être
directement intégrer au seins du processus de développement via des méthodologies
de *TDD*
<!-- include: uml.md -->
Dossier de déploiement
===
<!-- include: ../README.md -->