Chaque module indique la plage de versions PrestaShop qu'il prend en charge sur sa propre page produit, vous y trouverez la version exacte couverte. La plupart des modules du catalogue livrent un seul ZIP qui détecte la version de l'hôte à l'installation et charge le bon chemin de code. Le même achat continue donc de fonctionner à mesure que vous mettez votre boutique à jour.

Ce que « pris en charge » signifie concrètement :

• Nous effectuons des tests de régression sur une installation neuve de chaque version prise en charge avant chaque release.
• Les signalements de bugs sur toute version prise en charge sont traités selon la même politique de support. Pas de « désolé, cette version est trop ancienne ».
• Quelques modules exigent un cœur plus récent car l'API PrestaShop qu'ils utilisent n'existait pas dans les versions plus anciennes ; c'est indiqué sur la page produit.

Si votre boutique tourne sur un cœur très ancien et non maintenu, mieux vaut mettre PrestaShop à jour d'abord, nous ne rétroportons pas vers des cœurs qui ne reçoivent plus de correctifs de sécurité.

mypresta.rocks est une petite équipe spécialisée de développeurs PrestaShop basée à Tychy, en Pologne. Nous développons des modules PrestaShop depuis 2013 et avons enregistré la société en 2018.

Nous développons, vendons et suivons plus de 150 modules couvrant le SEO, le checkout, la performance, la recherche, l'analytique et plus encore. Ce qui compte pour vous : PrestaShop est la seule chose que nous faisons, nous ne sommes pas une agence généraliste qui touche aussi à d'autres plateformes. Quand vous achetez un module, le support vient de ceux qui l'ont écrit.

Parcourez le catalogue de modules ou lisez l'histoire complète sur notre page à propos.

Les deux fonctionnent, et vous pouvez aussi les exécuter en même temps. Activez la plateforme GTM et saisissez votre container ID si vous voulez que tout passe par Tag Manager, le module pousse tous les événements ecommerce vers le dataLayer au format GA4 Enhanced Ecommerce, donc toute balise construite là-bas les reçoit. Vous préférez éviter GTM ? Activez la plateforme GA4, saisissez votre Measurement ID, et le module charge gtag.js puis envoie les événements directement à Analytics.

Chaque plateforme est activée séparément, donc faire tourner GTM et GA4 ensemble est possible : beaucoup de boutiques utilisent GTM pour les tags et triggers personnalisés pendant que GA4 direct gère le tracking natif des événements. L’erreur fréquente est le double comptage, si GTM déclenche déjà une balise GA4 depuis le dataLayer, n’activez pas aussi la plateforme GA4 direct pour la même propriété, sinon chaque événement sera enregistré deux fois. Choisissez un seul chemin vers GA4 et tenez-vous-y.

Dans le module, ce sont des adaptateurs séparés avec des champs requis séparés : GTM a besoin d’un CONTAINER_ID, tandis que GA4 direct a besoin d’un MEASUREMENT_ID. L’interrupteur principal de tracking doit être activé d’abord ; si le tracking est désactivé, ou si une plateforme est active mais sans son ID requis, les scripts front-office de cette plateforme ne sont pas injectés.

GTM route: enable GTM + CONTAINER_ID = GTM-XXXXXXX; create GA4 tags inside Tag Manager from dataLayer events.
Voie directe : activez GA4 et définissez MEASUREMENT_ID = G-XXXXXXXXXX ; n’intégrez pas GTM au parcours GA4.

GA4 direct possède aussi des réglages optionnels que GTM n’utilise pas de la même façon : anonymisation IP, suivi user ID pour clients connectés, et API secret pour le renvoi côté serveur d’achats manqués. GTM est meilleur quand vous voulez qu’un conteneur contrôle plusieurs vendors ; GA4 direct est plus propre si vous voulez seulement que le module envoie les événements ecommerce GA4 standard sans construire de tags dans GTM.

Cela fait partie de Marketing Revolution, qui unifie le tracking pour Google, Meta et plus depuis un seul endroit.

Nous proposons actuellement plus de 150 modules, regroupés en domaines comme le SEO et le trafic, les conversions et les ventes, le checkout et l'expérience client. Le catalogue s'étoffe à mesure que nous trouvons de nouveaux problèmes à résoudre pour les marchands.

Parcourez l'ensemble de l'offre dans notre catalogue de modules.

Oui. Chaque achat de module inclut l'installation gratuite par notre équipe. Après votre commande, ouvrez un ticket de support avec les accès à votre boutique : nous installons et configurons le module pour vous, vous évitant toute la mise en place.

Voir notre politique de support pour le détail.

La plupart oui, le multiboutique PrestaShop s'active module par module, et la profondeur du support varie. La réponse honnête est donc : généralement oui, mais vérifiez avant de compter dessus.

Ce que nous pouvons dire concrètement de nos modules dans un PrestaShop multiboutique :

• Réglages par boutique. Les modules qui stockent une configuration le font avec le contexte id_shop / id_shop_group, donc chaque boutique garde sa propre configuration et respecte le sélecteur multiboutique du back-office.
• Contenus par boutique, tout ce qui crée des lignes en base (entrées FAQ, règles de sitemap, blocs personnalisés) est rattaché à la boutique active.
• Templates par boutique, les templates front-office se surchargent dans themes/<theme-boutique>/modules/<module>/, comme les templates du cœur.

Les modules qui travaillent étroitement avec le cœur, comme SEO Revolution et Performance Revolution, sont développés et exploités en environnement multiboutique. Les petits modules utilitaires fonctionnent en général aussi, mais n'exposent pas toujours chaque option dans le sélecteur. Si le multiboutique est essentiel pour vous, vérifiez la page produit ou demandez-nous avant.

Si vous craignez qu'un module de suivi rende votre boutique PrestaShop lente, voici la réponse honnête : Marketing Revolution est plus léger que d'exécuter un module distinct par plateforme. Au lieu de 8 à 15 SDK JavaScript séparés, ajoutant chacun ses propres requêtes DOM et écouteurs d'événements, vous obtenez une seule couche d'événements partagée par toutes les plateformes.

Il charge aussi gtag.js une seule fois et le partage entre GA4 et Google Ads quand les deux sont actifs, vous ne payez donc pas ce script en double. La limite honnête : chaque plateforme activée ajoute tout de même son propre script SDK, activer les 15 représente donc plus de JavaScript qu'en activer 3. N'activez que les plateformes que vous utilisez vraiment et la charge reste faible.

Si la vitesse est votre vraie préoccupation, associez-le à Performance Revolution, qui gère directement le cache et l'optimisation du front-office.

Oui. Nous proposons des boutiques de démonstration en ligne où vous pouvez essayer le front-office et le back-office de n'importe quel module, avec toutes les fonctionnalités et sans inscription. C'est le moyen le plus rapide de voir comment un module se comporte avant de dépenser quoi que ce soit. Découvrez-les sur notre page de démonstration.

Meta Conversions API (CAPI) envoie les événements d'achat à Meta depuis votre serveur au lieu de dépendre uniquement du navigateur du visiteur. Dans Marketing Revolution, l'expéditeur Meta côté serveur utilise votre Pixel ID et votre token d'accès CAPI, puis poste les événements d'achat vers la Graph API de Meta. L'objectif est de récupérer les achats que le tracking navigateur peut manquer à cause des bloqueurs de publicité, du timing du consentement, des redirections de checkout ou d'un client qui ferme la page de confirmation trop tôt.

CAPI fonctionne avec le renvoi des achats manqués. Le module journalise le tracking d'achat, la tâche de renvoi planifiée s'exécute toutes les heures, regarde la fenêtre configurée et envoie les commandes manquées via les API côté serveur configurées. Pour Meta, le payload inclut l'événement Purchase, la devise, la valeur, le contenu des produits, l'ID de commande et les données d'enhanced matching. E-mail, téléphone, prénom, nom, ville, code postal, État et pays sont normalisés et hashés en SHA-256 avant l'envoi ; l'IP client et l'user agent sont envoyés non hashés, car Meta attend ces champs sous cette forme.

Minimal CAPI checklist:
1. Meta Pixel ID in the Meta platform settings.
2. Meta CAPI access token in the Meta platform settings.
3. Optional Test Event Code while validating in Meta Events Manager.
4. Activez Resend Missed Purchases si vous souhaitez exécuter la tâche de récupération horaire côté serveur.
5. Laissez également le pixel du navigateur activé, car CAPI complète le suivi frontend normal au lieu de le remplacer.

Event flow:
Customer reaches order confirmation -> browser pixel tries to send Purchase.
Marketing Revolution logs the purchase tracking attempt.
Hourly cron task -> ResendMissedPurchases finds completed orders not logged as tracked inside the lookback window.
MetaConversionsApi::sendPurchase() -> POST /{pixel_id}/events with Purchase, value, currency, contents, order_id and hashed customer data.
Meta Events Manager -> use the Test Event Code first, then remove it for live traffic.

CAPI vous est utile si les publicités Meta comptent pour votre reporting ou votre optimisation. Si vous ne faites pas de campagnes Meta, c'est optionnel. Si vous faites des campagnes Meta, c'est l'une des améliorations de tracking les plus efficaces, car elle réduit l'écart entre les vraies commandes PrestaShop et ce que Meta peut attribuer.

Oui, nous prenons en charge le développement de modules PrestaShop sur mesure lorsqu'aucun de nos modules existants ne couvre votre besoin. Nous gérons nous-mêmes des boutiques et examinons chaque demande comme le ferait un marchand : quel problème elle résout et si la réalisation en vaut la peine.

Dites-nous ce que vous cherchez à faire, envoyez-nous les détails et nous vous donnerons une évaluation honnête de la faisabilité, du délai et du coût avant tout démarrage. Si un module sur mesure n'est pas la bonne voie, ou si l'un de nos modules existants fait déjà le travail, nous vous le dirons. Toutes les demandes ne sont pas réalisables, mais vous le saurez toujours d'emblée.

Nous assumons chaque module que nous vendons. Si un module pose un problème sur votre boutique, notre équipe le corrige gratuitement, et si nous ne pouvons pas le résoudre, vous êtes intégralement remboursé. Vous ne restez jamais bloqué avec du code qui ne tourne pas chez vous.

Lorsque vous signalez un souci, envoyez-nous votre version de PrestaShop, la version du module et l'erreur exacte ou une capture d'écran pour que nous reproduisions vite le cas. La plupart du temps, il s'agit d'un conflit avec le thème ou un module tiers, que nous vous aidons à isoler. Pour vos vérifications préalables, voyez notre guide de dépannage PrestaShop.

