Identifier ce que le visiteur voit réellement
Vous ouvrez une page dans votre session d’administration, mais les personnes auxquelles elle est destinée ne voient rien, rencontrent une page introuvable ou restent devant une demande d’accès. Le résultat recherché est simple : permettre la lecture aux destinataires autorisés tout en maintenant le refus pour les autres visiteurs.
Demandez d’abord l’adresse exacte et le message rencontré, sans réclamer le mot de passe. Distinguez une page absente du menu, une adresse qui ne s’ouvre pas, une demande de connexion et un formulaire de mot de passe. Ces symptômes ne correspondent pas nécessairement au même mécanisme.
Depuis Pages, retrouvez le document original et son lien de consultation. Comparez le domaine et le chemin avec l’adresse transmise. Un lien d’aperçu, une ancienne adresse ou le lien vers l’éditeur ne remplace pas l’adresse destinée aux lecteurs. Si la page fonctionne directement mais manque dans le menu, examinez la navigation séparément.
Un refus peut être normal pour une personne qui n’a pas encore l’autorisation prévue. Ne rendez pas la page publique pour savoir si cela débloque la situation. Notez plutôt quel public doit la consulter, par quel moyen et jusqu’à quand : cette décision permettra de choisir une correction adaptée.
Relever la protection avant toute modification
Ouvrez le document avec un compte autorisé à le gérer. Dans les réglages de la page, examinez son état et sa visibilité. Selon l’éditeur et la version, les choix se trouvent près de Statut ou dans Visibilité. Dans l’éditeur classique, ils figurent dans le panneau de publication.
Relevez si la page est privée, protégée par mot de passe, encore en brouillon ou programmée. Vérifiez aussi si tout le site exige une connexion. Une restriction d’espace membre peut s’ajouter à la visibilité du document ; son nom et sa règle doivent être identifiés avant d’agir.
Conservez les valeurs initiales sans copier les secrets dans des captures, des tickets ou un document partagé. Pour un changement de règle générale, de modèle ou de composant, prévoyez une sauvegarde récupérable et une copie de test avec le responsable. Une simple observation de l’état ne nécessite pas de modifier l’installation.
Sur WordPress autohébergé, les comptes et réglages dépendent du site. Sur WordPress.com, certaines autorisations concernent aussi le compte de plateforme. En multisite, vérifiez le sous-site et les droits qui y sont attribués. Relevez les versions si les libellés ou le comportement diffèrent de ceux décrits.
Reproduire le lien de menu avec un visiteur et un éditeur
Sur une copie, créez une page « Dossier d’atelier » et ajoutez son adresse comme lien personnalisé dans un bloc Navigation. Ajoutez un second lien vers une page qui doit rester publique, « Plan public ». Gardez une troisième page publique, « Présentation de l’atelier », si vous voulez tester une destination de remplacement. Ouvrez les deux entrées initiales du menu sans être connecté. Notez le nom du menu, les libellés et les adresses réellement servies. Relevez le statut de la page Dossier avant d’essayer un autre état.
Dans la copie, passez cette page à Privé, puis recommencez avec l’état Brouillon. À chaque essai, ouvrez la même page de départ en visiteur et suivez le lien du menu. Essayez aussi l’adresse directe dans la session d’un éditeur autorisé sur la copie. Pour le brouillon, comparez l’aperçu si cette commande est disponible. Le menu de la recette garde le lien personnalisé dans les deux états. Le visiteur reçoit une 404, alors que l’éditeur fictif ouvre la page à la même adresse et peut aussi prévisualiser le brouillon. Le lien Plan reste le témoin public.
Gardez le statut observé dans la fiche, indépendamment du texte affiché par le thème. Une 404 dans cette recette indique ce que reçoit le visiteur. Elle ne suffit pas, à elle seule, à établir qu’une page a été supprimée. Si l’entrée a disparu du menu au lieu de mener à une erreur, vérifiez la source de la navigation. Une liste de pages automatique peut suivre les publications visibles. La recette porte sur un lien ajouté manuellement.
Corriger le lien public ou rétablir la publication
Si la page doit rester privée ou en brouillon, ouvrez le menu qui produit l’entrée publique. Modifiez seulement l’entrée concernée. Si une page publique remplit le même rôle pour les visiteurs, utilisez son adresse et un libellé qui annonce sa destination. Sinon, retirez l’entrée du menu. Dans la recette, « Dossier d’atelier » devient « Présentation de l’atelier ». En visiteur, cette entrée ouvre la présentation. L’adresse directe du dossier en brouillon renvoie toujours une 404, et le lien Plan est inchangé. Vous avez corrigé le chemin public tout en conservant le statut du dossier.
Vérifiez où le menu est réutilisé avant de l’enregistrer. Une même entité de menu peut servir dans plusieurs modèles. Si les visiteurs doivent voir le nouveau lien partout où ce menu figure, modifiez l’entrée dans cette source. Si une autre zone doit conserver sa propre navigation, identifiez le menu ou le bloc réellement affecté avant de faire le changement. Un remplacement d’en-tête ou de menu entier n’est pas nécessaire pour une seule entrée.
Si la décision éditoriale confirme que le dossier doit être accessible au public et qu’il a été retiré par erreur, relisez la version à remettre en ligne dans la copie. Le brouillon peut contenir un travail en cours qui ne fait pas partie de la version approuvée. Rétablissez ensuite l’état Publié et la visibilité publique sur la page elle-même. Vérifiez que le lien du menu désigne toujours sa véritable adresse. Dans le test, la page retrouve une réponse 200 en visiteur avec le même lien enregistré. Le repère du dossier est visible et Plan ouvre encore sa page. Cet essai rétablit l’accès prévu à un document qui doit réellement être public. Il ne change pas la règle d’accès des pages qui doivent rester réservées.
Les deux fragments du menu fictif montrent le lien initial puis le lien vers la présentation publique. Le second lien, « Plan public », est resté identique. Vérifiez ces deux champs dans le réglage du menu qui est réellement affiché.
<!-- wp:navigation-link {"label":"Dossier d’atelier","url":"\/?page_id=4","kind":"custom"} /-->
<!-- wp:navigation-link {"label":"Présentation de l’atelier","url":"\/?page_id=6","kind":"custom"} /-->Revenir à l’état précédent sur la copie
Si vous avez corrigé le menu, remettez son ancien libellé et son ancienne destination dans la copie. Comparez les deux entrées au relevé. Le dossier doit garder son statut de départ. Dans la recette, le retour à l’entrée d’origine fait réapparaître la 404 du brouillon côté visiteur. Ce résultat est attendu dans cet essai de restauration, et montre que le statut de la page n’a pas changé avec le menu.
Si vous avez rétabli la publication, revenez au statut que vous aviez noté avant l’essai et contrôlez de nouveau l’adresse directe sans connexion. La recette revient à Brouillon et retrouve la 404 du visiteur. Le balisage du menu et le corps de la page sont identiques à ceux de l’état qui précédait la republication. Comparez ces deux éléments séparément dans le relevé, puis vérifiez le lien témoin. Le test couvre le bloc Navigation avec des liens personnalisés et les droits du rôle Éditeur du cœur. Les listes automatiques, les redirections et les extensions de restriction peuvent produire d’autres réponses.
Choisir le parcours correspondant au mode d’accès
Une page privée utilise des autorisations de compte. Une page protégée par le mot de passe natif utilise un secret associé au document. Un site privé ou un espace membre ajoute ses propres conditions. Ne traitez pas ces trois organisations comme des variantes d’un même bouton.
Choisissez le premier parcours si le document porte la visibilité Privé. Il permet de vérifier le compte et les droits, sans transformer un lecteur en administrateur. Choisissez le deuxième si un mot de passe de page est prévu : la vérification porte alors sur ce secret et sur son formulaire.
Le troisième parcours convient lorsqu’une barrière concerne tout le site ou un groupe de membres. Commencez par identifier le système déjà en place ; installer un autre outil d’accès au milieu du diagnostic rendrait les résultats plus difficiles à comprendre.
Si plusieurs restrictions se cumulent, examinez-les dans l’ordre rencontré par le lecteur. Une personne peut franchir la connexion au site et rester bloquée par la visibilité de la page. Après chaque correction autorisée, vérifiez la même adresse avec le même compte. Gardez un relevé du changement pour pouvoir rétablir précisément la règle précédente.
Approche 1 : vérifier le compte d’une page privée
Pour une page privée, demandez à la personne de se connecter à son propre compte sur le site concerné, puis de rouvrir le lien direct. Vérifiez avec elle le compte utilisé, sans demander ses identifiants. Une connexion réussie démontre une identité reconnue ; elle ne garantit pas les droits de lecture de cette page.
Sur un WordPress standard, les rôles Administrateur et Éditeur possèdent par défaut les droits permettant de lire les pages privées d’autrui. Un simple compte Abonné n’obtient pas cette lecture parce qu’il est connecté. Les rôles personnalisés et les règles ajoutées par une extension peuvent modifier ce comportement ; le cas de l’auteur du document mérite également un contrôle distinct.
Avec un accès autorisé à la gestion des comptes, vérifiez dans Comptes ou Utilisateurs l’appartenance de la personne au bon site et son rôle actuel. En multisite, ne déduisez pas les droits du sous-site de sa seule présence dans le réseau. Faites intervenir l’administrateur concerné si cette vérification dépasse votre périmètre.
Si les droits prévus sont déjà présents mais que l’adresse reste refusée, conservez le message et l’heure, puis examinez les restrictions supplémentaires. Ne modifiez pas successivement plusieurs rôles pour voir lequel fonctionne. Le résultat attendu est une explication précise du refus, avec le minimum de changement nécessaire.
Distinguer lecteur du site et lecteur d’une page privée
Sur WordPress.com, un site entièrement privé peut accueillir des lecteurs approuvés, désignés par le rôle Viewer ou Lecteur selon l’interface. Ce mécanisme concerne l’accès au site. Il ne faut pas l’assimiler à la visibilité Privé d’une page individuelle, documentée séparément pour les administrateurs et éditeurs.
Vérifiez d’abord si l’invitation concerne le bon site et le bon compte WordPress.com. Si la personne voit une demande d’accès à tout le site, le propriétaire doit vérifier cette autorisation par le parcours prévu. Si elle entre sur le site mais pas sur cette page, revenez à l’état du document et aux autres restrictions.
Un abonnement aux publications ne rend pas automatiquement la personne lectrice approuvée d’un site devenu privé. De même, disposer d’un compte WordPress.com ne signifie pas appartenir à tous les sites de la plateforme. Ne demandez pas de créer plusieurs comptes pour compenser une invitation adressée à la mauvaise identité.
Relevez le niveau où l’accès échoue : plateforme, site ou page. Cette distinction évite de changer la visibilité de tout le site pour une seule ressource. Une nouvelle autorisation de site doit rester limitée aux personnes prévues, avec la possibilité de la retirer ensuite selon les règles du propriétaire.
Corriger le mode d’accès sans donner des droits excessifs
Si les destinataires doivent seulement lire un document, le statut Privé natif n’est peut-être pas le mécanisme adapté à votre organisation. N’attribuez pas un rôle Éditeur ou Administrateur pour leur fournir cette seule lecture : ces rôles accordent des possibilités de gestion bien plus larges.
Faites confirmer le besoin par le responsable du contenu. Un mot de passe de page peut convenir à un partage simple lorsque ses limites sont acceptables. Une autorisation individuelle, un retrait par personne ou des documents sensibles demandent un dispositif d’accès adapté, à définir avec le responsable plutôt qu’à improviser pendant le dépannage.
Si une correction de rôle est réellement nécessaire parce que la personne exerce déjà les responsabilités correspondantes, faites-la effectuer par l’administrateur autorisé. Relevez le rôle précédent, le rôle validé et le périmètre concerné. Vérifiez ensuite la lecture ainsi que les accès accordés, sans utiliser le compte d’un collègue.
Pour revenir en arrière, rétablissez le rôle ou la règle relevée et contrôlez le refus attendu. Ne changez pas le rôle par défaut de tous les nouveaux comptes. Si vous préparez un autre mode de partage, conservez la page d’origine et sa protection jusqu’à validation du parcours complet ; évitez un intervalle de publication ouverte entre deux configurations.
Approche 2 : contrôler le mot de passe de la page
Si le partage repose sur le mot de passe natif, ouvrez la page dans l’éditeur avec les droits requis et confirmez que la protection est bien enregistrée. Consultez ensuite son adresse de lecture dans une session distincte. Le parcours attendu comporte un formulaire avant l’affichage du texte protégé.
Ce mot de passe est celui du document, pas celui du compte WordPress du visiteur. La protection par mot de passe ne demande pas en elle-même de créer un compte lecteur. Si une connexion est également exigée, recherchez une restriction supplémentaire du site plutôt que de communiquer un mot de passe d’administration.
Vérifiez que les destinataires ont reçu la version actuelle du secret par votre canal de partage habituel. Une ancienne consigne, une saisie différente ou un remplissage automatique peuvent expliquer l’échec. Ne placez pas le secret dans le lien public, le menu, une capture ou le commentaire d’un ticket de support.
Si le mot de passe est perdu ou doit être remplacé, une personne autorisée peut en définir un nouveau dans le réglage de protection, enregistrer et prévenir les destinataires concernés. Conservez la protection pendant cette opération. Le nouveau secret doit être vérifié dans une session propre ; l’accès encore ouvert dans votre navigateur habituel ne suffit pas à valider le partage.
Comparer les sessions et les cookies du navigateur
WordPress utilise un cookie pour reconnaître la saisie d’un mot de passe de document. Il s’agit d’une information conservée par le navigateur, distincte de l’autorisation d’un compte. Cela peut expliquer pourquoi une personne voit le texte sans nouvelle demande alors qu’une autre reste devant le formulaire.
Comparez d’abord la même adresse dans votre session habituelle et dans une fenêtre privée neuve. Fermez les autres fenêtres privées si vous voulez repartir d’une session distincte. Respectez les restrictions nécessaires au site : une page privée par compte demande toujours la connexion autorisée, même dans ce mode de navigation.
Si le problème concerne un seul navigateur, vérifiez les données du site et les réglages qui empêchent l’enregistrement des cookies. Suivez l’aide du navigateur pour agir sur le domaine concerné plutôt que d’effacer toutes les données de navigation. Cette suppression ciblée peut déconnecter les comptes et faire redemander les mots de passe ; prévenez la personne avant l’essai.
Sur un ordinateur partagé, fermez la session utilisée pour consulter le document et suivez les règles locales de suppression des données. Ne considérez pas la fermeture d’un simple onglet comme une révocation d’accès. Si une confidentialité par personne est indispensable, un secret partagé ne fournit pas à lui seul cette gestion individuelle.
Vérifier aussi la protection réelle des pièces jointes
Le mot de passe natif du document ne constitue pas une protection des fichiers qu’il contient. Une image ou un autre média téléversé peut rester accessible par son adresse directe. Le fait que le lecteur doive saisir un secret pour voir le texte ne permet donc pas de conclure que le téléchargement joint est réservé au même public.
Avec l’autorisation du responsable, identifiez les pièces concernées et leur adresse réelle dans la bibliothèque ou le lien de téléchargement. Contrôlez leur accès depuis une session non autorisée, sans les diffuser à une personne supplémentaire. Distinguez le refus du document et celui du fichier ; ce sont deux résultats à relever séparément.
Si un fichier confidentiel reste ouvert, interrompez ce mode de partage et faites intervenir le responsable pour sa protection ou son retrait selon la procédure du site. Changer seulement le mot de passe de la page ne répare pas l’accès direct. Ne dupliquez pas le fichier sous une nouvelle adresse supposée secrète en guise de contrôle d’autorisation.
Le titre, l’existence de la page et les autres éléments de présentation méritent aussi une vérification depuis l’extérieur. Une protection du corps du texte ne promet pas l’invisibilité de tous les éléments qui l’entourent. Adaptez les informations affichées au public réellement autorisé à les connaître.
Approche 3 : examiner une restriction du site ou des membres
Si toutes les pages demandent un accès, vérifiez d’abord la règle de l’ensemble du site. Sur WordPress.com, le réglage correspondant se trouve dans Réglages, Lecture, à la rubrique de visibilité du site. Consultez sa valeur sans la passer en Public pour débloquer une seule personne.
Pour un site privé WordPress.com, le propriétaire peut examiner les invitations et demandes d’accès prévues pour les lecteurs. Vérifiez que l’identité approuvée correspond au compte utilisé par la personne. Après correction, contrôlez une page ordinaire du site, puis le document concerné : une visibilité privée individuelle peut toujours imposer une condition supplémentaire.
Sur un site doté d’un espace membre, identifiez la règle appliquée à la page et le mécanisme qui l’évalue. Avec le responsable de cet outil, comparez le compte refusé et un compte de même catégorie qui fonctionne : appartenance au groupe, état d’autorisation et éventuelle échéance. Les intitulés et conditions dépendent du dispositif installé ; suivez sa documentation officielle.
Corrigez uniquement l’association ou la règle effectivement erronée et notez sa valeur précédente. Ne simulez pas un achat ni un renouvellement réel pour rétablir un accès pendant le diagnostic. Si un paiement ou une validation manuelle fait partie du parcours, faites examiner son état par la personne habilitée, sans modifier artificiellement les données pour obtenir un résultat favorable.
Rechercher un problème d’affichage après les autorisations
Si les règles sont cohérentes mais que le formulaire manque ou boucle, notez si le problème touche toutes les pages protégées ou un seul modèle. Le parcours natif sait afficher un formulaire lorsque le mot de passe est requis. Une présentation personnalisée doit être examinée avec le responsable du thème avant de conclure que la protection elle-même est cassée.
Conservez la structure actuelle et reproduisez le cas sur une copie sauvegardée, avec des données d’essai non confidentielles. Le responsable doit neutraliser les notifications, paiements et autres effets externes de cette copie. Comparez un seul composant suspect à la fois et rétablissez-le si l’essai ne confirme pas son rôle.
Examinez également le cache déjà en place si une ancienne réponse semble persister après un réglage enregistré. Utilisez le parcours documenté du site ou du service, selon les fonctions disponibles. Une purge éventuelle ne remplace pas la vérification de la règle d’accès et n’autorise pas à diffuser une copie du contenu réservé.
Si un visiteur non autorisé voit le texte, interrompez la mise à disposition et sollicitez immédiatement le responsable du site pour rétablir la protection prévue. Conservez l’adresse, l’heure et le contexte sans multiplier les captures du contenu. Un résultat plus ouvert que prévu n’est pas une réussite du dépannage, même si le destinataire peut désormais lire la page.
Valider l’accès autorisé et le refus attendu
Terminez par deux vérifications distinctes : le destinataire prévu peut ouvrir la bonne adresse et lire ce qui lui est destiné ; une session non autorisée reste bloquée selon le mécanisme choisi. Pour un mot de passe, utilisez une session sans cookie antérieur et contrôlez la saisie correcte ainsi que le refus d’une saisie incorrecte.
Vérifiez le parcours sur le navigateur réellement utilisé par la personne, y compris sur téléphone si nécessaire. Contrôlez les liens de téléchargement et le retour vers la page après connexion. Ne vous contentez pas de votre session d’administration, dont les droits et les données de navigateur diffèrent de ceux des lecteurs.
Consignez la correction, sa date et son périmètre, sans enregistrer de mot de passe en clair. Retirez les éventuels comptes ou accès temporaires selon la procédure convenue. Le retour arrière doit rétablir la valeur précise de visibilité, de rôle ou de règle conservée au départ, avec un nouveau contrôle du refus attendu.
Si le blocage reste inexpliqué, transmettez au support les versions, le mode de restriction, l’adresse par un canal adapté et le message exact. Indiquez où le parcours s’arrête et quelles comparaisons ont été faites. Gardez les secrets et le contenu confidentiel hors du ticket ; le responsable pourra demander les éléments supplémentaires nécessaires par un moyen approprié.
