PrestaWard Facet Shield

Ce qu’il fait

La recherche par facettes peut générer des combinaisons de filtres très gourmandes en ressources. Un faible volume de requêtes anormales peut épuiser les ressources, ralentir les catégories ou rendre une boutique inaccessible. PrestaWard Facet Shield analyse cette complexité avant que le module de facettes ne traite la requête.

Il ne remplace pas le moteur de recherche et ne modifie pas ses index. Il agit comme un disjoncteur ciblé : il analyse le modèle de chaque requête et, uniquement lorsque la politique est expressément activée, rejette les combinaisons qui dépassent les limites configurées.

Comment ça marche

Observez d’abord. Enregistrez de manière agrégée la complexité des requêtes HTML et AJAX liées à la navigation par facettes.
Consultez les preuves. Le Back Office affiche les requêtes analysées, les requêtes dans la limite, les dépassements, les blocages réels, les histogrammes et la période statistique.
Ajustez les limites. Vous pouvez contrôler les filtres, les valeurs par facette et les requêtes mal formées en fonction du comportement réel de votre catalogue, avec des limites spécifiques à une catégorie ou à toutes celles d’un niveau du catalogue.
N’activez la Protection que lorsqu’elle a été validée. La modification nécessite une confirmation et est propre à chaque boutique.

Ce que cela comprend

