Module de recherche pour PrestaShop, et le thème ne s'en aperçoit pas

En bref

• Le module fait trois choses : il relie la boutique au compte, il garde le catalogue indexé, et il injecte une balise de script. Il ne modifie ni le thème ni la structure du catalogue.
• La barre de recherche du thème reste où elle est. Ce qui change, c'est qui lui répond, et c'est une ligne de configuration, pas une refonte.
• L'installation ne change rien pour les visiteurs. Le layer n'apparaît que lorsqu'il est activé, et il est possible de l'essayer en production pour une seule adresse IP.
• Compatible avec PrestaShop 1.7.6 et plus, y compris les branches 8 et 9.
• La désinstallation efface la configuration locale et rend la recherche à la plateforme. Rien n'est retenu.

Installer un module de recherche sur PrestaShop a mauvaise réputation, et à juste titre. Cela suppose en général de toucher au thème, d'apprendre un langage de templates qui n'est pas celui de la plateforme, et de découvrir trois mois plus tard qu'une mise à jour a cassé l'intégration.

Le module de Buskara a été conçu pour ne pas être cela. Il remplace la recherche de PrestaShop sans toucher à un seul fichier du thème, et cet article explique ce qu'il fait, ce à quoi il ne touche pas, et ce qui change une fois qu'il est activé.

Ce que fait le module de recherche, et ce à quoi il ne touche pas

Trois choses, et rien de plus :

1. Il relie la boutique au compte. Un clic sur Connecter à Buskara et la boutique se présente : adresse, versions, boutiques, langues et devises. Elle reçoit en retour son identifiant et un moteur de recherche pour chaque combinaison de boutique, de langue et de devise. Il n'y a rien à créer à la main de ce côté-ci.
2. Il garde le catalogue indexé. Enregistrer, supprimer ou modifier le stock d'un produit pousse la modification sur-le-champ. À cela s'ajoutent une synchronisation périodique et un bouton de réindexation complète.
3. Il injecte une balise de script. Une seule, sur chaque page, et uniquement quand l'interrupteur du layer est activé.

Ce qui reste exactement en l'état compte autant que ce qui change :

La barre de recherche du thème PrestaShop n'est ni remplacée ni déplacée. Elle reste au même endroit, avec la même apparence ; ce qui change, c'est qui répond quand quelqu'un écrit dedans. Si le sélecteur par défaut ne trouve pas la barre d'un thème moins conventionnel, cela se règle dans un champ de texte, et le sujet est traité dans apparence et intégration au thème.

La recherche livrée avec PrestaShop

Avant de dire ce qui change, il faut être juste avec ce qui existe déjà, et la meilleure source pour cela est la documentation de la plateforme elle-même.

La recherche native de PrestaShop est un index de mots qui se configure dans Paramètres de la boutique. La documentation officielle en décrit les pièces : on définit la longueur minimale des mots qui entrent dans l'index, il est recommandé de limiter la longueur maximale à 15 caractères pour que la recherche approximative reste rapide, et l'index peut être reconstruit depuis le back-office quand les comptes ne tombent pas juste.

Pour les fautes de frappe, la plateforme propose des alias : une liste où l'on écrit le mot erroné et le mot correct vers lequel il doit pointer. C'est une solution honnête et elle fonctionne. Ce qu'elle demande, c'est que quelqu'un pense à chaque faute avant qu'un client ne la commette.

C'est là que se trouve la différence de fond, et ce n'est pas une question de qualité de code :

La dernière ligne est la plus importante du tableau et il ne faut pas la cacher. La recherche native ne coûte rien et, dans une boutique de deux cents produits au vocabulaire stable, elle suffit généralement très bien. L'argument pour en changer apparaît quand le catalogue grandit, quand le vocabulaire du client s'éloigne de celui du fournisseur, ou quand personne n'a le temps de tenir une liste d'alias.

Ce qui change pour celui qui achète

La partie visible se décrit en deux lignes : la recherche répond pendant la saisie, et elle répond à davantage de choses.

