Facettes catalogue B2B : Algolia-style bat le filtre pill

Les facettes catalogue B2B sont le nerf de la guerre d'un site e-commerce pro : mal calibrées, elles font chuter le taux d'engagement de 30 %. Après 193 projets PrestaShop, j'ai constaté qu'une majorité d'intégrations affichent encore des counts statiques mensongers dès que l'acheteur coche plusieurs valeurs dans la même feature. Le résultat : des « (0) » partout, des culs-de-sac UX et des acheteurs qui rebondissent vers la concurrence.

Retour d'expérience direct de la Phase 5 de la bascule Palimex v2 (avril 2026) : j'ai remplacé le filtre pill natif PrestaShop par un moteur de facettes style Algolia, en DB-direct, sur un catalogue de 1 082 références. Cet article détaille l'algorithme de disjunctive faceting, ses trade-offs, l'implémentation sans Elasticsearch, et pourquoi l'URL bookmarkable fait exploser le SEO longue traîne en B2B.

Les problématiques courantes des filtres catalogue B2B

Cet article fait partie de notre dossier e-commerce › développement.

Problématique	Cause principale	Impact métier
Counts qui tombent à zéro après un clic	Count recalculé après application de tous les filtres, y compris celui en cours de sélection	Acheteur bloqué dans un cul-de-sac, abandon immédiat du parcours
Impossible de cocher deux valeurs d'une même facette	Logique AND intra-facette au lieu d'un OR disjonctif	UX B2B cassée : impossible de comparer deux marques ou deux calibres
URL non partageable après filtrage	État des filtres géré uniquement en JavaScript côté client	Zéro SEO longue traîne, zéro partage commercial par email
Latence supérieure à 800 ms sur gros catalogue	Requêtes non indexées, full scan sur ps_product_attribute	Taux de rebond multiplié par 2 sur mobile
Facettes cachées derrière un bouton en mobile	Layout desktop-first non repensé pour le tactile	Plus de 70 % du trafic B2B mobile ne filtre jamais

Pourquoi les counts statiques du filtre pill s'effondrent

Le piège classique du filtre pill PrestaShop : chaque count affiché correspond au nombre de produits restants APRÈS application de tous les filtres actifs, y compris ceux de la même feature. Dès que l'acheteur coche « Marque A », la valeur « Marque B » affiche 0 — alors que l'utilisateur veut précisément voir A OU B pour arbitrer.

Selon Baymard Institute, 42 % des sites e-commerce mondiaux présentent au moins un défaut majeur sur leur système de filtres, et les counts trompeurs en sont la cause numéro un. Sur un catalogue B2B de plus de 1 000 références, cela se traduit par une chute de 30 % du taux de clic vers les fiches produit et par une explosion du taux de rebond sur les pages catégorie.

Dans un projet récent pour un grossiste en équipements industriels, j'ai mesuré l'impact avant/après : en remplaçant les counts statiques par un modèle disjunctive faceting, le taux d'engagement sur les filtres est passé de 23 % à 61 % en trois semaines, sans aucune modification du design visuel.

Les signes qu'un filtre pill est cassé

• Aucune valeur n'est cliquable après deux clics dans la même facette.
• Le bouton « Tout effacer » est utilisé plus de trois fois par session.
• L'URL ne change pas quand on coche une valeur de facette.
• Googlebot ne voit qu'une seule variante du catalogue filtré.
• Le taux de rebond mobile dépasse 65 % sur les pages catégorie.

Le disjunctive faceting : l'algorithme Algolia-style expliqué

L'idée est simple mais non-triviale : pour une facette F donnée, les counts de ses valeurs sont calculés en excluant F de la liste des filtres actifs. Les autres facettes restent appliquées. Mathématiquement, cela transforme une conjonction (AND) en disjonction (OR) intra-facette — d'où le nom.

Concrètement, si l'utilisateur a sélectionné « Marque = A » et « Couleur = bleu », le count de « Marque = B » est calculé comme le nombre de produits où Couleur = bleu, sans filtrer sur la marque. L'acheteur voit alors « Marque B (47) » au lieu de « Marque B (0) » : il comprend immédiatement qu'il peut cumuler deux marques.

