Le workflow de lutte contre le vol d’énergie de Databricks transforme la détection en action gouvernée

Databricks a présenté un workflow de lutte contre le vol d’énergie qui relie les alertes de machine learning aux enquêtes, aux interventions sur le terrain, au suivi des recouvrements et au reporting de direction. Le problème est clair : les fournisseurs d’énergie peuvent détecter des comptes suspects, mais la détection seule ne permet ni de récupérer des revenus ni de sécuriser un compteur dangereux.

Le workflow de lutte contre le vol d’énergie de Databricks, publié le 15 septembre, recadre le problème autour des opérations. Il associe une Databricks App, Lakebase, Genie One, Unity Catalog, Unity Gateway, Model Serving et Agent Bricks. Ensemble, ces composants sont conçus pour faire passer un dossier d’un score de ML à une réponse métier gouvernée.

Cette promesse est soumise à une épreuve plus difficile que la précision du modèle. Les fournisseurs doivent distinguer le vol des pannes d’équipement, des erreurs de facturation, des consommations inhabituelles et des situations de clients vulnérables. Ils doivent également contrôler l’accès aux données énergétiques détaillées et préserver le jugement humain avant d’envoyer un technicien sur une propriété.

L’évolution importante n’est donc pas un nouveau modèle de détection du vol. C’est la tentative de Databricks de rendre les processus métier d’IA pour les fournisseurs d’énergie traçables, de l’analytique à la gestion des dossiers, à la préparation des interventions terrain et au reporting de gestion.

Le workflow de lutte contre le vol d’énergie de Databricks commence là où le modèle s’arrête

Databricks considère le score de risque comme le début d’une enquête, et non comme sa conclusion.

Le vol d’énergie implique généralement une intervention délibérée sur un compteur, une conduite, un câble ou un raccordement d’alimentation afin que la consommation ne soit pas enregistrée. Il se distingue d’une facture impayée parce que le système physique de fourniture d’énergie a été modifié. Cette distinction crée à la fois une exposition financière et une préoccupation immédiate en matière de sécurité.

Les fournisseurs d’énergie utilisent depuis longtemps des règles, la détection d’anomalies et le machine learning pour identifier des consommations inhabituelles. Un modèle peut signaler une baisse soudaine de l’usage, un schéma de compteur improbable ou un comportement qui diffère de celui de propriétés comparables. Toutefois, un score ne peut pas établir qui a modifié l’équipement, si une panne a provoqué le schéma observé ou quelle action est appropriée.

Le workflow proposé par Databricks commence après l’apparition de ce score. Une Databricks App présente le dossier à un analyste et ajoute un résumé généré par l’IA expliquant pourquoi le compte a été signalé. L’entreprise indique que Model Serving fournit cette interprétation, tandis que Unity Gateway gouverne l’accès au modèle sélectionné.

L’analyste peut ensuite prioriser le dossier et produire un rapport prêt pour l’intervention. Selon Databricks, le rapport peut inclure des éléments probants, les prochaines étapes recommandées, des informations de conformité et des notes de sécurité pour le technicien terrain.

Cela comble une lacune que les tableaux de bord conventionnels laissent ouverte. Un tableau de bord peut montrer quels comptes méritent une attention, mais un autre processus doit toujours attribuer le travail, rassembler les preuves, consigner les décisions et suivre le résultat. Ces transferts manuels impliquent souvent des feuilles de calcul, des e-mails, des fichiers de présentation et des systèmes de gestion de dossiers distincts.

Lakebase fournit la couche transactionnelle de la conception proposée. Une couche transactionnelle stocke des enregistrements opérationnels évolutifs, tels que le responsable actuel, le statut de l’enquête et le recouvrement confirmé. Elle diffère d’une table analytique principalement conçue pour les requêtes et le reporting historique.

Lorsqu’un analyste met à jour un dossier, l’application peut écrire cet état dans Lakebase avec une faible latence. Si un recouvrement est confirmé, Databricks indique que le total cumulé des recouvrements peut être actualisé immédiatement. Le modèle analytique et l’enregistrement opérationnel du dossier restent connectés sans obliger le tableau de bord à devenir un système de gestion de dossiers.

