Prévision solaire : modèles frugaux

Read the full article in English · Version française ci-dessous

Auteurs et fondements scientifiques

Équipe du manuscrit, dans l’ordre du document : Cyril Voyant, Martin Leiva, Xavier Silvani, Gilles Notton, Luis Garcia-Gutierrez, Alan Julien, Gabriel Chesnoiu, Kamel Abdeladim, Thomas Carriere. Manuscrit non soumis ; Cyril Voyant est l’auteur de cette explication pédagogique.

Crédits de la version logicielle citée dans le guide PV_ELM_pred : M. Leiva, X. Silvani, G. Notton, C. Voyant et A. Julien. Ils sont distincts de la liste du manuscrit.

L’ELM est une méthode antérieure à ces études : Guang-Bin Huang, Qin-Yu Zhu et Chee-Kheong Siew, Extreme learning machine: Theory and applications (2006). Notre démarche concerne son évaluation et son usage en prévision ; elle ne revendique pas l’invention de l’ELM.

Comprendre la prévision solaire · 20 octobre 2026 · Lecture accessible

Le meilleur modèle n’est pas seulement celui qui obtient le plus petit score d’erreur. C’est aussi celui qui tient sur le matériel disponible, répond à temps et reste maintenable.

Pourquoi penser au déploiement dès le départ ?

Une prévision peut servir dans une station météo, un contrôleur de batterie ou à proximité d’un onduleur. Ces équipements n’ont pas tous un GPU, une grande mémoire ou une connexion permanente au cloud. Le budget de calcul fait alors partie du problème de prévision.

Produire la prévision localement peut réduire la dépendance au réseau et limiter les transferts de données. Cela ne dispense pas de sécuriser le dispositif, de suivre ses erreurs et de mettre à jour le modèle lorsque le système évolue.

Frugal ne signifie pas simpliste

L’idée est de justifier la complexité ajoutée. Commencer par une persistance bien définie, puis une autorégression linéaire, donne un point de comparaison. Un modèle plus riche est intéressant s’il apporte un gain utile et robuste au regard de son coût.

Un ELM utilise une couche cachée dont les poids sont fixés aléatoirement, puis ajuste les poids de sortie. C’est une piste pour étudier des modèles non linéaires avec un ajustement simple. Ce choix ne garantit ni la meilleure prévision sur tous les sites, ni un coût négligeable : les poids fixes occupent eux aussi de la mémoire.

Une question concrète : que gagne-t-on en ajoutant du modèle ?

Supposons, à titre illustratif, que deux modèles répondent au besoin de pilotage, mais que l’un exige beaucoup plus de mémoire. Ce surcoût mérite d’être justifié. À l’inverse, une amélioration modeste d’erreur peut être précieuse si elle évite une décision coûteuse. La décision dépend donc de l’usage, pas seulement de la taille du modèle.

Le dépôt PV_ELM_pred permet de comparer persistance, BLEND, autorégression et variantes d’ELM avec un protocole commun. Un balayage de tailles aide à regarder ensemble précision et nombre de paramètres stockés.

Exemple chiffré : plus de modèle, pour quel gain ?

Imaginons un modèle A stockant 100 paramètres, avec une RMSE de 100 W. Un modèle B stocke 10 000 paramètres et obtient 95 W sur les mêmes observations et au même horizon : 100 fois plus de paramètres pour 5 % de RMSE en moins. Ce gain peut être utile, mais le seul score ne tranche pas la décision de déploiement.

Avec un stockage en float32, les paramètres seuls occupent environ 400 octets pour A et 40 000 octets pour B. Il faut encore compter les entrées, les tableaux temporaires et le logiciel. La latence et l’énergie ne se déduisent pas de ces nombres : elles se mesurent sur l’appareil cible.

Si l’on compare ensuite ces deux modèles à une persistance dont la RMSE vaut 125 W, leurs rapports d’erreur sont respectivement 0,80 et 0,76. Les deux améliorent cette référence sur ce test, avec des coûts très différents. Exemple pédagogique fictif : aucun classement des études en cours n’est déduit de ces valeurs.

Que mesurer sur le terrain ?

• La prévision : mêmes dates, mêmes horizons, comparaison à une référence et stabilité sur plusieurs périodes.

• Le dispositif : mémoire réellement utilisée, temps de réponse, coût de mise à jour et comportement hors connexion.

• L’énergie : consommation mesurée sur le matériel cible, en distinguant préparation, apprentissage et fonctionnement.

Moins de paramètres ne prouve pas une économie d’énergie ou de carbone. Il faut mesurer la chaîne réelle. Un benchmark de taille de modèle ne constitue pas à lui seul une validation embarquée.

Où s’arrête cette approche ?

Prévoir un canal à partir de son propre passé est une stratégie pour explorer la prévision locale à court terme. Elle ne remplace pas, par principe, la météo numérique pour anticiper le lendemain, ni les modèles physiques lorsqu’ils apportent une information pertinente. Le vent, la charge et les autres renouvelables demandent leur propre validation.

Réduire les entrées et réduire le modèle sont deux leviers différents. On peut les combiner, à condition de compter le coût de toute la chaîne et de vérifier la qualité de la prévision finale.

Code ouvert et recherche en cours

Cette page présente la démarche de Cyril Voyant et de ses collaborateurs autour de la prévision solaire et météorologique frugale. Le manuscrit How Much Model Is Enough for Endogenous, Edge-Oriented Solar and Weather Forecasting?, dont Cyril Voyant est premier auteur, n’est pas encore soumis. Cette page ne publie pas ses chiffres ni ses classements.

Le dépôt Python public est le point d’entrée actuel pour le protocole, les modèles et les conditions d’accès aux données. L’exemple Palaiseau est fourni ; les autres données peuvent avoir des conditions d’accès spécifiques.

Explorer le benchmark PythonLire le guide technique ELMPourquoi réduire les entrées ?

English summary

Frugal solar forecasting treats deployment constraints as part of model selection. Compare persistence, linear models and ELMs under the same protocol; justify extra capacity by useful forecast gains. Stored parameter count does not measure energy or carbon savings. Validate latency, memory and energy on the target device. The associated first-author manuscript remains unsubmitted; this explainer links to public software only.