Il récupère les achats manqués par le tracking côté navigateur : le module journalise les événements purchase qu'il capture, et le cron horaire compare les commandes PrestaShop valides récentes à ce log pour repérer toute commande qui n'a jamais produit d'événement purchase. Chaque commande manquée est ensuite renvoyée côté serveur.

Les renvois partent via le GA4 Measurement Protocol et/ou la Meta Conversions API. Cela ne s'exécute que si vous avez saisi les identifiants côté serveur - un API secret GA4 et/ou un token d'accès Meta ; sans eux, il n'y a aucun canal d'envoi et le job saute. Vous choisissez la fenêtre de recherche : 6, 12, 24, 48 ou 72 heures.

La fonctionnalité est désactivée par défaut. Pour l'utiliser, activez le renvoi des achats manqués, gardez le logging purchase activé, et assurez-vous que le cron du module tourne ; le module enregistre une tâche horaire resend_missed_purchases. Le lookback par défaut est de 24 heures, et la requête sélectionne les commandes PrestaShop valides dans cette fenêtre qui n'ont aucune ligne purchase dans le log de tracking du module.

• Renvoi GA4 : nécessite le GA4 Measurement ID et l'API secret. Le module envoie l'achat via Measurement Protocol.
• Renvoi Meta : nécessite le Meta Pixel ID et le token d'accès Conversions API. Un Meta test event code peut être utilisé pendant les tests.
• Logging : après un renvoi réussi, le cron écrit une entrée de log purchase avec source cron_resend, de sorte que les commandes récupérées sont enregistrées et ne sont pas renvoyées à nouveau.

Un détail utile : ce n'est pas un replay magique de la session navigateur exacte du client. Pour une commande manquée, le module reconstruit le payload de commande depuis les données de commande PrestaShop et l'envoie côté serveur. Cela reste précieux pour l'attribution et le reporting d'achat, même si les détails strictement navigateur qui n'ont jamais été capturés peuvent ne pas exister pour le renvoi.

Le resender est intégré à Marketing Revolution, notre module de tracking tout-en-un.

Notre boutique et les interfaces d'administration des modules sont disponibles en anglais, allemand, français, polonais, italien et espagnol. L'affichage côté client de la plupart des modules suit les langues que vous avez configurées dans votre boutique PrestaShop, le texte montré aux acheteurs provient de vos propres traductions, pas de chaînes codées en dur.

En savoir plus sur nous : à propos de mypresta.rocks.

Oui. Chaque achat de module inclut trois mois de support et de mises à jour gratuits via notre système de tickets, et le support peut être prolongé avec des forfaits payants. Les jours ouvrés, nous répondons généralement en quelques heures, que vous ayez besoin d'aide pour la configuration, le dépannage ou une question de personnalisation. Vos tickets sont traités par des développeurs PrestaShop en activité, nous gérons nous-mêmes des boutiques, et non par un support externalisé.

Pour tous les détails, consultez notre politique de support.

Pour personnaliser un thème en toute sécurité, l'approche la plus propre sous PrestaShop est le thème enfant, vos changements vivent dans l'enfant et survivent aux mises à jour du thème parent. Notre générateur de thème enfant gratuit le crée pour vous.

Il génère un thème enfant prêt à l'emploi pour ces thèmes parents :

• Classic, le thème PrestaShop par défaut.
• Hummingbird, le thème léger de PrestaShop 8/9.
• Warehouse, le thème parent Warehouse, très répandu.

L'enfant généré embarque un config/theme.yml qui pointe vers le parent choisi et active use_parent_assets, si bien que l'enfant hérite d'origine du style du parent. Il crée aussi un custom.css et un custom.js pour vos retouches, plus des surcharges de templates optionnelles quand vous devez modifier le balisage du parent.

Placez votre CSS, votre JavaScript et vos modifications de templates dans le thème enfant : une mise à jour ultérieure du parent ne les écrasera pas.

Oui. FAQ Manager vous donne le contrôle de l’indexation de votre FAQ au lieu de laisser les moteurs de recherche explorer chaque question mince et chaque page de recherche - vous décidez donc exactement quelles réponses méritent d’être indexées.

L’indexation est décidée par type de page, et vous gardez la main :

• Page d’accueil FAQ - indexable par défaut (index/follow), car c’est votre vrai point d’entrée.
• Pages de question individuelles - opt-in. Vous activez un interrupteur principal, puis vous marquez les questions précises qui méritent l’indexation. Seules celles-ci utilisent index/follow et peuvent être ajoutées au sitemap XML ; les autres restent en dehors.
• Pages de résultats de recherche - toujours noindex, afin de ne pas polluer l’index avec des URL de recherche interne.
• Pages de catégorie et de tag - les pages de catégorie sont optionnellement indexables et peuvent être incluses dans le sitemap quand la politique de sitemap catégorie et l’indicateur indexable de la catégorie l’autorisent. Les pages de tag restent exclues du sitemap.

Il y a aussi des données structurées. Le module peut émettre un schema FAQPage sur une page de question ; cette sortie est configurable et désactivée par défaut, donc vous l’activez seulement si un consommateur de données structurées en a besoin. Le vrai sujet ici est le contrôle d’indexation - schema et balises robots servent à orienter ce que les moteurs de recherche explorent, pas à garantir un résultat.

Voir FAQ Manager pour l’ensemble complet des fonctionnalités.

Les valeurs par défaut sont volontairement strictes : le schema est désactivé par défaut, les pages de question individuelles ne sont pas indexables par défaut, le hub FAQ est indexable, les pages de catégorie et de tag ne sont pas indexables par défaut, les pages de recherche ne sont jamais indexables, et l’inclusion sitemap n’est activée que pour les types de pages autorisés par la politique SEO. Cela empêche une nouvelle FAQ d’inonder l’index avant que vous ayez revu quelles réponses méritent une visibilité de recherche autonome.

Pour le schema de question individuelle, le contrôleur ne construit le JSON-LD FAQPage que lorsque la question est active, publiée, indexable, possède un texte de question et de réponse non vide, et que la politique schema correspondante l’autorise. Le schema du hub est également limité : il sélectionne un petit ensemble de questions actives, publiées et indexables, triées par signaux d’utilité et de visibilité, au lieu de déverser chaque brouillon ou réponse de faible valeur dans les données structurées.

Le hook sitemap suit la même discipline. Il peut ajouter l’URL du hub, les URL de catégorie actives et indexables lorsque la politique de sitemap catégorie les autorise, et les URL de questions actives, publiées, avec slug et marquées indexables. Un brouillon, un aperçu, une question noindex ou non publiée doit donc rester hors du sitemap même s’il existe dans les tables FAQ.

La configuration admin avertit aussi que Google a réduit l’affichage des rich results FAQ, donc le schema FAQ ne doit pas être traité comme un interrupteur magique de classement. La valeur SEO pratique est le contrôle éditorial : publiez des réponses utiles, indexez celles qui peuvent se tenir seules, et gardez les pages de recherche, tags minces et questions non relues hors de l’index.

Oui. Marketing Revolution inclut un bridge Consent Mode v2 qui relie les bannières cookies prises en charge aux signaux de consentement Google. Il est conçu pour détecter automatiquement quatre plateformes de consentement : MPR Cookies Revolution, Cookiebot, toute bannière IAB TCF v2 et OneTrust.

Lorsque le bridge s’exécute avec window.mprMarketingConfig.consentMode disponible, il définit le consentement Google par défaut pour analytics et ads selon les valeurs par défaut configurées, généralement denied pour une configuration de type UE, puis met à jour le consentement lorsque le visiteur accepte les catégories pertinentes. Le bridge transmet l’état de consentement à Google ; il ne bloque pas les scripts tiers par lui-même. Le blocage des scripts reste le rôle de la bannière cookie ou du CMP.

Il existe une réserve importante d’ordre d’exécution dans le code actuel. Le bridge quitte immédiatement si window.mprMarketingConfig n’est pas déjà défini, tandis que le template header imprime les scripts d’init de plateforme et les scripts d’événements de page avant de définir cet objet de configuration. Pour cette raison, la build actuelle ne garantit pas que le consentement denied/default soit appliqué avant l’exécution des tags Google ou événements de page. Pour un séquencement strict de Consent Mode, vérifiez l’ordre rendu réel dans votre thème ou ajustez le module afin que la config et la commande de consentement par défaut soient présentes avant tout script Google init/event.

Consent Mode est désactivé par défaut dans les réglages du module. Lorsqu’il est activé et que le bridge reçoit l’objet config à temps, les valeurs par défaut du module sont denied pour analytics storage et denied pour ads storage, sauf si vous les modifiez volontairement.

Le bridge envoie les champs de consentement v2 de Google : analytics_storage, ad_storage, ad_user_data et ad_personalization. Il laisse aussi functionality_storage et security_storage granted, et utilise une fenêtre wait_for_update de 500 millisecondes pour qu’une mise à jour CMP puisse arriver avant que Google traite les hits.

Default EU-style setup: Consent Mode enabled; analytics default = denied; ads default = denied; CMP accepts analytics + marketing; bridge updates Google consent to granted.

Si votre CMP ne fait pas partie des intégrations prises en charge, vous avez besoin d’un petit bridge personnalisé qui appelle le même chemin de mise à jour quand le visiteur change son consentement. Sans cela, Google gardera le dernier état de consentement qui lui a été envoyé, même si l’interface de la bannière a changé.

Marketing Revolution gère la partie tracking ; pour la bannière elle-même, consultez Cookies Revolution, notre module de consentement GDPR.

Non. Nos modules sont des logiciels commerciaux sous licence propriétaire. Vous recevez néanmoins le code source PHP complet : rien n'est obfusqué, chiffré ni protégé par ionCube. Vous pouvez ouvrir chaque fichier, vos développeurs peuvent l'auditer pour la sécurité ou la compatibilité, et vous pouvez adapter certaines parties aux spécificités de votre boutique.

Ce que nos conditions de licence autorisent : installer sur les domaines couverts par votre licence, personnaliser overrides et templates pour votre propre usage, et continuer à utiliser la version achetée sans limite de durée. Ce qui n'est pas autorisé : redistribuer, revendre, sous-licencier ou republier le code, le forker comme produit dérivé, ou supprimer la mention de copyright d'origine.

Le code ouvert a un intérêt concret : chaque évolution de PrestaShop ou de PHP reste visible et corrigeable, les audits de sécurité sont possibles, et vous ne restez jamais bloqué par un fournisseur injoignable.

