Les réglages de visibilité de WordPress donnent plusieurs possibilités, à choisir selon les personnes qui relisent et les informations à préserver. Pour préparer une sortie, nous proposons de partir de ce besoin, puis de vérifier les adresses sans les droits de l’auteur. Si le contenu a déjà circulé, ce contrôle arrive trop tard pour prévenir l’exposition : il faudra aussi examiner les accès et copies laissés par la diffusion.
Le titre peut suffire à révéler l’information
Dans sa documentation sur la visibilité des contenus, WordPress distingue les publications publiques, privées et protégées par mot de passe. Un article protégé peut afficher son titre devant le formulaire d’accès. Un article privé est réservé aux personnes disposant des permissions nécessaires. Ces comportements documentés ne permettent pas de considérer le mot de passe comme une manière de cacher toute trace du sujet.
Prenons une situation fictive : un magazine prépare une annonce de changement de direction, à paraître après une communication officielle. Le nom de la personne dans le titre constitue déjà l’annonce. Masquer uniquement les paragraphes ne répond donc pas au besoin. La personne qui organise la relecture doit écrire cette contrainte avant de choisir comment transmettre la version de travail.
Le même raisonnement vaut pour un slug explicite, une légende ou le nom d’un document. Il ne s’agit pas de présumer que WordPress rend tous ces éléments publics dans chaque configuration. Il s’agit de les inclure dans ce que l’équipe vérifiera. Un test qui se limite au corps de l’article laisse précisément de côté les éléments qui peuvent porter l’information principale.
Pour cette annonce, le contrôle pourrait tenir en une phrase : « Avant la sortie, un visiteur sans accès ne doit découvrir ni le nom annoncé, ni le texte, ni le document joint. » L’auteur et la personne chargée des réseaux sauraient ainsi ce qu’ils doivent vérifier avec le responsable du site. On pourra constater le résultat sur les pages concernées, au lieu de se contenter d’un accord vague sur leur caractère privé.
Choisir un accès qui correspond aux relecteurs
Pour une relecture interne, un brouillon accessible aux personnes autorisées dans le CMS peut suffire. Le choix dépend des comptes disponibles et des permissions réellement attribuées. Il mérite un essai avec le compte du relecteur, car l’auteur et l’administrateur ne voient pas nécessairement les mêmes choses. Demander à chacun de vérifier depuis son accès donne une réponse plus fiable qu’une capture de l’écran de l’auteur.
La documentation WordPress précise que les administrateurs et éditeurs peuvent voir les contenus privés et intervenir sur les publications protégées. Ce réglage ne crée donc pas un espace réservé à un seul journaliste. Dans une rédaction partagée avec plusieurs équipes, il faut tenir compte de ce périmètre avant d’y placer une information que seuls quelques collègues devraient connaître. Permissions et visibilité documentées.
Une relecture externe pose un autre problème. Le destinataire n’a peut-être pas de compte sur le site, et lui transmettre un compte interne ne devrait pas être la solution improvisée. L’équipe peut choisir un document de travail dans son espace habituel, ou un mécanisme de prévisualisation dont elle connaît les limites. Ce guide ne suppose pas qu’une extension de partage est installée ni qu’un simple lien de prévisualisation sera accessible à tout destinataire.
Il reste à savoir quelle version le destinataire a lue. Des corrections peuvent revenir par courriel pendant que l’auteur poursuit ses modifications dans WordPress ; l’accord reçu ne porte alors pas forcément sur le texte affiché. Une date et un nom de version dans le suivi habituel permettent de rapprocher la réponse du bon document. Un accès correctement protégé ne règle pas ce décalage entre les versions.
Vérifier depuis un navigateur sans accès
Le contrôle commence avec l’adresse exacte qui sera transmise. Une session de navigation privée, déconnectée du CMS et sans mot de passe déjà saisi, permet d’observer ce qu’un visiteur ordinaire reçoit. Elle ne constitue pas un audit de sécurité complet. Son intérêt est plus immédiat : éviter de conclure à partir d’un écran qui bénéficie encore de l’accès de l’auteur.
Cette précaution compte aussi avec les mots de passe. WordPress documente l’utilisation d’un cookie pour mémoriser l’accès ; plusieurs publications utilisant le même mot de passe peuvent devenir accessibles après une seule saisie. Le comportement est décrit dans son guide de protection par mot de passe. Pour une recette, repartir d’une session vierge permet de ne pas confondre cette autorisation conservée avec l’accès offert à un nouvel arrivant.
Dans cette session, relevez ce qui apparaît sur la page, puis cherchez l’article dans les endroits où le site le présenterait normalement : accueil, rubrique et recherche interne. Ces vérifications sont proposées pour votre configuration ; elles ne supposent pas que toutes les extensions respectent les mêmes règles. Si un titre sensible ressort dans un bloc, conservez son adresse et une capture pour le responsable technique.
Confier ensuite le lien à un collègue qui n’a pas préparé la page donne un autre point de vue. Ce qu’il parvient à apprendre compte davantage que la présence du formulaire. S’il retrouve le nom annoncé sans saisir de mot de passe, la protection ne répond pas au besoin. S’il ne voit rien, le compte rendu devra tout de même nommer les adresses testées : on ne sait encore rien des fichiers qu’il n’a pas ouverts.
Examiner les pièces jointes et les champs du site
WordPress avertit que la protection par mot de passe ne couvre pas automatiquement les données de champs personnalisés affichées par le thème. Sa documentation dédiée prévoit un contrôle spécifique de ces affichages. Pour une rédaction, cela concerne les informations que son propre site place en dehors du corps standard : un encadré, une fiche ou une légende issue d’un champ ajouté.
Pour préparer cette vérification, le responsable éditorial peut relever les informations sensibles et leur emplacement dans la version de travail. La personne qui maintient le site saura alors quels champs examiner dans le thème. Un signalement comme « le nom reste visible dans le bloc de présentation » lui donne une observation à reproduire ; il ne lui demande pas de deviner ce que la rédaction voulait cacher.
Dans notre exemple fictif, un PDF aurait pu être transmis avant que l’article soit prêt. Sa propre adresse doit entrer dans le contrôle, même si la page WordPress est devenue inaccessible. Le stockage et les protections du site détermineront ce qu’un visiteur peut lire. Ouvrir directement le fichier dans la session sans autorisation permettra de répondre pour cette URL ; nous ne supposons ici aucun incident réellement constaté.
Les images de partage et les métadonnées méritent la même attention lorsqu’elles contiennent le nom ou l’annonce. Pour ce contrôle, mieux vaut examiner localement la réponse du site avec son responsable technique plutôt qu’envoyer une URL encore confidentielle à un service public d’aperçu. Le guide sur les aperçus de liens sera utile après l’ouverture publique, quand le contenu pourra être récupéré par les plateformes.
Garder les relais sociaux au même stade que l’article
Le calendrier de l’article ne suffit pas à connaître celui de tous ses relais. Dans le suivi de préparation, la rédaction devrait retrouver les textes déjà copiés, les publications programmées et les personnes capables d’envoyer une annonce. Le risque à examiner est concret : quelqu’un peut disposer d’une version prête et penser que l’autorisation de publier a déjà été donnée.
« Texte relu, sortie en attente » est un état de travail possible. Il dit aux collègues que l’accord éditorial n’autorise pas encore l’envoi. Si le créneau change, il faudra retrouver les destinations préparées et vérifier leur calendrier. Modifier l’heure dans WordPress ne constitue pas une preuve que les publications prêtes dans d’autres outils ont suivi ; chacune doit pouvoir être retrouvée par la personne qui pilote la sortie.
EditoRelay détecte des articles à partir des sources configurées, puis prépare ou publie des propositions selon les règles du média. Ce fonctionnement, présenté dans le parcours RSS, ne constitue pas une gestion d’embargo dans WordPress. Pour un contenu sensible, la rédaction doit donc contrôler ce que la source expose et choisir la validation adaptée avant d’autoriser une diffusion.
Si une source a déjà exposé le contenu et qu’un outil l’a importé, rendre ensuite l’article privé ne démontre pas que la copie importée a disparu. Il faut vérifier l’outil concerné et les envois qui y attendent. Le guide sur la suspension des publications sociales détaille cette situation. Une préparation encore confidentielle ne devrait pas servir de test réel d’autopublication.
Passer de la version relue à la version publique
Au moment de la sortie, la personne responsable compare le texte prêt à publier avec celui qui a reçu l’accord. Elle vérifie l’état de visibilité enregistré, l’heure retenue et les documents inclus. Si un nom ou une information a changé depuis la relecture, le changement doit être revu pour lui-même. L’ancien accord ne couvre pas automatiquement une version différente.
Une fois la publication effectuée, le contrôle change de sens. L’article doit maintenant être lisible à son adresse publique par une personne déconnectée. Le lien destiné aux réseaux doit conduire vers cette version, et non vers l’adresse utilisée pour relire le brouillon. L’équipe peut ensuite suivre la détection et l’envoi, sans confondre la mise en ligne du site avec la confirmation de chaque post.
Si le contenu est sorti trop tôt, noter les accès observés aidera à traiter l’incident. Cela ne permet pas d’affirmer qu’aucune autre personne ne l’a vu. Le guide de retrait d’un article couvre les copies et accès à examiner après une diffusion. Ici, la prévention se termine avec un relevé simple : version autorisée, adresses testées, heure de sortie et relais effectivement vérifiés.
Sources officielles
Documents utilisés pour vérifier les points techniques de cet article.