Mode « Observation sécurisée » par défaut et mode « Protection explicite ».
Inscription automatique à l’Integrity API : aucun compte ni clé à configurer.
Analyse précoce de la complexité des requêtes de navigation à facettes en HTML et AJAX.
Limites configurables par boutique pour les facettes, les valeurs et le contexte de la requête.
Tableau de bord avec agrégats par minute, histogramme de complexité et motifs d’excès traduits.
Panneau des limites suggérées : à partir du trafic enregistré en mode Observation, il propose une valeur pour chaque limite, indique le nombre de requêtes bloquées par les limites actuelles et celui qui serait bloqué par la suggestion, et explique la cause principale en langage clair, par exemple quel filtre de quelle catégorie est à l’origine de la majeure partie du dépassement. Un bouton permet d’appliquer les quatre limites suggérées à la boutique sélectionnée sans modifier le mode.
Suggestions robustes : une suggestion n’est jamais plus stricte que la limite par défaut et ne va jamais au-delà de la politique signée d’Integrity. Si quelques catégories concentrent les requêtes dépassant une limite, la suggestion est calculée à partir des autres catégories, sans assouplir cette limite, et le tableau de bord explique quelle part du dépassement provient de combien de catégories.
Statistiques avec durée de conservation configurable (90 jours par défaut, comprise entre 30 et 365) : les enregistrements par minute sont regroupés par heure et ceux qui ont expiré sont supprimés par lots en arrière-plan, jamais pendant la mise à disposition d’une page à un client.
Le diagnostic des bots conserve les échantillons les plus récents (500 par défaut, configurable entre 50 et 5 000) et supprime les plus anciens au lieu de cesser l’enregistrement.
Le panneau de cache des facettes, qui distingue les tables de cache de celles des index, montre l’évolution de la taille au cours des derniers jours, avec une alerte en cas de croissance rapide, et renvoie vers la configuration native de ps_facetedsearch, où se trouvent les outils permettant de reconstruire les index et de vider le cache. Facet Shield se contente de lire ces tables et ne les modifie ni ne les supprime jamais.
Panneau nettement plus rapide dans les boutiques enregistrant un trafic important : il calcule les statistiques, les tendances et les limites suggérées à partir de deux relevés et conserve le résultat pendant dix minutes dans un fichier cache temporaire.
Synchronisation avec Integrity à l’ouverture du panneau, via une requête en arrière-plan qui ne ralentit pas le chargement de la page, à raison d’au maximum une fois par minute et par boutique.
Limites par catégorie et par niveau du catalogue : une catégorie, ou toutes celles d’un même niveau, peut disposer de ses propres limites (taille de la requête, facettes, valeurs totales et valeurs au sein d’une facette) ; une limite laissée vide utilise le niveau suivant et les limites globales restent la base. La politique signée d’Integrity limite également les limites par catégorie.
Limites suggérées par catégorie : le panneau répertorie les catégories nécessitant une autre limite, en indiquant le nombre de requêtes à partir duquel le blocage s’appliquerait actuellement ainsi que la suggestion, et permet d’appliquer une catégorie d’un simple clic. Une catégorie identifiée comme relevant d’une exploration automatisée ne fait jamais l’objet d’un assouplissement.
Protection pilote par catégorie : lorsque la boutique est en mode « Observation », vous pouvez faire en sorte que seules les catégories de votre choix soient bloquées, tandis que les autres restent en mode « Observation ». Cela nécessite une politique d’Integrity valide et signée, ainsi qu’une confirmation explicite par catégorie ; pour désactiver cette fonction, un simple clic suffit.
Limite de requêtes par adresse (facultatif) : compte le nombre de requêtes filtrées par minute et par adresse (30 par minute par défaut, entre 5 et 600). Au-delà de cette limite, en mode « Protection », l’adresse est temporairement bloquée (une heure par défaut, jusqu’à 24 heures) avec le code HTTP 429 et l’en-tête Retry-After ; en mode « Observation », elle est simplement comptabilisée. Aucune adresse IP n’est enregistrée, seulement un hachage avec une clé qui est supprimé peu après la fin du blocage ; il n’y a donc pas de liste noire permanente. Les adresses et plages de votre liste blanche ne sont jamais comptabilisées et une défaillance de la base de données ne bloque jamais un client.
Moteurs de recherche vérifiés : dans la section « Protection », un Googlebot ou un Bingbot dont les DNS inverses et directs correspondent aux serveurs officiels reçoit une réponse allégée avec l’attribut « noindex » et l’URL canonique de la catégorie au lieu d’un code d’erreur 403, de sorte que l’URL du filtre soit retirée de l’index sans exécuter de requête SQL de filtrage. Seuls ceux qui se présentent comme l’un de ces moteurs de recherche sont interrogés.
Signes de faux positifs : les requêtes qui dépassent les limites sont également comptabilisées lorsqu’elles proviennent d’un client connecté, d’un moteur de recherche vérifié ou d’une rafale rapide de dix requêtes ou plus par minute, et les statistiques indiquent ces trois chiffres ainsi que leur proportion.
Alertes par e-mail (facultatives), avec les paramètres de messagerie de la boutique : augmentation rapide de la taille du cache (au maximum une fois par jour), pics de requêtes bloquées (au maximum toutes les six heures) et un récapitulatif hebdomadaire, pour un maximum de cinq destinataires de votre choix, avec un bouton d’envoi d’e-mail de test. Pas de PDF ni de liens dans le texte, et les e-mails sont envoyés depuis la maintenance en arrière-plan, jamais lors de l’affichage d’une page à un client.
Vidéage automatique du cache (facultatif) : lorsque le cache de la recherche par facettes dépasse la taille que vous avez choisie, Facet Shield demande à ps_facetedsearch de vider son propre cache à l’aide de la méthode proposée par ce module, au maximum une fois par jour, et consigne cette opération dans le journal d’assistance. Si la version installée ne dispose pas de cette méthode, aucune modification n’est effectuée.
Avertissement concernant les versions vulnérables d’ ps_facetedsearch (de la 3.0.0 à la 4.0.3, CVE-2026-54159, corrigée dans la version 4.0.4), à partir d’un petit tableau inclus dans le module, sans aucun téléchargement.
Panneau à onglets (Aperçu, Limites et catégories, Trafic et bots, Statistiques, Cache et maintenance et Configuration, plus un onglet Assistance, toujours le dernier) : seul l’onglet ouvert est pris en compte et l’aperçu affiche le mode, les dernières 24 heures, une action principale et, au maximum, une ligne d’alerte.
Réinitialisation protégée des statistiques par boutique.
Onglet « Limites et catégories » organisé sous forme de fiches : limites globales, impact des suggestions avec des boutons de taille normale et tableau des règles par catégorie avec un formulaire permettant d’en ajouter une autre. L’onglet « Cache » utilise des blocs repliables et une seule ligne de statistiques.
E-mails d’alerte comportant le logo de votre boutique dans l’en-tête et, en pied de page, le logo de GO ON Agency accompagné de la mention « PrestaWard by GO ON Agency ».
Aspect unifié du panneau dans les quatre modules PrestaWard : en-têtes de section, fiches de formulaire aux bordures neutres et blocs repliables communs, statistiques sur une seule ligne et un logo GO ON Agency plus grand dans l’en-tête. Le bouton principal adopte désormais une couleur unie conforme à l’identité visuelle de la marque, sans dégradé.
Réponses de blocage compréhensibles (HTTP 403 ou HTTP 429 avec Retry-After dans la limite par adresse), sans dévoiler les détails internes de la politique.
Exclusion de certaines catégories de l’analyse de complexité, avec des modifications vérifiables.
Avertissement dans le tableau de bord lorsque la taille estimée du cache de la recherche par facettes atteint la limite que vous avez définie.
Panneau d’assistance de GO ON Agency proposant un rapport de diagnostic téléchargeable. Celui-ci est téléchargé par un employé disposant d’une autorisation de modification, après avoir sélectionné une boutique. Il ne contient que des versions, des états et des compteurs ; il n’inclut ni URL de requêtes, ni adresses IP, ni identifiants, et n’est pas envoyé automatiquement.
Connexion à PrestaWard Integrity, dont la politique signée ne peut que renforcer vos limites, jamais les assouplir. Sur l’écran du module, le bouton « Synchroniser » actualise la connexion.
Panneau de configuration et traductions en neuf langues.

