Heure de publication WordPress décalée : corriger le fuseau et la programmation

Définir l’heure attendue avec son fuseau

Un article paraît une heure plus tôt ou plus tard que prévu, ou la date visible sur le site ne correspond pas au calendrier éditorial. Pour corriger le bon réglage, partez d’un document précis et d’une attente complète : jour, heure et fuseau. « Publier à neuf heures » reste ambigu si l’équipe travaille dans plusieurs pays.

Le résultat recherché est une échéance correcte pour les prochains articles, puis une vérification des programmations déjà enregistrées. Changer seulement l’apparence de la date ne déplace pas nécessairement la publication. Inversement, déplacer l’article pour corriger une étiquette d’heure peut modifier inutilement son calendrier.

Gardez l’adresse du document, son état et la date indiquée dans l’éditeur. Si l’article est déjà public, notez comment son heure réelle de sortie est connue : observation, journal ou autre trace disponible. La date affichée dans le texte n’est pas, à elle seule, la preuve de son instant d’exécution.

Ouvrez Articles et retrouvez l’original, sans en créer une copie publique.
Dans ses réglages, relevez la date de publication complète et l’état enregistré.
Notez séparément l’heure voulue et le fuseau de référence de l’équipe.
Comparez avec un second article concerné pour savoir si l’écart est général ou isolé.

Distinguer fuseau, format et retard d’exécution

Le fuseau permet d’interpréter une heure locale. Le format détermine comment elle s’écrit, par exemple sur douze ou vingt-quatre heures. L’horloge du serveur indique l’heure du système. Enfin, le déclenchement des tâches décide quand un travail arrivé à échéance est effectivement traité. Ces niveaux peuvent produire des symptômes différents.

Un écart constant sur les échéances invite à vérifier le fuseau. Une confusion entre matin et soir peut concerner la saisie ou le format. Un article toujours programmé après une échéance correctement interprétée demande plutôt le diagnostic d’une publication manquée. N’ajoutez pas une correction d’une heure à tous les contenus avant cette distinction.

Il faut un accès autorisé aux réglages généraux pour changer le fuseau du site. La correction d’un document demande ses droits d’édition et de publication. Sur WordPress.com, choisissez le bon site dans le tableau de bord ; en multisite, vérifiez le sous-site. Votre fuseau personnel et celui d’une autre installation ne remplacent pas son réglage.

Ouvrez Réglages, Général et relevez la valeur exacte de Fuseau horaire.
Relevez les formats de date et d’heure sans encore les modifier.
Comparez les heures dans un même repère, en précisant la date concernée.
Si l’échéance est correcte mais reste dépassée, conservez le cas pour la publication manquée plutôt que de changer le fuseau.

Préserver les programmations avant une correction globale

Le fuseau du site concerne plusieurs contenus et peut aussi être utilisé par des composants. Préparez une liste courte des articles programmés et de leurs heures attendues avant de le modifier. Si une sortie proche ne doit pas survenir pendant le diagnostic, faites valider son report ou son retour en brouillon par la personne responsable.

Le premier parcours corrige un fuseau global réellement erroné. Le deuxième ajuste l’échéance d’un seul article lorsque le réglage du site est bon. Le troisième examine une date d’affichage, un journal ou un outil externe qui utilise un autre repère. Vous n’avez besoin d’aucune nouvelle extension pour ces vérifications.

Une sauvegarde récupérable est utile avant une intervention plus large sur les données ou les composants. Pour une modification ciblée de réglage, conservez surtout sa valeur initiale et les décisions de calendrier. Le retour arrière doit rétablir ces valeurs, pas restaurer toute une base plus ancienne.

Conservez les états et dates des programmations à contrôler dans un relevé privé.
Confirmez le fuseau éditorial voulu avec l’équipe avant le changement global.
Préparez les essais d’affichage ou de composant sur une copie isolée si nécessaire.
Corrigez un seul niveau à la fois et notez le résultat avant de poursuivre.

Approche 1 : corriger le fuseau du site dans Général

Ce parcours convient lorsque le site utilise un autre fuseau que celui retenu pour son calendrier éditorial. Il demande les droits de réglage du site. Le résultat attendu est une valeur conservée après rechargement et une heure locale cohérente avec le repère choisi, sans avoir à modifier l’horloge du serveur.

Sélectionnez une ville qui applique les mêmes règles horaires que le lieu de référence, par exemple Paris pour un calendrier correspondant à ce fuseau. Une ville proche géographiquement peut suivre d’autres règles : choisissez le repère horaire, pas seulement le lieu le moins éloigné. Si l’équipe travaille volontairement en UTC, conservez ce choix et exprimez ses consignes dans ce repère.

