233 lines
9.9 KiB
Markdown
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 -->
|