Contrôles effectués

Avant que PrestaShop ne construise la requête de produits, Facet Shield examine le paramètre des filtres de la recherche par facettes. Les limites initiales sont de 256 octets pour le filtre, 8 facettes, 16 valeurs au total et 6 valeurs par facette ; les requêtes comportant des filtres mal formés sont rejetées. Vous pouvez les modifier pour chaque boutique et, en outre, définir vos propres limites pour une catégorie ou pour toutes les catégories d’un niveau du catalogue. Toute requête dépassant l’une de ces limites est considérée comme un dépassement.

Exigences

PrestaShop de la version 1.7.7 à la version 9, ainsi que la version de PHP requise par votre version de PrestaShop (PHP 7.1 ou supérieur pour PrestaShop 1.7).
Une boutique utilisant la recherche à facettes de PrestaShop : le module analyse le paramètre des filtres (q) des pages de catégories et de recherche.
Pour activer la Protection, la boutique doit avoir enregistré au moins une requête de facettes en mode Observation.
Les alertes par e-mail utilisent les paramètres de messagerie de la boutique.
Les limites, le mode et les statistiques sont propres à chaque boutique. Pour télécharger le rapport d’assistance ou modifier le diagnostic des bots, sélectionnez une boutique spécifique.

Confidentialité et champ d’application

Par défaut, Facet Shield n’enregistre que des métriques agrégées de complexité. Si vous activez le diagnostic des bots, qui est désactivé par défaut, il conserve un échantillon limité des requêtes dépassant les limites : jusqu’à 512 caractères du filtre de facettes, le motif, le type de page, la catégorie, l’agent utilisateur (jusqu’à 255 caractères), le compteur et les dates. Il n’enregistre jamais les adresses IP, les cookies ni les URL complètes. Si vous activez la limite par adresse, il n’enregistre qu’un hachage avec clé de l’adresse, qui est automatiquement supprimé peu après la fin du blocage. Les échantillons les plus anciens sont automatiquement supprimés dès que le nombre maximal que vous avez défini (500 par défaut) est dépassé ; l’administrateur peut les supprimer depuis le module et ils peuvent être exportés.

Son champ d’application couvre la navigation à facettes dans les catégories et les recherches, tant pour les requêtes normales que pour les requêtes AJAX. Il n’analyse pas les requêtes sans filtres, ni le panier, la commande, les formulaires, les clients ou l’accès administratif ; pour cela, des contrôles spécifiques sont nécessaires.

Ce qu’il ne fait pas

