---
title: 'Analyse de la consommation'
description: "Analyse complète d'un point de comptage de gaz unique — qualité des données, profil de consommation, passeport de l'appareil et journal des événements, avec un niveau de détail forensique optionnel."
section: AI Analytics
weight: 1
related:
  - ai-analytics/node-reports/metering-bypass
  - ai-analytics/node-reports/battery-forecast
  - ai-analytics/fleet-reports/top-problem-nodes
---

import Alert from '@/components/docs/Alert.astro';
import Image from '@/components/docs/Image.astro';

L'analyse de la consommation est un examen métrologique et opérationnel approfondi d'**un seul point de comptage de gaz** sur la période sélectionnée. L'objectif n'est pas simplement de tracer une courbe de consommation, mais de répondre aux questions concrètes du service de comptage. L'analyse s'appuie sur des références métrologiques internationales lorsqu'elles justifient une valeur : ISO 5167 (mesure par diaphragme), EN 12405-1 (convertisseurs électroniques de volume), OIML R 137 (compteurs de gaz), OIML R 140 (systèmes de mesure pour combustibles gazeux), ISO 6976 (pouvoir calorifique), EN 1359 (compteurs de gaz à parois déformables) et EN 14236 (compteurs de gaz domestiques à ultrasons).

## Objet

<Image
  src="/images/ai-analytics/consumption-analytics/01_hero_block.svg"
  alt="En-tête du rapport"
/>

_En-tête du rapport._ La première chose que voit le lecteur : le nom et l'adresse du point, le type de correcteur, les métriques clés de la dernière heure (P, T), le volume total de données dans la fenêtre (points), le nombre d'événements détectés, la méthode d'analyse (règles / règles+LLM / LLM seul), la durée de récupération et la période couverte.

Le rapport répond aux questions quotidiennes du service de comptage :

- les données de la période sélectionnée sont-elles complètes ;
- l'archive peut-elle servir à la clôture de la période commerciale ;
- y a-t-il une lacune en fin de période ;
- la télémétrie actuelle fonctionne-t-elle ;
- le débit horaire correspond-il au volume cumulé ;
- des capteurs P/T sont-ils bloqués ;
- y a-t-il des problèmes de communication ou de livraison de l'archive ;
- le passeport métrologique est-il suffisamment renseigné ;
- existe-t-il des schémas suspects de sous-comptage ;
- une visite sur site est-elle nécessaire ;
- quel rôle doit intervenir : métrologue, dispatcheur, ingénieur télécom, ingénieur d'intégration, équipe de terrain ou analyste facturation.

<Alert type="warning">
  Le rapport **n'est pas un constat formel d'incident**. Il ne prouve ni manipulation, ni
  dérivation, ni vol de gaz. Il présente des indicateurs techniques et métrologiques qui nécessitent
  une vérification. Un verdict juridique relève d'un processus distinct qui exige une visite
  obligatoire sur site.
</Alert>

## Logique fondamentale

Le rapport distingue **trois évaluations orthogonales** qu'il ne faut pas confondre :

| Évaluation                              | Signification                                                          |
| --------------------------------------- | ---------------------------------------------------------------------- |
| Disponibilité des données de la période | l'archive est-elle exploitable pour la période sélectionnée            |
| État de la télémétrie actuelle          | le point est-il vivant au moment de la génération du rapport           |
| Aptitude à la clôture commerciale       | la période peut-elle servir à la facturation sans rapprochement manuel |

Une période historique peut être parfaitement exploitable pour l'analyse même si le point est silencieux aujourd'hui.

**Exemple d'interprétation correcte :**

```
Données de la période :   exploitables avec réserves
Surveillance actuelle :   dégradée
Clôture facturation :     non prête pour la clôture définitive
```

Ce n'est pas une contradiction. Cela signifie : les données historiques sont partiellement exploitables, mais la télémétrie actuelle ou la clôture commerciale nécessitent une vérification complémentaire.

## Glossaire

| Terme                 | Signification                                                  |
| --------------------- | -------------------------------------------------------------- |
| Q                     | débit horaire, m³/h                                            |
| P                     | pression du gaz, kPa                                           |
| T                     | température du gaz, °C                                         |
| V                     | volume cumulé, m³                                              |
| ΣQ                    | somme des débits horaires sur la période                       |
| ΔV                    | accroissement du volume cumulé sur la période                  |
| H_expected            | combien d'heures étaient attendues sur la période de rapport   |
| H_received            | combien d'enregistrements horaires ont effectivement été reçus |
| H_validQ              | combien d'enregistrements ont une valeur de débit valide       |
| H_nullQ               | combien d'enregistrements existent mais avec un débit NULL     |
| H_missing             | combien d'heures sont absentes de l'archive                    |
| final_tail_gap        | absence de données en fin de période                           |
| internal_gap          | lacune à l'intérieur de la période                             |
| freshness             | fraîcheur de la dernière heure d'archive                       |
| passport completeness | taux de remplissage du passeport métrologique                  |
| incident              | un problème regroupé nécessitant une action                    |

## Fenêtre temporelle d'analyse

### Début et fin de période

Vous définissez le début et la fin de la période. Le rapport analyse chaque heure depuis 00:00 du premier jour jusqu'à 23:00 du dernier jour :

