Sessions longues

Nœuds du parc dont les sessions de communication s'étirent anormalement par rapport à leur propre norme, avec des seuils IQR individuels par nœud, un score de gravité et une analyse des causes racines fondée sur les incidents.

Le rapport Sessions longues analyse les sessions de communication télémétrique sur l’ensemble du parc de nœuds de comptage et identifie les appareils, les emplacements, les jours et les types de correcteurs pour lesquels les communications fonctionnent de façon instable ou mettent un temps excessif à transmettre les données.

En-tête du rapport avec sept indicateurs clés

L’en-tête du rapport présente sept indicateurs clés : la société, la couverture du parc, la disponibilité des données, le nombre de nœuds présentant des anomalies, le nombre de sessions anormales, la durée maximale de session, le nombre total d’incidents horaires et la période d’analyse. Le chiffre phare correspond au nombre de nœuds présentant des anomalies sur le total du parc ; les incidents sont des regroupements horaires où cinq nœuds ou plus présentent simultanément des sessions longues.

Le rapport répond à des questions opérationnelles concrètes :

quels nœuds ont des sessions de communication trop longues ;
quelles sessions sont considérées comme anormales pour ce nœud précis ;
où le problème est local : antenne, carte SIM, alimentation, modem, site d’installation ;
où le problème ressemble à un incident de station de base ou d’opérateur de réseau mobile ;
s’il existe des incidents horaires massifs à l’échelle du parc ;
quels jours ont été les plus problématiques ;
quels types de correcteurs tombent plus souvent en sessions longues ;
combien d’énergie a approximativement été dépensée en retransmissions ou en transmissions prolongées ;
quels nœuds nécessitent une intervention sur site avec antenne externe, répéteur ou contrôle de la SIM ;
où il convient de vérifier l’opérateur de réseau mobile ou la qualité de couverture à un emplacement précis.

Position du rapport

Le rapport relève du diagnostic opérationnel de la télémétrie. Il ne doit pas confondre deux situations différentes :

Absence totale de communication. Le nœud ne se connecte pas, il n’y a aucune donnée.
La communication existe, mais les sessions sont trop longues. Le nœud transmet des données, mais lentement, de façon instable ou avec des nouvelles tentatives.

Ce rapport analyse la deuxième situation. Lorsqu’il n’y a ni communication, ni archive, ni aucune donnée, utilisez le rapport Top des nœuds problématiques ; lorsque vous devez vérifier si les données d’un nœud donné conviennent au comptage, utilisez Analytique de consommation.

À qui s’adresse le rapport

Rôle	Ce que le rapport lui apporte
Responsable des opérations	vue d’ensemble du parc, nombre de nœuds présentant des anomalies, incidents massifs
Ingénieur communications	liste des nœuds à mauvais RSSI, sessions longues et problèmes locaux
Dispatcheur	liste priorisée de tickets et jours problématiques
Équipe de terrain	top des nœuds à contrôler pour antenne, SIM, alimentation et site d’installation
Ingénieur d’intégration	diagnostic de disponibilité des données, couverture de l’API et cas de données de session manquantes
Acheteur	comparatif détaillé par type de correcteur
Analyste du parc	hypothèses de cause racine : station de base, opérateur, micrologiciel, nœud local

Ce que le rapport ne fait pas

Le rapport ne doit pas :

prouver qu’un modem précis est défaillant sans intervention sur site ;
considérer une session longue comme preuve directe d’un appareil défectueux ;
accuser automatiquement le serveur ou l’opérateur de réseau mobile ;
confondre « absence de données » et « absence d’anomalies » ;
comparer la durée de session de tous les nœuds selon un unique seuil commun ;
considérer une période courte comportant peu de sessions comme statistiquement fiable ;
tirer des conclusions sur la qualité d’un modèle d’appareil sans tenir compte du nombre d’appareils dans l’échantillon ;
se substituer à une étude radioélectrique du site d’installation ;
considérer l’estimation de perte batterie comme une mesure précise ;
utiliser le commentaire de l’IA comme source de diagnostic.

Termes clés

Terme	Signification
Session de communication	un épisode de connexion de l’appareil au système de transmission de données
Durée de session	temps écoulé entre le début et la fin de la session
Session normale	session dont la durée se situe dans la norme individuelle du nœud
Session longue	session dont la durée dépasse le seuil IQR individuel du nœud
`IQR`	écart interquartile : `Q3 − Q1`
`Q1`	premier quartile des durées de session
`Q3`	troisième quartile des durées de session
`UpperFence`	borne supérieure de la norme : `Q3 + 1.5 × IQR`
`RSSI`	niveau du signal radio, dBm
`CSQ`	indice de qualité du signal GSM, convertible en dBm
`Btm`	tension de batterie ou indicateur d’alimentation de l’appareil
`Long share`	part des sessions longues parmi toutes les sessions d’un nœud
`Severity score`	évaluation finale du niveau de problème d’un nœud au titre des sessions longues
Incident	regroupement horaire où des sessions longues sont apparues simultanément sur plusieurs nœuds
`RCA`	analyse de la cause probable : station de base, réseau, serveur, micrologiciel, nœud local
`Battery loss`	estimation approximative de l’énergie dépensée du fait de la durée de transmission excédentaire