Il ne s’agit pas d’un pare-feu d’applications web (WAF) : il s’agit d’une protection supplémentaire limitée aux filtres de recherche par facettes.
Il ne remplace ni ne corrige ps_facetedsearch et n’en modifie pas les index. Il ne vide pas les caches de son propre chef : uniquement si vous activez la purge automatique, il demande à ce module de vider son propre cache à l’aide de la méthode qu’il propose, au maximum une fois par jour, et ne supprime jamais ses tables. Vous devez maintenir à jour PrestaShop et ce module.
Il ne bloque rien en mode « Observation », à l’exception des catégories que vous avez expressément placées en « Protection pilote », et ce uniquement tant qu’une politique d’Integrity valide a été signée. Si la politique expire, le module se limite à nouveau à l’observation jusqu’à ce qu’elle soit renouvelée.
Il ne conserve pas de listes noires permanentes d’adresses : le blocage lié à la limite par adresse est temporaire et s’efface de lui-même.
Il ne fait rien si la requête ne comporte pas de filtres.
Le pied de page des e-mails du module ne contient ni liens, ni coordonnées, ni images hébergées en dehors de votre boutique : le logo de GO ON Agency est un fichier provenant du module lui-même et diffusé depuis votre boutique.

Compatibilité et validation

Le module est déclaré compatible avec PrestaShop 1.7.7 à 9. La version 0.1.16 a passé avec succès les tests en laboratoire sur PrestaShop 1.7, 8 et 9 le 15 octobre 2026, aussi bien sur une installation vierge que lors d’une mise à jour depuis la version 0.1.15. Avant de l’activer, veuillez vérifier l’installation, les filtres habituels, l’Observation, la Protection, la mise à jour et la désinstallation dans votre configuration spécifique de PrestaShop, PHP, thème et modules.

Utilisation sécurisée

N’activez pas la Protection lors de l’installation. Laissez le module en mode Observation, naviguez parmi les catégories et les filtres habituels, consultez les statistiques et définissez des limites qui n’affectent pas les clients légitimes. Si une limite bloque la navigation réelle, revenez en mode Observation, corrigez le seuil et validez à nouveau.

Mise à jour de sécurité requise

Facet Shield ajoute une protection spécifique contre les signatures complètes de sérialisation PHP dans les requêtes de facettes, même si une catégorie est exclue. Il ne remplace pas le correctif officiel : pour remédier à la vulnérabilité connue du module de facettes, vous devez mettre à jour ps_facetedsearch vers la version 4.0.4 ou une version ultérieure. Le tableau de bord vous avertit s’il détecte une version concernée (de la 3.0.0 à la 4.0.3, CVE-2026-54159).

Licence

PrestaWard Facet Shield est distribué sous la licence Academic Free License 3.0 (AFL-3.0). Vous pouvez l’utiliser, l’étudier, le modifier et le redistribuer conformément à ses conditions. Le paquet du module comprend la licence complète.

Historique des versions

Ce journal des modifications résume, version par version, l’impact pour les boutiques et les équipes de commerce électronique.

0.1.16

