Aller au contenu principal

KiloDelta v1.23.0 : le module météo bascule sur Météo‑France

Exit Open‑Meteo : passage aux stations DPClim, au modèle AROME et au radar national. Retour sur un chantier technique d'envergure, de la chaîne IFM au proxy pivot.

6 min de lecture
Par Nuno CastroSapeur-pompier · Fondateur de KiloDelta

Avec la version 1.23.0, KiloDelta abandonne Open-Meteo au profit des flux officiels de Météo-France. Modèle AROME, réseau DPClim, prévision immédiate par radar et calcul d'IFM réaligné : voilà ce qui change sous le capot et sur le terrain pour les chefs d'agrès et les COS.

Pourquoi lâcher Open‑Meteo ?

Open-Meteo a fait le job. C'est une excellente source open source basée sur ERA5 et des modèles de qualité : gratuit, sans clé d'API à gérer, idéal pour prototyper vite. Problème : même si Open-Meteo exploite certaines données de Météo-France, la source officielle reste Météo-France. Et surtout, je commençais à atteindre les limites du modèle gratuit lors du calcul des IFM, ce qui pouvait partiellement bloquer la simulation.

J'ai donc tranché pour deux raisons pragmatiques :

  • Parler la même langue que la doctrine. Pour être utile, l'application doit coller au référentiel opérationnel.
  • Maîtriser la chaîne de donnée. S'appuyer sur des intermédiaires tiers ajoute une couche de vulnérabilité. Météo-France ouvrant ses API publiques, autant piocher directement à la source.

La v1.23.0 concrétise cette bascule. Si le service national venait à tousser, l'application retombe automatiquement sur Open-Meteo en secours.

Impact visuel et fonctionnalités

Concrètement, l'onglet Météo évolue sans alourdir la prise en main :

  • Indice de danger IFM : consultation nationale avec bascule instantanée Aujourd'hui / Demain.
  • Couche vent : plaquage direct des données du modèle AROME.
  • Radar de pluie animé : boucle fluide incluant 2 heures d'historique, le temps réel et une projection à court terme des cellules orageuses.
  • Réseau de stations temps réel : remontée de la température, de l'hygrométrie, du vent. La densité des pastilles s'adapte au niveau de zoom.

L'objectif reste inchangé : fournir une aide à la décision réactive, pas remplacer la réglementation.

L'IFM décortiqué : la mécanique du FWI

Pour comprendre l'enjeu technique, un rappel s'impose. L'IFM français dérive du Fire Weather Index canadien (Van Wagner). Il ne s'agit pas d'un relevé instantané, mais d'une chaîne de six indices cumulatifs qui gardent la mémoire du climat :

  • ICL (combustibles fins) : réagit à l'échelle de quelques heures.
  • IH (humus) : intègre le stockage d'humidité sur plusieurs jours à plusieurs semaines.
  • IS (sécheresse profonde) : mémoire longue, de plusieurs semaines à plusieurs mois.
  • IPI (propagation) : croisement de l'ICL et du vent instantané.
  • ICD (combustible disponible) : synthèse de l'IH et de l'IS.
  • IFM : la note finale.

Puisque l'IH et l'IS accumulent les historiques, impossible d'extraire une valeur isolée le 15 juillet sans avoir rejoué la météo jour par jour depuis le 1er mars.

Pour la partie mathématique, le moteur s'appuie sur la formulation canonique Van Wagner‑Pickett (1985, FTR‑33). Ce code tourne dans une conteneur (kd_sim_core) pour garantir une stricte parité de résultat entre le serveur central et le smartphone.

Architecture : worker, pivot et gestion du token

Fixer les équations était la partie la plus simple. Le vrai travail a consisté à intégrer Météo-France sans exposer de secrets et sans paralyser l'application mobile. Le système repose sur trois briques.

1. Le worker backend

Un daemon Python traite les flux en continu sur le serveur :

  • Récupération quotidienne des observations sur le réseau de stations DPClim.
  • Calcul et mise à jour de la chaîne FWI cumulée depuis le 1er mars pour chaque point du réseau, avec stockage SQLite.
  • Ingestion du modèle AROME (~1,3 km de résolution) pour projeter la prévision à J+1 dans une table distincte.
  • Génération des cartes thermiques et des surimpressions PNG (IFM, vent).

Les traitements lourds restent sur l'infrastructure. Le téléphone ne fait que recevoir du prêt à l'affichage.

2. Le proxy pivot

L'application interroge un proxy pivot. Ce pivot distribue les données, gère la mise en cache et orchestre la bascule vers Open-Meteo si Météo-France ne répond plus.

3. L'application mobile

Le client mobile sollicite le pivot pour obtenir les indices précalculés en une poignée de millisecondes. La chaîne FWI locale n'est conservée qu'à titre de secours hors-ligne, ce qui évite de charger le processeur du téléphone lors des simulations de propagation.

Alignement sur l'échelle EFFIS

Les seuils historiques de KiloDelta laissaient à désirer. Ils ont été réalignés sur le standard européen EFFIS / Copernicus, identique à celui de Météo-France : 11,2 / 21,3 / 38 / 50 / 70.

L'échelle s'articule ainsi en six paliers : Faible, Léger, Modéré, Sévère, Très sévère et Exceptionnel.

Benchmarks et cohérence des résultats

