Quote Request Pro - Formulaire de demande de devis, bloc colonne et bouton flottant pour PrestaShop

Le visiteur qui ne trouve pas de prix

Certains catalogues ne peuvent pas afficher un prix fixe. Fabrication sur mesure, tarifs de gros et B2B, tout ce qui se chiffre au projet : le montant dépend de la réponse à une question que personne n'a encore posée. Le visiteur qui arrive sur cette fiche n'a que deux options : deviner, ou partir.

Ce module lui en offre une troisième. Un formulaire court, placé sur la fiche produit, transforme « je n'ai pas trouvé de prix » en un contact identifié, avec une adresse e-mail à la clé.

Deux emplacements, un seul formulaire

Le formulaire s'affiche à deux endroits qui partagent exactement le même code : le visiteur utilise celui qu'il voit.

Un bloc en colonne vient se greffer sur la colonne gauche ou droite de votre thème — l'installation du module enregistre les deux. Un bouton flottant reste au-dessus de la page et ouvre le formulaire d'une simple pression.

Ce bouton flottant compte plus qu'il n'y paraît, et il vaut mieux être direct sur les raisons. Un bloc en colonne ne peut s'afficher que là où votre thème dessine réellement une colonne. Sur Hummingbird, le thème par défaut de PrestaShop 9, la page d'accueil et les fiches produit occupent toute la largeur et n'ont aucune colonne : un bloc accroché à une colonne n'a nulle part où s'afficher, précisément sur les pages où quelqu'un décide s'il va vous demander un prix. Le bouton flottant ne dépend d'aucune colonne : il couvre donc ces pages. Si votre thème a bien une colonne latérale, utilisez les deux ; s'il n'en a pas, le bouton flottant est le module. Dans tous les cas, il dispose de son propre réglage d'activation.

Ne demandez que ce dont vous avez réellement besoin

Trois éléments sont toujours obligatoires : la description du produit, une adresse e-mail à laquelle répondre et la case de consentement. Tout le reste correspond à un interrupteur sur la page de configuration : le nom du visiteur, l'adresse, la ville, le téléphone, la quantité souhaitée, la destination de livraison, un choix d'urgence, une case « je possède déjà un compte PayPal » et une case « ce serait ma première commande ». Nom, adresse, ville, téléphone, quantité, destination et urgence sont actifs par défaut ; les deux cases à cocher sont désactivées.

Coupez tout ce que vous n'exploiterez pas. Un formulaire qui pose quatre questions est bien plus souvent terminé qu'un formulaire qui en pose neuf, et rien de ce que vous désactivez n'est enregistré, même si quelque chose venait à le poster.

Les clients connectés ne saisissent jamais deux fois leurs coordonnées

Si le client est connecté, le module reprend son nom et son adresse e-mail depuis son compte et n'affiche pas ces champs du tout. Les visiteurs non identifiés, eux, les renseignent. Le formulaire que voit un client fidèle est réellement plus court que celui présenté à un inconnu.

Chaque demande est conservée, pas seulement envoyée par e-mail

Les demandes sont écrites dans la table dédiée du module avant toute tentative d'envoi d'e-mail, puis listées sous un onglet Quote Requests (demandes de devis) de la page de configuration. Vous pouvez filtrer par All, New ou Handled (toutes, nouvelles, traitées), parcourir la liste vingt par vingt, ouvrir n'importe quelle demande dans un panneau de détail, la marquer comme traitée ou la repasser en nouvelle, et la supprimer.

Le panneau de détail montre tout ce que le visiteur a envoyé, avec des badges pour les signaux qui comptent d'un coup d'œil — Urgent, Possède un compte PayPal, Premier achat — ainsi que le texte complet du produit et l'adresse IP d'où provient la demande.

C'est ce qui fait du module un véritable outil, et pas un simple formulaire. Un serveur de messagerie en panne un mauvais jour ne peut pas faire perdre un contact : la demande est déjà enregistrée, et un envoi en échec part dans vos logs au lieu de s'afficher au client.

Deux e-mails, pas un seul

Une notification marchand part vers les adresses que vous désignez : saisissez-en plusieurs, séparées par des virgules, elles la recevront toutes.

Le client reçoit lui aussi un e-mail. Il confirme la bonne réception de sa demande et récapitule ce qu'il a demandé — toute la différence entre un client qui attend votre réponse et un client qui se dit que le formulaire ne marchait pas et achète ailleurs.

Une carte de notification sur le tableau de bord

Quand des demandes de devis sont en attente, une carte apparaît en haut du tableau de bord du back-office, avec leur nombre et un lien direct vers la liste. Elle disparaît d'elle-même dès que toutes les demandes ont été traitées ou supprimées : c'est un indicateur de tâches à faire, pas un meuble permanent.

Elle est accrochée au hook dashboardZoneOne de façon délibérée. Le choix évident, displayDashboardTop, se déclenche en réalité sur la plupart des pages d'administration affichant une rangée d'indicateurs — Performances comprise — si bien que la carte vous aurait suivi dans tout le back-office au lieu de rester sur le tableau de bord, à sa place.

