03 · Alten · banque
Un décalage de dates qui traînait depuis deux ans
Certains enregistrements étaient comptabilisés la veille de leur date réelle. Un bug de fuseau horaire dans une conversion, présent depuis 2023.
- Symptôme circonscrit aux événements survenus entre 1 h et 2 h du matin
- Cause : conversion de timestamp dépendante du fuseau horaire
- Correction par extraction directe de la date, sans passer par un timestamp
- Déploiement canal par canal, avec validation en bac à sable
Certains enregistrements étaient comptabilisés à la mauvaise date : un événement du 10 apparaissait au 9. Pas tous, une petite proportion seulement. Le problème existait depuis 2023 et avait été signalé plusieurs fois sans jamais être élucidé.
Circonscrire avant d'expliquer
La première étape a été d'isoler des cas précis et reproductibles, en remontant jusqu'aux enregistrements individuels dans le système source. Cela a permis de constater que le décalage ne frappait pas au hasard : il concernait les événements survenus entre une heure et deux heures du matin.
Cette régularité désigne immédiatement un coupable. Un décalage qui n'affecte qu'une plage horaire étroite en début de nuit, c'est une conversion de fuseau horaire.
Le mécanisme
Une étape du flow convertissait une donnée temporelle en passant par un timestamp. Cette conversion appliquait un décalage horaire, ce qui, pour les événements proches de minuit, faisait basculer la date au jour précédent.
Le reste du temps, le décalage existait aussi mais restait invisible : décaler 14 h de deux heures ne change pas la date. Le bug ne se manifestait que sur une fenêtre étroite, ce qui explique qu'il ait survécu deux ans.
La correction
Plutôt que de compenser le décalage, solution fragile qui casse au changement d'heure, j'ai supprimé l'intermédiaire. L'extraction directe de la date, sans passer par un timestamp, rend la conversion indépendante du fuseau.
C'est une correction de quelques lignes, mais qui n'a de valeur que parce que le diagnostic était solide. Sans les cas tracés jusqu'à la source, il aurait été impossible de valider que le problème était bien réglé.
Le déploiement
Canal par canal, avec validation en bac à sable sur les cas connus avant chaque mise en production. Sur un bug de données qui touche l'historique, une correction non vérifiée peut aggraver la situation : on risque de décaler dans l'autre sens des enregistrements qui étaient justes.
Les noms de projets, de tables et de systèmes internes ont été retirés. Les détails techniques sont réels.