Mettre en place un conseil de gouvernance des données dans une utility

Un transformateur tombe en panne à 2 h du matin. Le système de gestion des pannes récupère l'âge de l'actif dans une base de données, l'historique de maintenance dans une deuxième, le nombre de clients dans une troisième. Les trois chiffres ne concordent pas. Le comptage indique que le numéro de série du transformateur a été mis hors service en 2019. L'exploitation réseau affirme qu'il est toujours sous tension et qu'il porte de la charge. Personne n'est propriétaire du désaccord. Ce n'est pas un cas d'école : les incohérences de registres d'actifs figurent parmi les causes racines les plus fréquentes des audits de rétablissement de panne retardés chez les utilities américaines cotcotTechnique de prompting qui amène un modèle de langage à produire des étapes de raisonnement intermédiaires avant de donner sa réponse finale, ce qui améliore la précision sur les tâches complexes.Voir la définition complète →ées, d'après les postmortems régulièrement cités dans les rapports de fiabilité de la NERC (North American Electric Reliability Corporation). La solution n'est pas une meilleure base de données. C'est une instance de gouvernance dotée de l'autorité nécessaire pour imposer une décision.

Pourquoi les utilities en ont particulièrement besoin

Les utilities détiennent des données avec, par construction, trois propriétaires concurrents :

• Le comptage s'intéresse au point de comptage : consommation, intervalles, flags de fraude.
• Le commercial (facturation, opérations client) s'intéresse au compte client rattaché à ce point de comptage.
• L'exploitation réseau s'intéresse à l'actif physique : le transformateur, le départ ou le poste derrière lequel se trouve le compteur.

Ces trois vues décrivent le même objet du monde réel mais vivent dans des systèmes différents : un Meter Data Management System (MDMS), un Customer Information System (CIS), et un Geographic Information System (GIS) ou un système de gestion d'actifs (souvent bâti sur des outils comme IBM Maximo ou SAP PM). Quand une équipe terrain remplace un transformateur, quelqu'un doit mettre à jour les trois, dans le bon ordre, sinon les systèmes en aval (facturation, cartes de pannes, prévision de charge) divergent silencieusement.

Aucune équipe n'a l'autorité d'obliger les deux autres à corriger leur côté. C'est là le trou de gouvernance.

Ce qu'est réellement un conseil de gouvernance des données

Un conseil de gouvernance des données (parfois appelé data stewardshipdata stewardshipUn responsable côté métier, garant de la qualité, de la cohérence et du bon usage des données de son domaine.Voir la définition complète → board) est une instance permanente et transverse, dotée d'une autorité formelle pour :