Pour annuler la correction, remettez la valeur exacte relevée avant l’intervention, puis recontrôlez les articles qui auraient été reprogrammés entre-temps. Le retour au réglage initial ne remplace pas cette seconde vérification des documents.

Ouvrez Réglages, Général dans l’administration du site concerné.
Dans Fuseau horaire, choisissez la ville ou le repère validé avec l’équipe.
Enregistrez avec le bouton de validation de cette page.
Rechargez Général et vérifiez que le choix est resté sélectionné ; comparez l’heure locale indiquée lorsqu’elle est affichée.
Ouvrez un article à programmer et contrôlez son calendrier avant toute confirmation de sortie.

Choisir entre une ville et un décalage fixe

Un fuseau nommé possède des règles qui peuvent varier selon la date, notamment lors des changements saisonniers. Un décalage fixe comme UTC+1 exprime toujours le même écart ; il ne devient pas automatiquement UTC+2 parce qu’une région change d’heure. Les deux choix peuvent afficher la même heure aujourd’hui tout en différant à une autre date.

Pour un calendrier lié à l’heure civile d’un lieu, le fuseau nommé adapté évite de maintenir vous-même ces changements. Un décalage fixe reste pertinent si votre organisation veut précisément ce même écart toute l’année. Il ne faut donc pas remplacer tous les choix fixes sans vérifier l’usage attendu.

Ne modifiez pas les dates de changement saisonnier dans WordPress et n’ajoutez pas une extension pour obtenir une conversion élémentaire. Si le fuseau nommé semble incohérent à une date précise, préparez un cas daté pour le responsable de l’environnement ; les règles utilisées par le serveur doivent alors être vérifiées.

Relisez la valeur actuelle : nom de ville ou décalage numérique.
Déterminez si la consigne attend une heure locale du lieu ou un décalage constant.
Choisissez la valeur adaptée dans Général et enregistrez si une correction est nécessaire.
Comparez une échéance proche et une échéance située dans une autre période de l’année, sans les publier pour cet essai.

Recontrôler les articles déjà programmés

Ne supposez pas qu’un changement de fuseau convertit toutes les programmations antérieures selon votre nouvelle intention. WordPress conserve des informations de date locale et de date GMT, et la tâche de publication possède son échéance. Reprenez les documents concernés à partir du relevé initial plutôt que de les décaler en bloc.

Cette étape demande les droits sur les articles concernés. Le résultat attendu est une date future explicitement validée pour chacun et un état Programmé conservé. Si un document ne doit plus sortir, choisissez le brouillon selon la décision éditoriale ; ne laissez pas une ancienne échéance dépassée servir de réglage temporaire.

Pour annuler une reprogrammation, utilisez la consigne de calendrier encore valable, pas automatiquement une ancienne heure devenue passée. Si la comparaison de dates reste incohérente, la consultation technique proposée plus loin permet de relever les champs avant une nouvelle modification.

Ouvrez Articles et retrouvez les documents notés avant le changement global.
Pour chacun, ouvrez les réglages de publication et relisez jour, mois, année et heure.
Si nécessaire, choisissez explicitement la nouvelle échéance future validée puis confirmez la programmation.
Rouvrez les réglages pour vérifier l’état et la date conservés.
Notez les corrections réellement faites et les documents qui demandent encore une comparaison technique.

Approche 2 : corriger seulement l’échéance d’un article

Ce parcours convient si le fuseau du site est volontaire et que seule la date d’un document est erronée. Utilisez un compte qui peut modifier et programmer cet article. Le résultat attendu est une nouvelle échéance future conservée sur l’original, sans changement global pour les autres auteurs.

Traduisez d’abord la consigne dans le repère du site. Pour une équipe internationale, écrivez dans votre relevé la date complète et les deux fuseaux concernés. Une conversion proche de minuit peut changer le jour ; vérifiez le calendrier et pas seulement le nombre d’heures.

Si l’article est déjà public, changer sa date n’annule pas sa sortie précédente. Faites confirmer l’objectif avant de le remettre en programmation. Son classement et une adresse contenant la date peuvent également être concernés ; vérifiez le lien fourni après correction.

Depuis Articles, ouvrez le document original et ses réglages de publication.
Cliquez sur sa date pour ouvrir le calendrier ; saisissez la date et l’heure futures exprimées dans le fuseau du site.
Vérifiez l’indication matin ou soir lorsque l’interface utilise ce format.
Confirmez Programmer, puis rouvrez le document pour relire l’état et l’échéance.
Si vous annulez, remettez la date encore validée ou le brouillon prévu, sans rétablir une échéance passée par automatisme.