Logique générale du rapport

Le rapport est conçu comme une analyse des sessions de communication à l’échelle du parc.

text

Liste des nœuds du parc
→ récupérer les sessions de communication
→ vérifier la disponibilité des données
→ norme de session individuelle pour chaque nœud
→ recherche des sessions longues via l'IQR
→ calculer le score pour chaque nœud
→ regrouper les sessions longues en incidents horaires
→ déterminer la cause probable (RCA)
→ répartir les hypothèses entre les nœuds
→ top des nœuds problématiques
→ détail par type de correcteur
→ détail par jours et par mois
→ recommandations pour les opérations

Le principe principal :

text

une session longue est définie par rapport à la norme d'un nœud précis,
et non par rapport à un seuil fixe commun à l'ensemble du parc.

Cela importe, car des appareils, régions, opérateurs de réseau mobile et modes d’interrogation différents peuvent présenter des durées de session normales différentes.

Paramètres d’exécution

Paramètre	Signification
Date de début / Date de fin	bornes de la fenêtre d’analyse
Fenêtre d’analyse, jours	fenêtre de repli utilisée lorsque les dates sont vides (par défaut 30)
Nœuds par type de correcteur	taille de l’échantillon par type ; `0` désigne tous les nœuds du parc
Sessions minimales par nœud pour l’IQR	nombre minimal de sessions requis pour qu’un nœud soit éligible (par défaut 30)
Nombre de nœuds problématiques dans le rapport	taille de la table top-N (par défaut 50)
Analyse LLM	récit IA optionnel expliquant les résultats
Société de distribution	restreint l’analyse au parc d’un seul fournisseur

Données d’entrée

Données principales

Donnée	À quoi elle sert
Liste des nœuds	déterminer le parc à analyser
Type de correcteur	construire le détail par modèle
`Equipment ID`	récupérer les sessions d’un appareil précis
Sessions de communication	cœur du rapport
Heure de début de session	regroupement par jours, mois et heures
Durée de session	principal indicateur analysé
`RSSI` / `CSQ`	estimation de la qualité du signal radio
`Btm` / batterie	estimation de l’influence de l’alimentation
Organisation / emplacement	attribution des incidents : client local, station de base, parc

Ensemble minimal requis

Pour une analyse correcte d’un nœud, il faut :

l’identifiant de l’appareil ;
au moins le nombre minimal de sessions ;
la durée de chaque session ;
l’horodatage de chaque session.

Si la durée de session est manquante, cette session ne participe pas à l’analyse IQR.

Disponibilité des données : le filtre de données

Avant de calculer les anomalies, le rapport vérifie si l’analyse peut être réalisée. Le bloc de disponibilité des données indique la taille du parc, sa taille après le filtre société, combien de nœuds ont renvoyé des données de session et combien d’entre eux ont franchi le minimum de sessions requis pour l’IQR. Il s’agit d’un diagnostic d’importance critique — sans lui, « aucune anomalie » se confond facilement avec « aucune donnée pour l’analyse ».

Principaux indicateurs de disponibilité

Indicateur	Formule / valeur
Nœuds du parc	`N_park`
Nœuds de l’échantillon	`N_sampled`
Nœuds avec données de session	`N_with_data`
Nœuds ayant franchi le minimum de sessions	`N_qualified`
Total des sessions	`N_sessions`
Appels API	`N_calls`
Erreurs API	`N_errors`
Taux d’erreur API	`N_errors / N_calls × 100%`
Couverture des données	`N_with_data / N_sampled × 100%`
Couverture de l’échantillon IQR	`N_qualified / N_sampled × 100%`

Taux d’erreur API

APIErrorRate = \frac{N_{errors}}{N_{calls}} \times 100\%

Couverture des données

Coverage_{with\_data} = \frac{N_{with\_data}}{N_{sampled}} \times 100\%

Couverture par nœuds éligibles à l’IQR

Coverage_{qualified} = \frac{N_{qualified}}{N_{sampled}} \times 100\%

Statuts de disponibilité