Pas de CAPTCHA, et ce n'est pas un compromis

La version 1.x proposait une question de calcul. La version 2 la supprime et protège le formulaire de trois façons, dont aucune n'est visible pour un vrai visiteur :

Un champ pot de miel (honeypot) que les humains ne voient jamais et que les robots remplissent — et lorsqu'il est rempli, le formulaire annonce poliment un succès et écarte discrètement l'envoi, sans donner au robot le moindre signal qu'il a été démasqué. Un jeton de temps signé, une signature HMAC-SHA256 portant sur l'instant où le formulaire a été affiché : l'envoi est refusé s'il arrive moins de trois secondes après le chargement de la page, ou plus d'une heure après. Et une limitation par IP qui accepte au maximum cinq demandes par heure depuis la même connexion.

Rien à configurer, et aucune énigme à résoudre.

Fonctionne aussi quand JavaScript est désactivé

Avec JavaScript, le formulaire s'envoie en arrière-plan et laisse place à un message de confirmation. Sans lui, le formulaire est posté normalement, le serveur le traite exactement de la même manière et le visiteur revient sur la page d'où il vient, avec un message de succès ou d'erreur affiché en haut.

L'adresse de retour est vérifiée par rapport au nom de domaine de votre propre boutique avant la redirection : le formulaire ne peut donc pas servir à rediriger quelqu'un vers un autre site.

Une image promotionnelle et vos propres liens

La page de configuration accepte une image promotionnelle facultative, téléversée directement, sans aucun chemin de fichier à deviner. Elle est redimensionnée pour tenir dans 400 × 280 pixels en conservant ses proportions, et ré-encodée plutôt que simplement déplacée : impossible donc de faire passer quoi que ce soit sur votre serveur en l'accolant à un fichier image valide. JPG, PNG, GIF et WEBP, jusqu'à 4 Mo.

Trois liens l'accompagnent, chacun paramétrable par langue : un lien En savoir plus vers une page expliquant votre fonctionnement en matière de devis, ainsi que les URL de vos Conditions générales et de votre Politique de confidentialité. Laissez le champ Conditions générales vide et le module pointe vers la page CMS Conditions générales déjà configurée dans votre boutique. Laissez le champ Confidentialité vide et le lien n'est tout simplement pas affiché. Une case de consentement est toujours affichée et toujours obligatoire.

Multiboutique, et un module qui se répare tout seul

Les réglages sont stockés par boutique : dans une installation multiboutique, chaque boutique a ses propres destinataires, ses propres choix de champs et ses propres liens. Si une boutique se retrouve sans ligne de réglages — ajoutée après l'installation, ou perdue d'une autre manière — elle est créée à la volée, au lieu de laisser le formulaire se casser silencieusement pour cette boutique.

L'ouverture de la page de configuration réaffirme également les hooks et le schéma de base de données du module, et synchronise le numéro de version enregistré. Le bouton Mettre à jour de la liste des modules de PrestaShop peut échouer pour des raisons qui échappent à tout module : plutôt que d'en dépendre, le module converge vers l'état correct chaque fois qu'un administrateur vient réellement le consulter.

Compatibilité

PrestaShop 1.7 à 9, en huit langues : néerlandais, anglais, français, allemand, italien, polonais, espagnol et turc.

Une réserve, en toute franchise : les modèles d'e-mail ne sont fournis qu'en anglais, français, espagnol et turc. Le formulaire vu par vos visiteurs et la totalité du back-office sont traduits dans les huit langues ; les deux e-mails, non.

Cinq hooks standard, aucun override et aucune modification du thème. PrestaShop 1.4, 1.5 et 1.6 ne sont plus pris en charge : la version 2.0.0 les a abandonnés, en même temps que l'ancien CAPTCHA arithmétique côté navigateur et le manuel PDF fourni, remplacé par l'onglet Tutoriel intégré au module.

Foire aux questions

Les visiteurs doivent-ils résoudre un CAPTCHA ?

Non, et aucun réglage ne permet d'en activer un. La protection repose sur un champ pot de miel caché, un jeton de temps signé en HMAC qui refuse les envois arrivant moins de trois secondes ou plus d'une heure après le chargement de la page, et une limite de cinq demandes par heure depuis une même adresse IP. Un vrai visiteur n'en voit rien.

Où le formulaire apparaît-il ?

À deux endroits. Un bloc en colonne se place dans la colonne gauche ou droite de votre thème, et un bouton flottant reste au-dessus de la page et ouvre le même formulaire. Le bouton flottant dispose de son propre réglage d'activation ; le bloc en colonne, lui, dépend de son accrochage à un hook de colonne dans Apparence → Positions et du fait que votre thème dessine réellement une colonne sur cette page. Sur Hummingbird, le thème par défaut de PrestaShop 9, la page d'accueil et les fiches produit n'ont aucune colonne : c'est donc le bouton flottant qui les couvre. Si votre thème n'a pas de colonnes latérales sur mobile — c'est le cas de beaucoup — le bouton flottant sera le seul point d'entrée de vos visiteurs sur smartphone.