Cette architecture ne prouve pas que chaque fournisseur d’énergie devrait consolider son workflow sur Databricks. Elle précise toutefois ce que l’entreprise souhaite voir les acheteurs évaluer. L’unité pertinente n’est plus le modèle de détection du vol isolé. C’est l’ensemble du parcours, de l’alerte à l’action responsable.

Ce changement modifie également la façon dont les équipes mesurent le succès. La précision et le rappel restent importants, mais ils deviennent des éléments parmi d’autres aux côtés du temps d’enquête, de la capacité d’intervention, des cas confirmés, des revenus recouvrés, des résultats en matière de sécurité et du retour d’information transmis au modèle.

Pourquoi la lacune opérationnelle compte davantage qu’un nouveau gain de précision

Un modèle légèrement meilleur a une valeur limitée lorsque les cas réels restent bloqués dans des files d’attente ou des transferts incomplets.

Le vol d’énergie a des conséquences importantes au-delà de la perte de revenus des fournisseurs. Une estimation du coût du vol commandée par la Retail Energy Code Company a évalué l’exposition annuelle de la Grande-Bretagne à jusqu’à 1,4 milliard de livres sterling. Sa méthodologie estimait jusqu’à 1 069 GWh de gaz volé et 2 837 GWh d’électricité volée chaque année.

Ces estimations dépendent des prix de l’énergie et d’une méthodologie analytique ; elles ne doivent donc pas être considérées comme un décompte direct de vols avérés. Elles montrent néanmoins l’ampleur du problème opérationnel auquel sont confrontés les fournisseurs et les régulateurs.

Les données officielles de performance révèlent un deuxième enjeu. Ofgem a indiqué que les fournisseurs avaient confirmé 16 581 vols en 2022 et 2023, pour un objectif cumulé de 41 000. Cela ne représentait que 40 % de l’objectif.

Le régulateur a également fait état de 17 423 cas confirmés durant la période précédente, soit 42 % de l’objectif. Ces chiffres ne démontrent pas l’échec des systèmes de ML. Ils montrent que le système dans son ensemble n’a pas converti suffisamment d’activités suspectes en résultats confirmés.

L’examen du vol d’énergie d’Ofgem a décrit la performance globale des fournisseurs comme insuffisante. Il a également relevé que les signalements à Crimestoppers étaient passés d’environ 8 000 à plus de 12 000 entre deux périodes annuelles consécutives s’achevant en avril.

Ces conditions exercent une pression sur les responsables de la protection des revenus depuis plusieurs directions. Ils doivent améliorer le débit de traitement des dossiers sans submerger les enquêteurs de faux positifs. Ils doivent préparer les équipes terrain à des équipements potentiellement dangereux. Ils ont également besoin d’éléments probants défendables lorsqu’une enquête affecte un client.

Un simple score de risque constitue un fondement fragile pour ces décisions. Les analystes doivent savoir quels signaux ont influencé le score, si les données sous-jacentes sont à jour et quelles preuves font encore défaut. Le personnel de terrain a besoin d’instructions pratiques plutôt que d’une sortie de modèle dépourvue de contexte opérationnel.

C’est pourquoi les processus métier d’IA pour les fournisseurs d’énergie sont devenus plus importants que des démonstrations isolées. Le processus métier détermine si une prédiction utile reçoit l’attention nécessaire alors que l’information reste pertinente.

Databricks positionne sa plateforme face à des opérations fragmentées plutôt que face à un concurrent logiciel unique. La principale alternative est l’empilement familier de tableaux de bord analytiques, de dossiers préparés manuellement, d’outils de workflow distincts et de rapports de gestion assemblés a posteriori.

Cette approche fragmentée peut fonctionner, et de nombreux fournisseurs y recourent déjà. Sa faiblesse apparaît lorsque les équipes doivent réconcilier différentes définitions, autorisations, horodatages et statuts de dossiers. Un rapport peut comptabiliser un recouvrement avant sa validation par la finance, tandis qu’un autre système continue de classer le dossier comme ouvert.

L’approche de Databricks cherche à créer une chaîne gouvernée unique autour de ces événements. Elle pourrait réduire les délais et le travail de réconciliation. Le résultat dépendra toujours de la qualité de mise en œuvre, de l’intégration aux systèmes existants et d’une responsabilité rigoureuse pour chaque décision.

