Ventes et vues produit : afficher des statistiques en direct pour guider les décisions d’achat

Passez devant deux restaurants aux menus identiques : vous choisirez spontanément celui qui est plein. En ligne, le client ne voit pas la file d’attente — c’est donc à la page produit de la lui montrer. « 847 vendus » ou « 32 personnes consultent ce produit en ce moment », placé à côté du bouton Ajouter au panier, joue pour un produit le même rôle qu’une salle comble pour un restaurant : cela indique à l’acheteur hésitant que d’autres personnes ont déjà fait ce choix et qu’elles ne l’ont pas regretté. Cet article porte précisément sur la version en direct, produit par produit de ce signal sur une page produit PrestaShop — le nombre de ventes et le nombre de vues qui se mettent à jour pour le produit réellement consulté par le client, pas un badge global pour toute la boutique ni une notification flottante dans un coin.

Dernière mise à jour : juin 2026.

Deux notions proches méritent d’être distinguées avant de commencer, car c’est en les mélangeant que la plupart des marchands se trompent dans la mise en œuvre. Un chiffre de confiance affiché à l’échelle du site, comme « 12 400 produits vendus », est un autre outil, avec un autre rôle — c’est le sujet du compteur du nombre total de produits vendus. Une notification flottante du type « Quelqu’un à Cracovie vient d’acheter ceci » est encore un autre format — voir la notification de vente et la question de savoir si ces messages font réellement bouger les chiffres dans les notifications de ventes en direct. Cet article se concentre sur ce que ces formats ne font pas : des chiffres intégrés à la page, produit par produit, tirés de vos vraies données de commandes et de visites, affichés directement sur la page produit.

Les deux chiffres, et ce que chacun dit réellement

Le nombre de ventes et le nombre de vues se ressemblent, mais ils n’agissent pas du tout de la même façon sur le plan psychologique. C’est cette différence qui détermine où utiliser chacun d’eux.

Et alors ? Les ventes cumulées rassurent ; l’activité récente et les visiteurs en direct créent une urgence légère. Un acheteur nerveux face à un article à 600 € veut être rassuré — affichez le total des ventes. Un chasseur de bonnes affaires sur un accessoire remisé réagit à « 7 vendus aujourd’hui ». Afficher le mauvais chiffre dans le mauvais contexte explique pourquoi certains marchands testent les compteurs, ne voient aucun effet, puis concluent que la preuve sociale « ne fonctionne pas ». Elle fonctionne ; le chiffre doit simplement répondre au bon doute.

Un point que cet article laisse volontairement de côté : les notes par étoiles et le nombre d’avis sont aussi de la preuve sociale, mais ils relèvent d’un système distinct, avec ses propres enjeux de modération, de spam et de SEO — c’est le sujet des avis natifs ou tiers, pas celui-ci.

Où PrestaShop conserve déjà ces chiffres

La bonne nouvelle, c’est que PrestaShop enregistre déjà la plupart des données nécessaires — il ne les affiche tout simplement pas en front office. Savoir où elles se trouvent permet de distinguer ce qui relève d’une simple requête de ce qui nécessite un nouveau suivi.

Les ventes sont déjà dans la base de données. Chaque ligne de commande se trouve dans ps_order_detail (les colonnes product_id et product_quantity), reliée à ps_orders pour la date et l’état de la commande. Le nombre de ventes cumulées d’un produit correspond à un SUM(product_quantity) sur ps_order_detail pour ce product_id ; un compteur « 7 derniers jours » ajoute un WHERE sur le date_add de la commande. La décision importante ici est de savoir quels états de commande comptent. Compter tous les paniers ayant atteint un état provisoire gonfle le chiffre et revient presque à mentir ; la plupart des marchands ne comptent que les états valides/payés. PrestaShop maintient aussi une table séparée ps_product_sale (la colonne quantity, exposée comme sales dans les requêtes de meilleures ventes) — un agrégat de ventes dénormalisé que PrestaShop met à jour lorsque les commandes sont validées — mais si vous avez besoin d’une logique personnalisée sur les états de commande ou les dates, interroger directement ps_order_detail avec des états valides explicites peut être préférable au total mis en cache.