Statut	Condition	Signification
`OK`	un échantillon suffisant pour l’IQR existe	le rapport peut être lu comme opérationnel
`DEGRADED`	l’échantillon est restreint mais l’analyse est possible	les conclusions sont prudentes
`INCONCLUSIVE`	nombreuses erreurs ou couverture trop basse	les conclusions sur les anomalies ne sont pas fiables
`NO_DATA`	aucune donnée de session	l’analyse est impossible
`NO_FLEET`	aucun nœud après filtrage	rien à analyser

Conditions critiques

L’analyse est considérée comme impossible si :

APIErrorRate \ge 50\%

ou :

Coverage_{with\_data} < 5\%

ou :

N_{qualified} = 0

Minimum de sessions par nœud

Pour une analyse IQR fiable, chaque nœud doit disposer d’un nombre suffisant de sessions.

Seuil minimal

Par défaut :

N_{sessions,station} \ge 30

Si un nœud a moins de sessions, sa norme individuelle est jugée statistiquement non fiable et le nœud ne franchit pas le filtre IQR.

Pourquoi un minimum est nécessaire

L’IQR repose sur des estimations de quartiles. Avec un faible nombre d’observations, le quartile devient instable :

une seule session longue aléatoire peut surestimer le seuil ;
une seule période de communication courte peut sous-estimer le seuil ;
il devient impossible de distinguer la norme du nœud du simple hasard.

Norme individuelle de durée de session

Pourquoi la norme est individuelle

On ne peut pas utiliser un unique seuil commun pour l’ensemble du parc, par exemple « toute session de plus de 10 minutes est mauvaise ». Les nœuds ont des conditions de communication différentes :

des types de correcteurs différents ;
des opérateurs de réseau mobile différents ;
des RSSI différents ;
des volumes d’archives différents ;
des plannings d’interrogation différents ;
des sites d’installation différents ;
des antennes différentes.

C’est pourquoi chaque nœud dispose de sa propre norme statistique calculée.

Sélection des durées valides

Pour chaque nœud, seules les durées positives sont retenues :

D = \{d_i \mid d_i > 0\}

où :

d_i — durée de la i-ème session en secondes.

Quartiles

Les durées sont triées par ordre croissant.

D_{sorted} = sort(D)

Premier quartile :

Q1 = percentile(D, 25\%)

Médiane :

Q2 = median(D)

Troisième quartile :

Q3 = percentile(D, 75\%)

Écart interquartile

IQR = Q3 - Q1

Borne supérieure de la norme par les bornes de Tukey

Pour chaque nœud, une borne supérieure individuelle de la norme est calculée :

UpperFence = Q3 + 1.5 \times IQR

Il s’agit de la règle classique des bornes de Tukey pour la détection des valeurs aberrantes.

Session longue

Une session est considérée comme anormalement longue si :

d_i > UpperFence

où :

d_i — durée de session ;
UpperFence — seuil individuel de ce nœud.

Indicateurs de base du nœud

Pour chaque nœud, les indicateurs suivants sont calculés.

Nombre total de sessions

N_{total} = count(D)

Nombre de sessions longues

N_{long} = count(d_i > UpperFence)

Part des sessions longues

Pct_{long} = \frac{N_{long}}{N_{total}} \times 100\%

Durée moyenne de toutes les sessions

AvgDuration = \frac{\sum d_i}{N_{total}}

Durée moyenne des sessions longues

AvgLongDuration = \frac{\sum_{d_i > UpperFence} d_i}{N_{long}}

Durée maximale

MaxLongDuration = max(d_i \mid d_i > UpperFence)

RSSI moyen

RSSI_{avg} = \frac{\sum RSSI_i}{N_{RSSI}}

où N_RSSI est le nombre de sessions disposant d’une valeur RSSI.

Score de problème du nœud

Sens du score

Le score indique à quel point un nœud est problématique en matière de sessions longues. Il prend en compte trois dimensions :

la part des sessions longues ;
l’ampleur du dépassement de la norme par les sessions longues ;
le nombre absolu de sessions longues.

Cette approche évite de surévaluer une valeur aberrante ponctuelle et de sous-évaluer un nœud comptant un grand nombre de sessions modérément longues.

Composante A — part des sessions longues

A = min(100,\;4 \times Pct_{long})

Interprétation :

Part des longues	A
5%	20
10%	40
25%	100
>25%	100

Composante B — durée relative

B = min \left( 100,\; 8 \times \frac{AvgLongDuration}{max(1, MedianDuration)} \right)

où MedianDuration est la durée médiane de session du nœud.

Interprétation :

AvgLong / Median	B
2×	16
5×	40
10×	80
12.5×	100

Composante C — nombre de sessions longues

C = min(100,\;N_{long})

Autrement dit, 100 sessions longues ou plus donnent la contribution maximale de cette composante.

Score final

Score = 0.5 \times A + 0.3 \times B + 0.2 \times C

où :

