Le changement d'heure est une échéance récurrente pour quiconque gère une infrastructure planifiée. L'UE recule ses horloges le 25 octobre et les États-Unis suivent le 1er novembre. Il vaut donc la peine d'auditer vos tâches cron, vos fenêtres de maintenance et vos plannings d'astreinte avant que la prochaine transition ne prenne une tâche au dépourvu. La cause de presque tous les bugs de planification liés au changement d'heure est la même : on a demandé à quelque chose de s'exécuter à une heure locale (heure murale) plutôt qu'à un instant fixe en UTC.
Ce n'est pas un désagrément ponctuel. Cela se produit deux fois par an, dans chaque fuseau horaire qui applique l'heure d'été. Et cela casse discrètement trois catégories d'infrastructure : les tâches planifiées, les fenêtres de maintenance et les rotations d'alerte et d'astreinte.
Ce qui casse vraiment au changement d'heure
Deux fois par an, l'heure locale saute une heure (passage à l'heure d'été) ou en répète une (passage à l'heure d'hiver). Tout ce qui est planifié en heure locale doit alors prendre une décision pour laquelle il n'est généralement pas conçu.
- Des tâches s'exécutent deux fois ou pas du tout. Une sauvegarde planifiée à 01:30 heure locale se déclenchera deux fois lors du passage à l'heure d'hiver, car 01:30 survient deux fois cette nuit-là. Lors du passage à l'heure d'été, une tâche prévue à 02:30 risque de ne jamais se déclencher, car cette heure n'existe tout simplement pas.
- Les fenêtres de maintenance se décalent d'une heure. Une fenêtre définie comme « 02:00–04:00 heure locale » se décale silencieusement par rapport à l'UTC. Une fenêtre censée éviter le trafic de journée peut alors tomber en plein dedans. De même, un gel des déploiements planifié peut commencer une heure trop tôt ou trop tard par rapport à tous les autres systèmes restés en UTC.
- Les relèves d'astreinte se passent mal. Des rotations définies en heure locale peuvent effectuer la relève une heure trop tôt ou trop tard. Elles peuvent aussi alerter deux fois l'ingénieur sortant pendant l'heure répétée.
- Les horodatages des logs semblent remonter le temps. Si les logs sont écrits en heure locale, l'heure entre 01:00 et 02:00 apparaît deux fois la nuit du passage à l'heure d'hiver. Il devient alors impossible de reconstituer une chronologie pendant un incident.
Rien de tout cela n'est un bug de cron, de Kubernetes ou de votre outil d'alerte. C'est ce qui arrive quand un système qui ne comprend que « maintenant » doit se soucier d'une convention calendaire inventée par les humains pour la lumière du jour, et non pour les ordinateurs.
Pourquoi la planification en heure locale est le vrai problème
Le cron POSIX classique (le démon cron utilisé par la plupart des distributions Linux) évalue votre crontab selon le fuseau horaire local du système, défini via /etc/localtime. Il n'a aucune notion d'une heure qui « n'existe pas » ou qui « survient deux fois ». Il vérifie simplement, chaque minute, si l'heure murale actuelle correspond à votre planification. C'est précisément cette ambiguïté qui provoque les doubles exécutions et les exécutions manquées.
Le même problème se retrouve dans les planificateurs managés. Kubernetes a ajouté un champ .spec.timeZone aux CronJob précisément pour qu'on puisse épingler une planification à un fuseau horaire IANA plutôt qu'à l'horloge locale du contrôleur. Pourtant, la documentation de Kubernetes avertit toujours qu'un CronJob peut s'exécuter deux fois, être sauté ou se comporter de manière inattendue autour d'un changement d'heure, même avec un fuseau horaire défini. Les anciennes règles cron d'AWS EventBridge fonctionnent uniquement en UTC, sans aucun paramètre de fuseau horaire. Cela évite l'ambiguïté. En revanche, si vous avez planifié par erreur une règle « 9h heure locale » en vous basant sur l'heure locale, vous devrez la décaler manuellement deux fois par an.
WarningSi votre crontab, votre CronJob Kubernetes ou la configuration de votre planificateur contient un commentaire du type
# runs at 2am local, considérez-le comme un bug de changement d'heure en puissance. L'heure locale dans une définition de planification est le symptôme, pas la solution.
La solution : faire tourner serveurs et planifications en UTC
Le principe fiable est simple : conservez vos serveurs, vos planifications et vos logs en UTC, et ne convertissez en heure locale qu'au moment où un humain les lit. L'UTC ne connaît pas d'heure d'été. 03:00 UTC correspond à 03:00 UTC tous les jours de l'année, sans jamais aucune heure répétée ou sautée.
Concrètement, cela signifie :
- Régler le fuseau horaire système des serveurs sur UTC (
timedatectl set-timezone UTCsur les Linux basés sur systemd). - Écrire chaque entrée crontab, CronJob Kubernetes, timer systemd et règle de planificateur cloud en UTC.
- Stocker tous les horodatages des logs en UTC (ISO 8601 avec le suffixe
Z, par ex.2026-11-01T01:30:00Z). La conversion vers l'heure locale de la personne qui consulte se fait uniquement dans le tableau de bord ou la sortie CLI. - Définir en interne les fenêtres de maintenance et les rotations d'astreinte en UTC. Elles s'affichent ensuite dans le fuseau horaire local de chacun, comme simple couche d'affichage.
Exemples cron concrets
# Bad: local time, ambiguous twice a year
30 1 * * * /usr/local/bin/nightly-backup.sh
# Good: explicit UTC, unambiguous year-round
# (crontab itself has no time zone field — set the system/container to UTC)
TZ=UTC
30 1 * * * /usr/local/bin/nightly-backup.sh
Pour les timers systemd, la même logique s'applique à OnCalendar= :
[Timer]
# Runs at 01:30 UTC every day — set the unit's environment/system TZ to UTC
OnCalendar=*-*-* 01:30:00
Pour Kubernetes, vous avez deux options. Vous pouvez laisser timeZone non défini : il prend alors par défaut l'heure locale du contrôleur, réglez donc cet hôte sur UTC. Vous pouvez aussi le définir explicitement :
spec:
schedule: "30 1 * * *"
timeZone: "Etc/UTC"
Etc/UTC est le seul fuseau IANA garanti sans aucun changement d'heure. C'est précisément pour cela qu'il a sa place dans toute définition de planification importante.
Fenêtres de maintenance et astreintes : même règle, autre terrain
Une fenêtre de maintenance ou un planning d'incident sur une page de statut relève de la même catégorie de bugs qu'une tâche cron, simplement sous une autre forme. Prenons une fenêtre définie comme « samedi 02:00–04:00 Europe/Berlin ». Ses heures de début et de fin sous-jacentes en UTC se décalent d'une heure selon le côté de la transition où l'on se trouve. Définissez la fenêtre en UTC. Montrez ensuite l'équivalent en heure locale aux ingénieurs et aux clients comme une conversion en lecture seule, jamais comme valeur stockée.
Les rotations d'astreinte doivent suivre la même séparation. La limite de rotation (qui reçoit l'alerte, et quand le relais passe) est un horodatage UTC. La vue calendrier consultée par votre équipe le convertit dans l'heure locale de chacun. Une relève à 07:00 UTC s'affiche ainsi à 8h ou 9h selon le fuseau de l'ingénieur et la saison, sans que la planification sous-jacente ne bouge jamais.
Petite checklist avant le changement d'heure
| Vérification | Pourquoi c'est important |
|---|---|
| Le fuseau horaire du serveur/conteneur est UTC | Supprime l'ambiguïté de toutes les planifications qui y tournent |
| Les entrées crontab/CronJob/timer utilisent l'UTC, pas l'heure murale locale | Évite totalement l'heure répétée/sautée |
Les logs stockent des horodatages UTC (ISO 8601 Z) |
Garde la chronologie des incidents dans l'ordre pendant la transition |
| Fenêtres de maintenance stockées en UTC, affichées en heure locale | Les limites des fenêtres ne dérivent pas par rapport aux vrais schémas de trafic |
| Limites de rotation d'astreinte stockées en UTC | Les relèves ont lieu au même instant réel à chaque fois |
Si vous coordonnez cela entre des tâches, des certificats et des serveurs chez plusieurs fournisseurs, mieux vaut centraliser la logique de planification. C'est plus efficace que d'auditer une douzaine de crontabs à la main deux fois par an. Consultez notre guide pour réduire le travail manuel sur l'infrastructure pour savoir par où commencer.
Autres pièges à connaître
Les outils d'agrégation de logs qui regroupent par heure locale afficheront une heure en double ou manquante la nuit de la transition, même si les horodatages sous-jacents sont corrects. Vérifiez comment votre visualiseur de logs regroupe le temps, et pas seulement comment il le stocke. Par ailleurs, votre chaîne d'alerte envoie peut-être ses notifications via un webhook ou une intégration de messagerie. Dans ce cas, assurez-vous que l'intégration elle-même (et pas seulement votre planificateur) gère les fuseaux horaires. Une tâche UTC correctement planifiée peut encore être mal synchronisée par un notificateur en aval qui suppose l'heure locale.
Les automatisations d'InfraNest tournent en UTC en coulisses et gèrent la conversion d'affichage pour vous. Vos tâches planifiées liées au DNS, aux certificats et aux serveurs n'ont donc pas besoin d'un audit manuel deux fois par an. Découvrez-les si vous en avez assez de traquer ce bug chez tous vos fournisseurs chaque mois de mars et de novembre.
Questions fréquentes
#Passer le fuseau horaire de mon serveur en UTC casse-t-il autre chose ?
Non. Les applications devraient déjà stocker et comparer les horodatages en UTC en interne. Régler le fuseau horaire du système d'exploitation sur UTC supprime simplement une couche de conversion en heure locale inutile et rend cron, les logs et les timers sans ambiguïté.
#Cron prend-il directement en charge les fuseaux horaires ?
Le cron POSIX classique n'a aucun champ de fuseau horaire. Il évalue simplement votre planification selon l'heure locale du système. C'est pourquoi il faut régler le système (ou le conteneur) sur UTC plutôt que d'essayer d'exprimer un fuseau horaire dans la crontab.
#Le champ timeZone des CronJob Kubernetes résout-il entièrement le problème ?
Il permet d'épingler une planification à un fuseau IANA précis comme Etc/UTC. Cependant, la documentation de Kubernetes avertit toujours que, dans d'autres fuseaux, des tâches peuvent s'exécuter deux fois ou être sautées pile au moment d'un changement d'heure. Régler le fuseau sur UTC reste donc le choix le plus sûr.
#Quelle est la première correction la plus simple si je ne peux pas tout changer aujourd'hui ?
Commencez par tout ce qui s'exécute entre minuit et 3h du matin heure locale, car c'est la plage la plus susceptible d'être répétée ou sautée. Passez d'abord ces tâches à des planifications UTC explicites, puis traitez le reste.
Cet article vous a-t-il été utile ?