La lecture des ventes cumulées tient en une seule requête. PrestaShop définit ps_orders.valid = 1 lorsqu’une commande atteint un état payé/accepté ; s’appuyer sur ce marqueur est donc la façon la plus honnête de ne compter que les commandes réellement passées (adaptez le préfixe ps_ à votre installation). C’est une lecture seule — elle ne modifie rien :

-- Lifetime units sold for one product, counting only valid orders
SELECT SUM(od.product_quantity) AS units_sold
FROM ps_order_detail od
JOIN ps_orders o ON o.id_order = od.id_order
WHERE od.product_id = 123      -- the product you're displaying
  AND o.valid = 1;

-- "Sold in the last 7 days" — same query, with a date window
SELECT SUM(od.product_quantity) AS units_7d
FROM ps_order_detail od
JOIN ps_orders o ON o.id_order = od.id_order
WHERE od.product_id = 123
  AND o.valid = 1
  AND o.date_add >= DATE_SUB(NOW(), INTERVAL 7 DAY);

Exécutez-les dans Paramètres avancés → Base de données → Gestionnaire SQL pour vérifier les vrais chiffres d’un produit avant d’afficher le moindre compteur sur la page — si le chiffre honnête est faible, c’est précisément le produit sur lequel laisser le compteur désactivé.

Les vues sont en partie là, en partie non. PrestaShop compte déjà les vues de pages par jour dans ps_page_viewed (reliée via ps_page / ps_page_type pour déterminer à quel produit correspond une visite de page « product ») — ce sont les données utilisées par les modules de statistiques PrestaShop, comme les produits les plus vus lorsque le module de statistiques est installé/activé. Ainsi, les vues « aujourd’hui / cette semaine » peuvent être lues directement dans les tables existantes. Ce que PrestaShop ne suit pas nativement, c’est le compteur en direct et simultané du type « X personnes consultent ce produit maintenant » — il n’existe pas de compteur intégré de présence de session. Ce chiffre exige un suivi léger dédié : un petit heartbeat AJAX qui enregistre une session sur un produit et l’expire après quelques minutes de silence. C’est important à savoir avant de vous promettre un compteur en temps réel — une moitié relève d’une requête SQL, l’autre doit être développée ou achetée.

L’afficher sur la page produit — la partie propre à PrestaShop

Quelle que soit la façon dont vous générez les chiffres, ils doivent s’afficher au bon endroit dans le thème, et PrestaShop fournit des hooks propres pour éviter toute modification des fichiers du cœur (qu’une mise à jour écraserait de toute façon).

• displayProductPriceBlock — se déclenche autour de la zone de prix, avec un $type que vous pouvez vérifier ('after_price', 'weight', etc.). C’est là qu’un nombre de ventes a sa place : juste à côté du prix, dans la ligne de regard principale du client.
• displayProductButtons / displayProductActions — à côté d’Ajouter au panier, l’emplacement naturel d’une ligne d’urgence comme « 32 personnes consultent ce produit », car c’est la dernière information lue avant le clic.
• displayProductAdditionalInfo — sous le bloc d’achat, un emplacement plus calme pour « 156 vues aujourd’hui », qui informe sans insister.

Le modèle le plus propre consiste à créer un module qui s’enregistre sur ces hooks et fournit ses propres templates .tpl. Ainsi, une mise à jour du thème ne supprimera pas vos changements, et désactiver le module retirera proprement la fonctionnalité. L’autre option — modifier directement product.tpl (ou les partiels templates/catalog/_partials/ dans les thèmes 1.7+) — fonctionne, mais lie la fonctionnalité à un thème et à une version, et vous devrez la refaire à la prochaine mise à jour. Si vous touchez au template produit pour cela, mieux vaut d’abord comprendre la logique de mise en page dans son ensemble : les bonnes pratiques de conception d’une page produit et ce qui déclenche réellement le clic dans l’anatomie d’une page produit.