$$
\text{window\_start} = \text{report\_start } 00{:}00, \quad
\text{window\_end} = \text{report\_end } 23{:}00
$$

### Nombre d'heures attendu

$$
H_\text{expected} = \mathrm{count}(\text{hours from window\_start to window\_end})
$$

Pour une période annuelle, on a typiquement $H_\text{expected} \approx 8760$.

## Décomposition de la disponibilité de l'archive

| Catégorie          | Signification                                             |
| ------------------ | --------------------------------------------------------- |
| Heure valide       | l'enregistrement existe avec une valeur de débit correcte |
| Heure NULL         | l'enregistrement existe mais le débit est vide            |
| Lacune interne     | heure manquante à l'intérieur de la période               |
| Lacune de fin      | heures manquantes en fin de période                       |
| Heure non observée | toute heure sans valeur de débit valide                   |

**Formules :**

$$
H_\text{received} = \mathrm{count}(\text{hourly records})
$$

$$
H_\text{validQ} = \mathrm{count}(\text{records where } Q \neq \text{NULL and } Q \geq 0)
$$

$$
H_\text{nullQ} = \mathrm{count}(\text{records where } Q = \text{NULL})
$$

$$
H_\text{missing} = \max(0, H_\text{expected} - H_\text{received})
$$

$$
H_\text{unobserved} = H_\text{missing} + H_\text{nullQ}
$$

<Alert type="warning">
  La lacune de fin **n'est pas comptée deux fois** en plus de `missing_records` lorsque ces heures
  font déjà partie du total des heures manquantes.
</Alert>

## Complétude des données

<Image
  src="/images/ai-analytics/consumption-analytics/07_completeness_validity.svg"
  alt="Disponibilité, fraîcheur et validité des données"
/>

_Disponibilité, fraîcheur et validité_ sont trois coupes orthogonales du contrôle d'aptitude de l'archive avant toute analyse de fond. La **complétude** répond : combien d'heures parmi celles attendues sont arrivées. La **fraîcheur** — à quel point les données sont à jour _en cet instant_. La **validité** — si les valeurs tombent dans des plages physiquement plausibles.

### Formule de couverture

$$
\mathrm{Coverage}_\text{valid} = \frac{H_\text{validQ}}{H_\text{expected}} \times 100\,\%
$$

De plus :

$$
\mathrm{Coverage}_\text{received} = \frac{H_\text{received}}{H_\text{expected}} \times 100\,\%
$$

La différence est importante :

- `Coverage_received` — les enregistrements sont-ils arrivés tout court ;
- `Coverage_valid` — sont-ils exploitables pour l'analyse du débit.

### Interprétation de la couverture

| Couverture | Statut        | Signification                            |
| ---------- | ------------- | ---------------------------------------- |
| ≥ 98 %     | Excellent     | archive quasi complète                   |
| 95–98 %    | Bon           | exploitable avec réserves mineures       |
| 80–95 %    | Avertissement | lacunes notables                         |
| 50–80 %    | Majeur        | rapprochement manuel requis              |
| < 50 %     | Critique      | inexploitable pour la plupart des tâches |

## Lacune de fin

Lacune de fin = absence de données d'archive en fin de période sélectionnée.

$$
H_\text{tail} = \text{window\_end} - \text{last\_valid\_archive\_hour}
$$

| Fin     | Statut                                                                  |
| ------- | ----------------------------------------------------------------------- |
| ≤ 2 h   | acceptable                                                              |
| 2–6 h   | avertissement                                                           |
| 6–24 h  | majeur                                                                  |
| > 24 h  | critique                                                                |
| > 168 h | appareil silencieux depuis plus d'une semaine — visite sur site urgente |

La lacune de fin répond à : **la période peut-elle être considérée comme entièrement clôturée ?** S'il manque des données à la fin, le rapport peut rester exploitable pour une analyse rétrospective mais **n'est pas prêt** pour la clôture commerciale définitive (voir Verdict de comptage commercial).

## Fraîcheur des données

Deux métriques de fraîcheur distinctes.

### Fraîcheur par rapport à la fin de période

Utilisée pour l'analyse historique et la facturation :

$$
\mathrm{Lag}_\text{period} = \text{window\_end} - \text{last\_valid\_archive\_hour}
$$

Répond à : **dispose-t-on de données jusqu'à la fin de la période sélectionnée ?**

### Fraîcheur par rapport au moment de génération

Utilisée pour la surveillance actuelle :

$$
\mathrm{Lag}_\text{current} = \text{generation\_time} - \text{last\_valid\_archive\_hour}
$$

Répond à : **le point est-il vivant en cet instant ?**

### Couverture des 24 dernières heures

$$
\mathrm{Fresh}_{24h} = \frac{H_\text{validQ, last 24h}}{24} \times 100\,\%
$$

### Score composite de fraîcheur

$$
\mathrm{LagScore} = \max(0, 100 - 2 \times \mathrm{Lag}_\text{period})
$$

$$
\mathrm{FreshnessScore} = \frac{\mathrm{LagScore} + \mathrm{Fresh}_{24h}}{2}
$$

## État de la télémétrie actuelle

