Vérifier que la correction a bien atteint le bon article
L’adresse publique est le premier repère à conserver. Un aperçu et une copie de travail peuvent ressembler à l’article sans être ce que le lecteur consulte. Le collègue chargé de vérifier la correction ouvre donc l’URL complète, indépendamment du bouton de prévisualisation du CMS. Dans la fiche de suivi, il dispose aussi de la phrase attendue : il pourra reconnaître la bonne version sans devoir connaître tout l’historique de l’édition.
La documentation WordPress sur les changements invisibles distingue plusieurs causes : cache du navigateur, cache du serveur, extension de cache ou modification au mauvais endroit. Cette liste donne des pistes de diagnostic. Elle ne permet pas d’attribuer automatiquement chaque retard d’affichage à une extension, ni de conclure qu’une correction a bien été enregistrée parce que l’éditeur la montre.
Dans notre exemple, le journaliste transmet au responsable du site l’ancien montant, le nouveau montant et l’heure de sauvegarde. Il précise où chacun a été observé. « La page est fausse » laisse trop de possibilités ; « à cette adresse, à telle heure, hors connexion au CMS, le deuxième paragraphe contient encore l’ancienne somme » permet de reproduire le problème. La capture complète la description, mais le texte recherché reste utile pour contrôler les réponses reçues.
Comparer la lecture publique et la session de rédaction
La personne qui publie travaille souvent avec une session ouverte. Il est donc utile de refaire le parcours dans un autre contexte : navigateur distinct, fenêtre privée nouvellement ouverte ou autre appareil. Ces essais servent à comparer des observations. Une fenêtre privée ne vide pas les caches de l’hébergement ; voir la même erreur dans cette fenêtre ne suffit pas à identifier la machine qui conserve la copie.
Quelques lignes suffisent pour suivre les essais, à condition de garder leurs conditions. À quelle heure la page a-t-elle été ouverte ? Avec une session WordPress ou sans connexion ? Quelle phrase était visible ? Si le rédacteur et son collègue obtiennent des textes différents, cet écart devient une piste pour la maintenance. Si tous deux voient l’ancien montant, l’enregistrement et la destination de publication restent à vérifier. Un nouvel essai doit répondre à une question laissée ouverte par le précédent.
Le contrôle gagne à reproduire l’arrivée du lecteur. Un lien depuis la rubrique, un lien conservé dans une newsletter et l’adresse copiée depuis le CMS méritent une comparaison si leurs résultats diffèrent. Il peut s’agir d’une autre page ou d’une variante d’adresse. Pour autant, changer le slug afin de contourner l’incident créerait un second problème : les liens déjà diffusés continueraient à viser l’adresse précédente. Le guide sur le choix du slug avant publication explique pourquoi cette adresse doit rester stable.
Distinguer la copie locale des copies partagées
Le guide MDN sur les caches HTTP distingue les caches privés, associés à un utilisateur, des caches partagés. Il décrit aussi la revalidation : un client peut demander si sa copie est encore valable et recevoir une réponse sans nouveau corps de page lorsque le serveur la considère inchangée. Actualiser n’équivaut donc pas toujours à télécharger une nouvelle version complète.
Pour la rédaction, la question pratique est de savoir qui continue à recevoir l’ancien contenu. Si un seul navigateur est concerné, un rechargement forcé ou l’effacement ciblé de son cache peut faire partie de l’essai. Si plusieurs lecteurs restent concernés, intervenir uniquement sur le poste du journaliste ne résout pas le problème public. Le responsable technique doit alors examiner le chemin suivi par la requête et les couches de cache présentes sur cet hébergement.
Le rédacteur peut fournir ces observations sans savoir interpréter des en-têtes HTTP. Le dépannage doit rester proportionné : un contrôle ciblé du cache de son navigateur est plus facile à évaluer qu’un effacement général de son historique. La personne chargée du site lui indique ce que la manipulation cherche à départager. Après l’essai, tous deux peuvent comparer le résultat à celui de départ, au lieu d’accumuler des gestes dont personne ne sait lequel a été utile.
Purger le bon cache et contrôler la page après l’opération
Sur WordPress.com, la documentation de purge distingue le cache distribué qui peut conserver des pages HTML et le cache d’objets lié aux données. Les commandes disponibles dépendent de la configuration du site. Ce parcours WordPress.com ne doit pas être présenté comme un menu universel de WordPress installé chez un autre hébergeur ; celui-ci peut fournir son propre panneau ou une extension spécifique.
La demande à la maintenance peut viser l’adresse concernée, avec les éléments déjà réunis. Si l’outil permet une purge ciblée adaptée au problème, elle évite de lancer d’emblée une opération générale. Le choix revient à la personne qui connaît l’installation. WordPress.com prévient qu’une purge peut ralentir temporairement le site pendant la reconstruction du cache et déconseille d’en faire une optimisation de routine. Vider davantage de caches n’est donc pas un objectif en soi.
La confirmation de purge marque le moment de refaire le contrôle public. Le collègue ouvre la même adresse et cherche le passage corrigé, puis note l’heure. Si le montant reste faux, ce résultat doit accompagner la suite du dépannage. Une notification « cache vidé » renseigne sur l’opération demandée ; seule la lecture de la réponse permet de dire quel texte est maintenant servi. Les extensions et la configuration de production ne devraient pas être modifiées au hasard pour obtenir un autre résultat.
Préparer une demande technique qui permette de trancher
Quand l’origine du défaut reste incertaine, la rédaction peut transmettre un dossier limité à ce qui est nécessaire : URL, contenu attendu, contenu observé, heures et contextes des essais. Le responsable technique peut compléter avec les en-têtes de réponse et les journaux dont il dispose. Il doit pouvoir distinguer une réponse provenant de l’origine d’une copie intermédiaire, sans exposer dans le ticket des cookies de session ou des identifiants.
La documentation MDN précise que la directive no-cache impose une validation avant réutilisation, tandis que no-store empêche le stockage de la réponse sans supprimer les copies déjà conservées. Ces noms ne sont donc pas des commandes interchangeables pour effacer une page ancienne. Leur configuration relève du fonctionnement du site entier. Copier une combinaison d’en-têtes trouvée dans un forum pourrait masquer le symptôme tout en modifiant les performances et les conditions de partage des réponses.
La maintenance peut rendre une conclusion courte, mais elle doit distinguer ce qui est établi de ce qui reste supposé. Si plusieurs actions ont été effectuées ensemble et que le défaut a disparu, on ne sait pas encore laquelle a résolu l’incident. Pour la prochaine correction, mieux vaut conserver ce doute que recommander une purge générale sans preuve. L’URL contrôlée, la phrase reçue et l’heure du dernier essai seront plus utiles qu’une mention « problème réglé ».
Le cas des images et des résumés encore anciens
Une correction peut concerner une légende, une image ou un document joint. La recette doit alors nommer précisément l’objet attendu. Remplacer une illustration sans modifier son nom ne prouve pas que tous les lecteurs reçoivent déjà le nouveau fichier. Le responsable technique peut comparer le fichier servi et celui qui a été déposé, puis déterminer s’il faut intervenir sur sa mise en cache ou sur la référence utilisée par la page.
Dans un exemple fictif, un média remplace une carte dont la légende comporte une erreur. L’article affiche désormais une phrase correcte, mais l’ancienne carte est encore visible sur un téléphone. La vérification doit porter sur les deux informations. Si le lecteur peut ouvrir l’image en grand, cette destination fait également partie du contrôle. Le problème n’est clos que lorsque le parcours testé permet de comprendre correctement la carte et son texte d’accompagnement.
Il reste parfois un ancien montant dans la carte de rubrique, alors que le corps de l’article est correct. Avant une nouvelle purge, la rédaction peut relire le champ qui fournit cette carte. Le guide sur les extraits WordPress explique ce travail éditorial. Une phrase répétée à plusieurs endroits peut avoir été enregistrée séparément : dans ce cas, c’est le contenu du champ qu’il faut corriger, puis vérifier à son tour.
Une dernière comparaison peut porter sur la durée du rétablissement. Si la bonne version apparaît juste après une purge, puis que l’ancienne revient, la maintenance a besoin de connaître les deux heures et les mêmes conditions de lecture. Ce retour du défaut mérite un nouvel examen de la source qui alimente les copies. La rédaction peut suspendre le relais concerné le temps de vérifier la destination, sans modifier à nouveau une phrase correcte pour essayer de provoquer un rafraîchissement.
Reprendre la diffusion à partir de la version vérifiée
La correction visible sur le site ne met pas automatiquement à jour les textes déjà copiés ailleurs. Avant un nouveau partage, la personne chargée de la diffusion compare sa proposition avec le passage corrigé. Si un ancien montant reste dans un brouillon social, la réparation du cache ne le changera pas. La validation éditoriale du relais doit donc porter sur la proposition elle-même et sur sa destination, à partir d’un article effectivement vérifié.
L’aperçu d’un lien sur une plateforme constitue un autre contrôle. Le guide pour corriger un aperçu Facebook ou LinkedIn traite ce problème distinct. Une page publique correcte et une vignette sociale ancienne peuvent coexister. Inversement, un aperçu correct ne prouve pas que le corps de l’article reçu après le clic est à jour. Le collègue doit ouvrir le lien et lire le passage concerné.
L’équipe applique ensuite sa politique de correction si l’erreur changeait le sens de l’information. Le dépannage ne décide pas du texte à adresser aux lecteurs. Dans notre cas fictif, le responsable de diffusion dispose désormais du montant public vérifié et peut le comparer au résumé et au relais prévu. Il garde l’heure de ce contrôle pour la passation. Si un autre lecteur signale encore l’ancienne somme, l’équipe lui demande l’adresse et les conditions de lecture, puis rapproche ce témoignage des essais précédents au lieu de rouvrir indistinctement tout le dossier.
Sources officielles
Documents utilisés pour vérifier les points techniques de cet article.