Nouveau : limites par catégorie et par niveau du catalogue. Une catégorie, ou toutes celles d’un même niveau, peut disposer de ses propres limites (taille de la requête, facettes, valeurs totales et valeurs au sein d’une facette) ; une limite laissée vide utilise le niveau suivant et les limites globales restent la base. Une politique signée par Integrity limite également celles des catégories.
Nouveau : limites suggérées par catégorie. Le panneau répertorie les catégories nécessitant une limite différente, en indiquant le nombre de requêtes à partir duquel le blocage s’appliquerait actuellement ainsi que la suggestion, et permet d’appliquer une limite à une catégorie d’un simple clic. Il reprend la règle stricte de la suggestion globale : une catégorie qui semble relever d’une exploration automatisée ne fait jamais l’objet d’un assouplissement.
Nouveau : Protection pilote par catégorie. Lorsque la boutique est en mode « Observation », les catégories de votre choix peuvent bloquer l’accès tandis que les autres se contentent d’observer. Cela nécessite une politique Integrity signée et valide (sans laquelle Facet Shield se contente d’observer, comme auparavant) ainsi qu’une confirmation explicite par catégorie ; il suffit d’un clic pour mettre fin au mode pilote.
Nouveau : limite de requêtes par adresse, facultative. Compte les requêtes filtrées par minute et par adresse (30 par minute par défaut, entre 5 et 600) ; au-delà de cette limite, en mode « Protection », l’adresse est temporairement bloquée (une heure par défaut, jusqu’à 24 heures) avec le code d’état HTTP 429 et l’en-tête « Retry-After », tandis qu’en mode « Observation », elle est simplement comptabilisée. Aucune adresse IP n’est enregistrée : seul un hachage avec clé est conservé, qui est supprimé peu après la fin du blocage ; il n’y a donc pas de liste noire permanente. L’adresse est celle que PrestaShop résout (à l’aide des proxys de confiance) ; les adresses et plages de votre liste blanche ne sont jamais comptabilisées et un problème de base de données ne bloque jamais un client.
Nouveau : moteurs de recherche vérifiés. Dans la section « Protection », un Googlebot ou un Bingbot dont les DNS inverses et directs correspondent aux serveurs officiels reçoit une réponse allégée avec « noindex » et l’URL canonique de la catégorie au lieu d’un code 403 ; ainsi, l’URL du filtre est retirée de l’index et aucune requête SQL de facettes n’est exécutée. Seuls ceux qui se présentent comme l’un de ces moteurs de recherche sont interrogés ; le verdict est mis en cache (24 heures s’il est valide, une heure dans le cas contraire) et les requêtes sont limitées par minute pour l’ensemble des boutiques.
Signes de faux positifs : les requêtes qui dépassent les limites sont également comptabilisées lorsqu’elles proviennent d’un client connecté, d’un robot d’indexation vérifié ou d’une rafale rapide de dix requêtes ou plus par minute, et les statistiques indiquent ces trois chiffres avec leur proportion respective. Les rafales sont mesurées tant que la limite par adresse est activée.
Nouveau : alertes par e-mail, facultatives, via les paramètres de messagerie de la boutique : augmentation rapide de la taille du cache (au maximum une fois par jour), pics de requêtes bloquées (au maximum toutes les six heures) et un récapitulatif hebdomadaire distinct, pour un maximum de cinq destinataires de votre choix et avec un bouton d’envoi d’e-mail de test. Pas de PDF ni de liens dans le texte. Elles sont envoyées depuis la maintenance en arrière-plan, jamais lors de la mise à disposition d’une page à un client.
Nouveau : vidage automatique du cache, facultatif. Lorsque le cache de la recherche par facettes dépasse la taille que vous avez choisie, Facet Shield demande à ps_facetedsearch de vider son propre cache à l’aide de la méthode proposée par ce module, au maximum une fois par jour, et consigne cette opération dans le journal d’assistance. Si la version installée ne dispose pas de cette méthode, rien n’est modifié. Facet Shield continue de ne jamais effacer les tables d’un autre module.
Avertissement concernant les versions vulnérables d’ ps_facetedsearch, d’après un petit tableau inclus dans le module (aucun téléchargement n’est nécessaire) : les versions 3.0.0 à 4.0.3 sont concernées par la faille CVE-2026-54159, corrigée dans la version 4.0.4, et le panel recommande de procéder à la mise à jour.
Le panneau est organisé en onglets (Résumé, Limites et catégories, Trafic et bots, Statistiques, Cache et maintenance, et Configuration). L’onglet Résumé affiche uniquement le mode, les dernières 24 heures, une action principale et, au maximum, une ligne d’alerte ; seul l’onglet ouvert est pris en compte dans le calcul. Le tableau de bord d’assistance de GO ON Agency dispose de son propre onglet, « Assistance », toujours le dernier, et l’état d’Integrity apparaît à la fin de tous les onglets. L’en-tête affiche désormais le logo de GO ON Agency.
L’onglet « Limites et catégories » est organisé en fiches : limites globales, impact des suggestions avec des boutons de taille normale et tableau des règles par catégorie avec un formulaire permettant d’en ajouter une autre. L’onglet « Cache » utilise des blocs repliables et une seule ligne de statistiques.
Les e-mails d’alerte affichent le logo de votre boutique dans l’en-tête (avec le nom de la boutique comme texte alternatif) et un pied de page commun comportant le logo de GO ON Agency et la signature « PrestaWard by GO ON Agency », sans liens ni coordonnées. Le logo du pied de page est un fichier provenant du module lui-même et mis à disposition depuis vos boutiques.
Aspect unifié du panneau dans les quatre modules PrestaWard : en-têtes de section, fiches de formulaire aux bordures neutres et blocs repliables communs, statistiques sur une seule ligne et un logo GO ON Agency plus grand dans l’en-tête. Le bouton principal adopte désormais une couleur unie conforme à l’identité visuelle de la marque, sans dégradé.
Corrige le fait que, dans PrestaShop 9, le thème d’administration affichait les onglets soulignés comme des liens et les titres de section en majuscules. Les styles communs neutralisent cet effet uniquement au sein du panneau PrestaWard ; ainsi, PrestaShop 1.7 et 8 s’affichent comme auparavant.
Corrige le fait que, dans PrestaShop 1.7, la feuille de style du module était ignorée lorsqu’elle était enregistrée avec le numéro de version dans l’adresse. Désormais, le fichier est vérifié et enregistré sans paramètres, de sorte que le nouveau thème s’affiche dans les versions 1.7, 8 et 9.
Corrige le fait que, dans PrestaShop 9, les formulaires d’action du panneau et la synchronisation avec Integrity vérifiaient le jeton de sécurité à l’aide d’une méthode que PrestaShop 9 n’utilise pas, ce qui pouvait entraîner leur rejet. La validation s’effectue désormais via le service de PrestaShop 9 ; dans PrestaShop 1.7 et 8, la vérification reste inchangée.
Lorsque la connexion à Integrity ne peut pas être mise à jour pour le moment, le panneau affiche un seul message : la connexion enregistrée reste valide et une nouvelle tentative sera effectuée automatiquement. Les libellés de tous les onglets sont traduits dans les neuf langues.
Corrige la dégradation de la connexion avec Integrity dans le contexte « toutes les boutiques » : l’identité de l’installation est désormais lue en une seule fois à partir de la portée globale (ou de la boutique qui la stocke) quel que soit le contexte ; la mise à jour transfère vers la portée globale une identité stockée dans une boutique sans la régénérer et, si elle ne peut pas être lue, l’état d’Integrity reste inchangé.
Corrige le décalage de quelques pixels du tableau de l’onglet « Cache » sur les ordinateurs de bureau : le conteneur occupe désormais l’espace entre ses marges.
Tous les nouveaux textes sont disponibles dans les neuf langues du module. La mise à jour ajoute un petit tableau et trois compteurs aux statistiques de requêtes et n’active rien en soi ; le contrat avec l’Integrity API reste inchangé et seule une politique signée valide peut encore renforcer les limites.

