Dans une maison flamande à l’heure du retour du travail, la tension monte entre la pompe à chaleur, la plaque à induction, le four et la recharge du véhicule électrique — un seul pic de quelques minutes suffit à faire basculer la facture réseau. C’est le point de départ d’une quête technique menée par Claire, ingénieure en gestion énergétique, qui décide de développer un algorithme de Peak Shaving en .NET pour piloter une batterie via l’onduleur Deye et son Copilot. Son objectif : maintenir la puissance soutirée sous 2 500 W en Flandre, réduire les pénalités du tarif capacitaire et améliorer l’efficacité énergétique du foyer.
Claire part d’un scénario concret et de chiffres mesurables — un pic à 5 900 W dont 3 400 W doivent être fournis par la batterie pendant 30 minutes (≈ 1,7 kWh) — et trace un plan technique en .NET qui couvre la collecte de données, la modélisation du système BESS, la programmation de stratégies d’effacement des pics et l’intégration avec des prévisions solaires 48–72 h.
Ce récit technique raconte le développement, la validation et le déploiement d’une solution de gestion de la demande qui combine optimisation énergétique, programmation robuste et supervision en temps réel.
Peak Shaving en .NET : conception d’un algorithme d’effacement des pics
Le cœur du système est simple : utiliser la batterie comme tampon pour maintenir la puissance réseau sous un seuil prédéfini. L’algorithme calcule à chaque intervalle la différence entre consommation et production, puis ordonne une décharge si le seuil est dépassé.
Pour la mise en œuvre en .NET, on structure l’application en services : ingestion des mesures, moteur de règles de Peak Shaving, module de prévision solaire, modèle batterie et interface vers l’onduleur/Deye Copilot. Chaque composant suit des contrats d’interface clairs pour faciliter le développement, la maintenance et le test.
Ce design modulaire permet d’itérer rapidement sur la logique d’effacement des pointes et d’assurer une intégration fluide avec des systèmes industriels ou résidentiels. Cible clé : réduction de la consommation réseau au moment des pics.
Architecture logicielle pour le développement en .NET
On divise l’application en services indépendants : acquisition (MQTT/REST/CSV), moteur de règles, prévision (48–72 h), simulateur et API d’action vers l’onduleur. L’utilisation de .NET 7/8 avec BackgroundService facilite les tâches planifiées et la programmation événementielle.
Le modèle batterie inclut paramètres : capacité (kWh), puissance max de décharge (kW), SOC min/max et rendement. Pour le résidentiel, on retient couramment 5–10 kWh ; pour le C&I, les BESS atteignent plusieurs centaines de kWh à plusieurs MWh. Le système gère aussi la gestion de la demande en priorisant le maintien du seuil tarifaire.
Chaque service expose des métriques pour le suivi: puissance mesurée, puissance envoyée par batterie, SOC, fréquence des cycles. Ces métriques alimentent ensuite un tableau de bord et des alertes pour optimiser l’efficacité énergétique.
Phrase-clé : une architecture propre permet d’assurer un déploiement fiable et de faciliter l’évolution de l’algorithme.
Algorithme de contrôle : logique, règles et contraintes
L’algorithme principal s’exécute à intervalles réguliers (typ. 15 min → 0,25 h), ou en mode quasi-instantané si les données sont à haute fréquence. Il calcule le besoin d’aide comme : besoin = max(0, puissance_totale – seuil).
Règles et contraintes essentielles : limiter la décharge à la puissance maximale de l’onduleur, respecter un SOC minimum (souvent 20–30 %) et prendre en compte le rendement batterie Aller/Retour. Si le besoin dépasse la capacité instantanée, on applique une hiérarchie : réduire charges flexibles, décharger batterie, alerter opérateur.
Exemple chiffré : un pic de 3 400 W pendant 30 minutes consomme ~1,7 kWh. Pour une batterie 10 kWh réservant 30 % de SOC, l’énergie disponible est ≈ 7 kWh — largement suffisante pour plusieurs pics courts.
Phrase-clé : la robustesse de l’algorithme repose sur la prise en compte simultanée de puissance, énergie et contrainte de durée.
Cas pratique chiffré : scénario résidentiel flamand à 18h30
Yann rentre chez lui à 18h30. Les appareils démarrent simultanément et le compteur pointe à 5 900 W. Le seuil configuré dans Deye Copilot est fixé à 2 500 W. L’onduleur détecte l’excédent et demande à la batterie de fournir 3 400 W, évitant ainsi la pénalité capacitaire.
Conditions techniques : SOC suffisant, onduleur 5 kVA capable de délivrer la puissance demandée, durée du pic 30 minutes. Cette séquence illustre le principe physique et économique de l’effacement des pics.
| Appareil ⚡ | Puissance (W) 🔋 | Sans Peak Shaving 🌐 | Avec Peak Shaving 🔒 |
|---|---|---|---|
| Pompe à chaleur 🏠 | 1 200 | Inclus dans total | Réseau : 2 500 W ✅ |
| Plaque induction 🍳 | 2 200 | Contribue au pic | Batterie : 3 400 W ⚡ |
| Four électrique 🔥 | 1 800 | Total réseau : 5 900 W ❗ | Seuil respecté |
| Éclairage + divers 💡 | 400 | — | — |
| Recharge VE 🚗 | 300 | — | Recharge réduite si nécessaire |
Phrase-clé : cet exemple met en lumière comment une stratégie de Peak Shaving permet une réduction immédiate de la puissance mesurée et des coûts réseau.
Tests, simulation et intégration avec Deye Copilot
Pour valider l’algorithme, on met en place une chaîne de test : ingestion de données (CSV ou flux en temps réel), simulation de profils de charge et PV, puis tests unitaires et d’intégration avec un onduleur en banc d’essai. Le projet Python cité fournit une logique utile (scraping, tests), mais le développement .NET reprend les mêmes principes en adaptant les formats (CSV horodaté, interval = 0.25).
Scénarios à simuler : pics courts (quelques minutes), pics prolongés (30–60 min), SOC bas, coupures réseau. Les outils recommandés : émulation MQTT, HIL pour l’onduleur, et suivi via Prometheus/Grafana pour les KPIs.
Phrase-clé : une stratégie de test complète garantit que l’algorithme respecte les contraintes opérationnelles réelles.
- 🔧 Collecte : configurer ingestion (MQTT/CSV/REST) et régler l’intervalle (15 min = 0,25 h).
- 🧭 Modélisation : définir capacité batterie, puissance max, SOC min (20–30 %).
- ⚙️ Règles : seuil Peak Shaving (ex. 2 500 W), hiérarchie d’actions (réduction charges, décharge batterie).
- 🧪 Tests : simu de pics, HIL, monitoring KPI.
- 📈 Suivi : métriques temps réel (kW évités, kWh déchargés, cycles batterie).
- 🔁 Maintenance : mises à jour des prévisions solaires 48–72 h et adaptation via apprentissage des habitudes.
Phrase-clé : une checklist opérationnelle réduit le risque de défaillance lors du déploiement en production.
Optimisation énergétique et KPIs pour piloter la performance
Les indicateurs suivis en permanence sont : réduction de pointe (kW), énergie de décharge dédiée au Peak Shaving (kWh), cycles batterie, économies €/an et temps de retour. Pour une maison 4–5 kWc avec batterie 10 kWh, le Deye Copilot revendique des économies additionnelles de 450 à 650 €/an, et un retour sur investissement batterie raccourci de 2 à 3 ans si la gestion est automatisée.
En contexte industriel, la valeur économique d’un kW évité est encore plus élevée, d’où l’importance d’un algorithme scalable capable d’orchestrer plusieurs batteries en parallèle.
Phrase-clé : mesurer ces KPIs permet d’ajuster la stratégie d’optimisation et d’améliorer l’efficacité énergétique au fil du temps.
Quel seuil configurer pour un ménage en Flandre ?
Pour une installation résidentielle en Flandre, le seuil recommandé est souvent 2 500 W (seuil tarif minimum). Ce seuil peut être ajusté selon le contrat et le profil de consommation ; un seuil plus bas augmente les économies mais sollicite davantage la batterie.
Quelle taille de batterie pour l’effacement des pointes ?
Pour des pics résidentiels courts (30–60 minutes), une batterie de 5 kWh suffit souvent pour le peak shaving seul. Pour combiner autoconsommation solaire et arbitrage tarifaire, prévoir 10–15 kWh. Pour C&I, on travaille en centaines de kWh à plusieurs MWh.
Le peak shaving est-il utile en Wallonie après la réforme 2026 ?
La réforme tarifaire 2026 (CWaPE) en Wallonie introduit un tarif par zones ECO/MEDIUM/PIC basé sur les kWh ; l’optimisation prioritaire est l’arbitrage temporel. Néanmoins le peak shaving reste pertinent si la puissance de raccordement est limitée ou pour réduire contraintes locales.
Quels sont les prérequis techniques pour une intégration .NET avec Deye Copilot ?
Prérequis : onglet ‘Grid Peak Shaving’ actif dans Deye Copilot (Deye Cloud v3.2.0+), onduleur hybride compatible connecté en Wi‑Fi, batteries compatibles (Pylontech, Delong…), et API/commande locale supportée pour piloter la décharge. L’application .NET doit implémenter ingestion, règles, et interface d’action (MQTT/REST/gRPC).