Sommaire

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

Références simples (points de comparaison)

Modèles à introduire dans les chapitres suivants