1. Définir quel est le système de référence (system of record) pour chaque domaine de données (la source autoritative quand les copies divergent).
2. Approuver ou rejeter les évolutions des modèles de données partagés (par exemple l'ajout d'un champ « statut de l'actif » que le GIS et le CIS doivent tous deux respecter).
3. Arbitrer les litiges lorsque deux équipes revendiquent la propriété ou un droit de veto.
4. Fixer des seuils de qualité de données et valider les plans de remédiation.

Cela se distingue de la gouvernance IT (qui gère les systèmes et l'infrastructure) et d'une fonction conformité (qui gère les obligations réglementaires). Le conseil détient le *sens métier et l'autorité* sur les données, pas les tuyaux dans lesquels elles circulent.

Charte : les quatre points qu'elle doit spécifier

Une charte qui fait l'économie d'un de ces quatre éléments échouera en moins d'un an.

1. Périmètre. Nommez explicitement les domaines de données : données de référence des actifs, données de point de comptage, données client, données de panne. Un périmètre vague (« toutes les données de l'utility ») produit un conseil qui ne se réunit jamais, parce que personne ne sait si son sujet est éligible.

2. Droits de décision. Utilisez un découpage simple de type RACI (Responsible, Accountable, Consulted, Informed) par domaine. Exemple :

3. Chemin d'escalade. Définissez ce qui se passe quand les deux propriétaires accountable ne sont pas d'accord, par exemple lorsque l'exploitation réseau déclare un transformateur déclassé alors que le comptage affiche encore des relevés actifs. Le chemin est typiquement : niveau data steward (groupe de travail hebdomadaire), puis niveau conseil (mensuel), puis sponsor exécutif (CIO, CDO ou COO) si le sujet reste non résolu au bout d'un nombre de jours fixé, couramment 10 à 15 jours ouvrés dans les programmes matures.

4. Cadence et quorum. Réunions mensuelles du conseil, triage hebdomadaire des stewards, quorum défini (par exemple au moins un propriétaire accountable par domaine plus un représentant conformité ou privacy).

Rôles : qui siège à la table

• Chief Data Officer (CDO) ou équivalent, préside le conseil. Une enquête Gartner de 2023 (benchmark largement cité, chiffres approximatifs) indiquait que plus de 80 % des grandes entreprises avaient nommé un CDO, même si les utilities sont en retard sur les autres secteurs pour donner à ce rôle une véritable autorité.
• Data stewards, un par domaine (comptage, commercial, exploitation réseau, ingénierie des actifs). Ce sont des opérationnels qui corrigent les enregistrements au quotidien, pas des dirigeants.
• Data owners, responsables de département, accountable de l'exactitude de leur domaine.
• Représentant privacy / conformité, garantit que les décisions respectent les contraintes réglementaires (voir section suivante).
• Représentant IT / architecture, sans droit de vote dans la plupart des modèles, conseille sur la faisabilité technique.
• Sponsor exécutif, tranche les égalités et prend en charge les escalades que le conseil ne peut pas résoudre.

Les garde-fousgarde-fousRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → réglementaires que le conseil doit respecter

Aux États-Unis comme dans l'UE, les décisions de gouvernance ne se prennent pas dans le vide : elles s'inscrivent dans des règles contraignantes.

• Les standards NERC CIP (Critical Infrastructure Protection), obligatoires pour les propriétaires du bulk power system américain, exigent des contrôles d'accès et une gestion du changement documentés pour les données liées aux actifs critiques du réseau. Une décision du conseil de « fusionner » deux enregistrements d'actifs doit préserver la piste d'audit exigée par CIP-010.
• Les lois d'État sur la protection des données, par exemple le California Consumer Privacy Act (CCPA), encadrent les données d'usage client (comme les relevés de compteur par intervalle, qui révèlent les habitudes d'occupation).
• Le Règlement général sur la protection des données (RGPD) de l'UE, pour les utilities européennes, considère les données fines de compteurs intelligents comme des données personnelles dès lors qu'elles sont rattachables à un foyer, ce qui impose une base légale documentée et la minimisation des données.
• Le code de réseau européen / les règles d'échange de données ENTSO-E régissent la manière dont les gestionnaires de réseau de transport partagent les données d'actifs et de réseau au-delà des frontières.

Le chemin d'escalade du conseil doit toujours router les litiges signalés privacy (ce jeu de données contient-il des données personnelles, peut-il être partagé entre équipes) vers le représentant conformité avant qu'une décision métier ne soit arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êtée. Pour une présentation en langage clair des dispositions du RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète → les plus pertinentes pour les utilities, voir les orientations du Comité européen de la protection des données.

Exemple traité : résoudre le litige du transformateur

Retour à la panne de 2 h du matin. Voici comment le processus du conseil la résout en pratique :

1. Le technicien terrain signale l'incohérence via un ticket qualité de données.
2. Les data stewards du comptage et de l'exploitation réseau font le triage hebdomadaire : l'exploitation réseau confirme via le GIS que le transformateur a été physiquement remplacé en 2019 ; le comptage confirme que son enregistrement pointe toujours vers l'ancien numéro de série.
3. Cause racine : le workflow de déclassement n'a jamais déclenché de mise à jour automatique du MDMS. C'est un trou de processus, pas une erreur de saisie.
4. Décision du conseil (selon le tableau RACI) : le GIS est le système de référence pour le statut des actifs, donc le MDMS doit être corrigé pour s'y aligner. Mais le conseil impose aussi un correctif d'intégration : les événements de déclassement dans le GIS devront désormais publier un événement automatique vers le MDMS.
5. Le sponsor exécutif approuve le budget du correctif d'intégration pour le prochain cycle de sprint.

Un contrôle simple que tout analyste peut lancer avant d'escalader un litige de ce type est une requête de réconciliation d'enregistrements :

SELECT g.asset_id, g.status AS grid_status, m.asset_id, m.status AS meter_status
FROM gis_assets g
FULL OUTER JOIN mdms_assets m ON g.serial_number = m.serial_number
WHERE g.status != m.status OR g.status IS NULL OR m.status IS NULL;

Ce type de contrôle de réconciliation, exécuté de façon planifiée (quotidienne ou hebdomadaire), constitue l'audit pratique qui alimente l'agenda du conseil, plutôt que de le remplacer.

Contrôles et audits pratiques que le conseil doit imposer

• Audits de réconciliation inter-systèmes, trimestriels, comparant les comptages et statuts d'actifs entre GIS, MDMS et CIS.
• Revue des logs d'accès, liée aux exigences NERC CIP, confirmant que seuls les rôles autorisés ont modifié les enregistrements d'actifs critiques.
• Documentation du data lineage, retraçant l'origine d'un champ comme « statut du compteur » et chaque système qu'il traverse, pour qu'un litige puisse être remonté à sa source en minutes, pas en jours.
• Analyses d'impact relatives à la protection des données (PIA), exigées par le RGPD pour les traitements à haut risque, déclenchées automatiquement dès que le conseil approuve un nouvel usage de données de comptage fines.

Points clés

• Le travail central d'un conseil de gouvernance est d'attribuer des droits de décision, pas de construire des dashboards : désignez un système de référence pour chaque domaine de données partagé (actif, compteur, client).
• La charte doit spécifier le périmètre, les droits de décision (RACI), un chemin d'escalade avec des délais et une cadence de réunion, sinon elle ne survivra pas au premier litige réel.
• Faites passer tout litige touchant aux données d'usage client par un représentant privacy / conformité en premier ; le RGPD comme le CCPA considèrent les données de comptage fines comme sensibles.
• Les standards NERC CIP exigent une piste auditable pour les modifications des enregistrements d'actifs critiques du réseau ; les décisions du conseil doivent préserver cette piste, pas la contourner.
• Automatisez les contrôles de réconciliation (requêtes inter-systèmes, revues de logs d'accès) pour que le conseil passe son temps à arbitrer de vrais conflits de propriété, pas à courir après des fautes de saisie.