Protection par mot de passe dans PrestaShop : masquer des pages et des produits au public

« Masquer ceci au public » semble être une seule et même tâche. Dans PrestaShop, ce sont en réalité quatre besoins différents qui se ressemblent, et choisir le mauvais levier, c’est ainsi que des marchands se retrouvent avec des prix grossistes visibles par des clients particuliers, un produit « secret » avant lancement présent dans le sitemap, ou une page CMS protégée par un simple mot de passe partagé si faiblement qu’elle pourrait presque être publique. La plateforme vous donne de vrais outils pour chaque cas, groupes de clients, mode B2B, visibilité des produits, mode maintenance, mais ils masquent des choses différentes, à des niveaux différents, avec des garanties très différentes. Ce guide explique quel contrôle correspond à quelle intention, les chemins exacts dans le back-office, et la limite à partir de laquelle « caché à la navigation » ne signifie plus « sécurisé ».

Un point à régler d’emblée, parce qu’il change toutes les recommandations ci-dessous : le contrôle d’accès n’est pas du chiffrement. Les outils de visibilité de PrestaShop décident ce que le navigateur d’un visiteur affiche ; ils ne verrouillent pas les fichiers sous-jacents. Nous reviendrons sur les cas où cette distinction devient critique. Pour le travail plus large de sécurisation de la boutique elle-même, administration, serveur, en-têtes, cet article reste dans son périmètre et vous renvoie à la checklist de durcissement de la sécurité PrestaShop.

Relu en juin 2026 avec PrestaShop 1.6, 1.7, 8 et 9 pour le comportement des groupes de clients, du B2B, de la visibilité des produits et de la maintenance, ainsi qu’avec le module mprpasswordprotect actuel.

Commencez par décider ce que vous masquez vraiment

Avant de toucher à un réglage, nommez l’intention, car le bon contrôle en découle directement :

• Un niveau d’audience complet (acheteurs grossistes, membres, segment B2B) doit voir des éléments que les visiteurs particuliers ne doivent pas voir. C’est un sujet de groupes.
• Un seul produit doit exister sans apparaître encore dans la navigation ni la recherche (pré-lancement, échantillon accessible uniquement par lien). C’est un sujet de visibilité produit.
• Toute la boutique doit être invisible pendant que vous la construisez ou la préparez, sauf pour vous. C’est un sujet de mode maintenance.
• Une page précise (une liste de prix, des documents partenaires, une page d’accueil réservée aux membres) doit être placée derrière un mot de passe. C’est un sujet de mot de passe de page, et c’est celui pour lequel PrestaShop n’a pas de réponse native.

Choisissez le mauvais outil et vous restreignez trop (des clients B2C payants se retrouvent bloqués) ou pas assez (du contenu privé est indexé par Google). Les sections ci-dessous reprennent chaque intention une par une.

Méthode 1, Groupes de clients : masquer un niveau d’audience, pas un élément isolé

C’est la réponse la plus native dans PrestaShop, et celle vers laquelle la plupart des marchands devraient se tourner en premier quand la question est « qui a le droit de voir ceci ». L’accès se contrôle au niveau de la catégorie, puis se répercute sur les produits qu’elle contient.

• Créez un groupe dans Paramètres de la boutique → Paramètres clients → Groupes (par exemple « Grossistes », « VIP », « Membres »).
• Ouvrez la catégorie restreinte puis, dans le panneau Accès des groupes, décochez les trois groupes par défaut fournis par PrestaShop, Visiteur (navigateurs non connectés, ce qui inclut les robots des moteurs de recherche), Invité et Client, en ne laissant coché que votre groupe privé.
• Affectez les bons clients à ce groupe (manuellement sur la fiche client, ou automatiquement, nous y revenons plus bas).