<Image
  src="/images/ai-analytics/consumption-analytics/16_telemetry_major.svg"
  alt="État de la télémétrie actuelle et synthèse du point"
/>

_Surveillance actuelle et synthèse du point._ Ce bloc répond à « pouvons-nous agir sur cette archive dès maintenant ? ». Trois moments sont comparés : la dernière heure archivée, la fin de la fenêtre de rapport et le moment de génération du rapport. Si les communications sont fraîches mais que l'archive est en retard — le problème **n'est pas chez le dispatcheur** mais dans l'analyseur/import côté serveur. Le commentaire IA produit une courte synthèse lisible pour l'opérateur, **sans surcharger** les statuts formels.

Calculé **par rapport au moment de génération**, et non à la période :

$$
\mathrm{Lag}_\text{archive, current} = \text{generation\_time} - \text{last\_archive\_hour}
$$

$$
\mathrm{Age}_\text{session} = \text{generation\_time} - \text{last\_session\_time}
$$

| Retard        | Statut        |
| ------------- | ------------- |
| ≤ 6 h         | normal        |
| 6–24 h        | avertissement |
| 24–72 h       | majeur        |
| > 72 h        | critique      |
| aucune donnée | critique      |

**Diagnostic différentiel :**

| Symptôme                             | Cause probable                                           |
| ------------------------------------ | -------------------------------------------------------- |
| sessions fraîches, archive en retard | problème de **livraison d'archive / analyseur / import** |
| ni sessions, ni archive              | modem / SIM / antenne / alimentation / batterie          |

## Validité des données

Contrôles de plage physique par voie :

| Voie          | Condition                                      |
| ------------- | ---------------------------------------------- |
| Débit Q       | $Q \geq 0$                                     |
| Pression P    | $0 < P \leq 5000\text{ kPa}$                   |
| Température T | $-50\,°\mathrm{C} \leq T \leq 80\,°\mathrm{C}$ |

Par voie :

$$
\mathrm{Validity}_\text{ch} = \frac{N_\text{ok}}{N_\text{total}} \times 100\,\%,
\quad
N_\text{ok} = N_\text{total} - N_\text{null} - N_\text{below} - N_\text{above}
$$

Agrégat :

$$
\mathrm{Validity}_\text{total} = \frac{\sum N_\text{ok}}{\sum N_\text{checked}} \times 100\,\%
$$

## Stabilité des capteurs

<Image
  src="/images/ai-analytics/consumption-analytics/06_sensor_health.svg"
  alt="Diagnostic de stabilité des capteurs"
/>

_Diagnostic détaillé des capteurs P et T._ Chaque plage de blocage reçoit son début/fin/durée/valeur. Les longs intervalles à valeur constante sont presque toujours le signe d'une défaillance du CAN / d'une réinitialisation du capteur / d'un arrêt opérationnel du débit — et **non** de la physique réelle. Les pics — sauts brusques ≥ seuil par heure — sont à l'inverse un artefact de télémétrie ou une réinitialisation de capteur.

<Image
  src="/images/ai-analytics/consumption-analytics/05_sensors_critical.svg"
  alt="État des capteurs et plan d'action"
/>

_Interprétation et plan d'action pour les capteurs._ « État des capteurs : CRITIQUE » est une synthèse textuelle finale sur les deux voies. Chaque problème détecté est automatiquement assorti d'une recommandation, d'une priorité, d'un rôle responsable et d'un court déclencheur (ce qui s'est précisément déclenché).

### Capteur bloqué

Un capteur est considéré comme bloqué si sa valeur change à peine pendant une durée supérieure au seuil (24 h) :

$$
H_\text{stuck} \geq 24 \text{ h}
$$

Tolérance d'identité (0,1 %) :

$$
\mathrm{tol}(x) = \max\bigl(0.05,\ |x| \times 0.001\bigr)
$$

Les points sont considérés comme identiques si $|x_i - x_\text{run}| \leq \mathrm{tol}(x_\text{run})$.

### Pic de température

$$
|T_i - T_{i-1}| > 20\,°\mathrm{C / h}
$$

### Pic de pression

$$
|P_i - P_{i-1}| > \max(1.0, 0.5 \times \overline{P})
$$

### Interprétation

| Indicateur      | Signification                                                |
| --------------- | ------------------------------------------------------------ |
| Long blocage T  | défaillance possible du capteur T                            |
| Long blocage P  | défaillance possible du capteur P ou mode `P_const`          |
| Nombreux pics P | instabilité de la voie ou artefact de télémétrie             |
| Nombreux pics T | erreur de capteur ou changement brutal de mode technologique |

<Alert type="warning">
  Un capteur bloqué **n'est pas une preuve de manipulation**. C'est avant tout un risque
  métrologique qui nécessite une vérification selon OIML R 137 / EN 12405-1.
</Alert>

## Scores agrégés de qualité de l'archive

<Image
  src="/images/ai-analytics/consumption-analytics/08_quality_summary.svg"
  alt="Panneau agrégé de qualité"
/>

_Panneau agrégé de qualité._ En haut — les KPI clés du rapport (heures de données, volume, événements, inactivité/dérive). En dessous — les onglets de section (qualité des données, profil de consommation, passeport technique, sous-comptage et manipulation, anomalies et incidents, journalier, sources). Dans l'onglet qualité des données — 6 sous-indicateurs de 0 à 100 plus un verdict verbal et les pondérations du score composite.

