Vue d'ensemble
Le système fonctionne en boucle automatique toutes les 5 minutes en période de vigilance, sans intervention humaine. Il collecte les données publiques, effectue les calculs et diffuse les résultats en temps réel aux navigateurs connectés.
Workflow détaillé
1. Orchestration — n8n
n8n est un orchestrateur de workflows open source auto-hébergé. Un cron déclenche le pipeline toutes les 5 minutes en période de vigilance. Il exécute le script Python, puis publie une notification vers Mercure si le calcul réussit.
2. Collecte et calcul — Python
Un script Python interroge l'API Hub'Eau Hydrométrie (BRGM) pour récupérer les 48 dernières heures de mesures sur les 15 stations surveillées, puis l'API Open-Meteo pour les conditions météo actuelles et les prévisions horaires (météo, vent, précipitations). Il effectue ensuite :
- Normalisation des données (mm → m, tri chronologique)
- Contrôle qualité (complétude, fraîcheur)
- Calcul des tendances de hauteur d'eau par régression linéaire (numpy)
- Estimation des délais de propagation par corrélation croisée (numpy)
- Intégration des précipitations prévues (correction hausse et dégradation de confiance)
- Calcul des tendances météo et vent (détection du prochain changement significatif)
- Production des prévisions de hauteur d'eau à +1h, +2h, +3h et +6h
Le résultat est écrit dans un fichier JSON statique servi directement par le serveur web garantissant un accès rapide, léger et fiable aux données. Le traitement des données étant séparé de leur diffusion, l'application se veut la plus légère et réactive possible côté client. L'objectif est de maximiser l'expérience utilisateur.
3. Diffusion temps réel — Mercure
Mercure est un protocole et serveur de push open source basé sur Server-Sent Events (SSE). Quand de nouvelles données sont disponibles, n8n publie un événement sur un topic Mercure. Tous les navigateurs abonnés reçoivent instantanément la notification et rechargent les données.
Un mécanisme de polling de secours (60 secondes) prend le relais si la connexion SSE est interrompue.
4. Affichage — Frontend
L'interface est une page HTML statique avec du JavaScript vanilla.
Elle consomme le fichier JSON et dessine les cartes stations, les graphiques (Canvas 2D) et les indicateurs de tendance. L'utilisateur n'a jamais à recharger la page, les prévisions sont mises à jour en temps réel après chaque publication Mercure. Le design est responsive et accessible, avec une attention particulière à la lisibilité et à la clarté de l'information.
Stack technique
| Composant | Technologie | Rôle |
|---|---|---|
| Données hydrométriques | Hub'Eau API | Mesures de hauteur d'eau temps réel (BRGM) |
| Données météorologiques | Open-Meteo API | Conditions actuelles, prévisions horaires (météo, vent, précipitations) |
| Orchestration | n8n | Planification cron, enchaînement des étapes |
| Calcul | Python 3, numpy, requests | Collecte API, traitement statistique, sortie JSON |
| Push temps réel | Mercure (SSE) | Notification instantanée des navigateurs |
| Serveur web | Caddy | Serveur de fichiers statiques, reverse proxy, HTTPS automatique |
| Frontend | HTML, CSS, JS (vanilla) | Interface utilisateur, graphiques Canvas 2D |
| Analytique | Matomo | Statistiques anonymisées, sans cookies tiers |
| Hébergement | Serveur dédié | Auto-hébergé, Agen (47) |
Principes de conception
- Zéro dépendance frontend : pas de framework JavaScript, pas de build, pas de node_modules. Le code est directement lisible et modifiable.
- Données ouvertes : 100% des données sources proviennent d'API publiques gratuites (Hub'Eau, Open-Meteo).
- Auto-hébergement : l'ensemble de l'infrastructure (serveur, Mercure, n8n, Matomo) est hébergé sur mon propre home-serveur Ubuntu Server à Agen (47).
- Résilience : si une station ou un service est indisponible, le système continue avec les données restantes. Le polling de secours compense une perte de connexion SSE.
- Respect de la vie privée : analytique via Matomo auto-hébergé, données anonymisées, aucun cookie déposé dans le navigateur.