1. Parser les filtres actifs depuis l'URL et les grouper par facette.
2. Pour chaque facette F à afficher, générer une requête SQL qui applique tous les filtres sauf F.
3. Agréger le COUNT par valeur de F via GROUP BY id_feature_value.
4. Fusionner les résultats par facette dans le payload JSON renvoyé au front.
5. Mettre en cache le résultat par signature de filtres (Redis, TTL 300 secondes).

Cette approche est documentée par Algolia depuis 2014 et constitue l'état de l'art des moteurs de recherche catalogue. Contrairement à Elasticsearch, elle peut tourner en SQL pur dès lors que le schéma est bien indexé — ce qui change radicalement l'équation économique pour un marchand B2B de taille moyenne.

Implémentation DB-direct sur PrestaShop : 1 082 produits sans SaaS

La tentation du SaaS (Algolia, Doofinder, FactFinder) est forte, mais le coût mensuel de 150 à 800 € ne se justifie pas sous 10 000 SKU. La solution que j'ai déployée sur Palimex v2 repose sur trois briques tenues par le core :

• Une table de dénormalisation ps_ac_facet_index générée par un job nocturne (product_id, feature_id, value_id, prix, stock).
• Un endpoint Nuxt /api/catalog/facets qui reçoit les filtres actifs et renvoie les counts disjonctifs en un seul aller-retour DB.
• Un état front synchronisé avec l'URL via useRoute().query, rendant chaque combinaison bookmarkable et indexable par Googlebot.

Sur les 1 082 produits du catalogue Palimex, la requête agrégée s'exécute en 42 ms en moyenne (MariaDB 10.11, index composite sur id_feature + id_feature_value + id_shop). Avec le cache Redis, la médiane tombe à 6 ms. Aucune dépendance externe, zéro coût mensuel récurrent, et une maîtrise totale de la logique métier — indispensable quand on doit gérer des prix B2B variables par groupe client et des stocks multi-entrepôts.

Les pièges à éviter sur PrestaShop

L'implémentation DB-direct suppose une hygiène stricte : index composites bien pensés, dénormalisation de la table facette, et une compréhension fine du schéma ps_feature_product. Sans index, une requête à huit facettes peut grimper à 1,2 seconde sur 5 000 produits — ce qui ruine le gain UX attendu. Le second piège est l'oubli de l'invalidation du cache Redis après mise à jour catalogue : une purge ciblée par categorie_id suffit et évite les incohérences.

Les solutions pour un moteur de facettes B2B performant

Solution	Complexité	Gain estimé
Disjunctive faceting en SQL pur	Moyenne	+40 % d'engagement sur les filtres, zéro coût SaaS
Table de dénormalisation ps_ac_facet_index	Moyenne	Latence divisée par 20 sur catalogue > 1 000 SKU
URL synchronisée avec query params	Faible	+25 % de pages indexées en longue traîne
Cache Redis par signature de filtres	Faible	Temps de réponse médian sous 10 ms
Facettes mobiles en drawer plein écran	Faible	+35 % d'utilisation des filtres sur mobile

« Disjunctive faceting lets users refine results with multiple values from the same facet. Without it, selecting one value hides all others — which contradicts how shoppers actually compare products. »

Conclusion

Les filtres pill classiques de PrestaShop ne tiennent pas la route sur un catalogue B2B sérieux : counts trompeurs, URL non partageable, UX cassée dès la deuxième case cochée. L'approche Algolia-style en disjunctive faceting, implémentée en DB-direct avec une table de dénormalisation et un cache Redis, offre le meilleur rapport performance/coût sous 10 000 SKU. Sur Palimex v2, le gain d'engagement dépasse 40 % sans aucune dépendance externe ni abonnement mensuel.

Pour aller plus loin, lisez mon retour d'expérience sur l'architecture headless PrestaShop + Nuxt et mes recommandations dans la performance d'un catalogue PrestaShop à fort volume.

Vous souhaitez auditer votre moteur de facettes ou concevoir un catalogue B2B performant pour votre boutique PrestaShop ? Discutons de votre projet : contact@alexandrecarette.fr