La prévision de charge énergétique estime la quantité d'électricité qu'un bâtiment, une usine ou un site consommera au cours des prochaines heures ou des prochains jours. Avec des compteurs IoT qui diffusent leurs relevés via MQTT, vous pouvez construire une prévision à partir de vos propres données plutôt que de vous fier aux factures mensuelles. Ce cas d'usage décrit le chemin des données du compteur jusqu'au modèle, les variables qui comptent pour la demande, un script fonctionnel de prévision J+1 et la manière de publier le résultat pour piloter l'écrêtement des pointes et la planification.
Pourquoi prévoir la charge énergétique
Une prévision de charge répond à des questions concrètes que les responsables d'exploitation et de production se posent chaque jour :
- Gestion de la puissance de pointe. De nombreux tarifs incluent des frais de puissance basés sur l'intervalle le plus élevé du mois. Savoir à l'avance que demain après-midi frôlera la limite permet de décaler les charges flexibles.
- Planification des charges flexibles. Les procédés par lots, la recharge des véhicules électriques, le pré-refroidissement et la production d'eau chaude peuvent être déplacés vers des heures où la demande ou les prix sont plus bas.
- Achats et autoconsommation. Les sites équipés de panneaux solaires, de batteries ou de contrats à tarification horaire ont besoin d'une prévision de la demande pour décider quand charger, décharger ou acheter.
- Détection d'anomalies. Un écart important et persistant entre la charge prévue et la charge réelle signale souvent un équipement resté allumé, un compresseur défaillant ou un défaut de comptage.
L'horizon de prévision dépend de la décision : les prévisions infrajournalières (quelques heures) servent au pilotage en temps réel, les prévisions J+1 à la planification et aux achats, et les horizons plus longs à la budgétisation.
Le chemin des données : du compteur au modèle
Une installation typique comporte des compteurs ou sous-compteurs électriques reliés à une passerelle qui les lit via Modbus, M-Bus ou l'API d'un fabricant, puis publie les relevés vers un broker MQTT. Les données météo et les plannings de production ou d'occupation sont publiés ou stockés à côté.
Meters (Modbus RTU/TCP) -> gateway -> MQTT broker -> historian subscriber -> forecasting service
^ |
weather / schedule publisher forecast topic <-+
Une arborescence de topics claire rend le modèle indépendant des fabricants de compteurs :
connectmq/site1/main/meter1/energy {"ts":..., "kwh_total": 183422.6}
connectmq/site1/main/meter1/power {"ts":..., "kw": 142.8}
connectmq/site1/weather/outdoor {"ts":..., "temp_c": 27.4}
connectmq/site1/main/meter1/forecast {"generated":..., "points":[...]}
Dans la mesure du possible, publiez l'énergie sous forme d'index cumulé plutôt que de valeurs par intervalle. Si un message est perdu, la valeur suivante de l'index contient toujours la consommation, et la puissance par intervalle peut être reconstituée exactement par différence. La puissance instantanée est utile pour les tableaux de bord en direct, mais trop bruitée pour la prévision. Si vos compteurs sont des équipements Modbus, le guide Modbus TCP vers MQTT présente la partie passerelle.
Les variables qui déterminent la prévision de charge énergétique
| Groupe de variables | Exemples | Pourquoi c'est important |
|---|---|---|
| Calendrier | Heure de la journée, jour de la semaine, indicateur de jour férié, mois | L'occupation et la production suivent des plannings |
| Charge décalée | Même heure la veille, même heure la semaine précédente | Forte persistance de la demande |
| Météo | Température extérieure, sa prévision, humidité, rayonnement solaire | Les charges de chauffage et de climatisation en dépendent |
| Météo dérivée | Degrés-heures de refroidissement et de chauffage, décalage de température | Les bâtiments réagissent avec une inertie thermique |
| Exploitation | Plan de production, organisation des équipes, taux d'occupation | Explique les variations non liées à la météo |
Pour une prévision J+1, chaque variable doit être disponible avant l'établissement de la prévision. Il faut donc utiliser la prévision météo, et non la température mesurée, pour les heures futures, ainsi que des décalages d'au moins 24 heures. Confondre météo mesurée et météo prévue lors de l'entraînement est une cause fréquente de modèles excellents en test et décevants en exploitation.
Une prévision J+1 en Python
Le script ci-dessous simule l'index d'un compteur et la température extérieure d'un bâtiment tertiaire sur quatre semaines, les publie sur le serveur MQTT public gratuit, les récupère, convertit l'index en puissance au pas de 15 minutes, entraîne un modèle de gradient boosting et publie une prévision sur 24 heures. Dans un déploiement réel, l'étape de collecte lirait votre historian plutôt qu'un simulateur.
import json
import math
import random
import time
import uuid
import numpy as np
import pandas as pd
import paho.mqtt.client as mqtt
from sklearn.ensemble import HistGradientBoostingRegressor
BROKER = "broker.connectmq.com"
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/site1"
START = 1767225600 # 2026-01-01 00:00 UTC
STEPS = 28 * 96 # 4 semaines d'intervalles de 15 minutes
rows = []
def on_message(client, userdata, msg):
p = json.loads(msg.payload)
p["kind"] = msg.topic.rsplit("/", 1)[1]
rows.append(p)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="elf-" + uuid.uuid4().hex[:8])
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
client.subscribe([(f"{BASE}/meter1/energy", 1), (f"{BASE}/weather/temp", 1)])
client.loop_start()
time.sleep(1)
counter = 100000.0
for i in range(STEPS):
t = START + i * 900
hour = (t % 86400) / 3600
workday = time.gmtime(t).tm_wday < 5
temp = 24 + 7 * math.sin((hour - 9) / 24 * 2 * math.pi) + random.gauss(0, 1)
occupied = workday and 7 <= hour < 19
kw = 40 + (90 if occupied else 0) + 6 * max(temp - 22, 0) + random.gauss(0, 5)
counter += kw * 0.25
client.publish(f"{BASE}/meter1/energy", json.dumps({"ts": t * 1000, "kwh_total": round(counter, 2)}))
client.publish(f"{BASE}/weather/temp", json.dumps({"ts": t * 1000, "temp_c": round(temp, 2)}))
time.sleep(0.21) # deux messages par pas, rester sous 10 msg/s
time.sleep(3)
df = pd.DataFrame(rows)
df["ts"] = pd.to_datetime(df["ts"], unit="ms", utc=True)
energy = df[df.kind == "energy"].set_index("ts")["kwh_total"].sort_index().resample("15min").last()
temp = df[df.kind == "temp"].set_index("ts")["temp_c"].sort_index().resample("15min").mean()
data = pd.DataFrame({"kw": energy.interpolate().diff() * 4, "temp": temp.interpolate()})
data["hour"] = data.index.hour + data.index.minute / 60
data["dow"] = data.index.dayofweek
data["lag_1d"] = data["kw"].shift(96)
data["lag_7d"] = data["kw"].shift(7 * 96)
data["cdh"] = (data["temp"] - 22).clip(lower=0)
FEATS = ["hour", "dow", "lag_1d", "lag_7d", "temp", "cdh"]
data = data.dropna()
train, test = data.iloc[:-96], data.iloc[-96:]
model = HistGradientBoostingRegressor(max_iter=300, learning_rate=0.05).fit(train[FEATS], train["kw"])
pred = model.predict(test[FEATS])
mae = np.mean(np.abs(pred - test["kw"]))
print(f"Day-ahead MAE: {mae:.1f} kW, peak forecast {pred.max():.0f} kW, actual peak {test['kw'].max():.0f} kW")
forecast = {
"generated": int(time.time() * 1000),
"model": "gbr-load-v1",
"unit": "kW",
"points": [{"ts": int(ts.timestamp() * 1000), "kw": round(float(v), 1)} for ts, v in zip(test.index, pred)],
}
client.publish(f"{BASE}/meter1/forecast", json.dumps(forecast), qos=1, retain=True).wait_for_publish()
client.loop_stop()
client.disconnect()
Installez les dépendances avec pip install paho-mqtt pandas numpy scikit-learn. L'exécution prend environ dix minutes, car le simulateur respecte la limite de débit du serveur MQTT public gratuit. Le jour de test utilise ici la température mesurée simulée à la place d'une prévision météo ; en production, fournissez au modèle la température prévue pour les heures futures. Pour en savoir plus sur le backtesting avec plusieurs origines de prévision et la comparaison à une référence naïve, consultez la prévision de séries temporelles IoT.
Transformer la prévision en action
Une prévision n'est rentable que si elle modifie les décisions. Les schémas courants :
- Alertes de pointe. Comparez la pointe prévue à votre limite de puissance et prévenez l'équipe technique la veille au soir.
- Déplacement de charge. Un script de planification s'abonne au topic de prévision et déplace les charges flexibles, comme la recharge des véhicules électriques ou le chauffage par lots, vers les intervalles de faible demande.
- Pré-refroidissement et préchauffage. Le CVC peut profiter des heures bon marché ou peu chargées pour stocker de l'énergie thermique dans la masse du bâtiment, un schéma présenté dans l'optimisation CVC par IA.
- Suivi prévision contre réel. Publiez l'écart en direct sur son propre topic et déclenchez une alerte en cas d'écart persistant.
Avec ConnectMQ, vous pouvez suivre les topics de prévision et de puissance mesurée dans l'explorateur de topics en direct et définir des règles d'alerte à seuil sur la puissance mesurée, afin que le journal des alertes enregistre chaque intervalle ayant dépassé votre limite. Les actions plus avancées s'exécutent dans vos propres clients, comme des flux Node-RED ou des services Python abonnés au même broker.
Mettre à jour les prévisions en cours de journée
Une prévision J+1 est établie une seule fois, mais la journée se déroule rarement exactement comme prévu. Une équipe en heures supplémentaires imprévue ou un après-midi plus chaud que prévu modifie la charge. Une amélioration simple consiste à relancer la prévision toutes les heures en utilisant la dernière puissance mesurée comme entrée supplémentaire, et à publier chaque nouvelle version sur le même topic retenu avec un horodatage de génération. Les consommateurs voient toujours la vue la plus récente, et vous pouvez stocker chaque version pour mesurer dans quelle mesure les mises à jour infrajournalières améliorent la précision par rapport à l'exécution J+1 initiale.
Pièges pratiques
- Remises à zéro et débordements d'index. Les compteurs repartent à zéro ou sont réinitialisés après un remplacement ; traitez les différences négatives comme des remises à zéro, pas comme une demande négative.
- Fuseaux horaires et heure d'été. Stockez en UTC et calculez les variables calendaires en heure locale, sinon votre démarrage de 08:00 se décalera d'une heure deux fois par an.
- Jours fériés et arrêts. Sans indicateur de jour férié, le modèle prévoira une charge de jour ouvré normal un jour férié.
- Évolution des références. De nouveaux équipements, des rénovations ou des horaires d'ouverture modifiés rendent l'historique ancien trompeur ; pondérez davantage les données récentes ou réentraînez sur une fenêtre glissante.
- Sommes des sous-compteurs différentes du compteur principal. Les charges non comptées et les pertes existent ; prévoyez directement le compteur principal plutôt que d'additionner les prévisions des sous-compteurs, et utilisez les sous-compteurs pour le diagnostic.
Passer à l'échelle sur plusieurs sites
Un bâtiment, c'est un script ; cinquante sites, c'est une plateforme. Gardez une arborescence de topics identique sur chaque site, exécutez un seul service de prévision qui s'abonne avec des jokers et stockez les résultats par site. Un broker MQTT managé supprime le travail d'exploitation de la couche de messagerie, et ConnectMQ propose des clusters Dedicated et des déploiements BYOC lorsque les sites exigent une isolation. Pour en savoir plus sur l'association de modèles et d'objets connectés, consultez le guide IA et IoT, et pour une approche des systèmes énergétiques fondée sur les modèles, les jumeaux numériques pour l'énergie.
Démarrer avec ConnectMQ
Créez gratuitement un broker Serverless sur app.connectmq.com, sans carte bancaire. Connectez votre passerelle de comptage et votre service de prévision avec les identifiants générés YOUR_USERNAME, YOUR_PASSWORD et YOUR_CLIENT_ID, et commencez à constituer l'historique dont votre modèle de prévision de charge énergétique a besoin. À mesure que vous ajoutez des sites, passez à une offre de broker MQTT cloud plus importante sans modifier vos topics.
Questions fréquentes
Qu'est-ce que la prévision de charge énergétique ?
La prévision de charge énergétique estime la demande électrique d'un bâtiment, d'une usine ou d'une zone du réseau pour des intervalles futurs, généralement à partir de l'historique des compteurs, de la météo et d'informations calendaires.
De combien de données ai-je besoin pour prévoir la charge énergétique ?
Quelques semaines de données au pas de 15 minutes suffisent à produire une prévision J+1 exploitable pour un bâtiment aux horaires stables. Il faut au moins un an de données pour capturer les variations saisonnières de chauffage et de climatisation ainsi que les jours fériés.
Dois-je publier l'énergie ou la puissance de mes compteurs ?
Publiez l'index d'énergie cumulé pour la précision des prévisions et de la facturation, car la perte de messages ne fait pas perdre de consommation. Publiez en plus la puissance instantanée si vous avez besoin de tableaux de bord en direct.
Quel modèle fonctionne le mieux pour la prévision de charge ?
Le gradient boosting sur des variables calendaires, décalées et météo constitue un choix par défaut solide et explicable. Comparez-le à une référence « même jour la semaine précédente » et ne changez de modèle que si un autre l'emporte lors d'un backtest glissant.