A — part des sessions longues ;
B — durée relative des sessions longues ;
C — nombre absolu de sessions longues.

Le score final est borné par l’intervalle :

0 \le Score \le 100

Interprétation du score

Score	Niveau
≥ 80	nœud de communication critique
60–80	priorité élevée
40–60	priorité moyenne
20–40	observation / contrôle planifié
< 20	signal faible

Estimation de la perte batterie sur les sessions longues

Sens

Une session longue allonge le temps de transmission et peut consommer de la batterie en plus. Le rapport fournit une estimation approximative de la dépense énergétique excédentaire. Il ne s’agit pas d’une mesure précise de batterie, mais d’une estimation opérationnelle.

Temps de transmission excédentaire

Pour chaque session longue, l’excédent par rapport à la norme médiane du nœud est calculé :

ExtraTime_i = max(0,\;d_i - MedianDuration)

Temps excédentaire total :

ExtraTime_{total} = \sum_{i \in LongSessions} ExtraTime_i

Courant de transmission

Un courant de transmission de base est utilisé pour l’estimation approximative :

I_{TX} = 340 \; mA

Perte batterie

BatteryLoss_{mAh} = \frac{I_{TX} \times ExtraTime_{total}}{3600}

où :

ExtraTime_total — en secondes ;
I_TX — courant en milliampères ;
résultat — en mAh.

Pour l’affichage en Ah :

BatteryLoss_{Ah} = \frac{BatteryLoss_{mAh}}{1000}

Limitation

Cette estimation ne tient pas compte :

du profil de courant réel du modèle précis ;
du mode veille ;
des nouvelles tentatives au niveau du modem ;
de la puissance d’émission ;
de la température ;
de l’âge de la batterie ;
de la capacité de la batterie ;
de la qualité du réseau au moment de la transmission.

Elle doit donc être lue comme une estimation d’ordre de grandeur, et non comme une mesure de laboratoire.

RSSI et CSQ

RSSI

RSSI indique le niveau du signal radio en dBm. Plus la valeur est proche de zéro, plus le signal est fort.

Interprétation approximative :

RSSI	Évaluation
≥ −65 dBm	bon signal
−65…−75 dBm	acceptable
−75…−85 dBm	faible
< −85 dBm	très faible

CSQ

Certains appareils ne transmettent pas le RSSI en dBm, mais le CSQ — l’indice de qualité du signal GSM. Si la valeur ressemble à un CSQ, elle peut être convertie :

RSSI_{dBm} = -113 + 2 \times CSQ

Exemple :

CSQ = 29

RSSI = -113 + 2 \times 29 = -55 \; dBm

Signal localement faible

Si :

RSSI_{avg} < -85 \; dBm

et que les anomalies du nœud ne coïncident pas avec des incidents massifs du parc, la cause peut être classée comme :

text

signal faible au site d'installation

Regroupement des sessions longues en incidents

Les anomalies sont regroupées dans des fenêtres horaires. Si plusieurs nœuds ont reçu des sessions longues dans la même heure, il ne s’agit pas d’un problème local de nœud, mais d’un incident réseau, serveur ou opérateur. L’hypothèse est déterminée automatiquement par l’étendue de la couverture — le nombre de nœuds, de modèles et de clients dans la fenêtre.

Pourquoi le regroupement est nécessaire

Si des sessions longues sont apparues sur de nombreux nœuds dans la même heure, il ne s’agit probablement pas d’un problème local d’un seul appareil. Cela peut être :

un problème de station de base ;
une surcharge locale de l’opérateur ;
un incident réseau massif ;
une opération serveur planifiée ;
une particularité du micrologiciel d’un modèle précis.

Compartiment horaire

Chaque session longue est placée dans un compartiment horaire :

Bucket(t) = floor\left( \frac{t}{1h} \right) \times 1h

Autrement dit, tous les événements survenant dans une même heure tombent dans un même compartiment.

Incident

Un compartiment horaire est considéré comme un incident si au moins :

N_{stations,bucket} \ge 5

nœuds sont touchés.

Indicateurs d’incident

Pour chaque incident, les éléments suivants sont calculés :

Indicateur	Formule
nombre de nœuds	`count(unique station_id)`
nombre de modèles	`count(unique equipment_type)`
nombre de clients / emplacements	`count(unique customer_id)`
nombre de sessions	`count(long sessions in bucket)`
RSSI moyen	`average(RSSI)`
principaux modèles	`top equipment types by count`

RCA : attribution de la cause d’incident

Synthèse de l'investigation des causes racines

La synthèse du parc identifie le principal responsable — pylône, serveur, réseau, micrologiciel ou nœud local —, fournit une attribution des responsabilités entre les nœuds présentant des anomalies et constitue un plan d’action. Un récit IA optionnel, en bas, explique les chiffres en langage clair, mais ne les modifie pas.

