Compteur total de produits vendus : preuve sociale avec de vrais chiffres

"1 247 vendus." Deux mots et un nombre, juste sous le prix — et pour un acheteur qui n'a jamais entendu parler de votre boutique, cela répond à la seule question qui compte vraiment : d'autres personnes ont-elles eu assez confiance pour sortir leur carte bancaire ? Un compteur du total vendu prend une donnée que votre base connaît déjà et la place là où se joue la décision d'achat. Cet article parle précisément de ce chiffre : le nombre cumulé, depuis toujours, d'unités vendues, affiché sous forme de badge statique sur la page produit. Pas du bandeau en direct "12 personnes consultent ce produit en ce moment", ni de la popup "quelqu'un à Munich vient de l'acheter" — ce sont d'autres signaux, avec leur propre rôle, et nous y renvoyons plus bas. Le compteur historique a un seul objectif : transformer votre historique de ventes en preuve.

Dernière mise à jour : juin 2026.

Ce que signifie réellement "total des produits vendus" dans PrestaShop — et où se trouve ce chiffre

Avant d'afficher un nombre de ventes, vous devez savoir quel chiffre vous montrez, car PrestaShop en stocke plusieurs qui se ressemblent mais ne signifient pas la même chose. Se tromper ici est l'erreur de mise en œuvre la plus fréquente que nous voyons.

Qu'est-ce que cela signifie pour vous ? Le véritable total vendu est une somme sur ps_order_detail, reliée à ps_orders afin de ne compter que les commandes dans un état valide (payée, expédiée, livrée) et d'exclure les paniers abandonnés, les commandes annulées ou en erreur. Un compteur qui inclut discrètement les commandes annulées et remboursées gonfle lui-même son chiffre — et le jour où un client s'en aperçoit, ce nombre cesse d'inspirer confiance et commence à en coûter.

La version honnête de cette requête ressemble à ceci — elle additionne les quantités des lignes de commande, mais uniquement pour les commandes que PrestaShop a marquées comme valides :

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 = :id_product
  AND o.valid = 1;

Le drapeau o.valid est le filtre décisif : PrestaShop le met à 1 uniquement lorsqu'une commande atteint un état que le marchand a marqué comme "logable" (payée, expédiée, livrée). La jointure sur ce champ exclut donc les commandes abandonnées, annulées ou en erreur. Exécutez toutefois cela avec un GROUP BY sur chaque page produit, et cela devient exactement le problème de performance que cet article signale — d'où l'existence de la table mise en cache ci-dessous.

PrestaShop expose déjà un raccourci plus propre : la table ps_product_sale, tenue à jour par la classe ProductSale de PrestaShop chaque fois qu'une commande est validée (les mêmes données que derrière Stats → Best-selling products dans le back-office). Lire la colonne quantity mise en cache dans cette table est beaucoup plus léger que d'additionner les détails de commandes à chaque chargement de page — et c'est important, car la page produit fait partie des URL les plus consultées de votre boutique, et vous ne voulez pas déclencher un GROUP BY coûteux pour chaque visiteur.

Pourquoi un compteur de ventes fonctionne — et où se situe la limite

La preuve sociale fonctionne parce que les gens se tournent vers les autres lorsqu'ils doivent décider dans l'incertitude. Dans un magasin physique, vous voyez d'autres clients prendre des produits en main ; en ligne, ce signal disparaît si vous ne le réintroduisez pas. Un compteur de ventes est la manière la plus quantitative de le faire — un seul chiffre qui dit "d'autres personnes ont déjà emprunté ce chemin". Il est généralement le plus utile sur les achats réfléchis de milieu de gamme : assez chers pour que l'acheteur ait besoin d'être rassuré, pas assez pour qu'il lise d'abord une douzaine d'avis. Sur les produits d'achat impulsif, le client s'arrête à peine ; sur les produits haut de gamme, il fera ses recherches quoi qu'indique votre badge.

