Data Battle IA PAU 2026 · Meteorage · AllClear

Fin d'alerte
d'une foudre
en temps réel.

Un modèle XGBoost calibré qui remplace la règle fixe des 30 minutes par une probabilité calculée éclair par éclair — sur 5 aéroports européens.

Voir la démo → Notre approche
0.966
AUC-ROC global
0.018
Brier Score
150h
gain de temps total
1.8%
risque R à θ=0.4

Le problème

30 minutes d'attente.
Chaque alerte.
Sans exception.

La règle actuelle impose un délai fixe après le dernier éclair détecté dans un rayon de 10 km. Elle ne tient compte ni de l'intensité de l'orage, ni de sa trajectoire, ni du temps déjà écoulé.

⏱

La règle des 30 minutes

Dès qu'un éclair est détecté à moins de 10 km, tout s'arrête sur la piste. Le compteur repart à zéro à chaque nouveau coup, indépendamment de la distance ou de l'intensité.

30 min
💸

Coût opérationnel

À l’échelle d’un aéroport, les retards peuvent représenter environ 2 000 € par minute lors des périodes de forte activité, en se basant sur un coût moyen de 80 à 100 € par minute et par avion (EUROCONTROL) et sur plusieurs vols retardés simultanément. Ces retards ont par ailleurs tendance à se propager en cascade dans l’ensemble du réseau aérien.

~ €2000/min
✈️

Impact environnemental

Chaque minute d'immobilisation au sol a un coût environnemental direct : un seul A320 en attente émet près de 400 kg de CO₂ par heure en mode APU, sans avancer d'un mètre — soit l'équivalent de plusieurs trajets Paris-Lyon en voiture.

400 kg CO2
🎯

Notre réponse

