Ce que corrige cette version
L’annonce mentionne plusieurs vulnérabilités, dont une faiblesse du processus de mise à jour pouvant permettre une exécution de code à distance pendant cette opération. Elle décrit aussi des problèmes de scripts malveillants persistants dans plusieurs composants, un déni de service dans l’Interactivity API et la possibilité de découvrir des modifications non publiées du personnalisateur. Ces éléments justifient de transmettre rapidement l’avis au responsable technique. Ils ne permettent pas, à eux seuls, d’affirmer qu’un site particulier a été compromis.
Certaines rédactions n’auront aucune opération à lancer : l’annonce prévoit le démarrage automatique de la mise à jour sur les installations compatibles avec ce mécanisme. Il faut tout de même regarder ce qui s’est passé. Le courriel annonçant 7.1.4 peut arriver avant son installation, et une opération peut avoir commencé sans aboutir. Demandez la version relevée après l’intervention, avec la date de ce relevé. Si un message d’erreur subsiste, il fait partie du compte rendu.
Cette publication concerne le maintien en sécurité du site exploité. Les essais d’une future version majeure suivent un autre calendrier, décrit dans notre article sur WordPress 7.2 bêta et les tests d’une rédaction. Une campagne de découverte de nouvelles fonctions ne devrait pas devenir une raison de laisser sans traitement l’avis de sécurité du 28 octobre.
Qui confirme la version installée ?
Prenons un cas fictif assez simple : la rédactrice en chef compte sur le prestataire web, qui pense que l’hébergeur applique les correctifs. Personne n’a vérifié la version. Pour sortir de cette attente, elle transmet l’adresse du site et la référence de l’annonce à son interlocuteur technique, en lui demandant de confirmer l’installation. Il peut la réaliser lui-même ou joindre l’hébergeur ; la rédaction sait désormais qui lui répondra et à quel sujet.
La réponse attendue est concrète : version relevée, mise à jour déjà appliquée ou intervention prévue, personne chargée du contrôle après installation. Si plusieurs sites utilisent le même contrat, chacun garde sa ligne de suivi. Le bon état du titre principal ne renseigne pas sur celui d’un ancien microsite encore accessible, ni sur une édition locale qui possède sa propre installation. L’inventaire doit correspondre aux sites réellement maintenus.
La documentation de mise à jour WordPress décrit le passage par le tableau de bord et les mises à jour en arrière-plan. Elle prévoit aussi des cas où l’opération nécessite une intervention sur les fichiers. Une rédaction qui n’administre pas l’hébergement peut demander l’exécution au prestataire sans improviser cette procédure. L’important est que le relais soit pris immédiatement et que le blocage éventuel soit nommé, plutôt que de multiplier les demandes sans responsable.
Préserver les textes produits pendant l’intervention
Avant la manipulation, l’équipe technique vérifie la sauvegarde. Le manuel d’administration WordPress distingue les fichiers du site et sa base de données ; les deux sont nécessaires pour restaurer une installation habituelle. Le fait de disposer d’un export d’articles ne démontre donc pas qu’une restauration complète est possible. Notre guide sur l’export WordPress et la sauvegarde d’un média développe cette différence.
La sauvegarde a une heure, et le travail éditorial continue après. Une enquête terminée dans cet intervalle manquerait dans une restauration de cette copie. Avant l’intervention, la rédaction et le prestataire conviennent donc du sort des textes en cours : faut-il suspendre brièvement les écritures, ou suffit-il de consigner les changements pendant le créneau ? La réponse dépend de l’opération prévue. Une interruption générale n’a pas à être annoncée si elle ne sert à rien, mais les journalistes doivent savoir ce qu’ils peuvent enregistrer.
Dans l’exemple du petit média, le secrétaire de rédaction note les articles modifiés pendant le créneau, avec leur état et les corrections encore à reprendre. Il conserve les versions utiles dans l’espace de travail déjà prévu par l’équipe. On évite ainsi de découvrir, après un retour arrière, qu’une correction sensible a disparu alors que le site paraît à nouveau fonctionner. Le suivi porte sur les contenus effectivement touchés, pas sur une copie improvisée de toute la rédaction.
Un retour arrière demande la même attention. Qui peut le décider, et où sont les données produites depuis la sauvegarde ? Ces questions se règlent avant d’en avoir besoin. Le site pourrait redevenir accessible tout en servant des textes périmés, dont une correction que l’équipe croyait acquise. Il faudrait alors les rétablir. Et si la restauration remet en place une version vulnérable, le problème de sécurité reste à traiter avec le responsable technique.
Le brouillon s’enregistre, l’article se lit
Un écran d’administration accessible ne suffit pas à clore l’intervention. La rédaction peut préparer un brouillon sans information sensible, l’enregistrer, le rouvrir et vérifier que les blocs utilisés au quotidien sont toujours présents. Il n’est pas nécessaire de publier ce texte d’essai. Une image, une légende et un lien interne permettent de contrôler un petit parcours représentatif, avec les permissions habituelles du journaliste plutôt qu’avec un compte administrateur qui masquerait certains obstacles.
Côté lecteur, la vérification commence sur une vraie page d’article, ouverte sans connexion au CMS. L’équipe choisit une publication récente et un contenu comportant un élément qu’elle utilise souvent, par exemple une galerie ou un tableau. Elle regarde ce qui s’affiche sur mobile, ouvre les liens et contrôle les informations utiles à la lecture. Le résultat doit décrire les pages visitées ; deux parcours réussis ne prouvent pas que toutes les extensions et toutes les archives fonctionnent.
Supposons que le brouillon s’enregistre bien, mais que la galerie publique reste vide. Ce sont deux résultats à transmettre séparément, avec l’adresse de l’article et le compte utilisé pour l’essai. La mention « site testé » ne permettrait pas de les retrouver. Le prestataire pourra examiner la galerie sans immobiliser la rédaction sur une nouvelle vérification complète. Les essais réussis restent utiles, à condition de ne pas leur faire dire que tout le site a été contrôlé.
Suivre la prochaine publication jusqu’à sa diffusion
Le prochain article du calendrier fournit un contrôle que les essais dans le CMS ne remplacent pas. La rédaction le désigne à l’avance, puis suit sa sortie : adresse publique, heure de publication, présence dans le flux utilisé pour la diffusion. Il n’est pas nécessaire d’inventer une actualité ou de publier un texte d’essai pour cela. Tant que cet article n’est pas sorti, on peut confirmer les vérifications déjà faites et garder ce dernier contrôle en attente.
Le contrôle d’un flux porte notamment sur le lien, le titre et le texte qu’il expose. Si quelque chose manque, il faut conserver l’observation avant d’accuser la mise à jour : l’anomalie peut préexister ou venir d’un autre changement. Le guide consacré au flux RSS qui ne se met plus à jour aide à localiser ce type de défaut sans recommencer toute la configuration.
Avec EditoRelay, les nouveaux articles sont détectés depuis les sources configurées, puis les propositions sont préparées ou publiées selon les règles du média. La présentation des intégrations situe ce parcours. Une mise à jour WordPress réussie ne confirme pas à elle seule que la détection et l’envoi social ont eu lieu. Le responsable de diffusion regarde l’article concerné, les propositions et l’historique ; il ouvre aussi la publication réelle lorsque l’envoi était prévu.
Si un envoi semble absent, relancer plusieurs fois sans vérifier les états risque de brouiller le diagnostic. L’équipe conserve l’heure, l’adresse de l’article et le message affiché, puis suit sa procédure de reprise. Aucun résultat de publication connectée n’est supposé dans cette méthode : chaque média doit observer son propre parcours, avec ses comptes et ses autorisations.
Traiter un défaut sans perdre le bénéfice du correctif
Un signalement tel que « depuis l’intervention, je ne peux plus enregistrer cet article avec mon compte de journaliste » donne un début de diagnostic. C’est un exemple de formulation, à remplacer par l’observation réelle. « La mise à jour a tout cassé » laisse le prestataire chercher. La rédaction joint l’adresse concernée, le résultat attendu et ce qu’elle a effectivement observé ; elle précise si le défaut existait auparavant. Un bloc mal affiché, une erreur d’enregistrement et un site inaccessible peuvent survenir dans la même période sans avoir la même cause. Le signalement doit garder ces différences.
La documentation WordPress recommande de vider le cache après la mise à jour lorsque celui-ci est utilisé. Cette étape relève de l’administration du site ; elle doit être suivie d’une nouvelle lecture publique. Si une correction paraît invisible, notre guide sur la version d’un article servie depuis le cache décrit comment distinguer les versions observées. Le simple fait de recharger son propre navigateur ne suffit pas à établir ce que reçoit un autre lecteur.
Lorsque le défaut empêche de publier, la direction éditoriale et le responsable technique choisissent ensemble la solution temporaire. Ils précisent ce qui reste disponible, les contenus éventuellement affectés et la prochaine vérification. La pression du bouclage ne doit pas transformer une suppression d’extension ou une restauration complète en geste automatique. La correction retenue doit aussi préserver les textes, les accès et les protections du site.
À la fin, le compte rendu tient dans les faits vérifiés : version installée, parcours réalisés, anomalies restantes et personne qui les suit. Le contrôle de la prochaine publication peut encore attendre sa sortie. Il reste alors ouvert, avec le nom de la personne qui regardera le flux et la diffusion. La rédaction sait ainsi ce qui a été confirmé avant de reprendre son travail, et ce qu’elle devra encore observer au prochain article.
Sources officielles
Documents utilisés pour vérifier les points techniques de cet article.