Le rapport produit **5 scores orthogonaux** (de 0 à 100 chacun) couvrant des facettes distinctes de la qualité :

| Score                         | Objet                                                |
| ----------------------------- | ---------------------------------------------------- |
| `score_historical_archive`    | exploitabilité des données historiques de la période |
| `score_data_validity`         | exactitude des valeurs Q/P/T                         |
| `score_sensor_health`         | état des capteurs (blocages, pics)                   |
| `score_timeliness`            | fraîcheur de l'archive et des sessions               |
| `score_operational_readiness` | aptitude à la surveillance actuelle                  |

<Alert type="warning">
  Un unique **scalaire composite** « qualité globale » n'est volontairement pas produit — mélanger
  l'exploitabilité historique et la fraîcheur donne une image faussement rassurante. Chaque score se
  lit séparément, avec son propre verdict.
</Alert>

## Estimation du volume potentiellement non observé

<Image
  src="/images/ai-analytics/consumption-analytics/14_uncovered_volume.svg"
  alt="Estimation du risque de volume non observé"
/>

_Deux estimations différentes du même volume._ La moyenne de la période est conservatrice (remplissage de la lacune de fin sous un profil plat), tandis que le profil des heures actives capture mieux le rythme journalier (poste de travail / nuit / week-end). L'écart entre les deux est la **plage d'incertitude**, et non une valeur unique. Le niveau de risque dépend de la durée de la lacune et du débit moyen caractéristique.

<Image
  src="/images/ai-analytics/consumption-analytics/11_anomalous_month.svg"
  alt="Mois de consommation anormal"
/>

_Mois de consommation anormal._ Les anomalies mensuelles sont un signal distinct évalué par rapport au rythme annuel (saison de chauffe vs été). Si un mois donné dépasse **substantiellement** la médiane des autres (seuil × 2), il est automatiquement remonté en tête avec une suggestion de vérifier le flux d'événements, le passeport et les causes technologiques.

Ce bloc estime quelle quantité de gaz a pu transiter pendant les heures sans données d'archive valides.

<Alert type="warning">
  Ce **n'est pas une perte confirmée**. Ce n'est ni un chiffre de vol ni une demande de dommages
  automatique. C'est une estimation de l'**angle mort** — le volume non couvert par une archive
  valide.
</Alert>

### Heures sans données valides

$$
H_\text{blind} = H_\text{missing} + H_\text{nullQ}
$$

### Estimation basée sur la moyenne

$$
\overline{Q} = \frac{\sum Q_\text{valid}}{H_\text{validQ}},
\qquad
V_\text{blind, mean} = H_\text{blind} \times \overline{Q}
$$

Convient aux objets à consommation relativement uniforme.

### Estimation basée sur le profil

Débit typique pour l'heure de la journée $h$ (médiane sur la période) :

$$
\mathrm{Profile}(h) = \mathrm{median}(Q \mid \text{hour\_of\_day} = h)
$$

$$
V_\text{blind, profile} = \sum_{t \in \text{BlindHours}} \mathrm{Profile}(\text{hour}(t))
$$

Si le profil d'une heure n'est pas fiable, on utilise $\overline{Q}$.

### Plage d'estimation

Les deux estimations sont affichées. Si elles sont proches — le profil journalier est stable. Si elles divergent fortement — l'objet présente un mode de fonctionnement marqué et la prudence s'impose.

## Point inactif

Si un point n'a pratiquement eu aucune consommation réelle sur la période, l'absence de débit **n'est pas considérée comme un risque**.

### Contrôle d'inactivité

Seuil adaptatif proche de zéro :

$$
Q_\text{nearzero} = \max(0.5, 0.05 \times \mathrm{median}(Q))
$$

Le point est considéré comme inactif lorsque **les deux** conditions sont réunies :

$$
\overline{Q} \leq 0.05\text{ m³/h} \quad \text{et} \quad V_\text{blind, mean} < 5\text{ m³}
$$

### Effet

L'échelle de gravité s'assouplit (`medium` au maximum au lieu de `critical`), et le rapport indique :

> Le point était de fait hors ligne / arrêté saisonnièrement. L'absence de consommation n'est pas considérée comme un risque de sous-comptage.

## Rapprochement Q/V

<Image
  src="/images/ai-analytics/consumption-analytics/13_qv_volume.svg"
  alt="Analyse du volume cumulé"
/>

_Rapprochement débit horaire vs totalisateur._ Le calcul commercial métrologique repose sur l'accroissement de V, et non sur la somme des valeurs instantanées de Q. Une correspondance ΣQ ≈ ΔV sur ≥ 80 % des heures est la norme pour un point sain. Les **inversions de V** (d'une heure à l'autre, $V_{t+1} < V_t$) et les **sauts brusques de V** sont des signes critiques de défaillance de l'archive et exigent presque toujours une investigation.

Le bloc métrologique clé. Compare la somme des débits horaires à l'accroissement du totalisateur cumulé.

### Grandeurs de base

$$
\Sigma Q = \sum_{h=1}^{n} Q_h, \qquad
\Delta V = V_\text{end} - V_\text{start}
$$