Vous pouvez, mais ne laissez jamais deux modules injecter le même tag Google Analytics, cela double chaque événement et gonfle vos rapports. Choisissez un module par plateforme : si vous activez GA4 dans Marketing Revolution, désactivez ou désinstallez d’abord tout autre module GA4, et inversement.

Si vous voulez plutôt un module Google Analytics PrestaShop dédié et unique, notre module autonome Google Analytics GA4 gère GA4 seul (navigateur plus Measurement Protocol côté serveur et Consent Mode v2). Le faire tourner côte à côte avec un autre pack GA est correct uniquement si un seul d’entre eux envoie GA4. L’autre doit garder GA4 désactivé.

Il est aussi possible de séparer les plateformes : utilisez Marketing Revolution pour, par exemple, TikTok et Pinterest pendant qu’un module séparé possède GA4. La règle est un tag par plateforme, pas un module par boutique.

Marketing Revolution est construit autour d’un interrupteur principal de tracking plus des adaptateurs propres à chaque plateforme. Cela signifie qu’une configuration mixte sûre est possible : par exemple, gardez votre module GA4 existant actif, laissez l’adaptateur GA4 désactivé dans Marketing Revolution, et activez seulement TikTok, Pinterest, Reddit ou Meta dans Marketing Revolution. La configuration front-office expose les slugs de plateformes actives, donc Debug Mode permet de voir facilement ce que le module considère actif.

• Dangereux : un autre module charge G-XXXXXXXXXX et Marketing Revolution GA4 direct charge aussi le même measurement ID.
• Généralement sûr : Marketing Revolution pousse des événements GTM dataLayer tandis qu’un module GA4 séparé possède GA4 direct, tant que le conteneur GTM ne déclenche pas aussi des tags ecommerce GA4 pour la même propriété.
• Séparation sûre : le module GA4 existant possède GA4 ; Marketing Revolution possède Meta, TikTok, Pinterest, Snapchat, Reddit ou d’autres plateformes non-GA.

Pendant les tests, ouvrez la source de page ou le panneau réseau du navigateur et cherchez le GA4 Measurement ID et le GTM container ID. Voir un propriétaire intentionnel est normal ; voir la même propriété GA4 chargée depuis plusieurs modules est le signal d’alerte.

Performance Revolution stocke des données techniques de monitoring sur votre boutique, mais toutes les tables de monitoring n’ont pas le même profil de confidentialité. Les lignes RUM portent sur les temps de chargement, l’URL, la classe d’appareil et le contexte boutique plutôt que sur des champs de profil client ; le journal des requêtes lentes est différent, car il stocke le texte SQL brut et le contexte de stack trace. Traitez-le donc comme une donnée de diagnostic potentiellement sensible si vos requêtes contiennent des identifiants client, panier ou commande.

Concrètement, le module conserve ces tables :

• Métriques de performance - mesures chronométrées avec un type de métrique, une valeur et un contexte JSON, utilisées pour visualiser le comportement de la boutique dans le temps.
• Métriques agrégées - valeurs regroupées par heure, jour, semaine et mois, avec somme, moyenne, minimum, maximum et compteur, afin que les tableaux de bord restent utilisables sur de longues périodes.
• Requêtes lentes - hash de requête, texte SQL, temps d’exécution, contrôleur, stack trace, nombre d’occurrences et horodatages de première/dernière détection. Le schéma peut contenir des emplacements supplémentaires, mais le chemin du profiler enregistre ces champs plutôt que les lignes examinées ou envoyées.
• Real-user monitoring (RUM) - données de timing navigateur issues de visites échantillonnées : TTFB, FCP, LCP, CLS, FID et INP, plus les champs de timing DOM, un résumé resource-timing, l’URL, le type d’appareil et la boutique.
• Agrégats RUM - nombres d’échantillons et moyennes par heure, URL et appareil pour les métriques RUM. Le schéma d’agrégat inclut une colonne p75_lcp, mais la requête d’agrégation actuelle ne la renseigne pas.

Erreur fréquente : considérer toutes les données de monitoring comme également peu risquées. Le RUM sert au diagnostic timing/appareil, mais les lignes de requêtes lentes peuvent exposer tout ce qui était présent dans l’instruction SQL. Limitez l’accès à ces diagnostics comme vous limiteriez l’accès aux logs de base de données.

Les valeurs par défaut sont volontairement prudentes. Le cache de fragments est activé avec un TTL de 3600 secondes, le cache de requêtes est activé, les métriques sont activées, le seuil de requête lente est par défaut 0.1 seconde, la rétention des métriques est par défaut 30 jours, le profiling est désactivé par défaut, et l’échantillonnage RUM vaut par défaut 0.1, soit environ 10 % des pages vues éligibles. Sur une boutique à faible trafic, ce taux peut rendre les graphiques RUM clairsemés jusqu’à ce qu’assez de visiteurs aient été mesurés.

Le script front collecte les timings navigateur avec les Performance APIs, puis les envoie avec sendBeacon quand c’est disponible, avec repli sur XHR. Le contrôleur RUM accepte des données JSON en POST, vérifie qu’une URL existe, stocke les champs timing/resource nettoyés, et renvoie une réponse 204 avec des en-têtes no-store/noindex. Le contrôleur supprime aussi les en-têtes Set-Cookie, donc l’endpoint beacon lui-même ne crée pas de cookies client.

Pour le nettoyage, le profiler de requêtes enregistre les SQL lents par hash et met à jour le nombre d’occurrences et la dernière date vue quand la même requête revient. Les données RUM brutes peuvent être agrégées en résumés horaires, puis les anciennes lignes brutes sont supprimées après agrégation, ce qui garde les tableaux de bord long terme utilisables sans stocker chaque beacon individuel indéfiniment. La limite importante est que l’agrégation RUM actuelle stocke des moyennes et des compteurs, pas un LCP au 75e percentile calculé.

Par défaut, le module envoie l’ID produit PrestaShop comme item_id dans chaque événement de tracking. Vous pouvez le changer dans le réglage Product Identifier pour la référence produit, le code-barres EAN-13 ou l’UPC. Ce que vous choisissez est utilisé de manière cohérente sur les vues produit, événements panier et événement purchase.

C’est surtout important pour Google Merchant Center et Shopping : si votre flux produit identifie les articles par, par exemple, EAN, vos événements de tracking doivent envoyer le même identifiant afin que les conversions correspondent aux bons produits dans votre flux. Garde-fou utile, si un produit n’a pas de valeur dans le champ choisi (référence ou code-barres vide), le module se rabat sur l’ID produit pour cet article, donc les événements ne partent jamais avec un ID vide. Définissez l’identifiant pour qu’il corresponde à votre flux, afin que vos événements utilisent le même format d’identifiant que votre flux produit.

Le même extracteur est utilisé pour les pages produit, impressions catégorie/liste, produits panier et produits de commande, donc le réglage affecte les événements navigateur et les reconstructions purchase côté serveur. Les valeurs par défaut liées méritent aussi vérification : les prix sont envoyés TTC par défaut, la profondeur de catégorie vaut par défaut 4, et la langue de données vaut par défaut la langue courante de la boutique.

Example: PRODUCT_ID_FORMAT = ean13; product has EAN-13 = 5901234123457; item_id = 5901234123457.
Fallback example: PRODUCT_ID_FORMAT = reference; product reference is empty; item_id = PrestaShop product ID.

Pour les variantes produit, le payload peut inclure une valeur item_variant lorsque des données de combinaison sont disponibles. Les champs de catégorie sont construits depuis l’arbre de catégories du produit jusqu’à la profondeur configurée, en excluant les catégories root et home, ce qui garde les rapports ecommerce plus propres.

Cela fait partie de Marketing Revolution, notre module de tracking tout-en-un.

Non, chaque licence couvre une boutique de production (un domaine de production), y compris les environnements de staging et de développement de ce domaine. Si vous exploitez plusieurs boutiques en ligne sur des domaines distincts, il vous faut une licence distincte pour chacune.

Le support fonctionne de la même façon : il est affecté à une seule boutique, une formule de support ne couvre donc pas tout un parc. Vous gérez plusieurs boutiques ? Nous proposons des remises groupées et des offres pack qui réduisent le coût par boutique, voir nos Packs & Bundles.

Pour la vue d'ensemble, ce qu'une licence couvre, comment fonctionne l'activation et comment le support se compte par boutique, voir Fonctionnement des licences, de l'activation et du support.

Chaque module passe par des tests de compatibilité sur les versions de PrestaShop que nous prenons en charge avant sa publication. Nous testons avec plusieurs versions de PHP, MySQL et MariaDB, ainsi que les thèmes populaires dont les thèmes par défaut Classic et Hummingbird. Cela dit, nous ne pouvons pas tester chaque combinaison possible de modules, thèmes et configurations serveur, c'est pourquoi chaque achat inclut un essai de 30 jours satisfait ou remboursé, pour que vous puissiez le vérifier sur votre propre boutique sans risque.

En savoir plus sur nos standards de technologie et de qualité.

