Quick Callback Request - Bouton flottant Rappelez-moi, formulaire et liste de demandes PrestaShop, sans CAPTCHA

Le visiteur qui ne remplira jamais un formulaire de contact

Beaucoup de gens veulent acheter, mais ont d'abord une question. Un formulaire de contact réclame un objet, un message et une référence de commande ; un numéro de téléphone en pied de page leur demande de passer l'appel eux-mêmes. Les deux font fuir les hésitants.

Ce module ne demande presque rien : un nom, et un numéro de téléphone ou une adresse e-mail. Le visiteur appuie sur un bouton, remplit deux champs, et c'est vous qui rappelez.

Quatre emplacements, choisis une fois pour toute la boutique

Vous choisissez où vit le formulaire parmi quatre options : un onglet coulissant sur le bord gauche, un onglet coulissant sur le bord droit, une barre basse en pied de page, ou un bouton flottant. Si vous optez pour le bouton flottant, un réglage distinct le place dans le coin inférieur gauche ou inférieur droit.

Le bouton flottant est le choix à faire en cas de doute. Un premier appui ouvre un petit menu d'actions, et ce menu ouvre le formulaire dans une fenêtre modale — il n'entre donc jamais en concurrence avec le contenu de la page et se comporte de la même façon sur mobile et sur ordinateur. L'onglet coulissant et la barre basse masquent volontairement des éléments à mesure que l'écran se rétrécit, pour que la mise en page tienne toujours : utile si votre trafic est surtout sur ordinateur, moins si vos visiteurs sont majoritairement sur mobile.

Sans CAPTCHA — et ce n'est pas un compromis

La version 1.x proposait une question de calcul entièrement calculée et vérifiée dans le navigateur du visiteur. Elle n'arrêtait rien, et elle agaçait tout le monde.

La version 2 la supprime et protège le formulaire de trois façons, toutes invisibles :

Un champ honeypot que les humains ne voient jamais et que les robots remplissent. Un jeton de temps signé — une signature HMAC-SHA256 sur l'instant où le formulaire a été généré — de sorte qu'un envoi est rejeté s'il arrive moins de deux secondes après le chargement de la page, ou plus de deux heures après. Et une limitation par IP qui accepte au maximum cinq demandes par heure depuis la même adresse.

Il n'y a rien à configurer et aucune énigme à résoudre pour un vrai visiteur.

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

Une alerte e-mail part vers les adresses que vous désignez. La demande est aussi enregistrée dans la table de base de données du module et affichée sur la page de configuration, où vous pouvez marquer les entrées comme lues ou non lues, les supprimer en lot et attacher une note privée à n'importe quelle demande.

Cette liste, c'est toute la différence entre une notification que vous risquez de manquer et un petit pipeline que vous pouvez réellement traiter.

Ce que le formulaire demande

Le nom est toujours demandé. Au-delà, vous choisissez téléphone uniquement, e-mail uniquement ou les deux, et vous pouvez éventuellement demander un type de demande pour que la requête arrive déjà triée.

Les couleurs du texte et du fond sont des réglages : le widget peut donc s'accorder à votre thème au lieu de le contrarier.

Consentement et vos pages légales

Une case de consentement est toujours affichée — aucun réglage ne permet de la désactiver. Elle arrive cochée, et si un visiteur la décoche, le serveur refuse l'envoi avec un message précis au lieu de l'accepter sans rien dire. Vous pouvez la pointer vers vos propres URL de Conditions générales et de Politique de confidentialité ; laissez ces champs vides et le module renvoie vers la page CMS Conditions générales déjà configurée dans votre boutique.

La version 1.x codait ici en dur un lien vers le site de démonstration de l'éditeur. C'est terminé.

La version 2 a corrigé plusieurs choses discrètement défaillantes

Le multiboutique ne fonctionnait pas. Le front-office et le gestionnaire d'envoi lisaient toujours les réglages de la boutique n° 1, quelle que soit la boutique où se trouvait le visiteur. Ils lisent désormais la configuration de la boutique en cours.

Les envois pouvaient échouer en silence. Le formulaire annonçait une réussite quoi qu'il se passe côté serveur. Il renvoie maintenant un vrai résultat, avec des messages par champ pour une adresse e-mail invalide ou un consentement manquant.

L'e-mail de notification ne trouvait pas son modèle sur certaines installations, car le répertoire des mails était résolu par rapport au contrôleur et non à la racine du module.

L'insertion des demandes construisait le SQL par concaténation de chaînes. Les demandes sont désormais écrites via des insertions paramétrées.

La table de stockage, au nom générique et propice aux collisions, est passée de callbacks à wecallyouback_request, et les lignes existantes sont migrées automatiquement lors de la mise à jour.

Corrections pour le thème Hummingbird de PrestaShop 9

Autant le dire clairement si vous utilisez Hummingbird, le thème par défaut de PrestaShop 9.

Le bouton flottant et sa fenêtre modale reposaient sur les attributs de données de Bootstrap 4 (data-toggle, data-dismiss), qu'un thème Bootstrap 5 ignore : cliquer sur le bouton ne faisait donc absolument rien. La 2.0.5 a réécrit les deux avec le JavaScript natif du module, sans dépendance à jQuery ni au composant modal du thème, si bien que le bouton fonctionne sur n'importe quel thème quelle que soit sa version de Bootstrap.