L’analyse du vol d’énergie avec Genie relie les questions à des métriques partagées

Le rôle le plus déterminant de Genie n’est pas la commodité conversationnelle, mais le contrôle du sens des métriques opérationnelles.

Les dirigeants posent naturellement des questions sur les montants recouvrés, les volumes d’enquêtes, les faux positifs et la performance régionale. La difficulté ne consiste pas à convertir une question en anglais en SQL. Elle consiste à s’assurer que chaque réponse utilise des définitions approuvées et respecte les droits d’accès de la personne qui pose la question.

Genie One est l’interface conversationnelle de Databricks pour les données métier. Dans le scénario de vol d’énergie, un responsable de la protection des revenus pourrait demander quelle valeur a été recouvrée ou quelles régions présentent les plus grandes files d’attente non résolues.

Databricks indique que Genie fonde ces réponses sur des définitions de métriques gérées via Unity Catalog. Une métrique telle que « revenus recouvrés » peut donc utiliser un calcul partagé plutôt qu’une requête improvisée créée pour une seule réunion.

Cette distinction compte. Un modèle peut estimer une perte évitée, un enquêteur peut enregistrer une valeur présumée et la finance peut ne reconnaître qu’un recouvrement validé. Qualifier les trois de « revenus recouvrés » produirait un tableau de bord impressionnant, mais de faible valeur décisionnelle.

Une couche sémantique gouvernée définit quels champs, filtres et calculs représentent un concept métier. L’analyse du vol d’énergie avec Genie traduit ensuite la question de l’utilisateur dans ce contexte approuvé. La conversation devient une autre interface vers des données gouvernées, plutôt qu’une demande sans restriction visant à parcourir toutes les tables disponibles.

Databricks propose également d’utiliser un Agent Bricks Multi-Agent Supervisor pour les rapports récurrents destinés à la direction. Selon l’entreprise, le superviseur peut coordonner les requêtes Genie et assembler une sortie prête pour le conseil d’administration. L’avantage recherché est un processus de reporting traçable qui réutilise des métriques approuvées.

C’est là que le workflow va au-delà d’une démonstration de gestion de dossiers. Il relie les opérations de première ligne aux chiffres présentés aux dirigeants. Un résultat confirmé sur le terrain peut mettre à jour l’état du dossier, influencer le reporting agrégé sur les recouvrements et, à terme, devenir un retour d’information pour l’évaluation du modèle.

La boucle peut également révéler plus rapidement les faiblesses des modèles. Si une région reçoit de nombreuses alertes à haut risque mais confirme peu de cas, les dirigeants peuvent se demander si la qualité des données, l’étalonnage du modèle, la capacité d’enquête ou les conditions locales expliquent l’écart.

Toutefois, l’accès en langage naturel ne supprime pas la responsabilité analytique. Genie peut exécuter un calcul approuvé alors que la métrique sous-jacente demeure incomplète ou mal conçue. Une définition cohérente peut encore produire un signal de gestion trompeur si les équipes ignorent les résultats différés ou le biais de sélection.

Par exemple, une précision calculée uniquement à partir des enquêtes achevées peut sembler meilleure lorsque les dossiers difficiles restent non résolus. Les totaux de recouvrement peuvent également favoriser les dossiers où les pertes sont faciles à mesurer, tout en sous-représentant les interventions de sécurité.

Une analyse utile du vol d’énergie avec Genie exige donc davantage qu’un comportement précis de conversion du texte en requête. Elle nécessite des définitions documentées, des fenêtres temporelles claires, des règles de maturité des résultats et une visibilité sur les enregistrements exclus.

Les équipes devraient également conserver la possibilité d’inspecter la manière dont une réponse a été produite. Databricks indique que les utilisateurs peuvent retracer le calcul à l’origine de la réponse de Genie. Cette fonctionnalité devient essentielle lorsque le résultat influence les budgets, les effectifs, la conformité des fournisseurs ou le traitement des clients.

La gouvernance doit s’étendre au compteur, au modèle et à la décision terrain

Une gouvernance centralisée réduit les accès non contrôlés, mais elle ne rend pas une recommandation automatisée équitable, légale ou correcte.