La RCA est la classification de la cause probable des sessions longues.

Hypothèses possibles

Hypothèse	Signification
`Server driver`	défaillance du pilote de collecte de masse
`Server routine`	opération ou maintenance serveur régulière
`Network outage`	défaillance de l’opérateur de réseau mobile
`Cell tower`	problème d’une station de base ou d’un emplacement précis
`Firmware`	problème de modèle d’appareil / de micrologiciel
`Local signal`	signal faible au site d’installation
`Battery low`	alimentation insuffisante / dégradation de la batterie
`Isolated device`	dysfonctionnement local d’un nœud précis
`Mixed causes`	causes mixtes

Incident serveur étendu

Un incident est classé comme serveur si de nombreux nœuds, de nombreux modèles et de nombreux clients sont touchés simultanément. Conventionnellement :

N_{stations} \ge ServerWideStations

N_{models} \ge ServerWideModels

N_{customers} \ge ServerWideCustomers

Dans le rapport, cela signifie :

text

incident étendu au parc, ne ressemblant pas à un problème local d'un seul nœud.

Défaillance du réseau de l’opérateur

Si plusieurs modèles et plusieurs clients sont touchés, mais que l’ampleur n’atteint pas celle d’une défaillance serveur :

N_{models} \ge 3

et :

N_{customers} \ge 3

alors l’hypothèse est :

text

défaillance du réseau mobile / incident opérateur

Problème de station de base

Si de nombreux nœuds sont touchés, mais qu’ils appartiennent à un ou deux emplacements / clients :

N_{customers} \le 2

et :

N_{stations} \ge CellMinStations

alors l’hypothèse est :

text

problème de station de base ou problème de couverture local

Problème de micrologiciel ou de modèle

Si un seul modèle est touché, mais chez différents clients :

N_{models} = 1

et :

N_{customers} \ge 3

alors l’hypothèse est :

text

particularité de micrologiciel / de modèle d'appareil

Causes mixtes

Si les conditions ne permettent pas une classification univoque, l’incident reçoit le statut :

text

causes mixtes

Routine serveur récurrente

Il arrive que des incidents serveur massifs surviennent à la même heure de la journée.

Condition

S’il existe au moins trois incidents serveur étendus à la même heure de la journée :

N_{server\_incidents,same\_hour} \ge 3

ils peuvent être classés comme :

text

routine serveur

Sens

Cela peut indiquer une tâche nocturne régulière, une maintenance des archives, un traitement par lot ou une opération de masse qui affecte la durée des sessions.

Attribution de la cause par nœud

Après la recherche des incidents du parc, le rapport détermine ce qui prédomine pour chaque nœud : des incidents externes ou un problème local.

Part des anomalies d’un nœud qui tombent dans des incidents du parc

InIncidentPct = \frac{N_{long,in\_incidents}}{N_{long}} \times 100\%

Si la plupart des anomalies ont coïncidé avec des incidents du parc

Si :

InIncidentPct \ge 70\%

alors la cause dominante du nœud est reprise de l’incident du parc :

text

network_outage / cell_tower / firmware / server

Cela signifie :

text

l'appareil n'est probablement pas le principal responsable ; il a subi le problème avec les autres.

Contrôle de batterie faible

Si les anomalies ne s’expliquent pas par des incidents du parc, l’alimentation est contrôlée. Soit :

Btm_{first}

la première valeur de batterie disponible dans les sessions longues, et :

Btm_{last}

la dernière valeur disponible. La baisse :

BtmDrop = Btm_{first} - Btm_{last}

L’hypothèse battery_low est possible si :

Btm_{first} < 3500 \; mV

et :

BtmDrop > 200 \; mV

Contrôle de signal localement faible

Si :

RSSI_{avg} < -85 \; dBm

alors l’hypothèse est :

text

signal faible au site d'installation

Dysfonctionnement isolé du nœud

Si :

les anomalies ne coïncident pas avec des incidents du parc ;
la batterie n’explique pas le tableau ;
le RSSI n’est pas critiquement faible ;

alors la cause est classée comme :

text

dysfonctionnement local du nœud

Répartition des hypothèses sur le parc

Pour chaque nœud, la cause dominante est sélectionnée. Lorsque la plupart des nœuds ont subi des incidents du parc, le nœud lui-même n’est pas en cause ; seule une minorité présente un problème local isolé. Cela modifie le plan d’action : l’effort principal porte sur les stations de base et l’opérateur, et non sur une intervention de masse auprès de chaque nœud présentant des anomalies.

Le rapport indique combien de nœuds sont attribués à chaque cause dominante.

Formule de la part d’une hypothèse

Share_{hypothesis} = \frac{N_{stations,hypothesis}}{N_{stations,with\_anomalies}} \times 100\%

