Une feuille de route pratique pour l’eau numérique : partir du problème, et non de la plateforme

Pourquoi partir du problème

L’eau numérique, c’est la numérisation des actifs et des procédés liés à l’eau : des capteurs, des communications, des plateformes de données et des outils d’analyse qui rendent leurs données accessibles pour une analyse plus rapide, une surveillance à distance et des décisions plus simples. La technologie est mature et largement accessible. Le plus difficile est de décider quoi mesurer, de se fier à ce qui est mesuré et de mettre le résultat devant la personne qui peut agir.

Un bon test consiste à vous demander si vous pouvez énoncer le problème en une phrase, en termes d’exploitation. « Ce sont les citoyens qui nous apprennent que les réservoirs débordent. » « Nous ne pouvons pas dire quelles pompes s’éloignent de leur point de fonctionnement. » « L’eau non facturée est élevée, mais nous ignorons où elle se perd. » Chacune de ces phrases suppose des mesures différentes, une connectivité différente et un tableau de bord différent. Une plateforme achetée avant que cette phrase n’existe a tendance à accumuler des données que personne n’a demandées.

Une approche par étapes

La séquence ci-dessous convient à une seule station de traitement, à un réseau de pompage ou à une installation industrielle. Dans la pratique, les étapes se chevauchent, mais leur ordre compte : chacune dépend de la qualité de la précédente.

Phase 1 : évaluer

Commencez par un inventaire de ce qui existe déjà : instruments, automates programmables industriels (API, ou PLC), RTU, SCADA, historiens de données et liaisons de communication. De nombreux systèmes canadiens combinent des équipements issus de plusieurs décennies, des panneaux à relais et des enregistreurs à papier jusqu’aux API modernes. Attendez-vous donc à un portrait hétéroclite et prévoyez de l’intégrer plutôt que de le remplacer. Parlez ensuite aux gens qui exploitent le système. Les opérateurs et le personnel d’entretien savent quelles lectures sont fiables et lesquelles ils ignorent, une information qu’aucun plan ne contient.

À partir de ces conversations, retenez de trois à cinq cas d’utilisation et définissez l’indicateur clé de performance (ICP) que chacun doit améliorer, par exemple l’énergie spécifique en kWh/m³, les arrêts non planifiés, l’eau non facturée ou le nombre d’alarmes par opérateur par heure. Consignez d’abord la valeur actuelle. Sans valeur de référence, aucune amélioration ultérieure ne peut être démontrée. Les livrables sont une liste hiérarchisée de cas d’utilisation, une analyse des écarts et une esquisse de l’architecture cible.

Phase 2 : qualité de l’instrumentation et connectivité

Un tableau de bord ne vaut que par le capteur qui l’alimente. Avant d’ajouter quoi que ce soit, vérifiez que les instruments existants conviennent à l’application, qu’ils sont correctement installés, mis à l’échelle dans les bonnes unités et étalonnés selon un calendrier. Les débitmètres électromagnétiques exigent une conduite pleine et une longueur droite suffisante. Les capteurs de niveau à ultrasons éprouvent des difficultés avec la mousse et la condensation. Un transmetteur de pression étalonné pour 100 m donnera des lectures grossières sur un système de 20 m. Marquez les données douteuses au moyen d’indicateurs de qualité (hors plage, figée, en pointe) au lieu de les laisser circuler en silence jusque dans les rapports.

Faites ensuite correspondre la liaison de communication aux données :

• Les liaisons SCADA existantes (fibre optique, radio sous licence, réseau cellulaire) pour la commande et les données qui varient rapidement.
• Les réseaux étendus à faible consommation, comme LoRaWAN, pour la surveillance à faible débit d’appareils alimentés par pile et répartis sur de nombreux sites. Voir LoRaWAN pour les services d’eau.
• Le réseau cellulaire lorsqu’un site dispose d’électricité, mais d’aucune autre liaison.

Pesez la fréquence de mise à jour, la latence, la disponibilité de l’alimentation électrique, la couverture, la propriété du réseau et le coût récurrent. Au Canada, les longues distances entre les sites et la couverture cellulaire inégale en région rurale et éloignée tranchent souvent la question, et les conditions hivernales influent à la fois sur les instruments (gel, glace, condensation) et sur l’autonomie des piles. Les protocoles normalisés comme Modbus, DNP3, OPC UA et MQTT gardent les options ouvertes.

Phase 3 : plateforme de données, tableaux de bord et indicateurs clés