Approche 3 : contrôler la date affichée dans le modèle

Choisissez ce parcours si l’instant de publication est correct, mais que la date visible sur le site paraît erronée. Une date de dernière modification n’est pas celle de publication. Une carte du blog et la page de l’article peuvent également utiliser des réglages de présentation différents.

Sur un thème de blocs, vérifiez s’il s’agit du bloc Date de publication ou de sa variante Date de modification. Le choix se fait, selon la version, par transformation du bloc ou par un réglage de dernière modification. Le modifier agit sur le modèle et peut toucher plusieurs contenus. Conservez l’état initial ; le résultat attendu est la bonne information affichée, sans reprogrammer le document.

Sur un thème classique ou un constructeur, cherchez la fonction de date dans sa documentation officielle. Corrigez le champ ou réglage identifié au lieu de modifier l’heure de l’article pour compenser une présentation. L’absence du bloc natif dans ces interfaces est normale et ne demande pas de changer de thème.

Ouvrez la destination concernée et identifiez si elle montre publication ou modification.
Pour un thème de blocs, allez dans Apparence, Éditeur, Modèles et ouvrez le modèle de cette destination.
Dans la vue en liste, sélectionnez le bloc Date concerné et identifiez sa variante ainsi que son format.
Si vous voulez la publication mais trouvez Date de modification, utilisez Transformer pour choisir Date de publication, ou désactivez l’ancien réglage équivalent s’il existe dans votre version. Pour le format, utilisez les réglages du bloc ; le bouton Modifier la date de sa barre concerne la date du document.
Enregistrez puis contrôlez deux articles, sans modifier leurs dates de publication.
Pour annuler, rétablissez la variante ou l’option et le format initiaux.

Comparer un service externe dans son propre repère

Si l’écart apparaît uniquement dans une lettre d’information, une intégration ou un journal, vérifiez le repère de cet outil. Une date exprimée en UTC peut représenter le même instant qu’une heure locale différente. Cela ne prouve pas une erreur de WordPress.

Relevez le nom du champ utilisé par l’intégration et son format avec le responsable de l’outil. Une date de modification, une date de publication locale et une date GMT ne sont pas interchangeables. Les fonctions natives permettent justement de distinguer ces informations ; ne corrigez pas le site pour satisfaire un affichage externe mal interprété.

Si le service possède son propre fuseau ou calendrier, modifiez ce seul réglage après avoir confirmé sa portée. Le retour arrière consiste à rétablir sa valeur initiale, sans déplacer l’article dans WordPress. Une fonction qui envoie des messages doit être vérifiée sur un environnement de test adapté.

Choisissez un document et relevez la même opération dans WordPress et dans l’outil externe.
Notez pour chaque heure la date, le fuseau ou le décalage indiqué et le champ concerné.
Convertissez vers un même repère pour comparer les instants.
Si l’erreur vient du service, corrigez son paramètre documenté puis contrôlez une donnée d’essai sans envoi réel.

Lire les valeurs enregistrées avec WP-CLI si cet accès existe

Cette vérification facultative s’adresse à la personne qui dispose déjà d’un terminal autorisé et de WP-CLI. Elle permet de comparer les données sans demander leur modification. Exécutez les commandes depuis le répertoire de la bonne installation ; en multisite, ajoutez le paramètre --url avec l’adresse confirmée du sous-site à chaque commande.

Remplacez 123 par l’identifiant réel de l’article, visible notamment dans l’adresse de son écran d’édition. post_date désigne la date locale enregistrée, post_date_gmt son champ GMT ; les champs post_modified concernent la modification. La valeur de gmt_offset ne doit pas être utilisée seule comme règle saisonnière pour toutes les dates. Avec un fuseau nommé, regardez d’abord timezone_string.

Le résultat attendu est un relevé ciblé à comparer au calendrier voulu, pas une correction automatique. Une valeur timezone_string vide peut correspondre à un décalage fixe. Si WordPress ne se charge pas ou si l’identifiant n’est pas celui attendu, arrêtez et vérifiez l’environnement. Aucune commande de mise à jour en masse n’est nécessaire ici.

Confirmez le chemin et, le cas échéant, le sous-site avant l’inventaire.
Lisez les deux options puis les seuls champs de date du document.
Comparez la paire locale/GMT au fuseau et à la date concernés, avec le responsable si elle est incohérente.
Conservez le relevé dans un espace privé puis revenez à une correction ciblée dans l’interface ; ces commandes ne demandent pas de retour arrière de données.

wp option get timezone_string
wp option get gmt_offset
wp post get 123 --fields=ID,post_status,post_date,post_date_gmt,post_modified,post_modified_gmt --format=json

