+150 XP

Du compteur intelligent à la télémétrie réseau : la stack data de l'énergie

# Du compteur intelligent à la télémétrie réseau : la stack data de l'énergie

Un seul foyer équipé d'un compteur intelligent génère 96 relevés par jour. À intervalles de 15 minutes, cela fait un relevé toutes les 900 secondes, mesurant les kilowattheures consommés. Multipliez par les quelque 130 millions de compteurs intelligents installés dans les foyers et entreprises américains (un chiffre qui progresse régulièrement depuis plus de dix ans), et vous obtenez un déluge de données qui se compte en téraoctets par jour.

Voici la vérité qui dérange : la plupart des utilities stockent presque tout et n'utilisent presque rien. Suivons un relevé pour comprendre pourquoi.

Le parcours d'un relevé

Voici la famille Nguyen. À 18h15, ils allument le four, la climatisation démarre et un véhicule électrique se met en charge dans le garage. Leur compteur enregistre l'énergie cumulée consommée sur cette fenêtre de 15 minutes.

Étape 1 : le compteur AMI

L'appareil au mur est un compteur AMI (Advanced Metering Infrastructure). Contrairement aux anciens compteurs analogiques à cadran relevés une fois par mois par un humain, les compteurs AMI enregistrent des données par intervalle et les transmettent automatiquement à l'utility, généralement via un réseau maillé sans fil ou une liaison cellulaire.

Le relevé des Nguyen est désormais un petit paquet : un identifiant de compteur, un horodatage, une valeur en kWh, et souvent un indicateur de qualité (le relevé était-il propre ou estimé ?).

Étape 2 : le head-end system

Le paquet part vers le head-end system (HES), le logiciel qui dialogue directement avec le parc de compteurs. Voyez-le comme un standard téléphonique. Son rôle est étroit mais critique :

  • Collecter les relevés de millions de compteurs.
  • Renvoyer des commandes (coupure à distance, mise à jour firmware, relevé à la demande).
  • Gérer les échecs de communication et les tentatives de reprise.

Le HES parle le protocole du compteur. Ce n'est pas là que l'analyse se fait. C'est de la plomberie.

Étape 3 : le meter data management system (MDM)

Prochain arrêt : le MDM (Meter Data Management system). C'est le système de référence pour les données de consommation. Le MDM fait le travail ingrat mais essentiel :

  • Validation, Estimation and Editing (VEE) : si le compteur des Nguyen a manqué un relevé, les règles VEE comblent le trou à partir des historiques, puis le marquent comme estimé.
  • Agrégation : consolidation des relevés de 15 minutes en totaux horaires, quotidiens et mensuels.
  • Billing determinants : production des chiffres propres dont le système de facturation a besoin.

Quand le relevé des Nguyen arrive au MDM, il a été vérifié, complété et standardisé. Ce sont ces données qui finissent sur leur facture.

Étape 4 : le côté réseau

La consommation n'est que la moitié du tableau. Le réseau lui-même est instrumenté avec sa propre télémétrie :

  • SCADA (Supervisory Control and Data Acquisition) : la colonne vertébrale traditionnelle qui surveille postes, disjoncteurs et départs, avec une interrogation typiquement toutes les quelques secondes.
  • PMU (Phasor Measurement Units) : des capteurs haute fréquence qui échantillonnent la phase de tension et de courant 30 à 60 fois par seconde, offrant aux opérateurs une vue quasi temps réel de la stabilité du réseau.

La stack data de l'énergie a donc deux fleuves : côté client (compteurs, MDM) et côté réseau (SCADA, PMU). Ils se rejoignent rarement.

Pourquoi les utilities se noient

Venons-en au problème central. Le relevé des Nguyen a servi à une chose : la facture. Ensuite, il dort dans une base de données.

Les données sont cloisonnées par construction

L'équipe facturation possède le MDM. L'équipe exploitation possède le SCADA. L'équipe planification possède encore un autre système. Chacun a été acheté séparément, souvent à des années d'écart, auprès de fournisseurs différents. Ils ne partagent pas de modèle de données commun.

Un exemple concret : savoir que le véhicule électrique des Nguyen charge à 18h15 pourrait aider l'équipe planification à décider si le transformateur local doit être renforcé. Mais les données de comptage vivent dans un silo et les données d'actifs dans un autre. Personne ne les relie.

Le volume est réellement difficile

Regardons le calcul brut pour une utility de taille moyenne :

1,000,000 meters
× 96 reads/day (15-min intervals)
= 96,000,000 reads/day
× 365 days
≈ 35 billion reads/year

Ajoutez plusieurs canaux par compteur (kWh livrés, kWh reçus du solaire en toiture, tension) et le compte se multiplie. La télémétrie réseau issue des PMU en ajoute bien davantage, car échantillonner 30 fois par seconde écrase un relevé de compteur toutes les 15 minutes. Stocker tout cela coûte peu. Le rendre interrogeable, propre et recoupé coûte cher.

La régulation détermine ce qui est exploité

