Problèmes opérationnels et cycle de vie

L'Operational Issue comme unité de travail — modèle de base, distinction entre Issue et Task, types unitaire et massif, workflow des statuts avec sa matrice de transitions, et journal d'audit immuable.

Operational Issue

Operational Issue est l’entité centrale d’OHM.

C’est un objet à état (stateful) qui représente un problème d’exploitation tout au long de son cycle de vie.

Modèle de base

yaml

id: OHM-2026-001842
kind: single
canon: no_hourly_archive
title: 'Hourly archive is missing'
priority: P1
severity: critical
confidence: 0.94

scope:
  organization: 'Demo Gas Utility'
  region: 'North'
  asset_id: 'station-5690'

ownership:
  zone: backend_integration
  assignee: 'Integration-2'

timestamps:
  first_detected_at: '2026-07-21T04:00:00Z'
  created_at: '2026-07-21T04:03:12Z'
  acknowledged_at: '2026-07-21T05:10:00Z'
  due_at: '2026-07-22T04:00:00Z'
  resolved_at: null

status:
  workflow: in_progress
  snapshot: persistent
  overdue: false
  unattended: false
  chronic: false

root_cause:
  class: communication
  hypothesis: 'device does not establish a communication session'
  confidence: 0.82
  confirmed: false

evidence: []
tasks: []
history: []
related_issues: []
knowledge_articles: []

Fiche Operational Issue présentant l'indicateur d'étapes du workflow, les Evidence des détecteurs, une hypothèse de Root Cause produite par l'AI avec sa probabilité, la synthèse de l'impact métier et les articles de la Knowledge Base classés par pertinence — Fiche Issue : indicateur d'étapes du workflow, Evidence des détecteurs, AI Root Cause avec probabilité, impact métier, articles de solutions connues (KB) classés par pertinence

Issue et Task sont deux entités distinctes

Une Issue répond à la question :

Quel problème d’exploitation doit être résolu ?

Une Task répond à la question :

Quelle action précise doit être exécutée ?

Une même Issue peut contenir plusieurs Tasks. Pour l’Issue archive manquante sur 38 équipements :

Task 1 — vérifier la disponibilité de la passerelle ;
Task 2 — vérifier la file d’attente du serveur ;
Task 3 — comparer les versions de firmware ;
Task 4 — contacter l’opérateur du réseau mobile ;
Task 5 — réaliser une inspection sur site par échantillonnage.

La clôture d’une seule Task n’entraîne pas automatiquement celle de l’Issue.

Issues unitaires et Issues massives

OHM utilise un modèle unique pour les deux échelles :

Type	Description
`single`	un problème affectant un actif ou une entité logique
`massive`	un incident systémique affectant un groupe d’actifs
`manual`	un problème enregistré par une personne
`external`	un problème importé depuis un système externe

Cycle de vie d’une Operational Issue

Workflow principal

flowchart TD
  S1["Détecté"] --> S2["Triage effectué"]
  S2 --> S3["Affecté"]
  S3 --> S4["Accepté"]
  S4 --> S5["En cours"]
  S5 --> S6["En attente de vérification"]
  S6 --> S7["Vérifié"]
  S7 --> S8["Résolu"]
  S8 --> S9["Archivé"]

Résultats terminaux supplémentaires :

annulé ;
doublon ;
non reproduit ;
correction non prévue ;
risque accepté.

Statuts du workflow

Statut	Signification
`detected`	l’Issue a été créée automatiquement ou manuellement
`triaged`	la gravité, la zone de responsabilité et le contexte initial ont été examinés
`assigned`	un responsable a été désigné
`accepted`	le responsable a confirmé la prise en charge
`in_progress`	les travaux sont en cours
`awaiting_verification`	les travaux sont déclarés terminés et attendent la vérification
`verified`	le résultat a été confirmé
`resolved`	l’Issue est close avec un résultat établi
`archived`	l’objet terminé a été déplacé vers l’historique à long terme
`cancelled`	l’Issue a été annulée pour un motif documenté
`duplicate`	l’Issue est un doublon d’un autre objet
`not_reproduced`	le problème n’a pas été confirmé lors de la vérification
`wont_fix`	une décision de gestion a été prise de ne pas engager de correction
`accepted_risk`	le risque a été formellement accepté par une personne habilitée

Statut du Snapshot

Outre le workflow, OHM suit l’état du problème à partir du Snapshot quotidien des détecteurs :

Statut du Snapshot	Signification
`new`	le problème est apparu pour la première fois
`persistent`	le problème persiste
`worsened`	l’état s’est dégradé
`improved`	l’état s’est amélioré, mais le problème subsiste
`cleared`	le détecteur ne confirme plus le problème
`reopened`	le problème est réapparu après la clôture

Le statut du workflow et le statut du Snapshot ne sont jamais confondus.

Exemple : workflow_status = in_progress avec snapshot_status = improved.

Cela signifie que les travaux se poursuivent alors que les données objectives montrent déjà une amélioration.

Matrice des transitions

Statut courant	Transitions autorisées
detected	triaged, assigned, duplicate, cancelled
triaged	assigned, cancelled, accepted_risk
assigned	accepted, in_progress, reassigned
accepted	in_progress, reassigned
in_progress	awaiting_verification, escalated, accepted_risk
awaiting_verification	verified, in_progress
verified	resolved
resolved	reopened, archived
reopened	triaged, assigned, in_progress
tout statut actif	duplicate, cancelled

Chaque transition est consignée dans un journal d’événements immuable.

Écran de référence listant les statuts du cycle de vie d'une Issue avec leurs transitions autorisées, les statuts du Snapshot et les étapes d'un incident — Statuts et workflow : le cycle de vie d'une Issue avec ses transitions autorisées, les statuts du Snapshot et les étapes d'un incident

Journal d’audit (Audit Trail)

Toutes les actions significatives sont consignées dans un historique immuable.

Un événement contient :

yaml

event_id: EVT-9038172
issue_id: OHM-2026-001842
event_type: status_changed
timestamp: '2026-07-23T10:14:00Z'
actor:
  type: user
  id: 'usr-231'
  role: 'zone_manager'
before:
  status: assigned
after:
  status: in_progress
reason: 'Diagnostics started'
source:
  ip: 'masked'
  client: 'web'
correlation_id: 'req-982310'

Sont systématiquement journalisés :

la création ;
l’affectation ;
la réaffectation ;
le changement de priorité ;
le changement d’échéance ;
le changement de statut ;
le commentaire ;
l’ajout d’une Evidence ;
la confirmation de la Root Cause ;
la vérification manuelle ;
l’acceptation du risque ;
l’application d’un article KB ;
la fusion et la scission d’Issues ;
la modification de la configuration d’un détecteur ;
les actions d’export et d’intégration.

Suite de la fiche Issue, avec la liste de contrôle des Tasks et la chronologie des événements consignant chaque action menée sur l'Issue — Fiche Issue (suite) : liste de contrôle des Tasks et chronologie complète des événements — la source unique de tous les KPI

Sujets connexes

Dernière mise à jour le 4 août 2026

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