Détecteurs et problèmes canoniques

Architecture des détecteurs

Détecteur (Detector)

Un Detector est un algorithme qui analyse un jeu de données défini et produit un constat formalisé (finding).

Un détecteur ne pilote pas l’exécution et ne rédige pas de texte libre. Son résultat a un format structuré.

detector_id: archive.tail_gap.v3
detector_version: '3.2.1'
run_id: 'run-20260723-0400'
asset_id: 'station-5690'
observed_at: '2026-07-23T04:00:00Z'

finding:
  canon: no_hourly_archive
  detected: true
  severity: critical
  confidence: 0.98
  value: 73
  unit: 'hours'
  threshold: 24
  baseline: 0

evidence:
  last_valid_hour: '2026-07-20T03:00:00Z'
  expected_end: '2026-07-23T04:00:00Z'
  missing_hours: 73

Chaîne Detector → Canon → Issue

flowchart TD
  D["Detector"] -->|"classification"| C["Canon"]
  C -->|"gestion"| I["Operational Issue"]

• Detector — un algorithme particulier ;
• Canon — un type stable de problème d’exploitation ;
• Operational Issue — une instance du problème dans un contexte donné.

Plusieurs détecteurs différents peuvent confirmer un même canon.

Exemple :

flowchart TD
  D1["archive.tail_gap.v3"] --> CANON["no_hourly_archive"]
  D2["archive.coverage.v2"] --> CANON
  D3["archive.delivery_queue.v1"] --> CANON
  D4["session.freshness.v4"] --> CANON
  CANON --> ISSUE["OHM-2026-001842"]

Classes de détecteurs

Exigences applicables à chaque détecteur

Tout détecteur en production possède :

• un detector_id unique ;
• une version sémantique ;
• une finalité déclarée ;
• un propriétaire ;
• une description des données d’entrée ;
• des seuils contrôlés ;
• des règles d’exclusion ;
• des exigences de taille minimale d’échantillon ;
• des verrous DQ ;
• une formule de Severity ;
• une formule de niveau de confiance ;
• un canon correspondant ;
• un jeu d’Evidence ;
• des tests ;
• un échantillon de contrôle ;
• une estimation des faux positifs ;
• une date de mise en service ;
• un journal des modifications ;
• un mode de désactivation et un retour arrière (rollback).

Verrous de qualité des données (Data Quality Gates)

Un détecteur ne doit pas produire un niveau de confiance élevé si les données sources sont incomplètes ou contradictoires.

Exemples de verrous :

Santé des détecteurs (Detector Health)

OHM surveille la qualité des détecteurs eux-mêmes.

Principaux indicateurs :

• nombre de déclenchements ;
• part des déclenchements confirmés ;
• taux de faux positifs ;
• part des annulations manuelles ;
• part des réouvertures ;
• distribution du niveau de confiance ;
• dérive des données d’entrée ;
• évolution de la structure de l’échantillon ;
• temps moyen jusqu’à la confirmation ;
• version de l’algorithme ;
• nombre d’Issues actives par version.

Problèmes canoniques

Un Canon est une classification métier stable d’un problème, indépendante de l’implémentation d’un détecteur particulier.

Pourquoi les canons sont nécessaires

Sans canons, un système analytique dégénère rapidement en un ensemble de messages incohérents :

• archive_missing
• no_archive
• archive_gap
• hourly_data_absent
• delivery_error

Le canon réunit tous ces signaux équivalents sous un identifiant unique : canon: no_hourly_archive.

Cela apporte :

• un workflow unique ;
• un SLA unique ;
• une analytique claire ;
• des KPI stables ;
• une base de connaissances commune ;
• la comparabilité entre versions ;
• la traduction de l’interface sans modification de la logique ;
• l’intégration avec les systèmes externes.

Structure d’un canon

canon_id: no_hourly_archive
name: 'Hourly archive is missing'
domain: archive
default_owner_zone: backend_integration
default_priority: P1
actionable: true
verification_mode: data
sla_policy: archive_p1
suppression_group: communication_archive
knowledge_tags:
  - archive
  - delivery
  - communication

Jeu de canons de base

Versionnement des canons

La modification d’un texte ou d’une traduction n’impose pas de changer l’identifiant.

Une nouvelle version du canon est requise dès que l’un des éléments suivants change :

• la signification métier ;
• la règle d’affectation ;
• le critère d’actionability ;
• la méthode de vérification ;
• le principe de SLA ;
• la logique de fusion avec d’autres problèmes.

Analytique de la qualité des détecteurs

L’Operational Health Matrix évalue non seulement les équipements, mais aussi la qualité de ses propres algorithmes analytiques.

Pour chaque Detector, le système calcule :

• Accuracy ;
• Precision ;
• Recall ;
• False Positive Rate ;
• False Negative Rate ;
• la confiance moyenne ;
• Drift ;
• Stability ;
• le temps moyen de vérification ;
• le taux d’acceptation.

Cette approche permet d’améliorer en continu le modèle analytique de la Plateforme IIoT sans compromettre la reproductibilité des résultats.

Le portefeuille de détecteurs évolue lui-même selon une roadmap par étapes : les nouveaux détecteurs sont introduits par vagues, chaque vague étant conditionnée par la disponibilité des API sous-jacentes de la plateforme.