Cadre prédictif local

Dans ce chapitre, on quitte le terrain purement descriptif pour tenter quelque chose de plus ambitieux : faire parler la station météo comme un petit modèle de prévision maison. L’idée est de construire un cadre simple, mais honnête, qui prédise au pas local la température, la pluie et le vent à plusieurs horizons (T+10 min, +60 min, +6 h, +24 h). On garde une approche expérimentale : on cherche à comprendre ce qui fonctionne, ce qui casse, et pourquoi, et non pas à rivaliser avec les services de prévision nationaux. Il s’agit avant tout de jouer avec nos données et avec l’IA, en gardant les pieds sur terre.

Cibles et horizons

Concrètement, on veut prédire trois types de grandeurs.

D’abord des valeurs continues comme la température et la vitesse du vent, pour lesquelles on attend des erreurs exprimées en °C ou en km/h. Ensuite une variable binaire « pluie oui/non », qui condense les précipitations en un simple événement : y a‑t‑il eu pluie (ou neige fondue) sur le pas considéré, oui ou non ? On pourrait prolonger ce cadre vers des événements extrêmes (forte chaleur, coup de froid, rafales, risque d’orage) en posant des seuils, mais on reste ici sur ces cibles de base.

Ces cibles sont évaluées à plusieurs horizons pour voir à partir de quand la prévision décroche : T+10 minutes pour le très court terme, T+60 minutes pour l’heure qui vient, T+360 minutes (~6 h) pour la demi‑journée et T+1440 minutes (~24 h) pour l’échéance journalière. On ne s’attend pas à ce que le modèle soit bon partout ; justement, comparer les horizons permettra de voir où il commence à perdre pied.

Métriques

Pour juger ces prévisions, on a besoin d’une grille de lecture commune. Sur la température et le vent, on utilise deux erreurs classiques : la MAE (Mean Absolute Error), qui est en gros la moyenne des écarts en valeur absolue, et la RMSE (Root Mean Squared Error), qui pénalise davantage les grosses erreurs (voir par exemple l’article sur l’erreur quadratique moyenne).

La MAE se lit directement en unités physiques (°C, km/h) et donne une intuition simple : « en moyenne, je me trompe de 0,7 °C ». La RMSE, elle, sert surtout à mettre en avant les scénarios dans lesquels le modèle déraille.

Pour la pluie binaire, on revient aux métriques de classification : précision (proportion des annonces de pluie qui étaient correctes), rappel (part des pluies réellement captées), F1 (compromis entre précision et rappel), et Brier score (qualité des probabilités, plus il est bas mieux c’est). On s’intéresse aussi à la calibration : lorsqu’on annonce 30 % de pluie, est‑ce qu’il pleut effectivement dans ~30 % des cas ? Un modèle mal calibré « sur‑réagit » ou se montre trop timide, même si son F1 est correct.

Pour des événements extrêmes éventuels (rafale, forte chaleur, etc.), on resterait sur la même logique précision/rappel, mais avec un focus particulier sur les fausses alertes : il vaut mieux ne pas déclencher une alerte dès que le modèle a un doute, surtout si l’utilisateur est un simple particulier.

Limites à garder en tête

Avant de lancer des modèles, il faut aussi être clair sur ce qu’ils ne pourront pas faire.

Notre jeu de données ne couvre que mars à novembre : toute la saison froide manque, avec la neige, les pluies froides et les régimes hivernaux typiques.

La station ne voit que son environnement immédiat : elle n’a aucune information sur la situation synoptique (pression régionale, nébulosité large, vent en altitude), ce qui la laisse quasiment aveugle au contexte qui pilote la météo à grande échelle.

La pluie est rare (~4 % des pas de temps), ce qui crée un fort déséquilibre de classes pour la partie pluie/orage.

Enfin, le pas brut de 10 minutes est pratique pour la réactivité, mais assez bruité : il faudra tester des variables un peu lissées pour ne pas nourrir les modèles avec du « bruit blanc ».

Ces contraintes ne rendent pas l’exercice inutile ; elles fixent simplement la barre de ce que l’on peut raisonnablement espérer. Tout gain devra se lire à l’aune de ces limites.

Données et découpes

Le terrain de jeu reste le même : data/weather_minutely.csv, le dataset minuté du chapitre 2, mis à jour au fil du temps. On peut y rattacher les CSV dérivés des chapitres précédents (matrices de lags et de corrélations décalées du chapitre 5, notamment) pour guider les choix de variables et vérifier que les signaux utilisés restent cohérents.

