La fiche peut porter une mauvaise date, utiliser une autre référence horaire ou attendre l’exécution d’une tâche. Ces causes ne se corrigent pas au même endroit. Partir de l’article attendu, puis conserver les heures observées, permet de transmettre un problème précis au responsable du site et de savoir ce qui a réellement repris.
Retrouver l’heure réellement enregistrée
Le planning indique mardi ; la fiche WordPress peut encore indiquer mercredi. Avant de la modifier, une capture de la date complète, de l’heure et de l’état conserve ce point de départ. Elle sera utile si un collègue reprend le dossier. Sans elle, une correction faite dans l’urgence peut effacer le seul indice qui distinguait une mauvaise programmation d’un défaut d’exécution.
La documentation WordPress sur les réglages d’un article distingue notamment brouillon, programmation et publication. Elle décrit le choix d’une date future dans les paramètres de publication. Ces états ont un sens différent : un article enregistré comme brouillon ne devient pas une publication programmée parce qu’une heure figure dans le planning de la rédaction.
Pour l’entretien de notre exemple, une date fixée au lendemain expliquerait déjà l’attente. La personne autorisée pourrait la corriger après avoir confirmé que le texte est prêt et que le créneau reste valable. Inutile, à ce stade, de demander à l’hébergeur de chercher une tâche en panne : rien ne montre encore que WordPress a manqué une échéance enregistrée.
L’examen doit également porter sur la bonne fiche. Deux versions d’un entretien peuvent avoir des titres proches, dont une copie de travail. Conserver l’adresse de la page prévue ou l’identifiant de l’article évite de réparer un brouillon qui n’était pas destiné à sortir. Le même repère servira plus tard pour rechercher l’article dans le flux et dans l’outil de diffusion.
La documentation décrit les réglages standards ; les écrans de votre site peuvent dépendre de sa version ou de ses extensions. Si l’état n’est pas clair, mieux vaut transmettre la capture à la personne qui maintient le CMS que cliquer plusieurs fois sur une commande dont l’effet est incertain. Le diagnostic doit laisser un historique compréhensible.
L’heure du planning est-elle celle du site ?
Une heure sans fuseau devient ambiguë dès qu’une partie de l’équipe travaille ailleurs. « 9 heures » peut désigner l’heure de Paris dans le planning, alors que le site utilise un autre réglage. Pour la vérification, inscrivez l’heure attendue avec son fuseau, puis comparez-la à celle que WordPress affiche. L’heure de l’ordinateur du rédacteur ne suffit pas à établir celle du site.
Dans Réglages, puis Général, WordPress permet de sélectionner une ville correspondant au fuseau voulu. Sa documentation des réglages généraux indique que les heures UTC et locale affichées permettent de confirmer le choix après enregistrement. Le format de présentation de la date ou de l’heure constitue un réglage distinct : changer l’affichage ne règle pas un décalage de fuseau.
Une rédaction basée en France peut, par exemple, retenir Paris comme référence de son planning. C’est un choix d’organisation à rendre explicite, notamment pour les correspondants. Le point à vérifier est la correspondance entre ce choix et le site, pas la localisation physique de la personne qui programme. Le dossier de l’article peut conserver une mention comme « mardi, 9 h, heure de Paris ».
La tentation serait de programmer le prochain entretien une heure plus tôt pour compenser. Ce contournement laisserait pourtant le réglage inexpliqué. Un collègue pourrait ensuite corriger le fuseau sans savoir que certains articles ont déjà été décalés à la main. Mieux vaut conserver les deux heures dans le signalement et vérifier leur correspondance avant de déplacer les rendez-vous suivants.
Changer le fuseau du site est une intervention commune à plusieurs contenus. Avant de l’enregistrer, la personne qui en a la responsabilité devrait relever les autres articles déjà programmés, puis contrôler leurs heures après le changement. Cette vérification évite de traiter le seul article signalé en laissant le reste du planning dans un état inconnu.
Comprendre ce qui déclenche une publication programmée
WordPress utilise WP-Cron pour des tâches planifiées, dont la publication d’articles. Dans son fonctionnement standard, ce mécanisme vérifie les tâches à exécuter lors d’un chargement de page ; il ne tourne pas en continu comme une horloge système. La documentation officielle de WP-Cron explique pourquoi une tâche peut donc s’exécuter après l’heure prévue si aucun chargement ne la déclenche au bon moment.
Votre hébergeur a peut-être organisé autrement ce déclenchement. La documentation décrit le fonctionnement standard, pas la configuration de votre média. Le faible trafic du matin ne suffit donc pas à expliquer un incident précis. Avant d’ajouter une extension, il faut demander à la personne qui maintient le site quel mécanisme exécute les publications et quelles traces elle peut consulter.
Le signalement utile contient l’article concerné, l’heure attendue avec son fuseau, l’état vu dans WordPress et l’heure du constat. Demandez ensuite quelle tâche devait publier cet article et si elle s’est exécutée. Cette question est plus précise que « WordPress ne respecte pas les horaires » et permet de rapprocher la fiche éditoriale des traces techniques disponibles.
Si l’article paraît pendant l’enquête, notez cette heure avant de fermer le sujet. Une reprise observée ne prouve pas que la cause a disparu. Il reste à savoir si la publication est venue d’une intervention manuelle, d’un déclenchement tardif ou du fonctionnement ordinaire. Sans cette distinction, le prochain incident semblera nouveau alors qu’il peut reproduire le même retard.
Pour un rendez-vous exigeant une publication à une heure précise, l’équipe doit convenir avec l’hébergeur du mécanisme de déclenchement et du contrôle attendu. Le niveau de suivi dépend de cet engagement. Un simple article de fond programmé pour le matin et une annonce dont l’heure a été annoncée aux lecteurs ne posent pas le même problème d’organisation.
Décider d’une reprise sans multiplier les commandes
Quand l’heure est passée, la rédaction doit d’abord décider si l’article doit encore paraître. L’actualité peut avoir évolué pendant l’attente ; une interview peut désormais nécessiter un ajout. Cette décision appartient au responsable éditorial. Réparer la programmation n’autorise pas à diffuser automatiquement une version dont la validité n’a pas été revue.
Si une publication manuelle est retenue, une personne la prend en charge et prévient les autres intervenants. Elle vérifie ensuite l’état de la fiche ainsi que la page publique. Il serait facile, dans l’urgence, de demander simultanément une nouvelle programmation à un collègue et une mise en ligne immédiate à un autre. Un relevé court de l’action choisie limite cette confusion.
Le test de lecture se fait sans la session d’édition. Une prévisualisation accessible à l’auteur ne démontre pas qu’un lecteur peut ouvrir l’article. La personne chargée du contrôle suit l’adresse publique, vérifie le titre et le contenu attendu, puis note le résultat. Si elle rencontre une erreur ou une page ancienne, le problème reste à examiner côté site.
La date visible mérite elle aussi un contrôle, surtout si l’équipe a modifié la programmation plusieurs fois. Elle doit raconter correctement la publication. Le guide sur les dates d’articles détaille la différence entre première parution et mise à jour ; aucune retouche de planning ne devrait servir à donner artificiellement de la fraîcheur à un ancien texte.
Pour fermer cette étape, le compte rendu doit pouvoir dire : l’article prévu est maintenant public à cette adresse, à telle heure observée, après telle intervention. Cette phrase établit ce qui a été vérifié. Elle laisse la cause technique ouverte si l’équipe ne dispose pas encore d’éléments suffisants pour la confirmer.
Suivre ensuite l’article jusqu’au relais social
Le fait qu’une page soit publique ne signifie pas que son relais a déjà été envoyé. Dans EditoRelay, le traitement d’un flux planifie sa prochaine consultation selon l’intervalle configuré, puis prépare la suite pour les nouvelles entrées détectées. Ce fonctionnement, vérifié dans le code du produit, ne permet pas de promettre un départ social à la seconde de la publication WordPress.
La rédaction peut donc suivre le même article dans l’ordre : page accessible, présence dans le flux connecté, détection dans l’outil, puis état des propositions et des publications. Il ne s’agit pas de répéter tout le tutoriel WordPress vers Facebook, mais de localiser le retard sans modifier plusieurs systèmes à la fois.
Si la page est publique mais que le flux ne présente toujours pas l’entrée, le diagnostic d’un flux RSS bloqué devient pertinent. Si l’article figure déjà dans l’outil, la recherche porte plutôt sur l’étape de préparation ou d’envoi. La date inscrite dans le CMS ne suffit pas à répondre à ces deux questions.
Dans un exemple fictif, la page apparaît à 9 h 12 et l’outil la détecte à 9 h 18. Ces observations séparées ne permettent pas d’attribuer tout le retard à la diffusion sociale. Elles montrent au moins que l’article n’était pas encore accessible à l’heure prévue. Le relevé aide à discuter du bon correctif avec la bonne personne, sans annoncer un délai normal qui vaudrait pour tous les sites.
Vérifier le prochain rendez-vous réel
Le prochain contenu ordinaire du planning peut servir de témoin. Une personne disponible à cette heure relève sa mise en ligne, puis les étapes de diffusion, avec le même fuseau que lors de l’incident. Ce contrôle fournit un cas comparable sans créer de faux article public. Il reste limité à ce rendez-vous : une publication réussie ne démontre pas que tous les problèmes possibles ont disparu.
Avant ce rendez-vous, l’équipe conserve le réglage retenu, le responsable du suivi et la conduite prévue si l’heure passe à nouveau. Une capture des paramètres peut suffire. L’objectif est que le collègue de permanence sache quoi vérifier et qui contacter, sans devoir reconstituer les échanges de la veille au milieu d’une publication urgente.
Le compte rendu conserve l’heure de parution du nouvel article et, séparément, l’explication du retard précédent si elle a été confirmée. Si la cause reste inconnue, autant l’écrire. Le responsable du site disposera des deux cas et de leurs heures exactes si un autre rendez-vous prend du retard.
Sources officielles
Documents utilisés pour vérifier les points techniques de cet article.