Recherche à facettes PrestaShop : des filtres utiles, sans ralentir ni dupliquer les pages

La recherche à facettes d’une boutique PrestaShop, c’est le module ps_facetedsearch : il filtre les catégories à partir d’index et d’un cache stockés en base. Elle peut ralentir quand ses index sont reconstruits aux heures de vente ou que le cache enfle, et elle déroute quand les valeurs proposées n’ont pas de sens pour le client. Au 14 octobre 2026, la version 5.1.0 est la dernière publiée du module.

• Le module ps_facetedsearch de PrestaShop répond aux filtres par des tables d’index et un cache
• Quatre boutons du module reconstruisent ses index, à des coûts très différents
• Un cache de filtres qui grossit se repère à la taille de ses tables
• Des filtres utiles reposent sur des attributs et des caractéristiques cohérents
• Un modèle de filtres par catégorie évite les filtres vides ou inutiles
• Les filtres ne remplacent pas le réglage de la barre de recherche
• Les adresses de filtres sollicitent le serveur avant même leur indexation
• Un module de filtres tiers se jauge sur cinq points avant toute installation
• Ce qui se chiffre dans une mission de filtres
• Des réglages justes en apparence faussent la mesure ou les filtres
• Sources consultées
• Foire aux questions

Le module ps_facetedsearch de PrestaShop répond aux filtres par des tables d’index et un cache

Un filtre est une condition simple, « produits bleus » ; une facette combine des filtres par des opérateurs logiques, « produits bleus ou rouges ». La documentation développeur décrit un moteur qui traduit les choix du client en requêtes SQL (le langage de la base de données), lancées sur des tables d’index préparées, avec un cache des résultats stocké en base.

La version courante du module demande PrestaShop 8.2.0 ou plus récent, d’après le dépôt public : une boutique plus ancienne utilise une version antérieure. Avant PrestaShop 1.7, le module s’appelait blocklayered, et ses tables portent encore le préfixe « layered » pour cette raison.

La version 5.1.0 indexe les prix pour chaque pays actif de la boutique et annonce une optimisation de l’affichage des listes de produits, d’après ses notes de publication du 10 septembre 2026.

Quatre boutons du module reconstruisent ses index, à des coûts très différents

Dans la configuration du module, le bloc « Indexes and caches » (libellés de la documentation anglaise) propose quatre actions.

La documentation fonctionnelle recommande une reconstruction nocturne, par deux adresses à jeton (clés d’accès) appelées par une tâche planifiée : l’une pour les prix, l’autre pour les attributs. La documentation développeur compte trois points d’entrée, dont un vide le cache.

Scénario : une reconstruction complète des prix lancée à midi sur un catalogue de plusieurs milliers de produits ralentit les pages au moment où les clients filtrent. Faites écrire l’heure de chaque tâche ; le cas d’un catalogue volumineux relève aussi de la mission gros catalogue.

Un cache de filtres qui grossit se repère à la taille de ses tables

Demandez à l’hébergeur la taille des tables dont le nom commence par « layered » après le préfixe de votre base, lisible dans son panneau. Si l’une d’elles domine la base, le bouton « Clear cache » ou son adresse planifiée la vide.

Le réglage « Enable cache system » est activé par défaut et les résultats de filtres y sont gardés en base. Plus les combinaisons demandées sont variées, plus ce cache s’étoffe : déduction, à vérifier sur vos tables. Mesurez une page filtrée avant et après : sans mesure, désactiver le cache déplace la lenteur sans la prouver.

Décrire mon besoin →

Des filtres utiles reposent sur des attributs et des caractéristiques cohérents

La documentation utilisateur distingue deux familles. Un attribut crée des variantes que le client choisit : couleur, taille. Une caractéristique décrit ce qui ne varie pas : poids, matière. Les deux ont une option d’indexation qui les rend disponibles au module de filtres.

Scénario : une boutique saisit « Rouge », « rouge » et « Rouge bordeaux » comme trois valeurs. Le filtre affiche trois lignes pour une seule idée, et chaque valeur reçoit sa propre adresse. Nettoyez les valeurs avant d’ajuster le module.

Dans le benchmark de Baymard Institute, 34 % des 344 sites de commerce testés ont une mise en œuvre médiocre des filtres.

Un modèle de filtres par catégorie évite les filtres vides ou inutiles

Les filtres se composent par modèle, rattaché à des catégories. Le modèle par défaut reprend tous les filtres disponibles, d’après la spécification 1.7 du module. Scénario : un modèle pour les chaussures n’a pas besoin du filtre « poids ».

• Chaque filtre se règle : style (cases à cocher, boutons radio ou liste déroulante), limite de valeurs affichées jusqu’à 20, ordre par glisser-déposer.
• Seules les cases à cocher permettent plusieurs choix à la fois.
• « Category filter depth » vaut 1 par défaut ; 0 supprime la limite de profondeur.
• « Show products from subcategories » élargit le périmètre du filtre aux sous-catégories.

La version 5.1.0 ajoute une option de cases à cocher en logique ET pour les caractéristiques.