Groupes de causes

Pour la synthèse de direction, les hypothèses peuvent être regroupées :

Groupe	Comprend
réseau / serveur	`server_driver`, `server_routine`, `network_outage`, `cell_tower`
problèmes locaux d’appareil	`isolated_device`, `local_signal`, `battery_low`
modèle / micrologiciel	`firmware`
mixte	`mixed`

Interprétation

Prédomine	Que faire
`Cell tower`	vérifier la couverture, l’opérateur, les antennes externes chez les clients touchés
`Local signal`	intervention sur le nœud précis, antenne, répéteur, site d’installation
`Isolated device`	diagnostic modem, SIM, alimentation, micrologiciel
`Firmware`	vérifier la version logicielle et contacter le fournisseur
`Server routine`	vérifier les processus réguliers de la plateforme
`Network outage`	interroger l’opérateur de réseau mobile par horaire et zone

Top des nœuds problématiques

La table du top des nœuds problématiques classe les nœuds selon un score composite (0–100) construit à partir de la part des sessions longues, de leur durée moyenne et de leur nombre. Un clic sur une ligne déploie les sessions les plus longues du nœud avec les valeurs RSSI et Btm — ce qui sert à planifier une intervention sur site.

Objet

La table indique où se rendre ou ce qu’il faut contrôler en premier.

Colonnes de la table

Colonne	Signification
Nœud	nom et identifiant du nœud
Correcteur	type d’appareil
Sessions	nombre total de sessions valides
Longues	nombre de sessions anormalement longues
Part	pourcentage de sessions longues
Longue moyenne	durée moyenne des sessions longues
Session maximale	pire session trouvée
`RSSI` moyen	qualité du signal radio
Perte batterie	énergie excédentaire estimée
Score	score composite de problème

Comment lire le top

Un score élevé peut résulter de différentes raisons :

une part importante de sessions longues ;
des sessions individuelles très longues ;
un grand nombre absolu de sessions longues ;
une combinaison de ces facteurs.

Pour planifier une intervention sur site, ne lisez pas seulement le score, mais aussi :

le RSSI ;
l’hypothèse RCA ;
la perte batterie ;
la session maximale ;
l’appartenance ou non à des incidents du parc ;
le type de correcteur.

Top des jours problématiques

Toutes les sessions anormales sont regroupées par jour calendaire. Le jour comptant le plus grand nombre d’anomalies est le plus susceptible de correspondre à un incident du parc. Chaque jour se déploie en une liste des nœuds avec leurs anomalies, la session maximale et des liens. C’est utile pour investiguer des événements massifs et vérifier leur récurrence.

Objet

Le détail par jours met en évidence les jours où des sessions longues sont apparues en masse à l’échelle du parc.

Indicateurs du jour

Indicateur	Signification
Date	jour calendaire
Sessions longues	nombre de sessions longues pour le jour
Nœuds	combien de nœuds sont touchés
Longue moyenne	durée moyenne des sessions longues
Session maximale	pire cas du jour
Pire nœud	nœud présentant la session maximale

Interprétation

Tableau	Cause possible
de nombreux nœuds le même jour	incident réseau ou de parc
un même nœud chaque jour	problème local
un pic un week-end	réseau opérateur / travaux de maintenance
des pics à la même heure	tâche régulière ou planification
croissance mensuelle	dégradation du réseau, surcharge saisonnière, changement de mode d’interrogation

Détail par type de correcteur

Le bloc de couverture indique ce qui a été vérifié dans le parc pour chaque type de correcteur : combien de nœuds figurent dans l’échantillon, combien ont renvoyé des données, combien ont franchi l’IQR et combien présentent des anomalies. Si un type affiche « norme », des données sont bien arrivées, mais aucune anomalie n’a été trouvée. « Aucune donnée » signifie que le type ne renvoie pas la durée de session dans l’API — pour certains modèles, c’est normal.

Détail approfondi par type de correcteur

Déployez un type pour voir tous ses nœuds présentant des anomalies ; déployez un nœud pour voir ses sessions longues précises avec l’heure, la durée, le RSSI et le Btm. La couleur de mise en évidence de la session dépend de l’ampleur du dépassement de la norme du nœud par cette session.

Objet

Le détail par type de correcteur indique quels modèles tombent plus souvent en sessions anormalement longues.

Indicateurs par type

Indicateur	Signification
Dans l’échantillon	combien de nœuds de ce type figurent dans le parc
Avec données	combien de nœuds ont renvoyé des données de session
IQR franchi	combien de nœuds disposent du minimum de sessions
Anomalies	nombre de sessions longues
État	norme / anomalies / aucune donnée

Limitation importante