Pourquoi c’est l’option propre : lorsque le groupe Visiteur est décoché, la catégorie et ses produits disparaissent réellement pour toute personne qui n’est pas connectée au bon groupe. Dans la navigation et la recherche normales de PrestaShop, ils ne remontent ni dans les listes de catégories ni dans les résultats de recherche pour quelqu’un qui n’est pas connecté au bon groupe, parce que le robot d’exploration est le groupe Visiteur. La couche d’accès se charge du masquage, il n’y a donc pas d’étape séparée du type « penser aussi à le passer en noindex » pour la navigation normale. Une réserve mérite d’être formulée clairement : la sortie du sitemap dépend de votre module sitemap/SEO et de la manière dont les produits sont affectés. Un produit également présent dans une autre catégorie publique, ou un module sitemap négligent, peut donc encore exposer l’URL, auditez le sitemap généré et tous les produits multi-catégories avant de faire confiance à la restriction. Et concrètement ? Vos tarifs professionnels restent entre vous et vos acheteurs vérifiés, sans surveillance manuelle d’un fichier robots.

La limite honnête : les groupes nécessitent des comptes. Un visiteur doit s’inscrire et être placé dans le bon groupe avant de voir quoi que ce soit ; cette approche convient donc aux relations que vous contrôlez (vente en gros, adhésion) plutôt qu’à un simple « je veux partager un lien avec quelqu’un que je ne connais pas ». Si vous voulez verrouiller les prix pour toute la boutique plutôt que catégorie par catégorie, le mode B2B et l’option d’affichage des prix par groupe s’en chargent, c’est la suite.

Méthode 2, Mode B2B plus masquage des prix par groupe : réserver les prix aux acheteurs professionnels

PrestaShop inclut un mode B2B natif dans Paramètres de la boutique → Paramètres clients → Activer le mode B2B. Soyez précis sur ce qu’il fait réellement, car on lui prête souvent trop de choses. L’activer ajoute des champs B2B aux comptes clients, Société, SIRET, APE, Encours autorisé, Nombre maximum de jours de paiement, Niveau de risque, ainsi qu’une entrée Encours autorisés dans le menu Clients. Voilà ce qu’est le mode B2B natif : des champs professionnels supplémentaires et une base de gestion du crédit. À lui seul, il ne masque pas les prix et n’ajoute pas de validation de compte. Les nouvelles inscriptions sont actives immédiatement, comme n’importe quel compte B2C.

Le contrôle qui masque réellement les prix est séparé et se trouve au niveau du groupe : ouvrez un groupe dans Paramètres de la boutique → Paramètres clients → Groupes et décochez Afficher les prix. Lorsque cette option est désactivée pour le groupe Visiteur (et Invité), les navigateurs non connectés peuvent toujours voir le catalogue, mais sans prix ni ajout au panier, tandis que les clients professionnels connectés appartenant à un groupe où Afficher les prix reste coché voient tout. Si vous avez vraiment besoin que chaque nouveau compte soit validé manuellement avant de pouvoir acheter, cette étape d’approbation n’est pas native. Il faut ajouter un module d’inscription/validation.

La bonne recette native pour une boutique réservée aux professionnels est donc le mode B2B (pour les champs entreprise et les limites de crédit) combiné avec l’option « Afficher les prix » du groupe (pour verrouiller les tarifs), pas le mode B2B seul. Ce modèle convient à un portail distributeur ou à une marque vendant uniquement en gros. Il ne convient pas à une boutique mixte B2B/B2C, car masquer les prix au groupe Visiteur les masque aussi à vos visiteurs particuliers, et un acheteur particulier qui ne voit pas de prix quitte simplement la boutique. Pour les boutiques mixtes, ne verrouillez pas les prix à l’échelle du site, utilisez la méthode 1 (un groupe grossiste sur les catégories professionnelles) et laissez le catalogue grand public ouvert.

Méthode 3, Visibilité du produit : masquer un produit sans toucher aux comptes

Chaque produit dispose d’un réglage de visibilité dans son onglet Options (dans les anciennes versions 1.6, il se trouvait dans la zone SEO/associations). Les quatre valeurs ne font pas la même chose, et leurs noms se lisent facilement de travers :

• Partout, affiché dans les listes de catégories et trouvable dans la recherche. C’est l’état normal.
• Catalogue uniquement, apparaît dans la navigation par catégories, mais la recherche interne ne le renvoie pas.
• Recherche uniquement, renvoyé par la recherche, mais non listé dans la navigation par catégories.
• Nulle part, la page produit existe toujours à son URL, mais rien dans la boutique ne pointe vers elle. Pas de catégorie, pas de recherche, pas de menu.

