Pilotage solaire local ou cloud : dépendance et confidentialité
09.10.2026
Le pilotage local peut garder mesures et automatismes dans le logement, tandis qu’une intégration cloud dépend du service du fabricant et de ses mises à jour. Comparer les deux suppose d’examiner les données échangées, la fréquence des mesures et ce qui reste fonctionnel sans Internet.
La différence tient au trajet des données
« Local » ne signifie pas qu’aucune donnée ne circule : les mesures passent du compteur ou de l’onduleur au contrôleur domestique. La question est plutôt de savoir si elles quittent ensuite le logement et si la logique qui décide d’allumer un chauffe-eau ou de charger une batterie dépend d’un service distant. Home Assistant indique que son logiciel stocke les données localement et communique directement avec les appareils lorsque ceux-ci le permettent ; certains protocoles locaux peuvent même fonctionner sans Internet. À l’inverse, son intégration Sunsynk présentée dans la documentation lit les mesures depuis le cloud du fabricant. Ce sont deux architectures possibles, pas une garantie générale sur toutes les marques ni sur toutes les fonctions d’un équipement. [Home Assistant : confidentialité](https://www.home-assistant.io/faq/is-my-data-private/), [SolarEdge Modbus](https://www.home-assistant.io/integrations/solaredge_modbus/), [Sunsynk](https://www.home-assistant.io/integrations/sunsynk).
Une mesure plus fraîche n’est pas automatiquement un meilleur pilotage
Pour une action déclenchée par le surplus photovoltaïque, la fraîcheur des données compte : une règle peut observer la production et éviter de réagir à une valeur déjà dépassée. Dans l’exemple SolarEdge Modbus, les relevés arrivent toutes les quelques secondes ; l’intégration Sunsynk décrite interroge son cloud toutes les cinq minutes. Ce rythme concerne ces intégrations précises, pas une comparaison universelle de la latence des clouds et des appareils locaux. Autre distinction importante : lire une mesure et commander un appareil ne sont pas la même chose. La page Sunsynk décrit des capteurs en lecture seule. Avant de bâtir une automatisation, vérifiez donc si votre chaîne sait seulement afficher la production, ou aussi agir sur la batterie, la borne ou le relais concerné. [SolarEdge Modbus](https://www.home-assistant.io/integrations/solaredge_modbus/), [Sunsynk](https://www.home-assistant.io/integrations/sunsynk).
Panne Internet : distinguer mesure, automatisme et accès à distance
Le cas concret est simple : si la connexion Internet tombe en plein après-midi, une intégration locale SolarEdge peut continuer à recevoir la production tant que le réseau domestique, l’onduleur et le contrôleur restent disponibles ; la documentation précise qu’aucun service cloud n’est impliqué. Pour l’intégration Sunsynk, les données cessent de se mettre à jour si l’onduleur perd Internet. Cela ne permet pas de conclure que l’installation solaire elle-même cesse de produire : c’est le flux de données de l’intégration qui est concerné. La séparation local/distant peut aussi être volontaire. OpenEMS décrit Edge comme un composant sur site qui communique avec les appareils et exécute les algorithmes de commande, et un Backend sur serveur cloud pour connecter et surveiller plusieurs Edge. Ce modèle hybride peut conserver une commande locale tout en ajoutant supervision distante ; la présence du Backend doit toutefois être prise en compte dans l’analyse des données et des dépendances. [SolarEdge Modbus](https://www.home-assistant.io/integrations/solaredge_modbus/), [Sunsynk](https://www.home-assistant.io/integrations/sunsynk), [OpenEMS](https://github.com/OpenEMS/openems/blob/develop/README.md).
Confidentialité : regarder au-delà de l’étiquette « local »
Un pilotage local réduit le besoin d’envoyer les relevés énergétiques à un service tiers, mais ne dispense pas d’examiner les options activées : accès à distance, sauvegardes, assistants vocaux, analyses facultatives ou connexion au compte du constructeur. Home Assistant présente son service cloud comme optionnel et rappelle que les services activés déterminent les échanges. Un cloud fabricant, de son côté, peut apporter une application et une consultation à distance, mais crée une dépendance à la disponibilité du service, du compte et du flux réseau. Ne confondez pas non plus « local » et « sans maintenance ». Il faut que l’onduleur expose une interface compatible, que le réseau domestique soit stable et que les identifiants et mises à jour soient gérés. Dans l’exemple SolarEdge, Modbus doit être activé sur l’onduleur ; le matériel incompatible ne gagne pas une API locale par simple choix d’une plateforme. [Confidentialité Home Assistant](https://www.home-assistant.io/faq/is-my-data-private/), [SolarEdge Modbus](https://www.home-assistant.io/integrations/solaredge_modbus/).
Une méthode de choix en quatre vérifications
Avant de choisir une domotique solaire, posez quatre questions : 1. **Quelles données sont nécessaires ?** Production seule, import/export réseau, batterie, ou détail par panneau ? Toutes les intégrations n’exposent pas les mêmes informations. 2. **À quelle cadence faut-il agir ?** Un relevé toutes les minutes peut suffire pour un tableau de bord, mais une régulation de surplus mérite une cadence adaptée à l’appareil et à la charge pilotée. 3. **Que se passe-t-il sans Internet ?** Vérifiez séparément l’affichage des mesures, l’exécution des règles sur le contrôleur, les commandes vers l’équipement et l’accès à distance. Ne supposez pas qu’une fonction décrite comme locale couvre toute la chaîne. 4. **Qui reçoit quoi ?** Lisez les réglages de télémétrie, d’accès distant et de compte fabricant ; désactivez les fonctions facultatives inutiles et documentez les accès. Pour réduire dépendance et exposition, privilégiez un système où l’interface locale de l’onduleur est documentée et où l’automatisme critique est exécuté dans la maison. Si l’application du fabricant reste utile, une architecture mixte peut être raisonnable : mesures et décisions locales, consultation distante seulement lorsque nécessaire. Le meilleur compromis dépend des appareils effectivement compatibles, des priorités de confidentialité et de la tolérance à la maintenance.