On ne peut pas comparer directement les types de correcteurs par le seul nombre d’anomalies. Il faut tenir compte :

du nombre d’appareils de ce type dans le parc ;
du nombre d’entre eux ayant renvoyé des données ;
du nombre ayant franchi le minimum de sessions ;
de leur lieu d’installation ;
des réseaux dans lesquels ils opèrent ;
de l’identité ou non de leur planning d’interrogation ;
de leur concentration éventuelle chez un seul client.

Part d’anomalies normalisée par type

Pour une comparaison correcte, vous pouvez utiliser :

TypeAnomalyRate = \frac{N_{long,type}}{N_{sessions,type}} \times 100\%

ou :

TypeAffectedRate = \frac{N_{stations\_anomalous,type}}{N_{stations\_qualified,type}} \times 100\%

Détail temporel : dynamique et mois

Le graphique de dynamique quotidienne montre combien de sessions anormales sont survenues à l’échelle du parc chaque jour de la fenêtre. Des « flambées » sont visibles — des jours de mauvaise communication sur l’ensemble du réseau. Un pic coïncidant avec le registre des incidents correspond généralement à une série de problèmes de station de base à un même emplacement.

Le détail par mois calendaire aide à repérer une saisonnalité ou une tendance de long terme. Un pic mensuel massif correspond à la même série d’incidents observée dans la dynamique quotidienne ; une croissance progressive dans le temps est un candidat à une dégradation de la communication ou de la batterie.

Objet

Le détail par mois met en évidence une saisonnalité ou une tendance de long terme des sessions longues.

Indicateur du mois

N_{long,month} = count(long\_sessions \; in \; month)

Part du mois

Si vous devez afficher une part :

Share_{month} = \frac{N_{long,month}}{\sum N_{long,all\_months}} \times 100\%

Interprétation

Tableau	Explication possible
pic mensuel brutal	changement de réseau, défaillance massive, charge saisonnière
croissance progressive	dégradation de la communication ou de la batterie
pic hivernal	conditions météo, charge réseau, alimentation
pic après une mise à jour	micrologiciel, paramètres, planning d’interrogation

Mise en évidence par couleur par session

Lorsqu’un nœud est déployé, ses sessions longues individuelles sont mises en évidence selon l’intensité du dépassement du seuil individuel, et les valeurs précises de RSSI et de Btm au moment de chaque session longue sont affichées. C’est précisément ce dont l’équipe de terrain a besoin : un RSSI bas pointe vers un problème de signal radio, tandis qu’une tension de batterie normale écarte la batterie.

Rapport de dépassement

Ratio_i = \frac{d_i}{UpperFence}

Interprétation

Ratio	Couleur / niveau
1–2×	dépassement faible
2–5×	dépassement moyen
≥5×	dépassement fort

Cela aide à distinguer rapidement les sessions modérément longues des sessions extrêmes.

Que faire à partir des résultats du rapport

Si la cause est une station de base

Vérifier :

la qualité de couverture à l’emplacement ;
un opérateur de réseau mobile alternatif ;
une antenne externe ;
un répéteur ;
la récurrence des incidents par jour ;
les nœuds voisins au même emplacement ;
la surcharge réseau à des heures précises.

Si la cause est un nœud local

Vérifier :

l’antenne ;
la carte SIM ;
le modem ;
l’alimentation ;
la batterie ;
les connecteurs ;
le site d’installation ;
les interférences ;
la version du micrologiciel ;
les paramètres de planning de transmission.

Si la cause est un signal faible

Actions :

mesurer le RSSI sur place ;
essayer de déplacer l’antenne ;
vérifier l’orientation de l’antenne ;
vérifier un opérateur alternatif ;
installer une antenne externe ou un répéteur.

Si la cause est la batterie

Actions :

vérifier le Btm sur place ;
remplacer la batterie si nécessaire ;
vérifier le courant de consommation ;
vérifier la fréquence des nouvelles tentatives ;
vérifier si l’appareil surcharge le réseau de nouvelles tentatives.

Si la cause est le modèle / le micrologiciel

Actions :

regrouper les nœuds par version logicielle ;
consulter les notes de version du fournisseur ;
demander les problèmes connus ;
comparer avec d’autres modèles aux mêmes emplacements ;
tester le mode de communication en laboratoire.

Commentaire de l’IA

Le commentaire optionnel de l’IA lit la RCA et rédige un court plan d’intervention sur site, lisible pour l’équipe. Il s’agit d’une explication en langage naturel, et non d’une source de diagnostic — tous les chiffres et toutes les causes sont déterminés par les formules et règles ci-dessus.

Ce que l’IA peut faire

résumer brièvement la RCA ;
expliquer le principal responsable probable ;
mettre en avant les principaux nœuds ;
formuler un plan d’intervention sur site ;
expliquer le détail par modèles.

