Produits récemment consultés : aider les clients à retrouver ce qu’ils avaient oublié

Presque personne n’achète lors de sa première visite. Un client trouve un produit qui lui plaît, il est interrompu par un appel ou ferme un onglet, puis revient une heure, ou un jour, plus tard avec un problème : il ne se souvient plus exactement de ce qu’il regardait. Il sait que c’était « le modèle gris avec la poignée en bois », mais votre boutique en propose quarante du même genre. Il cherche, ne trouve pas, puis s’en va. Un bloc produits récemment consultés résout précisément ce moment : il remet sous les yeux du client les produits qu’il avait déjà choisis, afin que le trajet entre « je reviens » et « ajouter au panier » tienne en un clic au lieu de devenir une recherche frustrante.

Dernière mise à jour : juin 2026.

Cet article traite de cette seule mission : combler l’écart entre l’intention d’achat et le bouton retour en mémorisant ce qu’un visiteur a regardé. Il ne s’agit pas de suggérer des produits qu’il n’a pas vus (c’est de la vente croisée et de la montée en gamme) ni d’enregistrer volontairement des produits pour plus tard (c’est une liste d’envies). Les produits récemment consultés fonctionnent de façon automatique, passive, et reposent sur une vérité simple : reconnaître est plus facile que se rappeler.

Ce que PrestaShop fournit déjà, et où cela s’arrête

PrestaShop propose une fonctionnalité de produits récemment consultés depuis des années, et la plupart des marchands ne savent pas qu’elle est déjà installée. Dans les versions 1.7, 8 et 9, il s’agit du module natif ps_viewedproduct (« Bloc produits vus ») ; en 1.5/1.6, il s’appelait blockviewed. Vous le trouverez dans Modules → Gestionnaire de modules, recherchez « viewed ». Il affiche les produits consultés sur la page produit, généralement via displayFooterProduct (l’ancien blockviewed de la version 1.6 utilisait les hooks de colonnes), et son seul réglage configurable est le nombre de produits à afficher.

Sous le capot, il n’interroge ni commande ni compte client : il lit un cookie de navigateur nommé viewed, une simple liste d’ID de produits séparés par des virgules que le ProductController complète à chaque chargement d’une page produit. Cette conception a deux conséquences à connaître avant de décider si le module standard vous suffit :

• Il est anonyme et immédiat. Comme il repose sur un cookie, il fonctionne pour les visiteurs non connectés dès le tout premier produit ouvert, sans connexion, sans compte. Il utilise un cookie de navigateur ; gérez l’information et le consentement conformément à votre politique de cookies et au droit local. Et concrètement ? Le client qui ne créera jamais de compte en profite quand même.
• Il oublie quand le cookie disparaît. La liste vit dans le navigateur du visiteur. Supprimez les cookies, passez du téléphone à l’ordinateur portable, ou laissez le cookie expirer : l’historique disparaît. Le module natif ne tente pas d’associer les vues à un ID client pour les suivre d’un appareil à l’autre.

Pour un petit catalogue placé dans une barre latérale, le module standard convient vraiment, ne payez pas pour ce que vous avez déjà. Les raisons qui poussent les marchands à le dépasser sont précises : l’emplacement par défaut (colonne gauche/droite) est un espace mort sur la plupart des thèmes modernes en pleine largeur ; il ne peut pas être placé sur la page panier, là où le rappel « avez-vous oublié ces produits ? » est le plus fort ; et il ne survit pas à un changement d’appareil. Ce sont les lacunes qu’un module dédié est conçu pour combler, comme nous le verrons plus bas.

Pourquoi les « produits récemment consultés » font vraiment le travail

Le mécanisme relève de la psychologie cognitive la plus simple : la reconnaissance l’emporte sur le rappel. Demander à un client de se souvenir du nom d’un produit et de le retaper, c’est lui demander un effort ; lui montrer une miniature de l’article exact qu’il regardait ne lui demande que de le reconnaître. La première option est laborieuse et échoue souvent ; la seconde est immédiate.

Il y a un second effet, facile à sous-estimer. Un visiteur qui revient sur une page d’accueil générique doit retrouver ses repères : reparcourir les catégories, filtrer à nouveau, redécider. Un visiteur qui voit immédiatement les trois produits qu’il comparait une heure plus tôt est replacé directement dans la décision qu’il avait déjà commencée. Vous ne créez pas un nouvel intérêt ; vous reprenez un intérêt qui existe déjà, ce qui coûte beaucoup moins cher que de le générer.

