Feature Requests & Voting est un module pour les boutiques PrestaShop qui recueille les demandes de fonctionnalités des clients sur la page produit elle-même et les transforme en demande comptée et votée. L’installation ajoute l’onglet de demandes, les tableaux et l’écran de réglages ; l’activer constitue toute la mise en route.
Le problème qu’il règle est la demande éparpillée. Les souhaits arrivent par mail au support, par chat et dans les avis, et personne ne les compte, si bien que la prochaine décision de développement suit la voix la plus forte au lieu du plus grand nombre. Les tableaux de retours hébergés mesurent la demande, mais ils vivent hors de la boutique, facturent un abonnement mensuel par tableau et ignorent tout de votre catalogue.
Le module s’ouvre simplement et se gouverne en profondeur. Les clients déposent une demande et votent directement sur la page produit, et les mêmes enregistrements alimentent trois surfaces : l’onglet de chaque produit, un tableau par produit et une feuille de route publique couvrant toute la boutique, consultable et groupée par statut : déposée, à l’étude, planifiée, en cours, réalisée. Vous décidez qui participe : dépôt ouvert à tous ou réservé aux clients connectés, nouvelles demandes retenues pour votre approbation avant d’être visibles, vote des invités autorisé ou non, avec un vote par client.
Vous gouvernez aussi ce que voit le public : compteurs de votes, badges de statut et réponses de l’équipe ont chacun leur interrupteur, et une discussion sous chaque demande permet aux clients d’ajouter des détails et à votre équipe de répondre publiquement. Les demandes en double fusionnent en une seule en conservant chaque vote. Les pages héritent du thème de la boutique, existent dans chaque langue avec des adresses propres, et le tableau principal participe à la recherche pendant que les pages filtrées en restent écartées. Chaque demande enregistre sa boutique et sa langue, les données ne quittent pas la boutique, et rien de personnel n’atteint le navigateur.
Le résultat : une feuille de route bâtie sur une demande comptée plutôt que sur des mails retenus de mémoire, des clients qui voient « planifiée » et restent au lieu de partir, des pages de demandes qui mènent les chercheurs droit au produit qui gagnera la fonctionnalité, et un tableau de retours sans abonnement.
Aperçu des possibilités du module
Feature Requests & Voting transforme les souhaits de fonctionnalités en feuille de route mesurable et liée aux produits, à l’intérieur d’une boutique PrestaShop. L’aperçu ci-dessous parcourt les six parties de cette page.
- Les demandes là où elles naissent : un onglet déposer-et-voter sur la page produit elle-même.
- Trois surfaces, un seul jeu de données : onglet produit, tableau par produit et feuille de route de toute la boutique.
- Règles de participation : connexion exigée, file d’approbation, vote des invités, un vote par client.
- Conversation et consolidation : discussions avec réponses de l’équipe, doublons fusionnés votes conservés.
- Un tableau qui se positionne : adresses propres et localisées, participation du tableau principal à la recherche, liens vers les produits.
- Le tri à grande échelle : tableau de bord, liste filtrable, changements de statut en masse, notifications.

Où les clients demandent-ils, et pourquoi est-ce décisif ?
Sur la page produit, à l’instant précis où ils remarquent ce qui manque. La demande voyage avec le produit qu’elle concerne : « ajoutez une version avec câble plus long » n’est jamais une note volante, c’est un souhait compté rattaché à un article du catalogue. Le vote se tient à côté : une pression, un vote par client, les votes d’invités étant dédoublonnés.
Les mêmes enregistrements s’affichent de trois façons sans travail supplémentaire : l’onglet de chaque produit, le tableau complet de ce produit et la feuille de route de toute la boutique où toutes les demandes se rejoignent, consultable et groupée par statut. La conséquence : la demande cesse d’être une anecdote. La capacité à quarante votes et celle à deux ont enfin des tailles différentes.

Qui a le droit de déposer et de voter ?
Vous en décidez, par interrupteurs. Dépôt ouvert à chaque visiteur ou réservé aux clients connectés. Les nouvelles demandes attendent dans votre file d’approbation et restent cachées jusqu’à votre feu vert, si bien que spam et doublons n’atteignent jamais le tableau public. Le vote s’active ou se coupe en bloc, le vote des invités est une décision à part, et chaque client vote une fois par demande.
L’affichage suit la même logique : compteurs de votes, badges de statut et réponses de l’équipe ne paraissent que si vous les activez. Une jeune boutique montre les demandes sans compteurs tant que les chiffres ne convainquent pas ; une boutique établie montre tout.

Que devient une demande après son dépôt ?
Elle reçoit un cycle de vie : déposée, à l’étude, planifiée, en cours, réalisée, chaque état porté par un badge que le client comprend. Sous chaque demande court une discussion où les clients précisent et où votre équipe répond publiquement, le raisonnement restant à côté du souhait. Quand deux personnes demandent la même chose en d’autres mots, vous fusionnez les doublons en une demande et chaque vote est conservé.
La conséquence touche la fidélité : le client qui voit « planifiée » sur son souhait reste, et celui qui voit « réalisée » revient acheter. Un tableau d’idées qui répond est une raison de revenir ; une boîte silencieuse, non.