$$
\mathrm{Diff} = \Sigma Q - \Delta V, \qquad
\mathrm{Diff}_\% = \frac{\Sigma Q - \Delta V}{\Delta V} \times 100\,\%
$$

### Interprétation de l'écart

| $\vert\mathrm{Diff}_\%\vert$ | Verdict                           |
| ---------------------------- | --------------------------------- |
| ≤ 2 %                        | `good` (aligné)                   |
| 2–5 %                        | `warn` (aligné avec réserves)     |
| > 5 %                        | `bad` (écart)                     |
| pas de V                     | `unavailable`                     |
| base Q/V inconnue            | vérification du passeport requise |

### Monotonie du totalisateur

Le totalisateur doit croître ou rester constant.

Retour en arrière : $\Delta V_h < -0.5\text{ m³}$ → incident `V_ROLLBACK`.

Saut brusque : $\Delta V_h > V_\text{jump\_threshold}$ → incident `V_JUMP`.

### Rapprochement horaire $Q \cdot 1\text{h} \approx \Delta V$

Pour chaque heure disposant à la fois de $Q$ et de $V$ :

$$
\mathrm{Match}_h = \frac{|Q_h - \Delta V_h|}{\max(Q_h, \Delta V_h)}
$$

L'heure est alignée si $\mathrm{Match}_h \leq 20\,\%$. Part des heures alignées :

$$
\mathrm{Match}_\% = \frac{H_\text{matched}}{H_\text{checked}} \times 100\,\%
$$

### Limites du rapprochement Q/V

Même une bonne correspondance numérique n'équivaut pas à une exploitabilité commerciale. Il faut savoir :

| Question                             | Pourquoi c'est important                              |
| ------------------------------------ | ----------------------------------------------------- |
| Q — volume normalisé ou de service ? | des bases différentes introduisent un biais           |
| V — volume normalisé ou de service ? | il faut la même base                                  |
| Quel est le poids d'impulsion ?      | requis pour un rapprochement commercial complet       |
| V est-il monotone ?                  | les retours en arrière jettent un doute sur l'archive |
| Y a-t-il des corrections manuelles ? | elles peuvent expliquer la divergence                 |

Si la base est inconnue :

> Le rapprochement Q/V est numériquement aligné, mais la base commerciale n'est pas confirmée. Une vérification du passeport, du poids d'impulsion et de la base de volume est requise (voir EN 12405-1 §7).

## Communications vs archive

<Image
  src="/images/ai-analytics/consumption-analytics/12_csq_vs_archive.svg"
  alt="Diagnostic CSQ vs archive"
/>

_Diagnostic différentiel « comms vs upload »._ Si des sessions existent dans la fenêtre mais que l'archive n'existe pas — l'appareil répond via GSM/CSQ, mais l'archive n'est soit pas écrite, soit pas analysée par le serveur. Ce **n'est pas** un problème de dispatcheur / modem — il doit être traité par un ingénieur d'intégration.

### Formules de base

$$
N_\text{sessions} = \mathrm{count}(\text{sessions}), \quad
N_\text{success} = \mathrm{count}(\text{successful sessions})
$$

$$
\mathrm{SessionSuccess}_\% = \frac{N_\text{success}}{N_\text{sessions}} \times 100\,\%
$$

### Livraison de l'archive

Pour chaque lacune, nous vérifions si des sessions ont eu lieu dans la même fenêtre temporelle :

- `gap_with_sessions` — lacune d'archive avec sessions présentes ;
- `gap_without_sessions` — lacune d'archive et absence de sessions également.

### Diagnostic différentiel

| Situation                                      | Cause probable                                              |
| ---------------------------------------------- | ----------------------------------------------------------- |
| ni sessions, ni archive                        | modem / SIM / antenne / alimentation                        |
| sessions OK, archive non mise à jour           | livraison de l'archive horaire / analyseur / import         |
| sessions OK mais partie de l'archive manquante | lecture partielle / coupure de page / backend               |
| sessions fraîches, archive obsolète            | **pas un problème GSM**, problème de livraison de l'archive |
| horodatage de session dans le futur            | décalage d'horloge / fuseau horaire                         |

### Qualité du signal

Si la qualité du signal est rapportée en CSQ :

$$
\mathrm{RSSI}_\text{dBm} \approx -113 + 2 \times \mathrm{CSQ}
$$

Exemple : CSQ=29 → RSSI ≈ −55 dBm (excellent).

## Passeport métrologique

### Champs requis avec pondérations

Le passeport définit 11 champs avec des pondérations :

| Champ                      | Poids   | Pourquoi                           |
| -------------------------- | ------- | ---------------------------------- |
| equipment_serial_number    | 1.0     | identification                     |
| equipment_type_id          | 1.0     | modèle/type                        |
| installation_date          | 0.8     | contexte d'exploitation            |
| **verification_date**      | **1.5** | validité légale (OIML R 137 cl. 3) |
| next_verification_date     | 1.0     | contrôle d'échéance                |
| **flow_range** (Qmin/Qmax) | **1.5** | plage selon EN 12405-1             |
| meter_serial_number        | 1.0     | identification sur site            |
| meter_type                 | 1.0     | rattachement métrologique          |
| firmware_version           | 0.5     | compatibilité et bogues connus     |
| p_const                    | 0.5     | pression substituée                |
| pulse_weight               | 0.8     | pour le rapprochement Q/V          |