La 2.0.6 a empêché le texte d'appel à l'action du bouton de se répartir sur cinq lignes et corrigé son icône réduite à un filet par le flex-shrink. La 2.0.7 a centré la fenêtre modale verticalement au lieu de la laisser collée en haut de l'écran.

Un module plus léger en dessous

La version 2 est réservée à PrestaShop 1.7+ ; tous les chemins de code 1.4/1.5/1.6 et le dossier backward_compatibility/ ont été supprimés. Quatre gabarits front-office quasi identiques — un par version de PrestaShop — n'en font plus qu'un, et les CSS et JS des onglets coulissants gauche et droit ont fusionné dans des fichiers communs.

Ont également disparu : la dépendance externe aux Google Material Icons (désormais du SVG en ligne), une balise <script> pointant en dur vers un CDN jQuery, un ancien manuel PDF, un fichier source PSD et cinq dossiers de langues de mail inutilisés.

Compatibilité

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

Une réserve, en toute honnêteté : le modèle de l'e-mail de notification n'existe qu'en anglais et en français. Le formulaire côté visiteur et le back-office sont traduits dans les huit langues ; l'alerte qui arrive dans votre boîte de réception, non.

Trois hooks standard, aucune surcharge et aucune modification du thème. Encore sous PrestaShop 1.5 ou 1.6 ? Utilisez plutôt la version 1.x du module — les versions 2.0 et supérieures sont réservées à 1.7+.

Questions fréquentes

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 honeypot caché, un jeton de temps signé en HMAC qui rejette les envois arrivant moins de deux secondes ou plus de deux heures après le chargement de la page, et une limite de cinq demandes par heure depuis une même adresse IP. Un vrai visiteur ne voit rien de tout cela.

Où le formulaire apparaît-il ?

Là où vous le décidez pour toute la boutique, parmi quatre options : un onglet coulissant sur le bord gauche, un onglet coulissant sur le bord droit, une barre basse, ou un bouton flottant. Un réglage distinct place le bouton flottant dans le coin inférieur gauche ou inférieur droit. En cas de doute, choisissez le bouton flottant : il ouvre une fenêtre modale, donc la largeur de la page n'a aucune incidence.

J'utilise Hummingbird sur PrestaShop 9 et le bouton flottant ne fait rien.

Mettez à jour vers la 2.0.5 ou une version ultérieure. Avant cette version, le bouton utilisait les attributs de données de Bootstrap 4, que les thèmes Bootstrap 5 ignorent. Il s'appuie désormais sur le JavaScript propre au module et fonctionne sur n'importe quel thème. À noter : le bouton est un contrôle en deux temps, par conception — le premier appui ouvre un petit menu d'actions, et l'entrée du menu ouvre le formulaire.

La case de consentement est-elle facultative ?

Elle est toujours affichée et aucun réglage ne permet de la retirer. Elle arrive cochée, mais elle est réellement contrôlée : décochez-la et le serveur refuse l'envoi avec une erreur précise au lieu de l'accepter en silence.

Que demande le formulaire ?

Un nom, plus un numéro de téléphone, une adresse e-mail, ou les deux — à vous de choisir. Vous pouvez aussi demander un type de demande. Une case de consentement est toujours affichée.

Où vont les demandes ?

Vers les adresses e-mail de notification que vous avez définies, et vers une liste sur la page de configuration du module. Vous pouvez y marquer les demandes comme lues ou non lues, les supprimer en lot et ajouter une note privée à n'importe laquelle d'entre elles.

Aucun e-mail de notification n'arrive.

Vérifiez qu'une adresse de notification valide est bien renseignée : si ce n'est pas le cas, un avertissement s'affiche à côté du module dans la liste des modules et chaque envoi est journalisé avec son motif dans Paramètres avancés → Logs. Si une adresse est renseignée et que la remise échoue quand même, vérifiez Paramètres avancés → E-mail ainsi que ce même journal.

Le formulaire ne s'affiche pas côté boutique.

Vérifiez que le réglage "Show the form" (Afficher le formulaire) est sur Yes et que le module est activé. Sur un thème fortement personnalisé, assurez-vous qu'il appelle bien le hook displayHeader (ou header).

Puis-je utiliser ma propre illustration ?

Oui. Remplacez rep_bottom.png, rep_left.png ou rep_right.png dans le dossier views/img/ du module par un PNG de même dimension.

Du texte disparaît sur les écrans étroits.

C'est voulu pour la barre basse et l'onglet coulissant, qui masquent progressivement des éléments pour que le formulaire tienne encore. Utilisez plutôt la position bouton flottant si cela ne convient pas à votre trafic.

Que deviennent mes demandes existantes lors de la mise à jour depuis la 1.x ?

Elles sont migrées automatiquement. L'ancienne table callbacks est copiée dans la nouvelle table wecallyouback_request au premier chargement suivant la mise à jour, et vos réglages sont repris avec elles.