Les filtres ne remplacent pas le réglage de la barre de recherche

La barre de recherche se règle dans la page Recherche des paramètres de la boutique, avec des poids par champ, à part du module de filtres. D’après la documentation développeur, la référence pèse 10 par défaut, le nom du produit 6, les tags 4 et les descriptions 1. Baymard relève que, sur plus de 170 sites et applications évalués, 56 % ne répondent pas correctement aux besoins de recherche des visiteurs.

Les adresses de filtres sollicitent le serveur avant même leur indexation

Google écrit que l’exploration d’adresses de navigation à facettes tend à coûter aux sites de grandes quantités de ressources de calcul. Chaque combinaison de filtres a sa propre adresse : un robot en parcourt un grand nombre avant de les juger inutiles. Le fichier robots.txt (consignes aux robots), la balise canonical (adresse de référence) et la balise noindex (exclusion de l’index) relèvent de la mission facettes et indexation.

Un module de filtres tiers se jauge sur cinq points avant toute installation

Un module tiers qui remplacerait le module officiel devrait se juger sur cinq points : compatibilité avec votre version de PrestaShop, ce qu’il indexe et à quel moment, où il garde son cache, ce qu’il laisse en base à la désinstallation, rythme de ses mises à jour. Faites écrire les cinq réponses.

Décrire mon besoin →

Ce qui se chiffre dans une mission de filtres

Par déduction, le coût d’une mission suit le nombre de modèles de filtres, le nombre de valeurs à nettoyer, la présence d’un module tiers et la copie de test à monter. Faites aussi écrire qui remet les pages en état si un changement de filtres les dégrade.

Des réglages justes en apparence faussent la mesure ou les filtres

Mesurer la catégorie sans filtre cache le coût du filtrage : testez avec trois filtres cochés, sur mobile aussi. Si la page reste lente sans aucun filtre, la cause est ailleurs : un audit de performance la situe.

Vider le cache juste avant un pic de visites oblige la base à recalculer les requêtes au moment où elles abondent.

Après un import de prix, vérifiez le filtre de prix sur une catégorie. La spécification 1.7 demande de mettre les index à jour à chaque changement des produits ; d’après le code de la version 5.1.0, l’enregistrement d’un produit indexe ses prix et ses attributs.

Dans le message du formulaire de cette page, reportez la version de PrestaShop, celle du module de filtres et la catégorie la plus lente.

Sources consultées

• PrestaShop, documentation développeur, « Faceted search » et « Inside the module », consulté le 14 octobre 2026.
• PrestaShop, documentation fonctionnelle, « Faceted search (ps_facetedsearch) », consulté le 14 octobre 2026.
• PrestaShop, « ps_facetedsearch specifications », build.prestashop-project.org, consulté le 14 octobre 2026.
• PrestaShop, dépôt public ps_facetedsearch, README, notes et code de la version 5.1.0 (fichiers ps_facetedsearch.php et src/Hook/Product.php), consulté le 14 octobre 2026.
• PrestaShop, documentation utilisateur de la version 8, « Managing product attributes », « Managing product features » et « Search parameters », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur, « Products search index », consulté le 14 octobre 2026.
• Baymard Institute, « Ecommerce Search UX 2026 » et page « Filtering Options » du benchmark des listes de produits, consulté le 14 octobre 2026.
• Google Search Central, « Managing crawling of faceted navigation URLs », consulté le 14 octobre 2026.

Foire aux questions

Faut-il désactiver le cache du module de filtres ?

Pas sans mesure. Chronométrez une catégorie filtrée avec le cache, puis après l’avoir vidé, puis après l’avoir désactivé. Si l’écart est faible et que les tables de cache grossissent, un vidage planifié suffit. Si la page ralentit nettement sans cache, gardez-le et planifiez son vidage la nuit.

Elasticsearch remplace-t-il le module de filtres ?

La documentation de l’échelle range Elasticsearch, ou une solution bâtie dessus, parmi les ajouts possibles pour les recherches des clients. Elle ne dit pas qu’il remplace le module officiel : cela dépend de la solution choisie. Demandez au prestataire ce qu’elle remplace, ce qu’elle laisse en place et comment elle se met à jour.

Peut-on afficher le nombre de produits à côté de chaque valeur ?

Oui : le réglage « Show the number of matching products » est activé par défaut. Le compteur évite au client de cliquer sur une valeur vide. Si une catégorie est lente, mesurez-la avec et sans compteur avant de le retirer.

Combien de filtres faut-il afficher par catégorie ?

La documentation fonctionnelle ne fixe aucun nombre. Elle permet de limiter les valeurs affichées par filtre, jusqu’à 20. Le bon nombre se juge sur vos catégories : gardez les filtres que vos clients utilisent, en vous appuyant sur les mesures de votre outil d’audience.

Le module de filtres fonctionne-t-il en multiboutique ?

D’après le README du dépôt, le module est partiellement compatible avec le mode multiboutique, plusieurs boutiques gérées depuis un même back-office : certaines options peuvent manquer. Testez les réglages boutique par boutique.