GoodAir (Phase 2) : Visualisation des données (Cas d'usage Analyste)

Contexte

Ce projet s’inscrit dans le cadre de ma formation en ingénierie des données, menée avec mes collègues. Il est structuré en plusieurs phases : la construction d’un pipeline data, puis l’exploitation des données issues de ce pipeline. Cette année, nous avons travaillé sur ces deux premières phases : la construction du pipeline data (lien vers la documentation du pipeline) et l’exploitation des données, elle-même divisée en deux volets: un cas d’usage IA et un cas d’usage Analyste. Cette documentation couvre la partie sur laquelle nous avons travaillé : la visualisation des données.

L’entreprise fictive TotalGreen, qui opère dans le secteur des énergies renouvelables, a décidé de développer son pôle R&D en créant GoodAir : un laboratoire de recherche pour étudier la qualité de l’air et de l’eau en France.

GoodAir souhaite utiliser les données récoltées afin de mettre à disposition de ses chercheurs un certain nombre de rapports sur les principales villes de France. L’objectif est de valoriser les données pour en extraire des KPI, visualisations et dashboards pertinents. GoodAir s’intéresse en particulier à trois types de livrables :

• Des rapports sur les indicateurs principaux de qualité de l’air et les indicateurs météorologiques.
• Des rapports mettant en lumière les variations extrêmes, de façon à alerter les équipes sur une situation anormale.
• Des rapports mettant en lumière les variables fortement corrélées.

Nous avons décidé de réaliser la visualisation juste après la phase du cas d’usage IA, car cela nous permet de visualiser nos prédictions et cela va aider les chercheurs à prendre leurs décisions en ayant, d’un côté, les prédictions sous les yeux. C’est ce choix d’enchaînement qui nous a le plus aidés dans ce projet.

Analyse de notre source de données

Notre source de données pour la visualisation est le Data Warehouse SQL Server construit lors de la Phase 1. Il a été modélisé en étoile (Star Schema) et comprend :

• Une table de faits principale : FactMesures.
• Deux tables de dimensions : DimLieux et DimTemps.
• Une table additionnelle issue de la phase IA : AlertesPredites.

C’est à partir de ces tables modélisées que nous allons créer les visualisations nécessaires pour notre tableau de bord.

Choix de l’outil de visualisation

Avant de nous lancer dans la visualisation, il a fallu choisir le meilleur outil possible, capable non seulement de créer des visuels, mais aussi de faciliter la création de KPI pour les chercheurs.Nous avons analysé le besoin sous deux angles :

1. Quel est le meilleur outil pour créer des visuels ?
2. Quel est le meilleur outil qui puisse s’intégrer dans notre infrastructure ?

L’objectif était de pouvoir regrouper l’ensemble des fonctionnalités, pour qu’un futur déploiement sur un VPS ne repose que sur notre propre infrastructure, sans avoir à externaliser un service tiers. Nous avons comparé trois outils de visualisation : Power BI, Tableau et Metabase. Metabase est ressorti comme le choix le plus judicieux pour ce projet.

Pourquoi Metabase plutôt que Power BI ou Tableau

Metabase s’intègre naturellement dans notre stack Docker et ne nécessite aucune licence. C’est le choix le plus cohérent pour un MVP local et open source.

Architecture technique

Pipeline Airflow (horaire)
        ↓
SQL Server — GoodAirDW
        ↓
Metabase (connecté via JDBC)
        ↓
Dashboard accessible sur http://localhost:3001

Metabase tourne dans un conteneur Docker dédié, connecté au même réseau que SQL Server. Il utilise PostgreSQL (déjà présent pour Airflow) comme base de données interne, pour stocker ses configurations, questions et dashboards.

Configuration Docker

metabase:
  image: metabase/metabase:latest
  container_name: metabase
  hostname: metabase
  volumes:
    - /dev/urandom:/dev/random:ro
  ports:
    - "3001:3000"
  environment:
    MB_DB_TYPE: postgres
    MB_DB_DBNAME: metabase
    MB_DB_PORT: 5432
    MB_DB_USER: airflow
    MB_DB_PASS: airflow
    MB_DB_HOST: postgres
    MB_JAVA_OPTS: "-Xmx1g -Xms512m"
  depends_on:
    postgres:
      condition: service_healthy
  restart: always
  mem_limit: 2g

Points importants :

• /dev/urandom:/dev/random:ro pour éviter le blocage au démarrage lié à l’entropie Linux.
• MB_JAVA_OPTS: "-Xmx1g -Xms512m" : alloue jusqu’à 1 Go de heap Java (512 Mo au démarrage) pour éviter les OutOfMemoryError.
• mem_limit: 2g : limite la consommation mémoire du conteneur.
• Port 3001 choisi pour éviter les conflits avec les autres services de mon environnement Docker.

Connexion à SQL Server

Dans Metabase → Administration → Bases de données → Ajouter une base de données :

Dans l’interface d’administration de Metabase, la connexion à la base GoodAirDW s’est faite via le driver SQL Server (Port 1433, hôte sqlserver). L’avantage majeur de Metabase est qu’il détecte automatiquement les tables et les clés étrangères définies dans SQL Server. Les jointures entre FactMesures, DimLieux et DimTemps sont proposées nativement sans écrire une seule ligne de SQL.

Structure du dashboard

Le dashboard “Tableau de Bord de Surveillance : GoodAir” est organisé en deux onglets, avec deux filtres globaux dynamiques.

Filtres globaux

• Filtre Ville : liste déroulante permettant de sélectionner une ou plusieurs villes parmi les 11 surveillées. Les graphiques se mettent à jour automatiquement selon la sélection.
• Filtre Date : sélecteur de période permettant de filtrer par jour, semaine, mois ou plage personnalisée. Par défaut, aucune valeur fixe n’est appliquée : le dashboard affiche tout l’historique disponible.

Onglet 1 : Vue générale

KPIs: Vue générale

Ces 4 KPIs sont affichés en haut du dashboard pour donner une vue d’ensemble immédiate. Ils sont volontairement globaux et ne sont pas affectés par le filtre Ville, afin de conserver des chiffres de référence stables.

AQI moyen par ville. Graphique à barres verticales montrant l’indice de qualité de l’air moyen pour chaque ville sélectionnée. Paris apparaît systématiquement comme la ville la plus polluée (45.87), et Lyon comme la moins polluée (19.42), en raison de l’absence de capteurs PM25 et O3 sur sa station AQICN.

Évolution de l’AQI dans le temps. Courbe temporelle montrant l’évolution journalière de l’indice de qualité de l’air depuis le début de la collecte (mars 2026). Chaque ville sélectionnée a sa propre courbe colorée. On observe clairement des pics de pollution à Paris en juin, avec un maximum à 120 sur la courbe journalière.

Prédictions de l’AQI pour les 6 prochaines heures. Graphique montrant les prédictions générées par le modèle Random Forest pour chaque ville et chaque heure future. Ces données proviennent de la table Gold.AlertesPredites et sont mises à jour à chaque run horaire d’Airflow. Le graphique est filtré sur la journée courante, pour n’afficher que les prédictions pertinentes.

Évolution de la température. Courbe temporelle de la température moyenne journalière par ville. Une ligne d’objectif rouge à 40 °C matérialise le seuil de température extrême. On observe clairement la montée progressive des températures de mars à juillet 2026.

Onglet 2 : Analyse détaillée

KPIs: Analyse détaillée

La vitesse du vent est affichée sous forme de jauge, avec des zones colorées (rouge, orange, vert) pour une lecture immédiate. C’est un choix de visualisation plus parlant qu’un simple chiffre.

PM10, PM25 et O3 moyens par ville. Graphique à barres groupées montrant les trois polluants principaux côte à côte pour chaque ville. Cette visualisation permet de comparer facilement le profil de pollution de chaque ville. Paris a le PM25 le plus élevé ; Lyon a des valeurs très basses sur PM25 et O3, en raison de l’absence de capteurs.

Évolution de l’humidité. Courbe temporelle de l’humidité moyenne journalière par ville. L’humidité varie entre 30 % et 90 % selon les périodes, avec une tendance à la baisse en été, cohérente avec la montée des températures observée dans l’onglet 1.

Disponibilité des APIs. Deux graphiques à barres montrant le nombre de mesures avec statut OK vs FAILED pour MeteoStatus (API OpenWeatherMap) et AirStatus (API AQICN). Ces graphiques confirment la très haute fiabilité des deux APIs sur la période, avec moins de 0.1 % de pannes pour OpenWeatherMap et moins de 0.03 % pour AQICN.

Rafraîchissement des données

Metabase met les résultats en cache par défaut. Deux options de mise à jour sont disponibles :

• Rafraîchissement automatique : configuré à 1 heure, pour être synchronisé avec la fréquence du pipeline Airflow. Les données auront au maximum 1 heure de décalage.
• Rafraîchissement manuel : via l’icône de rafraîchissement en haut à droite du dashboard. Utile immédiatement après un run manuel d’Airflow.

Perspectives d’évolution

Onglet 3 : Performance du pipeline

Un troisième onglet dédié à la surveillance du pipeline lui-même, avec le nombre de runs réussis vs échoués par jour, le nombre de lignes insérées par run, les villes avec le plus de pannes API, et l’historique des alertes email déclenchées.

Onglet 4 : Analyse météorologique approfondie

Un onglet dédié aux variables météo, avec des corrélations entre vent, pression et qualité de l’air, une carte de chaleur de la température par ville et par mois, et des boxplots de distribution de chaque variable météo.

Onglet 5 : Qualité de l’air par polluant

Un onglet détaillé sur chaque polluant (PM25, PM10, NO2, O3), avec leur évolution dans le temps, leur répartition par ville et leur comparaison avec les seuils OMS (déjà disponibles dans la table Ref.SeuilsOMS du Data Warehouse).

Alertes en temps réel dans Metabase

Metabase permet de configurer des alertes email directement depuis un graphique. Si l’AQI prédit dépasse un seuil défini, Metabase peut envoyer une notification indépendamment du pipeline Airflow. Cela offre une double couche d’alerting.

Accès multi-utilisateurs

Créer des comptes distincts dans Metabase pour les chercheurs, les directeurs et les équipes BI, avec des droits d’accès différenciés : les chercheurs voient toutes les données, les directeurs voient uniquement les KPIs et les alertes.

Compétences mises en avant

• Sélection argumentée d’un outil de Business Intelligence à partir de critères objectifs (coût, licence, intégration infrastructure, courbe d’apprentissage).
• Déploiement et configuration d’un outil de BI (Metabase) en conteneur Docker, connecté à une base PostgreSQL interne et à un Data Warehouse SQL Server via JDBC.
• Exploitation d’un modèle en étoile (table de faits + dimensions) pour construire des dashboards et des KPIs.
• Conception de dashboards orientés utilisateur final (chercheurs), avec filtres globaux dynamiques (ville, période) et KPIs de référence volontairement stables.
• Intégration des sorties d’un modèle de Machine Learning (prédictions AQI) dans un outil de visualisation métier.
• Mise en place d’un double niveau d’alerting (technique via Airflow, métier via Metabase).

Récapitulatif des apprentissages

• Le choix d’un outil de BI ne se limite pas à ses capacités de visualisation : son intégration dans l’infrastructure existante (Docker, absence de licence, déploiement futur sur VPS) a été un critère aussi déterminant que la qualité des graphiques produits.
• Enchaîner la visualisation juste après le cas d’usage IA a permis de confronter directement les prédictions du modèle aux besoins de décision des chercheurs, plutôt que de traiter ces deux phases de façon cloisonnée.
• Séparer les KPIs de référence des graphiques filtrables est un choix de conception utile : cela évite de perdre les chiffres globaux de contexte lorsqu’un utilisateur filtre sur une ville en particulier.
• La détection automatique des relations entre tables (clés étrangères SQL Server reconnues par Metabase) simplifie fortement la création de visualisations sur un modèle en étoile, sans avoir à écrire de SQL pour chaque jointure.
• Documenter une roadmap d’onglets futurs (performance pipeline, météo approfondie, polluants) permet de garder trace des besoins identifiés mais non encore implémentés, pour prioriser les prochaines itérations du MVP.

Liens pertinents et ressources

• Dépôt GitHub du projet : code source complet, Docker Compose, scripts SQL et documentation.
• Images des résultats du projet : captures d’écran des tables SQL, des fichiers Parquet et des logs Airflow.
• Visualisation des données dans Metabase : présentation des dashboards et KPIs pour les chercheurs.
• Documentation Metabase