Des données de consommation détaillées peuvent révéler des schémas sur les moments où les personnes occupent une propriété, la façon dont elles utilisent leurs appareils et l’évolution de leur comportement. La combinaison de ces informations avec des dossiers de compte et des observations terrain soulève des préoccupations en matière de confidentialité et de sécurité.

Le cadre d’accès aux données du Royaume-Uni définit les niveaux d’accès aux données de consommation issues des compteurs intelligents. Il traite également des finalités autorisées et des choix proposés aux consommateurs.

Databricks indique que Unity Catalog peut étiqueter les champs contenant des informations personnellement identifiables, appliquer des contrôles d’accès, enregistrer la traçabilité et auditer les usages. La traçabilité montre l’origine des données et quelles transformations, quels modèles ou quels rapports les ont utilisés.

Unity Gateway fournit un autre point de contrôle pour les appels d’IA. Databricks affirme que les organisations peuvent l’utiliser pour appliquer des politiques au niveau des modèles, observer les usages et changer le modèle sous-jacent par configuration. Cette séparation peut aider les équipes à éviter de reconstruire l’application métier à chaque évolution de leur stratégie de modèles.

Ces capacités répondent à une faiblesse importante des projets d’IA improvisés. Un prototype peut envoyer des informations de compte à un modèle sans historique clair du prompt, de l’autorisation, de la réponse ou du coût. Une passerelle gouvernée peut rendre ces interactions visibles et appliquer des politiques communes.

Pourtant, les contrôles de plateforme ne résolvent qu’une partie du problème. Ils peuvent déterminer si un analyste est autorisé à consulter un champ. Ils ne peuvent pas décider si un schéma de consommation justifie un soupçon ni si une enquête traite le client équitablement.

Les faux positifs restent le risque central. La consommation peut diminuer parce qu’un résident voyage, déménage, modifie ses habitudes de chauffage, installe des équipements solaires ou subit une panne de compteur. Un modèle entraîné sur des enquêtes passées peut également hériter de pratiques d’application inégales.

La publication de Databricks laisse explicitement aux analystes et aux ingénieurs de terrain la responsabilité du jugement, de la conformité, de la relation client et de l’exécution physique. Cette limite est importante, car les enquêtes sur le vol d’énergie peuvent conduire à des visites de sites dangereuses et à de graves accusations.

La revue humaine doit être substantielle plutôt que cérémonielle. Un analyste doit pouvoir remettre en cause une recommandation, demander davantage de preuves, rétrograder un dossier et consigner les raisons du rejet de la suggestion du modèle.

Le rapport de mission exige également une conception rigoureuse. Les notes de sécurité peuvent aider un ingénieur à se préparer, mais des instructions générées automatiquement ne doivent pas remplacer les procédures terrain établies. Tout détail non étayé pourrait créer un risque sur la propriété.

La gouvernance devrait donc couvrir quatre enregistrements liés : les données sources, la version du modèle, la recommandation et la décision humaine finale. Un examinateur ultérieur devrait pouvoir reconstituer les informations disponibles et ce qui a changé après l’enquête.

Le cadre de gestion des risques liés à l’IA du NIST fournit une référence plus large utile. Il organise le travail sur les risques liés à l’IA autour de leur gouvernance, cartographie, mesure et gestion tout au long du cycle de vie du système.

Pour les services publics, ce cycle de vie se prolonge au-delà du déploiement. Les équipes doivent surveiller les schémas de faux positifs, les exceptions d’accès, la dérive des données, les dossiers non résolus et les réclamations clients. Elles ont également besoin d’un processus contrôlé pour mettre à jour les prompts, les définitions de métriques et les modèles.

Le test de gouvernance le plus difficile survient lorsque le système semble réussir. Un traitement plus rapide des dossiers peut encourager une automatisation plus large avant que les équipes ne comprennent qui fait l’objet d’un contrôle supplémentaire. Une montée en charge maîtrisée exige des preuves sur les résultats, et pas seulement sur l’utilisation.

La stratégie de plateforme face aux environnements fragmentés des services publics

Databricks parie que les services publics accorderont davantage de valeur à une boucle opérationnelle gouvernée unique qu’à un ensemble d’outils spécialisés individuellement.