Un point de performance important à grande échelle : une implémentation naïve lance un nouveau COUNT/SUM sur les tables de commandes à chaque chargement de page produit. Sur un catalogue fréquenté, c’est une vraie pression sur la base de données pour un chiffre qui n’a pas besoin d’être exact à la seconde près. Mettez-le en cache — calculez les compteurs selon une planification (une fois par heure suffit largement pour les chiffres cumulés) ou utilisez la couche de cache de PrestaShop — puis lisez la valeur mise en cache au rendu. « Léger et mis en cache » fait toute la différence entre une fonctionnalité qui aide la conversion et une fonctionnalité qui dégrade votre vitesse de page précisément sur la page où la rapidité compte le plus.

Les règles d’honnêteté — et pourquoi l’affichage par produit les rend strictes

C’est ici que l’affichage de chiffres sur un produit précis ne pardonne pas, contrairement à un badge global pour toute la boutique. Un total de site comme « 12 400 vendus » peut absorber discrètement quelques produits faibles. Un compteur intégré s’affiche sur chaque produit individuellement : chaque chiffre gênant devient visible.

• Fixez un seuil d’affichage. N’affichez « X vendus » qu’au-dessus d’un plancher — 50, 100, selon votre volume. « 3 vendus » sous un prix ne se lit pas comme une preuve ; cela se lit comme « personne n’achète ce produit », ce qui est pire que de ne rien afficher. Un bon module expose ce seuil comme un réglage, afin que vous le définissiez une seule fois.
• Ne fabriquez jamais les chiffres. Pas de vues inventées sur une base « faux socle + réel », pas de « plus que 2 en stock ! » sur un produit dont le stock est de 400, pas de nombre aléatoire de visiteurs qui se réinitialise à l’actualisation. Les clients font des captures d’écran et comparent ; se faire prendre à fabriquer artificiellement de la rareté abîme durablement la réputation, et c’est de plus en plus facile à repérer. Si le trafic réel n’est pas là, n’affichez pas le nombre de visiteurs sur ce produit — réservez-le à vos produits réellement fréquentés.
• Faites correspondre le chiffre à l’activité réelle. « Vues aujourd’hui » doit refléter les vraies données ps_page_viewed, pas un multiplicateur. Toute la valeur des statistiques intégrées tient au fait qu’elles sont vraies ; dès qu’un client averti soupçonne qu’un chiffre est inventé, tous les autres chiffres de votre page — prix, stock, avis — héritent du doute.

Si vos chiffres honnêtes ne sont pas encore impressionnants, ce n’est pas un échec de la tactique — c’est un signal pour l’utiliser de façon sélective. Activez-la sur les produits qui ont déjà du trafic et des ventes, laissez-la désactivée sur la longue traîne, et la page dit la vérité partout.

Combiner les statistiques sans surcharger la page

Les compteurs en direct sont un élément de persuasion parmi d’autres, et les empiler tous produit une page produit bruyante, façon vente agressive, qui convertit moins bien qu’une page calme. L’objectif est d’associer, pas d’accumuler.

Un nombre de ventes à côté du prix, associé à une photo produit honnête et à une estimation de livraison claire, construit un argument cohérent : populaire, réel, bientôt livré. Ajouter une ligne de visiteurs en direct par-dessus un nombre de ventes, par-dessus un badge « tendance », par-dessus un compte à rebours produit l’effet inverse — cela sent la panique commerciale. Choisissez le ou les deux signaux qui correspondent au doute précis que ce produit déclenche. Pour savoir où les badges s’inscrivent dans cette logique (et s’ils méritent vraiment leur place), l’article sur les badges et étiquettes produit entre dans le détail ; pour faire passer les clients d’un article populaire à un panier plus élevé une fois la confiance acquise, voir la vente croisée et la montée en gamme.

Comment savoir si cela a réellement fonctionné