Nulle part est le réglage de pré-lancement et de « partage avec quelques personnes » : la page est en ligne, donc un lien direct fonctionne, mais un visiteur ordinaire ne peut pas tomber dessus par hasard. Le point à dire clairement, c’est de l’obscurité, pas de la sécurité. L’URL peut se deviner si vos slugs suivent un modèle, et le produit peut encore être inclus dans votre sitemap selon le module sitemap que vous utilisez et sa configuration, vérifiez le XML généré, car un sitemap qui le liste transmettrait le « secret » directement à Google. Considérez « Nulle part » comme acceptable pour un échantillon de pré-lancement à faible enjeu, jamais comme un moyen de protéger quelque chose qui compte vraiment. La bonne recette de pré-lancement : définissez la visibilité sur Nulle part, partagez l’URL avec les quelques personnes qui en ont besoin, puis repassez sur Partout le jour du lancement.

Méthode 4, Mode maintenance : masquer toute la boutique pendant la construction

Dans Paramètres de la boutique → Général → Maintenance, vous pouvez désactiver entièrement la boutique côté public et la remplacer par une page de maintenance, tout en ajoutant vos propres IP à la liste blanche (le champ IP de maintenance, « Ajouter mon IP » renseigne celle depuis laquelle vous êtes connecté) afin que votre client et vous voyiez toujours la boutique en direct.

C’est réellement utile dans deux situations : construire une nouvelle boutique que vous ne voulez pas encore voir indexée ou découverte, et préparer une refonte pour qu’un client la prévisualise avant la mise en ligne. Ce que ce n’est pas : un système de contrôle d’accès. C’est tout ou rien. Vous ne pouvez pas ouvrir une section aux membres et fermer le reste ; toutes les personnes hors liste d’IP voient le même écran. Pour un besoin permanent du type « les membres voient X, le public voit Y », ce sont les groupes (méthode 1), pas le mode maintenance. Tant que la boutique est en maintenance, elle renvoie un HTTP 503, le bon signal pour dire aux robots « revenez plus tard » plutôt que « cette page a disparu ».

Méthode 5, Protéger une page précise par mot de passe (le manque natif)

La barrière par mot de passe se configure depuis le module, avec contournement pour les employés et comportement noindex.

Le module Password Protect filtre les requêtes très tôt via le hook du dispatcher, avant le rendu du contenu de la page :

public function getHooks()
{
    return [
        'actionDispatcherBefore',
    ];
}

Voici le cas que la plateforme ne couvre pas. Il n’existe aucun réglage natif PrestaShop permettant de placer une page CMS, une catégorie ou un produit derrière une simple invite de mot de passe. Les outils natifs sont soit basés sur les comptes (groupes), soit tout ou rien (maintenance). Le module mprpasswordprotect actuel est lui aussi une barrière pour toute la boutique côté public : il redirige les requêtes front-office et les requêtes de modules vers une page de mot de passe partagé jusqu’à ce que le visiteur s’authentifie. C’est adapté aux boutiques avant lancement et aux vitrines privées ; ce n’est pas encore un ciblage par page, par catégorie ou par produit.

Le module livré est utile lorsque l’objectif est une boutique protégée par mot de passe : une boutique avant lancement, un aperçu de catalogue privé ou une zone temporaire de validation client. Il s’accroche à actionDispatcherBefore, vérifie le mot de passe partagé, définit un cookie front-office et peut envoyer une réponse 503/noindex tant que la barrière est active. Qu’est-ce que cela vous apporte ? Toute une boutique peut être masquée derrière un seul mot de passe partagé, sans modification du cœur ni friction liée aux comptes clients. Pour une liste de prix revendeurs, une page CMS, une catégorie ou un produit, utilisez les groupes natifs ou la visibilité produit lorsque les comptes sont acceptables, ou considérez le ciblage par entité avec mot de passe comme une fonctionnalité manquante à implémenter correctement.

