thingslog logo

Jeux de données pour entraîner l’IA générative à la gestion de l’eau non revenue

L’eau non revenue (ENR) — eau perdue avant d’atteindre les consommateurs en raison de fuites, de vols ou d’imprécisions de comptage — représente un défi majeur pour les opérateurs de réseaux d’eau. Les modèles d’IA générative (GANs, VAEs, Transformers) offrent un potentiel remarquable pour modéliser les pertes d’eau, détecter les anomalies et optimiser la gestion des réseaux. Mais leur performance dépend directement de la qualité et de la diversité des données d’entraînement disponibles. Ce guide présente les sources de données, les formats requis et les outils d’augmentation pour constituer un corpus d’entraînement robuste.

Table des matières

Timestamp Débit (L/s) Pression (kPa) Température (°C) Statut fuite (0/1)
2023-10-01 00:00:00 120.5 250.3 18.2 0
2023-10-01 00:15:00 118.7 248.9 18.1 0
2023-10-01 00:30:00 115.2 245.6 18.0 1

Exemple de format de données multivarié horodaté pour l’entraînement de modèles de détection de fuites

Format idéal des données pour l’IA générative ENR

Avant d’identifier les sources de données, il est utile de définir le format cible que les modèles d’IA générative requièrent pour la gestion de l’ENR :

  • Séries temporelles multivariées : débit, pression, consommation — horodatées avec une fréquence élevée (5 à 15 minutes) et sans lacunes importantes
  • Données topologiques du réseau : graphes de réseau (nœuds, arcs) représentant la structure physique de la distribution d’eau — essentiel pour la localisation des fuites
  • Étiquettes d’anomalies : marqueurs binaires ou multi-classes indiquant les événements de fuite, de fraude ou de défaillance capteur — souvent rares et difficiles à obtenir
  • Métadonnées contextuelles : conditions météorologiques, calendriers d’utilisation, informations sur les matériaux de tuyauterie — enrichissent le contexte pour la modélisation

1. Jeux de données publics

Les jeux de données publics constituent un point de départ accessible, bien que souvent insuffisants seuls pour les applications en production :

  • Réseaux exemples EPANET : EPANET (logiciel libre de modélisation hydraulique de l’US EPA) fournit des jeux de données sur des réseaux de distribution fictifs incluant débits, pressions et configurations de canalisations — utile pour simuler des scénarios de fuites et valider les algorithmes
  • Jeu de données BattLeDIM : issu de la compétition internationale BattLeDIM (Battle of the Leak Detection and Isolation Methods, 2020), ce jeu contient des données synthétiques et réelles d’un réseau de distribution avec des fuites étiquetées — référence internationale pour comparer les algorithmes de détection
  • Données OMS / OCDE / Eurostat : bases statistiques sur la qualité de l’eau, les taux d’ENR par pays et les indicateurs de performance des services — utiles pour contextualiser les modèles et établir des benchmarks sectoriels
  • Données météorologiques open-data (Météo-France) : pluviométrie, température, ETP — variables de contexte essentielles pour distinguer les variations de consommation normales des anomalies

2. Partenariats avec les opérateurs d’eau

Les données propriétaires issues des opérateurs sont parmi les plus précieuses — car elles reflètent les conditions réelles d’un réseau existant :

  • Accords de recherche avec les services des eaux : des municipalités et opérateurs comme Suez, Veolia ou les syndicats locaux collaborent parfois avec des laboratoires et startups pour la recherche sur la détection de fuites
  • Conformité RGPD : les données de consommation d’eau individuelle sont des données personnelles — toute collaboration requiert une base légale (intérêt légitime de recherche, accord de partage), une anonymisation et un encadrement par convention
  • Exemple international : le Public Utilities Board (PUB) de Singapour a collaboré avec des chercheurs pour développer des solutions d’IA pour la détection des fuites — modèle de partenariat public-recherche réplicable

3. Génération de données synthétiques

Quand les données réelles sont rares, la simulation hydraulique et les modèles génératifs permettent de créer des données synthétiques réalistes :

  • EPANET : simule les débits et pressions dans un réseau modélisé selon différents scénarios de fuites, de demande et de manœuvres de vannes — résultats exportables au format CSV pour l’entraînement
  • WaterGEMS (Bentley) : modélisation hydraulique commerciale plus avancée, permettant des simulations détaillées avec des réseaux de grande taille
  • SWMM (EPA) : modèle de gestion des eaux pluviales et des réseaux d’assainissement — génère des séries temporelles de débit et de niveau pour l’entraînement de modèles ENR sur les eaux usées
  • GANs et VAEs : après entraînement initial sur des données réelles (même limitées), ces modèles génératifs peuvent produire des exemples synthétiques supplémentaires qui reproduisent les distributions statistiques des données originales — technique d’augmentation très efficace

4. Capteurs IoT sur le terrain