Produire une probabilité P(fin d'alerte) mise à jour à chaque éclair. Le seuil de déclenchement est un paramètre de risque ajustable par Meteorage — pas un hyperparamètre technique.

P(fin)

Approche technique

Pipeline complet
en 5 étapes.

1

Données & preprocessing

128 992 éclairs CG (Cloud-ground) sur 10 ans, 2 627 alertes, 5 aéroports. Les timestamps dupliqués (521 alertes concernées) sont résolus par un offset nanoseconde.

128 992 éclairs CG2 627 alertes10 ans5 aéroportsclé composite airport+id
2

Ingénierie des features : + 40 variables

Des fenêtres glissantes temporelles (5-10-15-30 min) capturent la dynamique de l'orage en temps réel. Le comptage dédié des éclairs à moins de 3 km traite séparément la zone de danger opérationnel.

rolling 5-10-15-30min<3 km MeteorageSuivi de l'amplitudeencodage cyclique
3

Pourquoi XGBoost ?

4 modèles sont comparés sur les mêmes données, et XGBoost domine sur tous les aéroports. Celui ci gère naturellement les déséquilibres de classes (2 627 positifs / 56 599 observations), supporte les valeurs manquantes, et demeure robuste aux features corrélées. La calibration est appliquée en post-processing.

XGBoost ✓HeuristiqueRégression logistique Random Forest
4

Pourquoi la calibration isotonique ?

XGBoost produit des scores discriminants mais pas nécessairement des probabilités calibrées. Sans calibration, une valeur de 0.8 ne correspond pas à 80% de chances réelles — ce qui rend le modèle inutilisable pour une décision opérationnelle. La calibration isotonique via CalibratedClassifierCV corrige cette déviation sans contrainte paramétrique.

# La calibration comme étape dédiée du pipeline
xgb_model = XGBClassifier(n_estimators=300, max_depth=6, ...)
calibrated = CalibratedClassifierCV(xgb_model, method='isotonic', cv=3)
calibrated.fit(X_train, y_train)
# Brier Score : 0.042 → 0.018 après calibration
Brier 0.042 → 0.018isotoniquecv=3
5

Validation sans fuite de données

Split par groupe d'alerte complet (GroupShuffleSplit). Aucun éclair d'une alerte de test n'apparaît en entraînement. La feature alert_progress (= 1.0 exactement au dernier éclair) a été identifiée et supprimée — c'était une fuite directe.

GroupShuffleSplittest_size=0.2alert_progress supprimée

Choix clés & justifications

Chaque décision a une raison technique précise.

Métrique principale
Brier Score plutôt qu'AUC
L'AUC mesure le classement, pas la fiabilité des probabilités. Pour une décision opérationnelle basée sur un seuil θ, la calibration est critique — un score de 0.7 doit correspondre à 70% de probabilité réelle. Le Brier Score pénalise les probabilités mal calibrées.
Fenêtres temporelles
Rolling sur index datetime
La boucle iterrows() initiale prenait plusieurs heures sur 128k éclairs. Le rolling pandas sur index datetime est entièrement vectorisé en C — le feature engineering passe en moins de 2 minutes.
Évaluation du risque
Protocole Meteorage : R = M³/N³
Le risque R mesure la fraction d'éclairs à moins de 3 km ratés après notre prédiction. À θ=0.4, R=0.018 < 0.02 — on rate moins de 2% des éclairs dangereux. Le seuil θ est le curseur risque/gain que Meteorage règle.
Format de prédiction
Une prédiction par éclair
À chaque éclair reçu, on émet une prédiction (date d'émission, date prédite de fin, score de confiance). Le jury sélectionne la première prédiction avec score ≥ θ. Ce format permet d'arbitrer entre réactivité et précision.

Démonstration live

Rejouer un orage réel.

Choisis un aéroport et une alerte. Regarde le modèle recalculer P(fin d'alerte) éclair par éclair, en conditions opérationnelles réelles.

Chargement des données…
Lance python predict.py puis place predictions.csv dans le même dossier.
P(fin d'alerte)
—
En attente de données…
Éclairs0
Écoulé0 min
Distance—
<3 km0

Résultats

Performances
sur 5 aéroports.

Évalués sur un test set d'alertes complètes jamais vues à l'entraînement (GroupShuffleSplit, 20%).

AUC-ROC global
0.966
Discrimination parfaite = 1.0. Mesuré sur alertes non vues à l'entraînement.
Brier Score
0.018
Calibration des probabilités. 0.0 = parfait. Après isotonic calibration.
Gain total
150h
Gain cumulé sur toutes les alertes d'entraînement à θ=0.4 vs baseline 30 min.
Risque R à θ=0.4
1.80%
Fraction d'éclairs <3km ratés. Seuil acceptable : R < 2% (protocole Meteorage).

Performances par aéroport

Aéroport AUC-ROC Brier Score Note
Ajaccio 0.9675 0.0226 ✓ Solide
Bastia 0.9792 0.0105 ✓ Meilleur
Biarritz 0.9385 0.0349 △ Orages courts
Nantes 0.9208 0.0303 △ Moins de données
Pise 0.9682 0.0151 ✓ Solide

Arbitrage Gain / Risque par seuil θ

Raccept = 0.02 (protocole Meteorage). Le seuil optimal maximise le gain sous contrainte de risque.

θ Gain (heures) Risque R Safe ?
0.30 259 0.0401 ❌
0.35 192 0.0260 ❌
0.40 150 0.0185 ✅
0.45 116 0.0180 ✅
0.5 94 0.0035 ✅
0.60 75 0.0030 ✅
0.70 62 0.0030 ✅

Courbe ROC — par aéroport

ROC

Calibration des probabilités

Calibration

Distribution des probabilités prédites

Distribution

Arbitrage couverture / sécurité

Coverage

Risque de faux négatifs selon le seuil

FN

Responsabilité

Au-delà
de la performance.

Un bon modèle ne suffit pas. Il faut anticiper ses effets secondaires et les responsabilités qu'il crée.

Effet rebond

Empreinte carbone des inférences

Un modèle en production émet une prédiction à chaque éclair, en continu, sur 5 aéroports. Les inférences répétées sur serveur génèrent une consommation énergétique non négligeable. Ce coût carbone doit être mis en balance avec les gains opérationnels — et justifie de privilégier un modèle léger et efficace comme XGBoost plutôt qu'un réseau de neurones profond.

Risque critique

Sécurité des agents de piste

Un faux négatif — prédire la fin trop tôt — expose directement les équipes au sol à un risque physique. Le seuil θ est une décision de responsabilité appartenant à Meteorage, pas un hyperparamètre technique.

Innovation opérationnelle

Zone 3 km : priorité Meteorage

Suite à la discussion avec Stéphane Schmidtz (Meteorage), le modèle intègre des features dédiées aux éclairs à moins de 3 km — nettement plus dangereux pour les équipes. Ces features reçoivent un traitement séparé dans le pipeline de features.

Transparence

Probabilités calibrées & auditables

Les probabilités sont calibrées isotoniquement — 80% correspond à 80% de fins d'alerte réelles. Le Brier Score valide cette calibration. Le modèle produit des valeurs interprétables, pas un score opaque.