boncourant

Moteur de valorisation des offres — gros consommateurs


Module : negotiated-structure/offer-pricing — spec-2bis#18

Version : 1.0.0


---


Ce que fait ce module


Ce module est le cœur de la recommandation tarifaire pour les gros consommateurs (C4/C3/C2). Il prend la courbe de consommation nette réelle (charge − production) et la valorise sous chaque archétype d'offre du marché français, pour produire un coût global en €/MWh et en €/an, accompagné d'une vue du risque.


En entrée :

  • La courbe nette demi-horaire (17 520 ou 17 568 points selon l'année).
  • Un archétype d'offre typé (voir taxonomy spec-2bis#17).
  • Un snapshot de marché : prix EEX CAL Y+1, strip forward complet, prix de capacité RTE.
  • En option : TURPE annuel, obligation de capacité (kW), cours EMMY (CEE), prime GO.

  • En sortie (PricedOffer) :

  • all_in_eur_mwh — coût tout compris (énergie + réseau + taxes) en €/MWh.
  • total_eur_year — coût annuel total en €, ou null si les données sont insuffisantes.
  • component_breakdown — décomposition par poste (énergie, TURPE, accise, CSPE, GO, TVA…).
  • risk_framing — position de couverture, ratio de couverture, bande d'exposition (p05/p50/p95).
  • data_quality"real" / "modelled" / "unavailable".
  • rationale — une phrase en français expliquant le moteur de prix.

  • ---


    La règle du refus de fabrication


    Ce module ne fabrique jamais un nombre. Si une entrée de marché réellement nécessaire au calcul de l'énergie est absente (et qu'aucun proxy déclaré n't est disponible), le module retourne data_quality: "unavailable" et total_eur_year: null. La décomposition des composants est vide pour la partie énergie. Le champ missing_inputs liste les identifiants de flux manquants.


    ---


    La pile de coûts hors énergie


    La même pile hors énergie s'applique à tous les archétypes. Elle est calculée une seule fois et importée depuis reference-price (spec-1c#5, spec-2bis#5, spec-2bis#18) :


    | Composant | Valeur de référence | Source |

    |-----------|-------------------|--------|

    | Déséquilibre / coût EnR | 3,5 €/MWh | Benchmark sectoriel Phase-1b |

    | Obligation de capacité | Variable (RTE) | Enchère RTE €/kW/an × puissance de pointe |

    | CEE (pass-through) | Variable (EMMY) | 0,02 CEE/MWh × cours EMMY cumac |

    | TURPE 7 HTA | Variable | €/an ÷ MWh/an (calculé spec-1c#6) |

    | Accise électricité C4 | 26,58 €/MWh | Taux au 1er février 2026 |

    | CSPE | 22,5 €/MWh | Contribution au Service Public |

    | Prime GO | Variable | Powernext (si électricité verte demandée) |

    | Frais fixes | 2,0 €/MWh | Benchmark sectoriel |

    | TVA 20 % | Sur TURPE + accise + CSPE + GO | Taux légal |


    ---


    Valorisation de la partie énergie par archétype


    Offres consommation


    fixe — Le prix contractuel fixe fixed_eur_mwh est directement utilisé. Aucune donnée de marché requise pour la partie énergie. data_quality: "real".


    calendaire_indexe — L'énergie est indexée sur le future CAL Y+1 (ou Y+2) d'EEX, plus le spread fournisseur. Requiert le prix baseload du strip forward. data_quality: "real" si le strip est présent.


    bloc_calendaire — Combinaison d'un volume baseload (CAL Y+1) et de blocs produits saisonniers ou peak. Le prix peakload CAL Y+1 est utilisé pour les blocs ; si absent, le baseload sert de proxy et data_quality passe à "modelled".


    spot_indexe — Préparer une offre indexée spot ne nécessite pas le prix spot : le forward CAL Y+1 est l'espérance risque-neutre du spot moyen, donc le module price sur l'ancre forward (M+1 → CAL Y+1) + une bande de risque de volatilité. data_quality: "modelled" (prévisionnel déclaré, jamais "unavailable"). La phrase de rationale signale explicitement l'ancrage forward. Le prix spot J-1 réel (ENTSO-E) ne sert qu'au backtesting (« ce que vous auriez payé »).


    spot_plus_future — Mélange d'une fraction spot (proxy M+1) et d'une fraction hedgée (CAL). data_quality: "modelled" (proxy spot).


    cliquetable — Base CAL Y+1, avec une décote approximée de la valeur de l'option de fixing (1 % × part fixable). C'est une approximation conservatrice de la valeur réelle des fenêtres de cliquet. data_quality: "modelled".


    mix — Portefeuille pondéré d'archétypes. Chaque jambe est valorisée indépendamment ; la qualité globale est celle de la jambe la moins bonne. Les pondérations doivent sommer à 1,0 (validation).


    Offres production


    ppa_fixe — Les kWh exportés sont valorisés au prix PPA contractuel. data_quality: "real".


    ppa_indexe — Prix CAL à l'horizon choisi, moins la décote PPA. data_quality: "real".


    oa_complement_remuneration — Prix de référence CRE (arrêté applicable), complément = référence − spot mensuel (proxy M+1). data_quality: "modelled".


    autoconsommation_avec_surplus — Surplus injecté (fraction × MWh/an) valorisé au CAL Y+1. data_quality: "modelled".


    Offre stockage


    battery_arbitrage — Valeur estimée via le spread peakload/baseload CAL Y+1 (proxy du spread intraday réel, lequel nécessite ENTSO-E). Calcul : spread × rendement aller-retour × capacité MWh × cycles/jour × 365 jours. data_quality: "modelled".


    Cas spécial


    arenh_residuel — Le mécanisme successeur de l'ARENH est en attente de publication CRE. data_quality: "unavailable", total_eur_year: null. Aucun nombre ne peut être produit tant que la CRE n'a pas publié le cadre définitif.


    ---


    La vue du risque


    Pour chaque offre, le module dérive la position de couverture implicite (part fixe / CAL / spot) à partir des paramètres de l'archétype, puis appelle :

  • computeLockVsFloat (spec-2bis#9) — analyse 3 scénarios (central / hausse ±15 % / baisse ±15 %).
  • computeExposure (spec-2bis#11) — bande p05/p50/p95, delta worst-case, label faible/modéré/élevé.

  • Si le strip forward est absent ou ne contient pas de point CAL Y+1, la bande d'exposition est null (dégradation gracieuse, pas d'erreur).


    ---


    Ce module ne fait pas


  • Il ne re-calcule pas TURPE ou la capacité (délégués aux modules dédiés).
  • Il ne compare pas les offres entre elles (c'est le rôle de spec-2bis#19 — 3 alternatives).
  • Il ne génère pas les courbes (spec-2bis#1–4), ni le strip forward (spec-2bis#8).
  • Il ne consomme pas de données résidentielles (lib/simulator/ — hors périmètre).