Reformulations

docs/08 - Cadre prédictif local/index.md

@@ -1,40 +1,70 @@
 # Cadre prédictif local
 
-Objectif : poser les bases d’un modèle sur-mesure qui prédit, au pas local de la station, 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 ou échoue, non pas à atteindre une performance commerciale.
-Il ne s'agit pas ici de venir concurrencer Météo France, mais de jouer avec nos données et avec l'IA.
+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
 
-- Température (continue) ; Vitesse du vent (continue) ; Précipitations binaires (pluie ou neige oui/non). Éventuellement : événements extrêmes (forte chaleur/froid, risque d’orage) vus comme des seuils.
-- Horizons évalués : T+10, T+60, T+360 (~6 h), T+1440 (~24 h) minutes pour voir quand notre modèle montrera ses faiblesses.
+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
 
-- Température / vent : _MAE_ (_Mean Absolute Error_) = moyenne des écarts en valeur absolue, facile à lire en °C ou km/h ; _RMSE_ (_Root Mean Squared Error_) pénalise davantage les grosses erreurs pour mieux voir les limites du modèle lorsque des écarts importants apparaissent.
-- Précipitations binaires : précision (part des annonces de pluie qui étaient justes), rappel (part des pluies réellement captées), _F1_ (compromis précision/rappel), _Brier score_ (qualité des probabilités, plus il est bas mieux c’est) et _calibration_ des probabilités (est-ce qu’un 30 % de pluie signifie vraiment ~30 % des cas).
-- Événements extrêmes : même logique précision/rappel sur dépassement de seuils (chaleur/froid/rafale), avec suivi des fausses alertes pour rester prudent.
+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](https://fr.wikipedia.org/wiki/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_](https://fr.wikipedia.org/wiki/F-mesure) (compromis entre précision et rappel), et [_Brier score_](https://en.wikipedia.org/wiki/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
 
-- Pas d’hiver complet dans le jeu actuel (mars→novembre) : les régimes froids et la neige sont absents.
-- Aucune info synoptique (pression régionale, nébulosité, vent en altitude) : le modèle reste “aveugle” au contexte large.
-- Pluie rare (~4 % des pas), donc classes déséquilibrées pour la partie pluie/orage.
-- Pas brut à 10 minutes : bon pour réactivité courte, mais bruité ; on testera aussi des features lissées.
+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
 
-- Source principale : `data/weather_minutely.csv` (pas 10 min), enrichissable au fil du temps. On peut réutiliser les CSV dérivés des chapitres précédents (matrices de lags/corrélations du chapitre 5, notamment) pour guider les lags utiles ou vérifier la cohérence.
-- Découpe temporelle sans fuite : partie _train_ (début→~70 %), partie validation (~15 % suivant), partie test finale (~15 % le plus récent). Variante : _time-series split_ “en rouleau”, où l’on répète ce découpage plusieurs fois ; on appelle _fold_ chaque paire (train, validation) ainsi construite.
-- Normalisation/standardisation : 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 d’introduire, par mégarde, des informations issues du futur dans les étapes de préparation des données.
+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.
 
-## Variables dérivées de base (simples et explicables)
+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 : (u, v) = (speed _ *sin*(direction), speed _ _cos_(direction)) pour représenter la direction sans discontinuité 0/360°.
-- Drapeaux d’événements : pluie*en_cours (rain_rate > 0), vent_fort (seuil), chaleur/froid (seuils). Peuvent servir de \_features* et de cibles dérivées.
+- 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)
 
@@ -45,8 +75,8 @@ Il ne s'agit pas ici de venir concurrencer Météo France, mais de jouer avec no
 
 ## 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 _boosting_ légers pour capturer des relations non linéaires sans rendre le modèle complètement opaque.
+- Modèles linéaires avec régularisation ([_Ridge_](https://en.wikipedia.org/wiki/Ridge_regression)/[_Lasso_](<https://en.wikipedia.org/wiki/Lasso_(statistics)>)) 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](https://fr.wikipedia.org/wiki/R%C3%A9gression_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_](https://fr.wikipedia.org/wiki/For%C3%AAt_al%C3%A9atoire) ou [_gradient boosting_](https://fr.wikipedia.org/wiki/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.