La data readiness, facteur décisif

Deux utilities américaines de taille moyenne testent la même année l'outil d'AI meter-analytics du même fournisseur, sur le même logiciel, paramétré par la même équipe d'intégration. L'une réduit ses pertes non techniques de plus de 10 % en six mois. L'autre 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 →ête discrètement le pilote au bout d'un an, en blâmant « l'algorithme ». L'algorithme était identique. Ce qui différait, ce sont les données qui l'alimentaient.

C'est le schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → qui se répète dans le secteur : le modèle échoue rarement de lui-même. C'est le pipeline de donnéespipeline de donnéesSéquence automatisée d'étapes qui déplace les données de la source vers la destination : ingestion, transformation, validation et chargement, pour qu'elles arrivent propres et prêtes à l'emploi.Voir la définition complète → en amont qui lâche.

Pourquoi la data readiness prime sur le choix du modèle

Les modèles d'IA pour la prévision de charge, la prédiction de panne ou la détection de fraude ne valent que par trois conditions amont :

1. Granularité : la fréquence et la précision de capture des données (relevés par intervalles de 15 minutes contre relevés de facturation mensuels).
2. Qualité : complétude, exactitude des timestamps et cohérence des flux SCADA (Supervisory Control and Data Acquisition, le système temps réel avec lequel les opérateurs supervisent et pilotent les équipements réseau) et AMI (Advanced Metering Infrastructure, les compteurs communicants et le réseau de communication qui remplacent le relevé manuel).
3. Intégration : la capacité à joindre effectivement les données compteur, SCADA, GIS (Geographic Information System, qui cartographie spatialement les actifs réseau) et CRMCRMCustomer Relationship Management : logiciel et stratégie pour gérer et analyser les interactions clients tout au long de leur cycle de vie.Voir la définition complète → (Customer Relationship Management) sur un identifiant d'actif commun.

Un modèle de prévision entraîné sur des données AMI propres à 15 minutes avec moins de 2 % de relevés manquants surpassera le même modèle alimenté par des relevés mensuels comportant 15 % de trous, qu'il s'agisse d'un gradient boosted tree ou d'un réseau de neurones. Les équipes ML des utilities le constatent souvent à la chute brutale de la feature importance quand la complétude des données baisse, ce qui est exactement ce qui s'est produit dans le pilote défaillant ci-dessus.

Le Grid Modernization Lab Consortium du Department of Energy américain l'a documenté à de multiples reprises : les pilotes qui échouent invoquent des « limites de l'IA » dans leurs post-mortems, mais l'analyse forensique identifie le plus souvent comme cause racine la latence des données, des pings compteur manquants ou des incohérences non résolues d'identifiants d'actifs.

La comparaison des deux utilities, décortiquée

Utility A (pilote réussi) :

• Déploiement AMI achevé depuis plusieurs années, données par intervalles de 15 minutes, plus de 98 % de fiabilité des pings compteur
• Données SCADA et AMI jointes via un référentiel d'actifs commun
• Historiques de pannes nettoyés et normalisés avant le lancement du pilote

Utility B (pilote échoué) :

• Parc de compteurs hétérogène : une partie AMI, une partie encore en anciens compteurs AMR (Automated Meter Reading, communication unidirectionnelle, fréquence plus faible) en cours de remplacement
• Données SCADA cloisonnées dans un système séparé, sans clé d'actif partagée
• Historiques de pannes saisis manuellement par les équipes terrain, avec un formatage incohérent

Le modèle d'Utility B n'était pas faux. Il était affamé. La leçon se généralise : avant d'évaluer un fournisseur d'IA, auditez d'abord votre propre patrimoine de données.

Une checklist de data readiness opérationnelle

Avant de valider un pilote, posez ces questions :

• Granularité : quel est l'intervalle de relevé ? Des données de facturation mensuelles ne peuvent pas soutenir une prévision de charge en temps réel ni une détection rapide de panne, seules des données par intervalles de niveau AMI le peuvent.
• Complétude : quel pourcentage de compteurs remonte de façon fiable ? En dessous d'environ 90-95 % de fiabilité de ping, la plupart des fournisseurs vous diront que les résultats se dégradent fortement, même si le seuil exact varie selon le cas d'usage.
• Latence : les données sont-elles disponibles en quasi temps réel, ou arrivent-elles par lots quelques heures ou jours plus tard ? La prédiction de panne exige la première option.
• Rattachement aux actifs : un relevé de compteur peut-il être joint à un transformateur, un départ ou un poste précis dans votre GIS ? Sans cela, l'analytics de cause racine ne peut pas localiser les problèmes.
• Profondeur historique : disposez-vous d'au moins 12 à 24 mois d'historique propre pour entraîner et valider un modèle sur les cycles saisonniers ?

Une illustration chiffrée simple

Supposons qu'une utility veuille estimer les économies potentielles d'un outil de détection de pertes piloté par IA, qui signale les probables fraudes au compteur ou pertes non techniques.

Hypothèses (illustratives, non liées à un fournisseur) :

