1. Principes généraux

Kordelia analyse les mesures horaires des compteurs d'eau afin de produire deux familles d'événements distinctes : les fuites et les anomalies compteur.

• Une fuite concerne une consommation suspecte ou inhabituelle.
• Une anomalie concerne un problème de fonctionnement, de remontée ou de cohérence des données compteur.
• Un compteur peut être opérationnel et présenter une fuite.
• Une fuite n'est pas automatiquement une anomalie compteur.
• Les calculs doivent toujours tenir compte de la période affichée.
• L'utilisateur conserve la décision finale sur la qualification métier des événements.

Kordelia ne doit pas seulement appliquer des seuils fixes : l'objectif est de construire progressivement une application capable de tenir compte du comportement réel de chaque compteur.

2. Import des fichiers XLS

Les fichiers importés proviennent des exports horaires de consommation. Le format attendu reprend la structure historique des exports eau : noms des compteurs en ligne d'en-tête, date, heure, puis valeurs horaires.

• Les compteurs sont lus à partir des colonnes de mesures.
• Les dates et heures sont utilisées pour reconstituer une base de mesures unique.
• Les valeurs vides doivent être distinguées des valeurs à zéro.
• Les unités affichées peuvent être normalisées pour l'affichage, sans modifier l'identifiant source du compteur.

Les imports peuvent être réalisés sur une journée, plusieurs jours ou une période plus longue. Les imports successifs sont cumulés dans l'historique analysé.

Pour une même mesure compteur + date + heure, la règle est la suivante :

• ancienne valeur pleine + nouvelle valeur vide : conserver l'ancienne valeur ;
• ancienne valeur vide + nouvelle valeur pleine : prendre la nouvelle valeur ;
• deux valeurs identiques : ne rien changer ;
• deux valeurs pleines différentes : conserver la nouvelle valeur pleine.

3. Période du fichier et période analysée

L'accueil distingue deux notions importantes :

• Période du fichier : période couverte par le dernier fichier importé.
• Période analysée : période totale disponible dans l'application après cumul des imports successifs.

Exemple : si un fichier du 1er juillet est importé, puis un fichier du 2 juillet sans effacer les données, la période du dernier fichier est le 2 juillet, mais la période analysée devient du 1er au 2 juillet.

Les dates sélectionnables dans le Dashboard doivent correspondre à la période analysée complète, afin de pouvoir afficher les indicateurs sur tout l'historique importé.

4. Détection des fuites

La détection des fuites repose principalement sur l'analyse des consommations nocturnes, avec une plage configurable par défaut de 00h00 à 06h00.

Le moteur recherche notamment :

• une consommation nocturne continue ou répétée ;
• un débit de fond stable ;
• une absence de retour à zéro ou quasi-zéro ;
• une répétition sur plusieurs nuits ;
• un comportement incompatible avec le comportement habituel du compteur ;
• une dérive par rapport aux mesures déjà connues.

La probabilité de fuite augmente lorsque le phénomène est régulier, stable, répété et non expliqué par un usage normal.

Le débit de fuite estimé doit représenter un débit de fond réaliste. Il doit privilégier une valeur basse ou médiane représentative plutôt qu'un pic isolé.

Les éléments suivants doivent être exclus de la détection fuite lorsqu'ils ne sont pas pertinents :

• compteurs généraux utilisés pour le total parc ;
• sommes virtuelles ;
• compteurs supprimés ;
• compteurs non réels ;
• eaux usées ;
• pompage ou libellés assimilés ;
• compteurs sans données exploitables ;
• compteurs avec anomalie bloquante.

5. Fin de fuite et qualification humaine

Dans l'onglet FUITES_CPT, le moteur ne doit pas passer automatiquement une fuite au statut Résolu.

Lorsque la fuite n'est plus détectée, Kordelia peut renseigner automatiquement une date de fin ou de résolution. En revanche, le statut reste inchangé tant que l'utilisateur ne l'a pas modifié manuellement.

• Par défaut, un événement non qualifié reste au statut À vérifier.
• La date de fin peut être renseignée automatiquement par le moteur.
• La qualification finale reste une décision humaine.
• L'utilisateur choisit ensuite le statut approprié : Résolu, Normal, Pas de fuite, Intervention demandée, etc.

Objectif : le moteur constate la fin probable du phénomène, mais il ne décide pas seul de la conclusion métier.