On écrit mal et on trouve quand même. La tolérance aux fautes est automatique et proportionnelle à la longueur du mot, ce qui évite le problème classique de la correction excessive : « ancre » et « encre » ne sont qu'à une lettre l'une de l'autre et ne sont pas la même recherche, c'est pourquoi sur les mots courts on ne tolère rien. Le mécanisme est détaillé dans pourquoi la correction des fautes ne peut pas être silencieuse.

On décrit au lieu de nommer. « Un truc pour accrocher des vélos dans le garage » n'a aucun mot en commun avec la fiche du produit. C'est la catégorie de recherche que les catalogues servent le plus mal : dans le benchmark de recherche du Baymard Institute, 43 % des sites évalués ont des problèmes avec les recherches par cas d'usage et 39 % avec les recherches par caractéristique.

On pose des questions qui ne portent pas sur un produit. « Combien de temps prend la livraison » est écrit dans la barre de recherche bien plus souvent qu'on ne l'imagine, et avec le contenu de la boutique indexé, la réponse apparaît dans les résultats, dans un bloc à part qui ne vole pas la place aux produits.

La colonne de filtres sort de la recherche et non de la catégorie. Une recherche dont les résultats ont une couleur et une taille gagne ces cases ; une recherche où aucun résultat n'a de couleur ne les affiche pas. Le raisonnement est dans trop de filtres, c'est un endroit où la vente meurt.

Ce qui change pour celui qui gère la boutique

C'est la moitié qui n'apparaît pas sur les captures d'écran et c'est elle qui décide si un module de recherche vaut son prix.

La recherche se met à produire une liste de travail. Les termes revenus vides apparaissent classés par type de problème et triés selon l'estimation de ce qui se récupère par mois, et chacun porte l'action à côté : un synonyme, un champ produit à corriger, une décision d'achat. C'est le sujet de les recherches sans résultat sont la liste de courses que personne ne lit.

Il y a aussi trois signaux facultatifs que la boutique peut partager, et qui changent ce que le panneau parvient à dire :

• le volume de ventes par produit, qui alimente le tri par meilleures ventes et la détection des produits qui se vendent bien mais n'apparaissent jamais dans les résultats ;
• le prix de revient, qui met des marges dans les analytics au lieu du seul chiffre d'affaires ;
• les commandes, qui relient la recherche au chiffre d'affaires attribué.

Aucun de ces signaux n'est obligatoire, et le partage s'active et se désactive dans la configuration du module. Modifier celui des ventes ou celui du coût demande une réindexation complète, et le module prévient quand c'est le cas.

Installer le module de recherche sur PrestaShop

Les étapes exactes sont dans le guide d'installation, et il ne sert à rien de les recopier ici. Ce qui vaut la peine, c'est la forme, parce que c'est elle qui répond à la question que tout le monde pose en premier : quel risque cela représente.

1. Émettre une clé d'API dans le panneau. Elle n'apparaît qu'une seule fois, et elle est révocable sans être supprimée, ce qui veut dire qu'une erreur se rattrape. Voir clé d'API.
2. Installer le module et coller la clé. L'installation ne change rien pour les visiteurs.
3. Réindexer. Sur les gros catalogues, le bouton peut se heurter au temps d'exécution maximal de PHP, et pour ces cas il existe une commande en ligne qui n'a pas cette limite. Voir comment le catalogue est indexé et réindexer le catalogue.
4. Essayer seul. Le champ des IP de débogage fait apparaître le layer uniquement à ceux qui figurent dans la liste, ce qui permet de tester sur la boutique en production sans que personne ne s'en aperçoive.
5. Activer le layer quand tout est à votre goût.

Le point quatre est celui qui surprend le plus agréablement, et il a un revers qu'il vaut mieux connaître par cœur : tant qu'il y a des adresses dans ce champ, personne d'autre ne reçoit le layer. Si un jour la recherche semble avoir disparu de la boutique, c'est le premier endroit où regarder.

Pour et contre le remplacement de la recherche native de PrestaShop

La première ligne de la colonne de droite est l'objection sérieuse, et il n'existe pas de réponse qui l'annule. La réponse possible est celle de la dernière ligne de gauche : la sortie est toujours là, désinstaller efface la configuration locale et la recherche redevient celle de la plateforme dans l'heure.