• Chiffre d'affaires annuel de distribution : 200 millions de dollars
• Pertes non techniques estimées : 3 % du chiffre d'affaires = 6 millions de dollars (les taux de pertes varient fortement selon l'utility et le pays ; les utilities américaines affichent généralement des taux inférieurs à certains marchés émergents, c'est un exemple simplifié)
• Le fournisseur affirme que l'outil peut récupérer 30 % des pertes détectées la première année

Récupération attendue en première approche : 6 M$ x 30 % = 1,8 million de dollars.

Mais ce chiffre de 30 % suppose des données AMI propres et granulaires en entrée du modèle. Si seuls 60 % du territoire desservi sont couverts en AMI (le reste encore en compteurs AMR à relevé manuel), la base adressable réaliste se réduit :

6 M$ x 60 % (couverturecouvertureLe nombre de personnes uniques exposées à votre message sur une période donnée. Contrairement aux impressions, le reach compte chaque personne une seule fois, quel que soit le nombre d'expositions.Voir la définition complète → AMI) x 30 % (taux de récupération) = 1,08 million de dollars.

Soit une décote de 40 % sur le business case, entièrement due à l'infrastructure de comptage, et non à quoi que ce soit que le fournisseur d'IA maîtrise. C'est le calcul que les utilities sautent systématiquement dans leurs projections de ROIROIReturn on Investment : le rapport entre le profit net et le coût d'un investissement. Un ROI de 300 % signifie que chaque dollar investi en rapporte 3.Voir la définition complète → (Return on Investment), et c'est la raison la plus fréquente pour laquelle les pilotes tiennent moins que ce que promettent les decks commerciaux.

À quoi ressemble une bonne infrastructure de données en pratique

Un schéma minimal et illustratif pour joindre données compteur et SCADA autour d'une clé d'actif commune :

meter_id | timestamp           | kwh_interval | asset_id | ping_status
--------------------------------------------------------------
MTR-0091 | 2026-01-14T08:00:00 | 4.2          | FDR-014  | ok
MTR-0091 | 2026-01-14T08:15:00 | null         | FDR-014  | missed
SCADA_asset_id | feeder_load_mw | timestamp
-------------------------------------------
FDR-014        | 3.8            | 2026-01-14T08:00:00

La colonne asset_id est la clé de voûte. Sans elle, les anomalies au niveau compteur ne peuvent jamais être remontées jusqu'à un départ ou un transformateur précis pour un diagnostic de cause racine. Cette jointure représente souvent le premier poste de coût d'intégration d'un pilote, supérieur à la licence du logiciel d'IA lui-même.

Contexte réglementaire et normatif

Aux États-Unis, les exigences de granularité des données se forment indirectement, via les dossiers tarifaires des Public Utility Commissions (PUC) d'État qui approuvent la récupération des investissements AMI, et non par un mandat fédéral unique sur l'IA. En Europe, le Clean Energy Package de l'UE a poussé les États membres vers un déploiement quasi universel des compteurs communicants, des pays comme l'Italie et la Suède atteignant une forte pénétration AMI il y a plusieurs années (les pourcentages exacts varient selon le pays et l'année, à traiter comme des estimations), tandis que d'autres restent à la traîne. Ce point de départ inégal signifie qu'un même fournisseur d'IA démarchant les marchés américain et européen fait face à des situations de données radicalement différentes, ce qui doit directement orienter le périmètre du pilote et les délais attendus.

Évaluer les fournisseurs au regard de votre maturité data réelle

Quand un fournisseur présente les résultats obtenus chez son « client de référence », demandez précisément :

• Quel était le pourcentage de couverture AMI de ce client ?
• Quelle fiabilité de ping et quel intervalle de relevé caractérisaient les données d'entraînement ?
• Accepteront-ils de mener un audit de data readiness sur vos systèmes avant d'annoncer une performance attendue ?

Un fournisseur qui refuse de nuancer ses promesses de performance en fonction de votre maturité data est un signal d'alerte. Les acteurs sérieux (Itron, Landis+Gyr ou Oracle Utilities sur le segment meter-analytics) intègrent de plus en plus une phase d'assessment de qualité des données dans le contrat de pilote lui-même, précisément parce que cet écart a fait échouer beaucoup de déploiements antérieurs.

Points clés

• La data readiness, et non la sophistication de l'algorithme, détermine en premier lieu le succès d'un pilote IA dans les utilities. Auditez granularité, complétude, latence et rattachement aux actifs avant d'évaluer les fournisseurs.
• Les trous de couverture AMI réduisent directement le ROI réaliste. Intégrez le pourcentage de couverture dans vos calculs d'économies, pas seulement le taux de récupération affiché par le fournisseur.
• La jointure par asset ID entre données compteur, SCADA et GIS est généralement l'étape d'intégration la plus difficile et la plus coûteuse, souvent plus chère que la licence du logiciel d'IA.
• Le contexte réglementaire diffère nettement entre les États-Unis (déploiement AMI piloté État par État par les PUC) et l'UE (comptage communicant quasi universel porté par le Clean Energy Package), les attentes sur un pilote doivent donc être calibrées sur la maturité locale du comptage.
• Exigez de la transparence du fournisseur : demandez les conditions de données derrière tout résultat client de référence, et accueillez avec scepticisme les promesses de performance sans réserve.