1. Description du projet
2. Architecture et sécurité
3. Pré-requis
4. Configuration
5. Monitoring
6. Lancer le SI
7. Utilisation
8. Authentification et rôles
9. Contact
10. Contribution

Cette partie présente la description fonctionnelle, technique et le cadre de réalisation du projet.

Le Diagnostic de Performance Energétique (DPE) sert de document de référence pour :

• évaluer la consommation d'énergie d'un bâtiment/logement (étiquette énergie)
• évaluer les émissions de gaz à effet de serre (étiquette GES).

Depuis son introduction en 2006, la méthode de calcul n'a cessé d'être réévaluée pour coller au plus près à la réalité et fait constamment l'objet d'étude scientifiques. Ces études se basent toutes sur des échantillons de données et tombent toutes d'accord sur le fait que malgré les efforts réalisés, le DPE a tendance à sur évaluer les consommations énergétique des logements.

Toutefois, ces études sont ponctuelles et réalisées chaque fois sur des échantillons de logement. Il en est ainsi en raison du challenge technique que représente l'exploitation des données volumineuses sur tous les logements français (plus de 12 millions). En effet, les données utilisées sont celles de Enedis, l'Ademe et la BAN.

Ce projet vient apporter une solution pratique à ce problème en développant une infrastructure ETL open source capable de collecter et de traiter les données volumineuses à l'échelle nationale disponibles (consommations Enedis, DPE ADEME, caractéristiques des logements) pour :

• Quantifier les écarts entre estimations DPE et consommations réelles mesurées par Enedis
• Mesurer la part de variabilité non expliquée par les caractéristiques des logements
• Apporter une aide à la décision pour les travaux de rénovation en prédisant les gains de performance énergétique selon le profil du logement.

Il s'agit d'un système d'information client/serveur où le serveur est organisé en microservices. L'objectif est d'analyser, comparer et prédire et expliquer la consommation énergétique des logements français. Le serveur exécute la charge de travail (pipelines de données, stockage, sécurité) et communique les données à l'application cliente pour l'analyse via une API rest.

Les composantes du SI ont été pensés pour être ré-utilisables en standalone ou avec intégration afin de faciliter un maximum la prise en main du sujet par les chercheurs. En suivant les instructions de ce guide vous aurez un jeu de données constamment à jour et exploitable et vous n'aurez plus qu'à vous concentrer sur la modélisation et l'analyse des résultats 📊 🙂.

Ce projet est réalisé dans le cadre du challenge OpenData University - DPE - saison 24/25. Il est également présenté et soutenu dans le cadre de la certification RNCP Ingénieur en Science des Données 2025.

Le schéma ci-dessous présnete l'architecure globale du SI. L'infra est composée de l'app client et du serveur. Le point d'entrée du serveur est l'API Rest qui interface avec les autres micro service du serveur et sert de data access layer. L'API Rest encapsule également l'application ETL. En effet une chaque instance de l'API rest démarre un agent prefect dans un thread séparé à l'initialisation. Ce moteur ETL est utilisé par le serveur prefect pour exéuter la charge de travail lors du déploiement. Les autres microservices du serveur sont :

• S3 Object Storage : représenté par une instance MinIO mais interfacable avec AWS S3 grâce à boto3
• seveur Prefect : nécéssaire pour l'ETL et le monitoring via son UI
• caching service Redis : utilisé pour l'authentification avec les OTP
• Postgres : utilisé pour la persistance des données à la sortie de l'ETL
• Prometheus, Grafana : utilisés pour surveiller les temps d'exécution des donctions et profiler l'API
• Traefik : sert de load balancer lorsqu'on exécute le serveur avec plusieurs instances de l'API rest.

Figure: Vue simplifiée de l'architecture du SI

Le schéma suivant montre une vue globale des flux de données échangés entre les micro services d'une part et entre le serveur et le client de l'autre.

Figure: Vue globale des flux de données échangées

Les repos gitmodules utilisent des pipelines CI/CD centralisés dans le dossier pipelines-templates.

