Résumé

  • Entre les révisions 15 et 16, le projet NMOP a choisi de garder le modèle d’incident indépendant de la confiance ; la révision 17 conserve cette séparation.
  • Les projets voisins sur les anomalies transportent pourtant confiance, niveau de préoccupation, identité et version de l’annotateur. Une cause normalisée ne doit donc pas survivre seule à la disparition de cette enveloppe.
  • La bonne architecture ne confond ni cause, ni certitude, ni urgence, ni pouvoir d’agir. Elle relie l’observation, la version analytique, l’incident, l’autorisation et le résultat de service.

Le rapport de garde ne montre que le survivant

À 03 h 17, un système détecte plusieurs pertes de signal, une baisse de puissance optique et l’indisponibilité d’un service. À 03 h 19, le tableau de garde ne présente plus cette diversité. Il affiche un incident critique, un port et une cause probable : panne matérielle d’interface.

Cette condensation est précisément ce que recherchent les opérateurs. Elle évite d’ouvrir une dizaine de tickets pour le même phénomène. Mais le rapport ne dit plus si la cause a été proposée par une règle, un ingénieur ou un modèle ; il ne donne ni la version de cet analyste, ni la fenêtre d’observation, ni l’hypothèse arrivée en deuxième position. La cause est devenue plus lisible au moment même où les réserves qui l’accompagnaient sont sorties du cadre.

draft-ietf-nmop-network-incident-yang-17 rend cette frontière explicite. Son historique indique qu’entre les révisions 15 et 16 le modèle d’incident a été maintenu indépendant de la confiance. Le texte de la révision 15 disait encore que les travaux voisins sur la détection d’anomalies attribuaient des scores de confiance et de préoccupation. La révision 16 retire cette phrase de score sans supprimer le lien architectural. La révision 17, datée du 24 septembre 2026, maintient le choix.

Il faut résister à deux lectures trop faciles. La première conclurait que la confiance ne compte pas. La seconde demanderait qu’un score universel soit ajouté à tout incident. Le projet ne dit ni l’un ni l’autre. Il choisit un noyau d’échange commun qui ne dépend pas d’une méthode analytique particulière.

Un objet de cause riche, mais pas probabiliste

Le modèle peut créer un incident alors que sa source n’est pas encore connue. La liste sources peut être vide, puis être renseignée après le diagnostic. Quand une hypothèse est disponible, probable-causes l’attache à un réseau, à un nœud et éventuellement à une ressource. cause-name est une identité structurée ; detail apporte du contexte ; probable-events renvoie vers les événements associés. Le domaine, la priorité et la catégorie sont obligatoires.

Ce vocabulaire offre une valeur concrète. « Perte de signal » n’est plus une chaîne locale impossible à comparer. Une cause peut être comprise par plusieurs systèmes, reliée à un objet précis et rapprochée des événements qui l’ont motivée.

Cependant, aucun de ces attributs n’est un poids épistémique. La priorité indique l’urgence opérationnelle. La catégorie organise l’incident. L’identité de cause rend le terme stable. La présence d’un événement prouve une relation déclarée. Rien de tout cela ne dit avec quelle probabilité la cause est correcte, selon quelle population elle a été calibrée ou quelles alternatives ont été rejetées.

La définition de « Probable Root Cause » fixe même un critère ambitieux : la suppression complète de la condition doit arrêter l’incident et empêcher sa réapparition ; une condition contributive ne suffit pas. Mais l’objet YANG ne contient ni résultat de suppression, ni fenêtre de non-récurrence, ni test contrefactuel. La sémantique encadre la déclaration ; elle ne transforme pas chaque instance en expérience concluante.

L’enveloppe existe dans la famille des anomalies

Les documents NMOP voisins montrent où peuvent vivre les informations absentes. draft-ietf-nmop-network-anomaly-lifecycle-07 définit un score de confiance de 0 à 100 pour une anomalie ou une stratégie de détection. Il définit séparément un score de préoccupation, lui aussi de 0 à 100, pour exprimer le degré d’attention ou d’action que mérite la situation.