Soyez lucide sur ce qu’est, et n’est pas, un mot de passe partagé : un seul secret, partagé par toutes les personnes qui le possèdent, sans piste d’audit par utilisateur. C’est le bon niveau pour un contenu « modérément privé, à faible impact » (un lookbook saisonnier, une fiche partenaire). Ce n’est pas le bon niveau pour des données juridiquement sensibles, voir la note de sécurité ci-dessous.

Combiner les méthodes pour des scénarios réels

La plupart des configurations en production empilent deux ou trois de ces méthodes, parce que les intentions se chevauchent :

• Catalogue grossiste : groupes de clients pour restreindre les catégories professionnelles + étape de vérification avant d’accorder le groupe + prix spécifiques au groupe. Si vous collectez aussi des informations de demande professionnelle (numéro de TVA, type d’entreprise), les modèles pour capturer ces données d’inscription supplémentaires et agir dessus sont décrits dans les informations client supplémentaires et les blocages IP.
• Produit avant lancement : visibilité réglée sur Nulle part + lien partagé avec quelques personnes + passage à Partout le jour du lancement.
• Page réservée aux membres : groupes de clients si les membres ont déjà des comptes ; une barrière par mot de passe par page nécessite une implémentation de module ciblée, tandis que le module Password Protection actuel protège la boutique dans son ensemble.
• Nouvelle boutique encore en construction : mode maintenance avec votre IP en liste blanche jusqu’au lancement.

Le piège SEO : caché dans l’interface, indexé dans Google

PrestaShop ne génère pas de sitemaps XML par lui-même ; l’exclusion se règle donc dans le module sitemap que vous utilisez, comme gsitemap ou Advanced SEO Sitemap Builder.

La barrière d’accès et les règles de sitemap doivent dire la même chose.

L’échec le plus fréquent ici n’est pas un réglage qui ne fonctionne pas. C’est une page « cachée » qui reste discrètement publique pour les robots. Deux règles permettent de garder le contenu privé réellement privé :

• Le contenu restreint par groupe est sûr par défaut. Comme un robot est un Visiteur non authentifié, tout ce que vous avez masqué au groupe Visiteur est aussi masqué à Googlebot. Aucune étape supplémentaire n’est nécessaire.
• La visibilité « Nulle part » n’est pas sûre par défaut. La page existe toujours, et si votre module SEO/sitemap l’inclut, vous avez publié l’URL dans Google. Vérifiez que les produits non liés sont exclus du sitemap et, pour tout ce qui doit rester privé, ajoutez une directive noindex au lieu de compter sur « personne ne crée de lien vers cette page ».

Si vous utilisez une suite SEO/sitemap, auditez ce qu’elle émet réellement avant de faire confiance à une restriction. Un sitemap trop généreux peut annuler un réglage de visibilité soigneux. Et rappelez-vous qu’une page protégée par mot de passe n’aurait jamais dû apparaître dans un sitemap public au départ ; la barrière gère les humains, l’exclusion du sitemap gère les robots.

Où le contrôle d’accès s’arrête et où la sécurité commence

C’est la limite à intégrer. Tout ce qui précède contrôle ce qu’un navigateur affiche. Rien de tout cela ne chiffre les fichiers ni ne garantit qu’une personne déterminée ne pourra pas atteindre la ressource sous-jacente. Concrètement :

• Les images d’un produit vivent à des URL prévisibles et peuvent parfois être récupérées directement même lorsque la page produit est restreinte, car les fichiers image ne sont pas soumis au même contrôle d’accès que la page.
• Une URL « Nulle part » ou partagée peut fuiter via l’historique du navigateur, les en-têtes de référent ou le transfert du lien par quelqu’un.
• Un contenu chargé dans la page puis masqué avec CSS reste présent dans le code source pour toute personne qui ouvre les outils de développement.

Donc, pour des éléments réellement confidentiels, contrats tarifaires signés, documents juridiques, tout contenu dont l’exposition serait un vrai problème, ne vous appuyez pas du tout sur la visibilité de la boutique. Servez-les depuis un système correctement sécurisé, avec une vraie authentification et, idéalement, une protection des fichiers au niveau serveur. Les contrôles de visibilité de PrestaShop sont conçus pour un contrôle d’accès commercial (qui obtient le prix grossiste), pas pour protéger des données critiques de sécurité. Si vous durcissez plus largement la boutique, les règles .htaccess de sécurité et de performance couvrent la protection des fichiers et répertoires au niveau serveur, et le guide en langage clair pour sécuriser votre boutique pose le contexte plus large. Et si quelque chose de privé a déjà été exposé, le guide de réponse à une fuite de données est la prochaine page à lire.