Ce que l’IA ne peut pas faire

L’IA ne peut pas :

modifier le seuil IQR ;
modifier la liste des sessions longues ;
modifier le score ;
déterminer la cause réelle sans données ;
se substituer à une étude radioélectrique ;
se substituer à une intervention sur site ;
servir de base probante.

Erreurs d’interprétation typiques

Erreur : session longue = appareil défectueux

Incorrect. Une session longue peut être causée par le réseau, la station de base, un signal faible, une routine serveur, l’antenne locale, la carte SIM ou la batterie.

Erreur : beaucoup d’anomalies pour un modèle = le modèle est mauvais

Incorrect. Il faut normaliser par le nombre d’appareils, le nombre de sessions, les emplacements et les opérateurs de réseau mobile.

Erreur : aucune anomalie = tout va bien

Incorrect s’il n’y a pas de données de session ou si la couverture est trop basse.

Erreur : un RSSI élevé écarte un problème de communication

Pas toujours. Il peut y avoir des problèmes d’opérateur, une surcharge, du micrologiciel, une réception côté serveur, des nouvelles tentatives ou des erreurs de protocole.

Erreur : perte batterie = consommation exacte de la batterie

Incorrect. Il s’agit d’une estimation fondée sur le temps de transmission excédentaire et un courant conventionnel.

Erreur : une session extrêmement longue fait du nœud le principal problème

Pas toujours. Le score tient compte non seulement du maximum, mais aussi de la part, de la durée moyenne et du nombre de sessions longues.

Critères minimaux d’un rapport complet

Un rapport est jugé méthodologiquement complet s’il contient :

la période d’analyse ;
la couverture du parc ;
le statut du filtre de données ;
le nombre de nœuds du parc ;
le nombre de nœuds interrogés ;
le nombre de nœuds avec données de session ;
le nombre de nœuds ayant franchi le seuil IQR ;
le nombre de sessions dans l’échantillon ;
le nombre de sessions longues ;
le nombre de nœuds présentant des anomalies ;
la durée maximale de session ;
le nombre d’incidents horaires ;
la distribution des hypothèses RCA ;
la formule du seuil IQR ;
la formule du score du nœud ;
la formule de perte batterie ;
les règles de classification RCA ;
la table du top des nœuds problématiques ;
le détail par jours ;
le détail par type de correcteur ;
le détail par mois ;
la mention sur le caractère approximatif de la perte batterie ;
la mention sur le rôle de l’IA ;
les recommandations d’actions.

Formule consolidée du rapport

Pour chaque nœud :

D = \{d_i \mid d_i > 0\}

IQR = Q3(D) - Q1(D)

UpperFence = Q3(D) + 1.5 \times IQR

LongSessions = \{d_i \mid d_i > UpperFence\}

Pct_{long} = \frac{|LongSessions|}{|D|} \times 100\%

A = min(100,\;4 \times Pct_{long})

B = min \left( 100,\; 8 \times \frac{AvgLongDuration}{max(1, MedianDuration)} \right)

C = min(100,\;|LongSessions|)

Score = 0.5A + 0.3B + 0.2C

Estimation de la consommation batterie excédentaire :

ExtraTime_{total} = \sum_{d_i \in LongSessions} max(0,\;d_i - MedianDuration)

BatteryLoss_{mAh} = \frac{340 \times ExtraTime_{total}}{3600}

Regroupement en incidents :

Bucket(t) = floor(t / 1h) \times 1h

Incident = Bucket \; where \; N_{unique\_stations} \ge 5

Clause de non-responsabilité recommandée

text

Le rapport détecte les sessions de communication anormalement longues par rapport à
la norme individuelle de chaque nœud. Le résultat sert à prioriser le diagnostic des
communications, des antennes, des cartes SIM, de l'alimentation, des opérateurs et des
stations de base. Le rapport n'est pas une preuve du dysfonctionnement d'un appareil
précis sans intervention sur site et n'évalue pas l'exactitude du comptage commercial
du gaz.

Lien avec les autres rapports

Si vous devez comprendre	Utilisez
quels nœuds maintiennent longtemps la communication et vident la batterie	ce rapport
quels nœuds n’ont ni communication ni archive	Top des nœuds problématiques
si la période peut être clôturée pour un nœud précis	Analytique de consommation
s’il y a soupçon de sous-comptage	Nœuds suspects
pourquoi un nœud précis est suspect	Contournement du comptage
quand remplacer les batteries	Prévision batterie

Cette séparation évite que les sessions de communication longues soient mêlées à des conclusions commerciales, métrologiques et d’expertise.

Sujets connexes

Explorateur d'événements

Dernière mise à jour le 23 juin 2026

Cette page vous a-t-elle été utile ?