Logiciels de l’eau

// Le problème

Un service d’eau et d’eaux usées envoie ses factures par la poste, encaisse les paiements par chèque et au comptoir, et annonce les avis d’ébullition et les interruptions par téléphone et sur les réseaux sociaux, si bien que les clients appellent pour savoir ce qui se passe.

// Ce que nous bâtirions

Un portail client à l’image du service où les clients voient leur consommation et leurs factures, paient en ligne et s’abonnent aux avis par courriel ou texto, avec une carte des avis et des interruptions tirée du SIG du service. Factures et comptes sont lus dans le système de facturation par son API ; nous vérifions la vôtre avant de chiffrer. Le libellé des avis est fixé par les personnes responsables de votre service.

// Ce qu’il comprend

// Technologies

• Next.js
• PostgreSQL
• API du système de facturation
• API REST d’ArcGIS
• Paiement hébergé du processeur
• AWS Canada

// Le problème

Une régie régionale de l’eau facture à partir d’une base Access remplie de macros écrites par un ancien employé, les releveurs saisissent les relevés à partir du papier, et un changement à la grille tarifaire veut dire une semaine d’essais sur une copie du fichier.

// Ce que nous bâtirions

D’abord une revue d’architecture de l’ancien système, avec un plan écrit, puis un nouveau système de facturation qui garde chaque compte, chaque tarif et tout l’historique, une application Android que les releveurs utilisent hors ligne sur leur tournée, et des cycles de facturation comparés à l’ancien système avant la bascule. Les écritures vont dans QuickBooks Online, grâce à son API.

// Ce qu’il comprend

// Technologies

• Next.js
• Kotlin pour Android
• PostgreSQL
• API de QuickBooks Online
• AWS Canada

// Le problème

Les opérateurs d’un service ne voient le SCADA que dans la salle de contrôle, les résultats de labo vivent dans des chiffriers, et les données du rapport mensuel comme le tableau de bord du conseil sont montés à la main à partir des deux.

// Ce que nous bâtirions

Un entrepôt de données qui lit les données de l’historien SCADA par une connexion en lecture seule, reçoit les résultats de labo et la consommation facturée, et présente des tableaux de bord aux opérateurs, aux gestionnaires et au conseil. Il prépare les données de rapport pour que votre opérateur responsable les révise et les soumette. Rien n’est jamais écrit dans le SCADA ni dans un système de contrôle.

// Ce qu’il comprend

// Technologies

• PostgreSQL
• dbt
• API de l’historien (lecture seule)
• Next.js
• Apache Superset
• AWS Canada

// Le problème

Les équipes reçoivent leurs bons de travail sur papier, les tournées des stations de pompage vivent dans un cartable, et l’inventaire des entrées de service en plomb que le service doit tenir est un chiffrier avec des trous pour la moitié des adresses.

// Ce que nous bâtirions

Un espace de travail web et une application iOS et Android que les équipes utilisent hors ligne, sur le SIG et le registre des actifs du service : bons de travail pour conduites, vannes, bornes d’incendie et pompes, tournées des stations, et un inventaire des entrées de service avec le matériau consigné à chaque adresse, la façon dont il a été constaté et des photos. Une recherche publique montre à un résident ce qu’on sait de son entrée.

// Ce qu’il comprend

// Technologies

• Next.js
• React Native
• PostgreSQL avec PostGIS
• API REST d’ArcGIS
• AWS Canada

// Le problème

Un service multiréseau qui facture l’eau, l’égout et l’énergie de quartier exploite un système de facturation, un système de télérelève, un SIG, un système de bons de travail et un logiciel financier qui ne se parlent pas, si bien que le personnel exporte et importe des fichiers chaque nuit.

// Ce que nous bâtirions

Un carrefour d’intégration interne qui relie les cinq systèmes par une seule API : les relevés vont à la facturation, les nouveaux comptes arrivent au système de bons de travail et les adresses de service restent synchronisées avec le SIG. Chaque connecteur s’appuie sur l’API publiée ou l’exportation du système ; nous vérifions les vôtres avant de chiffrer. Nous l’exploitons pour vous, avec surveillance et alertes.

// Ce qu’il comprend

// Technologies

• Node.js
• PostgreSQL
• OpenAPI
• API de facturation et de télérelève
• API REST d’ArcGIS
• AWS Canada

// Le problème

Le service d’eau d’une ville dessert des clients qui parlent de nombreuses langues, ses pages d’aide n’existent qu’en anglais, et le centre d’appels se remplit des mêmes questions sur les factures, les déménagements et les avis sur la qualité de l’eau.

// Ce que nous bâtirions

Un centre d’aide en français, en anglais et dans les langues de vos clients, avec un assistant qui répond à partir des articles approuvés, les cite et passe la main à une personne. Les avis en cours s’affichent en premier. L’assistant répond aux questions générales ; il ne voit pas les comptes et ne donne jamais de conseil de santé ou de sécurité au-delà de l’avis lui-même.

// Ce qu’il comprend

// Technologies

• Next.js
• API Claude
• PostgreSQL avec pgvector
• Plateforme de gestion de la traduction
• AWS Canada

// Le problème

Plusieurs villes achètent de l’eau traitée à une même usine régionale, les relevés des compteurs de gros et les quotes-parts sont calculés dans un chiffrier que tient l’usine, et chaque ville le vérifie à sa façon.

// Ce que nous bâtirions

Un registre commun où les relevés des compteurs de gros, les coûts d’immobilisation et d’exploitation et la part de chaque membre sont saisis et convenus chaque mois, sur une chaîne privée à permissions dont chaque membre exploite un nœud. Des relevés mensuels signés font souvent ce travail ; le registre aide quand plusieurs membres ont besoin du même dossier et qu’aucun ne veut qu’un autre le détienne.

// Ce qu’il comprend

// Technologies

• Next.js
• Hyperledger Besu (privé, à permissions)
• PostgreSQL
• AWS Canada