0.1.15

Les statistiques de requêtes ne continuent plus à croître indéfiniment : toutes les heures, les enregistrements par minute datant de plus d’une heure sont regroupés en un seul par heure sans modifier les totaux ni les graphiques, et ceux antérieurs à la nouvelle durée « Conservation des statistiques (jours) » (90 par défaut, comprise entre 30 et 365) sont supprimés par petits lots en arrière-plan, jamais pendant qu’une page est servie à un client.
Le diagnostic des bots ne cesse plus de collecter des échantillons une fois le seuil de 500 atteint : il conserve les plus récents et supprime les plus anciens. Ce comportement est contrôlé par le paramètre « Échantillons de diagnostic à conserver » (500 par défaut, entre 50 et 5 000).
Nouveau panneau « Limites suggérées » : à partir du trafic enregistré en mode Observation, il propose une valeur pour chaque limite (taille de la requête, facettes, valeurs totales et valeurs dans une facette), indique le nombre de requêtes bloquées par les limites actuelles et celui que bloquerait la suggestion, et explique la cause principale, par exemple quel filtre de quelle catégorie entraîne le plus de dépassements. Un bouton permet d’appliquer les quatre limites suggérées à la boutique sélectionnée sans changer de mode.
Les suggestions ne sont jamais plus strictes que la limite par défaut, elles n’assouplissent jamais une limite et respectent la politique d’Integrity signée lorsqu’elle est plus stricte. Si quelques catégories concentrent les requêtes dépassant une limite, la suggestion est calculée sur le reste ; le tableau de bord indique quelle part du dépassement provient de combien de catégories et cette limite n’est pas modifiée lors de l’application.
Le panneau de cache de la recherche par facettes distingue les tables de cache des tables d’index, affiche l’évolution de leur taille au cours des derniers jours avec une alerte en cas de croissance rapide, répertorie les boutiques où ps_facetedsearch est manquant ou désactivé et renvoie vers sa configuration native. Facet Shield se contente de lire ces tables : il ne les modifie ni ne les supprime jamais.
Le panneau est nettement plus rapide dans les boutiques enregistrant un trafic important : avec plus d’un demi-million d’enregistrements, le temps de chargement passe d’environ 20 secondes à quelques secondes, et à une fraction de seconde si vous le rouvrez dans les dix minutes. Les chiffres affichés ne changent pas.
Tous les nouveaux textes sont disponibles dans les neuf langues du module.
Le panneau d’assistance et de diagnostic est placé juste avant la section Integrity, comme dans les autres modules PrestaWard, et dans le contexte « toutes les boutiques », il ne disparaît plus : cela indique qu’il faut sélectionner une boutique.
Se synchronise avec Integrity à chaque ouverture du tableau de bord, via une requête en arrière-plan qui ne ralentit jamais le chargement de la page, à raison d’au maximum une fois par minute et par boutique.