La limite honnête est la suivante : un compteur de ventes est un signal parmi d'autres, pas un chiffre magique. Il valide la popularité, mais ne dit rien sur le fait que le produit soit bon — c'est le rôle des avis produit, qui apportent un poids qualitatif qu'un simple total ne peut pas fournir. Les deux se complètent : "238 vendus · 4,7 étoiles · 41 avis" est bien plus fort que chacun de ces éléments pris séparément, car cela répond à la fois à "est-ce populaire ?" et à "les clients en ont-ils été satisfaits ?" Si votre boutique s'appuie sur des widgets d'avis tiers, il vaut la peine de comprendre pourquoi ils ne suffisent pas à eux seuls pour le signal de confiance qu'un compteur de ventes vient renforcer.

Quand ce chiffre vous aide — et quand il vaut mieux le masquer

Ce que la plupart des guides passent sous silence : un compteur de ventes n'est pas bénéfique dans tous les cas. Le même badge qui convertit sur un produit peut en pénaliser un autre. Un compteur intelligent, qui sait quand s'afficher, vaut mieux qu'un compteur qui imprime aveuglément ce que contient la base de données.

• Affichez-le seulement une fois un seuil atteint. "2 vendus" est pire que l'absence de compteur — cela murmure "personne n'en veut". Définissez un minimum (nous conseillons souvent aux marchands de commencer autour de 25 à 50 unités) et masquez le badge en dessous. Un produit gagne son compteur ; il ne naît pas avec.
• Nouvelle boutique, aucun avis ? C'est là qu'il justifie sa place. Sans avis et sans notoriété de marque, même "47 vendus" indique à un premier visiteur que de vraies personnes ont acheté et, vraisemblablement, reçu leur commande. C'est la preuve que la boutique fonctionne, pas seulement que le produit existe.
• Catalogue très concurrentiel ? Lorsqu'un acheteur compare le même article dans trois onglets, la fiche qui affiche "3 400 vendus" prend l'avantage sur les deux autres qui ne montrent rien — le compteur devient le critère de départage qu'il ne savait pas chercher.
• Positionnement luxe ou exclusivité ? Désactivez-le. Si votre récit de marque repose sur "édition limitée, fabrication artisanale, très peu d'exemplaires", un nombre de ventes à cinq chiffres le contredit frontalement. Vous ne pouvez pas être exclusif et grand public sur la même page.
• Produits numériques et thèmes ? Soyez prudent. Un chiffre élevé peut se lire comme "tout le monde l'a déjà", ce qui devient une objection d'achat plutôt qu'une réassurance pour des éléments de design censés rendre une boutique distinctive.

Comment présenter le chiffre pour qu'il paraisse honnête

Le même historique de ventes peut inspirer confiance ou déclencher la méfiance selon la manière dont vous le formatez. Quelques règles restent valables d'une boutique à l'autre :

• Arrondissez les grands nombres, gardez les petits chiffres exacts. "247 vendus" est crédible parce que c'est précis ; "12 847 vendus" paraît étrangement exact et invite à se demander "est-ce qu'ils l'ont inventé ?" Au-dessus de quelques milliers, "12K+ vendus" ou "10 000+ vendus" semble plus honnête, pas moins.
• Envisagez une période récente. "124 vendus ce mois-ci" signale une demande actuelle, souvent plus persuasive que "5 000 vendus" accumulés silencieusement sur quatre ans. Une fenêtre récente redonne aussi de la force à d'anciens produits dont le total historique est modeste mais dont la dynamique actuelle est réelle. En termes PrestaShop, cela correspond à une somme bornée par date sur ps_order_detail reliée à la date de commande — plus lourde que la table mise en cache, donc mettez le résultat en cache.
• Placez-le dans la zone de décision. Le compteur doit se trouver près du prix et du bouton d'ajout au panier, là où le client prend réellement sa décision — pas enterré en bas de page ni caché dans un onglet. Dans le template produit, cela correspond à la zone des hooks displayProductActions / displayProductPriceBlock ; un compteur rendu trop bas dans displayFooterProduct perd l'essentiel de son effet psychologique. (Pour savoir où placer chaque élément de la page et pourquoi, consultez notre guide sur l'anatomie d'une page produit.)