Les utilities sont des monopoles régulés sur la majeure partie de leur territoire de desserte. Leurs revenus sont fixés dans le cadre de rate cases (procédures où un régulateur approuve ce que l'utility peut facturer). Historiquement, les régulateurs récompensaient la construction d'actifs physiques, pas l'extraction de valeur à partir des données. Les données ont donc été collectées pour satisfaire une obligation de facturation, et le business case pour aller plus loin restait faible.

Cela change à mesure que les régulateurs poussent la modernisation du réseau et les programmes côté demande, mais l'état d'esprit héritée persiste.

Ce que ces données pourraient débloquer

Quand les utilities relient vraiment les deux fleuves, le relevé des Nguyen prend une valeur qui dépasse largement la facture.

Détection des pertes non techniques

Comparez l'énergie livrée sur un départ à l'énergie facturée à tous les compteurs en aval. Un écart persistant peut signaler une manipulation de compteur, des compteurs défectueux ou du vol. Les données par intervalle rendent cela détectable.

Gestion de charge des transformateurs

Agrégez les relevés par intervalle de chaque foyer raccordé à un même transformateur. Si les Nguyen et trois voisins chargent tous leur véhicule électrique à 18h15, ce transformateur peut être en surcharge. Les utilities peuvent le repérer avant la panne plutôt qu'après.

Demand response et tarification dynamique

Les données par intervalle permettent les time-of-use rates et le demand response (rémunérer ou inciter les clients à déplacer leur consommation hors des heures de pointe). Sans données de comptage granulaires, rien de tout cela n'est mesurable ni équitable.

Détection des coupures

Un groupe de compteurs qui cesse brusquement d'émettre (messages « last gasp ») indique aux opérateurs exactement où se situe une coupure, souvent avant que les clients n'appellent.

Pour bien comprendre comment cette infrastructure de données est censée évoluer, la Grid Modernization Initiative du Department of Energy américain est un point de départ gratuit et crédible.

La stack qui émerge

Les utilities modernes tentent de casser les silos avec un data lake ou un lakehouse partagé : un stockage central où les données du MDM, les flux SCADA, les données météo et les registres d'actifs arrivent tous dans un format commun.

Au-dessus se trouve une couche analytique qui alimente des modèles de prévision, un digital twin (un modèle virtuel du réseau physique mis à jour avec la télémétrie en direct) et, de plus en plus, du machine learning pour la prédiction de charge.

Le blocage n'est plus vraiment technologique. C'est la gouvernance : s'accorder sur les définitions de données, la propriété, les droits d'accès et la confidentialité. Les données par intervalle sont sensibles. Elles peuvent révéler quand un foyer est présent, endormi ou en vacances, d'où des règles de protection des données (variables selon les juridictions) qui encadrent leur partage et leur monétisation.

Vérification des acquis

1. La leçon souligne que les utilities stockent presque toutes leurs données de compteurs intelligents mais n'en utilisent presque aucune. Qu'est-ce que cela illustre le mieux à propos de la stack data de l'énergie ?

2. Pourquoi le head-end system (HES) est-il décrit comme de la « plomberie » plutôt que comme le lieu où se fait l'analyse ?

3. Un relevé arrive avec un indicateur de qualité signalant qu'il est « estimé » plutôt que propre. Quel système est chargé de résoudre ces problèmes de qualité de données avant qu'il n'intègre le système de référence ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les réponses correctes sur ce qui distingue fondamentalement un compteur AMI d'un ancien compteur analogique à cadran.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les réponses qui décrivent correctement le flux et la répartition des responsabilités dans la stack data de l'énergie.

Sélectionnez toutes les réponses correctes.

Où se situe réellement la valeur

Repérez le schéma. Le parcours technique du compteur au MDM est largement un problème résolu. Le difficile est organisationnel et réglementaire.

Un modèle mental utile : la stack data de l'énergie a trois niveaux de maturité.

1. Collecter : obtenir les relevés de façon fiable. La plupart des utilities en sont là ou l'ont dépassé.

2. Nettoyer et stocker : VEE, agrégation, modèle de données commun. Beaucoup y travaillent.

3. Agir : recouper données client et données réseau pour piloter les décisions. Peu le font bien.

Les téraoctets ne sont pas le problème. Le problème, c'est que la valeur se trouve au niveau trois, alors que l'essentiel des dépenses et de la récompense réglementaire s'est historiquement arrêté au niveau un.

Pour un MBA qui lit ces lignes : l'opportunité dans la data énergie tient rarement à construire un modèle plus sophistiqué. Elle tient au travail ennuyeux mais à fort effet de levier de connecter des systèmes qui n'ont jamais été conçus pour se parler, et de bâtir le business case qui fera dire oui au régulateur.

Points clés

  • Un compteur, 96 relevés par jour. À l'échelle d'un parc national, cela représente des téraoctets par jour, mais l'essentiel n'est utilisé qu'une fois, pour la facturation.
  • Retenez les quatre arrêts : compteur AMI, puis head-end system, puis MDM pour les données client, plus SCADA et PMU pour la télémétrie réseau. Deux fleuves distincts qui fusionnent rarement.
  • Le goulot d'étranglement est organisationnel, pas technique. Les données vivent dans des silos fournisseurs détenus par des équipes différentes, sans modèle partagé. C'est en les reliant que se cache la valeur.
  • Les données par intervalle débloquent de l'argent réel : détection des pertes, gestion de charge des transformateurs, demand response et réponse plus rapide aux coupures, mais seulement quand les données client et réseau sont jointes.
  • La régulation dicte les comportements. Les utilities ont historiquement été récompensées pour construire des actifs, pas pour exploiter des données. À mesure que les obligations de modernisation du réseau se renforcent, le business case de l'analytique de niveau trois se consolide enfin.

Articles liés

Les articles récents du blog qui s'appuient sur cette leçon.