Un onduleur, une borne de recharge ou une pompe à chaleur qui transmet déjà ses données à son fabricant offre deux moyens d'y accéder : appeler l'API du fabricant ou lire l'appareil sur site par Modbus ou une autre interface locale. Les sous-compteurs voisins ne disposent généralement d'aucune connexion cloud ; pour eux, un Gateway local est la seule voie d'accès. Décidez appareil par appareil, et non pour l'ensemble du site.
Certaines API tierces agrègent les clouds de plusieurs fabricants. Elles simplifient l'intégration, mais ajoutent un deuxième fournisseur, avec ses propres intervalles et quotas, entre vous et les données.
Comparaison
| Question | API cloud du fabricant | Gateway local |
|---|---|---|
| Quels points ? | Ceux que le fournisseur expose à votre compte, souvent moins nombreux que ceux de l'appareil | Ceux que fournit l'interface locale et que le Gateway peut intégrer |
| Intervalle | Intervalle de transmission de l'appareil et agrégation du fournisseur, puis limite imposée par le quota d'appels | Intervalle d'interrogation ou de transmission que vous définissez, souvent de 1 s à 1 min |
| Horodatage | Heure de mesure ou de transmission, selon l'API | Heure d'interrogation, sauf si l'appareil fournit son propre horodatage |
| Coupure Internet | Aucune nouvelle donnée. Le trou n'est comblé ensuite que si l'appareil conserve les mesures et si l'API fournit l'historique | Collecte, historique local, tableaux de bord et automatisation continuent. L'envoi en amont reprend depuis la mémoire tampon |
| Quels équipements ? | Gamme d'un fabricant, ou plusieurs gammes via un agrégateur | Tout appareil doté d'une interface locale prise en charge, dans un modèle de données que vous maîtrisez |
| Sur site | Aucun matériel supplémentaire | Un Gateway, son alimentation et une connexion réseau |
| Exploitation | Identifiants, renouvellement des jetons et changements de l'API du fournisseur | Mises à jour logicielles, sauvegardes et règles de pare-feu |
| Commande | Seulement les commandes exposées par le fournisseur, via ses serveurs | Écritures locales, avec les limites et les verrouillages que vous configurez |
Quand une API cloud convient
Une API cloud est la voie la plus rapide si l'équipement est déjà connecté et que l'objectif est de produire des rapports. Le quota d'appels détermine alors la fraîcheur possible des données. L'API Enlighten v4 d'Enphase autorise 10 appels par minute et 1 000 par mois avec l'offre gratuite Watt, 50 000 par mois avec Kilowatt et 300 000 avec Megawatt (offres développeur Enphase). Un appel par système toutes les 15 minutes représente 96 appels par jour, soit environ 2 900 par mois. L'offre gratuite ne suffit donc pas pour un seul système. Quarante systèmes exigent environ 117 000 appels mensuels, au-delà du plafond Kilowatt.
Ces mêmes 40 systèmes ne nécessitent que 40 appels par jour si l'intégration récupère chaque nuit les intervalles de la journée précédente à partir d'un point d'accès qui renvoie une journée entière par appel. Cette méthode convient à un rapport mensuel sur un parc d'installations. Elle ne convient pas à un tableau de bord qui doit afficher la dernière heure.
Vérifiez les points suivants avec un compte et un appareil réels, plutôt qu'avec les seuls exemples de la documentation :
- l'intervalle effectivement fourni par l'API pour vos appareils et le quota de votre offre ;
- la profondeur de l'historique et l'arrivée ultérieure éventuelle des intervalles manquants ;
- la signification de chaque horodatage, mesure ou transmission, et son fuseau horaire ;
- la représentation d'un appareil hors ligne : trou, répétition de la dernière valeur ou zéro ;
- le propriétaire du compte et le transfert des accès si le site ou l'actif change de propriétaire ;
- le préavis accordé par le fournisseur avant la suppression d'un point d'accès.
Ce dernier risque est réel. Le 20 février 2026, Enphase a annoncé que neuf points d'accès seraient retirés le 16 mars 2026, soit 24 jours plus tard. Après cette date, leurs appels renvoient HTTP 401 (avis d'abandon d'Enphase).
Quand un Gateway local convient
Un Gateway local convient lorsque les appareils disposent d'interfaces locales mais d'aucune connexion cloud. Prenons un site équipé de 20 sous-compteurs Modbus RTU sur un bus RS-485, d'une sortie à impulsions sur le compteur de gaz et d'un système de gestion technique du bâtiment BACnet/IP. Aucun de ces appareils ne transmet ses données ailleurs. Le Gateway les lit à l'intervalle défini, conserve l'historique sur site et exécute les automatismes sans aller-retour vers un serveur.
Lire soi-même un appareil implique aussi d'assumer la configuration de ses points. Les erreurs fréquentes se situent au niveau des registres : mots d'une valeur sur 32 bits lus dans le mauvais ordre, facteur d'échelle appliqué deux fois ou registre d'énergie en Wh interprété comme des kWh. Chacune peut produire un nombre plausible mais faux. Le guide des tables de registres Modbus explique comment comparer chaque point à l'affichage du compteur.
Le Gateway est aussi un équipement à exploiter. Désignez dès la mise en service une personne responsable des mises à jour logicielles, des sauvegardes et des règles de pare-feu. Sans responsable, le Gateway risque de ne pas être mis à jour.
Horodatages et intervalles de puissance appelée
La puissance appelée sur 15 minutes se calcule à partir de l'énergie de chaque intervalle : l'horodatage détermine donc à quel intervalle appartient une mesure. Supposons qu'un appareil conserve les données pendant une coupure de trois heures, avec une puissance moyenne de 400 kW, puis envoie 1 200 kWh lorsque la connexion revient à 14:07. Si l'API ou la plateforme horodate ces mesures à l'heure de leur envoi, les 1 200 kWh tombent tous dans l'intervalle de 14:00 à 14:15. Cet intervalle affiche alors une puissance appelée de 4 800 kW, douze fois la valeur réelle.
Il faut conserver l'heure de mesure depuis l'appareil jusqu'à la plateforme. L'interrogation locale présente une variante moins grave du même problème. Le Gateway horodate une valeur Modbus quand il interroge l'appareil ; un registre actualisé une fois par minute peut donc déjà avoir une minute lorsqu'il est lu. Le guide sur l'heure de source et l'heure d'arrivée précise ce que doit représenter chaque horodatage. Le calculateur de puissance par intervalle montre comment un seul intervalle erroné modifie le pic facturé.
Architectures hybrides
Un site utilise souvent les deux voies. Prenons une installation photovoltaïque de 250 kW dont les onduleurs envoient leurs données au portail du fabricant, un compteur général d'importation et six sous-compteurs Modbus, dont un sur le départ photovoltaïque. Deux règles assurent la cohérence des données et des commandes.
Première règle : une source par point. Pour le quart d'heure se terminant à 13:00, le compteur du départ photovoltaïque indique 182 kW et l'API de l'onduleur 185 kW. Ce sont deux mesures du même flux. Si vous les additionnez pour calculer la production du site, le rapport affiche 367 kW pour une installation de 250 kW. Utilisez le compteur de départ, dont vous connaissez la classe de précision, et réservez la valeur de l'API au diagnostic de l'onduleur. Si la mesure du compteur manque, ne la remplacez par celle de l'API qu'en signalant cette substitution.
Deuxième règle : un responsable par point inscriptible. Une plateforme de flexibilité commande la batterie du site via l'API du fabricant et fixe la décharge à 0 kW pendant une période de charge. Simultanément, une règle locale d'écrêtement des pointes demande 150 kW de décharge lorsque l'importation dépasse sa limite. Chaque interface confirme la réussite de son écriture. La consigne change à chaque nouvelle commande et sa courbe prend une forme en dents de scie. Confiez la consigne à un seul système ; l'autre la lit ou demande au responsable de la modifier.
Le guide sur la qualité des données explique comment signaler les valeurs de substitution et les valeurs obsolètes.
Sécurité et accès
Les deux voies placent la limite de confiance à des endroits différents. Pour une API cloud, l'identifiant d'accès est l'actif critique. L'API Enlighten v4 utilise OAuth 2.0. Le propriétaire du système autorise l'application ; le jeton d'accès est valable un jour et le jeton de renouvellement un mois (guide de démarrage Enphase). Si l'intégration ne renouvelle pas le jeton durant ce mois, une nouvelle autorisation du propriétaire est nécessaire. Notez le compte auquel chaque actif est rattaché. Une vente du site ou un changement d'installateur peut supprimer votre accès.
Avec un Gateway, l'actif critique est l'appareil présent sur votre réseau OT. Aucun port entrant depuis Internet n'est nécessaire, puisqu'il établit lui-même la connexion sortante vers la plateforme. La section 5.2.3.1 du NIST SP 800-82 Rev. 3 recommande de séparer OT et IT, de n'autoriser les connexions qu'entre zones adjacentes et de rendre les règles sortantes aussi strictes que les règles entrantes. Pour un Gateway, cela suppose une liste explicite de ses destinations réelles : broker ou point d'accès de la plateforme, serveurs de temps et service de mise à jour. Une règle autorisant tout le trafic HTTPS sortant n'est pas une liste de destinations autorisées.
Tester une coupure
Avant de généraliser l'une ou l'autre voie à un parc, interrompez la connexion Internet d'un site pilote selon un plan convenu. Coupez la liaison WAN, pas l'alimentation du Gateway : une coupure de courant teste une autre panne. Maintenez la liaison coupée pendant au moins deux heures, soit huit intervalles de puissance appelée de 15 minutes.
- Pendant la coupure, consignez ce qui continue à fonctionner sur site : mesures, historique local, tableaux de bord et automatisation.
- Notez comment la plateforme représente la période manquante : trou, dernière valeur conservée ou zéros. Les zéros sont le pire résultat, car ils ressemblent à de vraies mesures.
- Rétablissez la liaison et comptez les mesures arrivées. Cinquante points à un intervalle d'une minute pendant deux heures doivent fournir 6 000 mesures. Un total inférieur indique une perte ; un total supérieur, des doublons que la plateforme doit éliminer. MQTT QoS 1 garantit une livraison au moins une fois (MQTT 5.0, section 4.3.2) : des doublons après reconnexion sont donc normaux, pas nécessairement un défaut.
- Vérifiez que les mesures reçues en différé conservent leur heure de mesure et qu'aucun intervalle de puissance appelée ne présente un pic semblable à celui de l'exemple précédent.
- Pour une API, vérifiez si le fournisseur comble le trou, dans quel délai, et si votre intégration redemande la période manquante.
L'essai réussit si le nombre de mesures est correct, si chacune conserve son horodatage d'origine et si la plateforme n'a jamais représenté la coupure par des zéros. La liste de contrôle de mise en service permet d'enregistrer l'essai. Le guide sur le stockage et le renvoi des données aide à dimensionner le stockage local pour la plus longue coupure prévue.
Rapport et commande : deux besoins distincts
Une intégration destinée aux rapports nécessite des lectures périodiques. Une intégration de commande exige un cycle de vie des ordres : expiration, limites locales, retour d'état mesuré et repli lorsque la liaison échoue. Une API cloud ne peut pas fournir ce repli, puisque la liaison défaillante est précisément le chemin vers le cloud.
Une réponse positive de l'API signifie que le fournisseur a accepté la commande. Une réponse positive à une écriture Modbus signifie que le registre a été écrit. Aucune des deux ne prouve que l'actif a réagi. Le guide de vérification des commandes BESS montre comment confirmer la réaction par des mesures. La matrice des défaillances des verrouillages aide à définir la conduite du site lorsque la voie de commande échoue.
Edge sur le Gateway
Edge fonctionne sur le Gateway ZGW-20, sur site. Il rassemble les appareils sans fil EpiSensor, les appareils Zigbee et LoRaWAN tiers, les équipements Modbus TCP et RTU et les contrôleurs BACnet/IP dans un même inventaire. Il conserve l'historique localement et fait fonctionner les tableaux de bord et l'automatisation sans Internet. Il transmet les données par MQTT ou HTTPS, ou sous forme de fichiers via FTPS, en JSON ou CSV. Aucun service cloud EpiSensor n'intervient dans cette voie. Le Gateway consomme 5 W au repos et 15 W au maximum.
Lors de l'essai de coupure, Edge met les livraisons échouées dans une file sur disque. Pour les destinations qu'il gère, il vérifie cette file chaque minute et renvoie les données dès que la destination redevient disponible. Les mesures renvoyées conservent leur horodatage d'origine et ne déclenchent pas une seconde fois l'automatisation locale. Deux limites influent sur le décompte de l'étape 3. Un lot encore en mémoire lorsque le Gateway perd son alimentation peut être perdu. Un lot que le destinataire a stocké avant qu'Edge n'enregistre la réussite peut arriver deux fois.
Questions fréquentes
Quelle différence entre une API cloud et un Gateway local ?
Une API cloud renvoie les données déjà transmises par l’équipement à son fabricant. Un Gateway local lit l’équipement sur site par Modbus, BACnet, Zigbee ou LoRaWAN et stocke les mesures avant de les envoyer. Pendant une coupure Internet, le Gateway continue la collecte alors que l’API ne fournit aucune nouvelle donnée. Dans les deux cas, la plateforme attend le rétablissement de la liaison.
Quand une API cloud suffit-elle ?
Quand l’équipement communique déjà avec son fabricant, que l’API fournit les points voulus à l’intervalle nécessaire et que l’objectif est de produire des rapports, pas de commander l’équipement. Un rapport mensuel sur un parc photovoltaïque en est un exemple.
Pourquoi utiliser un Gateway local pour le suivi énergétique ?
De nombreux sous-compteurs de sites professionnels ne disposent que d’une interface Modbus ou d’une sortie à impulsions, sans connexion cloud : un Gateway est alors nécessaire pour les lire. Il conserve également l’historique et l’automatisation sur site pendant une coupure Internet.