La plateforme peut être un prolongement du SCADA et de l’historien existants, une base de données chronologiques, un service infonuagique ou une combinaison de ces éléments. Quel que soit le choix, quelques principes s’appliquent :

• Conservez un seul modèle de référence des actifs et des points de données, avec les unités, les plages techniques et la hiérarchie.
• Stockez les données brutes horodatées et documentez la façon dont chaque ICP est calculé.
• Exigez des interfaces ouvertes et le droit d’exporter vos données.
• Décidez où les données seront hébergées. De nombreux services d’eau et exploitants industriels canadiens préfèrent conserver leurs données d’exploitation au Canada, ou y sont tenus par leurs propres politiques ; demandez donc à tout fournisseur de plateforme quelles régions d’hébergement il offre.
• Rendez le trajet entre les systèmes de commande et la plateforme en lecture seule, afin que l’analyse ne puisse pas perturber l’exploitation.

Concevez les tableaux de bord en fonction des rôles, et non de l’exhaustivité. Les opérateurs ont besoin de l’état en direct et d’alarmes claires. Les superviseurs de l’entretien ont besoin d’un portrait hiérarchisé du travail à faire. Les gestionnaires ont besoin d’un petit nombre de tendances. La conception des alarmes mérite une attention particulière : un système qui déclenche des centaines d’alarmes de faible valeur apprend aux gens à les ignorer toutes. Les lignes directrices ISA-18.2 et EEMUA 191 sur la gestion des alarmes constituent une référence solide pour rationaliser les alarmes.

Phase 4 : analyse

Commencez par une logique simple et explicable : seuils, vérifications de la vitesse de variation et bilans massiques, comme le débit entrant comparé au débit sortant. Passez aux valeurs de référence statistiques une fois la qualité des données établie. Recourez à l’apprentissage automatique lorsque les données et les résultats consignés sont assez nombreux pour le justifier. Notre article sur la surveillance de l’état des pompes montre à quoi ressemble cette progression dans la pratique.

Personnel, formation et cybersécurité

Deux fils conducteurs traversent chacune des phases. Le premier est le personnel. Quelqu’un doit assumer la qualité des données, quelqu’un doit assumer l’étalonnage des capteurs, et les procédures d’exploitation doivent préciser qui intervient et pour quoi. Les opérateurs qui comprennent comment lire une tendance feront confiance au système ; ceux qui n’y ont pas été associés le contourneront. La formation fait partie du budget et n’est pas un détail de dernière minute.

Le second est la cybersécurité. Connecter des actifs accroît l’exposition ; il faut donc concevoir la sécurité en conséquence dès le départ : séparer les technologies opérationnelles (TO) de la TI de l’entreprise, utiliser un accès à distance selon le principe du moindre privilège avec authentification multifacteur, tenir un inventaire des actifs, prévoir les correctifs et les sauvegardes, et gérer correctement les clés des appareils sans fil. IEC 62443 est la principale série de normes internationales sur la sécurité des systèmes d’automatisation et de commande industriels.

Pièges courants

• Acheter d’abord la plateforme. C’est le cas d’utilisation qui doit dicter l’outil, et non l’inverse.
• Construire des tableaux de bord plutôt que des décisions. Chaque écran devrait répondre à une question que quelqu’un se pose réellement.
• Se fier à des capteurs non vérifiés. De mauvaises données dans un bon tableau de bord sont pires que l’absence de tableau de bord.
• Ne nommer aucun responsable des données. La qualité des données se dégrade si personne n’en est nommément responsable.
• Ignorer ce qui fonctionne déjà. Les API et le SCADA existants détiennent souvent la plupart des données dont vous avez besoin. Connectez-les avant de les remplacer.
• Ne compter que le coût en capital. La connectivité, les licences, l’étalonnage et l’assistance technique reviennent chaque année.
• Lancer un projet pilote sans voie vers le déploiement. Décidez d’avance comment un projet pilote réussi serait étendu.
• Repousser la sécurité à une phase ultérieure. Il coûte beaucoup moins cher de la concevoir dès le départ que de l’ajouter après coup.

Commencer petit et convenir de la ligne d’arrivée

Choisissez un site ou un problème. Convenez de trois à cinq mesures, des critères de réussite et d’une date de revue avant de commander quelque matériel que ce soit. Menez le projet pilote assez longtemps pour observer la variation normale, y compris, si possible, un changement saisonnier ou une variation de la demande, puis décidez de l’étendre, de l’ajuster ou d’y mettre fin. Un petit projet pilote évalué honnêtement vaut mieux qu’un vaste déploiement qui ne l’est pas.