Les capteurs IoT déployés sur les réseaux d’eau représentent la source de données en temps réel la plus précieuse et la plus directement exploitable :

  • Enregistreurs de données basse consommation (ThingsLog) : capturent en continu débit, pression et température sur le réseau, même dans des zones reculées sans alimentation électrique, grâce aux connectivités LoRaWAN et NB-IoT
  • Compteurs intelligents AMR/AMI : les compteurs d’eau communicants fournissent des données de consommation à haute résolution (15 minutes à 1 heure) — essentiels pour identifier les anomalies de consommation et les pertes apparentes
  • Capteurs de qualité de l’eau : sondes de pH, turbidité, conductivité et chlore résiduel — enrichissent le contexte pour la modélisation ENR et la détection des contaminations

5. Données historiques opérationnelles

Les archives des opérateurs constituent une mine d’informations rarement exploitée systématiquement :

  • Journaux de réparation : les historiques d’interventions sur ruptures de canalisations et réparations de fuites permettent d’étiqueter rétrospectivement les événements anormaux dans les séries temporelles historiques — créant ainsi des données d’entraînement étiquetées à partir des archives existantes
  • Relevés de compteurs historiques : combinés aux données IoT récentes, ils permettent d’identifier les évolutions à long terme du comportement hydraulique et les points de rupture dans les profils de consommation
  • Données météorologiques locales : les corrélations entre précipitations, température et comportement du réseau (pression, consommation) fournissent un contexte environnemental crucial pour les modèles

6. Plateformes cloud et edge computing

L’infrastructure de collecte, stockage et prétraitement des données joue un rôle crucial dans la qualité des jeux d’entraînement :

  • Edge computing : prétraitement local avant transfert vers le cloud — filtrage des valeurs aberrantes, compression des données et tampon local en cas de coupure réseau. Réduit les coûts de transmission et améliore la qualité des données.
  • Plateformes IoT cloud : ThingsLog, AWS IoT Core, Microsoft Azure IoT Hub, ThingSpeak — stockent et exposent les données des capteurs via des APIs standard (REST, MQTT) pour l’intégration dans les pipelines ML

7. Augmentation et prétraitement des données

Pour maximiser la valeur des données disponibles, plusieurs techniques d’augmentation sont applicables aux séries temporelles hydrauliques :

  • Augmentation temporelle : mise à l’échelle des amplitudes, déformation temporelle (time warping), injection de bruit gaussien — crée des variantes réalistes des séries originales
  • Génération synthétique ciblée : utiliser des GANs ou VAEs entraînés sur les données disponibles pour générer des exemples supplémentaires dans les zones sous-représentées (types de fuites rares, conditions météo extrêmes)
  • Prétraitement rigoureux : imputation des valeurs manquantes (interpolation linéaire ou krigeage), détection et correction des valeurs aberrantes, normalisation des échelles — étape critique pour garantir la qualité des données d’entraînement

ThingsLog comme source de données terrain

Les enregistreurs de données ThingsLog fournissent les séries temporelles de débit, pression et niveau qui constituent la base des modèles d’IA pour l’ENR. La plateforme cloud ThingsLog expose ces données via des APIs REST standard, permettant leur intégration dans des pipelines de traitement Python/R et des frameworks ML comme TensorFlow, PyTorch ou scikit-learn.

→ Voir aussi : IA générative pour réduire l’ENR | Réduire l’eau non revenue avec l’IoT

Foire aux questions

Quelle quantité de données est nécessaire pour entraîner un modèle de détection de fuites ?

Un minimum de 6 à 12 mois de données continues à résolution 15 minutes par DMA instrumentée est recommandé pour capturer les saisonnalités et les variations de comportement du réseau. Pour les modèles de localisation (qui nécessitent des données spatiales multi-points), un réseau d’au minimum 5 à 10 capteurs par DMA est recommandé. Les techniques d’augmentation et les données synthétiques (EPANET) peuvent compenser les lacunes d’historique.

Comment obtenir des données étiquetées de fuites pour l’entraînement supervisé ?

Les données étiquetées sont la principale difficulté dans ce domaine. Trois approches sont possibles : (1) récupération rétrospective des archives de réparation pour étiqueter les événements passés dans les séries temporelles historiques ; (2) simulation hydraulique (EPANET) pour générer des données synthétiques étiquetées avec différents types de fuites ; (3) approches non supervisées ou semi-supervisées qui n’ont pas besoin d’étiquettes — particulièrement adaptées aux VAEs et aux modèles de détection d’anomalies.

Les données IoT sont-elles suffisamment propres pour l’entraînement de modèles d’IA ?

Rarement sans prétraitement. Les défis courants incluent les valeurs manquantes (coupures réseau, changements de batterie), les valeurs aberrantes (transitoires de pression lors de manœuvres), la dérive des capteurs (recalibration périodique nécessaire) et les artefacts d’installation (débits parasites lors de la mise en service). Un pipeline de prétraitement robuste — détection d’anomalies, imputation, normalisation — est aussi important que le modèle d’IA lui-même.

Partager:

Facebook
LinkedIn

Autres articles