Il est tentant d’ajouter ici un chiffre de conversion bien net, et vous verrez sur le web des formules du type « X % des clics sur les produits récemment consultés convertissent ». Traitez ces chiffres comme des indications, pas comme une promesse : le gain réel dépend de la taille de votre catalogue, de la fréquence à laquelle vos clients comparent avant d’acheter, et de la visibilité du bloc. L’argument honnête est mécanique, pas statistique : chaque client qui aurait abandonné faute de retrouver un produit est un client que vous n’avez pas perdu. Mesurez-le sur votre propre boutique au lieu d’emprunter le pourcentage de quelqu’un d’autre.

Où le placer, et pourquoi l’emplacement change son rôle

Le même bloc ne rend pas le même service selon l’endroit où il apparaît. Décidez d’abord de ce que vous voulez qu’il accomplisse, puis placez-le en conséquence :

Un point utile avant de chercher un module : sur PrestaShop 1.7, 8 et 9, ps_viewedproduct implémente l’interface widget. Vous pouvez donc le rendre partout où votre thème vous permet d’appeler un widget, en ajoutant une seule balise dans le template à l’endroit où vous souhaitez afficher le bloc, sans enregistrer de nouveau hook :

{* render the viewed-products block in any theme template *}
{widget name='ps_viewedproduct'}

Cela couvre un emplacement ponctuel, par exemple l’ajout du bloc à un template de page d’accueil personnalisé. Ce que cela ne résout pas, ce sont les limites du cookie, et le module natif ps_viewedproduct reste par ailleurs limité à son emplacement intégré sur la page produit ; il ne propose pas de placement arbitraire sur le panier, l’accueil ou un hook personnalisé sans travail côté thème ou module. C’est pourquoi l’emplacement sur la page panier, sans doute le plus précieux, nécessite généralement un module plus flexible. Si vous repensez toute la mise en page au passage, notre guide plus large sur la conception des pages produit PrestaShop explique comment un bloc de produits récemment consultés doit cohabiter avec tout le reste sous la ligne de flottaison.

Les réglages qui comptent vraiment

Trois décisions déterminent si le bloc aide réellement ou ne fait qu’ajouter du bruit :

• Combien de produits afficher. Six à huit est le bon compromis pratique : assez pour raviver la mémoire, assez peu pour être parcouru d’un coup d’œil. Dans une mise en page sur une seule ligne, cela correspond au nombre de produits qui remplissent proprement la rangée ; un mur de vingt produits consultés cesse d’être une aide-mémoire et devient du bruit.
• Ne jamais l’afficher vide. Un nouveau visiteur n’a pas d’historique, le bloc n’a donc rien à afficher. Assurez-vous qu’il se masque entièrement lorsque le cookie viewed est vide, plutôt que de rendre un titre vide : un intitulé « Produits récemment consultés » isolé, sans rien dessous, donne l’impression d’un élément cassé et entame la confiance. Le module natif le gère ; un bloc de thème personnalisé, pas toujours. Vérifiez-le hors connexion dans un navigateur fraîchement ouvert.
• Exclure le produit actuellement affiché. Sur une page produit, l’article que le client regarde à cet instant ne doit pas apparaître dans sa propre rangée de « produits récemment consultés ». C’est redondant et cela occupe une place inutile. Vérifiez que votre module filtre l’ID du produit courant.

Sur mobile, remplacez la grille par un carrousel horizontal défilant. L’espace vertical est ce qu’il y a de plus rare sur un écran de téléphone ; une seule rangée que l’on peut faire défiler au doigt montre les mêmes produits sans repousser le bouton « ajouter au panier » plus bas dans la page. Une grille qui impose trois lignes de défilement sur mobile fait généralement plus de mal que le bloc ne fait de bien.

Quand aller au-delà du module natif

Vous dépassez ps_viewedproduct lorsque l’une de ses limites intégrées commence à vous coûter des commandes. Les signaux les plus clairs :

Le passage d’un appareil à l’autre est le point qui distingue vraiment les deux approches. Un acheteur qui parcourt votre boutique sur son téléphone à midi et achète depuis un ordinateur portable le soir est une seule personne pour vous, mais deux boîtes à cookies sans lien pour le module natif : ses recherches du matin s’évaporent donc exactement au moment où elles auraient pu conclure la vente. Un module qui associe les produits récemment consultés à l’ID client pour les utilisateurs connectés (en stockant l’historique côté serveur plutôt que dans le navigateur) transporte cet historique d’un appareil à l’autre. Si une part significative de votre trafic achète sur plusieurs appareils, et c’est le cas de la plupart des boutiques, c’est la fonctionnalité qui mérite d’être payée. mypresta.rocks construit des modules de personnalisation précisément autour de ce type de comportement conscient du client, sans intervention lourde dans le thème ; le test pratique pour savoir si vous en avez besoin est simple : regardez combien de vos clients commencent une session sur mobile et la terminent sur ordinateur.

