Nommer la nature d’une panne plutôt que l’afficher comme une absence

Contexte

Le cockpit interroge les produits du groupe par une route de santé. Quand l’appel échouait, la case restait vide.

Trois situations très différentes donnaient exactement le même écran : le produit répond qu’il ne va pas bien, le délai d’attente est dépassé, ou la sortie réseau du cockpit elle-même a échoué.

Tant que ces trois cas se ressemblent, le cockpit ne peut pas dire s’il diagnostique un produit ou sa propre panne.

Options envisagées

• Retenue

  Enregistrer chaque tentative avec la nature de son échec

  La panne devient une donnée, avec sa date et sa cause, au lieu d’un blanc que chacun interprète.

• Écartée

  Garder une absence unique et lire les journaux serveur en cas de doute

  Le journal serveur n’est pas visible du lecteur, et l’absence continue de mentir à l’écran.

Raisonnement

Technique

Un type énuméré en base porte les quatre natures d’échec. L’interface les traduit en une phrase lisible, sans jargon.

Réglementaire

Une absence non expliquée se lit comme une omission. Nommer la cause est la même discipline que nommer la source d’une valeur.

Économique

Une table de plus et une écriture par tentative, contre un diagnostic qui ne demande plus d’ouvrir un journal serveur.