6. Détection des anomalies compteur

Les anomalies concernent la qualité ou le fonctionnement du compteur, et non une consommation suspecte.

Les principaux états détectables sont :

• Aucune information remontée : aucune donnée exploitable n'est disponible.
• Consommation toujours à 0 : le compteur remonte des valeurs, mais elles restent nulles.
• Compteur figé : les valeurs ne varient plus alors qu'une variation est attendue.
• Données incohérentes : valeurs négatives, pics aberrants ou données incompatibles avec l'historique.
• Site en travaux ou Supprimé : qualification humaine ou état connu du compteur.

L'ordre de priorité de l'inventaire doit éviter qu'un compteur supprimé ou sans donnée soit classé à tort comme opérationnel.

7. Inventaire des compteurs

L'onglet INVENTAIRE_CPT constitue le référentiel de base des compteurs connus par Kordelia.

Il contient notamment :

• le nom du compteur ;
• le type de compteur ;
• le profil bâtiment ou profil site ;
• l'état compteur ;
• l'indication éventuelle d'un nouveau compteur.

Le profil bâtiment et le type de compteur sont des propriétés du compteur. Ils doivent être conservés lors d'une réinitialisation simple des analyses.

Le profil bâtiment affiché dans les fuites doit être synchronisé avec celui de l'inventaire : une modification dans FUITES_CPT doit mettre à jour l'inventaire, et inversement.

8. Statuts, états et propriétés métier

Les statuts et états ne sont pas de simples libellés. Ils portent des propriétés métier configurables qui déterminent leur impact dans l'application.

Pour chaque statut ou état, l'utilisateur peut modifier :

• la couleur ;
• Comportement normal ;
• Compte comme une fuite ;
• Compte comme une anomalie ;
• Supprimer du tableau de suivi.

Ces propriétés pilotent les calculs du Dashboard, les volumes estimés, le nombre de secteurs estimés en fuite, les indicateurs d'anomalies et l'affichage dans les tableaux de suivi.

Le comportement ne doit pas dépendre uniquement du nom du statut, mais des propriétés définies dans les paramètres. Cela permet de tester différentes méthodes de calcul sans modifier le code.

Exemple : l'utilisateur peut décider que le statut À vérifier reste visible dans le tableau des fuites, mais ne compte pas dans les volumes de fuite estimés du Dashboard.

9. Différence entre Normal et Pas de fuite

Les statuts Normal et Pas de fuite ont deux significations différentes.

Normal signifie que le moteur a bien détecté une évolution réelle de comportement, mais que cette évolution est expliquée par un changement connu du site ou de l'usage. Exemple : ajout d'un refroidissement, nouvelle activité, nouvel équipement ou changement d'exploitation.

• Le moteur n'a pas forcément eu tort de signaler l'événement.
• Le phénomène ne compte pas comme une fuite.
• L'événement reste dans le tableau de suivi.
• Il peut avoir une date de début et une date de fin.
• Il ne sert pas nécessairement à relever les seuils permanents du compteur.

Pas de fuite signifie plutôt que la détection était un faux positif. Le niveau détecté doit être considéré comme normal pour ce compteur à l'avenir.

• Le phénomène ne compte pas comme une fuite.
• Il peut être retiré du tableau de suivi selon le paramétrage.
• Il alimente la base de connaissances.
• Il sert à ajuster la compréhension future du compteur.
• Le moteur doit éviter de recréer la même fausse alerte sur une signature similaire.

Résumé : Normal = changement réel expliqué ; Pas de fuite = faux positif à apprendre.

10. Base de connaissances

La base de connaissances mémorise les décisions humaines utiles à l'amélioration du moteur de détection, en particulier les événements classés comme faux positifs.

Lorsqu'un utilisateur classe une fuite en Pas de fuite, Kordelia doit mémoriser que la signature détectée correspond à un niveau normal pour ce compteur.

Cette connaissance doit permettre au moteur :

• de reconnaître une situation déjà qualifiée ;
• de ne pas recréer inutilement une fuite similaire ;
• d'adapter progressivement les seuils d'analyse du compteur ;
• de distinguer une vraie dérive d'un comportement déjà validé.

La base de connaissances est une mémoire métier. Elle ne doit pas être supprimée lors d'une simple réinitialisation des analyses.

11. Dashboard