Questions fréquentes

PrestaShop intègre-t-il des produits récemment consultés ? Oui, la plupart des marchands ne savent pas que c’est déjà installé. Sur les versions 1.7, 8 et 9, il s’agit du module natif ps_viewedproduct (« Bloc produits vus ») ; sur 1.5/1.6, c’était blockviewed. Vous le trouverez dans Modules → Gestionnaire de modules, en recherchant « viewed ». Son seul réglage concerne le nombre de produits à afficher, et il les affiche sur la page produit (généralement via displayFooterProduct).

Comment mémorise-t-il ce qu’un visiteur a regardé ? Il lit un cookie de navigateur nommé viewed, une liste d’ID de produits séparés par des virgules que le ProductController complète à chaque chargement de page produit. Il ne touche jamais aux commandes ni au compte client. C’est ce qui le rend anonyme et immédiat (il fonctionne pour les visiteurs non connectés dès le premier produit), mais il oublie quand le cookie disparaît : supprimez les cookies ou passez du téléphone à l’ordinateur portable, et l’historique est perdu.

Où faut-il placer le bloc ? L’emplacement change son rôle. Sur la page produit (displayFooterProduct), il aide les acheteurs qui comparent à passer d’un candidat à l’autre, c’est l’emplacement le plus fort. Sur la page d’accueil (displayHome), il réoriente les visiteurs qui reviennent. Sur la page panier (displayShoppingCartFooter), c’est le rappel le plus proche de l’achat : « vous avez aussi regardé ces produits ». L’emplacement dans le panier est généralement le plus précieux, et celui que le module natif ne peut pas gérer seul.

Quand le module standard ne suffit-il plus ? Lorsque l’une de ses limites commence à coûter des commandes : vous devez l’afficher sur la page panier ou sur un hook personnalisé, vous voulez un historique qui suit un client connecté d’un appareil à l’autre (le cookie seul le perd lors d’un changement d’appareil), une vraie mise en page carrousel, ou un filtrage « consulté mais non acheté » dans le panier. Le cas multi-appareils est celui qui sépare vraiment les deux solutions : un module qui rattache l’historique à l’ID client, stocké côté serveur, le conserve dans le passage du téléphone à l’ordinateur portable, là où la vente se conclut souvent.

Combien de produits afficher, et comment sur mobile ? Six à huit est le bon compromis pratique : assez pour raviver la mémoire, assez peu pour être parcouru rapidement. Masquez toujours entièrement le bloc lorsque le cookie est vide (un titre « Produits récemment consultés » isolé donne l’impression d’un élément cassé), et excluez le produit actuellement affiché. Sur mobile, passez d’une grille à un carrousel horizontal défilant sur une seule rangée, afin de ne pas repousser votre bouton d’ajout au panier plus bas dans la page.

Sa place dans une stratégie plus large

Les produits récemment consultés sont un fil discret dans une boutique qui se souvient de ses clients. Ils recoupent l’enregistrement volontaire (une liste d’envies est une intention déclarée par le client ; les produits récemment consultés sont une intention que vous déduisez), et ils complètent la comparaison directe à laquelle les acheteurs ont recours lorsqu’ils n’arrivent pas à choisir entre deux produits. C’est aussi une brique de l’argument plus large que porte une page produit fiable et sans friction : le type d’anatomie de page produit qui pousse les visiteurs à cliquer sur acheter plutôt que sur retour.

L’idée de fond est simple : vous n’essayez pas de convaincre quelqu’un de quelque chose de nouveau. Vous refusez simplement d’obliger un client qui revient à retrouver lui-même le produit qu’il voulait déjà. Sur PrestaShop, cela ne coûte presque rien à activer, ps_viewedproduct se trouve probablement déjà dans votre Gestionnaire de modules, et les seules vraies décisions sont son emplacement, sa présentation sur mobile, et la question de savoir si vos clients achètent sur suffisamment d’appareils différents pour que la mémoire du cookie doive devenir la mémoire du client.