### Formule de complétude

$$
\mathrm{PassportCompleteness} = \frac{\sum w_\text{filled}}{\sum w_\text{required}} \times 100\,\%
$$

### Interprétation

| Complétude | Statut              |
| ---------- | ------------------- |
| ≥ 80 %     | COMPLETE            |
| 50–80 %    | PARTIAL             |
| 20–50 %    | INCOMPLETE          |
| < 20 %     | CRITICAL_INCOMPLETE |

Si le passeport est incomplet, le verdict commercial doit comporter une réserve :

> Passeport métrologique incomplet. Le verdict commercial nécessite un rapprochement manuel et une référence à OIML R 137 / EN 12405-1.

## Schémas suspects de sous-comptage

<Image
  src="/images/ai-analytics/consumption-analytics/03_forensic_signals.svg"
  alt="Tri des signaux de sous-comptage"
/>

_Tri des signaux._ Chaque signal est classé dans une catégorie, possède un niveau de preuve (low / medium / high), une priorité de terrain, des éléments formels et une action recommandée. **Ce n'est pas un verdict sur le point** — c'est une liste de fenêtres nécessitant une vérification manuelle par un opérateur ou par le personnel de service.

Ce sont des **heuristiques**, pas des preuves.

### Seuil proche de zéro

$$
Q_\text{nearzero} = \max(0.5, 0.05 \times \mathrm{median}(Q))
$$

### Débit nul pendant les heures actives

Une heure est suspecte de calme si $Q_h < Q_\text{nearzero}$ ET qu'elle tombe dans l'intervalle d'activité typique de l'objet.

### P vivante + zéro (Q≈0 avec P vivante)

Peut être :

- arrêt / vanne aval fermée / arrêt saisonnier ;
- mode P_const ou défaillance de capteur ;
- erreur d'entrée d'impulsion ;
- **manipulation possible** — mais non prouvée.

<Alert type="warning">
  P vivante + zéro **n'est pas une preuve de manipulation**. C'est seulement une raison de vérifier
  le mode de fonctionnement du point.
</Alert>

### Reprise après coupure

Schéma : Q normal → Q≈0 → Q normal. Changement de mode brutal, mais pas une preuve de violation. Explications possibles : arrêt planifié / arrêt de l'objet / fermeture de vanne / défaillance de voie / intervention manuelle / erreur de livraison de l'archive.

### Manipulation confirmée

Un schéma statistique seul **ne peut pas** confirmer une manipulation. Il faut des **preuves tangibles** :

- ouverture de l'armoire (cover_open dans les événements de l'appareil) ;
- interférence magnétique ;
- modifications de paramètres (parameter_change) ;
- modification non autorisée de P_const ;
- réinitialisation de l'archive ;
- manipulation confirmée de l'entrée d'impulsion ;
- procès-verbal de réception sur site ;
- photos / scellés / relevés sur site.

Format de verdict correct :

```
Manipulation confirmée :  NON DÉTECTÉE
Schémas suspects :        PRÉSENTS
Recevabilité juridique :  NON PRÊTE
```

## Verdict de comptage commercial

<Image
  src="/images/ai-analytics/consumption-analytics/02_commercial_verdict.svg"
  alt="Verdict de comptage commercial"
/>

_Statut de gestion._ Les 7 lignes répondent à 7 questions distinctes de niveau gestionnaire : la période peut-elle être clôturée (facturation), le point fonctionne-t-il maintenant (surveillance), l'archive et le totalisateur concordent-ils (Q×h vs ΔV), une visite sur site est-elle nécessaire, des schémas suspects sont-ils présents, dans quelle mesure les données sont-elles intègres, tous les paramètres du passeport sont-ils présents. Chaque ligne est cliquable et pointe vers le bloc de preuves du rapport.

Le verdict de tête pour le responsable du service de comptage.

### Règles d'archive de facturation

**Prêt :**

- Couverture ≥ 98 %
- Lacune de fin ≤ 2 h
- Q/V aligné (`good`)
- V monotone
- Passeport COMPLETE
- Aucun problème critique de capteur

**Prêt avec réserves :**

- Couverture 95–98 %
- Lacune de fin 2–24 h
- Q/V aligné avec réserves (`warn`)
- Passeport PARTIAL
- Aucun blocage critique

**Non prêt pour la clôture définitive :**

- Lacune de fin > 24 h OU
- Q/V non classé OU
- Retour en arrière de V présent OU
- Passeport incomplet dans les champs commerciaux OU
- Problème critique de capteur

**Inexploitable :**

- Couverture critiquement faible OU
- Archive corrompue OU
- V présente des retours en arrière / pics majeurs OU
- Q/V totalement incohérent OU
- Voie clé indisponible

### Surveillance actuelle — évaluée séparément

| Condition                                 | Statut                               |
| ----------------------------------------- | ------------------------------------ |
| archive et session fraîches               | exploitable                          |
| archive en retard mais sessions présentes | dégradé / problème de livraison      |
| archive et sessions obsolètes             | critique / problème de communication |
| horodatage invalide                       | non fiable                           |