Nous évitons les overrides PrestaShop dès que possible. La quasi-totalité de nos modules étend la plateforme via des hooks (points d'événement du back-office et du front-office) et des services Symfony, pas en déposant des fichiers dans override/classes ou override/controllers.

C'est important parce que les overrides sont la première cause des conflits "le module A casse le module B" : une seule classe peut être overridée à la fois, et un override oublié laissé par un module désinstallé peut casser une boutique pendant des mois. Ils empêchent aussi les mises à jour en un clic du cœur, car le processus refuse de toucher à une classe overridée. Sans override, vous pouvez mettre à jour PrestaShop et ajouter des modules sans ce risque.

Dans les rares cas où un override est vraiment la seule option, nous le documentons sur la page produit, le limitons au strict minimum et le rendons proprement supprimable à la désinstallation. Voir notre guide des hooks pour le raisonnement.

Non. Product Canonical Manager ne génère pas de redirections 301. Il réécrit plutôt le head HTML de vos pages front-office : il remplace ou ajoute la balise canonical, définit les robots noindex/nofollow là où vous le choisissez, régénère les balises hreflang à partir de vos langues actives, et nettoie les conventions canonical (suppression de paramètres, minuscules forcées ou slash final). L’URL demandée par le visiteur reste la même.

C’est important, car les balises canonical et les redirections 301 résolvent des problèmes différents. Une balise canonical indique à Google quelle version indexer tout en laissant chaque variante accessible ; une 301 déplace réellement une URL et c’est le bon outil quand une adresse a changé définitivement. Une erreur fréquente consiste à utiliser des redirections pour corriger des URL dupliquées avec paramètres (tri, filtres, tags de tracking) alors qu’un canonical est plus propre et garde ces pages utilisables par les acheteurs. Product Canonical Manager modifie uniquement les balises head et laisse l’URL demandée inchangée.

Dans le code, le module fonctionne via hookActionOutputHTMLBefore. Ce hook reçoit le HTML terminé, vérifie qu’une section <head> existe, résout l’entité de page courante, puis modifie les balises canonical, robots et hreflang avant l’envoi de la réponse. Il n’y a dans ce chemin ni réponse de redirection, ni changement de statut HTTP, ni réécriture de l’URL de requête.

Les règles sont stockées par type d’entité et ID d’entité, avec périmètre boutique, priorité, indicateur actif et URL canonical personnalisée par langue. Les types d’entité pris en charge sont produits, catégories, pages CMS, fabricants et fournisseurs. Une règle peut cibler une entité précise ou utiliser l’ID d’entité 0 comme règle globale, ce qui permet de créer un fallback large puis de le remplacer par une règle spécifique de priorité plus élevée.

L’action canonical compte aussi :

• override remplace un canonical existant par l’URL calculée ou personnalisée.
• custom utilise l’URL personnalisée stockée pour la langue.
• add missing insère un canonical seulement quand la page n’en a aucun.

La suppression de paramètres s’applique à l’URL canonical, pas à l’URL visible de l’acheteur. Les paramètres supprimés par défaut incluent les valeurs de tracking courantes comme utm_source, utm_medium, utm_campaign, fbclid, gclid et msclkid. C’est pourquoi le module est utile pour nettoyer les URL dupliquées sans casser les URL de filtre, de tri ou de campagne que les clients peuvent encore utiliser.

Oui. Marketing Revolution est compatible multistore sur les configurations multistore PrestaShop. Chaque événement de suivi est enregistré avec l'ID de la boutique d'origine, et les requêtes de hiérarchie de catégories respectent le contexte de la boutique active, de sorte que vos données restent attribuées à la bonne boutique.

Une limite honnête à connaître d'emblée : la configuration des plateformes, vos identifiants de mesure GA4, vos IDs de pixel Meta et autres, vos clés API. Est actuellement stockée globalement, pas par boutique. Concrètement :

• Si vos boutiques partagent les mêmes comptes publicitaires, c'est exactement ce qu'il faut, réglage unique, toutes les boutiques remontent vers les mêmes propriétés.
• Si chaque boutique a besoin de sa propre propriété GA4 ou de son propre pixel, le module applique un seul jeu d'IDs à tout le groupe ; vous configurez alors pour votre boutique principale.

Si des IDs de pixel distincts par boutique sont indispensables, décrivez-nous votre groupe de boutiques avant l'achat et nous confirmerons la compatibilité. Tous les détails sur Marketing Revolution.

Réponse honnête : nous ne pouvons pas juger le code d'un autre développeur, donc nous ne prétendrons pas qu'un module du marketplace PrestaShop Addons est moins bon que le nôtre. Nous pouvons seulement vous expliquer comment nous travaillons, à vous de décider.

• Vous parlez aux personnes qui ont écrit le code. Le support vient des développeurs, pas d'un guichet de tickets séparé qui revend le module de quelqu'un d'autre.
• Nous ne faisons que du PrestaShop. Ce n'est pas une plateforme parmi d'autres : chaque module que nous vendons, nous l'utilisons et le maintenons aussi nous-mêmes.
• Vous pouvez essayer avant de vous engager. Nous proposons un essai de 30 jours pour comparer les deux modules dans votre propre boutique, sur vos propres données, plutôt que de deviner depuis une fiche.

Le vrai conseil : installez les deux sur une copie de préproduction et jugez-les sur votre catalogue. Une capture d'écran sur le marketplace ne dit pas grand-chose.

En savoir plus sur notre façon de concevoir et de suivre nos modules : mypresta.rocks et notre approche technique.

Oui. Checkout Revolution inclut un workflow de demande de devis (RFQ) au-dessus du checkout, ce dont beaucoup de boutiques B2B et de produits sur mesure ont besoin.

Voici ce qu’il fait, concrètement dans le module :

• Les clients demandent un devis au lieu de payer immédiatement, ou en parallèle. Vous choisissez les champs à collecter, notamment téléphone, société, référence projet et pièce jointe, et activez ou désactivez chacun d’eux.
• Votre équipe gère chaque devis par statut : pending, sent, negotiating, accepted, rejected, expired, converted et cancelled. Les statuts sont codés par couleur, peuvent être marqués comme finaux, et peuvent envoyer automatiquement un email au client quand vous y déplacez le devis.
• La négociation de prix optionnelle peut être conditionnée à une quantité minimale ou à une valeur minimale de panier, afin que les petits paniers passent par le checkout normal tandis que les grosses commandes ouvrent un fil de négociation avec échanges de messages.
• Les devis acceptés peuvent devenir une vraie commande. Le personnel peut convertir un devis depuis le back-office, et le module dispose aussi d’une gestion de liens de paiement tokenisés avec expiration pour que le client paie en ligne le devis accepté. Un PDF du devis est généré pour les archives du client.

Tout le workflow vit dans le même module que le checkout, donc le devis est basé sur votre catalogue PrestaShop, votre client, votre devise et votre contexte fiscal, plutôt que sur un tableur séparé. C’est une fonctionnalité payante de Checkout Revolution.

La validité par défaut d’un devis est de 30 jours et celle d’un lien de paiement de 48 heures. Les références de devis sont générées depuis un format configurable, avec le modèle par défaut QUO-{YEAR}-{ID:5}. Les liens de paiement utilisent un token généré et ne sont acceptés que tant que le token stocké existe et que la date d’expiration est encore dans le futur.

Les demandes de devis invité sont contrôlées séparément des demandes client normales. Le contrôleur de demande de devis autorise techniquement l’accès invité, mais la configuration par défaut est quote_allow_guest = false ; si les devis invités sont désactivés et que le visiteur n’est pas connecté, il est redirigé vers l’authentification. Quand les devis invités sont autorisés, le formulaire collecte l’email, le prénom et le nom de l’invité.

Côté admin, le devis reste modifiable jusqu’à ce qu’il soit converti, expiré ou déplacé dans un statut final. Le personnel peut ajouter des produits du catalogue, des déclinaisons ou des lignes libres personnalisées, ajuster quantité, prix et remises, ajouter des remises au niveau du devis, envoyer des messages, changer le statut et générer le lien de paiement. La conversion directe crée un nouveau panier PrestaShop, ajoute les articles du devis liés à des produits, et valide une commande en attente de paiement avec ps_wirepayment quand ce module est disponible ; sinon, elle se rabat sur l’instance du module Checkout Revolution. L’état de commande vient de PS_OS_BANKWIRE, avec repli sur PS_OS_CHEQUE. C’est un chemin de conversion codé en dur, pas un sélecteur de module de paiement configurable spécifiquement pour les devis.

Cela rend le flux RFQ pratique pour les tarifs professionnels, commandes projet, quantités personnalisées et commandes nécessitant un document joint. Le point d’attention clé pour le marchand est la discipline des statuts : si vous marquez un statut comme final, le devis cesse d’être modifiable ou convertible dans le workflow normal.

Activez Debug Mode dans les réglages du module - il imprime les événements dans la console de votre navigateur au moment où ils se déclenchent, tagués [MPR Marketing], afin que vous puissiez ouvrir les outils développeur et observer en temps réel les événements add-to-cart, checkout et autres.

Pour les achats, utilisez le Debug Inspector intégré : saisissez une commande et il reconstruit le payload order/debug courant depuis les extracteurs du module, avec le log de commande et le contexte de configuration. Cela vous permet de valider les valeurs, la devise et les identifiants produit, mais ce n’est pas le JSON historique exact propre à chaque plateforme qui a été transmis précédemment. Vérifiez ensuite côté réception - pour Meta, renseignez le Test Event Code et inspectez Meta Events Manager → Test Events ; pour GA4, regardez Realtime ou DebugView dans Google Analytics. L’erreur fréquente est de laisser Debug Mode actif en production - désactivez-le une fois tout confirmé, car il logue dans la console de chaque visiteur.

Le Debug Inspector est basé sur une commande, donc il est idéal pour vérifier les données d’achat : transaction ID, référence commande, valeur, taxe, livraison, devise, coupon et articles. Il montre aussi la configuration du module comme le format d’identifiant produit, l’affichage des prix, la profondeur de catégorie, le purchase logging et l’état Debug Mode, ce qui aide à repérer les écarts entre votre flux et vos événements de tracking.

Pour les événements navigateur, testez le parcours utilisateur exact qui vous intéresse. Add-to-cart est détecté depuis l’événement updateCart de PrestaShop sur les boutiques récentes, avec un fallback de clic PrestaShop 1.6. Les événements d’étapes checkout dépendent d’un markup checkout compatible, donc utilisez la console navigateur et le debugger réseau/tag pour confirmer add_shipping_info et add_payment_info séparément de purchase.

• GTM : vérifiez que dataLayer reçoit le nom event attendu et l’objet ecommerce.
• GA4 direct : vérifiez Realtime ou DebugView pour le nom d’événement, la valeur, la devise et les item IDs.
• Google Ads : un événement ne se déclenche que lorsque le conversion label correspondant est configuré.
• Meta CAPI : le Test Event Code s’applique aux appels CAPI côté serveur, pas à chaque événement uniquement navigateur.

Debug Mode et l’Inspector sont intégrés à Marketing Revolution.

Oui, nous sommes une société enregistrée à Tychy, en Pologne (UE), numéro de TVA PL5492453186. Être basés dans l'UE signifie que nous respectons le RGPD, émettons des factures TVA conformes et sommes soumis aux règles européennes de protection des consommateurs. Votre achat a donc le même cadre juridique que chez tout vendeur de l'UE. Plus de détails sur notre page société basée dans l'UE.

Oui, Smart Search Revolution remplace la recherche par mot-clé intégrée au front-office de PrestaShop par un moteur AJAX en temps réel qui affiche les résultats au fil de la saisie. C'est une recherche e-commerce pour votre site conçue à cet effet : les requêtes interrogent notre propre index tokenisé au lieu de l'index par défaut, et trouvent donc ce que la recherche native ne sait pas gérer, valeurs d'attributs, mots partiels et fautes de frappe.

Ce que vous obtenez à la place de la recherche par défaut :

• Autocomplete instantané avec vignettes produit, plus des suggestions de catégories, pages CMS, fabricants et fournisseurs.
• Tolérance aux fautes (correspondance approximative), "snekers" trouve toujours "sneakers".
• Synonymes bidirectionnels par langue, pour que "pantalon" et "jean" se trouvent mutuellement.
• Mises en avant et épinglages, faire remonter des produits ou catégories précis sur certaines requêtes.
• Réécritures et redirections de requêtes, router une recherche comme "soldes" vers une URL, une catégorie, une page CMS ou un produit.
• Analytique de recherche, requêtes les plus fréquentes et un flux de résultats vides montrant ce que les visiteurs cherchent sans le trouver, pour repérer les stocks manquants.

Erreur fréquente : s'attendre à ce qu'il modifie la recherche catalogue du back-office, ce n'est pas le cas. Il s'agit de la recherche en boutique utilisée par vos clients ; la recherche admin reste inchangée. Le nombre de résultats, le minimum de caractères et le timing de debounce sont configurables.

Associez-le au filtrage à facettes des pages catégorie avec Filter Revolution.

Marketing Revolution peut suivre la progression du checkout, mais seulement lorsque le checkout expose la structure d’étapes que le module surveille.

Il y a trois éléments distincts à garder en tête. L’événement begin_checkout est construit depuis le contexte contrôleur checkout/order de PrestaShop. L’événement purchase est envoyé depuis le hook de confirmation de commande après l’existence de la commande. Les événements navigateur add_shipping_info et add_payment_info sont détectés par JavaScript lorsque l’étape checkout active change.

• Checkout PrestaShop par défaut : fonctionne généralement, car il utilise un conteneur checkout et des classes d’étape active comme les étapes livraison et paiement.
• Checkout Revolution : il utilise sa propre UI checkout en modal/sections, donc il ne faut pas supposer que Marketing Revolution verra les sélecteurs d’étapes PrestaShop par défaut sauf si un bridge/intégration personnalisée est ajouté.
• One-page checkout tiers : fonctionne seulement s’il garde un markup compatible comme #checkout ou .checkout-process avec une .checkout-step.-current active dont l’id ou le data step contient delivery/shipping/payment. Un checkout Vue/React ou OPC personnalisé avec des sélecteurs sans rapport peut encore suivre purchase, mais manquer les événements d’étape livraison et paiement.

Si les événements d’étape comptent pour GA4 ou les plateformes publicitaires, testez le checkout avec le debugger réseau/tag du navigateur après avoir choisi le module checkout. Ne vous fiez pas au seul événement purchase pour prouver que les événements d’étape livraison et paiement se déclenchent.

Le watcher navigateur exact cherche un conteneur #checkout ou .checkout-process, observe les changements, puis cherche .checkout-step.-current ou .step.-current. Si l’id de l’étape active ou data-step contient delivery ou shipping, il envoie add_shipping_info ; s’il contient payment, il envoie add_payment_info.

<section id='checkout'><div class='checkout-step -current' id='checkout-delivery-step'>...</div></section>

Cela signifie qu’un checkout peut être visuellement parfait et rester invisible pour le suivi d’étapes si son étape active n’est stockée que dans l’état JavaScript. Dans ce cas, ajoutez un markup/classes compatibles au template checkout, ou créez un petit bridge qui dispatch l’événement Marketing Revolution lorsque le checkout personnalisé change d’étape.

Oui, nous avons un programme de partenaires PrestaShop. Notre Compte Partenaire est ouvert aux agences PrestaShop, aux développeurs freelances et aux intégrateurs qui déploient nos modules régulièrement chez plusieurs clients.

Les partenaires obtiennent trois avantages concrets. D'abord, des remises sur volume sur chaque commande : plus vous achetez de licences, plus le coût unitaire baisse. Ensuite, un support prioritaire : vos tickets arrivent dans une file séparée traitée directement par les développeurs, pas par un helpdesk générique. Enfin, un tableau de bord consolidé pour gérer les licences de tous vos clients, émission, transfert, renouvellement et factures depuis un seul compte.

La candidature via le formulaire dédié prend quelques minutes. Nous l'examinons généralement sous quelques jours ouvrés. Aucun frais d'adhésion, aucun engagement mensuel minimum, et vos achats existants en licence unique restent disponibles sur le même compte après validation.

Découvrez les modules à déployer dans le catalogue complet.

Oui. Warehouse Revolution est conçu pour les boutiques à fort volume, et les chemins critiques, ajustements de stock, transferts et prélèvements, s'exécutent en SQL par lots dans des transactions plutôt que ligne par ligne. Warehouse Revolution prend en charge l'inventaire avec rapport d'écarts ainsi que des opérations de stock en masse et transactionnelles.

Ce qui continue de fonctionner quand le catalogue grandit :

• Stock multi-entrepôt avec séparation réservé/disponible par site.
• Commandes fournisseurs et réceptions par lot, pas d'aller-retour ligne par ligne dans l'interface.
• Inventaire avec rapport d'écarts, pour compter et rapprocher en une seule passe.
• Suggestions de réapprovisionnement selon les délais et la vitesse de vente.
• Gestion des expéditions avec intégration transporteur et suivi par envoi.
• Nomenclature (BOM) pour les produits composites et les kits.
• Éditeur de plan pour zones, allées et étagères, afin que les parcours de prélèvement restent cohérents.

Le même module convient à une boutique de 50 SKU comme à un catalogue bien plus grand, car le travail se fait en masse plutôt qu'un produit à la fois.

Oui. Marketing Revolution prend en charge PrestaShop 1.6.0.0 et supérieur. Sur 1.6, il y a deux limitations mineures :

• Le hook displayAfterBodyOpeningTag n'existe pas sur 1.6, donc les fallbacks noscript pour GTM, Meta et Pinterest ne sont pas rendus.
• Le suivi de l'ajout au panier se rabat sur l'interception des clics sur les boutons panier au lieu de l'événement updateCart des versions plus récentes, ce qui est un peu moins fiable sur les thèmes très personnalisés.

Tout le reste, suivi côté serveur, événements d'achat et intégrations de plateformes, se comporte de la même façon sur toutes les versions.

Abonnez-vous à notre newsletter, le formulaire d'inscription se trouve en pied de chaque page. Nous publions aussi les sorties et mises à jour sur notre blog. Pas de spam : quelques emails par mois au maximum, sur les nouveaux modules ou des mises à jour importantes.

Oui. Une campagne de remise planifiée peut viser exactement la partie de votre catalogue que vous voulez mettre en promotion. Avec Smart Dynamic & Scheduled Discounts, vous pouvez ajouter à une campagne :

• des produits individuels, voire des combinaisons spécifiques (attributs), chacun avec sa propre remise ;
• des catégories, avec une option pour inclure leurs sous-catégories afin de mettre toute une branche en promotion d’un coup ;
• des fabricants, pour lancer une promotion sur toute une marque ;
• des groupes de clients, afin qu’un prix ne soit affiché qu’à des clients grossistes ou VIP, par exemple.

Vous pouvez les mélanger dans une même campagne. Si vous n’ajoutez aucun produit, catégorie ou fabricant, la campagne s’applique simplement à tout le catalogue, ce qui est pratique pour une vente générale. L’erreur fréquente consiste à laisser le champ groupe client vide tout en attendant un prix réservé aux membres, sans restriction de groupe, tout le monde le voit. Cela vous évite de modifier les prix produit par produit avant chaque promotion.

Le modèle de campagne prend en charge plusieurs types : flash_sale, scheduled, recurring, countdown, early_bird et last_chance. Le calcul de remise prend en charge les remises en pourcentage, les réductions à montant fixe et les offres à prix fixe. Les dates, l’indicateur actif et le planning récurrent sont vérifiés avant qu’une campagne soit considérée comme active.

Le ciblage produit est plus précis qu’une simple liste de produits. Une ligne produit de campagne peut cibler un produit, un attribut produit spécifique, un type/une valeur de remise personnalisé et une limite de quantité. Le ciblage catégorie peut inclure les sous-catégories, le ciblage fabricant peut couvrir une marque entière, et le contrôle runtime des groupes client considère l’absence de groupes configurés comme tous les groupes.

Quand PrestaShop demande le prix d’un produit, le module se branche dans le calcul de prix, vérifie si la campagne est active, si le groupe client est éligible, si les limites d’utilisation sont encore disponibles et si la campagne s’applique au produit. Il soustrait ensuite la meilleure remise applicable du prix courant et bloque le résultat à zéro. Cela signifie que le prix visible produit, le prix en listing et la tarification côté panier peuvent tous venir des règles de campagne plutôt que de prix catalogue modifiés manuellement.

Utilisez priorité et cumul avec attention. La campagne possède un champ priority et un indicateur stackable, plus un suivi d’utilisation maximale. Pour des promotions propres, gardez les campagnes qui se chevauchent étroites et définissez explicitement les limites ; sinon, une campagne générale et une campagne spécifique produit peuvent toutes deux être éligibles au même article, et le module doit choisir la meilleure remise applicable.

Un conversion label indique à Google Ads quelle action vient de se produire, achat, ajout au panier, inscription. Vous créez chaque label dans Google Ads (Tools & Settings → Conversions → Tag setup), puis vous le collez dans le champ correspondant de la plateforme Google Ads du module, avec votre conversion ID AW-.

Vous avez un champ label séparé pour chaque action suivie : purchase, add to cart, begin checkout, view item, sign up, search, et un label page-view qui se déclenche à chaque chargement de page pour construire des audiences de remarketing. Seules les actions auxquelles vous donnez un label envoient une conversion. Laissez un champ vide et cette action est simplement ignorée, donc vous contrôlez exactement ce qui compte. L’erreur fréquente est de réutiliser un seul label pour tout ; utilisez un label distinct par action afin que vos rapports séparent une vente d’un ajout panier. Si vous exécutez aussi GA4 direct, le module réutilise gtag.js déjà chargé au lieu de le charger deux fois.

Le champ requis est le Google Ads conversion ID. Les labels sont optionnels par événement, mais sans label il n’y a pas d’appel de conversion Google Ads pour cette action. Purchase utilise son propre purchase label et peut inclure transaction ID, value et currency ; les événements non purchase comme view item, add to cart, begin checkout, sign up et search ne sont envoyés que lorsque leur label correspondant existe.

Google Ads conversion ID: AW-123456789
Purchase label: AbCdEfGhIjK
send_to: AW-123456789/AbCdEfGhIjK

Le label page-view est différent des labels de conversion ecommerce : il peut se déclencher à chaque chargement de page pour construire des audiences de remarketing. Si vous n’avez pas besoin de pings conversion page-view, laissez ce label vide et gardez les labels ecommerce uniquement pour les actions que vous voulez réellement compter.

Le suivi des conversions Google Ads fait partie de Marketing Revolution, notre module de tracking tout-en-un.

Nos modules les plus complets portent le suffixe Revolution, par exemple Checkout Revolution, SEO Revolution, Warehouse Revolution et Blog Revolution. Ce sont des suites complètes qui réunissent plusieurs fonctions dans un seul module, avec une configuration unifiée. Nos modules plus simples, à usage unique, portent des noms descriptifs directs comme Product Canonical Manager ou Automatic SEO Images Alt Tags. Pour réunir tous les modules Revolution, voyez le Revolution Complete Pack.

Dans le réglage « Cache Backend », vous pouvez choisir Détection automatique (recommandée), Redis, APCu ou un cache sur fichiers.

La détection automatique choisit la meilleure option disponible dans l'ordre Redis → APCu → fichiers : vous n'avez pas besoin de savoir ce que votre serveur prend en charge, si Redis et APCu sont absents, le cache sur fichiers prend le relais, et il fonctionne toujours. Choisissez un backend précis seulement pour le forcer ; s'il est indisponible, le module écrit une note et revient à la détection automatique, donc le cache n'est jamais désactivé par erreur.

Avec Redis, vous obtenez les champs de connexion attendus : hôte, port, mot de passe, numéro de base et un préfixe de clés (pratique quand plusieurs boutiques partagent une instance Redis). Réglez-les selon le service Redis de votre hébergeur.

C'est un élément de Performance Revolution. Si vous n'avez pas votre propre Redis mais voulez le gérer depuis le back-office, voyez Redis Cache Manager & Monitor.

Oui, mais le workflow habituel consiste à utiliser les événements que Marketing Revolution pousse dans la couche de données, puis à créer vos triggers personnalisés dans Google Tag Manager. Le module pousse les événements ecommerce avec un nom event propre et un objet ecommerce, donc GTM peut écouter ces événements et déclencher vos propres tags.

Par exemple, un trigger d’événement personnalisé GTM pour un achat de forte valeur pourrait être configuré ainsi :

Trigger type: Custom Event
Event name: purchase
Some Custom Events
Condition: ecommerce.value greater than 500

Useful Data Layer Variables:
ecommerce.transaction_id
ecommerce.value
ecommerce.currency
ecommerce.items

Le module réinitialise l’ancien objet ecommerce avant d’en pousser un nouveau, puis pousse un payload comme { event: 'add_to_cart', ecommerce: {...} } ou { event: 'purchase', ecommerce: {...} }. Dans GTM, vous pouvez utiliser directement ces noms d’événements, ajouter des conditions, et mapper les champs ecommerce vers Google Ads, GA4, Meta ou des tags HTML personnalisés.

C’est différent de définir arbitrairement de nouveaux noms d’événements dans l’interface du module. Le module fournit la base ecommerce data layer ; GTM est le bon endroit pour créer des triggers personnalisés, filtres et tags propres aux vendors depuis ces données.

Le jeu d’événements standard est plus large que le seul purchase. Le contexte de page côté serveur peut émettre page_view, view_item, view_item_list, search et begin_checkout. Les interactions navigateur ajoutent des événements comme select_item, add_to_cart, remove_from_cart, add_to_wishlist, add_shipping_info et add_payment_info. Purchase est envoyé depuis le hook de confirmation de commande après l’existence de la commande.

Point d’attention plateforme : GTM reçoit l’objet ecommerce propre, mais les adaptateurs directs de plateformes ne prennent pas tous en charge chaque événement. Les plateformes Google couvrent le jeu ecommerce le plus complètement ; certaines plateformes sociales ne mappent que certaines actions, et les noms d’événements non pris en charge sont ignorés plutôt que forcés vers un mauvais événement vendor. Utilisez GTM quand vous avez besoin d’un routage personnalisé, de conditions supplémentaires ou d’un nom d’événement vendor non intégré au module.

Partiellement. Certains de nos anciens modules s'installent encore sur PrestaShop 1.6, mais les nouveaux modules sont développés et testés uniquement sur les versions actuelles de PrestaShop, nous n'ajoutons plus le support 1.6 à rien de nouveau.

La règle pratique :

• Les anciens modules nés sur 1.6 continuent généralement à fonctionner, mais les correctifs spécifiques à 1.6 ne sont plus prioritaires.
• Le badge de compatibilité de chaque page produit fait foi, si 1.6 n'y figure pas, elle n'est pas supportée pour ce module.

Nous vous recommandons fortement de planifier une mise à niveau. PrestaShop 1.6 a atteint la fin de vie et ne reçoit plus de correctifs de sécurité ; toute faille non corrigée devient un risque permanent. La migration concerne surtout la base de données, le thème et les modules, voir notre guide de migration PrestaShop 9. Contactez-nous pour la trajectoire d'un module précis.

Oui. Avec Digital Revolution, vos clients gèrent eux-mêmes les domaines liés à leurs licences depuis un portail dans leur compte PrestaShop, vous passez ainsi moins de temps à traiter les e-mails « merci de déplacer ma licence ».

Dans l'espace My Shops du portail, un client enregistre un domaine de production, puis lui affecte une licence. Le parcours applique quelques règles de bon sens pour que tout reste propre :

• La propriété est vérifiée. Un client ne peut enregistrer, affecter et retirer que les boutiques appartenant à son propre compte.
• Les emplacements sont appliqués strictement, une licence dispose d'un nombre défini d'emplacements de domaine, et toute affectation au-delà est bloquée jusqu'à ce qu'un emplacement soit libéré ou que la licence soit mise à niveau.
• Les domaines de dev sont traités à part. Les sous-domaines manifestement de dev/staging/test ne peuvent pas être enregistrés comme domaine de production principal ; ils ne sont autorisés que sous un domaine de production déjà affecté à la même licence, et ne consomment pas d'emplacement.
• Pas d'orphelin accidentel. Une boutique ne peut pas être retirée tant qu'elle est encore affectée à une licence ; le client la désaffecte d'abord.

Et vous gardez la main : la désaffectation en libre-service peut être désactivée dans le back office, les changements de domaine passent alors par votre équipe de support. Le portail est un espace de compte privé et reste hors des moteurs de recherche. C'est exactement le modèle que nous utilisons sur notre propre boutique, voir Fonctionnement des licences, de l'activation et du support pour le parcours côté client, ou la page Digital Revolution pour la boîte à outils complète (clés de licence, téléchargements tokenisés, gestion des versions).

La désinstallation supprime la table du journal de suivi du module et sa configuration des plateformes de votre base de données. Les données déjà envoyées à Google Analytics, Meta et d'autres plateformes restent dans ces services, la désinstallation ne supprime rien de ce qui se trouve en dehors de votre boutique. Si vous prévoyez de réinstaller plus tard, exportez d'abord votre configuration des plateformes (IDs de pixel, clés API) pour ne pas avoir à les rechercher à nouveau.

En savoir plus sur Marketing Revolution, suivi unifié pour PrestaShop.

Warehouse Revolution est un système complet de stock et d'entrepôt pour PrestaShop : il suit les stocks sur plusieurs entrepôts, gère la préparation des commandes (picking), les fournisseurs et les commandes d'achat, le traitement des retours avec évaluation de l'état, les nomenclatures (BOM) et les rapports : le tout depuis le back-office.

Il est fait pour vous si la gestion de stock intégrée de PrestaShop atteint ses limites : vous expédiez depuis plus d'un emplacement, devez transférer du stock entre entrepôts, voulez un rangement et une préparation guidés, ou devez savoir quel entrepôt a traité quelle commande. Nous gérons aussi des boutiques, c'est la couche que PrestaShop ne couvre pas nativement dès qu'un vrai entrepôt entre en jeu.

Si vous vendez depuis un seul emplacement et n'avez besoin que des quantités disponibles, vous n'en avez probablement pas besoin : les outils de PrestaShop suffisent, et un système d'entrepôt serait une charge inutile. Le test honnête : plusieurs emplacements, transferts, achats fournisseurs ou évaluation des retours le justifient ; une seule étagère et un champ quantité, non.

Oui. Google Customer Reviews (GCR) est l’une des plateformes que vous pouvez activer dans Marketing Revolution. Saisissez votre Google Merchant Center ID et définissez les jours de livraison estimés, par défaut 7. Le module possède un chemin de script opt-in sur confirmation d’achat et un chemin de script badge séparé pour afficher le badge de note Google.

GCR fonctionne différemment des plateformes analytics et publicitaires. Il n’est pas utilisé pour les événements ecommerce standard comme view_item, add_to_cart ou purchase. Activez-le pour la collecte d’avis et le badge de confiance Google, mais gardez GA4, Google Ads, Meta ou une autre plateforme analytics/ad activée pour le vrai suivi des conversions.

Le payload opt-in actuel inclut le Merchant Center ID, l’ID de commande PrestaShop et une date de livraison estimée calculée depuis le nombre de jours configuré. L’adaptateur possède des champs pour l’email client, le pays de livraison et les GTIN produit, mais les extracteurs de commande et produit utilisés pour construire le payload ne renseignent pas customer_email, delivery_country_iso ni ean13 d’article. Dans le code actuel, ces valeurs sont vides sauf si les extracteurs sont étendus.

Required configuration: MERCHANT_ID
Default: ESTIMATED_DELIVERY_DAYS = 7
Limite actuelle des données transmises : l’adresse e-mail, le pays de livraison et le GTIN du produit ne sont pas renseignés par les extracteurs

Le badge et l’opt-in sont volontairement séparés du tracking ecommerce. Le script badge est différé vers le footer de page, tandis que l’opt-in est généré depuis les données purchase sur la page de confirmation. Il existe un réglage de position du badge dans la configuration de plateforme, mais le renderer de badge actuel ajoute le badge de note avec le merchant ID et ne transmet pas actuellement la position choisie dans les attributs rendus du badge, donc vérifiez le placement visuel dans votre thème.

GCR est intégré à Marketing Revolution. Pour une vision plus large sur les avis et trust badges, consultez notre guide des trust badges.

Non. Dans Performance Revolution, le préchauffage planifié du cache d'origine est désactivé par défaut, l'indicateur cache_warming_enabled démarre à false, et le warmer cron renvoie simplement « disabled » sans rien faire tant que vous ne l'activez pas.

Rien ne lance donc le warmer à votre place par défaut. Vous disposez du mécanisme, prêt à l'emploi :

• Une entrée cron qui, une fois activée, parcourt vos URL pour que l'OPcache PHP, les templates Smarty et le CSS/JS combinés soient compilés avant l'arrivée de vrais visiteurs.
• Des commandes de préchauffage manuel dans le Back Office pour un passage à la demande.
• Des réglages de concurrence et de durée maximale, pour qu'un passage ne sature pas un serveur froid.

Un réglage est activé par défaut : cache_warming_post_deploy_enabled vaut true, ce qui autorise uniquement la commande CLI post-déploiement à lancer un passage complet après une mise en production. Cela autorise cette commande, cela ne planifie rien de soi-même. Le préchauffage edge Cloudflare (cdn_edge_warm_enabled) est lui aussi désactivé par défaut.

Erreur fréquente : activer l'indicateur cron sans jamais brancher un vrai cron (ni le hook post-déploiement) pour l'appeler. Le toggle dit « autorisé » ; un planificateur doit quand même le déclencher.

Oui. Cookies Revolution peut envoyer des valeurs par défaut Google Consent Mode v2 différentes selon la localisation du visiteur, les acheteurs de l'UE partent ainsi d'une posture opt-in stricte, tandis que le trafic des régions sans cette obligation n'est pas bridé inutilement.

Lorsque vous activez l'option régionale et qu'un visiteur n'a pas encore choisi, le module écrit deux valeurs par défaut de consentement dans l'en-tête de la page :

• Un défaut denied limité à l'EEE, au Royaume-Uni et à la Suisse, ad_storage, analytics_storage, ad_user_data et ad_personalization démarrent refusés jusqu'à acceptation du visiteur.
• Un défaut granted pour les autres régions que vous listez (ou pour toutes les régions restantes si vous laissez la liste vide).

C'est émis avant l'initialisation de vos balises Google, avec le tableau region attendu par Google, afin que Consent Mode lise le bon état initial par pays. Si vous préférez un défaut global unique, laissez l'option régionale désactivée et le module envoie un seul défaut.

Cela fait partie du module plus large, quatre catégories de cookies, blocage de scripts par motif réécrivant les traceurs en type="text/plain" jusqu'au consentement, un journal de consentement (IP hachée + horodatage + version) et un scanner de cookies intégré. Une précision honnête : un module de consentement configure des signaux et un blocage ; ce n'est pas un conseil juridique, et les régions et catégories applicables à votre boutique doivent être validées par un avocat ou un DPO.

Oui, Digital Revolution vous offre trois façons distinctes de laisser tester un produit avant l'achat, et vous activez chacune par produit. Un prospect peut ainsi évaluer votre module sans vous demander une copie par e-mail.

• Téléchargements démo, une demande publique sans connexion : le visiteur saisit un e-mail et un domaine, accepte les conditions et reçoit une copie filigranée et limitée dans le temps. Le téléchargement est tokenisé et la démo est limitée à une par e-mail et une par domaine et par produit, avec une expiration que vous définissez.
• Téléchargements gratuits, pour les produits que vous offrez : une copie tokenisée, filigranée, avec un lien qui n'expire pratiquement pas, plus un token de mise à jour intégré pour que le client récupère les versions futures.
• Licences d'essai. Un client connecté peut créer lui-même un essai depuis le portail. C'est une véritable licence limitée dans le temps (vous contrôlez la durée d'essai et le nombre d'essais par client), avec son propre chemin de téléchargement qui ne nécessite pas encore de domaine affecté, pratique pour une première installation.

Chaque variante est journalisée et porte un filigrane avec les coordonnées du demandeur : offrir ne signifie pas perdre la traçabilité. Dès qu'un visiteur est prêt à acheter, le même produit devient une licence complète avec des téléchargements liés au domaine. Le reste de la boîte à outils, clés de licence, journal de téléchargement et gestion des versions, est sur la page Digital Revolution.

Dans le back-office, modifiez le produit sous MPR Digital Revolution > Digital Products. Le formulaire produit contient Trial Enabled, Trial Days, Max Trials per Customer, Demo Enabled, Demo Days et Free Download. Les valeurs par défaut utilisées par le formulaire produit sont trial_days = 7, trial_max_per_customer = 1 et demo_days = 30.

Les clients voient les formulaires de démo/téléchargement gratuit dans le bloc de variante de la page produit : les téléchargements de démo affichent un bouton Download X-Day Demo et demandent l'e-mail, le domaine et l'acceptation des conditions ; les téléchargements gratuits affichent un formulaire Download Module avec e-mail, domaine et conditions du module gratuit. Les licences d'essai sont créées depuis le portail client connecté, pas depuis le formulaire de démo public sans connexion.

Vous évaluez nos propres modules plutôt que de construire votre boutique ? Chaque module payant mypresta.rocks dispose d'une démo pleinement fonctionnelle de 30 jours, et activer votre achat plus tard conserve votre installation et vos réglages en l'état, voir Fonctionnement des licences, de l'activation et du support.

Oui, de trois façons différentes, pour que votre contenu éditorial pousse réellement les visiteurs vers le catalogue au lieu d'être une impasse.

• Choisir des produits par article. Chaque article dispose d'un champ produits associés dans l'éditeur ; les liens sont stockés dans une table de relation dédiée et affichés sous forme de bloc produit sur la page de l'article.
• Afficher des articles sur les pages produit. Blog Revolution s'accroche au pied de la page produit et fait remonter les articles de blog liés à ce produit, transformant un guide d'achat ou un tutoriel en étape vers le bouton « ajouter au panier ».
• Insérer des produits via shortcodes. Dans le corps de l'article, écrivez [products ids="1,2,3"], [products category="5"], [products new] ou [products bestsellers] : le module affiche une grille de produits à jour via le presenter de produits natif de PrestaShop. Prix et disponibilité restent actuels.

Le content commerce devient simple : rédigez un comparatif ou un guide de style, rattachez les SKU exacts et laissez l'article vendre.

Dans le back-office, allez dans Blog Revolution > Posts, modifiez l'article, puis utilisez l'onglet Related Products. Le sélecteur enregistre les ID des produits choisis dans l'ordre, et le front-office les rend avec la miniature produit normale du thème de la boutique via catalog/_partials/miniatures/product.tpl.

Les produits sélectionnés sont triés selon leur position enregistrée. Il n'y a pas de limite fixe stricte dans la relation article-produit elle-même ; la limite pratique dépend du nombre de produits que vous choisissez d'attacher et du volume de contenu de grille produit pertinent sous l'article.

Erreur courante : oublier que les shortcodes chargent des produits en direct, un produit supprimé disparaît simplement de la grille, sans devoir fouiller les anciens articles pour réparer des blocs cassés.

Ces trois liens sont intégrés à Blog Revolution.

Smart Search Revolution va plus loin que la recherche native PrestaShop en ajoutant recherche AJAX, synonymes, fuzzy matching, redirections par motif, boosting produit, analytics, suivi des clics et insights zéro résultat. Il peut aussi rendre des résultats produit/catégorie/fabricant/fournisseur/CMS dans une seule expérience de recherche, tandis que la recherche native correspond surtout des mots-clés aux champs catalogue indexés.

C’est un système de recherche complet, pas seulement une search box stylée. Il installe des tables pour motifs, synonymes, réécritures, règles de boost, analytics de requêtes, clics et signaux produit. Le moteur étend les synonymes, applique une correspondance pondérée, prend en charge une recherche de repli, peut exécuter des actions de motif avant les résultats normaux, applique des réécritures, charge plusieurs sections de résultats et journalise les statistiques de requête lorsque les analytics sont activées.

Le contrôleur front prend en charge des actions AJAX pour recherche, load more, suggestions, preview, refinement, historique de recherche, recherche vocale, AI search, ajout au panier, suivi des clics, produits récemment consultés et opérations batch. Le suivi des clics peut attribuer des clics produit à des commandes ultérieures, marquer les clics comme convertis, incrémenter les nombres de conversion et mettre à jour les signaux de recherche produit. La recherche native PrestaShop ne fournit pas cette couche combinée live-search, merchandising, routage, analytics et feedback de conversion.

Indirectement, oui. Financial Revolution est une couche financière qui vit à l'intérieur de PrestaShop, il ne pousse pas les données par API vers QuickBooks, Xero, Sage ou SAP, mais produit des exports CSV et Excel propres que votre comptable ou votre logiciel sait importer.

Dans PrestaShop, il prend en charge le travail fait d'habitude à la main :

• Factures, proformas et avoirs avec chaînes de référence correctes et séquences de numérotation configurables (avec options de réinitialisation).
• Rapports TVA et validation VIES en direct des numéros de TVA B2B.
• Coûts récurrents et suivi des dépenses par fournisseur et catégorie.
• Un tableau de bord avec compte de résultat et trésorerie.

Le transfert vers un logiciel comptable externe se fait via ces exports CSV/Excel. Pour un push API en temps réel vers une plateforme précise, il s'agit de développement sur mesure, mais pour la clôture mensuelle classique suivie d'un import comptable, la voie d'export suffit.

Oui. Il remplace la page de checkout, pas le reste de votre boutique. Le flux par défaut en cinq étapes de PrestaShop est remplacé par un checkout en une page qui regroupe contact, adresse, transporteur, paiement et récapitulatif sur un seul écran.

Ce qui change :

• Le template de checkout et le flux côté front (une page au lieu de plusieurs étapes).
• L'agencement des champs, le comportement de validation et l'UX de création de compte.
• Le suivi de session, l'attribution UTM et le journal des transactions deviennent disponibles dans le back-office.

Ce qui ne change pas :

• Vos modules de paiement (Stripe, PayPal, Apple Pay, Google Pay, méthodes hors ligne) continuent à s'enregistrer et traiter les paiements comme avant.
• Vos modules de transport conservent leurs règles, Checkout Revolution les affiche via son propre sélecteur de transporteurs.
• Règles de panier, codes promo, taxes, devises et comportement multistore restent natifs PrestaShop.
• Les comptes clients, adresses et historique de commandes utilisent les tables standard PrestaShop.

Le basculement est donc non destructif : vous pouvez désactiver le module à tout moment et le checkout d'origine revient, avec toutes les commandes, transporteurs et configurations de paiement intacts. Compatible PrestaShop 1.6 à 9.x.

Les enregistrements natifs importants pour l'historique des commandes restent dans PrestaShop : paniers, commandes, clients, adresses, transporteurs, devises, taxes, règles panier et données de commande des modules de paiement ne sont pas convertis en enregistrements propres à Checkout Revolution. Le module ajoute ses propres fonctionnalités de checkout/session/attribution autour de ce flux, mais il ne remplace pas ps_orders, ps_cart, ps_customer ni les tables natives d'adresses/commandes.

Le rollback est le rollback standard d'un module : désactivez Checkout Revolution depuis Modules > Module Manager ou désinstallez-le si vous avez terminé les tests. Après avoir vidé le cache, PrestaShop revient au contrôleur et aux templates de checkout natifs ; les commandes existantes et la configuration paiement/transport restent en place.

Liste complète des fonctionnalités sur la page produit Checkout Revolution.

Cela dépend de votre thème, pas de votre navigateur. Les navigateurs modernes prennent en charge le lazy loading natif via l'attribut loading="lazy", mais seulement si quelque chose place réellement cet attribut sur vos balises image. Beaucoup de thèmes PrestaShop ne le font pas, et les images se chargent alors immédiatement, même si le navigateur les différerait volontiers.

C'est la lacune que comble ce module. Il ajoute loading="lazy" (et en option decoding="async") aux images produit et de liste, ainsi qu'aux images des contenus WYSIWYG comme les descriptions et pages CMS. Il le fait via les hooks de présentation de PrestaShop plutôt qu'en réécrivant la sortie de page : il reste donc compatible avec le cache, et vous pouvez exclure certaines images par une classe CSS.

Vérifiez donc d'abord vos propres pages : affichez le code source d'une page produit ou catégorie et cherchez loading="lazy" sur les balises <img>. S'il y est déjà, votre thème s'en charge et le module est inutile. Sinon, il l'ajoute sans que vous modifiiez les templates. Une réserve honnête, mieux vaut laisser le lazy loading désactivé sur l'image principale au-dessus de la ligne de flottaison ; le module compte sur votre template pour afficher l'attribut fourni. Voir Automatic SEO Images Lazy Tags.

Non. Nos modules gratuits sont pleinement fonctionnels, pas des démos bridées. Vous obtenez la vraie fonctionnalité, pas un aperçu qui pousse sans cesse à passer à la version payante.

Les différences honnêtes portent sur la portée et le support. Les modules gratuits sont plutôt des outils simples et mono-fonctionnels, avec un support de niveau communautaire : nous corrigeons les vrais bugs, mais les temps de réponse ne sont pas garantis et les mises à jour sont moins fréquentes. Les modules payants bénéficient d'un support prioritaire avec temps de réponse garantis et un rythme de mises à jour plus soutenu. Si un module gratuit couvre votre besoin, utilisez-le en confiance, il ne cache aucun péage interne.

En bref : pour l'entretien lié aux modules, oui ; pour la maintenance complète de la boutique, non, et nous vous orienterons au bon endroit.

Notre métier, c'est concevoir et suivre des modules. Si votre besoin de maintenance PrestaShop est lié aux modules, garder nos modules à jour, les reconfigurer quand votre catalogue évolue, ou régler un conflit après une mise à jour de PrestaShop, , nous pouvons en discuter dans le cadre d'un arrangement de support.

Ce que nous ne faisons pas, c'est la maintenance générale : mises à jour serveur, correctifs de sécurité, sauvegardes, retouches du thème, optimisation de toute la boutique. Ce travail est continu et très proche du système ; il revient à une agence PrestaShop dédiée ou à un freelance proche de votre stack, idéalement celui qui gère déjà votre hébergement.

Conseil pratique : séparez les deux rôles. Confiez la boutique et l'infrastructure à votre agence, et venez nous voir pour tout ce qui concerne les modules que vous avez achetés. Cela évite les renvois de responsabilité quand une seule partie gère tout.

En savoir plus sur ce que nous proposons : nos services et l'ensemble du catalogue de modules.

Non. Le Ultimate All-In-One Pack est une offre de licence et d'achat, pas une consigne pour activer tous les modules d'un coup. N'installez que ceux adaptés à la boutique concernée, par exemple outils SEO, outils de checkout, intégrations analytics, widgets de chat ou utilitaires d'administration.

C'est ce qui le rend utile aux agences et aux développeurs : un seul achat offre une boîte à outils commune pour le travail PrestaShop récurrent. Chaque module inclus garde sa propre installation, ses notes de compatibilité et sa configuration sur sa page produit. Considérez donc le pack comme un accès au catalogue, pas comme un module géant à faire tourner sur chaque boutique.

Voyez ce pack PrestaShop comme un ensemble de modules indépendants, pas un seul énorme module à tout activer d'un coup. Le Revolution Complete Pack regroupe les modules de la gamme Revolution sous un même achat et un même support, mais chaque module garde ses réglages, sa documentation et ses fonctions.

Le déploiement recommandé se fait module par module, dans l'ordre de vos priorités :

• Commencez par ce dont la boutique a vraiment besoin. Une nouvelle boutique débute souvent par les modules SEO, performance et sécurité ; une boutique axée conversion par le checkout et le marketing/analytics.
• Installez un module, configurez-le, vérifiez-le en préproduction ou sur une plage calme, puis passez au suivant. Tout installer d'un coup complique l'attribution d'une régression à un module.
• Laissez désactivés les modules inutiles. Tout activer ajoute des hooks et des onglets d'administration que vous n'utiliserez peut-être jamais.

Comme les modules sont indépendants, vous adoptez ce pack de modules PrestaShop à votre rythme tout en bénéficiant d'un seul flux de mises à jour et de support. Voir le contenu et les pages par module sur la page Revolution Complete Pack.

Oui. Lightweight Cookie Banner stocke ses textes visibles par les visiteurs par langue, afin que chaque langue PrestaShop affiche sa propre bannière au lieu d’une chaîne anglaise pour tout le monde.

Les champs que vous pouvez traduire sont :

• Le message principal de consentement.
• Les libellés des boutons Accept et Deny.
• Le texte du lien de politique, c’est-à-dire le libellé cliquable à côté des boutons.

Le lien de politique pointe vers votre page de confidentialité ou de cookies via un seul champ Privacy Policy URL. Cette URL est une valeur unique plutôt que par langue ; si votre politique vit à des URL différentes par langue, pointez vers une page qui change elle-même de langue, ou utilisez une URL que votre boutique localise. Laissez le champ vide et le lien est masqué.

La bannière est first-party : le consentement est mémorisé dans un cookie mprcookie_consent sur votre propre domaine, sans serveur tiers. Elle peut émettre des signaux Google Consent Mode v2 par défaut depuis displayHeader et met à jour ad_storage, analytics_storage, ad_user_data et ad_personalization lorsque le visiteur accepte ou refuse le consentement.

Ne supposez pas que le bloc Consent Mode tourne toujours avant chaque tag Google de la boutique. Le script de consentement par défaut est renvoyé depuis hookDisplayHeader, tandis que le script front-end de mise à jour est enregistré comme asset chargé en bas de page, et le module n’impose pas l’ordre des hooks face aux autres modules Google-tag. Pour une configuration stricte, vérifiez l’ordre des hooks rendus afin que les tags Google chargent après le bloc de consentement par défaut.

Par défaut, le module est activé, utilise une expiration de cookie de 365 jours, place la bannière en bas à gauche, utilise le thème sombre, et définit le consentement par défaut Google Consent Mode sur denied. Accept écrit granted ; deny écrit denied. Le cookie est défini avec SameSite=Lax et ajoute Secure sur les pages HTTPS.

Il y a quelques choix de mise en page plutôt qu’un centre complet de préférences : boutons côte à côte, boutons empilés, ou accept-only avec un modèle close/deny. Quand le consentement change, le script front-end met à jour Google Consent Mode et dispatch un événement mprcookie:consent, que d’autres modules de tracking peuvent écouter.

Limite honnête : c’est un petit avis accept/deny volontairement léger, pas une plateforme de consentement complète. Il ne bloque pas les scripts par catégorie et ne tient pas de journal d’audit. Si vous avez besoin de cela, Cookies Revolution est le module plus complet. La logique d’installation empêche aussi d’exécuter les deux modules de consentement cookie en même temps, car deux gestionnaires de consentement produiraient des états visiteur contradictoires.

Oui. Cookies Revolution peut créer une vraie page CMS PrestaShop pour votre politique cookies, afin que vous ne mainteniez pas à la main une table de cookies statique chaque fois qu’un tracker change.

Fonctionnement :

• Le module construit la page depuis vos catégories de cookies et inventaire - pour chaque catégorie, il liste les cookies enregistrés avec leur nom, fournisseur, finalité et durée.
• Il génère le contenu par langue, donc une boutique multilingue obtient un corps de politique pour chacune de ses langues.
• Les réglages incluent une option auto-update CMS page, mais dans le chemin de code actuel, les actions exposées sont create et update depuis la page de réglages du module. Après modification des catégories ou de l’inventaire cookies, utilisez l’action update pour régénérer le contenu CMS depuis les données les plus récentes.

Le contenu généré commence par une courte explication, puis sort chaque catégorie active avec sa description. Dans chaque catégorie, il crée une table avec Cookie Name, Provider, Purpose et Duration. Les cookies de session sont affichés avec une durée session, tandis que les durées en minutes, heures, jours, mois et années sont formatées depuis l’enregistrement cookie.

La bannière cookies peut ensuite pointer directement vers cette page générée. Si vous avez déjà une politique rédigée ailleurs, vous pouvez plutôt pointer la bannière vers votre propre URL de politique personnalisée - le choix vous appartient. Le champ policy URL est multilingue, et s’il est vide, le module se rabat sur l’ID de page CMS stocké lorsque cette page CMS est active.

Les données cookies viennent des catégories et enregistrements cookie que vous maintenez dans le module. L’installateur initialise des catégories courantes comme necessary, functional, analytics et marketing, plus des cookies connus comme les cookies de session PrestaShop, Google Analytics, Facebook et Bing UET. Le scanner peut aussi détecter de nouveaux cookies, suggérer une catégorie, et vous laisser catégoriser les résultats sélectionnés dans l’inventaire avant de régénérer la page de politique.

Réserve honnête : le générateur produit une table cookies claire et structurée depuis ce que vous avez configuré, mais ce n’est pas de la rédaction juridique. Relisez le wording et faites confirmer par un avocat ou DPO qu’il reflète réellement la façon dont votre boutique traite les données. Pour un avis accept/deny minimal sans génération de page, voir Lightweight Cookie Banner.