Vérifier une programmation après correction

Sur une copie préparée pour les essais, créez un document sans contenu confidentiel et choisissez une échéance future dans le repère corrigé. Le responsable doit neutraliser les notifications, diffusions et autres effets externes de la copie avant cette vérification. Un nom de domaine de test ne garantit pas cet isolement.

En production, préférez observer une prochaine publication légitime avec l’équipe. Une copie peut utiliser un autre déclenchement ou une autre configuration. Le résultat attendu combine un état et une échéance cohérents, puis une publication observée ; une simple heure joliment formatée ne valide pas le traitement.

Si l’heure est correcte mais que l’article reste programmé après son échéance, poursuivez sur la publication manquée. Ne changez pas encore le fuseau pour compenser un retard de WP-Cron.

Programmez le document d’essai sur la copie isolée et relevez la date conservée.
Après l’échéance, vérifiez son état et sa consultation dans cet environnement.
Notez l’heure observée et le repère utilisé pour la comparer.
Faites supprimer ou conserver le document d’essai selon les règles de la copie, puis observez la prochaine programmation réelle prévue.

Conserver le calendrier et un retour arrière ciblé

Une fois le résultat validé, indiquez aux auteurs le fuseau de référence et où il se consulte. Pour une équipe répartie dans plusieurs pays, gardez ce repère dans les consignes de calendrier. Une formulation avec date complète et fuseau évite de recalculer de mémoire un écart qui peut varier selon la période.

En cas de régression, rétablissez le réglage précis conservé puis vérifiez les documents modifiés pendant l’intervention. Une restauration globale risquerait d’effacer d’autres changements récents. Si l’article est déjà public, un retour de date ou de statut ne retire pas les informations déjà consultées ou envoyées.

Si le problème persiste après ces manipulations, transmettez un cas complet : identifiant, date locale et GMT si disponibles, fuseau choisi, heure attendue et affichage constaté. Précisez le modèle ou le service où apparaît l’écart. Cela permet de contrôler une conversion particulière sans déplacer tout le calendrier.

Gardez l’ancienne valeur, la correction appliquée et les documents reprogrammés.
En cas d’annulation, restaurez seulement le fuseau, la variante de date ou l’échéance concernée selon le parcours suivi.
Contrôlez l’état final des publications proches et informez l’équipe du repère retenu.
Conservez le suivi technique tant que la prochaine publication attendue n’a pas été observée.

Recalculer l’échéance si l’heure affichée est déjà correcte

Sur une copie WordPress, une publication prévue à 9 h en juillet avait été enregistrée avec le décalage fixe UTC+1. Sa date GMT et son événement indiquaient 8 h UTC. Après passage à Europe/Paris, une nouvelle échéance de juillet à 9 h correspondait à 7 h UTC. L’article déjà programmé avait conservé 8 h UTC. Dans la recette, enregistrer à nouveau exactement la même heure locale a laissé le champ GMT à 8 h, alors que l’événement de publication est passé à 7 h.

Ce contrôle vérifie les dates enregistrées et la tâche planifiée. Sur le site public, observez la prochaine publication légitime avant de conclure au bon fonctionnement de son déclenchement.

Si WP-CLI est déjà disponible, comparez la tâche de cet article au champ GMT lu plus haut. Remplacez 123 par son identifiant réel et gardez le même site cible. La commande indique si l’événement existe et affiche son heure UTC sans le déclencher.

Relevez le fuseau, l’heure civile, la date GMT et l’échéance de l’événement de l’article. Vérifiez d’abord que les deux heures UTC correspondent à la consigne. Si une ancienne valeur persiste après l’enregistrement, traitez uniquement ce document.
Sur la copie isolée, choisissez une autre minute clairement future et confirmez la programmation. Revenez ensuite à l’heure future voulue et enregistrez. Le passage par une autre minute a forcé la réécriture de l’heure locale et du champ GMT dans la recette. Ne faites pas cet essai avec une échéance proche de l’instant présent.
Rouvrez l’article et comparez à nouveau le champ GMT et l’événement programmé. Dans la recette, les deux sont passés à 7 h UTC pour 9 h à Paris. L’article est resté programmé et une autre échéance est restée intacte. Relisez aussi la procédure de publication manquée si les deux valeurs concordent mais que le contenu ne sort pas au moment prévu.

wp eval '$instant = wp_next_scheduled("publish_future_post", [123]); echo false === $instant ? "Aucun événement\n" : gmdate("Y-m-d H:i:s", $instant) . " UTC\n";'

Notre méthode éditoriale