Lancer des calculs sur des données officielles est une chose ; s'assurer d'obtenir des résultats identiques aux bulletins zone Sud en est une autre. Plusieurs jeux de données réels ont été comparés.

Bilan des vérifications :

  • IS, IPI et réserve hydrique : correspondance exacte.
  • Niveau IFM global : écart maximal constaté de ±1 classe, conservant la même cohérence opérationnelle (ex. 49 calculé vs 43 affiché Météo-France, tous deux classés Très élevé).
  • IH (humus) : le point le plus délicat. L'indice IH de Météo-France s'écarte légèrement du DMC théorique, affichant une forte sensibilité aux micro-pluies.

Implémentation du radar et du nowcast

Le flux DPRadar exploite la mosaïque LAME_D_EAU (résolution de 500 m, format HDF5 ODIM).

Le worker exécute les opérations suivantes toutes les 5 minutes :

  1. Parsing du fichier HDF5.
  2. Reprojection cartographique de la grille vers EPSG:4326 (WGS84).
  3. Colorisation PNG et injection dans un tampon circulaire (ring buffer) sur une fenêtre de 2 heures.
  4. Génération d'un manifeste pour l'animation côté client.

Pour projeter le mouvement des pluies, le système intègre la prévision immédiate AROME-PI. Le modèle fournissant des cumuls sur des durées variables (15 min, 30 min, 1 h), le backend applique une différenciation des volumes successifs pour normaliser le rendu sur une cadence de 5 minutes. La transition entre le passé mesuré et le futur proche (jusqu'à +3 h) se fait sans saut visuel.

Module ROD : mise à jour de la maille DFCI

Le module de Risque Opérationnel Départemental (ROD) exploite ces mêmes données. Partageant le conteneur du worker météo, il lit directement les valeurs FWI calculées.

Le ROD fonctionne en mode hybride :

  • Aujourd'hui et J+1 : données réelles DPClim et prévisions AROME.
  • J+2 et J+3 : relais pris par Open-Meteo pour maintenir une visibilité à 3 jours, AROME s'arrêtant à 36 heures.

Si les flux principaux venaient à échouer, le système repasse intégralement sur Open-Meteo.

Optimisations mémoire et comportement hors-ligne

L'ajout de ces couches cartographiques imposait une révision des performances, notamment pour corriger des plantages (ANR) constatés sur certains terminaux sous Android 16.

Plusieurs chantiers d'optimisation ont été menés :

  • Mémoïsation des stations : recalcul des marqueurs uniquement en cas de déplacement ou changement de zoom effectif.
  • Isolation du parsing : le décodage JSON des flux nationaux est déporté dans un thread secondaire (isolate).
  • Gestion dynamique de la RAM : réduction automatique du tampon radar et de la mémoire cache sur les téléphones plus anciens.
  • Purge mémoire : libération systématique des ressources image hors champ.

Côté mode dégradé, le cache des cartes est désormais borné en taille et en durée. Les données des points d'eau ont été déplacées vers des fichiers locaux dédiés, et un témoin d'état indique clairement à l'utilisateur s'il fonctionne sur ses bases embarquées.

Limites du système

Pour maintenir une transparence totale sur les capacités de la v1.23.0 :

  • Il s'agit d'un outil d'aide à la décision, sans valeur réglementaire.
  • Les valeurs d'IFM résultent du calcul interne basé sur les données Météo-France.
  • La directionalité du vent au niveau des stations reste partiellement exploitée sur l'IHM météo, la couche globale restant portée par le modèle AROME.

En résumé

Cette version 1.23.0 constitue une refonte majeure de l'infrastructure météo de KiloDelta. Ingestion DPClim, intégration d'AROME, traitement des données HDF5 radar, architecture à serveur pivot et réalignement des échelles : l'ensemble est conçu pour fournir des données fiables, rapides et utilisables sans réseau.

Questions

Questions fréquentes

D'où viennent les données météo affichées dans KiloDelta ?
Les observations du jour proviennent du réseau de stations DPClim de Météo-France, tandis que les prévisions à J+1 s'appuient sur le modèle AROME. L'imagerie radar combine le flux LAME_D_EAU et le modèle de prévision immédiate AROME-PI.
L'IFM présenté est-il le chiffre officiel de Météo-France ?
L'indice est recalculé localement selon la méthode FWI Van Wagner-Pickett à partir des relevés Météo-France. Il produit des niveaux de danger équivalents aux bulletins officiels.
Quel est le comportement de l'application en cas de panne de Météo-France ?
Un basculement transparent vers les API d'Open-Meteo assure la continuité de service sans intervention de l'utilisateur.
KiloDelta remplace-t-il les bulletins de danger de la chaîne de commandement ?
Non. L'application reste un outil de simulation et d'aide à la décision. Elle ne se substitue pas aux publications réglementaires ni aux ordres de conduite.
Cet article t'a servi ? Fais-le tourner.
LinkedIn X (Twitter) Facebook E-mail
Météo-FranceIFMFWIAROMEradararchitecturev1.23
Nuno Castro Sapeur-pompier · Fondateur de KiloDelta

Réagir, corriger, proposer un retex ? Écris-moi à nuno.castro@kilodelta.fr ou via le formulaire de support. Les nouveaux articles arrivent aussi par le flux RSS.

Télécharger ou mettre à jour KiloDelta. Gratuit pour tous les sapeurs-pompiers, sur iOS et Android.