### Inspection sur site

Une visite est requise si **au moins une** des conditions suivantes est réunie :

- lacune de fin non rétablie ;
- Q/V non classé ;
- retour en arrière du totalisateur présent ;
- passeport critiquement incomplet ;
- capteur P ou T bloqué ;
- schémas suspects de sous-comptage ;
- journal des événements indisponible alors que de fortes anomalies existent ;
- télémétrie actuelle critiquement dégradée.

## Incidents

Un incident est un problème **regroupé**, pas chaque enregistrement brut.

### Types

| Type                   | Signification                          |
| ---------------------- | -------------------------------------- |
| `FINAL_TAIL_GAP`       | pas de données en fin de période       |
| `COMMUNICATION_GAP`    | panne de communication                 |
| `ARCHIVE_DELIVERY_GAP` | sessions présentes, archive non livrée |
| `Q_V_MISMATCH`         | Q et V ne concordent pas               |
| `V_ROLLBACK`           | totalisateur revenu en arrière         |
| `P_SENSOR_STUCK`       | pression bloquée                       |
| `T_SENSOR_STUCK`       | température bloquée                    |
| `PASSPORT_INCOMPLETE`  | champs du passeport manquants          |
| `TAMPERING_CANDIDATE`  | schéma suspect, pas une preuve         |

### Principe de regroupement

```
événements bruts → incidents regroupés → incidents prioritaires
```

Exemple : 301 bruts → 15 regroupés → Top-5 pour action. On ne doit pas présenter à l'opérateur 301 événements identiques comme 301 problèmes distincts.

## Plan d'action

<Image
  src="/images/ai-analytics/consumption-analytics/09_action_plan_checklist.svg"
  alt="Plan d'action par rôle et liste de contrôle terrain"
/>