Le compteur historique et le bandeau en direct — ne les confondez pas

C'est cette distinction qui détermine l'outil dont vous avez réellement besoin. Un compteur total de produits vendus est une donnée stable et cumulative — elle évolue lentement, se met en cache sans risque, et son message est "beaucoup de personnes, au fil du temps, ont choisi ce produit". C'est le sujet de cet article. Il est différent des signaux en temps réel de la même famille :

• Ventes en direct et statistiques de consultation — "9 personnes ont acheté ce produit aujourd'hui / 23 le consultent maintenant" — parlent de dynamique et de simultanéité, avec un recalcul constant. C'est un autre choix, traité dans notre article sur l'affichage des ventes et vues en direct.
• Popups d'achat récent — le toast qui glisse à l'écran avec "Anna à Cracovie vient de commander ce produit" — sont des notifications de ventes en direct et des popups de vente, qui créent un sentiment d'immédiateté plutôt qu'un poids accumulé.

Quelle est donc la conclusion pratique ? Le compteur historique et le bandeau en direct répondent à des objections différentes. "Est-ce un choix sûr ?" est couvert par le volume accumulé ; "est-ce que cela se passe maintenant ?" est couvert par les données en direct. Beaucoup de boutiques utilisent les deux — mais choisissez le compteur statique lorsque vous voulez une réassurance calme et durable, qui n'a pas besoin d'un pic de trafic pour paraître convaincante.

L'ajouter à une page produit PrestaShop

PrestaShop ne propose pas nativement de badge "total vendu" en front-office, il faut donc l'ajouter. Trois voies existent, par ordre d'effort croissant :

La voie du module existe précisément parce que les exigences qui rendent un compteur de ventes sûr — exclure les commandes annulées, masquer les faibles volumes, arrondir les grands nombres, lire la table ps_product_sale mise en cache au lieu d'additionner les détails de commandes à chaque chargement — sont délicates à gérer à la main et faciles à rater. Un module conçu pour cela s'accroche à la page produit en une seule installation, évite de placer une requête lourde sur le chemin critique, et se configure entièrement depuis votre back-office plutôt que via une facture de développement. Si un compteur s'inscrit dans un plan plus large pour mieux convertir vos pages produit, notre guide de conception et de conversion des pages produit montre comment il s'articule avec les autres éléments.

Un mot sur les performances — car c'est là que les compteurs maison se trompent

La version naïve d'un compteur de ventes lance un SELECT SUM(product_quantity) … GROUP BY sur ps_order_detail à chaque affichage de page produit. Sur une boutique avec un historique de commandes profond et un trafic correct, c'est un ralentissement auto-infligé sur votre page la plus importante. Deux défenses, par ordre de préférence : lire la table préagrégée ps_product_sale (PrestaShop la maintient déjà via la classe ProductSale lorsque les commandes sont validées, le coût est donc payé une fois en arrière-plan, pas à chaque visiteur) ; et si vous devez calculer une fenêtre personnalisée, mettre le résultat en cache par produit avec un TTL raisonnable afin que la base de données soit sollicitée occasionnellement, pas en permanence. Un compteur qui dégrade le temps de chargement de vos pages fait l'inverse de ce qu'il devrait faire pour vos ventes — les pages lentes font partir précisément les clients que le badge devait rassurer.

La place du compteur de ventes dans votre écosystème de preuve sociale