Le Dashboard affiche une synthèse de la période sélectionnée. Il ne doit pas raisonner uniquement sur l'état actuel, mais sur les événements actifs ou présents dans la période affichée.

Il présente notamment :

• la consommation totale parc estimée ;
• la consommation estimée comme normale ;
• le volume de fuites estimées ;
• le nombre de secteurs estimés en fuite ;
• la répartition des consommations ;
• l'état général des compteurs.

Le volume de fuite est calculé à partir du débit estimé et de la durée de présence de l'événement sur la période affichée.

Un événement résolu ou terminé peut donc compter uniquement sur sa période active. Un statut configuré comme ne comptant pas comme fuite ne doit pas alimenter les volumes de fuite estimés.

12. Principes de calcul

Les compteurs généraux configurés alimentent le total parc. Les compteurs connus comme généraux ne doivent pas être traités comme de simples fuites ordinaires.

Référentiel historique des compteurs généraux :

• 000_EF_Eau de ville [FUTUROSCOPE]
• 000_EI_sortie siveer [FUTUROSCOPE]
• 000_General_EP_CAP_Sud [FUTUROSCOPE]

La consommation normale correspond à la consommation totale estimée du parc diminuée des volumes considérés comme fuites selon les propriétés métier des statuts.

Les données incohérentes doivent être visibles dans les anomalies, mais exclues des calculs lorsqu'elles risquent de fausser les indicateurs.

13. Réinitialisations et effacements

Kordelia distingue plusieurs niveaux de remise à zéro.

Réinitialiser les analyses permet de repartir sur une base d'analyse vierge sans perdre le référentiel des compteurs.

• supprime les fuites détectées ;
• supprime les anomalies détectées ;
• réinitialise les états d'analyse temporaires ;
• efface le fichier importé et les mesures ;
• conserve l'inventaire, les types, les profils et la base de connaissances.

Effacement total des données est une action de dernier recours, prévue notamment si les noms des compteurs changent totalement.

• supprime les imports ;
• supprime les mesures ;
• supprime les fuites et anomalies ;
• supprime l'inventaire ;
• supprime les compteurs connus ;
• supprime la base de connaissances ;
• conserve les paramètres applicatifs.

Cette action doit être sécurisée par une confirmation explicite.

14. Rôle des écrans

• Accueil : import des fichiers, période du fichier, période analysée et priorités non traitées.
• Dashboard : synthèse des consommations, fuites, anomalies et états sur la période sélectionnée.
• FUITES_CPT : suivi des fuites détectées, qualification humaine, dates, profils et statuts.
• ANOMALIES_CPT : suivi des dysfonctionnements ou incohérences de compteurs.
• INVENTAIRE_CPT : référentiel des compteurs, types, profils et états.
• Paramètres : configuration des seuils, statuts, états, profils, types, couleurs et règles métier.
• À propos : documentation intégrée des règles et principes de fonctionnement.

15. Règles d'ergonomie importantes

• Le bouton Retour doit fonctionner comme un historique d'actions et permettre d'annuler une modification lorsque cette fonction est active.
• Le bouton Avancer doit permettre de rétablir une action annulée.
• Les changements de couleur ou de propriétés dans les paramètres doivent être enregistrés explicitement.
• Les tris de dates doivent modifier uniquement l'ordre d'affichage, jamais les données.
• Une ligne modifiée par l'utilisateur ne doit pas disparaître brutalement pendant la saisie ; les reclassements peuvent être différés au Refresh ou au changement d'onglet.

16. Limites et évolutions prévues

La version actuelle reste une V1 : elle vise à stabiliser l'import, l'affichage, le suivi, les calculs et les premières règles de détection.

Les évolutions futures pourront renforcer l'intelligence de détection autour de la signature propre de chaque compteur, plutôt qu'autour du seul profil bâtiment.

L'objectif à terme est que Kordelia compare un compteur à son propre comportement habituel, tienne compte des décisions humaines précédentes et réduise progressivement les faux positifs.

Le profil bâtiment reste utile comme contexte, mais le coeur de l'analyse doit progressivement devenir la connaissance du compteur lui-même.

Conclusion

Kordelia est un outil d'aide à la décision. Son rôle est de détecter vite, de présenter clairement, de laisser l'humain qualifier, puis de mémoriser ce qui a été appris.

La valeur de l'application vient autant de ses calculs que de la connaissance métier accumulée au fil des imports, des corrections et des décisions utilisateur.