Backtest SMARD de 90 jours : uplift de revenus d'un dispatch par programmation dynamique, avec usure explicitement chiffrée

Les exploitants hydro et de STEP savent déjà qu'un prix élevé ne crée pas automatiquement une marge élevée. Une heure de turbine a un coût d'opportunité, une valeur d'eau et un coût de fatigue. Un planning qui court après chaque spread attrayant peut augmenter le revenu brut tout en consommant plus de budget de maintenance que ce que le revenu supplémentaire justifie.

C'est pourquoi cette étude de cas utilise le backtest de 90 jours comme test d'évidence et non comme slogan. La proposition de valeur consiste à augmenter le revenu par turbine tout en minimisant l'usure, mais la seule façon défendable de l'affirmer est de montrer revenus, valeur nette et comptabilité de la fatigue côte à côte. Le rapport le fait, y compris pour les résultats inconfortables.

La fenêtre de backtest court du 2024-10-01T00:00:00+00:00 au 2024-12-29T23:00:00+00:00 : 90 jours et 2 160 pas de dispatch horaires. La série de prix de dispatch est celle des prix day-ahead allemands DE-LU, chargée via le chemin de données live/cache de SMARD.de et enregistrée dans le rapport comme price_source smard_de_api.

Le rapport enregistre aussi les séries de prix CH et FR comme smard_de_api, avec 2 160 heures chacune. Les données d'apport et météo proviennent d'open_meteo pour le bassin de la grande_dixence. La baseline simulée est volontairement simple : faire tourner la turbine au meilleur rendement pendant les 8 heures de prix les plus élevées de chaque jour UTC et rester en veille sinon.

L'optimiseur principal du rapport est stochastic_dynamic_programming. Il utilise un horizon glissant de 8 heures, 2 scénarios de prix, 2 scénarios d'apport, une génération de scénarios par bootstrap et un modèle partagé de comptabilisation des coûts de fatigue maintenance_schedule avec damage_cost_per_unit_eur fixé à 60 000 €. La valeur terminale de l'eau est modélisée par un price_proxy sur une fenêtre de prix de 168 heures avec une hypothèse d'efficience de pompage-turbinage de 0,85.

Les dispatchs optimisé et baseline sont tous deux exécutés via damagedopt.backtesting.simulator.PlantSimulator, et le bloc de validation rapporte mass_balance_pass à true pour la run stochastique optimisée, la baseline et la run de comparaison déterministe. Le rapport inclut également un mode de comparaison deterministic_vs_stochastic, ce qui importe parce que le solveur DP déterministe a produit le signal d'uplift de revenus alors que la configuration stochastique ne l'a pas produit.

Dans la comparaison entre solveurs déterministes, le revenu du dispatch optimisé atteint 6 128 037,21 € contre 2 196 737,29 € pour la baseline. Soit un uplift de revenu brut de 3 931 299,92 €, ou +178,96 %, sur la même fenêtre SMARD de 90 jours et la même baseline « 8 heures de prix les plus élevées ».

La même comparaison déterministe rapporte une valeur nette totale de 5 393 005,36 €, une valeur nette ajustée de l'eau de 7 100 996,80 € et un uplift de valeur nette de 6 199 885,11 € (+688,03 %) face à la baseline. C'est le véritable point de preuve d'uplift de l'artefact : la programmation dynamique a trouvé sensiblement plus de valeur de marché qu'une règle naïve de dispatch aux 8 meilleures heures.

Le résultat principal du rapport est moins flatteur et il ne faut pas le cacher. La run stochastique optimisée a produit 1 820 080,39 € de revenus contre 2 196 737,29 € pour la baseline, soit un déficit de 376 656,90 € et un uplift de revenu brut de -17,15 %. Le rapport de tête affiche aussi -18,18 % d'uplift de valeur nette ajustée de l'eau.

La régularité journalière était faible : un uplift positif n'apparaît que 24 jours sur 90, soit 26,67 %. La ventilation mensuelle est négative en octobre, novembre et décembre, avec des uplifts de revenus de -187 541,71 €, -86 033,56 € et -103 081,63 € respectivement. Cela signifie que la configuration stochastique de cet artefact n'est pas encore une preuve de production de l'uplift.

Le backtest ne soutient pas de claim de réduction d'usure. Dans la comparaison déterministe, le coût d'usure total s'élève à 735 031,85 € et l'usure évitée à -728 223,58 € face à la baseline. Dans la run stochastique, le coût d'usure total est de 48 281,88 € contre 6 808,27 € pour la baseline, donc l'usure évitée est de -41 473,61 €. Une usure évitée négative signifie que la run optimisée a consommé plus de budget de fatigue modélisé, pas moins.

Cette réserve compte commercialement. Un optimiseur fondé sur le seul revenu peut paraître attrayant tout en déplaçant silencieusement le coût vers la maintenance, le risque d'indisponibilité ou la marge de fatigue. La contribution utile de DAMagedOpt ici n'est pas que ce rapport prouve une usure plus faible ; c'est que le rapport chiffre l'usure assez explicitement pour rejeter un claim non sûr. La prochaine cible d'optimisation n'est donc pas le revenu maximum, mais l'uplift ajusté de l'usure.

Il s'agit d'un replay de marché adossé à SMARD, pas d'un audit de trading en conditions réelles. Les prix day-ahead allemands DE-LU proviennent du chemin de données SMARD ; les contraintes d'offre propres à la centrale, l'exposition à l'écartement, les fenêtres d'indisponibilité réelles et les règles commerciales propres au site ne figurent pas dans le rapport publié. La source du hillchart est enregistrée comme estimée, si bien que des courbes de rendement et de fatigue calibrées sur la machine seraient nécessaires avant de considérer les chiffres absolus comme une garantie de fonctionnement.

Le résultat déterministe doit être lu comme un fort signal de potentiel, pas comme une politique de dispatch finale, parce qu'il a gagné sensiblement plus de revenu en acceptant sensiblement plus d'usure modélisée. Le résultat stochastique doit être lu comme un signal de réglage, parce qu'il a utilisé la configuration sensible à l'usure sans battre la baseline naïve. Ensemble, ces deux faits rendent l'étude de cas crédible : il y a une valeur de revenu mesurable, et le modèle d'usure empêche de la survendre.

Pour les exploitants hydro et les desks de trading d'énergie, la leçon est directe. La programmation dynamique peut identifier du revenu qu'une simple logique « heures de prix les plus élevées » manque, mais un planning ne mérite le déploiement que lorsque la valeur nette ajustée de l'usure s'améliore sous les contraintes propres à la centrale. C'est le standard que nous appliquons pour la tarification à l'uplift : mesurer la valeur incrémentale, puis soustraire le coût de fatigue de son obtention.

Si vous voulez tester la même logique sur un cas simplifié, commencez par la démo interactive. Pour comprendre comment DAMagedOpt aligne ses honoraires sur la performance mesurée plutôt que sur des licences logicielles fixes, consultez le modèle de tarification à l'uplift.