# Panne de synchronisation NTP : des articles programmés qui partent en retard > Un client s'étonnait que ses publications programmées sortent avec plusieurs minutes de retard, parfois plus. Le coupable : une horloge serveur qui avait cessé de se synchroniser. - Auteur : Clément Hadrot - Publié le : 2022-09-06 - Mis à jour le : 2022-09-06 - Catégorie : Hébergement & serveurs - URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/panne-ntp-articles-programmes-retard/ ## L’essentiel - WP-Cron dépend entièrement de l'heure système du serveur - Un service NTP arrêté dérive de plusieurs minutes en quelques jours - Le décalage s'accumule silencieusement sans provoquer d'erreur visible Un client éditorial programmait ses articles avec soin, toujours à des horaires précis pour coller aux pics d'audience de son secteur — 8h00 tapantes, pas 8h03. Ces derniers temps, ses publications sortaient avec un retard qui grandissait de jour en jour : trois minutes, puis sept, puis onze. Rien dans les journaux WordPress ne signalait d'erreur, aucun plugin de cache ne semblait en cause, et pourtant l'écart entre l'heure programmée et l'heure réelle de publication ne cessait de croître. Le symptôme pointait vers une seule direction possible une fois les causes applicatives écartées : l'horloge système du serveur elle-même dérivait, lentement, sans qu'aucune alerte ne le signale — un service NTP silencieusement arrêté depuis une mise à jour système récente. ## Symptôme : un retard progressif, jamais un échec net Ce qui rendait le diagnostic contre-intuitif, c'est l'absence totale d'erreur. WP-Cron, le système de tâches planifiées de WordPress, n'échouait jamais franchement : les articles finissaient bien par se publier, juste de plus en plus tard par rapport à l'heure programmée. Un échec pur (article jamais publié) aurait orienté immédiatement vers WP-Cron lui-même ; un retard progressif et croissant orientait vers autre chose de plus fondamental : la mesure du temps. ## Diagnostic : comparer l'heure serveur à une référence externe La vérification la plus simple consiste à comparer l'heure du serveur à une source de temps fiable externe, plutôt que de faire confiance à la commande `date` exécutée localement, qui ne fait qu'afficher l'heure que le système croit être la bonne. ``` $ timedatectl status Local time: lun. 2022-09-05 14:23:07 CEST Universal time: lun. 2022-09-05 12:23:07 UTC RTC time: lun. 2022-09-05 12:11:52 Time zone: Europe/Paris (CEST, +0200) System clock synchronized: no NTP service: inactive ``` La ligne `System clock synchronized: no` confirmait le diagnostic en une commande : l'horloge matérielle (RTC) affichait déjà onze minutes de retard sur l'heure système, et aucun service NTP actif ne venait corriger cette dérive. Sur Debian, le service concerné est `systemd-timesyncd`, désactivé quelque temps plus tôt lors d'un durcissement système un peu trop large, qui avait coupé plusieurs services jugés « non essentiels » sans vérifier leur utilité réelle. > L'essentiel à retenir : WP-Cron dépend entièrement de l'heure système du serveur ; Un service NTP arrêté dérive de plusieurs minutes en quelques jours ; Le décalage s'accumule silencieusement sans provoquer d'erreur visible ## Correctif : réactiver la synchronisation et vérifier la dérive La correction elle-même prend quelques secondes une fois la cause identifiée : ``` sudo systemctl enable --now systemd-timesyncd sudo timedatectl set-ntp true timedatectl status ``` Après réactivation, l'horloge se recale progressivement (ou brutalement selon le delta et la configuration), et la ligne `System clock synchronized` repasse à `yes` en quelques minutes. Sur ce serveur précis, le décalage de onze minutes s'est corrigé en une seule resynchronisation, sans redémarrage nécessaire. Restait à comprendre pourquoi les publications WordPress avaient continué à sortir malgré tout, avec retard plutôt qu'en échec total. WP-Cron se déclenche à chaque visite du site (à moins d'être configuré en cron système réel) et compare l'heure système courante à l'heure de publication programmée stockée en base : tant que l'horloge dérive dans le même sens que le temps qui passe, WP-Cron finit toujours par constater que l'heure programmée est dépassée, juste plus tard que prévu. ## Prévention : surveiller la synchronisation, pas seulement l'heure affichée La leçon retenue a été de ne plus se fier à un simple `date` dans les scripts de vérification, mais d'ajouter une sonde de supervision dédiée à l'état de synchronisation NTP lui-même. - Vérification périodique de `timedatectl show --property=NTPSynchronized` dans le monitoring de chaque serveur - Alerte immédiate si un service de synchronisation temporelle passe à l'état inactif après une mise à jour système - Documentation explicite des services jugés « essentiels » avant tout script de durcissement, pour éviter une coupure collatérale > Une dérive d'horloge ne casse presque jamais un site de façon spectaculaire ; elle le rend juste subtilement inexact, ce qui la rend bien plus longue à repérer qu'une vraie panne. ## En résumé Un retard de publication qui grandit jour après jour, sans erreur explicite dans les journaux, mérite un contrôle de l'heure serveur avant toute investigation dans WordPress lui-même. NTP est un service qu'on oublie précisément parce qu'il fonctionne silencieusement — jusqu'au jour où il ne fonctionne plus, tout aussi silencieusement.