L’architecture de l’entreprise réunit plusieurs charges de travail. Lakeflow prépare les données et les caractéristiques. Les services de machine learning entraînent et servent les modèles. Une Databricks App présente les tâches opérationnelles. Lakebase stocke l’état évolutif des dossiers. Genie répond aux questions métier, tandis que les agents préparent des rapports récurrents.

Cette consolidation peut réduire les frontières d’intégration, mais elle étend aussi le rôle de la plateforme. Databricks ne demande plus seulement à rester le socle analytique derrière une application de service public. L’entreprise propose d’héberger des parties de l’application opérationnelle et de ses processus métier d’IA.

L’approche concurrente utilise des composants spécialisés. Un service public peut conserver son entrepôt de données existant, son application de lutte contre la fraude, sa plateforme client, son système de gestion des interventions, son outil de reporting et son fournisseur de modèles. Chaque système peut être optimisé pour sa propre fonction.

Cette approche offre de la flexibilité et peut mieux correspondre aux responsabilités existantes. Elle peut également empêcher une plateforme unique de devenir le plan de contrôle des données, de l’IA, des applications et du reporting.

Son coût apparaît dans la coordination. Chaque frontière exige une correspondance des identités, des autorisations, des schémas, une logique d’intégration, une supervision et une réconciliation. Un signalement de modèle peut arriver sans contexte suffisant, tandis que les résultats terrain reviennent trop tard pour améliorer le cycle de notation suivant.

Le workflow de lutte contre le vol d’énergie de Databricks réduit certaines de ces frontières en gardant l’analytique et l’état opérationnel proches l’un de l’autre. L’entreprise affirme également que les clients peuvent changer le modèle routé via Unity Gateway sans repenser l’application environnante.

Cette flexibilité des modèles est importante, car les services publics ne devraient pas lier un workflow réglementé à un seul modèle de langage. Différentes tâches peuvent nécessiter des caractéristiques différentes en matière de latence, de coût, d’hébergement régional ou d’évaluation. La synthèse des dossiers et le reporting au conseil d’administration présentent aussi des profils de risque différents.

Cependant, « une seule plateforme » ne signifie pas « un seul système ». La répartition sur le terrain, la facturation, le service client, l’identité, la finance et le reporting réglementaire continueront d’impliquer des applications externes. La plateforme doit s’intégrer à ces systèmes de manière fiable.

La valeur de l’architecture dépendra donc de l’endroit où le service public trace les frontières de ses systèmes. Conserver l’état des dossiers dans Lakebase n’aide que si les autres systèmes reçoivent des mises à jour rapides et si les responsabilités restent claires.

Le même schéma peut s’étendre au-delà du vol. Databricks cite la maintenance prédictive, les sinistres d’assurance, la fraude aux paiements et l’intervention contre l’attrition comme applications possibles. Chacune commence par un signal de modèle et exige une séquence d’actions examinées.

Cette affirmation plus large est plausible sur le plan architectural. Ces quatre domaines impliquent tous la détection, la priorisation, l’état opérationnel et le retour d’information sur les résultats. Toutefois, une architecture partagée n’élimine pas les contrôles propres au domaine, les normes de preuve ou la conception des workflows.

Les processus métier d’IA destinés aux services publics sont particulièrement sensibles, car les décisions peuvent affecter la sécurité des ménages, le traitement des clients et les obligations réglementées. Un modèle réutilisable peut accélérer le développement, mais il ne devrait pas effacer ces différences.

Il existe également une contrainte organisationnelle. Une pile technique unifiée n’unifiera pas automatiquement la science des données, la protection des revenus, les opérations terrain, la conformité, la finance et la direction. Ces groupes doivent s’accorder sur la propriété des dossiers et les définitions des résultats.

La véritable question concurrentielle n’est donc pas de savoir si Databricks peut connecter ses produits. L’entreprise a montré un flux de référence cohérent. La question est de savoir si les services publics peuvent exploiter ce flux entre les équipes sans recréer des frontières manuelles au sein de la nouvelle plateforme.

Trois signaux montreront si l’action gouvernée fonctionne

Les prochaines preuves devront venir des résultats de production, et non d’une nouvelle démonstration de workflow soignée.