Un compteur de ventes est une pièce d'un tableau de confiance plus large, et il fonctionne le mieux lorsque les pièces autour de lui tirent dans le même sens. Le chiffre quantitatif se combine naturellement avec les signaux qualitatifs : les notes en étoiles et les avis répondent à "les clients ont-ils été satisfaits ?" ; les badges de confiance répondent à "le paiement est-il sécurisé ?" ; et les signaux en direct — ventes et vues ou une popup d'achat récent — répondent à "est-ce que cela se passe maintenant ?" La contribution propre du compteur historique est un poids durable, accumulé : la preuve que le chemin sur lequel vous invitez un acheteur hésitant a déjà été emprunté, des milliers de fois, par des personnes qui ont payé et sont revenues simplement avec le produit qu'elles voulaient.

Choisissez correctement le chiffre source (ventes réelles, commandes valides uniquement), affichez-le seulement lorsqu'il valorise le produit, formatez-le pour qu'il paraisse honnête, placez-le là où se prend la décision, et gardez la requête hors du chemin critique de chargement de page. Faites cela, et une donnée que votre base enregistre discrètement depuis votre première commande commence à jouer son rôle au moment exact où un client décide s'il peut vous faire confiance.

FAQ

Quel chiffre PrestaShop correspond aux vraies "unités vendues" ?

C'est la somme de product_quantity dans ps_order_detail sur les commandes valides — pas le stock. Le stock disponible se trouve dans ps_stock_available.quantity et indique ce qu'il reste à vendre, soit l'inverse de ce qui a été vendu ; l'afficher comme "vendu" est l'erreur la plus courante. PrestaShop conserve aussi un agrégat mis en cache dans ps_product_sale, maintenu par sa classe ProductSale lorsque les commandes sont validées, et c'est le chiffre le plus léger à lire sur une page produit très consultée.

Le compteur de ventes inclut-il les commandes annulées ou remboursées ?

Il ne devrait pas, et c'est précisément l'intérêt de la jointure sur o.valid = 1. Sans ce filtre, vous compteriez les paniers abandonnés et les commandes annulées comme des ventes, ce qui gonflerait le badge. Un compteur gonflé ne se contente pas d'exagérer — dès qu'un client sent que le chiffre est inventé, il passe du statut de signal de confiance à celui de raison de douter de tout le reste de la page.

Un compteur de ventes ne va-t-il pas ralentir mes pages produit ?

Si, si vous le calculez de manière naïve — un SUM ... GROUP BY sur tout l'historique des commandes à chaque affichage de page, sur ce qui est déjà l'une de vos URL les plus fréquentées. Deux défenses, dans l'ordre : lire la table préagrégée ps_product_sale que PrestaShop maintient déjà en arrière-plan, ou, si vous avez besoin d'un chiffre sur une période personnalisée, le calculer une fois et mettre le résultat en cache par produit avec un TTL raisonnable, afin que la base soit sollicitée occasionnellement plutôt qu'à chaque visite.

Tous les produits doivent-ils afficher leur nombre de ventes ?

Non — un compteur n'est un atout qu'au-dessus d'un seuil. "2 vendus" est pire que l'absence de badge, fixez donc un minimum (souvent 25 à 50 unités) et masquez-le en dessous. Désactivez-le complètement pour un positionnement luxe ou édition limitée, où un chiffre élevé contredit le récit d'exclusivité, et soyez prudent sur les produits numériques, où "tout le monde l'a déjà" peut devenir une objection plutôt qu'une réassurance.

Faut-il afficher un total historique ou une période récente ?

Cela dépend de ce que vous voulez signaler. Un total historique ("5 000 vendus") montre une confiance durable et accumulée ; une période ("124 vendus ce mois-ci") montre une demande actuelle et peut redonner de la force à un ancien produit dont le volume total est modeste mais dont la dynamique présente est réelle. La période est plus lourde à calculer, car elle repose sur une somme bornée par date plutôt que sur une lecture en cache, donc mettez le résultat en cache. Beaucoup de boutiques affichent le cadrage qui valorise le mieux le produit concerné.