Pour évaluer un modèle, on découpe cette série temporelle en trois morceaux successifs : une partie train qui couvre environ les 70 % premiers points, une partie validation (~15 % suivant) qui sert à choisir les hyperparamètres sans toucher au test, et enfin une partie test (~15 % les plus récents) qui joue le rôle de futur inconnu.

Tout est gardé dans l’ordre chronologique pour éviter d’utiliser des informations à rebours. Une variante plus robuste consiste à utiliser un time-series split « en rouleau » : on répète plusieurs fois ce découpage en faisant glisser la fenêtre d’apprentissage/validation dans le temps, chaque couple (train, validation) formant alors un fold.

La normalisation (ou standardisation) se fait, elle aussi, de façon prudente : on calcule les paramètres (par exemple moyenne et écart‑type) uniquement sur la partie train, puis on applique ces mêmes paramètres à la validation et au test. Cela évite de « voir le futur » lors de la préparation des données, ce qui fausserait immédiatement l’évaluation.

Variables dérivées de base

Temps (sin/cos) : l’heure et le jour de l’année sont périodiques ; représenter l’heure avec sin/cos évite un faux saut entre 23h et 0h ou entre 31 déc et 1er jan. On encode ainsi heure/minute sur 24 h et jour de l’année sur 365 j.
Lags courts : valeurs à T-10, -20, -30 min pour chaque variable cible ; deltas (T0 − T-10) pour décrire la tendance récente (la “pente”) : est‑ce que la température, le vent ou la pression augmentent ou diminuent, et à quelle vitesse. Les lags analysés au chapitre 5 serviront d’inspiration.
Moyennes glissantes : moyenne ou médiane sur 30–60 min pour lisser le bruit ; cumul de pluie sur 30–60 min pour connaître l’état “humide” récent.
Composantes vent : on projette la vitesse et la direction du vent en deux composantes cartésiennes (u, v) avec u = speed * sin(direction) et v = speed * cos(direction). Cela permet de représenter la direction sans discontinuité artificielle entre 0° et 360° (un vent de 359° reste ainsi très proche d’un vent de 1°).
Drapeaux d’événements : créer des variables booléennes comme pluie_en_cours (quand rain_rate > 0), vent_fort (au‑delà d’un certain seuil) ou chaleur/froid (au‑delà/en‑deçà de seuils de température). Ces indicateurs peuvent servir de features supplémentaires pour les modèles, mais aussi de cibles dérivées lorsque l’on s’intéresse à des événements plutôt qu’à des valeurs exactes.

Références simples (points de comparaison)

Persistance : prédire que la valeur reste identique à T0 (par horizon).
Climatologie horaire : moyenne/quantiles par heure locale (et éventuellement par saison) pour température/vent ; fréquence de pluie par heure pour la pluie.
Moyenne mobile : prolonger la moyenne des 30–60 dernières minutes comme prédiction à court terme.
Pluie rare : classifieur “toujours sec” comme référence minimale. Si un modèle ne fait pas mieux, il est probablement inutile.

Modèles à introduire dans les chapitres suivants

Modèles linéaires avec régularisation (Ridge/Lasso) pour températures/vents : même formule que la régression linéaire classique, mais avec un terme supplémentaire qui limite l’ampleur des coefficients pour réduire le sur‑apprentissage (Ridge pénalise surtout les coefficients trop grands, Lasso peut en forcer certains à zéro).
Régression logistique pour la pluie : produit une probabilité de pluie plutôt qu’un oui/non brut, ce qui permet ensuite de choisir un seuil de décision adapté à l’usage (plutôt prudent ou plutôt conservateur).
Si besoin de courbes plus flexibles : arbres peu profonds, random forest ou gradient boosting légers pour capturer des relations non linéaires sans rendre le modèle complètement opaque .
Évaluation multi-horizons avec time-series split, courbes d’erreur en fonction de l’horizon pour voir à partir de quand le modèle décroche.
Pipeline d’inférence local (pipeline de prédiction) : charger le dernier point, générer les variables dérivées, prédire T+10/+60/+360/+1440, journaliser l’erreur au fil du temps pour suivre la qualité du modèle.

9.2 KiB Raw Blame History Unescape Escape