_Actions avec priorités P0/P1/P2._ Chaque action porte un rôle responsable, une échéance (aujourd'hui / dans la journée / 1–3 jours) et la **cause** qui l'a inscrite sur la liste. La liste de contrôle terrain est construite automatiquement à partir du verdict et des incidents ouverts : quoi emporter, quoi examiner, quoi mesurer — étiqueté P0/P1 pour la priorisation sur site.

Chaque recommandation est rattachée à une cause.

| Champ    | Description                       |
| -------- | --------------------------------- |
| ID       | numéro de la recommandation       |
| Priorité | P0 / P1 / P2 / P3                 |
| Action   | quoi faire                        |
| Rôle     | qui est responsable               |
| Échéance | quand achever                     |
| Cause    | pourquoi cette action est apparue |
| Statut   | open / assigned / done / verified |

### Exemples de règles

| Condition                    | Action                                                                        |
| ---------------------------- | ----------------------------------------------------------------------------- |
| fin > 24h, sessions fraîches | backend : rétablir la livraison de l'archive horaire                          |
| fin > 24h, pas de sessions   | comms : vérifier modem/SIM/alimentation                                       |
| T bloquée ≥ 24h              | métrologue : vérifier le capteur T (OIML R 137)                               |
| P bloquée ≥ 24h              | métrologue : vérifier le capteur P ou le réglage P_const                      |
| écart Q/V                    | métrologue + facturation : rapprocher V, Q, poids d'impulsion (EN 12405-1 §7) |
| passeport incomplet          | admin / métrologue : renseigner le passeport                                  |
| schémas suspects             | équipe de terrain : vérifier scellés, entrée d'impulsion, vannes              |

## Liste de contrôle terrain

### Quoi emporter

manomètre étalon • thermomètre étalon • multimètre • testeur de signal/antenne • kit de scellés • protocole d'inspection • accès à l'archive et au passeport • appareil photo.

### Quoi vérifier

scellés du correcteur et du compteur • câble d'impulsion • capteurs P, T • modem, antenne, alimentation, batterie • vannes de sectionnement • dérivation éventuelle • passeport vs équipement réel.

### Quoi mesurer

P, T de référence • Q actuel • V cumulé • relevés du compteur externe • CSQ/RSSI • tension d'alimentation • impulsions d'entrée • date/heure du correcteur • P_const • Qmin/Qmax • poids d'impulsion.

### Quoi photographier

afficheur du correcteur (P/T/Q/V) • date/heure sur l'appareil • numéros de série • scellés • câble d'impulsion • capteurs • modem et antenne • vue d'ensemble • positions des vannes.

## Source selon le profil comportemental

L'archive et le champ d'API spécifiques sont sélectionnés automatiquement selon le comportement de l'appareil. Trois familles :

### Archive horaire continue

L'appareil écrit un enregistrement **exactement une fois par heure**. Priorité des sources :

1. champ direct « débit par heure » (si l'appareil le calcule) ;
2. Δ du volume normalisé cumulé ;
3. Δ du volume de service cumulé.

Lacune acceptable — **exactement 1 heure**.

### Téléversement par sessions avec archive d'état courant

L'appareil écrit des enregistrements lorsqu'il se connecte, pas strictement à l'heure. La source principale est le **débit instantané** (calculé par l'appareil) ; le repli est le Δ du volume cumulé normalisé :

$$
\dot Q_h = \frac{V_t - V_{t-\Delta t}}{\Delta t / 3600}
$$

Lacune acceptable — **jusqu'à 6 heures** ; si $\Delta t > 6\text{ h}$, le point est considéré comme invalide (probable perte de données, et non décharge du totalisateur).

### Blocs de pure télémétrie

L'appareil ne transmet que les communications/l'état, ne mesure pas le gaz — le rapport affiche N/A avec « cet appareil n'a pas de point de comptage ».

### Repli clairsemé

Si l'archive principale fournit < 50 % des points attendus, l'archive secondaire des sessions est essayée automatiquement (telle quelle, sans grille horaire) et le calcul s'en déduit.

## Limites de la méthodologie

### Archive

Si l'archive horaire est incomplète, toutes les estimations pour les heures manquantes sont **approximatives**.

### Q/V

Le rapprochement Q/V n'a de sens que lorsque Q et V :

- partagent une seule base de volume (normalisée ou de service) ;
- disposent d'un poids d'impulsion correct ;
- proviennent de la même source de comptage ;
- sont synchronisés temporellement.

Voir OIML R 137 pour la procédure de vérification et EN 12405-1 §7 pour la base de conversion.

### Passeport

Sans Qmin/Qmax, date de vérification, P_const ou poids d'impulsion, le verdict commercial doit comporter une réserve.

### Schémas suspects

Les schémas de sous-comptage **ne sont pas une preuve** de manipulation. Ils ne font que fixer la priorité d'inspection.

### Commentaire IA

Le commentaire IA **ne prend aucune part** au verdict juridique et ne remplace pas les règles formelles. Il aide seulement à expliquer la situation en langage clair.

## Comment lire le rapport

<Image
  src="/images/ai-analytics/consumption-analytics/04_chart_qpt_profile.svg"
  alt="Débit, pression et température avec profil de consommation"
/>

_Visualisation Q/P/T et profils comportementaux._ Sur le graphique principal, les événements sont surlignés sous forme de bandes verticales semi-transparentes par type (pic / inactivité / fuite / capteur bloqué / pas de données) — n'importe quel type peut être affiché/masqué en cliquant sur sa puce. Les moyennes glissantes sur 7 / 30 jours assurent un lissage saisonnier. Le motif de consommation est une double décomposition : profil journalier (heure de la journée) ventilé par jour de semaine/week-end, et une carte thermique calendaire « jour de la semaine × mois » montrant la stabilité du poste de travail.

<Image
  src="/images/ai-analytics/consumption-analytics/10_period_compare.svg"
  alt="Comparaison avec la période précédente"
/>

_Comparaison période sur période._ Un delta d'une année sur l'autre comporte deux pièges : (1) le **changement de couverture de la période précédente** (si elle était de 6 %, une croissance des événements « ×33 » est un artefact de division, pas une réalité) et (2) l'**absence de normalisation de la durée**. Aussi, avec une couverture < 50 %, la comparaison masque le Δ % et n'affiche que les deltas absolus, pour éviter d'amener l'opérateur à de fausses conclusions.

1. Commencez par le **Verdict de comptage commercial**.
2. Voyez si la période est prête pour la facturation.
3. Vérifiez séparément la surveillance actuelle.
4. Passez aux **Top-5 incidents**.
5. S'il y a une lacune de fin — allez à « comms vs archive ».
6. S'il y a un écart Q/V — allez à l'analyse du volume cumulé.
7. Si les capteurs P/T sont bloqués — allez à la stabilité des capteurs.
8. Si le passeport est incomplet — **n'émettez pas** de verdict commercial ferme.
9. Si des schémas suspects existent — planifiez une vérification, mais **n'émettez pas de verdict juridique**.
10. Exécutez le plan d'action par rôle.

## Critères minimaux pour un rapport complet

Un rapport est considéré comme complet s'il contient :

- période d'analyse • $H_\text{expected}$ • enregistrements reçus • enregistrements valides • enregistrements NULL • lacunes internes • lacune de fin • couverture • fraîcheur • validité Q/P/T • santé des capteurs • estimation du volume non observé • rapprochement Q/V • monotonie de V • comms vs archive • complétude du passeport • Top-5 incidents • plan d'action par rôle • liste de contrôle terrain ;

- trois avertissements obligatoires :
  - sur le sous-comptage (il s'agit d'une estimation d'angle mort, pas d'un chiffre de perte) ;
  - sur la suspicion de manipulation (schémas ≠ preuve) ;
  - sur le commentaire IA (pas un verdict juridique).

## Paramètres d'exécution

| Paramètre               | Description                                                                                                                                                                                                                                                                                                                                           |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| N° du point de comptage | le point de comptage à analyser                                                                                                                                                                                                                                                                                                                       |
| Période du              | début de la fenêtre d'analyse (par défaut : un an en arrière)                                                                                                                                                                                                                                                                                         |
| Période au              | fin de la fenêtre d'analyse (par défaut : hier)                                                                                                                                                                                                                                                                                                       |
| Analyse étendue         | charge en plus l'archive des sessions de communication et l'archive des événements anormaux du correcteur. Active les blocs Data Source Readiness, Communication Health et Device Abnormal Log, et remplit la Root Cause Matrix avec le niveau de confiance et la cause racine par événement. Ajoute 5–15 secondes au temps de génération du rapport. |