Questions fréquentes

Comment protéger par mot de passe une seule page CMS ou un produit dans PrestaShop ?

Il n’existe pas de réglage natif PrestaShop pour cela. Les outils natifs sont soit basés sur les comptes (groupes de clients), soit tout ou rien (mode maintenance). Le module mprpasswordprotect actuel place toute la boutique côté public derrière un seul mot de passe partagé, ce qui convient à une boutique avant lancement ou à un aperçu privé, mais il n’est pas encore ciblable par page, par catégorie ou par produit. Pour une page unique où les comptes sont acceptables, utilisez les groupes de clients ; un véritable ciblage par entité avec mot de passe est une fonctionnalité qui demande une implémentation spécifique.

Quelle est la différence entre le mode B2B et le masquage des prix ?

Ce sont deux contrôles distincts, que l’on confond souvent. Le mode B2B (Paramètres de la boutique → Paramètres clients) ajoute seulement des champs professionnels et une base de gestion du crédit, Société, SIRET, APE, encours autorisé, jours de paiement, niveau de risque. Il ne masque pas les prix et n’ajoute pas de validation de compte. Pour masquer les prix, ouvrez un groupe et décochez Afficher les prix pour le groupe Visiteur (et Invité). Une boutique réservée aux professionnels a besoin des deux : le mode B2B pour les champs, l’option de groupe pour les prix.

Si je règle un produit sur « Nulle part », est-il privé ?

Non, c’est de l’obscurité, pas de la sécurité. La page produit existe toujours à son URL, donc un lien direct fonctionne ; « Nulle part » signifie simplement que rien dans la boutique ne pointe vers elle. L’URL peut se deviner si vos slugs suivent un modèle et, selon votre module sitemap, elle peut encore être publiée dans Google. Utilisez ce réglage pour des échantillons avant lancement à faible enjeu, vérifiez leur exclusion du sitemap généré et ajoutez une directive noindex pour tout ce qui doit vraiment rester hors de la recherche.

Masquer un produit ou une catégorie l’empêchera-t-il aussi d’apparaître dans Google ?

Cela dépend de la méthode utilisée. Le contenu restreint par groupe est sûr par défaut. Un robot est un Visiteur non authentifié, donc tout ce qui est masqué au groupe Visiteur est aussi masqué à Googlebot, sans étape supplémentaire. La visibilité « Nulle part » n’est pas sûre par défaut : la page existe et un module sitemap trop généreux peut republier l’URL. Auditez toujours le XML réellement émis par votre module sitemap avant de faire confiance à un réglage de visibilité.

Puis-je utiliser ces outils pour protéger des documents juridiquement sensibles ?

Non. Chaque méthode décrite ici contrôle ce qu’un navigateur affiche ; aucune ne chiffre les fichiers. Les images produit vivent à des URL prévisibles et peuvent être récupérables même lorsque la page est restreinte, les liens partagés fuitent via l’historique et les en-têtes de référent, et le contenu masqué par CSS reste présent dans la source de la page. Pour des contrats signés, des documents juridiques ou tout élément dont l’exposition serait un vrai problème, servez-les depuis un système correctement sécurisé avec une vraie authentification et une protection des fichiers au niveau serveur, pas avec la visibilité de la boutique.

À retenir : « masquer au public » se décompose en quatre besoins, masquer un niveau d’audience (groupes), un seul produit (visibilité), toute la boutique (maintenance) ou une page (module de mot de passe), et chaque outil natif garantit quelque chose de différent. Faites correspondre l’outil à l’intention, vérifiez que votre sitemap ne republie pas discrètement ce que vous avez caché, et ne confondez jamais « afficher moins » avec « sécuriser ». Faites cela, et le bon contenu atteindra les bonnes personnes sans qu’une liste de prix privée se retrouve dans les résultats de recherche de quelqu’un.