Ne jugez pas cela au ressenti ni sur trois jours de données. Avant d’activer les compteurs, notez la référence pour les produits ciblés : taux de conversion de la page produit (vues vers ajout au panier, puis ajout au panier vers commande) et taux de rebond sur ces pages. Activez les compteurs, puis comparez les mêmes chiffres sur au moins 30 jours et avec un volume de commandes significatif — suffisamment pour lire une tendance, pas le bruit d’une semaine à l’autre. La lecture la plus propre consiste à activer les statistiques sur un groupe de produits comparables et à laisser un groupe similaire intact comme témoin, afin que les variations saisonnières touchent les deux groupes de la même façon.

La plupart des boutiques qui le font honnêtement constatent un gain intéressant sur les produits dont les chiffres sous-jacents étaient déjà solides — et des résultats plats, voire négatifs, lorsqu’elles forcent les compteurs sur des produits faibles. Ce schéma résume toute la leçon de cet article en une phrase : les statistiques de ventes et de vues en direct ne créent pas la demande, elles diffusent une demande qui existe déjà. Affichez de vrais chiffres, sur les produits qui en ont, à l’endroit qui répond au doute — et laissez l’instinct du restaurant plein faire le reste.

Si vous préférez ne pas développer vous-même le suivi heartbeat, la mise en cache, le seuil d’affichage et les hooks de thème, notre module Product Sales & Views Live Stats relie ces éléments depuis le back office — des compteurs tirés de vos vraies données de commandes et de visites, un seuil d’affichage minimum pour que les produits faibles restent silencieux, et des lectures mises en cache afin que le compteur ne lance pas une nouvelle requête à chaque chargement de page produit. Les règles d’honnêteté ci-dessus sont l’essentiel ; le module les applique pour vous au lieu de les laisser dépendre de votre discipline.

Questions fréquentes

Où PrestaShop stocke-t-il déjà le nombre de ventes que je veux afficher ? Dans ps_order_detail (les colonnes product_id et product_quantity), reliée à ps_orders pour la date et le marqueur de validité. Un total cumulé correspond à un SUM(product_quantity) sur les commandes valides de ce produit. PrestaShop conserve aussi un agrégat dénormalisé dans ps_product_sale, mais interroger directement ps_order_detail vous permet de contrôler précisément quels états de commande comptent.

PrestaShop peut-il afficher nativement un vrai compteur « X personnes consultent ce produit en ce moment » ? Non. PrestaShop compte les vues de pages par jour dans ps_page_viewed (donc « vues aujourd’hui / cette semaine » relève d’une requête), mais il n’a pas de compteur intégré de présence de session en direct. Un vrai chiffre « consulté en ce moment » nécessite son propre suivi léger — un heartbeat AJAX qui enregistre une session sur un produit et l’expire après quelques minutes.

Quel est le chiffre minimum à afficher ? Fixez un plancher — 50 ou 100, selon votre volume — et masquez le compteur en dessous. « 3 vendus » sous un prix se lit comme « personne n’achète ce produit », ce qui est pire que de ne rien afficher. Un bon module expose ce seuil comme un réglage.

Un compteur sur chaque produit ne risque-t-il pas de ralentir ma boutique ? Si, s’il lance un nouveau COUNT/SUM à chaque chargement de page. Mettez les chiffres en cache — calculez-les selon une planification (une fois par heure suffit largement pour les compteurs cumulés) et lisez la valeur mise en cache au rendu. « Léger et mis en cache » fait toute la différence entre une fonctionnalité qui aide la conversion et une fonctionnalité qui ralentit la page où la vitesse compte le plus.

Est-il acceptable de gonfler les chiffres pour donner l’impression que le produit est plus populaire ? Non. Pas de vues avec faux socle, pas de « plus que 2 en stock » sur un produit avec 400 unités disponibles, pas de nombres de visiteurs aléatoires qui se réinitialisent à l’actualisation. Les clients font des captures d’écran et comparent ; dès qu’un chiffre semble inventé, tous les autres chiffres de la page — prix, stock, avis — héritent du doute. N’affichez de vrais chiffres que sur les produits qui en ont réellement.