La sécurité est gérée par l'API coté serveur. Pour récupérer de la donnée, il faut être authentifié au moins comme READER. L'autre niveau d'authentification est ADMIN qui permet d'avoir accès à d'autres routes de l'API y compris celles permettant de déployer l'ETL ou d'envoyer des mails à la base d'utilisateurs. Pour s'authentifier, il faut disposer d'une adresse mail valide sur laquelle un OTP est envoyé. Cet OTP permet d'avoir une session de connexion de quelques heures (paramétrable par l'admin).

• Python 3.12
• Docker desktop
• Compte DockerHub
• Compte AWS (optionnel)

• Option 1 : Configuration low code et rapide (recommandée)

Commencer par cloner ce repos git avec la commande :

git clone https://github.com/fereol023/DPE-Energy-Performance-Analysis.git

Ensuite définir les variables d'environnement suivantes dans un fichier .env à la racine du projet. Voir le fichier exemple

ENV="NOLOCAL"
POSTGRES_DB_NAME="dpedb_v2"
POSTGRES_ADMIN_USERNAME="postgres"
POSTGRES_ADMIN_PASSWORD="password"
POSTGRES_READER_USERNAME="reader"
POSTGRES_READER_PASSWORD="reader_password"
POSTGRES_WRITER_USERNAME="writer"
POSTGRES_WRITER_PASSWORD="writer_password"
S3_ACCESS_KEY="minio-access-key"
S3_SECRET_KEY="minio-secret-key"
S3_BUCKET_NAME="dpe-storage-v1"
MINIO_ROOT_USER="minio"
MINIO_ROOT_PASSWORD="password"
SMTP_USERNAME="google-email-that-will-sent-mails@gmail.com"
SMTP_PASSWORD="code-got-from-google"
ADMIN_EMAIL="any-admin-email-to-auth-as-admin-in-client-app"
AWS_S3_STREAMLIT_ACCESS_KEY="optional-aws-s3-access-key"
AWS_S3_STREAMLIT_SECRET_KEY="optional-aws-s3-secret-key"
AWS_S3_STREAMLIT_BUCKET_NAME="dpe-storage-aws-v1"
GRAFANA_ADMIN_USER="admin"
GRAFANA_ADMIN_PASSWORD="adminpwd"
VERSION_DASHBORD="v0.10.0.1756027620" 
VERSION_API="v0.19.0.1756058671"

Pour les versions de l'API et du dashboard, consultez les pages dockerhub :

• Image docker server
• Image docker client

Pour monitorer le SI, on implémente plusieurs solutions :

• mailing de l'état des micro services fait après pring par l'API Gateway :

Utilise le même module de mailing que le SSO basé sur le serveur SMTP de gmail (procédure ici).

• monitoring via Prefect UI pour l'ETL et les logs
• monitoring de l'API elle même via Prometheus + Grafana

Ceci est possible grâce au client prometheus qui est utilisé dans l'API. Pour configurer le collecteur de métrqiues prometheus, il faut mettre dans un bind mount le fichier de fichier de config suivant. A mettre dans /DPE-Energy-Performance-Analysis-API/storage/prometheus/prometheus.yml car les docker compose files sont configurés ainsi (voir volume prometheus).

global:
  scrape_interval: 5s

scrape_configs:
  - job_name: "api-functions-profiling"
    metrics_path: /profiling
    static_configs:
      - targets: ["api:8000"]

  - job_name: "api-system-metrics"
    metrics_path: /metrics
    static_configs:
      - targets: ["api:8000"]

• Option 2 : Configuration en partant de la code base

Cloner le projet avec la commande. Clonera également tous les sous modules git

git clone --recursive https://github.com/fereol023/DPE-Energy-Performance-Analysis.git

Ensuite pour chacun des modules client et serveur, créer un venv et exécuter la commande :

pip install -r requirements.txt

Vous l'aurez remarqué on a 3 fichiers docker-compose dans ce repos. Les deux premiers .dev et .prod sont respectivement utilisés pour exécuter la stack complète avec docker compose. Le dernier .local est utilisé pour déployer les micro services utilisés par le serveur uniquement. Ceci est pratique pour lancer le SI avec l'option 2 (cloner la code base et décortiquer le code).

• Option 1

Exécuter l'une des commande suivantes pour déployer la stack dans la config 1.

-- déploiement basique --

docker compose -f docker-compose.dev.yml --env-file .env up -d --build

-- déploiement avec k replicats de l'api --

docker compose -f docker-compose.dev.yml --env-file .env up --scale api=k -d

-- déploiement avec docker swarm (reproduire le fonctionement des clusters k8s) --

docker swarm init
docker stack deploy -c docker-compose.prod.yml dpe
docker service scale dpe_api=3

• Option 2 :

Lancer le serveur API et le client avec les commandes

# api
python3 main.py --local

# client app
streamlit run app.py --server.port=8501

La documentation interactive du serveur est accessble sur le port 8000 de votre machine. L'interface dashboard analytique est disponible sur le port 8501.

L'interface client est une app streamlit multipages (3 pages). La première est la page de connexion. Obligatoire pour s'authetifier et utiliser l'app. Permet de s'authentifier soit en tant qu'admin ou en tant que lecteur simple.

Figure: Page de connexion sur l'app client

La deuxième page présente les graphiques.

Figure: dataviz 1

Figure: dataviz 2

La troisième page, encapsule un modèle IA qui permet de prédire les éconopmies réalisables en engageant des travaux pour changer de classe DPE.

Pour obtenir ce modèle random forest nous avons réalisé une étude visant à comprendre les facteurs explicatifs de la consommation énergétique des bâtiments sur la base des variables dont on disposait. Ces 220 variables portaient sur les caractérisiques des logements et sont obtenues via le pipeline d'ETL à l'étape silver data. Le résultat de l'anayse de données est présentée dans ce rapport.

L'image suivante présente les performances du modèle en apprentissage-validation.

Figure: Métriques modele rf-oise-2023

Et enfin, les images suivante présntent un ensemble d'inputs et un exemple d'output (matrice de gain):

Figure:variables inputs du modèle

Figure:matrice de gains

Pour le serveur, la documentation interactive est accessible via le swagger.

Figure: swagger UI

Pour plus d'information sur l'utilisation de l'app cliente, un support de formation est disponible ici

Figure: Panel admin dans l'app

Etant connecté en tant qu'administatrateur dans l'app client, les solutions de monitoring énumérées ci-dessus sont toutes accessibles sur la première page. Plus précisément, lorsque l'admin se connecte :

• il reçoit un état global du SI par mail avec messages d'erreur si erreur il y a.

Figure: SI Global State Report to Admin

• il peut accéder à l'UI prefect sur le server:4200

Figure: Prefect UI

• il peut accéder au dashboard grafana pour voir les métriques CPU, RAM etc de l'API et le profiling de toutes les fonctions utilisées sur le serveur:3000

Figure: Dashboard Grafana Monitoring

Pour les mesures de sécurité, on implemente un système d'authentification SSO avec oAuth2 basé sur 2 rôles ADMIN et READER. Ces rôles sont crées au niveau de l'API. En effet, pour utiliser les endpoints database, l'utilisateur doit s'authentifier. L'authentification consiste à envoyer un OTP sur l'adresse mail renseignée. L'utilisateur doit alors consulter ses mails et saisir l'OTP recu. Ceci donne doit à une session de quelques heures. Si l'email utilisé est celui de l'admin, l'utilisateur est authentifié en tant que tel et peut avoir accès au panel admin qui permet de faire plusieurs choses entre autres :

• exécuter le déploiment de l'ETL
• exécuter l'ETL en targettant un département
• accéder au tableau de bord de monitoring avec Prefect et Grafana

Figure: Authentification

• Le schéma ci-dessous récapitule le fonctionnement du gitflow reproduit partout dans le projet avec les pipelines de CI/CD

Figure: Gitflow

• Pour toute contribution, vous êtes libre de forker ce repos ou celui d'un des modules en respectant les licences.
• Vous pouvez également contribuer à l'évolution du projet en ajoutant des US dans le github project ici.

• E-mail : fereol.gbenou@ynov.com
• Page pro : LinkedIn