Son modèle conserve aussi la version et l’étape de l’anomalie, l’identité et le nom de l’annotateur, sa nature humaine ou algorithmique et sa version. Le cycle Détection–Validation–Affinement prévoit que l’évaluation soit corrigée au fil de l’expérience. draft-ietf-nmop-network-anomaly-semantics-06 reprend ces éléments dans une représentation sérialisée. La confiance peut même être nulle : la présence du champ ne garantit donc pas la qualité du jugement.

La différence d’objet est saine. Une anomalie décrit le travail d’un détecteur et son évaluation. Un incident coordonne l’exploitation autour d’une situation agrégée. Le danger naît lorsque le passage de l’un à l’autre coupe le lien. La cause sélectionnée devient durable, tandis que l’annotateur, sa version, ses scores et les hypothèses écartées restent dans un magasin temporaire ou sont écrasés.

Le tableau de garde hérite alors du nom mais perd la mesure du doute. Plus le nom est standardisé, plus il peut sembler institutionnellement certain.

Trois axes qu’un feu tricolore confond

La confiance, la préoccupation et la priorité répondent à trois questions différentes.

Une oscillation de trafic prévue peut être détectée avec une confiance très élevée et ne justifier presque aucune intervention. À l’inverse, un signal optique incomplet peut donner une confiance modeste mais une forte préoccupation s’il menace un service critique. La priorité de l’incident peut rester maximale en raison de l’impact possible, même si le diagnostic causal est encore fragile.

Un chiffre unique ne résout pas cette pluralité. Un score de 90 produit par une règle déterministe, un classificateur entraîné et un expert humain n’a pas nécessairement la même signification. Il faut connaître la méthode, la population de calibration, la fenêtre temporelle, le seuil et le coût des erreurs.

L’indépendance du noyau commun évite d’ériger un barème local en vérité universelle. En contrepartie, l’opérateur doit conserver ces trois dimensions dans une enveloppe liée à l’incident, au lieu de les remplacer par une couleur.

Le droit d’agir ne valide pas la croyance

Le projet exige des protocoles de gestion YANG protégés et une authentification mutuelle. Il renvoie à NACM pour limiter l’accès au contenu et aux opérations. C’est indispensable : la liste des services touchés, les causes probables et la forme d’une panne peuvent révéler des informations sensibles sur des clients et sur l’état vulnérable du réseau.

Ces contrôles répondent à « qui peut lire ou agir ? ». Ils ne répondent pas à « pourquoi cette cause mérite-t-elle d’être crue ? ». Un compte parfaitement autorisé peut lancer une action fondée sur une hypothèse mal calibrée. Un détecteur très confiant ne reçoit pas pour autant un mandat de modification.

Toute automatisation de réparation doit donc joindre deux pièces différentes : l’enveloppe qui soutient le diagnostic et l’autorité qui permet l’action. Le résultat observé forme encore une troisième pièce.

Une implémentation nommée n’est pas un résultat mesuré

La section d’état d’implémentation cite Huawei iMaster NCE, avec RESTCONF, gestion du cycle de vie des incidents, notifications et interrogation de la liste. Cette mention constitue une indication utile de code existant.

Le même texte précise que les informations sont fournies par des contributeurs, qu’elles n’ont pas été vérifiées par l’IETF, qu’elles n’impliquent pas d’approbation et qu’elles ne constituent pas un catalogue complet. Le paquet de sources ne montre ni test d’interopérabilité de la provenance analytique, ni mesure de calibration, ni incident de production documenté.

On ne peut donc ni effacer l’implémentation, ni la transformer en preuve de résultat. La question à tester est très précise : lorsque l’incident est matérialisé, l’identité et la version de l’annotateur, le score et les alternatives restent-ils rejouables ?

Une frontière distincte de l’article précédent

L’article existant A Cleared Incident Does Not Prove Which Command Cleared It étudie la révision 14 et l’absence de lien explicite entre une commande incident-resolve et une notification ultérieure cleared. Son objet est l’attribution de l’exécution.

Le présent article étudie l’état de la croyance avant cette exécution. Un identifiant de commande parfait ne recrée pas une confiance supprimée. Une cause parfaitement calibrée ne confère pas l’autorisation. Un état de service rétabli ne prouve pas, à lui seul, que la cause initiale était exacte. Les deux frontières sont voisines mais non substituables.

Sources