Le premier signal est l’adoption opérationnelle documentée. Les acheteurs devraient rechercher un service public nommé utilisant le workflow Databricks de lutte contre le vol d’énergie avec des dossiers en production, des intégrations d’entreprise existantes et des étapes de revue humaine définies.

Un exemple de production devrait préciser quelle partie du processus a migré vers Databricks. Il devrait distinguer la notation par modèle, le triage des dossiers, la préparation des interventions, la confirmation des recouvrements et le reporting à destination de la direction. Sans ce niveau de détail, « utiliser l’IA pour détecter le vol » révèle très peu de choses.

Les mesures les plus utiles incluraient le délai entre l’alerte et la revue par un analyste, le délai jusqu’à l’intervention, le taux de confirmation, l’arriéré de dossiers et le recouvrement validé. Les incidents de sécurité et les réclamations clients doivent également faire partie de l’évaluation.

Des preuves d’un traitement plus rapide avec une précision stable ou améliorée renforceraient l’argument de Databricks. Un débit plus élevé accompagné de davantage de faux positifs l’affaiblirait, même si le nombre total d’enquêtes augmentait.

Le deuxième signal est la qualité des preuves de gouvernance. Les services publics devraient vérifier si chaque recommandation peut être reliée à la version du modèle, aux données sources, au prompt, à la politique d’accès et à la décision de l’analyste.

Ils devraient également demander si les restrictions au niveau des lignes fonctionnent de manière cohérente dans Genie, les applications, les endpoints de modèles et les rapports exportés. Une table source sécurisée offre peu de protection si des synthèses générées ou des documents en aval exposent des informations restreintes.

Une assurance indépendante rendrait l’argument de gouvernance plus crédible. Elle pourrait inclure des résultats d’audit, une évaluation de modèle documentée, des analyses d’impact sur la vie privée et la preuve que les équipes ont testé les résultats auprès de différents groupes de clients.

Le troisième signal est de savoir si les résultats terrain améliorent le système. Une boucle fermée devrait renvoyer les vols confirmés, les pannes d’équipement, les visites non concluantes et les dérogations des analystes vers l’environnement analytique.

Ce retour peut révéler les domaines où le modèle fonctionne mal ou ceux où les contraintes opérationnelles faussent les résultats. Il peut également montrer si les synthèses générées par l’IA aident les enquêteurs ou se contentent de reformuler le score initial.

Les services publics devraient surveiller le délai entre une visite terminée et la mise à jour du modèle ou de la métrique. Une prétendue boucle fermée devient un autre pipeline de reporting lorsque les retours arrivent tardivement, ne disposent pas de libellés cohérents ou n’influencent jamais la priorisation.

Des données sectorielles plus larges rendent cette focalisation opérationnelle urgente. L’Agence internationale de l’énergie estime que les pertes non techniques sur les réseaux entraînent chaque année entre 80 et 100 milliards de dollars de pertes de revenus. Son analyse des réseaux intelligents associe également ces pertes à de graves risques de sécurité.

Cette estimation couvre un problème mondial plus vaste que la démonstration de Databricks. Elle inclut des marchés, des infrastructures, des réglementations et des schémas de vol variés. Aucun workflow unique ne peut répondre à toutes les causes.

Databricks a néanmoins identifié le bon point de pression. La détection crée une valeur potentielle, tandis que l’exécution gouvernée détermine si cette valeur devient réelle. Les services publics qui expérimentent déjà des modèles de détection du vol devraient examiner les transferts autour de ces modèles avant de financer une nouvelle amélioration de précision.

La prochaine étape pratique consiste à cartographier un dossier réel, de son premier signal jusqu’à sa résolution finale. Consignez chaque système, transfert manuel, responsable de décision, règle d’accès et délai de reporting. Testez ensuite si un workflow unifié élimine des frictions mesurables sans affaiblir la revue.

Le workflow Databricks de lutte contre le vol d’énergie devrait être jugé à l’aune de ces preuves opérationnelles. Peut-il réduire les délais de traitement des dossiers, préserver des décisions humaines responsables et produire des métriques auxquelles la finance et les régulateurs font confiance ? Ces résultats, plutôt que le nombre de composants d’IA dans l’architecture, détermineront si l’action gouvernée devient plus qu’une démonstration convaincante.