Résumé

  • RFC 9940 distingue ce qui est mesuré de ce qui est interprété : une Valeur, un Événement, un Défaut, un Problème, un Symptôme, une Cause, une Alerte et une Alarme n’ont pas la même portée.
  • Une alarme peut mériter une action corrective tout en laissant ouvertes l’attribution de la cause, la preuve du rétablissement du service et l’autorisation d’un changement.

Un compteur franchit un seuil, une console se colore, une notification arrive. Rien de cela n’est imaginaire. Pourtant, le récit « la panne a été trouvée et corrigée » ajoute souvent plusieurs propositions qui ne figurent dans aucune mesure. Il faut savoir lesquelles.

RFC 9940, texte informationnel de l’IETF publié en avril 2026, fixe des termes pour la gestion des défauts et problèmes réseau, dans le périmètre de la couche réseau et des couches inférieures. Son objet est l’entente entre modèles et protocoles de gestion. Ce n’est ni une procédure de diagnostic automatique ni un mandat de modification d’un service.

Le document part d’objets modestes. Une Caractéristique est un aspect observable d’une Ressource; une Valeur la mesure. Une Modification est une variation de cette valeur dans le temps, alors qu’un Événement est une variation à un instant distinct. Une Condition interprète une ou plusieurs valeurs; un État est la condition d’une ressource à un moment donné. Le passage de la valeur à l’état est donc déjà une opération d’interprétation, avec une fenêtre temporelle et une perspective.

Vient ensuite la sélection. La Pertinence dépend d’une politique, d’un point de vue, de l’intention et d’autres informations. Une Occurrence est un Événement ou une Modification jugé pertinent. Un Défaut est une Occurrence indésirable pouvant signaler un État actuel ou futur non souhaité. Un Problème est un État indésirable susceptible de demander une action; il ne se réduit pas forcément à une Cause. Un Symptôme indique un Problème. Une Cause peut être suggérée ou déterminée à partir de plusieurs défauts, problèmes et symptômes. Une Alerte indique un Défaut; une Alarme signale un État indésirable demandant attention corrective.

La différence devient concrète lorsque le symptôme disparaît. L’exemple de perte de lumière de RFC 9940 permet que les services redeviennent opérationnels alors que le défaut récent reste inexpliqué. Réparer une microcourbure répond à une question causale; prévenir son retour peut en laisser une autre ouverte. « Le trafic est revenu » établit une observation importante, pas une clôture universelle.

RFC 8632 protège la même frontière dans un modèle d’alarme. Les ressources candidates de cause racine y sont des indices destinés au client. Le modèle sépare aussi is-cleared, état de l’alarme, de closed, état de traitement par l’opérateur. L’un indique que le signal observé a été effacé; l’autre qu’un opérateur considère le travail correctif réussi. Ni l’un ni l’autre ne démontre seul l’origine, la couverture de mesure ou le résultat de tous les services dépendants.

La télémétrie ne doit pas davantage absorber l’intention. RFC 9940 place télémétrie, supervision, analyse et observabilité dans une chaîne; les données de télémétrie ne portent pas à elles seules la définition du service. RFC 9315 définit l’intention comme des objectifs et résultats déclaratifs que le réseau ne connaît pas spontanément. RFC 9417 maintient aussi une séparation entre métrique, symptôme, score de santé et métrique indisponible. Un score peut guider l’enquête; il ne décide pas à lui seul d’un reroutage, d’une suspension ou d’une promesse au client.

Daniel Kade utilise ici la séparation des couches de réalité de docs/heng-lu-note.md comme discipline éditoriale, non comme exigence IETF. Garder la lecture brute, le seuil, la politique, la qualification, l’hypothèse causale, la décision autorisée, le changement et l’observation après changement permet d’agir vite sans baptiser une étiquette « preuve complète ».

Sources