Le formulaire ne s'affiche pas en front-office.

Ouvrez Apparence → Positions, cherchez priceandorder et vérifiez qu'il est bien accroché à un hook de colonne pour le bloc en colonne, et au hook de pied de page pour le bouton flottant. L'installation du module accroche les deux hooks de colonne : le problème ne se pose donc généralement que sur un thème personnalisé.

Si le bouton flottant s'affiche mais que le bloc en colonne n'apparaît jamais, le hook est probablement correct et c'est le thème qui est en cause : beaucoup de thèmes n'affichent qu'une colonne gauche, voire aucune sur les pages pleine largeur. Hummingbird dessine une colonne gauche sur les pages de catégorie et aucune colonne droite nulle part. Déplacez le module vers la colonne que votre thème utilise réellement, et comptez sur le bouton flottant pour les pages pleine largeur.

Quels champs puis-je retirer ?

Tous, sauf la description du produit, l'adresse e-mail et la case de consentement. Adresse, ville, téléphone, quantité, destination de livraison, urgence, la question PayPal et la question sur la première commande sont chacune un interrupteur. Le nom du visiteur est également un interrupteur, et il est automatiquement ignoré pour les clients connectés, tout comme leur adresse e-mail.

Où arrivent les demandes ?

Vers les adresses de notification que vous définissez — plusieurs si vous le souhaitez, séparées par des virgules — et dans l'onglet Quote Requests (demandes de devis) de la page de configuration du module. Vous y filtrez par All, New ou Handled (toutes, nouvelles, traitées), parcourez la liste vingt par vingt, ouvrez chaque demande dans un panneau de détail, la marquez comme traitée et la supprimez. Les demandes sont enregistrées avant tout envoi d'e-mail : un problème de messagerie ne peut donc pas en faire perdre une.

Le client reçoit-il une confirmation ?

Oui. Deux e-mails partent : un pour vous et un pour la personne qui a rempli le formulaire, confirmant ce qu'elle a demandé. L'e-mail client existe en anglais, français, espagnol et turc.

Aucun e-mail de notification n'arrive.

Vérifiez d'abord l'adresse destinataire dans les réglages : si aucune n'est définie, un avertissement s'affiche à côté du module dans la liste des modules. Contrôlez ensuite votre dossier de courrier indésirable et confirmez que l'envoi de courrier fonctionne, dans Paramètres avancés → E-mail. Chaque envoi en échec est consigné dans Paramètres avancés → Logs, et la demande elle-même se trouve de toute façon dans l'onglet Quote Requests.

Un visiteur signale que le formulaire a refusé son envoi.

C'est presque toujours la protection anti-spam automatique. L'envoi est arrivé moins de trois secondes après le chargement de la page, plus d'une heure après ce chargement, ou bien c'était le sixième envoi depuis cette connexion en une heure. Demandez-lui de recharger la page et de réessayer.

Je ne vois pas la carte de notification du tableau de bord.

La carte n'apparaît que sur le tableau de bord lui-même, et uniquement tant qu'au moins une demande est encore marquée New. Si des demandes sont en attente et qu'elle ne s'affiche toujours pas, allez dans Apparence → Positions, vérifiez le hook dashboardZoneOne et assurez-vous que priceandorder y est bien accroché et activé : ce réglage est indépendant des hooks du front-office.

Cela fonctionne-t-il si le visiteur a désactivé JavaScript ?

Oui. Le formulaire bascule sur un envoi de page classique, le serveur le traite de façon identique, et le visiteur revient sur la page où il se trouvait avec un message de confirmation ou d'erreur. Rien n'est perdu.

L'image promotionnelle paraît étirée ou se fait refuser.

Elle ne devrait pas être étirée : l'image est ajustée à l'intérieur de 400 × 280 pixels en conservant ses proportions, jamais déformée. Les refus viennent en général du format ou du poids : JPG, PNG, GIF et WEBP sont acceptés, jusqu'à 4 Mo.

Le lien Conditions générales ou Politique de confidentialité est absent ou incorrect.

Définissez les deux explicitement dans les réglages, langue par langue, et commencez chaque URL par http:// ou https:// — le module refuse tout le reste. Un champ Conditions générales vide bascule sur la page CMS Conditions générales de votre boutique ; un champ Confidentialité vide masque simplement ce lien.

Que deviennent mes réglages lors de la mise à jour depuis la 1.x ?

Ils sont migrés automatiquement. Vos interrupteurs de champs passent au nouveau schéma, votre adresse destinataire est conservée, la table de journal des demandes de devis est ajoutée, et les clés de configuration résiduelles des très anciennes installations sont nettoyées.