Un tableau de retours aide-t-il la boutique à se positionner ?
Celui-ci, oui, à dessein. Les pages de demandes portent des adresses propres dans chaque langue de la boutique, un comportement canonique correct et une pagination nette. Le tableau public participe à la recherche et au plan du site quand vous l’autorisez, tandis que pages de détail et pages filtrées en restent volontairement écartées : la boutique gagne une page indexée forte au lieu de mille pages minces. Une adresse de demande ouverte dans la mauvaise langue redirige vers la bonne.
Ainsi la personne qui cherche exactement la capacité que vous bâtissez atterrit sur votre feuille de route, à un lien du produit qui la portera. Un tableau hébergé dans un cadre n’offre rien aux moteurs ; celui-ci leur offre une page digne d’un classement.
Comment l’équipe suit-elle quand les demandes se multiplient ?
Le tableau de bord montre la charge par boutique : totaux, demandes récentes, idées les plus votées et répartition des statuts. La liste des demandes filtre par produit, statut et votes, change les statuts en masse et porte une note privée par demande. Un e-mail vous prévient de chaque nouvelle demande, à l’adresse de votre choix.
Tout reste dans la boutique : les pages héritent automatiquement de votre thème, seuls des fichiers locaux sont servis aux acheteurs, en multiboutique chaque demande appartient à sa boutique et à sa langue, et les réponses publiques ne portent ni e-mail du client, ni adresse, ni identité. Les données de demande de vos clients vous appartiennent.

-
Référencemprfeaturerequest
-
Compatibilité PrestaShopPS 1.7 – 9.x
-
Modèle tarifaireAchat unique
-
Type de moduleFront & Back-office
-
Concerne le RGPDOui
-
Objectif commercialCommunication client
-
Compte externe requisNon
-
Complexité du moduleModule complet
-
Étape du parcours clientFidéliser les clients
-
Compatible avec la plateformeAucune plateforme externe
Ce que nos clients disent de nous
Soyez le premier à partager votre expérience avec ce module.
Écrire un avis
Offrez à vos clients un espace dédié sur les pages produit pour proposer des améliorations, voter pour les idées qui les intéressent et suivre votre roadmap publique. Feature Requests & Voting transforme les messages récurrents du type « pouvez-vous ajouter ceci ? » en un tableau de demandes visible, avec nombre de votes, statuts, réponses de l’administrateur et hub de roadmap que vous pouvez lier depuis votre boutique.
- AddedFinalize feature request hub SEO cleanup
- AddedComplete feature request SEO hub
- AddedRebuild public feature request hub
Fonctionne bien avec Demandes de fonctionnalités & votes
Les modules que notre équipe associe réellement à celui-ci, et pourquoi chacun a sa place dans la même configuration.
Feature Requests & Voting offre aux clients un tableau visible pour suggérer des idées et voter sur les changements qui comptent le plus, en reliant les demandes aux produits et en donnant à votre équipe un flux de feuille de route dans le Back Office. Une fois que vous avez décidé quoi construire ou modifier, il vous faut aussi un endroit pour en informer les clients.
Blog Revolution couvre ce besoin comme un outil distinct, un espace natif pour les guides d'achat, les annonces et les conseils, avec catégories, étiquettes, auteurs, commentaires et des pages de blog soignées capables d'attirer du trafic de recherche et d'orienter les lecteurs vers les produits.
Utilisés côte à côte, Feature Requests & Voting recueille et priorise les retours des clients tandis que Blog Revolution communique les résultats et les actualités plus larges. L'un écoute et l'autre annonce ; ensemble ils bouclent une partie de la boucle, de sorte que les clients voient leurs idées prises en compte et lisent ce qui change, gardant l'engagement et le contenu orientés dans la même direction.
Feature Requests & Voting donne aux clients un espace public pour proposer des idées et voter, transformant des retours dispersés en une feuille de route gérée, avec des demandes reliées aux produits. Les idées publiques sont tournées vers l'avenir, mais les clients ont aussi des problèmes privés et immédiats qui n'ont pas leur place sur un tableau ouvert.
Support Revolution couvre ces cas comme un outil distinct, un service d'assistance PrestaShop avec historique des tickets, identité du client et contexte de commande, plus des tickets invités facultatifs, pour traiter les problèmes individuels.
Utilisés côte à côte, Feature Requests & Voting recueille les suggestions communes et publiques tandis que Support Revolution gère l'aide privée, au cas par cas. Ce sont des outils indépendants servant différents types de contact ; ensemble ils donnent aux clients à la fois une voix sur ce qui est construit et un parcours clair pour les problèmes personnels, afin que les retours et le support aient chacun leur bonne place plutôt que d'être mélangés dans un seul canal.
Feature Requests & Voting permet aux clients de suggérer de futures améliorations et de voter, en donnant à votre équipe une feuille de route gérée de ce que les gens veulent ensuite. Cela capte les souhaits de ce qui devrait changer ; cela ne communique pas l'état actuel des problèmes connus sur les produits existants.
Issue Tracker couvre ce besoin comme un outil distinct, en publiant un flux de problèmes connus et de FAQ produit, avec un onglet de problèmes sur la page produit affichant les compteurs ouverts et totaux, des badges de statut et les corrections résolues.
Utilisés côte à côte, Feature Requests & Voting regarde vers l'avant, vers les changements souhaités, tandis qu'Issue Tracker est transparent sur les limites et les corrections actuelles. L'un rassemble les aspirations et l'autre rapporte la réalité ; ensemble ils donnent aux clients une vue honnête et à deux faces, ce qui est demandé et ce qui est actuellement ouvert ou résolu, ce qui renforce la confiance et réduit les contacts au support liés à la surprise.
Chargement des demandes de fonctionnalités...
Retour simple - sans questions
Installer, configurer et profiter
Aide et satisfaction avant tout