Versions de PrestaShop prises en charge

Le module de recherche déclare une compatibilité à partir de PrestaShop 1.7.6.0 et sans limite supérieure fixe, ce qui inclut les branches 8 et 9. Il n'exige pas de thème particulier et n'oblige pas à changer de version.

Sur les thèmes dotés de leur propre recherche mobile, il est normal de devoir indiquer aussi quels boutons ouvrent la recherche et quoi masquer pendant qu'elle est ouverte. Ce sont des champs de texte dans la fiche de la boutique, pas des modifications du thème.

Questions fréquentes

Que fait un module de recherche pour PrestaShop ?

Il remplace la recherche native de la plateforme par un moteur dédié, qui répond désormais à la barre que le thème possède déjà. En pratique, il change trois choses : l'index, qui n'est plus reconstruit à la main et suit le catalogue ; le traitement des fautes de frappe et du vocabulaire, qui n'est plus une liste d'alias écrite faute après faute ; et les rapports, puisque la recherche native n'en a aucun. Le thème, le panier et la structure du catalogue restent tels quels.

Comment améliorer la recherche de PrestaShop sans changer de module ?

Il y a trois choses à faire sans rien installer, et elles valent la peine d'être faites avant de décider. Reconstruire l'index dans Paramètres de la boutique, parce que des comptes qui ne concordent pas entre produits et produits indexés expliquent beaucoup de « ne trouve pas ». Baisser la longueur minimale des mots, si le catalogue contient des références courtes. Et écrire des alias pour les fautes d'orthographe les plus fréquentes, que l'on découvre dans les journaux de recherche. Si après cela les clients continuent de ne pas trouver, le problème est de vocabulaire et de pertinence, et aucune configuration ne le résout.

Le module de Buskara modifie-t-il le thème PrestaShop ?

Il ne modifie ni les templates, ni le CSS, ni la structure du catalogue. Il ajoute une balise de script aux pages et se met à répondre à la barre de recherche que le thème possède déjà. Si le sélecteur par défaut ne trouve pas cette barre, on en indique un autre dans un champ de configuration.

Avec quelles versions de PrestaShop fonctionne-t-il ?

À partir de la 1.7.6.0, sans limite supérieure déclarée, ce qui inclut les branches 8 et 9. Il n'est pas nécessaire de changer de thème ni de version pour l'installer.

Puis-je l'essayer sans que les clients le voient ?

Oui. La configuration du module comporte un champ d'adresses IP de débogage : avec votre adresse dedans, le layer n'apparaît qu'à vous, même sur la boutique en production. Tant que ce champ n'est pas vide, aucun autre visiteur ne le reçoit.

Que se passe-t-il si je désinstalle le module ?

La configuration locale est effacée et la boutique revient à la recherche de la plateforme. L'index du côté de Buskara continue d'exister, il cesse simplement d'être alimenté par la boutique.

À quelle fréquence le catalogue est-il synchronisé ?

Les modifications sur les produits, stock compris, sont poussées au moment où elles sont enregistrées. À cela s'ajoutent une synchronisation périodique demandée depuis l'extérieur, et un bouton de réindexation complète pour quand on veut forcer. Sur les gros catalogues, la réindexation complète doit passer par la ligne de commande.

Cela vaut-il la peine si la boutique est petite ?

Pas toujours, et cela ne coûte rien de le dire. Sur un petit catalogue au vocabulaire stable, la recherche native et une courte liste d'alias suffisent généralement. L'argument pour changer apparaît quand le catalogue grandit, quand les clients emploient des mots différents de ceux du catalogue, ou quand la liste d'alias n'est plus tenue depuis un an. Les forfaits commencent à la taille de boutique où ce calcul a encore du sens.

Le module partage-t-il des données clients ?

Le catalogue est toujours partagé, puisque c'est ce que l'on indexe. Le volume de ventes, le prix de revient et les commandes sont trois signaux facultatifs, avec chacun son interrupteur, et ils servent respectivement au tri par meilleures ventes, aux marges dans les analytics et au chiffre d'affaires attribué à la recherche. Ils restent désactivés jusqu'à ce que quelqu'un les active.