0.1.14

Cesse de réessayer l’inscription à Integrity lorsque la clé d’enregistrement de la boutique change et affiche un message d’avertissement clair.
Renouvelle la politique Integrity signée avant son expiration et conserve la politique en vigueur ainsi que ses limites en cas d’échec du renouvellement.
Une politique Integrity signée ne peut que renforcer les limites configurées dans la boutique, jamais les assouplir : pour la taille, le nombre de facettes, de valeurs et de valeurs par facette, c’est la plus petite valeur entre votre limite et celle de la politique qui s’applique, et c’est vous qui décidez du mode (Observation ou Protection).
Corrige la clé de politique incluse afin qu’elle fonctionne sous PHP 7.1 et 7.2.
Ajoute le panneau d’assistance de GO ON Agency en neuf langues, avec un rapport de diagnostic téléchargeable qui ne contient pas de données clients et n’est pas envoyé automatiquement. Seul un employé disposant d’une autorisation de modification et ayant sélectionné une boutique peut le télécharger.
Déclare la compatibilité à partir de PrestaShop 1.7.7.0, la version la plus ancienne testée.

0.1.13

Corrige le test d’inscription et les tâches du Back Office dans PrestaShop 9.
Accepte les deux formats valides d’URL de test de propriété avec une validation stricte.
Améliore le diagnostic et les nouvelles tentatives d’inscription dans Integrity.

0.1.12

La désinstallation supprime également la table des exclusions par catégorie ainsi que toutes les clés de configuration d’Integrity (phase d’installation, test d’inscription, identifiant scellé et clés), sans laisser de trace.
Ajoute les index.php de protection manquants ainsi que la vérification d’accès direct via _PS_VERSION_ dans le contrôleur du Back Office et dans les trois derniers scripts de mise à jour, tout comme dans les autres points d’entrée du module.
Adopte le système de design partagé de PrestaWard : le tableau de bord du Back Office utilise l’en-tête sombre commun, l’indicateur d’état unifié (Désactivé/Observe/Protège) et le panneau « Surveillance GO ON », servis depuis une feuille de style unique, partagée et hébergée en local.

0.1.11 — mise à jour de sécurité

Les exclusions par catégorie ne font qu’éviter l’analyse normale de complexité : les signatures complètes de sérialisation PHP continuent d’être analysées, enregistrées et bloquées systématiquement en mode Protection.
La documentation précise que ps_facetedsearch 4.0.4 ou une version ultérieure est nécessaire pour corriger la vulnérabilité CVE-2026-54159 ; Facet Shield reste un dispositif de défense en profondeur, et ne remplace pas le correctif officiel.

0.1.10

Simulateur d’URL local ou q, tendance quotidienne basée sur les agrégats existants et les exportations CSV limitées.
Exclusions vérifiables par catégorie, avec motif obligatoire et suppression logique ; les adresses IP et les user-agents ne sont pas exclus.
La première activation de la Protection nécessite des preuves issues de l’Observation et calcule une estimation prudente de l’impact avec la politique candidate ; en l’absence de requêtes observées, elle ne permet pas d’activer le blocage.
Tous les répertoires de production du pack contiennent un fichier index.php qui met fin à l’exécution, y compris views/js.
Ce guide explique comment réinscrire Integrity par boutique après avoir effectué une rotation de _COOKIE_KEY_, sans récupérer ni partager la clé précédente.
Protection supplémentaire contre les en-têtes de sérialisation PHP complets dans les requêtes de facettes, sans bloquer les valeurs normales contenant du texte telles que O:.
Avis configurable par boutique lorsque l’estimation du cache de recherche à facettes dépasse le seuil défini ; le module ne supprime ni ne met à jour quoi que ce soit automatiquement.
Les tentatives de reconnexion et les « heartbeats » d’Integrity ne s’exécutent plus au sein du rendu synchrone d’aucune page du Back Office : ils sont programmés via une requête asynchrone authentifiée et limitée.
La requête du résumé d’événements hérité est supprimée sans effacer les données historiques, et le panneau de mises à jour existant est conservé comme unique avis de nouvelles versions.

