L’essai est l’argument numéro un d’un vélociste physique face aux pure players. Pouvoir enfiler le casque, monter sur la selle, faire un tour devant le magasin — c’est ce qui décide le client sur un vélo à 2000 €.
Encore faut-il que le vélo soit en magasin. Proposer une demande d’essai sur un modèle pas en stock, c’est créer une attente déçue. Le module Demandes d’essai croise le catalogue web et le stock physique du magasin pour n’afficher l’option que sur les modèles réellement présents.
Côté client : le parcours
Sur la fiche d’un vélo dont au moins une unité est en stock magasin (via vlstockphys) ET dont la catégorie est éligible à l’essai (config BO) :
- Apparition d’un bouton « Réserver un essai » sous l’ajout au panier
- Clic ouvre un formulaire en modal : nom, prénom, email, téléphone, créneau souhaité (jour + matin/après-midi), message optionnel
- À la soumission, email envoyé au magasin avec les infos + lien vers la fiche produit
- Confirmation au visiteur : « Le magasin vous recontacte sous 24h pour confirmer le créneau »
Si le vélo n’est pas en stock magasin, le bouton n’apparaît pas. Le visiteur voit simplement les options achat web standard, sans fausse promesse.
Côté technique
Le module repose sur PrestaShop 9 et stocke chaque demande dans une table vlessai_request qui contient l’identifiant produit, l’identifiant de la déclinaison (si applicable), les coordonnées du visiteur, le créneau souhaité, le statut courant et la date d’arrivée.
L’affichage conditionnel du bouton « Réserver un essai » s’effectue via le hook displayProductAdditionalInfo, qui combine deux vérifications avant de rendre le bouton. La première consulte la table vlstockphys_unit pour confirmer qu’au moins une unité physique est rattachée au produit (et à la bonne déclinaison s’il y a lieu). La seconde consulte les catégories du produit et la configuration BO pour vérifier que la catégorie est marquée comme éligible à l’essai. Si les deux conditions sont remplies, le bouton apparaît ; sinon il reste caché.
La soumission du formulaire passe par un controller AJAX exposé sur /modules/vlessai/ajax.php. Ce controller valide les entrées (regex email, longueur du téléphone, champs requis), applique deux mesures anti-spam — un honeypot invisible aux humains et un rate-limiting de trois demandes par IP et par jour — puis insère la demande en base. Il déclenche enfin un email vers l’adresse du magasin avec les détails formatés dans un template HTML responsive, et renvoie une réponse JSON à la modal qui se ferme avec un message de confirmation.
Au back-office, la liste des demandes est éditable avec un workflow de statut explicite : nouveau, contacté, essai effectué, converti en vente, annulé.
Pourquoi c’est pertinent pour un vélociste
Le pire pour un magasin, c’est qu’un prospect prenne RDV pour essayer un vélo qui n’est pas là. Décourageant pour le client, énervant pour le magasin. Conditionner le formulaire au stock physique réel garantit que chaque demande reçue est exploitable. Et pour le magasin, c’est un flux de leads qualifiés qu’il peut convertir en vente le jour de l’essai.