0.1.9

L’inscription utilise désormais le répartiteur de modules natif de PrestaShop et ne dépend plus des URL conviviales, des règles de .htaccess ou des caches de routes.
La mise à jour à partir des versions antérieures corrige de manière idempotente les hooks nécessaires sans supprimer les politiques ni les statistiques.
À l’ouverture du tableau de bord, le système vérifie automatiquement s’il existe une nouvelle version, avec un cache de six heures et sans bloquer le Back Office si le manifeste ne répond pas.
Fonctionnement validé sur PrestaShop 1.7, 8 et 9.

0.1.8

La protection se limite aux contrôleurs réels de catégorie et de recherche, ce qui évite de bloquer les paramètres q qui ne relèvent pas des facettes.
Les requêtes HEAD bloquées renvoient uniquement des en-têtes, sans corps.
Le diagnostic identifie l’agent tel qu’il est déclaré et explique correctement l’extrait abrégé de l’agent utilisateur qui est conservé de manière facultative.
Integrity se présente avec un minimum d’informations sur la connexion et la synchronisation, sans détails internes susceptibles de dérouter l’utilisateur.
Compatibilité fonctionnelle validée sur PrestaShop 1.7, 8 et 9.

0.1.7

Heartbeat automatique sans cron : le trafic de la boutique déclenche une requête locale limitée et le serveur confirme sa présence auprès de l’Integrity API sans exposer les identifiants au navigateur.
Verrouillage atomique par boutique, intervalle de six heures et délai d’attente de quinze minutes après les échecs afin d’éviter les envois en double.
La synchronisation manuelle d’Integrity renouvelle également le « heartbeat ».
Compatibilité validée avec PrestaShop 1.7, 8 et 9.

0.1.6

Heartbeat authentifié, tentatives automatiques et diagnostic détaillé de la connexion avec l’Integrity API.
Diagnostic facultatif également disponible en mode Observation, avec identification de l’agent, filtres par bot et motif, pagination et échantillon restreint issu de la combinaison des facettes.
Conservation contrôlée par l’administrateur : nombre d’échantillons, espace estimé et suppression manuelle depuis le Back Office.
Indicateurs visuels et en lecture seule concernant la taille, le nombre estimé d’enregistrements et les tables du cache des facettes.
Interface réorganisée : modes et activation de la Protection sous « Ce qu’il fait », sections délimitées et Integrity API reléguée à la fin.
Pas d’adresse IP, de cookies ni d’URL complètes ; textes disponibles en neuf langues.
Installation, blocage, diagnostic, cache, désinstallation et réinstallation vérifiés sur PrestaShop 1.7, 8 et 9.

0.1.5

Inscription automatique et non bloquante dans l’Integrity API via un test de vérification de la boutique.
L’installation ne nécessite ni compte, ni clé API, ni étape d’enregistrement manuel.
Les politiques signées ont été vérifiées à l’aide d’ancres de confiance incluses dans la version.

0.1.4

Histogrammes de complexité et de comptage atomique pour toutes les requêtes analysées.
Limites des valeurs par facette, requêtes mal formées et contexte de requête restreint.
Statut Observation, début de la période statistique et réinitialisation protégée par boutique.
Motifs et statistiques traduits.

0.1.3

Indicateurs des requêtes analysées, des requêtes dans la limite, des dépassements et des blocages réels.
Agrégats par boutique et par minute, sans adresse IP, URL, agent utilisateur ni valeurs sélectionnées.
Sélecteur de mode accessible et shell visuel PrestaWard pour ordinateur de bureau et mobile.

0.1.2

Identité d’installation et de boutique préparée pour Integrity API.
Politique signée avec le dernier statut valide par boutique et retour sécurisé au mode Observation.
État de la connexion et nouvelle tentative manuelle depuis le Back Office, sans appel depuis le Front-Office.